diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d44d8a2..031703d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -25,7 +25,7 @@ The site is everything under `source/`. Most of it is written here, but two file
 | `/helm-charts/` (the Helm chart repository) | the chart packages of the `ansibleforms/helm-charts` releases, indexed at build time | the `helm-charts` repository |
 | everything else in `source/` | this repository | here |
 
-The docs are served under a language prefix (`/en/`, `/es/`), and the language selector in the header lists
+The docs are served under a language prefix, its ISO 639-1 code (`/en/`, `/es/`, `/de/`...), and the language selector in the header lists
 every language in `docs_languages` (`source/_config.yml`). Every page that used to live at the root keeps
 its address as a redirect, written at build time by `scripts/redirects.sh`, to the reader's language: the
 one they last picked, else their browser's, else English. The install script (`/install`) and the Helm chart
diff --git a/README.md b/README.md
index 260b4ad..867958d 100644
--- a/README.md
+++ b/README.md
@@ -18,7 +18,7 @@ The site covers everything a user of AnsibleForms needs, from the first install
 - The app's changelog, rebuilt into the site on every release
 - The Helm chart repository, served under `/helm-charts/`
 - The 6.x documentation, kept alongside under `/v6/`
-- The docs in English and Spanish under `/en/` and `/es/`, picked from the reader's browser language
+- The docs in the app's eleven languages, each under its ISO 639-1 code (`/en/`, `/es/`, `/fr/`, `/ja/`...), picked from the reader's browser language
 
 ## Previewing locally
 
diff --git a/i18n/ca.yml b/i18n/ca.yml
new file mode 100644
index 0000000..21ed3d8
--- /dev/null
+++ b/i18n/ca.yml
@@ -0,0 +1,42 @@
+# The Catalan docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: ca
+docs_language: "ca"
+
+title: "Documentació d'AnsibleForms"
+description: "Documentació tècnica d'AnsibleForms"
+
+footer_content: "Copyright © 2023-2026 AnsibleForms. Tots els drets reservats."
+
+# "Edit this page on GitHub" opens the Catalan page's source
+gh_edit_link_text: "Edita aquesta pàgina a GitHub"
+gh_edit_source: i18n/ca
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Introducció"
+    get_started:
+      name: "Primers passos"
+    configure:
+      name: "Configuració"
+    build_forms:
+      name: "Creació de formularis"
+    use:
+      name: "Guia d'usuari"
+    integrate:
+      name: "Integració"
+    security_assessment:
+      name: "Seguretat"
+    reference:
+      name: "Referència"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (la més recent)"
+    url: "/ca/"
+  - name: "6"
+    title: "6.x (en anglès)"
+    url: "/v6/"
diff --git a/i18n/ca/_build_forms/expressions/credentials.md b/i18n/ca/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..01ed7dc
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Credencials
+parent: Expressions
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Credencials
+{: .no_toc }
+
+Llegeix una credencial desada en una expressió
+{: .fs-6 .fw-300 }
+
+---
+
+Llegeix una credencial desada pel nom o per una expressió regular, amb una alternativa:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Primer es prova el nom exacte. Si cap credencial no té aquest nom, el nom s'utilitza com a expressió regular i després es prova l'alternativa.
+
+#### Limitat per rol
+
+Quan un dels rols de l'usuari inclou `credentials` a `config.yaml`, `fn.fnCredentials` només retorna una credencial que aquest rol
+permeti: els patrons del rol es comparen amb el nom de la credencial trobada (pel nom, per expressió regular o per l'alternativa),
+i qualsevol altra es rebutja. Els rols sense la llista no la limiten, i un administrador no està mai limitat.
+
+#### Credencials d'un magatzem de secrets
+
+Una credencial que indica un [magatzem de secrets](../secret-stores) obté el seu `user` i el seu `password`
+d'aquest magatzem en temps d'execució. `fn.fnCredentials('myapp')` continua funcionant sense canvis.
+
+Un secret també es pot llegir sense cap fila de credencial, allà on s'accepti un nom de credencial
+(inclosos `fnRestBasic`, `fnRestJwtSecure` i les substitucions de capçaleres de `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+Les claus del secret s'assignen tal com es descriu a [Noms de clau](../secret-stores#key-names).
+Un secret amb una altra forma es transforma amb una expressió `jq` com a tercer argument:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/ca/_build_forms/expressions/index.md b/i18n/ca/_build_forms/expressions/index.md
new file mode 100644
index 0000000..91088ff
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Expressions
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Expressions
+{: .no_toc }
+
+Calcula els valors dels camps amb JavaScript, al navegador o al servidor
+{: .fs-6 .fw-300 }
+
+---
+
+Per als autors de formularis: omple els camps de manera dinàmica amb JavaScript, calculats al navegador o obtinguts al servidor.
+
+L'atribut `expression` d'un camp de formulari et permet crear formularis dinàmics amb expressions JavaScript.
+
+---
+
+## Introducció
+
+L'atribut `expression` està disponible en diversos tipus de camp:
+- camp `enum`: per omplir les opcions del desplegable de manera dinàmica
+- camp `expression`: per obtenir o generar qualsevol tipus de dades
+- camp `html`: per construir-ne el contingut HTML
+- camps `yaml` i `list`: per omplir-ne les dades
+
+Les expressions JavaScript s'avaluen al **costat del servidor** (per defecte) o al **costat del client**, segons el que indiqui la propietat del camp `runLocal`.
+Un camp `html`, i els tipus de camp `local`, `local_out` i `credential`, sempre executen la seva expressió al navegador, digui el que digui
+`runLocal`.
+
+- **Al costat del servidor** (`runLocal: false`, el valor per defecte): funcions predefinides que obtenen dades d'API, fitxers i bases de dades.
+- **Al costat del client** (`runLocal: true`): el codi aprofita tot el motor JavaScript dins de l'entorn aïllat del navegador per fer càlculs, transformacions i manipulacions.
+
+---
+
+## Qüestions de seguretat
+
+Com que les expressions s'avaluen amb la funció `eval` de JavaScript, la injecció de codi és un risc potencial:
+
+- **Les expressions del costat del servidor** passen primer per un sanejador: cada crida ha de ser una funció `fn.` o `fnc.`, i es rebutgen les línies múltiples,
+  el `;`, les plantilles literals, `process.env` i les maneres de sortir d'`eval` (`import`, `require`, `constructor`, ...).
+- **Les expressions del costat del client** s'avaluen dins de l'entorn aïllat del navegador i es poden considerar segures.
+
+El nivell d'exigència del sanejador depèn de
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER):
+
+| Valor | Expressions del costat del servidor |
+|---|---|
+| `strict` (per defecte) | crides `fn.` i `fnc.`, i mètodes sobre el seu resultat, com ara `fn.fnTime().format('YYYY')` |
+| `paranoid` | només crides directes `fn.` i `fnc.`, sense mètodes sobre el seu resultat |
+| `off` | es rebutgen totes les expressions del costat del servidor; només funcionen les expressions `runLocal` |
+| `legacy` | les regles de la 6.2.1, que permeten a qualsevol usuari autenticat executar codi al servidor; només per a una actualització, i només a l'entorn real (no des de la pàgina de configuració) |
+
+Un valor buit o desconegut equival a `strict`. Un canvi s'aplica a la següent expressió, sense reiniciar.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Marcadors](placeholders.html) | Fer referència a un altre camp, a una constant o a l'usuari amb `$(...)` |
+| [Expressions locals](local.html) | JavaScript que s'executa dins de l'entorn aïllat del navegador |
+| [Expressions remotes](remote.html) | Funcions del costat del servidor per a dates, xarxes, fitxers, SSH i noms numerats |
+| [API REST](rest-apis.html) | Cridar API REST amb autenticació bàsica, per token o personalitzada |
+| [Credencials](credentials.html) | Llegir una credencial desada |
+| [Ordenació](sorting.html) | Ordenar matrius amb un objecte d'ordenació |
+| [Consultes jq](jq.html) | Transformar dades amb jq |
diff --git a/i18n/ca/_build_forms/expressions/jq.md b/i18n/ca/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..7484645
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Consultes jq
+parent: Expressions
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# Consultes jq
+{: .no_toc }
+
+Transforma dades amb jq, incloses les funcions integrades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Executar una consulta JSON (jq) sobre un objecte
+
+Transforma un objecte, per exemple el valor d'un altre camp, amb una expressió jq:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+A partir de la 7.3.0, un filtre jq s'executa com a màxim [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (30 per defecte)
+abans d'aturar-se, i la seva sortida es limita a 64 MB. Això s'aplica a `fn.fnJq` i a l'expressió jq de les funcions de REST, de fitxer,
+de credencial i de consulta a base de dades.
+
+---
+
+## Funcions JQ integrades
+
+Totes les funcions que obtenen dades accepten una consulta JSON (jq), un llenguatge per manipular objectes i matrius de dades.  
+Quan manipules dades, potser necessites convertir bytes a KB, MB o GB, o arrodonir nombres.  
+Per a això, AnsibleForms inclou unes quantes funcions jq pròpies:
+
+- **fn2KB**: de bytes a KB
+- **fn2MB**: de bytes a MB
+- **fn2GB**: de bytes a GB
+- **fnRound0**: arrodoneix amb 0 decimals
+- **fnRound1**: arrodoneix amb 1 decimal
+- **fnRound2**: arrodoneix amb 2 decimals
+- **fnRound**: arrodoneix amb 2 decimals
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/ca/_build_forms/expressions/local.md b/i18n/ca/_build_forms/expressions/local.md
new file mode 100644
index 0000000..1527a3e
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Expressions locals
+parent: Expressions
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Expressions locals
+{: .no_toc }
+
+JavaScript que s'executa dins de l'entorn aïllat del navegador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Els exemples següents s'executen amb la propietat del camp `runLocal: true`.  
+S'executen dins de l'entorn aïllat del navegador i poden aprofitar tot el motor JavaScript.
+
+{: .note }
+> **Consell**: fes servir el tipus `local` com a àlies de `type: expression, runLocal: true, hide: true, output: false`  
+> **Consell**: fes servir el tipus `local_out` com a àlies de `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Convenció de noms
+
+Fes servir manipulacions de cadenes per aplicar convencions de noms.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Càlcul
+
+Fes servir les matemàtiques per fer càlculs.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Conversions
+
+Converteix bytes a gigabytes.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Convertir una matriu d'objectes en una taula HTML
+
+Converteix una matriu d'objectes, per exemple d'un altre camp, en una taula HTML per a un camp `html`:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Obtenir un nom amb numeració incremental
+
+Amb la numeració automàtica, potser necessites trobar el nom següent en una matriu de cadenes numerades.  
+Aquesta funció també està disponible com a expressió del costat del servidor (amb el prefix `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Quan el primer argument no és una matriu, la funció local retorna el valor per defecte. La funció de servidor `fn.fnGetNumberedName`
+falla amb un error.
+
+---
+
+## Manipulació de matrius d'objectes
+
+Sovint cal filtrar, modificar i ordenar matrius d'objectes.  
+AnsibleForms inclou una eina auxiliar pròpia que manté aquest codi concís.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Manipulació de matrius d'objectes amb JavaScript pur
+
+Tots els mètodes estàndard de matrius de JavaScript continuen disponibles per filtrar i modificar les teves dades, com ara `map`, `forEach`, `find`, `filter` i `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/ca/_build_forms/expressions/placeholders.md b/i18n/ca/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..4505038
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Marcadors
+parent: Expressions
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Marcadors
+{: .no_toc }
+
+Fes referència a un altre camp, a una constant o a l'usuari actual amb `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Què és un marcador
+
+Un marcador és una referència escrita com a `$(reference)`. Se substitueix per un valor abans que s'utilitzi el text que el conté.
+
+Els marcadors funcionen a l'`expression`, la `query` i el `default` d'un camp (aquest últim avaluat amb `evalDefault`), i també al seu `label`,
+`help` i `placeholder`. Un camp que conté un marcador depèn del camp que anomena: espera fins que aquest camp tingui un
+valor, i es torna a avaluar cada vegada que aquest valor canvia. Així es construeixen els desplegables en cascada.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## A què pot fer referència un marcador
+
+Un marcador anomena un camp del formulari, o un d'aquests, que tenen tots els formularis:
+
+| Referència | Què conté |
+|---|---|
+| `$(field)` | el valor d'un altre camp del formulari |
+| `$(name)`, una constant | una [constant](../config/constants.html) de `config.yaml`, o un valor dels `varsFiles` del formulari |
+| `$(__user__)` | l'usuari que ha iniciat la sessió: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | en un [subformulari](../forms/subform.html) (una fila d'una llista, un pas d'un assistent), un valor del formulari pare |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Accedir a una part d'un valor
+
+La notació de punt i d'índex llegeix una part d'un valor, sempre que el camí només contingui lletres, dígits, `_`, `-`, `.` i `[n]`:
+
+| Marcador | Sobre | Dona |
+|---|---|---|
+| `$(field)` | un camp de text, de número o de contrasenya | el valor |
+| `$(field)` | un enum de registres | la `placeholderColumn` del registre seleccionat, o si no la seva primera columna |
+| `$(field.col)` | un enum de registres | aquesta columna del registre seleccionat |
+| `$(field)` | un enum amb `multiple: true` | la columna triada de cada registre seleccionat, com a matriu |
+| `$(field)` | una expressió, una llista o una constant | el valor sencer (una llista dona les seves files) |
+| `$(field.a.b)`, `$(f[0].x)` | una expressió, una llista o una constant | aquesta part de l'objecte o de la matriu |
+
+Posar `placeholderColumn: "*"` en un enum fa que `$(field)` doni tot el registre seleccionat en lloc d'una sola columna.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Com s'insereix el valor
+
+La manera com s'insereix un valor al text depèn d'on es troba el marcador.
+
+| On | Exemple | Es converteix en |
+|---|---|---|
+| una expressió, fora de cometes | `$(count) + 1` | un literal JavaScript: un número continua sent un número, un text es converteix en una cadena entre cometes, un objecte o una matriu en un literal |
+| una expressió, tota una cadena entre cometes | `fn.fnLs('$(dir)')` | el mateix literal, cometes incloses, de manera que un valor amb una cometa no se'n pot escapar |
+| una expressió, dins d'una cadena més llarga | `'$(dir)/vars'` | el text, escapat per a aquesta cadena |
+| una consulta, una etiqueta, un text d'ajuda | `where city='$(city)'` | el text |
+
+Un camp els marcadors del qual encara no es poden resoldre tots no s'avalua; amb `ignoreIncomplete: true`, un valor que falta
+s'insereix com a `undefined`.
+
+### Accents greus i `${` en un valor
+
+A partir de la 7.3.0, el valor d'un camp no es pot executar com a codi quan el servidor l'insereix en una expressió (expressions remotes, validació
+del llançament, MCP i xat). Un accent greu o un `${` al valor s'escriu com una seqüència d'escapament Unicode (```, `${`), de manera que continua sent
+text fins i tot dins d'una plantilla literal. Les expressions del costat del servidor rebutgen del tot les plantilles literals; per a això fes servir `runLocal`.
+
+Una expressió `runLocal` avaluada al navegador insereix el valor tal com indica la taula anterior, sense aquest escapament, així que no posis
+un marcador dins d'una plantilla literal en aquest cas.
+
+---
+
+## Vegeu també
+
+Pàgines relacionades i entrades de les PMF:
+
+- [Expressions locals](local.html) i [Expressions remotes](remote.html): on s'utilitzen la majoria dels marcadors
+- [PMF: Desplegables en cascada](../faq.html#cascaded-dropdowns) i [Marcadors de camp](../faq.html#field-placeholders): més exemples
+- [PMF: Com accedeixo a les dades del formulari pare des d'un subformulari?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/ca/_build_forms/expressions/remote.md b/i18n/ca/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..b05eb5e
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Expressions remotes
+parent: Expressions
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Expressions remotes
+{: .no_toc }
+
+Funcions del costat del servidor per a dates, xarxes, fitxers, SSH i noms numerats
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Els exemples següents s'executen amb la propietat del camp `runLocal: false` (per defecte).  
+S'avaluen al costat del servidor.
+
+Com que avaluar codi al servidor és un risc de seguretat, l'expressió se saneja i es limita a les funcions que
+porta AnsibleForms i a les [funcions que hi afegeixis tu](#your-own-functions).  
+Les expressions del costat del servidor estan pensades per obtenir informació de fonts de dades com ara fitxers, API REST i ordres SSH.
+
+{: .important }
+Les funcions integrades del costat del servidor porten el prefix `fn.` (per exemple, `fn.fnRestBasic`), i les teves, el prefix `fnc.`.
+
+---
+
+## Manipular la data i l'hora
+
+Treballa amb dates i hores mitjançant [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## Obtenir la informació CIDR d'una IP
+
+Obtén la subxarxa d'una adreça IP i d'una màscara de xarxa, i comprova quines adreces en formen part:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## Obtenir la sortida d'SSH
+
+Executa una ordre en un amfitrió remot per SSH i fes servir la seva sortida:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Llistar els fitxers d'un directori
+
+Llista els fitxers d'un directori del servidor d'AnsibleForms, opcionalment de manera recursiva i filtrats:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Analitzar una pàgina HTML
+
+Obtén una pàgina HTML i extreu-ne les parts que coincideixen amb una expressió regular:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+La pàgina s'obté sota [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) i
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), com les funcions REST. A diferència d'aquestes, ignora
+`REST_IGNORE_CERTS` i `REST_TIMEOUT_SECONDS`: sempre comprova el certificat i espera com a màxim 30 segons.
+
+---
+
+## Obtenir informació DNS
+
+Resol un registre DNS d'un domini:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Llegir un fitxer JSON
+
+Llegeix un fitxer JSON del servidor, opcionalment filtrat amb jq:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Llegir un fitxer YAML
+
+Llegeix un fitxer YAML del servidor, opcionalment filtrat amb jq:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Obtenir un nom amb numeració incremental
+
+En una matriu de cadenes amb números incrementals (server001, server002, ...), potser necessites trobar el següent nom disponible.  
+Aquesta funció també està disponible com a expressió local (sense el prefix `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Al servidor, `fn.fnGetNumberedName` falla amb un error quan el primer argument no és una matriu. L'expressió local
+(sense `fn.`) retorna el valor per defecte.
+
+---
+
+## Les teves pròpies funcions
+
+Afegeix funcions JavaScript pròpies a `custom.js` i crida-les en una expressió de servidor amb el prefix `fnc.`.
+
+El fitxer exporta un objecte de funcions. El que porta la imatge conté dos exemples:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+De la mateixa manera, `jq.custom.definitions` conté definicions jq pròpies. S'afegeixen al davant de cada consulta jq que
+executa el servidor, de manera que les [consultes jq](jq.html) de qualsevol funció les poden fer servir.
+
+En un contenidor, munta tots dos fitxers per sobre dels de la imatge i reinicia; es llegeixen quan s'inicia el servidor:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Una funció personalitzada s'executa dins del procés del servidor, amb els seus permisos, cada vegada que una expressió la crida. El
+> [sanejador](index.html#security-concerns) comprova que l'expressió només cridi funcions `fn.` i `fnc.`; el que una
+> funció fa amb els seus arguments és cosa teva.
diff --git a/i18n/ca/_build_forms/expressions/rest-apis.md b/i18n/ca/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..9bc3ed6
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: API REST
+parent: Expressions
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# API REST
+{: .no_toc }
+
+Crida API REST amb autenticació bàsica, per token o personalitzada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## API REST amb autenticació bàsica
+
+Crida una API REST amb l'usuari i la contrasenya d'una credencial desada:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## API REST amb autenticació per token
+
+Crida una API REST amb un token bearer escrit a l'expressió:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST amb autenticació per token segura
+
+Crida una API REST amb un token bearer tret d'una credencial desada, de manera que no apareix mai al formulari:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST amb capçaleres personalitzades
+
+Crida una API REST amb capçaleres pròpies, per a qualsevol altre tipus d'autenticació:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certificats i temps límit
+
+A partir de la 7.3.0, totes les funcions auxiliars REST (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) comproven el certificat
+TLS del punt final i deixen d'esperar passat un temps determinat:
+
+| Opció | Què canvia |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` omet la comprovació del certificat. Fins a la 7.2.0 no es comprovava mai; deixa-ho a `0` i, en lloc d'això, confia en una CA privada amb `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Quant de temps espera una crida una resposta, 60 segons per defecte; així, un punt final que no respon mai fa fallar el camp en lloc de deixar-lo bloquejat |
+
+A partir de la 7.3.0, un camp el punt final del qual té un certificat autosignat falla amb un error de certificat fins que es defineix una de les dues opcions.
+[Crides REST i jq](../customization/security.html#rest-calls-and-jq) descriu totes dues, i com confiar en una CA privada per a totes les crides REST alhora.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) no és una funció auxiliar REST: ignora totes dues opcions, sempre comprova el
+certificat i espera com a màxim 30 segons.
diff --git a/i18n/ca/_build_forms/expressions/sorting.md b/i18n/ca/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..51f37af
--- /dev/null
+++ b/i18n/ca/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Ordenació
+parent: Expressions
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Ordenació
+{: .no_toc }
+
+Ordena matrius amb un objecte d'ordenació
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ordenar una matriu
+
+Ordena una matriu que ve d'una expressió, d'una API REST o d'una base de dades amb un objecte d'ordenació:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## L'objecte d'ordenació
+
+Les funcions REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) accepten aquest objecte d'ordenació
+com a argument. Per a qualsevol altre resultat, com ara `fn.fnJq` o la lectura d'un fitxer, embolcalla'l amb `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/ca/_build_forms/formfields/checkbox.md b/i18n/ca/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..6ea8817
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Camps de formulari
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Camp Checkbox
+{: .no_toc }
+
+Un valor cert o fals, per activar una opció o marcar un indicador
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `checkbox`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `checkbox`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/datetime.md b/i18n/ca/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..61b1b1e
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Camps de formulari
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Camp Datetime
+{: .no_toc }
+
+Un selector de data, hora, setmana, mes o any
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `datetime`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `datetime`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/enum.md b/i18n/ca/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..162b715
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Camps de formulari
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Camp Enum
+{: .no_toc }
+
+Un desplegable amb cerca, per a una o diverses opcions
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `enum`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `enum`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/expression.md b/i18n/ca/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..7d94374
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Camps de formulari
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Camp Expression
+{: .no_toc }
+
+Un valor calculat amb JavaScript, al navegador o al servidor
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `expression`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `expression`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/file.md b/i18n/ca/_build_forms/formfields/file.md
new file mode 100644
index 0000000..dc19eb8
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Camps de formulari
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Camp File
+{: .no_toc }
+
+Puja fitxers, com ara fitxers de configuració o certificats
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `file`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `file`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/html.md b/i18n/ca/_build_forms/formfields/html.md
new file mode 100644
index 0000000..62508e4
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Camps de formulari
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Camp Html
+{: .no_toc }
+
+Contingut HTML enriquit dins d'un formulari
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `html`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `html`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/index.md b/i18n/ca/_build_forms/formfields/index.md
new file mode 100644
index 0000000..10f693b
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Camps de formulari
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Camps de formulari
+{: .no_toc }
+
+Els controls d'entrada d'un formulari
+{: .fs-6 .fw-300 }
+
+---
+
+Per als autors de formularis: els tipus de camp que pot contenir un formulari i les propietats que admet cadascun.
+
+Els camps de formulari defineixen els controls d'entrada d'un formulari. Cada tipus de camp té les seves pròpies propietats i el seu propi comportament per recollir un tipus concret de dades.
+
+Tria el tipus de camp que correspongui a les dades que vols recollir, des de text pla fins a llistes estructurades.
+
+---
+
+## Propietats comunes
+
+Tots els camps de formulari comparteixen dues propietats fonamentals:
+
+- **name** (string, obligatori): l'identificador únic del camp
+- **type** (string, obligatori): el tipus de camp, que determina quina de les pàgines següents descriu les propietats disponibles
+
+Cada tipus de camp afegeix propietats pròpies de la seva funció. Selecciona un tipus de camp a la barra lateral de navegació o a la taula següent per obrir la referència completa de les seves propietats:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Tipus de camp</th>
+      <th>Descripció</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/ca/_build_forms/formfields/list.md b/i18n/ca/_build_forms/formfields/list.md
new file mode 100644
index 0000000..80a1f68
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Camps de formulari
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Camp List
+{: .no_toc }
+
+Una taula de files, cadascuna editada en un subformulari
+{: .fs-6 .fw-300 }
+
+---
+
+Un camp list mostra una taula de files, cadascuna creada i editada en un panell de **subformulari** dedicat (un patró de navegació en profunditat). Substitueix el camp `table`, que es va eliminar a la 7.0.0.
+
+---
+
+## Característiques principals
+
+El camp list ofereix les possibilitats següents:
+
+- Cada fila s'edita en un subformulari a pantalla completa, amb accés a tots els tipus de camp, incloses les llistes niades.
+- El subformulari és un formulari en si mateix, de tipus `subform`, i es pot **reutilitzar en diversos camps list** de formularis diferents (p. ex. un sol subformulari `Address` compartit per clients, proveïdors, comandes…).
+- Les propietats de marcatge (`insertMarker`, `updateMarker`, `deleteMarker`) permeten patrons de playbook idempotents.
+- Amb `allowDelete: false`, les files que ja existien estan protegides; només es poden eliminar les files afegides a la sessió actual (les que porten l'`insertMarker`).
+- La propietat `columns` controla quins camps del subformulari apareixen com a columnes a la taula de resum.
+- La sortida és sempre una matriu d'objectes. Quan es generen les extravars, es respecten els `model`, `output`, `outputObject` i `valueColumn` declarats als camps del subformulari.
+
+---
+
+## Declaració del subformulari
+
+Un subformulari és un formulari en si mateix amb `type: subform`, en un fitxer de la carpeta de formularis com qualsevol altre formulari. Accepta la mateixa matriu `fields` que qualsevol altre formulari, però no apareix mai a la llista de mosaics de formularis i no s'envia mai directament.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `list`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Exemples</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Exemples
+
+### Subformulari d'adreça compartit
+
+Un subformulari `Address` reutilitzat per dos camps list del mateix formulari:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Seguiment amb marcadors (pensat per a la idempotència)
+
+Les files precarregades estan protegides, i els marcadors indiquen al playbook quines files són noves, quines han canviat i quines s'han eliminat:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Emplenar les files per endavant
+
+Una llista es pot emplenar per endavant des de tres fonts. En tots els casos, les files resultants han de ser objectes les claus dels quals coincideixin amb els noms dels camps del subformulari referenciat.
+
+#### `default` estàtic
+
+Files escrites al mateix formulari:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Des d'una API REST (`expression`)
+
+Files carregades des d'una API REST per una expressió del costat del servidor:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Des d'una consulta a base de dades (`dbConfig` + `query`)
+
+Files carregades des d'una consulta a base de dades:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Des d'una expressió local (`runLocal`)
+
+Files calculades al navegador per una expressió local:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Llistes niades
+
+Un subformulari pot contenir un camp list propi, per tenir una llista dins de cada fila:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Accedir a les dades del formulari pare amb `__parent__`
+
+Quan s'obre l'editor de files d'un subformulari, AnsibleForms injecta una variable `__parent__` al subformulari. Conté una instantània de **tots els valors dels camps del formulari pare**, incloses les constants i les variables.
+
+Fes-hi referència amb la sintaxi d'expressió estàndard `$(...)` a les definicions dels camps del subformulari:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` és una eina auxiliar **només del frontend**. Es treu de les extravars d'Ansible i no s'envia mai al playbook.
+
diff --git a/i18n/ca/_build_forms/formfields/number.md b/i18n/ca/_build_forms/formfields/number.md
new file mode 100644
index 0000000..50bc9a0
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Camps de formulari
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Camp Number
+{: .no_toc }
+
+Un valor enter o decimal, com ara un port o una quantitat
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `number`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `number`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/password.md b/i18n/ca/_build_forms/formfields/password.md
new file mode 100644
index 0000000..12b9f79
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Camps de formulari
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Camp Password
+{: .no_toc }
+
+Un valor emmascarat, per a contrasenyes, secrets i tokens
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `password`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `password`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/radio.md b/i18n/ca/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..c0ad048
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Camps de formulari
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Camp Radio
+{: .no_toc }
+
+Una opció d'entre un conjunt d'opcions mútuament excloents
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `radio`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `radio`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/text.md b/i18n/ca/_build_forms/formfields/text.md
new file mode 100644
index 0000000..0a106f2
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Camps de formulari
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Camp Text
+{: .no_toc }
+
+Una sola línia de text, com ara un nom o un nom d'amfitrió
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `text`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `text`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/textarea.md b/i18n/ca/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..dacaaad
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Camps de formulari
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Camp Textarea
+{: .no_toc }
+
+Text de diverses línies, com ara una descripció o un fragment de configuració
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `textarea`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `textarea`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ca/_build_forms/formfields/yaml.md b/i18n/ca/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..17ba3c7
--- /dev/null
+++ b/i18n/ca/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Camps de formulari
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Camp YAML
+{: .no_toc }
+
+Dades estructurades en un editor YAML, amb validació i importació de fitxers
+{: .fs-6 .fw-300 }
+
+---
+
+## Propietats
+
+Les propietats disponibles per a un camp `yaml`, agrupades per finalitat:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de camps `yaml`, en YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició del camp, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Accedir a les dades del formulari pare amb `__parent__`
+
+Quan un camp `yaml` fa servir el mode `subform`, AnsibleForms injecta una variable `__parent__` al subformulari. Conté una instantània de **tots els valors dels camps del formulari pare** en el moment en què s'obre l'editor, incloses les constants i les variables.
+
+Fes-hi referència amb la sintaxi d'expressió estàndard `$(...)` a les definicions dels camps del subformulari:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` és una eina auxiliar **només del frontend**. Es treu de les extravars d'Ansible i no s'envia mai al playbook.
diff --git a/i18n/ca/_build_forms/forms/ansible.md b/i18n/ca/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..88064b3
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularis d'Ansible
+parent: Formularis
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Formularis d'Ansible
+{: .no_toc }
+
+Formularis que executen un playbook d'Ansible local
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: ansible`, a més de les [propietats comunes dels formularis](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/approval.md b/i18n/ca/_build_forms/forms/approval.md
new file mode 100644
index 0000000..544b400
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Punts d'aprovació
+parent: Formularis
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Punts d'aprovació
+{: .no_toc }
+
+Atura una tasca fins que algú l'aprovi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Com funciona
+
+Un punt d'aprovació atura la tasca en el lloc que ocupa al formulari fins que un aprovador hi respon:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Aprovar la teva pròpia tasca
+
+A partir de la 7.3.0, l'usuari que ha llançat una tasca no la pot aprovar, encara que tingui un dels rols de l'aprovació, de manera que cal una segona persona; un administrador sempre pot aprovar, també les seves pròpies tasques.
+Qui l'ha llançada encara pot rebutjar (retirar) la seva pròpia tasca. Posa `allowSelf: true` quan també la pugui aprovar, per exemple en un formulari de proves:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Atributs
+
+Els atributs d'un punt d'aprovació:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de punts d'aprovació, en YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/awx.md b/i18n/ca/_build_forms/forms/awx.md
new file mode 100644
index 0000000..02667ee
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularis d'AWX
+parent: Formularis
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# Formularis d'AWX
+{: .no_toc }
+
+Formularis que llancen una plantilla de job d'AWX, AAP o Ascender
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: awx`, a més de les [propietats comunes dels formularis](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/common.md b/i18n/ca/_build_forms/forms/common.md
new file mode 100644
index 0000000..2d51379
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Propietats comunes
+parent: Formularis
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Propietats comunes dels formularis
+{: .no_toc }
+
+Propietats que comparteixen tots els tipus de formulari
+{: .fs-6 .fw-300 }
+
+---
+
+Aquestes propietats s'apliquen a **tots els tipus de formulari**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (obsolet) i `subform`.
+
+Totes les altres propietats són específiques de cada tipus i es documenten a la pàgina del tipus de formulari corresponent.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Propietats
+
+Les propietats que comparteixen tots els tipus de formulari:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/ca/_build_forms/forms/index.md b/i18n/ca/_build_forms/forms/index.md
new file mode 100644
index 0000000..4711dd8
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formularis
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formularis
+{: .no_toc }
+
+Defineix els formularis que omplen els teus usuaris
+{: .fs-6 .fw-300 }
+
+---
+
+Per als autors de formularis: com s'escriuen els formularis en YAML, d'on es carreguen i les propietats de cada tipus de formulari.
+
+Els formularis són el nucli d'AnsibleForms. Cada formulari és una interfície web que recull les dades de l'usuari i, amb aquestes dades, executa un
+playbook d'Ansible, una plantilla d'AWX, AAP o Ascender, una plantilla de Semaphore, un job de Rundeck o de Jenkins, o un
+[workflow](../workflows/).
+
+Els formularis es defineixen en fitxers YAML a la carpeta de formularis. Cada fitxer YAML conté un sol formulari o una llista de formularis, i es poden fer servir subcarpetes per organitzar-los.
+
+**VÍDEO**: [Crea el teu primer formulari](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Entendre l'estructura d'un formulari
+
+Cada formulari d'AnsibleForms es configura amb un conjunt de propietats. **[Propietats comunes](common.html)** recull les propietats que s'apliquen a tots els tipus de formulari; les pàgines específiques de cada tipus descriuen les addicionals.
+
+---
+
+## Com es carreguen els formularis
+
+AnsibleForms carrega els formularis des de les ubicacions següents:
+
+1. **DES DELS REPOSITORIS**: tots els repositoris amb l'interruptor "Utilitzar per als formularis" activat (s'admeten diversos repositoris)
+   - Els formularis de tots els repositoris activats es fusionen automàticament.
+   - Primer es comprova si cada repositori té una subcarpeta `forms/`.
+   - Si no hi ha cap subcarpeta `forms/`, es fa servir l'arrel del repositori.
+   - Els formularis creats al dissenyador que encara no s'han enviat amb push es guarden en una carpeta de preparació
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) i es carreguen juntament amb els altres.
+
+2. **DES DE LA CARPETA LOCAL**: la carpeta local `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), quan cap repositori no té activat "Utilitzar per als formularis"
+
+{: .warning }
+> **Nota:** quan "Utilitzar per als formularis" està activat en diversos repositoris, se'n fusionen tots els formularis. Els noms dels formularis han de ser únics entre repositoris per evitar conflictes.
+
+---
+
+## On s'executa un formulari
+
+El tipus d'un formulari decideix el tipus de [runner](../runners.html) on s'executa la seva tasca: un RTE per a `ansible`, un runner d'AWX per a `awx`,
+`aap` i `ascender`, i un runner del seu mateix tipus per a `semaphore`, `rundeck` i `jenkins`.
+
+- `runner: <name>` al formulari tria pel nom un runner d'aquest tipus; sense això, la tasca s'executa al runner per defecte del tipus.
+- Un runner desactivat a **Connexions > Runners** fa fallar la tasca, tant si el formulari l'anomena com si és el per defecte. La tasca
+  no recorre mai a un altre runner.
+- Quan un dels rols de l'usuari inclou `runners` a `config.yaml`, la tasca només es pot executar en un runner que aquest rol inclogui, o es
+  rebutja. Els rols sense la llista no la limiten, i un administrador no està mai limitat.
+
+---
+
+## En aquesta secció
+
+Les pàgines següents descriuen en detall les propietats dels formularis:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Propietats comunes](common.html) | Propietats que s'apliquen a tots els tipus de formulari (`name`, `description`, `help`, `type`, `fields`) |
+| [Formularis d'Ansible](ansible.html) | Propietats específiques de `type: ansible` |
+| [Formularis d'AWX](awx.html) | Propietats específiques de `type: awx` |
+| [Formularis de Semaphore](semaphore.html) | Propietats específiques de `type: semaphore`, que executa una plantilla de Semaphore |
+| [Formularis de Rundeck](rundeck.html) | Propietats específiques de `type: rundeck`, que executa un job de Rundeck |
+| [Formularis de Jenkins](jenkins.html) | Propietats específiques de `type: jenkins`, que fa un build d'un job de Jenkins |
+| [Formularis multipas](multistep.html) | Propietats específiques de `type: multistep`, obsolet en favor de `workflow` |
+| [Formularis de workflow](workflow.html) | Propietats específiques de `type: workflow`, que executa un [workflow](../workflows/) |
+| [Assistent](wizard.html) | Repartir les dades d'un formulari en diverses pàgines (funciona sobre qualsevol tipus de formulari executable) |
+| [Subformulari](subform.html) | Els subformularis només fan servir les propietats comunes |
+| [Punts d'aprovació](approval.html) | Aturar una tasca fins que s'aprovi (`approval`) |
+| [Notificacions](notifications.html) | Enviar correus i missatges a canals segons l'estat o els esdeveniments d'una tasca (`notifications`) |
+| [Accions segons l'estat de la tasca](job-status-action.html) | Actuar sobre el formulari quan una tasca canvia d'estat (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/ca/_build_forms/forms/jenkins.md b/i18n/ca/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..7e54a48
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularis de Jenkins
+parent: Formularis
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Formularis de Jenkins
+{: .no_toc }
+
+Formularis que fan un build d'un job de Jenkins
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: jenkins`, a més de les [propietats comunes dels formularis](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/job-status-action.md b/i18n/ca/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..e1fa412
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Accions segons l'estat de la tasca
+parent: Formularis
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Accions segons l'estat de la tasca
+{: .no_toc }
+
+Actua sobre el formulari quan la seva tasca s'envia, té èxit, falla o acaba
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Hi ha disponibles els ganxos següents:
+
+- `onSubmit`: s'activa quan s'envia el formulari
+- `onSuccess`: s'activa quan la tasca acaba correctament
+- `onFailure`: s'activa quan la tasca falla
+- `onFinish`: s'activa quan la tasca acaba, sigui quin sigui el seu estat
+- `onAbort`: s'activa quan s'avorta la tasca
+
+---
+
+## Atributs
+
+Els atributs d'una acció segons l'estat de la tasca:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples d'accions segons l'estat de la tasca, en YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/multistep.md b/i18n/ca/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..c122020
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Formularis multipas
+parent: Formularis
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Formularis multipas
+{: .no_toc }
+
+Executa diversos playbooks o plantilles en seqüència des d'un sol formulari
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` està obsolet des de la 7 i s'elimina a la 8: fes servir un [workflow](workflow.html) en el seu lloc. Un workflow fa tot el que
+> fa un multistep, amb condicions, valors propis per a cada node, nodes d'aprovació i branques que s'executen en paral·lel.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietat a nivell de formulari
+
+Un formulari multipas defineix els seus passos en una única propietat a nivell de formulari:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / obligatori</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+A més de `steps`, un formulari multipas accepta aquestes propietats a nivell de formulari, documentades a la pàgina [Formularis d'Ansible](ansible.html):
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (obligatòria){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Propietats dels passos
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Només disponible amb els tipus:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Afegit</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Exemples
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Exemple
+
+Un formulari multipas executa diverses tasques en seqüència, i cada pas llança el seu propi playbook o plantilla d'AWX. Tots els passos comparteixen els camps del formulari: per defecte, cada pas rep totes les extravars, i la `key` d'un pas el limita a aquesta part.
+
+### Crear i configurar un servidor
+
+Cada pas rep la seva pròpia part de les extravars: un pas d'AWX crea el servidor, un pas d'Ansible en configura la xarxa i un últim pas sempre envia un informe:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/ca/_build_forms/forms/notifications.md b/i18n/ca/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..467c8df
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Notificacions
+parent: Formularis
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Notificacions
+{: .no_toc }
+
+Envia un correu o un missatge a un canal quan una tasca acaba o li passa alguna cosa
+{: .fs-6 .fw-300 }
+
+---
+
+Les `notifications` d'un formulari indiquen qui s'assabenta de les seves tasques, i quan:
+
+- **Qui**: `recipients`, adreces de correu electrònic, i `channels`, els noms dels
+  [canals de notificació](../notification-channels.html) (correu, Slack, Microsoft Teams, Telegram, un webhook). Cal com a mínim
+  un dels dos.
+- **Quan**: `onStatus`, quan una tasca acaba (`success`, `failed`, `aborted`, `warning` o `any`), i `onEvent`, quan
+  li passa alguna cosa a una tasca (`launch`, `relaunch`, `delete`, `approve`, `reject` o `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Atributs
+
+Els atributs de l'objecte `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de notificacions, en YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definició, en YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/rundeck.md b/i18n/ca/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..0aa606a
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularis de Rundeck
+parent: Formularis
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Formularis de Rundeck
+{: .no_toc }
+
+Formularis que executen un job de Rundeck
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: rundeck`, a més de les [propietats comunes dels formularis](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/semaphore.md b/i18n/ca/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..fa3a03e
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularis de Semaphore
+parent: Formularis
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Formularis de Semaphore
+{: .no_toc }
+
+Formularis que executen una plantilla de Semaphore UI
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: semaphore`, a més de les [propietats comunes dels formularis](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/forms/subform.md b/i18n/ca/_build_forms/forms/subform.md
new file mode 100644
index 0000000..1750706
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Subformulari
+parent: Formularis
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Subformulari
+{: .no_toc }
+
+Un fragment de formulari reutilitzable per a camps list, camps yaml i pàgines d'assistent
+{: .fs-6 .fw-300 }
+
+---
+
+Un subformulari és un fragment de formulari reutilitzable. No apareix a la vista de mosaic i no es pot enviar directament. En lloc d'això, s'hi fa referència des de:
+
+- Un camp [`list`](../formfields/list.html): obre el subformulari com a editor de detall per a cada fila
+- Un camp [`yaml`](../formfields/yaml.html) amb la propietat `subform`: obre el subformulari com a editor de detall per a un sol objecte
+- Un pas d'un [`wizard`](wizard.html): mostra el subformulari com una pàgina de l'assistent
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Els subformularis **no tenen propietats específiques del tipus**. Només fan servir les [propietats comunes dels formularis](common.html): `name`, `description`, `help`, `type` i `fields`.
+
+Quan un subformulari fa de pàgina d'un assistent, el seu `description` i el seu `help` proporcionen els valors per defecte del `title` i el `help` del pas. També pot definir `showHelp` per desplegar aquesta ajuda quan es carrega la pàgina.
+
+Les propietats d'execució (`playbook`, `template`, `roles`, `inventory`, etc.) no s'apliquen als subformularis, perquè un subformulari no s'envia mai directament.
+
diff --git a/i18n/ca/_build_forms/forms/wizard.md b/i18n/ca/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..33510aa
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Assistent
+parent: Formularis
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Assistent
+{: .no_toc }
+
+Reparteix les dades d'un formulari en diverses pàgines amb Enrere i Següent
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Què és un assistent?
+
+Un **assistent** (`wizard`) converteix un sol formulari en una seqüència de pàgines. Cada pàgina es genera a partir d'un [`subform`](subform.html) i l'usuari hi navega amb els botons **Enrere** i **Següent**. La validació s'aplica pàgina per pàgina: l'usuari no pot avançar fins que el pas actual sigui vàlid, tret que el pas estigui marcat com a `optional`.
+
+Al final de cada assistent s'hi afegeix automàticament una **pàgina de revisió** de només lectura. Mostra cada pas amb els valors recollits perquè l'usuari els pugui confirmar abans d'enviar. La pàgina de revisió **no** es declara en YAML; el seu títol surt de l'idioma actiu.
+
+En enviar, els **valors recollits de tots els passos es fusionen en un sol conjunt d'extravars** i s'envien al playbook, la plantilla o el workflow subjacent, exactament com si l'usuari hagués omplert un únic formulari gran.
+
+Un formulari amb un `wizard` no necessita `fields` propis, però no pot definir `enableForChat`, i un `subform` no pot tenir un `wizard` propi. La [validació del llançament](../launch-validation/rolling-it-out.html#wizard-forms) comprova el llançament d'un assistent pas a pas.
+
+{: .note }
+> Per saber en què es diferencia un `wizard` d'un workflow, i com es combinen, consulta l'entrada de les PMF [Quina diferència hi ha entre un assistent i un workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Propietat a nivell de formulari
+
+Un assistent s'activa amb una única propietat a nivell de formulari:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">afegit a la versió {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Exemples:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats dels passos de l'assistent
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatori</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / únic</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Afegit</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Exemples
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Combinar un assistent amb un workflow
+
+Un assistent es pot posar per sobre d'un formulari de [workflow](workflow.html). Quan el `defaultModel` de cada pas de l'assistent coincideix amb l'[`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) del node corresponent del workflow, cada playbook o plantilla rep només els valors de la seva pròpia pàgina de l'assistent.
+
+Les PMF contenen un exemple complet i l'estructura de les extravars fusionades: [Quina diferència hi ha entre un assistent i un workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (secció *Combinat (assistent per sobre d'un workflow)*).
+
+Un assistent en un formulari [`multistep`](multistep.html), que està obsolet, funciona de la mateixa manera, amb la [`key`](multistep.html#step_key) del pas en lloc d'`extra_vars_key`.
+
+---
+
+## Vegeu també
+
+Pàgines relacionades i entrades de les PMF:
+
+- [Subformulari](subform.html): les pàgines de l'assistent es generen a partir de subformularis
+- [Formularis de workflow](workflow.html): l'equivalent de l'assistent a la capa d'execució
+- [`__parent__` als subformularis](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): com fer referència als passos anteriors de l'assistent des d'un pas posterior
diff --git a/i18n/ca/_build_forms/forms/workflow.md b/i18n/ca/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..eeebe16
--- /dev/null
+++ b/i18n/ca/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Formularis de workflow
+parent: Formularis
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Formularis de workflow
+{: .no_toc }
+
+Formularis que executen un dels workflows del dissenyador
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propietats
+
+Propietats específiques de `type: workflow`, a més de les [propietats comunes dels formularis](common.html). La secció
+[Workflows](../workflows/) descriu els fitxers de workflow en si.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atribut</th>
+      <th>Comentaris</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatori</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">afegit a la versió {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcions:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (per defecte)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Per defecte:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ca/_build_forms/launch-validation/file-uploads.md b/i18n/ca/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..3a5f0f5
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Pujades de fitxers
+parent: Validació del llançament
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Pujades de fitxers
+{: .no_toc }
+
+Com es validen els camps de fitxer
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un camp de fitxer no es fia mai del que diu la petició de llançament sobre un fitxer. La validació del llançament comprova el fitxer mateix, al
+disc del servidor.
+
+---
+
+## Com arriba una pujada a una tasca
+
+Un fitxer es puja abans de llançar el formulari, en dos passos:
+
+1. El navegador puja el fitxer amb `POST /api/v2/job/upload`. El servidor el desa a `UPLOAD_PATH`.
+2. La petició de llançament descriu aquesta pujada a la seva part `files`.
+
+Després, la validació del llançament compara la descripció amb el disc:
+
+* El fitxer ha d'existir dins d'`UPLOAD_PATH`.
+* El seu camí i la seva mida es llegeixen del disc, mai de la petició.
+
+---
+
+## Què s'accepta
+
+Un camp de fitxer només obté un valor d'una pujada verificada. Qualsevol altra cosa es descarta:
+
+* Un camí que qui fa la crida escrigui a `rawFormData` o a `extravars` s'ignora.
+* Un camp de fitxer obligatori sense una pujada real es notifica com a `missing`.
+
+---
+
+## Regles de fitxer
+
+Les regles d'un camp de fitxer es comproven amb la pujada real, amb les mides en bytes:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` i `maxSize` comparen la mida real del fitxer, i `regex`, el seu nom. Independentment de qualsevol formulari,
+`UPLOAD_MAX_GB` limita la mida d'una sola pujada (10 GB per defecte).
diff --git a/i18n/ca/_build_forms/launch-validation/index.md b/i18n/ca/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..5bf168a
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Validació del llançament
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Validació del llançament
+{: .no_toc }
+
+Comprova al servidor cada llançament d'un formulari
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors i autors de formularis: fes que el servidor comprovi cada llançament, les seves regles i les seves extravars, l'enviï qui l'enviï.
+
+La comprovació s'aplica sigui qui sigui o sigui el que sigui que llanci el formulari: el navegador, un script que crida l'API REST
+o un agent d'IA a través del servidor MCP.
+
+---
+
+## Per què existeix
+
+Les regles d'un formulari (`required`, `regex`, `minValue`, `sameAs`, ...) sempre s'han comprovat
+al navegador. Després, el navegador envia dues coses a `POST /api/v2/job`:
+
+- `rawFormData`: els valors dels camps tal com els ha omplert l'usuari;
+- `extravars`: el que rep el playbook, construït al navegador a partir d'aquests valors.
+
+Sense la validació del llançament, el servidor es fia de totes dues. Qualsevol persona amb un token vàlid pot cridar aquest
+punt final directament i enviar-hi qualsevol extravar, sense que s'apliqui cap regex, camp obligatori ni regla de
+llista. Per a un formulari que només es fa servir al navegador, això pot ser acceptable; per a un
+formulari que altres sistemes llancen per REST, vol dir que les regles del formulari no s'apliquen en absolut.
+
+A més, el servidor no té manera de distingir una petició del navegador d'una enviada per un
+script: totes dues fan servir el mateix punt final, el mateix token i el mateix cos, i els usuaris poden modificar
+qualsevol petició que enviï el seu propi navegador. Només es pot confiar en una comprovació feta al servidor, i la validació
+del llançament és aquesta comprovació.
+
+---
+
+## Les tres vies d'entrada
+
+La manera com es valida un llançament depèn de per on arriba i del mode de validació del llançament:
+
+| Llançat per | Validat | Extravars amb què s'executa la tasca |
+|---|---|---|
+| **Servidor MCP** (agent d'IA) | sempre, al servidor | sempre construïdes pel servidor |
+| **Navegador** o **API REST**, validació del llançament `off` | només al navegador | les que ha enviat el navegador (o qui fa la crida) |
+| **Navegador** o **API REST**, validació del llançament `log` | al servidor, els rebuigs només es registren | les enviades; les diferències es registren |
+| **Navegador** o **API REST**, validació del llançament `enforce` | al servidor, es rebutja si no és vàlid | **construïdes pel servidor** |
+
+El navegador, el servidor MCP i la validació del llançament fan servir el mateix codi per a les regles (el
+motor de formularis compartit): les mateixes regles, en el mateix ordre i amb els mateixos missatges. Un error que
+mostra el navegador, el servidor el rebutja amb el mateix text.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Activar-la](switching-it-on.html) | Per a tota la instància, o per a un formulari |
+| [Registrar i aplicar](log-and-enforce.html) | Què fa cada mode amb un llançament que incompleix les regles |
+| [Files de llista](list-rows-and-subforms.html) | Com es validen les files dels camps list |
+| [Pujades de fitxers](file-uploads.html) | Com es validen els camps de fitxer |
+| [Contrasenyes](passwords.html) | Com es validen els camps de contrasenya i com es mantenen fora de les API |
+| [Rellançament](relaunching.html) | Com es valida una tasca rellançada |
+| [Desplegar-la](rolling-it-out.html) | Passar una instància a enforce, i les limitacions conegudes |
diff --git a/i18n/ca/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/ca/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..c6468b6
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Files de llista
+parent: Validació del llançament
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Files de llista
+{: .no_toc }
+
+Com es validen les files dels camps list
+{: .fs-6 .fw-300 }
+
+---
+
+Un camp `list` conté files; cada fila és una instància del seu subformulari, emplenada amb l'editor
+de files. Un camp `yaml` amb un `subform` és una d'aquestes files. El servidor les tracta de la mateixa manera
+que l'editor de files del navegador: cada fila es resol a través del seu subformulari, amb els valors del formulari
+com a `__parent__`, se'n comproven les regles i se n'avaluen els camps calculats. Les llistes niades funcionen
+igual: dins de la llista pròpia d'una fila, `$(__parent__.__parent__.x)` arriba fins al formulari.
+
+Les files es comproven així:
+
+- **Una fila que l'usuari ha afegit o editat** a l'editor es resol i es valida.
+- **Una fila que ningú no ha tocat**, generada pel valor per defecte, l'expressió o la consulta de la mateixa llista
+  (com ara les entrades existents d'una llista d'ACL), passa **exactament tal com ha arribat**, igual que al
+  navegador: no es torna a validar i no s'hi afegeix res. Una entrada existent que incompleix una regla
+  escrita més tard no atura el llançament.
+- **Una fila marcada com a eliminada** (el `deleteMarker` de la llista) es conserva tal com és i no es valida.
+
+Per distingir aquestes files sense fiar-se de la petició, el servidor torna a executar la font de la
+llista (el seu valor per defecte o, si no, la seva expressió o consulta) sota la validació del llançament. Una fila
+que no ha passat per l'editor passa sense canvis **només si és una de les files que genera
+aquesta font**. Qualsevol altra fila, com ara una que s'inventi qui fa una crida REST, es resol i es
+valida com una fila editada. Per tant, una fila senzilla no es pot saltar les comprovacions, mentre que les
+files no tocades del navegador continuen passant sense canvis.
+
+Un usuari del navegador només ho nota en un cas: les dades de la font han canviat entre que s'ha obert el
+formulari i que s'ha llançat (mentrestant s'ha canviat o eliminat una entrada), **i** aquesta fila
+incompleix una regla del seu subformulari. Llavors la fila ja no compta com una de les files de la font, de manera que
+es valida, i el llançament es rebutja indicant la fila, per exemple
+`acls[2].user_or_group (regex)`.
+
+Les files que fallen apareixen a `rowErrors` amb el seu `index` (un camp `yaml` no en té) i al registre com a
+`disks[1].size (maxValue)`.
+
+Un llançament pot contenir com a màxim **500 files** sumant tots els nivells de niament, ja que cada fila executa les consultes del seu subformulari.
+
+---
+
+## Marcadors de fila
+
+Els marcadors que una llista posa a les seves files (`insertMarker`, `updateMarker` i `deleteMarker`; sense
+`insertMarker`, les files noves reben `__inserted__` quan la llista defineix `allowDelete: false`, un `deleteMarker` o un `updateMarker`)
+arriben al playbook en cada fila que en porta un. Una fila eliminada s'envia amb el seu marcador
+d'eliminació, perquè el playbook la pugui eliminar. Abans de la 6.4.1, una fila de llista només portava un marcador si el seu
+subformulari el declarava com a camp (ocult).
diff --git a/i18n/ca/_build_forms/launch-validation/log-and-enforce.md b/i18n/ca/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..df8df52
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Registrar i aplicar
+parent: Validació del llançament
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Registrar i aplicar
+{: .no_toc }
+
+Què fa cada mode amb un llançament que incompleix les regles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Què fa `log`
+
+Es comprova cada llançament, però per a l'usuari no canvia res. S'escriu un avís al registre quan:
+
+- el llançament **es rebutjaria**, amb el motiu (només noms de camp i tipus de regla, mai
+  valors):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- les extravars que ha enviat el client **difereixen** de les que construeix el servidor, amb les
+  claus de primer nivell que difereixen:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Primer, fes funcionar `log` durant un temps en una instància real. Mostra quins formularis es rebutjarien i
+quins calculen valors diferents al servidor, abans que afecti ningú.
+
+---
+
+## Què fa `enforce`
+
+Amb `enforce`, un llançament no vàlid es rebutja, i un de vàlid s'executa amb les extravars que construeix
+el servidor.
+
+### Un llançament que incompleix les regles es rebutja
+
+`POST /api/v2/job` respon `422` amb els camps que fallen:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing`: camps obligatoris sense valor;
+- `invalid`: camps que incompleixen una regla, opcions que no són cap de les permeses i camps list
+  amb alguna fila que falla;
+- `waiting`: camps que no s'han pogut avaluar (un camp que necessiten no ha arribat a tenir valor);
+- `validationErrors`: per a cada camp, totes les regles que fallen amb el missatge que mostra el navegador;
+- `rowErrors`: per a cada camp list, les files que fallen (vegeu [Files de llista](list-rows-and-subforms.html));
+- `uploads`: camps de fitxer la pujada dels quals no s'ha pogut verificar.
+
+Un llançament **sense `rawFormData`** també es rebutja: els seus valors no es poden comprovar.
+
+### Un llançament vàlid s'executa amb les extravars del servidor
+
+La tasca no s'executa amb les extravars que ha enviat el client. El servidor les construeix a partir dels valors
+comprovats, amb el mateix codi que el navegador, i executa aquestes. Qui fa una crida enviant uns `rawFormData` vàlids
+al costat d'unes `extravars` diferents obté les extravars que corresponen als valors, no
+les que ha enviat.
+
+De la petició, el servidor conserva `__verbose__` (només per als usuaris que tenen permès el mode detallat). Les
+claus reservades (`__playbook__`, `__inventory__`, ...) surten del formulari, com sempre, i
+`ansibleforms_user` és l'usuari que llança.
+
+### El que ha vist l'usuari no sempre és el que s'executa
+
+Construir les extravars vol dir tornar a avaluar el formulari: cada expressió i cada consulta s'executa
+un altre cop al servidor, un moment després que ho hagi fet el navegador, com l'usuari que llança. Un valor
+que depèn de **quan** o **on** s'avalua pot ser diferent, i en aquest cas es fa servir el
+valor del servidor:
+
+| Què | Per què pot ser diferent | En quina mesura |
+|---|---|---|
+| `fn.fnTime()`, una marca de temps, un nom construït a partir de l'hora | s'avalua de nou, uns segons més tard | només importa en el límit d'un segon o d'una data. `fnTime` ja s'executa al servidor també en el flux del navegador, amb la mateixa zona horària (el `TZ` del contenidor) |
+| una consulta, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, la lectura d'un fitxer | les dades externes han canviat entremig | només quan han canviat |
+| una expressió `runLocal` que fa servir `new Date()`, `toLocaleString`, `Intl` | el navegador fa servir la zona horària i l'idioma de l'usuari, el servidor els seus | només aquestes expressions |
+
+El mateix s'aplica a la **validació**: una regla que llegeix un camp d'aquests (`notIn` contra el resultat d'una
+consulta, `validIf` sobre un indicador calculat) es comprova amb el valor del servidor. Els formularis les
+extravars dels quals difereixen apareixen als avisos de `log` descrits més amunt; revisa'ls abans d'aplicar enforce.
diff --git a/i18n/ca/_build_forms/launch-validation/passwords.md b/i18n/ca/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..c36df14
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Contrasenyes
+parent: Validació del llançament
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Contrasenyes
+{: .no_toc }
+
+Com es validen, es desen i es mantenen fora de les API els camps de contrasenya
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un camp de contrasenya es valida com qualsevol altre camp. Ara bé, el seu valor es queda al servidor i no es retorna mai a
+cap client.
+
+---
+
+## On es desa una contrasenya
+
+El servidor desa la contrasenya amb la tasca, a les seves extravars:
+
+* Així, una **aprovació** pot continuar la tasca amb la contrasenya que ha introduït l'usuari.
+* Un **rellançament tal com es va executar** la pot tornar a fer servir, quan la validació del llançament no és `enforce`.
+
+La contrasenya desada només es fa servir al servidor.
+
+---
+
+## Què retornen les API
+
+Cap API no retorna mai una contrasenya:
+
+* Una tasca llegida a través de l'API REST o del `get_job` del servidor MCP emmascara tots els camps `password` del seu formulari, també dins de
+  les files de llista i dels subformularis YAML.
+* `MASK_EXTRAVARS_REGEX` (per defecte `password|secret|token`) també emmascara totes les extravars el nom de les quals hi coincideix, per als
+  secrets que no són camps de contrasenya.
+
+---
+
+## Què rep un rellançament
+
+Per emplenar per endavant un rellançament, el navegador rep les dades en brut del formulari de la tasca. Aquestes dades no contenen mai cap contrasenya, ni tan sols dins de
+les files de llista o dels subformularis YAML, de manera que l'usuari torna a introduir la contrasenya.
+
+Un camp de contrasenya que les dependències del formulari amaguen no és necessari, i no s'ha de tornar a introduir.
diff --git a/i18n/ca/_build_forms/launch-validation/relaunching.md b/i18n/ca/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..f2a1651
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Rellançament
+parent: Validació del llançament
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Rellançament
+{: .no_toc }
+
+Com es valida una tasca rellançada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Una tasca es pot rellançar de dues maneres. Com es comprova el rellançament depèn de quina es faci servir, i del mode de validació
+del llançament.
+
+---
+
+## Dos tipus de rellançament
+
+Els dos tipus es diferencien en si qui fa la crida envia valors nous o no:
+
+* **Tal com es va executar**: el botó Rellança, `POST /api/v2/job/{id}/relaunch` sense cos, o `relaunch_job` sense
+  `values`.
+* **Amb canvis**: les mateixes crides amb valors nous, aplicats per sobre dels valors dels camps desats de la tasca:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Com es comprova cadascun
+
+El mode de validació del llançament decideix si un rellançament es reprodueix o es torna a comprovar:
+
+| Rellançament | `off` / `log` | `enforce` |
+|---|---|---|
+| **Tal com es va executar** | reprodueix les extravars desades de la tasca, contrasenyes incloses | la comprovació completa, a partir dels valors dels camps desats |
+| **Amb canvis** | la comprovació completa, sobre els valors desats amb els canvis aplicats a sobre | la comprovació completa, de la mateixa manera |
+
+Una excepció amb `enforce`: una tasca llançada per una programació de nivell d'administrador no té valors de camp propis, de manera que rellançar-la tal com es va executar
+reprodueix les extravars desades de la programació, per a un administrador o per a un usuari amb l'opció de rol `allowScheduledJobs`.
+
+Un rellançament comprovat (vegeu [Registrar i aplicar](log-and-enforce.html)) inicia una tasca nova a nom de qui fa la crida.
+
+---
+
+## Camps de contrasenya
+
+Els valors dels camps desats no contenen contrasenyes, de manera que un rellançament comprovat no en té cap per a un **camp de contrasenya visible**:
+
+* El rellançament es rebutja com a `unsupported`, amb els `passwordFields` que li falten.
+* Torna a llançar el formulari i introdueix la contrasenya.
+* Un camp de contrasenya que les dependències del formulari **amaguen** no és necessari i no bloqueja el rellançament.
+
+Amb `enforce`, això també s'aplica al botó Rellança.
+
+---
+
+## Qui pot rellançar
+
+Tots dos tipus de rellançament requereixen:
+
+* que el formulari permeti el rellançament (`allowRelaunch`, true per defecte);
+* l'opció de rol `allowJobRelaunch`;
+* que l'usuari sigui **el propietari de la tasca**, un administrador o un usuari amb l'opció de rol `manageAllJobs`.
+
+Veure totes les tasques (`showAllJobLogs`) no és suficient per rellançar la tasca d'un altre usuari. Els aprovadors poden veure una tasca que espera la seva
+aprovació, però tampoc no la poden rellançar.
diff --git a/i18n/ca/_build_forms/launch-validation/rolling-it-out.md b/i18n/ca/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..6c965d8
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Desplegar-la
+parent: Validació del llançament
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Desplegar-la
+{: .no_toc }
+
+Passar una instància a enforce, i les limitacions conegudes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Desplegament
+
+`enforce` és el valor per defecte. En una instància amb scripts o altres sistemes que llancen formularis per
+REST, arriba-hi per passos, vigilant el registre abans de rebutjar res:
+
+1. Defineix `LAUNCH_VALIDATION=log` per a tota la instància (abans d'actualitzar, si es tracta d'una actualització).
+2. Funciona en aquest mode durant un temps i revisa el registre: els avisos `would refuse` indiquen llançaments
+   que incompleixen les regles; els avisos `extravars differ` indiquen formularis que calculen alguna cosa
+   de manera diferent al servidor (una marca de temps, dades externes). Decideix per a cada formulari si això
+   importa.
+3. Passa aquests formularis a `launchValidation: enforce`. Qui feia crides amb valors no vàlids o
+   amb extravars inventades ara rep un `422` amb el motiu.
+4. Quan tots els formularis es comportin com s'espera, treu `LAUNCH_VALIDATION` (o posa-hi `enforce`) per a tota la instància.
+
+---
+
+## Limitacions
+
+La validació del llançament encara no ho cobreix tot:
+
+- Els **formularis amb assistent** no es poden rellançar amb canvis, i una tasca d'assistent llançada abans de la 7.0
+  no es pot rellançar amb `enforce` (no desava els valors dels passos). El servidor MCP
+  no pot llançar formularis amb assistent.
+- La **resolució de marcadors** al navegador encara fa servir la seva pròpia còpia del codi del servidor; en
+  casos límit poc freqüents (`__undefined__`, cometes dins d'expressions) tots dos podrien resoldre un
+  marcador de manera diferent. `log` posa de manifest aquestes diferències.
+- Les expressions **`runLocal`** s'executen al motor JavaScript del navegador quan és al navegador, i en un
+  entorn aïllat al servidor; el mateix codi produeix el mateix resultat, excepte quan depèn de
+  la zona horària o de l'idioma del navegador.
+
+---
+
+## Formularis amb assistent
+
+Un [assistent](../forms/wizard.html) es comprova pas a pas: el navegador envia els valors de
+cada pas, i el servidor comprova cada pas que l'usuari enviaria amb el seu propi subformulari.
+
+- Un pas es deixa fora quan és `optional` i l'usuari se l'ha saltat, o quan el seu `when` és fals.
+- Un pas llegeix els passos anteriors a través de `$(__parent__.<step>.<field>)`, amb els seus valors comprovats.
+- Els errors indiquen el pas i el camp, com a `<step>.<field>`.
+- Amb `enforce`, les extravars es construeixen al servidor, cada pas sota el seu `defaultModel`.
+- Els camps de fitxer no s'admeten en un assistent.
diff --git a/i18n/ca/_build_forms/launch-validation/switching-it-on.md b/i18n/ca/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..d139b5e
--- /dev/null
+++ b/i18n/ca/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Activar-la
+parent: Validació del llançament
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Activar-la
+{: .no_toc }
+
+Per a tota la instància, o per a un formulari
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La validació del llançament té dues opcions. **S'aplica la més estricta de les dues.**
+
+---
+
+## Per a tota la instància: `LAUNCH_VALIDATION`
+
+La variable d'entorn [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) s'aplica a tots els formularis:
+
+- `off`: cap comprovació al servidor; la tasca s'executa amb les extravars que ha enviat el navegador o qui fa la crida.
+- `log`: es comprova cada llançament; el que es rebutjaria s'escriu al registre com a
+  avís, i el llançament s'executa igual que abans.
+- `enforce` (per defecte): un llançament no vàlid es rebutja, i un de vàlid s'executa amb les extravars que
+  construeix el servidor.
+
+Un valor buit o desconegut també equival a `enforce`. Els canvis tenen efecte sense reiniciar.
+
+{: .warning }
+> **L'actualització canvia el comportament.** Una instància que no defineix `LAUNCH_VALIDATION` aplica la validació a
+> tots els llançaments després de l'actualització. Els scripts que criden `POST /api/v2/job` sense `rawFormData`,
+> o amb valors que incompleixen les regles d'un formulari, es rebutgen amb un `422`. Defineix
+> `LAUNCH_VALIDATION=log` abans d'actualitzar per veure què es rebutjaria, o `off` per mantenir el
+> comportament antic (vegeu [Desplegar-la](rolling-it-out.html)).
+
+---
+
+## Per a un formulari: `launchValidation`
+
+Un formulari pot definir el seu propi nivell:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Fes servir aquesta opció en una instància que funciona amb `off` o `log`, per a un formulari que saps que es
+llançarà per REST: aquest formulari queda en enforce, mentre que la resta de la instància no. També es pot definir al dissenyador, a la
+configuració del formulari.
+
+**Un formulari es pot fer més estricte que la instància, mai més permissiu.** Amb `LAUNCH_VALIDATION`
+a `enforce`, el `launchValidation: off` d'un formulari no té cap efecte: un formulari no pot passar per sobre
+de la decisió d'un operador.
+
+Els formularis amb assistent també la fan servir: el llançament d'un assistent es comprova pas a pas, cada pas amb el seu propi
+subformulari (vegeu [Formularis amb assistent](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/ca/_build_forms/workflows/designer.md b/i18n/ca/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..2003dfe
--- /dev/null
+++ b/i18n/ca/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Edició al dissenyador
+parent: Workflows
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Edició al dissenyador
+{: .no_toc }
+
+Dibuixa un workflow i prova'l sense executar res
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La secció Fluxos de treball
+
+**Dissenyador > Fluxos de treball** mostra els fitxers de workflow en un explorador de fitxers, amb les pestanyes YAML, Visual i Previsualització de totes les
+seccions del [dissenyador](../designer/).
+
+- **El botó `+`** de la barra d'eines crea un fitxer de workflow, amb un workflow buit per començar.
+- **YAML** mostra el fitxer tal com està escrit. Les altres pestanyes també conserven els comentaris i l'ordre de les claus.
+- **Visual** dibuixa cada workflow del fitxer com un graf, amb el seu nom i la seva descripció a sobre. Un fitxer amb dos workflows
+  mostra tots dos, l'un sota l'altre.
+- **Previsualització** és una simulació del workflow: vegeu [Provar-lo](#trying-it-out).
+
+Els problemes es mostren a sobre del graf, cadascun amb un enllaç que obre el YAML a la seva línia: un enllaç a un node que no
+existeix, un bucle, o un playbook, inventari, credencial, runner o repositori que el dissenyador no coneix.
+
+---
+
+## El graf
+
+El graf es llegeix d'esquerra a dreta, des de **START** fins als últims nodes. Cada node mostra el seu identificador i, a sota, què
+executa; els enllaços tenen colors segons què els activa, tal com indica la llegenda dins del graf: en cas d'èxit, en cas d'error,
+sempre.
+
+- **Fes clic a START** per afegir un primer node: un node sense pare, que s'executa tan bon punt comença el workflow.
+- **Fes clic en un node** per editar-lo.
+- **Fes clic en un enllaç** per canviar què l'activa, o per treure'l.
+
+---
+
+## Afegir un node
+
+Un node nou s'afegeix amb un assistent: **Node nou si té èxit**, **Node nou si falla** o **Node nou sempre** en un node
+existent, o START per al primer.
+
+1. **Què executa**: l'identificador del node, **Executa** (quin tipus de node és i, per a un node de playbook, on s'executa)
+   i què executa: un playbook o una plantilla o job, un workflow, el nom i el temps límit d'una aprovació, o un repositori. Vegeu
+   [On s'executa un node](#where-a-node-runs).
+2. **Com s'executa**: les opcions d'execució: l'inventari, les credencials, el límit, les etiquetes, la verbositat,
+   el mode check i el mode diff, la condició (**S'executa si**) i **Valors de** (vegeu [el fitxer de workflow](file.html#run-settings)).
+3. **On va**: el node després del qual s'executa, i en quin cas.
+
+**Crear** afegeix el node al YAML.
+
+---
+
+## On s'executa un node
+
+**Executa** indica què executa un node i on, en una sola llista: **Playbook a l'RTE**, **Plantilla a AWX**, **Plantilla a
+Semaphore**, **Job a Rundeck**, **Job a Jenkins**, i després **Workflow**, **Aprovació** i **Pull de repositori**.
+
+| Executa | El camp de sota | Runner |
+|---|---|---|
+| **Playbook a l'RTE** | **Playbook**: un playbook del dissenyador | **L'RTE per defecte**, o un runner RTE pel nom |
+| **Plantilla a AWX** (AAP i Ascender inclosos) | **Plantilla**: el nom de la plantilla, escrit a mà | els runners d'AWX, cadascun amb la seva variant |
+| **Plantilla a Semaphore** | **Plantilla**: el nom de la plantilla, escrit a mà | els runners de Semaphore |
+| **Job a Rundeck** o **Job a Jenkins** | **Job**: el nom del job, escrit a mà | els runners de Rundeck o de Jenkins |
+
+- **Playbook a l'RTE** s'ofereix sempre; els altres, només quan la instància té un [runner](../runners.html) d'aquest tipus.
+- **Runner** només mostra els runners d'aquest tipus, amb el per defecte marcat i preseleccionat (o el primer per nom).
+- Triar un altre lloc esborra el que executa el node, de manera que s'ha de tornar a triar.
+- Un node el runner del qual el dissenyador no coneix mostra **Plantilla o job a** aquest runner.
+
+El fitxer de workflow no canvia: un node així és un node `job_template` amb un `runner:` (vegeu
+[el fitxer de workflow](file.html#run-settings)).
+
+---
+
+## Editar un node
+
+En fer clic en un node s'obre el seu diàleg, amb quatre pestanyes:
+
+| Pestanya | Què conté |
+|---|---|
+| **Què executa** | L'identificador, **Executa**, què executa i, per a un node de playbook, el runner |
+| **Com s'executa** | Les opcions d'execució; les credencials es trien d'una llista, i cadascuna s'afegeix amb `+` |
+| **S'executa després de** | Els enllaços que arriben al node, i **Tots els pares han de convergir** |
+| **Executa després** | Els enllaços que en surten, amb **Enllaçar a un node existent:** i **Enllaçar a un node nou:** |
+
+**Mostra en YAML** obre el YAML al node, i **Treure node** el treu amb els seus enllaços. Cada canvi s'escriu al
+YAML immediatament; **Desa** desa el fitxer.
+
+---
+
+## Provar-lo
+
+La pestanya **Previsualització** recorre el workflow sense llançar res, segons les regles d'AWX.
+
+Tots els nodes comencen amb èxit. Fes clic en un node perquè falli, i torna-hi a fer clic perquè tingui èxit; llavors el graf mostra
+quins nodes s'executarien, quins no s'executarien i si el workflow fallaria. **Restablir** torna a fer que tots els nodes tinguin èxit.
diff --git a/i18n/ca/_build_forms/workflows/file.md b/i18n/ca/_build_forms/workflows/file.md
new file mode 100644
index 0000000..8918c03
--- /dev/null
+++ b/i18n/ca/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: El fitxer de workflow
+parent: Workflows
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# El fitxer de workflow
+{: .no_toc }
+
+La sintaxi del workflow, els tipus de node i les opcions d'execució de cada node
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## On són els fitxers de workflow
+
+Els fitxers de workflow són fitxers YAML a la carpeta local de workflows i a cada repositori que es fa servir per a workflows.
+
+- **La carpeta local** és [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), per defecte `workflows` dins de la
+  carpeta persistent.
+- **Un repositori** amb **Fer servir per a workflows?** activat es llegeix sencer, de manera que els seus fitxers de workflow poden estar a qualsevol carpeta. El
+  dissenyador els torna a desar al repositori, i **Push** els envia al remot.
+
+Es llegeix cada fitxer YAML que conté `workflow_job_templates`, fins a sis carpetes de profunditat, i un fitxer pot contenir diversos
+workflows. Un formulari anomena un workflow pel seu `name`, així que mantén els noms únics: quan dos workflows comparteixen nom, una tasca que
+l'executa falla i demana que en reanomenis un.
+
+---
+
+## La sintaxi
+
+Un fitxer de workflow s'escriu amb la sintaxi d'una exportació d'AWX, amb els nodes a `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+També es llegeix la forma de la col·lecció `awx.awx`: `workflow_nodes` directament sota el workflow, i noms escrits com a
+cadenes simples (`inventory: staging`) en lloc de mapes (`inventory: {name: staging}`).
+
+### El workflow
+
+Una entrada de workflow té unes quantes claus pròpies, al costat dels seus nodes:
+
+| Clau | Què és |
+|---|---|
+| `name` | El nom del workflow, el que indica el `workflow:` d'un formulari |
+| `description` | Per a què serveix, es mostra al dissenyador |
+| `extra_vars` | Variables que rep cada node; els valors del formulari hi tenen prioritat |
+| `related.workflow_nodes` | Els nodes |
+
+### Un node
+
+Cada node té un identificador, el que executa i els seus enllaços:
+
+| Clau | Què és |
+|---|---|
+| `identifier` | L'id del node: lletres, dígits, punts, guions, dos punts i guions baixos, únic dins del workflow |
+| `unified_job_template.type` | Què executa el node: vegeu [tipus de node](#node-types) |
+| `unified_job_template.name` | El playbook, el workflow, l'aprovació o el repositori que executa |
+| `related.success_nodes` | Els nodes que s'executen quan aquest té èxit |
+| `related.failure_nodes` | Els nodes que s'executen quan aquest falla |
+| `related.always_nodes` | Els nodes que s'executen quan aquest ha acabat, sigui com sigui |
+| `all_parents_must_converge` | `true`: el node espera que s'activin tots els enllaços que hi arriben, no només un |
+
+Els enllaços han d'anar endavant: un workflow els enllaços del qual fan un bucle no s'executa.
+
+---
+
+## Tipus de node
+
+Un node executa una de quatre coses, anomenades com les anomena AWX:
+
+| Tipus | Què executa el node |
+|---|---|
+| `job_template` | Un dels playbooks del dissenyador, com a tasca pròpia a l'RTE; o, amb `runner:`, la plantilla o el job d'aquest runner |
+| `workflow_job_template` | Un altre workflow, com a tasca de workflow filla; els workflows es poden niar fins a cinc nivells |
+| `workflow_approval_template` | Una aprovació: la tasca del workflow espera fins que algú l'aprova o la rebutja |
+| `project` | Un pull del repositori que indica (l'actualització de projecte d'AWX) |
+
+El `unified_job_template.timeout` d'un node d'aprovació s'expressa en segons. Quan passa sense resposta, el node falla; amb `0` o sense
+temps límit, espera una resposta el temps que calgui. Una aprovació rebutjada fa fallar el node, i el workflow continua pels seus
+enllaços.
+
+---
+
+## Opcions d'execució
+
+Un node `job_template` admet les opcions d'un node d'AWX, al mateix node:
+
+| Clau | Què fa |
+|---|---|
+| `inventory` | L'inventari contra el qual s'executa el playbook, pel seu nom, com l'`inventory:` d'un formulari |
+| `related.credentials` | Les credencials: cadascuna arriba al playbook amb el seu propi nom, i la primera de tipus *SSH* també és l'accés amb què es connecta ansible. Una de tipus vault només obre els vaults |
+| `limit` | Només s'executa en aquests hosts (`--limit`) |
+| `job_tags` | Només executa les tasques amb aquestes etiquetes (`--tags`) |
+| `skip_tags` | Omet les tasques amb aquestes etiquetes (`--skip-tags`) |
+| `verbosity` | De `0` a `5`: el nombre de `-v` |
+| `diff_mode` | `true`: mostra els canvis (`--diff`) |
+| `job_type` | `check`: una simulació (`--check`); `run` o res: una execució real |
+| `extra_data` | Variables que rep aquest node, per sota de les `extra_vars` del workflow i dels valors del formulari |
+
+La tasca del node rep els valors del formulari com a extra vars. Els valors del formulari tenen prioritat sobre les `extra_vars` del workflow, que tenen prioritat
+sobre l'`extra_data` del node, com passa amb les respostes d'un survey a AWX.
+
+---
+
+## Claus pròpies d'AnsibleForms
+
+Tres claus d'un node són pròpies d'AnsibleForms, i AWX les ignora, de manera que un workflow pot fer el que fa un formulari multipas:
+
+| Clau | Què fa |
+|---|---|
+| `runner` | En un node `job_template`, executa la plantilla o el job d'aquest runner en lloc d'un playbook del dissenyador: AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins. Un runner RTE hi executa el playbook del node. Un mateix workflow els pot combinar. |
+| `if_extra_var` | El node només s'executa quan aquesta extra var és `true`, com l'`ifExtraVar` d'un pas multistep. Si no es compleix, el node s'omet, i el que el segueix s'executa com després d'un èxit. No en un node d'aprovació, que sempre s'executa. |
+| `extra_vars_key` | El node només rep aquesta clau de les extra vars, amb l'usuari copiat a dins, com la `key` d'un pas multistep |
+
+En un runner de plantilles, `unified_job_template.name` és la plantilla o el job que cal executar, i el `limit`, els `job_tags`, el mode check
+i el mode diff del node es passen tal com els passaria un formulari del tipus d'aquest runner. Una `verbosity` superior a `0` activa el
+`verbose` del formulari, i `skip_tags` no es passa. Només un runner d'AWX (AWX, AAP o Ascender) rep l'inventari del node, i les
+credencials com a credencials d'AWX; Semaphore, Rundeck i Jenkins reben les credencials com els `credentials` d'un formulari.
diff --git a/i18n/ca/_build_forms/workflows/index.md b/i18n/ca/_build_forms/workflows/index.md
new file mode 100644
index 0000000..acbaf0f
--- /dev/null
+++ b/i18n/ca/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflows
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflows
+{: .no_toc }
+
+Encadena playbooks, aprovacions i altres workflows, com fa AWX
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per als autors de formularis: què és un workflow, com s'executen els seus nodes i on continuar llegint.
+
+Un workflow és un graf de nodes. Cada node executa alguna cosa: un dels playbooks del dissenyador, un altre workflow, una aprovació
+o un pull d'un repositori. Els enllaços entre els nodes indiquen què s'executa després: si té èxit, si falla o sempre. Un formulari de
+[tipus `workflow`](../forms/workflow.html) el llança, i la pàgina de tasques el dibuixa en directe mentre s'executa.
+
+Els workflows segueixen la sintaxi i les regles d'AWX, de manera que un workflow exportat d'AWX es llegeix igual a AnsibleForms. S'executen a
+l'RTE, sense AWX: un node de playbook és una tasca pròpia, amb l'inventari, les credencials, el límit i les etiquetes del node.
+
+---
+
+## Com s'executa un workflow
+
+Els nodes s'executen segons les regles d'AWX, i les branques que no depenen l'una de l'altra s'executen en paral·lel.
+
+- **Un node sense pare comença de seguida**, quan comença el workflow.
+- **Un enllaç s'activa quan el seu node ha acabat**: un enllaç *si té èxit* després d'un èxit, un enllaç *si falla* després d'una fallada,
+  un enllaç *sempre* després de qualsevol dels dos. Un node cancel·lat no activa cap dels seus enllaços.
+- **Un node comença tan bon punt s'activa un dels enllaços que hi arriben.** Amb **Tots els pares han de convergir** activat, espera fins que s'han activat tots
+  els enllaços que hi arriben.
+- **Un node que ja no pot començar es marca com a *no s'executa***, igual que els nodes que només ell podia iniciar.
+- **El workflow falla quan un node ha fallat i res no ho gestiona**: aquest node no té cap enllaç *si falla* ni cap enllaç *sempre*.
+  Una fallada que gestiona un enllaç no fa fallar el workflow.
+
+Un node amb una condició (`if_extra_var`) que no es compleix s'omet. El que el segueix s'executa com després d'un èxit. Un node
+d'aprovació no admet condició: sempre espera una resposta.
+
+---
+
+## Passar dades entre nodes
+
+El que el playbook d'un node recull amb `set_stats` arriba als nodes posteriors com a extra vars, de la mateixa manera que AWX passa els
+artefactes d'una tasca. Un node rep les dades de tots els pares l'enllaç dels quals cap a ell s'ha activat, fusionades en l'ordre en què estan
+escrits els pares, i passa endavant el que ha rebut més les dades de la seva pròpia tasca; si tots dos defineixen una clau, guanya la seva.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Un node posterior llegeix llavors {% raw %}`{{ version }}` i `{{ build_id }}`{% endraw %} com qualsevol altra extra var.
+
+Les extra vars d'un node provenen de quatre llocs. Un d'ells, `extra_data`, són les variables pròpies del node: el nom que els dona AWX,
+definides al node al [fitxer de workflow](file.html#run-settings). Quan dos llocs defineixen la mateixa clau, l'ordre de precedència és
+el d'AWX, de menor a major:
+
+| Origen | Guanya a |
+|---|---|
+| les variables pròpies del node (`extra_data`) | res |
+| les dades passades amb `set_stats` | l'`extra_data` del node |
+| les `extra_vars` del workflow | les dades passades |
+| els valors del formulari | tot |
+
+- Només es passen les dades de tot el playbook: `set_stats` amb `per_host: false`, el seu valor per defecte.
+- Un node d'aprovació, un node omès i un node de projecte passen endavant el que els ha arribat.
+- La sortida d'un node acaba amb les claus que ha passat endavant, només pel nom, ja que els seus valors poden ser secrets.
+- La tasca del node conserva les seves dades com a artefactes (**Mostra els artefactes** a la seva pàgina), i la tasca del workflow conserva les dades de tots
+  els seus nodes, de manera que un workflow niat també les passa als nodes posteriors.
+- Un node que s'executa en un runner d'AWX passa endavant els artefactes de la seva tasca d'AWX de la mateixa manera.
+---
+
+## En aquesta secció
+
+Les pàgines següents descriuen els workflows en detall:
+
+| Pàgina | Què tracta |
+|---|---|
+| [El fitxer de workflow](file.html) | La sintaxi del fitxer, els tipus de node i les opcions d'execució de cada node |
+| [Edició al dissenyador](designer.html) | La secció Fluxos de treball del dissenyador: el graf, els diàlegs de node i d'enllaç i la simulació |
+| [Executar un workflow](running.html) | El formulari que el llança, la pàgina de la tasca, les sortides dels nodes, les aprovacions i l'avortament |
diff --git a/i18n/ca/_build_forms/workflows/running.md b/i18n/ca/_build_forms/workflows/running.md
new file mode 100644
index 0000000..33a4a57
--- /dev/null
+++ b/i18n/ca/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Executar un workflow
+parent: Workflows
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Executar un workflow
+{: .no_toc }
+
+Llança un workflow des d'un formulari i segueix-lo a la pàgina de tasques
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## El formulari
+
+Un formulari de [tipus `workflow`](../forms/workflow.html) llança un workflow, indicat amb `workflow:` com es fa amb un playbook: pel
+seu **fitxer** a la carpeta de workflows, amb les seves subcarpetes (`team/deploy-app.yml`), o pel **nom** del workflow dins
+del fitxer (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+Els camps del formulari arriben a cada node com a extra vars, i també les seves [`credentials`](../forms/workflow.html#workflow_credentials), amb els noms
+que els dona el formulari, igual que els d'un formulari multipas arriben als seus passos:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+Les credencials pròpies d'un node, definides al fitxer de workflow, arriben al seu playbook amb el seu propi nom i guanyen si tots dos fan servir el mateix nom. A la pestanya Visual d'un formulari al dissenyador, **Workflow** és una llista dels
+fitxers de workflow del dissenyador.
+
+Un nom de fitxer sol també es troba en una subcarpeta, quan només un fitxer el té. Dos workflows amb el mateix nom aturen un formulari que
+l'indica pel nom, i el dissenyador avisa quan deses el segon: reanomena'n un, o indica'n el fitxer. Un workflow que no es pot
+trobar fa que la tasca acabi fallida, amb el motiu a la sortida.
+
+---
+
+## La tasca
+
+Una tasca de workflow s'executa al servidor d'AnsibleForms, i cada node de playbook s'executa com una tasca pròpia, filla de la tasca del
+workflow, igual que els passos d'un formulari multipas: un playbook del dissenyador a l'RTE o, per a un node amb un `runner:`, la plantilla
+o el job d'aquest runner a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins (vegeu [On s'executa un node](designer.html#where-a-node-runs)).
+
+La pàgina de la tasca dibuixa el workflow en directe: cada node amb el color del seu estat, els enllaços que s'han activat i els nodes que no
+s'executaran. Les dades de la part superior indiquen el workflow en lloc d'un playbook.
+
+- **Fes clic en un node** que hagi acabat per obrir-ne la sortida en un diàleg.
+- **La sortida** conté la sortida de cada node sota una capçalera `WORKFLOW NODE [identifier] (status)`, en l'ordre en què han
+  acabat els nodes.
+- **Mostra les extravars** i **Mostra els artefactes**, a la capçalera de cada node a la sortida i al diàleg que s'obre des del graf,
+  mostren les extravars i els artefactes propis d'aquest node (`{}` si no en té), en JSON o YAML, amb un botó Copia.
+
+Les extravars d'un node contenen el que li han passat els nodes anteriors, i els seus artefactes, el que el seu playbook ha recollit amb
+`set_stats`. Els dos botons segueixen les [opcions de rol](../config/roles.html#role-options) `showExtravars` i
+`showArtifacts`. Les mateixes dades s'obtenen de `GET /api/v2/job/{id}/node/{nodeId}`, per a qualsevol que pugui veure la tasca.
+
+La tasca falla quan un node ha fallat i res no ho ha gestionat, segons la regla d'AWX; si no, té èxit.
+
+---
+
+## Aprovacions
+
+Un node d'aprovació reté la tasca del workflow fins que algú hi respon.
+
+Quan el workflow arriba a un node d'aprovació, l'estat de la tasca passa a **Esperant aprovació**: es mostra a la campaneta i a la
+pàgina de la tasca, com un [punt d'aprovació](../forms/approval.html) d'un formulari. El nom del node és el títol de l'aprovació, i la seva descripció,
+el missatge; la resta surt de l'`approval` del formulari:
+
+- els seus `roles` decideixen qui la pot aprovar o rebutjar, i `allowSelf`, si qui l'ha llançada també la pot aprovar;
+- la sol·licitud s'envia a les seves `notifications` i `channels`.
+
+Un formulari de workflow sense `approval` també reté la tasca en un node d'aprovació, però llavors només un administrador la pot aprovar.
+
+- **Aprovada**: el node té èxit i el workflow continua pels seus enllaços *si té èxit*.
+- **Rebutjada**: el node falla i el workflow continua pels seus enllaços *si falla*.
+- **Temps esgotat**: passat el temps límit del node sense resposta, el node també falla.
+
+---
+
+## Avortar
+
+**Avorta** en una tasca de workflow en execució l'atura: les tasques dels nodes en curs s'avorten, no comença res més, i l'aprovació que
+estigui esperant es cancel·la. Una tasca de workflow que espera una aprovació també es pot avortar.
diff --git a/i18n/ca/_configure/announcements.md b/i18n/ca/_configure/announcements.md
new file mode 100644
index 0000000..32e3057
--- /dev/null
+++ b/i18n/ca/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Anuncis
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Anuncis
+{: .no_toc }
+
+Missatges sota la capçalera per a tothom, com ara una finestra de manteniment, cadascun des del seu inici fins al seu final
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: avisa tots els usuaris d'una finestra de manteniment o d'una incidència, a **Configuració > Aparença > Anuncis**.
+
+La pàgina necessita l'opció de rol `showSettings` o `showAppearanceSettings`. Des de la 7.3.0 és una sola llista, i cada anunci
+té la seva pròpia pàgina i el seu interruptor Activat.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [General](announcements/general.html) | L'interruptor Activat de cada anunci, que va substituir l'interruptor de tots alhora |
+| [Llista](announcements/list.html) | Els anuncis que no han acabat, les seves columnes i la pàgina d'un anunci |
+| [Afegir-ne un](announcements/adding-one.html) | L'assistent de dos passos: el missatge i, després, quan es mostra |
+
+
+---
+
+## On es mostren
+
+Els anuncis es mostren com una línia sota la capçalera de cada pàgina, per a tots els usuaris que han iniciat sessió, cadascun amb el color del seu tipus.
+
+Se'n poden mostrar diversos d'activats alhora, el més recent primer. La pàgina d'inici de sessió i un formulari incrustat en un altre lloc web no en mostren cap.
+
+Cadascun té un botó per tancar-lo. Un anunci tancat continua tancat en aquella pestanya del navegador fins que es tanca la pestanya, o
+fins que canvia el seu missatge o la seva data de final. Un anunci desat arriba alhora a tots els navegadors oberts; un que
+arriba a la seva data d'inici o de final s'hi mostra o s'hi amaga en menys d'un minut.
diff --git a/i18n/ca/_configure/announcements/adding-one.md b/i18n/ca/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..e5231e4
--- /dev/null
+++ b/i18n/ca/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Afegir-ne un
+parent: Anuncis
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Afegir-ne un
+{: .no_toc }
+
+L'assistent de dos passos: el missatge i, després, quan es mostra
+{: .fs-6 .fw-300 }
+
+**Afegeix anunci** obre un assistent de dos passos. **Missatge** pregunta què diu:
+
+| Camp | Significat |
+|---|---|
+| **Missatge** | El text, com a màxim 500 caràcters. Obligatori. |
+| **Tipus** | El seu color i la seva icona: blau per a Informació (el predeterminat), ambre per a Advertència, vermell per a Perill |
+
+**Quan** pregunta quan es mostra:
+
+| Camp | Significat |
+|---|---|
+| **Data d'inici** | Es mostra a partir d'aquest moment. Deixa-la buida per mostrar-lo de seguida. |
+| **Data de final** | En aquest moment s'amaga i se suprimeix. Deixa-la buida per conservar-lo fins que el suprimeixis. |
+
+La data de final ha de ser posterior a la data d'inici i ha de ser en el futur.
diff --git a/i18n/ca/_configure/announcements/general.md b/i18n/ca/_configure/announcements/general.md
new file mode 100644
index 0000000..3b4693d
--- /dev/null
+++ b/i18n/ca/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: General
+parent: Anuncis
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# General
+{: .no_toc }
+
+L'interruptor Activat de cada anunci, que va substituir l'interruptor de tots alhora
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Activar o desactivar un anunci
+
+Des de la 7.3.0, cada anunci s'activa o es desactiva per separat, amb el seu interruptor **Activat**.
+
+Un anunci nou està activat. **Desactiva** al menú de la seva fila, o l'interruptor **Activat** de la seva pàgina, l'amaga de sota la capçalera i el conserva
+a la llista, i **Activa** el torna a mostrar des de la seva data d'inici fins a la seva data de final. L'interruptor es desa a l'instant.
+
+---
+
+## L'interruptor Mostra els anuncis de la 7.2
+
+Fins a la 7.2, una pestanya **General** tenia un interruptor **Mostra els anuncis** que els activava o desactivava tots alhora.
+
+Des de la 7.3.0 aquest interruptor ja no hi és. Si estava desactivat, l'actualització desactiva tots els anuncis, perquè cap no comenci a mostrar-se: torna a activar els que vulguis.
diff --git a/i18n/ca/_configure/announcements/list.md b/i18n/ca/_configure/announcements/list.md
new file mode 100644
index 0000000..61dd02d
--- /dev/null
+++ b/i18n/ca/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Llista
+parent: Anuncis
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Llista
+{: .no_toc }
+
+Els anuncis que no han acabat, les seves columnes i la pàgina d'un anunci
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La llista
+
+**Configuració > Aparença > Anuncis** llista tots els anuncis que no han acabat, amb aquestes columnes:
+
+| Columna | Significat |
+|---|---|
+| **Activat** | Si es mostra sota la capçalera des del seu inici fins al seu final (des de la 7.3.0) |
+| **Missatge** | El text sota la capçalera |
+| **Tipus** | Informació, Advertència o Perill |
+| **Data d'inici** | Quan comença a mostrar-se; `–` quan es mostra de seguida |
+| **Data de final** | Quan acaba; `–` quan es mostra fins que se suprimeix |
+| **Creat per** | Qui l'ha afegit |
+
+Un clic en una fila, o **Edita** al menú de la seva fila, obre la pàgina de l'anunci. El menú també té **Activa** o **Desactiva**, i **Suprimeix**.
+
+Quan passa la seva data de final, l'anunci se suprimeix: la llista només conserva els que han de venir i els que s'estan mostrant.
+
+---
+
+## La pàgina d'un anunci
+
+Des de la 7.3.0, cada anunci s'obre a la seva pròpia pàgina, a `/settings/announcements/<id>`, amb una pestanya, **Detalls**.
+
+Conté el missatge, el tipus, les dates d'inici i de final i l'interruptor **Activat**, que es desa a l'instant; els altres camps es desen
+amb **Desa**, i **Suprimeix** elimina l'anunci. El títol de la pàgina l'anomena pels primers caràcters del seu missatge.
diff --git a/i18n/ca/_configure/appearance.md b/i18n/ca/_configure/appearance.md
new file mode 100644
index 0000000..43034d3
--- /dev/null
+++ b/i18n/ca/_configure/appearance.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Aparença
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Aparença
+{: .no_toc }
+
+Els valors predeterminats, el nom, el logotip, la icona del navegador, els enllaços de la capçalera i les etiquetes al costat del logotip
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: dona a la instància el teu propi aspecte, a **Configuració > Aparença**, amb l'opció de rol `showSettings`.
+L'opció de rol `showAppearanceSettings` tota sola també obre aquestes pàgines, anuncis inclosos, sense la resta de la configuració.
+
+Les pàgines d'aquest grup són **Valors predeterminats**, **Nom**, **Logotip**, **Icona**, **Enllaços**, **Etiquetes** i **Anuncis**;
+els anuncis tenen una pàgina pròpia, [Anuncis](announcements.html). Un valor predeterminat, un nom, un enllaç o una etiqueta que es desa
+es mostra a l'instant a tots els navegadors oberts.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Valors predeterminats](appearance/defaults.html) | El tema, l'idioma, la zona horària i el format de data per als usuaris que no n'han triat cap |
+| [Nom](appearance/name.html) | El nom de l'aplicació a la pestanya del navegador i a la pàgina d'inici de sessió |
+| [Logotip](appearance/logo.html) | El teu propi logotip a la capçalera |
+| [Icona](appearance/icon.html) | La teva pròpia icona a la pestanya del navegador i a les adreces d'interès |
+| [Enllaços](appearance/links.html) | Els enllaços de la capçalera, els integrats i els teus |
+| [Etiquetes](appearance/labels.html) | Etiquetes al costat del logotip que indiquen quina instància és aquesta; una sola etiqueta Environment fins a la 7.2 |
+
diff --git a/i18n/ca/_configure/appearance/defaults.md b/i18n/ca/_configure/appearance/defaults.md
new file mode 100644
index 0000000..31db607
--- /dev/null
+++ b/i18n/ca/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Valors predeterminats
+parent: Aparença
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Valors predeterminats
+{: .no_toc }
+
+El tema, l'idioma, la zona horària i el format de data per als usuaris que no n'han triat cap
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Els valors predeterminats
+
+**Valors predeterminats** defineix com es veu l'aplicació per a un usuari que no ha fet cap tria pròpia a les seves
+[preferències](../profile/preferences.html); la tria del mateix usuari sempre té prioritat:
+
+| Camp | Opcions | Sense tria |
+|---|---|---|
+| **Tema predeterminat** | Segueix el navegador, Clar, Fosc o Color, amb un de 12 colors per a Color | Segueix el navegador (Clar fins a la 7.2) |
+| **Idioma predeterminat** | Els idiomes de l'aplicació, desat a [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Anglès |
+| **Vista de formularis predeterminada** | Mosaics o Llista, per a la pàgina de formularis | Mosaics |
+| **Zona horària predeterminada** | UTC, la del navegador de cada usuari o qualsevol zona pel seu nom | UTC |
+| **Format de data predeterminat** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY`, mostrat amb la data d'avui | `YYYY-MM-DD` |
+
+L'idioma és una variable d'entorn i s'aplica sense reiniciar. Amb
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) a `0`, la pàgina el mostra només de lectura.
+
+Des de la 7.3.0 la pàgina és a les dues pestanyes de les preferències del perfil, **Aparença** (tema, idioma i vista de formularis) i **Data i
+hora** (zona horària i format de data, amb una previsualització de l'hora actual), i el seu quadre de cerca llista les coincidències sota el nom de cada pestanya.
+
+---
+
+## Seguir el navegador
+
+Des de la 7.3.0 **Segueix el navegador** mostra a cada usuari el tema clar o fosc que demana el seu navegador, i canvia amb ell.
+
+És el valor predeterminat quan no s'ha triat cap tema predeterminat, així que una instal·lació nova segueix el navegador. En passar el punter per un dels colors de
+**Color**, l'aplicació es previsualitza en aquell color; el tema que tenies torna quan el punter en surt, i no es desa res fins que no prems **Desa**.
diff --git a/i18n/ca/_configure/appearance/icon.md b/i18n/ca/_configure/appearance/icon.md
new file mode 100644
index 0000000..f7f7644
--- /dev/null
+++ b/i18n/ca/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Icona
+parent: Aparença
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Icona
+{: .no_toc }
+
+La teva pròpia icona a la pestanya del navegador i a les adreces d'interès
+{: .fs-6 .fw-300 }
+
+**Icona** substitueix la icona d'AnsibleForms a la pestanya del navegador i a les adreces d'interès:
+
+| Regla | Valor |
+|---|---|
+| Tipus | PNG, ICO, SVG, WEBP, GIF i JPEG |
+| Mida màxima | 256 KB |
+| Millor resultat | Una imatge quadrada d'almenys 64 × 64 px, o un SVG |
+
+Tria un fitxer a **Icona nova** i fes clic a **Puja**; **Elimina la icona personalitzada** recupera la icona predeterminada.
diff --git a/i18n/ca/_configure/appearance/labels.md b/i18n/ca/_configure/appearance/labels.md
new file mode 100644
index 0000000..1120462
--- /dev/null
+++ b/i18n/ca/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Etiquetes
+parent: Aparença
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Etiquetes
+{: .no_toc }
+
+Etiquetes al costat del logotip que indiquen quina instància és aquesta
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La llista
+
+Des de la 7.3.0 **Configuració > Aparença > Etiquetes** conté diverses etiquetes al costat del logotip de la capçalera, com ara PRODUCTION i EU:
+
+| Columna | Significat |
+|---|---|
+| **Activat** | Si l'etiqueta es mostra al costat del logotip i a la pàgina d'inici de sessió |
+| **Etiqueta** | El seu text, mostrat com la píndola de color que mostra la capçalera |
+
+Les files segueixen l'ordre de la capçalera. Un clic en una fila, o **Edita** al menú de la fila, obre la pàgina de l'etiqueta; el menú de la fila també té
+**Activa** o **Desactiva**, segons correspongui, **Puja** i **Baixa** per canviar l'ordre, i **Suprimeix**.
+
+La capçalera i la pàgina d'inici de sessió mostren les etiquetes activades en el seu ordre. Passades tres, un **+N** gris agrupa les altres al seu tooltip,
+i un telèfon mostra la primera etiqueta i el **+N**. Una etiqueta desada es mostra a l'instant a tots els navegadors oberts.
+
+---
+
+## Afegir una etiqueta
+
+**Afegeix etiqueta** obre un diàleg amb els dos camps de l'etiqueta, tots dos obligatoris:
+
+| Camp | Significat |
+|---|---|
+| **Etiqueta** | El text de l'etiqueta, com ara PRODUCTION |
+| **Color** | Blau, verd, ambre, taronja, vermell o gris, com a mostres rodones; vermell al principi |
+
+Una previsualització mostra la capçalera amb totes les etiquetes activades i la nova a mesura que s'escriu. Una etiqueta nova està activada i va després de les
+altres. La seva pàgina té una pestanya, **Detalls**, amb els mateixos camps, l'interruptor **Activat**, que es desa a l'instant, i la previsualització.
+
+---
+
+## L'etiqueta d'entorn de la 7.2
+
+Fins a la 7.2, **Configuració > Aparença > Entorn** definia una sola etiqueta al costat del logotip.
+
+Amb una sola etiqueta, PRODUCTION EU i PRODUCTION US es llegeixen totes dues com a PRODUCTION quan hi ha diverses instàncies obertes alhora. Des de la 7.3.0
+l'actualització converteix aquesta etiqueta en la primera de la llista, amb el seu text, el seu color i si es mostrava, i l'antiga adreça d'**Entorn**
+obre la llista.
+
+---
+
+## Etiquetes a la llavor de configuració
+
+Des de la 7.3.0 la [llavor de configuració](../seed/) declara etiquetes a la seva secció `labels`, cadascuna amb el seu text i, opcionalment, el seu color:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` és un de `blue`, `green`, `amber`, `orange`, `red` o `grey`, i `position` les ordena, la més baixa primer. Una etiqueta declarada
+a la llavor és només de lectura a la seva pàgina, com qualsevol [objecte gestionat](../seed/managed-objects.html).
diff --git a/i18n/ca/_configure/appearance/links.md b/i18n/ca/_configure/appearance/links.md
new file mode 100644
index 0000000..c7a657d
--- /dev/null
+++ b/i18n/ca/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Enllaços
+parent: Aparença
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Enllaços
+{: .no_toc }
+
+Els enllaços de la capçalera, els integrats i els teus
+{: .fs-6 .fw-300 }
+
+**Enllaços** defineix els enllaços de la capçalera, per a tots els usuaris que han iniciat sessió, en dues pestanyes.
+
+**Integrats** té l'interruptor **Dissenyador**, desat a [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) i aplicat
+sense reiniciar. Si es desactiva, el dissenyador desapareix per a tothom: el seu enllaç, la seva pàgina i la seva API.
+
+**Personalitzats** conté els teus propis enllaços, com ara una wiki, un runbook o un portal de suport. **Afegeix enllaç** afegeix una fila amb aquests camps:
+
+| Camp | Significat |
+|---|---|
+| **Icona** | La icona davant de l'etiqueta, triada d'una llista |
+| **Etiqueta** | El text de l'enllaç |
+| **Adreça** | Un lloc web (`https://…`) o una pàgina de l'aplicació (`/forms/all`) |
+| **Pestanya nova** | Obre l'enllaç en una pestanya nova del navegador |
+
+Els botons d'una fila la mouen: **→** posa l'enllaç dins de l'enllaç de dalt, que llavors s'obre com a menú a la capçalera,
+**←** el torna a treure a la capçalera, i les fletxes amunt i avall el mouen (un menú, amb els enllaços que conté).
+Un menú no necessita cap adreça pròpia.
+
+La capçalera conté com a màxim 5 dels teus enllaços després dels integrats, i com a màxim 10 dins de cada menú.
diff --git a/i18n/ca/_configure/appearance/logo.md b/i18n/ca/_configure/appearance/logo.md
new file mode 100644
index 0000000..8287959
--- /dev/null
+++ b/i18n/ca/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logotip
+parent: Aparença
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logotip
+{: .no_toc }
+
+El teu propi logotip a la capçalera
+{: .fs-6 .fw-300 }
+
+**Logotip** substitueix el logotip d'AnsibleForms de la capçalera per la teva pròpia imatge, que es mostra en tots els temes:
+
+| Regla | Valor |
+|---|---|
+| Tipus | PNG, JPEG, WEBP, GIF i SVG |
+| Mida màxima | 900 KB |
+| Mida a la capçalera | Com a màxim 200 × 33 px, mantenint-ne les proporcions |
+
+Tria un fitxer a **Logotip nou** per previsualitzar-lo i després fes clic a **Puja**. **Logotip actual** mostra el logotip en ús i la mida
+amb què el mostra la capçalera. **Elimina el logotip personalitzat** recupera el logotip predeterminat, que segueix el tema.
diff --git a/i18n/ca/_configure/appearance/name.md b/i18n/ca/_configure/appearance/name.md
new file mode 100644
index 0000000..abf925e
--- /dev/null
+++ b/i18n/ca/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Nom
+parent: Aparença
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Nom
+{: .no_toc }
+
+El nom de l'aplicació a la pestanya del navegador i a la pàgina d'inici de sessió
+{: .fs-6 .fw-300 }
+
+**Nom** conté el **Nom de l'aplicació**, que es mostra a la pestanya del navegador i a la pàgina d'inici de sessió. Si és buit, la pestanya del navegador mostra
+`AnsibleForms` i la pàgina d'inici de sessió no mostra cap nom.
diff --git a/i18n/ca/_configure/authentication/entra-id.md b/i18n/ca/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..04678f9
--- /dev/null
+++ b/i18n/ca/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Autenticació
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Inici de sessió únic amb Microsoft Entra ID (Azure AD), amb rols segons els grups d'Entra ID de l'usuari
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Com funciona
+
+Amb un proveïdor Entra ID activat, la pàgina d'inici de sessió mostra un botó d'Entra ID sota **Inicia la sessió**. Un inici de sessió segueix aquests passos:
+
+1. El botó envia el navegador a `/api/v2/auth/entraid`, que el redirigeix a Microsoft.
+2. L'usuari inicia sessió a Microsoft, que el redirigeix de tornada a la **URL de redirecció** amb un codi d'autorització. El servidor
+   intercanvia aquest codi amb Microsoft per l'ID token i un access token per a Microsoft Graph.
+3. El servidor llegeix els grups de l'usuari de Microsoft Graph (`/v1.0/me/transitiveMemberOf`), de manera que els grups niats també compten.
+4. Els grups es filtren amb el **Filtre de grups** sobre el seu nom de visualització, i cada grup que es conserva es desa dues vegades,
+   com a `azuread/<object id>` i com a `azuread/<display name>`.
+
+El nom d'usuari és el claim `upn` del token, p. ex. `jdoe@example.com`, o el claim `preferred_username` quan el token
+no té `upn`; en un compte de feina tots dos contenen el mateix valor.
+
+---
+
+## Registrar l'aplicació
+
+AnsibleForms necessita un registre d'aplicació a l'Entra admin center, a **App registrations > New registration**:
+
+1. Dona-li un nom, tria **Accounts in this organizational directory only** com a tipus de compte admesos i afegeix un
+   URI de redirecció de tipus **Web**: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. A **Certificates & secrets**, crea un secret de client i copia'n el valor; només es mostra una vegada.
+3. A **API permissions**, afegeix els permisos **delegated** de Microsoft Graph `User.Read` i `GroupMember.Read.All`,
+   i concedeix-los el consentiment d'administrador.
+4. A la pàgina **Overview**, anota l'**Application (client) ID** i el **Directory (tenant) ID**.
+
+L'URI de redirecció és l'adreça amb què els usuaris arriben a AnsibleForms, seguida de `/api/v2/auth/entraid/callback`.
+Amb [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms`, passa a ser
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Ha de coincidir exactament amb l'**URI de redirecció** de la
+credencial del proveïdor.
+
+Fins a la 7.2.0 el camí era `/api/v2/auth/azureadoauth2/callback`. Continua funcionant des de la 7.3.0, així que un registre existent
+no necessita cap canvi; una credencial amb l'**URI de redirecció** buit utilitza el camí nou, així que en aquest cas afegeix-lo al registre.
+
+AnsibleForms llegeix els grups de Graph i no utilitza cap claim de grups al token, així que no cal configurar cap claim de grups
+al registre.
+
+---
+
+## Afegir el proveïdor
+
+Afegeix el proveïdor a **Accés > SSO**: un assistent en demana els camps en quatre passos, amb **Microsoft Entra ID** al pas **Tipus**:
+
+| Pas | Camp | Significat |
+|---|---|---|
+| Detalls | Nom, Descripció | Un nom únic per al proveïdor i una descripció opcional |
+| Tipus | Proveïdor | **Microsoft Entra ID**; es fixa quan es crea i no canvia |
+| Credencials | Credencial | Una credencial **Microsoft Entra ID** de [Connexions > Credencials](../credentials.html), vegeu més avall |
+| Grups | Filtre de grups | Expressió regular; només es conserven els grups el nom de visualització dels quals coincideix. Buit conserva tots els grups |
+
+La credencial conté el registre de l'aplicació, així que només un admin la pot afegir o canviar:
+
+| Camp | Significat |
+|---|---|
+| ID del tenant | Obligatori. El Directory (tenant) ID, un GUID, o un dels dominis del tenant. Només els usuaris d'aquest tenant poden iniciar sessió |
+| ID del client | L'Application (client) ID |
+| Secret del client | El valor del secret de client, desat xifrat o llegit d'un [magatzem de secrets](../secret-stores/) |
+| URI de redirecció | Tal com està registrat, p. ex. `https://af.example.com/api/v2/auth/entraid/callback`. Buit: la URL de l'aplicació i el camí de retorn |
+
+Una credencial amb l'ID del tenant buit es rebutja quan es desa. Els endpoints multitenant `common`, `organizations`
+i `consumers` es rebutgen quan es desa el proveïdor que nomena la credencial, perquè permetrien iniciar sessió a usuaris de qualsevol
+tenant de Microsoft. En iniciar sessió, el servidor també comprova que el token ve del tenant configurat. Un proveïdor
+desat abans sense ID del tenant no deixa entrar ningú: fins que no s'emplena l'ID del tenant, el servidor registra
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Fins a la 7.2.0 el tenant, l'ID del client, el secret i la URL de redirecció eren camps del proveïdor. L'actualització a la 7.3.0 els trasllada a una
+credencial anomenada `<provider>-sso`, vegeu [Adreces a les credencials](../credentials/types.html#addresses-in-credentials).
+Tria una credencial per a cada proveïdor nou: el servidor encara accepta un proveïdor amb el seu propi ID de client i secret d'abans
+de la 7.3.0, que hi inicia sessió fins que es tria una credencial.
+
+Només hi ha un proveïdor Entra ID activat alhora, aquell amb què inicia sessió el botó d'Entra ID. **Activa** al menú de fila d'un altre,
+o el seu interruptor **Activat**, desactiva els altres del seu tipus; la columna **Activat** de la llista mostra quin s'està fent servir. Un proveïdor
+també es pot saltar la pàgina d'inici de sessió, vegeu [Activar i desactivar l'inici de sessió únic](./#switching-single-sign-on). En desar, s'aplica a l'instant, sense reiniciar.
+
+---
+
+## Assignació a rols
+
+A config.yaml, un grup d'Entra ID és `entraid/<object id>` o `entraid/<display name>`, i un usuari és `entraid/<upn>`.
+L'object id és únic al tenant, així que és l'opció més segura; un nom de visualització és més fàcil de llegir:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Fins a la 7.2.0 el prefix era `azuread/`. En un rol continua coincidint amb els mateixos membres des de la 7.3.0 i s'elimina a la 8.0; l'editor
+de rols escriu `entraid/`. Només els rols accepten `entraid/`: els grups de l'usuari es desen com a `azuread/<object id>` i
+`azuread/<display name>`, i així els mostren la pàgina del perfil i l'extravar `ansibleforms_user`. Un **Filtre de grups** com ara `^AF-` conserva només els grups que fan servir els teus rols; vegeu [Rols](../config/roles.html). Des de la 7.1.0
+el token d'inici de sessió ja no porta els grups, de manera que la seva mida ja no creix amb ells. El filtre continua sent important per als
+usuaris amb molts grups: a cada inici de sessió es comparen menys grups amb els rols, i el
+[registre del directori](../users-and-groups/directory.html) de l'usuari només llista els grups que compten. Abans de la 7.1.0,
+un usuari amb cent grups o més el necessita per veure algun formulari, vegeu
+[Formularis i tasques buits després d'un inici de sessió únic](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Endpoint de Microsoft Graph
+
+Per defecte, el servidor inicia la sessió dels usuaris a `https://login.microsoftonline.com` i crida Microsoft Graph a `https://graph.microsoft.com`:
+
+| Variable | Què canvia |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | L'autoritat d'inici de sessió, per a un núvol nacional com ara `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | L'endpoint de Graph del qual es llegeixen els grups, com ara `https://graph.microsoft.us` |
+
+Totes dues reben un URI base sense barra final, i són noves a la 7.3.0. `AZURE_AUTHORITY_URI` i `AZURE_GRAPH_URI` encara es llegeixen
+quan no estan definides, amb un avís al registre, i s'eliminen a la 8.0. El servidor ha de poder arribar a Graph: un inici de sessió falla quan no es poden llegir els grups.
+
+---
+
+## Limitacions
+
+Els usuaris d'Entra ID inicien sessió amb Microsoft, així que algunes coses funcionen de manera diferent que amb els comptes locals i LDAP:
+
+- No tenen contrasenya a AnsibleForms, així que no la hi poden canviar; un [token d'API](../profile/api-token.html) es crea des de la seva sessió.
+- Els noms de visualització no són únics a Entra ID: dos grups amb el mateix nom corresponen al mateix rol. Nomena el grup pel seu
+  object id al rol, `entraid/<object id>`, perquè només coincideixi amb aquest grup.
diff --git a/i18n/ca/_configure/authentication/index.md b/i18n/ca/_configure/authentication/index.md
new file mode 100644
index 0000000..7f2cb00
--- /dev/null
+++ b/i18n/ca/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Autenticació
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Autenticació
+{: .no_toc }
+
+Tria com inicien sessió els usuaris, i com el seu compte i els seus grups porten als rols
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Mètodes d'inici de sessió
+
+AnsibleForms admet quatre mètodes d'inici de sessió, i n'hi pot haver diversos d'actius alhora:
+
+| Mètode | Quan fer-lo servir | Pàgina |
+|---|---|---|
+| Comptes locals | L'admin integrat, comptes de servei, equips petits, o com a alternativa quan el directori no està disponible. | [Comptes locals](local.html) |
+| LDAP | Els usuaris i els grups són a Active Directory, OpenLDAP o un altre directori LDAP. | [LDAP](ldap.html) |
+| Entra ID | Els usuaris inicien sessió amb el seu compte de Microsoft 365 / Entra ID (inici de sessió únic). | [Entra ID](entra-id.html) |
+| OIDC | Inici de sessió únic a través d'un altre proveïdor OpenID Connect, com ara Keycloak. | [OIDC](oidc.html) |
+
+Els comptes locals i LDAP es configuren a **Accés > Usuaris**, **Grups** i **LDAP**; Entra ID i OIDC a
+**Accés > SSO**.
+
+---
+
+## Com tria el mètode un inici de sessió
+
+La pàgina d'inici de sessió té un formulari de nom d'usuari i contrasenya, més un botó per cada proveïdor d'inici de sessió únic activat:
+
+- **El nom d'usuari i la contrasenya** es comproven primer amb els usuaris locals. Només quan cap usuari local no té aquest nom, i LDAP
+  està activat, es prova el directori. Un usuari local amb una contrasenya incorrecta es rebutja sense consultar LDAP.
+- **Els botons d'Entra ID i OpenID** apareixen sota **Inicia la sessió** quan hi ha un proveïdor d'aquest tipus activat. Envien el navegador al
+  proveïdor i de tornada; cap contrasenya no arriba a AnsibleForms.
+
+Només pot haver-hi activat alhora un proveïdor Entra ID i un proveïdor OIDC: activar-ne un desactiva els altres del seu tipus.
+Un inici de sessió fallit amb usuari i contrasenya mostra sempre el mateix missatge genèric; el motiu és al registre del servidor i al registre d'auditoria.
+
+---
+
+## Activar i desactivar l'inici de sessió únic
+
+Des de la 7.3.0 cada proveïdor d'**Accés > SSO** té dos interruptors propis, que s'apliquen sense reiniciar:
+
+| Interruptor | Efecte |
+|---|---|
+| **Activat** | Mostra el botó del proveïdor a la pàgina d'inici de sessió i n'accepta l'inici de sessió. Activar-lo desactiva els altres proveïdors del seu tipus. |
+| **Salta la pàgina d'inici de sessió** | Els usuaris van directament a aquest proveïdor, sense la pàgina d'inici de sessió, mentre el proveïdor està activat. Activar-lo en un proveïdor el desactiva en els altres; apareix en gris en un proveïdor desactivat. |
+
+El formulari d'usuari i contrasenya continua accessible a `/login?local`, per a l'admin local o quan el proveïdor falla,
+i es mostra després de tancar la sessió i quan un inici de sessió únic torna amb un error.
+
+Les variables `ENABLE_SSO` i `SSO_AUTO_LOGIN` s'eliminen a la 7.3.0. La primera arrencada de la 7.3.0 les llegeix una vegada, i
+registra un avís a cada arrencada mentre continuïn definides, així que treu-les de l'entorn després de l'actualització:
+
+| Variable abans de la 7.3.0 | Què fa l'actualització |
+|---|---|
+| `ENABLE_SSO=0` | Desactiva tots els proveïdors: continuen configurats, sense botó a la pàgina d'inici de sessió |
+| `SSO_AUTO_LOGIN=1` | Activa **Salta la pàgina d'inici de sessió** al proveïdor activat, quan n'hi ha exactament un d'activat i `ENABLE_SSO` no és `0` |
+
+---
+
+## De l'usuari als rols
+
+Cada inici de sessió produeix un usuari amb un **tipus** (`local`, `ldap`, `azuread` o `oidc`), un nom d'usuari i una llista de grups.
+Cada grup rep el prefix del seu tipus, de manera que un grup d'Entra ID es desa i es mostra com a `azuread/...`:
+
+| Mètode d'inici de sessió | Nom d'usuari | Grups |
+|---|---|---|
+| Local | el nom d'usuari local | `local/<group>`, un per cada grup local de l'usuari |
+| LDAP, directori `main` | el valor de l'Username Attribute | `ldap/<cn>`, el CN de cada grup que retorna el directori |
+| LDAP, un altre directori | `<directory>/<username>` | `ldap/<directory>/<cn>`, vegeu [Diversos directoris](ldap.html#several-directories) |
+| Entra ID | el claim `upn`, o `preferred_username` quan el token no té `upn` | `azuread/<object id>` i `azuread/<display name>` de cada grup, llegits de Microsoft Graph |
+| OIDC | el claim `preferred_username` | `oidc/<name>`, del claim `groups` de l'ID token |
+
+Els [rols](../config/roles.html) de config.yaml comparen després aquests valors: un rol s'aplica quan un dels seus `groups` és un
+dels grups de l'usuari, o quan el seu `users` conté `<type>/<username>`. Tots els usuaris reben també el rol `default`. Des de la 7.3.0 un
+rol nomena un membre d'Entra ID com a `entraid/<group>` o `entraid/<upn>`, que coincideix amb el valor `azuread/` desat; `azuread/`
+en un rol continua funcionant i s'elimina a la 8.0. El perfil i les extravars de la tasca continuen mostrant `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+La pàgina del **perfil** d'un usuari llista el tipus d'inici de sessió, els grups i els rols, que és la manera més ràpida de comprovar una assignació.
+L'opció de rol `allowLogin` pot rebutjar l'inici de sessió dels usuaris que no coincideixen amb cap rol: posa-la a `false` a `default` i a
+`true` als rols que poden iniciar sessió.
diff --git a/i18n/ca/_configure/authentication/ldap.md b/i18n/ca/_configure/authentication/ldap.md
new file mode 100644
index 0000000..ab90097
--- /dev/null
+++ b/i18n/ca/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Autenticació
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Deixa que els usuaris del directori iniciïn sessió amb la seva pròpia contrasenya, i dona'ls rols a través dels seus grups del directori
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Com funciona
+
+AnsibleForms es connecta al directori amb un compte de bind, cerca l'usuari i després fa bind com a aquest usuari per comprovar
+la contrasenya:
+
+1. L'usuari inicia sessió amb nom d'usuari i contrasenya. Quan cap usuari **local** no té aquest nom, es prova LDAP.
+2. AnsibleForms fa bind amb el compte de bind de la credencial del directori, i cerca a la **Base de cerca** una entrada l'**Atribut del
+   nom d'usuari** de la qual sigui igual al nom d'usuari.
+3. Fa bind com a l'entrada trobada, amb la contrasenya que s'ha escrit.
+4. Els grups es llegeixen de l'entrada (o d'una cerca de grups), es filtren i se'ls afegeix el prefix `ldap/`.
+
+Un nom d'usuari en format UPN (`jdoe@example.com`) que no troba cap usuari es torna a provar una vegada amb la part anterior a l'`@`, de manera que els usuaris
+poden iniciar sessió amb qualsevol de les dues formes encara que l'Atribut del nom d'usuari contingui el nom curt. Una contrasenya incorrecta no es torna a provar mai.
+
+Una mateixa configuració serveix per a Active Directory, OpenLDAP i d'altres; des de la 7.3.0 hi pot haver [diversos directoris](#several-directories).
+
+---
+
+## Configuració
+
+Des de la 7.3.0 la configuració és per directori. **Accés > LDAP** llista els directoris, en l'ordre en què es cerca un nom d'usuari sense directori:
+
+![Accés > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menú de fila | Què fa |
+|---|---|
+| Edita | Obre la pàgina del directori |
+| Prova la connexió | Prova un inici de sessió amb un nom d'usuari i una contrasenya de prova, vegeu [Provar la connexió](#testing-the-connection) |
+| Activa, Desactiva | Activa o desactiva el directori; `main` es desactiva en lloc de suprimir-se |
+| Puja, Baixa | Canvia el seu lloc a l'ordre de cerca |
+| Suprimeix | Elimina el directori; es mostra però desactivat a `main` |
+
+Afegir un directori en demana els camps en quatre passos, les pestanyes de la seva pàgina. **Detalls** conté **Activat**, el **Nom** i una **Descripció**:
+
+| Pestanya | Ajust | Significat |
+|---|---|---|
+| Credencials | Credencial | Obligatori. Una credencial `ldap` de [Connexions > Credencials](../credentials.html), que conté la connexió, vegeu més avall |
+| Usuaris | Base de cerca | DN on comença la cerca d'usuaris, p. ex. `OU=Users,DC=example,DC=com`. També es cerquen els subarbres |
+| Usuaris | Atribut del nom d'usuari | Atribut que es compara amb el nom d'inici de sessió: `sAMAccountName` a AD (el predeterminat), `uid` a OpenLDAP |
+| Usuaris | Atribut de correu | Atribut que conté l'adreça de correu, normalment `mail` |
+| Usuaris | Dominis d'inici de sessió | Dominis els inicis de sessió `user@domain` dels quals van directament a aquest directori, vegeu [Diversos directoris](#several-directories) |
+| Grups | Atribut de grups | Atribut de l'entrada de l'usuari que conté els grups (`memberOf`, el predeterminat), o `groups` amb una cerca de grups |
+| Grups | Base de cerca de grups | DN on comença la cerca de grups |
+| Grups | Classe de grup | objectClass dels grups, p. ex. `group`, `groupOfNames` o `posixGroup` |
+| Grups | Atribut de membre del grup | Atribut d'un grup que llista els seus membres, p. ex. `member`, `uniqueMember` o `memberUid`; predeterminat `member` |
+| Grups | Atribut d'usuari del membre del grup | Atribut de l'usuari que contenen aquests valors de membre, p. ex. `dn` o `uid`; predeterminat `dn` |
+| Grups | Filtre de grups | Expressió regular; només es conserven els grups el nom dels quals coincideix. Buit conserva tots els grups |
+
+Els valors predeterminats dels tres últims camps de grup només s'apliquen quan es fa servir la cerca de grups, vegeu la secció següent.
+
+La credencial `ldap` conté com s'arriba al directori i amb quin compte s'hi cerca:
+
+| Camp | Significat |
+|---|---|
+| Servidors | Un per camp, com a `host`, `host:port` o `ldaps://host:port`, provats en aquest ordre: quan no es pot arribar a un, es prova el següent |
+| Port | `389` per a LDAP sense xifrar, `636` per a LDAPS |
+| Activa TLS | Connectar amb LDAPS (`ldaps://`). StartTLS al port 389 no és compatible |
+| Ignora els certificats | Omet la validació del certificat del servidor. Només es mostra amb **Activa TLS** |
+| Certificat | El certificat de client que AnsibleForms presenta als servidors, en PEM, quan es comproven els certificats |
+| Paquet de CA | El certificat o els certificats de CA que han signat el certificat del servidor, en PEM, quan es comproven els certificats |
+| DN de l'usuari de bind | El DN del compte de servei que cerca al directori |
+| Contrasenya de l'usuari de bind | La seva contrasenya, desada xifrada o llegida d'un [magatzem de secrets](../secret-stores/) |
+
+Només un admin pot afegir o canviar una credencial `ldap`, vegeu [Qui pot canviar una credencial](../credentials.html#who-may-change-a-credential).
+Fins a la 7.2.0 els servidors, el TLS i el compte de bind eren camps de la configuració LDAP. L'actualització a la 7.3.0 els trasllada a una credencial,
+vegeu [Adreces a les credencials](../credentials/types.html#addresses-in-credentials):
+
+| El directori abans de l'actualització | On van els seus servidors |
+|---|---|
+| El seu propi DN i contrasenya de bind, sense credencial | Una credencial `ldap` nova anomenada `<directory>-ldap`, com ara `main-ldap` |
+| Una credencial sense servidors | A aquesta credencial |
+| Una credencial que ja conté altres servidors | Una còpia de la credencial anomenada `<credential>-<directory>`, que el directori passa a nomenar |
+
+Un nom que ja està agafat rep `-2`, `-3`, etc. Un directori de la llavor de configuració es deixa tal com està: la llavor n'és la propietària.
+
+---
+
+## Grups
+
+Els grups vénen d'un de dos llocs, i l'**Atribut de grups** decideix quin es fa servir:
+
+- **Un atribut de l'entrada de l'usuari**, normalment `memberOf`. És la configuració habitual per a Active Directory, i per a
+  OpenLDAP amb l'overlay `memberof`.
+- **Una cerca de grups**, per a directoris sense `memberOf`. Només s'executa quan **Base de cerca de grups** i **Classe de grup**
+  estan tots dos definits: AnsibleForms cerca llavors grups d'aquesta classe l'**Atribut de membre del grup** dels quals contingui
+  l'**Atribut d'usuari del membre del grup** de l'usuari, i desa el resultat a l'atribut `groups`. Posa **Atribut de grups** a `groups`
+  per fer-la servir.
+
+{: .note }
+> Amb **Atribut de grups** `memberOf`, una cerca de grups configurada s'executa però el seu resultat no s'utilitza per als rols.
+
+Cada grup és un DN, i AnsibleForms en conserva el primer CN: `CN=AF-Admins,OU=Groups,DC=example,DC=com` passa a ser `AF-Admins`.
+Després s'aplica el **Filtre de grups** a aquest nom, i els grups que queden reben el prefix `ldap/`: `ldap/AF-Admins`.
+
+En directoris grans el filtre manté petits els tokens i les tasques; una expressió regular no vàlida conserva tots els grups i es registra.
+
+---
+
+## Assignació a rols
+
+A config.yaml, un grup LDAP és `ldap/<group CN>` i un usuari LDAP és `ldap/<username>`, tots dos distingeixen majúscules i minúscules:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+El nom d'usuari és el valor de l'**Atribut del nom d'usuari** tal com el retorna el directori, no tal com l'ha escrit l'usuari.
+Vegeu [Rols](../config/roles.html) per a les opcions dels rols.
+
+---
+
+## Diversos directoris
+
+Des de la 7.3.0 hi pot haver diversos directoris, cadascun amb els seus propis servidors, usuaris i grups. Els seus noms distingeixen els seus membres:
+
+| Directori | Nom d'usuari | Grups | En un rol |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Qualsevol altre, com ara `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Un usuari nomena el directori en iniciar sessió com a `corp\jdoe` o `corp/jdoe`, o inicia sessió amb una adreça d'un domini que és
+del directori. Un nom d'usuari sense directori es prova a cada directori activat, en el seu ordre, i també un nom com ara `other\jdoe` quan cap
+directori no es diu `other`: llavors es cerca tal com s'ha escrit.
+
+Decideix el primer directori que coneix l'usuari: una contrasenya incorrecta en aquest és la resposta, i el directori següent no es
+prova, ja que podria contenir una altra persona amb aquest nom. Un directori al qual no es pot arribar s'omet.
+
+El directori anomenat `default` fins a la 7.2.0 es diu `main` des de la 7.3.0: l'actualització el reanomena, i una instal·lació nova comença
+amb `main`. Els seus membres conserven els seus noms curts, així que els rols que els nomenen no necessiten cap canvi. El directori `main` no es pot
+reanomenar, i el nom d'un directori només conté lletres, xifres, `-` i `_`.
+
+---
+
+## Provar la connexió
+
+**Prova la connexió** demana un nom d'usuari i una contrasenya de prova, i intenta un inici de sessió amb la configuració de la pantalla, desada o no.
+Si funciona, mostra l'entrada de l'usuari al directori, que t'indica els noms exactes dels atributs i els DN dels grups que has de fer servir.
+
+Un usuari de prova que no existeix també informa d'èxit: la connexió i el compte de bind funcionen, només que l'usuari no es
+troba. Errors habituals:
+
+| Missatge | Causa |
+|---|---|
+| `Bad server or port (connection failed)` | El nom de host no es resol o no es pot arribar al port. |
+| `Wrong binding credentials` | El DN o la contrasenya de bind de la credencial del directori són incorrectes. |
+| `Unable to verify the certificate` | El certificat del servidor no està signat pel Paquet de CA de la credencial. |
+| `Certificate is not valid` | El Certificat o el Paquet de CA de la credencial no contenen un certificat PEM vàlid. |
+
+---
+
+## Exemple amb Active Directory
+
+Aquest exemple es connecta a dos controladors de domini per LDAPS i només conserva els grups el nom dels quals comença per `AF-`:
+
+| Ajust | Valor |
+|---|---|
+| Credencial > Servidors | `dc01.example.com`, i després `dc02.example.com` |
+| Credencial > Port | `636` |
+| Credencial > Activa TLS | activat |
+| Credencial > Ignora els certificats | desactivat, amb un certificat de client i la cadena de CA de la CA de l'empresa |
+| Credencial > DN de l'usuari de bind | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Base de cerca | `OU=Users,DC=example,DC=com` |
+| Atribut de correu | `mail` |
+| Atribut del nom d'usuari | `sAMAccountName` |
+| Atribut de grups | `memberOf` |
+| Filtre de grups | `^AF-` |
+
+Els membres de `CN=AF-Operators,…` coincideixen amb els rols que fan servir `ldap/AF-Operators`, i inicien sessió com a `jdoe` o `jdoe@example.com`.
+
+---
+
+## Exemple amb OpenLDAP
+
+Aquest exemple fa servir una cerca de grups sobre entrades `groupOfNames`, així que funciona sense l'overlay `memberof`:
+
+| Ajust | Valor |
+|---|---|
+| Credencial > Servidors | `ldap.example.com` |
+| Credencial > Port | `636` |
+| Credencial > Activa TLS | activat |
+| Credencial > DN de l'usuari de bind | `cn=readonly,dc=example,dc=com` |
+| Base de cerca | `ou=people,dc=example,dc=com` |
+| Atribut de correu | `mail` |
+| Atribut del nom d'usuari | `uid` |
+| Atribut de grups | `groups` |
+| Base de cerca de grups | `ou=groups,dc=example,dc=com` |
+| Classe de grup | `groupOfNames` |
+| Atribut de membre del grup | `member` |
+| Atribut d'usuari del membre del grup | `dn` |
+
+Un usuari llistat a `cn=af-admins,ou=groups,dc=example,dc=com` rep el grup `ldap/af-admins`. Per a grups `posixGroup`,
+fes servir **Atribut de membre del grup** `memberUid` i **Atribut d'usuari del membre del grup** `uid`.
+
+Amb l'overlay `memberof`, deixa buits els camps de cerca de grups i posa **Atribut de grups** a `memberOf`.
+
+---
+
+## Errors habituals
+
+La majoria dels problemes amb LDAP es redueixen a un d'aquests:
+
+- **Un usuari local amb el mateix nom.** Els usuaris locals es comproven primer, així que mai no es consulta el directori per a aquest nom.
+- **Cap grup, o grups equivocats.** L'Atribut de grups ha d'existir (`groups` amb una cerca de grups); `memberOf` no segueix els grups niats.
+- **Noms de grup que no coincideixen.** Fes servir `ldap/<CN>` amb les mateixes majúscules i minúscules, i comprova que el Filtre de grups conserva el grup.
+- **DN de grup que no comencen per un CN.** Només s'utilitza el primer valor `CN=` com a nom del grup, així que tots els DN de grup
+  han de començar per `CN=` (o `cn=`).
+- **Certificats.** El TLS necessita els dos camps de certificat de la credencial i un nom de servidor que coincideixi; Ignora els certificats és només per a proves.
+- **Una configuració que no es pot desar.** Quan un directori ve de la [llavor de configuració](../seed/managed-objects.html), la seva pàgina
+  és només de lectura: canvia el fitxer de la llavor.
+
+Un inici de sessió fallit mostra un missatge genèric. El servidor en registra el motiu i el conserva al registre d'auditoria, i per a Active
+Directory es tradueix a partir del codi del directori, p. ex. `Wrong password`, `Account locked` o `Password expired`.
diff --git a/i18n/ca/_configure/authentication/local.md b/i18n/ca/_configure/authentication/local.md
new file mode 100644
index 0000000..1e95c83
--- /dev/null
+++ b/i18n/ca/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Comptes locals
+parent: Autenticació
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Comptes locals
+{: .no_toc }
+
+L'admin integrat, i els usuaris i grups desats a la base de dades d'AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'admin integrat
+
+Cada arrencada crea el grup local `admins` i l'usuari admin si no existeixen; tres variables controlen l'admin:
+
+| Variable | Predeterminat | Significat |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Nom d'usuari de l'admin, creat al grup `admins` quan cap usuari no té aquest nom. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Contrasenya que rep l'admin quan es crea (o es restableix). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` restableix la contrasenya de l'admin a `ADMIN_PASSWORD` i el torna a posar a `admins`. |
+
+`ADMIN_PASSWORD` només s'utilitza quan l'usuari es crea o es restableix: canviar-la després no fa res per si sol.
+
+Un usuari local que inicia sessió amb la contrasenya predeterminada pública `AnsibleForms!123` només la pot canviar. El navegador obre una
+pàgina de canvi de contrasenya que no es pot tancar, i el servidor respon a qualsevol altra petició amb `403` (codi
+`password_change_required`) fins que es canvia la contrasenya. La contrasenya nova ha de ser diferent de la predeterminada; després del
+canvi, l'usuari torna a iniciar sessió amb ella. Defineix `ADMIN_PASSWORD` amb el teu propi valor abans de la primera arrencada per saltar-te aquest pas.
+
+Canviar `ADMIN_USERNAME` després de la primera arrencada crea un segon usuari admin amb aquest nom; l'antic es conserva.
+
+{: .warning }
+> `REINIT_ADMIN=1` restableix la contrasenya a **cada** arrencada mentre està definida. Fes-la servir per recuperar una contrasenya d'admin perduda,
+> i després treu-la i reinicia.
+
+---
+
+## Usuaris i grups
+
+Els usuaris i grups locals es gestionen a **Accés > Usuaris** i **Accés > Grups**. Un usuari té aquests camps:
+
+| Camp | Significat |
+|---|---|
+| Nom d'usuari | El nom d'inici de sessió. Ha de ser únic. |
+| Descripció | Opcional. |
+| Contrasenya | Es desa com a hash. Canvia-la més endavant amb l'acció **Canvia la contrasenya**. |
+| Correu electrònic | Opcional. |
+| Grup | El primer grup local de l'usuari. Afegeix-ne més a la pestanya **Grups** de la pàgina de l'usuari. |
+
+Els usuaris locals canvien la seva pròpia contrasenya al seu perfil; els altres usuaris ho fan al seu directori o proveïdor d'identitat.
+
+Un usuari pot pertànyer a diversos grups, i rep els rols de tots ells. La pestanya **Grups** de la pàgina d'un usuari afegeix i
+treu grups, igual que la pestanya **Usuaris** de la pàgina d'un grup. Un usuari conserva almenys un grup: l'últim no es pot
+treure.
+
+Un grup que encara té usuaris no es pot suprimir: primer treu-ne els usuaris. El grup `admins` no es pot suprimir ni
+reanomenar mai, i l'usuari `admin` no es pot suprimir mai.
+
+---
+
+## Permetre l'inici de sessió
+
+La pestanya **Detalls** de la pàgina d'un usuari té un interruptor **Permet l'inici de sessió**, que també s'ofereix com a **Bloqueja l'inici de sessió** i **Permet
+l'inici de sessió** al menú de fila de la llista d'usuaris. Existeix tant per als usuaris locals com per als usuaris LDAP i SSO:
+
+- **Activat**: l'usuari inicia sessió amb normalitat.
+- **Desactivat**: les sessions de l'usuari acaben a l'instant i es rebutja qualsevol inici de sessió, fins que un admin el torni a activar. La pàgina
+  demana confirmació abans.
+
+L'interruptor no es pot desactivar per a l'usuari `admin`, la via per tornar a entrar, ni el pot desactivar un admin per al seu propi compte. La pàgina
+d'un usuari LDAP o SSO també té **Tanca les sessions**, que tanca la sessió de l'usuari a tot arreu sense bloquejar-lo.
+
+---
+
+## Assignació a rols
+
+Els rols nomenen els grups locals com a `local/<group>` i els usuaris com a `local/<user>`; per defecte `admins` rep `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Mantén `local/admins` al rol `admin`, perquè l'admin integrat sempre pugui iniciar sessió, fins i tot quan el directori o el
+proveïdor d'identitat no estan disponibles. Quan config.yaml no es pot carregar de cap manera, els membres de `local/admins` continuen rebent el
+rol `admin`, així que pots iniciar sessió i corregir-ho. Vegeu [Rols](../config/roles.html) per a les opcions dels rols.
+
+---
+
+## Comptes locals i LDAP
+
+Un inici de sessió amb usuari i contrasenya comprova els usuaris locals abans que LDAP. Quan un usuari local té el mateix nom que un usuari
+del directori, el compte local sempre guanya i la contrasenya del directori no funciona per a aquest nom. Dona als comptes locals noms
+que no puguin coincidir amb comptes del directori, per exemple amb un prefix `svc-`.
diff --git a/i18n/ca/_configure/authentication/oidc.md b/i18n/ca/_configure/authentication/oidc.md
new file mode 100644
index 0000000..34b3f60
--- /dev/null
+++ b/i18n/ca/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Autenticació
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Inici de sessió únic amb un proveïdor OpenID Connect com ara Keycloak, amb rols segons un claim de grups
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Com funciona
+
+Amb un proveïdor OIDC activat, la pàgina d'inici de sessió mostra un botó d'OpenID sota **Inicia la sessió**. Un inici de sessió segueix aquests passos:
+
+1. El botó envia el navegador a `/api/v2/auth/oidc`, que el redirigeix al proveïdor (flux de codi d'autorització
+   amb PKCE).
+2. L'usuari inicia sessió al proveïdor, que el redirigeix de tornada a la **URL de redirecció**.
+3. El servidor intercanvia el codi per tokens i llegeix els claims de l'ID token.
+4. El nom d'usuari és el claim `preferred_username`, i cada valor del claim `groups` que passa el
+   **Filtre de grups** es converteix en un grup `oidc/<value>`.
+
+AnsibleForms demana els scopes `openid profile email`; els scopes no són configurables. Tancar la sessió d'AnsibleForms
+també envia el navegador a l'endpoint de final de sessió del proveïdor, quan el proveïdor en publica un.
+
+{: .note }
+> OIDC s'ha provat amb Keycloak. Altres proveïdors funcionen quan compleixen els requisits següents.
+
+---
+
+## Requisits del proveïdor
+
+El proveïdor ha d'oferir el descobriment d'OpenID Connect i un client confidencial per a AnsibleForms:
+
+- **Descobriment**: AnsibleForms llegeix `<issuer>/.well-known/openid-configuration`, així que l'emissor ha de ser accessible des
+  del servidor d'AnsibleForms, per HTTPS.
+- **Un client confidencial** amb el flux de codi d'autorització, un ID de client i un secret de client.
+- **L'URI de redirecció** `https://af.example.com/api/v2/auth/oidc/callback`, és a dir, l'adreça amb què els usuaris arriben a
+  AnsibleForms seguida de `/api/v2/auth/oidc/callback`. Amb [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms`, passa a ser `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Un claim `groups` a l'ID token**, amb una llista de noms de grup. Sense aquest claim, l'usuari no rep cap grup OIDC.
+- **Un claim `preferred_username`**, que es converteix en el nom d'usuari.
+
+---
+
+## Exemple amb Keycloak
+
+Aquest exemple utilitza un realm `example` a `https://keycloak.example.com`; l'emissor és llavors
+`https://keycloak.example.com/realms/example`. En aquest realm:
+
+1. A **Clients**, crea un client OpenID Connect amb el client ID `ansibleforms`. Activa **Client authentication**,
+   mantén **Standard flow** i posa a **Valid redirect URIs** `https://af.example.com/api/v2/auth/oidc/callback`.
+2. A la pestanya **Credentials** del client, copia el **Client secret**.
+3. A la pestanya **Client scopes**, obre `ansibleforms-dedicated` i afegeix un mapper **By configuration > Group Membership**,
+   amb **Token Claim Name** `groups`, **Full group path** desactivat i **Add to ID token** activat.
+
+Amb **Full group path** activat, el claim conté camins com ara `/af-admins`, i llavors el rol ha d'utilitzar `oidc//af-admins`.
+
+---
+
+## Afegir el proveïdor
+
+Afegeix el proveïdor a **Accés > SSO**: un assistent en demana els camps en quatre passos, amb **Open ID** al pas **Tipus**:
+
+| Pas | Camp | Significat |
+|---|---|---|
+| Detalls | Nom, Descripció | Un nom únic per al proveïdor i una descripció opcional |
+| Tipus | Proveïdor | **Open ID**; es fixa quan es crea i no canvia |
+| Credencials | Credencial | Una credencial **Open ID** de [Connexions > Credencials](../credentials.html), vegeu més avall |
+| Grups | Filtre de grups | Expressió regular; només es conserven els valors del claim `groups` que coincideixen. Buit conserva tots els grups |
+
+La credencial conté el client, així que només un admin la pot afegir o canviar:
+
+| Camp | Significat |
+|---|---|
+| Emissor | Obligatori. La URL de l'emissor, p. ex. `https://keycloak.example.com/realms/example` |
+| ID del client | L'ID de client al proveïdor, p. ex. `ansibleforms` |
+| Secret del client | El secret de client, desat xifrat o llegit d'un [magatzem de secrets](../secret-stores/) |
+| URI de redirecció | Tal com està registrat, p. ex. `https://af.example.com/api/v2/auth/oidc/callback`. Buit: la URL de l'aplicació i el camí de retorn |
+
+Fins a la 7.2.0 l'emissor, l'ID del client, el secret i la URL de redirecció eren camps del proveïdor. L'actualització a la 7.3.0 els trasllada a una
+credencial anomenada `<provider>-sso`, vegeu [Adreces a les credencials](../credentials/types.html#addresses-in-credentials).
+Tria una credencial per a cada proveïdor nou: el servidor encara accepta un proveïdor amb el seu propi ID de client i secret d'abans
+de la 7.3.0, que hi inicia sessió fins que es tria una credencial.
+
+Només hi ha un proveïdor OIDC activat alhora, aquell amb què inicia sessió el botó d'OpenID. **Activa** al menú de fila d'un altre,
+o el seu interruptor **Activat**, desactiva els altres del seu tipus; la columna **Activat** de la llista mostra quin s'està fent servir.
+Un proveïdor també es pot saltar la pàgina d'inici de sessió, vegeu [Activar i desactivar l'inici de sessió únic](./#switching-single-sign-on).
+
+Desar el proveïdor l'aplica immediatament. Quan no es pot arribar a l'emissor, el servidor registra
+`Failed to initialize OIDC strategy` i els inicis de sessió OIDC fallen fins que es torna a desar el proveïdor o es reinicia el servidor.
+
+---
+
+## Assignació a rols
+
+A config.yaml, un grup OIDC és `oidc/<group>` i un usuari és `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+Els valors es comparen exactament, majúscules i minúscules incloses. Vegeu [Rols](../config/roles.html) per a les opcions dels rols.
+
+---
+
+## Limitacions
+
+Els usuaris OIDC inicien sessió al proveïdor, així que algunes coses funcionen de manera diferent que amb els comptes locals i LDAP:
+
+- No tenen contrasenya a AnsibleForms, així que no la hi poden canviar; des de la 7.2.0 un [token d'API](../profile/api-token.html)
+  es crea des de la seva sessió.
+- Mantén curt el claim `groups`: envia només els grups que importen a AnsibleForms, per exemple amb un client scope dedicat
+  o una estructura de grups al proveïdor, o filtra'ls amb el **Filtre de grups**. Des de la 7.1.0 el token d'inici
+  de sessió d'AnsibleForms ja no porta els grups; abans, un usuari amb cent grups o més podia no veure cap formulari, vegeu
+  [Formularis i tasques buits després d'un inici de sessió únic](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/ca/_configure/config/categories.md b/i18n/ca/_configure/config/categories.md
new file mode 100644
index 0000000..4c32244
--- /dev/null
+++ b/i18n/ca/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Categories
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Categories
+{: .no_toc }
+
+Agrupa els formularis al tauler.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'atribut categories
+
+La llista `categories` de primer nivell de config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Objecte Category
+
+Cada entrada de la llista `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/ca/_configure/config/constants.md b/i18n/ca/_configure/config/constants.md
new file mode 100644
index 0000000..812cb8a
--- /dev/null
+++ b/i18n/ca/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Constants
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Constants
+{: .no_toc }
+
+Objectes lliures que tots els formularis poden reutilitzar.
+{: .fs-6 .fw-300 }
+
+---
+
+## L'atribut constants
+
+L'objecte `constants` de primer nivell de config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/ca/_configure/config/index.md b/i18n/ca/_configure/config/index.md
new file mode 100644
index 0000000..b20f545
--- /dev/null
+++ b/i18n/ca/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Categories, rols i constants per a tots els formularis
+{: .fs-6 .fw-300 }
+
+---
+
+Per a administradors: el fitxer config.yaml que conté les categories, els rols i les constants que comparteixen tots els formularis.
+
+AnsibleForms utilitza un fitxer config.yaml per configurar categories, rols i constants. Si no se n'hi proporciona cap, se'n genera un amb una configuració mínima. La configuració també es pot importar a la base de dades, i llavors ja no cal cap fitxer config.yaml.
+
+---
+
+## Visió general
+
+El fitxer config.yaml conté la configuració de les categories, els rols i les constants que utilitza AnsibleForms.
+
+**VÍDEO**: [Crea el teu primer formulari](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+El config.yaml mínim següent serveix com a punt de partida. Només conté la categoria obligatòria `Default` i els rols obligatoris `admin` i `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Prioritat de càrrega de la configuració
+
+AnsibleForms carrega el fitxer config.yaml en l'ordre següent (guanya la primera coincidència):
+
+1. **DES DE LA BASE DE DADES** : la configuració importada a la base de dades, només quan `ENABLE_CONFIG_IN_DATABASE=1`, o quan aquesta
+   variable no està definida i l'origen de configuració desat a la base de dades és `database` (una còpia buida recorre al fitxer)
+2. **DES D'UN REPOSITORI (use_for_config)** : el repositori amb l'interruptor "utilitzar per a la configuració" activat (nou a la 6.1.0)
+3. **DES D'UN REPOSITORI (use_for_forms)** : el repositori amb l'interruptor "utilitzar per als formularis" activat (alternativa per compatibilitat amb versions anteriors)
+4. **DES D'UN FITXER LOCAL** : el fitxer local `config.yaml` (variable d'entorn CONFIG_PATH)
+
+{: .warning }
+> **Nota:** Activa "utilitzar per a la configuració" en un sol repositori. Si n'hi ha diversos que el tenen activat, es registra un avís i s'utilitza el primer.
+
+---
+
+## En aquesta secció
+
+El fitxer té tres atributs de primer nivell, i cadascun té la seva pròpia pàgina:
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Categories](categories.html) | Agrupa els formularis del tauler en un arbre de categories amb icones |
+| [Rols](roles.html) | Assigna usuaris i grups a rols, i defineix què pot fer cada rol |
+| [Constants](constants.html) | Objectes lliures que tots els formularis poden reutilitzar |
diff --git a/i18n/ca/_configure/config/roles.md b/i18n/ca/_configure/config/roles.md
new file mode 100644
index 0000000..c05cce2
--- /dev/null
+++ b/i18n/ca/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Rols
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Rols
+{: .no_toc }
+
+Assigna usuaris i grups a rols, i defineix què pot fer cada rol.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'atribut roles
+
+La llista `roles` de primer nivell de config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## El rol default
+
+Tots els usuaris que han iniciat sessió tenen el rol `default`, de manera que un formulari amb `roles: [default]` està obert a tothom qui pot iniciar sessió. No
+hi ha accés anònim: ningú no rep aquest rol sense iniciar sessió.
+
+El rol no conté cap grup ni cap usuari, perquè ja s'aplica a tothom. Les seves `options` són els valors predeterminats de tothom, tal com
+es descriu a [Opcions de rol](#role-options) més avall. `config.yaml` ha de tenir un rol `admin` i un rol `default`, i la
+pàgina de rols mostra tots dos com a **Obligatori**.
+
+`default` es deia `public` abans de la 7.0.0, i el nom antic continua funcionant:
+
+- **En un formulari**, `roles: [public]` continua coincidint amb tots els usuaris, així que els formularis dels teus repositoris no necessiten cap canvi.
+- **A `config.yaml`**, un rol anomenat `public` es reanomena `default` al fitxer quan es carrega la configuració. Només canvia el
+  nom, abans es fa una còpia de seguretat de la configuració, i una configuració guardada en un repositori queda amb un canvi pendent de fer push.
+- **En una plantilla ytt**, la plantilla no es reescriu: es reanomena la configuració que produeix, i un avís al registre et demana
+  que també reanomenis el rol a la plantilla. La versió 8 hi rebutja un rol `public`.
+
+Una configuració que té alhora un rol `default` i un rol `public` es rebutja, perquè són el mateix rol.
+
+---
+
+## Objecte Role
+
+Cada entrada de la llista `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Opcions de rol
+
+Les `options` d'un rol activen o desactiven funcions per als seus membres. Des de la 7.3.0 la pàgina del rol les mostra en quatre grups,
+cada opció amb una (i) que explica què dona, el mateix text que mostra la vista **Permisos** del perfil:
+
+| Opció | Permet a l'usuari | Predeterminat |
+|---|---|---|
+| **Configuració** | | |
+| `showSettings` | Veure i canviar totes les pàgines de configuració; el registre del servidor i les còpies de seguretat tenen les seves pròpies opcions | Només admins |
+| `showAppearanceSettings` | Canviar la configuració d'aparença, sense la resta de la configuració (des de la 7.3.0) | Desactivat |
+| `showConnectionsSettings` | Gestionar la configuració de connexions (credencials, runners i més), sense la resta de la configuració (des de la 7.3.0) | Desactivat |
+| `showLogs` | Veure el registre del servidor | Només admins |
+| `showAuditLog` | Veure el registre d'auditoria, sense la resta de la configuració (des de la 7.3.0) | Només admins |
+| `allowBackupOps` | Fer còpies de seguretat de la base de dades i restaurar-la | Només admins |
+| **Dissenyador** | | |
+| `showDesigner` | Veure i utilitzar el dissenyador | Només admins |
+| `allowFormDesign` | Editar la configuració de formularis al dissenyador: categories, constants i formularis. Sense aquesta opció, només lectura (des de la 7.3.0) | Activat |
+| `allowPlaybookDesign` | Editar els playbooks al dissenyador: desar-los, crear-los, treure'ls i fer-ne push. Sense aquesta opció, només lectura | Activat |
+| `allowWorkflowDesign` | Editar els workflows al dissenyador: desar-los, crear-los, treure'ls i fer-ne push. Sense aquesta opció, només lectura | Activat |
+| `allowInventoryDesign` | Editar els inventaris al dissenyador: desar-los, crear-los, treure'ls i fer-ne push. Sense aquesta opció, només lectura | Activat |
+| `allowVarsFileDesign` | Editar els fitxers de variables al dissenyador: desar-los, crear-los, treure'ls i fer-ne push. Sense aquesta opció, només lectura | Activat |
+| **Tasques** | | |
+| `showJobs` | Veure la pàgina de tasques | Activat |
+| `showAllJobLogs` | Veure les tasques de tots els usuaris, no només les seves | Només admins |
+| `manageAllJobs` | Avortar, suprimir i tornar a llançar les tasques de tots els usuaris; suprimir i tornar a llançar també necessiten les dues opcions següents (des de la 7.3.0) | Només admins |
+| `showExtravars` | Veure les extravars d'un formulari i d'una tasca | Activat |
+| `showDebugButtons` | Veure els botons de depuració d'un formulari | Activat |
+| `showArtifacts` | Veure els artefactes d'una tasca: el que retorna una tasca d'AWX, o el que un playbook ha recollit amb `set_stats` | Activat |
+| `allowVerboseMode` | Executar tasques en mode detallat | Activat |
+| `allowJobRelaunch` | Tornar a llançar una tasca amb les dades del formulari d'una execució anterior | Només admins |
+| `allowJobDeletion` | Suprimir tasques: les seves, o les de tots els usuaris amb `manageAllJobs`. Sense aquesta opció, l'historial de tasques es conserva sencer (des de la 7.3.0) | Activat |
+| `allowScheduledJobs` | Crear i gestionar programacions recurrents i puntuals, a la pàgina **Programacions** (vegeu l'avís més avall) | Només admins |
+| `allowPlannedJobs` | Planificar una tasca perquè s'executi una vegada a una hora fixada (**Executa més tard**) | Activat |
+| `allowStoredJobs` | Desar les dades d'un formulari i tornar-les a carregar més tard | Activat |
+| **Accés i integracions** | | |
+| `allowLogin` | Iniciar sessió a AnsibleForms | Activat |
+| `allowChat` | Utilitzar l'[assistent de xat](../chat/), quan està activat | Activat |
+| `allowMcp` | Utilitzar el [servidor MCP](../mcp/) des d'un agent d'IA, quan està activat | L'`allowChat` del rol |
+| `allowFileUploads` | Pujar fitxers mitjançant els camps de fitxer d'un formulari (des de la 7.3.0) | Activat |
+| `allowApiTokens` | Crear [tokens d'API](../profile/api-token.html) per a scripts, fins a la durada màxima que permet la instància (des de la 7.3.0) | Desactivat |
+| `extendedTokenExpiration` | Crear també tokens d'API que no caduquen mai; necessita `allowApiTokens` | Desactivat |
+
+Algunes opcions n'inclouen d'altres, i la pàgina del rol mostra les incloses activades i en gris:
+
+- **`showSettings`** també dona `showAppearanceSettings`, `showConnectionsSettings` i `showAuditLog`.
+- **`manageAllJobs`** també dona `showAllJobLogs`, ja que actuar sobre les tasques de tots els usuaris vol dir veure-les.
+- **Les opcions de disseny** només compten amb `showDesigner`, i `extendedTokenExpiration` només amb `allowApiTokens`.
+
+Fins a la 7.2.0, `showAllJobLogs` també permetia a l'usuari avortar i suprimir les tasques que mostrava; des de la 7.3.0 això requereix `manageAllJobs`.
+Un rol d'abans de la 7.3.0 amb `extendedTokenExpiration` i sense `allowApiTokens` rep `allowApiTokens`, de manera que conserva els seus tokens.
+
+**Només admins** vol dir activat per als usuaris que tenen el rol `admin`, i desactivat per a tota la resta. Quan un usuari coincideix amb diversos rols,
+les opcions es combinen així:
+
+- **Entre els rols de l'usuari**, una opció només està activada quan tots els rols que la defineixen hi estan d'acord: un `false` explícit guanya.
+- **El rol `default`** completa les opcions que no defineix cap dels altres rols de l'usuari, de manera que pot contenir valors predeterminats per a tothom.
+- **Les opcions que no es defineixen enlloc** prenen el valor predeterminat de la taula.
+
+`showExtraVars`, amb V majúscula, s'accepta com una altra grafia de `showExtravars`; quan qualsevol de les dues és `false`, l'opció
+està desactivada.
+
+{: .warning }
+> Tracta `allowScheduledJobs` com una opció de nivell d'admin. Les programacions no pertanyen a l'usuari que les ha creat: tots els usuaris amb
+> l'opció veuen i poden canviar totes les programacions. A més, una programació s'executa amb drets d'admin, per a qualsevol formulari, sigui quin sigui
+> l'accés del creador. Concedeix-la només a rols en què confiaries com a admins.
+
+{: .warning }
+> `allowLogin: false` al rol `default` deixa fora tots els usuaris els altres rols dels quals no defineixen `allowLogin: true`, inclosos
+> els admins. Torna-la a concedir als rols que han de poder iniciar sessió abans de desar.
diff --git a/i18n/ca/_configure/credentials.md b/i18n/ca/_configure/credentials.md
new file mode 100644
index 0000000..3d0c6ea
--- /dev/null
+++ b/i18n/ca/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Credencials
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Credencials
+{: .no_toc }
+
+Desa els accessos amb què es connecten els formularis, els repositoris, els magatzems de secrets i els canals de notificació
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: afegeix els usuaris, les contrasenyes i els tokens amb què es connecta AnsibleForms, desats xifrats o llegits d'un magatzem de secrets.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Tipus de credencial](credentials/types.html) | Què conté cada tipus i on es pot triar |
+| [La pàgina de credencials](credentials/list.html) | La llista de credencials i el diàleg que n'afegeix una |
+| [La pàgina d'una credencial](credentials/credential-page.html) | Les pestanyes d'una credencial i què la utilitza |
+
+---
+
+## Com funciona
+
+Una **credencial** és un accés amb nom, que s'afegeix a **Connexions > Credencials**. Els formularis i els altres objectes d'administració
+s'hi refereixen pel seu nom, de manera que la contrasenya mai no apareix en un formulari. El seu usuari i la seva contrasenya o bé es desen a la
+base de dades d'AnsibleForms, xifrats amb `ENCRYPTION_SECRET`, o bé es llegeixen d'un [magatzem de secrets](secret-stores/) cada vegada que
+s'utilitza la credencial.
+
+---
+
+## Qui pot canviar una credencial
+
+Des de la 7.3.0, una credencial de la qual depèn una connexió o un inici de sessió només la pot afegir, canviar o suprimir un admin:
+
+| Credencials | Per què |
+|---|---|
+| Tipus de connexió: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` i `cyberark` | Un runner o un magatzem de secrets en pren l'adreça i el secret |
+| Tipus d'inici de sessió: `oidc`, `entraid` i `ldap` | Un proveïdor SSO o un directori LDAP hi inicia la sessió dels usuaris |
+| Qualsevol credencial que nomeni un runner | El runner hi inicia sessió, i un canvi del mateix runner també necessita un admin |
+
+Els altres usuaris amb accés a les credencials les veuen només de lectura. Un usuari que pogués apuntar una credencial d'aquest tipus a un altre
+servidor rebria tots els secrets que s'hi envien, i per això la regla segueix la dels runners. Tres regles més
+mantenen aquests usuaris lluny de secrets que d'una altra manera no podrien llegir:
+
+- **Nomenar una credencial protegida**: només un admin pot nomenar una d'aquestes credencials en un altre lloc, com ara en un repositori,
+  un canal de notificació o la configuració de l'assistent de xat. Una credencial que llegeix la seva contrasenya d'un magatzem de secrets està
+  protegida de la mateixa manera, sigui quin sigui el seu tipus.
+- **Triar un magatzem de secrets**: només un admin pot apuntar una credencial a un [magatzem de secrets](secret-stores/), o canviar el
+  magatzem o la referència que llegeix; un altre usuari encara els pot tornar a enviar sense canvis, o buidar-los tots.
+- **Moure una credencial**: quan un altre usuari canvia on inicia sessió una credencial (el seu host, port, emissor, tenant o
+  adreça del servidor) sense tornar a escriure'n la contrasenya, la contrasenya desada s'esborra, i també la referència del magatzem de secrets
+  que llegeix, de manera que el secret antic mai no va al nou destí.
+
+---
+
+## Credencials en ús
+
+Una credencial que encara nomenen altres registres no es pot suprimir ni reanomenar, perquè quedarien apuntant a res.
+El rebuig indica quants registres la utilitzen; la pestanya **Usat per** de [la seva pàgina](credentials/credential-page.html) els llista.
+Apunta'ls primer a una altra credencial, i després suprimeix-la o reanomena-la.
diff --git a/i18n/ca/_configure/credentials/credential-page.md b/i18n/ca/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..5f4ba79
--- /dev/null
+++ b/i18n/ca/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "La pàgina d'una credencial"
+parent: Credencials
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# La pàgina d'una credencial
+{: .no_toc }
+
+Les pestanyes d'una credencial i què la utilitza
+{: .fs-6 .fw-300 }
+
+La pàgina d'una credencial mostra els passos del seu diàleg com a pestanyes, més el que la utilitza:
+
+| Pestanya | Què conté |
+|---|---|
+| Detalls | Nom i descripció. |
+| Tipus | Per a què serveix la credencial. |
+| Accés | Tots els camps del seu tipus, com al pas **Accés** del diàleg: l'usuari, la contrasenya i on inicia sessió (host i port, la base de dades, el servidor de correu, els servidors del directori, el tenant o l'emissor, l'adreça del servidor i el seu TLS). L'AppID, el certificat de client i la clau d'una credencial CyberArk. |
+| Magatzem | Base de dades o Magatzem de secrets, i el magatzem i la referència. No per a CyberArk ni HashiCorp Vault. |
+| Usat per | Tot el que nomena aquesta credencial: magatzems de secrets, canals de notificació, repositoris, directoris LDAP, proveïdors SSO, runners, l'assistent de xat, formularis i els workflows del dissenyador. Una fila l'obre. |
+
+La contrasenya s'escriu a la pestanya **Accés** i no es torna a mostrar mai un cop desada: si es deixa buida, es conserva la desada. En una credencial
+CyberArk, deixa buida la clau de client per conservar la desada. A dalt a la dreta hi ha **Prova la connexió** (només credencials de base de dades),
+**Suprimeix** i **Desa**.
+
+Des de la 7.3.0, **Suprimeix** i un nom nou es rebutgen mentre **Usat per** llisti alguna cosa, vegeu [Credencials en ús](../credentials.html#credentials-in-use).
+
+Una credencial declarada a la [llavor de configuració](../seed/) és només de lectura en aquesta pàgina: canvia-la al fitxer de la llavor.
diff --git a/i18n/ca/_configure/credentials/list.md b/i18n/ca/_configure/credentials/list.md
new file mode 100644
index 0000000..7ddd28f
--- /dev/null
+++ b/i18n/ca/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: La pàgina de credencials
+parent: Credencials
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# La pàgina de credencials
+{: .no_toc }
+
+La llista de credencials i el diàleg que n'afegeix una
+{: .fs-6 .fw-300 }
+
+La pàgina de **Connexions > Credencials** llista totes les credencials amb el seu **Nom**, **Tipus**, **Descripció** i **Usat per**, el
+nombre de registres, formularis i workflows que la nomenen (vegeu [Credencials en ús](../credentials.html#credentials-in-use)).
+
+**Afegeix credencial** obre un diàleg per passos:
+
+| Pas | Camps |
+|---|---|
+| Credencial | Nom i descripció, tots dos obligatoris. |
+| Tipus | Un de 18 tipus, vegeu més avall. |
+| Accés | Amb què i on inicia sessió el tipus, vegeu més avall. |
+| Magatzem | On es desen l'usuari i la contrasenya: **Base de dades** (xifrats a la base de dades d'AnsibleForms) o **Magatzem de secrets**, amb el magatzem i la **Referència** que hi ha dins. No per a CyberArk ni HashiCorp Vault, amb els quals inicia sessió un magatzem de secrets. |
+
+El pas **Tipus** llista els tipus pel seu nom: AAP, API, Ascender, AWX, CyberArk, Base de dades, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH i Usuari i contrasenya (vegeu [Tipus de credencial](types.html)).
+
+El pas **Accés** conté tots els camps del tipus, l'adreça inclosa; no hi ha cap pas de connexió a part:
+
+| Tipus | Camps del pas Accés |
+|---|---|
+| Tots els tipus excepte CyberArk | La contrasenya, o el que en fa les funcions: la contrasenya de bind de LDAP, el secret de client d'Entra ID i Open ID, el token d'HashiCorp Vault, el token de l'RTE, el token d'API de Semaphore, Rundeck i Jenkins, un token o una contrasenya per a AWX, AAP i Ascender |
+| Tots els tipus excepte HashiCorp Vault, RTE, Semaphore i Rundeck | L'usuari: l'AppID de CyberArk, el DN de bind de LDAP, l'ID de client d'Entra ID i Open ID, opcional per a AWX, AAP i Ascender |
+| SSH, Base de dades | **Amfitrió** i **Port**; per a una base de dades també el **Tipus de base de dades** i la **Base de dades** |
+| SMTP | **Servidor de correu** (obligatori), el seu **Port** i **Utilitza TLS** |
+| LDAP | Els **Servidors** del directori (obligatori), el seu **Port** i **Activa TLS**; amb TLS, **Ignora els certificats**, el **Paquet de CA** i un **Certificat de client** |
+| Microsoft Entra ID | **ID del tenant** (obligatori) i **URI de redirecció** |
+| Open ID | **Emissor** (obligatori) i **URI de redirecció** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Servidor**, l'adreça on inicia sessió, obligatori, amb **Omet la verificació del certificat** i el **Paquet de CA** |
+| CyberArk | **Certificat de client** i **Clau del client** |
+
+Una fila obre la pàgina pròpia de la credencial. El seu menú ofereix **Edita**, **Prova la connexió** (només credencials de base de dades) i **Suprimeix**. La
+contrasenya es canvia a la pàgina de la credencial, a la seva pestanya **Accés**.
diff --git a/i18n/ca/_configure/credentials/types.md b/i18n/ca/_configure/credentials/types.md
new file mode 100644
index 0000000..1d55ca2
--- /dev/null
+++ b/i18n/ca/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Tipus de credencial
+parent: Credencials
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Tipus de credencial
+{: .no_toc }
+
+Què conté cada tipus i on es pot triar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Els tipus
+
+El tipus indica per a què serveix una credencial. Decideix quins camps demana el diàleg i on es pot triar:
+
+| Tipus | Què conté | Usat per |
+|---|---|---|
+| Usuari i contrasenya | Un usuari i una contrasenya per a qualsevol accés: una API REST amb autenticació bàsica, un servei i més. El predeterminat | Playbooks, mitjançant les `credentials` d'un formulari o un camp de credencial; [expressions REST](../expressions/credentials.html) |
+| SSH | Un usuari i una contrasenya per a SSH a un servidor, amb el seu host i el seu port | Playbooks, mitjançant les `credentials` o `ansibleCredentials` d'un formulari o un camp de credencial, i l'accés d'un node de workflow |
+| Git | Un usuari i una contrasenya o un token per a repositoris git | [Repositoris](../repositories/authentication.html) |
+| API | Un usuari i una contrasenya o un token per a una API REST | [Expressions REST](../expressions/credentials.html), el token d'un bot de Telegram, el bearer token d'un webhook, la clau d'API de l'assistent de xat |
+| Base de dades | Un accés a base de dades, amb el seu tipus, host, port i nom de base de dades | Consultes de formularis (`dbConfig`) i `fnCredentials`; es pot provar |
+| CyberArk | L'adreça del CyberArk Central Credential Provider (CCP) i el seu TLS, i l'AppID, el certificat de client i la clau amb què accedeix un magatzem CyberArk | Un magatzem de secrets [CyberArk](../secret-stores/cyberark.html) |
+| SMTP | Un servidor de correu, el seu port i TLS, i el seu accés (cap per a un relay) | Un [canal de notificació](../notification-channels.html) de correu |
+| LDAP | Els servidors, el port, el TLS i els certificats d'un directori, i el seu DN i contrasenya de bind | Un [directori LDAP](../authentication/ldap.html) |
+| Microsoft Entra ID | El registre d'aplicació d'un proveïdor: el seu ID de tenant, ID de client, secret de client i URI de redirecció | Un [proveïdor Entra ID](../authentication/entra-id.html) |
+| Open ID | El client d'un proveïdor: el seu emissor, ID de client, secret de client i URI de redirecció | Un [proveïdor OIDC](../authentication/oidc.html) |
+| RTE | El token (`RTE_TOKEN`) i l'adreça d'un RTE | Un [runner](../runners.html) RTE |
+| AWX, AAP, Ascender | El token o l'accés, i l'adreça, d'aquesta plataforma | Un runner d'aquest tipus |
+| Semaphore, Rundeck | El token d'API i l'adreça d'aquest producte | Un runner d'aquest tipus |
+| Jenkins | Un usuari, el seu token d'API i l'adreça d'un Jenkins | Un runner Jenkins |
+| HashiCorp Vault | El token i l'adreça amb què accedeix un magatzem Vault | Un magatzem de secrets [HashiCorp Vault](../secret-stores/hashicorp-vault.html) |
+
+Una credencial de base de dades pot ser de tipus MySQL, MSSQL, PostgreSQL, Oracle o MongoDB.
+
+A l'API i a la [llavor de configuració](../seed/), els tipus són `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` i `vault`. L'actualització des de la 6
+dona a cada credencial el tipus `userpass`, o `database` a una de base de dades: un formulari la utilitza com a la 6. Canvia-la a SSH per a un
+accés amb què es connecta el playbook d'un node de workflow, o a API per a una API REST.
+
+---
+
+## Adreces a les credencials
+
+Des de la 7.3.0, un accés que funciona en un servidor porta amb si aquest servidor, de manera que el registre que l'utilitza només nomena la credencial:
+
+| Registre | Què ha passat a la seva credencial |
+|---|---|
+| Un directori LDAP | Els seus servidors, port, TLS, certificats i compte de bind, a una credencial `ldap` anomenada `<directory>-ldap` |
+| Un proveïdor SSO | El seu ID de client i secret, tenant o emissor, i URI de redirecció, a una credencial `entraid` o `oidc` anomenada `<provider>-sso` |
+| Un runner | La seva adreça i TLS, i el seu token o accés, a una credencial del seu tipus, `<runner>-token` o `<runner>-login` |
+| Un magatzem de secrets | La seva adreça i TLS, i el seu token (`<store>-token`) o l'AppID i el certificat de CyberArk (`<store>-appid`) |
+| Un canal de correu | El seu servidor, port i TLS, a la seva credencial `smtp`, o a una de nova anomenada `<channel>-smtp` |
+
+L'actualització a la 7.3.0 fa aquests trasllats una sola vegada. Un registre que ja nomenava una credencial la conserva, i en rep una còpia quan
+un altre registre utilitzava el mateix accés amb un altre servidor. Els registres declarats a la [llavor de configuració](../seed/) es deixen tal com els té la llavor.
+Les credencials de les connexions i dels inicis de sessió només les pot canviar un admin, vegeu [Qui pot canviar una credencial](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/ca/_configure/customization/configuration.md b/i18n/ca/_configure/customization/configuration.md
new file mode 100644
index 0000000..e65a380
--- /dev/null
+++ b/i18n/ca/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Configuració
+parent: Variables d'entorn
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Configuració
+{: .no_toc }
+
+La llavor de configuració, on es desa la configuració, git i ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per decidir d'on surt la configuració: una llavor de configuració, la base de dades, git o plantilles ytt.
+
+---
+
+## Exemple
+
+Aplica una llavor de configuració muntada, comprova-la cada cinc minuts i desa `config.yaml` a la base de dades. A `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Una llavor no vàlida impedeix que el servidor arrenqui. Vegeu [Llavor de configuració](../seed/) per al format del fitxer.
+
+---
+
+## D'on es llegeix config.yaml
+
+Les categories, els rols i les constants surten de `config.yaml` al disc o de la seva còpia a la base de dades, decidit en aquest ordre:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), quan està definida, a l'entorn o a la
+   pestanya **Configuració** de la pàgina de configuració: `1` llegeix la base de dades, `0` llegeix el fitxer.
+2. Si no, l'origen de configuració desat a la base de dades (`file` o `database`), que les instàncies configurades
+   abans de la 6.3.0 van triar a la pàgina de configuració.
+3. Si no, el fitxer: el `config.yaml` del repositori amb **Utilitzar per a la configuració ?** activat, si no el d'un repositori amb
+   **Utilitzar per als formularis ?** activat, i si no el de [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Un `ENABLE_CONFIG_IN_DATABASE` definit explícitament sempre guanya, fins i tot `0` davant d'un `database` desat. Es llegeix cada vegada que
+es carrega la configuració, així que un canvi s'aplica sense reiniciar. La pàgina **Estat** mostra l'origen en ús a la seva pestanya **Informació**.
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/ca/_configure/customization/features.md b/i18n/ca/_configure/customization/features.md
new file mode 100644
index 0000000..83f5d98
--- /dev/null
+++ b/i18n/ca/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Funcions
+parent: Variables d'entorn
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Funcions
+{: .no_toc }
+
+El dissenyador, MCP, el xat, la validació del llançament, la llista de tasques, les mètriques, l'API d'AWX i el registre de consultes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per activar o desactivar parts opcionals de l'aplicació.
+
+---
+
+## Exemple
+
+Serveix el servidor MCP per a agents d'IA i imposa les regles de validació del formulari a cada llançament. Al `.env` del projecte compose:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` i `ENABLE_CHAT` s'apliquen sense reiniciar: es llegeixen a cada petició, així que les pots activar a la
+pàgina de configuració. Mentre una està desactivada, el seu endpoint (`/api/v2/mcp` o `/api/v2/chat`) respon `404`.
+
+Executa primer `LAUNCH_VALIDATION=log` durant un temps: registra el que `enforce` rebutjaria, sense rebutjar-ho. Vegeu [MCP](../mcp/)
+i [Registrar i imposar](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/ca/_configure/customization/index.md b/i18n/ca/_configure/customization/index.md
new file mode 100644
index 0000000..14205d5
--- /dev/null
+++ b/i18n/ca/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Variables d'entorn
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Variables d'entorn
+{: .no_toc }
+
+Configura AnsibleForms amb variables d'entorn
+{: .fs-6 .fw-300 }
+
+---
+
+Per a administradors que despleguen AnsibleForms: les variables d'entorn que llegeix el servidor, agrupades per tema.
+
+AnsibleForms s'ajusta amb variables d'entorn, tant si s'executa amb Docker Compose, a Kubernetes o des del codi font.
+
+---
+
+## D'on surten els valors
+
+El servidor llegeix cada variable de la primera d'aquestes fonts que la defineix, així que un valor més amunt a la llista sempre guanya:
+
+1. **L'entorn del procés**: `environment:` i `env_file:` a docker-compose (el `.env` del projecte es passa així),
+   `env` i `envFrom` a Kubernetes, o la shell que arrenca `node`.
+2. **`persistent/.env`**, el fitxer que escriuen les pàgines de configuració (`data/.env` al projecte docker-compose, un altre camí amb
+   `MANAGED_ENV_PATH`). Es llegeix a cada arrencada, també en producció, i mai no sobreescriu una variable que ja està definida.
+3. **`server/.env.<NODE_ENV>`**, per exemple `.env.development`. Només es llegeix quan `NODE_ENV` no és `production` (o amb
+   `FORCE_DOTENV=1`), a la pràctica quan s'executa [des del codi font](../installation/from-source.html) en mode de desenvolupament.
+4. **El valor predeterminat integrat**, que apareix a les taules de cada grup.
+
+Les pàgines de configuració, a **Configuració > General**, mostren el valor vigent i desen els canvis a `persistent/.env`. Moltes variables
+s'apliquen tan bon punt es desen; les altres es desen però necessiten un reinici, i la pàgina les llista després de desar. Una variable definida a
+l'entorn del procés no s'hi pot canviar: la pàgina la mostra com a *Definit a l'entorn, així que no es pot canviar aquí.*
+Algunes variables, com ara `ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET`, no es poden canviar mai des de la pàgina.
+
+Les variables que llegeix un RTE, com ara `AF_ROLE`, `RTE_MODE`, `APP_URL` o `RTE_MAX_JOBS`, no són a les pàgines de configuració: l'aplicació
+no les utilitza, així que defineix-les a l'entorn on s'executa l'RTE. Les variables `RTE_*` que llegeix la mateixa aplicació,
+`RTE_QUEUE_MINUTES` i `RTE_FILES_MAX_MB`, són l'excepció i continuen a les pàgines. Quatre variables de l'RTE, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` i `RTE_DRAIN_SECONDS`, es poden definir per a cada RTE a la seva pàgina de runner, on un valor guanya a la
+variable (vegeu [La configuració d'un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Amb [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` les pàgines només mostren els valors i el desament es rebutja. Fes-lo servir
+quan l'entorn es declara en un manifest, tal com es descriu a [Edició i auditoria](../seed/environment-and-audit.html).
+
+La [llavor de configuració](../seed/) no defineix cap variable d'entorn. Declara objectes que es desen a la base de dades, i les
+referències `${ENV_VAR}` que conté es resolen a partir de l'entorn del servidor en execució.
+
+Algunes variables només es llegeixen de l'entorn i no són a les taules: `MANAGED_ENV_PATH` i `FORCE_DOTENV`, descrites
+més amunt, i les variables de proxy del sistema `HTTPS_PROXY` i `NO_PROXY` (també es llegeixen en minúscules). Un RTE sortint truca a l'aplicació a través de
+`HTTPS_PROXY`, i un RTE entrant hi envia la seva crida de registre, tret que el host de l'aplicació sigui a `NO_PROXY` (noms de host,
+sufixos `.domain`, o `*` per a tots els hosts).
+
+Les variables marcades amb <span class="af-badge af-badge-secret">Secret</span> contenen una contrasenya, un token o una clau: mantén-les fora del control
+de versions, per exemple en un Secret de Kubernetes o en un fitxer `.env` que no es faci commit.
+
+---
+
+## En aquesta secció
+
+Les variables s'agrupen per tema, amb una pàgina per grup:
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Altres variables
+
+Les variables següents encara no estan assignades a cap grup:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/ca/_configure/customization/logging.md b/i18n/ca/_configure/customization/logging.md
new file mode 100644
index 0000000..c377565
--- /dev/null
+++ b/i18n/ca/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Registre
+parent: Variables d'entorn
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Registre
+{: .no_toc }
+
+Nivells de registre, fitxers, syslog i colors de la consola
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per ajustar quant es registra, on van els fitxers de registre, o per mostrar les marques de temps a la teva pròpia zona horària.
+
+---
+
+## Exemple
+
+Registra més als fitxers que a la consola, i mostra les marques de temps del registre i de les tasques en hora d'Amsterdam.
+Al `.env` del projecte compose:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Els servidors syslog ja no es configuren aquí: afegeix-los a **Configuració > Connexions > Syslog**, vegeu [Registres](../production/logs.html#syslog).
+Les variables `LOG_SYSLOG_*` de sota estan obsoletes des de la 7. La primera arrencada que troba `LOG_SYSLOG_HOST` definida les importa
+una sola vegada com el servidor syslog `syslog`, que rep el registre del servidor, i a partir d'aleshores les ignora.
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/ca/_configure/customization/paths.md b/i18n/ca/_configure/customization/paths.md
new file mode 100644
index 0000000..e20b54a
--- /dev/null
+++ b/i18n/ca/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Camins
+parent: Variables d'entorn
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Camins
+{: .no_toc }
+
+On són la configuració, els formularis, els playbooks, els fitxers pujats i les còpies de seguretat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per desar part de les dades en un altre volum, per exemple les còpies de seguretat i els fitxers pujats en un emmagatzematge més gran o més barat.
+
+---
+
+## Exemple
+
+Còpies de seguretat i fitxers pujats en un volum a part, i la resta de les dades a la carpeta persistent habitual. A `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Un camí nou només s'aplica als fitxers nous: el que ja és a la carpeta antiga no es mou, així que copia-ho tu mateix.
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/ca/_configure/customization/retention.md b/i18n/ca/_configure/customization/retention.md
new file mode 100644
index 0000000..68c4c07
--- /dev/null
+++ b/i18n/ca/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Còpies de seguretat i retenció
+parent: Variables d'entorn
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Còpies de seguretat i retenció
+{: .no_toc }
+
+Les ordres de còpia de seguretat, i quant de temps es conserven les còpies, les tasques i els registres d'auditoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per controlar quant d'historial conserva la base de dades i quantes còpies de seguretat es queden al disc.
+
+---
+
+## Exemple
+
+Conserva les tasques acabades durant 90 dies i el rastre d'auditoria durant dos anys. Al `.env` del projecte compose:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Una tasca diària elimina les tasques acabades més antigues que això a les 2:30 de la matinada i les entrades d'auditoria a les 3:30. Una tasca en execució, o una que espera
+aprovació, no s'elimina mai. Totes dues variables s'apliquen sense reiniciar quan es canvien a la pàgina de configuració.
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/ca/_configure/customization/security.md b/i18n/ca/_configure/customization/security.md
new file mode 100644
index 0000000..cb0a7ad
--- /dev/null
+++ b/i18n/ca/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Variables de seguretat
+parent: Variables d'entorn
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Variables de seguretat
+{: .no_toc }
+
+Tokens, xifratge, hosts REST de sortida, emmascarament i els antics ajustos VAULT_*
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables per definir els teus propis secrets de token i de xifratge, i per limitar què poden cridar i mostrar els formularis.
+
+---
+
+## Exemple
+
+Els teus propis secrets, crides REST limitades a una API i a una xarxa interna, i una clau emmascarada més. Al `.env` del projecte compose:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Defineix `ENCRYPTION_SECRET` abans de desar la primera credencial. Des de la 7.3.0, definir-la o canviar-la torna a xifrar tots els secrets
+desats a la següent arrencada, amb `ENCRYPTION_SECRET_PREVIOUS` indicant la clau antiga quan era teva, vegeu
+[Canviar el secret de xifratge](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## Crides REST i jq
+
+Des de la 7.3.0 les funcions auxiliars REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) comproven el
+certificat de l'endpoint que criden, com qualsevol altra connexió; fins a la 7.2.0 no ho feien mai. S'hi apliquen tres ajustos:
+
+| Variable | Predeterminat | Efecte |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` omet la comprovació del certificat: només per a endpoints amb un certificat autosignat |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Quant espera una crida REST una resposta abans de fallar per temps d'espera esgotat |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Quant pot funcionar un filtre jq abans que s'aturi; la sortida de jq també està limitada a 64 MB |
+
+Totes tres tenen efecte en desar-les, sense reiniciar. Per a un endpoint el certificat del qual està signat per una CA privada, mantén la comprovació activada
+i dona aquesta CA a Node.js: defineix `NODE_EXTRA_CA_CERTS` amb un fitxer PEM que la contingui a l'entorn de l'aplicació i reinicia l'aplicació.
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/ca/_configure/customization/server.md b/i18n/ca/_configure/customization/server.md
new file mode 100644
index 0000000..6470178
--- /dev/null
+++ b/i18n/ca/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Servidor i base de dades
+parent: Variables d'entorn
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Servidor i base de dades
+{: .no_toc }
+
+El servidor web, la connexió a MySQL, el compte d'admin i el que executa cada procés (AF_ROLE i les variables RTE_*)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Canvia aquestes variables quan l'aplicació s'executa darrere d'un proxy invers, en un altre port o contra una base de dades de fora del projecte compose.
+
+---
+
+## Exemple
+
+Darrere d'un proxy invers que termina el TLS, sota `/ansibleforms`, amb un MySQL extern. A `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Aquestes línies substitueixen les línies `DB_*` i `PORT` que el fitxer compose ja hi té, que guanyen als mateixos noms de `.env`. Treu
+el servei `mysqldb` i el `depends_on` que l'espera, i mapeja el port 8000 a `ports`. La part del proxy es descriu a la
+pàgina [Proxy invers](../production/reverse-proxy.html).
+
+---
+
+## Variables
+
+Totes les variables d'aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/ca/_configure/disclaimer.md b/i18n/ca/_configure/disclaimer.md
new file mode 100644
index 0000000..77ba0ac
--- /dev/null
+++ b/i18n/ca/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Avís legal
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Avís legal
+{: .no_toc }
+
+Condicions que cada usuari accepta una vegada abans d'utilitzar l'aplicació, registrades amb qui ha acceptat quina versió i quan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: demana a tots els usuaris que acceptin unes condicions d'ús, a **Configuració > Accés > Avís legal**, amb l'opció de rol `showSettings`.
+
+Des de la 7.3.0 la pàgina llista totes les versions de l'avís legal, i cada versió s'obre en una pàgina pròpia amb les seves acceptacions.
+Fins a la 7.2, la pàgina tenia en canvi tres pestanyes (**General**, **Versions** i **Acceptacions**); l'actualització conserva totes les versions.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [General](disclaimer/general.html) | La llista de versions, com afegir-ne una i com activar la que accepten els usuaris |
+| [Versions](disclaimer/versions.html) | La pàgina d'una versió, i com canviar-ne el text com a correcció o tornar-lo a demanar a tothom |
+| [Acceptacions](disclaimer/acceptances.html) | Qui ha acceptat quina versió, i com tornar-ho a demanar als usuaris que triïs |
+
+
+---
+
+## Què veuen els usuaris
+
+Amb una versió activada, tots els usuaris que inicien sessió la reben en un diàleg abans de res més, admins inclosos:
+
+1. En llegeixen el títol i el text.
+2. Marquen la casella i després fan clic a **Accepta**. **Rebutja**, en vermell, els tanca la sessió.
+
+Des de la 7.3.0 la pàgina de darrere del diàleg es veu desenfocada fins que responen.
+
+Un usuari accepta cada versió una sola vegada: no se li torna a demanar al següent inici de sessió, només quan arriba una versió nova, quan
+un admin desa un text canviat amb [Demana-ho a tothom de nou](disclaimer/versions.html#changing-the-text), o quan un admin fa servir
+[Torna a demanar](disclaimer/acceptances.html#asking-users-again) sobre la seva acceptació.
+
+Fins que no l'accepten, l'API respon a cada crida de la seva sessió amb l'estat `403` i el codi `disclaimer_required`,
+excepte les crides sota `/api/v2/disclaimer` i `/api/v2/profile`, i els esdeveniments en directe que segueix el navegador.
+A un [token d'API](profile/api-token.html) no se li demana mai, ja que un script no té ningú que hi faci clic.
+
diff --git a/i18n/ca/_configure/disclaimer/acceptances.md b/i18n/ca/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..bc92bf4
--- /dev/null
+++ b/i18n/ca/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Acceptacions
+parent: Avís legal
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Acceptacions
+{: .no_toc }
+
+Qui ha acceptat quina versió, i com tornar-ho a demanar als usuaris que triïs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Qui l'ha acceptat
+
+Cada acceptació es registra amb l'usuari i la versió, i la pestanya **Acceptacions** de la pàgina d'una versió les llista, la més recent primer:
+
+| Columna | Significat |
+|---|---|
+| **Usuari** | El nom d'usuari |
+| **Inici de sessió** | Com ha iniciat sessió: Local, LDAP, Microsoft Entra ID o OpenID Connect |
+| **Acceptat** | Quan |
+| **Adreça IP** | Des d'on |
+| **Navegador** | El seu navegador |
+
+---
+
+## Tornar-ho a demanar
+
+Des de la 7.3.0 es pot demanar als usuaris que triïs que tornin a acceptar una versió, sense demanar-ho a tothom.
+
+**Torna a demanar**, al menú d'una fila o sobre les files marcades a la llista, esborra aquestes acceptacions després d'una confirmació: aquests usuaris
+tornen a rebre l'avís legal a la seva propera petició, sense haver de tornar a iniciar sessió. La llista també es pot exportar, com qualsevol taula.
+
+El [registre d'auditoria](../production/logs.html#audit-trail) també registra cada acceptació, cada rebuig i cada canvi de l'avís legal.
diff --git a/i18n/ca/_configure/disclaimer/general.md b/i18n/ca/_configure/disclaimer/general.md
new file mode 100644
index 0000000..f76d1cc
--- /dev/null
+++ b/i18n/ca/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: General
+parent: Avís legal
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# General
+{: .no_toc }
+
+La llista de versions, com afegir-ne una i com activar la que accepten els usuaris
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La llista
+
+Des de la 7.3.0, **Configuració > Accés > Avís legal** és una llista de les versions de l'avís legal, una per cada text tal com es va acceptar:
+
+| Columna | Significat |
+|---|---|
+| **Activat** | Si aquesta és la versió que accepten els usuaris; com a màxim n'hi ha una d'activada |
+| **Versió** | El seu número, comptant des d'1 |
+| **Títol** | El títol del seu diàleg |
+| **Publicat per** | Qui l'ha afegida |
+| **Publicat** | Quan |
+| **Acceptacions** | Quants usuaris l'han acceptada |
+
+Un clic en una fila, o **Edita** al menú de la fila, obre la [pàgina de la versió](versions.html). El menú també té **Activa** o **Desactiva**, i **Suprimeix**.
+
+---
+
+## Afegir una versió
+
+**Afegeix avís** obre un diàleg per a una versió nova, amb el número següent, que no queda activada fins que l'activis:
+
+| Camp | Significat |
+|---|---|
+| **Títol** | El títol del diàleg, com ara Condicions d'ús |
+| **Text** | El que accepten els usuaris, com a màxim 20000 caràcters. Text pla: es conserven els salts de línia. |
+| **Casella** | El que marquen els usuaris abans de poder acceptar, al principi "He llegit i accepto aquestes condicions." |
+
+Tots tres són obligatoris. La versió activada fins aleshores continua sent la que accepten els usuaris, així que pots preparar un text nou per endavant.
+
+---
+
+## Activar una versió
+
+**Activa** al menú d'una fila, o l'interruptor **Activat** a la pàgina de la versió, converteix aquesta versió en la que accepten els usuaris i desactiva
+les altres.
+
+Als usuaris que ja havien acceptat aquesta versió no se'ls torna a demanar, així que pots tornar a activar una versió anterior sense demanar-ho a tothom.
+**Desactiva** a la versió activada desactiva l'avís legal fins que es torni a activar una versió; les versions i les acceptacions es conserven.
+Suprimir una versió també en suprimeix les acceptacions, i suprimir l'activada desactiva l'avís legal.
diff --git a/i18n/ca/_configure/disclaimer/versions.md b/i18n/ca/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..2fb47e1
--- /dev/null
+++ b/i18n/ca/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versions
+parent: Avís legal
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versions
+{: .no_toc }
+
+La pàgina d'una versió, i com canviar-ne el text com a correcció o tornar-lo a demanar a tothom
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La pàgina d'una versió
+
+Des de la 7.3.0 cada versió té una pàgina pròpia, a `/settings/disclaimer/<version>`, amb dues pestanyes:
+
+| Pestanya | Què conté |
+|---|---|
+| **Detalls** | El títol, el text i el text de la casella, i l'interruptor **Activat**, que es desa a l'instant |
+| **Acceptacions** | Qui ha acceptat aquesta versió, vegeu [Acceptacions](acceptances.html) |
+
+**Previsualització** mostra el diàleg tal com el veuran els usuaris, i **Suprimeix** elimina la versió juntament amb les seves acceptacions. El quadre de cerca
+de sobre les pestanyes cerca a totes dues alhora: els camps que coincideixen a **Detalls** i les files que coincideixen a **Acceptacions**.
+
+---
+
+## Canviar el text
+
+**Desa** sobre un títol, un text o un text de la casella modificats que els usuaris ja havien acceptat pregunta **Tornar-ho a demanar a tothom?**:
+
+| Resposta | Què passa |
+|---|---|
+| **Demana-ho a tothom de nou** | S'esborren les acceptacions d'aquesta versió, i cada usuari la torna a acceptar a la seva propera petició |
+| **Mantén com a correcció** | El text es reescriu, per exemple per corregir una errada, i les acceptacions continuen comptant: no es torna a demanar a ningú |
+
+Una versió que encara no ha acceptat ningú es desa sense preguntar. Per conservar el text acceptat, [afegeix una versió nova](general.html#adding-a-version) i activa-la.
diff --git a/i18n/ca/_configure/notification-channels.md b/i18n/ca/_configure/notification-channels.md
new file mode 100644
index 0000000..798aafd
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Canals de notificació
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Canals de notificació
+{: .no_toc }
+
+Envia sol·licituds d'aprovació i notificacions de tasques per correu, a Slack, Microsoft Teams, Telegram o a qualsevol webhook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: afegeix els servidors de correu i els canals de xat als quals els formularis envien les seves notificacions i aprovacions.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Correu](notification-channels/mail.html) | Els servidors SMTP, el predeterminat i el seu inici de sessió |
+| [Slack i Microsoft Teams](notification-channels/slack-and-teams.html) | El webhook d'un canal de Slack o de Teams |
+| [Telegram](notification-channels/telegram.html) | Un bot que publica en un xat de Telegram |
+| [Webhook](notification-channels/webhook.html) | Una petició JSON a qualsevol endpoint HTTP |
+| [Utilitzar canals en un formulari](notification-channels/in-a-form.html) | Com nomenar canals a les notificacions i a les aprovacions |
+| [Provar un canal](notification-channels/testing.html) | Envia una prova, i què demostra |
+
+
+---
+
+## Com funciona
+
+Un **canal de notificació** és un lloc on van les notificacions, que s'afegeix a **Connexions > Notificacions**. Cada canal és
+d'un d'aquests tipus:
+
+| Tipus | Què envia |
+|---|---|
+| Correu | Correu a través d'un servidor SMTP: sol·licituds d'aprovació i notificacions de tasques. |
+| Slack | Un missatge en un canal de Slack, mitjançant el seu webhook d'entrada, amb un botó que porta a la tasca. |
+| Microsoft Teams | Una targeta en un canal de Teams, mitjançant un webhook de Workflows, amb un botó que porta a la tasca. |
+| Telegram | Un missatge d'un bot en un xat de Telegram, amb un enllaç a la tasca. |
+| Webhook | Una petició JSON a qualsevol endpoint HTTP, construïda a partir d'una plantilla. |
+
+Un formulari nomena els seus canals a les seves [notificacions](forms/notifications.html) i a la seva [aprovació](forms/approval.html),
+amb `channels:`. Una notificació que no es pot enviar s'escriu al registre; mai no fa fallar la tasca ni l'aprovació.
+
+---
+
+## La pàgina de notificacions
+
+La pàgina de **Connexions > Notificacions** llista tots els canals amb aquestes columnes:
+
+| Columna | Significat |
+|---|---|
+| Activat | Si se li envien notificacions, vegeu [Utilitzar canals en un formulari](notification-channels/in-a-form.html). |
+| Nom | Com el nomenen els formularis a `channels:`. |
+| Tipus | Correu, Slack, Microsoft Teams, Telegram o Webhook. El canal de correu predeterminat mostra una etiqueta **Predeterminat** després del seu tipus. |
+| Descripció | Per a què serveix el canal. |
+
+**Afegeix canal de notificació** obre un diàleg: **Canal** (nom i descripció), **Tipus** i després els passos del tipus
+triat. El tipus es fixa quan es crea el canal i ja no canvia. Una fila obre la pàgina pròpia del canal, amb els mateixos passos com a
+pestanyes després de **Detalls**, i **Envia una prova**, **Suprimeix** i **Desa** a dalt a la dreta. El menú de la fila ofereix
+**Edita**, **Activa** o **Desactiva** (segons correspongui), **Fes-lo predeterminat** (correu), **Envia una prova** i **Suprimeix**.
+
+La pestanya **Detalls** de la pàgina d'un canal conté l'interruptor **Activat**, que es desa a l'instant, i per al correu l'interruptor
+**Predeterminat**, que es desa amb **Desa**.
+
+Un usuari que obre aquestes pàgines amb `showConnectionsSettings` però sense el rol d'admin no pot triar una credencial que només
+pot nomenar un admin, vegeu [Qui pot canviar una credencial](credentials.html#who-may-change-a-credential). Quan un usuari així canvia
+on envia un canal (la url d'un webhook o la seva comprovació del certificat, l'adreça de la Bot API de Telegram), el canal perd la
+credencial que nomenava, tret que en triï una en el mateix canvi.
+
+Un canal declarat a la [llavor de configuració](seed/) és només de lectura en aquesta pàgina, i tot i així es pot provar.
+
diff --git a/i18n/ca/_configure/notification-channels/in-a-form.md b/i18n/ca/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..b6816e4
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Utilitzar canals en un formulari
+parent: Canals de notificació
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Utilitzar canals en un formulari
+{: .no_toc }
+
+Com nomenar canals a les notificacions i a les aprovacions
+{: .fs-6 .fw-300 }
+
+Els formularis nomenen els canals pel seu nom, a `notifications` per a l'estat i els esdeveniments de la tasca, i a `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- Els canals de xat i de webhook reben un missatge breu (el formulari, la tasca, què ha passat) amb un enllaç a la tasca; en una
+  aprovació, la pàgina de la tasca és on s'aprova o es rebutja.
+- Un canal de **correu** de la llista envia el correu habitual a `recipients` (les adreces de `notifications` d'una aprovació) a través
+  d'aquest servidor en lloc del predeterminat.
+- Un nom que no existeix, o un canal de xat o de webhook desactivat, s'omet i s'indica al registre.
+- Un canal de **correu** desactivat no s'omet: el correu surt pel canal de correu predeterminat, i el
+  registre ho indica.
diff --git a/i18n/ca/_configure/notification-channels/mail.md b/i18n/ca/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..b23e2e8
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Correu
+parent: Canals de notificació
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Correu
+{: .no_toc }
+
+Els servidors SMTP, el predeterminat i el seu inici de sessió
+{: .fs-6 .fw-300 }
+
+Un canal de correu és un servidor SMTP. En pots tenir diversos; el marcat com a **Predeterminat** és el servidor amb què l'aplicació envia el seu
+correu quan un formulari no nomena cap canal de correu. El primer canal de correu passa a ser el predeterminat, i **Fes-lo predeterminat** el canvia.
+
+| Pas | Camp | Significat |
+|---|---|---|
+| Credencials | Credencial | Obligatori. Una credencial **smtp** de [Connexions > Credencials](../credentials.html): el servidor de correu, el seu port i TLS, i l'inici de sessió. Per a un relay sense inici de sessió, una credencial smtp sense usuari. |
+| Remitent | Remitent | L'adreça del remitent que veuen els destinataris. |
+
+L'interruptor **Predeterminat** de la pestanya **Detalls** de la pàgina d'un canal de correu el converteix en el predeterminat, igual que **Fes-lo predeterminat**.
+Els ajustos de correu de la llavor de configuració s'utilitzen mentre cap canal de correu no sigui el predeterminat, o mentre el predeterminat estigui desactivat.
diff --git a/i18n/ca/_configure/notification-channels/slack-and-teams.md b/i18n/ca/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..ed03d76
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack i Microsoft Teams
+parent: Canals de notificació
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack i Microsoft Teams
+{: .no_toc }
+
+El webhook d'un canal de Slack o de Teams
+{: .fs-6 .fw-300 }
+
+Els canals de Slack i de Teams només necessiten l'adreça del webhook del canal:
+
+| Tipus | Adreça del webhook |
+|---|---|
+| Slack | El webhook d'entrada del canal (Slack app > Incoming Webhooks). |
+| Microsoft Teams | El webhook de Workflows del canal ("post to a channel when a webhook request is received"). |
+
+L'adreça és el secret que permet a qualsevol publicar al canal: es desa xifrada i no es torna a mostrar mai un cop desada.
diff --git a/i18n/ca/_configure/notification-channels/telegram.md b/i18n/ca/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..247fff5
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Canals de notificació
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Un bot que publica en un xat de Telegram
+{: .fs-6 .fw-300 }
+
+Un canal de Telegram és un bot que publica en un xat. El seu pas **Credencials** conté el **Token del bot**, i el seu pas **Bot**, la resta:
+
+| Camp | Significat |
+|---|---|
+| Token del bot | Una credencial **api** de [Connexions > Credencials](../credentials.html) la contrasenya de la qual és el token del bot que dona BotFather. |
+| Id del xat | El xat, el grup o el canal on publica el bot; un nombre negatiu per a un grup o un canal. |
+| Adreça de la Bot API | Un servidor Bot API propi; buit per a `api.telegram.org`. |
diff --git a/i18n/ca/_configure/notification-channels/testing.md b/i18n/ca/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..1ed9011
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Provar un canal
+parent: Canals de notificació
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Provar un canal
+{: .no_toc }
+
+Envia una prova, i què demostra
+{: .fs-6 .fw-300 }
+
+**Envia una prova** envia una notificació de prova a través del canal tal com està desat, així que desa abans els teus canvis. També funciona amb un canal
+desactivat. Per a un canal de correu
+el diàleg demana l'adreça on enviar-la; els altres publiquen al seu propi canal. El diàleg mostra si ha funcionat
+i, si no, el motiu.
diff --git a/i18n/ca/_configure/notification-channels/webhook.md b/i18n/ca/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..4b86856
--- /dev/null
+++ b/i18n/ca/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Canals de notificació
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Una petició JSON a qualsevol endpoint HTTP
+{: .fs-6 .fw-300 }
+
+Un canal webhook envia una petició JSON a qualsevol endpoint HTTP. El seu pas **Endpoint** indica on i com, i el seu pas
+**Credencials** conté el **Token bearer**:
+
+| Camp | Significat |
+|---|---|
+| Url | L'adreça a la qual s'envia la petició. |
+| Mètode | `POST` (predeterminat) o `PUT`. |
+| Token bearer | Una credencial **api** de [Connexions > Credencials](../credentials.html) la contrasenya de la qual s'envia com a `Authorization: Bearer <password>`. Buit: sense token. |
+| Comprova el certificat TLS | Activat per defecte; desactiva'l només per a un endpoint amb un certificat autosignat. |
+
+{% raw %}
+El seu pas **Contingut** conté les **Capçaleres**, capçaleres addicionals com un objecte JSON, per exemple `{ "X-Source": "ansibleforms" }`, i el
+**Contingut**, la plantilla JSON del cos. S'emplenen aquests marcadors:
+
+| Marcador | Valor |
+|---|---|
+| `{{title}}` | El títol de la notificació |
+| `{{text}}` | El seu text |
+| `{{status}}` | L'estat de la tasca |
+| `{{event}}` | L'esdeveniment de la tasca |
+| `{{jobId}}` | L'id de la tasca |
+| `{{form}}` | El nom del formulari |
+| `{{user}}` | L'usuari que ha iniciat la tasca |
+| `{{link}}` | L'enllaç a la tasca |
+
+Un marcador que ocupa tota una cadena JSON (`"{{text}}"`) se substitueix pel valor com a JSON; dins d'una cadena més llarga, el seu
+text s'escapa per a JSON. Un marcador desconegut es deixa tal com està escrit. Un contingut buit envia aquesta plantilla:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/ca/_configure/production/backups.md b/i18n/ca/_configure/production/backups.md
new file mode 100644
index 0000000..e0bfdd1
--- /dev/null
+++ b/i18n/ca/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Còpies de seguretat
+parent: En producció
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Còpies de seguretat
+{: .no_toc }
+
+Còpies nocturnes, què contenen, restauracions, i què més cal conservar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Còpies nocturnes
+
+AnsibleForms fa una còpia de seguretat de si mateix cada nit a mitjanit, a la zona horària de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(UTC per defecte). Aquests ajustos la controlen:
+
+| Variable | Predeterminat | Significat |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | On s'escriuen les còpies de seguretat, cadascuna en una carpeta amb marca de temps |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Quantes còpies nocturnes es conserven; `0` les conserva totes |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | L'ordre que bolca la base de dades |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | L'ordre que reprodueix un bolcat en restaurar |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Quant de temps poden durar el bolcat i la restauració |
+
+Els usuaris amb l'opció de rol `allowBackupOps` també poden fer una còpia de seguretat en qualsevol moment a la pàgina **Còpies de seguretat**. La retenció
+només elimina les còpies nocturnes, i només hi compten les còpies amb un bolcat utilitzable, de manera que una sèrie de nits fallides
+mai no fa fora l'última còpia bona.
+
+Abans que una actualització canviï la base de dades, el worker fa primer una còpia de seguretat normal, una per versió, anomenada *Before the upgrade to
+&lt;version&gt;*. Es mostra a la pàgina **Còpies de seguretat** i la retenció nocturna no l'elimina mai. Si falla (no hi ha eina de bolcat,
+no es pot escriure a `BACKUP_PATH`), l'actualització s'atura i n'explica el motiu, de manera que l'aplicació mai no arrenca sobre una base de dades a mig actualitzar.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` actualitza sense còpia de seguretat.
+
+Les ordres poden ser embolcalls com ara `docker exec <container> mysqldump`, si la seva primera paraula existeix localment. Des de la 7.3.0 s'executen
+sense shell: les cometes i `$NAME` de l'entorn de l'ordre funcionen, però `;`, `|`, `&&`, `>` i `<` es rebutgen.
+
+---
+
+## Permisos de la base de dades
+
+El bolcat s'executa com a [`DB_USER`](../customization/server.html#env_DB_USER), i no necessita més permisos que els que necessita la mateixa aplicació:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+El bolcat es fa amb `--no-tablespaces`, de manera que no cal el permís `PROCESS` de tot el servidor, i omet les taules
+que descriuen els processos en execució (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). La restauració el reprodueix amb el mateix usuari.
+La pàgina **Estat** mostra un avís a la comprovació **Usuari de la base de dades** quan l'usuari té permisos sobre totes les bases de dades, com en té `root`.
+
+---
+
+## Què conté una còpia de seguretat
+
+Cada còpia de seguretat és una carpeta sota `BACKUP_PATH`, amb el nom de la seva marca de temps UTC (`YYYYMMDDHHmmss`), que conté:
+
+| Fitxer | Contingut |
+|------|---------|
+| `ansibleforms.sql` | El bolcat de la base de dades `AnsibleForms`: usuaris, grups, credencials, tasques, ajustos, el rastre d'auditoria |
+| `config.yaml` | El fitxer de [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | La carpeta de [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | El fitxer d'entorn que escriuen les pàgines de configuració, sense `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` ni `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | La descripció de la còpia de seguretat |
+
+Una còpia de seguretat el bolcat de la qual falla s'elimina de nou i es registra com a error. La pàgina **Estat** avisa quan no hi ha cap còpia,
+quan la més recent té més de dos dies o quan no té cap bolcat utilitzable, i comprova que l'eina de bolcat existeix.
+
+En canvi, [`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) conserva els punts de restauració del dissenyador (60 dies per defecte).
+
+---
+
+## Restaurar una còpia de seguretat
+
+Restaura des de la [pàgina **Còpies de seguretat**](../gui/administration.html#restore), amb **Crea una còpia de seguretat nova abans de restaurar** marcat. Una restauració:
+
+* reprodueix `ansibleforms.sql`, que substitueix tota la base de dades; des de la 7.3.0 una còpia d'una versió anterior es torna a actualitzar
+  després, com a l'inici d'una versió nova, i s'informa d'un pedaç que falla
+* torna a copiar `config.yaml`, i substitueix la carpeta `forms/` per la de la còpia: des de la 7.3.0 els formularis que no són a la còpia
+  s'eliminen en lloc de conservar-se, els enllaços i el mode de la carpeta es mantenen, i una còpia fallida fa tornar la carpeta enrere
+* **no** restaura `managed.env`, perquè descriu l'amfitrió d'on prové la còpia. El botó **Restaura l'entorn**
+  el torna a posar si es demana, conserva el fitxer actual com a `.env.bak`, i necessita un reinici.
+
+Una còpia de seguretat sense un bolcat utilitzable es rebutja; després d'una restauració interrompuda, corregeix la causa i torna a restaurar.
+
+En un amfitrió nou, defineix el mateix `ENCRYPTION_SECRET` abans de restaurar, o les credencials desades no es podran desxifrar.
+
+---
+
+## Què més cal copiar
+
+La còpia nocturna cobreix la base de dades, la configuració i els formularis, però res més de la carpeta persistent:
+
+* **`ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET`** : mai no són en una còpia de seguretat, a propòsit. Guarda'ls al teu gestor de secrets;
+  sense el secret de xifratge, un bolcat de la base de dades no serveix de res per a les credencials.
+* **les mateixes còpies de seguretat** : són al mateix volum que la instància. Copia `BACKUP_PATH` a un altre amfitrió.
+* **la resta de la carpeta persistent** : playbooks, fitxers pujats, fitxers de variables, repositoris clonats, certificats i registres.
+  Amb el projecte docker-compose, fes una còpia de tota la carpeta `data/`, que també conté la clau SSH, les funcions
+  personalitzades i els rols i les col·leccions d'Ansible.
+
+El contingut que ve de git (repositoris, formularis en un repositori) es pot tornar a clonar, així que la seva còpia importa menys.
diff --git a/i18n/ca/_configure/production/index.md b/i18n/ca/_configure/production/index.md
new file mode 100644
index 0000000..c867188
--- /dev/null
+++ b/i18n/ca/_configure/production/index.md
@@ -0,0 +1,60 @@
+---
+layout: default
+title: En producció
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# En producció
+{: .no_toc }
+
+Publica, fes còpies de seguretat i supervisa una instància de la qual depenen persones
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Abans de posar-la en marxa
+
+Els valors predeterminats posen una instància en marxa ràpidament, però alguns només estan pensats per a una primera ullada. AnsibleForms
+registra un avís `[SECURITY]` en arrencar quan `ENCRYPTION_SECRET` o `ACCESS_TOKEN_SECRET` no estan definides, i la
+pàgina **Estat** informa de les còpies de seguretat, dels ajustos de retenció i del sanejador d'expressions.
+
+---
+
+## Llista de comprovació per a producció
+
+Revisa aquests punts una vegada abans que els usuaris depenguin de la instància, i un altre cop després d'una actualització important:
+
+| Punt | Què cal fer | Detalls |
+|------|------------|---------|
+| Contrasenya de l'admin | Canvia la contrasenya del compte d'admin local | [Enduriment](../security/hardening.html#the-admin-account) |
+| Secret de xifratge | Defineix [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) abans de desar cap credencial | [Secrets i xifratge](../security/secrets.html#the-two-master-secrets) |
+| Secret dels tokens | Defineix [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET), perquè les sessions sobrevisquin a un reinici | [Secrets i xifratge](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Termina el TLS amb el teu propi certificat, no amb el d'exemple | [HTTPS](../security/https.html) |
+| Proxy invers | Publica la instància darrere d'un proxy, opcionalment sota [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Proxy invers](reverse-proxy.html) |
+| Endpoint de l'esquema | Posa [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) a `0` un cop existeix l'esquema | [Enduriment](../security/hardening.html#the-database) |
+| Crides de sortida | Restringeix les expressions REST amb [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Enduriment](../security/hardening.html#expressions-and-outbound-calls) |
+| Funcions opcionals | Deixa MCP i l'assistent de xat desactivats si no els fas servir | [Enduriment](../security/hardening.html#optional-features) |
+| Còpies de seguretat | Comprova que la còpia nocturna funciona, i copia-la fora de l'amfitrió | [Còpies de seguretat](backups.html) |
+| Retenció | Decideix quant de temps es conserven les tasques i les entrades d'auditoria | [Registres](logs.html#retention) |
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina; la protecció de la instància es tracta a [Seguretat](../security/):
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Proxy invers](reverse-proxy.html) | Publicar AnsibleForms darrere de Nginx, Traefik o Apache, a l'arrel o sota un subcamí |
+| [Còpies de seguretat](backups.html) | Còpies nocturnes, què contenen, restauracions, i què més cal conservar |
+| [Registres](logs.html) | Fitxers de registre, syslog, el rastre d'auditoria, i la retenció de tasques i entrades d'auditoria |
+| [Escalat](scaling.html) | Diversos nodes d'aplicació amb un worker; l'RTE té la seva pròpia secció, [Entorns d'execució](../rte/) |
+| [Supervisió](monitoring.html) | Sondes de salut, mètriques de Prometheus i la pàgina Estat |
+
diff --git a/i18n/ca/_configure/production/logs.md b/i18n/ca/_configure/production/logs.md
new file mode 100644
index 0000000..7b2e391
--- /dev/null
+++ b/i18n/ca/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Registres
+parent: En producció
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Registres
+{: .no_toc }
+
+Fitxers de registre, syslog, el rastre d'auditoria, i quant de temps es conserven les tasques i les entrades d'auditoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fitxers de registre
+
+AnsibleForms escriu dos registres amb rotació diària a [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), comprimeix els dies anteriors i els conserva durant [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+(30 per defecte, `0` conserva tots els fitxers; un canvi a la pàgina de configuració s'aplica a l'instant):
+
+* `ansibleforms.<date>.log` : tot el que és de nivell [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) o superior
+* `ansibleforms.errors.<date>.log` : només els errors
+
+La consola, que es llegeix amb `docker logs` o `kubectl logs`, té el seu propi nivell,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Tots dos són `notice` per defecte, que és l'adequat per a
+producció; fes servir `info` o `debug` només mentre investigues un problema, i deixa
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) desactivat. Els nivells es poden canviar a
+les pàgines de configuració sense reiniciar, i la pàgina **Registre del servidor** mostra el registre als usuaris amb l'opció `showLogs`.
+
+---
+
+## Línies JSON
+
+Per a un col·lector de registres com ara Loki, ELK o Splunk, posa [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) a `json`. Cada
+línia, a la consola i als fitxers, és llavors un objecte JSON en lloc de `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Camp | Contingut |
+|-------|---------|
+| `time` | L'hora, en ISO 8601 UTC |
+| `level` | El nivell de registre |
+| `message` | El missatge |
+| `requestId` | La petició a la qual pertany la línia, quan s'ha escrit mentre se'n servia una |
+| `role` | El rol del procés, [`AF_ROLE`](scaling.html), o `all` quan no està definit |
+| `host` | El nom de host de la màquina o del contenidor on s'executa el procés |
+
+Cada petició rep un id: la capçalera `X-Request-Id` que ha enviat un proxy invers, o un de nou. Es retorna a la capçalera
+`X-Request-Id` de la resposta i el porten totes les línies escrites mentre se serveix la petició (com a `[req <id>]` a les línies de text),
+de manera que una petició es pot seguir pel registre i relacionar amb les del proxy. Un canvi a la pàgina de configuració s'aplica a l'instant.
+
+---
+
+## Syslog
+
+Els servidors syslog es gestionen a **Configuració > Connexions > Syslog**, de manera que un servidor syslog o un SIEM rep el registre a mesura que s'escriu.
+Pots afegir diversos servidors, i cadascun té els seus propis ajustos:
+
+| Ajust | Què fa |
+|---------|--------------|
+| Activat | Només els servidors activats reben alguna cosa, de manera que un servidor es pot aturar sense suprimir-lo; **Activa** i **Desactiva** al seu menú de fila també el canvien |
+| Protocol | `udp4` (predeterminat), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` o `unix-connect` |
+| Amfitrió i port | El servidor al qual s'envia, port `514` per defecte; un protocol `unix` pren en canvi un camí de sòcol |
+| Rep | El registre del servidor, les entrades d'auditoria, o tots dos (el predeterminat per a un servidor nou) |
+| Nivell | El nivell més baix del registre del servidor que rep, `info` per defecte; les entrades d'auditoria s'envien sempre |
+| Format | `BSD` (RFC 3164, el predeterminat) o `RFC 5424` |
+
+Un canvi s'aplica a tots els nodes sense reiniciar, i la pàgina del servidor té un botó que li envia un missatge de prova.
+Un servidor al qual no es pot arribar mai no atura l'aplicació: l'error s'escriu a la consola.
+
+Des de la 7.3.0 els servidors syslog necessiten tots els permisos de configuració, l'opció de rol [`showSettings`](../config/roles.html#role-options):
+l'accés només a la configuració de connexions no n'hi ha prou, ja que un servidor syslog rep el registre del servidor i les entrades d'auditoria.
+
+Les variables `LOG_SYSLOG_*` de versions anteriors estan obsoletes des de la 7. La primera arrencada que troba
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) definida les importa una sola vegada com el servidor `syslog`,
+que rep el registre del servidor com abans, i a partir d'aleshores les ignora. Treu-les de l'entorn després d'aquesta primera
+arrencada, i gestiona el servidor a la pàgina de configuració.
+
+---
+
+## Rastre d'auditoria
+
+La pàgina **Registre d'auditoria** (a **Configuració > Registres**) registra qui ha canviat què, cosa que els fitxers de registre no responen bé.
+Hi queda registrat:
+
+* cada canvi fet a través de l'API (`POST`, `PUT`, `PATCH`, `DELETE`), inclosos els intents rebutjats amb 401 o 403
+* els inicis de sessió, amb el nom d'usuari que s'ha provat
+* els esdeveniments de la mateixa aplicació, com ara les còpies de seguretat nocturnes, les còpies eliminades, les tasques purgades i les aplicacions de la llavor de configuració
+
+Cada entrada té la seva hora, l'actor (un usuari, o la mateixa aplicació per a les seves pròpies tasques), l'adreça IP del client,
+l'acció, el seu objectiu i el seu resultat: `success`, `failure` o `denied`. La pàgina filtra per l'actor, l'acció i
+el resultat, i la poden obrir els usuaris amb l'opció de rol `showSettings`.
+
+L'adreça IP és la que veu AnsibleForms, que és la del proxy quan s'executa darrere d'un. Posa
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) al nombre o a les adreces dels teus proxies, i AnsibleForms
+registra en canvi l'adreça del client que el proxy indica a `X-Forwarded-For`; vegeu [Proxy invers](reverse-proxy.html).
+
+Per conservar el rastre d'auditoria fora de la instància, per a un SIEM, afegeix un servidor syslog que rebi les entrades d'auditoria (vegeu
+[Syslog](#syslog)). Cada entrada s'envia en el moment que es produeix, com una línia `audit {...}` amb l'entrada en JSON, sigui quin sigui el
+nivell del servidor. La retenció de més avall no elimina la còpia de syslog, ni la substitueix una restauració de la base de dades.
+
+---
+
+## Retenció
+
+Dues tasques diàries amb un ajust eviten que la base de dades creixi sense límit:
+
+| Variable | Predeterminat | S'executa a les | Elimina |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Les entrades d'auditoria més antigues que això |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (ho conserva tot) | 2:30 | Les tasques acabades més antigues que això, amb la seva sortida |
+
+`0` ho conserva tot en tots dos casos. Dues tasques diàries més no tenen cap ajust: a les 3:00 s'eliminen els refresh tokens desats de més de 30 dies i
+les revocacions de tokens caducades, i a les 4:00 les [tasques desades](../jobs/stored-jobs.html) que han passat la seva caducitat.
+Les hores són a la zona horària de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), i les executa el worker.
+
+La sortida de les tasques sol ser la taula que creix més de pressa: la pàgina **Estat** n'indica la mida
+i avisa quan passa d'1 GB sense cap retenció definida. Les tasques en execució i les que esperen aprovació no s'eliminen mai.
+Decideix una retenció de tasques que s'ajusti als teus requisits d'auditoria, i conserva el rastre d'auditoria almenys el mateix temps.
diff --git a/i18n/ca/_configure/production/monitoring.md b/i18n/ca/_configure/production/monitoring.md
new file mode 100644
index 0000000..dc8f4c8
--- /dev/null
+++ b/i18n/ca/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Supervisió
+parent: En producció
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Supervisió
+{: .no_toc }
+
+Sondes de salut per a un balancejador de càrrega o Kubernetes, mètriques de Prometheus i la pàgina Estat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sondes de salut
+
+Dos endpoints indiquen a un balancejador de càrrega, a un healthcheck de contenidor o a Kubernetes si un procés pot rebre trànsit.
+Cap dels dos no necessita iniciar sessió, i cap dels dos no retorna res sobre la configuració:
+
+| Endpoint | Respon | Fes-lo servir per a |
+|----------|---------|------------|
+| `/api/v2/live` | `200` amb `{"status":"live"}` mentre el procés s'executa | Una sonda de liveness: reinicia el procés quan deixa de respondre |
+| `/api/v2/ready` | `200` amb `{"status":"ready"}`, o `503` amb `{"status":"not ready","reason":"..."}` | Una sonda de readiness: envia trànsit només als processos preparats |
+
+Un procés està preparat quan es compleix tot això:
+
+* no s'està aturant (`stopping`)
+* la base de dades respon (`database unreachable`)
+* l'esquema existeix (`schema not provisioned`) i és complet, amb totes les taules, columnes i índexs d'aquesta versió
+  (`schema not upgraded`); aquesta última comprovació es desa en memòria cau durant 30 segons, de manera que una sonda cada pocs segons continua sent barata
+
+Sota un [`BASE_URL`](../customization/server.html#env_BASE_URL) els camins comencen per aquest valor, per exemple
+`/ansibleforms/api/v2/ready`. Un entorn d'execució (RTE) respon les mateixes sondes a `/live` i `/ready`, sense la
+comprovació de completesa de l'esquema; no està preparat mentre buida les seves tasques en aturar-se, de manera que no se li envia cap tasca nova. Un RTE sortint
+tampoc no està preparat (`not connected to the app`) fins que el seu sòcol cap a l'aplicació està obert.
+Un procés iniciat amb `AF_ROLE=worker` no té interfície web: només respon `/api/v2/version` i `/health` per al healthcheck
+del seu contenidor. Vegeu [Escalat](scaling.html) per als rols.
+
+---
+
+## Mètriques de Prometheus
+
+Posa a [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) una cadena aleatòria llarga per servir mètriques de Prometheus.
+Un procés que serveix l'aplicació web respon a `/api/v2/metrics`, i un RTE a `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Sense `METRICS_TOKEN` els endpoints responen `404`, com si no existissin, i una petició sense la capçalera
+`Authorization: Bearer <token>` correcta rep `401`. Cada procés informa de les seves pròpies xifres, així que fes scrape de cadascun:
+
+| Mètrica | Què mesura |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | El procés: CPU, memòria, retard del bucle d'esdeveniments, recollida d'escombraries |
+| `af_http_requests_total{route,method,status}` | Les peticions servides |
+| `af_http_request_duration_seconds{route}` | Quant de temps han trigat |
+| `af_jobs{status}` | Tasques en execució (`running`) o pendents d'aprovació (`approve`) ara mateix |
+| `af_jobs_ended_24h{status}` | Tasques que han acabat les últimes 24 hores, per estat |
+| `af_nodes{role,alive}` | Els processos registrats a la base de dades, per rol, vius o no |
+| `af_login_failures_total`, `af_login_lockouts_total` | Inicis de sessió fallits i bloquejos de comptes |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | En un RTE: els playbooks que executa ara, i quants en pot executar alhora |
+| `af_rte_socket_connected` | En un RTE en mode sòcol: `1` mentre el seu sòcol cap a l'aplicació està obert, `0` quan no ho està |
+
+Les xifres de tasques i de nodes es llegeixen de la base de dades a cada scrape. Quan la base de dades no respon, es deixen
+fora, i l'scrape funciona igualment amb les altres mètriques.
+
+---
+
+## La pàgina Estat
+
+La pàgina **Estat**, a **Configuració > Sistema**, mostra als usuaris amb l'opció de rol `showSettings` com va la instància.
+Només llegeix, així que actualitzar-la mai no envia cap correu ni llança cap tasca. Té dues pestanyes, i el nombre de problemes es mostra a l'etiqueta de la pestanya **Comprovacions**.
+
+### Comprovacions
+
+Cada comprovació és verda (correcta), ambre (requereix atenció) o vermella (un problema), amb els detalls en desplegar la fila:
+
+| Comprovació | Què examina |
+|-------|------------------|
+| Connexió amb la base de dades | La base de dades respon |
+| Usuari de la base de dades | Ambre quan l'usuari té permisos sobre totes les bases de dades, com `root`, en lloc de només `AnsibleForms.*` |
+| Esquema de la base de dades | Existeixen totes les taules, columnes i índexs d'aquesta versió, i quin pedaç ha fallat quan no és així |
+| Planificador | Un worker executa les tasques del sistema, i cap no ha deixat de planificar-se |
+| Nodes | Els processos de la base de dades, ambre quan executen versions diferents |
+| Tasques | Tasques en execució i tasques pendents d'aprovació, ambre quan una tasca fa més de 24 hores que s'executa |
+| Eines de còpia de seguretat | L'ordre de bolcat de [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) existeix, i la seva versió |
+| Darrera còpia de seguretat | Ambre quan no n'hi ha cap o la més recent té més de dos dies, vermell quan no té cap bolcat utilitzable |
+| Bloqueig del dissenyador | Qui té el bloqueig del dissenyador, ambre quan fa més de 8 hores que el té |
+| Repositoris | Vermell quan un repositori ha fallat o no té arbre de treball al disc |
+| Config seed | El fitxer de la [llavor de configuració](../seed/) es pot llegir i analitzar, i la seva darrera recàrrega ha funcionat |
+| Magatzems de secrets | Tots els magatzems de secrets responen, ambre quan el token d'un HashiCorp Vault caduca aviat |
+| Runners | Tots els runners responen, ambre quan no n'hi ha cap o no hi ha cap RTE predeterminat |
+| Expressions del servidor | Ambre quan [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) és `legacy` |
+| Secrets | Ambre quan `ENCRYPTION_SECRET` és el valor predeterminat públic o `ACCESS_TOKEN_SECRET` no està definit |
+| LDAP | El servidor LDAP és accessible i el seu certificat TLS és vàlid, sense iniciar-hi sessió |
+| Emmagatzematge de tasques | La mida de les taules de tasques, ambre per sobre d'1 GB quan no hi ha cap retenció de tasques definida |
+| Carpetes amb permís d'escriptura | Es pot escriure a totes les carpetes configurades |
+| Espai en disc | El disc que conté les còpies de seguretat, ambre a partir d'un 85% d'ús i vermell a partir d'un 95% |
+
+### Informació
+
+Dades de la instància que no tenen cap veredicte, les primeres coses que es demanen en una conversa de suport: la versió
+d'AnsibleForms, la URL base, la versió i l'amfitrió de la base de dades, l'origen de la configuració, la llavor de configuració, els ajustos
+de retenció, els mètodes d'autenticació, el servidor del [canal de correu](../notification-channels.html) actiu, el nivell i el camí
+del registre, el temps en funcionament, la zona horària, la versió de Node.js i la plataforma.
+
+La pàgina llegeix `/api/v2/health`, que necessita un usuari amb la sessió iniciada i `showSettings`. Per a un sistema de supervisió, fes servir
+les sondes i les mètriques de més amunt.
diff --git a/i18n/ca/_configure/production/reverse-proxy.md b/i18n/ca/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..75c9082
--- /dev/null
+++ b/i18n/ca/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Proxy invers
+parent: En producció
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Proxy invers
+{: .no_toc }
+
+Publica AnsibleForms darrere de Nginx, Traefik o Apache, a l'arrel o sota un subcamí
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quan fer-ne servir un
+
+AnsibleForms serveix la interfície, l'API REST i Swagger en un sol port; un proxy invers al davant et permet:
+
+* servir-lo al port 443 amb un certificat gestionat per les teves eines habituals (ACME, una CA corporativa)
+* compartir un nom de host amb altres aplicacions, publicant AnsibleForms sota un subcamí
+* mantenir el port de l'aplicació i la base de dades fora de la xarxa pública
+
+Un proxy és opcional: l'aplicació pot servir HTTPS ella mateixa, vegeu [HTTPS](../security/https.html).
+
+---
+
+## Els ajustos que importen
+
+Només uns quants ajustos afecten el comportament d'AnsibleForms darrere d'un proxy:
+
+| Ajust | Darrere d'un proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | El port al qual reenvia el proxy, `8000` per defecte. El projecte docker-compose el posa a `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` quan el proxy termina el TLS i arriba a l'aplicació per una xarxa privada, `1` per xifrar també aquest tram. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | El subcamí, per exemple `/ansibleforms`. Deixa'l a `/` quan l'aplicació té un nom de host propi. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Quins proxies poden indicar l'adreça del client a `X-Forwarded-For`, normalment `1`. Vegeu [Adreces dels clients](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | La petició JSON més gran que accepta l'aplicació, 50 MB per defecte. El proxy n'ha de permetre com a mínim aquesta. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | El fitxer més gran que accepta un camp de pujada d'un formulari, 10 GB per defecte. El proxy també l'ha de permetre, o les pujades hi fallen. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | El conjunt més gran de capçaleres de petició que accepta l'aplicació, 16 KB per defecte, des de la 7.1.0. Vegeu [Mida de les capçaleres de petició](#request-header-size). |
+| **URL arrel pública** | A **Sistema > General**, a la pestanya **Servidor**: l'adreça on arriben els usuaris, subcamí inclòs. Construeix els enllaços dels correus de notificació, dels missatges dels canals i de les sol·licituds d'aprovació. |
+
+Per a Entra ID o OIDC, registra l'adreça pública com a URI de redirecció, amb el subcamí de `BASE_URL` si n'hi ha.
+
+---
+
+## Servir sota un subcamí
+
+`BASE_URL` munta tota l'aplicació sota el subcamí; el proxy ha de reenviar el camí **sense canvis**.
+Amb `BASE_URL=/ansibleforms`:
+
+* la interfície, `/api/v2/...` i la interfície de Swagger se serveixen totes sota `/ansibleforms/`
+* el `<base href>` de la interfície es reescriu en arrencar, de manera que els recursos i les crides a l'API es resolen sota el subcamí
+* una petició a `/` o a `/ansibleforms` (sense barra final) es redirigeix a `/ansibleforms/`
+
+Conserva el prefix: cap `StripPrefix` a Traefik, cap URI a `proxy_pass` a Nginx, ja que l'aplicació l'espera.
+
+La pàgina **Estat** mostra la URL base vigent.
+
+---
+
+## Temps d'espera, pujades i sortida en directe
+
+La pàgina de tasques i els comptadors de tasques s'assabenten dels canvis a través d'un únic flux de llarga durada d'esdeveniments enviats pel servidor,
+[`/api/v2/events`](../api/events.html), obert per a cada navegador. El flux envia capçaleres que desactiven la memòria intermèdia del proxy
+(`X-Accel-Buffering: no`) i una línia de keep-alive cada 15 segons, de manera que l'habitual temps d'espera de lectura de 60 segons el manté obert;
+quan un proxy el tanca igualment, el navegador es torna a connectar tot sol. La sortida sota un formulari, just després d'un llançament, es
+llegeix en canvi cada dos segons. El llançament d'una tasca torna tan bon punt es crea la tasca, de manera que un playbook llarg no manté
+oberta cap petició.
+
+Les peticions que poden trigar són:
+
+* **còpia de seguretat i restauració** des de la pàgina **Còpies de seguretat**, que esperen que acabi l'ordre de bolcat o de restauració, fins a
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (3600 per defecte)
+* **pujades grans** a través d'un camp de fitxer, que transmeten tot el fitxer en una sola petició
+* **missatges de xat**, quan l'[assistent de xat](../chat/) està activat, que esperen que respongui el proveïdor del model
+
+Els proxies sovint esgoten el temps d'espera als 60 segons i limiten el cos de les peticions (Nginx accepta 1 MB per defecte). Augmenta tots dos per a
+les rutes d'AnsibleForms, com als exemples de més avall.
+
+---
+
+## WebSockets dels runners
+
+Des de la 7.3.0 un [Runner sortint](../rte/modes.html#outbound) truca a l'aplicació i manté un WebSocket obert a
+`<BASE_URL>/api/v2/rte/socket`. El proxy ha de deixar passar l'upgrade, o el Runner no es connecta mai i continua trucant:
+
+| Proxy | Què necessita el WebSocket |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` i les capçaleres `Upgrade` i `Connection`, que Nginx no reenvia per defecte |
+| Traefik | Res: els WebSockets hi passen tal com són |
+| Apache | `upgrade=websocket` a la línia `ProxyPass` (2.4.47 i posteriors), o `mod_proxy_wstunnel` abans d'aquesta versió |
+
+Tots dos extrems envien un ping cada 20 segons, de manera que l'habitual temps d'espera de lectura de 60 segons manté obert un sòcol inactiu.
+
+---
+
+## Mida de les capçaleres de petició
+
+Cada petició porta el token d'inici de sessió a la seva capçalera `Authorization`, al costat de les galetes i de les capçaleres que afegeix el proxy.
+Tant el proxy com l'aplicació limiten la mida de les capçaleres de petició, i rebutgen una petició que passa del límit abans que
+AnsibleForms la vegi, de manera que res no arriba al registre del servidor. Els valors predeterminats:
+
+| Component | Límit | Predeterminat | Rebutjada amb |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), totes les capçaleres juntes | 16384 bytes | 431 |
+| Nginx | `large_client_header_buffers`, per camp de capçalera | `4 8k`: 8 KB per camp | 400 |
+| Traefik | `http.maxHeaderBytes` del punt d'entrada, totes les capçaleres juntes | 1 MB | 431 |
+| HAProxy | `tune.bufsize` a la secció `global`, tot el bloc de capçaleres, menys la reserva de `tune.maxrewrite` (1024 bytes) | 16384 bytes: 15360 bytes de capçaleres | 400 |
+| Apache | `LimitRequestFieldSize`, per camp de capçalera | 8190 bytes | 400 |
+
+Fins a la 7.0.3 el token d'inici de sessió portava tots els grups d'un usuari d'inici de sessió únic, i podia superar aquests límits, vegeu
+[Formularis i tasques buits després d'un inici de sessió únic](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Des de la 7.1.0 el token es manté petit, i els valors predeterminats són suficients. Quan alguna altra cosa fa grans les capçaleres, com ara
+galetes d'altres aplicacions al mateix domini o una passarel·la d'inici de sessió únic al davant, augmenta els límits alhora:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536`, o abans de la 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; tots dos es
+  llegeixen en arrencar, així que reinicia l'aplicació després d'un canvi
+* Nginx: `large_client_header_buffers 4 32k;` al bloc `http` o `server`
+* HAProxy: `tune.bufsize 65536` a la secció `global`; cada flux rep una memòria intermèdia d'aquesta mida, així que HAProxy recomana
+  reduir el `maxconn` global en el mateix factor, i HTTP/2 necessita com a mínim el valor predeterminat de 16384
+* Apache: `LimitRequestFieldSize 32768` a la configuració del servidor o a l'amfitrió virtual
+
+---
+
+## Adreces dels clients
+
+Darrere d'un proxy totes les connexions vénen del proxy. Sense [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY),
+el rastre d'auditoria registra l'adreça del proxy per a cada acció, i els
+[límits d'inici de sessió](../security/hardening.html#sign-in-limits-and-passwords) per adreça compten tots els clients com una sola adreça.
+`TRUST_PROXY` indica quins proxies pot creure l'aplicació quan indiquen el client a `X-Forwarded-For`:
+
+| Valor | Adreça del client |
+|-------|----------------|
+| `0` (predeterminat) | L'adreça de la connexió. `X-Forwarded-For` s'ignora; buit, `false`, `off` i `no` volen dir el mateix. |
+| Un nombre, p. ex. `1` | Confia en aquest nombre de proxies davant de l'aplicació: `1` per a un sol proxy invers, `2` per a un balancejador de càrrega davant d'un ingress. |
+| Una llista, p. ex. `10.0.0.5,172.16.0.0/12` | Confia en els proxies d'aquestes adreces i rangs CIDR. També s'accepten els predefinits `loopback`, `linklocal` i `uniquelocal`. |
+| `true` | Confia en tots els salts: s'utilitza l'adreça de més a l'esquerra de `X-Forwarded-For`. |
+
+L'aplicació recorre `X-Forwarded-For` des de la dreta, salta els proxies de confiança i pren la primera adreça que no
+n'és cap. Fes servir el nombre exacte de proxies, o les seves adreces:
+
+* `X-Forwarded-For` és una capçalera de petició normal que qualsevol client pot enviar. Un nombre massa alt, o `true`, permet a un
+  client triar l'adreça que registra el rastre d'auditoria. `true` només és segur quan només es pot arribar a l'aplicació a través
+  del proxy, i el servidor registra un avís `[SECURITY]` en arrencar quan està definit.
+* El proxy ha d'afegir l'adreça des de la qual ha rebut la connexió, com fan els exemples de més avall
+  (`$proxy_add_x_forwarded_for` a Nginx; Traefik i `mod_proxy` d'Apache l'afegeixen per defecte).
+* Un valor no vàlid es rebutja a la pàgina de configuració; definit a l'entorn, es registra com a error en arrencar i
+  no es confia en cap proxy. Un canvi desat a la pàgina de configuració s'aplica sense reiniciar.
+
+---
+
+## Exemples
+
+Cada exemple publica AnsibleForms a `https://forms.example.com/ansibleforms/`, amb el TLS terminat pel proxy i
+l'aplicació executant-se amb `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` i `TRUST_PROXY=1`:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` no nomena cap URI, de manera que Nginx reenvia el camí tal com ha arribat, prefix inclòs. El bloc `map` va al
+context `http` (un fitxer sota `conf.d/` s'hi inclou), i deixa passar l'upgrade a WebSocket dels runners:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Sense subcamí, fes servir `location /` i deixa `BASE_URL` sense definir.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Etiquetes al servei `app` del projecte docker-compose, amb Traefik a la mateixa xarxa de Docker. El servei
+no publica cap port propi; Traefik hi arriba per la xarxa:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+No hi ha cap middleware `StripPrefix`, a propòsit. Traefik defineix ell mateix les capçaleres `X-Forwarded-*` i no limita
+la mida del cos, però revisa els `respondingTimeouts` del punt d'entrada quan les còpies de seguretat o les pujades triguen més que el seu
+temps d'espera de lectura. Sense subcamí, conserva només la part `Host(...)` de la regla.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Necessita `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl`, i Apache 2.4.47 o posterior per a l'`upgrade=websocket` dels runners.
+Tots dos costats de `ProxyPass` porten el prefix:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Sense subcamí, fes proxy de `/` cap a `http://10.0.0.20:8000/` i deixa `BASE_URL` sense definir.
+
+</div>
+</div>
+
+Per mantenir xifrat el tram entre el proxy i l'aplicació, executa l'aplicació amb `HTTPS=1`, apunta el proxy a
+`https://` i dona a l'aplicació un certificat en què el proxy confiï, vegeu [HTTPS](../security/https.html).
diff --git a/i18n/ca/_configure/production/scaling.md b/i18n/ca/_configure/production/scaling.md
new file mode 100644
index 0000000..36383c8
--- /dev/null
+++ b/i18n/ca/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Escalat
+parent: En producció
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Escalat
+{: .no_toc }
+
+AnsibleForms repartit en diversos nodes d'aplicació i un worker, al costat d'un o més RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rols
+
+Tots els contenidors d'AnsibleForms executen el mateix codi de servidor, i [`AF_ROLE`](../customization/server.html#env_AF_ROLE) decideix què fa cadascun:
+
+| `AF_ROLE` | Imatge | Executa | Quants |
+|---|---|---|---|
+| `all` (sense definir) | `ansibleforms` | L'aplicació web i el worker en un sol procés: el predeterminat | 1 |
+| `app` | `ansibleforms` | La interfície web i l'API | Tants com vulguis, darrere d'un balancejador de càrrega |
+| `worker` | `ansibleforms` | La feina en segon pla: l'esquema de la base de dades i les seves actualitzacions, la llavor de configuració, les programacions, la còpia de seguretat nocturna, les sincronitzacions dels repositoris i les neteges | Un treballant; els altres esperen i prenen el relleu |
+| `rte` | `ansibleforms-rte-full` (o `-rte-core`, `-rte-base`) | Els playbooks | Tants com vulguis |
+
+La instal·lació més petita és un contenidor sense `AF_ROLE` al costat d'un RTE: és el que executen el [projecte Docker Compose](../installation/docker-compose.html)
+i el [chart de Helm](../installation/kubernetes.html). Qualsevol altre valor d'`AF_ROLE` atura el procés en arrencar.
+
+---
+
+## L'RTE
+
+L'RTE, l'entorn d'execució que executa els playbooks, té la seva pròpia secció: [Entorns d'execució](../rte/). Hi trobaràs com un RTE
+executa una tasca, [les seves imatges](../rte/images.html), [com executar-ne un](../rte/run.html), [diversos RTE](../rte/several.html) com a runners o
+rèpliques, i [un RTE en un altre centre de dades](../rte/another-datacenter.html).
+
+---
+
+## Diversos nodes d'aplicació
+
+Per servir més usuaris, o per sobreviure a la pèrdua d'un node, divideix l'aplicació en nodes `app` darrere d'un balancejador de càrrega i un `worker`.
+
+### Què comparteixen els nodes
+{: .no_toc }
+
+Els nodes es posen d'acord entre ells a través de la base de dades i d'un volum compartit:
+
+* **La base de dades** : les tasques, el bloqueig del worker, el bloqueig del dissenyador, la llista de nodes, els leases dels runners (quin node d'aplicació té el
+  sòcol de cada RTE) i els avisos de canvi que mantenen al dia la memòria cau de cada node. Una credencial, un runner o una programació editats
+  en un node són vigents a tots en menys de 5 segons
+* **El volum persistent** (`/app/dist/persistent`) : formularis, la configuració, repositoris, fitxers pujats, còpies de seguretat i el `.env` gestionat.
+  Tots els nodes d'aplicació i el worker munten el mateix, en lectura i escriptura
+* **La carpeta ssh** (`/home/node/.ssh`) : la clau i els hosts coneguts per a git per ssh; el worker crea la clau a la seva primera arrencada
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : el mateix a tots els nodes d'aplicació, o el node següent rebutja un token signat
+  per un altre node. Un node d'aplicació es nega a arrencar sense aquest secret
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : el mateix a tots els nodes d'aplicació i al worker, o una
+  credencial desada per un no la pot llegir un altre. Un RTE en mode sòcol no el llegeix mai; només el necessita un RTE obsolet en mode base de dades
+  que es registra ell mateix
+
+Dona també a tots els contenidors el mateix usuari de base de dades: un worker en espera només pot acabar la sessió d'un worker mort quan és la seva.
+
+### El bloqueig del worker
+{: .no_toc }
+
+Només treballa un worker alhora. Té el bloqueig de base de dades `ansibleforms_worker`; quan s'atura, la base de dades allibera el bloqueig i un
+worker en espera el pren en menys de 10 segons. Quan l'amfitrió del worker mor sense acomiadar-se, la base de dades podria conservar el bloqueig durant hores,
+així que un worker en espera acaba aquella sessió quan fa dos minuts que cap worker no ha escrit un heartbeat, i pren el relleu.
+
+Un worker que perd el bloqueig en favor d'un altre s'atura, i el seu contenidor es reinicia com a worker en espera. Un worker que no aconsegueix arrencar també
+s'atura, de manera que mai no té el bloqueig sense fer res. Galera i la replicació de grup no comparteixen el bloqueig entre nodes de base de dades: apunta tots
+els workers al mateix node de base de dades.
+
+### Tasques i nodes
+{: .no_toc }
+
+Cada contenidor s'anomena `<role>-<hostname>-<port>`, sense res a definir, i la pàgina **Estat** els llista tots amb el seu rol
+i la seva versió, quin és el worker, i un avís quan executen versions diferents.
+
+Una tasca que s'executa en un RTE pertany a aquell RTE, i continua quan desapareix el node d'aplicació que l'ha iniciada. Qualsevol altra tasca (una tasca de plantilla
+a AWX o a un altre runner, una tasca de workflow, o els passos d'un formulari multistep obsolet) pertany al node d'aplicació que l'ha iniciada. Un contenidor que es reinicia acaba les seves pròpies tasques pendents, i el
+worker acaba les tasques d'un contenidor que fa dos minuts que no respon, com ara un pod substituït.
+
+Un `SIGHUP` enviat a qualsevol node torna a aplicar la [llavor de configuració](../seed/): un node d'aplicació demana al worker que ho faci.
+
+### Actualitzar
+{: .no_toc }
+
+Actualitza **primer el worker**, i després els nodes d'aplicació. El worker aplica els pedaços a l'esquema, i un node d'aplicació de la versió nova espera fins que
+l'esquema està actualitzat i registra què espera. Els nodes d'aplicació actualitzats primer es queden sense estar preparats fins que el worker els segueix, mentre els antics continuen
+servint. Els RTE poden seguir en qualsevol moment, sempre que parlin el mateix contracte.
+
+### Límits
+{: .no_toc }
+
+Algunes coses es queden en un sol node:
+
+* **L'assistent de xat** conserva les seves converses a la memòria d'un node d'aplicació: fes servir sessions persistents al balancejador de càrrega (`ip_hash` de
+  nginx), o un sol node d'aplicació
+* **Els registres** es queden a cada contenidor. Posa [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) fora del volum compartit, perquè si diversos
+  processos fan la rotació d'un mateix fitxer es perden línies. El visor de registres mostra el registre del node que respon, així que recull els registres de manera centralitzada
+* **Els ajustos** canviats a les pàgines de configuració s'escriuen al `.env` gestionat del volum compartit i s'apliquen a tots els nodes; els que
+  necessiten un reinici el necessiten a tots els nodes
+
+---
+
+## Exemple de disposició
+
+El repositori de l'aplicació té un punt de partida complet a [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Servei | Imatge | Rol |
+|---|---|---|
+| `db` | `mariadb:11` | La base de dades, amb un usuari que només té permisos sobre l'esquema `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, darrere del balancejador de càrrega |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: el segon espera i pren el relleu |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Executa els playbooks amb `RTE_MODE=inbound` i `RTE_FILES=local`: l'aplicació hi truca |
+| `lb` | `nginx:stable` | Termina l'HTTPS al port 8443 i reparteix els navegadors entre els nodes d'aplicació amb `ip_hash` |
+
+El runner `rte` de l'RTE i la credencial amb què s'hi inicia sessió (la seva adreça `http://rte:8000` i `RTE_TOKEN`) es declaren a la
+[llavor de configuració](../seed/) `seed.yaml`, que el worker aplica a cada arrencada; l'RTE no defineix cap `RTE_URL` i no es publica a l'amfitrió.
+
+Els nodes d'aplicació i els workers comparteixen un mateix `.env`, amb l'usuari de la base de dades, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` darrere del balancejador de càrrega i un `LOG_PATH` fora del volum compartit. L'RTE no té `env_file`: només rep
+`RTE_TOKEN` de `compose.yaml`, de manera que no conté cap contrasenya de base de dades. Els nodes d'aplicació, els workers i l'RTE munten els mateixos
+volums persistent i ssh:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/ca/_configure/rte/another-datacenter.md b/i18n/ca/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..5e8c23f
--- /dev/null
+++ b/i18n/ca/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Un altre centre de dades
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Un RTE en un altre centre de dades
+{: .no_toc }
+
+D'un host buit en un segon centre de dades a un RTE sortint que executa el seu primer playbook
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Per a administradors: quan els hosts gestionats d'un segon centre de dades s'han de gestionar des d'un RTE d'aquell centre de dades, no des del primer.
+
+{: .note }
+> **El camí fàcil.** L'[instal·lador](../installation/installer.html#a-runner) fa tots els passos de més avall a l'host de l'RTE amb una sola ordre:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, amb `--join afj_...` perquè s'aprovi a l'instant.
+> Aquest runbook fa el mateix a mà, amb Docker o Podman, perquè puguis veure i adaptar cada part.
+
+---
+
+## Què tindràs al final
+
+L'aplicació, el seu worker i la seva base de dades es queden on són, al centre de dades 1. El centre de dades 2 rep un host que executa un contenidor RTE en
+mode sortint ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), vegeu [Modes](modes.html#outbound)): truca a l'aplicació per
+HTTPS i manté un WebSocket obert, s'uneix com a runner propi, i executa els playbooks dels formularis que el nomenen contra els hosts
+gestionats del centre de dades 2.
+
+| On | Què s'hi executa | Parla amb |
+|---|---|---|
+| Centre de dades 1 | Els nodes d'aplicació, el worker, la base de dades (com fins ara) | Res de nou: rep el sòcol de l'RTE a la seva adreça HTTPS habitual |
+| Centre de dades 2, l'host de l'RTE | Docker o Podman, i el contenidor RTE | L'aplicació a `APP_URL` per HTTPS, i els hosts gestionats del centre de dades 2 |
+
+L'RTE no té cap credencial de base de dades ni cap `ENCRYPTION_SECRET`, només un token propi. Res no s'hi connecta, així que no necessita cap port
+obert, ni cap nom DNS, ni cap certificat. L'aplicació envia els playbooks i els inventaris amb cada tasca (`RTE_FILES=transfer`, el
+predeterminat), així que l'RTE no en necessita cap còpia ni cap disc compartit.
+
+Totes les ordres de més avall s'executen en un terminal a l'host de l'RTE, com a usuari amb `sudo`, tret que s'indiqui el contrari. Calen uns 20 minuts,
+la major part esperant la imatge.
+
+---
+
+## 0. Abans de començar
+
+Recull això:
+
+| Què | D'on surt |
+|---|---|
+| L'adreça de l'aplicació | `APP_URL`: l'adreça que la gent obre en un navegador, com ara `https://forms.example.com`, amb el seu camí base si en té |
+| El certificat de l'aplicació | Signat per una CA pública, per una CA privada (en necessites el certificat, pas 6), o autosignat |
+| Un proxy | L'`HTTPS_PROXY` que fa servir aquest centre de dades per arribar al centre de dades 1, si n'hi ha |
+| El nom de l'RTE | El nom del seu runner a **Connexions > Runners**, el que els formularis nomenen amb `runner:`, com ara `rte-dc2`: lletres, xifres i `_ . : @ -` |
+| Un token d'unió | Opcional: un [token d'unió](../runners/registration.html#join-tokens) (`afj_...`) aprova l'RTE a l'instant. Sense, l'aprova un admin (pas 8) |
+| La clau ssh | La clau privada que fan servir els playbooks per arribar als hosts gestionats, o el permís per crear-ne una |
+
+L'aplicació ha de funcionar amb la 7.3.0 o posterior. Per crear un token d'unió només per a aquest RTE, un admin crida l'API una vegada (vegeu
+[Tokens d'unió](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Preparar l'host
+
+L'RTE és un contenidor, així que l'host necessita un motor de contenidors i res més: Node.js, python i ansible són a la imatge.
+
+| Cal | Per què |
+|---|---|
+| Linux en **x86_64** (amd64) | Les imatges de l'RTE només es publiquen per a amd64 |
+| 2 CPU i 4 GB de memòria, o més | Un RTE executa fins a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks alhora (10), cadascun amb els seus forks: dimensiona'l per a ells |
+| 20 GB de disc lliure | La imatge `-rte-full` fa uns 3,3 GB, més una imatge durant les actualitzacions, els fitxers de tasca que envia l'aplicació i els fitxers temporals de les tasques |
+| Docker, o Podman amb podman-compose | Per descarregar i executar la imatge |
+| L'hora sincronitzada per NTP | Les hores de les tasques es comparen amb les de l'aplicació |
+
+**Docker**, a Ubuntu o Debian (altres distribucions: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, a RHEL, Rocky o Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Amb Podman, escriu `podman` en lloc de `docker` i `podman-compose` en lloc de `docker compose` a totes les ordres de més avall.
+
+---
+
+## 2. Xarxa i tallafocs
+
+L'RTE obre ell mateix totes les connexions. Res no hi arriba des de fora:
+
+| Des de | Cap a | Port | Per què |
+|---|---|---|---|
+| L'host de l'RTE | L'aplicació, a `APP_URL` (a través d'`HTTPS_PROXY` si està definit) | El port de l'aplicació, `443` darrere de la majoria de proxies | El sòcol per on passen les tasques, els seus fitxers i la seva sortida |
+| L'host de l'RTE | Els hosts gestionats del centre de dades 2 | ssh (`22`), WinRM, les seves API | Els playbooks s'executen des d'aquí |
+| L'host de l'RTE | `ghcr.io` | `443` | Per descarregar la imatge, tret que vingui del teu propi registre o d'un fitxer (pas 4) |
+
+No obris cap port d'entrada per a l'RTE. El seu `PORT` (`8000`) només serveix `/live`, `/ready` i `/metrics`, per a les sondes d'aquest host.
+
+L'RTE truca a `APP_URL` amb `/api/v2/rte/socket` afegit, com a WebSocket. Un proxy invers davant de l'aplicació ha de deixar passar l'upgrade
+en aquest camí (vegeu [WebSockets dels runners](../production/reverse-proxy.html#runner-websockets)). Comprova des d'aquí que l'aplicació respon:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Carpetes
+
+Tot és sota `/opt/af-rte`. L'RTE s'executa com l'usuari `node` (uid 1000), així que les seves dades pertanyen a aquest uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Carpeta | Al contenidor | Conté |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | L'spool (`rte-spool`: la sortida i el final de cada tasca fins que l'aplicació els ha desat), els fitxers de tasca que ha enviat l'aplicació (`rte-files`), una CA privada, les biblioteques de python que instal·la un playbook |
+| `data/ssh/` | `/home/node/.ssh` | La clau ssh i el `known_hosts` dels playbooks |
+| `data/ansible/` | `/etc/ansible/...` | Un `ansible.cfg`, rols i col·leccions propis, muntats en lloc d'incloure'ls a la imatge |
+
+Mantén `data/` a l'host: un RTE reiniciat encara envia el que l'aplicació no havia desat, i conserva la seva memòria cau de fitxers de tasca.
+
+**Clau ssh.** Copia la clau que fan servir els playbooks al centre de dades 1, o crea'n una per a aquest centre de dades i dona'n la part pública als hosts gestionats:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Després dona-ho tot a l'uid 1000, amb la clau llegible només pel seu propietari:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. La imatge
+
+Tria una de les dues opcions.
+
+### Opció A: la imatge oficial
+{: .no_toc }
+
+Les imatges publicades són al GitHub Container Registry, públiques, sense necessitat d'iniciar sessió (vegeu [Imatges](images.html) per a les tres capes).
+Agafa la mateixa capa que al centre de dades 1. `:7` segueix la darrera versió 7, igual que el `:7` de l'aplicació:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Un host sense accés a internet obté la imatge d'un que en té:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+O puja-la una vegada al teu propi registre (`docker tag` i `docker push`), i fes servir aquest nom als passos següents.
+
+### Opció B: la teva pròpia imatge
+{: .no_toc }
+
+Quan els playbooks del centre de dades 2 necessiten col·leccions o biblioteques de python que la imatge oficial no té (les de VMware per al vCenter d'aquest centre de dades,
+per exemple), construeix sobre `ansibleforms-rte-core`:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Torna-la a construir a cada versió nova de l'aplicació (vegeu [Construir el teu propi RTE](images.html#build-your-own-rte)). Amb diversos hosts RTE, construeix-la
+una vegada i puja-la al teu propi registre. Sense connexió, fes `docker save` i `docker load` de la imatge construïda com a l'opció A.
+
+---
+
+## 5. Ajustos
+
+Un [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) nou i propi, d'almenys 16 caràcters. És la contrasenya d'aquest RTE: l'aplicació
+el conserva a la credencial RTE del runner, i hi segella els secrets de cada tasca.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variable | Significat |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: l'RTE truca a l'aplicació. Sense aquesta variable l'RTE arrenca en el mode base de dades obsolet |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'adreça de l'aplicació, `http://` o `https://`, amb el seu camí base si en té |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | El nom del seu runner. Si no es defineix: el seu id de node, `rte-<hostname>-<port>`, que canvia amb el contenidor |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | El seu propi token, d'almenys 16 caràcters. Conserva'l: el runner hi inicia sessió a partir d'ara |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcional: un token d'unió, que només es fa servir mentre el seu runner encara no existeix o espera aprovació |
+
+Afegeix aquests quan la xarxa els necessiti:
+
+| Variable | Quan |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | L'RTE arriba a l'aplicació a través d'un proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Un host llistat a `NO_PROXY` (separats per comes, `.example.com` per a un domini) es truca directament |
+| `NODE_EXTRA_CA_CERTS` | El certificat de l'aplicació ve d'una CA privada: posa el certificat de la CA a `/opt/af-rte/data/certificates/ca.pem` i defineix `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` accepta qualsevol certificat de l'aplicació, un d'autosignat inclòs. Només dins d'una xarxa de confiança: millor `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predeterminat) obté els playbooks i els inventaris amb cada tasca. Deixa'l així, tret que els muntis tu mateix a l'RTE (`local`) |
+
+Els altres ajustos que llegeix un RTE són a [Executar un RTE](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` i
+`RTE_DRAIN_SECONDS` també es poden definir més endavant a la seva pàgina de runner, que guanya a la variable (vegeu
+[La configuració d'un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Iniciar-lo
+
+Un fitxer compose manté tota la definició en un sol lloc, al costat dels ajustos. Posa la imatge del pas 4 a `image:`:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker el torna a iniciar després d'un reinici (`unless-stopped`). Podman no té cap dimoni que ho faci: activa `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`), o executa el contenidor com a servei systemd amb un fitxer Quadlet. En un host amb SELinux
+en mode enforcing, afegeix `:Z` a cada volum (`./data:/app/dist/persistent:Z`).
+
+Sense compose, el mateix contenidor amb una sola ordre:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Comprovar-lo a l'host
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+El registre mostra com l'RTE arrenca, truca a l'aplicació i s'hi connecta:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Sense token d'unió, una línia més indica que espera:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Anota't l'empremta.
+
+`/ready` respon `503` amb `not connected to the app` fins que el sòcol està obert. El healthcheck només indica que el procés escolta.
+
+---
+
+## 8. Aprovar-lo
+
+Sense token d'unió, l'RTE ha demanat unir-se: **Connexions > Runners** mostra un avís taronja damunt de la llista,
+**1 Runner espera aprovació**. Obre'l, comprova que l'**Empremta** és la del registre de l'RTE i que el **Mode** diu
+Sortint, i després fes clic a **Aprova** (vegeu [Aprovar un RTE](../runners/registration.html#approving-an-rte)). Només un admin pot aprovar. Una sol·licitud
+que ningú no gestiona en 24 hores s'elimina, i l'RTE ho torna a demanar el proper cop que truca a l'aplicació.
+
+Amb un token d'unió, el runner s'aprova a l'instant i la seva descripció nomena el token d'unió. En tots dos casos l'aplicació conserva el token de l'RTE
+en una credencial RTE nova, `rte-dc2-rte`, i l'RTE hi inicia sessió amb el seu propi `RTE_TOKEN` a partir d'aleshores: `RTE_JOIN_TOKEN` ja no
+es fa servir, i el pots treure de `rte.env`.
+
+---
+
+## 9. Comprovar-lo a AnsibleForms
+
+1. **Connexions > Runners** llista el runner `rte-dc2`, de tipus RTE. Activa **Columnes > Connexió** per veure **Connectat** a la llista
+2. Obre'l. La seva pestanya **RTE** mostra el **Mode** Sortint i la insígnia de **Connexió** **Connectat**; en passar-hi el punter nomena el node d'aplicació que
+   té el sòcol, la versió de l'RTE i quantes de les seves tasques s'executen
+3. Fes clic a **Prova la connexió**: diu **Runner connection is OK**. No crida res: llegeix quin node d'aplicació té el sòcol de l'RTE
+   (`runner_leases`) i comprova el contracte que l'RTE ha parlat en connectar-se
+4. Dona-li una descripció, com ara *Centre de dades 2*
+5. Deixa **És el predeterminat** al runner del centre de dades 1, tret que tots els formularis de playbook sense `runner:` s'hagin d'executar al centre de dades 2
+
+La pàgina **Estat** llista l'RTE nou amb la seva versió, al costat dels altres.
+
+---
+
+## 10. Una primera tasca
+
+Prova tot el camí amb un playbook que no canviï res. Als playbooks de l'aplicació (la seva carpeta o el seu repositori de playbooks, com al
+centre de dades 1), afegeix `ping-dc2.yaml`:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Després afegeix al dissenyador un formulari que nomeni el runner nou:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Llança'l. L'aplicació envia la carpeta de playbooks i l'inventari amb la tasca, i l'RTE els conserva pel seu hash, de manera que una carpeta
+sense canvis no s'envia mai dues vegades. La sortida comença amb `Running on RTE rte-dc2 (outbound)`, mostra `pong` per a cada host, i la tasca
+acaba amb èxit. Una carpeta més gran que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 per defecte) no
+s'envia: la tasca falla i ho indica.
+
+---
+
+## 11. Enviar-li els formularis
+
+Un formulari s'executa a l'RTE que nomena, així que afegeix la mateixa línia a cada formulari per al centre de dades 2:
+
+```yaml
+runner: rte-dc2
+```
+
+Vegeu [Runners](../runners.html) per al runner predeterminat i els altres tipus de runner.
+
+---
+
+## Quan alguna cosa falla
+
+L'RTE escriu a `docker logs` a partir de `notice`. Una connexió que falla abans que el sòcol s'obri (un nom DNS, un port rebutjat, un
+certificat) només es mostra com a `RTE: dialing the app again in <n> seconds`, a `info`: defineix
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) a `rte.env` i reinicia'l per veure
+`RTE: socket to wss://...: <the error>`.
+
+| Què veus | On | Què cal fer |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | Falta `RTE_TOKEN` a `rte.env` o és massa curt |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Defineix `APP_URL` a `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` ha de començar per `https://` (o `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | Falta `RTE_MODE=outbound` a `rte.env` |
+| Cap línia `connected to the app`, `/ready` continua a `503` | `docker logs`, `/ready` | La xarxa del pas 2: fes `curl` a l'aplicació des d'aquest host, el proxy (`HTTPS_PROXY`, `NO_PROXY`), el certificat de l'aplicació (`NODE_EXTRA_CA_CERTS`, pas 5). Defineix `LOG_CONSOLE_LEVEL=debug` per veure l'error |
+| `the app refused the socket (404)` o un altre estat que no sigui 401, 403 o 409 | `docker logs` | Un proxy invers no deixa passar el WebSocket a `/api/v2/rte/socket`, o a `APP_URL` li falta el camí base de l'aplicació |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Ja existeix un runner `rte-dc2` amb un altre token. Dona a l'RTE aquest token (la contrasenya de la credencial del runner), o suprimeix el runner perquè demani unir-se |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Crea un token d'unió nou, o treu `RTE_JOIN_TOKEN` i aprova l'RTE (pas 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | L'RTE s'ha tornat a instal·lar amb un token nou: fes servir el token de la credencial del seu runner, o demana a un admin que el canviï |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Ve després d'un rebuig. Corregeix-ne la causa, i després `docker restart af_rte_dc2` en lloc d'esperar |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Aprova'l (pas 8). Està connectat, però fins aleshores no rep cap tasca |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | L'aplicació i l'RTE executen versions d'un altre [contracte](images.html#the-contract): actualitza l'RTE a la versió de l'aplicació (vegeu Actualitzar-lo) |
+| **No connectat**, o **Prova la connexió** diu *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | L'aplicació | Cap node d'aplicació no té el seu sòcol: l'RTE està aturat, o no arriba a l'aplicació. Llegeix els seus `docker logs` |
+| Una tasca espera i després falla amb *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | La sortida de la tasca | L'RTE no estava connectat mentre la tasca esperava |
+| `Permission denied` a la clau ssh | La sortida de la tasca | Els fitxers de `data/` han de pertànyer a l'uid 1000 (pas 3) |
+| `UNREACHABLE` per als hosts gestionats | La sortida de la tasca | L'ssh des d'aquest host: la clau, el `known_hosts` i el tallafocs cap als hosts |
+
+A la banda de l'aplicació, un RTE rebutjat apareix al registre de l'aplicació com a `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Actualitzar-lo
+
+Quan l'aplicació passa a una versió nova, segueix-la també en aquest host. Mentrestant, un RTE del mateix contracte continua funcionant; quan una versió
+canvia el contracte, les seves notes de versió ho diuen (vegeu [El contracte](images.html#the-contract)). Amb `:7` a `compose.yml`, o al
+`FROM` del teu Dockerfile:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Actualitza'l quan no s'hi executi cap playbook: una aturada espera `RTE_DRAIN_SECONDS` (25) els playbooks en execució, i els que encara s'executen
+llavors acaben com a abandonats. El que han escrit abans de l'aturada es conserva a l'spool i s'envia un cop l'RTE torna. Sense connexió, fes `docker load`
+de la imatge nova (pas 4) abans de `docker compose up -d`.
+
+---
+
+## Revertir-lo
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+El sòcol es tanca, i el runner mostra **No connectat** a l'instant: cap node d'aplicació no té ja el seu sòcol (`runner_leases`). Un host
+que desapareix sense tancar-lo mostra **No connectat** en un minut aproximadament, quan el node d'aplicació no sent res pel sòcol. El
+runner es queda: un runner que s'ha unit per un sòcol no s'elimina mai tot sol. Suprimeix-lo a **Connexions > Runners**, i la seva
+credencial `rte-dc2-rte` a **Connexions > Credencials**. Primer treu la línia `runner:` dels formularis que el nomenaven: fins
+aleshores les seves tasques esperen l'RTE, fins a `RTE_QUEUE_MINUTES`, i fallen.
+
+---
+
+## Més capacitat al centre de dades 2
+
+Repeteix els passos de l'1 al 9 en més hosts del centre de dades 2, cadascun amb el seu propi `RTE_NAME` i `RTE_TOKEN`, com ara `rte-dc2-b`: cadascun s'uneix com a
+runner propi i accepta fins a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks. Un formulari en tria un amb
+`runner:`. Dos RTE amb el mateix `RTE_NAME` no es reparteixen la feina: el segon pren el sòcol al primer (vegeu
+[Diversos RTE](several.html#several-rtes)).
+
+---
+
+## Un RTE en mode base de dades
+
+Abans de la 7.3.0 aquest runbook configurava un RTE en mode base de dades: tenia les credencials de la base de dades (`DB_*`, `ENCRYPTION_SECRET`), es connectava
+a la base de dades del centre de dades 1 pel port `3306`, i l'aplicació el cridava al seu port `8000`. Aquest mode és obsolet des de la 7.3.0 i
+s'elimina a la 8.0.0. Per passar un RTE d'aquests a sortint sense un runner nou, defineix-hi `RTE_MODE=outbound`, `APP_URL` i `RTE_NAME` (el nom del
+seu runner), conserva el seu `RTE_TOKEN`, i treu `DB_*`, `ENCRYPTION_SECRET` i `RTE_REGISTER`: vegeu
+[Base de dades (obsolet)](modes.html#database-deprecated). Després tanca el port `8000` i el port de la base de dades, que ja no necessita.
diff --git a/i18n/ca/_configure/rte/images.md b/i18n/ca/_configure/rte/images.md
new file mode 100644
index 0000000..d552f07
--- /dev/null
+++ b/i18n/ca/_configure/rte/images.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Imatges
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# Imatges de l'RTE
+{: .no_toc }
+
+Les tres imatges publicades de l'RTE, i un RTE propi amb les col·leccions i les biblioteques que fan servir els teus playbooks
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les imatges de l'RTE
+
+L'RTE es publica en tres capes, cadascuna construïda sobre l'anterior, amb les mateixes etiquetes que l'aplicació (vegeu [Etiquetes d'imatge](../installation/#image-tags)):
+
+| Imatge | Què conté | Fes-la servir |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js i el servidor d'AnsibleForms, git, ssh i sshpass. Sense python ni ansible, així que tota sola no executa cap playbook | Per construir un RTE amb les teves pròpies versions de python i ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base, més python 3.14, ansible-core i unes quantes biblioteques habituals (`jmespath`, `netaddr`, `requests`, `paramiko`). Sense col·leccions | Per construir un RTE més petit només amb les col·leccions i les biblioteques que fan servir els teus playbooks |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | La core, més el paquet `ansible` sobre el mateix ansible-core, i el que tenia la imatge d'AnsibleForms 6.5: les col·leccions de NetApp, AWS i community, `pandas`, `pyvmomi`, `boto3`, el client de mariadb, ytt i unes quantes eines del sistema | **La predeterminada.** Executa-la tal com és: els playbooks de la 6.5 hi troben el que feien servir |
+
+Igual que la imatge de l'aplicació, totes les capes s'executen amb l'usuari `node` (uid 1000), i els playbooks també s'executen amb aquest usuari.
+
+---
+
+## Construir el teu propi RTE
+
+Construeix sobre `ansibleforms-rte-core` i afegeix les col·leccions i les biblioteques de python que fan servir els teus playbooks. Aquest exemple de NetApp és un dels
+Dockerfiles d'[examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+L'entorn de python i la carpeta de col·leccions pertanyen a `node`, així que aquestes instal·lacions no necessiten root. Una capa que instal·la paquets
+del sistema canvia a `USER root` per fer-ho i torna a `USER node` al final. Per portar el teu propi python i ansible, construeix sobre
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` a la mateixa carpeta).
+
+Mantén la imatge a la versió de l'aplicació: `:7` segueix el `:7` de l'aplicació. Les col·leccions i els rols també es poden muntar en lloc d'incloure'ls a la imatge, a
+`/etc/ansible/collections` i `/etc/ansible/roles`. Llavors no cal reconstruir la imatge per a cada canvi, però el que s'executa depèn d'aquell volum;
+les biblioteques de python sempre van a la imatge. Incloure-ho tot a la imatge és reproduïble i arrenca de pressa, i per això és la manera de fer-ho en producció.
+
+---
+
+## El contracte
+
+El que han de compartir l'aplicació i un RTE és el seu contracte, un número que tots dos indiquen. Un RTE d'una versió més antiga continua funcionant amb una aplicació
+més nova mentre tots dos parlin el mateix contracte; quan una versió el canvia, les seves notes de versió diuen que cal actualitzar els RTE. Cada mode
+té el seu:
+
+| Mode | Contracte | Si no coincideix |
+|---|---|---|
+| Sortint, Entrant | 3, nou a la 7.3.0 | L'aplicació tanca el sòcol de l'RTE amb el codi `4409` i registra *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Un RTE sortint registra *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Una tasca enviada amb un altre contracte es rebutja |
+| Base de dades (obsolet) | 2, des de la 7.0.0 | L'RTE rebutja les tasques de l'aplicació |
+
+**Prova la connexió** al runner indica quin contracte parla l'RTE i quin necessita l'aplicació (vegeu
+[Prova la connexió](../runners/runner-page.html#test-connection)), i la fila **Runners** de la pàgina **Estat** fa la mateixa comprovació.
+
diff --git a/i18n/ca/_configure/rte/index.md b/i18n/ca/_configure/rte/index.md
new file mode 100644
index 0000000..ae0b2f8
--- /dev/null
+++ b/i18n/ca/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Entorns d'execució (RTE)
+{: .no_toc }
+
+Què és un RTE, com executa un playbook i què pot tocar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: entén l'RTE abans d'executar-ne un, de dimensionar-lo o de moure'l a una altra xarxa.
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Imatges](images.html) | Les tres imatges de l'RTE, i com construir la teva pròpia amb les col·leccions que fan servir els teus playbooks |
+| [Modes](modes.html) | Sortint, entrant o base de dades: qui obre la connexió, l'spool, els fitxers de la tasca |
+| [Executar un RTE](run.html) | Els ajustos de cada mode, i un exemple de `docker run` de cadascun |
+| [Diversos RTE](several.html) | Capacitat, rèpliques darrere d'una adreça, i què passa quan un RTE s'atura o mor |
+| [Un altre centre de dades](another-datacenter.html) | Un runbook: afegir un RTE en un segon centre de dades, des d'un host buit fins a la seva primera tasca |
+
+---
+
+## Què és un RTE
+
+AnsibleForms 7 no executa cap playbook al contenidor de l'aplicació. La tasca d'un formulari `ansible` es passa a un [runner](../runners.html) de tipus
+`rte`, un entorn d'execució: el servidor d'AnsibleForms iniciat amb `AF_ROLE=rte`, al costat de python i ansible, sense interfície
+web. Parla amb l'aplicació per un sol WebSocket i no té cap credencial de base de dades
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` o `inbound`, vegeu [Modes](modes.html)): l'aplicació li envia la tasca,
+l'RTE executa `ansible-playbook`, i l'aplicació desa la sortida i l'estat final que li torna, d'on els llegeix el navegador.
+
+L'aplicació resol les credencials de la tasca i les passa a l'RTE segellades només per a aquell RTE i aquella tasca. L'RTE mai no llegeix la
+taula de credencials ni cap magatzem de secrets, i un playbook no hereta les variables d'entorn pròpies d'AnsibleForms
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` i les altres): passa un valor d'aquests com a extravar o com a credencial. L'RTE de la 7.0 a la 7.2,
+que llegia i escrivia ell mateix la base de dades, encara funciona a la 7.x com a mode base de dades obsolet (vegeu [Mode base de dades](#database-mode-deprecated)).
+
+---
+
+## Com s'executa l'RTE
+
+L'RTE és un contenidor que executes tu mateix, al costat de l'aplicació o en una altra xarxa: AnsibleForms mai no en crea cap. Aquí es repassa
+on s'executa, què comparteix amb l'aplicació i què hi passa a dins des del moment que es llança un formulari fins que el procés del playbook
+desapareix:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Com executa un playbook l'RTE</title>
+<desc id="afr-desc">En un host de contenidors o en un clúster de Kubernetes, tots dos gestionats per l'operador, el contenidor de l'aplicació i un o més contenidors RTE mantenen cadascun un WebSocket entre ells, obert per l'aplicació (entrant) o per l'RTE (sortint). Només l'aplicació parla amb la base de dades. 1: el navegador llança un formulari a l'aplicació. 2: l'aplicació desa la tasca a la base de dades, tria el runner i hi segella els secrets de la tasca. 3: l'aplicació envia la tasca pel sòcol. 4: l'RTE la reclama i obté els fitxers de la tasca, de la seva memòria cau o de l'aplicació. 5: l'RTE inicia ansible-playbook com a procés fill, un per tasca, fins a RTE_MAX_JOBS. 6: el playbook arriba als hosts gestionats. 7: l'RTE escriu la sortida, els esdeveniments i el final al seu spool i els envia pel sòcol; l'aplicació els desa a la base de dades i en confirma la recepció. 8: el navegador segueix la tasca a través de l'aplicació. El volum de l'aplicació només es munta a l'RTE amb RTE_FILES=local.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Host de contenidors o clúster de Kubernetes</text>
+<text class="afr-s" x="181" y="61">gestionat per tu; un RTE sortint pot ser en una altra xarxa</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Navegador</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">formularis, tasca</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">Contenidor app</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">web, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runners</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">segellen els secrets</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">Hub de l'RTE</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">desa i confirma</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">Contenidor RTE</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="477" y="160" text-anchor="middle">Fitxers de la tasca</text>
+<text class="afr-s" x="477" y="174" text-anchor="middle">en memòria cau per hash</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">fins a RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">fins a la confirmació</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">un</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Hosts gestionats</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volum de l'app</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbooks, inventaris</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">només RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">només de l'app</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="548" cy="142" r="9"/><text class="afr-nt" x="548" y="146" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+El diagrama mostra un sòcol per RTE, l'obri qui l'obri: l'aplicació truca a un RTE entrant, un RTE sortint truca a l'aplicació (vegeu
+[Modes](modes.html)). Un cop obert, hi circulen els mateixos missatges en tots dos sentits, i només l'aplicació llegeix i escriu la base de dades.
+
+**Qui l'inicia.** Un RTE és un contenidor de llarga durada, iniciat pel mateix que executa els teus altres contenidors. Espera tasques i continua
+funcionant entre una i una altra:
+
+| Com executes AnsibleForms | Qui inicia l'RTE |
+|---|---|
+| `docker run` o `podman run` | Tu, amb una ordre com la d'[Executar un RTE](run.html), en qualsevol host que arribi a l'aplicació, o al qual arribi l'aplicació |
+| [Docker Compose](../installation/docker-compose.html) | El servei `rte` de `docker-compose.yml`, al costat d'`app` i `mysqldb`. La seva llavor de configuració el declara com el runner predeterminat `rte`, entrant, a `http://rte:8000` |
+| [Chart de Helm](../installation/kubernetes.html) | Kubernetes, com un segon contenidor anomenat `rte` al pod de l'aplicació (`containers.rte`). L'aplicació hi truca a `127.0.0.1`, entrant, i la llavor del chart el declara com el runner predeterminat |
+| [L'instal·lador](../installation/installer.html) | Docker Compose o el chart de Helm com més amunt, o un servei systemd [sense contenidors](../installation/native.html); un Runner propi, que demana unir-se i espera l'aprovació d'un admin |
+
+El motor de contenidors és teu: Docker o Podman a l'amfitrió, o el runtime de contenidors del teu clúster de Kubernetes, instal·lat i mantingut
+al dia per tu. AnsibleForms mai no hi parla. Ni l'aplicació ni l'RTE criden Docker o Podman, en munten el sòcol o inicien cap
+contenidor: l'aplicació només parla amb l'RTE pel seu sòcol.
+
+**Què hi ha a dins.** Un contenidor, amb el que cal per executar un playbook i res més:
+
+* **El servidor** : el mateix servidor Node.js que l'aplicació, iniciat amb `AF_ROLE=rte` (definit a la imatge) sota `tini`
+* **El que queda fora** : la interfície web, l'inici de sessió, el planificador, el worker i tots els mòduls de base de dades, que aquest rol no carrega
+* **On escolta** : al seu `PORT` (`8000`): `/live` i `/ready` per a les sondes i `/metrics` per a Prometheus, i en mode entrant el sòcol
+  al qual truca l'aplicació, `/rte/v1/socket`. Un RTE sortint no accepta cap connexió de l'aplicació
+* **Python i ansible** : els aporta la capa d'imatge que triïs (vegeu [Les imatges de l'RTE](images.html))
+* **L'usuari** : el servidor i tots els playbooks s'executen com a `node` (uid 1000), mai com a root
+
+**Què comparteix amb l'aplicació.** El seu token, i amb `RTE_FILES=local` els fitxers de l'aplicació. Amb `RTE_FILES=transfer`, el predeterminat, els
+playbooks i els inventaris arriben amb cada tasca, i l'RTE no necessita cap disc compartit:
+
+| Compartit amb l'aplicació | Què en fa l'RTE |
+|---|---|
+| `RTE_TOKEN` | El presenta quan truca a l'aplicació (sortint), o el comprova quan l'aplicació li truca (entrant). L'aplicació té el mateix valor a la credencial RTE del runner, i els secrets de la tasca es segellen amb ell |
+| El volum persistent, `/app/dist/persistent`, només amb `RTE_FILES=local` | La carpeta de playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)), o el repositori de playbooks que el worker ha clonat sota [`REPO_PATH`](../customization/paths.html#env_REPO_PATH), els inventaris ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) i els repositoris d'inventari) i els fitxers pujats. L'RTE escriu els fitxers d'extravars de la tasca a la carpeta del playbook, així que munta-la en lectura i escriptura |
+| La carpeta ssh, `/home/node/.ssh` | La clau privada i el `known_hosts` que fan servir les connexions ssh del playbook: munta la de l'aplicació, gestionada a les seves pàgines de configuració, o dona a l'RTE la seva pròpia |
+
+L'RTE no clona res: un repositori li arriba als fitxers d'una tasca, o al volum que comparteix amb l'aplicació. Les col·leccions, els rols i
+`ansible.cfg` vénen de la imatge, de les carpetes `/etc/ansible/collections`, `/etc/ansible/roles` i `/etc/ansible/ansible.cfg` quan
+les hi muntes (el projecte Docker Compose ho fa), o d'un `ansible.cfg` al costat dels playbooks.
+
+**La vida d'una tasca.** Els números de sota són els del diagrama, per a un formulari de playbook llançat des del navegador o l'API:
+
+1. **Llançament** : l'aplicació comprova el formulari i els seus valors, construeix les extravars i desa la tasca amb l'estat `running`. Un formulari amb una
+   [aprovació](../forms/approval.html) s'atura aquí fins que un aprovador l'accepta, i abans no arriba a cap RTE
+2. **Tria del runner** : l'aplicació pren l'RTE que el formulari nomena amb `runner: <name>`, o si no el runner predeterminat de tipus RTE, i en desa el
+   nom a la tasca. Resol les credencials de la tasca a partir de la base de dades o d'un [magatzem de secrets](../secret-stores/), el seu accés d'ansible i la seva
+   contrasenya de vault, i les segella amb AES-256-GCM sota una clau derivada del token d'aquell runner i de l'id de la tasca
+3. **Lliurament** : el node d'aplicació que té el sòcol de l'RTE li envia la tasca: les extravars, les opcions del formulari, els secrets segellats i
+   els hashes dels fitxers de la tasca. Qualsevol node d'aplicació pot llançar la tasca; el que té el sòcol l'envia en menys de dos segons. Un RTE ple,
+   o un que no està connectat, fa esperar la tasca, fins a [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Reclamació** : l'RTE respon `claimed`, o `refused` quan està ple, s'està aturant, no pot obrir els secrets, o la tasca arriba amb un altre
+   [contracte](images.html#the-contract) que el seu. Amb `RTE_FILES=transfer` pren els playbooks i els inventaris de la seva
+   memòria cau pel seu hash, demana a l'aplicació un hash que no té, i els desempaqueta en una carpeta pròpia de la tasca
+5. **Inici** : a la carpeta del playbook (més el `playbookSubPath` del formulari, que ha d'existir) escriu dos fitxers: `extravars_<id>.json`
+   amb els valors del formulari i les credencials, i un d'ocult amb l'accés d'ansible. Després inicia `ansible-playbook` com a procés fill
+   seu, sense shell, en un grup de processos propi, amb `-e @` aquests fitxers, un `-i` per inventari, i els tags, el limit, el check, el
+   diff i la verbositat del formulari. La contrasenya de vault entra per stdin, mai en un fitxer ni a la línia d'ordres, i el procés s'executa com a
+   `node` amb un entorn filtrat (vegeu més avall)
+6. **Execució** : el playbook es connecta als hosts gestionats des del contenidor de l'RTE, per ssh amb la clau i el `known_hosts` de
+   `/home/node/.ssh`, amb `sshpass` per a un accés amb contrasenya, o per les API que criden els seus mòduls. És l'RTE, no l'aplicació, qui hi ha d'arribar
+7. **Sortida i final** : l'RTE agrupa stdout i stderr cada mig segon o cada 64 KB, amb les credencials emmascarades, i numera cada
+   lot. Escriu cada element a l'spool de la tasca al seu disc abans d'enviar-lo: la sortida, els esdeveniments, el registre de la tasca de
+   `.joblogs/job_log_<id>.log` (cada 2 segons), l'inici i el final amb l'estat final (`success`, `failed` o `aborted`). L'aplicació
+   desa cada element una sola vegada i en confirma la recepció, i l'RTE descarta l'spool un cop desat el final. Passats
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) bytes en un flux (50 MB per defecte) ja no n'envia més, i
+   el playbook continua. L'aplicació envia llavors les [notificacions](../forms/notifications.html) del formulari
+8. **Seguiment** : el navegador mai no parla amb l'RTE: la pàgina del formulari torna a llegir la tasca a través de l'aplicació cada 2 segons, i la pàgina Tasques
+   la segueix en directe a mesura que l'aplicació desa cada element
+
+**Un sòcol que cau.** El playbook continua. L'RTE torna a trucar (sortint), o un node d'aplicació hi torna a trucar (entrant), i torna a enviar el que
+l'aplicació no havia confirmat: l'aplicació salta el que ja havia desat, de manera que no es perd ni es desa dues vegades cap línia. Això val mentre el sòcol
+torni en menys de dos minuts: l'aplicació escriu el heartbeat de l'RTE només mentre el seu sòcol està obert, i quan aquest heartbeat té dos minuts
+el worker acaba les tasques en execució de l'RTE com a abandonades, encara que els seus playbooks continuïn funcionant. Mantén l'spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) en un volum, perquè un RTE reiniciat encara enviï el que havia conservat. Un
+playbook que s'estava executant quan el seu RTE s'ha reiniciat no pot continuar: l'aplicació n'acaba la tasca com a abandonada quan l'RTE torna sense ell.
+
+**Avortament.** Un avortament activa l'indicador d'avortament de la tasca, i el node d'aplicació que té el sòcol de l'RTE envia `cancel` en menys de dos segons. L'RTE
+envia `SIGTERM` al grup de processos del playbook, de manera que `ansible-playbook` i tots els forks que ha iniciat s'aturen alhora, i la tasca acaba
+`aborted`. Una cancel·lació que arriba abans que la seva tasca es conserva durant un minut, i llavors la tasca comença avortada.
+
+**Neteja.** Tan bon punt el procés acaba, sigui quin sigui el resultat, l'RTE elimina els dos fitxers d'extravars (un formulari amb `keepExtravars`
+conserva el visible, mai l'ocult), el fitxer d'artefactes de `/tmp`, el fitxer de registre de la tasca i la carpeta de fitxers pròpia de la tasca. El
+final es desa una sola vegada: un segon escriptor, com ara l'aplicació fent fallar una tasca que l'RTE ja ha acabat, no canvia res.
+
+**Un procés per tasca, no un contenidor per tasca.** AWX i AAP inicien un pod o un contenidor nou a partir d'una imatge d'execution environment per a
+cada tasca. AnsibleForms no inicia res: el contenidor de l'RTE ja està en marxa, i cada tasca és un procés fill a dins seu. Una tasca comença
+sense descarregar cap imatge ni planificar cap pod, i AnsibleForms no necessita cap permís sobre el teu motor de contenidors o el teu clúster. A canvi, els
+playbooks que s'executen en un RTE en comparteixen la CPU, la memòria, `/tmp`, la carpeta personal i python: dona al contenidor prou recursos per a
+`RTE_MAX_JOBS` playbooks amb els seus forks. Per canviar el que pot fer servir un playbook, canvia la imatge, no la tasca.
+
+---
+
+## El límit de seguretat
+
+L'RTE executa codi que han escrit els autors dels formularis, així que està fet per contenir tan poc com sigui possible:
+
+* **Només el seu token** : l'RTE no té cap credencial de base de dades ni cap `ENCRYPTION_SECRET`. No accepta cap crida tret del sòcol de l'aplicació, amb
+  el seu token, i no té usuaris, ni inici de sessió, ni pàgines web. Pel sòcol només pot executar les tasques que li envia l'aplicació, informar-ne i
+  demanar-ne els fitxers: no pot crear cap tasca, llegir-ne una altra ni repartir credencials
+* **Secrets segellats** : per executar una tasca, l'RTE mai no llegeix la taula de credencials ni cap magatzem de secrets. Rep els secrets de les tasques que
+  executa, segellats només per al seu token i aquell id de tasca, de manera que un paquet pensat per a un altre RTE o una altra tasca no s'obre, i un byte canviat
+  es rebutja
+* **Una connexió comprovada** : en mode sortint, l'RTE comprova el certificat de l'aplicació. En mode entrant per HTTPS, l'aplicació fixa el certificat propi de l'RTE
+  quan s'uneix, i només hi truca quan presenta aquest certificat (vegeu [Modes](modes.html#inbound)). Un RTE entrant per HTTP sense xifrar ha de ser
+  en una xarxa privada, com la del projecte Docker Compose
+* **Cap entorn heretat** : `ansible-playbook` rep l'entorn de l'RTE sense cap de les variables que llegeix el mateix AnsibleForms
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, les `MYSQL_*` i les altres), de manera que
+  `lookup('env', ...)` no hi pot arribar. El que defineixis per als playbooks (`PATH`, proxies, `ANSIBLE_*`) passa tal com és
+* **Cap plantilla dels usuaris** : {% raw %}un valor de formulari que conté `{{`, `{%` o `{#` arriba al playbook com a cadena unsafe{% endraw %}
+  que ansible mai no processa com a plantilla, tret que el formulari defineixi `allowJinjaInExtravars`, i cap shell no executa mai la línia d'ordres
+* **No root** : l'RTE i els seus playbooks s'executen com a `node` (uid 1000), de manera que un playbook pot fer el que pot fer aquest usuari al contenidor, com ara
+  llegir-ne els fitxers i la clau ssh, i res més
+
+Tracta el seu contenidor, la seva imatge i el seu entorn amb la mateixa cura que els de l'aplicació.
+
+---
+
+## Mode base de dades (obsolet)
+
+L'RTE de la 7.0 a la 7.2, sense `RTE_MODE`, funciona durant tota la 7.x i s'elimina a la 8.0.0. Es diferencia dels passos de més amunt en quatre punts:
+
+* **Té la base de dades** : els seus ajustos `DB_*`, i `ENCRYPTION_SECRET` quan es registra ell mateix
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **El lliurament és una crida HTTP** : l'aplicació crida `POST <address>/rte/v1/jobs` amb el token i els secrets segellats, i l'RTE reclama
+  la tasca escrivint-hi el seu nom a la base de dades (passos 3 i 4)
+* **Escriu ell mateix la sortida** : a la base de dades, per lots, sense spool (pas 7). Un avortament li arriba per l'indicador d'avortament de la tasca,
+  que llegeix cada 2 segons, i per una crida `/cancel`
+* **Llegeix els fitxers del volum de l'aplicació** : necessita el mateix disc que l'aplicació, com amb `RTE_FILES=local`
+
+La seva pàgina de runner no té cap dels [ajustos de l'RTE](../runners/runner-page.html#an-rtes-settings): llegeix les seves pròpies variables. Per passar-lo a un
+mode de sòcol, vegeu [Modes](modes.html#database-deprecated).
diff --git a/i18n/ca/_configure/rte/modes.md b/i18n/ca/_configure/rte/modes.md
new file mode 100644
index 0000000..a5a0179
--- /dev/null
+++ b/i18n/ca/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modes
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Com parla un RTE amb l'aplicació
+{: .no_toc }
+
+Sortint, entrant o base de dades: qui obre la connexió, i què hi passa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: des de la 7.3.0 un RTE parla amb l'aplicació per un sol WebSocket i no té cap credencial de base de dades. Tria el mode
+que s'adapti a la xarxa que hi ha entre tots dos: qui pot obrir una connexió cap a qui, i per quins proxies i tallafocs passa.
+
+---
+
+## Els tres modes
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) a l'RTE indica com arriba a l'aplicació; el seu runner té el mateix **Mode**:
+
+| Mode | Qui obre la connexió | Què té l'RTE | Per a |
+|---|---|---|---|
+| `outbound` | L'RTE truca a l'aplicació a [`APP_URL`](../customization/server.html#env_APP_URL) i manté un WebSocket obert | El seu `RTE_TOKEN`, cap credencial de base de dades | Una DMZ, NAT, o una zona que no permet connexions entrants: res no arriba a l'RTE des de fora |
+| `inbound` | L'aplicació truca a l'RTE a l'adreça del seu runner i manté un WebSocket obert | El seu `RTE_TOKEN`, cap credencial de base de dades | Una xarxa on la banda central obre totes les connexions, un projecte compose, un pod |
+| `database` (obsolet) | L'aplicació crida l'API de l'RTE per HTTP, i l'RTE llegeix i escriu ell mateix la base de dades de l'aplicació | Les credencials de la base de dades (`DB_*`) i `ENCRYPTION_SECRET` | El comportament de la 7.0 a la 7.2, eliminat a la 8.0.0 |
+
+Un RTE sense `RTE_MODE` funciona en mode base de dades durant tota la 7.x, i registra un avís `[DEPRECATED] This RTE runs in database mode` en
+arrencar. Un runner afegit abans de la 7.3.0 té el mode **Base de dades (obsolet)**; posa-li el mode en què s'executa el seu RTE quan el migris.
+
+---
+
+## Sortint
+
+L'RTE obre la connexió, així que funciona des d'una xarxa que no accepta cap connexió entrant:
+
+* **El sòcol** : l'RTE truca a `APP_URL` amb `/api/v2/rte/socket` afegit, per `wss://` (`ws://` per a una adreça `http://`), amb el seu
+  `RTE_TOKEN` i el nom del seu runner, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Torna a trucar quan el sòcol cau
+* **La primera vegada** : demana unir-se, i el seu runner espera l'aprovació d'un admin a **Connexions > Runners**, connectat
+  però sense tasques (vegeu [Demanar unir-se](../runners/registration.html#asking-to-join)). Un token d'unió,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), l'aprova a l'instant. A partir d'aleshores inicia sessió amb el seu propi token
+* **La xarxa** : només des de la zona de l'RTE cap a l'aplicació, al port de l'aplicació, a través d'un proxy quan ho indica `HTTPS_PROXY`. Un proxy
+  invers davant de l'aplicació ha de deixar passar el WebSocket en aquest camí (vegeu [WebSockets dels runners](../production/reverse-proxy.html#runner-websockets))
+* **El certificat** : es comprova el certificat de l'aplicació. Indica una CA privada amb `NODE_EXTRA_CA_CERTS`, o, només dins d'una xarxa
+  de confiança, desactiva la comprovació amb [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **El runner** : no necessita cap adreça, així que la seva credencial RTE només conté el token
+* **Preparat** : `/ready` respon `503` fins que el sòcol cap a l'aplicació està obert
+
+Amb diversos nodes d'aplicació darrere d'un balancejador de càrrega, el node al qual arriba l'RTE en té el sòcol. Qualsevol node pot llançar una tasca: el node que té
+el sòcol l'envia a l'RTE, en menys de dos segons quan la tasca s'ha llançat en un altre node.
+
+---
+
+## Entrant
+
+L'RTE escolta al seu `PORT`, i l'aplicació hi truca a l'adreça del seu runner, amb `/rte/v1/socket` afegit i el token de l'RTE. Amb
+diversos nodes d'aplicació, cada vegada només un té el sòcol de cada runner entrant; quan aquest node s'atura, un altre pren el relleu i hi torna a trucar.
+
+L'aplicació necessita el runner de l'RTE abans de poder-hi trucar: tipus RTE, mode **Entrant**, i una credencial RTE amb l'adreça de l'RTE i el seu
+`RTE_TOKEN`. Hi arriba d'una de dues maneres:
+
+| Com | Què cal definir |
+|---|---|
+| L'RTE demana unir-se | `APP_URL` i [`RTE_URL`](../customization/server.html#env_RTE_URL) (l'adreça a la qual truca l'aplicació). L'RTE fa una sola crida, `POST /api/v2/rte/register`, i el seu runner espera l'aprovació d'un admin: l'aplicació hi truca un cop aprovat (vegeu [Demanar unir-se](../runners/registration.html#asking-to-join)). Amb `RTE_JOIN_TOKEN` s'aprova a l'instant. Un RTE entrant amb `APP_URL` però sense `RTE_URL` es nega a arrencar |
+| Afegeixes tu el runner | Sense `APP_URL`: afegeix el runner a **Connexions > Runners**, o a la [llavor de configuració](../seed/), com a [Executar un RTE](run.html#start-it) |
+
+El projecte Docker Compose, el chart de Helm i el controlador de l'instal·lador executen el seu propi RTE d'aquesta manera, entrant, declarat per la llavor.
+
+**Per HTTPS.** Amb [`HTTPS=1`](../customization/server.html#env_HTTPS) l'RTE serveix el seu sòcol per TLS, amb la clau i el certificat
+d'[`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) i [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(`key.pem` i `cert.pem` a la seva carpeta `certificates` per defecte). Un RTE amb un `RTE_URL` `https://` envia aquest certificat quan
+demana unir-se, i l'aplicació el fixa: només truca a l'RTE quan presenta el mateix certificat, de manera que un d'autosignat funciona sense CA.
+L'RTE registra l'empremta del certificat en arrencar (els 8 primers dígits hexadecimals del SHA-256 dels seus bytes DER, com a `abcd-ef12`),
+i el diàleg d'aprovació mostra la que ha rebut l'aplicació: comprova que coincideixen abans d'aprovar-lo.
+L'[instal·lador](../installation/installer.html#a-runner) configura els seus Runners entrants d'aquesta manera, amb un certificat de la seva pròpia adreça.
+
+---
+
+## Base de dades (obsolet)
+
+L'RTE de la 7.0 a la 7.2: l'aplicació crida la seva API per HTTP, i l'RTE reclama la tasca a la base de dades, hi escriu la sortida i manté al dia la seva
+pròpia fila de runner, amb [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Mode base de dades](./#database-mode-deprecated)
+explica en què es diferencien els seus passos. Encara funciona a la 7.x, amb un avís a cada arrencada, i s'elimina a la 8.0.0.
+
+Per passar un RTE d'aquests a un mode de sòcol, conserva el seu runner i el seu token:
+
+1. Un runner de la [llavor de configuració](../seed/): primer defineix-hi `rte_mode: outbound` o `rte_mode: inbound` a la llavor (entrant: amb
+   l'adreça a la qual truca l'aplicació a l'`url` de la seva credencial). L'RTE no pot moure ell mateix un runner de la llavor
+2. A l'RTE, defineix `RTE_MODE=outbound` amb `APP_URL`, o `RTE_MODE=inbound` (amb `APP_URL` i `RTE_URL` per fer la seva única
+   crida de registre), i posa a [`RTE_NAME`](../customization/server.html#env_RTE_NAME) el nom que té el seu runner a
+   **Connexions > Runners**. Conserva el seu `RTE_TOKEN`
+3. Treu `DB_*` i `ENCRYPTION_SECRET` del seu entorn, i `RTE_REGISTER`, que només llegeix el mode base de dades, i després reinicia'l
+
+Quan l'RTE actualitzat inicia sessió amb el nom del runner i el token propi del runner, l'aplicació passa aquest runner al mode de l'RTE a
+l'instant, sense aprovació, i registra *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. El runner ja no és una fila que el seu RTE ha registrat, de manera que el worker no l'elimina mai quan el contenidor antic deixa de respondre. Un
+runner de la llavor de configuració que encara és en mode base de dades es rebutja, en canvi, amb *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. No facis servir un token d'unió per a això: un token
+d'unió es rebutja per a un runner que ja està aprovat. Un RTE entrant sense `APP_URL` no fa cap crida: posa en canvi el **Mode** del seu runner a
+**Entrant** a **Connexions > Runners**, i l'aplicació hi truca. L'[instal·lador](../installation/installer.html#a-72-runner)
+actualitza un Runner de la 7.2 d'aquesta manera.
+
+---
+
+## Què passa pel sòcol
+
+En tots dos modes de sòcol, l'aplicació envia a l'RTE cada tasca amb tot el que l'RTE llegia abans a la base de dades, i desa el que torna,
+la sortida, els esdeveniments, el registre de la tasca i el final, exactament una vegada. L'aplicació també envia les notificacions de final.
+
+**L'spool.** Cada lot de sortida, lot d'esdeveniments, registre, inici i final es numera i s'escriu al fitxer d'spool de la tasca
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) abans d'enviar-se, i es conserva fins que l'aplicació diu que l'ha desat.
+Després d'una reconnexió, al mateix node d'aplicació o a un altre, l'RTE torna a enviar el que no s'havia confirmat, i l'aplicació salta el que ja havia
+desat: no es perd res, i no es desa res dues vegades. Mantén l'spool en un volum, perquè un RTE que es reinicia encara enviï el que no havia
+lliurat. Un playbook que s'estava executant quan l'RTE s'ha reiniciat no pot continuar: la seva tasca acaba com a abandonada.
+
+**Capacitat.** L'RTE executa fins a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks alhora, o el valor definit
+a la seva [pàgina de runner](../runners/runner-page.html#an-rtes-settings), i indica a l'aplicació cada 20 segons quants se n'executen. Una tasca per a un RTE
+ple espera, tal com es descriu a [Diversos RTE](several.html#several-jobs-on-one-rte).
+
+**Els fitxers de la tasca.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES), o l'ajust **Fitxers de treball** de la seva pàgina de runner, indica
+d'on obté l'RTE els playbooks i els inventaris:
+
+| `RTE_FILES` | D'on vénen els fitxers |
+|---|---|
+| `transfer` (predeterminat) | L'aplicació envia la carpeta de playbooks i els inventaris amb la tasca, cadascun empaquetat i anomenat amb un hash del seu contingut. L'RTE els conserva empaquetats sota [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), els darrers utilitzats fins a [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (1024 MB per defecte), i només demana un hash que no té: una carpeta sense canvis no s'envia mai dues vegades. L'RTE no necessita cap disc compartit ni accés als repositoris |
+| `local` | L'RTE s'executa des de les seves pròpies carpetes, com un RTE en mode base de dades: munta-hi els playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) i els repositoris ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) |
+
+Amb `transfer`, cada tasca desempaqueta els seus fitxers en una carpeta privada pròpia, que s'elimina quan la tasca acaba: cap tasca no veu el que una altra
+ha escrit, i cap fitxer d'inventari o d'extravars no queda desempaquetat al disc de l'RTE. Els RTE poden compartir un mateix `RTE_CACHE_PATH`; cadascun conserva les seves tasques en
+una carpeta pròpia, i els altres eliminen la carpeta d'un RTE que s'ha aturat (mort a mitja tasca, o recreat amb un altre nom de host)
+al cap de 10 minuts. Una carpeta més gran que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 per defecte, la llegeix
+l'aplicació i s'aplica sense reiniciar) no s'envia: la tasca falla i diu que cal muntar la carpeta a l'RTE. La carpeta ssh no s'envia mai: l'RTE conserva la seva pròpia
+clau privada i el seu `known_hosts` a `/home/node/.ssh`.
+
+**Hosts i tasques.** Des de la 7.3.0, un RTE en qualsevol mode registra els esdeveniments estructurats d'un playbook al costat de la seva sortida de text: cada play, task i
+resultat de host, i el resum, escrits pel seu plugin de callback `af_events`. La pàgina de la tasca els mostra a **Hosts i tasques** (vegeu
+[Seguir una tasca](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Xarxa
+
+Què cal obrir entre l'aplicació, l'RTE i els hosts gestionats, per mode:
+
+| Mode | Des de | Cap a | Port |
+|---|---|---|---|
+| Sortint | L'RTE | L'aplicació, a `APP_URL` | El port de l'aplicació (`443` darrere de la majoria de proxies) |
+| Entrant | Els nodes d'aplicació | L'RTE, a l'adreça del seu runner | El `PORT` de l'RTE (`8000`) |
+| Base de dades (obsolet) | L'RTE, i els nodes d'aplicació i el worker | La base de dades, i l'RTE | `3306`, i el `PORT` de l'RTE |
+| Tots els modes | L'RTE | Els hosts gestionats | ssh (`22`), WinRM, les seves API |
+
+En un mode de sòcol l'RTE no es connecta mai a la base de dades. La seva API només respon al sòcol i a les sondes: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/ca/_configure/rte/run.md b/i18n/ca/_configure/rte/run.md
new file mode 100644
index 0000000..e5ed2ce
--- /dev/null
+++ b/i18n/ca/_configure/rte/run.md
@@ -0,0 +1,163 @@
+---
+layout: default
+title: Executar un RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Executar un RTE
+{: .no_toc }
+
+Els ajustos de cada mode, i com iniciar un RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ajustos
+
+El que necessita un RTE depèn del seu mode (vegeu [Modes](modes.html)). Tots els RTE llegeixen aquests:
+
+| Variable | Significat |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Des de la 7.3.0: `outbound` (truca a l'aplicació), `inbound` (l'aplicació li truca) o `database` (obsolet, el predeterminat durant tota la 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | El token entre l'aplicació i l'RTE, d'almenys 16 caràcters; l'RTE es nega a arrencar sense ell |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quants playbooks executa alhora, `10` per defecte (`0` no posa cap límit). Una tasca per a un RTE ple espera fins que acaba un playbook |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | En aturar-se, quant de temps espera els seus playbooks en execució, `25` per defecte; els que encara s'executen llavors acaben com a abandonats |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | La llegeixen els nodes d'aplicació i el worker, no l'RTE: quant de temps espera una tasca un RTE ple o que s'està aturant, `60` per defecte |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | La carpeta de playbooks i el límit de sortida: les llegeix l'RTE, així que defineix-les al seu entorn |
+| `LISTEN_HOST` | Des de la 7.3.0: l'adreça on escolten els seus listeners, totes les interfícies per defecte; `127.0.0.1` quan res no li truca des de fora (un RTE sortint) |
+
+Un RTE en un mode de sòcol, `outbound` o `inbound`, també llegeix aquests, i cap `DB_*` ni cap `ENCRYPTION_SECRET`:
+
+| Variable | Significat |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'adreça de l'aplicació tal com l'obre la gent, com ara `https://forms.example.com`. Sortint: l'adreça a la qual truca. Entrant: l'adreça de la seva única crida de registre |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (predeterminat): el certificat de l'aplicació ha de ser vàlid. `0` n'accepta qualsevol, només dins d'una xarxa de confiança |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | El nom del seu runner, el que els formularis nomenen amb `runner:`. Si no es defineix: el seu id de node, `rte-<hostname>-<port>`, que canvia amb el contenidor: defineix-lo en producció |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcional, només la primera vegada: un token d'unió, creat a través de l'API, que aprova el seu runner a l'instant en lloc d'esperar un admin (vegeu [Tokens d'unió](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Entrant, quan demana unir-se: l'adreça a la qual truca l'aplicació, com ara `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predeterminat): l'aplicació envia els playbooks i els inventaris amb la tasca. `local`: s'executa des de les seves pròpies carpetes muntades |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | On esperen la sortida, els esdeveniments i el final de cada tasca fins que l'aplicació els ha desat, `<persistent>/rte-spool` per defecte: mantén-lo en un volum |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Amb `transfer`: on es conserven les carpetes que ha enviat l'aplicació, `<persistent>/rte-files` per defecte |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Amb `transfer`: quant poden ocupar aquestes carpetes, `1024` per defecte; primer surten les que fa més temps que no es fan servir, i `0` no en conserva cap |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | La llegeix l'aplicació, no l'RTE: la carpeta més gran que envia amb `transfer`, `512` per defecte |
+
+En un RTE en un mode de sòcol, `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` i `RTE_CACHE_MB` també es poden definir a la seva pàgina de runner,
+a la pestanya RTE: un valor definit allà guanya a la variable, que llavors només omple un camp deixat buit (vegeu
+[La configuració d'un RTE](../runners/runner-page.html#an-rtes-settings)). Un valor fora de rang es porta al seu límit, i l'RTE ho indica
+quan arrenca.
+
+Un RTE en mode base de dades (obsolet) llegeix en canvi els ajustos de la base de dades, i es registra ell mateix:
+
+| Variable | Significat |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Els mateixos valors que l'aplicació: l'RTE llegeix les seves tasques de la base de dades i hi escriu la sortida |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | L'adreça on l'aplicació crida l'RTE, com ara `http://rte:8000`. El runner rep el nom del seu host (`rte`), de manera que els formularis poden fer servir `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Obsolet a la 7.3.0, juntament amb el mode base de dades: un RTE en mode de sòcol s'uneix amb un token d'unió. `1` (predeterminat): l'RTE s'afegeix ell mateix a **Connexions > Runners** en arrencar, i el primer passa a ser el runner predeterminat. `0`: afegeix-lo tu mateix allà, o a la [llavor de configuració](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | El mateix valor que l'aplicació, necessari només per registrar-se ell mateix (el token del runner es desa xifrat); deixa'l fora amb `RTE_REGISTER=0` |
+
+En mode base de dades, sense `RTE_URL` l'RTE registra la seva adreça IP i el seu port amb el nom `rte-<hostname>-<port>`, que canvien quan
+es recrea el contenidor: defineix `RTE_URL` en producció. El worker elimina un runner que l'RTE ha registrat ell mateix 10 minuts després del
+darrer heartbeat de l'RTE.
+
+---
+
+## Iniciar-lo
+
+L'RTE executa els playbooks, així que necessita la seva carpeta ssh, amb la clau privada i el `known_hosts` que fan servir els playbooks, i una carpeta
+persistent per al seu spool i els fitxers que envia l'aplicació. Tria el mode:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Sortint</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Entrant</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Base de dades (obsolet)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Inicia l'RTE en qualsevol host que arribi a l'aplicació, amb el seu propi token i el nom que rebrà el seu runner:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Truca a l'aplicació i demana unir-se: **Connexions > Runners** mostra el runner `rte-dmz` pendent d'aprovació, i el seu registre mostra
+l'empremta del seu token. Comprova que la revisió mostra la mateixa empremta, i després fes clic a **Aprova** (vegeu
+[Aprovar un RTE](../runners/registration.html#approving-an-rte)): a partir d'aleshores rep tasques, i inicia sessió amb el seu propi `RTE_TOKEN`.
+Per a un inici desatès, afegeix `-e RTE_JOIN_TOKEN=<a join token, afj_...>`, que l'aprova a l'instant. Res no ha d'arribar a aquest
+host: no publiquis cap port. Al seu `PORT` només escolten `/live`, `/ready` i `/metrics`, per a les sondes.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Inicia l'RTE on hi arribi l'aplicació. Aquest s'executa al costat de l'aplicació i executa els playbooks des de les seves carpetes (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Després dona a l'aplicació el seu runner: a la [llavor de configuració](../seed/), una credencial RTE i un runner entrant que hi inicia sessió:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+O afegeix aquests dos a mà: la credencial a **Connexions > Credencials**, de tipus RTE, i el runner a
+**Connexions > Runners**, de tipus RTE, mode **Entrant**, amb aquesta credencial. Per deixar que l'RTE demani unir-se, inicia'l amb
+`APP_URL` i `RTE_URL`, i aprova'l a **Connexions > Runners** (vegeu [Entrant](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Obsolet des de la 7.3.0 i eliminat a la 8.0.0. L'RTE executa els playbooks des del seu propi disc, així que munta-hi també el volum persistent de l'aplicació
+(playbooks, repositoris, fitxers pujats) i la seva carpeta ssh. Un exemple amb Docker, amb l'aplicació accessible com a `ansibleforms` a la
+mateixa xarxa:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Mantén un RTE entrant fora de la xarxa pública: el seu sòcol respon a qualsevol que tingui el token. `docker stop` només espera 10 segons abans
+de matar un contenidor, així que dona a l'RTE un temps d'aturada més llarg (`--stop-timeout`, o `stop_grace_period` a compose) o redueix
+`RTE_DRAIN_SECONDS`. Kubernetes espera 30 segons per defecte.
+
+L'[instal·lador](../installation/installer.html) configura un RTE sortint o entrant en un servidor propi, amb Docker, Podman o
+[sense contenidors](../installation/native.html), i mostra l'empremta amb què s'ha d'aprovar. Per executar a mà un RTE en un altre centre de dades,
+segueix [Un altre centre de dades](another-datacenter.html).
+
diff --git a/i18n/ca/_configure/rte/several.md b/i18n/ca/_configure/rte/several.md
new file mode 100644
index 0000000..17addca
--- /dev/null
+++ b/i18n/ca/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Diversos RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Diversos RTE
+{: .no_toc }
+
+Quants playbooks executa un RTE, més RTE com a runners o rèpliques, i què passa quan un s'atura o mor
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Diverses tasques en un RTE
+
+Un RTE executa fins a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks en paral·lel, 10 per
+defecte (`0` no posa cap límit). Una tasca per a un RTE ple no es reclama. En un mode de sòcol l'aplicació no l'envia mentre el darrer
+informe de salut de l'RTE no mostri cap espai lliure, i un RTE ple o que s'està aturant respon `refused` com a ocupat; en mode base de dades l'RTE respon
+`503`. En tots dos casos l'aplicació escriu `Waiting for a free slot on RTE <name>` una vegada a la sortida i torna a oferir la tasca cada 10 segons,
+durant [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) com a màxim (60 per defecte). Llavors la tasca falla amb
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Una tasca avortada mentre espera acaba `aborted` sense arribar mai
+a l'RTE.
+
+---
+
+## Diversos RTE
+
+L'aplicació no reparteix tota sola les tasques entre els runners: cada tasca va a un runner, el que nomena el formulari o el
+predeterminat. Més contenidors RTE ajuden de dues maneres:
+
+* **Com a runners propis** : cada RTE té el seu propi `RTE_NAME` i s'uneix com a runner propi: demana unir-se i un admin
+  l'aprova, o presenta un token d'unió (vegeu [Registre](../runners/registration.html)). Un formulari en tria un amb `runner: <name>`,
+  per exemple un RTE amb les col·leccions de VMware, o un en una altra zona de xarxa; els altres s'executen a l'RTE predeterminat
+* **Com a rèpliques darrere d'una adreça** (només en mode base de dades) : diversos contenidors RTE amb el mateix `RTE_URL` i el mateix `RTE_TOKEN`,
+  com ara els pods darrere d'un Service de Kubernetes, comparteixen un runner, i l'adreça reparteix les crides entre ells. Una rèplica plena respon
+  `503`, i el següent intent pot anar a parar a una altra. L'aplicació segueix una tasca a través de la base de dades, així que no importa quina rèplica
+  respon a les seves crides d'estat
+
+En un mode de sòcol (vegeu [Modes](modes.html)) un runner té un sòcol amb un RTE, i un segon RTE que inicia sessió amb el mateix
+`RTE_NAME` pren el sòcol al primer. Dona a cada RTE un nom i un runner propis, i deixa que els formularis triïn entre ells amb
+`runner:`.
+
+Cada RTE en mode base de dades escriu un heartbeat a la base de dades cada 10 segons, i un que es registra ell mateix comprova la seva fila de runner cada
+30 segons. Per a un RTE en un mode de sòcol, el node d'aplicació que té el seu sòcol hi escriu el heartbeat cada 20 segons, mentre el
+sòcol està obert. La pàgina **Estat** llista tots els RTE amb la seva versió. El worker elimina un runner que un RTE en mode base de dades ha registrat
+ell mateix quan aquest RTE fa 10 minuts que no escriu cap heartbeat, i quan el runner predeterminat és una fila d'aquestes l'RTE de la qual s'ha aturat, el següent RTE
+que fa la comprovació passa a ser el predeterminat. Un runner de la llavor de configuració, afegit a mà o unit per un sòcol no s'elimina mai d'aquesta manera.
+
+---
+
+## Quan un RTE s'atura o mor
+
+**Quan un RTE s'atura.** Amb `SIGTERM` (`docker stop`, una actualització progressiva, una reducció d'escala) l'RTE deixa d'acceptar tasques: `/ready` respon `503`,
+i una tasca nova es rebutja com a ocupat (`503` en mode base de dades), de manera que l'aplicació espera, o en mode base de dades l'adreça l'envia a una altra
+rèplica. Els playbooks en execució tenen [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) per acabar, 25 per defecte,
+i després l'RTE surt.
+
+**Quan un RTE mor.** Un contenidor que es mata (sense memòria, un node perdut, el final del temps d'aturada) s'emporta els seus playbooks: res no
+els passa a un altre RTE, i res no els torna a executar. Les seves tasques s'acaben com a `abandoned`, per part del mateix RTE o de l'aplicació quan
+torna amb el mateix id, que un contenidor reiniciat conserva (`rte-<hostname>-<port>`), o per part del worker, quan el heartbeat de l'RTE
+té dos minuts. Comprova als hosts gestionats què ha fet el playbook abans de tornar-lo a llançar.
+
+**Mentre un RTE no funciona.** En un mode de sòcol una tasca nova per a aquest RTE espera el seu sòcol, fins a `RTE_QUEUE_MINUTES` i un minut més, i després
+falla amb *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+En mode base de dades falla a l'instant amb *the RTE at ... is unreachable*, tret que una altra rèplica respongui a la seva adreça.
diff --git a/i18n/ca/_configure/runners.md b/i18n/ca/_configure/runners.md
new file mode 100644
index 0000000..cf0899b
--- /dev/null
+++ b/i18n/ca/_configure/runners.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Runners
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runners
+{: .no_toc }
+
+On s'executen les tasques: contenidors d'entorn d'execució per als playbooks, i AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins per a les plantilles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: afegeix els runners on s'executen les teves tasques, tria el predeterminat de cada tipus, aprova els RTE que demanen unir-se i prova'ls.
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [La pàgina de runners](runners/list.html) | La llista de runners, com afegir-ne un, com activar-lo o desactivar-lo, i el predeterminat de cada tipus |
+| [Tipus de runner](runners/types.html) | Els productes que pot ser un runner, la seva adreça i el seu accés |
+| [Registre](runners/registration.html) | Com un RTE demana unir-se i s'aprova, els tokens d'unió per a instal·lacions desateses, i el mode base de dades |
+| [La pàgina d'un runner](runners/runner-page.html) | Les pestanyes d'un runner, el mode i la connexió d'un RTE, i Prova la connexió |
+| [Qui gestiona els runners](runners/permissions.html) | Qui pot afegir, canviar i provar runners |
+
+
+---
+
+## Com funciona
+
+Des de la versió 7 l'aplicació no executa res ella mateixa: totes les tasques s'executen en un **runner**, afegit a **Connexions > Runners**.
+El tipus d'un formulari decideix quin tipus de runner necessita:
+
+| Tipus de formulari | S'executa en un runner de tipus | Què s'executa |
+|---|---|---|
+| `ansible` | RTE | Un playbook, en un contenidor d'entorn d'execució |
+| `awx`, `aap`, `ascender` | AWX (les variants AWX, AAP i Ascender) | Una plantilla de tasca o de workflow |
+| `semaphore` | Semaphore | Una plantilla de Semaphore UI |
+| `rundeck` | Rundeck | Una tasca de Rundeck |
+| `jenkins` | Jenkins | Una tasca de Jenkins |
+
+Un formulari `workflow` o `subform` no té runner propi: cada node d'un [workflow](workflows/) tria el seu. Un node
+amb un `runner:` s'executa en aquell runner (un RTE, o una plantilla o una tasca a AWX, Semaphore, Rundeck o Jenkins), i qualsevol altre a
+l'RTE predeterminat, de manera que els nodes d'una mateixa tasca es poden executar en runners diferents. El formulari `multistep`, obsolet des de la 7 i
+substituït pels workflows, funciona igual: cadascun dels seus passos s'executa al runner que necessita el seu propi tipus.
+
+Un formulari tria el seu runner d'una de dues maneres:
+
+- **Pel nom**: `runner: <name>` al formulari, en un node de workflow, o en un pas d'un multistep obsolet (també a la
+  configuració del formulari al dissenyador). El runner ha de ser del tipus que necessita el formulari, o la tasca falla. L'antic `awx: <name>`
+  encara funciona, registra un avís d'obsolescència, i desapareix a la 8.
+- **Com a predeterminat**: un formulari que no nomena cap runner s'executa al runner predeterminat del seu tipus. Si no n'hi ha, la tasca falla
+  amb un missatge que indica quin tipus de runner cal afegir.
+
+Un runner desactivat a **Connexions > Runners** no rep cap tasca, ni pel nom ni com a predeterminat: la tasca falla i diu que cal activar-lo
+o nomenar un altre runner (vegeu [Predeterminat i Activat](runners/list.html#default-and-enabled)).
+
+
diff --git a/i18n/ca/_configure/runners/list.md b/i18n/ca/_configure/runners/list.md
new file mode 100644
index 0000000..4caf5bc
--- /dev/null
+++ b/i18n/ca/_configure/runners/list.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: La pàgina de runners
+parent: Runners
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# La pàgina de runners
+{: .no_toc }
+
+La llista de runners, com afegir-ne un, com activar-lo o desactivar-lo, i el predeterminat de cada tipus
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La llista
+
+La pàgina de **Connexions > Runners** llista tots els runners amb aquestes columnes:
+
+| Columna | Significat |
+|---|---|
+| Activat | Si rep tasques. Un runner desactivat no rep cap tasca, ni tan sols com a predeterminat del seu tipus. |
+| Nom | Com el nomenen els formularis, amb `runner: <name>`. |
+| Tipus | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck o Jenkins. El runner predeterminat del seu tipus té una etiqueta **Predeterminat** al darrere. |
+| Descripció | Per a què serveix. |
+
+**Columnes** n'afegeix dues més, desactivades per defecte: **Mode**, el mode d'un RTE (Sortint, Entrant o Base de dades (obsolet), vegeu
+[Modes](../rte/modes.html)), i **Connexió**, si un node d'aplicació té un sòcol amb un RTE en un mode de sòcol: **Connectat** o
+**No connectat**.
+
+Des de la 7.3.0 els runners pendents d'aprovació no són a la llista sinó en un avís damunt seu, vegeu [Aprovar un RTE](registration.html#approving-an-rte).
+**Afegeix runner** obre un diàleg per passos: **Runner** (nom i descripció), **Tipus** i **Credencials**, amb un pas **Mode** després de
+**Tipus** per a un RTE (Sortint, el predeterminat per a un de nou, Entrant o Base de dades (obsolet)): quatre passos per a un RTE, tres per als
+altres. Al pas **Tipus** cada producte té una pista: la de l'RTE en dona el nom complet, *Entorn d'execució*. Una fila obre la pàgina
+pròpia del runner, i el seu menú ofereix:
+
+| Acció | Què fa |
+|---|---|
+| Edita | Obre la seva pàgina |
+| Prova la connexió | Comprova que respon i que accepta la seva credencial, vegeu [Prova la connexió](runner-page.html#test-connection) |
+| Activa, Desactiva | L'activa o el desactiva, segons el que no estigui |
+| Canvia les credencials | Obre la pestanya Credencials de la seva pàgina |
+| Suprimeix | L'elimina |
+
+---
+
+## Predeterminat i Activat
+
+El predeterminat de cada tipus és on s'executen els formularis d'aquest tipus quan no nomenen cap runner:
+
+| Predeterminat per a | On s'executen aquests formularis quan no nomenen cap runner |
+|---|---|
+| Formularis de playbook | Els formularis `ansible`, en un RTE |
+| Formularis AWX, AAP i Ascender | Els formularis `awx`, `aap` i `ascender`, en un runner AWX |
+| Formularis Semaphore | Els formularis `semaphore` |
+| Formularis Rundeck | Els formularis `rundeck` |
+| Formularis Jenkins | Els formularis `jenkins` |
+
+El primer runner d'un tipus passa a ser-ne el predeterminat, de manera que un sol runner per tipus no necessita cap pas addicional. Per fer que un altre runner sigui el predeterminat,
+activa l'interruptor **És el predeterminat** a la seva pàgina (vegeu [La pàgina d'un runner](runner-page.html)).
+
+Un runner desactivat continua llistat amb els seus ajustos, però no hi va cap tasca, tampoc com a predeterminat del seu tipus. Una tasca per a ell falla amb
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Activa'l o desactiva'l amb **Activa** o **Desactiva** al menú de la seva fila, o amb l'interruptor **Activat** a la seva pàgina. Un runner nou està activat, i els
+runners que existien abans de la 7.3.0 estan activats després de l'actualització. La [llavor de configuració](../seed/example.html) en pot desactivar un amb
+`enabled: false`.
+
diff --git a/i18n/ca/_configure/runners/permissions.md b/i18n/ca/_configure/runners/permissions.md
new file mode 100644
index 0000000..a902ddf
--- /dev/null
+++ b/i18n/ca/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Qui gestiona els runners
+parent: Runners
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Qui gestiona els runners
+{: .no_toc }
+
+Qui pot afegir, canviar i provar runners
+{: .fs-6 .fw-300 }
+
+Un runner rep les credencials de totes les tasques que executa, així que només el rol **admin** afegeix, canvia, activa o desactiva i suprimeix runners,
+i aprova o rebutja un RTE que ha demanat unir-se. Els usuaris amb accés a la configuració els veuen i els poden provar, però no els poden canviar.
+
+Un runner declarat a la [llavor de configuració](../seed/) és només de lectura en aquesta pàgina: canvia'l al fitxer de la llavor.
diff --git a/i18n/ca/_configure/runners/registration.md b/i18n/ca/_configure/runners/registration.md
new file mode 100644
index 0000000..8c2bd5f
--- /dev/null
+++ b/i18n/ca/_configure/runners/registration.md
@@ -0,0 +1,124 @@
+---
+layout: default
+title: Registre
+parent: Runners
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Registre
+{: .no_toc }
+
+Com un RTE demana unir-se i s'aprova, els tokens d'unió per a instal·lacions desateses, i el mode base de dades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Demanar unir-se
+
+Des de la 7.3.0, un RTE en un mode de sòcol (`outbound` o `inbound`) que l'aplicació encara no coneix demana unir-se, i un admin l'aprova.
+Es presenta amb el seu propi `RTE_TOKEN` i el seu `RTE_NAME`: un RTE sortint quan truca per primer cop a l'aplicació, un d'entrant en la seva única
+crida de registre. Sense token d'unió, l'aplicació llavors:
+
+1. Desa l'`RTE_TOKEN` de l'RTE en una credencial nova de tipus RTE anomenada `<name>-rte` (amb un número afegit quan aquest nom ja està agafat), i
+   per a un RTE entrant la seva adreça, `RTE_URL`
+2. Afegeix un runner amb el nom de l'`RTE_NAME`, de tipus RTE, en el mode de l'RTE, que inicia sessió amb aquesta credencial, marcat com a **Pendent d'aprovació**
+   i desactivat. La seva descripció indica l'host des d'on ho ha demanat
+
+Un RTE sortint es manté connectat mentre espera, però no rep cap tasca. L'aplicació no truca a un d'entrant fins que no està aprovat. Tots dos registren
+que esperen que un admin els aprovi a **Connexions > Runners**, amb l'empremta del seu token.
+
+Un RTE entrant amb un `RTE_URL` `https://` també envia el seu certificat quan demana unir-se, i l'aplicació el fixa: a partir d'aleshores
+l'aplicació només truca a aquest RTE quan presenta el mateix certificat, de manera que un d'autosignat funciona sense CA (vegeu [Entrant](../rte/modes.html#inbound)).
+
+Com a màxim hi pot haver 20 RTE esperant aprovació alhora: els altres es rebutgen fins que se n'aprovin o rebutgin alguns. Una sol·licitud que ningú no gestiona en
+24 hores l'elimina el worker, juntament amb la seva credencial.
+
+Un RTE amb el nom d'un runner que l'aplicació ja coneix, però amb un altre token, es rebutja i no demana unir-se. Dona-li el token d'aquell
+runner, o suprimeix el runner perquè demani unir-se. Un [token d'unió](#join-tokens) només ajuda mentre aquell runner encara espera aprovació.
+
+---
+
+## Aprovar un RTE
+
+Els runners pendents d'aprovació surten de la llista de **Connexions > Runners** i passen a un avís taronja damunt seu, com ara
+**2 Runners esperen aprovació**, amb una línia per runner: el seu nom, host, adreça IP, mode, adreça i empremta.
+La campana de la capçalera els compta, per als usuaris que poden veure els runners (vegeu [la campana](../jobs/#the-jobs-page)).
+
+Un clic a l'avís obre el diàleg **Revisar l'aprovació** per a cada runner, un rere l'altre; un clic en un nom obre només aquell.
+La seva pàgina mostra les mateixes dades en un requadre groc, **Aquest RTE ha demanat unir-se**. Comprova que és un que has iniciat tu abans d'aprovar-lo:
+
+| Camp | Què mostra |
+|---|---|
+| Empremta | Els 8 primers dígits hexadecimals del SHA-256 del seu `RTE_TOKEN`, com a `abcd-ef12`. L'RTE la registra en arrencar, i l'[instal·lador](../installation/installer.html#a-runner) la mostra al final. Ha de ser la mateixa |
+| Empremta del certificat | Al diàleg, per a un RTE entrant per HTTPS: els 8 primers dígits hexadecimals del SHA-256 del certificat que fixa l'aplicació (els seus bytes DER), com a `abcd-ef12`. L'RTE la registra en arrencar i l'[instal·lador](../installation/installer.html#a-runner) la mostra al final. Ha de ser la mateixa |
+| Host | L'host on s'executa |
+| Adreça IP | L'adreça des d'on ha trucat a l'aplicació |
+| Mode | Sortint o Entrant |
+| URI | L'adreça d'un RTE entrant, on hi truca l'aplicació |
+| Versió | La seva versió |
+| Sol·licitat el | Quan ha demanat unir-se |
+
+**Aprova** i **Rebutja**, al diàleg o al requadre de la seva pàgina, decideixen:
+
+| Acció | Què passa |
+|---|---|
+| Aprova | El runner s'activa i rep tasques a partir d'ara. Passa a ser el predeterminat del seu tipus quan no n'hi ha cap |
+| Rebutja | El runner s'elimina juntament amb la seva credencial, i el seu sòcol es tanca. L'RTE pot tornar a demanar unir-se; llavors torna a esperar aprovació |
+
+Només un admin aprova o rebutja un RTE.
+
+---
+
+## Tokens d'unió
+
+Un token d'unió aprova un RTE a l'instant, per a instal·lacions desateses: un RTE iniciat amb
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), o un Runner instal·lat amb el `--join` de l'instal·lador, el presenta una vegada
+i el seu runner s'afegeix activat, sense esperar. Els tokens d'unió no tenen cap pàgina a la interfície: un admin els crea a través de
+l'[API REST](../api/), sota `/api/v2/runner`:
+
+| Crida | Què fa |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Crea un token d'unió. El cos conté el seu `name`, i opcionalment `expiresInHours` (cap: no caduca mai) i `maxUses` (cap: qualsevol nombre d'RTE) |
+| `GET /api/v2/runner/jointoken` | Llista els tokens d'unió, el més nou primer, amb els seus usos i si encara es poden fer servir; mai els tokens en si |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | El revoca: ja no afegeix cap runner, i es queda a la llista |
+| `DELETE /api/v2/runner/jointoken/<id>` | El suprimeix |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+La resposta conté el token, que comença per `afj_`, aquesta única vegada: només se'n desa el SHA-256. Un RTE que el presenta rep la mateixa
+credencial i el mateix runner que un que [demana unir-se](#asking-to-join), activat, i la seva descripció nomena el token d'unió. A partir d'aleshores l'RTE
+inicia sessió amb el seu propi token, de manera que el token d'unió pot caducar o revocar-se sense afectar-lo. Revocar o suprimir un token d'unió
+no elimina els runners que ha afegit.
+
+Un token d'unió mai no dona un token nou a un runner aprovat. Quan ja existeix un runner RTE amb aquest nom:
+
+| El runner | Què passa |
+|---|---|
+| Espera aprovació | Rep el token nou a la seva credencial, i continua esperant l'aprovació d'un admin |
+| Està aprovat | Es rebutja amb `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. El token d'unió no es gasta |
+| Ve de la [llavor de configuració](../seed/) | Es rebutja: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Per tant, un RTE que s'ha tornat a instal·lar amb un token nou inicia sessió amb el token de la credencial del seu runner, o bé un admin canvia aquest token
+a **Connexions > Credencials**, o suprimeix el runner perquè l'RTE s'uneixi com a nou.
+
+---
+
+## Registre en mode base de dades
+
+Un RTE en mode base de dades, obsolet des de la 7.3.0, es registra ell mateix per defecte, al seu `RTE_URL` o, si no, a la seva pròpia adreça i port. El
+worker elimina un runner d'aquests quan el seu RTE fa 10 minuts que no escriu cap heartbeat. Un runner afegit a mà, per la llavor de configuració o per un
+RTE en un mode de sòcol no s'elimina mai d'aquesta manera.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), que activa o desactiva aquest registre, és obsolet a la 7.3.0 juntament amb el
+mode base de dades: un RTE en un mode de sòcol demana unir-se, o s'uneix amb un token d'unió. Per gestionar tu mateix aquests runners mentrestant, inicia
+l'RTE amb `RTE_REGISTER=0` i afegeix-lo aquí amb el tipus RTE, el mode **Base de dades (obsolet)**, i una credencial RTE amb la seva adreça i el
+mateix token. Per passar-lo a un mode de sòcol, vegeu [Modes](../rte/modes.html#database-deprecated).
+
diff --git a/i18n/ca/_configure/runners/runner-page.md b/i18n/ca/_configure/runners/runner-page.md
new file mode 100644
index 0000000..8f663a9
--- /dev/null
+++ b/i18n/ca/_configure/runners/runner-page.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: "La pàgina d'un runner"
+parent: Runners
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# La pàgina d'un runner
+{: .no_toc }
+
+Les pestanyes d'un runner, el mode, la connexió i la configuració d'un RTE, i Prova la connexió
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pestanyes
+
+La pàgina d'un runner mostra els passos del seu diàleg com a pestanyes, més el que s'hi executa:
+
+| Pestanya | Què conté |
+|---|---|
+| Detalls | El nom i la descripció, l'interruptor **És el predeterminat** i l'interruptor **Activat**, iguals per a tots els tipus de runner |
+| Tipus | El producte, com al diàleg. Per a un RTE també el seu **Mode**: **Base de dades (obsolet)**, **Entrant** o **Sortint**, l'`RTE_MODE` amb què s'executa el seu RTE (vegeu [Modes](../rte/modes.html)) |
+| RTE | Només per a un RTE: el seu **Mode** en paraules i, en un mode de sòcol, la seva **Connexió** i la seva configuració (vegeu [La configuració d'un RTE](#an-rtes-settings)) |
+| Credencials | La **Credencial** amb què inicia sessió, una credencial de Connexions > Credencials del tipus del runner, que conté el seu token o accés i l'adreça del seu servidor. La d'un RTE conté el seu `RTE_TOKEN`, i l'adreça de l'RTE tret que sigui sortint. **Projecte** per a Semaphore, Rundeck i Jenkins |
+| Formularis | Els formularis que s'hi executen, i com: **El nomena** o **Com a runner per defecte**. Una fila obre el formulari |
+| Tasques | Les 100 darreres tasques que s'hi han executat, amb el seu estat, inici, final i durada. Una fila obre la tasca |
+
+Cada pestanya té la seva pròpia adreça, com ara `/settings/runners/<id>/rte`, de manera que un enllaç o una adreça d'interès l'obre. Un runner sense aquesta pestanya s'obre a
+Detalls.
+
+Els dos interruptors de la pestanya Detalls es desen a l'instant. **És el predeterminat** fa que el runner sigui el predeterminat del seu tipus; es desactiva fent
+que un altre runner sigui el predeterminat. **Activat** activa o desactiva el runner: desactivat, no hi va cap tasca, tampoc com a predeterminat del seu tipus (vegeu
+[Predeterminat i Activat](list.html#default-and-enabled)).
+
+Un RTE que ha demanat unir-se s'obre amb un requadre groc, **Aquest RTE ha demanat unir-se**, amb la seva empremta i el que ha dit de si mateix, i
+**Aprova** i **Rebutja** (vegeu [Aprovar un RTE](registration.html#approving-an-rte)). Un runner de la [llavor de configuració](../seed/) ho indica
+a la part superior de la seva pàgina, i és només de lectura.
+
+---
+
+## La configuració d'un RTE
+
+La pestanya RTE gestiona un RTE des de l'aplicació, sense editar-ne l'entorn a la màquina on s'executa.
+
+**Connexió.** Un RTE en un mode de sòcol mostra una insígnia: **Connectat** o **No connectat**. En passar-hi el punter, **Connectat** mostra el node d'aplicació
+que té el seu sòcol, la versió de l'RTE, i quantes de les seves tasques s'executen. **No connectat** vol dir que cap node d'aplicació no hi té un sòcol:
+comprova que l'RTE s'executa, la seva adreça o `APP_URL`, i el seu token.
+
+**Configuració.** Un RTE en mode sortint o entrant té quatre ajustos, cadascun buit per defecte:
+
+| Ajust | El mateix que | Què fa |
+|---|---|---|
+| Màxim de treballs simultanis | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quants playbooks executa alhora, `10` per defecte; `0` no posa cap límit |
+| Memòria cau de fitxers | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Quant dels fitxers de tasca que li ha enviat l'aplicació conserva, en MB, `1024` per defecte; `0` no en conserva cap |
+| Temps d'espera en aturar | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Quant de temps espera un RTE que s'atura els seus playbooks en execució, `25` segons per defecte |
+| Fitxers de treball | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Transferència**: l'aplicació envia els fitxers d'una tasca amb la tasca. **Local**: s'executa des de les seves pròpies carpetes muntades |
+
+**Quin valor guanya.** Un valor a la pàgina guanya a la mateixa variable definida a l'RTE. Un camp deixat buit fa servir la variable pròpia de l'RTE,
+o si no el valor predeterminat. Sota cada camp la pàgina indica quin: **Substitueix RTE_MAX_JOBS definida a l'RTE (3).**, o **Buit: l'RTE fa servir la seva
+RTE_MAX_JOBS, 3.**; el text indicatiu mostra el valor que representa un camp buit.
+
+**Com arriben a l'RTE.** Els ajustos es desen amb el runner a la base de dades de l'aplicació. L'aplicació els envia pel sòcol de l'RTE
+quan es connecta i cada vegada que es desen, i l'RTE els aplica a l'instant: una memòria cau més petita es retalla, un límit nou compta a partir de la
+tasca següent. L'RTE només els conserva a la memòria i no escriu cap fitxer: després d'un reinici els torna a rebre en connectar-se, abans de la seva primera tasca.
+
+Un RTE en mode base de dades (obsolet) no té sòcol: llegeix aquests ajustos de les seves pròpies variables, i la pestanya ho indica.
+
+---
+
+## Prova la connexió
+
+Els botons de dalt a la dreta actuen sobre el runner tal com està desat.
+
+Al costat de **Desa** hi ha **Prova la connexió** i **Suprimeix**, i a la pestanya Credencials **Afegeix una credencial**, que crea una credencial del
+tipus del runner i la tria. Un token o una contrasenya no es tornen a mostrar mai un cop desats: canvia'ls a la credencial.
+
+**Prova la connexió** comprova que el runner respon i que accepta el seu token o accés, i ho indica en un missatge: **Runner connection is
+OK**, o per què ha fallat. No executa cap tasca. Per a un RTE també comprova el contracte que parla l'RTE (vegeu
+[El contracte](../rte/images.html#the-contract)):
+
+| RTE | Què llegeix la prova | Quan falla |
+|---|---|---|
+| Sortint o Entrant | Qui té el seu sòcol, tal com ho registra cada node d'aplicació, i el que ha dit l'RTE quan s'ha connectat. No crida res | Cap node d'aplicació no hi té un sòcol: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, o per a un d'entrant, *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. O l'RTE parla un altre contracte que no és el 3 |
+| Base de dades (obsolet) | El `/rte/v1/health` de l'RTE, cridat amb el seu token | L'RTE no respon a la seva adreça, rebutja el token, o parla un altre contracte que no és el 2 |
+
+La insígnia de **Connexió** de la pestanya RTE mostra el mateix estat del sòcol sense cap prova.
+
diff --git a/i18n/ca/_configure/runners/types.md b/i18n/ca/_configure/runners/types.md
new file mode 100644
index 0000000..9d5ea15
--- /dev/null
+++ b/i18n/ca/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Tipus de runner
+parent: Runners
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Tipus de runner
+{: .no_toc }
+
+Els productes que pot ser un runner, la seva adreça i el seu accés
+{: .fs-6 .fw-300 }
+
+El pas **Tipus** ofereix una opció per producte, cadascuna amb una pista; la de l'RTE en dona el nom complet, *Entorn d'execució*. AAP i
+Ascender es desen com un runner de tipus `awx` amb una variant (`aap` o `ascender`), que és també el que fa servir la llavor de configuració:
+
+| Tipus | Exemple d'URI | Projecte | Autenticació |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | L'`RTE_TOKEN` de l'RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Un token d'API, o un usuari i una contrasenya |
+| Ascender | `https://ascender.example.com/api/v2` | | Un token d'API, o un usuari i una contrasenya |
+| AWX | `https://awx.example.com/api/v2` | | Un token d'API, o un usuari i una contrasenya |
+| Jenkins | `https://jenkins.example.com` | La carpeta on són les tasques (opcional) | Un usuari i el token d'API d'aquest usuari |
+| Rundeck | `https://rundeck.example.com` | El nom del projecte | El token d'API d'un usuari |
+| Semaphore | `https://semaphore.example.com` | L'id del projecte, el número de `/project/<id>` | El token d'API d'un usuari |
+
+Una adreça d'AWX, AAP o Ascender porta el seu camí d'API: `/api/v2`, o `/api/controller/v2` per a AAP 2.5 i posteriors.
+Un RTE és la imatge d'AnsibleForms iniciada amb `AF_ROLE=rte`; com executar-ne un es descriu a
+[Entorns d'execució](../rte/).
diff --git a/i18n/ca/_configure/secret-stores/cyberark.md b/i18n/ca/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..f8b6de5
--- /dev/null
+++ b/i18n/ca/_configure/secret-stores/cyberark.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: CyberArk
+parent: Magatzems de secrets
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Llegeix credencials del CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Experimental.** Encara no s'ha provat amb una instal·lació real de CyberArk; si us plau, informa del que trobis.
+
+El CCP és la interfície REST de l'Application Access Manager de CyberArk.
+
+---
+
+## Camps del magatzem
+
+A més dels [camps que té tot magatzem](./#adding-a-store), un magatzem CyberArk té aquests camps:
+
+| Camp | Significat |
+|---|---|
+| Credencial | Una credencial **CyberArk** de [Connexions > Credencials](../credentials.html): la URL base del CCP, p. ex. `https://ccp.example.com` (s'hi afegeix `/AIMWebService/api/Accounts`), els seus ajustos de TLS, el seu AppID (l'aplicació definida per a AnsibleForms a CyberArk), i un certificat i una clau de client en PEM, només quan l'AppID ho requereix. |
+
+---
+
+## Referència del secret
+
+La referència del secret identifica el compte com a parells clau-valor separats per `;`:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Claus permeses: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` passa la resta de la referència com a consulta nativa del CCP, amb `QueryFormat=Exact`
+  tret que n'indiquis un altre.
+- Un `AppID` a la referència s'ignora: sempre es fa servir l'AppID del magatzem.
+- La contrasenya del compte (`Content`) passa a ser la contrasenya; `UserName`, `Address`, `Port` i
+  `Database` omplen l'usuari, l'host, el port i el nom de la base de dades.
+
+---
+
+## Opcions addicionals
+
+Les opcions addicionals del magatzem es defineixen com a objecte JSON:
+
+| Clau | Significat |
+|---|---|
+| `reason` | S'envia com a `Reason` quan la referència no en té cap, per a l'auditoria de CyberArk. |
+| `check_ref` | Una referència que **Prova la connexió** llegeix de veritat. Sense aquesta clau, la prova només verifica que el CCP respon i accepta l'AppID. |
+| `timeout_ms` | Temps d'espera de la petició, per defecte 10000. |
+
+Per exemple, per enviar un motiu i deixar que **Prova la connexió** llegeixi un compte de prova:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
+
diff --git a/i18n/ca/_configure/secret-stores/hashicorp-vault.md b/i18n/ca/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..2164a6c
--- /dev/null
+++ b/i18n/ca/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Magatzems de secrets
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Llegeix credencials d'HashiCorp Vault, de KV v1 o v2 o d'un motor de secrets dinàmics
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Camps del magatzem
+
+A més dels [camps que té tot magatzem](./#adding-a-store), un magatzem HashiCorp Vault té aquests camps:
+
+| Camp | Significat |
+|---|---|
+| Credencial | Una credencial **HashiCorp Vault** de [Connexions > Credencials](../credentials.html): l'adreça del Vault, els seus ajustos de TLS, i el token com a contrasenya, amb accés de lectura als camins que fan servir les teves credencials. **Afegeix una credencial** en crea una d'aquest tipus. AnsibleForms no renova el token. |
+| Espai de noms | L'espai de noms de Vault Enterprise, enviat com a `X-Vault-Namespace`. Es mostra un cop activat **Vault Enterprise**, al pas **Tipus**. |
+| Versió de KV | `2` (predeterminat) o `1`. |
+| Punt de muntatge predeterminat | Es fa servir per a una referència sense barra, p. ex. `myapp` passa a ser `secret/data/myapp`. |
+
+La referència del secret és el camí, p. ex. `secret/myapp/prod`. Per a KV v2 el segment `/data/`
+s'insereix quan no el poses.
+
+---
+
+## Credencials dinàmiques de base de dades
+
+Una referència de la forma `<mount>/creds/<role>`, p. ex. `database/creds/readonly`, llegeix d'un
+motor de secrets dinàmics com el motor de bases de dades de Vault. Vault crea llavors un compte de base de dades
+nou per a cada lectura, vàlid durant el lease.
+
+- Un compte es reutilitza durant el 80% del seu lease, no durant el temps de memòria cau; amb memòria cau `0`, cada consulta en llegeix un de nou.
+- Vault només retorna un usuari i una contrasenya: posa la resta de la connexió a la fila de la credencial.
+- El lease no es revoca mai abans d'hora; el compte caduca quan Vault acaba el lease.
+
diff --git a/i18n/ca/_configure/secret-stores/index.md b/i18n/ca/_configure/secret-stores/index.md
new file mode 100644
index 0000000..56dd24c
--- /dev/null
+++ b/i18n/ca/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Magatzems de secrets
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Magatzems de secrets
+{: .no_toc }
+
+Llegeix les credencials d'un gestor de secrets en lloc de desar-les a AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: connecta un gestor de secrets, i deixa que les credencials en llegeixin l'usuari i la contrasenya.
+
+---
+
+## Com funciona
+
+Un **magatzem de secrets** és una connexió a un gestor de secrets, afegida a
+**Connexions > Magatzems de secrets**. Una **credencial** pot llavors nomenar un magatzem i un lloc dins seu
+(la *referència del secret*). Quan un formulari, un playbook o una expressió fa servir aquesta credencial:
+
+- l'**usuari** i la **contrasenya** es llegeixen del magatzem, cada vegada (dins del temps de memòria cau del magatzem);
+- l'**host**, el **port** i la **base de dades** continuen sent els de la fila de la credencial. Quan la fila en deixa
+  un de buit i el secret el porta, es fa servir el valor del secret.
+
+Els formularis continuen referint-se a la credencial pel nom, de manera que moure una contrasenya a un magatzem no canvia
+res als teus formularis.
+
+| Tipus de magatzem | Estat |
+|---|---|
+| HashiCorp Vault (KV v1 i v2, autenticació per token) | disponible |
+| Credencials dinàmiques d'HashiCorp Vault (`<mount>/creds/<role>`) | experimental |
+| CyberArk Central Credential Provider (CCP) | experimental |
+
+---
+
+## Afegir un magatzem
+
+Des de la 7.3.0 només un admin pot afegir, canviar o suprimir un magatzem, ja que el seu token o la seva clau s'envien a la seva adreça. Tots els magatzems tenen aquests camps:
+
+| Camp | Significat |
+|---|---|
+| Nom | Com es refereixen les credencials al magatzem. |
+| Tipus | El gestor de secrets. |
+| Credencial | Com i on inicia sessió el magatzem: una credencial de [Connexions > Credencials](../credentials.html), al pas **Credencials**, de tipus **HashiCorp Vault** (el seu token i la seva adreça) o **CyberArk**. Conté la URL base, p. ex. `https://vault.example.com:8200`, i els ajustos de TLS: ometre la verificació del certificat, o un paquet de CA en PEM per a una CA privada. No pot llegir ella mateixa d'un magatzem de secrets. |
+| Memòria cau (segons) | Quant de temps es reutilitza un secret que s'ha llegit. `0` el llegeix a cada ús. Per defecte 60. |
+| Opcions addicionals (JSON) | Opcions pròpies del tipus, com a objecte JSON. |
+
+Fins a la 7.2.0 l'adreça, el token i els ajustos de TLS eren camps del magatzem. L'actualització a la 7.3.0 els trasllada a la seva
+credencial, anomenada `<store>-token` (o `<store>-appid` per a CyberArk), vegeu [Adreces a les credencials](../credentials/types.html#addresses-in-credentials).
+
+**Prova la connexió** comprova l'accés sense llegir cap secret. La pàgina **Estat** comprova tots els magatzems, i avisa 7 dies
+abans que caduqui un token de Vault.
+
+Cada gestor de secrets té la seva pròpia pàgina:
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 i v2 amb autenticació per token, i credencials dinàmiques de base de dades |
+| [CyberArk](cyberark.html) | El Central Credential Provider (CCP) de l'Application Access Manager de CyberArk |
+
+---
+
+## Utilitzar un magatzem
+
+### En una credencial
+
+A **Connexions > Credencials**, al pas **Magatzem** de la credencial, tria **Magatzem de secrets**, després tria el
+**Magatzem de secrets** i omple la **Referència**. L'usuari i la contrasenya es llegeixen llavors del magatzem, no s'escriuen.
+
+### En línia, sense fila de credencial
+
+A qualsevol lloc on s'accepta un nom de credencial, pots fer referència directament a un magatzem (`fnCredentials`, `fnRestBasic`,
+les `credentials:` d'un formulari, el `dbConfig` d'una consulta).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Sense fila de credencial, un secret de base de dades necessita com a mínim un `db_type` i un host, per exemple:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Sense `db_type`, el secret és una credencial normal (usuari, contrasenya i qualsevol altra clau), i una consulta sobre ell suposa `mysql`.
+
+### Noms de les claus
+
+Un secret s'assigna a una credencial amb aquests àlies. Les altres claus es passen tal com són.
+
+| Camp de la credencial | Claus acceptades al secret |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | el mateix nom (només secrets en línia) |
+
+Per a una fila de credencial, l'host, el port i el nom de la base de dades del secret només es fan servir on la
+fila els deixa buits.
+
+Un secret amb una estructura diferent es pot remodelar amb una expressió `jq`, passada com a tercer argument de
+`fnCredentials`:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## A la llavor de configuració
+
+Els magatzems també es poden declarar a la llavor de configuració, com els altres objectes d'administració:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+El magatzem inicia sessió amb la seva credencial: una de `vault` conté l'adreça del Vault a `url` i el token com a contrasenya, una de `cyberark`
+l'AppID i l'adreça del CCP. Sense credencial, es fan servir l'`url` i el `token` propis del magatzem.
+Per als detalls, vegeu [Llavor de configuració](../seed).
+
+---
+
+## Actualitzar des de les variables VAULT_*
+
+Abans de la 7 l'únic magatzem era un HashiCorp Vault configurat amb variables d'entorn `VAULT_*`,
+i una credencial hi apuntava amb **Vault path**.
+
+- **Les variables s'importen una sola vegada** com un magatzem anomenat `vault`; treu-les després.
+- **Les credencials amb un `vault_path`** ara fan servir aquest magatzem; `vault_path` desapareix a la 8.
diff --git a/i18n/ca/_configure/security/hardening.md b/i18n/ca/_configure/security/hardening.md
new file mode 100644
index 0000000..8f5bb97
--- /dev/null
+++ b/i18n/ca/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Enduriment
+parent: Seguretat
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Enduriment
+{: .no_toc }
+
+El compte d'admin, els límits d'inici de sessió, la base de dades, les expressions, les dades de les tasques, la política del navegador, les funcions opcionals i les opcions de rol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## El compte d'admin
+
+El compte d'admin local es crea a la primera arrencada a partir d'[`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+i [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), el valor predeterminat del qual és `AnsibleForms!123`.
+
+* Un inici de sessió amb la contrasenya predeterminada pública `AnsibleForms!123` l'ha de canviar primer: fins aleshores el servidor respon
+  a qualsevol petició excepte el canvi de contrasenya amb `403` (codi `password_change_required`), i el navegador mostra una
+  pàgina de canvi de contrasenya que no es pot tancar. La contrasenya nova no pot tornar a ser la predeterminada.
+* `ADMIN_PASSWORD` només es llegeix quan es crea el compte per primera vegada: defineix el teu propi valor abans de la primera arrencada.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` restableix la contrasenya a `ADMIN_PASSWORD` a cada
+  arrencada. Fes-lo servir només per recuperar una contrasenya perduda, i després treu-lo i reinicia.
+* Defineix primer els dos secrets mestres: vegeu [Secrets i xifratge](secrets.html).
+* Quan l'inici de sessió per LDAP o SSO funcioni, conserva l'admin local només per a emergències, amb una contrasenya llarga desada al teu gestor de contrasenyes.
+
+---
+
+## Límits d'inici de sessió i contrasenyes
+
+L'endevinament de contrasenyes es frena amb tres límits. Els errors es compten a la base de dades, de manera que tots els nodes d'aplicació veuen
+els mateixos intents, i tots els límits s'apliquen sense reiniciar:
+
+| Variable | Predeterminat | Què fa |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Després d'aquest nombre d'inicis de sessió fallits, un compte local o LDAP es bloqueja durant `LOGIN_LOCKOUT_MINUTES`. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Una adreça amb aquest nombre d'inicis de sessió fallits dins de `LOGIN_LOCKOUT_MINUTES` queda retinguda fins que acaba aquesta finestra: una adreça que prova molts comptes. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Quant de temps es manté bloquejat un compte, i la finestra en què es compten els errors. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Peticions per minut des d'una adreça, per node d'aplicació, a l'inici de sessió, el tancament de sessió, la renovació del token i els retorns de l'inici de sessió únic. |
+
+Un compte bloquejat o una adreça retinguda reben `429` amb una capçalera `Retry-After`, abans que es comprovi cap contrasenya i
+tant si el compte existeix com si no; per sobre d'`AUTH_RATE_LIMIT` la resposta també és `429`. Un inici de sessió correcte esborra el
+recompte del compte, i també ho fa un admin que posa la contrasenya de l'usuari. `0` desactiva un límit; `LOGIN_LOCKOUT_MINUTES=0`
+desactiva tant el bloqueig com el límit per adreça.
+
+`LOGIN_MAX_FAILURES_PER_IP` i `AUTH_RATE_LIMIT` compten per adreça de client: darrere d'un proxy invers, defineix `TRUST_PROXY`
+perquè l'adreça sigui la del client i no la del proxy, vegeu [Adreces dels clients](../production/reverse-proxy.html#client-addresses).
+
+Una contrasenya local definida a través de l'aplicació, per a un usuari nou, per un admin o pels usuaris que canvien la seva, ha de tenir
+almenys [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) caràcters (`8` per defecte,
+`0` no comprova cap longitud). No pot ser el nom d'usuari ni la contrasenya predeterminada pública. `ADMIN_PASSWORD` no es comprova.
+
+---
+
+## La base de dades
+
+AnsibleForms conserva totes les credencials i totes les tasques a la seva base de dades MySQL, així que mantén aquesta base de dades fora de la xarxa:
+
+* El projecte docker-compose publica MySQL a l'amfitrió (`MYSQLDB_LOCAL_PORT`, `3306`) i ve amb la contrasenya de root
+  `AnsibleForms!123`. Treu aquest mapatge de port, o lliga'l a `127.0.0.1`, i canvia la contrasenya.
+* Connecta't amb un compte dedicat en lloc de `root`, definit a [`DB_USER`](../customization/server.html#env_DB_USER) i
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Només necessita permisos sobre l'esquema `AnsibleForms`:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Això cobreix la creació de l'esquema (el `CREATE DATABASE` inclòs), l'aplicació de pedaços a les actualitzacions, i les
+  [còpies de seguretat](../production/backups.html) i restauracions, que s'executen amb el mateix usuari: el bolcat es fa amb
+  `--no-tablespaces`, de manera que no cal cap permís de tot el servidor com ara `PROCESS`. Substitueix `%` per l'adreça de
+  l'aplicació sempre que puguis. Un usuari amb permisos sobre totes les bases de dades, com en té `root`, converteix un forat a l'aplicació en
+  un forat a tot el servidor de bases de dades: la pàgina **Estat** n'avisa a la comprovació **Usuari de la base de dades**, i el registre
+  a cada arrencada.
+* Posa [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) a `0` un cop existeix l'esquema.
+  Crear l'esquema elimina primer totes les taules; amb `0` ni l'arrencada inicial ni l'endpoint `/api/v2/schema`
+  ho poden executar.
+
+---
+
+## Expressions i crides de sortida
+
+Les expressions del servidor s'executen al servidor per a qualsevol usuari que hagi iniciat sessió, així que el sanejador i els filtres de sortida importen:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` o `paranoid`, mai `legacy`, que permet als usuaris executar codi al servidor.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : hosts als quals no poden arribar les expressions REST, p. ex. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : quan està definida, les expressions REST només poden arribar
+  a aquests hosts i rangs. La llista de denegats hi guanya.
+
+Totes dues llistes només cobreixen les funcions auxiliars REST del mateix AnsibleForms; els playbooks s'executen fora i no es filtren.
+
+Des de la 7.3.0 les funcions auxiliars REST comproven el certificat de l'endpoint, com fan totes les altres connexions.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` desactiva la comprovació: fes-lo servir només per a
+endpoints amb un certificat autosignat.
+
+---
+
+## Dades de les tasques
+
+Les extravars i la sortida de les tasques es desen a la base de dades i es mostren a tothom qui pot veure la tasca:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : les extravars la clau de les quals coincideix
+  es mostren com a `********`. El valor predeterminat és `password|secret|token`; els camps de contrasenya sempre s'emmascaren. Amplia'l amb
+  els noms que fan servir els teus formularis, per exemple `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : retalla l'objecte `ansibleforms_user`
+  que s'envia amb cada tasca, que si no conté tota la pertinença a grups de l'usuari.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) només amaga tasques sorolloses; amaga els secrets amb `no_log`.
+
+---
+
+## La Content-Security-Policy
+
+La interfície se serveix amb una capçalera Content-Security-Policy, que limita què pot carregar i executar una pàgina al navegador:
+
+* Els scripts només vénen de la mateixa aplicació, de manera que un script injectat en una pàgina no s'executa.
+* Cap altre lloc web no pot mostrar la interfície dins d'un frame.
+* Permet el que necessita l'aplicació: les expressions locals dels formularis avaluades al navegador (`'unsafe-eval'`), els estils
+  en línia, imatges de qualsevol URL (imatges de formularis i de categories), i els workers de l'editor de codi.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) és `1` per defecte i s'hi hauria de
+quedar. Amb `0` la política s'envia com a `Content-Security-Policy-Report-Only`: la consola del navegador llista el que
+bloquejaria, i no es bloqueja res. Fes servir `0` només per a una configuració que encara no pot funcionar amb la política, com ara un proxy invers
+que injecta un script propi. Un canvi a la pàgina de configuració s'aplica sense reiniciar.
+
+---
+
+## Les pàgines de configuració i el dissenyador
+
+Els administradors poden canviar bona part de la configuració des del navegador. Restringeix-ho quan la configuració viu en un altre lloc:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : configuració només de lectura, per a un [entorn gestionat](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : treu el dissenyador integrat quan els formularis
+  es mantenen a git.
+
+---
+
+## Funcions opcionals
+
+Aquestes funcions estan desactivades per defecte. Activa-les només quan les facis servir; un canvi a la pàgina de configuració s'aplica sense reiniciar:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : serveix el [servidor MCP](../mcp/) a `/api/v2/mcp`,
+  perquè els clients MCP puguin llançar formularis amb el token d'un usuari.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : l'[assistent de xat](../chat/). Les definicions dels formularis
+  i els valors que s'estan omplint s'envien al proveïdor de models configurat.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) funciona al revés: és `enforce`
+per defecte, de manera que el servidor rebutja un llançament els valors del qual incompleixen les regles del formulari, inclosos els llançaments per l'API REST.
+Deixa-la així: `log` només registra el que es rebutjaria i `off` no comprova res, vegeu [Validació del llançament](../launch-validation/).
+
+---
+
+## Opcions de rol
+
+Algunes opcions de rol de [config.yaml](../config/roles.html) donen més del que suggereix el seu nom. Concedeix-les amb cura:
+
+| Opció | Per què importa |
+|--------|----------------|
+| `allowScheduledJobs` | Un usuari que la té veu i pot canviar totes les programacions, i una programació s'executa amb drets d'admin, per a qualsevol formulari. Tracta-la com una opció de nivell d'admin. |
+| `allowBackupOps` | Inclou la **restauració**, que substitueix tota la base de dades. |
+| `showSettings` | Obre les pàgines d'administració. Sense el rol admin, no pot canviar els comptes i els grups que nomena el rol admin, vegeu [Usuaris i grups](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Mostra el registre del servidor, que pot contenir noms de host, noms d'usuari i detalls d'errors. |
+| `showConnectionsSettings` | Obre les pàgines de connexions: credencials, runners, canals de notificació i més. Afegir, canviar i suprimir runners i magatzems de secrets continua sent cosa d'un admin, i també les credencials de les connexions i dels inicis de sessió. D'un repositori, afegir-lo o suprimir-lo i canviar-ne l'adreça, la branca o els indicadors `use_for_*` continua sent cosa d'un admin. |
+| `showAllJobLogs` | Mostra les tasques de tots els usuaris, no només les de l'usuari. |
+| `manageAllJobs` | Avorta, suprimeix i torna a llançar les tasques de tots els usuaris. |
+| `allowApiTokens` | Permet a l'usuari crear tokens d'API que duren fins a [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 per defecte). Tancar la sessió amb un token o revocar-lo l'acaba, i un canvi de contrasenya acaba tots els tokens de l'usuari, vegeu [Tokens](secrets.html#tokens). |
+| `extendedTokenExpiration` | Amb `allowApiTokens`, també permet a l'usuari crear tokens d'API que no caduquen mai. |
+| `allowFileUploads` | Permet a l'usuari pujar fitxers mitjançant els camps de fitxer d'un formulari. Activada per a tots els usuaris tret que un rol la desactivi. |
+| `allowChat`, `allowMcp` | Permeten a l'usuari fer servir l'assistent de xat i el servidor MCP, quan estan activats. `allowChat` està activada per a tots els usuaris tret que un rol la desactivi, i `allowMcp` segueix `allowChat` tret que un rol la defineixi. |
+
+Un usuari sense el rol `admin` no rep cap de les opcions de nivell d'admin de més amunt tret que un rol les hi doni. Quan el rol `admin`
+no defineix cap opció, els seus usuaris reben `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` i `allowScheduledJobs`. `allowApiTokens` i
+`extendedTokenExpiration` continuen desactivades fins i tot per al rol `admin`: defineix-les als rols que les necessiten.
+
+Quan diversos rols d'un usuari defineixen la mateixa opció, guanya `false`. Les opcions del rol `default` només completen les opcions
+que no defineix cap dels rols propis de l'usuari; mai no les anul·len.
diff --git a/i18n/ca/_configure/security/https.md b/i18n/ca/_configure/security/https.md
new file mode 100644
index 0000000..7b0f1c4
--- /dev/null
+++ b/i18n/ca/_configure/security/https.md
@@ -0,0 +1,98 @@
+---
+layout: default
+title: HTTPS
+parent: Seguretat
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+Serveix HTTPS des de la mateixa aplicació, i substitueix el certificat d'exemple
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## On acaba el TLS
+
+El TLS pot acabar en un de tres llocs, i només el primer té a veure amb els ajustos d'aquesta pàgina:
+
+* **a AnsibleForms**, amb `HTTPS=1` : HTTPS al [`PORT`](../customization/server.html#env_PORT) amb els fitxers de més avall, com fa docker-compose al 443.
+* **en un proxy invers**, amb `HTTPS=0` al darrere : vegeu [Proxy invers](../production/reverse-proxy.html).
+* **en un ingress de Kubernetes** : vegeu la pestanya Ingress de [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) i el README del chart.
+
+Pots combinar el primer amb els altres dos per xifrar també el tram entre el proxy i l'aplicació.
+
+---
+
+## Els ajustos
+
+Tres variables controlen l'HTTPS a l'aplicació:
+
+| Variable | Predeterminat | Significat |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` serveix HTTPS, `0` HTTP sense xifrar |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | La clau privada, en PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | El certificat del servidor, en PEM |
+
+A la imatge del contenidor la carpeta persistent és `/app/dist/persistent`, de manera que els fitxers predeterminats són
+`/app/dist/persistent/certificates/key.pem` i `cert.pem`. Amb el projecte docker-compose és `data/certificates/`
+a l'amfitrió.
+
+---
+
+## El certificat d'exemple
+
+Quan `HTTPS=1` i falta algun dels dos fitxers en arrencar, AnsibleForms registra `httpsKey or httpsCert not found, copying from
+templates` i copia una clau i un certificat d'exemple de la imatge als camins configurats. Si aquesta còpia falla, l'aplicació
+s'atura.
+
+Aquest certificat és autosignat per a `CN=ansibleforms`, i és **el mateix a totes les instal·lacions**: la seva clau privada
+ve dins de la imatge pública. Serveix per a una primera ullada, però els navegadors n'avisen i qualsevol pot desxifrar el trànsit
+que protegeix. Substitueix-lo abans que la instància contingui credencials reals.
+
+---
+
+## Substituir el certificat
+
+Fes servir un certificat emès per al nom de host que escriuen els usuaris, per la teva CA o per un client ACME, en format PEM.
+El fitxer del certificat pot contenir tota la cadena: primer el certificat del servidor, i després els intermedis.
+
+1. Copia els fitxers a la carpeta persistent, o a qualsevol lloc on l'aplicació els pugui llegir:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Si són en un altre lloc, posa a `HTTPS_KEY` i `HTTPS_CERT` els seus camins **dins del contenidor**.
+
+3. Reinicia l'aplicació, que llegeix tots dos fitxers en arrencar.
+
+Per a un certificat autosignat propi ràpid (una instància de prova, o el tram darrere d'un proxy), `openssl` en crea un:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Renovar sense reiniciar
+
+Canviar `HTTPS_KEY` o `HTTPS_CERT` a les pàgines de configuració torna a carregar la clau i el certificat al servidor en execució.
+Les connexions noves reben el certificat nou, i les obertes conserven l'antic. Si els fitxers nous no es poden llegir o no formen un parell
+vàlid, el certificat actual es manté i es registra un avís.
+
+Això només funciona quan les pàgines de configuració poden escriure l'entorn ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+és `1`) i la variable no està definida a l'entorn real. Quan una renovació substitueix els fitxers als mateixos
+camins, reinicia l'aplicació.
+
diff --git a/i18n/ca/_configure/security/index.md b/i18n/ca/_configure/security/index.md
new file mode 100644
index 0000000..8f0e667
--- /dev/null
+++ b/i18n/ca/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Seguretat
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Seguretat
+{: .no_toc }
+
+Protegeix una instància: el compte d'admin, els seus secrets, HTTPS i què poden fer els usuaris i els formularis
+{: .fs-6 .fw-300 }
+
+---
+
+Per a administradors que preparen una instància per a producció, i per a revisions de seguretat d'una instància existent.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Enduriment](hardening.html) | El compte d'admin, els límits d'inici de sessió, la base de dades, les expressions, les dades de les tasques, la política del navegador, les funcions opcionals i les opcions de rol |
+| [HTTPS](https.html) | On acaba el TLS, servir HTTPS des de l'aplicació, i substituir el certificat d'exemple |
+| [Secrets i xifratge](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, i la durada dels tokens |
+
+Pàgines relacionades: [Autenticació](../authentication/) per als mètodes d'inici de sessió, [Validació del llançament](../launch-validation/) per a les
+comprovacions al servidor de cada llançament, i les [Variables de seguretat](../customization/security.html).
diff --git a/i18n/ca/_configure/security/secrets.md b/i18n/ca/_configure/security/secrets.md
new file mode 100644
index 0000000..097e57a
--- /dev/null
+++ b/i18n/ca/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Secrets i xifratge
+parent: Seguretat
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Secrets i xifratge
+{: .no_toc }
+
+Els dos secrets mestres, què protegeixen, i quant duren les sessions i els tokens
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Els dos secrets mestres
+
+Dos secrets protegeixen tota la resta. Defineix-los tots dos abans que la instància contingui dades reals, desa'ls fora de la instància,
+i no els canviïs mai a la lleugera:
+
+| Secret | Què protegeix | Si no està definit | Si es perd o es canvia |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Totes les contrasenyes i tots els tokens desats a la base de dades: credencials, la contrasenya de bind de LDAP, els tokens dels runners, els secrets de client SSO, les adreces de webhook de Slack i Teams, la clau d'API del xat | Es fa servir una clau predeterminada, que és pública al codi font | Si es perd: cal tornar a introduir tots els secrets desats. Si es canvia: des de la 7.3.0 tots els secrets desats es tornen a xifrar, vegeu [més avall](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | La signatura dels access tokens i dels refresh tokens, inclosos els [tokens d'API](../profile/api-token.html) de llarga durada | Es genera un secret aleatori a cada arrencada, de manera que cada reinici tanca la sessió de tothom | Totes les sessions i tots els tokens d'API deixen de ser vàlids |
+
+Tots dos es registren com a avís `[SECURITY]` en arrencar mentre falten. Les pàgines de configuració no permeten editar-los,
+l'API no els retorna mai, i les còpies de seguretat els deixen fora a propòsit, de manera que un `ENCRYPTION_SECRET` perdut no es pot recuperar
+d'enlloc: conserva'n una còpia al teu gestor de secrets. El secret de xifratge es fa servir com a clau de 32 caràcters; un valor més curt o
+més llarg s'emplena o es retalla.
+
+Canviar `ACCESS_TOKEN_SECRET` acaba totes les sessions i tots els tokens d'API alhora. Per acabar els tokens d'un usuari o d'una
+sessió, fes servir les revocacions descrites a [Tokens](#tokens).
+
+---
+
+## Canviar el secret de xifratge
+
+Des de la 7.3.0, definir o canviar `ENCRYPTION_SECRET` ja no fa perdre els secrets desats. A la següent arrencada el worker torna a xifrar
+cadascun d'ells amb la clau nova, en una sola transacció de base de dades, abans que res més escrigui cap secret:
+
+| Situació | Què cal definir |
+|---|---|
+| La instància funcionava sense `ENCRYPTION_SECRET`, amb la clau predeterminada pública | Només `ENCRYPTION_SECRET`: els secrets es tornen a xifrar a partir de la clau predeterminada |
+| La instància funcionava amb una clau pròpia | `ENCRYPTION_SECRET` amb la clau nova i [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) amb l'antiga, per a aquesta única arrencada |
+
+Quan els secrets desats es van xifrar amb una clau que no és cap de les dues, no es canvia res i l'aplicació es nega a arrencar fins que
+`ENCRYPTION_SECRET_PREVIOUS` indiqui aquesta clau. Treu `ENCRYPTION_SECRET_PREVIOUS` un cop l'arrencada els hagi tornat a xifrar, i defineix el
+nou `ENCRYPTION_SECRET` a tots els nodes d'aplicació, al worker i a tots els RTE en mode base de dades que es registren ells mateixos. Aquest
+autoregistre (`RTE_REGISTER`) és obsolet a la 7.3.0: un RTE que s'uneix amb un token d'unió (`RTE_JOIN_TOKEN`) en mode
+de sòcol no necessita `ENCRYPTION_SECRET`, vegeu [Modes de l'RTE](../rte/modes.html).
+
+---
+
+## Tokens
+
+Un inici de sessió retorna un access token de curta durada i un refresh token més llarg, que el navegador fa servir per obtenir un parell nou:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : `30m` per defecte. Un valor més curt
+  limita l'ús d'un token interceptat.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : `24h` per
+  defecte. És el temps que un navegador inactiu continua amb la sessió iniciada.
+* L'opció de rol `allowApiTokens` permet a un usuari demanar un token d'API vàlid durant un nombre de dies, i
+  `extendedTokenExpiration` n'hi afegeix un que no caduca mai. Concedeix-les només als rols que necessiten accés a l'API des de scripts.
+  A la [pàgina del perfil](../profile/api-token.html) un token es crea des d'una sessió del navegador que ha iniciat sessió fa com a màxim 10 minuts,
+  i mai des d'un altre token d'API. Un token que no caduca mai dura 50 anys, i els esdeveniments de més avall també l'acaben.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : `90` per defecte. El màxim que dura un
+  token d'API: una petició més llarga s'hi retalla.
+
+Un token és un JWT signat, però el servidor també manté una llista de tokens revocats, compartida per tots els nodes d'aplicació, de manera que un token
+pot acabar abans de caducar:
+
+| Esdeveniment | Què acaba |
+|-------|-----------|
+| Tancar la sessió | Tots els tokens d'aquell inici de sessió: l'access token, el seu refresh token, i un token d'API quan el tancament de sessió el fa servir |
+| Un canvi de contrasenya, fet per l'usuari o per un admin | Tots els tokens de l'usuari emesos abans del canvi, tokens d'API inclosos, a tots els dispositius |
+| L'interruptor **Permet l'inici de sessió** d'un usuari desactivat (usuari local, LDAP o SSO), o un usuari local suprimit | Tots els tokens de l'usuari |
+| **Tanca les sessions** a la pàgina d'un usuari LDAP o SSO | Tots els tokens de l'usuari; pot tornar a iniciar sessió tret que estigui bloquejat |
+| **Revoca** en un token d'API, a la pàgina del perfil o a la pestanya **Tokens d'API** de l'usuari | Aquest token d'API, a l'instant |
+
+Un script acaba el seu propi token d'API tancant la sessió amb ell: `POST /api/v2/auth/logout` amb el token a la capçalera
+`Authorization`.
diff --git a/i18n/ca/_configure/seed/environment-and-audit.md b/i18n/ca/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..5a6c4ad
--- /dev/null
+++ b/i18n/ca/_configure/seed/environment-and-audit.md
@@ -0,0 +1,60 @@
+---
+layout: default
+title: Edició i auditoria
+parent: Llavor de configuració
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Edició i auditoria
+{: .no_toc }
+
+Bloquejar les pàgines de configuració, i què registra el registre d'auditoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Desactivar l'edició de l'entorn
+
+`ALLOW_ENV_EDIT=0` fa que les pàgines de configuració siguin només de lectura. Cada variable es continua mostrant amb
+el valor vigent i el motiu pel qual no es pot canviar, i l'endpoint de desament respon amb
+403.
+
+Fes-lo servir sempre que l'entorn es declari en un altre lloc. Si no, la pàgina de configuració escriu
+`persistent/.env`, que en un volum efímer es perd sense avís al següent reinici, i en
+un de durador s'allunya del manifest que hauria de ser la referència.
+
+{: .note }
+> Les còpies de seguretat inclouen `persistent/.env` com a `managed.env`, de manera que una reconstrucció recupera els ajustos de la base de dades i
+> dels camins. **`ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET` se n'eliminen**:
+> el bolcat del costat conté totes les credencials desades com a text xifrat AES, i escriure la clau que
+> el desxifra a la mateixa carpeta faria que n'hi hagués prou amb una còpia de seguretat copiada per llegir-les totes. Defineix
+> aquests dos secrets a l'amfitrió de destinació; un comentari al fitxer ho indica.
+>
+> El que queda encara pot contenir credencials (`DB_PASSWORD`, `METRICS_TOKEN`, un antic `VAULT_TOKEN`), així que el fitxer
+> s'escriu amb `0600`. Restaurar-lo és un pas opcional a part en lloc de formar part d'una restauració normal,
+> perquè l'amfitrió de la base de dades i els camins que conté descriuen la màquina d'on prové la còpia. El
+> diàleg de restauració llista el fitxer i ofereix el seu propi botó *Restaura l'entorn*
+> (`POST /api/v2/backup/:folder/restore-env`), que conserva el fitxer anterior com a `.env.bak`.
+
+---
+
+## Què es registra
+
+Cada aplicació que canvia alguna cosa escriu una entrada `seed.apply` al registre d'auditoria, que nomena
+els objectes creats, actualitzats, alliberats i purgats. Els valors no es registren mai, perquè la majoria
+són secrets. Una aplicació que no canvia res no escriu res, cosa que manté el rastre significatiu. Una
+comprovació que troba el fitxer sense canvis no canvia res, de manera que el rastre no guanya una fila cada minut.
+
+Una aplicació demanada a través de l'endpoint es registra dues vegades a propòsit, i les dues files
+registren coses diferents: `config-seed.apply.create` és **qui** l'ha demanada, `seed.apply` és
+**què** ha canviat.
+
+La pàgina Estat informa de la llavor dues vegades: una **comprovació** que el fitxer encara es pot llegir i analitzar,
+i que la darrera recàrrega ha funcionat, i una fila d'**informació** que indica quants registres té
+actualment. La comprovació és l'únic lloc que informa quan el fitxer del disc i la configuració
+vigent han divergit, perquè una recàrrega fallida deixa la instància en funcionament.
+
diff --git a/i18n/ca/_configure/seed/example.md b/i18n/ca/_configure/seed/example.md
new file mode 100644
index 0000000..67ce6bf
--- /dev/null
+++ b/i18n/ca/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Exemple
+parent: Llavor de configuració
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Exemple
+{: .no_toc }
+
+Un fitxer de llavor complet, secció per secció
+{: .fs-6 .fw-300 }
+
+---
+
+El fitxer de llavor següent declara totes les seccions excepte `oauth2` i l'obsolet `awx`; els secrets vénen de variables
+d'entorn com ara `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` és un de:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : qualsevol altre endpoint compatible amb OpenAI
+
+Com `ldap`, la secció `chat` és una sola fila, de manera que tots els camps són obligatoris excepte els
+opcionals; un camp opcional que s'omet es deixa sense canvis.
+
+L'assistent de xat també necessita `ENABLE_CHAT=1`; vegeu la pàgina [Assistent de xat](../chat).
+
+Des de la 7.3.0 un runner inicia sessió amb una credencial del seu tipus, que conté l'adreça del seu servidor a `url`. Un runner amb el seu propi `token`,
+o `username` i `password`, encara funciona: la llavor registra un avís i els converteix en una credencial d'aquest tipus, amb el nom del runner. Un
+runner que nomena una credencial `api` o `userpass` també funciona encara, amb un avís: dona a aquesta credencial el tipus del runner.
+Totes dues coses són obsoletes des de la 7.3.0 i s'eliminen a la 8.0.0. Un runner RTE sense `rte_mode` és en mode base de dades, obsolet (vegeu
+[Modes](../rte/modes.html)). Un runner amb `enabled: false` no rep cap tasca, tampoc com a predeterminat del seu tipus (vegeu
+[Predeterminat i Activat](../runners/list.html#default-and-enabled)); sense `enabled`, la llavor el deixa tal com està.
+
+Un element de runner accepta aquestes claus a més de `name`, `type`, `description`, `credential`, `is_default` i `enabled`:
+
+| Clau | Què defineix |
+|---|---|
+| `rte_mode` | El mode d'un RTE: `outbound`, `inbound` o `database` (obsolet, el predeterminat) |
+| `rte_max_jobs` | El **Màxim de treballs simultanis** d'un RTE en mode de sòcol, de `0` a `10000` (`0`: sense límit) |
+| `rte_cache_mb` | La seva **Memòria cau de fitxers** en MB, de `0` a `1048576` (`0` no en conserva cap) |
+| `rte_files` | Els seus **Fitxers de treball**: `transfer` o `local` |
+| `rte_drain_seconds` | El seu **Temps d'espera en aturar** en segons, de `0` a `86400` |
+| `flavour` | Un runner `awx` que és un AAP o un Ascender: `aap` o `ascender`; cap per a AWX |
+| `project` | L'id de projecte d'un runner Semaphore, el nom de projecte d'un runner Rundeck, la carpeta d'un runner Jenkins |
+| `uri`, `ignore_certs`, `ca_bundle` | L'adreça i el TLS propis del runner, d'abans de la 7.3.0: només es fan servir mentre la seva credencial no conté cap `url` |
+
+Els quatre ajustos `rte_*` són els de la pestanya RTE de la pàgina del runner (vegeu [La configuració d'un RTE](../runners/runner-page.html#an-rtes-settings)):
+guanyen a les mateixes variables definides a l'RTE, i un RTE en mode base de dades els ignora. Un valor fora del seu rang fa fallar la
+validació de la llavor.
+
+Un RTE en mode base de dades es pot registrar ell mateix abans que s'apliqui la llavor. Un runner RTE de la llavor l'`uri` del qual és l'adreça on s'ha
+registrat un RTE d'aquests **adopta** aquella fila: en pren el nom i els camps declarats, i el worker ja no l'elimina quan l'RTE deixa de
+respondre, en lloc de crear un segon runner per al mateix RTE.
diff --git a/i18n/ca/_configure/seed/index.md b/i18n/ca/_configure/seed/index.md
new file mode 100644
index 0000000..46084e5
--- /dev/null
+++ b/i18n/ca/_configure/seed/index.md
@@ -0,0 +1,69 @@
+---
+layout: default
+title: Llavor de configuració
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Llavor de configuració
+{: .no_toc }
+
+Declara els objectes d'administració en un fitxer
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors que aprovisionen des de git: declara els objectes d'administració en un fitxer, perquè una instància es pugui reconstruir sobre una base de dades buida.
+
+---
+
+## Què cobreix
+
+Posa a `CONFIG_SEED_PATH` un fitxer YAML, i AnsibleForms l'aplica en arrencar. El fitxer
+declara objectes que abans només existien a la base de dades:
+
+| Secció                  | Què declara                                                         |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | On s'executen les tasques: RTE, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Magatzems de secrets (HashiCorp Vault, ...)                         |
+| `credentials`           | Credencials                                                         |
+| `oauth2`                | Proveïdors SSO: Entra ID i OIDC                                     |
+| `repositories`          | Repositoris git                                                     |
+| `syslog_servers`        | Els servidors syslog que reben el registre del servidor i les entrades d'auditoria |
+| `notification_channels` | Servidors de correu, Slack, Teams, Telegram i webhooks per a les notificacions |
+| `labels`                | Les etiquetes al costat del logotip de la capçalera, des de la 7.3.0 |
+| `ldap`                  | La configuració de LDAP                                             |
+| `settings`              | La URL pública, i els ajustos de correu que es fan servir quan no hi ha cap canal de correu actiu |
+| `chat`                  | El proveïdor de models de l'assistent de xat                        |
+| `awx`                   | Obsolet des de la 7, eliminat a la 8: fes servir `runners` amb `type: awx` |
+
+Una llavor escrita abans de la 7 continua funcionant: cada element de la seva secció `awx` s'aplica com un runner de tipus `awx`, i el registre
+n'avisa a cada aplicació. Mou aquests elements a `runners` amb `type: awx` abans d'actualitzar a la 8.
+
+La llavor **no** és el mateix que `config.yaml`, que conté les categories, els rols i les constants
+i té el seu propi `CONFIG_PATH`. Totes dues coses es mantenen separades a propòsit: el
+repositori que *conté* `config.yaml` és un dels objectes que declara la llavor, de manera que la llavor
+no pot viure a dins seu.
+
+Els usuaris i els grups en queden fora: vénen de LDAP o SSO, i el primer admin d'`ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Exemple](example.html) | Un fitxer de llavor complet, secció per secció |
+| [Objectes gestionats](managed-objects.html) | Com la llavor és propietària dels objectes que llista, i com manté els secrets fora |
+| [Recàrrega i arrencada](reloading.html) | Canviar el fitxer sense reiniciar, i què passa en arrencar |
+| [Kubernetes](kubernetes.html) | Aprovisionar AnsibleForms des d'un ConfigMap i Secrets |
+| [Edició i auditoria](environment-and-audit.html) | Bloquejar les pàgines de configuració, i què registra el registre d'auditoria |
+
diff --git a/i18n/ca/_configure/seed/kubernetes.md b/i18n/ca/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..9bf48fa
--- /dev/null
+++ b/i18n/ca/_configure/seed/kubernetes.md
@@ -0,0 +1,90 @@
+---
+layout: default
+title: Kubernetes
+parent: Llavor de configuració
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+Aprovisionar AnsibleForms des d'un ConfigMap i Secrets
+{: .fs-6 .fw-300 }
+
+---
+
+Munta la llavor des d'un `ConfigMap` i els seus secrets des d'un `Secret`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Un sol pod, amb `AF_ROLE` sense definir.** Aquest pod executa l'aplicació web i el worker en un sol procés. Les programacions, la còpia de seguretat
+> nocturna i l'altra feina en segon pla només s'executen al procés que té el bloqueig del worker a la base de dades, el bloqueig del dissenyador
+> és una taula de la base de dades, i els playbooks s'executen en un RTE, no en aquest pod. Tot i així, mantén `replicas: 1` amb l'estratègia `Recreate`:
+> en una actualització el pod nou espera que el worker apliqui els pedaços a l'esquema, i el pod antic conserva el
+> bloqueig del worker fins que s'atura. Per executar diversos nodes web, divideix-los en nodes `AF_ROLE=app` i un worker, tal com
+> descriu [Escalat](../production/scaling.html).
+
+`ENCRYPTION_SECRET` s'ha de definir abans d'introduir cap credencial. Un cop les credencials vénen
+de la llavor, la base de dades és de fet una memòria cau, de manera que rotar-la vol dir tornar a aplicar la
+llavor en lloc de tornar a introduir-ho tot a mà.
+
+Les dues sondes no necessiten iniciar sessió. Sota un [`BASE_URL`](../customization/server.html#env_BASE_URL) els seus camins comencen per aquest valor, i
+[Supervisió](../production/monitoring.html) descriu què comprova cadascuna.
+
diff --git a/i18n/ca/_configure/seed/managed-objects.md b/i18n/ca/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..6fdcf36
--- /dev/null
+++ b/i18n/ca/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Objectes gestionats
+parent: Llavor de configuració
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Objectes gestionats
+{: .no_toc }
+
+Com la llavor és propietària dels objectes que llista, i com manté els secrets fora
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les seccions d'una sola fila són tot o res
+
+`ldap`, `settings` i `chat` són cadascuna una **sola fila**, així que la llavor n'ha de declarar tots els camps; les altres seccions són llistes.
+
+Una llavor que omet un camp es nega a arrencar i el nomena:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Declara un valor buit explícitament amb `""` o `false`. Alguns camps són opcionals, i un que s'omet es deixa sense canvis:
+
+| Secció | Camps opcionals |
+|---|---|
+| `ldap` | `description`, `credential` (una credencial amb què fer bind) i `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` i `extra_headers` |
+| `settings` | Cap |
+
+`settings` només cobreix els camps de correu i la URL; tota la resta de la configuració continua sent editable.
+
+---
+
+## El fitxer no conté cap secret
+
+Cada `${VARIABLE}` se substitueix per aquella variable d'entorn (a Kubernetes, des d'un `Secret`), de manera que el fitxer pot viure a Git.
+
+Una variable que no està definida és un **error fatal**, així que un marcador mai no pot acabar desat com a contrasenya.
+
+Les credencials també poden fer servir un [magatzem de secrets](../secret-stores) (`secret_store`, `secret_ref`); `vault_path` desapareix a la 8.
+
+---
+
+## Objectes gestionats
+
+Un objecte que ve de la llavor es marca com a **gestionat**:
+
+- S'imposa a **cada** arrencada, de manera que el fitxer continua sent la referència.
+- És només de lectura: l'API respon **403**, la interfície desactiva Edita i Suprimeix, i la seva pròpia pàgina diu que ve del fitxer de la
+  llavor de configuració i que és només de lectura.
+- Només la llavor pot posar o treure la marca.
+
+Els objectes creats a mà **no es toquen mai**, tret que la llavor declari el mateix nom. Aquell registre llavors s'**adopta**:
+els camps declarats s'imposen i passa a ser només de lectura. L'adopció es registra com a avís i al rastre d'auditoria.
+
+Aplicar la llavor és idempotent: els registres que ja coincideixen es deixen tranquils, de manera que un reinici normalment informa de `0 updated`.
+
+Un repositori declarat l'arbre de treball del qual falta es **torna a clonar** a cada arrencada, de manera que un primer clonatge fallit es
+torna a provar. La fila *Repositoris* de la pàgina Estat mostra qualsevol repositori sense arbre de treball.
+
+### Treure un objecte
+
+Treure un objecte del fitxer l'**allibera**: el registre es queda i torna a ser editable. Suprimir una secció sencera
+fa el mateix.
+
+Afegeix `prune: true` a una secció de llista per **suprimir** els registres gestionats que el fitxer ja no declara:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` no suprimeix mai un registre creat a mà.
+
+### Desactivar la llavor
+
+Treure `CONFIG_SEED_PATH` **no** allibera res: la llavor ja no s'aplica, i els registres que gestionava continuen gestionats
+i només de lectura. Per tornar-los a editar, primer allibera'ls: apunta `CONFIG_SEED_PATH` a un fitxer sense ells (un fitxer buit no declara
+res i allibera tots els registres), deixa que s'apliqui en una arrencada o una recàrrega, i després treu la variable. Els registres alliberats es queden tal com
+estan, i passen a ser editables.
diff --git a/i18n/ca/_configure/seed/reloading.md b/i18n/ca/_configure/seed/reloading.md
new file mode 100644
index 0000000..0c85cde
--- /dev/null
+++ b/i18n/ca/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Recàrrega i arrencada
+parent: Llavor de configuració
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Recàrrega i arrencada
+{: .no_toc }
+
+Canviar el fitxer sense reiniciar, i què passa en arrencar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Canviar el fitxer sense reiniciar
+
+La llavor es torna a llegir cada `CONFIG_SEED_RELOAD_SECONDS` (60 per defecte, `0` ho desactiva)
+i es torna a aplicar quan el seu contingut ha canviat. Per tant, un canvi confirmat a git arriba
+automàticament a una instància en funcionament: a Kubernetes, un `ConfigMap` es torna a muntar sota el pod en
+aproximadament un minut, i la comprovació següent el detecta. No hi ha cap desplegament ni cap reinici, i cap
+hook no ha de cridar res.
+
+Per a un fitxer sense canvis, la comprovació calcula un hash i s'atura, de manera que mai no reescriu una fila que ja
+ha aplicat.
+
+Per aplicar el fitxer immediatament en lloc d'esperar la comprovació següent, fes servir qualsevol d'aquests:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Tots dos **forcen** una aplicació encara que el fitxer no hagi canviat. Una aplicació forçada torna a imposar un
+registre gestionat que s'ha editat directament a la base de dades, i torna a clonar un repositori declarat
+l'arbre de treball del qual falta.
+
+{: .note }
+> Una recàrrega **mai no és fatal**, a diferència de l'aplicació en arrencar. Una instància que ja està
+> en servei conserva la seva configuració actual, es registra el motiu, i la fila *Config seed*
+> de la pàgina Estat es posa vermella i l'indica. Un error tipogràfic enviat a git no ha de poder fer caure
+> una instància en funcionament sense cap acció d'un operador.
+>
+> El mateix contingut defectuós tampoc no es torna a provar a cada comprovació; si no, una sola edició dolenta
+> escriuria el mateix error al registre indefinidament. Corregeix el fitxer, o crida l'endpoint per tornar-ho a provar
+> immediatament.
+
+---
+
+## Una llavor defectuosa impedeix arrencar
+
+Un fitxer il·legible, YAML no vàlid, un camp desconegut, un nom duplicat o una
+`${VARIABLE}` sense resoldre fan que el servidor **surti** en lloc d'arrencar. Això només passa a l'**arrencada**:
+vegeu la nota de més amunt per saber què fa el mateix fitxer a una instància que ja funciona.
+
+És deliberat. Continuar amb la configuració anterior deixaria una instància el
+comportament de la qual ja no coincideix amb el manifest que l'hauria de descriure, sense res que
+n'informés. El motiu s'escriu a la sortida d'error estàndard a més del fitxer de registre, de manera que
+`kubectl logs` i `docker logs` el mostren.
+
+La validació és estricta: els camps desconeguts es rebutgen en lloc d'ignorar-se, i l'error nomena
+la clau culpable:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Una base de dades buida s'aprovisiona sola
+
+Amb `ALLOW_SCHEMA_CREATION` activat (el predeterminat), una base de dades que no conté **cap taula
+d'AnsibleForms** rep el seu esquema en arrencar. Per tant, un desplegament nou arrenca
+sense que ningú hagi de cridar manualment l'endpoint `/schema`.
+
+La condició prèvia és estricta a propòsit: crear l'esquema **elimina primer totes les taules**, així que
+només s'executa mai contra una base de dades completament buida. Una base de dades a la qual falta
+una columna, o que té taules però cap compte d'usuari, *no* és buida i es deixa intacta;
+els pedaços de l'esquema s'encarreguen d'aquests casos.
diff --git a/i18n/ca/_configure/users-and-groups.md b/i18n/ca/_configure/users-and-groups.md
new file mode 100644
index 0000000..15e7021
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Usuaris i grups
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Usuaris i grups
+{: .no_toc }
+
+Els usuaris i grups locals, al costat dels de LDAP i d'inici de sessió únic, i com bloquejar un inici de sessió
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: gestiona qui pot iniciar sessió a **Configuració > Accés > Usuaris** i **Grups**, amb l'opció de rol `showSettings`.
+
+L'admin integrat, l'ordre d'inici de sessió i l'assignació de rols dels comptes locals són a [Comptes locals](authentication/local.html).
+
+---
+
+## En aquesta secció
+
+| Pàgina | Què hi trobaràs |
+|---|---|
+| [Un usuari local](users-and-groups/local-user.html) | Afegir un usuari local, i les pestanyes de la seva pàgina |
+| [Diversos grups](users-and-groups/several-groups.html) | Un usuari local en diversos grups, i els seus rols |
+| [Un grup local](users-and-groups/local-group.html) | La pàgina d'un grup local i les seves pestanyes |
+| [Usuaris i grups del directori](users-and-groups/directory.html) | Usuaris i grups de LDAP, Entra ID i OIDC, tal com es van veure per últim cop |
+| [Bloquejar un inici de sessió](users-and-groups/blocking-a-sign-in.html) | Permet l'inici de sessió: bloqueja un usuari sense suprimir res |
+
+
+---
+
+## Les llistes
+
+Les llistes **Usuaris** i **Grups** mostren els usuaris i grups locals i, al seu costat, els de LDAP i d'inici de sessió únic.
+
+Un usuari o un grup de LDAP, Entra ID o OIDC apareix a la llista quan ha iniciat sessió (o s'ha vist en un inici de sessió), o quan un rol el nomena.
+La columna **Origen** indica d'on ve cadascun: Local, LDAP, Microsoft Entra ID o OIDC. Des de la 7.3.0 la llista **Usuaris** també
+té una columna **Darrer inici de sessió**, que indica quan va iniciar sessió cada usuari per última vegada.
+
+Una fila obre la pàgina del seu usuari o grup. **Afegeix un usuari** i **Afegeix un grup** en creen un de local.
+
+---
+
+## Comptes que donen admin
+
+El rol admin de config.yaml nomena grups i usuaris locals, així que només un admin pot canviar els comptes i els grups que nomena.
+
+Un usuari amb `showSettings` però sense el rol admin no pot canviar, bloquejar, canviar de grup, posar la contrasenya ni suprimir un
+compte local que el rol admin nomena (directament o a través d'un dels seus grups). Tampoc no pot crear, reanomenar ni suprimir un grup
+que el rol admin nomena, ni posar-hi un usuari. El mateix val per a un usuari LDAP o SSO que s'assigna al rol admin: bloquejar-lo,
+tancar-ne les sessions, oblidar-lo i revocar-ne els tokens d'API són cosa d'un admin. El servidor respon a una petició així amb `403`.
+
diff --git a/i18n/ca/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/ca/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..c1554e6
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Bloquejar un inici de sessió
+parent: Usuaris i grups
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Bloquejar un inici de sessió
+{: .no_toc }
+
+Permet l'inici de sessió: bloqueja un usuari sense suprimir res
+{: .fs-6 .fw-300 }
+
+L'interruptor **Permet l'inici de sessió** bloqueja un usuari, local o d'un directori, sense suprimir res.
+
+Si es desactiva, després d'una confirmació, les sessions de l'usuari acaben a l'instant i es rebutja qualsevol inici de sessió fins que el tornis a activar.
+La llista d'usuaris té **Bloqueja l'inici de sessió** i **Permet l'inici de sessió** al menú de cada fila per fer el mateix.
+
+No pots bloquejar l'usuari `admin`, ni el teu propi inici de sessió.
diff --git a/i18n/ca/_configure/users-and-groups/directory.md b/i18n/ca/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..b49a63f
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Usuaris i grups del directori
+parent: Usuaris i grups
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Usuaris i grups del directori
+{: .no_toc }
+
+Usuaris i grups de LDAP, Entra ID i OIDC, tal com es van veure per últim cop
+{: .fs-6 .fw-300 }
+
+Un usuari de LDAP, Entra ID o OIDC té la seva pàgina a `/settings/users/<source>/<name>`, amb `ldap`, `azuread` o `oidc`
+com a origen, per exemple `/settings/users/ldap/jdoe`. Mostra el que es va registrar al darrer inici de sessió de l'usuari, només de lectura,
+ja que és el directori o el proveïdor d'identitat qui decideix qui és l'usuari i quins són els seus grups.
+
+Les seves pestanyes són les d'un usuari local. **Detalls** té l'interruptor **Permet l'inici de sessió**, el nom d'usuari, l'origen, el nom,
+el correu, quan es va veure l'usuari per primer cop i el seu darrer inici de sessió. **Grups** llista els grups del darrer inici de sessió.
+**Tokens d'API** llista els tokens d'API de l'usuari, i **Revoca** n'acaba un a l'instant.
+
+A dalt a la dreta, **Tanca les sessions** tanca ara mateix la sessió de l'usuari a tot arreu. **Oblida** elimina el registre, que torna
+al seu proper inici de sessió; les seves tasques, tasques desades i programacions es conserven. Un usuari bloquejat no es pot oblidar, perquè
+això el deixaria tornar a entrar: el servidor respon `409`, així que primer permet-ne l'inici de sessió.
+
+Els grups d'aquest registre són també els grups amb què treballa la sessió de l'usuari, llegits en directe. Oblidar un usuari que té la sessió
+iniciada el deixa sense grups, i sense els rols que donen aquests grups, fins que torna a iniciar sessió.
+
+Un grup del directori té la seva pàgina a `/settings/groups/<source>/<name>`, només de lectura, amb les pestanyes **Detalls**,
+**Usuaris** (els usuaris que s'hi han vist al seu darrer inici de sessió), **Rols** i **Formularis**.
diff --git a/i18n/ca/_configure/users-and-groups/local-group.md b/i18n/ca/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..fd30696
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Un grup local
+parent: Usuaris i grups
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Un grup local
+{: .no_toc }
+
+La pàgina d'un grup local i les seves pestanyes
+{: .fs-6 .fw-300 }
+
+La pàgina d'un grup, `/settings/groups/<id>`, té aquestes pestanyes:
+
+| Pestanya | Què mostra |
+|---|---|
+| **Detalls** | El nom i la descripció |
+| **Usuaris** | Els usuaris del grup; **Afegeix un usuari** n'afegeix un, el menú d'una fila o les caselles en treuen un |
+| **Rols** | Els rols que nomenen el grup |
+| **Formularis** | Els formularis que obren aquests rols |
+
+Un grup amb usuaris no es pot suprimir: primer treu-ne els usuaris. El grup `admins` no es pot suprimir ni reanomenar mai.
diff --git a/i18n/ca/_configure/users-and-groups/local-user.md b/i18n/ca/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..a82dd83
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Un usuari local
+parent: Usuaris i grups
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Un usuari local
+{: .no_toc }
+
+Afegir un usuari local, i les pestanyes de la seva pàgina
+{: .fs-6 .fw-300 }
+
+**Afegeix un usuari** obre un assistent de tres passos: **Usuari** (nom d'usuari, descripció, correu), **Contrasenya** i **Grup**.
+
+La pàgina d'un usuari, `/settings/users/<id>`, té aquestes pestanyes:
+
+| Pestanya | Què mostra |
+|---|---|
+| **Detalls** | L'interruptor **Permet l'inici de sessió**, el nom d'usuari, la descripció, el correu i, des de la 7.3.0, el **Darrer inici de sessió** |
+| **Grups** | Els grups als quals pertany l'usuari |
+| **Rols** | Els rols que té l'usuari, i què li dona cadascun: **Directament**, **A través de** un grup, o **Tothom** |
+| **Formularis** | Els formularis que obren aquests rols |
+| **Tasques** | Les tasques que ha llançat l'usuari, la més recent primer |
+| **Tasques desades** | Els valors de formulari que l'usuari ha desat per tornar-los a executar |
+| **Programacions** | Les tasques que l'usuari ha planificat amb Executa més tard |
+| **Activitat** | El que el registre d'auditoria ha registrat que ha fet l'usuari |
+| **Tokens d'API** | Els tokens d'API de l'usuari, amb quan es va crear, quan caduca i quan es va utilitzar per última vegada cadascun; **Revoca** n'acaba un a l'instant |
+
+Des de la 7.3.0 els inicis de sessió d'un usuari local es registren, com ja passava amb els d'un usuari LDAP o SSO: **Darrer inici de sessió** mostra el més recent, i
+la llista d'usuaris té una columna **Darrer inici de sessió** ordenable per a tots els orígens, de manera que un compte que no fa servir ningú salta a la vista. Un inici de sessió rebutjat no
+es registra, i un usuari local que no ha iniciat sessió des de l'actualització mostra `–`.
+
+**Canvia la contrasenya** i **Suprimeix** són a dalt a la dreta. L'usuari `admin` no es pot suprimir ni reanomenar mai.
diff --git a/i18n/ca/_configure/users-and-groups/several-groups.md b/i18n/ca/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..34f04db
--- /dev/null
+++ b/i18n/ca/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Diversos grups
+parent: Usuaris i grups
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Diversos grups
+{: .no_toc }
+
+Un usuari local en diversos grups, i els seus rols
+{: .fs-6 .fw-300 }
+
+Un usuari local pot pertànyer a diversos grups, i rep els rols de tots ells: els rols nomenen un grup com a `local/<group>`.
+
+A la pestanya **Grups**, **Afegeix un grup** afegeix l'usuari a un altre grup, i el menú d'una fila o les caselles en treuen un.
+Un usuari conserva almenys un grup. La llista d'usuaris té **Afegeix a un grup** al menú de cada fila per fer el mateix.
diff --git a/i18n/ca/_get_started/first-form.md b/i18n/ca/_get_started/first-form.md
new file mode 100644
index 0000000..d4088ab
--- /dev/null
+++ b/i18n/ca/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: El teu primer formulari
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# El teu primer formulari
+{: .no_toc }
+
+Escriu un playbook, crea-hi un formulari al Dissenyador, llança'l i troba la tasca
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Aquest tutorial parteix d'una instal·lació nova, consulta [Instal·lació](installation/). Dura uns quinze minuts.
+
+---
+
+## 1. Inicia sessió
+
+Obre AnsibleForms en un navegador i inicia sessió com a administrador.
+
+El compte predeterminat és `admin` / `AnsibleForms!123` (o els teus valors d'[`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)); s'obre la pàgina **Formularis**:
+
+![La pàgina Formularis, amb formularis d'exemple](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Escriu el playbook
+
+Un formulari `ansible` executa un playbook de la carpeta de playbooks, així que primer va el playbook. Desa això com a `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+El playbook llegeix quatre variables. El formulari que crearàs a continuació les envia com a extravars, una per camp.
+
+Posa el fitxer a la carpeta `playbooks` de la carpeta persistent
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); crea la carpeta si encara no existeix:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Des del codi font</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+La carpeta que vas muntar a `/app/dist/persistent`, `/srv/apps/ansibleforms/persistent` a l'exemple d'instal·lació:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+La carpeta `data/playbooks` del projecte de docker-compose:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+El volum persistent, muntat a `/app/dist/persistent` al pod d'AnsibleForms. Busca el nom del pod i després copia-hi el fitxer:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+La carpeta `persistent/playbooks` del servidor, `/srv/apps/ansibleforms/server` a l'exemple d'instal·lació:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Quan un repositori git té activat **Utilitzar per als playbooks ?**, els playbooks s'executen des d'aquest repositori:
+> fes-hi commit de `hello.yaml`. Consulta [Dissenyador i git](gui/designer-and-git.html).
+
+---
+
+## 3. Crea el formulari
+
+Els formularis són fitxers YAML a la carpeta de formularis. El Dissenyador els edita al navegador i els comprova abans de desar-los.
+
+1. Fes clic a **Dissenyador** al menú superior, i després a **Formularis** al menú de l'esquerra.
+2. Fes clic a l'interruptor de dalt a la dreta (**Inicia el dissenyador**). Bloqueja la configuració perquè ningú més l'editi alhora,
+   i després mostra **Bloquejat per mi**.
+3. Fes clic a **Fitxer nou**, el primer botó de la barra d'eines, i introdueix el nom de fitxer `hello-world.yaml`. El Dissenyador hi afegeix un formulari
+   anomenat `New Form`.
+4. Substitueix el YAML de l'editor per aquest formulari:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Fes clic a **Valida** (la marca de verificació), i després a **Desa**. En desar, s'escriu `hello-world.yaml` a la carpeta de formularis.
+6. Torna a fer clic a l'interruptor per alliberar el bloqueig.
+
+![El Dissenyador, editant un formulari](assets/screenshots/designer.jpg)
+
+El formulari fa servir quatre tipus de camp:
+
+| Camp | Tipus | Què fa |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Un quadre de text obligatori |
+| `target_env` | [`enum`](formfields/enum.html) | Un desplegable amb una llista fixa de `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Un desplegable emplenat per una [expressió](expressions/local.html) local; `__auto__` selecciona el primer element |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Una casella, enviada com a `true` o `false` |
+
+`vm_size` mostra les dues columnes, `size` i `cpus`, i envia `size`, la primera; `valueColumn` en tria una altra.
+
+`roles: [default]` permet que qualsevol usuari que hagi iniciat sessió executi el formulari, i `categories: [Default]` el posa a la categoria que defineix el
+`config.yaml` predeterminat.
+
+{: .note }
+> També pots copiar `hello-world.yaml` a [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH), i [validar-lo a VS Code](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Llança'l
+
+Obre el formulari des de la pàgina **Formularis**: fes clic a **Formularis** al menú superior i tria **Hello world** a la categoria **Default**.
+
+Emplena el teu nom i canvia els altres camps si vols. Fes clic a **Mostra les extravars** per veure què rebrà el playbook,
+i després fes clic a **Envia**:
+
+![Un formulari](assets/screenshots/form.jpg)
+
+---
+
+## 5. Mira la sortida
+
+La tasca s'inicia a l'instant, i la seva sortida apareix sota el formulari mentre s'executa, i acaba amb una barra **Acabada**:
+
+![La sortida d'una tasca](assets/screenshots/run.jpg)
+
+La tasca de debug mostra els teus valors, per exemple `Hello Alice: a small machine in development (dry run: True)`.
+
+L'avís sobre el localhost implícit és normal sense inventari; un formulari real defineix [`inventory`](forms/ansible.html).
+
+---
+
+## 6. Troba-la a l'historial de tasques
+
+Cada llançament es conserva com una tasca. Fes clic a **Tasques** al menú superior: la tasca nova és a dalt de tot de **Totes les tasques**.
+
+Fes clic a la tasca per tornar a veure'n la sortida, i a **Mostra les extravars** per veure què s'ha enviat. Les icones davant de cada tasca
+la rellancen o la suprimeixen:
+
+![L'historial de tasques](assets/screenshots/job-output.jpg)
+
+---
+
+## Passos següents
+
+Amplia aquest formulari amb les pàgines de referència:
+
+* **[Formularis](forms/)** : totes les propietats d'un formulari, plantilles en runners, formularis de workflow, punts d'aprovació i notificacions
+* **[Camps de formulari](formfields/)** : tots els tipus de camp, amb validació, dependències i disposició
+* **[Expressions](expressions/)** : emplena camps des d'API REST, bases de dades i fitxers
+* **[Rols](config/roles.html)** i **[categories](config/categories.html)** a `config.yaml` : decideix qui veu cada formulari
+* **[Com funciona](how-it-works.html)** : què passa darrere d'un llançament, i on es desa tot
diff --git a/i18n/ca/_get_started/installation/docker-compose.md b/i18n/ca/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..044aef4
--- /dev/null
+++ b/i18n/ca/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Instal·lació
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Instal·la AnsibleForms, el seu RTE i MySQL alhora amb docker-compose o podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+El [projecte de docker-compose](https://github.com/ansibleforms/docker) executa tres contenidors: MySQL, l'aplicació AnsibleForms i l'RTE
+(runtime environment, entorn d'execució) que executa els playbooks. Conté la seva configuració, formularis i playbooks d'exemple, així que l'únic altre requisit és
+Docker o Podman amb la seva eina compose.
+
+L'[instal·lador](installer.html) baixa aquest projecte, n'emplena la configuració i els secrets, i l'inicia amb una sola ordre. Aquesta pàgina
+el configura a mà.
+
+---
+
+## Requisits previs
+
+Abans de començar, necessites:
+
+* **Una màquina Linux** : qualsevol distribució, amb una CPU i una memòria modestes
+* **Accés a GitHub** : per baixar o clonar el projecte de docker-compose de GitHub
+* **Docker o Podman** : un motor de contenidors, que s'instal·la a continuació
+* **Una eina compose** : Docker Compose o podman-compose, per iniciar els tres contenidors a partir d'uns quants fitxers de configuració
+
+**VÍDEO**: [Com instal·lar AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Tria una ubicació per a la instal·lació
+
+Crea una carpeta per al projecte; els exemples fan servir `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Clona el projecte de docker-compose
+
+Instal·la Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Després clona el projecte de docker-compose en aquesta carpeta:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Defineix els permisos adequats
+
+L'aplicació i l'RTE s'executen amb l'usuari `node` (uid 1000), així que dona a aquest usuari la carpeta `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Si véns de la 6, el contenidor de la qual s'executava com a root, executa el mateix `chown` una vegada abans d'iniciar la 7. MySQL recupera la seva pròpia carpeta quan s'inicia.
+
+---
+
+## Instal·la un motor de contenidors
+
+Instal·la Docker o Podman, cadascun amb la seva eina compose:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Instal·la Docker Engine amb el plugin Compose des del repositori de Docker
+(consulta els [manuals d'instal·lació de Docker](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Després permet que els noms es resolguin dins dels contenidors, i inicia Docker com a servei:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman no necessita cap servei. Instal·la'l juntament amb podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Personalitza
+
+Revisa les variables dels fitxers `.env` i `docker-compose.yml`, i canvia totes les contrasenyes: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` i `RTE_TOKEN`. [Més informació sobre les variables d'entorn](../customization)
+
+L'aplicació es connecta a MySQL com a `ansibleforms` (`MYSQLDB_USER`), amb tots els permisos sobre l'esquema `AnsibleForms` i cap
+més enlloc; root només és per al mateix MySQL. MySQL només crea aquest usuari en el seu primer inici: una instal·lació que fins ara es connectava com a root
+el crea una vegada, tal com mostra el [README](https://github.com/ansibleforms/docker#database) del projecte.
+
+L'RTE no es publica a l'amfitrió. Des de la 7.3.0 l'aplicació el truca a `http://rte:8000` amb `RTE_TOKEN` i hi manté un WebSocket obert
+(`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)): l'RTE no rep cap configuració de la base de dades ni el `.env`, només el seu token i uns quants
+paràmetres propis a `docker-compose.yml`. El config seed `data/seed.yaml` declara una credencial d'RTE amb el token i aquesta
+adreça, i el runner predeterminat `rte`, en mode inbound, que s'hi autentica. L'RTE executa els playbooks des de la mateixa carpeta `data`
+(`RTE_FILES=local`). Quan els teus playbooks necessitin més col·leccions o biblioteques de Python, construeix un RTE propi
+i fes que el servei `rte` hi apunti (consulta [Construir el teu propi RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Inicia el projecte de docker-compose
+
+Inicia els tres contenidors en segon pla. L'aplicació espera fins que MySQL està en bon estat, i després truca a l'RTE:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Prova l'aplicació
+
+Un cop els contenidors estan en marxa, obre AnsibleForms en un navegador:
+
+* Obre `https://your_ip` (port 443, consulta `WEBAPP_LOCAL_PORT` al fitxer .env)
+* Inicia sessió com a `admin` amb l'`ADMIN_PASSWORD` del fitxer `.env`; mentre encara sigui el predeterminat `AnsibleForms!123`, tria una contrasenya nova
+* Comprova a **Connexions > Runners** que l'RTE apareix com a `rte`, el runner predeterminat, i que la seva pàgina mostra la seva
+  **Connexió** com a **Connectat**
+* Passos següents:
+  * Crea formularis afegint fitxers YAML a la carpeta data/forms/ o fent servir el dissenyador integrat
+  * Afegeix els teus playbooks a la carpeta data/playbooks/
+  * Afegeix una connexió LDAP
+  * Afegeix usuaris i grups
+  * Afegeix runners per als formularis de plantilles: AWX, AAP o Ascender, Semaphore, Rundeck o Jenkins
+  * Afegeix credencials per a connexions externes, com ara altres servidors MySQL o API REST, o per passar-les als playbooks d'Ansible
+  * Connecta repositoris git i tria si els teus formularis i/o playbooks se sincronitzen amb un repositori
+
+---
+
+## Estructura de fitxers
+
+El projecte de docker-compose té l'estructura de carpetes següent:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/ca/_get_started/installation/docker.md b/i18n/ca/_get_started/installation/docker.md
new file mode 100644
index 0000000..6aa68b1
--- /dev/null
+++ b/i18n/ca/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Instal·lació
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Executa les imatges de l'aplicació i de l'RTE d'AnsibleForms amb Docker o Podman, al costat d'un servidor MySQL propi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pots executar AnsibleForms amb Docker o Podman com a dos contenidors, l'aplicació i l'RTE que executa els playbooks, connectats a una base de dades MySQL.
+
+---
+
+## Requisits previs
+
+Abans de començar, necessites:
+
+* **Docker o Podman** : un dels dos instal·lat i en marxa
+* **MySQL** : instal·lat i en marxa
+
+---
+
+## Instal·lar MySQL
+
+Instal·la MySQL 8+, o MariaDB, en un servidor Linux al qual pugui arribar el contenidor:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu inclou MySQL 8:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian inclou MariaDB en lloc de MySQL, que AnsibleForms també admet:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 i posteriors, i les seves recompilacions, inclouen MySQL 8 a AppStream:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms es connecta a la base de dades per la xarxa, com a `DB_USER` amb `DB_PASSWORD`. Dona-li un usuari propi, amb permisos només sobre
+l'esquema `AnsibleForms`, no root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+És tot el que necessita AnsibleForms: amb això, crea i actualitza el seu esquema i fa les seves còpies de seguretat. La pàgina **Estat** i el registre
+avisen quan l'usuari té permisos sobre totes les bases de dades. A Ubuntu i Debian el servidor només escolta a localhost: defineix `bind-address` a la seva
+configuració perquè els contenidors hi puguin arribar.
+
+---
+
+## Preparar les carpetes
+
+AnsibleForms 7 s'executa en dos contenidors: l'aplicació, i l'RTE (runtime environment, entorn d'execució) que executa els playbooks. Tots dos munten una carpeta per al
+teu `config.yaml`, formularis, playbooks, registres i certificats, i una carpeta per a la clau SSH. Les imatges s'executen amb l'usuari `node` (uid 1000),
+així que dona a aquest usuari totes dues carpetes:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Posa la configuració de l'aplicació en un fitxer d'entorn: la connexió a la base de dades,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) abans de desar cap credencial, el token que comparteixen l'aplicació i
+l'RTE ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), com a mínim 16 caràcters) i el config seed que declara l'RTE:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+L'RTE rep un fitxer propi, sense la configuració de la base de dades: des de la 7.3.0 l'aplicació el truca i hi manté un WebSocket obert
+(`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)), i executa els playbooks des de les mateixes carpetes (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+El [config seed](../seed/) declara una credencial d'RTE amb l'adreça de l'RTE i el seu token, i el runner predeterminat `rte` que s'hi
+autentica:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Iniciar els contenidors
+
+Executa les imatges publicades al GitHub Container Registry (consulta [Etiquetes d'imatge](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) per a l'aplicació i
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) per a l'RTE.
+
+El seed afegeix l'RTE a **Connexions > Runners** com el runner `rte`, el predeterminat, així que els formularis de playbook s'hi executen sense cap més
+configuració. L'aplicació crea l'esquema en el primer inici, i truca a l'RTE un cop tots dos s'executen (hi ha un `config.yaml` d'exemple al
+[projecte de docker-compose](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Un cop iniciats, es llisten tots dos contenidors:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman accepta les mateixes opcions i no necessita cap servei:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Un cop iniciats, es llisten tots dos contenidors:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+L'aplicació escolta al port `8000`, per HTTP tret que defineixis `HTTPS=1`. L'RTE no es publica a l'amfitrió: només el truca l'aplicació, dins de
+la xarxa. `--stop-timeout 30` dona temps a l'RTE perquè els playbooks en execució acabin quan s'atura (consulta
+[Executar un RTE](../rte/run.html) per a la configuració de l'RTE i per construir un RTE propi).
+
+---
+
+## Provar l'aplicació
+
+Un cop els contenidors estan en marxa, obre AnsibleForms en un navegador:
+
+* Obre `http://your_ip:8000` (o HTTPS, si has definit `HTTPS=1`)
+* Inicia sessió com a `admin` / `AnsibleForms!123` (o amb la contrasenya que hagis definit amb `ADMIN_PASSWORD`), i tria una contrasenya nova
+* Comprova a **Connexions > Runners** que l'RTE apareix com a `rte`, el runner predeterminat, i que la seva pàgina mostra la seva
+  **Connexió** com a **Connectat**
+* Passos següents:
+  * Crea formularis afegint fitxers YAML a la carpeta `forms` o fent servir el dissenyador integrat
+  * Afegeix els teus playbooks a la carpeta `playbooks` de la carpeta persistent muntada
+  * Afegeix una connexió LDAP
+  * Afegeix usuaris i grups
+  * Afegeix runners per als formularis de plantilles: AWX, AAP o Ascender, Semaphore, Rundeck o Jenkins
+  * Afegeix credencials per a connexions externes, com ara altres servidors MySQL o API REST, o per passar-les als playbooks d'Ansible
diff --git a/i18n/ca/_get_started/installation/from-source.md b/i18n/ca/_get_started/installation/from-source.md
new file mode 100644
index 0000000..461ce7f
--- /dev/null
+++ b/i18n/ca/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Des del codi font
+parent: Instal·lació
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Des del codi font
+{: .no_toc }
+
+Compila AnsibleForms des del codi font i executa'l amb Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Com està organitzat el codi
+
+El repositori conté dues aplicacions Node.js, i una compilació les combina en una de sola:
+
+* **client** : la interfície web, escrita en Vue 3 i compilada en fitxers estàtics amb Vite
+* **server** : l'API, escrita amb Express. Lliura les tasques als runners, es connecta a la base de dades i serveix el client compilat.
+  Iniciat amb `AF_ROLE=rte`, el mateix servidor és l'RTE (runtime environment, entorn d'execució) que executa els playbooks
+
+Només es compila el client; el resultat va a la carpeta `views` del servidor, com a la [imatge de Docker](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Requisits previs
+
+Compilar i executar des del codi font requereix bons coneixements de Linux i una mica de Node.js. Instal·les tu mateix cada component. Per
+executar AnsibleForms sense contenidors i sense compilar-lo, la [instal·lació nativa](native.html) de l'instal·lador ho fa tot per tu:
+
+* **Node.js 26** (la versió de `.nvmrc`; com a mínim 24), amb npm
+* **Git**, per obtenir el codi i sincronitzar repositoris
+* **Client OpenSSH**, per a git per SSH, i **sshpass**, per als playbooks que es connecten amb una contrasenya SSH
+* **Client de MariaDB** (`mariadb`, `mariadb-dump`), per a les còpies de seguretat i les restauracions, també amb un servidor MySQL
+* **MySQL 8+ o MariaDB**, accessible des del servidor
+* **Ansible**, per al procés RTE que executa els playbooks (`ansible-playbook` al seu path). El procés de l'aplicació en si no necessita
+  ni Ansible ni Python, i amb només formularis de plantilles (AWX, AAP, Ascender i els altres runners) no necessites cap RTE
+
+Instal·la'ls per a la teva distribució:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 ve del repositori de NodeSource, i les altres eines del mateix Ubuntu:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 ve del repositori de NodeSource, i les altres eines del mateix Debian:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js ve de NodeSource i `sshpass` d'EPEL (al mateix RHEL, activa EPEL tal com ho documenta Red Hat):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Comprova `node --version` (26) i `ansible-playbook --version`; per a la base de dades i el seu usuari, consulta [Instal·lar MySQL](docker.html#install-mysql).
+
+---
+
+## Obtenir el codi
+
+Clona el repositori en una carpeta que triïs, propietat de l'usuari que executarà l'aplicació. Els exemples fan servir `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Compilar
+
+Compila en tres passos, des de la carpeta del repositori. Primer compila el client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Després instal·la les dependències del servidor:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Finalment copia el client compilat a la carpeta `views` del servidor:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Configurar
+
+El servidor llegeix la seva configuració de variables d'entorn i, en producció, també de `server/persistent/.env`, el fitxer
+on escriuen les pàgines de configuració.
+
+Parteix del fitxer d'exemple de l'arrel del repositori i defineix com a mínim la connexió a MySQL (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Totes les variables es descriuen a [Variables d'entorn](../customization). Tota la resta es desa a `server/persistent` per defecte:
+`config.yaml`, la carpeta `forms` i els certificats autosignats s'hi creen en el primer inici, al costat dels registres.
+Posa els teus playbooks a `server/persistent/playbooks`, o fes que `ANSIBLE_PATH` apunti a un altre lloc a l'entorn de l'RTE, que és qui el llegeix.
+
+---
+
+## Executar
+
+Executa AnsibleForms en producció, o en mode de desenvolupament per treballar en el codi mateix:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Producció</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Desenvolupament</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Inicia el servidor en mode de producció des de la carpeta `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Una aplicació iniciada des de la línia d'ordres s'atura quan tanques la sessió. [PM2](https://pm2.keymetrics.io/) la manté en marxa en
+segon pla, la reinicia després d'una fallada i la torna a iniciar en arrencar:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Els playbooks s'executen en un RTE: inicia el mateix servidor una segona vegada amb `AF_ROLE=rte`, en un port propi. L'aplicació el truca i hi manté
+un WebSocket obert (`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)), i executa els playbooks des de les mateixes carpetes
+(`RTE_FILES=local`). També llegeix `persistent/.env`, però no en fa servir cap paràmetre de la base de dades. Afegeix a `persistent/.env` el token que comparteixen l'aplicació i l'RTE,
+de com a mínim 16 caràcters, i el config seed que declara l'RTE:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+El [config seed](../seed/) declara una credencial d'RTE amb l'adreça de l'RTE i el seu token, i el runner predeterminat `rte` que s'hi
+autentica:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Sense seed, afegeix-los a **Connexions > Credencials** (una credencial d'RTE amb aquesta adreça i el token) i a
+**Connexions > Runners** (tipus RTE, **Mode** **Entrant**). Després inicia l'RTE, només a `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+La configuració de l'RTE es descriu a la pàgina [Executar un RTE](../rte/run.html). Comprova que PM2 llista tots dos processos:
+
+```bash
+pm2 status
+```
+
+Tots dos són `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Per treballar en el codi mateix, inicia-ho tot des de l'arrel del repositori amb recàrrega en directe: el servidor al port 3001, un RTE al port 8010
+i el client a `https://localhost:8443`. En aquest mode, el servidor i l'RTE llegeixen `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+L'RTE (`npm run dev:rte`) necessita `ansible-playbook` al path, i s'afegeix ell mateix com a runner en mode database, obsolet, només per al
+desenvolupament; `npm run dev:local` inicia el client i el servidor sense ell. La [guia de contribució](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) descriu les proves i les comprovacions que cal executar.
+
+</div>
+</div>
+
+---
+
+## Primera execució
+
+Obre el servidor en un navegador (amb el `.env` d'exemple, `https://your_ip:8443`). Amb una base de dades buida, l'esquema es crea en el
+primer inici.
+
+Les credencials d'administrador predeterminades són:
+
+* nom d'usuari : `admin`
+* contrasenya : `AnsibleForms!123`
diff --git a/i18n/ca/_get_started/installation/index.md b/i18n/ca/_get_started/installation/index.md
new file mode 100644
index 0000000..38a5a67
--- /dev/null
+++ b/i18n/ca/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Instal·lació
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Instal·lació
+{: .no_toc }
+
+Tria un mètode d'instal·lació per a AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Per als administradors que posen en marxa una instància nova: tria un mètode d'instal·lació i després segueix-ne la pàgina.
+
+---
+
+## En aquesta secció
+
+AnsibleForms admet diversos mètodes d'instal·lació, cadascun descrit a la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Instal·lador](installer.html) | Una sola ordre que instal·la un controlador o un Runner a Docker, Podman, Kubernetes o de manera nativa, i després l'actualitza i en fa còpies de seguretat |
+| [Nativa](native.html) | La instal·lació de l'instal·lador sense contenidors: Node.js, MariaDB i Ansible al servidor, AnsibleForms com a serveis de systemd |
+| [Docker](docker.html) | Instal·la MySQL i executa la imatge de Docker precompilada amb les variables d'entorn necessàries |
+| [Docker Compose](docker-compose.html) | Baixa el [projecte de docker-compose](https://github.com/ansibleforms/docker) i fes servir docker-compose per iniciar alhora MySQL i AnsibleForms |
+| [Des del codi font](from-source.html) | Instal·la totes les dependències a mà, i després compila i inicia el codi |
+| [Kubernetes](kubernetes.html) | Instal·la el chart de Helm i fes servir Kubernetes per iniciar AnsibleForms i la seva base de dades MySQL |
+
+{: .note }
+> **Recomanació** L'instal·lador, des de la 7.3.0, és la manera més ràpida de tenir una instància en marxa: configura el projecte de Docker Compose a
+> Docker o Podman, o un dels altres mètodes, a partir d'unes quantes preguntes. Les imatges de Docker inclouen totes les dependències.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Per passar una instal·lació existent a una versió més nova, consulta [Actualització](../upgrading/).
+
+Cada mètode executa un RTE al costat de l'aplicació, el contenidor (o servei) que executa els playbooks. Per afegir-ne un altre, en un altre host o en un altre
+centre de dades, instal·la un Runner amb l'[instal·lador](installer.html#a-runner): truca a AnsibleForms a través d'un WebSocket (outbound, consulta
+[Modes](../rte/modes.html)) i no té credencials de la base de dades. Consulta també [Entorns d'execució](../rte/) i el seu runbook
+[Un RTE en un altre centre de dades](../rte/another-datacenter.html).
+
+---
+
+## Etiquetes d'imatge
+
+La imatge es publica com a `ghcr.io/ansibleforms/ansibleforms` al GitHub Container Registry, que pertany al
+projecte i no limita les baixades anònimes. Totes les versions a partir de la 7.0.0 només es publiquen allà, i les versions 6.x
+també hi són.
+
+Des de la 7, els playbooks s'executen en un RTE, publicat en tres capes al costat de l'aplicació (consulta [Les imatges de l'RTE](../rte/images.html)):
+
+| Imatge | Què és |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | L'aplicació web i l'API, sense python ni ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | L'RTE sense python ni ansible: la base per a la teva |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base amb python, ansible-core i unes quantes biblioteques: la que has de fer servir per afegir-hi les teves col·leccions |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | El core amb el paquet `ansible`, les seves col·leccions i biblioteques: l'RTE predeterminat |
+
+Les quatre imatges es construeixen en la mateixa execució i porten les mateixes etiquetes, així que una etiqueta de l'RTE sempre coincideix amb la de l'aplicació.
+
+L'antic repositori de Docker Hub, `ansibleguy/ansibleforms`, ja no s'actualitza. Conserva les seves
+versions existents, però no rep versions noves de cap de les dues línies. Si hi fas pull, canvia
+a `ghcr.io/ansibleforms/ansibleforms` amb la mateixa etiqueta per continuar rebent actualitzacions.
+
+Les etiquetes següents estan disponibles a cada imatge; les imatges de l'RTE comencen a la 7.0.0, així que no tenen etiquetes 6.x:
+
+| Etiqueta | Apunta a |
+|---|---|
+| `latest` | la versió més nova de la versió major més nova |
+| `7`, `6` | la versió més nova d'aquella versió major |
+| `7.0`, `6.5` | la versió més nova d'aquella versió menor |
+| `7.0.0`, `6.5.5` | exactament aquella versió |
+| `latest-rc` | la release candidate més nova, o la versió més nova quan és més recent; cada candidata també té la seva pròpia etiqueta |
+
+`latest` només avança: un pedaç per a una versió major més antiga (per exemple una 6.5.x publicada
+després de la 7.0.0) mou `6` i `6.5`, però mai `latest`.
+
+Per quedar-te en una versió major, fes servir el seu número (`6`) en lloc de `latest`.
diff --git a/i18n/ca/_get_started/installation/installer.md b/i18n/ca/_get_started/installation/installer.md
new file mode 100644
index 0000000..b64d814
--- /dev/null
+++ b/i18n/ca/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Instal·lador
+parent: Instal·lació
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# L'instal·lador
+{: .no_toc }
+
+Instal·la, actualitza i manté AnsibleForms en un servidor Linux, amb una sola ordre
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors: la manera més ràpida de tenir una instància en marxa, o un Runner per a un AnsibleForms instal·lat en un altre lloc. Des de la 7.3.0.
+
+---
+
+## Què instal·la
+
+L'instal·lador fa unes quantes preguntes en un assistent a pantalla completa, mostra totes les respostes perquè les revisis, i només aleshores canvia el servidor.
+Instal·la un de dos rols, en un de quatre motors:
+
+| Rol | Què és |
+|---|---|
+| Controlador | L'aplicació completa: la interfície web, la seva base de dades i el seu propi Runner. Tria aquest per a una primera instal·lació |
+| Runner | Un RTE que executa els playbooks d'un AnsibleForms instal·lat en un altre lloc, com ara en una altra xarxa, una DMZ o un altre centre de dades. Parla amb AnsibleForms a través d'un sol WebSocket i no té credencials de la base de dades |
+
+Els motors on els instal·la:
+
+| Motor | Com s'executa |
+|---|---|
+| Docker | El [projecte de Docker Compose](docker-compose.html), a Docker Engine amb el seu plugin compose. Els contenidors es reinicien juntament amb Docker |
+| Podman | El mateix projecte a Podman, rootless o com a root, amb podman-compose. Una unitat de systemd inicia els contenidors en arrencar |
+| Kubernetes | El [chart de Helm](kubernetes.html), al clúster on arriba `kubectl`. Un controlador se serveix darrere d'un ingress; un Runner fa servir el mode runner del chart |
+| Directament en aquest servidor | Sense contenidors: Node.js, MariaDB i Ansible al servidor, i AnsibleForms com a serveis de systemd. Consulta [Instal·lació nativa](native.html) |
+
+Després de la instal·lació, el mateix programa actualitza la instal·lació, en fa còpies de seguretat, en mostra l'estat i l'elimina. També es fa càrrec d'un
+AnsibleForms que no ha instal·lat ell, com ara un configurat a mà a partir del projecte de Docker Compose (consulta [Una instal·lació existent](#an-existing-installation)).
+
+---
+
+## Executar-lo
+
+L'script d'instal·lació baixa l'instal·lador per a aquest servidor i l'inicia:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Les variants habituals: com a root, per instal·lar Docker o Podman, per instal·lar directament al servidor o sota `/opt`; amb una ordre o
+amb opcions (consulta [Opcions](#flags)); i un instal·lador d'una versió concreta en lloc de la més recent:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+L'script:
+
+1. Comprova que el servidor executa Linux en amd64 o arm64, i troba `curl` o `wget` i `sha256sum`
+2. Baixa `ansibleforms-installer_linux_<arch>` de la darrera versió de
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases), o de la versió que indica `AF_INSTALLER_VERSION`
+3. El comprova amb el `checksums.txt` de la versió, i no fa servir cap baixada amb un checksum diferent
+4. El conserva com a `ansibleforms-installer`, a `/usr/local/bin` per a root i a `~/.local/bin` altrament, per a les actualitzacions i les còpies de seguretat posteriors.
+   Amb sudo, executa'l amb la ruta completa: el `secure_path` de sudo, com als sistemes Red Hat, sovint no inclou `/usr/local/bin`
+5. L'inicia amb les opcions donades, llegint el teclat des del terminal encara que l'script hagi arribat a través d'una canonada
+
+Sense terminal, com ara en una tasca de CI, l'instal·lador s'executa de manera desatesa (consulta [Desatès](#unattended)).
+
+---
+
+## L'assistent
+
+L'assistent fa una pregunta cada vegada, amb els passos llistats a l'esquerra. **Esc** torna al pas anterior, i en conserva la resposta:
+
+| Pas | Què pregunta |
+|---|---|
+| Idioma | L'idioma de l'instal·lador, per defecte el de la configuració regional d'aquest servidor: català, alemany, anglès, espanyol, francès, italià, japonès, neerlandès, polonès, portuguès o xinès. Es pregunta el primer, abans que l'instal·lador digui res d'una instal·lació que hagi trobat |
+| Novetats | El que hi ha de nou a la versió que instal·la, amb primer els canvis incompatibles, les eliminacions i les funcions obsoletes |
+| Rol | Controlador o Runner |
+| Motor | Docker, Podman, Kubernetes, o directament en aquest servidor |
+| Carpeta | La carpeta d'instal·lació i el nom de la instància |
+| Unió, Aplicació, Mode | Només un Runner: consulta [Un Runner](#a-runner). A Kubernetes no es pregunta el mode |
+| Xarxa | El port de la interfície web, o del Runner. No a Kubernetes |
+| HTTPS | Com es connecten els navegadors a un controlador |
+| Admin | La contrasenya del primer administrador, escrita dues vegades |
+| Clúster, Ingress, Emmagatzematge | Només Kubernetes: el namespace i la release, l'ingress (un controlador), la classe d'emmagatzematge |
+| Revisió | Totes les respostes: **Instal·la**, o **Canvia les respostes** |
+
+**Motor.** La llista mostra el que té aquest servidor. Un motor que hi falta s'ofereix com a *Docker (no instal·lat: l'instal·lador l'instal·la)*
+o el mateix per a Podman: quan ho confirmes, l'instal·lador instal·la Docker amb l'script del mateix Docker (`get.docker.com`, amb el plugin compose
+inclòs) o Podman amb podman-compose des dels paquets de la distribució. Això necessita root. Kubernetes s'ofereix quan `kubectl` i
+`helm` estan instal·lats i arriben a un clúster. *Directament en aquest servidor* necessita root i un Linux compatible, i diu per què quan apareix en gris.
+
+**Carpeta.** Els valors predeterminats:
+
+| | Controlador | Runner |
+|---|---|---|
+| Carpeta, com a root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Carpeta, com a un altre usuari | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Nom de la instància, Docker o Podman | `af` | `runner` |
+| Nom de la instància, nativa | `ansibleforms` | `ansibleforms-runner` |
+
+Amb Docker o Podman, la carpeta conté el fitxer compose i el seu `.env` amb els secrets, i totes les dades: base de dades, formularis, playbooks
+i registres. Ha d'estar buida. El nom de la instància, en minúscules, dígits i `-`, és el prefix dels contenidors (`af_app`, `af_db`, `af_rte`), així que diverses
+instàncies poden compartir un servidor. El nom de la instància d'un Runner també és el nom del seu runner a **Connexions > Runners** (`RTE_NAME`).
+
+**Xarxa.** La interfície web d'un controlador escolta al `443`, o al següent port lliure. **HTTPS** ofereix aleshores:
+
+| Opció | Què fa |
+|---|---|
+| HTTPS amb un certificat autosignat creat per a aquest servidor | Un certificat per als noms d'aquest servidor, vàlid durant deu anys. Els navegadors et demanen que l'acceptis una vegada |
+| HTTPS amb el meu propi certificat i clau | El teu propi certificat i clau, en format PEM, de la teva CA o de Let's Encrypt |
+| HTTP, amb HTTPS gestionat per un servidor intermediari invers | HTTP sense xifrar al port, per a nginx, Traefik o un balancejador de càrrega que gestioni HTTPS |
+
+**Admin.** La contrasenya de l'usuari `admin`, escrita dues vegades perquè un error tipogràfic no et deixi fora. Si es deixa buida, l'instal·lador en genera
+una de robusta.
+
+**El final.** L'instal·lador genera la contrasenya de la base de dades i els secrets, inicia AnsibleForms i espera que respongui. Després
+mostra l'adreça que cal obrir, l'usuari i la contrasenya, i la carpeta. Els Runners instal·lats per a ell demanen unir-s'hi, i un administrador els aprova
+a **Connexions > Runners** (consulta [Un Runner](#a-runner)).
+
+---
+
+## Un Runner
+
+Un Runner és un RTE per a un AnsibleForms que s'executa en un altre lloc, amb la versió 7.3.0 o posterior. No té credencials de la base de dades: s'autentica
+amb un token propi, que AnsibleForms guarda en una credencial d'RTE (consulta [Modes](../rte/modes.html)). Després de la carpeta, l'assistent
+pregunta tres coses més:
+
+| Pas | Què pregunta |
+|---|---|
+| Aplicació | L'adreça de l'AnsibleForms per al qual treballa aquest Runner, la que la gent obre en un navegador |
+| Mode | **Sortint: el Runner es connecta a AnsibleForms** (el predeterminat), o **Entrant: AnsibleForms es connecta al Runner** |
+| Xarxa | El port del Runner, `8000` per defecte. En sortint, només hi escolten les comprovacions de salut, accessibles només des d'aquest servidor. En entrant, també l'adreça d'aquest servidor tal com hi arriba AnsibleForms |
+
+`--role runner` se salta la pregunta del rol, així que aquesta ordre, executada al servidor del Runner, comença amb les preguntes d'un Runner:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+Després l'instal·lador es connecta a AnsibleForms. Un certificat autosignat, o un d'una CA privada, pregunta **Voleu confiar en aquest certificat?**:
+sí defineix [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) al Runner. Llegeix la versió que executa AnsibleForms,
+en rebutja una anterior a la 7.3.0, i instal·la el Runner amb aquesta mateixa versió, sigui quina sigui la versió que instal·laria el mateix instal·lador.
+
+Tria sortint per a una DMZ, NAT o una zona que no permet connexions entrants: només trànsit d'aquest servidor cap a AnsibleForms, al seu
+port. Tria entrant per a xarxes on el costat central obre totes les connexions.
+
+La revisió mostra **Registre: demana aprovació**, o **sol, amb un token d'unió** quan `--join` n'ha donat un. Al final l'instal·lador
+mostra el nom del Runner, el seu mode, l'aplicació i, en entrant, la seva adreça, i després diu que ha demanat unir-se a AnsibleForms: aprova'l a
+**Connexions > Runners**, després de comprovar que l'empremta que s'hi mostra és la que imprimeix:
+
+```
+Fingerprint: abcd-ef12
+```
+
+L'empremta són els primers 8 dígits hexadecimals del SHA-256 del token del Runner, `RTE_TOKEN`, que es guarda al fitxer
+`.env` de la carpeta (`rte.env` per a una [instal·lació nativa](native.html)). Consulta [Aprovar un RTE](../runners/registration.html#approving-an-rte). Amb `--join`, el Runner s'aprova a l'instant:
+s'ha registrat ell mateix, i apareix com a connectat a **Connexions > Runners**.
+
+Un Runner entrant serveix el seu socket per HTTPS. L'instal·lador crea un certificat autosignat per a l'adreça per on hi arriba AnsibleForms,
+vàlid durant deu anys, a `data/certificates` de la carpeta, i defineix `RTE_URL` com a `https://<address>:<port>`.
+El Runner envia el certificat quan demana unir-se, i AnsibleForms el fixa: només truca a aquell Runner quan presenta
+aquest mateix certificat, així que no cal cap CA. L'instal·lador imprimeix l'empremta del certificat sota la del token:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+Són els primers 8 dígits hexadecimals del SHA-256 dels bytes DER del certificat, com a `xxxx-xxxx`. Abans d'aprovar el Runner,
+comprova que el diàleg d'aprovació mostra la mateixa empremta del certificat. Un Runner registrat amb `--join` també la imprimeix.
+
+A Kubernetes, un Runner és el mode runner del chart de Helm, i sempre és sortint: l'assistent no pregunta ni el mode ni la xarxa, ja que res
+no hi arriba des de fora (consulta [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Per a un controlador a Kubernetes, l'instal·lador instal·la el [chart de Helm](kubernetes.html) al clúster on arriba `kubectl`:
+
+| Pregunta | Valor predeterminat |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nom de la release de Helm | `ansibleforms` |
+| Nom d'amfitrió servit per l'ingress | Cap: obligatori, per exemple `ansibleforms.example.com` |
+| Classe d'ingress | Una de les del clúster, `nginx` per defecte |
+| Voleu servir-lo per HTTPS (amb el certificat de l'ingress)? | Sí |
+| Classe d'emmagatzematge per als volums | La predeterminada del clúster |
+
+La contrasenya de l'administrador és al Secret `<release>-secrets` d'aquest namespace, amb la clau `ADMIN_PASSWORD`. L'instal·lador guarda els
+values del chart en un fitxer al costat del seu fitxer d'estat, `<release>-values.yaml`, i el torna a aplicar en les actualitzacions; `--values` hi afegeix un fitxer propi. El chart d'una versió es publica poc després d'ella.
+
+Per a un Runner, l'instal·lador instal·la el mateix chart en el seu [mode runner](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): un RTE
+sol, sense aplicació, sense base de dades i sense ingress, que truca a AnsibleForms (sortint). Després de l'adreça de l'aplicació, l'assistent pregunta:
+
+| Pregunta | Valor predeterminat |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nom de la release de Helm | `ansibleforms-runner`, que també és el nom del seu runner a **Connexions > Runners** |
+| Classe d'emmagatzematge per als volums | La predeterminada del clúster |
+
+L'instal·lador crea el token del Runner i defineix l'adreça de l'aplicació, el nom del runner i, quan confies en el certificat de l'aplicació,
+`runner.appTlsVerify: false`. Amb `--join`, el token d'unió aprova el Runner a l'instant; sense, el Runner demana unir-se, i
+l'instal·lador n'imprimeix l'empremta perquè la comprovis abans d'aprovar-lo a **Connexions > Runners**.
+
+---
+
+## Ordres
+
+L'instal·lador accepta una ordre, abans o després de les opcions. Sense cap ordre, instal·la:
+
+| Ordre | Què fa |
+|---|---|
+| `install` | Instal·la AnsibleForms, com a controlador o com a Runner (el predeterminat). En un servidor que ja té una instal·lació, la seva o una que troba, ofereix actualitzar-la |
+| `upgrade` | Actualitza a una versió més nova, mostrant-ne primer les novetats (consulta [Actualitzar](#upgrade)) |
+| `status` | Mostra la instal·lació (el seu rol, motor i versió) i els seus contenidors, pods o serveis, i si respon. Després llista qualsevol altre AnsibleForms que trobi al servidor |
+| `backup` | Fa ara una còpia de seguretat de la base de dades, a `installer-backups` dins la carpeta d'instal·lació (a Kubernetes, `backups` al costat del fitxer d'estat de l'instal·lador). Un Runner no té dades de què fer còpia |
+| `release-notes` | Mostra les novetats d'una versió, `--version` o la d'aquest instal·lador, amb primer els canvis incompatibles |
+| `uninstall` | Elimina la instal·lació, i amb `--purge` les seves dades |
+| `version` | Imprimeix la versió de l'instal·lador |
+
+L'instal·lador recorda la instal·lació a `/etc/ansibleforms/installer.json` per a root, o a `~/.config/ansibleforms/installer.json`
+per a un altre usuari, així que les ordres posteriors a `install` no necessiten opcions i troben la instal·lació tot soles. Aquesta carpeta no conté cap binari,
+i només existeix un cop l'instal·lador ha instal·lat un AnsibleForms o se n'ha fet càrrec d'un:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` pregunta **Suprimir també les dades (base de dades, formularis, playbooks, logs)?**. Per suprimir-les, escriu el nom de la instància (la release de Helm
+a Kubernetes); altrament elimina els contenidors, els pods o els serveis i conserva les dades.
+
+---
+
+## Opcions
+
+Cada opció respon una pregunta, que l'assistent aleshores se salta. `ansibleforms-installer --help` les llista:
+
+| Opció | Què respon |
+|---|---|
+| `--lang <code>` | L'idioma: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` o `zh` |
+| `--version <version>` | La versió d'AnsibleForms que s'instal·la o a la qual s'actualitza; la d'aquest instal·lador per defecte |
+| `--role <role>` | `controller` o `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` o `native` |
+| `--runtime <runtime>` | `docker` o `podman` (compose) |
+| `--install-runtime` | Instal·la Docker o Podman quan falta, sense preguntar |
+| `--dir <folder>` | La carpeta d'instal·lació (compose) |
+| `--name <name>` | El nom de la instància, el prefix dels seus contenidors (compose, `af` per defecte) |
+| `--port <port>` | El port de l'amfitrió: la interfície web per a un controlador, l'RTE per a un Runner |
+| `--tls <choice>` | `self`, `own` o `off` (un controlador compose) |
+| `--cert <file>`, `--key <file>` | Els fitxers del certificat i de la clau, amb `--tls own` |
+| `--admin-password <password>` | La contrasenya del primer administrador; generada per defecte |
+| `--join <token>` | Un token d'unió (`afj_...`), creat a través de l'API, que aprova el Runner a l'instant (un Runner, desatès; consulta [Tokens d'unió](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | L'adreça de l'aplicació, com ara `https://forms.example.com` (un Runner) |
+| `--runner-mode <mode>` | `outbound` (l'RTE truca a l'aplicació) o `inbound` (l'aplicació truca a l'RTE) (un Runner) |
+| `--host <address>` | L'adreça d'aquest servidor, a la qual truca l'aplicació (un Runner entrant) |
+| `--namespace <namespace>` | El namespace de Kubernetes, `ansibleforms` per defecte |
+| `--release <release>` | La release de Helm, `ansibleforms` per defecte |
+| `--hostname <name>` | El nom d'amfitrió de l'ingress (kubernetes) |
+| `--ingress-class <class>` | La classe d'ingress (kubernetes) |
+| `--storage-class <class>` | La classe d'emmagatzematge (kubernetes) |
+| `--values <file>` | Un fitxer de values de Helm addicional (kubernetes) |
+| `--purge` | Amb `uninstall`: també suprimeix les dades |
+| `--source <folder>` | Una còpia local del repositori [ansibleforms/docker](https://github.com/ansibleforms/docker) des de la qual instal·lar (sense connexió) |
+| `--bundle <file>` | Un bundle de versió, `ansibleforms-<version>-linux-<arch>.tar.gz`, des del qual instal·lar de manera nativa (consulta [Instal·lació nativa](native.html#air-gapped)) |
+| `--yes` | Respon totes les preguntes amb el seu valor predeterminat (desatès) |
+| `--verbose` | Mostra totes les ordres que executa |
+
+---
+
+## Desatès
+
+Amb `--yes`, o sense terminal, l'instal·lador no pregunta res: les opcions responen les seves preguntes i els valors predeterminats responen la resta. Se salta
+l'idioma, les novetats, la contrasenya de l'administrador (generada, tret que `--admin-password` en doni una) i la revisió, i en canvi imprimeix
+l'enllaç a les novetats. Només instal·la un Docker o un Podman que falti amb `--install-runtime` o `--yes`, i un Runner
+necessita `--app-url`. Sense `--join`, el Runner demana unir-se i espera l'aprovació d'un administrador; amb aquesta opció, s'aprova a l'instant.
+
+Un controlador a Docker, que instal·la Docker quan falta:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Un Runner entrant a Podman, al qual l'aplicació truca a `rte-dmz.example.com:8000`:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Una instal·lació existent
+
+L'instal·lador recorda el que ha instal·lat a `installer.json`. Sense aquest fitxer, `install`, `upgrade` i `status` busquen primer un
+AnsibleForms que ja sigui al servidor, sigui qui sigui qui l'hagi instal·lat:
+
+| Trobat | Com es troba | Se'n fa càrrec quan |
+|---|---|---|
+| Docker o Podman | Contenidors de la imatge de l'aplicació o de l'RTE, agrupats per projecte compose | La carpeta conté el fitxer compose i el `.env` del repositori [ansibleforms/docker](https://github.com/ansibleforms/docker): els serveis `mysqldb`, `app` i `rte`, als contenidors `<name>_db`, `<name>_app` i `<name>_rte` |
+| Un Runner de la 7.2 | Un RTE sol al seu projecte compose, amb els `DB_*` de l'aplicació i sense `RTE_MODE` (mode database) | El seu fitxer compose es pot llegir. La seva actualització el passa a un mode de socket (consulta [Un Runner de la 7.2](#a-72-runner)) |
+| Kubernetes | Releases de Helm del chart `ansibleforms`, i Deployments i StatefulSets de les seves imatges | És una release del chart: els seus values actuals es converteixen en el seu fitxer de values |
+| Nativa | Serveis de systemd que executen AnsibleForms amb Node.js | Segueixen l'estructura de l'instal·lador: `releases/`, `current`, `app.env` i `rte.env` (consulta [Instal·lació nativa](native.html#the-folder)) |
+| Cap motor | L'aplicació o un RTE que respon en un port habitual: 443, 3000, 3001, 8000, 8001, 8010 o 8443 | Mai: s'executa des del codi font o a mà. L'instal·lador només n'informa |
+
+Només compten les imatges de l'aplicació i de l'RTE: un contenidor de MySQL amb el nom d'AnsibleForms no és una instal·lació. L'instal·lador llista el que
+ha trobat, una línia per element, amb el motiu i el que cal fer a mà per a un del qual no es pot fer càrrec: el seu fitxer compose no és el del repositori,
+la seva base de dades és fora del seu projecte compose, s'executa a Kubernetes sense el chart de Helm, el gestiona Argo CD (actualitza'l allà,
+canviant la versió del chart de l'Application), o no se'n pot llegir la versió.
+
+Per a una instal·lació de la qual es pot fer càrrec, `install` ofereix tres opcions:
+
+| Opció | Què fa |
+|---|---|
+| Fer-se'n càrrec i actualitzar | Mostra el que recordarà, després escriu `installer.json` un cop ho confirmes, i continua amb l'[actualització](#upgrade) |
+| Instal·lar igualment un nou AnsibleForms al costat | Una segona instal·lació, amb la seva pròpia carpeta, ports i base de dades, després d'una confirmació pròpia |
+| Atura | No es canvia res |
+
+Per a una instal·lació que ja executa la versió que instal·laria l'instal·lador, la primera opció és **Fes-te'n càrrec**: l'instal·lador
+recorda on és i com s'executa, per a les seves còpies de seguretat, el seu estat i les properes actualitzacions, i ara no es canvia res.
+
+`upgrade` ofereix el mateix sense la segona opció, i s'atura quan no es pot fer càrrec de res. De manera desatesa, `install` s'atura amb un missatge,
+i `upgrade --yes` només es fa càrrec d'una instal·lació quan en troba exactament una de la qual es pot fer càrrec. Els values actuals d'una release de Kubernetes es
+desen al costat d'`installer.json`, i les actualitzacions els tornen a aplicar amb el chart de la versió nova.
+
+---
+
+## Actualitzar
+
+`ansibleforms-installer upgrade` porta la instal·lació a una versió més nova de la mateixa versió major. Llista les versions més noves,
+la més recent primer (de manera desatesa, agafa la més recent), i mostra les novetats de cada versió que deixa enrere, amb primer els canvis incompatibles
+i les eliminacions. Quan contenen canvis incompatibles, et demana que confirmis que les has llegides; de manera desatesa, només `--yes` continua.
+
+L'instal·lador fa una còpia de seguretat de la base de dades abans de canviar res. Quan la versió nova no respon, ofereix tornar enrere: torna la versió
+anterior, i la seva base de dades es restaura a partir d'aquella còpia. No baixa de versió, i no travessa una versió major: per a això segueix
+la [guia d'actualització](../upgrade-7.html), per exemple de la 6.x a la 7.x, amb el que cal fer a la 6.5 abans d'actualitzar.
+
+A Docker o Podman, l'actualització d'un controlador també posa al dia els seus fitxers amb la versió nova del repositori docker:
+
+| Fitxer | Què fa l'actualització |
+|---|---|
+| `docker-compose.yml` | Se substitueix pel de la versió nova, després de desar-ne una còpia a `installer-backups` |
+| `.env` | Es conserva cada línia existent, i s'hi afegeixen les claus que necessita la versió nova, amb secrets creats com els crea una instal·lació nova. Abans se'n desa una còpia |
+| `data/seed.yaml` | Se substitueix quan és un seed que venia amb el repositori docker, sense canvis. Un que s'hagi canviat a mà es conserva, i el nou es desa al costat |
+| `data/` | S'hi afegeixen els fitxers nous que porta la versió, com ara un playbook nou. Es conserven tots els fitxers que ja existeixen |
+
+Un paràmetre de base de dades que falti (`MYSQLDB_USER` o una contrasenya) no es pot inventar per a una base de dades que ja existeix, així que aleshores l'actualització s'atura abans
+de cap canvi. Una marxa enrere torna a deixar el fitxer compose, el `.env` i el seed tal com eren.
+
+Un Runner executa la mateixa versió que el seu AnsibleForms: actualitza primer AnsibleForms, i després els seus Runners. L'actualització d'un Runner reescriu el seu
+fitxer compose per a la nova imatge de l'RTE i en conserva el `.env` i les dades tal com són.
+
+---
+
+## Un Runner de la 7.2
+
+Un Runner de la 7.2 s'executa en mode database, obsolet des de la 7.3.0: el seu RTE té la configuració de la base de dades d'AnsibleForms. L'instal·lador el
+troba (consulta [Una instal·lació existent](#an-existing-installation)), i la seva actualització el passa a un mode de socket amb el mateix runner:
+
+1. Llegeix el nom del runner (`RTE_NAME`) i el token (`RTE_TOKEN`) del contenidor de l'RTE antic. Quan l'RTE no es registrava ell mateix
+   (`RTE_REGISTER=0`), escrius el nom que té el seu runner a **Connexions > Runners**
+2. Pregunta l'adreça de l'aplicació i el mode, **sortint** per defecte o entrant, i en entrant el port i l'adreça d'aquest servidor
+3. Mostra el pla, i després fa una còpia de seguretat del fitxer compose antic i del `.env` a `installer-backups`
+4. Escriu l'estructura de Runner de l'instal·lador sense els paràmetres `DB_*`. Conserva `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` i `METRICS_TOKEN`, que un RTE en mode de socket encara llegeix
+5. Inicia l'RTE nou al costat de l'antic. L'RTE nou s'autentica amb el token propi del runner, i AnsibleForms passa el runner al
+   mode nou ell mateix, **sense cap aprovació**: les seves tasques i els formularis que l'anomenen no canvien
+6. Un cop l'RTE nou està connectat, el contenidor antic s'atura i s'elimina
+
+Un Runner entrant serveix HTTPS amb un certificat fixat, com en fa un de nou (consulta [Un Runner](#a-runner)), i l'instal·lador n'imprimeix
+l'empremta del certificat. Quan l'RTE antic ocupa el port que necessita el nou, primer s'atura, així que el Runner queda fora de línia fins que
+el nou es connecta. L'RTE nou d'un Runner sortint agafa un port lliure a `127.0.0.1` i s'executa al costat de l'antic sense interrupció.
+
+Quan l'instal·lador no pot llegir cap token de l'RTE antic, tries com s'autentica l'RTE nou:
+
+| Opció | Què passa després |
+|---|---|
+| Escriure el testimoni del runner | La contrasenya de la credencial d'RTE del runner a **Connexions > Credencials**. El runner conserva el nom i les tasques |
+| Unir-se com a runner nou amb un testimoni d'unió | Un [token d'unió](../runners/registration.html#join-tokens) afegeix un runner nou amb un altre nom. Retira el runner antic a mà |
+
+Quan l'RTE nou no es connecta, l'instal·lador ofereix tornar a posar els fitxers antics i tornar a iniciar el contenidor antic; si AnsibleForms
+ja havia passat el runner al mode nou, torna a posar-ne el mode a database a **Connexions > Runners**. Un cop l'RTE nou està connectat, ja no
+hi ha marxa enrere: els fitxers antics es queden a `installer-backups`.
+
+Quan AnsibleForms no coneix cap runner amb aquest nom, l'RTE nou demana unir-se i espera una aprovació. Rebutja aquesta sol·licitud a
+**Connexions > Runners**, i després torna a executar l'actualització amb el nom que hi té el runner.
+
+---
+
+## Versions
+
+La versió de l'instal·lador segueix la de l'aplicació: cada versió d'AnsibleForms ve amb un instal·lador de la mateixa versió, publicat amb ella, i
+aquest instal·lador instal·la aquesta versió per defecte. `--version` n'instal·la una altra. Cada versió de la
+[pàgina de Releases de l'instal·lador](https://github.com/ansibleforms/installer/releases) té binaris per a Linux en amd64 i arm64, amb els seus
+checksums.
diff --git a/i18n/ca/_get_started/installation/kubernetes.md b/i18n/ca/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..3a438c9
--- /dev/null
+++ b/i18n/ca/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Instal·lació
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Instal·la AnsibleForms i la seva base de dades MySQL amb el chart de Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+El chart de Helm desplega AnsibleForms amb MySQL i l'RTE que executa els playbooks (consulta la [referència de values](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+L'[instal·lador](installer.html) també instal·la el chart, a partir d'unes quantes preguntes, i actualitza una release que no ha instal·lat ell. El mateix
+chart també instal·la un Runner independent, per a un AnsibleForms que s'executa en un altre lloc (consulta [Un Runner a Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Requisits previs
+
+Abans de començar, necessites:
+
+* **Un clúster de Kubernetes** : amb `kubectl` configurat per arribar-hi
+* **Helm 3** : per instal·lar i actualitzar el chart
+* **Emmagatzematge** : una StorageClass per a l'aprovisionament dinàmic, o PersistentVolumes creats prèviament
+* **Un controlador d'ingress** : només si vols exposar AnsibleForms a través d'un ingress
+
+---
+
+## 1. Obtén els values del chart
+
+Obtén els values predeterminats del chart en un fitxer propi, des del repositori del chart o des del registre OCI:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Repositori de charts</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">Registre OCI</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+No cal afegir cap repositori: el chart es baixa del GitHub Container Registry.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Configura l'emmagatzematge
+
+Tant AnsibleForms com MySQL desen les seves dades en un volum persistent. Defineix la StorageClass i la mida de cadascun:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Un `className` buit fa servir la StorageClass predeterminada del clúster. El mode d'accés per defecte és `ReadWriteMany`, que moltes classes
+d'emmagatzematge no ofereixen; `ReadWriteOnce` va bé amb una sola rèplica. Per a PersistentVolumes creats prèviament, consulta el
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart.
+
+---
+
+## 3. Defineix les credencials
+
+AnsibleForms necessita un compte d'administrador, una contrasenya de la base de dades i un `ENCRYPTION_SECRET`, la clau que xifra les credencials
+desades a AnsibleForms. Per canviar aquesta clau més endavant, posa a [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+l'antiga durant un inici: aleshores cada secret desat es torna a xifrar amb la clau nova. Proporciona-les d'una d'aquestes tres maneres:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">Al fitxer de values</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Generades pel chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Secret existent</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Defineix-les a `my_values.yaml`. El chart les desa en un Secret anomenat `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Deixa que el chart generi el que no proporcionis, en la primera instal·lació. Després conserva els mateixos valors a cada
+actualització:
+
+```bash
+--set secrets.generate=true
+```
+
+Això no funciona amb Argo CD ni amb Flux, que renderitzen el chart sense accés al clúster. El Secret generat
+sobreviu a `helm uninstall`; fes-ne una còpia de seguretat, perquè `ENCRYPTION_SECRET` no es pot recuperar.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Fes que el chart apunti a un Secret que gestiones tu, per exemple amb External Secrets, Sealed Secrets o SOPS. Aleshores el chart
+no en crea cap:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+El Secret ha de contenir `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` i `ADMIN_PASSWORD`.
+
+</div>
+</div>
+
+---
+
+## 4. Tria la imatge de l'RTE
+
+AnsibleForms 7 no executa cap playbook per si mateix: ho fa l'RTE (runtime environment, entorn d'execució). El chart l'executa com un segon contenidor al
+pod del servidor, sobre el mateix volum, i el registra com a runner predeterminat `rte`, així que els formularis de playbook funcionen sense cap configuració. Des de la 7.3.0
+l'aplicació el truca a `127.0.0.1` i hi manté un WebSocket obert (`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)): l'RTE no rep cap
+configuració de la base de dades ni cap clau de xifratge. El config seed del chart declara una credencial d'RTE amb el token i aquesta adreça, i
+el runner, en mode inbound, que s'hi autentica.
+
+La imatge predeterminada, `ghcr.io/ansibleforms/ansibleforms-rte-full`, conté ansible amb les seves col·leccions i les biblioteques de Python que tenia la imatge de la 6.5.
+Per tenir-ne més, o menys, construeix-ne una de pròpia sobre una de les tres capes de l'RTE (`ansibleforms-rte-base`, `-rte-core` o `-rte-full`, consulta
+[Les imatges de l'RTE](../rte/images.html)) i fes que el chart hi apunti:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+El token entre l'aplicació i l'RTE, i la clau que signa les sessions, es generen en la primera instal·lació al
+Secret `<release>-keys` i es conserven a cada actualització. Amb un config seed propi, afegeix-hi aquesta credencial i aquest runner: les notes que mostra Helm després de la instal·lació expliquen com fer-ho
+(consulta el [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart).
+
+---
+
+## 5. Instal·la el chart
+
+Instal·la el chart al seu propi namespace amb els teus values:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Amb el registre OCI, fes servir `oci://ghcr.io/ansibleforms/charts/ansibleforms` com a chart. En qualsevol cosa que s'executi de manera desatesa,
+fixa la versió del chart amb `--version`, perquè mai no s'instal·li una versió nova tota sola.
+
+---
+
+## 6. Comprova la instal·lació
+
+El chart inclou una prova que comprova tant el servidor web com la connexió a la base de dades:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+La prova acaba amb `OK` quan AnsibleForms respon i la seva base de dades accepta connexions.
+
+---
+
+## 7. Obre AnsibleForms
+
+Com arribes a AnsibleForms depèn de com s'exposa el servidor:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Amb el servei `ClusterIP` predeterminat i sense ingress, no s'exposa res fora del clúster. Redirigeix un port local per
+fer-hi un cop d'ull:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Després obre `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Defineix `services.server.type: LoadBalancer` (opcionalment amb una adreça fixa a `services.server.loadbalancer.ip`),
+i després espera que el servei obtingui la seva adreça:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Activa l'ingress i defineix el nom d'amfitrió que encamina cap al teu controlador d'ingress:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+El [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart explica el TLS darrere d'un ingress, inclòs el paràmetre del backend que necessita HTTPS al
+servidor.
+
+</div>
+</div>
+
+---
+
+## 8. Inicia sessió
+
+Inicia sessió amb l'usuari administrador, `admin` per defecte. Per llegir la contrasenya del Secret:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Amb `secrets.existingSecret`, llegeix-la del teu propi Secret.
+
+---
+
+## Un Runner a Kubernetes
+
+Amb `runner.enabled`, el chart només instal·la un RTE: un Runner per a un AnsibleForms instal·lat en un altre lloc, en un altre namespace, un altre
+clúster o en una VM. Truca a l'aplicació i hi manté un WebSocket obert (`RTE_MODE=outbound`, consulta [Modes](../rte/modes.html)), així que no necessita
+cap base de dades, cap clau de xifratge ni cap port entrant. No renderitza ni aplicació, ni MySQL, ni Service, ni Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Valor | Què fa |
+|---|---|
+| `runner.enabled` | Instal·la només el Runner: sense aplicació, sense MySQL, sense Service, sense Ingress |
+| `runner.appUrl` | L'adreça de l'aplicació tal com l'obre la gent, amb el seu `BASE_URL` si n'hi ha. Obligatori |
+| `runner.name` | El nom de runner amb què s'uneix (`RTE_NAME`). Buit: el nom de la release |
+| `runner.joinToken` | Un [token d'unió](../runners/registration.html#join-tokens) creat a l'aplicació, que es llegeix en el primer inici per aprovar el Runner a l'instant |
+| `runner.appTlsVerify` | `false` accepta el certificat autosignat de l'aplicació (`APP_TLS_VERIFY=0`), només dins d'una xarxa de confiança |
+
+Sense token d'unió, el Runner demana unir-se i espera fins que un administrador l'aprova a **Connexions > Runners**. Un cop aprovat,
+s'autentica amb el seu propi `RTE_TOKEN`, desat al Secret `<release>-keys`: conserva aquest Secret amb la release. L'
+[instal·lador](installer.html#kubernetes) també instal·la aquest mode runner, quan tries el rol Runner i Kubernetes.
+
+---
+
+## Passos següents
+
+El [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart explica la resta de la configuració:
+
+* **La teva pròpia base de dades** : defineix `mysql.enabled: false` i fes que AnsibleForms apunti a un servidor MySQL existent
+* **Formularis des de ConfigMaps** : proporciona `config.yaml` i els fitxers de formularis mitjançant ConfigMaps
+* **HTTPS darrere d'un ingress**, recursos, ubicació als nodes i registres privats
+* **L'RTE** : el seu token, una imatge d'RTE pròpia, o cap RTE
+
+Per passar a una versió més nova, consulta [Actualitzar a Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/ca/_get_started/installation/native.md b/i18n/ca/_get_started/installation/native.md
new file mode 100644
index 0000000..7f7fb02
--- /dev/null
+++ b/i18n/ca/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Nativa
+parent: Instal·lació
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Instal·lació nativa
+{: .no_toc }
+
+AnsibleForms directament al servidor, sense contenidors, com a serveis de systemd que configura l'instal·lador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per als administradors de servidors on no es permeten contenidors: l'[instal·lador](installer.html) instal·la tot el que necessita AnsibleForms al
+mateix servidor, i després l'actualitza i el desinstal·la. Instal·la AnsibleForms 7.3.0 o posterior.
+
+---
+
+## Què necessita
+
+Tria **Directament en aquest servidor, sense contenidors** al pas **Motor** de l'instal·lador, o passa `--mode native`. Necessita:
+
+* **Root** : executa l'instal·lador amb `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : els serveis s'executen com a unitats de systemd
+* **Un Linux compatible** : Ubuntu, Debian, RHEL i les seves recompilacions com ara Rocky Linux i AlmaLinux, SUSE Linux Enterprise o openSUSE
+* **amd64 o arm64**
+* **Accés a Internet** : als repositoris de la distribució, GitHub, nodejs.org i els índexs de paquets de Python i Ansible (consulta
+  [Sense connexió](#air-gapped) per saber què substitueix un bundle de versió)
+
+En un servidor que no compleixi això, el motor apareix com a *Directament en aquest servidor (cal root: executeu-lo amb sudo)* o
+*Directament en aquest servidor (no compatible amb aquest Linux)*. Tots dos rols s'instal·len així: un controlador i un [Runner](installer.html#a-runner).
+
+---
+
+## Què instal·la
+
+L'instal·lador instal·la això des dels paquets de la distribució, per a tots dos rols:
+
+| Paquet | Per què |
+|---|---|
+| `git` | Els repositoris |
+| El client ssh | Les connexions dels playbooks |
+| El client de MariaDB | Les còpies de seguretat de l'aplicació: `app.env` defineix [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) i [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) amb el client trobat, `mariadb-dump` i `mariadb` o els més antics `mysqldump` i `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | Les baixades |
+| `libatomic` | Node.js s'hi enllaça, i els servidors mínims no el tenen |
+| `sshpass` | Els playbooks que inicien sessió amb una contrasenya ssh. A RHEL i les seves recompilacions ve d'EPEL, que l'instal·lador intenta activar amb `epel-release`; quan no es pot instal·lar, la instal·lació continua i ho indica |
+| El servidor MariaDB | Només un controlador: la seva base de dades |
+
+Després, a la carpeta d'instal·lació, amb cada baixada comprovada amb el seu checksum publicat:
+
+* **AnsibleForms** : el bundle de versió `ansibleforms-<version>-linux-<arch>.tar.gz` de la release de GitHub de l'aplicació, l'aplicació compilada per a
+  Node.js. Una versió sense bundle mostra *Instal·lar sense contenidors requereix AnsibleForms 7.3.0 o posterior.*
+* **Node.js** : la versió més nova de la versió major que indica el bundle, de nodejs.org
+* **Python i Ansible** : uv, i després amb ell el Python de les imatges de l'RTE i un entorn virtual amb Ansible i les biblioteques de
+  la imatge completa de l'RTE, i després les seves col·leccions d'Ansible (consulta [Les imatges de l'RTE](../rte/images.html)). Això triga uns minuts
+* **Els fitxers inicials** : els formularis, els playbooks i la configuració de la carpeta `data` del [projecte de docker-compose](https://github.com/ansibleforms/docker),
+  tal com els rep una instal·lació nova de Docker Compose. Un Runner només en conserva la configuració d'Ansible, ssh i git
+
+Per a un controlador, després crea l'esquema `AnsibleForms` a MariaDB, i un usuari de base de dades amb el nom de la instància, amb tots els permisos sobre aquest
+esquema i cap més enlloc, que només pot iniciar sessió des d'aquest servidor.
+
+---
+
+## La carpeta
+
+Tot és a la carpeta d'instal·lació, `/opt/ansibleforms` (o `/opt/ansibleforms-runner` per a un Runner) per defecte:
+
+| Ruta | Què conté |
+|---|---|
+| `releases/<version>/` | Una versió: el bundle, el seu enllaç a Node.js, el seu entorn virtual de Python i les seves col·leccions |
+| `current` | L'enllaç a la versió que s'executa; una actualització el mou, i una marxa enrere també |
+| `runtime/` | Node.js, uv i Python, compartits per les versions |
+| `data/` | El que els contenidors munten com a `/app/dist/persistent`: formularis, playbooks, `config.yaml`, el config seed, certificats i registres |
+| `home/` | El directori personal de l'usuari del sistema: `.ssh` i `.gitconfig`, enllaçats a `data/ssh` i `data/git` |
+| `app.env`, `rte.env` | La configuració i els secrets dels serveis, llegibles només per root i per l'usuari del sistema. El de l'RTE no conté cap configuració de la base de dades |
+| `installer-backups/` | Les còpies de seguretat de la base de dades que fa l'instal·lador, abans d'una actualització o amb `backup` |
+
+Les versions i els entorns d'execució pertanyen a root, així que els serveis no poden canviar el seu propi codi; `data/` i `home/` pertanyen a l'usuari del sistema.
+Els fitxers de la base de dades els guarda MariaDB, fora de la carpeta.
+
+---
+
+## Els serveis
+
+Un controlador executa dos serveis de systemd, un Runner un de sol. Cadascun s'executa amb un usuari del sistema amb el nom de la instància (`ansibleforms` per defecte),
+des de `current/server`, amb el seu fitxer de configuració:
+
+| Servei | Què executa | Configuració |
+|---|---|---|
+| `<name>` | L'aplicació: la interfície web, l'API i el worker. Només un controlador | `app.env` |
+| `<name>-rte` | L'RTE que executa els playbooks | `rte.env` |
+
+L'RTE d'un controlador és `inbound` en un port propi a `127.0.0.1` (`8001`, o el següent lliure, amb
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), executa els playbooks des de les carpetes de l'aplicació (`RTE_FILES=local`),
+i el config seed `data/seed.yaml` el declara com a runner predeterminat.
+
+L'RTE d'un Runner rep el mode, `APP_URL`, `RTE_NAME` i, amb `--join`, el token d'unió, i rep els playbooks amb cada tasca (consulta
+[Modes](../rte/modes.html)). Un d'outbound no rep cap crida de l'aplicació, així que només escolta a `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Un d'inbound serveix HTTPS amb un certificat autosignat propi de la seva adreça a `data/certificates`, que AnsibleForms fixa (pinning).
+Sense token d'unió demana unir-se, i un administrador l'aprova a **Connexions > Runners**.
+
+S'inicien en arrencar i es reinicien després d'una fallada. Gestiona'ls i llegeix-ne els registres amb les eines de systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+L'aplicació pot escoltar en un port per sota de 1024, com ara `443`, sense ser root. L'RTE conserva el dret d'utilitzar `sudo`, que necessiten els playbooks amb
+`become` en aquest servidor, perquè un playbook pugui gestionar el servidor on s'executa l'RTE.
+
+---
+
+## Actualitzar i tornar enrere
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` actualitza una instal·lació nativa com fa amb les altres (consulta [Actualitzar](installer.html#upgrade)), en
+aquest ordre:
+
+1. Posa la versió nova al seu lloc al costat de la que s'executa: el seu bundle, Node.js, Python, Ansible i les col·leccions. Els serveis
+   en execució encara no es toquen
+2. Afegeix els fitxers inicials nous que porta la versió, conservant tots els fitxers que ja existeixen
+3. Fa una còpia de seguretat de la base de dades (un controlador) a `installer-backups/`, amb una còpia d'`app.env` i `rte.env`
+4. Atura els serveis, fa que `current` apunti a la versió nova, i els torna a iniciar
+5. Espera que l'aplicació respongui amb la versió nova (un Runner: que el seu RTE torni a escoltar)
+
+Quan la versió nova no respon, l'instal·lador ofereix tornar enrere: `current` torna a apuntar a la versió anterior, la
+base de dades es restaura a partir de la còpia de seguretat, i els serveis s'inicien. Només es conserven la versió en execució i l'anterior.
+
+Els serveis natius amb l'estructura de l'instal·lador sense cap `installer.json` al costat, per exemple després que s'hagi suprimit, els troben `install`
+i `upgrade`, que ofereixen fer-se'n càrrec (consulta [Una instal·lació existent](installer.html#an-existing-installation)).
+
+---
+
+## Desinstal·lar
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` atura i elimina els serveis. Conserva la carpeta i la base de dades, tret que triïs suprimir
+les dades (o passis `--purge`) i escriguis el nom de la instància per confirmar-ho. Aleshores també elimina la base de dades i el seu usuari (un controlador),
+suprimeix la carpeta i elimina l'usuari del sistema.
+
+Els paquets continuen instal·lats, MariaDB entre ells: altre programari els pot fer servir.
+
+---
+
+## Sense connexió
+
+`--bundle` instal·la a partir d'un bundle de versió que hagis copiat al servidor, en lloc de baixar-lo de GitHub. Agafa el fitxer de la seva
+arquitectura, `ansibleforms-<version>-linux-amd64.tar.gz` o `-arm64`, de les [Releases](https://github.com/ansibleforms/ansibleforms/releases) de l'aplicació:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` fa el mateix amb els fitxers inicials, a partir d'una còpia local del repositori [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python amb els seus paquets i les col·leccions d'Ansible encara es baixen durant la instal·lació.
diff --git a/i18n/ca/_get_started/upgrade-7.md b/i18n/ca/_get_started/upgrade-7.md
new file mode 100644
index 0000000..42cebd7
--- /dev/null
+++ b/i18n/ca/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Actualitzar a la v7
+parent: Actualització
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Actualitzar a la v7
+{: .no_toc }
+
+Què cal canviar mentre encara ets a la 6.5, i què canvia quan passes a la versió 7
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La versió 7 elimina tot el que la 6.x havia declarat obsolet; corregeix-ho primer a la 6.5, on funcionen tant l'antic com el nou, i després actualitza.
+
+---
+
+## Abans d'actualitzar (a la 6.5)
+
+### Els formularis són als seus propis fitxers
+
+Els formularis només són a la carpeta de formularis (`FORMS_FOLDER_PATH`) o en un repositori de formularis; `config.yaml` conserva les categories, els rols i les constants.
+
+- **Un fitxer `forms.yaml`:** canvia-li el nom a `config.yaml`. A la 6.5 la pàgina de configuració té un botó
+  **Convert forms.yaml to config.yaml** per fer-ho.
+- **Una secció `forms:` a la configuració base:** la versió 7 la rebutja. Mou cada formulari al seu propi fitxer, per exemple
+  arrossegant-lo a un fitxer al dissenyador de la 6.5.
+- **Variables d'entorn:**
+
+  | Eliminada | Fes servir en el seu lloc |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` i `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### El camp `table`
+
+La versió 7 rebutja els camps `table`, i les seves propietats (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`) desapareixen amb ells: fes servir un camp `list` amb un `subform`, i converteix el `from` de cada columna en una expressió
+sobre `__parent__` (consulta les [PMF](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Propietats reanomenades
+
+Cada propietat eliminada té un substitut directe:
+
+| Eliminada | Fes servir en el seu lloc |
+|---|---|
+| `disableRelaunch: true` (formulari) | `allowRelaunch: false` |
+| `noOutput: true` (camp) | `output: false` |
+| `enableLogin` (opció de rol) | `allowLogin` |
+
+### Fonts de dades i esquemes de dades
+
+S'han eliminat les importacions de fonts de dades i les seves pàgines d'administració, així com la
+col·lecció de Galaxy d'AnsibleForms, els mòduls de la qual només servien per a això.
+
+- Les importacions programades s'aturen i les taules de fonts de dades s'eliminen: anota primer el que necessitis.
+- Els esquemes de dades que omplia una importació són bases de dades pròpies i es conserven. Un formulari que
+  les consulta mitjançant una credencial continua funcionant.
+- Per mantenir aquestes dades actualitzades, executa la importació com un playbook propi, per exemple des d'una
+  programació.
+
+### API v1
+
+`/api/v1/*` s'ha eliminat; fes servir `/api/v2/*` (documentació interactiva a `/api/v2/docs`). Les crides
+que solen fer servir els scripts són:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+La v2 respon amb codis d'estat HTTP (`400`, `403`, `404`, `422`) i un cos JSON simple, no amb l'embolcall
+`{ status, message, data }` de la v1.
+
+**Les crides de retorn d'inici de sessió únic també.** Un URL de redirecció amb `/api/v1/` ja no respon: l'inici de sessió torna a
+la pàgina d'inici de sessió sense iniciar-la. Canvia-ho a `/api/v2/` en dos llocs, al proveïdor d'SSO d'
+AnsibleForms i al proveïdor d'identitat (els URI de redirecció del registre d'aplicació d'Entra ID, els URI de redirecció vàlids del
+client OIDC):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback`, o `/api/v2/auth/entraid/callback` des de la 7.3.0
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Què canvia a la 7
+
+La versió 7 canvia com s'executen els playbooks i fa més estrictes diversos valors predeterminats. Comprova cadascun dels punts següents quan passis de la 6.5.
+
+### Els playbooks s'executen en un RTE
+
+La versió 7 ja no executa `ansible-playbook` al contenidor d'AnsibleForms. Els playbooks s'executen en un entorn d'execució (RTE),
+un contenidor propi, i la imatge de l'aplicació ja no conté ni ansible ni python. Inicia un RTE al costat de l'aplicació, a partir de la
+imatge `ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Des de la 7.3.0 l'aplicació truca a l'RTE i hi manté un WebSocket obert (consulta
+[Modes](rte/modes.html)): l'RTE no rep cap configuració de la base de dades ni `ENCRYPTION_SECRET`. La seva configuració:
+
+| Paràmetre | Valor |
+|---|---|
+| `AF_ROLE` | `rte`. Les imatges de l'RTE ja el defineixen. |
+| `RTE_MODE` | `inbound`: l'aplicació truca a l'RTE. Un Runner en una altra xarxa fa servir `outbound` (consulta [Modes](rte/modes.html)). |
+| `RTE_TOKEN` | Un token d'almenys 16 caràcters. L'aplicació s'hi autentica al socket de l'RTE, i l'RTE es nega a iniciar-se sense. |
+| `RTE_FILES` | `local` quan l'RTE munta la mateixa carpeta persistent que l'aplicació, com quan és al seu costat. |
+
+Després mou els muntatges d'ansible del contenidor de l'aplicació a l'RTE:
+
+- `ansible.cfg` a `/etc/ansible/ansible.cfg`, els teus rols a `/etc/ansible/roles` i les teves col·leccions a
+  `/etc/ansible/collections`.
+- Munta també a l'RTE la mateixa carpeta persistent que a l'aplicació, perquè hi trobi els playbooks i els repositoris.
+
+Després declara l'RTE com a runner, al [config seed](seed/) com fa el projecte de Docker Compose, o a **Connexions → Runners**:
+una credencial d'RTE amb l'adreça de l'RTE (per exemple `http://rte:8000`) i el mateix token, i un runner de tipus RTE, en mode inbound,
+que l'anomeni:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+El seed llegeix `RTE_TOKEN` de l'entorn de l'aplicació. Consulta [Runners](runners.html) i [Entorns d'execució](rte/).
+
+{: .warning }
+> **El mateix contracte per a l'aplicació i l'RTE** L'aplicació resol les credencials d'una tasca i les lliura a l'RTE segellades per a
+> aquell RTE (contracte d'RTE 2, nou a la 7.0.0). Un RTE d'un altre contracte rebutja les tasques de l'aplicació: executa la imatge de l'RTE de la mateixa
+> versió que l'aplicació, i actualitza-les totes dues alhora. Les versions 7 posteriors continuen funcionant amb un RTE 7 més antic mentre el contracte
+> sigui el mateix (consulta [Escalat](../rte/images.html#build-your-own-rte)).
+
+
+### Què conté la imatge de l'RTE
+
+L'RTE es presenta en tres capes, cadascuna construïda sobre l'anterior. Tria la que s'adapti als teus playbooks:
+
+| Imatge | Contingut |
+|---|---|
+| `ansibleforms-rte-full` | La predeterminada. Ansible 14 amb ansible-core 2.21, i les col·leccions i les biblioteques de python que tenia la imatge de la 6.5. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core i unes quantes biblioteques habituals, sense col·leccions. Afegeix-hi les teves en una imatge construïda a sobre. |
+| `ansibleforms-rte-base` | Només el servidor, sense python ni ansible, per construir un RTE amb les teves pròpies versions. |
+
+Passar de la 6.5 (ansible 12 amb ansible-core 2.19) també canvia això per als teus playbooks:
+
+- **ansible-core 2.21:** llegeix les [guies de migració](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  de la 2.20 i la 2.21.
+- **Python 3.14:** les capes de l'RTE s'executen amb python 3.14.
+- **Ja no hi ha `boto`:** l'antiga biblioteca `boto` 2 ha desaparegut. La col·lecció `amazon.aws` fa servir `boto3`, que s'inclou.
+
+Dues variables d'entorn ara pertanyen a l'RTE i l'aplicació ja no les llegeix, així que defineix-les al contenidor de l'RTE:
+
+| Variable | Canvi |
+|---|---|
+| `ANSIBLE_PATH` | La carpeta de playbooks, a l'RTE. |
+| `PROCESS_MAX_BUFFER` | Ara 50 MB per defecte. Si se supera, la sortida de la tasca ja no es desa (la tasca ho indica), però el playbook continua en lloc d'aturar-se. |
+
+
+### Els contenidors s'executen amb l'uid 1000
+
+Les imatges de l'aplicació i de l'RTE s'executen amb l'usuari `node` (uid 1000) en lloc de root, i el seu directori personal és `/home/node`:
+
+- **Dona els volums a l'uid 1000, una sola vegada.** Per als volums persistent i ssh, executa
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v`; per a una carpeta de l'amfitrió, `sudo chown -R 1000:1000 <folder>`.
+  A Kubernetes, defineix `fsGroup: 1000`.
+- **Munta la carpeta ssh a `/home/node/.ssh`**, no a `/root/.ssh`. Si havies definit
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) com a `/root`, treu-lo o defineix-lo com a `/home/node`.
+- **La teva pròpia imatge d'RTE** construïda sobre una capa de l'RTE canvia a `USER root` per a les seves instal·lacions i torna a `USER node` al final.
+
+
+### La validació del llançament està activada
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) ara és `enforce` per defecte (6.5: `off`). Cada
+llançament, des del navegador o des de `POST /api/v2/job`, es comprova amb les regles del formulari, i la tasca executa les extravars i les
+credencials que el servidor construeix a partir dels valors comprovats.
+
+- **Qui crida l'API REST ha d'enviar `rawFormData`**, els valors en brut dels camps tal com els envia el navegador. Un llançament amb només
+  `extravars` es rebutja, perquè els seus valors no es poden comprovar.
+- **Per veure primer què es rebutjaria**, defineix `LAUNCH_VALIDATION=log` i llegeix els avisos al registre. `off` restableix el
+  comportament de la 6.5.
+
+Consulta [Validació del llançament](launch-validation/) per als detalls.
+
+
+### Els playbooks ja no veuen la configuració de l'aplicació
+
+Un playbook ja no hereta les variables d'entorn que llegeix el mateix AnsibleForms: `ENCRYPTION_SECRET`, els paràmetres `DB_*`,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, els paràmetres `VAULT_*`, totes les altres variables documentades i totes les variables `MYSQL_*`.
+La resta de l'entorn de l'RTE, com ara `PATH`, els proxies, els paràmetres `ANSIBLE_*` i les credencials del núvol, es passa com abans.
+
+Un playbook que en llegia alguna amb `lookup('env', ...)` ha d'obtenir el valor d'una altra manera: passa'l com a extravar o com a
+credencial, o defineix-lo a l'RTE amb un altre nom.
+
+### Només el rol admin gestiona els runners i els administradors
+
+Un usuari amb accés a la configuració ja no té el control total sobre qui és administrador i on van les credencials:
+
+- **Runners:** només el rol admin afegeix, canvia o suprimeix un runner, perquè un runner rep les credencials de les tasques
+  que executa. Els usuaris amb accés a la configuració encara poden veure i provar els runners.
+- **Comptes i grups d'administrador:** només el rol admin concedeix permisos d'administrador. Sense aquest rol, un usuari no pot posar un compte en un grup que
+  anomena el rol admin, ni canviar, restablir o suprimir un compte d'administrador o un grup d'aquest tipus.
+- **Rols:** un dissenyador sense el rol admin no pot canviar els rols. Es rebutja un desament o una restauració amb rols diferents.
+
+Dona el rol admin a qui gestioni els runners, els administradors i els rols.
+
+### Cal canviar la contrasenya predeterminada
+
+Un usuari que inicia sessió amb la contrasenya predeterminada pública `AnsibleForms!123` l'ha de canviar primer. Fins aleshores, qualsevol altra crida a l'API
+respon `403` amb el codi `password_change_required`, i el navegador mostra la pàgina de canvi de contrasenya.
+
+Inicia sessió una vegada i tria una contrasenya nova, o defineix [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) abans del
+primer inici. Els scripts que inicien sessió amb la contrasenya predeterminada n'han de fer servir una altra.
+
+### Els tokens s'acaben en tancar la sessió i en canviar la contrasenya
+
+Ara un tancament de sessió acaba els tokens d'aquella sessió, i un canvi de contrasenya acaba totes les sessions d'aquell usuari, així que torna a iniciar sessió després de
+canviar una contrasenya.
+
+Un token d'API demanat amb `?expiryDays=` dura com a màxim [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) dies
+(90 per defecte). Els scripts que fan servir tokens d'API de llarga durada n'han de demanar un de nou abans que caduqui.
+
+### Entra ID necessita el teu tenant
+
+L'inici de sessió amb Entra ID (Azure AD) ara fa servir OpenID Connect només contra el teu propi tenant, i un usuari d'un altre tenant no pot iniciar
+sessió. Es rebutja un proveïdor sense id de tenant, o amb `common`, `organizations` o `consumers`.
+
+- **Defineix l'id del tenant** al proveïdor d'SSO: el Directory (tenant) ID, un GUID, o el domini del tenant.
+- **Concedeix els permisos de Graph:** l'inici de sessió demana `openid profile email User.Read GroupMember.Read.All`. Dona al registre
+  d'aplicació els permisos delegats de Microsoft Graph `User.Read` i `GroupMember.Read.All`, amb el consentiment de l'administrador.
+- **Als rols, millor els id de grup:** anomena un grup com a `azuread/<object id>` (`entraid/<object id>` des de la 7.3.0) en lloc de fer-ho pel seu nom visible.
+
+Consulta [Entra ID](authentication/entra-id.html) per a la configuració.
+
+### Les contrasenyes tenen una longitud mínima
+
+Una contrasenya local definida a través de l'aplicació necessita com a mínim
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) caràcters (8 per defecte), i no pot ser el nom d'usuari ni la
+contrasenya predeterminada. `PASSWORD_MIN_LENGTH=0` desactiva la comprovació de longitud. Les contrasenyes existents continuen funcionant.
+
+### Executa els contenidors amb una política de reinici
+
+Ara una excepció no capturada acaba el procés, registrada amb el nivell `crit`, en lloc de deixar-lo en marxa en un estat desconegut. Executa
+els contenidors amb una política de reinici, com ara `--restart unless-stopped` amb Docker (el projecte de docker-compose la defineix).
+Kubernetes reinicia els pods tot sol.
+
+### Connexions d'AWX i l'enllaç d'inici
+
+Dues coses més desapareixen a la 7, sense que calgui fer res a la 6.5:
+
+- **Connexions d'AWX i AAP:** la taula `awx`, `/api/v2/awx` i la pàgina A.A.P. han desaparegut. L'actualització mou cada connexió d'AWX o
+  d'AAP a **Connexions → Runners**, com a runner de tipus `awx`, i els formularis amb `awx:` continuen funcionant.
+- **`NAV_HOME_LABEL` i `NAV_HOME_ICON`:** ja no es llegeixen. El primer enllaç de la capçalera sempre és Formularis.
+
+### Obsolet a la 7, eliminat a la 8
+
+Això encara funciona a la 7, però cada element registra un avís quan es fa servir. Passa al substitut abans de la versió 8:
+
+| Obsolet | Fes servir en el seu lloc |
+|---|---|
+| Variables d'entorn `VAULT_*` | Un magatzem de secrets anomenat `vault` (**Connexions → Magatzems de secrets**). El primer inici de la 7 importa les variables una vegada com aquest magatzem, i després les ignora. |
+| Variables d'entorn `LOG_SYSLOG_*` | Un servidor syslog (**Connexions → Syslog**). Quan `LOG_SYSLOG_HOST` està definit, el primer inici de la 7 les importa una vegada com el servidor `syslog`, que rep el registre del servidor com abans, i després les ignora. Per enviar-hi també les entrades d'auditoria, configura'l perquè rebi tots dos. |
+| `vault_path` en una credencial (API, config seed) | `secret_store` i `secret_ref`. Consulta [Magatzems de secrets](secret-stores/). |
+| El rol `public` a `config.yaml` | El rol `default`. El fitxer es reanomena quan es carrega la configuració; reanomena a mà una plantilla ytt. `public` als `roles:` d'un formulari continua coincidint. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` en un formulari o un pas | `approval`. `hasApproval` no té cap efecte. |
+| `awx: <name>` en un formulari | `runner: <name>`. Una connexió d'AWX és un runner de tipus `awx`. |
+| `type: multistep` en un formulari, amb els seus `steps` | `type: workflow`, amb nodes que anomenen un `runner`. Consulta [Formularis de workflow](forms/workflow.html). |
+| La secció `awx:` del config seed | Elements de `runners:` amb `type: awx` |
+| `LOCK_PATH` | Res: ja no es llegeix, el bloqueig del dissenyador es guarda a la base de dades. |
+| Un RTE en mode database, des de la 7.3.0: `RTE_MODE=database` o sense `RTE_MODE`, amb els `DB_*` i l'`ENCRYPTION_SECRET` de la base de dades a l'RTE | `RTE_MODE=outbound` o `RTE_MODE=inbound`, sense `DB_*`. L'RTE s'uneix una vegada amb un token d'unió (`RTE_JOIN_TOKEN`), o el seu runner es posa en aquest mode a **Connexions → Runners** o al config seed (`rte_mode`). Consulta [Modes](rte/modes.html). |
+| `RTE_REGISTER`, des de la 7.3.0 (només mode database) | Un token d'unió (`RTE_JOIN_TOKEN`): l'RTE s'afegeix ell mateix com a runner que s'autentica amb una credencial d'RTE. |
+| Una credencial `api` o `userpass` en un runner del config seed, des de la 7.3.0 | Una credencial del tipus del runner (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` o `jenkins`), amb el seu servidor a `url`. |
+| Un runner del config seed amb el seu propi `token`, o `username` i `password`, des de la 7.3.0 | Una credencial del tipus del runner a la secció `credentials`, amb el seu servidor a `url`, que el runner anomena amb `credential:`. Mentrestant, el seed en crea una amb el nom del runner. |
+
+`ENABLE_SSO` i `SSO_AUTO_LOGIN` ja no es llegeixen des de la 7.3.0. El primer inici de la 7.3 els trasllada una vegada: `ENABLE_SSO=0` desactiva
+tots els proveïdors d'SSO, i `SSO_AUTO_LOGIN=1` marca **Salta la pàgina d'inici de sessió** a l'únic proveïdor activat. Després s'ignoren: cada inici
+registra un avís mentre estan definits, i cada proveïdor té **Activat** i **Salta la pàgina d'inici de sessió** a **Accés → SSO**.
+
+---
+
+## Etiquetes d'imatge
+
+`latest` passa a la 7 amb la 7.0.0. Per quedar-te a la 6, fes servir l'etiqueta `6` (o `6.5`) en lloc de `latest`.
+Totes les etiquetes es llisten a [Etiquetes d'imatge](installation/#image-tags).
+
+---
+
+## Tornar enrere
+
+Fes una còpia de seguretat abans d'actualitzar (**Configuració → Còpies de seguretat**). La 6.5 funciona amb una base de dades actualitzada a la 7, però només
+la còpia de seguretat restaura les definicions de fonts de dades eliminades.
diff --git a/i18n/ca/_get_started/upgrading/docker-compose.md b/i18n/ca/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..10ed64f
--- /dev/null
+++ b/i18n/ca/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Actualització
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Actualitza una instal·lació feta amb el projecte de docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+El projecte de docker-compose executa tres contenidors: MySQL (`mysqldb`), AnsibleForms (`app`) i l'RTE que executa els
+playbooks (`rte`). AnsibleForms i l'RTE fan servir l'etiqueta d'imatge `7`, que sempre apunta a la versió 7.x més nova. Una
+actualització torna a baixar les imatges i torna a crear els contenidors amb una imatge que ha canviat. Tot el que ha de persistir es desa
+a la carpeta `data` i es conserva.
+
+---
+
+## Abans d'actualitzar
+
+Prepara l'actualització de manera que puguis tornar enrere si alguna cosa va malament:
+
+* **Fes una còpia de seguretat** a **Configuració → Còpies de seguretat**. La versió nova actualitza l'esquema de la base de dades en el primer inici.
+* **Llegeix el [registre de canvis](../changelog)** de les versions entre la teva i la nova.
+* **Passes a una versió major nova?** Segueix primer [Actualitzar a la v7](../upgrade-7.html).
+* **Véns de la 6.5?** El projecte 6.x, a la seva branca `v6`, no té contenidor `rte`. Actualitza la teva còpia del projecte a
+  la seva branca `main`, conservant la configuració del teu `.env` i la teva carpeta `data`, perquè `docker-compose.yml` tingui el servei
+  `rte`. Aquest fitxer compose defineix `CONFIG_SEED_PATH`, i una carpeta `data` de la 6.x no té `seed.yaml`: copia `data/seed.yaml` del
+  repositori, i afegeix `RTE_TOKEN` (com a mínim 16 caràcters) al teu `.env`, tal com el té el `.env` del repositori. Sense això l'aplicació
+  es nega a iniciar-se. Les imatges de la 7 s'executen amb l'uid 1000 en lloc de root: dona una vegada la carpeta `data` a aquest usuari, deixant els fitxers de MySQL
+  a MySQL, amb `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  La carpeta `data/ssh` ara es munta a `/home/node/.ssh` en lloc de `/root/.ssh`.
+* **Véns de la 7.2?** Actualitza `docker-compose.yml` i `data/seed.yaml` alhora: consulta primer [De la 7.2 a la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 a la 7.3
+
+Fins a la 7.2.0 el servei `rte` rebia la configuració de la base de dades i el seu runner, declarat a `data/seed.yaml`, s'executava en mode database,
+obsolet a la 7.3.0 i eliminat a la 8.0.0. Des de la 7.3.0 l'aplicació truca a l'RTE a `http://rte:8000` i hi manté un WebSocket obert
+(`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)), i l'RTE no té cap configuració de la base de dades. Agafa tots dos fitxers de la branca
+`main` del repositori, conservant el teu `.env`:
+
+| Fitxer | Què canvia |
+|---|---|
+| `docker-compose.yml` | El servei `rte` ja no llegeix `.env`: rep `RTE_MODE=inbound`, `RTE_TOKEN` i `RTE_FILES=local`, i cap `DB_*` |
+| `data/seed.yaml` | Una credencial d'RTE `rte`, amb `url: http://rte:8000` i `password: ${RTE_TOKEN}`, i el runner `rte` amb `rte_mode: inbound` i `credential: rte` |
+
+Canvia'ls tots dos. Amb només el fitxer compose nou, el seed manté el runner `rte` en mode database: l'aplicació crida l'RTE com si fos un de la 7.2,
+cosa que el nou RTE no respon, i no s'executa cap playbook. Un seed que hagis canviat tu mateix necessita la mateixa credencial i el mateix `rte_mode`.
+
+Un runner que ha creat el seed continua gestionat, de només lectura a **Connexions → Runners**, fins i tot després de treure `CONFIG_SEED_PATH`: només un
+seed que s'aplica allibera un runner que ja no declara. Així que conserva el seed i defineix-hi `rte_mode`, en lloc de treure
+`CONFIG_SEED_PATH` per canviar el runner a mà.
+
+L'[instal·lador](../installation/installer.html#upgrade) ho fa tot sol: la seva actualització substitueix `docker-compose.yml`, i `data/seed.yaml`
+quan és un dels que venien amb el repositori, sense canvis. Un que s'hagi canviat a mà es conserva, i el nou es desa al costat.
+
+---
+
+## 1. Baixa les imatges noves
+
+Baixa les imatges més noves de les etiquetes de `docker-compose.yml`:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Torna a crear els contenidors
+
+Torna a iniciar el projecte; es tornen a crear els contenidors amb una imatge que ha canviat:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Comprova l'actualització
+
+Segueix el registre d'AnsibleForms mentre s'inicia. El primer inici d'una versió nova actualitza l'esquema de la base de dades, i l'RTE
+s'inicia quan AnsibleForms està en bon estat:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+A AnsibleForms, **Ajuda → Quant a** mostra la versió que s'està executant, i **Configuració → Estat** mostra la salut de la
+base de dades, de l'esquema i dels altres sistemes dels quals depèn AnsibleForms.
+
+---
+
+## Tornar enrere
+
+Per tornar a la versió que executaves abans, la que mostrava **Ajuda → Quant a** abans de l'actualització, fixa la seva etiqueta exacta a
+`docker-compose.yml` tant a la imatge d'AnsibleForms com a la de l'RTE, en lloc de `7`, i torna a executar el pas 2. Si aquella versió
+no s'inicia amb la base de dades actualitzada, restaura la còpia de seguretat que vas fer a **Configuració → Còpies de seguretat**. Torna a posar les etiquetes a
+`7` per tornar a rebre actualitzacions.
+
+**VÍDEO**: [Com actualitzar AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/ca/_get_started/upgrading/docker.md b/i18n/ca/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..baeb803
--- /dev/null
+++ b/i18n/ca/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Actualització
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Actualitza un contenidor independent, sense docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Una instal·lació independent s'actualitza substituint-ne els contenidors: baixa les imatges noves, suprimeix els contenidors antics i
+inicia'n de nous amb les mateixes ordres `run`. Des de la versió 7 n'hi ha dos: AnsibleForms i l'RTE que executa els
+playbooks, sempre en la mateixa versió. Els teus fitxers es desen a la carpeta muntada `/app/dist/persistent` i les teves dades a
+MySQL, així que tots dos es conserven.
+
+---
+
+## Abans d'actualitzar
+
+Prepara l'actualització de manera que puguis tornar enrere si alguna cosa va malament:
+
+* **Fes una còpia de seguretat** a **Configuració → Còpies de seguretat**. La versió nova actualitza l'esquema de la base de dades en el primer inici.
+* **Llegeix el [registre de canvis](../changelog)** de les versions entre la teva i la nova.
+* **Passes a una versió major nova?** Segueix primer [Actualitzar a la v7](../upgrade-7.html).
+* **Véns de la 6.5?** Les imatges de la 7 s'executen amb l'uid 1000 en lloc de root: dona una vegada a aquest usuari les carpetes que muntes, per
+  exemple `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Véns de la 7.2?** L'RTE rep un fitxer propi i l'aplicació el truca: consulta primer [De la 7.2 a la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 a la 7.3
+
+Fins a la 7.2.0 l'RTE llegia el fitxer d'entorn de l'aplicació, amb la configuració de la base de dades, i s'afegia ell mateix com a runner a partir de `RTE_URL`. Això
+és el mode database, obsolet a la 7.3.0 i eliminat a la 8.0.0. Des de la 7.3.0 l'aplicació truca a l'RTE i hi manté un WebSocket obert
+(`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)), i l'RTE no té cap configuració de la base de dades. Una sola vegada, abans del pas 2:
+
+1. Crea `/srv/apps/ansibleforms/rte.env` com ho fa la [instal·lació](../installation/docker.html#prepare-the-folders), amb
+   `RTE_MODE=inbound`, el mateix `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` i `HTTPS=0`. Cap `DB_*`, cap `ENCRYPTION_SECRET`, cap `RTE_URL`
+2. Declara el runner en aquest mode. O bé afegeix el [config seed](../seed/) de la instal·lació, `persistent/seed.yaml` amb la credencial d'RTE
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) i el runner `rte` (`rte_mode: inbound`), i afegeix
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` al fitxer d'entorn de l'aplicació. O bé, sense seed, obre el runner a
+   **Connexions → Runners**, posa el seu **Mode** a **Entrant**, i tria una credencial d'RTE que contingui `http://rte:8000` i el token
+
+Amb el seed, el fitxer d'entorn de l'aplicació també conté `RTE_TOKEN`, el mateix token, ja que el seed el llegeix d'allà.
+
+---
+
+## 1. Baixa les imatges noves
+
+Baixa les imatges més noves d'AnsibleForms i de l'RTE de l'etiqueta que executes:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Substitueix els contenidors
+
+Suprimeix els contenidors antics i inicia'n de nous amb les ordres `run` de la [instal·lació](../installation/docker.html). L'aplicació
+llegeix la connexió a la base de dades del seu fitxer d'entorn, amb l'usuari de base de dades d'AnsibleForms (no root). L'RTE llegeix el seu propi
+`rte.env`, sense la configuració de la base de dades, i l'aplicació el truca a través d'una xarxa que comparteixen tots dos contenidors:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Si véns de la 6.5, encara no hi ha cap contenidor d'RTE: les ordres `stop` i `rm` només troben l'aplicació. Crea la xarxa compartida
+una vegada amb `docker network create ansibleforms` (o `podman network create ansibleforms`). Com fa la
+[instal·lació](../installation/docker.html#prepare-the-folders), posa la connexió a la base de dades, `ENCRYPTION_SECRET`, un `RTE_TOKEN`
+d'almenys 16 caràcters i `CONFIG_SEED_PATH` al fitxer d'entorn de l'aplicació, i crea `rte.env` i el config seed. Fes servir les teves pròpies
+carpetes on la teva instal·lació 6.5 en muntava d'altres. El seed afegeix l'RTE a **Connexions → Runners** com a runner predeterminat `rte`;
+consulta [Actualitzar a la v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Comprova l'actualització
+
+Segueix el registre d'AnsibleForms mentre s'inicia. El primer inici d'una versió nova actualitza l'esquema de la base de dades:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+L'RTE escriu el seu propi registre, que mostra `docker logs rte`. A AnsibleForms, **Ajuda → Quant a** mostra la versió que s'està executant, i **Configuració → Estat** mostra la salut de la
+base de dades, de l'esquema i dels altres sistemes dels quals depèn AnsibleForms.
+
+---
+
+## Tornar enrere
+
+Per tornar a la versió que executaves abans, la que mostrava **Ajuda → Quant a** abans de l'actualització, torna a executar el pas 2 amb
+la seva etiqueta exacta en lloc de `7`, tant a la imatge d'AnsibleForms com a la de l'RTE. Si aquella versió no s'inicia amb la base de dades
+actualitzada, restaura la còpia de seguretat que vas fer a **Configuració → Còpies de seguretat**.
diff --git a/i18n/ca/_get_started/upgrading/from-source.md b/i18n/ca/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..7d00484
--- /dev/null
+++ b/i18n/ca/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Des del codi font
+parent: Actualització
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Des del codi font
+{: .no_toc }
+
+Actualitza una instal·lació compilada des del codi font
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Una instal·lació compilada des del codi font s'actualitza obtenint la versió nova, tornant-la a compilar i reiniciant
+l'aplicació. La teva configuració, els formularis, els playbooks, els certificats i els registres es desen a `server/persistent`, que ni Git ni la
+compilació modifiquen.
+
+---
+
+## Abans d'actualitzar
+
+Prepara l'actualització de manera que puguis tornar enrere si alguna cosa va malament:
+
+* **Fes una còpia de seguretat** a **Configuració → Còpies de seguretat**. La versió nova actualitza l'esquema de la base de dades en el primer inici.
+* **Llegeix el [registre de canvis](../changelog)** de les versions entre la teva i la nova.
+* **Passes a una versió major nova?** Segueix primer [Actualitzar a la v7](../upgrade-7.html).
+* **Comprova la versió de Node.js** que necessita la versió nova, al registre de canvis.
+
+---
+
+## 1. Obtén la versió nova
+
+Obtén les etiquetes de les versions i fes checkout de la versió que vulguis. Les etiquetes de versió porten el número de versió, i `git tag` les
+llista; la branca `main` pot contenir canvis que encara no s'han publicat:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Torna a compilar
+
+Torna a compilar amb els mateixos tres passos que en la instal·lació. Primer torna a compilar el client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Després actualitza les dependències del servidor:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Finalment torna a copiar el client compilat a la carpeta `views` del servidor:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Compara `.env.example`, a l'arrel del repositori, amb el teu `persistent/.env` per incorporar qualsevol paràmetre que afegeixi la versió.
+
+---
+
+## 3. Reinicia
+
+Reinicia l'aplicació i el seu RTE per carregar el codi nou. L'esquema de la base de dades s'actualitza en el primer inici:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Si véns de la 7.2, l'RTE s'executava en mode database, amb la configuració de la base de dades i `RTE_URL`, obsolet a la 7.3.0 i eliminat a la 8.0.0.
+Torna'l a iniciar en mode inbound, i declara'n el runner amb una credencial d'RTE al seed o a **Connexions → Runners**, com mostra la
+[instal·lació](../installation/from-source.html#run): `pm2 delete ansibleforms-rte`, i després la seva ordre `pm2 start`.
+
+Si executes l'aplicació sense PM2, atura `npm run start` i torna'l a iniciar.
+
+---
+
+## 4. Comprova l'actualització
+
+Segueix el registre de l'aplicació mentre s'inicia:
+
+```bash
+pm2 logs ansibleforms
+```
+
+A AnsibleForms, **Ajuda → Quant a** mostra la versió que s'està executant, i **Configuració → Estat** mostra la salut de la
+base de dades, de l'esquema i dels altres sistemes dels quals depèn AnsibleForms.
+
+---
+
+## Tornar enrere
+
+Per tornar a la versió que executaves abans, la que mostrava **Ajuda → Quant a** abans de l'actualització, fes checkout de la seva etiqueta amb
+`git checkout <version>`, i després torna a compilar i reinicia com als passos 2 i 3. Si aquella versió no s'inicia amb la base de dades actualitzada, restaura la còpia de seguretat que vas fer a
+**Configuració → Còpies de seguretat**.
diff --git a/i18n/ca/_get_started/upgrading/index.md b/i18n/ca/_get_started/upgrading/index.md
new file mode 100644
index 0000000..643c8ca
--- /dev/null
+++ b/i18n/ca/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Actualització
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Actualització
+{: .no_toc }
+
+Porta AnsibleForms a una versió més nova
+{: .fs-6 .fw-300 }
+
+---
+
+Per als administradors d'una instància en marxa: passa a una versió més nova, amb el mateix mètode amb què la vas instal·lar.
+
+---
+
+## En aquesta secció
+
+El procediment d'actualització depèn de com vas instal·lar AnsibleForms. Cada mètode es descriu a la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Actualitzar a la v7](../upgrade-7.html) | Què cal canviar mentre encara ets a la 6.5, abans de passar a la 7 |
+| [Amb l'instal·lador](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, per a una instal·lació feta amb l'instal·lador: còpia de seguretat, notes de la versió i marxa enrere |
+| [Docker](docker.html) | Baixa la imatge nova i torna a crear el contenidor amb la mateixa configuració |
+| [Docker Compose](docker-compose.html) | Baixa la imatge nova i reinicia el projecte de docker-compose |
+| [Des del codi font](from-source.html) | Baixa el codi nou, torna'l a compilar i reinicia l'aplicació |
+| [Kubernetes](kubernetes.html) | Actualitza el repositori del chart i executa `helm upgrade` amb els teus valors |
+
+{: .note }
+> **Primer, una còpia de seguretat** Fes una còpia de seguretat abans d'actualitzar (**Configuració → Còpies de seguretat**). L'esquema de la base de dades s'actualitza en el primer
+> inici de la versió nova, així que la còpia de seguretat és el teu punt de retorn si alguna cosa va malament. Des de la 7.3.0 el worker també en fa
+> una ell mateix abans d'actualitzar des d'una versió anterior, amb el nom de la versió, tret que
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) sigui `0`.
+
+La versió que reps depèn de l'etiqueta d'imatge que executes: `latest` segueix la versió major més nova, mentre que una etiqueta com ara `7`
+es queda en aquella versió major. Totes les etiquetes es llisten a [Etiquetes d'imatge](../installation/#image-tags).
diff --git a/i18n/ca/_get_started/upgrading/kubernetes.md b/i18n/ca/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..bb9be4d
--- /dev/null
+++ b/i18n/ca/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Actualització
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Actualitza una instal·lació feta amb el chart de Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Cada versió del chart desplega una versió d'AnsibleForms. Una actualització instal·la una versió més nova del chart amb els teus valors existents;
+les dades dels volums persistents es conserven. Una actualització que no canvia res deixa els pods intactes.
+
+---
+
+## Abans d'actualitzar
+
+Prepara l'actualització de manera que puguis tornar enrere si alguna cosa va malament:
+
+* **Fes una còpia de seguretat** a **Configuració → Còpies de seguretat**. La versió nova actualitza l'esquema de la base de dades en el primer inici.
+* **Llegeix el [registre de canvis](../changelog)** de les versions entre la teva i la nova.
+* **Passes a una versió major nova?** Segueix primer [Actualitzar a la v7](../upgrade-7.html).
+* **Llegeix el [registre de canvis](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) del chart** per veure els canvis en els valors.
+* **Amb credencials generades** (`secrets.generate`), fes una còpia de seguretat del Secret `<release>-secrets`: `ENCRYPTION_SECRET` no es pot recuperar.
+* **Véns de la 7.2?** L'RTE del pod del servidor canvia de mode: consulta [De la 7.2 a la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 a la 7.3
+
+El chart 7.3.0 treu l'RTE que hi ha al costat de l'aplicació del mode database, obsolet a la 7.3.0 i eliminat a la 8.0.0. L'aplicació el truca a
+`127.0.0.1` i hi manté un WebSocket obert (`RTE_MODE=inbound`, consulta [Modes](../rte/modes.html)):
+
+* El contenidor de l'RTE ja no rep `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` ni `RTE_URL`, i agafa els fitxers de la tasca del
+  volum compartit (`RTE_FILES=local`)
+* El config seed del chart declara una credencial d'RTE amb el token i l'adreça, i el runner, `rte_mode: inbound`, que s'hi
+  autentica. Amb el seed del chart, no cal fer res
+* Amb `containers.rte.seedRunner: false`, o un config seed propi (`CONFIG_SEED_PATH`), l'RTE ja no s'afegeix ell mateix com a runner.
+  Declara'l tu mateix, al teu seed o a **Connexions → Runners**: una credencial d'RTE amb `http://127.0.0.1:<port>` i el token,
+  i un runner de tipus RTE amb `rte_mode: inbound` que l'anomeni. Les notes que mostra Helm després de l'actualització expliquen com fer-ho
+
+Des de la 7.3.0 el chart també instal·la un Runner independent, amb `runner.enabled` (consulta
+[Un Runner a Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Troba la versió nova del chart
+
+Actualitza el repositori del chart i llista les versions disponibles del chart:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Actualitza la release
+
+Executa la mateixa ordre `helm upgrade` que en la instal·lació, amb el teu fitxer de valors i la versió nova del chart:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Amb el registre OCI, fes servir `oci://ghcr.io/ansibleforms/charts/ansibleforms` com a chart.
+
+---
+
+## 3. Comprova l'actualització
+
+Espera els pods nous i després executa la prova del chart, que comprova tant el servidor web com la connexió a la base de dades:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+A AnsibleForms, **Ajuda → Quant a** mostra la versió que s'està executant, i **Configuració → Estat** mostra la salut de la
+base de dades, de l'esquema i dels altres sistemes dels quals depèn AnsibleForms.
+
+---
+
+## Tornar enrere
+
+Helm conserva l'historial de la release. Per tornar a la revisió anterior:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Si no s'inicia amb la base de dades actualitzada, restaura la teva còpia de seguretat (consulta el [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart).
diff --git a/i18n/ca/_integrate/api/authentication.md b/i18n/ca/_integrate/api/authentication.md
new file mode 100644
index 0000000..7596cac
--- /dev/null
+++ b/i18n/ca/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Autenticació
+parent: API REST
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Autenticació
+{: .no_toc }
+
+Iniciar sessió, renovar el token o fer servir un token de llarga durada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Cada crida necessita un token d'accés a la capçalera `Authorization`. Un token s'obté iniciant sessió, i es manté vigent amb
+el token de renovació.
+
+---
+
+## Iniciar sessió
+
+Inicia sessió amb autenticació bàsica, amb el nom i la contrasenya de l'usuari:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+La resposta conté dos tokens, el token d'accés i el token de renovació:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Cridar l'API
+
+Envia el token d'accés com a token bearer amb cada crida:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Renovar el token
+
+El token d'accés caduca (`ACCESS_TOKEN_EXPIRATION`, 30 minuts per defecte). Obtén-ne un de nou amb el token de renovació,
+sense la contrasenya:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+La resposta conté un parell nou, amb la mateixa forma que l'inici de sessió. Un token de renovació funciona una sola vegada: guarda el nou per a la renovació següent.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Tokens de llarga durada
+
+Un script que s'executa desatès pot fer servir un token que duri més. Des de la 7.3.0 necessita l'opció de rol `allowApiTokens`:
+
+* Crea'n un a [Perfil > Tokens d'API](../profile/api-token.html).
+* O inicia sessió amb el paràmetre de consulta `expiryDays`, per obtenir un token vàlid durant aquest nombre de dies:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` només es llegeix de l'URL, mai del cos. Per a un usuari amb rols que no tenen `allowApiTokens`, s'ignora,
+i l'inici de sessió retorna un token amb la durada habitual. `expiryDays=never` també necessita `extendedTokenExpiration`. Afegeix el paràmetre de consulta `name`
+(`?expiryDays=90&name=nightly-backup`) per posar nom al token a la llista de tokens de l'usuari.
+
+Un token de llarga durada dura com a màxim [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) dies, 90 per
+defecte: un `expiryDays` més llarg es retalla a aquest valor, tret que sigui `never`. Renovar-lo retorna un token ordinari, així que torna a iniciar sessió quan caduqui.
+
+### Tokens de l'usuari que ha iniciat sessió
+
+La vista **Tokens d'API** del perfil fa servir aquests endpoints, que funcionen per a qualsevol compte, SSO inclòs, perquè no necessiten contrasenya:
+
+| Crida | Què fa |
+|---|---|
+| `GET /api/v2/profile/tokens` | Llista els teus tokens d'API, amb el seu `sid`, `name`, creació, caducitat i darrer ús |
+| `POST /api/v2/profile/tokens` | Crea un token a partir de la teva sessió; el cos conté `expiryDays` (un número, o `never`) i un `name` opcional |
+| `DELETE /api/v2/profile/tokens/{sid}` | Revoca un dels teus tokens |
+
+`POST` respon `403` quan es crida amb un token d'API (un token no en pot crear un altre), sense `allowApiTokens`, o quan la
+sessió es va iniciar fa més de 10 minuts (codi `sign_in_again`): torna a iniciar sessió primer. Una durada per sobre del màxim respon `400`.
+
+---
+
+## Quan un token s'acaba abans d'hora
+
+Un token, de llarga durada o no, deixa de funcionar abans de caducar quan passa una d'aquestes coses:
+
+* **Un tancament de la seva sessió**: `POST /api/v2/auth/logout` amb el token acaba els tokens d'aquell inici de sessió, i només aquests. Un
+  tancament de sessió al navegador no acaba el token d'un script.
+* **Un canvi de contrasenya**: l'usuari canvia la seva contrasenya, o un administrador la defineix. Es rebutja qualsevol token emès abans.
+* **L'usuari s'elimina o es bloqueja**: suprimir un usuari local, o bloquejar un usuari, acaba tots els seus tokens. Un administrador també pot
+  acabar les sessions d'un usuari de LDAP o SSO.
+
+Un token rebutjat respon `401`. Torna a iniciar sessió, amb la contrasenya nova si ha canviat.
+
+---
+
+## Scripts que inicien sessió a cada execució
+
+Els endpoints d'inici de sessió i de tokens estan protegits contra allaus de peticions i contra l'endevinament de contrasenyes, així que un script que inicia sessió cada vegada que s'executa
+hauria de conèixer aquests límits:
+
+| Límit | Predeterminat | Què passa |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 peticions per minut des d'una adreça | L'inici de sessió, el tancament de sessió, la renovació, els endpoints d'SSO, `PUT /api/v2/profile` (canvi de contrasenya) i `POST` o `DELETE /api/v2/profile/tokens` responen `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 inicis de sessió fallits seguits | El compte es bloqueja durant [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), i qualsevol inici de sessió respon `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 inicis de sessió fallits des d'una adreça | Qualsevol inici de sessió des d'aquesta adreça respon `429` fins que s'acaba la finestra |
+
+Un `429` porta una capçalera `Retry-After` amb els segons que cal esperar: atura't i espera, no ho tornis a provar de seguida. Un compte bloquejat
+rebutja fins i tot la contrasenya correcta fins que s'acaba el bloqueig, així que un script amb una contrasenya incorrecta bloqueja el seu usuari per a tothom.
+Una contrasenya actual incorrecta en un canvi de contrasenya (`PUT /api/v2/profile`) també compta com a inici de sessió fallit, i un compte bloquejat
+no pot canviar la seva contrasenya. Un inici de sessió correcte posa a zero el comptador del compte, i també ho fa que un administrador defineixi la contrasenya.
+
+Per no topar amb aquests límits, inicia sessió una vegada i reutilitza el token, o fes servir un token de llarga durada, en lloc d'iniciar sessió a
+cada crida. Darrere d'un servidor intermediari invers, defineix [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) perquè el servidor vegi
+l'adreça del client, o tots els clients comptaran com un de sol.
diff --git a/i18n/ca/_integrate/api/events.md b/i18n/ca/_integrate/api/events.md
new file mode 100644
index 0000000..7b2ac0f
--- /dev/null
+++ b/i18n/ca/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Esdeveniments en directe
+parent: API REST
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Esdeveniments en directe
+{: .no_toc }
+
+Saber quan canvien les tasques i la configuració, en lloc de consultar-ho periòdicament
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+El servidor explica als seus clients què canvia, a mesura que canvia. Un script també pot escoltar, en lloc de llegir una tasca cada pocs segons.
+
+---
+
+## El flux
+
+`GET /api/v2/events` és un flux de [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+que es manté obert. Qualsevol usuari que hagi iniciat sessió el pot obrir, amb el token bearer habitual:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Quan alguna cosa canvia, envia un esdeveniment `changed` amb el nom del que ha canviat:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Noms d'esdeveniments
+
+Un esdeveniment només porta un nom, mai dades, així que no revela res que l'usuari no pugui veure. S'envien aquests noms:
+
+| Nom | Què ha canviat |
+|---|---|
+| `jobs` | Una tasca: llançada, el seu estat o la seva sortida, suprimida |
+| `appearance` | La configuració que mostra la capçalera: el tema, el nom, un anunci, una variable d'entorn |
+| `designer` | Un bloqueig del dissenyador, pres o alliberat |
+| `runners` | Un runner (des de la 7.3.0): un RTE s'ha connectat o desconnectat, ha demanat unir-se, s'ha aprovat o rebutjat, o ha canviat el seu mode o la seva configuració |
+
+En rebre un nom, torna a llegir el que mostres a través de l'API normal (per exemple `GET /api/v2/job/42`), amb els teus propis
+permisos. Un nom molt actiu s'envia com a màxim un cop per segon.
+
+---
+
+## Mantenir-lo obert
+
+El flux està pensat per sobreviure a servidors intermediaris i balancejadors de càrrega, i un client es torna a connectar tot sol:
+
+* En connectar-se, el servidor envia un esdeveniment `hello`, i demana al client que esperi 3 segons abans de tornar-se a connectar.
+* Cada 15 segons envia una línia de comentari (`: ping`), perquè no es tanqui una connexió inactiva. Ignora les línies que comencen amb `:`.
+* Els esdeveniments de tots els nodes d'aplicació arriben a tots els fluxos, sigui quin sigui el node al qual està connectat el client.
+* Després d'una reconnexió, torna a llegir el que mostres: un esdeveniment enviat mentre el flux estava caigut no es torna a enviar.
+
+---
+
+## Salut i mètriques
+
+Les sondes de liveness i readiness (`/api/v2/live`, `/api/v2/ready`) i les mètriques de Prometheus (`/api/v2/metrics`) estan
+pensades per a eines de monitoratge més que per a scripts que actuen com un usuari. Consulta [Monitoratge](../production/monitoring.html).
diff --git a/i18n/ca/_integrate/api/index.md b/i18n/ca/_integrate/api/index.md
new file mode 100644
index 0000000..1ba6bee
--- /dev/null
+++ b/i18n/ca/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: API REST
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# API REST
+{: .no_toc }
+
+Llança formularis i gestiona AnsibleForms des de scripts
+{: .fs-6 .fw-300 }
+
+---
+
+Per a desenvolupadors i enginyers d'automatització: llança formularis i gestiona AnsibleForms des de scripts.
+
+Tot el que fa la interfície web passa per l'API REST, així que els scripts i altres eines poden fer el mateix.
+
+---
+
+## Visió general
+
+L'API se serveix sota `/api/v2` al servidor d'AnsibleForms:
+
+* **Referència completa** : aquestes pàgines cobreixen el que més fan servir els scripts. Cada endpoint es descriu, i es pot provar, a la
+  pàgina Swagger integrada del servidor, `https://<your server>/api/v2/docs`.
+* **Permisos** : una crida s'executa com l'usuari del token que porta, amb els rols d'aquest usuari, igual que al navegador.
+* **Validació del llançament** : les tasques llançades a través de l'API es poden comprovar com els llançaments des del navegador
+  (consulta [Validació del llançament](../launch-validation/)).
+* **Límits de peticions** : només estan limitats els endpoints d'inici de sessió, tancament de sessió, renovació del token i inici de sessió únic, el canvi de
+  contrasenya (`PUT /api/v2/profile`) i els endpoints de tokens d'API (`POST` i `DELETE /api/v2/profile/tokens`) (consulta
+  [Autenticació](authentication.html)). Les altres crides no tenen cap límit de peticions (l'[assistent de xat](../chat/) té límits
+  propis), així que un script s'hauria de regular ell mateix, per exemple quan segueix una tasca.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Autenticació](authentication.html) | Iniciar sessió, renovar el token o fer servir un token de llarga durada |
+| [Tasques](jobs.html) | Llançar un formulari, seguir la tasca, avortar-la, rellançar-la o aprovar-la |
+| [Respostes i errors](responses.html) | La forma d'una resposta i els codis d'estat |
+| [Esdeveniments en directe](events.html) | Saber quan canvien les tasques i la configuració, en lloc de consultar-ho periòdicament |
diff --git a/i18n/ca/_integrate/api/jobs.md b/i18n/ca/_integrate/api/jobs.md
new file mode 100644
index 0000000..69b8c2d
--- /dev/null
+++ b/i18n/ca/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Tasques
+parent: API REST
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Tasques
+{: .no_toc }
+
+Llançar un formulari, seguir la tasca, avortar-la, rellançar-la o aprovar-la
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Una tasca és una execució d'un formulari. Llança-la amb el nom del formulari i els seus valors, i després segueix-la pel seu ID.
+
+---
+
+## Llançar un formulari
+
+Envia el nom del formulari i els seus valors a `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+La petició accepta aquestes propietats:
+
+| Propietat | Significat |
+|---|---|
+| `formName` | El nom del formulari que es llança. Obligatori. |
+| `extravars` | Les variables extra de la tasca. També s'accepta `payload` com a nom alternatiu. |
+| `rawFormData` | Els valors dels camps del formulari, tal com els té el navegador. La [validació del llançament](../launch-validation/) els comprova i construeix les extravars a partir d'ells. |
+| `credentials` | Credencials que es passen a la tasca, pel nom. |
+| `files` | Els fitxers pujats als camps de fitxer del formulari (consulta [Pujada de fitxers](../launch-validation/file-uploads.html)). |
+
+La resposta conté l'ID de la tasca nova:
+
+```json
+{ "id": 42 }
+```
+
+Per executar la tasca en mode detallat, afegeix `"__verbose__": true` a les extravars. Necessita l'opció de rol `allowVerboseMode`,
+o el llançament respon `403`.
+
+---
+
+## Pujar un fitxer
+
+Un formulari amb un camp de fitxer necessita que primer es pugi el fitxer. Envia'l com a part multipart `file` a `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+La resposta descriu el fitxer desat:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Passa'l sense canvis al `files` del llançament, sota el nom del camp de fitxer: `"files": { "firmware": { ... } }`. El servidor
+el comprova amb el seu propi disc (consulta [Pujada de fitxers](../launch-validation/file-uploads.html)).
+
+---
+
+## Seguir la tasca
+
+Llegeix la tasca pel seu ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+La tasca conté el seu `status`, les seves `extravars` (també com a `payload`, el mateix objecte), els seus `subjobs` i el seu `output`. La
+sortida és HTML amb els colors de la pàgina de la tasca; afegeix `?text=true` per obtenir text pla, més adequat per a un script o un registre:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+El seu `status` és `running` mentre s'executa, i `approve` mentre espera una aprovació. Una tasca acaba amb un d'aquests:
+
+| Estat | Significat |
+|---|---|
+| `success` | La tasca ha acabat sense errors |
+| `failed` | La tasca ha fallat |
+| `warning` | Una tasca de diversos passos ha acabat, però un pas que té `continue` definit ha fallat pel camí |
+| `aborted` | La tasca s'ha avortat |
+| `rejected` | L'aprovació s'ha rebutjat, així que el que l'esperava no s'ha executat |
+| `abandoned` | El procés que seguia la tasca s'ha aturat (un reinici, un contenidor substituït) i s'ha abandonat la tasca |
+
+Una tasca que s'executava en un runner quan es va abandonar encara pot acabar amb el seu resultat real, si al final aquell runner l'acaba.
+
+---
+
+## Cercar tasques
+
+`GET /api/v2/job` llista primer les tasques més noves, com a `{ "count": ..., "records": [ ... ] }`. Aquests paràmetres de consulta en restringeixen la llista:
+
+| Paràmetre | Significat |
+|---|---|
+| `records` | Quantes tasques, com a màxim. El valor predeterminat és [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), i 5000 el màxim tret que `JOBS_LIST_SIZE` sigui més alt. |
+| `user`, `user_type` | Només les tasques d'aquest usuari. `user_type` és `local` quan s'omet (`ldap`, `azuread`, `oidc` per als altres). |
+| `runner` | Només les tasques que s'han executat en aquest runner |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Un usuari veu les seves pròpies tasques i les tasques que esperen una aprovació que pot donar un dels seus rols. Un administrador, o un rol amb l'opció
+`showAllJobLogs` o `manageAllJobs`, veu totes les tasques. Un registre conté el resum de la tasca (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); llegeix
+la tasca mateixa per obtenir-ne les extravars i la sortida.
+
+`GET /api/v2/job/approvals` respon amb un número: quantes tasques esperen una aprovació que l'usuari pot donar.
+
+---
+
+## Més informació sobre una tasca
+
+Aquests endpoints llegeixen més dades d'una tasca:
+
+| Crida | Què retorna |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | Els valors dels camps amb què es va llançar la tasca, tal com els tenia el formulari. S'apliquen els mateixos permisos que en un rellançament: la teva pròpia tasca (o totes les tasques per a un administrador o un rol amb `manageAllJobs`), un formulari que permeti rellançar, i l'opció de rol `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Els esdeveniments estructurats d'una tasca de playbook (des de la 7.3.0, per a un playbook en un RTE de la 7.3.0 o posterior): cada play, tasca, resultat per host i el resum, amb els seus `order`, `type`, `play`, `task`, `host`, `duration` i `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Un d'aquests esdeveniments amb tot el seu `result`, tal com el mostra el diàleg **Resultat de la tasca**; `400` quan `order` no és un nombre enter, `404` quan la tasca no té aquest esdeveniment |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Un node d'una tasca de workflow: `{ "node", "job", "extravars", "artifacts" }`, on `job` és l'ID de la tasca pròpia del node, o `null` quan el node no s'ha executat. |
+
+---
+
+## Altres accions
+
+Aquests endpoints actuen sobre una tasca existent:
+
+| Crida | Acció |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Avorta una tasca en execució |
+| `POST /api/v2/job/{id}/relaunch` | Rellança una tasca, tal com es va executar o amb canvis (consulta [Rellançar](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Aprova una tasca que espera aprovació; la teva pròpia tasca respon `403`, tret que la seva aprovació defineixi `allowSelf: true` o siguis administrador |
+| `POST /api/v2/job/{id}/reject` | Rebutja una tasca que espera aprovació |
+| `GET /api/v2/job/{id}/download` | Baixa la sortida de la tasca |
+| `DELETE /api/v2/job/{id}` | Suprimeix una tasca |
+
+Avortar, aprovar, rebutjar i suprimir responen amb un missatge, i un rellançament també amb l'ID de la tasca nova:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Afegeix `?verbose=true` a un rellançament per executar la tasca nova en mode detallat, amb l'opció de rol `allowVerboseMode`. Una tasca que
+és en un estat que no correspon a l'acció, per exemple avortar una tasca que ja ha acabat, respon `409`.
diff --git a/i18n/ca/_integrate/api/responses.md b/i18n/ca/_integrate/api/responses.md
new file mode 100644
index 0000000..ad3010e
--- /dev/null
+++ b/i18n/ca/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Respostes i errors
+parent: API REST
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Respostes i errors
+{: .no_toc }
+
+La forma d'una resposta i els codis d'estat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Les respostes són JSON pla, i el codi d'estat HTTP indica si una crida ha tingut èxit.
+
+---
+
+## Respostes
+
+Una crida correcta retorna l'objecte mateix, o una llista amb la seva mida:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Un error retorna un missatge, i detalls quan n'hi ha:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Codis d'estat
+
+El codi d'estat indica què ha anat malament:
+
+| Codi | Significat |
+|---|---|
+| `200` | La crida ha tingut èxit |
+| `400` | La petició està mal formada, per exemple una renovació de token sense token de renovació, o una pujada sense fitxer |
+| `401` | El token falta, és incorrecte o ha caducat: inicia sessió o renova'l |
+| `403` | Els rols de l'usuari no permeten la crida (inclòs aprovar la teva pròpia tasca, tret que la seva aprovació defineixi `allowSelf: true` o siguis administrador), o el compte ha de fer alguna cosa abans (vegeu més avall) |
+| `404` | L'objecte no existeix |
+| `409` | La petició està incompleta (un llançament sense dades), o l'objecte no és en un estat que permeti l'acció |
+| `422` | La [validació del llançament](../launch-validation/) ha rebutjat els valors del formulari; `details` en llista els motius |
+| `429` | Massa peticions als endpoints d'inici de sessió i de tokens, o massa inicis de sessió fallits (consulta [Autenticació](authentication.html)) |
+| `500` | El servidor ha fallat; el registre del servidor té el motiu |
+
+Per a una tasca, un `409` vol dir que és en un estat que no correspon a l'acció: avortar una tasca que no s'està executant (o que ja s'ha demanat avortar),
+rellançar una tasca que encara s'està executant, o aprovar o rebutjar una tasca que ja no espera cap aprovació.
+
+---
+
+## Un 403 amb un codi
+
+Algunes respostes `403` porten un `code`, per a alguna cosa que l'usuari ha de fer al navegador abans que funcioni cap altra crida:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Codi | Què cal fer |
+|---|---|
+| `password_change_required` | L'usuari ha iniciat sessió amb la contrasenya predeterminada pública: canvia-la primer al perfil |
+| `disclaimer_required` | L'avís legal està activat i l'usuari encara no n'ha acceptat la versió actual: accepta'l al navegador |
+
+Un token d'API de llarga durada (consulta [Autenticació](authentication.html#long-lived-tokens)) mai queda retingut per l'avís legal.
diff --git a/i18n/ca/_integrate/chat/index.md b/i18n/ca/_integrate/chat/index.md
new file mode 100644
index 0000000..90a7255
--- /dev/null
+++ b/i18n/ca/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Assistent de xat
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Assistent de xat
+{: .no_toc }
+
+Emplena i llança formularis a través d'una conversa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per als administradors que l'activen, i per als usuaris que hi xategen: emplena i llança formularis a través d'una conversa.
+
+Un botó de xat a cada pàgina obre un
+assistent que troba el formulari adequat, demana la informació que falta, ofereix les opcions del mateix
+formulari com a botons i mostra un resum amb un botó **Llança**. Una tasca només s'inicia quan l'usuari hi fa clic.
+
+---
+
+## Com funciona
+
+L'assistent es comunica amb el model d'IA a través del servidor, que respon les peticions del model amb el mateix motor de formularis que el navegador:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Les crides al model surten del servidor**, mai del navegador, així que la clau d'API es queda al servidor
+  (consulta [Proveïdors](providers.html)).
+- **El model no pot llançar res.** Prepara un resum d'un sol ús; Llança el torna a comprovar abans d'executar-lo.
+- **L'usuari tria els destins.** Les opcions i els noms obligatoris vénen de l'usuari, mai del model.
+- **Escriure "sí" o "llança" no fa res.** Només el botó llança una tasca.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Activar-lo](switching-it-on.html) | Activar l'assistent i oferir-hi formularis |
+| [Proveïdors](providers.html) | El model de llenguatge que hi ha darrere de l'assistent, i els proxies |
+| [Privadesa i límits](privacy-and-limits.html) | Què surt de la xarxa, i els límits per usuari |
+| [Rellançament i auditoria](relaunching-and-audit.html) | Rellançar des del xat, la traça d'auditoria i les limitacions |
diff --git a/i18n/ca/_integrate/chat/privacy-and-limits.md b/i18n/ca/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..e2fa898
--- /dev/null
+++ b/i18n/ca/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Privadesa i límits
+parent: Assistent de xat
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Privadesa i límits
+{: .no_toc }
+
+Què surt de la xarxa, i els límits per usuari
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Què surt de la xarxa
+
+Dels formularis que hi participen, s'envia al proveïdor el següent:
+
+- els noms i les descripcions dels formularis, les etiquetes dels camps, els textos d'ajuda, les opcions i els valors que s'estan
+  emplenant;
+- la conversa.
+
+El següent no s'envia mai al proveïdor, a la pàgina ni al registre:
+
+- les contrasenyes (l'usuari les introdueix al navegador), les credencials desades i la clau d'API;
+- la sortida d'una tasca, i les seves extravars desades (l'assistent només llegeix l'estat d'una tasca, i només
+  quan **Deixa que l'assistent segueixi els seus jobs** està activat a la configuració).
+
+Tot el que hi ha sota una clau que sembla un secret (`password`, `secret`, `token`, `api_key`, ...)
+s'emmascara abans que el model o la pàgina ho vegin.
+
+Per mantenir les dades dels formularis a casa, fes servir el teu propi tenant (Azure OpenAI) o un model local (Ollama), no una API pública.
+
+---
+
+## Límits
+
+Els límits següents es defineixen a la pàgina de configuració:
+
+- **Missatges per conversa** (20) - després dels quals l'usuari ha de començar una conversa nova.
+- **Rondes d'eines per missatge** (6) - quantes vegades pot cridar el model una eina abans de respondre.
+- **Temps d'espera** (60 s) - per crida al proveïdor.
+
+Els límits següents són fixos: un missatge alhora per conversa, com a màxim 4000 caràcters per missatge, 60 missatges per
+usuari i hora, i 5 converses per usuari. Una conversa es descarta després de 2 hores sense cap missatge.
+
+Una targeta de resum amb un botó **Llança** es pot fer servir una sola vegada, i caduca al cap de 15 minuts: aleshores Llança respon que el
+resum ha caducat, i l'usuari en demana un de nou a l'assistent. Les converses i els resums es guarden a la memòria, així que després
+d'un reinici l'usuari ha de començar una conversa nova.
diff --git a/i18n/ca/_integrate/chat/providers.md b/i18n/ca/_integrate/chat/providers.md
new file mode 100644
index 0000000..b70a629
--- /dev/null
+++ b/i18n/ca/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Proveïdors
+parent: Assistent de xat
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Proveïdors
+{: .no_toc }
+
+El model de llenguatge que hi ha darrere de l'assistent, i els proxies
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Tria el proveïdor a la pàgina de configuració. Això n'omple l'URL base, l'autenticació i
+la versió de l'API, que continuen sent editables. Els camps buits fan servir els valors predeterminats del proveïdor.
+
+| Proveïdor | Protocol | URL base (predeterminat) | La clau s'envia com a |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | obligatori: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, versió de l'API `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | cap |
+| **Un altre compatible amb OpenAI** (LiteLLM, una passarel·la, vLLM, LM Studio, ...) | OpenAI | obligatori, normalment acabat en `/v1` | Bearer |
+
+L'ID del model és el que fa servir el proveïdor o el proxy (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). L'assistent necessita un model que admeti **tool calling** (crides a eines); el suport varia entre
+els models locals petits.
+
+Per a servidors locals i proxies que no necessiten clau, n'hi ha prou amb un URL base; no s'envia cap capçalera d'autorització.
+
+---
+
+## La clau d'API
+
+La clau ve d'una credencial, així que es desa i es renova com qualsevol altre secret:
+
+* Crea una credencial de tipus **api** a **Configuració > Connexions > Credencials** (consulta [Credencials](../credentials.html)),
+  amb la clau com a contrasenya. També pot llegir la clau d'un [magatzem de secrets](../secret-stores/).
+* Tria-la al camp **Credencial** de la configuració del xat. La clau es llegeix a cada missatge, així que una
+  contrasenya canviada s'aplica al missatge següent.
+
+Una clau desada a la pàgina de configuració abans que existissin les credencials continua funcionant mentre no es triï cap credencial. El
+[config seed](../seed/) defineix la clau directament, com a `api_key`.
+
+---
+
+## Per a un proxy
+
+Un proxy o una passarel·la davant del model pot necessitar aquests paràmetres:
+
+- **Autenticació** - com s'envia la clau: `Authorization: Bearer`, `api-key`, `x-api-key`,
+  o cap. Buit fa servir el valor predeterminat del proveïdor.
+- **Versió de l'API** - la capçalera `anthropic-version`, o `?api-version=` a l'URL per als compatibles amb OpenAI (Azure).
+- **Usuari** - s'envia amb cada crida com a `user` (compatible amb OpenAI) o `metadata.user_id`
+  (Anthropic). Alguns proxies l'exigeixen. Buit no envia res.
+- **Ignora els errors de certificat** - insegur; en lloc d'això, confia en la CA del proxy amb `NODE_EXTRA_CA_CERTS`.
+- **Capçaleres addicionals** - un objecte JSON, p. ex. `{"X-Org": "ops"}`. Valors de text d'una sola línia, com a màxim 20;
+  les capçaleres de clau i de contingut no es poden substituir.
+
+---
+
+## En un contenidor, darrere d'un proxy
+
+El xat fa servir HTTPS sortint normal des del contenidor del servidor d'AnsibleForms. Darrere d'un
+proxy de sortida corporatiu, defineix `HTTPS_PROXY` **i** `NODE_USE_ENV_PROXY=1`; sense el segon,
+el client HTTP integrat de Node ignora `HTTPS_PROXY`. Un proveïdor amb un certificat d'una
+CA interna necessita que Node confiï en aquesta CA (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Amb `NODE_USE_ENV_PROXY=1`, un model o un proxy dins de la xarxa ha de figurar a
+`NO_PROXY`, o la crida va al proxy de sortida, que no hi pot arribar.
+
+Una prova de connexió fallida indica el host i el motiu (DNS, connexió rebutjada o certificat no fiable).
diff --git a/i18n/ca/_integrate/chat/relaunching-and-audit.md b/i18n/ca/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..8c2c1f6
--- /dev/null
+++ b/i18n/ca/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Rellançament i auditoria
+parent: Assistent de xat
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Rellançament i auditoria
+{: .no_toc }
+
+Rellançar des del xat, la traça d'auditoria i les limitacions
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rellançament
+
+Una petició com ara "Torna a executar la tasca 1234" (l'usuari ha d'escriure l'ID de la tasca) previsualitza un rellançament
+amb les mateixes regles que `relaunch_job` del servidor MCP, inclosa la regla de contrasenyes de la
+[validació del llançament](../launch-validation), i mostra un resum **Rellança**; el botó
+el llança una vegada. "Torna a executar la tasca 1234 amb el servidor web02" només canvia aquest camp.
+
+---
+
+## Auditoria
+
+Cada llançament des del xat es registra com a **chat.launch** amb l'usuari, la tasca, el formulari,
+el proveïdor i el hash del payload del resum que es va aprovar. Els canvis a la configuració del xat es
+registren com qualsevol altre canvi de configuració.
+
+---
+
+## Limitacions
+
+L'assistent de xat encara no fa tot el que fa un navegador:
+
+- Els **formularis d'assistent (wizard)** no hi poden participar (`enableForChat` s'hi rebutja), ni tampoc
+  els camps que l'assistent no emplena: contrasenyes i pujades de fitxers.
+- Les respostes arriben d'una sola peça; encara no s'admet el streaming.
+- El model pot entendre malament una petició. La targeta de resum mostra exactament què s'enviarà;
+  revisa-la abans de fer clic a **Llança**.
diff --git a/i18n/ca/_integrate/chat/switching-it-on.md b/i18n/ca/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..318bc44
--- /dev/null
+++ b/i18n/ca/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Activar-lo
+parent: Assistent de xat
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Activar-lo
+{: .no_toc }
+
+Activar l'assistent i oferir-hi formularis
+{: .fs-6 .fw-300 }
+
+---
+
+L'assistent necessita aquestes quatre coses alhora:
+
+1. **`ENABLE_CHAT=1`** - la variable d'entorn. Si es canvia a la pàgina de configuració, s'aplica a l'instant, sense reiniciar; mentre
+   està desactivada, els endpoints del xat responen `404`. Consulta [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Un proveïdor de models** - Configuració -> Connexions -> **Assistent de xat** (o el [config seed](../seed) a Kubernetes).
+3. **Formularis que hi participin** - `enableForChat: true` a cada formulari; l'assistent ignora tots els altres.
+4. **Usuaris que el puguin fer servir** - l'opció de rol `allowChat` (per defecte: true). Defineix
+   `allowChat: false` en un rol per excloure'n els membres.
+
+El botó de xat apareix per a un usuari quan es compleixen les quatre condicions.
diff --git a/i18n/ca/_integrate/mcp/index.md b/i18n/ca/_integrate/mcp/index.md
new file mode 100644
index 0000000..906ac6c
--- /dev/null
+++ b/i18n/ca/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Servidor MCP
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# Servidor MCP
+{: .no_toc }
+
+Deixa que els agents d'IA facin servir els teus formularis a través del Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a administradors i integradors: deixa que els clients MCP llistin, emplenin i llancin formularis com l'usuari del token que tenen.
+
+AnsibleForms pot servir un
+servidor de [Model Context Protocol](https://modelcontextprotocol.io), perquè un client MCP, com ara
+el backend d'un xat o un assistent d'un IDE, pugui llistar els formularis que un usuari pot fer servir, determinar-ne els camps,
+llançar tasques i seguir-ne el progrés.
+
+---
+
+## Què és, i què no és
+
+El servidor MCP és una interfície tècnica al mateix flux de formularis que fa servir el navegador. S'executa
+**com l'usuari del token que rep**: els mateixos rols de formulari, la mateixa visibilitat de les tasques i les
+mateixes comprovacions sobre les extravars reservades que un enviament des del navegador.
+
+No hi afegeix cap política d'IA pròpia. Si un agent ha de demanar confirmació abans d'un llançament,
+quins formularis pot fer servir o quantes peticions pot fer, ho decideix el client MCP. L'eina
+de llançament està marcada com a destructiva, així que un client ben comportat demana confirmació primer,
+però el servidor no ho imposa.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Configuració](setup.html) | Activar el servidor i autenticar el client |
+| [Eines](tools.html) | Les eines que fa servir un agent per emplenar, aprovar i rellançar formularis |
+| [Limitacions](limitations.html) | Les expressions s'executen al servidor, i què no fa el servidor MCP |
diff --git a/i18n/ca/_integrate/mcp/limitations.md b/i18n/ca/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..ad12f31
--- /dev/null
+++ b/i18n/ca/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Limitacions
+parent: Servidor MCP
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Limitacions
+{: .no_toc }
+
+Les expressions s'executen al servidor, i què no fa el servidor MCP
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Expressions runLocal
+
+Les expressions `runLocal`, els camps `local` / `credential` / `html` i els valors predeterminats `evalDefault`
+s'avaluen al servidor, en un context V8 separat: sense `process`, `require`, xarxa ni
+temporitzadors, sense compilar cadenes en codi, amb un límit de temps de 2 segons i només amb les funcions
+auxiliars que ofereix el navegador (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Això protegeix contra expressions defectuoses o descontrolades. No és un sandbox per a codi hostil,
+i no cal que ho sigui: el codi ve de la definició del formulari, mai de qui crida el servidor
+MCP, i cada valor que envia qui crida se substitueix com un literal de JavaScript.
+
+Una expressió que fa servir una API del navegador (`window`, `document`, `fetch`) no s'hi pot executar i
+retorna `status: error`.
+
+Les expressions del costat del servidor (sense `runLocal`) passen per les mateixes
+regles d'[`EXPRESSION_SANITIZER`](../customization) que per al navegador.
+
+---
+
+## Limitacions
+
+Alguns formularis i camps encara no es poden fer servir a través del servidor MCP:
+
+- Els **formularis d'assistent (wizard)** encara no es poden llançar. Els seus passos es poden resoldre amb `subform`.
+- Els **camps de fitxer** no es poden emplenar; es rebutja un formulari amb un camp de fitxer que tingui valor.
+- **Files de llista** (i un camp `yaml` amb un subform, que és una fila d'aquest tipus): cada fila que
+  envies, excepte una que porti el `deleteMarker` de la llista, es resol a través del seu subform amb
+  els valors del formulari com a `__parent__` i després es valida. Això inclou les llistes niades, en què
+  `__parent__.__parent__` arriba al formulari. Envia files planes, és a dir, els valors en brut dels camps
+  del subform. Les files que fallen es llisten per camp de llista a `rowErrors`
+  (`vms[1].disks[0].size (missing)` al missatge). S'accepten com a màxim 500 files per crida,
+  sumant tots els nivells.
+- Un enum deixat en `__auto__` mai s'emplena amb la seva primera opció; qui crida ha de triar.
+- Cada petició MCP crea una entrada al registre d'auditoria (acció "Sol·licitud MCP (agent d'IA)"); la
+  tasca mateixa es registra a nom de l'usuari, com qualsevol altre llançament.
diff --git a/i18n/ca/_integrate/mcp/setup.md b/i18n/ca/_integrate/mcp/setup.md
new file mode 100644
index 0000000..153c14e
--- /dev/null
+++ b/i18n/ca/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Configuració
+parent: Servidor MCP
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Configuració
+{: .no_toc }
+
+Activar el servidor i autenticar el client
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Activar-lo
+
+Posa [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) a `1`, o activa'l a **Configuració > Connexions > MCP**
+(consulta [La pàgina MCP](#the-mcp-page)). Si es canvia a la pàgina de configuració, l'interruptor s'aplica a l'instant, sense reiniciar. Mentre està
+desactivat, l'endpoint respon `404`. L'endpoint és:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Fa servir Streamable HTTP sense estat amb respostes JSON simples, així que `GET` i `DELETE` retornen 405.
+
+---
+
+## Limitar el que poden fer els agents
+
+Dos interruptors més restringeixen el servidor MCP per a tots els clients. Com `ENABLE_MCP`, s'apliquen sense reiniciar:
+
+| Variable | Amb `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | El servidor no ofereix cap de les eines que llancen, planifiquen o canvien coses (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), i les rebutja. Els agents poden llistar, llegir i emplenar formularis, llegir programacions i tasques desades, i seguir tasques, però no llancen ni canvien res: una manera segura de provar un agent. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Els agents només veuen els formularis que defineixen `enableForChat: true`, la mateixa llista que l'[assistent de xat](../chat/). Qualsevol altre formulari, i qualsevol tasca d'un d'ells, respon com si no existís. |
+
+Tots dos estan desactivats per defecte: els agents veuen tots els formularis que permeten els rols de l'usuari, i els poden llançar.
+
+---
+
+## La pàgina MCP
+
+**Configuració > Connexions > MCP** conté la configuració del servidor MCP en dues pestanyes.
+
+- **General** té els tres interruptors, `ENABLE_MCP`, `MCP_READ_ONLY` i `MCP_CHAT_FORMS_ONLY`, que es desen amb **Desa**. Els altres
+  dos només es poden canviar mentre el servidor MCP està activat.
+- **Configuració del client** mostra el **Punt final**, amb un botó per copiar-lo, i una configuració a punt per a **Claude Code**
+  (`.mcp.json`, o una ordre `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, que demana
+  el token la primera vegada que s'inicia el servidor) i **Codex** (`~/.codex/config.toml`, amb el token a la
+  variable d'entorn `ANSIBLEFORMS_TOKEN`). Cadascuna té el seu botó de copiar; substitueix `<your-token>` per un token propi, creat
+  amb l'enllaç **Crea un testimoni**.
+
+El punt final es construeix a partir de l'URL de l'aplicació (**Configuració > URL**) quan està definit, i si no, a partir de l'adreça del navegador.
+
+---
+
+## Autenticació
+
+Cada petició necessita un token d'accés d'AnsibleForms:
+
+```
+Authorization: Bearer <token>
+```
+
+Obtén-ne un de la manera habitual (`POST /api/v2/auth/login`, o els fluxos d'OIDC / Entra ID) i
+renova'l amb `POST /api/v2/token`. Expressament **no hi ha cap eina d'inici de sessió**: una contrasenya passada com a
+argument d'una eina acabaria al context del model de llenguatge i al seu historial de xat.
+
+Els rols de l'usuari també han de permetre el servidor MCP, mitjançant l'[opció de rol](../config/roles.html) `allowMcp`. Quan cap rol
+de l'usuari no la defineix, segueix `allowChat`, que està activada per defecte. Un usuari a qui es denega rep `403` a cada petició.
+
+- **El backend d'un xat** inicia ell mateix la sessió de l'usuari, guarda el token de renovació i passa el token
+  d'accés a cada crida MCP.
+- **Un client d'IDE** necessita un token que duri prou per configurar-lo una sola vegada. Amb un rol
+  que tingui l'opció `allowApiTokens`, crea'n un a
+  [Perfil > Tokens d'API](../profile/api-token.html), o inicia sessió amb `?expiryDays=<n>` a
+  l'URL d'inici de sessió per obtenir un token vàlid durant aquest nombre de dies.
+
+Per connectar un agent de programació amb un token d'aquest tipus:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Afegeix el servidor amb el token com a capçalera:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Afegeix el servidor a `~/.codex/config.toml`, amb el token llegit d'una variable d'entorn:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Després defineix la variable abans d'iniciar Codex:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/ca/_integrate/mcp/tools.md b/i18n/ca/_integrate/mcp/tools.md
new file mode 100644
index 0000000..5a4e2a2
--- /dev/null
+++ b/i18n/ca/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Eines
+parent: Servidor MCP
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Eines
+{: .no_toc }
+
+Les eines que fa servir un agent per emplenar, aprovar i rellançar formularis
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+El servidor MCP ofereix fins a 15 eines. Sis s'ofereixen a tots els usuaris; les altres segueixen les opcions de rol de l'usuari, així que a un usuari
+sense una opció no se li ofereixen les seves eines en absolut:
+
+| Eina | Què fa | S'ofereix amb |
+|---|---|---|
+| `list_forms` | Els formularis que l'usuari pot fer servir: nom, descripció, categories i `enableForChat` (si l'assistent de xat l'ofereix). | sempre |
+| `get_form` | La definició completa d'un formulari. Cada camp porta també `dynamic` (avaluat a partir d'una expressió o d'una consulta) i `dependsOn` (els camps que llegeix). | sempre |
+| `resolve_field` | Avalua el formulari amb els valors emplenats fins ara. Vegeu més avall. | sempre |
+| `launch_job` | Llança el formulari amb els valors donats, exactament com ho faria un enviament des del navegador. Retorna l'id de la tasca. | sempre |
+| `relaunch_job` | Torna a llançar una tasca amb alguns camps canviats. Vegeu més avall. | sempre |
+| `get_job` | Estat i sortida d'una tasca (`tail` limita la sortida a les darreres línies). | sempre |
+| `plan_job` | Executa el formulari una vegada, més tard, com l'usuari: el que fa **Executa més tard (una vegada)** al formulari. | `allowPlannedJobs` |
+| `create_schedule` | Crea una programació, recurrent (`cron`) o d'una sola vegada (`run_at`), com a la pàgina **Programacions**. | `allowScheduledJobs` |
+| `list_schedules` | Les programacions que l'usuari pot veure: totes amb `allowScheduledJobs`, i si no, les execucions que ha planificat. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `get_schedule` | Una programació, amb les seves extra vars (les que semblen secrets, emmascarades) i la sortida de la seva darrera execució. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `delete_schedule` | Cancel·la una execució planificada o suprimeix una programació que l'usuari pot veure. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `list_stored_jobs` | Les [tasques desades](../jobs/stored-jobs.html) que l'usuari pot veure, sense els seus valors. | `allowStoredJobs` |
+| `get_stored_job` | Una tasca desada amb els seus valors, per `id`, o per `form` i `name` entre les de l'usuari. | `allowStoredJobs` |
+| `store_job` | Desa valors d'un formulari amb un nom, com fa **Desa** al formulari. | `allowStoredJobs` |
+| `delete_stored_job` | Suprimeix una tasca desada que l'usuari pot veure. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` i `plan_job` accepten `verbose: true` per executar la tasca en mode detallat, cosa que necessita l'opció de rol
+`allowVerboseMode`. Amb [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) les eines que llancen, planifiquen o
+canvien coses (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` i `delete_stored_job`)
+no s'ofereixen.
+
+No hi ha cap eina per executar una expressió, una consulta, un playbook o unes extravars arbitràries. Les expressions
+i les consultes només s'executen tal com les defineix el formulari.
+
+L'[assistent de xat](../chat) també fa servir aquestes eines, amb un botó **Llança** en lloc de `launch_job`.
+
+---
+
+## Emplenar un formulari
+
+Crida `resolve_field` amb el nom del formulari i els valors que tens fins ara, i torna-la a cridar després de cada resposta. Recorre
+els camps en ordre de dependència i informa de cadascun:
+
+- `status`: `resolved`, `waiting` (amb `waitingFor`), `hidden`, o `error` (el camp torna al seu valor predeterminat);
+- `value`, `default` i, per als camps d'opcions, `options` (com a màxim `maxOptions`, 200 per defecte);
+- `needsInput`: un camp obligatori sense valor, o una opció que encara és a `__auto__`;
+- `validationErrors`: les regles que incompleix el valor, com a `[{type, description}]`, amb el missatge del navegador.
+
+Per a tot el formulari, `missing` i `invalid` llisten el que encara cal corregir; `launch_job` el rebutja fins que `complete` és true.
+
+La validació és el mateix codi del navegador, compartit amb la [validació del llançament](../launch-validation). Els camps ocults no
+es validen, i un camp opcional buit és vàlid.
+
+---
+
+## Programacions i execucions planificades
+
+`plan_job` accepta els mateixos `form`, `values` i `expectedPayloadHash` que `launch_job`, amb un `name` per a l'execució i `run_at`, una
+hora ISO 8601 amb el seu desplaçament o `Z` (`2026-10-15T22:00:00+02:00`); es rebutja una hora sense zona. Els valors es resolen
+i es validen ara, i es tornen a comprovar quan arriba l'execució, com en una [execució planificada](../jobs/schedules.html#planned-runs) al
+navegador. La resposta dona l'hora de l'execució en UTC i segons el rellotge de l'aplicació.
+
+`create_schedule` accepta un `form`, un `name`, o bé `cron` (cinc camps, com ara `0 22 * * 1-5`) o bé `run_at`, i les
+`extraVars` que rep la tasca. Una programació així s'executa com a `Schedule Service`, sense la validació del formulari; per executar un formulari una vegada com
+l'usuari, fes servir `plan_job`. Els noms de les programacions són únics.
+
+---
+
+## Tasques desades
+
+Una tasca desada són els valors d'un formulari guardats amb un nom; les eines treballen amb les mateixes tasques desades que el navegador.
+
+`list_stored_jobs` llista les tasques desades de l'usuari, o les de tothom per a un usuari amb `showSettings`, amb el nom, la descripció,
+el formulari, la creació i la caducitat. Una de marcada com a `usable` (de l'usuari mateix, d'un formulari que pot llançar) es pot passar com a `storedJob`
+(`{ "id": 7 }`, o `{ "name": "..." }` entre les de l'usuari d'aquell formulari) a `resolve_field`, `launch_job` o `plan_job`: els seus
+valors són el punt de partida i `values` s'hi superposa. Els camps de contrasenya no es desen, així que proporciona'ls a `values`.
+`launch_job` i `plan_job` a partir d'una tasca desada necessiten l'`expectedPayloadHash` que `resolve_field` hi ha retornat, i
+`resolve_field` rebutja `storedJob` juntament amb `subform`.
+
+`store_job` accepta el `form`, un `name` únic entre les tasques desades de l'usuari d'aquell formulari, els `values` i, opcionalment, una
+`description` i `expires_at` (ISO 8601 amb el seu desplaçament o `Z`). La resposta indica quins camps de contrasenya s'han deixat fora.
+
+---
+
+## Passar valors
+
+Passa `field` per resoldre només aquest camp i el que en depèn. Per a una fila de llista o un pas d'assistent, passa `subform` (i
+opcionalment `parent`, els valors del formulari pare).
+
+Envia els valors tal com els té el navegador. Un camp d'opcions també accepta un registre parcial o el seu valor de `valueColumn`
+(`"vol1"`), i un array quan és `multiple`. Els camps calculats ignoren els valors enviats tret que siguin `editable`.
+
+---
+
+## Aprovar el payload exacte
+
+Quan el formulari és complet, `resolve_field` també retorna el que enviarà `launch_job`:
+
+- `modeledExtravars`: les extravars un cop aplicats `model`, `valueColumn` i `output`,
+  amb els camps de contrasenya emmascarats;
+- `credentials`: les credencials d'AnsibleForms que farà servir la tasca (noms, no secrets);
+- `payloadHash`: un hash SHA-256 del nom del formulari, les extravars reals i les credencials.
+
+Mostra `modeledExtravars` a l'operador, i passa el `payloadHash` que ha aprovat a
+`launch_job` com a `expectedPayloadHash`. El llançament torna a resoldre el formulari i es rebutja
+quan el payload és diferent, per exemple perquè ara una consulta respon una altra cosa.
+`ansibleforms_user`, `__jobid__` i `__verbose__` s'afegeixen en el llançament i no formen part del hash.
+
+`launch_job` només comprova el payload. Una edició del formulari que deixa el payload igual no fa que es rebutgi el llançament.
+Cada resposta de `resolve_field` porta també un `formFingerprint`, un hash SHA-256 de la definició del formulari: per rebutjar un
+llançament després de qualsevol edició del formulari, compara'l tu mateix abans de cridar `launch_job`, com fa el botó
+**Llança** de l'assistent de xat.
+
+---
+
+## Rellançar amb canvis
+
+`relaunch_job` accepta un `id` de tasca i `values`: només els camps que cal canviar, com a valors en brut.
+`values` se superposa als valors amb què es va llançar originalment la tasca, i el resultat es
+resol i es valida exactament com amb `launch_job`, files de llista incloses, i després es llança com una
+tasca nova feta per tu (`ansibleforms_user` ets tu, no qui la va enviar originalment). Es reutilitzen els fitxers pujats de
+la tasca original.
+
+Sense `values`, és un rellançament **tal com es va executar la tasca**: les seves extravars desades es tornen a reproduir al
+servidor, contrasenyes incloses (la previsualització les emmascara). Ara bé, si el formulari està sota la validació del llançament
+`enforce`, el rellançament passa per la mateixa comprovació que un rellançament amb
+canvis.
+
+**Les contrasenyes mai es desen amb els valors dels camps**, així que un rellançament que passa per la
+comprovació es rebutja quan el formulari mostra un camp de contrasenya, al nivell superior o en una fila de llista
+(`unsupported`, amb els `passwordFields`). Un camp de contrasenya ocult per les seves dependències no
+bloqueja el rellançament. Consulta [Validació del llançament](../launch-validation).
+
+Crida-la primer amb `preview: true`: retorna `modeledExtravars` (contrasenyes emmascarades),
+`credentials` i un `payloadHash` sense llançar res. Confirma'ls amb l'usuari i després crida-la
+de nou amb `expectedPayloadHash`. S'apliquen els mateixos permisos que en un rellançament al navegador:
+el formulari ha de permetre rellançar i els teus rols necessiten l'opció `allowJobRelaunch`. Una
+tasca sense dades del formulari desades (llançada abans que existís el rellançament) i un formulari d'assistent no es poden
+rellançar amb canvis.
+
+L'API REST ofereix el mateix a través de `POST /api/v2/job/{id}/relaunch` amb el cos
+`{ "values": { ... } }`; sense cos, torna a reproduir la tasca tal com es va executar.
+
+---
+
+## Errors
+
+Una crida rebutjada és un error d'eina el contingut estructurat del qual porta un `code` i els detalls:
+
+| Codi | Quan |
+|---|---|
+| `form_incomplete` | `launch_job` o `relaunch_job` sobre un formulari que no és complet, amb `missing`, `invalid`, `waiting`, `validationErrors` i `rowErrors` |
+| `payload_mismatch` | el payload és diferent d'`expectedPayloadHash`, amb tots dos hashes |
+| `access_denied` | els rols de l'usuari no donen accés al formulari, la tasca, la programació o la tasca desada, o al mode detallat, o el servidor és de només lectura |
+| `not_found` | no existeix el formulari, el subform o la tasca |
+| `unsupported` | un formulari d'assistent, un subform sol, un camp de fitxer, o un `relaunch_job` que necessitaria un camp de contrasenya visible |
+| `no_form_data` | `relaunch_job` amb canvis per a una tasca que no va desar cap valor de formulari, com ara una que va llançar una programació; en aquest cas, rellança-la sense canvis |
+| `invalid_request` | una petició que el servidor rebutja per mal formada |
+| `internal_error` | qualsevol altra cosa |
diff --git a/i18n/ca/_introduction/concepts.md b/i18n/ca/_introduction/concepts.md
new file mode 100644
index 0000000..a057eb2
--- /dev/null
+++ b/i18n/ca/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Conceptes
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Conceptes
+{: .no_toc }
+
+Els termes que es fan servir en aquesta documentació, cadascun enllaçat a la seva pàgina
+{: .fs-6 .fw-300 }
+
+---
+
+## Glossari
+
+Els termes que es fan servir en aquesta documentació:
+
+| Terme | Significat |
+|---|---|
+| **[Formulari](forms/)** | Una definició YAML que recull dades i executa un playbook, una plantilla o un workflow |
+| **[Camp de formulari](formfields/)** | Una entrada d'un formulari, com ara `text`, `enum` o `checkbox`; el seu valor es converteix en una extravar |
+| **[Categoria](config/categories.html)** | Un grup de l'arbre de formularis que es mostra a la pàgina Formularis, definit a `config.yaml` |
+| **[Rol](config/roles.html)** | Un conjunt d'usuaris i grups; un formulari llista els rols que el poden veure i executar, `default` per a tothom |
+| **[Expressió](expressions/)** | JavaScript que calcula el valor d'un camp, al navegador (`runLocal: true`) o al servidor |
+| **[Extravars](formfields/)** | Les variables que s'envien al playbook o a la plantilla, construïdes a partir dels valors dels camps |
+| **[Credencial](expressions/credentials.html)** | Un inici de sessió desat, xifrat amb `ENCRYPTION_SECRET`: un usuari i una contrasenya (i host, port, base de dades) o, des de la 7.3.0, l'adreça i els secrets d'un directori LDAP, un proveïdor d'SSO, un runner o un HashiCorp Vault |
+| **[Magatzem de secrets](secret-stores/)** | Una connexió a HashiCorp Vault o CyberArk que proporciona l'usuari i la contrasenya d'una credencial |
+| **[Tasca](gui/forms-and-jobs.html)** | Una execució d'un formulari, amb el seu estat, les seves extravars i la seva sortida, que es conserva a l'historial de tasques |
+| **[Runner](runners.html)** | On s'executa una tasca, afegit a **Connexions > Runners**: `rte` per a playbooks, `awx` (AWX, o la variant `aap` o `ascender`), `semaphore`, `rundeck` o `jenkins` per a plantilles i jobs. Un formulari en tria un amb `runner:`, o s'executa al runner `rte` (playbooks) o `awx` (plantilles) predeterminat |
+| **[RTE](rte/)** | Un entorn d'execució (runtime environment): el servidor d'AnsibleForms iniciat amb `AF_ROLE=rte` al seu propi contenidor, al costat de python i ansible, que executa els playbooks d'un runner de tipus `rte` |
+| **[Punt d'aprovació](forms/approval.html)** | Una pausa en una tasca fins que un usuari amb un rol d'aprovació l'aprova o la rebutja |
+| **[Workflow](workflows/)** | Un graf de playbooks, aprovacions i altres workflows enllaçats en cas d'èxit, en cas d'error o sempre, amb la sintaxi d'AWX |
+| **[Formulari de diversos passos](forms/multistep.html)** | Obsolet des de la 7: un formulari que executa diversos playbooks o plantilles en seqüència; el substitueix un workflow |
+| **[Canal de notificació](notification-channels.html)** | Un servidor de correu, un webhook de Slack o Teams, un xat de Telegram o un webhook on van les notificacions i les sol·licituds d'aprovació |
+| **[Dissenyador](designer/)** | L'editor del navegador per a formularis, playbooks, inventaris i workflows, que fa servir una sola persona alhora |
+| **[Subform](forms/subform.html)** | Un conjunt reutilitzable de camps que descriu les files d'un camp `list` o l'objecte d'un camp `yaml` |
+| **[config.yaml](config/)** | El fitxer amb les categories, els rols i les constants; els formularis són als seus propis fitxers |
+| **[Config seed](seed/)** | Un fitxer YAML (`CONFIG_SEED_PATH`) que declara els objectes d'administració, com ara runners i credencials |
+| **[Carpeta persistent](customization/paths.html)** | La carpeta que conté els fitxers que AnsibleForms ha de conservar entre reinicis i actualitzacions |
diff --git a/i18n/ca/_introduction/gui/administration.md b/i18n/ca/_introduction/gui/administration.md
new file mode 100644
index 0000000..d228f43
--- /dev/null
+++ b/i18n/ca/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Administració
+parent: Recorregut per la interfície
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Administració
+{: .no_toc }
+
+El menú Configuració: el sistema, la seva aparença, l'accés, les connexions i els registres
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## El menú Configuració
+
+**Configuració** a la capçalera obre les pàgines d'administració, agrupades al menú de l'esquerra a **Sistema**, **Aparença**,
+**Accés**, **Connexions** i **Registres**. Cada entrada només es mostra a un usuari amb l'opció de rol que necessita la seva pàgina:
+`allowBackupOps` per a **Còpies de seguretat**, `showLogs` per a **Registre del servidor** i `showSettings` per a totes les altres pàgines.
+Des de la 7.3.0, tres opcions n'obren una part sense la resta:
+
+| Opció de rol | Obre |
+|---|---|
+| `showAppearanceSettings` | Les pàgines d'**Aparença** |
+| `showConnectionsSettings` | Les pàgines de **Connexions**, excepte **Syslog**; els repositoris, els magatzems de secrets i les credencials protegides només els pot canviar un administrador |
+| `showAuditLog` | El **Registre d'auditoria** |
+
+Consulta [Rols](../config/roles.html#role-options) per veure les opcions de rol.
+
+---
+
+## Llistes i pàgines de registre
+
+Des de la 7.3.0, les llistes de configuració i les pàgines de cada registre comparteixen un mateix disseny, amb els controls en una fila pròpia sota el títol:
+
+| Part | Com funciona |
+|---|---|
+| Quadre de cerca | El primer d'aquesta fila a totes les pàgines de configuració i de registre. Una paraula filtra totes les pestanyes alhora: els camps, les files o les línies que coincideixen es mostren sota el nom de la seva pestanya |
+| Mida de pàgina | Una taula mostra tantes files com caben a la pantalla fins que es tria una mida de pàgina: 10, 20, 50 o 100 |
+| Columnes | Totes les columnes amb nom es poden ordenar, i una cel·la buida mostra `–` |
+| Caselles | Les files només en tenen on es pot fer alguna cosa amb les files marcades, i el menú de la fila (⋮) ofereix la mateixa acció |
+| Menú de la fila | Etiquetes curtes, com ara **Edita** i **Suprimeix**. Una llista amb una columna **Activat** la té en primer lloc, i ofereix **Activa** o **Desactiva** al menú de cada fila, segons correspongui |
+
+Les llistes amb una columna **Activat** són els proveïdors d'SSO, els directoris LDAP, els runners, les programacions, els canals de
+notificació, els servidors syslog, els anuncis, les etiquetes i les versions de l'avís legal.
+
+---
+
+## Sistema
+
+La mateixa instància: la seva configuració, el seu estat de salut i les seves còpies de seguretat.
+
+| Pàgina | Per a què serveix |
+|---|---|
+| **General** | Les variables d'entorn, en pestanyes de Configuració a Registre. Consulta [Variables d'entorn](../customization/). |
+| **Estat** | La salut de la instància i dels sistemes dels quals depèn, a les pestanyes Comprovacions i Informació. Consulta [Monitoratge](../production/monitoring.html). |
+| **Còpies de seguretat** | Fer, restaurar i suprimir còpies de seguretat de la base de dades, config.yaml i els formularis. Consulta [Còpies de seguretat](../production/backups.html). |
+
+![Configuració > General, la pestanya Configuració](../assets/screenshots/settings.jpg)
+
+### Còpies de seguretat
+
+La llista de còpies de seguretat, nocturnes i manuals: **Afegeix una còpia de seguretat** en fa una en aquell moment, i el menú d'una fila té **Mostra la còpia de seguretat**, **Restaura** i **Suprimeix**.
+
+![Configuració > Còpies de seguretat](../assets/screenshots/backups.jpg)
+
+### Restaurar
+
+**Restaura** mostra el que conté la còpia de seguretat i després la restaura; **Crea una còpia de seguretat nova abans de restaurar (recomanat)** està marcada per defecte.
+
+![Restaurar una còpia de seguretat](../assets/screenshots/restore.jpg)
+
+---
+
+## Aparença
+
+Com es veu la instància per a tothom, i els missatges que mostra.
+
+| Pàgina | Per a què serveix |
+|---|---|
+| **Valors predeterminats** | El tema, l'idioma, la vista de formularis, la zona horària i el format de data dels usuaris que no n'han triat cap. Consulta [Valors predeterminats](../appearance/defaults.html). |
+| **Nom** | El nom a la pestanya del navegador i a la pàgina d'inici de sessió. Consulta [Nom](../appearance/name.html). |
+| **Logotip** | El teu propi logotip a la capçalera. Consulta [Logotip](../appearance/logo.html). |
+| **Icona** | La teva pròpia icona a la pestanya del navegador. Consulta [Icona](../appearance/icon.html). |
+| **Enllaços** | L'enllaç al Dissenyador, i els teus propis enllaços i menús a la capçalera. Consulta [Enllaços](../appearance/links.html). |
+| **Etiquetes** | Etiquetes al costat del logotip, com ara PRODUCTION i EU. Consulta [Etiquetes](../appearance/labels.html). |
+| **Anuncis** | Missatges sota la capçalera, cadascun des del seu inici fins al seu final. Consulta [Anuncis](../announcements.html). |
+
+---
+
+## Accés
+
+Qui pot iniciar sessió, i què pot fer un cop dins.
+
+| Pàgina | Per a què serveix |
+|---|---|
+| **Avís legal** | Condicions que cada usuari accepta una vegada, i qui ha acceptat quina versió. Consulta [Avís legal](../disclaimer.html). |
+| **Usuaris** | Els usuaris locals, i els de LDAP i d'inici de sessió únic. Consulta [Usuaris i grups](../users-and-groups.html). |
+| **Grups** | Els grups locals, i els de LDAP i d'inici de sessió únic. Consulta [Usuaris i grups](../users-and-groups/local-group.html). |
+| **Rols** | Els rols de config.yaml: qui els té i què permeten. Consulta [Rols](../config/roles.html). |
+| **LDAP** | Inici de sessió amb un directori LDAP o Active Directory. Consulta [LDAP](../authentication/ldap.html). |
+| **SSO** | Inici de sessió únic amb proveïdors d'Entra ID o OpenID Connect. Consulta [Autenticació](../authentication/). |
+
+![Accés > LDAP, el directori principal](../assets/screenshots/ldap.jpg)
+
+---
+
+## Connexions
+
+Els sistemes als quals accedeix AnsibleForms, i amb què hi inicia sessió.
+
+| Pàgina | Per a què serveix |
+|---|---|
+| **Repositoris** | Els repositoris git d'on vénen els formularis i els playbooks. Consulta [Repositoris git](../repositories/). |
+| **Credencials** | Els comptes i els secrets que fan servir els formularis, els playbooks i les connexions. Consulta [Credencials](../credentials.html). |
+| **Magatzems de secrets** | HashiCorp Vault i CyberArk, d'on es poden llegir les credencials. Consulta [Magatzems de secrets](../secret-stores/). |
+| **Runners** | On s'executen les tasques: contenidors RTE per als playbooks, i AWX i similars per a les plantilles. Consulta [Runners](../runners.html). |
+| **SSH** | El parell de claus amb què l'aplicació es connecta a git, i els amfitrions coneguts. Consulta [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Notificacions** | Servidors SMTP, Slack, Microsoft Teams, Telegram i webhooks. Consulta [Canals de notificació](../notification-channels.html). |
+| **Assistent de xat** | El proveïdor d'IA de l'assistent de xat. Consulta [Assistent de xat](../chat/). |
+| **MCP** | El servidor MCP per a agents d'IA. Consulta [MCP](../mcp/). |
+| **Syslog** | Servidors syslog que reben el registre del servidor, el registre d'auditoria o tots dos. Consulta [Syslog](../production/logs.html#syslog). |
+
+![Connexions > Credencials, la pestanya Connexió d'una credencial](../assets/screenshots/credentials.jpg)
+
+---
+
+## Registres
+
+El que ha passat a la instància.
+
+| Pàgina | Per a què serveix |
+|---|---|
+| **Registre d'auditoria** | Qui ha canviat què, i si estava permès, filtrat per usuari, acció i resultat. Consulta [Traça d'auditoria](../production/logs.html#audit-trail). |
+| **Registre del servidor** | El registre propi del servidor, per resoldre problemes. Consulta [Registres](../production/logs.html). |
+
+### Registre del servidor
+
+Les darreres línies del registre, les més noves a baix, que se segueixen a mesura que s'escriuen. El quadre de cerca les filtra (una expressió
+regular), **Neteja** buida la vista, no el registre, i **Baixa** desa el registre complet.
+
+![Registres > Registre del servidor](../assets/screenshots/logs.jpg)
+
+---
+
+## Documentació de l'API
+
+**Documentació de l'API** al menú d'ajuda (el signe d'interrogació de la capçalera) enllaça a la interfície Swagger de l'API REST a `/api/v2/docs`.
+Consulta [API](../api/).
+
+![Interfície Swagger](../assets/screenshots/swagger.jpg)
diff --git a/i18n/ca/_introduction/gui/designer-and-git.md b/i18n/ca/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..a31a766
--- /dev/null
+++ b/i18n/ca/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Dissenyador i git
+parent: Recorregut per la interfície
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Dissenyador i git
+{: .no_toc }
+
+Editar formularis i guardar-los a git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dissenyador integrat
+
+Edita formularis, categories, constants, fitxers de variables, playbooks, inventaris i workflows, cadascun com a YAML, amb camps (Visual)
+i com a previsualització. Les pàgines del [Dissenyador](../designer/) descriuen cada secció.
+
+![Dissenyador integrat](../assets/screenshots/designer.jpg)
+
+---
+
+## Repositoris git
+
+Integra't amb repositoris git per posar els teus formularis i playbooks sota control de versions.
+
+![Repositoris git](../assets/screenshots/git.jpg)
+
+---
+
+## Editor de repositoris git
+
+Edita i configura els paràmetres de la integració amb repositoris git.
+
+![Editor de repositoris git](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/ca/_introduction/gui/forms-and-jobs.md b/i18n/ca/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..752fba3
--- /dev/null
+++ b/i18n/ca/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formularis i tasques
+parent: Recorregut per la interfície
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formularis i tasques
+{: .no_toc }
+
+Iniciar sessió, el tauler principal, emplenar un formulari i seguir-ne les tasques
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Inici de sessió
+
+La pàgina d'autenticació d'usuaris, compatible amb autenticació local, LDAP, Entra ID i OIDC.
+
+![Inici de sessió](../assets/screenshots/login.jpg)
+
+---
+
+## El tauler principal
+
+El tauler principal mostra tots els formularis disponibles, organitzats per categoria.
+
+![Tauler principal](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Un formulari
+
+Un exemple de formulari amb fonts de dades externes i camps dinàmics.
+
+![Exemple de formulari](../assets/screenshots/form.jpg)
+
+---
+
+## Previsualització JSON del formulari
+
+Previsualitza el payload JSON i les variables extra que es passen a Ansible abans d'executar la tasca.
+
+![Previsualització JSON del formulari](../assets/screenshots/form-json.jpg)
+
+---
+
+## Tasca en execució
+
+Execució en temps real d'un playbook d'Ansible, amb la sortida en directe.
+
+![Tasca en execució](../assets/screenshots/run.jpg)
+
+---
+
+## Sortida de la tasca
+
+La sortida completa d'un playbook d'Ansible ja executat.
+
+![Sortida de la tasca](../assets/screenshots/job-output.jpg)
+
+---
+
+## Registre de tasques
+
+Totes les tasques amb el seu estat i les seves hores, filtrades per estat des del menú de l'esquerra.
+
+![Registre de tasques](../assets/screenshots/job-log.jpg)
+
+---
+
+## Diversos passos
+
+Una tasca de diversos passos, amb la sortida de cada pas sota la tasca principal. Els formularis de diversos passos són obsolets des de la 7: un
+[workflow](../workflows/) encadena playbooks, plantilles i aprovacions en el seu lloc.
+
+![Formulari de diversos passos](../assets/screenshots/multistep.jpg)
+
+---
+
+## Programacions
+
+Programa formularis perquè s'executin a hores concretes o a intervals. Els [exemples de cron](../faq.html#which-cron-expressions-can-i-use) llisten
+expressions habituals i expliquen en quina zona horària s'executa una programació.
+
+![Programacions](../assets/screenshots/schedules.jpg)
diff --git a/i18n/ca/_introduction/gui/index.md b/i18n/ca/_introduction/gui/index.md
new file mode 100644
index 0000000..4777ceb
--- /dev/null
+++ b/i18n/ca/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Recorregut per la interfície
+nav_order: 3
+has_children: true
+has_toc: false
+description: Captures de pantalla i recorregut per la interfície gràfica d'usuari
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Recorregut per la interfície
+{: .no_toc }
+
+Un recorregut visual per la interfície web d'AnsibleForms, des del tauler principal fins a les funcions avançades d'administració.
+{: .fs-6 .fw-300 }
+
+---
+
+Per a tots els usuaris i administradors: les pantalles de la interfície web, agrupades segons el que hi fas.
+
+---
+
+## En aquesta secció
+
+Cada grup de pantalles té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Formularis i tasques](forms-and-jobs.html) | Iniciar sessió, el tauler principal, emplenar un formulari i seguir-ne les tasques |
+| [Dissenyador i git](designer-and-git.html) | Editar formularis i guardar-los a git |
+| [Administració](administration.html) | El menú Configuració: el sistema, la seva aparença, l'accés, les connexions i els registres |
+| [Configuració personal](personal-settings.html) | El teu perfil i el tema fosc |
diff --git a/i18n/ca/_introduction/gui/personal-settings.md b/i18n/ca/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..a90edf2
--- /dev/null
+++ b/i18n/ca/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Configuració personal
+parent: Recorregut per la interfície
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Configuració personal
+{: .no_toc }
+
+El teu perfil i el tema fosc
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Perfil d'usuari
+
+El teu compte, les teves preferències, la contrasenya, els permisos i els tokens d'API.
+
+Consulta [El teu perfil](../profile).
+
+![Perfil d'usuari](../assets/screenshots/profile.jpg)
+
+---
+
+## Mode fosc
+
+AnsibleForms admet el mode fosc per cansar menys la vista.
+
+![Mode fosc](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/ca/_introduction/how-it-works.md b/i18n/ca/_introduction/how-it-works.md
new file mode 100644
index 0000000..5983e17
--- /dev/null
+++ b/i18n/ca/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Com funciona
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Com funciona
+{: .no_toc }
+
+Les parts d'una instal·lació, què passa en un llançament i on es desen les dades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Arquitectura
+
+AnsibleForms és un servidor Node.js que serveix l'aplicació web i una API REST, amb una base de dades MySQL al darrere. Llegeix els formularis
+de fitxers YAML i no executa res per si mateix: lliura cada tasca a un [runner](runners.html). Un playbook va a un dels teus contenidors RTE
+(runtime environment, entorn d'execució), que executa `ansible-playbook`, i una plantilla o un job va a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Arquitectura d'AnsibleForms</title>
+<desc id="afd-desc">El navegador i un client MCP opcional es comuniquen amb el servidor d'AnsibleForms. El servidor desa les seves dades a MySQL i a la carpeta persistent, i es connecta a fonts de dades, magatzems de secrets, repositoris git, proveïdors d'inici de sessió, canals de notificació, servidors syslog i un proveïdor de models opcional. Els seus runners lliuren cada playbook a un d'un o diversos contenidors RTE, cadascun a través d'un WebSocket, que executen ansible-playbook i retornen la sortida al servidor, i cada plantilla o job a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Navegador</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">formularis, dissenyador,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">tasques, xat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">Client MCP</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">opcional</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">Servidor d'AnsibleForms</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Aplicació web i API REST</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formularis, expressions</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflows, programacions</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">Servidor MCP (opcional)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runners</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">lliuren cada tasca al seu runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Fonts de dades</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">bases de dades, API, fitxers</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Magatzems de secrets</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Repositoris git</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">formularis, playbooks, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Inici de sessió</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Notificacions</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">correu, Slack, Teams, webhooks</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Servidors syslog</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">el registre, l'auditoria</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Proveïdor de models</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">opcional, assistent de xat</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Carpeta persistent</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, formularis, playbooks</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">tasques, usuaris,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">credencials</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">Contenidors RTE</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">executen ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbooks,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">plantilles, jobs</text>
+</svg>
+</div>
+
+Cada component del diagrama té el seu propi paper:
+
+| Component | Paper |
+|---|---|
+| **Navegador** | L'aplicació web Vue: els formularis, el [Dissenyador](gui/designer-and-git.html), l'historial de tasques i la configuració |
+| **Servidor d'AnsibleForms** | Avalua els formularis, registra les tasques, executa els workflows i les programacions, lliura cada tasca al seu runner i en fa el seguiment, i serveix l'[API REST](api/) |
+| **Runners** | On s'executen les tasques, afegits a **Connexions > Runners**: un formulari n'anomena un amb `runner: <name>`, o fa servir el runner predeterminat del seu tipus (consulta [Runners](runners.html)) |
+| **Contenidors RTE** | Un o diversos contenidors d'entorn d'execució, el mateix servidor iniciat amb `AF_ROLE=rte`: cadascun executa `ansible-playbook` per als [formularis d'Ansible](forms/ansible.html), amb les biblioteques de python i les col·leccions de la seva imatge, i envia la sortida i l'estat final al servidor a través d'un WebSocket, sense credencials de la base de dades (consulta [Com s'executa l'RTE](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runners per a plantilles i jobs: els [formularis d'AWX](forms/awx.html) llancen una plantilla de job o de workflow, els formularis de [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) i [Jenkins](forms/jenkins.html) llancen un dels seus jobs, i el servidor en segueix la sortida |
+| **MySQL / MariaDB** | Conté les tasques i la seva sortida, els usuaris, les credencials i les connexions; només el servidor hi llegeix i hi escriu |
+| **Carpeta persistent** | Conté `config.yaml`, els fitxers de formularis, els playbooks, els registres i les còpies de seguretat |
+| **Fonts de dades** | Emplenen els camps: [consultes a bases de dades](formfields/enum.html), [API REST](expressions/rest-apis.html), fitxers i [altres funcions](expressions/remote.html) |
+| **Magatzems de secrets** | Proporcionen l'usuari i la contrasenya d'una credencial en el moment d'usar-la, consulta [Magatzems de secrets](secret-stores/) |
+| **Repositoris git** | Mantenen els formularis, els playbooks i `config.yaml` sota control de versions |
+| **Proveïdors d'inici de sessió** | Inicien la sessió dels usuaris: [LDAP, Entra ID i OIDC](authentication/), a més dels usuaris locals |
+| **Canals de notificació** | Porten les [notificacions](forms/notifications.html) i les sol·licituds d'aprovació: [correu, Slack, Microsoft Teams, Telegram o un webhook](notification-channels.html) |
+| **Servidors syslog** | Reben el registre i la traça d'auditoria a mesura que s'escriuen, consulta [Syslog](production/logs.html#syslog) |
+| **Client MCP, xat** | Opcionals, tots dos desactivats per defecte: el [servidor MCP](mcp/) i l'[assistent de xat](chat/), que necessita un proveïdor de models |
+
+Per defecte, un contenidor executa alhora el servidor, l'aplicació web i la feina en segon pla, al costat d'un RTE. Per a diversos nodes d'aplicació darrere d'un
+balancejador de càrrega, un worker que executa la feina en segon pla i més RTE, consulta [Escalat](production/scaling.html).
+
+### Construït amb
+
+El servidor i la interfície web es basen en aquests components:
+
+| Part | Tecnologia |
+|---|---|
+| **Servidor** | Node.js i Express |
+| **Base de dades** | MySQL o MariaDB |
+| **Interfície web** | Vue 3, amb Bootstrap 5 i Font Awesome |
+
+---
+
+## Què passa quan llances un formulari
+
+Un llançament passa pels mateixos passos tant si ve del navegador com de l'[API REST](api/jobs.html):
+
+1. **Càrrega** : el servidor envia només els formularis que permeten els [rols](config/roles.html) de l'usuari, i avalua les expressions del servidor
+2. **Enviament** : el navegador converteix els valors dels camps en extravars i els envia amb `POST /api/v2/job`
+3. **Comprovació** : el servidor torna a carregar el formulari per als rols de l'usuari i, amb la [validació del llançament](launch-validation/) activada, comprova els valors
+4. **Registre** : la tasca es desa amb l'estat `running`, i el seu id s'afegeix a les extravars com a `__jobid__`
+5. **Aprovació** : un formulari amb un punt d'[`approval`](forms/approval.html) espera fins que un aprovador accepta la tasca
+6. **Credencials** : per a un playbook, l'aplicació (mai l'RTE) llegeix les credencials del formulari de la base de dades o d'un [magatzem de secrets](secret-stores/)
+7. **Execució** : la tasca va al seu runner, el que el formulari anomena amb `runner:` o el predeterminat del seu tipus. Per a un playbook, l'aplicació envia la tasca al seu
+   RTE pel WebSocket de l'RTE, amb les credencials segellades per a ell, i l'RTE executa `ansible-playbook` (consulta [Com s'executa l'RTE](rte/#how-the-rte-runs)),
+   i AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins executa una plantilla o un job. Un [workflow](workflows/) executa els seus nodes, cadascun com una
+   tasca pròpia al seu propi runner
+8. **Seguiment** : el servidor desa la sortida a la base de dades a mesura que arriba, enviada per l'RTE a través del seu socket en el cas d'un playbook, o llegida dels
+   altres runners. La pàgina del formulari torna a llegir la tasca cada dos segons, i la pàgina Tasques la segueix en directe a mesura que el servidor
+   anuncia cada canvi
+9. **Final** : la tasca rep el seu estat final, i les seves [`notifications`](forms/notifications.html) s'envien per correu i als seus
+   [canals de notificació](notification-channels.html) quan el formulari les demana
+
+---
+
+## On es desen les coses
+
+AnsibleForms desa el seu estat en dos llocs: la base de dades MySQL i la carpeta persistent. Fes còpia de seguretat de tots dos.
+
+### A la base de dades
+{: .no_toc }
+
+La base de dades, `AnsibleForms`, es crea en el primer inici (tret que `ALLOW_SCHEMA_CREATION` sigui `0`) i conté:
+
+* les tasques, les seves extravars i la seva sortida, les programacions i les tasques desades
+* els usuaris locals, els grups i els tokens d'API
+* les credencials, xifrades amb `ENCRYPTION_SECRET`, i les connexions als magatzems de secrets
+* els runners, els canals de notificació (inclòs el correu), els servidors syslog, i la configuració de LDAP, SSO, repositoris i assistent de xat
+* el registre d'auditoria
+
+### A la carpeta persistent
+{: .no_toc }
+
+És `/app/dist/persistent` a la imatge i `server/persistent` des del codi font; cada ruta té la seva pròpia [variable](customization/paths.html):
+
+| Ruta predeterminada | Variable | Contingut |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | Les categories, els rols i les constants |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | Els fitxers de formularis, `.yaml` o `.yml`, en subcarpetes si vols |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | Els playbooks dels formularis `ansible`, i el seu directori de treball |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Els clons dels repositoris git |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | Les còpies que fa el Dissenyador abans de desar |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | Les còpies de seguretat de la base de dades |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | Els fitxers pujats mitjançant camps `file` |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` i `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | El certificat i la clau, quan `HTTPS` és `1` |
+| `.env` | | Les variables d'entorn desades des de les pàgines de configuració (tret que `ALLOW_ENV_EDIT` sigui `0`) |
+
+La clau SSH generada és a [`HOME_PATH`](customization/paths.html#env_HOME_PATH), fora de la carpeta persistent per defecte.
diff --git a/i18n/ca/_introduction/prerequisites.md b/i18n/ca/_introduction/prerequisites.md
new file mode 100644
index 0000000..903b961
--- /dev/null
+++ b/i18n/ca/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Requisits previs
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Requisits previs
+{: .no_toc }
+
+El que necessites abans d'instal·lar AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Entorn d'execució
+
+AnsibleForms s'executa com a contenidor, com a serveis de systemd al mateix servidor o, per a qui el compila pel seu compte, com a aplicació Node.js:
+
+| Instal·lació | Necessites |
+|---|---|
+| [Instal·lador](installation/installer.html) | Linux en amd64 o arm64, `curl` o `wget` i `sha256sum`, i els requisits del motor on s'instal·la (a sota) |
+| [Nativa](installation/native.html) | Root, systemd i un Linux compatible (Ubuntu, Debian, RHEL i les seves derivades, SUSE); l'instal·lador instal·la la resta |
+| [Docker](installation/docker.html) | Docker o Podman, i un servidor MySQL propi |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose o podman-compose; el projecte també inicia MySQL |
+| [Kubernetes](installation/kubernetes.html) | Un clúster, Helm 3 i una StorageClass (o PersistentVolumes creats prèviament) |
+| [Des del codi font](installation/from-source.html) | Node.js 26 (com a mínim 24) amb npm, Git, i Ansible per al procés RTE que executa els playbooks |
+
+La imatge de l'aplicació, `ghcr.io/ansibleforms/ansibleforms`, conté Node.js i les eines que crida el servidor (git, ssh, el client de mariadb i
+ytt), però ni Python ni Ansible. Els playbooks s'executen en un RTE (runtime environment, entorn d'execució), un segon contenidor de
+`ghcr.io/ansibleforms/ansibleforms-rte-full`, o d'una imatge que construeixes sobre `ansibleforms-rte-core` (consulta [Escalat](rte/)).
+Els formularis que només llancen plantilles a AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins no necessiten cap RTE.
+
+---
+
+## Base de dades
+
+AnsibleForms desa les seves tasques, usuaris, credencials i connexions a MySQL 8 o posterior, o a MariaDB.
+
+En el primer inici crea ell mateix l'esquema `AnsibleForms`. Dona-li un usuari de base de dades propi, amb permisos només sobre aquest esquema,
+no root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+És tot el que necessita: crea i actualitza l'esquema, fa les seves còpies de seguretat i, amb diversos workers, tanca la sessió d'un que ha caigut.
+La pàgina **Estat** i el registre avisen quan l'usuari té permisos sobre totes les bases de dades. Els nodes d'aplicació i els workers es connecten amb aquest
+usuari. Un RTE en un mode de socket (outbound o inbound, consulta [Modes](rte/modes.html)) no té credencials de la base de dades: només un en mode
+database, obsolet des de la 7.3.0, també s'hi connecta. Per crear l'esquema tu mateix, posa [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) a `0`.
+El projecte de Docker Compose i el chart de Helm (que fa servir `mysql:8.4`) inicien una base de dades per tu.
+
+---
+
+## Dimensionament
+
+No hi ha requisits mesurats: la càrrega depèn sobretot de quantes tasques s'executen alhora i de quanta sortida escriuen.
+Els recursos predeterminats del chart de Helm són un punt de partida raonable per a un equip petit:
+
+| Component | Requests | Limits | Volum |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB de memòria | 4 CPU, 4 GiB de memòria | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB de memòria | 2 CPU, 2 GiB de memòria | 10 GiB |
+
+El contenidor de l'aplicació no executa cap playbook. Cada playbook és un procés `ansible-playbook`, amb els seus forks, en un RTE: dimensiona la CPU i la
+memòria de cada RTE per als playbooks que executa alhora, com a màxim [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (`10` per defecte), i executa més
+RTE per executar-ne més. Les tasques que s'executen a AWX, AAP, Ascender o als altres runners de plantilles costen poc a AnsibleForms.
+
+La sortida de les tasques es conserva a la base de dades per sempre per defecte. Defineix [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+en una instància amb molta activitat per evitar que la base de dades creixi sense límit.
+
+---
+
+## Xarxa
+
+L'aplicació i cada RTE escolten en un port propi, i obren connexions sortints cap als sistemes que fan servir els teus formularis i la teva configuració.
+
+### Entrant
+{: .no_toc }
+
+El servidor escolta al port `8000` ([`PORT`](customization/server.html#env_PORT)), per HTTP o, amb
+[`HTTPS`](customization/server.html#env_HTTPS) a `1`, per HTTPS. El projecte de Docker Compose el publica al port 443,
+i el chart de Helm l'exposa mitjançant un service o un ingress. Un RTE també escolta al seu propi `PORT`, però només el crida l'aplicació:
+mantén-lo fora de la xarxa pública. Un RTE outbound no necessita cap port entrant: és ell qui truca a l'aplicació al port de l'aplicació.
+
+### Sortint
+{: .no_toc }
+
+Obre les connexions des d'AnsibleForms cap als sistemes que fas servir:
+
+| Destinació | S'usa per a |
+|---|---|
+| MySQL / MariaDB | La base de dades d'AnsibleForms (`DB_HOST`, `DB_PORT`, per defecte `3306`) |
+| L'RTE | Trucar a un RTE inbound a l'adreça del seu runner a través d'un WebSocket, o cridar-ne un en mode database al seu [`RTE_URL`](customization/server.html#env_RTE_URL), que després es connecta ell mateix a MySQL; un RTE outbound és el que truca a l'aplicació (consulta [Modes](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Llançar i seguir plantilles i jobs als [runners](runners.html), a través de la seva API HTTP(S) |
+| Els hosts gestionats | Els playbooks s'hi connecten des de l'RTE, per exemple per SSH o WinRM |
+| LDAP, Entra ID, OIDC | Iniciar sessió amb comptes de directori o d'inici de sessió únic |
+| Servidors git | Clonar repositoris i obtenir-ne els canvis, per HTTPS o SSH |
+| API REST i bases de dades | Les fonts de dades de les expressions i les consultes dels teus formularis |
+| HashiCorp Vault, CyberArk | Llegir credencials d'un [magatzem de secrets](secret-stores/) |
+| Servidors de correu, Slack, Teams, Telegram, webhooks | Notificacions de tasques i sol·licituds d'aprovació, mitjançant els [canals de notificació](notification-channels.html) |
+| Proveïdor de models | L'[assistent de xat](chat/), només quan està activat |
+
+Per limitar a quins hosts poden cridar les funcions REST de les expressions, consulta
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) i
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Navegador
+
+L'aplicació web està feta per a navegadors actuals: Chrome o Edge 111, Firefox 114, Safari 16.4 o posteriors.
+Els navegadors més antics no són compatibles.
+
+---
+
+## Escalat
+
+Per defecte, un contenidor d'AnsibleForms executa alhora l'aplicació web i la feina en segon pla, al costat d'un RTE.
+
+Per atendre més usuaris, executa diversos nodes d'aplicació darrere d'un balancejador de càrrega (`AF_ROLE=app`) al costat d'un worker (`AF_ROLE=worker`), que executa les
+programacions, les còpies de seguretat i la resta de la feina en segon pla; només treballa un worker alhora, i un segon espera per prendre-li el relleu. Comparteixen
+la base de dades, la carpeta persistent, `ACCESS_TOKEN_SECRET` i `ENCRYPTION_SECRET`. Consulta [Escalat](production/scaling.html). Executa més
+RTE per executar més playbooks alhora: consulta [Diversos RTE](rte/several.html).
diff --git a/i18n/ca/_introduction/what-is-ansibleforms.md b/i18n/ca/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..784c2b9
--- /dev/null
+++ b/i18n/ca/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Què és AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Què és AnsibleForms
+{: .no_toc }
+
+Formularis d'autoservei davant d'Ansible i AWX, i quan els necessites
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Què fa
+
+AnsibleForms posa un formulari web davant d'un playbook, un workflow, o una plantilla o un job a AWX, AAP, Ascender, Semaphore, Rundeck
+o Jenkins, perquè la gent pugui executar automatitzacions sense la línia d'ordres.
+
+Un formulari recull les dades, les comprova, les converteix en extravars i llança la tasca. Les dades d'un formulari poden venir de bases de dades,
+API REST, fitxers i altres camps, i cada llançament queda registrat a l'historial de tasques amb la seva sortida.
+
+---
+
+## Usos habituals
+
+Els equips fan servir AnsibleForms per posar l'automatització rutinària en mans de qui la sol·licita:
+
+* **Sol·licituds d'autoservei** : una màquina virtual, un volum d'emmagatzematge, un recurs compartit o un compte d'usuari, emplenats per qui els sol·licita
+* **Operacions protegides** : accions amb punts d'aprovació, perquè una segona persona doni el vistiplau abans que s'executi la tasca
+* **Opcions basades en dades** : desplegables emplenats des d'una CMDB, una base de dades o una API REST, encadenats d'un camp al següent
+* **Tasques recurrents** : formularis executats més tard o segons una programació cron, amb les mateixes dades validades cada vegada
+* **Automatització per a eines i agents** : l'API REST, el servidor MCP i l'assistent de xat llancen els mateixos formularis
+
+---
+
+## AnsibleForms o enquestes d'AWX?
+
+AWX, AAP i Ascender tenen les seves pròpies enquestes (surveys). Quina encaixa millor depèn del que necessitin les persones que llancen les tasques.
+
+Una **enquesta** és suficient quan:
+
+* les preguntes són fixes: text, números, contrasenyes i opcions d'una llista estàtica
+* els usuaris ja treballen a AWX, AAP o Ascender, i els seus permisos els serveixen
+* no vols executar i mantenir una altra aplicació i una altra base de dades
+
+**AnsibleForms** ajuda quan:
+
+* les opcions vénen d'un altre lloc: una base de dades, una API REST, un fitxer o un altre camp (desplegables encadenats)
+* les dades necessiten validació, estructura (llistes, objectes niats) o valors calculats abans d'arribar al playbook
+* les tasques necessiten punts d'aprovació, programació o un workflow que encadeni playbooks, plantilles i aprovacions des d'un sol formulari
+* els usuaris no haurien de veure AWX en absolut, o també executes playbooks sense AWX
+
+AnsibleForms llança plantilles d'AWX, AAP i Ascender, així que tots dos treballen junts: els formularis recullen les dades i les donen forma, i
+AWX continua executant les tasques.
+
+---
+
+## Passos següents
+
+La resta d'aquesta secció explica les peces abans d'instal·lar:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Com funciona](how-it-works.html) | L'arquitectura, els passos d'un llançament i on es desen les dades |
+| [Recorregut per la interfície](gui/) | Captures de totes les pantalles, des de l'inici de sessió fins a les pàgines d'administració |
+| [Conceptes](concepts.html) | Els termes que es fan servir en aquesta documentació |
+| [Requisits previs](prerequisites.html) | El que necessites abans d'instal·lar |
diff --git a/i18n/ca/_reference/faq.md b/i18n/ca/_reference/faq.md
new file mode 100644
index 0000000..f9b7a26
--- /dev/null
+++ b/i18n/ca/_reference/faq.md
@@ -0,0 +1,1279 @@
+---
+layout: default
+title: PMF
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Preguntes més freqüents
+{: .no_toc }
+
+Preguntes i respostes habituals sobre AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Primers passos
+
+### Topologia del desplegament: un contenidor o diversos nodes
+
+Per defecte, un contenidor d'AnsibleForms executa l'aplicació web i la feina en segon pla en un sol procés, al costat d'un contenidor d'RTE que
+executa els playbooks. Executa'l amb una política de reinici (per exemple `restart: unless-stopped` a Docker), i fes còpia de seguretat tant de la base de dades com
+del volum persistent.
+
+Per executar diverses rèpliques darrere d'un balancejador de càrrega, divideix el procés amb `AF_ROLE`:
+
+- els nodes `app` serveixen la interfície web i l'API: executa'n tants com vulguis, cadascun amb el mateix `ACCESS_TOKEN_SECRET`
+- un `worker` executa la feina en segon pla: l'esquema i les seves actualitzacions, el config seed, les programacions, la còpia de seguretat nocturna, les
+  sincronitzacions de repositoris i les neteges. Només treballa un worker alhora, amb un bloqueig a la base de dades; un segon espera i pren el relleu quan el primer s'atura
+- els contenidors `rte` executen els playbooks: executa'n més per executar més playbooks alhora
+
+Els nodes d'aplicació i el worker comparteixen la base de dades, el volum persistent i `ENCRYPTION_SECRET`. Un RTE en un mode de socket (outbound o
+inbound, consulta [Modes](rte/modes.html)) no necessita ni la base de dades ni `ENCRYPTION_SECRET`. L'assistent de xat necessita sessions persistents (sticky sessions), i
+cada node manté el seu propi registre. Consulta [Escalat](production/scaling.html) i la configuració
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Gestió de formularis en diversos repositoris
+
+Els formularis de tots els repositoris git amb **Utilitzar per als formularis ?** activat es fusionen automàticament; si hi ha noms de formulari duplicats, guanya
+el primer i es registra un avís. Mantén `config.yaml` en un sol repositori. Consulta [Repositoris git](repositories/).
+
+### Sobre els repositoris
+
+AnsibleForms clona i fa pull dels repositoris git sota la ruta de repositoris (`REPO_PATH`), que es gestionen a **Configuració > Repositoris**.
+Els interruptors de cada repositori defineixen què conté: configuració, formularis, playbooks o fitxers de variables. Consulta [Repositoris git](repositories/).
+
+### Validació a VS Code dels fitxers de formulari
+
+Afegeix una capçalera d'esquema als fitxers YAML dels teus formularis per tenir validació en directe i autocompletat a VS Code.
+
+Instal·la l'[extensió YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) i afegeix aquest comentari com a **primera línia** de qualsevol fitxer de formulari:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Això funciona tant per als fitxers d'un sol formulari (un diccionari YAML) com per als de diversos formularis (una llista YAML):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code ressalta les propietats desconegudes, els camps obligatoris que falten i els tipus incorrectes mentre escrius.
+
+---
+
+## Gestió de tasques
+
+### Rellançar una tasca amb les dades emplenades
+
+El botó de rellançar obre el formulari emplenat amb els valors de la tasca anterior; els camps de contrasenya mai es desen.
+Necessita l'opció de rol `allowJobRelaunch`, i un formulari el pot desactivar amb `allowRelaunch: false`. Consulta [Rellançar una tasca](jobs/actions.html#relaunch-a-job).
+
+### Fitxer de registre de la tasca
+
+Segueix el progrés mitjançant un fitxer de registre propi de la tasca (v6.1.2).
+
+AnsibleForms pot mostrar un **fitxer de registre propi de la tasca** al costat de la sortida d'Ansible. Això et permet seguir el progrés de mòduls personalitzats de llarga durada que altrament no donarien cap senyal visible durant l'execució.
+
+{: .note }
+> Aquesta funció només funciona per als playbooks que s'executen en un RTE. Les plantilles i els jobs a AWX, AAP, Ascender, Semaphore, Rundeck o
+> Jenkins no tenen fitxer de registre.
+
+**Com funciona:**
+- Durant l'execució d'una tasca, l'RTE vigila un fitxer de registre en una ruta coneguda dins de la carpeta del playbook
+- Cada dos segons, quan el fitxer ha canviat, l'RTE en copia el contingut a la tasca, i una vegada més quan el playbook acaba
+- El fitxer de registre es mostra en una secció **Fitxer de registre** de la sortida de la tasca, numerada com les línies de la sortida : la marca de temps i el nivell (ERROR, WARNING, INFO, DEBUG) d'una línia del registre es llegeixen i s'acoloreixen com els de la sortida, i s'admeten els colors ANSI
+
+**Convenció de la ruta del fitxer de registre:**
+
+El fitxer de registre s'ha d'escriure en aquesta ruta:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms passa `__jobid__` automàticament**, així que pots construir la ruta al teu playbook sense cap configuració addicional:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Passa aquesta variable a qualsevol rol o mòdul personalitzat que hagi d'escriure el progrés al fitxer.
+
+**Responsabilitats del desenvolupador del playbook / mòdul:**
+- **Crear** el fitxer de registre (i el seu directori `.joblogs/`) a l'inici de l'operació
+- **Escriure** missatges de progrés útils a mesura que avança l'operació
+
+L'RTE suprimeix el fitxer un cop el playbook acaba i el darrer contingut s'ha desat a la tasca.
+
+**S'admeten els codis de color ANSI.**  
+Els codis d'escapament ANSI estàndard (per exemple, `\033[92m` per al verd i `\033[91m` per al vermell) dels teus missatges de registre es mostren com a colors a la interfície, així que els estats d'èxit, avís i error es distingeixen d'un cop d'ull.
+
+**Cas d'ús típic:**  
+Un mòdul d'Ansible personalitzat en Python que fa una llarga seqüència de crides a API o d'operacions de dades (per exemple, un workflow de DR amb SnapMirror) pot afegir una línia per pas al fitxer de registre. Un operador que segueix la tasca a AnsibleForms veu aleshores el progrés en directe a la secció Fitxer de registre mentre la pàgina de la tasca la segueix.
+
+### Jobid
+
+Passar l'ID de la tasca actual.
+
+AnsibleForms envia automàticament l'ID de la tasca actual a les extravars com a `__jobid__`; no cal cap configuració.
+
+### Informació de l'usuari
+
+Passar l'usuari actual.
+
+AnsibleForms envia automàticament la informació de l'usuari a les extravars com a `ansibleforms_user`; no cal cap configuració.
+
+Pots triar quanta s'envia. `EXTRAVARS_USER_FIELDS` accepta una llista de claus de primer nivell separades per comes
+(`username,email,type`), o `none` per no enviar res; un formulari la pot substituir amb la seva pròpia propietat `userExtravars`.
+El valor predeterminat és l'objecte complet, com abans. El `__user__` del costat del formulari que es descriu a continuació ve del token d'inici de sessió i mai no es veu afectat.
+
+### Informació de l'usuari al formulari
+
+Accedir a la informació de l'usuari actual al formulari (v4.0.2).
+
+El camp `__user__` s'afegeix automàticament al formulari i es pot referenciar a les expressions:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Camps de formulari
+
+### Desplegables encadenats
+
+Crear desplegables encadenats.
+
+Els camps `enum` (desplegables) poden contenir marcadors a la seva propietat `query` o `expression`, amb el format `$(another_field)` o `$(another_field[0].name)`.  
+Tan bon punt canvia el camp referenciat, el camp que el referencia es torna a avaluar, cosa que dona desplegables dinàmics i encadenats.  
+L'aplicació web client torna a avaluar els camps cada 100 ms; amb els processadors actuals i el motor Chromium, això dona una experiència fluida.
+
+{: .note }
+> Una referència a un altre camp enum retorna els valors seleccionats, **no** la llista completa del desplegable. Fes servir la propietat `placeholderColumn` o la notació amb punts com ara `$(city.name)`.  
+> **Novetat a la v4.0.20**: posar placeholderColumn a "*" retorna el registre complet en lloc d'una sola columna.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Marcadors de camp
+
+Fer referència al valor d'un altre camp.
+
+Els marcadors són referències a altres camps del formulari.  
+Un marcador sempre té el format `$(reference)`, i tant les expressions com les consultes poden contenir marcadors.  
+Un marcador que apunta a un camp simple (text, número, contrasenya) conté el valor d'aquest camp.  
+Un marcador que apunta a un camp enum basat en objectes ha de fer servir la propietat `placeholderColumn` o la notació amb punts com ara `$(city.name)`.  
+Un marcador que apunta a un camp d'expressió retorna l'objecte complet, o pots fer servir una referència avançada, semblant a JavaScript, com ara `$(myarray[0].name)`.
+
+{: .important }
+> El marcador se substitueix **abans** que s'avaluï l'expressió. Si esperes que el resultat sigui una cadena, l'has d'envoltar amb cometes.  
+> **Novetat a la v4.0.20**: posar placeholderColumn a "*" retorna el registre complet en lloc d'una sola columna.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Ocultar un camp
+
+Ocultar un camp.
+
+Oculta un camp amb la propietat de camp `hide`, o mostra'l i oculta'l dinàmicament amb les propietats de camp `dependencies` i `dependencyFn`.
+
+### Agrupar camps
+
+Agrupar camps en un bloc.
+
+Fes servir la propietat de camp `group`. Els camps amb el mateix nom de grup s'agrupen en un bloc.
+
+### Validació de camps
+
+Validar un camp.
+
+Fes servir les propietats de validació dels camps, com ara `regex`, `minValue` i `notIn`.
+
+### Valor predeterminat en un enum
+
+Valor predeterminat d'un enum.
+
+La propietat de camp `default` defineix un valor predeterminat, i als camps `enum` pots fer servir valors com ara `__auto__` per seleccionar automàticament el primer element.
+
+Per a un valor predeterminat dinàmic basat en una expressió, mou l'element predeterminat al principi de la llista, com a l'exemple següent.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Valor predeterminat amb una expressió
+
+Valor predeterminat d'una expressió.
+
+Per als camps de text, número o data, la propietat `default` defineix un valor predeterminat estàtic.
+
+Per fer que el valor predeterminat sigui dinàmic, basat en una expressió, fes servir una d'aquestes dues propietats:
+* `editable`: fes servir la propietat editable per fer editable un camp d'expressió
+* `evalDefault`: fes servir la propietat evalDefault per avaluar el valor predeterminat com una expressió
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Assistent (wizard) i workflows
+
+### Quina diferència hi ha entre un wizard i un workflow?
+
+Un **wizard** i un **workflow** tots dos es presenten en passos, però actuen en capes diferents i es poden combinar.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Capa** | Execució | Formulari / interfície |
+| **Què divideix** | La tasca en nodes que s'executen l'un darrere l'altre, o en paral·lel | L'entrada d'un formulari en diverses pàgines |
+| **Resultat** | 1 tasca de workflow, amb una tasca per node (cadascuna amb el seu propi playbook o plantilla) | 1 tasca s'executa al final |
+| **`type` del formulari** | Ha de ser `workflow` | Funciona amb tots els tipus de formulari excepte `subform` |
+| **Es defineix amb** | Un [fitxer de workflow](workflows/file.html) del dissenyador (`workflow:`) | Una llista de referències a [subforms](forms/subform.html) (`wizard:`) |
+| **Fes-lo servir quan** | "Fes A, després B, després C com a tasques separades" | "El meu formulari té massa camps per a una sola pàgina" |
+
+**Idea clau:** un workflow tracta de *què s'executa i en quin ordre*; `wizard` tracta de *com emplena el formulari l'usuari*.
+
+{: .note }
+> El tipus de formulari `multistep`, amb els seus `steps`, feia la part d'execució abans de la 7. És obsolet des de la 7 i s'elimina a la
+> 8: un workflow fa tot el que fa un multistep, consulta [Formularis de diversos passos](forms/multistep.html).
+
+#### Només workflow
+{: .no_toc }
+
+Un formulari `type: workflow` executa un dels workflows del dissenyador. L'usuari emplena una sola pàgina de camps i prem Envia,
+i el workflow executa els seus nodes, cadascun amb els valors del formulari com a extra vars:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Només wizard
+{: .no_toc }
+
+Un bloc `wizard:` en un formulari reparteix la recollida de dades en diverses pàgines. Al final només s'executa **una** tasca: les extravars fusionades de totes les pàgines s'envien a un sol playbook, plantilla o workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+S'afegeix automàticament una pàgina de revisió de només lectura com a darrera pàgina del wizard; no la declares al YAML.
+
+#### Combinats (wizard sobre un workflow)
+{: .no_toc }
+
+Un wizard es pot posar a sobre d'un formulari de workflow. L'usuari emplena les pàgines del wizard i prem Envia, i **aleshores**
+s'inicia el workflow. Fent coincidir el `defaultModel` d'un pas del wizard amb l'
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) d'un node, pots encaminar **una pàgina del wizard a un node**:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+I el workflow `provision-host`, en un fitxer de workflow del dissenyador:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` és una cerca d'un sol nivell, així que fes servir un nom pla a `defaultModel` (per exemple, `defaultModel: basics`, no `defaultModel: input.basics`) quan vulguis que coincideixin.
+
+Consulta la [pàgina del wizard](forms/wizard.html) per a la referència completa de propietats.
+
+### Com mostro o omet passos del wizard segons una condició?
+
+Fes servir `when:` per **ocultar** completament un pas, o `optional: true` per deixar que l'usuari **se salti** un pas visible. Les dues opcions són independents i en general no s'han de combinar.
+
+#### `when:`: visibilitat condicional
+{: .no_toc }
+
+El pas s'oculta quan l'expressió s'avalua com un valor fals. L'usuari no el veu mai, i els seus valors no es recullen. L'expressió pot llegir passos anteriors mitjançant `__parent__.<stepname>.<field>`:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Només es mostra la pàgina que correspon al `kind` triat. Els passos posteriors a un d'ocult es tornen a numerar automàticament.
+
+#### `optional: true`: permetre saltar-se un pas visible
+{: .no_toc }
+
+El pas **sempre es mostra** a l'indicador de passos, però l'usuari pot prémer **Següent** sense emplenar-lo, i **Envia** es permet encara que la pàgina no s'hagi visitat ni completat mai:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+L'usuari pot obrir la pàgina Advanced, deixar-la buida, prémer Següent i anar directament a la pàgina de revisió.
+
+{: .note }
+> `when:` controla la *visibilitat*; `optional:` controla *si la pàgina s'ha de completar*. No els combinis: per fer desaparèixer una pàgina, fes servir `when:`; per mantenir-la visible però opcional, fes servir `optional:`.
+
+### Com faig referència a valors d'un pas anterior del wizard?
+
+Fes servir `$(__parent__.<stepname>.<field>)` dins de qualsevol camp d'un pas posterior.
+
+El `name` d'un pas del wizard (per defecte el nom del seu `subform`) és l'espai de noms sota el qual s'exposen els seus valors als passos posteriors:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+És el mateix mecanisme `__parent__` que fan servir els subforms de `list` i `yaml`; consulta [Com accedeixo a les dades del formulari pare dins d'un subform?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Seguretat i credencials
+
+### Credencials
+
+Passar credencials.
+
+Les credencials es poden passar de diverses maneres:
+* amb la propietat de camp `asCredential`  
+* amb la propietat de formulari `credentials` (parells clau-valor)
+* amb una extravar anomenada `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Recuperar una contrasenya d'administrador perduda
+
+Si has perdut la contrasenya del compte local `admin` i no hi ha cap altre usuari administrador disponible, fes servir l'opció de recuperació `REINIT_ADMIN`. **No és una manera d'eludir l'autenticació en temps d'execució**: només força un restabliment puntual del compte d'administrador local en iniciar-se, i després l'autenticació funciona amb normalitat.
+
+**Com funciona**
+
+Quan `REINIT_ADMIN=1` està definit en iniciar-se, AnsibleForms:
+
+1. Assegura que existeix el grup `admins` (i el crea si falta).
+2. Busca l'usuari administrador local (nom d'usuari predeterminat `admin`, que es pot canviar amb `ADMIN_USERNAME`).
+3. Si existeix, en restableix la contrasenya amb el valor d'`ADMIN_PASSWORD` i el torna a afegir al grup `admins`.
+4. Si no existeix, el crea (com en una instal·lació nova).
+5. Registra l'acció de manera destacada perquè sigui visible als registres.
+
+**Passos**
+
+1. Atura AnsibleForms.
+2. Defineix les variables d'entorn (fes servir una contrasenya robusta):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   A Docker Compose, afegeix-les al bloc `environment:` del servei d'AnsibleForms.
+3. Inicia AnsibleForms i vigila als registres una línia com ara:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Inicia sessió amb `admin` / `YourNewStrongPasswordHere`.
+5. **Treu `REINIT_ADMIN` (o torna'l a posar a `0`)** i reinicia, perquè els reinicis futurs no tornin a restablir la contrasenya de l'administrador.
+
+**Notes**
+
+- Si t'havies quedat fora perquè LDAP era l'únic mètode d'inici de sessió configurat i fallava, el compte local `admin` recuperat sempre fa servir l'autenticació de la base de dades local, que és suficient per iniciar sessió i arreglar LDAP.
+- S'ha eliminat l'antiga variable d'entorn `ENABLE_BYPASS`. Permetia iniciar sessió com a administrador amb qualsevol contrasenya i era insegur deixar-la activada. `REINIT_ADMIN` només restableix la contrasenya; després s'aplica l'autenticació normal.
+- `REINIT_ADMIN` no invalida les sessions ni els tokens existents; només canvien el hash de la contrasenya i la pertinença al grup.
+
+### Restringir les destinacions dels helpers REST (llistes de permesos i denegats)
+
+Els helpers `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` i `fn.fnRestJwtSecure` es poden cridar des de les propietats `expression` dels formularis per obtenir dades per HTTP. Per defecte, els autors d'expressions poden apuntar a **qualsevol** URL a què pugui arribar l'host d'AnsibleForms, cosa que potser vols limitar en una xarxa sensible.
+
+Dues variables d'entorn proporcionen una llista de permesos i una llista de denegats:
+
+| Variable | Comportament |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Noms d'host o CIDR separats per comes. Quan està definida, **només** es permeten aquestes destinacions. |
+| `REST_DENIED_HOSTS` | Noms d'host o CIDR separats per comes. Sempre es bloquegen. Té prioritat sobre la llista de permesos. |
+
+Els noms d'host es comparen amb l'host de l'URL sense distingir majúscules i minúscules. Els CIDR es comparen amb cada IP a què es resol l'host, així que `10.0.0.0/8` bloqueja qualsevol nom DNS que es resolgui dins del rang privat.
+
+**Exemples:**
+
+La primera línia només permet dos hosts; la segona bloqueja destinacions concretes:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Aquesta protecció només protegeix el procés Node.js d'AnsibleForms.** Un cop s'executa un playbook, el mateix Ansible pot arribar a qualsevol cosa des de l'host, fora del control d'AnsibleForms. Fes servir aquestes llistes per evitar que els autors de formularis converteixin les expressions en un proxy cap a serveis de metadades o interfícies internes; no t'hi refiïs com a tallafoc de xarxa.
+
+Des de la 7.3.0 els helpers REST comproven el certificat TLS de l'endpoint, com fan totes les altres connexions, i desisteixen després de
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (`60` per defecte). Confia en una CA privada amb
+`NODE_EXTRA_CA_CERTS`, o posa [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) a `1` només per a endpoints amb un
+certificat autosignat.
+
+### Integració amb HashiCorp Vault
+
+Les credencials poden llegir el seu usuari i contrasenya de HashiCorp Vault, configurat com a
+**magatzem de secrets**. Consulta [Magatzems de secrets](secret-stores). Les variables d'entorn `VAULT_*`
+de versions anteriors s'importen una vegada com el magatzem `vault` en el primer inici de la 7.x.
+
+Per a secrets que només es fan servir dins d'un playbook, també pots fer servir el plugin de lookup `community.hashi_vault`,
+que llegeix directament de Vault i passa per alt AnsibleForms.
+
+---
+
+## Integració
+
+### Consultar AWX/Tower/AAP
+
+Consultar informació d'AWX o d'Ansible Automation Platform.
+
+Per emplenar desplegables amb dades d'AWX o Tower, fes servir `fn.fnRestBasic` o `fn.fnRestJwtSecure`. Des de la 7.3.0 aquests helpers comproven
+el certificat de l'adreça d'AWX: amb un d'autosignat, confia en la seva CA amb `NODE_EXTRA_CA_CERTS`, o posa
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) a `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Personalització
+
+### Personalització
+
+Personalitzar AnsibleForms.
+
+AnsibleForms és una aplicació web. Quan l'executes de manera nativa amb Node.js, en pots substituir o canviar els fitxers.  
+Tanmateix, la manera recomanada és executar-la com una imatge de Docker i afegir-hi muntatges de volums o de fitxers. Els projectes de Docker Compose ja munten directoris per mantenir persistents la base de dades, els playbooks, els registres, els certificats i les claus SSH, i pots afegir-hi més muntatges. Un logotip propi es puja a la pàgina de configuració **Logotip**.  
+El fitxer `custom.js` conté les teves pròpies funcions de JavaScript per fer-les servir a les expressions. Les funcions integrades fan servir el prefix `fn.` (per exemple, fn.fnRestBasic); les funcions personalitzades fan servir el prefix `fnc.`.  
+De la mateixa manera, pots afegir les teves pròpies definicions de jq al fitxer `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### Activar YTT
+
+Activar ytt.
+
+Per fer servir ytt, defineix `USE_YTT=1`.  
+Per a més informació sobre ytt, consulta https://carvel.dev/ytt/.
+
+{: .important }  
+> Aquesta funció no s'ha provat a fons, i no s'ha rebut cap comentari des que es va afegir com a millora.  
+> Quan facis servir ytt, has de desactivar el dissenyador: el dissenyador converteix els fitxers YAML a JSON intermedi i elimina la sintaxi de ytt (que consisteix en comentaris YAML).
+
+Ha d'existir un directori `lib` al directori arrel; s'inclou automàticament a la crida de ytt.
+Es poden proporcionar dades globalment definint variables d'entorn amb prefix:  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Alternativament, proporciona fitxers de dades de biblioteca:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**La biblioteca `demo` ha d'existir al context de ytt (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+Aleshores es poden fer servir les dades carregades:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Control d'accés
+
+### Com restringeixo el que poden fer els usuaris (opcions de rol)?
+
+A més de restringir quins formularis pot veure un rol, les `options` d'un rol activen o desactiven funcions de la interfície per als seus membres.
+Consulta [Opcions de rol](config/roles.html#role-options) per a cada opció, el seu valor predeterminat i com es combinen les opcions entre rols.
+
+### Com implemento una lògica RBAC pròpia als meus playbooks o formularis?
+
+La identitat de l'usuari està disponible tant al frontend com al backend a cada execució.
+
+A cada enviament d'un formulari, AnsibleForms injecta automàticament la identitat completa de l'usuari actual a les extravars que s'envien a Ansible:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+El teu playbook o qualsevol mòdul d'Ansible personalitzat pot, per tant, fer servir `ansibleforms_user` directament per a decisions detallades, per exemple per permetre només a certs grups modificar l'inventari de producció, o per escriure una traça d'auditoria amb el nom d'usuari de qui l'envia.
+
+Al **frontend**, el mateix objecte està disponible a través del camp especial `__user__`:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Patrons habituals:**
+
+La identitat de l'usuari admet patrons com els següents:
+
+- **Creuar dades amb un fitxer de configuració RBAC o una base de dades**: carrega un fitxer YAML o JSON (amb `fn.fnReadYamlFile` o una expressió) que relacioni grups amb recursos permesos, i després filtra per `$(__user__.groups)`
+- **Traça d'auditoria**: passa `ansibleforms_user.username` com a variable extra per registrar qui ha llançat la tasca
+- **Valors de camp dinàmics**: mostra un conjunt diferent d'opcions d'enum, emplena camps per avançat o oculta seccions segons els grups o els rols de l'usuari
+- **Autorització al costat del playbook**: comprova que `ansibleforms_user.groups` conté un grup obligatori abans que el playbook continuï, com a comprovació de defensa en profunditat independent de la llista `roles` del formulari
+
+{: .note }
+> L'objecte anterior és el que s'envia per defecte. Si la instància defineix `EXTRAVARS_USER_FIELDS`,
+> o el formulari defineix `userExtravars`, només s'envien les claus que s'hi indiquen, així que un playbook que
+> comprova `ansibleforms_user.groups` necessita que `groups` en sigui una. El camp `__user__`
+> del frontend ve del token d'inici de sessió i cap d'aquests paràmetres no el retalla mai.
+
+---
+
+## Programació de tasques
+
+### Com programo un formulari perquè s'executi automàticament?
+
+Obre el desplegable que hi ha al costat d'**Envia** i tria **Programa (recurrent)** o **Executa més tard (una vegada)**; necessiten les opcions de rol
+`allowScheduledJobs` (de nivell d'administrador) i `allowPlannedJobs`. Consulta [Programacions](jobs/schedules.html).
+
+### Quines expressions cron puc fer servir?
+
+Una programació recurrent accepta una expressió cron estàndard de 5 camps (minut, hora, dia del mes, mes, dia de la setmana).
+
+| Expressió | S'executa |
+|---|---|
+| `*/15 * * * *` | Cada 15 minuts |
+| `0 * * * *` | Cada hora, en punt |
+| `0 */6 * * *` | Cada 6 hores, a les 00:00, 06:00, 12:00 i 18:00 |
+| `0 2 * * *` | Cada dia a les 02:00 |
+| `30 7 * * 1-5` | De dilluns a divendres a les 07:30 |
+| `0 8 * * MON` | Cada dilluns a les 08:00 (s'accepten els noms dels dies i dels mesos) |
+| `0 0 1 * *` | A mitjanit el primer dia de cada mes |
+| `0 22 L * *` | A les 22:00 el darrer dia de cada mes |
+| `0 6 * * 1#1` | A les 06:00 el primer dilluns de cada mes |
+| `*/30 * * * * *` | Cada 30 segons (un sisè camp opcional al davant són els segons) |
+
+Quan es defineixen tant el dia del mes com el dia de la setmana, la programació s'executa quan coincideix qualsevol dels dos: `0 0 13 * 5` s'executa
+el dia 13 i cada divendres. El servidor rebutja una expressió que no pot executar, o una que no es pot donar mai (`0 0 30 2 *`).
+
+A la pàgina **Programacions**, l'editor de cron descriu l'expressió i en previsualitza les properes execucions. No accepta àlies
+com ara `@daily`, el comodí `?` ni el modificador `W` (dia laborable més proper), així que limita't a les formes de la taula.
+
+{: .note }
+> **Zona horària** Les programacions cron s'executen a la zona horària del servidor, definida amb [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (per defecte `UTC`), no a la zona horària del teu perfil o del teu navegador. `0 2 * * *` amb `LOG_TZ=Europe/Madrid` s'executa a les 02:00
+> hora de Madrid tot l'any, seguint l'horari d'estiu. L'editor de cron previsualitza les properes execucions en aquesta mateixa zona. Les programacions de pull
+> dels repositoris fan servir la mateixa zona.
+
+---
+
+## Desar i carregar dades de formularis
+
+### Com deso i torno a carregar les dades d'un formulari sense executar cap tasca?
+
+Tria **Desa** al desplegable que hi ha al costat d'**Envia** per desar els valors dels camps, i després **Carrega des de les desades** per restaurar-los més endavant.
+Els camps de contrasenya mai es desen. Necessita l'opció de rol `allowStoredJobs`. Consulta [Tasques desades](jobs/stored-jobs.html).
+
+---
+
+## Formularis niats i camps estructurats
+
+### Com recullo dades estructurades o repetides en un formulari?
+
+Fes servir camps `list` i `yaml` amb subforms (6.2.0+).
+
+Per recollir dades estructurades complexes, com ara una llista de servidors, un conjunt d'interfícies de xarxa o un sol objecte niat, fes servir el tipus de camp `list` o `yaml` juntament amb un `subform`.
+
+Un **subform** és un fragment de formulari reutilitzable (definit amb `type: subform`) que mai es mostra com un mosaic independent. Només existeix perquè el referenciïn camps d'altres formularis. Consulta la [documentació de subform](forms/subform.html) per a la referència completa.
+
+**Recollir una llista de files estructurades: camp `list`:**
+
+Un camp `list` obre el subform referenciat una vegada per fila:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+L'extravar `servers` que s'envia a Ansible és un array d'objectes: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Editar un sol objecte estructurat: camp `yaml`:**
+
+El camp `yaml` té tres modes:
+
+| Mode | Com | Comportament |
+|---|---|---|
+| **Editor** | per defecte | Mostra un editor YAML complet amb ressaltat de sintaxi on l'usuari pot escriure directament |
+| **Només lectura** | `readonly: true` | Mostra el valor YAML com a text formatat de només lectura, sense edició |
+| **Subform** | `subform: MySubform` | Amaga l'editor en brut; en fer-hi clic, obre el subform com un editor desplegable |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Pujada i baixada: camps `list` i `yaml`:**
+
+Tots dos tipus de camp admeten la transferència de fitxers al costat del client mitjançant dues propietats opcionals:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> El camp `list` i el tipus de formulari `subform` han substituït el camp `table` i `tableFields`, que es van eliminar a la 7.0.0.
+
+### Com accedeixo a les dades del formulari pare dins d'un subform?
+
+Fes referència als valors dels camps del pare des d'un subform mitjançant `__parent__` (v6.3.0+).
+
+Quan s'obre un subform, tant des d'un camp **`list`** (l'editor de cada fila) com des d'un camp **`yaml`** en mode subform, AnsibleForms injecta automàticament al subform un camp especial de només lectura anomenat `__parent__`. Conté una instantània de **tots els valors dels camps del formulari pare en el moment d'obrir el subform**, incloses les constants i les variables.
+
+Això permet que els camps del subform facin servir expressions que referencien dades del pare sense cap configuració addicional.
+
+#### Què hi ha a `__parent__`?
+{: .no_toc }
+
+`__parent__` és un objecte simple les claus del qual són els noms dels camps del formulari pare:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` **no s'envia a Ansible**; com `__user__`, s'elimina de les extravars. És purament una ajuda del frontend per a les expressions dins dels subforms.
+
+#### Accedir als valors del pare a les expressions d'un subform
+{: .no_toc }
+
+Fes referència als valors del pare amb la sintaxi d'expressió estàndard `$(...)`:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Subforms niats
+{: .no_toc }
+
+`__parent__` sempre fa referència al formulari pare **immediat**. Si nies un `list` dins d'un subform que al seu torn s'obre des d'un formulari pare, el `__parent__` del subform interior conté les dades del subform del mig. Per arribar a nivells superiors, encadena referències com ara `$(__parent__.__parent__.someField)` si el subform del mig també propaga el seu propi `__parent__`.
+
+### Com migro de `table` / `tableFields` a `list` / `subform`?
+
+El camp `table` i la propietat `tableFields` es van declarar obsolets a la 6.2.0 i es van eliminar a la 7.0.0, i un formulari que encara els fa servir no supera la validació. Per migrar:
+
+1. Extreu les columnes de `tableFields` a un nou formulari `type: subform` amb `formfields` normals
+2. Substitueix el camp `table` per un camp `list` que referenciï el subform mitjançant `subform: MySubformName`
+
+**Abans:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Després:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### Migrar `from` de `tableFields` a expressions amb `__parent__`
+{: .no_toc }
+
+La propietat `from` de les columnes enum de `tableFields` emplenava les opcions del desplegable a partir d'un altre camp del formulari pare. En un `subform`, se substitueix per una `expression` que llegeix el mateix valor a través de `__parent__`.
+
+**Abans: `tableFields` amb `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Després: subform amb una expressió `__parent__`:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` retorna el **valor actual** d'aquest camp, així que si aquest camp és al seu torn un camp d'expressió dinàmic, el subform sempre veu el darrer resultat avaluat del pare.
+
diff --git a/i18n/ca/_reference/getting-help.md b/i18n/ca/_reference/getting-help.md
new file mode 100644
index 0000000..2e296e2
--- /dev/null
+++ b/i18n/ca/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Obtenir ajuda
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Obtenir ajuda
+{: .no_toc }
+
+On fer una pregunta, informar d'un error o d'un problema de seguretat, i proposar una millora
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Abans de preguntar
+
+La majoria de respostes ja estan escrites; una ullada ràpida sovint estalvia anades i vingudes:
+
+1. Cerca en aquest lloc amb el quadre de cerca de la part superior de cada pàgina.
+2. Busca el missatge d'error exacte a [Resolució de problemes](troubleshooting.html), i fes una ullada a les [PMF](faq.html).
+3. Comprova el registre del servidor (**Configuració**, i després **Registre del servidor**) i la pàgina **Estat**, que informen de la majoria de problemes de configuració.
+4. Consulta el [Registre de canvis](changelog.html): potser el problema ja està corregit en una versió més nova.
+
+---
+
+## On anar
+
+Cada tipus de petició té el seu lloc, tots a GitHub:
+
+| Vols | Ves a |
+|---|---|
+| Fer una pregunta o compartir una idea | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Informar d'un error | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Proposar una funcionalitat | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Informar d'un problema de seguretat | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), en privat |
+| Corregir o millorar aquesta documentació | **Edita aquesta pàgina a GitHub** al peu de qualsevol pàgina, o una [issue al lloc web](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Informar d'un error
+
+Un informe que es pot reproduir es corregeix més de pressa. La plantilla d'informe d'error demana el següent:
+
+* **Versió** : es mostra a **Quant a** al menú d'ajuda (**?**) de la barra superior
+* **Desplegament** : Docker, Docker Compose, Kubernetes, l'instal·lador (i el seu motor), una instal·lació nativa o des del codi font
+* **Passos per reproduir-lo** : què has fet, què esperaves, i què ha passat en canvi
+* **Proves** : les línies rellevants del registre del servidor, i una captura de pantalla quan el problema és visible
+
+Per a un problema amb un formulari, inclou una definició de formulari mínima que el mostri. Treu les contrasenyes, els tokens, els noms d'host i qualsevol
+altra dada privada dels registres i dels formularis abans de publicar-los: les issues i les discussions són públiques.
+
+---
+
+## Informar d'un problema de seguretat
+
+**No obris mai una issue pública per a això:** fes servir [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), que només veuen els mantenidors.
+
+La [política de seguretat](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) llista les versions compatibles i
+què passa després d'informar-ne.
diff --git a/i18n/ca/_reference/troubleshooting.md b/i18n/ca/_reference/troubleshooting.md
new file mode 100644
index 0000000..4e568fb
--- /dev/null
+++ b/i18n/ca/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Resolució de problemes
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Resolució de problemes
+{: .no_toc }
+
+Missatges d'error i símptomes, per què passen i com corregir-los
+{: .fs-6 .fw-300 }
+
+---
+
+Cada problema següent té com a títol el missatge o el símptoma que veus, seguit de la causa i la solució. Els missatges es citen
+exactament com els escriu AnsibleForms; `<name>` representa un valor que canvia en cada cas. La majoria acaben al registre del
+servidor, que pots llegir a [Registre del servidor](gui/administration.html#server-log) o amb `docker logs`.
+
+**Base de dades i inici**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Configuració i formularis**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [La configuració base té una secció forms](#the-base-config-has-a-forms-section)
+* [Falta un formulari al tauler](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Inici de sessió**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Falla l'autenticació d'Azure AD o OIDC](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Sessió tancada després d'un reinici o al cap d'un dia](#logged-out-after-a-restart-or-after-a-day)
+* [Formularis i tasques buits després d'un inici de sessió únic (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Tasques**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Una tasca mostra l'estat abandoned](#a-job-shows-the-status-abandoned)
+* [Un RTE no es connecta](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Repositoris git i còpies de seguretat**
+
+* [Falla el clonatge o el pull d'un repositori](#a-repository-clone-or-pull-failed)
+* [El repositori de formularis encara no està clonat](#the-forms-repository-is-not-cloned-yet)
+* [Falla una còpia de seguretat](#a-backup-failed)
+
+Les [PMF](faq.html) tracten a fons dos problemes relacionats: una
+[contrasenya d'administrador perduda](faq.html#recovering-a-lost-admin-password) i
+[restringir les destinacions dels helpers REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms no s'inicia, i el registre repeteix aquestes línies cada 5 segons:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Per què passa**
+
+En iniciar-se, AnsibleForms espera fins que la base de dades respon una consulta, i continua esperant mentre no ho faci.
+El `<reason>` és el missatge del mateix controlador de la base de dades: una connexió rebutjada o que ha esgotat el temps apunta al host o al port,
+un missatge d'accés denegat al nom d'usuari o a la contrasenya.
+
+**Com corregir-ho**
+
+Comprova [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) i [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Des de dins d'un contenidor, `localhost` és el mateix contenidor, no l'host que executa MySQL. Assegura't que MySQL escolta
+en una adreça de xarxa i que l'usuari es pot connectar des de l'host d'AnsibleForms. AnsibleForms continua tot sol tan aviat
+com la base de dades respon; no cal reiniciar.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+El navegador obre una pàgina de base de dades en lloc de la pàgina d'inici de sessió, i el registre mostra:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Per què passa**
+
+Falta l'esquema `AnsibleForms` o està incomplet. Una base de dades *buida* s'aprovisiona automàticament en iniciar-se, tret que
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) sigui `0`. Si això falla, per exemple perquè
+l'usuari de la base de dades no pot crear un esquema, el registre diu `Failed to create the schema automatically : <reason>`. Un esquema
+que existeix però al qual falten taules (`Table '<name>' is not present`) mai es torna a crear automàticament, perquè crear
+l'esquema primer elimina totes les taules. Aleshores la pàgina de base de dades diu *It appears that you have an unuseable schema*.
+
+**Com corregir-ho**
+
+En una instal·lació nova, dona a l'usuari de la base de dades el dret de crear l'esquema `AnsibleForms` i reinicia, o prem
+**Crea** a la pàgina de base de dades. Amb un esquema present només en part, restaura una còpia de seguretat o elimina l'esquema `AnsibleForms`
+incomplet perquè AnsibleForms el pugui tornar a crear. El registre llista quines taules i quins pedaços han fallat.
+
+---
+
+## Schema creation is disabled
+
+Crear l'esquema, des de la pàgina de base de dades o amb `POST /api/v2/schema`, falla amb:
+
+```
+Schema creation is disabled
+```
+
+**Per què passa**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) és `0`, cosa que desactiva tant la creació
+automàtica en iniciar-se com l'endpoint. En una base de dades que ja té usuaris, l'endpoint també rebutja qui no hagi
+iniciat sessió com a administrador, amb `Schema creation requires an authenticated administrator`.
+
+**Com corregir-ho**
+
+Crea l'esquema amb `ALLOW_SCHEMA_CREATION=1` una vegada (és el valor predeterminat), o restaura'l a partir d'una còpia de seguretat, i després torna a posar la
+variable a `0`. En una base de dades aprovisionada, inicia sessió com a administrador abans de tornar a crear l'esquema, i recorda
+que elimina i torna a crear totes les taules.
+
+---
+
+## Config seed failed, refusing to start
+
+El contenidor surt just després d'iniciar-se, i la seva sortida acaba amb:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Per què passa**
+
+El fitxer de [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) no s'ha pogut aplicar: no és YAML
+vàlid o incompleix l'esquema del seed, per exemple; `<reason>` diu què ha anat malament. AnsibleForms es nega a iniciar-se en lloc
+d'executar-se amb la meitat dels objectes declarats. El motiu també s'escriu a la sortida d'error estàndard, així que `docker logs` i `kubectl logs` el mostren.
+
+**Com corregir-ho**
+
+Corregeix el que indica `<reason>` i torna a iniciar. Consulta [Recàrrega i inici](seed/reloading.html) per veure com s'aplica el seed,
+i [Exemple](seed/example.html) per a un fitxer vàlid.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Cada inici registra aquest avís:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+O el worker es nega a iniciar-se amb:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Per què passa**
+
+Els secrets desats es xifren amb [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET): des de la 7.3.0 són a les
+credencials (les contrasenyes i els tokens de directoris LDAP, proveïdors d'SSO, runners i magatzems de secrets, entre d'altres), al costat de les adreces dels webhooks de Slack
+i Teams. Sense aquesta variable, es fa servir una clau que és pública al codi font. Des de la 7.3.0, un inici amb un
+`ENCRYPTION_SECRET` nou torna a xifrar tots els secrets desats amb aquesta clau, en una sola transacció: des de la clau predeterminada quan es defineix per primera
+vegada, o des d'[`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) quan canvia. Quan els
+secrets desats no s'han xifrat amb cap de les dues, no es canvia res i AnsibleForms no s'inicia.
+
+**Com corregir-ho**
+
+Defineix `ENCRYPTION_SECRET`, i guarda'l amb els altres secrets: les còpies de seguretat mai el contenen. El següent inici registra
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Per canviar-lo més endavant, posa el valor nou a
+`ENCRYPTION_SECRET` i l'antic a `ENCRYPTION_SECRET_PREVIOUS` durant un inici, i després treu `ENCRYPTION_SECRET_PREVIOUS`. Quan el
+worker es nega a iniciar-se, posa a `ENCRYPTION_SECRET_PREVIOUS` la clau amb què es van xifrar els secrets, o torna a posar el valor antic.
+
+---
+
+## Could not load the forms
+
+El tauler no mostra cap formulari i informa:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Per què passa**
+
+La configuració base (`config.yaml`) no s'ha pogut llegir o no és vàlida. El `<reason>` diu quin és el cas:
+
+| Motiu | Causa |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Un error de sintaxi YAML |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Un fitxer buit, o un amb només comentaris |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | El mateix rol està definit dues vegades |
+| `There is no config.yaml nor could one be created from template.` | Falta `config.yaml` i la seva carpeta no té permisos d'escriptura |
+| `There is no forms directory nor could there be one created from template.` | Falta la carpeta de formularis i no es pot crear |
+| Qualsevol altra línia | La configuració incompleix l'esquema, per exemple un rol sense `groups` |
+
+**Com corregir-ho**
+
+Corregeix el fitxer que indica [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH), o el `config.yaml` del
+repositori que es fa servir per a la configuració. Quan falten fitxers, fes que [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) i
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) apuntin a una ubicació persistent amb permisos d'escriptura. Consulta
+[config.yaml](config/) per a l'estructura.
+
+---
+
+## La configuració base té una secció forms
+
+Després d'actualitzar des de la 6.x el tauler és buit, i el panell d'avisos mostra:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Per què passa**
+
+Des de la 7.0.0, cada formulari és al seu propi fitxer a la carpeta de formularis. Els formularis que encara figuren a `config.yaml`
+s'ignoren.
+
+**Com corregir-ho**
+
+Mou cada formulari al seu propi fitxer a [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Consulta
+[Actualitzar a la 7.x](upgrade-7.html).
+
+---
+
+## Falta un formulari al tauler
+
+Existeix un fitxer de formulari, però un usuari no veu el formulari al tauler.
+
+**Per què passa**
+
+Un usuari només veu un formulari quan un dels `roles` del formulari és un dels rols de l'usuari; els administradors veuen tots els formularis. Tots els usuaris tenen
+el rol `default`, així que un formulari amb `roles: [default]` és visible per a tothom. Els rols d'un usuari vénen dels grups i els usuaris
+llistats a `roles` a `config.yaml`. Un formulari sense `categories` apareix a **Default**, així que no surt a les
+altres categories, tot i que continua llistat a **Tots els formularis**. Finalment, un formulari que no supera la validació s'omet. Aleshores el
+tauler mostra un botó **Aquesta configuració té Avisos o errors**, que obre missatges com ara:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Com corregir-ho**
+
+Obre el panell d'avisos i corregeix el que hi llista. Comprova els rols de l'usuari a
+[Permisos](profile/permissions.html) al perfil, i els `roles` i les `categories` del formulari. Consulta
+[Rols](config/roles.html) i [Categories](config/categories.html). Quan dos fitxers defineixen el mateix nom de formulari,
+guanya el primer que es carrega.
+
+---
+
+## Could not save the forms
+
+Desar al dissenyador falla amb:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Per què passa**
+
+El dissenyador valida cada formulari amb l'esquema abans d'escriure res. Cada línia de `<messages>` indica el
+formulari i el camp que incompleixen una regla. Les opcions eliminades a la 7.0.0 tenen un missatge propi, per exemple
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Com corregir-ho**
+
+Corregeix els camps que indiquen els missatges. Per a les opcions que la 7.0.0 ha eliminat, segueix [Actualitzar a la 7.x](upgrade-7.html).
+Per validar els fitxers de formulari abans que arribin a AnsibleForms, consulta
+[Validació a VS Code per als fitxers de formulari](faq.html#vs-code-validation-for-form-files) a les PMF.
+
+---
+
+## The editor is read-only
+
+El dissenyador mostra **Bloquejat per** amb el nom d'un altre usuari, i desar falla amb:
+
+```
+The editor is read-only
+```
+
+**Per què passa**
+
+Només una persona alhora pot editar els formularis. El bloqueig es pren quan algú inicia el dissenyador, i es manté fins que
+l'atura, fins i tot si ha tancat el navegador sense aturar-lo. L'API rebutja un desament de qualsevol altra persona amb
+`Designer is locked by <username>`.
+
+**Com corregir-ho**
+
+Demana a `<username>` que aturi el dissenyador. Si no és possible, fes servir **Force Unlock** al dissenyador. Qui té el
+bloqueig perd els canvis que no hagi desat.
+
+---
+
+## Abuse attempt of eval function
+
+Un camp d'expressió mostra un error, i el registre té una línia com ara:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Per què passa**
+
+Les expressions del costat del servidor es comproven abans d'executar-se. Només poden cridar funcions `fn.` i `fnc.`; es rebutgen les sentències múltiples,
+les línies múltiples, els template literals, `process.env` i paraules com ara `require` o `constructor`. El missatge
+diu quina regla s'ha incomplert. Amb [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) a
+`off`, totes les expressions del servidor fallen amb
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Com corregir-ho**
+
+Reescriu l'expressió com una sola crida `fn.` o una operació simple, o executa-la al navegador amb `runLocal: true`. Consulta
+[Expressions](expressions/) i [Expressions locals](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Un camp que crida una API REST es queda buit, i el registre mostra:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Per què passa**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) està definit, i l'host de l'URL no hi és.
+Un host que coincideix amb [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) es rebutja amb
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, i un host que no es resol amb `cannot resolve <host>`.
+
+**Com corregir-ho**
+
+Afegeix el nom d'host, o un CIDR que en cobreixi les adreces, a `REST_ALLOWED_HOSTS`, o treu de
+`REST_DENIED_HOSTS` l'entrada que el bloqueja. Consulta [Restringir les destinacions dels helpers REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+La pàgina d'inici de sessió rebutja un nom d'usuari i una contrasenya amb:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Per què passa**
+
+La pàgina d'inici de sessió dona la mateixa resposta per a qualsevol error, perquè no reveli si un usuari existeix. AnsibleForms
+prova primer els usuaris locals i després LDAP: amb diversos directoris, un nom d'usuari es busca en el seu ordre a **Accés > LDAP**,
+tret que indiqui un directori (`corp\jane`) o un dels seus dominis d'inici de sessió (`jane@corp.example`). El motiu real va al registre. Els errors
+de LDAP es registren com a `Error connecting to ldap: <reason>`, amb motius com ara `Wrong binding credentials` o
+`Unable to verify the certificate`; els codis d'Active Directory es tradueixen a `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` o `Password expired`.
+
+**Com corregir-ho**
+
+Llegeix el motiu al registre. Per obtenir el motiu complet de cada inici de sessió fallit, posa
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) a `debug`, que registra `Ldap authentication failed: <reason>`.
+Si s'ha perdut la contrasenya de l'administrador local, consulta [Recuperar una contrasenya d'administrador perduda](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Provar un directori LDAP a **Accés > LDAP** falla amb un d'aquests:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Per què passa**
+
+L'usuari de bind o la seva contrasenya són incorrectes, el servidor o el port no són accessibles o, amb TLS, el certificat del servidor no es pot
+verificar amb el paquet de CA. Des de la 7.3.0 això és a la credencial ldap del directori, a **Connexions > Credencials**. Un usuari de prova que no existeix
+continua comptant com una prova correcta, perquè la connexió i el bind han funcionat.
+
+**Com corregir-ho**
+
+Obre la credencial que indica el directori (el directori predeterminat és `main`) a **Connexions > Credencials**, i corregeix el DN de
+bind i la seva contrasenya, els servidors i el port (normalment 389, o 636 per a LDAPS). Per a problemes de TLS, enganxa el paquet de CA que ha signat el
+certificat del servidor LDAP; ometre la comprovació del certificat no és per a producció. Consulta [LDAP](authentication/ldap.html).
+
+---
+
+## Falla l'autenticació d'Azure AD o OIDC
+
+Un inici de sessió únic torna a la pàgina d'inici de sessió amb:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Per què passa**
+
+El proveïdor d'identitat ha retornat l'usuari, però AnsibleForms no ha pogut completar l'inici de sessió. Motius habituals són
+`azuread login is not enabled` o `oidc login is not enabled` (el proveïdor està desactivat), i `jwt expired`, perquè
+el traspàs des del proveïdor només és vàlid durant 5 minuts. Un error durant la crida de retorn del proveïdor també es mostra
+a la pàgina d'inici de sessió, i es registra.
+
+**Com corregir-ho**
+
+Activa el proveïdor a **Accés > SSO**, i registra l'URL de retorn al proveïdor d'identitat exactament com
+el fa servir AnsibleForms: `https://<your host>/api/v2/auth/entraid/callback` per a Entra ID (des de la 7.3.0; `azureadoauth2` continua funcionant), o
+`https://<your host>/api/v2/auth/oidc/callback` per a OIDC. Un URL de retorn amb `/api/v1/`, d'abans de la 7 o d'abans de la
+6.1.5, s'ha d'actualitzar: si no, la pàgina d'inici de sessió es torna a carregar sense iniciar la sessió i sense cap error. Torna a provar l'inici de sessió després
+d'un traspàs caducat.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Un usuari amb una contrasenya vàlida no pot iniciar sessió, i rep:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Per què passa**
+
+Un dels rols de l'usuari defineix l'opció de rol `allowLogin` com a `false`. El registre diu
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Com corregir-ho**
+
+Treu `allowLogin: false` del rol, o treu l'usuari d'aquest rol. Consulta [Rols](config/roles.html).
+
+---
+
+## Sessió tancada després d'un reinici o al cap d'un dia
+
+Tots els usuaris tornen a la pàgina d'inici de sessió després que AnsibleForms es reiniciï, o després d'un dia d'ús.
+
+**Per què passa**
+
+Quan [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) no està definit, cada inici genera una
+clau de signatura nova, i registra
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Aleshores els tokens d'abans del
+reinici ja no s'accepten. Independentment, una sessió acaba quan caduca el seu token de renovació
+(`Refresh token is expired`), passat
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), 24 hores per defecte.
+
+**Com corregir-ho**
+
+Defineix `ACCESS_TOKEN_SECRET` amb un valor fix i secret. Augmenta `ACCESS_TOKEN_REFRESH_EXPIRATION` si un dia és massa curt. Per a
+un accés a l'API de llarga durada, fes servir un [token d'API](profile/api-token.html).
+
+---
+
+## Formularis i tasques buits després d'un inici de sessió únic (HTTP 431)
+
+Un usuari inicia sessió amb Entra ID o OIDC sense cap error, però les pàgines de formularis i de tasques es queden buides. La pestanya
+de xarxa del navegador mostra les crides a l'API respostes amb:
+
+```
+431 Request Header Fields Too Large
+```
+
+El registre del servidor no mostra res per a aquestes crides, i el mateix usuari pot funcionar bé amb un compte LDAP o local.
+
+**Per què passa**
+
+Abans de la 7.1.0, el token d'inici de sessió portava tots els grups de l'usuari, i els grups d'Entra ID hi eren dues vegades, per id d'objecte
+i per nom. El navegador envia aquest token a la capçalera `Authorization` de cada petició, així que un usuari en uns cent
+grups o més acaba amb una capçalera de bastant més de 16 KB. Node.js rebutja les capçaleres de petició de més de 16 KB amb un 431,
+abans que la petició arribi a AnsibleForms, i per això no es registra res. Un servidor intermediari invers al davant pot rebutjar la
+petició fins i tot abans: Nginx permet 8 KB per camp de capçalera per defecte
+(`large_client_header_buffers 4 8k`), i respon 400.
+
+**Com corregir-ho**
+
+Actualitza a la 7.1.0 o posterior: el token d'inici de sessió ja no porta els grups, així que la seva mida ja no depèn de quants
+grups té un usuari, i la interfície ho indica quan una petició es rebutja amb 431 en lloc de mostrar pàgines buides.
+Mentre no puguis actualitzar, pots:
+
+* definir un **Filtre de grups** al proveïdor a **Accés > SSO**, una expressió regular que només conservi els grups que fan servir els teus
+  rols, consulta [Entra ID](authentication/entra-id.html) o [OIDC](authentication/oidc.html); l'usuari torna a iniciar sessió
+  per obtenir un token més petit
+* o augmentar el límit de Node.js amb la variable d'entorn `NODE_OPTIONS=--max-http-header-size=65536`, i
+  reiniciar AnsibleForms
+
+Des de la 7.1.0, [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) defineix el mateix límit, 16384
+bytes per defecte i llegit en iniciar-se, per a altres capçaleres grans, com ara cookies grans que defineix una passarel·la d'inici de sessió únic al
+davant. Augmenta també els límits de capçalera del servidor intermediari, consulta [Mida de les capçaleres de petició](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Una tasca d'Ansible acaba com a fallida, i la darrera línia de la seva sortida és:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Per què passa**
+
+`ansible-playbook` ha sortit amb un codi diferent de zero. Les línies de sobre contenen l'error del mateix Ansible: no s'ha pogut trobar el playbook,
+un host no era accessible, una tasca ha fallat o l'inventari és incorrecte. El playbook es busca al repositori
+amb **Utilitzar per als playbooks ?** activat, o a [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); la línia del registre
+`Running from directory : <path>` mostra la carpeta que s'ha fet servir.
+
+**Com corregir-ho**
+
+Llegeix la sortida de la tasca per sobre de la darrera línia. Quan no es troba el playbook, compara el `playbook` del formulari amb la
+carpeta de `Running from directory`. Consulta [Formularis d'Ansible](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Una tasca d'Ansible acaba com a fallida amb:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Per què passa**
+
+El procés `ansible-playbook` de l'RTE ha acabat per un senyal, i ningú no ha avortat la tasca. Des de la 7.0.0 la mida de la
+sortida ja no ho provoca: passat [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (50 MB per flux
+per defecte) la resta de la sortida no es desa, la tasca mostra
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+i el playbook s'executa fins al final. Ara la causa habitual és la memòria: el contenidor de l'RTE ha arribat al seu límit de memòria i el
+nucli ha matat el playbook, per exemple amb molts forks o facts grans.
+
+**Com corregir-ho**
+
+Comprova la memòria del contenidor de l'RTE mentre s'executa el playbook (`docker stats`, `kubectl top pod`) i augmenta'n el límit, o redueix
+l'ús de memòria del playbook (menys `forks`, sense recollir facts innecessaris). Quan només veus l'avís de `PROCESS_MAX_BUFFER` i
+necessites tota la sortida, augmenta `PROCESS_MAX_BUFFER` a l'entorn del contenidor de l'RTE; el llegeix l'RTE, no l'aplicació.
+---
+
+## Failed to launch awx template
+
+Una tasca d'AWX acaba com a fallida, amb una sortida que comença amb:
+
+```
+failed to launch awx template <name>
+```
+
+**Per què passa**
+
+La línia següent dona el motiu. `Request failed with status code 401` vol dir que es rebutja el token o el nom d'usuari i la contrasenya de la
+credencial del runner d'AWX. `could not find job template <name>` vol dir que cap job template ni cap workflow job template
+té exactament aquest nom, o que l'usuari de la connexió no el pot veure. Un error de certificat, com ara
+`unable to verify the first certificate`, vol dir que el certificat d'AWX no és de confiança.
+
+**Com corregir-ho**
+
+Fes servir **Prova la connexió** al runner (**Connexions > Runners**), que respon `Runner connection is OK` quan funciona. Des de la
+7.3.0 el token o l'usuari i la contrasenya, l'adreça i el **Paquet de CA** són a la credencial del runner, a
+**Connexions > Credencials**: renova-hi el token o la contrasenya, i per als errors de certificat enganxa la CA al seu **Paquet de CA**.
+Comprova el nom i els permisos de la plantilla. Introdueix l'adreça sense `/api/v2`: AnsibleForms hi afegeix
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX) ell mateix.
+Consulta [Formularis d'AWX](forms/awx.html).
+
+---
+
+## Una tasca mostra l'estat abandoned
+
+Una tasca que s'estava executant ara està marcada com a `abandoned`, i el registre d'un node o d'un RTE mostra un d'aquests:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Un RTE en mode database, obsolet, registra els seus propis:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Per què passa**
+
+Una tasca pertany al contenidor que l'executa o la segueix: un playbook al seu RTE, qualsevol altra tasca (una tasca d'AWX, els passos d'un formulari de
+diversos passos) al node d'aplicació que la va iniciar. Quan aquest contenidor es reinicia, acaba les seves pròpies tasques no acabades. Quan desapareix, un
+pod substituït per exemple, el worker acaba les seves tasques un cop fa dos minuts que no respon. Un RTE en un mode de socket que torna sense
+una tasca que estava executant, un contenidor nou sense el seu spool per exemple, fa que aquesta tasca acabi com a abandonada. Un RTE que s'atura espera primer
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) els seus playbooks. Cada hora, les tasques que fa més
+d'un dia que s'executen també es marquen com a abandonades.
+
+Des de la 7.3.0 una tasca a AWX, AAP o Ascender continua al seu runner: just després que un reinici l'abandoni, un node la torna a seguir,
+si s'ha iniciat en les darreres 24 hores, i acaba amb el que realment hi ha passat. Aleshores el registre diu `Following <n> abandoned job(s) again on their runner`.
+
+**Com corregir-ho**
+
+Rellança una tasca de playbook. Reinicia o actualitza els RTE i els nodes d'aplicació mentre no s'executi cap tasca, i dona prou temps a un RTE que s'atura
+(consulta [Escalat](rte/run.html)). Comprova si el playbook realment ha acabat als hosts gestionats abans de
+rellançar, perquè pot haver-se executat en part.
+
+---
+
+## Un RTE no es connecta
+
+**Prova la connexió** en un runner RTE (**Connexions > Runners**) falla amb:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Per què passa**
+
+Un RTE en un mode de socket parla amb l'aplicació a través d'un WebSocket: en outbound truca a l'aplicació, en inbound l'aplicació el truca (consulta
+[Modes](rte/modes.html)). Els registres de l'aplicació i de l'RTE diuen per què el socket no està obert:
+
+| Missatge | On | Què vol dir |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | L'RTE (inbound) | El token de la credencial d'RTE del runner no és el `RTE_TOKEN` de l'RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | L'aplicació (inbound) | El mateix, vist des de l'aplicació |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | L'aplicació, i l'RTE rebutjat (`401`) | L'RTE s'autentica amb un token diferent del que l'aplicació guarda per al seu runner |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | L'RTE (outbound) | Ha demanat unir-se i espera una aprovació |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | L'RTE (inbound, amb `APP_URL`) | El mateix, per a un RTE inbound |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | L'aplicació, i l'RTE rebutjat (`409`) | El config seed declara el runner sense `rte_mode`, per tant en mode database, i és el seed qui en decideix el mode. Un RTE inbound rep `rte_mode: inbound` i `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | L'RTE | Un RTE inbound que es registra ell mateix necessita l'adreça on el truca l'aplicació |
+| `Runner '<name>': dialing <address>: <reason>` | L'aplicació, al nivell `debug` | L'aplicació no pot obrir el socket, per exemple perquè el certificat de l'RTE no és el fixat per al seu runner |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | L'RTE | S'executa en mode database, i no obre cap socket |
+
+**Com corregir-ho**
+
+* **Un token rebutjat** : dona a l'RTE el token de la credencial d'RTE del seu runner (**Connexions > Credencials**), o a l'inrevés
+* **Esperant aprovació** : aprova'l a **Connexions > Runners**, després de comprovar que l'empremta que s'hi mostra és la del seu
+  registre (consulta [Aprovar un RTE](runners/registration.html#approving-an-rte))
+* **Gestionat pel config seed en mode database** : defineix `rte_mode` al runner al seed, amb una credencial d'RTE (per a inbound, la seva
+  adreça), i després reinicia l'RTE
+* **Inbound sense `RTE_URL`** : defineix `RTE_URL` amb l'adreça per on l'aplicació arriba a l'RTE, o deixa fora `APP_URL` i declara el
+  runner al seed o a **Connexions > Runners**
+* **Un certificat que no és el fixat** : un RTE inbound per HTTPS envia el seu certificat quan es registra, i l'aplicació només el truca
+  amb aquell. Després d'un certificat nou, l'RTE el torna a enviar quan es registra; quan el paquet de CA de la credencial s'ha definit
+  a mà, l'aplicació el conserva i registra
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **L'avís [DEPRECATED]** : defineix `RTE_MODE` a l'RTE, treu `DB_*` del seu entorn, i posa el seu runner en aquest mode (consulta
+  [Modes](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Amb la validació del llançament a `enforce`, un llançament es rebutja amb `422` i:
+
+```
+The form data is not valid
+```
+
+**Per què passa**
+
+El servidor ha comprovat els valors dels camps amb les regles del formulari i ha trobat camps que falten o que no són vàlids; la resposta els llista
+a `details`. També es rebutja un llançament sense `rawFormData`. Un formulari que encara no es pot comprovar, com ara un assistent,
+es rebutja amb `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Com corregir-ho**
+
+Corregeix els camps que indiquen els detalls, o les regles del formulari si són massa estrictes. Executa primer en mode `log`: registra
+`Launch validation would refuse form '<name>' ...` sense rebutjar res. Consulta
+[Què fa enforce](launch-validation/log-and-enforce.html#what-enforce-does) i
+[Desplegar-la](launch-validation/rolling-it-out.html).
+
+---
+
+## Falla el clonatge o el pull d'un repositori
+
+Un repositori mostra un estat fallit, i la seva sortida conté l'error de git, o el registre mostra
+`Background clone of '<name>' failed : <reason>`.
+
+**Per què passa**
+
+Git no ha pogut arribar al remot o autenticar-s'hi. Per als URL SSH (`git@host:path`), el remot ha d'acceptar la clau pública
+d'AnsibleForms; per a HTTPS, el nom d'usuari i el token han de ser vàlids. També es rebutja un pull quan l'arbre de treball té
+canvis, amb
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Com corregir-ho**
+
+Per a SSH, copia la clau pública de la pestanya **Clau** de **Connexions > SSH** i afegeix-la com a deploy key, o a un usuari amb
+accés al repositori. AnsibleForms afegeix l'host remot als amfitrions coneguts en un clonatge; per a altres hosts, fes servir la
+pestanya **Amfitrions coneguts** de la mateixa pàgina. Per a
+HTTPS, renova el token. Consulta [Repositoris git](gui/designer-and-git.html#git-repositories) i
+[Sobre els repositoris](faq.html#about-repositories).
+
+---
+
+## El repositori de formularis encara no està clonat
+
+Desar formularis al dissenyador falla amb:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Per què passa**
+
+Un repositori amb **Utilitzar per als formularis ?** activat encara no té arbre de treball, perquè el clonatge no s'ha executat o ha fallat.
+
+**Com corregir-ho**
+
+Clona el repositori des de la configuració de repositoris. Si el clonatge falla, consulta
+[Falla el clonatge o el pull d'un repositori](#a-repository-clone-or-pull-failed).
+
+---
+
+## Falla una còpia de seguretat
+
+Una còpia de seguretat falla, i no s'afegeix res a la llista de còpies de seguretat. El motiu és un d'aquests:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Per què passa**
+
+L'ordre de bolcat, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), no està instal·lada, no s'ha pogut
+connectar, o ha generat un fitxer buit. Una base de dades gran també pot trigar més de
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), una hora per defecte.
+Una còpia de seguretat fallida no deixa cap carpeta; el registre diu `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Com corregir-ho**
+
+Instal·la les eines de client de MySQL o MariaDB, o defineix `MYSQLDUMP_COMMAND` (i `MYSQL_COMMAND` per a les restauracions) amb una ordre
+que funcioni en aquest host i amb la versió del teu servidor. Augmenta `BACKUP_COMMAND_TIMEOUT_SECONDS` per a una base de dades gran.
+Consulta [Còpies de seguretat](gui/administration.html#backups).
diff --git a/i18n/ca/_security_assessment/security-assessment/advisories.md b/i18n/ca/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..f4c2783
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Avisos de seguretat
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Avisos de seguretat
+{: .no_toc }
+
+Totes les vulnerabilitats publicades, la seva gravetat i la seva correcció
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avisos publicats
+
+Llegits de la [pestanya Security del repositori](https://github.com/ansibleforms/ansibleforms/security/advisories) a cada compilació d'aquest lloc:
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Avís</th>
+      <th>Gravetat</th>
+      <th>Debilitat</th>
+      <th>Afectades</th>
+      <th>Corregit a</th>
+      <th>Publicat</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+No s'ha publicat cap avís.
+{% endif %}
+
+Cada avís a GitHub en dona els detalls: l'impacte, les condicions, el vector CVSS i la correcció.
+
+---
+
+## Què vol dir això per a la teva versió
+
+Un avís indica les versions que afecta i la primera versió corregida. La correcció arriba a les versions amb suport,
+[7.x i 6.5.x](development.html#supported-versions), i les versions més antigues no es corregeixen: la solució és actualitzar.
+
+Compara la versió d'una instància (**Quant a** al menú d'ajuda, o `GET /api/v2/version`) amb **Afectades**.
+
+---
+
+## Rebre avís dels nous avisos
+
+GitHub avisa els seguidors del repositori quan es publica un avís:
+
+* A [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), tria **Watch > Custom > Security alerts**.
+* El [registre de canvis](../changelog.html) recull cada correcció de seguretat a la versió que la porta.
diff --git a/i18n/ca/_security_assessment/security-assessment/development.md b/i18n/ca/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..678f82d
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Desenvolupament segur
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Desenvolupament segur
+{: .no_toc }
+
+Com es comproven i es publiquen els canvis, i què té suport
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## El codi font
+
+AnsibleForms és de codi obert, de manera que tot el que diu aquesta pàgina es pot comprovar al mateix repositori:
+
+* El codi, el seu historial i els seus pipelines de compilació són públics a [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* La [llicència](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) és GPL-3.0.
+* El [registre de canvis](../changelog.html) recull tots els canvis de cada versió, correccions de seguretat incloses.
+
+---
+
+## Com s'integra un canvi
+
+Cada canvi arriba a `main` a través d'una pull request, sota un conjunt de regles que ningú no pot saltar-se:
+
+| Regla | Què vol dir |
+|---|---|
+| Pull request obligatòria | No es fa cap push directament a `main` |
+| Comprovacions obligatòries | La pull request només s'integra quan passen totes les comprovacions de sota |
+| Sense force push ni eliminació | L'historial de `main` no es pot reescriure ni eliminar |
+| Historial lineal | Cada pull request es converteix en un sol commit, de manera que cada canvi es pot rastrejar i revertir per separat |
+
+Les comprovacions que ha de passar una pull request:
+
+| Comprovació | Què fa |
+|---|---|
+| Client, Server | Les proves unitàries de la interfície web i del servidor |
+| CodeQL | L'anàlisi estàtica de GitHub del codi JavaScript i TypeScript, per detectar injeccions, cross-site scripting i altres debilitats |
+| Public schema is up to date | L'esquema de base de dades que espera el codi coincideix amb el que porta |
+| Title, Branch | La pull request segueix les regles de nomenclatura, perquè el registre de canvis sigui exacte |
+
+N'hi ha dues més que s'executen a cada pull request i n'informen:
+
+* **Database** prova el servidor amb MySQL i MariaDB, i **Browser** fa funcionar la interfície en un navegador.
+* **Dependency review** bloqueja una dependència nova amb una vulnerabilitat coneguda alta o crítica.
+
+---
+
+## Anàlisi del codi i dependències
+
+El codi i allò de què depèn es tornen a comprovar després d'integrar-se:
+
+* **CodeQL** també analitza cada push a `main` i a les branques de versió, i tot el codi cada setmana:
+  així, una regla nova de CodeQL també comprova el codi integrat abans que existís.
+* **Dependabot** obre una pull request per a cada versió nova d'una dependència: els paquets npm del servidor i de la
+  interfície, els paquets Python de l'entorn d'execució i les GitHub Actions dels pipelines cada setmana, i
+  les imatges base dels contenidors cada dia.
+* Les imatges base estan fixades per digest (`node:26-trixie-slim@sha256:...`), de manera que una compilació fa servir exactament la imatge revisada.
+  Dependabot actualitza el digest quan la imatge es torna a construir a l'origen.
+
+---
+
+## Versions i imatges
+
+Una versió només la construeix i la publica GitHub Actions, mai la màquina d'un desenvolupador:
+
+* Una versió es crea a partir de `main` (o de `release/6.x`), amb un registre de canvis construït a partir de les seves pull requests.
+* Les imatges les construeix el [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  i es publiquen al GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, amb les imatges de l'entorn d'execució
+  al costat. El workflow i els seus registres són públics, de manera que qualsevol pot veure què ha entrat en una imatge.
+* Les imatges de l'aplicació i de l'entorn d'execució s'executen com l'usuari sense privilegis `node` (uid 1000), mai com a root.
+
+---
+
+## Versions amb suport
+
+Les correccions de seguretat van a la versió més recent de cada línia amb suport:
+
+| Versió | Rep correccions de seguretat |
+|---|---|
+| 7.x | Sí |
+| 6.5.x | Sí |
+| Anterior a la 6.5 | No: la solució és actualitzar |
+
+La [guia d'actualització](../upgrading/) explica com passar a una versió més nova, i [Actualitzar a la v7](../upgrade-7.html), el pas des de la 6.5.
diff --git a/i18n/ca/_security_assessment/security-assessment/faq.md b/i18n/ca/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..db48b63
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: PMF de l'avaluació
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# PMF de l'avaluació
+{: .no_toc }
+
+Respostes breus a les preguntes que més fan els qüestionaris de seguretat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dades i allotjament
+
+On són les dades, i qui hi pot accedir:
+
+| Pregunta | Resposta |
+|---|---|
+| On es desen les nostres dades? | A la base de dades MySQL o MariaDB que gestiones tu, i a la carpeta persistent de la teva instància. AnsibleForms és autoallotjat, sense cap servei al núvol al darrere. |
+| Envia dades als seus creadors? | No. No hi ha telemetria, ni informes d'ús, ni comprovació d'actualitzacions. |
+| A què es connecta? | Només als sistemes que configura un administrador: vegeu [Connexions sortints](measures.html#outbound-connections). |
+| Fa servir IA o envia dades a un proveïdor de models? | Només amb l'[assistent de xat](../chat/) activat, que per defecte està desactivat. Llavors envia les definicions dels formularis i els valors que s'estan omplint al proveïdor que configuris. |
+| Pot funcionar sense accés a internet? | Sí. L'aplicació no necessita accés a internet; els playbooks necessiten el que facin servir les seves tasques. |
+
+---
+
+## Xifratge
+
+Què es xifra, i amb quines claus:
+
+| Pregunta | Resposta |
+|---|---|
+| Les dades es xifren en trànsit? | Amb [HTTPS](../security/https.html), servit per l'aplicació o pel teu proxy invers, i amb `wss://` entre l'aplicació i els seus entorns d'execució. |
+| Les dades es xifren en repòs? | L'aplicació xifra tots els secrets desats amb AES-256. Les tasques i la seva sortida es desen tal com són: fes servir el xifratge en repòs de la mateixa base de dades. Vegeu [Secrets desats](measures.html#stored-secrets). |
+| Qui té les claus? | Tu: el [`ENCRYPTION_SECRET`](../security/secrets.html) el defineixes tu, es manté fora de les còpies de seguretat i es pot rotar. |
+| Els secrets es poden quedar al nostre vault? | Sí: [HashiCorp Vault i CyberArk](../secret-stores/) es llegeixen quan una tasca els necessita. |
+
+---
+
+## Accés i traçabilitat
+
+Qui pot iniciar la sessió, què pot fer i què queda registrat:
+
+| Pregunta | Resposta |
+|---|---|
+| Admet l'inici de sessió únic? | Sí: LDAP / Active Directory, OpenID Connect i Entra ID. Vegeu [Autenticació](../authentication/). |
+| Admet l'autenticació multifactor? | A través de l'inici de sessió únic: s'aplica l'MFA del teu proveïdor d'identitat. Els comptes locals no en tenen de pròpia. |
+| Com es gestionen els permisos? | Amb rols assignats a grups, que el servidor comprova a cada petició. Vegeu [Permisos](measures.html#permissions). |
+| Hi ha un registre d'auditoria? | Sí: cada canvi i cada intent rebutjat, conservats 365 dies per defecte i reenviables a syslog. Vegeu [Registre d'auditoria](measures.html#audit-trail). |
+| Hi ha una contrasenya per defecte? | El primer compte d'administrador té una contrasenya per defecte pública, que s'ha de canviar al primer inici de sessió. Vegeu [El compte d'administrador](../security/hardening.html#the-admin-account). |
+
+---
+
+## Vulnerabilitats i actualitzacions
+
+Com es troben, es corregeixen i s'anuncien els problemes:
+
+| Pregunta | Resposta |
+|---|---|
+| S'hi han trobat vulnerabilitats? | Sí. Totes les publicades apareixen a [Avisos de seguretat](advisories.html), amb la versió que les va corregir. |
+| Com en comuniquem una? | En privat, a través de GitHub: vegeu [Comunicar una vulnerabilitat](reporting.html). |
+| Com es comprova el codi? | Anàlisi estàtica amb CodeQL i revisió de dependències a cada pull request, proves automatitzades i actualitzacions de Dependabot. Vegeu [Desenvolupament segur](development.html). |
+| Quines versions reben correccions de seguretat? | 7.x i 6.5.x. Vegeu [Versions amb suport](development.html#supported-versions). |
+| Com ens assabentem d'un avís nou? | Seguint les alertes de seguretat del repositori a GitHub. Vegeu [Rebre avís dels nous avisos](advisories.html#being-told-of-new-advisories). |
+| S'hi ha fet una prova de penetració? | No hi ha publicat cap informe de prova de penetració de tercers. El codi és públic, de manera que el teu propi equip o auditor el pot avaluar, i les troballes es comuniquen com s'ha dit més amunt. |
+
+---
+
+## Imatges i cadena de subministrament
+
+D'on surten les imatges, i com comprovar-les:
+
+| Pregunta | Resposta |
+|---|---|
+| On es publiquen les imatges? | Al GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, construïdes per workflows públics de GitHub Actions. Vegeu [Versions i imatges](development.html#releases-and-images). |
+| Els contenidors s'executen com a root? | No: com l'usuari sense privilegis `node`. |
+| Les imatges estan signades? | Encara no. Descarrega-les per digest (`@sha256:...`) per assegurar-te que executes la imatge que has revisat. |
+| Hi ha un SBOM? | Encara no se'n publica cap amb les imatges. Un escàner com Trivy o Syft en construeix un a partir de la imatge. |
+| Les imatges s'analitzen per detectar vulnerabilitats? | No al pipeline de publicació. Les seves imatges base estan fixades per digest i Dependabot les manté al dia; analitza les imatges al teu propi registre per aplicar la teva pròpia política. |
+| Amb quina llicència es distribueix? | GPL-3.0, codi obert, sense garantia. |
diff --git a/i18n/ca/_security_assessment/security-assessment/index.md b/i18n/ca/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..5dfcb5d
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Visió general
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Avaluació de seguretat
+{: .no_toc }
+
+Per a revisions de seguretat: mesures, desenvolupament i avisos
+{: .fs-6 .fw-300 }
+
+---
+
+## En resum
+
+AnsibleForms executa playbooks i en guarda les credencials, de manera que forma part de la teva cadena de confiança:
+
+* És **autoallotjat**: s'executa a la teva infraestructura, desa les dades a la teva base de dades i no envia res als seus creadors.
+* És de **codi obert** (GPL-3.0): el codi, els seus pipelines i tots els avisos són públics.
+* Tots els secrets desats estan **xifrats**, tots els canvis queden **auditats**, i els **rols** es comproven a cada petició.
+* Les vulnerabilitats es **comuniquen en privat**, es corregeixen a totes les versions amb suport i es **publiquen**.
+
+---
+
+## En aquesta secció
+
+Les pàgines responen les preguntes d'una revisió de seguretat, des del disseny fins a la llista de CVE:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Mesures de seguretat](measures.html) | Inici de sessió, permisos, secrets desats, el registre d'auditoria, el navegador, el servidor, les connexions i els contenidors |
+| [Desenvolupament segur](development.html) | Com es revisa i es prova un canvi, l'anàlisi del codi i de les dependències, com es construeixen les imatges, les versions amb suport |
+| [Comunicar una vulnerabilitat](reporting.html) | Com comunicar un problema en privat, i què passa després |
+| [Avisos de seguretat](advisories.html) | Totes les vulnerabilitats publicades, amb el seu CVE, la seva gravetat i la versió que les corregeix |
+| [PMF de l'avaluació](faq.html) | Respostes breus a les preguntes que més fan els qüestionaris de seguretat |
+
+Per protegir una instància en lloc d'avaluar-la, consulta [Seguretat](../security/) a la guia de l'administrador.
diff --git a/i18n/ca/_security_assessment/security-assessment/measures.md b/i18n/ca/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..ebf9ff9
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Mesures de seguretat
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Mesures de seguretat
+{: .no_toc }
+
+Com es protegeixen l'inici de sessió, els permisos, els secrets i les connexions
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## On s'executa
+
+AnsibleForms és autoallotjat, a la teva infraestructura, amb les dades en una base de dades que gestiones tu.
+
+* No hi ha cap servei al núvol d'AnsibleForms ni cap servidor de llicències, ni telemetria ni comprovació d'actualitzacions.
+* La interfície la serveix la mateixa aplicació i no carrega res d'un altre lloc.
+* L'aplicació només es connecta als sistemes que configura un administrador, que es recullen a [Connexions sortints](#outbound-connections).
+
+Les parts i què conté cadascuna:
+
+| Part | Què fa | Què conté |
+|---|---|---|
+| Aplicació | La interfície web, l'API REST, el planificador | Cap dada pròpia: tot és a la base de dades |
+| MySQL o MariaDB | La base de dades de l'aplicació | Usuaris, grups, credencials (xifrades), tasques amb les seves extravars i la seva sortida, el registre d'auditoria |
+| Entorn d'execució (RTE) | Executa els playbooks, en el seu propi contenidor | Els fitxers de les tasques que executa, i els secrets d'una tasca només mentre aquesta s'executa |
+| Carpeta persistent | La configuració, els formularis, els playbooks i les pujades | Els fitxers que fan servir els formularis i els playbooks |
+
+Consulta [Com funciona](../how-it-works.html) per veure el conjunt, i [RTE](../rte/) per a l'entorn d'execució.
+
+---
+
+## Inici de sessió
+
+Cada pàgina i cada crida a l'API que llegeix o canvia dades necessita un usuari que hagi iniciat la sessió. Els pocs punts finals oberts sense sessió serveixen
+el mateix inici de sessió, la versió, el nom i el logotip de la instància, la documentació de l'API i la configuració de la base de dades d'una primera arrencada,
+que [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` tanca:
+
+| Mètode | Com funciona |
+|---|---|
+| Comptes locals | Contrasenyes amb hash bcrypt, una [longitud mínima](../security/hardening.html#sign-in-limits-and-passwords), i la contrasenya per defecte pública de l'administrador s'ha de canviar al primer inici de sessió |
+| LDAP / Active Directory | El directori comprova la contrasenya, i els seus grups s'assignen a rols. Vegeu [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Inici de sessió únic a través del teu proveïdor d'identitat, que també aporta la seva pròpia autenticació multifactor. Vegeu [Autenticació](../authentication/) |
+
+* Els inicis de sessió fallits [bloquegen el compte](../security/hardening.html#sign-in-limits-and-passwords), i l'inici de sessió té un límit de freqüència.
+* Un inici de sessió retorna un token d'accés signat vàlid durant 30 minuts i un token de renovació vàlid durant 24 hores.
+* Els tokens es poden invalidar abans que caduquin: tancar la sessió, canviar la contrasenya, bloquejar un usuari i revocar un token d'API els invaliden a
+  tots els nodes alhora, vegeu [Tokens](../security/secrets.html#tokens).
+* AnsibleForms no té autenticació multifactor pròpia: fes servir l'inici de sessió únic allà on sigui necessària.
+
+---
+
+## Permisos
+
+El que pot fer un usuari surt dels rols dels seus grups, i el servidor ho comprova a cada petició:
+
+* Els rols es defineixen a [config.yaml](../config/roles.html): quins formularis veu un usuari i quines opcions té,
+  com ara el dissenyador, les pàgines de configuració o les tasques d'altres usuaris.
+* El servidor comprova cada llançament amb les regles del formulari (els seus camps, els seus valors i l'accés de l'usuari), inclosos
+  els llançaments a través de l'API REST, vegeu [Validació del llançament](../launch-validation/).
+* Per disseny, el rol d'administrador executa qualsevol playbook. Els altres rols només obtenen el que se'ls concedeix: un usuari amb diversos rols obté una
+  opció només quan cap d'aquests rols no la denega, de manera que n'hi ha prou amb un rol restrictiu per retirar-la.
+
+---
+
+## Secrets desats
+
+Les contrasenyes, els tokens i les claus es xifren abans d'escriure's a la base de dades:
+
+* Tots els secrets desats (credencials, la contrasenya de vinculació LDAP, els tokens dels runners, els secrets de client de l'inici de sessió únic, les adreces
+  dels webhooks i les claus d'API) es xifren amb AES-256 i un vector d'inicialització aleatori per a cada valor, sota el
+  [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) que defineixes tu.
+* Cap crida a l'API ni cap pàgina de configuració no mostra un secret desat, i les còpies de seguretat ometen els secrets mestres.
+* Els secrets es poden quedar al teu vault: [HashiCorp Vault i CyberArk](../secret-stores/) es llegeixen quan una tasca els necessita.
+* Els secrets d'una tasca arriben a l'entorn d'execució segellats amb AES-256-GCM, amb una clau derivada del seu token.
+* Les extravars el nom de les quals sembla un secret s'emmascaren a la vista de la tasca, i els camps de contrasenya sempre, vegeu [Dades de les tasques](../security/hardening.html#job-data).
+
+La resta de la base de dades (les tasques, les seves extravars i la seva sortida) es desa tal com és: protegeix-la amb el xifratge en repòs
+i el control d'accés de la mateixa base de dades, vegeu [La base de dades](../security/hardening.html#the-database).
+
+---
+
+## Registre d'auditoria
+
+Cada canvi, i cada intent que es rebutja, queda registrat:
+
+* Cada creació, canvi i eliminació, a través de la interfície o de l'API, s'escriu al registre d'auditoria amb l'usuari, la seva
+  adreça, l'acció, l'objecte i el resultat. També es registren els rebuigs i els inicis de sessió, inclosos els fallits.
+* Els valors que semblen secrets s'oculten abans d'escriure's.
+* El registre es conserva 365 dies per defecte, i es pot copiar a syslog per UDP, TCP o TLS.
+
+---
+
+## Al navegador
+
+La interfície està protegida contra el codi injectat en una pàgina:
+
+* Una [Content-Security-Policy](../security/hardening.html#the-content-security-policy) només permet els scripts i els frames propis de l'aplicació.
+* Cada resposta porta capçaleres de protecció: nosniff, protecció de frames i HSTS sobre HTTPS.
+* L'HTML dels formularis, dels textos d'ajuda i de les respostes del xat se saneja, i la sortida de les tasques s'escapa.
+
+---
+
+## Al servidor
+
+El codi que gestiona l'entrada dels usuaris evita les injeccions clàssiques:
+
+* Les consultes a la base de dades passen els valors com a paràmetres, mai com a text enganxat a la consulta.
+* Les ordres, git inclòs, s'executen a partir d'una llista d'arguments, mai amb un shell, de manera que els caràcters de shell no fan res.
+* Les expressions de servidor passen per un [sanejador d'expressions](../security/hardening.html#expressions-and-outbound-calls), i les seves crides REST, per un filtre d'amfitrions.
+* El [servidor MCP](../mcp/), l'[assistent de xat](../chat/) i el punt final de mètriques estan desactivats fins que els activis.
+
+---
+
+## Connexions
+
+El trànsit cap a AnsibleForms i des d'AnsibleForms es pot xifrar d'extrem a extrem:
+
+* L'aplicació serveix [HTTPS](../security/https.html) ella mateixa, o es posa darrere del teu proxy invers.
+* Un entorn d'execució parla amb l'aplicació per un WebSocket, `wss://` amb una adreça HTTPS, i l'aplicació
+  fixa el certificat d'un d'entrant, vegeu [Modes de l'RTE](../rte/modes.html).
+* LDAP, l'inici de sessió únic, els runners, git, els magatzems de secrets i les crides REST de les expressions comproven el certificat del
+  servidor al qual es connecten, tret que un administrador desactivi la comprovació per a un servidor amb un certificat autosignat.
+
+### Connexions sortints
+
+AnsibleForms només es connecta al que configura un administrador:
+
+| Connexió | Quan |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (inici de sessió de Microsoft i Graph) | Quan es configura aquest mètode d'inici de sessió |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Quan un formulari s'executa en aquest runner |
+| Servidors git | Quan es configura un repositori |
+| Servidor de correu, Slack, Teams, Telegram, webhooks | Quan es configura un canal de notificació |
+| HashiCorp Vault, CyberArk | Quan es configura un magatzem de secrets |
+| Un proveïdor de models (Anthropic, OpenAI i altres) | Només amb l'[assistent de xat](../chat/) activat, que per defecte està desactivat |
+| Amfitrions i API indicats als formularis | Quan les expressions d'un formulari o un playbook els criden |
+| Servidors syslog | Quan es configura el reenviament de l'auditoria o dels registres |
+
+---
+
+## Els contenidors
+
+Les imatges estan construïdes per funcionar amb els mínims privilegis possibles:
+
+* L'aplicació i l'entorn d'execució s'executen com l'usuari sense privilegis `node`, no com a root.
+* Estan construïdes sobre imatges Debian slim fixades per digest, vegeu [Desenvolupament segur](development.html#code-analysis-and-dependencies).
+* L'aplicació escolta en un sol port, el 8000.
+
+Per als passos que protegeixen una instància nova, segueix [Enduriment](../security/hardening.html).
diff --git a/i18n/ca/_security_assessment/security-assessment/reporting.md b/i18n/ca/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..417b0a0
--- /dev/null
+++ b/i18n/ca/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Comunicar una vulnerabilitat
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Comunicar una vulnerabilitat
+{: .no_toc }
+
+Com comunicar un problema de seguretat en privat, i què passa després
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Comunica-ho en privat
+
+AnsibleForms guarda credencials i tokens de vault, així que no comuniquis mai un problema de seguretat en una issue pública:
+
+1. Obre **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: un avís privat que només veuen els mantenidors.
+2. Si aquesta pàgina no està disponible per a tu, obre una issue normal que digui només que tens un informe de seguretat i que demani
+   un canal privat: sense detalls, sense passos per reproduir-lo i sense números de versió. Un mantenidor obre un avís privat i
+   t'hi convida.
+
+La política completa és al [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) del repositori.
+
+---
+
+## Què cal incloure
+
+Com més d'aquesta informació doni un informe, més aviat es corregeix:
+
+* Què hi guanya un atacant: les dades d'un altre usuari, un playbook que no pot executar, l'amfitrió o drets d'administrador.
+* La versió, i com està desplegada: Docker, Kubernetes o instal·lada de manera nativa.
+* Una manera de reproduir-lo, o la petició que el provoca.
+* Si necessita un usuari amb la sessió iniciada, i amb quines [opcions de rol](../config/roles.html).
+
+---
+
+## Què passa després
+
+Un informe passa pel mateix avís privat des del primer missatge fins a la publicació:
+
+| Pas | Què reps |
+|---|---|
+| Confirmació de recepció | La confirmació que l'informe ha arribat, i si es reprodueix |
+| Acceptat | Una correcció a la propera versió de cada [versió amb suport](development.html#supported-versions), i un avís publicat que t'hi reconeix, tret que prefereixis no aparèixer-hi |
+| Rebutjat | El raonament, normalment que el comportament necessita un permís que la persona que l'ha comunicat ja tenia |
+
+Un cop publicada la correcció, l'avís es publica i apareix a [Avisos de seguretat](advisories.html).
+
+---
+
+## Abast
+
+La política traça la línia allà on la traça el model de rols:
+
+| Dins de l'abast | Fora de l'abast |
+|---|---|
+| Qualsevol cosa a què pugui arribar un usuari amb la sessió iniciada més enllà del que li concedeix el seu rol | Troballes que requereixen que el compte d'administrador ja estigui compromès: que un administrador executi qualsevol playbook és el producte |
+| Qualsevol cosa accessible sense iniciar la sessió | Informes d'escàners sense cap impacte demostrat |
+| Credencials desades que es tornen llegibles, o que s'escriuen en un registre | |
+| Injecció al shell, a la base de dades o al navegador | |
diff --git a/i18n/ca/_use/designer/index.md b/i18n/ca/_use/designer/index.md
new file mode 100644
index 0000000..44f2e4f
--- /dev/null
+++ b/i18n/ca/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Dissenyador
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Dissenyador
+{: .no_toc }
+
+Edita formularis, playbooks, inventaris i workflows al navegador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per als autors de formularis: les seccions del dissenyador, i què mostra cadascuna de les seves pestanyes.
+
+El dissenyador necessita l'[opció de rol](../config/roles.html#role-options) `showDesigner`. Edita un element alhora, un
+formulari, un playbook o un fitxer de workflow, amb les seves seccions al menú de l'esquerra. Cada tipus de fitxer també necessita la seva pròpia opció, totes
+activades per defecte: `allowPlaybookDesign` per als **Playbooks**, `allowWorkflowDesign` per als **Fluxos de treball**,
+`allowInventoryDesign` per als **Inventaris** i `allowVarsFileDesign` per als **Fitxers de variables**. Sense l'opció, la seva secció és
+de només lectura i el servidor es nega a desar, crear, treure o fer push dels seus fitxers; els formularis i els workflows encara els poden triar. Els
+**Formularis**, les **Categories** i les **Constants** necessiten `allowFormDesign` de la mateixa manera: sense aquesta opció són de només lectura, i el servidor
+es nega a desar-los, fer-ne pull o fer-ne push. Només edita una persona alhora: vegeu [El bloqueig del dissenyador](lock.html).
+
+---
+
+## Les seves seccions
+
+Cada secció edita un tipus de fitxer, desat localment o en un [repositori](../repositories/):
+
+| Secció | Què edita |
+|---|---|
+| **Formularis** | Els fitxers de formulari |
+| **Categories** | Les categories de `config.yaml` |
+| **Constants** | Les constants de `config.yaml` |
+| **Fitxers de variables** | Els fitxers de variables que carreguen els formularis |
+| **Playbooks** | Els playbooks que executen els formularis i els workflows |
+| **Inventaris** | Els inventaris: `inventory.yaml`, `group_vars` i `host_vars` |
+| **Fluxos de treball** | Els fitxers de [workflow](../workflows/) |
+
+Les seccions amb fitxers els mostren en un explorador de fitxers i obren el primer; una secció que encara no té fitxers ho indica. La
+secció **Formularis** i totes les seccions de fitxers tenen un botó **Fitxer nou** en primer lloc a la barra d'eines: als Inventaris crea un inventari
+nou, als Fluxos de treball, un workflow nou i buit. La lupa de l'explorador obre un quadre que filtra els seus fitxers pel nom.
+
+El quadre de cerca de la línia del títol troba un text al YAML que està obert: marca tots els llocs on apareix. Funciona a la pestanya
+**YAML**, un cop tens el bloqueig del dissenyador.
+
+---
+
+## Les seves pestanyes
+
+Totes les seccions tenen les mateixes tres pestanyes, totes sobre el mateix YAML: una edició en una es veu a les altres, i **Desa** la desa.
+
+- **YAML** és el fitxer tal com està escrit.
+- **Visual** l'edita amb camps. Només canvien les claus que toca una edició, de manera que els comentaris i la resta queden tal com estaven escrits.
+- **Previsualització** mostra què fa, i no edita res.
+
+Què mostren les pestanyes Visual i Previsualització, secció per secció:
+
+| Secció | Visual | Previsualització |
+|---|---|---|
+| **Formularis** | La configuració del formulari i els seus camps, amb llistes dels playbooks, inventaris i workflows del dissenyador | El formulari tal com és ara, edicions no desades incloses; el seu enviament no executa res |
+| **Categories** | Les categories com a taula, editables | El menú de la pàgina Formularis, construït a partir d'elles |
+| **Constants** | Les constants com un esquema, editables (una clau es mou amb les tecles de fletxa) | Cada constant amb la seva referència, `$(NAME)`, per copiar-la, i els formularis que la fan servir |
+| **Fitxers de variables** | Les variables, editables | Cada variable amb la seva referència en un playbook, {% raw %}`{{ name }}`{% endraw %}, per copiar-la, i els formularis que carreguen el fitxer |
+| **Playbooks** | Els plays: el nom de cada play, els hosts, **Become**, **Recollir facts** i els rols, i les seves tasques, cadascuna amb el seu mòdul i els seus arguments | L'esquema del playbook: els seus plays, amb els hosts, els rols i les tasques, i els playbooks que importa |
+| **Inventaris** | Els grups, els seus grups fills, els seus hosts i les variables que defineix cadascun | L'inventari en forma d'arbre, amb els seus `group_vars` i `host_vars` |
+| **Fluxos de treball** | El graf del workflow, per [editar-lo](../workflows/designer.html) | Una [simulació](../workflows/designer.html#trying-it-out): fes clic en un node perquè falli |
+
+Quan el YAML no es pot llegir, les pestanyes Visual i Previsualització diuen per què, amb **Mostra en YAML** per obrir el YAML a la línia.
diff --git a/i18n/ca/_use/designer/lock.md b/i18n/ca/_use/designer/lock.md
new file mode 100644
index 0000000..d370a4a
--- /dev/null
+++ b/i18n/ca/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: El bloqueig del dissenyador
+parent: Dissenyador
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# El bloqueig del dissenyador
+{: .no_toc }
+
+Només edita una persona alhora
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Obtenir el bloqueig
+
+El dissenyador està desactivat fins que l'actives, amb l'interruptor de l'extrem superior dret del dissenyador. En activar-lo, obtens el
+bloqueig: a partir d'aquell moment ets l'única persona que pot desar, fins que el tornis a desactivar.
+
+Sense el bloqueig, el dissenyador mostra **El dissenyador no està actiu**, i no es pot editar res.
+
+Els desaments no se superposen mai: a partir de la 7.3.0, mentre s'executa un desament, un push o una càrrega, un segon **Desa** (un doble clic, o Ctrl+S mantingut) s'ignora,
+de manera que no pot escriure una segona còpia de seguretat o un segon commit que competeixi amb el primer.
+
+---
+
+## Quan el té una altra persona
+
+Mentre un altre usuari té el bloqueig, el dissenyador mostra **{user} està fent servir el dissenyador** amb el nom d'aquest usuari, i res més: ni seccions
+ni fitxers.
+
+L'interruptor apareix activat però en gris, amb **Bloquejat per** i el nom de l'usuari al costat. Pots obtenir el bloqueig quan aquella persona
+desactivi el dissenyador. Tots els dissenyadors oberts ho veuen immediatament quan el bloqueig s'obté o s'allibera, sense recarregar.
+
+Quan dos usuaris activen el dissenyador en el mateix moment, un dels dos obté el bloqueig. A partir de la 7.3.0, l'altre veu qui el té
+i tots els editors queden en només lectura, de manera que no es pot escriure res que no es pugui desar.
+
+---
+
+## Alliberar el bloqueig d'una altra persona
+
+Un administrador pot alliberar un bloqueig que té una altra persona, per exemple quan se n'ha anat a casa amb el dissenyador obert.
+
+**Alliberar**, al costat de **Bloquejat per**, només el veuen els administradors. Abans demana confirmació: es perden els canvis de l'usuari que no s'han desat.
+
+A partir de la 7.3.0, a l'usuari a qui s'ha alliberat el bloqueig se li indica, i qui ho ha fet: **{name} ha alliberat el teu bloqueig del dissenyador** amb el nom de l'administrador,
+i **Els canvis no desats ja no es poden desar.** El seu dissenyador no torna a obtenir el bloqueig pel seu compte; el torna a activar
+quan vol continuar.
+
+---
+
+## Un bloqueig oblidat
+
+Un bloqueig que ningú no fa servir s'allibera sol, de manera que ningú no espera un dissenyador que ningú no té obert.
+
+El dissenyador obert de qui té el bloqueig va dient al servidor que encara hi és. Quan el servidor no en té notícies durant
+5 minuts, perquè s'ha tancat el navegador, s'ha apagat l'ordinador o ha caigut la xarxa, el bloqueig torna a quedar lliure. Quan
+qui el tenia torna al dissenyador, torna a obtenir el bloqueig si ningú altre no l'ha agafat. L'alliberament per part d'un administrador és l'excepció:
+després d'aquest, el bloqueig no es torna a obtenir.
diff --git a/i18n/ca/_use/jobs/actions.md b/i18n/ca/_use/jobs/actions.md
new file mode 100644
index 0000000..cd1eb32
--- /dev/null
+++ b/i18n/ca/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Accions sobre les tasques
+parent: Tasques
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Accions sobre les tasques
+{: .no_toc }
+
+Llança, avorta, rellança, aprova o rebutja, i suprimeix una tasca
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Llançar una tasca
+
+Cada tasca comença amb un formulari. Obre'l des de la pàgina **Formularis**, omple els camps i prem **Envia**:
+
+1. El formulari es valida al navegador, i els valors dels camps s'envien al servidor.
+2. El servidor crea la tasca i en retorna el número; s'executen les accions [`onSubmit`](../forms/job-status-action.html) del formulari.
+3. La sortida de la tasca apareix sota el formulari i s'actualitza cada dos segons fins que la tasca acaba.
+
+La tasca també apareix a la pàgina **Tasques**, on la pots seguir més tard.
+
+### Qui pot llançar un formulari
+
+Un formulari es mostra, i es pot llançar, als usuaris que tenen un dels [rols](../config/roles.html) de la seva llista `roles`.
+El rol `default`, que tenen tots els usuaris, fa que un formulari estigui disponible per a tothom qui pot iniciar la sessió.
+
+### Abans d'enviar
+
+La barra que hi ha a sobre dels camps ofereix unes quantes eines, cadascuna visible només quan el teu rol ho permet:
+
+| Botó | Què fa | Opció de rol |
+|---|---|---|
+| **Mostra les extravars** | Previsualitza les extravars que rebrà la tasca, a mesura que omples els camps | `showExtraVars` |
+| **verbose** | Executa la tasca en mode detallat | `allowVerboseMode` |
+| **Carrega des de les desades** | Omple els camps a partir d'una [tasca desada](stored-jobs.html) | `allowStoredJobs` |
+| **Torna a carregar aquest formulari** | Torna a carregar el formulari, amb els seus valors per defecte | cap |
+
+### Opcions en el moment del llançament
+
+Un formulari pot permetre que els seus usuaris triïn algunes opcions d'Ansible quan el llancen, declarant un camp amb un nom reservat. Llavors
+el valor del camp té prioritat sobre la configuració pròpia del formulari:
+
+| Nom del camp | Té prioritat sobre | Tipus de camp habitual |
+|---|---|---|
+| `__check__` | El mode check, una simulació que no canvia res | `checkbox` |
+| `__diff__` | El mode diff, que mostra què canviaria | `checkbox` |
+| `__limit__` | Els hosts on s'executa el playbook | `text` o `enum` |
+| `__tags__` | Les etiquetes que s'executen | `text` o `enum` |
+| `__inventory__` | L'inventari | `enum` |
+| `__playbook__`, `__template__` | El playbook, o la plantilla d'AWX / AAP | `enum` |
+
+Per exemple, un formulari que ofereix una simulació i un límit d'hosts:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+El servidor només accepta aquests noms d'un formulari que els declara com a camps, de manera que un llançament des de l'API no els pot afegir
+pel seu compte. Les propietats que sobreescriuen es descriuen a [Formularis d'Ansible](../forms/ansible.html) i [Formularis d'AWX](../forms/awx.html).
+
+### Què pot aturar un llançament
+
+Un llançament no sempre es converteix directament en una tasca en execució:
+
+* **Camps no vàlids**: el formulari no s'envia, i cada camp que no passa la validació en mostra el motiu.
+* **Validació del llançament**: amb la [validació del llançament](../launch-validation/) definida a `enforce`, el servidor torna a comprovar els valors
+  i rebutja un llançament que incompleix les regles del formulari.
+* **Aprovació**: un formulari amb un [punt d'aprovació](../forms/approval.html) crea la tasca, que llavors espera amb l'estat
+  `approve`; vegeu [Aprovar o rebutjar una tasca](#approve-or-reject-a-job).
+
+Quan la tasca acaba, les [notificacions](../forms/notifications.html) del formulari envien els seus correus i missatges als canals, i s'executen les seves accions
+segons l'estat de la tasca.
+
+### Altres maneres d'iniciar una tasca
+
+Un formulari també pot iniciar una tasca sense que cap persona premi **Envia**:
+
+| Iniciada per | Com | Pàgina |
+|---|---|---|
+| Executar més tard o una programació cron | **Executa més tard (una vegada)** o **Programa (recurrent)** al costat d'**Envia** | [Programacions](schedules.html) |
+| Un script o un pipeline | `POST /api/v2/job` amb un token d'API | [Tasques de l'API REST](../api/jobs.html) |
+| Un agent d'IA | L'eina `launch_job` del servidor MCP | [Eines MCP](../mcp/tools.html) |
+| Una conversa | L'assistent de xat omple el formulari i el llança | [Assistent de xat](../chat/) |
+| Una tasca anterior | **Rellança**, més avall | [Rellançar una tasca](#relaunch-a-job) |
+
+---
+
+## Avortar una tasca
+
+**Avorta** al menú de la fila (⋮) de la llista, o **Avorta la tasca** a la pàgina de la tasca, atura una tasca amb l'estat `running`. Després que ho confirmis,
+AnsibleForms marca la tasca perquè s'avorti:
+
+* **`ansible`**: l'RTE atura el procés del playbook (amb tots els seus workers), i la tasca acaba com a `aborted` amb
+  `... was aborted by the operator`. Una tasca que encara espera un RTE lliure s'avorta abans de començar.
+* **Una tasca de plantilla** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): AnsibleForms demana al runner que cancel·li o aturi
+  el job, i la tasca acaba com a `aborted`. Quan el runner s'hi nega, la sortida mostra `Abort request denied`, seguit de
+  `reverting abort request`, i la tasca continua executant-se. Un build de Jenkins que encara és a la cua se'n treu.
+* **`workflow`**: les tasques dels nodes en curs s'avorten i no comença res més (vegeu
+  [Executar un workflow](../workflows/running.html#abort)).
+* **`multistep`**: els passos que encara no han començat s'ometen (`skipping: [Abort is requested]`), i la tasca principal
+  acaba com a `aborted`. Un pas que ja s'està executant és una tasca pròpia: obre-la i avorta-la per aturar-la també.
+
+Pots avortar les teves pròpies tasques; un administrador, o a partir de la 7.3.0 un usuari el rol del qual defineix `manageAllJobs`, pot avortar qualsevol tasca. `showAllJobLogs` permet a un
+usuari veure les tasques d'altres usuaris, no avortar-les.
+
+---
+
+## Rellançar una tasca
+
+**Rellança** al menú de la fila (⋮) de la llista, o **Rellança la tasca** a la pàgina de la tasca, inicia una tasca nova a partir d'una d'acabada. S'ofereix en qualsevol
+tasca que no estigui en `running` ni esperant aprovació, als usuaris el rol dels quals defineix l'opció de rol `allowJobRelaunch`.
+
+El diàleg ofereix:
+
+* **Rellança**: torna a executar la tasca amb els valors amb què es va executar, com una tasca nova al teu nom.
+* **Mode detallat**: rellança en mode detallat; es mostra amb l'opció de rol `allowVerboseMode`.
+* **Edita els valors abans de rellançar**, i després **Edita i rellança**: obre el formulari emplenat amb els valors de la tasca, perquè
+  els puguis canviar abans d'enviar.
+
+Un rellançament també requereix que el formulari ho permeti (`allowRelaunch`, true per defecte) i que la tasca sigui **teva**, tret que
+siguis administrador o, a partir de la 7.3.0, tinguis `manageAllJobs`; `showAllJobLogs`, que fins a la 7.2 permetia rellançar qualsevol tasca, ja no ho permet. Com es comprova un rellançament amb les regles del formulari, i per què un formulari amb un
+camp de contrasenya el pot rebutjar, es descriu a [Rellançament](../launch-validation/relaunching.html).
+
+### Rellançar amb dades emplenades
+
+**Edita i rellança** obre el formulari amb el paràmetre d'URL `prefillJobId`, que també pots fer servir en un enllaç propi:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+El formulari carrega els valors dels camps desats amb la tasca `61` i mostra `Formulari emplenat amb les dades de la tasca anterior #61`.
+En enviar-lo s'inicia una tasca nova, comprovada com qualsevol altre llançament. L'emplenament segueix les mateixes regles que un rellançament:
+
+* **Els camps de contrasenya no es desen mai**, de manera que no s'emplenen mai: torna'ls a introduir. Les constants tampoc no es desen.
+* Cal l'opció de rol `allowJobRelaunch`, i la tasca ha de ser teva (o has de ser administrador o tenir `manageAllJobs`).
+* Un formulari amb `allowRelaunch: false` no es pot rellançar ni emplenar:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Una tasca d'abans que es desessin els valors dels camps no es pot emplenar, i el formulari mostra un error:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Aprovar o rebutjar una tasca
+
+Una tasca amb un [punt d'aprovació](../forms/approval.html) s'atura amb l'estat `approve` i espera. Apareix a la pàgina Tasques dels seus
+aprovadors, els usuaris amb un dels rols de l'aprovació, perquè la puguin trobar; a partir de la 7.3.0, els altres usuaris ja no la veuen.
+
+**Revisar l'aprovació** s'ofereix als administradors i als usuaris que tenen un dels rols de l'aprovació: un clic a la fila de la tasca,
+**Revisar l'aprovació** al menú de la fila, o el botó **Revisar l'aprovació** a la pàgina de la tasca. El diàleg mostra el missatge de
+l'aprovació, amb els valors de la tasca inserits (o una línia genèrica si no en té), i el formulari, l'id de la tasca, qui l'ha llançada i
+quan, amb un enllaç a la tasca; **Rebutja** i **Aprova** hi responen:
+
+* **Aprova**: la tasca continua i el seu estat torna a `running`.
+* **Rebutja**: la tasca acaba com a `rejected`, i la seva sortida registra `rejected by <username>`.
+
+Una tasca que espera aprovació no es pot rellançar ni suprimir des de la pàgina Tasques; primer aprova-la o rebutja-la.
+
+A partir de la 7.3.0, l'usuari que ha llançat una tasca no la pot aprovar, de manera que sempre la mira una segona persona, tot i que encara la pot rebutjar per
+retirar-la. Un administrador sempre pot aprovar, també les seves pròpies tasques. Un formulari el punt d'aprovació del qual defineix
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) permet que qui el llança també aprovi la seva pròpia tasca.
+
+---
+
+## Suprimir una tasca
+
+**Suprimeix** al menú de la fila (⋮) de la llista, o **Suprimeix la tasca** a la pàgina de la tasca, suprimeix una tasca amb la seva sortida després que ho confirmis.
+Suprimir una tasca multipas també en suprimeix els passos. Per suprimir diverses tasques alhora, marca-les a la primera columna de la llista i
+fes clic a **Suprimeix (n)** a sobre.
+
+Pots suprimir les teves pròpies tasques. Els administradors i, a partir de la 7.3.0, els usuaris amb l'opció de rol `manageAllJobs` poden suprimir qualsevol tasca; `showAllJobLogs`
+ja no ho permet. Un rol que defineix `allowJobDeletion: false` no suprimeix cap tasca, ni tan sols les pròpies, de manera que l'historial de tasques queda sencer. A la pàgina
+de la tasca, el botó està amagat mentre la tasca s'executa o s'està avortant (excepte per als administradors i `manageAllJobs`) i mentre espera aprovació; a la llista, l'entrada
+del menú i la casella de selecció apareixen en gris per a una tasca que no pots suprimir.
diff --git a/i18n/ca/_use/jobs/cleanup.md b/i18n/ca/_use/jobs/cleanup.md
new file mode 100644
index 0000000..b19e431
--- /dev/null
+++ b/i18n/ca/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Neteja
+parent: Tasques
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Neteja
+{: .no_toc }
+
+Tasques interrompudes per un reinici, i quant de temps es conserven les tasques acabades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tasques abandonades
+
+Una tasca en execució la segueix el procés d'AnsibleForms que l'ha iniciada. Quan aquest seguiment s'atura, la tasca es marca com a
+`abandoned`:
+
+* **En arrencar**, les tasques que aquest procés seguia abans de reiniciar-se, i les tasques d'abans de la 7 que no segueix cap procés,
+  es marquen com a abandonades si encara estan en `running` o avortant-se; el registre mostra `Abandoned <n> jobs`. Una tasca que
+  s'executa en un RTE no es toca: continua sense el procés que l'ha iniciada.
+* **Cada minut**, les tasques que segueix un altre procés d'AnsibleForms (o RTE) que fa 2 minuts que no respon es
+  marquen com a abandonades; el registre mostra `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Cada hora**, les tasques que van començar fa més d'un dia, que encara estan en `running` i que no han escrit cap sortida en un dia es marquen com a abandonades.
+  Una tasca que s'executa en un RTE tampoc no es toca aquí: l'RTE neteja les seves pròpies tasques quan es reinicia.
+
+A partir de la 7.3.0, una tasca de plantilla a AWX, AAP o Ascender que ha quedat abandonada per un reinici o per un node aturat es recupera, si va començar
+en les últimes 24 hores: un procés d'AnsibleForms se n'encarrega, la torna a seguir al runner, i la tasca acaba amb el que
+hi ha passat realment. Les tasques dels altres runners, els playbooks, els workflows i les tasques multipas continuen abandonades.
+
+Un playbook abandonat pot haver-se executat en part. Comprova els hosts gestionats abans de rellançar-lo; vegeu
+[Una tasca mostra l'estat abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Retenció de les tasques
+
+Les tasques es conserven fins que se suprimeixen, tret que l'administrador defineixi un període de retenció.
+
+Amb [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) definit, un procés nocturn (a les 2:30) suprimeix
+les tasques acabades, amb la seva sortida i els seus passos, que van acabar fa més d'aquests dies. Només elimina tasques amb
+l'estat `success`, `failed`, `warning`, `aborted`, `rejected` o `abandoned`, de manera que les tasques en execució i les que esperen
+aprovació es conserven per antigues que siguin. El valor per defecte, `0`, conserva totes les tasques.
diff --git a/i18n/ca/_use/jobs/following.md b/i18n/ca/_use/jobs/following.md
new file mode 100644
index 0000000..e0d850e
--- /dev/null
+++ b/i18n/ca/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Seguir una tasca
+parent: Tasques
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Seguir una tasca
+{: .no_toc }
+
+Sortida en directe, extravars, filtres i baixades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Seguir una tasca
+
+En fer clic en una tasca s'obre la seva pàgina: el formulari de la tasca com a títol, les seves accions a la capçalera i la seva sortida a sota.
+
+![La sortida d'una tasca](../assets/screenshots/job-output.jpg)
+
+A partir de la 7.3.0, la pàgina està formada per targetes, i cadascuna es plega sota la seva capçalera:
+
+| Targeta | Què mostra |
+|---|---|
+| **Resum** | El nom, l'estat i el tipus de la tasca com a capçalera, i les seves dades a sota en una graella de tres columnes (dues, i després una, en una pàgina estreta) |
+| **Workflow** | Per a una tasca de workflow, també una tasca de workflow d'AWX o AAP, el seu graf i el seu nombre de nodes (vegeu [El graf del workflow](#the-workflow-graph)) |
+| **Sortida** | La sortida de la tasca i la seva barra d'eines |
+
+Una tasca que s'ha executat a AWX, AAP, Ascender, Jenkins, Semaphore o Rundeck hi mostra el seu número com un enllaç a la seva pàgina en aquesta eina, que s'obre
+en una pestanya nova. L'enllaç es desa a la tasca, de manera que continua funcionant si més endavant el runner es reanomena o s'elimina.
+
+La pàgina s'actualitza en directe: el servidor envia un esdeveniment cada vegada que es llança una tasca, canvia d'estat, escriu sortida o se
+suprimeix, i la pàgina torna a llegir la tasca, de manera que la sortida creix a mesura que la tasca l'escriu. La llista de tasques s'actualitza de la mateixa manera.
+**Actualitza** torna a carregar la tasca manualment.
+
+Mentre ets al final de la sortida, la pàgina la segueix cap avall a mesura que arriben línies noves. Desplaça't cap amunt per llegir una línia anterior
+i la pàgina es queda on ets: llavors apareix **Ves al més recent** a sobre de la part inferior de la sortida, que es converteix en **Línies noves** quan
+n'arriben més. Fes-hi clic, o torna a baixar fins al final, per tornar a seguir les línies noves. La sortida de la pàgina del formulari, després
+d'**Envia**, i el [registre del servidor](../production/logs.html) segueixen les seves línies noves de la mateixa manera.
+
+La barra d'eines de la sortida té:
+
+| Botó | Què fa |
+|---|---|
+| **Mostra les extravars** | Mostra les extravars amb què s'ha executat la tasca en un panell a sobre de la sortida, amb un selector **JSON** / **YAML** i **Copia** |
+| **Mostra els artefactes** | Mostra els artefactes de la tasca al mateix panell (vegeu més avall) |
+| **Mostra els paràmetres** | Ocupa el lloc de **Mostra les extravars** per a una tasca de Jenkins: els valors amb què s'ha executat, els seus paràmetres de build |
+| **Mostra el payload** | Ocupa el lloc de **Mostra les extravars** per a una tasca de Rundeck: el payload que se li ha enviat |
+| **Hosts i tasques** | Mostra els hosts i les tasques d'un playbook a sobre de la seva sortida (vegeu [Hosts i tasques](#hosts-and-tasks)) |
+| **Actualitza** | Torna a carregar la sortida |
+| **Aplica el filtre** | Amaga les tasques el nom de les quals coincideix amb el filtre de sortida; **Treu el filtre** les torna a mostrar |
+| **Copia la sortida** | Copia la sortida com a text pla, amb el filtre aplicat o no |
+| **Baixa la sortida** | Baixa la sortida com a `ansibleforms-job-<id>.txt` |
+
+**Mostra els artefactes** s'ofereix per a totes les tasques que no són tasques de plantilla, com ara un playbook a l'RTE o un workflow (buit quan
+els seus playbooks no han recollit cap artefacte amb `set_stats`), i per a una tasca de plantilla que s'ha executat a AWX, AAP o Ascender. Les tasques de Semaphore, Rundeck
+i Jenkins no tenen artefactes, així que no s'ofereix mai per a elles.
+
+A l'esquerra de la barra d'eines, el botó **Replega-ho tot** plega totes les seccions de la sortida (cada play i cada tasca) i es converteix en
+**Desplega-ho tot**, que les torna a desplegar.
+
+**Mostra les extravars** requereix l'opció de rol `showExtravars`, i **Mostra els artefactes**, l'opció de rol `showArtifacts` (vegeu
+[opcions de rol](../config/roles.html#role-options)). Els valors dels camps de contrasenya i de les claus que coincideixen amb
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) s'emmascaren.
+
+El filtre el defineix [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), `\[low\]` per
+defecte. Posa `[low]` al nom d'una tasca sorollosa, i **Aplica el filtre** amaga aquesta tasca i les seves línies.
+
+La pàgina d'una tasca multipas mostra tots els passos sota la tasca principal, l'un sota l'altre, cadascun sota una barra de títol com ara
+**Pas 1 · Prepare the server (id de tasca 98)** amb el seu estat. Fes clic en un títol (o prem Retorn o Espai a sobre) per plegar aquella sortida,
+i torna-hi a fer clic per desplegar-la. Els workflows d'AWX/AAP també mostren l'estat dels seus nodes.
+
+Les tasques de [workflow](../workflows/running.html#the-job) guarden la sortida de cada node dins de la seva, sota una capçalera `WORKFLOW NODE` per
+node; dibuixen el seu graf en directe, i un clic en un node n'obre la sortida.
+
+---
+
+## Cercar un text a la sortida
+
+A partir de la 7.3.0, la pàgina de la tasca té un quadre de cerca, **Cerca a la sortida**, a la seva línia de títol, a l'esquerra de les accions de la tasca.
+
+Cada lloc on apareix el text a la sortida es ressalta, sense distingir majúscules i minúscules, i la pàgina es desplaça fins al primer. **Retorn** va al
+següent, que es mostra més marcat, i la barra d'eines indica quin és de quants (**2 de 4**), o **No trobat**. La cerca primer desplega la sortida i
+les seves seccions, i mentre la tasca s'executa també es busca a les línies noves, sense moure la pàgina.
+
+---
+
+## Moure's per una sortida llarga
+
+A partir de la 7.3.0, una sortida llarga, a la pàgina de la tasca i sota un formulari després d'**Envia**, té aquestes maneres de recórrer-la:
+
+| Control | Què fa |
+|---|---|
+| Capçaleres fixes | La capçalera d'una secció (un node de workflow, el playbook de la tasca, un pas d'una tasca multipas) es queda a dalt mentre les seves línies es desplacen |
+| **2 fallides** | Compta les tasques fallides, sense comptar les fallades que s'ha indicat a Ansible que ignori; cada clic va a la següent, desplegada i ressaltada. Sense tasques fallides, **1 error** compta en canvi les línies d'error |
+| Números de línia | Cada número de línia enllaça amb la seva línia, com ara `#L45` a l'adreça: obrir aquesta adreça desplaça fins a la línia i la ressalta |
+| Botons amunt i avall | Es mostren a la part inferior dreta quan s'ha desplaçat la pàgina, per tornar al principi o anar al final |
+| **En execució** i **Avorta** | Mentre la tasca s'executa, la barra de la pàgina del formulari es manté a la part inferior de la finestra, i **Avorta** des d'allà atura la tasca immediatament |
+
+---
+
+## Resultats de les tasques
+
+A partir de la 7.3.0, la línia de resultat d'un host a la sortida d'un playbook obre aquest resultat en un diàleg **Resultat de la tasca**, com fa AWX.
+
+La línia, el cos del resultat que la segueix (`=> { ... }`) i l'error que s'imprimeix abans d'un resultat fallit es ressalten com un sol bloc en passar-hi el ratolí, i un
+clic obre el diàleg. Funciona a la pàgina de la tasca i sota un formulari després d'**Envia**, per a un playbook que s'ha executat en un RTE de la 7.3.0 o
+posterior, ja que el resultat surt dels mateixos esdeveniments que [Hosts i tasques](#hosts-and-tasks). El diàleg té aquestes pestanyes:
+
+| Pestanya | Què mostra |
+|---|---|
+| **Detalls** | L'estat, el host, el play, la tasca, el mòdul, l'element del bucle, l'hora d'inici, la durada, el codi de retorn i el missatge |
+| **JSON** i **YAML** | Tot el resultat del mòdul, amb colors i amb les línies numerades |
+| **Sortida estàndard** i **Error estàndard** | L'`stdout` i l'`stderr` del resultat, quan en té |
+
+El resultat sencer, i amb ell les pestanyes **JSON**, **YAML** i de sortida, només es desa quan la tasca s'executa en mode detallat, ja que llavors la sortida
+també el mostra; si no, el diàleg només mostra els detalls. Fins i tot en mode detallat, els arguments del mòdul (`invocation`) es deixen
+fora, els valors de les claus que semblen un secret s'emmascaren, i un resultat es talla quan supera els 64 KB de JSON.
+
+---
+
+## El graf del workflow
+
+A partir de la 7.3.0, el graf d'un workflow en execució es desplaça per mantenir a la vista el node en curs.
+
+Si allunyes el graf, es queda on l'has deixat, amb un botó **Segueix el node en curs** per tornar-lo a seguir. En passar el ratolí per sobre d'un node
+es mostra la seva targeta amb el nom sencer i es destaquen el node i els seus enllaços, amb la resta del graf atenuada. El graf té els botons **Ajusta a la
+pantalla** i **Pantalla completa**, i sota un formulari després d'**Envia**, un clic en un node n'obre la sortida com a la pàgina de la tasca.
+
+---
+
+## Hosts i tasques
+
+Des de la 7.3.0, una tasca de playbook que s'ha executat en un RTE de la 7.3.0 o posterior registra els seus esdeveniments estructurats al costat de la seva sortida de text: cada play, tasca
+i resultat de host, i el resum final. **Hosts i tasques**, a la barra d'eines de la sortida, els mostra en un panell a sobre de la sortida, a la pàgina de la tasca i
+sota un formulari després d'**Envia**. S'ofereix quan la tasca té esdeveniments, i el panell es torna a llegir cada pocs segons mentre la tasca s'executa:
+
+| Vista | Què mostra |
+|---|---|
+| **Graella** | El resum per host (ok, changed, failed, unreachable, skipped, rescued, ignored), i després una graella d'hosts per tasques: cada cel·la té el color del resultat del host per a aquella tasca, amb el seu missatge i el seu temps en passar-hi el ratolí, o *no executada* |
+| **Cronologia** | Cada tasca com una barra, tan llarga com el que ha trigat el seu host més lent, amb el seu temps en segons i el total |
+
+La sortida de text es queda tal com és. Els esdeveniments els escriu el plugin de callback `af_events` propi de l'RTE, de manera que el playbook no necessita cap canvi.
diff --git a/i18n/ca/_use/jobs/index.md b/i18n/ca/_use/jobs/index.md
new file mode 100644
index 0000000..3702994
--- /dev/null
+++ b/i18n/ca/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Tasques
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Tasques
+{: .no_toc }
+
+Segueix, avorta, rellança, aprova i suprimeix les tasques que inicien els teus formularis
+{: .fs-6 .fw-300 }
+
+---
+
+Per a tothom qui llança formularis: què és una tasca, on trobar-la i qui la pot veure.
+
+---
+
+## Què és una tasca
+
+Una tasca és una execució d'un formulari: AnsibleForms la registra amb el seu estat, les seves extravars i la seva sortida tan bon punt s'envia el formulari.
+
+Cada tasca conserva:
+
+* el **formulari** que ha executat i l'**usuari** que l'ha llançada (amb el tipus d'usuari, com ara `local` o `ldap`);
+* el seu **tipus de tasca** i el seu **estat**, i la seva **hora d'inici** i **hora de finalització**;
+* la seva **sortida**, les extravars i les credencials amb què s'ha executat, i els valors dels camps introduïts al formulari.
+
+Un formulari multipas crea una tasca per al formulari i una tasca per a cada pas. Els passos estan enllaçats a la tasca principal i es mostren a sota.
+
+Les mateixes tasques es poden llançar, seguir i gestionar a través de l'[API REST](../api/jobs.html).
+
+---
+
+## La pàgina Tasques
+
+L'enllaç **Tasques** de la capçalera obre la llista de totes les tasques, de la més recent a la més antiga (`/jobs/all`). La pàgina i el seu enllaç es mostren als usuaris
+el rol dels quals defineix l'[opció de rol](../config/roles.html#role-options) `showJobs`.
+
+![La llista de tasques](../assets/screenshots/job-log.jpg)
+
+El menú de l'esquerra ordena les tasques en el temps, amb el nombre de tasques de cada entrada; una entrada d'estat filtra la llista per aquest estat:
+
+| Secció | Entrada del menú | Mostra |
+|---|---|---|
+| **Passat** | **Correctes** | Tasques amb l'estat `success` |
+| | **Fallides** | Tasques amb l'estat `failed` |
+| | **Avortades** | Tasques amb l'estat `aborted` |
+| | **Rebutjat** | Tasques amb l'estat `rejected` |
+| | **Abandonat** | Tasques amb l'estat `abandoned` |
+| **Present** | **En execució** | Tasques amb l'estat `running` |
+| | **Esperant aprovació** | Tasques amb l'estat `approve`; el comptador es torna taronja quan n'hi ha una d'esperant |
+| **Futur** | **Programats** | La pàgina [Programacions](schedules.html) (opció de rol `allowScheduledJobs`) |
+| | **Desats** | La pàgina [Tasques desades](stored-jobs.html) (opció de rol `allowStoredJobs`) |
+
+El menú no té cap entrada per a totes les tasques: l'enllaç **Tasques** de la capçalera les mostra totes, incloses les tasques `warning`.
+
+A sobre de la taula, a la línia del títol:
+
+* el **quadre de cerca** conserva les tasques les columnes visibles de les quals contenen el text (sense distingir majúscules i minúscules), o un dels passos de les quals el té com a id
+  o destinació;
+* **Suprimeix** (amb el nombre de tasques marcades) suprimeix juntes les tasques marcades a la primera columna;
+* **Columnes** mostra o amaga les columnes `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` i `user`;
+  la durada d'una tasca en execució va comptant;
+* **Actualitza** torna a carregar la llista.
+
+La llista carrega les tasques més recents, tantes com indiqui l'opció [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)
+(**Configuració > Sistema > General**, pestanya **Tasques**, `1000` per defecte); les seves pàgines, la cerca i els filtres cobreixen aquestes tasques.
+
+Cada columna es pot ordenar i té el seu propi camp de filtre. Una tasca multipas té una fletxa just abans del seu `form` que desplega
+els seus passos; un clic a la resta d'una fila obre la tasca.
+
+La campaneta de la capçalera compta les tasques que esperen la teva aprovació i obre la llista a **Esperant aprovació**. Per als usuaris que poden veure
+els runners, també compta els [runners pendents d'aprovació](../runners/registration.html#approving-an-rte), RTE que han demanat unir-se,
+i obre **Connexions > Runners** quan només esperen runners. Si n'hi ha de tots dos tipus, obre un menú, **Feines pendents d'aprovació** i
+**Runners pendents d'aprovació**, cadascun amb el seu comptador.
+
+---
+
+## Qui veu quines tasques
+
+Les tasques que veu un usuari depenen dels seus rols:
+
+| Usuari | Veu |
+|---|---|
+| Administrador (rol `admin`) | Totes les tasques |
+| Opció de rol `showAllJobLogs` | Totes les tasques |
+| Opció de rol `manageAllJobs` (a partir de la 7.3.0) | Totes les tasques, i les pot avortar, suprimir i rellançar |
+| Qualsevol altre usuari | Les seves pròpies tasques, i les tasques que esperen una aprovació que indica un dels seus rols |
+
+Fins a la 7.2, qualsevol usuari podia obrir qualsevol tasca pendent d'aprovació, incloses les seves extravars i la seva sortida; a partir de la 7.3.0 només ho poden fer el seu propietari i els seus
+aprovadors. Veure una tasca no dona dret a totes les accions sobre ella: avortar, suprimir i rellançar la tasca d'un altre usuari requereix ser administrador o tenir
+`manageAllJobs`, i `showAllJobLogs` només mostra les tasques. Per suprimir també cal `allowJobDeletion`, i per rellançar, `allowJobRelaunch`.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Estats i tipus](statuses.html) | Tots els estats que pot tenir una tasca, i els tipus de tasca |
+| [Seguir una tasca](following.html) | Sortida en directe, extravars, filtres i baixades |
+| [Accions sobre les tasques](actions.html) | Llançar, avortar, rellançar, aprovar o rebutjar, i suprimir una tasca |
+| [Programacions](schedules.html) | Executar un formulari més tard o segons una programació cron, i gestionar totes les programacions |
+| [Tasques desades](stored-jobs.html) | Guardar les dades d'un formulari per tornar-les a carregar més tard |
+| [Neteja](cleanup.html) | Tasques interrompudes per un reinici, i quant de temps es conserven les tasques acabades |
diff --git a/i18n/ca/_use/jobs/schedules.md b/i18n/ca/_use/jobs/schedules.md
new file mode 100644
index 0000000..5af029d
--- /dev/null
+++ b/i18n/ca/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Programacions
+parent: Tasques
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Programacions
+{: .no_toc }
+
+Executa un formulari més tard o segons una programació cron, i gestiona totes les programacions
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les accions del formulari
+
+Un formulari pot fer més que executar-se immediatament: el desplegable que hi ha al costat del seu botó **Envia** conté tres accions més.
+
+| Acció | Què fa | Opció de rol |
+|---|---|---|
+| **Programa (recurrent)** | Crea una programació que executa el formulari segons una expressió cron | `allowScheduledJobs` |
+| **Executa més tard (una vegada)** | Crea una programació que executa el formulari una vegada, a la data i l'hora que triïs | `allowPlannedJobs` |
+| **Desa** | Desa els valors dels camps, per tornar-los a carregar al formulari més tard | `allowStoredJobs` |
+
+Una acció l'opció de rol de la qual està desactivada no es mostra. El formulari es valida abans de qualsevol d'elles, igual que per a **Envia**. Totes dues
+accions de programació creen una entrada a la pàgina **Programacions**; **Desa** crea una entrada a la pàgina **Tasques desades**. La
+barra lateral de la pàgina [Tasques](./) les obre a **Futur**, com a **Programats** i **Desats**. Les opcions de rol es descriuen
+a [Opcions de rol](../config/roles.html#role-options).
+
+{: .warning }
+> Tracta `allowScheduledJobs` com una opció de nivell d'administrador. Les seves programacions no pertanyen a l'usuari que les ha creat: tots els usuaris
+> amb l'opció veuen i poden canviar totes les programacions. A més, una programació d'aquestes s'executa amb drets d'administrador, per a qualsevol formulari, sigui quin sigui
+> l'accés propi de qui l'ha creada. Concedeix-la només a rols en què confiaries com a administradors.
+
+{: .note }
+> **Executa més tard (una vegada)** només necessita `allowPlannedJobs`. Per a un usuari sense `allowScheduledJobs`, planifica una execució **com a aquest
+> usuari**: el servidor comprova que l'usuari pugui executar el formulari, i la tasca s'executa com a ell, i és seva, quan arriba l'hora
+> (vegeu [Execucions planificades](#planned-runs)).
+
+---
+
+## Programar un formulari
+
+Omple el formulari, obre el desplegable que hi ha al costat d'**Envia** i tria una de les accions de programació.
+
+- **Programa (recurrent)** obre **Crea una programació**: introdueix un **Nom** i una **Expressió cron** (la per defecte, `0 0 * * *`,
+  s'executa cada dia a mitjanit), i després selecciona **Crea una programació**.
+- **Executa més tard (una vegada)** obre **Executa més tard**: introdueix un **Nom** i tria la data i l'hora a **Executa el**, i després selecciona
+  **Programa la tasca**.
+
+El nom ha de ser únic entre totes les programacions. La programació conserva el nom del formulari i una còpia de les extravars que ha produït el formulari
+en aquell moment, escrites en YAML; cada execució fa servir aquesta còpia, així que edita-la a la pàgina **Programacions** per canviar el que rep la tasca.
+
+![Programacions](../assets/screenshots/schedules.jpg)
+
+---
+
+## La pàgina Programacions
+
+La pàgina **Programacions** mostra totes les programacions, amb la seva columna **Activat** a partir de la 7.3.0, i necessita `allowScheduledJobs`. El menú de cada fila ofereix:
+
+| Acció | Què fa |
+|---|---|
+| **Edita** | Canvia el nom, el tipus, l'expressió cron o l'hora d'execució, el formulari i les extra vars |
+| **Executa ara** | Executa la programació ara, sense esperar la seva expressió cron o la seva hora d'execució |
+| **Activa** o **Desactiva** | Activa o desactiva la programació, segons correspongui, tal com mostra la seva columna **Activat** (a partir de la 7.3.0) |
+| **Suprimeix** | Elimina la programació; deixa d'executar-se immediatament |
+| **Darrera sortida** | A la pàgina de la programació, el que ha informat l'última execució, com ara el número de la tasca que ha iniciat |
+
+Aquí també es pot crear una programació des de zero. Tria el **Formulari** i, després, o bé marca **Execució única** i defineix
+**Executa el**, o bé deixa-ho sense marcar i defineix una **Programació** cron. **Extra vars** és YAML sense cap formulari que l'ompli, així que afegeix-hi
+tu mateix els valors que necessita el playbook, com a diccionari (parelles clau: valor).
+
+El camp de la **Programació** cron és un editor de cron: descriu l'expressió amb paraules, ofereix valors predefinits i previsualitza les properes
+execucions. El servidor rebutja una expressió que no pot executar, o una que no es pot produir mai.
+
+A partir de la 7.3.0, cada programació té un interruptor **Activat**, per posar-la en pausa sense suprimir-la. Una programació desactivada es queda a la pàgina
+amb la seva configuració, però no s'executa sola: una de recurrent se salta els seus tics de cron, i una d'única espera passat el seu
+**Executa el** fins que es torna a activar. **Executa ara** encara l'executa a demanda. Una programació nova està activada, i les programacions
+que existien abans de la 7.3.0 queden activades després de l'actualització.
+
+---
+
+## Expressions cron i zona horària
+
+Una programació recurrent admet una expressió cron estàndard de 5 camps: minut, hora, dia del mes, mes i dia de la setmana.
+
+| Expressió | S'executa |
+|---|---|
+| `*/15 * * * *` | Cada 15 minuts |
+| `0 2 * * *` | Cada dia a les 02:00 |
+| `30 7 * * 1-5` | De dilluns a divendres a les 07:30 |
+| `0 0 1 * *` | A mitjanit del primer dia de cada mes |
+
+Trobaràs més exemples, i les funcions de cron que l'editor no accepta, a les PMF, a
+[Quines expressions cron puc fer servir?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Les programacions cron s'executen a la zona horària del servidor, definida amb [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (per defecte `UTC`),
+> no a la zona horària del teu perfil ni del teu navegador. L'editor de cron previsualitza les properes execucions en aquesta mateixa zona.
+
+---
+
+## Com s'executa una programació
+
+Quan arriba l'hora d'una programació, es posa a la cua, i el servidor inicia les programacions de la cua d'una en una, comprovant la cua cada 10 segons.
+
+- Les programacions **recurrents** se salten un tic mentre l'execució anterior encara és a la cua o en execució, de manera que les execucions no se superposen mai.
+- Les programacions **úniques** s'executen durant el minut següent a **Executa el**, i després se suprimeixen, també quan s'inicien amb **Executa ara**.
+- L'**Estat** és `success` quan s'ha iniciat la tasca i `failed` quan no s'ha pogut iniciar. Un `success` només diu que la tasca s'ha
+  llançat: obre la tasca per veure com ha acabat.
+
+Una programació creada amb `allowScheduledJobs` s'executa com l'usuari integrat `Schedule Service` (tipus `schedule`) amb el
+rol `admin`. Pot executar qualsevol formulari, sigui quin sigui l'accés de la persona que ha creat la programació, i `ansibleforms_user` a
+les seves extravars descriu aquest usuari. Una [execució planificada](#planned-runs), en canvi, s'executa com l'usuari que l'ha planificada.
+
+La tasca també rep un objecte `schedule` (amb el seu `id`, `name` i `form`), de manera que un playbook sap que l'ha iniciat una programació:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Execucions planificades
+
+**Executa més tard (una vegada)** per part d'un usuari sense `allowScheduledJobs` crea una execució planificada: una programació única lligada a aquest usuari.
+
+- **Quan es planifica**, el servidor comprova que l'usuari pugui executar el formulari (els seus `roles`), i el mode detallat necessita
+  `allowVerboseMode`. Una execució planificada és sempre única; una expressió cron es rebutja.
+- **Amb la validació del llançament a `enforce`**, els valors dels camps es comproven en planificar-la, de manera que una execució que es rebutjaria es
+  rebutja mentre l'usuari encara hi és al davant.
+- **Quan s'executa**, la tasca s'executa com a aquest usuari, i és seva, amb les mateixes comprovacions que un llançament des del navegador: els
+  rols del formulari tal com són en aquell moment, les extravars reservades eliminades i la validació del llançament. `ansibleforms_user` el descriu.
+
+Qui la planifica no veu la pàgina **Programacions**, que necessita `allowScheduledJobs`; la tasca apareix al seu propi historial de tasques.
+
+---
+
+## Quan el formulari canvia
+
+Una programació fa referència al seu formulari pel nom i l'executa tal com està definit en el moment de cada execució.
+
+- **El formulari s'edita**: la següent execució fa servir la nova definició (playbook, plantilla, inventari) amb les extravars desades a
+  la programació. El formulari no es renderitza, així que no es recalcula cap camp; edita les extra vars de la programació perquè hi coincideixin.
+- **El formulari es reanomena o s'elimina**: l'execució falla, l'**Estat** passa a `failed` i la **Darrera sortida** diu
+  `Failed to launch : No such form '<name>'`. Edita la programació i tria el formulari correcte, o suprimeix-la.
+
+---
+
+## Tasques programades a l'historial de tasques
+
+Cada execució d'una programació crea una tasca normal, que apareix a la pàgina [Tasques](./) amb `Schedule Service` com a usuari o,
+per a una execució planificada, amb l'usuari que l'ha planificada.
+
+Una tasca de `Schedule Service` no pertany a la persona que ha creat la programació, de manera que només la veuen els administradors i
+els usuaris amb `showAllJobLogs`; la tasca d'una execució planificada també la veu el seu usuari. La **Darrera sortida** de la programació indica la tasca que ha iniciat, perquè la puguis trobar a la llista.
diff --git a/i18n/ca/_use/jobs/statuses.md b/i18n/ca/_use/jobs/statuses.md
new file mode 100644
index 0000000..7f0e49c
--- /dev/null
+++ b/i18n/ca/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Estats i tipus
+parent: Tasques
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Estats i tipus
+{: .no_toc }
+
+Tots els estats que pot tenir una tasca, i els tipus de tasca
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Estats de les tasques
+
+AnsibleForms assigna els estats següents a una tasca. La llista mostra cada estat com una etiqueta de color:
+
+| Estat | Significat | Què pots fer |
+|---|---|---|
+| `running` | La tasca s'està executant, o una tasca aprovada s'ha reprès | Seguir-ne la sortida, avortar-la |
+| `approve` | La tasca espera en un [punt d'aprovació](../forms/approval.html) abans d'executar-se (o abans d'un pas d'un multistep) | Aprovar-la o rebutjar-la, si un dels teus rols és aprovador |
+| `success` | El playbook, la plantilla o tots els passos han acabat sense errors | Veure'n la sortida, rellançar-la, suprimir-la |
+| `failed` | La tasca ha acabat amb un error, o ha fallat el llançament mateix | Veure'n la sortida per saber per què, rellançar-la, suprimir-la |
+| `warning` | Un multistep ha acabat, però ha fallat un pas que té `continue` definit | Veure'n la sortida, rellançar-la, suprimir-la |
+| `aborted` | La tasca s'ha avortat des d'AnsibleForms, o s'ha cancel·lat el job d'AWX / AAP | Veure'n la sortida, rellançar-la, suprimir-la |
+| `rejected` | Un aprovador ha rebutjat la tasca; no s'ha executat mai | Veure'n la sortida, rellançar-la, suprimir-la |
+| `abandoned` | AnsibleForms ha deixat de seguir la tasca (vegeu [Tasques abandonades](cleanup.html#abandoned-jobs)) | Comprovar els hosts gestionats, rellançar-la, suprimir-la |
+
+`running` és blau, `success` és verd i diu **Correctes**, i `failed` és vermell. `approve` és taronja i diu **Esperant aprovació**,
+de manera que una tasca que espera una persona es distingeix de les aturades; `warning`, `aborted` i `rejected` són ambre. `abandoned` és
+gris: ningú no l'ha aturada, el que l'executava ha desaparegut.
+
+---
+
+## Tipus de tasca
+
+El tipus de tasca segueix el `type` del formulari que ha iniciat la tasca, tal com el mostren la llista i la pàgina de la tasca:
+
+| Tipus que es mostra | Què s'executa |
+|---|---|
+| `ansible` | Un playbook d'Ansible, executat en un RTE |
+| `awx`, `aap`, `ascender` | Una plantilla de job o una plantilla de workflow a AWX, AAP o Ascender |
+| `semaphore` | Una plantilla a Semaphore UI |
+| `rundeck`, `jenkins` | Un job a Rundeck o Jenkins |
+| `workflow` | Un [workflow](../workflows/), els nodes de playbook del qual s'executen com a tasques pròpies a sota |
+| `multistep` | Obsolet, fes servir `workflow`: una seqüència de passos, cadascun registrat com a tasca pròpia sota la tasca principal |
+
+Una tasca de plantilla es desa com una tasca `awx` (també a l'API REST) i es mostra amb el tipus de runner on s'ha executat, digui el que digui
+el formulari: un formulari de tipus `awx` que s'executa en un runner d'AAP mostra `aap`.
+
+Consulta [Formularis d'Ansible](../forms/ansible.html), [Formularis d'AWX](../forms/awx.html), [Formularis de workflow](../forms/workflow.html) i
+[Formularis multipas](../forms/multistep.html) per a la part del formulari.
diff --git a/i18n/ca/_use/jobs/stored-jobs.md b/i18n/ca/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..220dc42
--- /dev/null
+++ b/i18n/ca/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Tasques desades
+parent: Tasques
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Tasques desades
+{: .no_toc }
+
+Guarda les dades d'un formulari per tornar-les a carregar més tard
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tasques desades
+
+Les tasques desades guarden els valors d'un formulari perquè els puguis tornar a carregar, en lloc d'omplir els mateixos camps cada vegada.
+
+Per desar, omple el formulari, obre el desplegable que hi ha al costat d'**Envia** i tria **Desa**. A **Desa les dades del formulari**, introdueix un
+**Nom**, una **Descripció** opcional i una data a **Caduca el (opcional)**, i desa. Els camps de contrasenya i de constant
+no es desen mai. Un subformulari té la mateixa acció **Desa** al costat del seu botó per desar, i guarda els valors inacabats sense
+validar-los.
+
+Per carregar, selecciona **Carrega des de les desades** a la part superior del formulari. **Carrega un formulari desat** mostra les teves tasques desades per a aquest formulari, amb
+les seves dates de creació i de caducitat; selecciona'n una per omplir el formulari amb els seus valors. No s'executa res fins que l'envies.
+
+Les tasques desades es guarden a la base de dades d'AnsibleForms (taula `stored_jobs`), amb el nom del formulari, el teu usuari com a
+`<type>/<username>` (per exemple `local/admin`) i els valors en JSON. Un nom ha de ser únic per usuari i formulari; desar-ne
+un segon amb el mateix nom falla amb "A saved form with this name already exists".
+
+---
+
+## Gestionar les tasques desades
+
+La pàgina **Tasques desades** mostra les tasques desades amb el seu formulari, l'usuari i les dates de creació i de caducitat, i necessita `allowStoredJobs`.
+
+- **Edita** obre la pàgina pròpia de la tasca desada: els seus **Detalls** (nom, formulari, caducitat) i els seus **Valors**, els valors
+  dels camps desats en YAML, que s'hi poden canviar i desar.
+- **Obre al formulari** obre el seu formulari amb els valors desats emplenats; no s'executa res fins que l'envies.
+- **Suprimeix** l'elimina. Pots suprimir les teves pròpies tasques desades; els usuaris amb `showSettings` en poden suprimir qualsevol.
+- Les tasques desades amb una data a **Caduca el** ja passada se suprimeixen automàticament cada dia a les 04:00 (a `LOG_TZ`).
diff --git a/i18n/ca/_use/profile/account.md b/i18n/ca/_use/profile/account.md
new file mode 100644
index 0000000..99e8968
--- /dev/null
+++ b/i18n/ca/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Compte
+parent: El teu perfil
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Compte
+{: .no_toc }
+
+Amb quin usuari has iniciat la sessió
+{: .fs-6 .fw-300 }
+
+---
+
+La vista Compte mostra amb quin usuari has iniciat la sessió i què determina el teu accés:
+
+- **Nom d'usuari** i **Tipus d'inici de sessió**: un compte local, LDAP, Microsoft Entra ID o OpenID Connect.
+- **Grups**: els grups que vénen amb el teu inici de sessió, com ara `local/admins` o `ldap/Domain Admins`.
+- **Rols**: els rols de `config.yaml` que coincideixen amb aquests grups i amb el teu usuari. Determinen
+  quins formularis veus i quines opcions tens.
diff --git a/i18n/ca/_use/profile/api-token.md b/i18n/ca/_use/profile/api-token.md
new file mode 100644
index 0000000..d121fc5
--- /dev/null
+++ b/i18n/ca/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Token d'API
+parent: El teu perfil
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# Token d'API
+{: .no_toc }
+
+Crea un token per a scripts i agents d'IA
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Qui en pot crear un
+
+Un token de llarga durada permet que els scripts cridin l'API sense la teva contrasenya. A partir de la 7.3.0 necessita l'opció de rol `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Fins a la 7.2.0, l'opció era només `extendedTokenExpiration`. A un rol d'abans de la 7.3.0 que només defineix aquesta opció se li dona
+`allowApiTokens`, de manera que conserva els seus tokens; amb totes dues, també es pot crear un token que no caduqui mai. Vegeu [Opcions de rol](../config/roles.html#role-options).
+
+---
+
+## Crear un token
+
+**Nou token**, a la línia del títol de **Perfil > Tokens d'API**, obre un assistent en tres passos:
+
+1. **Detalls**: un nom, perquè reconeguis el token a la llista, i quant de temps és vàlid. Les opcions són 30, 90, 180
+   o 365 dies fins a [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 per defecte), aquest
+   mateix màxim, i **No caduca mai** amb `extendedTokenExpiration`. Tria el període més curt que necessiti el teu script.
+2. **Confirma**: un compte local o d'LDAP introdueix la seva contrasenya, que no es desa al token. Un compte de Microsoft Entra ID o
+   d'OIDC no té contrasenya aquí: el seu token es crea a partir de la seva sessió, que ha d'haver iniciat la sessió com a màxim 10 minuts
+   abans, així que el proveïdor et pot demanar primer que tornis a iniciar la sessió.
+3. **Copia**: el token, que es mostra **només un cop**. Copia'l amb **Copia** i guarda'l amb la mateixa cura que una contrasenya.
+
+Envia el token a la capçalera `Authorization` de cada crida a l'API:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Un token d'API no en pot crear un altre. El token d'un compte SSO porta els rols del seu últim inici de sessió: un canvi de grup al
+proveïdor d'identitat només hi arriba quan tornes a iniciar la sessió i crees un token nou.
+
+---
+
+## Els teus tokens
+
+Els tokens que has creat es mostren amb el seu nom i amb quan es va crear cadascun, quan caduca i quan es va fer servir per última vegada; **Revoca** al menú d'una fila n'invalida un.
+Un administrador també els veu i els revoca a la teva pàgina a **Configuració > Usuaris**. Un token deixa de funcionar quan caduca, o abans:
+
+- **en revocar-lo**, des de la llista;
+- **en tancar la sessió amb el token** (`POST /api/v2/auth/logout` amb el token a la capçalera `Authorization`), cosa que l'invalida juntament amb
+  la sessió en què es va crear;
+- **en canviar la contrasenya**, cosa que invalida tots els tokens i les sessions del teu compte creats abans, i en bloquejar el teu compte.
+
+Un token que no caduca mai també deixa de funcionar en aquests casos. Un script també pot demanar un token pel seu compte a través de l'API d'inici de sessió i
+el seu paràmetre `expiryDays` (`POST /api/v2/auth/login?expiryDays=90`, o `expiryDays=never`); un `expiryDays` més llarg es retalla
+a `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/ca/_use/profile/index.md b/i18n/ca/_use/profile/index.md
new file mode 100644
index 0000000..e83d16d
--- /dev/null
+++ b/i18n/ca/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: El teu perfil
+nav_order: 4
+description: El teu compte, preferències, contrasenya, permisos i tokens d'API
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# El teu perfil
+{: .no_toc }
+
+El teu compte, les preferències, la contrasenya, els permisos i els tokens d'API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per a tots els usuaris: el teu propi compte, les preferències, la contrasenya, els permisos i els tokens d'API.
+
+Obre el teu perfil des de l'avatar de la part superior dreta: **Perfil**.
+
+---
+
+## Obrir una vista
+
+El menú de l'esquerra mostra les vistes del perfil per ordre alfabètic. Cada vista té la seva pròpia adreça,
+de manera que hi pots enllaçar directament:
+
+| Vista | Adreça |
+|---|---|
+| Compte | `/profile/account` |
+| Tokens d'API | `/profile/token` |
+| Contrasenya | `/profile/password` |
+| Permisos | `/profile/permissions` |
+| Preferències | `/profile/preferences` |
+
+`/profile` sol obre la primera vista del menú. Les vistes que els teus rols no permeten estan amagades; la seva adreça obre la primera
+vista. **Tokens d'API** només es mostra quan un dels teus rols té l'opció de rol `allowApiTokens`.
+
+---
+
+## En aquesta secció
+
+Cada tema es descriu a la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Compte](account.html) | Amb quin usuari has iniciat la sessió |
+| [Preferències](preferences.html) | Idioma, tema, zona horària, format de data i notificacions d'escriptori |
+| [Contrasenya](password.html) | Canviar la contrasenya d'un compte local |
+| [Permisos](permissions.html) | Què et permeten fer els teus rols |
+| [Tokens d'API](api-token.html) | Crear un token per a scripts i agents d'IA |
diff --git a/i18n/ca/_use/profile/password.md b/i18n/ca/_use/profile/password.md
new file mode 100644
index 0000000..de13688
--- /dev/null
+++ b/i18n/ca/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Contrasenya
+parent: El teu perfil
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Contrasenya
+{: .no_toc }
+
+Canvia la contrasenya d'un compte local
+{: .fs-6 .fw-300 }
+
+---
+
+Introdueix la teva contrasenya actual i la nova dues vegades, i després fes clic a **Canvia la contrasenya**.
+
+Els comptes d'LDAP, Entra ID i OpenID Connect canvien la contrasenya amb el seu proveïdor.
diff --git a/i18n/ca/_use/profile/permissions.md b/i18n/ca/_use/profile/permissions.md
new file mode 100644
index 0000000..85a3c27
--- /dev/null
+++ b/i18n/ca/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Permisos
+parent: El teu perfil
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Permisos
+{: .no_toc }
+
+Què et permeten fer els teus rols
+{: .fs-6 .fw-300 }
+
+---
+
+Les opcions de rol s'agrupen en pestanyes, cadascuna amb quantes de les seves opcions tens, com ara `5/8`:
+
+| Pestanya | Opcions sobre |
+|---|---|
+| **Accés i integracions** | L'inici de sessió, l'assistent de xat, el servidor MCP, la pujada de fitxers i els tokens d'API |
+| **Dissenyador** | Obrir el dissenyador, i editar formularis, playbooks, workflows, inventaris i fitxers de variables |
+| **Tasques** | Veure les tasques i les seves extravars o els seus artefactes, i rellançar, suprimir, programar i desar tasques |
+| **Configuració** | Les pàgines de configuració, els registres, el registre d'auditoria i les còpies de seguretat |
+| **Altres** | Una opció definida a mà en un rol que no és a cap altra pestanya; sempre és l'última pestanya |
+
+Les altres pestanyes estan per ordre alfabètic. Cada pestanya és una taula amb les columnes **Opció** (l'opció), **Descripció**
+(què fa) i **El teu accés**: **Permès** o **No permès**. Una opció que s'aplica a causa d'una altra ho indica
+sota la seva descripció: **Inclosa a** una opció que tens l'activa, i **Necessita** una opció que no tens la manté desactivada.
+
+Les opcions surten de les `options` dels teus rols a `config.yaml`; la pàgina [Rols](../config/roles.html) explica com
+es combinen.
diff --git a/i18n/ca/_use/profile/preferences.md b/i18n/ca/_use/profile/preferences.md
new file mode 100644
index 0000000..5c8c8e1
--- /dev/null
+++ b/i18n/ca/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Preferències
+parent: El teu perfil
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Preferències
+{: .no_toc }
+
+Idioma, tema, zona horària, format de data i notificacions d'escriptori
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les preferències
+
+La vista Preferències canvia com veus AnsibleForms. Cada opció es desa al navegador
+on la tries, de manera que un altre navegador o un altre ordinador comença amb els valors per defecte.
+
+| Opció | Valors | També es defineix des de |
+|---|---|---|
+| Idioma | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (japonès), 简体中文 (xinès simplificat) | la bandera de la capçalera |
+| Tema | Segueix el navegador, Clar, Fosc, o Color (una capçalera del color que triïs) | la icona del sol de la capçalera |
+| Vista dels formularis | Mosaic o Llista | el botó de la pàgina Formularis |
+| Zona horària | UTC, la zona d'aquest navegador, o qualsevol zona pel nom | només aquí |
+| Format de data | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY` | només aquí |
+| Notificacions d'escriptori | Activades o desactivades | només aquí |
+
+A partir de la 7.3.0, la vista està en pestanyes, cadascuna amb la seva pròpia adreça (`/profile/preferences/<tab>`): **Aparença** (idioma, tema i vista
+dels formularis), **Data i hora** (zona horària i format de data) i **Notificacions**. El quadre de cerca que hi ha a sobre mostra les opcions que coincideixen
+sota el nom de la seva pestanya. Una opció és un esborrany fins que fas **Desa**, i si surts de la vista amb un canvi sense desar, primer t'ho pregunta.
+
+**Segueix el navegador** canvia a clar o fosc segons el navegador, i canvia quan ell canvia. És el tema per defecte a partir de la 7.3.0, tret que el teu
+administrador en triï un altre. En passar el ratolí per sobre d'un color del tema **Color**, aquí o al menú de temes de la capçalera, es previsualitza l'aplicació amb aquell
+color, i el tema anterior torna quan el punter surt de la paleta; no canvia res fins que fas clic.
+
+---
+
+## Notificacions d'escriptori
+
+A partir de la 7.3.0, la pestanya **Notificacions** activa les notificacions d'escriptori en aquest navegador, per als usuaris el rol dels quals defineix `showJobs`.
+
+El navegador demana permís la primera vegada. Quan bloqueja les notificacions per al lloc, l'interruptor es queda desactivat i explica com
+permetre-les, i un lloc amb `http` sense xifrar no les pot mostrar de cap manera. Un cop activades, arriba una notificació:
+
+| Quan | Què diu | Un clic a sobre |
+|---|---|---|
+| Acaba una tasca que has llançat tu | El formulari i el seu resultat, com ara *Patch Linux servers: Correctes*, amb el número de la tasca i la durada | Porta la pestanya al davant, sobre aquella tasca |
+| Una tasca espera la teva aprovació | El formulari, el número de la tasca i qui l'ha llançada, amb els botons **Aprova** i **Rebutja** | Obre les tasques pendents d'aprovació |
+
+Els botons **Aprova** i **Rebutja** es mostren a Chrome i Edge; Firefox i Safari mostren la notificació sense ells, i el mateix passa amb un
+lloc amb un certificat autosignat, ja que els botons necessiten un service worker. Les notificacions només arriben mentre hi ha una pestanya d'AnsibleForms oberta,
+encara que sigui en segon pla: no s'envia res un cop tancades totes les pestanyes. Cadascuna es mostra un sol cop, per moltes pestanyes que hi hagi obertes, i els passos d'una
+tasca multipas i la tasca que estàs mirant no en generen.
+
+---
+
+## Zona horària
+
+Les dates i les hores de tot AnsibleForms es mostren a la zona horària que seleccionis. Això inclou les hores d'inici
+i de finalització de les tasques, el registre d'auditoria, la pàgina d'estat, les còpies de seguretat, les tasques desades i la caducitat d'un token
+d'API. En canviar la zona horària s'actualitzen totes les pàgines immediatament, sense recarregar.
+
+Fins que en triïs una, s'aplica la zona horària que el teu administrador ha definit per a tothom (**Configuració > Aparença > Valors predeterminats**, vegeu
+[Aparença](../appearance.html)), **UTC** si no s'ha canviat. **Aquest navegador** segueix la zona horària del teu ordinador, i la
+llista conté totes les zones pel nom, com ara `Europe/Madrid`. La targeta mostra l'hora actual a la zona i el format seleccionats.
+
+---
+
+## Format de data
+
+El format de data defineix com es llegeix la part de data de cada data, i cada opció es mostra amb la data d'avui: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY`. Fins que en triïs un, s'aplica el format de data per defecte del teu administrador,
+`YYYY-MM-DD` si no s'ha canviat. Com les altres opcions, es desa en aquest navegador.
+
+---
+
+## Què conserva les hores del servidor
+
+Dues excepcions conserven les hores pròpies del servidor:
+
+- **El registre del servidor i la sortida de les tasques** són text que conté les hores que hi va escriure el servidor.
+- **Les hores que introdueixes tu**, com ara quan s'ha d'executar una tasca planificada, i les programacions cron, funcionen com
+  abans.
diff --git a/i18n/ca/_use/repositories/adding.md b/i18n/ca/_use/repositories/adding.md
new file mode 100644
index 0000000..f63e9eb
--- /dev/null
+++ b/i18n/ca/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Afegir un repositori
+parent: Repositoris Git
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Afegir un repositori
+{: .no_toc }
+
+La pàgina Repositoris, cada camp d'un repositori i com declarar-ne un al config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La pàgina Repositoris
+
+Els repositoris es gestionen a **Configuració > Connexions > Repositoris**, que necessita l'[opció de rol](../config/roles.html#role-options) `showSettings` o, a partir de la 7.3.0,
+`showConnectionsSettings`. Alguns canvis només els pot fer un administrador, vegeu [més avall](#who-may-change-a-repository).
+
+![Repositoris](../assets/screenshots/git.jpg)
+
+La llista mostra el **Nom**, la **Descripció**, la **Branca**, el **Head** (el hash curt del commit que hi ha descarregat), **Pull** i
+**Push**. La pestanya **Detalls** d'un repositori mostra les mateixes insígnies de Pull i Push a sobre del seu head:
+
+| Columna | Què indica |
+|---|---|
+| **Pull** | L'últim clonatge, pull o restabliment: **En execució** mentre git treballa, i després **Correcte** o **Fallit**; un guió abans del primer |
+| **Push** | **Fallit** quan l'últim push ha fallat; **Canvis pendents** quan hi ha canvis desats aquí, pel dissenyador, que encara no s'han enviat al remot; **Correcte** quan no hi ha res pendent; un guió abans del primer push |
+
+**Correcte** a la columna Push només vol dir que no hi ha res pendent d'enviar: el remot encara pot tenir commits més nous que un
+pull portarà. El menú de cada fila conté aquestes accions:
+
+| Acció | Què fa |
+|---|---|
+| **Edita** | Canvia els camps de més avall |
+| **Pull** | Clona el repositori, o en fa pull quan la còpia de treball ja existeix |
+| **Push** | Fa commit i push de la còpia de treball; només en els repositoris que es fan servir per a formularis, configuració, playbooks, workflows o inventaris, i només està activat quan hi ha canvis que encara no s'han enviat |
+| **Restableix** | Esborra la còpia de treball i la torna a clonar, cosa que descarta els canvis locals |
+| **Canvia les credencials** | Obre la pestanya **Credencials** del repositori, per triar la credencial que fa servir git |
+| **Mostra la sortida de l'últim pull** | Mostra la sortida de git de l'últim clonatge, pull o restabliment, amb la contrasenya emmascarada |
+| **Mostra la sortida de l'últim push** | Mostra la sortida de git de l'últim push, amb la contrasenya emmascarada |
+| **Suprimeix** | Elimina el registre i la seva còpia de treball dins de `REPO_PATH`; només un administrador |
+
+**Pull de tots**, a sobre de la llista, fa pull de tots els repositoris alhora.
+
+En un repositori només s'executa una operació git alhora. Una segona es rebutja amb
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Afegir un repositori
+
+Fes clic a **Afegeix repositori**: un assistent demana els camps en quatre passos (**Repositori**, **Credencials**, **Ús**, **Programació
+del pull**), i AnsibleForms comença el clonatge en segon pla tan bon punt deses.
+
+![Edita el repositori](../assets/screenshots/git-edit.jpg)
+
+| Camp | Obligatori | Significat |
+|---|---|---|
+| **Nom** | sí | El nom de la carpeta dins de `REPO_PATH`; lletres, dígits, guió, guió baix i punt |
+| **Branca** | sí | La branca que es clona, de la qual es fa pull i a la qual es fa push, per exemple `main`; obligatòria a partir de la 7.3.0. Només un repositori del config seed la pot ometre, per clonar la branca per defecte del remot |
+| **Credencial** | no | Una credencial de [Connexions > Credencials](../credentials.html) amb l'usuari i la contrasenya o el token que fa servir git; **Afegeix una credencial** en crea una |
+| **URI** | sí | El remot, `https://...` o SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Activa el pull programat** | no | Fa pull del repositori segons una programació |
+| **Programació del pull** | no | Quan es fa el pull, com a expressió cron; es mostra un cop activat el pull programat |
+| **Descripció** | sí | Una descripció en text lliure |
+| **Utilitzar per a la configuració ?** ... **Fer servir per a inventaris?** | no | Què conté el repositori, vegeu [més amunt](./#what-a-repository-is-for) |
+| **Fes pull en iniciar l'aplicació** | no | Clona el repositori, o en fa pull, cada vegada que s'inicia AnsibleForms |
+
+Reanomenar un repositori mou la seva còpia de treball a la carpeta nova i també hi mou la seva programació de pull. Un repositori d'abans
+de la 7 que encara té el seu propi usuari ho indica a la seva pestanya **Credencials**: tria una credencial per substituir-lo.
+
+---
+
+## Qui pot canviar un repositori
+
+El contingut d'un repositori es converteix en el que AnsibleForms carrega i executa, així que a partir de la 7.3.0 un usuari sense el rol `admin` ja no pot:
+
+- afegir o suprimir un repositori;
+- canviar-ne l'**URI** o la **Branca**;
+- activar o desactivar cap dels seus indicadors **Utilitzar per a**.
+
+Encara en pot canviar la descripció, la programació del pull i la credencial, i en pot fer pull, push o restablir-lo. Una credencial que fa servir un runner,
+una connexió o un inici de sessió no la pot triar; el rebuig l'anomena, i no diu res del que conté.
+
+---
+
+## Declarar repositoris al config seed
+
+Els repositoris també es poden declarar al [config seed](../seed/), de manera que una instància nova els clona en la seva primera arrencada.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+Els camps són els de la pàgina, inclosos `credential` (una credencial del seed o de l'aplicació), `rebase_on_start` (**Fes pull en iniciar
+l'aplicació**) i `cron` (la programació del pull); `user` i `password` encara s'accepten en lloc d'una credencial. Un
+repositori del seed és de només lectura a la interfície, i es torna a clonar en arrencar quan falta la seva còpia de treball; vegeu
+[Objectes gestionats](../seed/managed-objects.html).
diff --git a/i18n/ca/_use/repositories/authentication.md b/i18n/ca/_use/repositories/authentication.md
new file mode 100644
index 0000000..f63f01a
--- /dev/null
+++ b/i18n/ca/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Autenticació
+parent: Repositoris Git
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Autenticació
+{: .no_toc }
+
+HTTPS amb un token, SSH amb la clau generada i ordres git personalitzades
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Autenticació
+
+La manera com s'autentica AnsibleForms depèn de la forma de l'**URI**.
+
+### HTTPS amb un token
+
+Per a un remot HTTPS privat, tria una **Credencial** l'usuari de la qual sigui l'usuari de git i la contrasenya de la qual sigui un token d'accés personal
+(o la contrasenya).
+
+A partir de la 7.3.0, git inicia la sessió a través de `GIT_ASKPASS`: l'usuari i el token van a cada ordre git que parla amb el servidor, mai a
+l'URL, de manera que no es guarden al `.git/config` del clon i un token canviat es fa servir al següent pull o push. El token necessita
+accés de lectura per fer pull, i accés d'escriptura per fer push. Un remot públic no necessita cap credencial.
+
+Fins a la 7.2.0, tots dos s'inserien a l'URL, com a `https://<user>:<token>@git.example.com/team/forms.git`. Un clon fet llavors conserva
+aquesta URL fins al seu següent pull o push, que torna a posar com a remot l'**URI** del mateix repositori.
+
+### SSH amb la clau generada
+
+Per a un remot SSH, AnsibleForms s'autentica amb el seu propi parell de claus, que genera en la primera arrencada.
+
+1. Obre **Configuració > Connexions > SSH**, a la pestanya **Clau**, i copia la **Clau pública**.
+2. Afegeix-la al servidor git, com a clau de desplegament del repositori (amb accés d'escriptura si fas push), o a un usuari que hi tingui accés.
+3. Afegeix el repositori amb una **URI** SSH, per exemple `git@git.example.com:team/forms.git`, i no triïs cap credencial.
+
+El parell de claus és a `.ssh/id_rsa` dins de [`HOME_PATH`](../customization/paths.html#env_HOME_PATH), així que mantén aquesta carpeta en
+emmagatzematge persistent, o la clau canviarà quan es torni a crear el contenidor.
+
+En un clon amb una URI `user@host:path`, AnsibleForms primer executa `ssh-keyscan` sobre l'amfitrió i n'afegeix la clau als
+amfitrions coneguts. Per a altres remots, afegeix l'amfitrió a la pestanya **Amfitrions coneguts** de **Configuració > Connexions > SSH** abans del
+primer clonatge.
+
+### Ordres git personalitzades
+
+Les ordres de clonatge, pull i push es poden substituir, per exemple per afegir-hi opcions de git, amb tres opcions.
+
+| Opció | Per defecte | Què hi afegeix AnsibleForms |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, l'URI i el nom |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+A partir de la 7.3.0, aquestes ordres s'executen sense shell: les cometes funcionen, però un operador de shell com ara `;`, `|`, `&&` o `>` es rebutja.
diff --git a/i18n/ca/_use/repositories/designer.md b/i18n/ca/_use/repositories/designer.md
new file mode 100644
index 0000000..027c6f0
--- /dev/null
+++ b/i18n/ca/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Dissenyador i push
+parent: Repositoris Git
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Dissenyador i push
+{: .no_toc }
+
+Edita formularis al dissenyador i fes-ne push al repositori
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Editar i fer push des del dissenyador
+
+Amb un repositori que es fa servir per a formularis, el dissenyador edita els fitxers de la seva còpia de treball i els torna a enviar al remot.
+
+| Botó | Què fa |
+|---|---|
+| **Desa (local)** | Escriu els formularis i el `config.yaml` a les còpies de treball, sense fer commit |
+| **Desa (repositori)** | Fa commit i push dels canvis desats; s'activa quan hi ha canvis sense enviar |
+| **Carrega (repositori)** | Fa pull dels repositoris de formularis i recarrega el dissenyador, després d'una confirmació si hi ha edicions sense desar |
+
+Els formularis es queden al seu repositori; els nous esperen, ja utilitzables, a [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) fins que en facis push.
+Un formulari desat en una subcarpeta conserva el seu camí relatiu: `team/deploy.yaml` s'envia a `team/deploy.yaml` dins de la carpeta de formularis
+del repositori. Un formulari nou el camí del qual ja hi existeix no se sobreescriu; es queda a la carpeta de preparació, així que reanomena'l.
+Amb diversos repositoris de formularis, **Desa (repositori)** i **Carrega (repositori)** pregunten quin, i per defecte proposen el del `config.yaml`.
+
+Un push prepara tots els canvis, en fa commit com a `AnsibleForms` amb el missatge `Forms sync by <user>`, després fa fetch, rebase sobre
+el remot i push, i ho reintenta fins a cinc vegades. Un conflicte de rebase s'avorta i es llisten els fitxers en conflicte;
+corregeix-los al remot, o fes servir **Restableix** a la pàgina Repositoris. **Push** a la pàgina Repositoris fa el mateix.
+
+Quan un únic repositori de formularis es clona buit, AnsibleForms copia el `config.yaml` i els formularis locals a la seva còpia
+de treball, de manera que un push (**Desa (repositori)**, o **Push** a la pàgina Repositoris) els publica. Trobaràs més informació sobre el dissenyador a [Dissenyador i git](../gui/designer-and-git.html).
diff --git a/i18n/ca/_use/repositories/index.md b/i18n/ca/_use/repositories/index.md
new file mode 100644
index 0000000..c8654a4
--- /dev/null
+++ b/i18n/ca/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Repositoris Git
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Repositoris Git
+{: .no_toc }
+
+Guarda formularis, fitxers de variables, configuració i playbooks a git
+{: .fs-6 .fw-300 }
+
+---
+
+Per als administradors que guarden formularis, configuració i playbooks a git: què pot contenir un repositori i quina font té prioritat.
+
+---
+
+## Per a què serveix un repositori
+
+Un repositori és un remot git que AnsibleForms clona i manté al dia, i cadascun té interruptors que indiquen què conté:
+
+| Interruptor | Què en llegeix AnsibleForms | Carpeta del repositori |
+|---|---|---|
+| **Utilitzar per a la configuració ?** | `config.yaml` amb les categories, els rols i les constants | l'arrel |
+| **Utilitzar per als formularis ?** | Els fitxers de formulari, que el dissenyador també hi torna a desar, i els seus fitxers de variables | `forms`, o l'arrel; els fitxers de variables a `vars` |
+| **Utilitzar per als playbooks ?** | Els playbooks d'Ansible que executen les tasques | `playbooks`, o l'arrel |
+| **Fer servir per a workflows?** | Els fitxers de [workflow](../workflows/), que el dissenyador també hi torna a desar | qualsevol carpeta |
+| **Fer servir per a inventaris?** | Un inventari, amb el nom del repositori, que un formulari indica amb `inventory:` | l'arrel: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Sense la subcarpeta, es fa servir l'arrel del repositori. Un repositori ho pot contenir tot; si els separes, només **Utilitzar per als
+formularis**, **Fer servir per a workflows** i **Fer servir per a inventaris** poden estar activats en diversos: els altres interruptors agafen el primer repositori
+i registren un avís.
+
+Cada repositori es clona en una subcarpeta amb el seu nom, dins de [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Un repositori per a tot
+
+Un sol repositori pot contenir formularis, fitxers de variables, configuració i playbooks, amb els interruptors activats i una subcarpeta per a cada tipus.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Un repositori per a cada finalitat
+
+Els repositoris separats permeten que cada equip sigui propietari de la seva part, amb un interruptor cadascun i els fitxers directament a l'arrel.
+
+| Repositori | Interruptor | Contingut a l'arrel |
+|---|---|---|
+| `af-config` | **Utilitzar per a la configuració ?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Utilitzar per als formularis ?** | Els fitxers de formulari de cada equip, fusionats en una sola llista |
+| `af-playbooks` | **Utilitzar per als playbooks ?** | Els playbooks i els rols |
+
+Només els formularis poden venir de diversos repositoris; la configuració i els playbooks venen cadascun d'un de sol. Els fitxers de variables venen de la carpeta `vars`
+del primer repositori de formularis que en tingui una.
+
+---
+
+## Com es combinen els repositoris amb les carpetes locals
+
+El contingut dels repositoris substitueix la carpeta local corresponent; aquesta taula resumeix d'on es llegeix cada tipus de fitxer.
+
+| Contingut | Es llegeix de, guanya la primera coincidència |
+|---|---|
+| Configuració | 1. la base de dades, quan la configuració s'hi desa ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. el `config.yaml` del repositori **Utilitzar per a la configuració** <br> 3. el `config.yaml` d'un repositori **Utilitzar per als formularis**, quan cap repositori no es fa servir per a la configuració <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formularis | Tots els repositoris **Utilitzar per als formularis** més `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) només quan no n'hi ha cap |
+| Playbooks | El repositori **Utilitzar per als playbooks**, o si no [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Fitxers de variables | La carpeta `vars` del primer repositori **Utilitzar per als formularis** que en tingui una, o si no [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflows | Tots els repositoris **Fer servir per a workflows** més [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), conjuntament |
+
+Els formularis de diversos repositoris es fusionen en una sola llista. Quan dos d'ells contenen un formulari amb el mateix nom, es conserva el primer
+que es carrega i es registra l'avís `skipping duplicate form <name>`, així que mantén els noms dels formularis únics entre repositoris.
+
+---
+
+## Resolució de problemes
+
+La majoria dels problemes es veuen a la columna **Pull** i a **Mostra la sortida de l'últim pull** (o **Mostra la sortida de l'últim push**), que contenen el missatge d'error
+de git mateix.
+
+- [Ha fallat el clonatge o el pull d'un repositori](../troubleshooting.html#a-repository-clone-or-pull-failed): autenticació, amfitrions
+  coneguts i canvis locals.
+- [El repositori de formularis encara no s'ha clonat](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): el dissenyador
+  no pot desar abans del primer clonatge.
+- Un repositori encallat a `running` es restableix a `failed`: després d'un reinici, a la següent arrencada; en menys d'un minut quan el node
+  que executa la seva operació git deixa de respondre durant 2 minuts; i en qualsevol cas passades 2 hores. Torna a executar **Pull**.
+
+---
+
+## En aquesta secció
+
+Cada tema té la seva pròpia pàgina:
+
+| Pàgina | Què tracta |
+|---|---|
+| [Afegir un repositori](adding.html) | La pàgina Repositoris, cada camp d'un repositori i com declarar-ne un al config seed |
+| [Autenticació](authentication.html) | HTTPS amb un token, SSH amb la clau generada i ordres git personalitzades |
+| [Fer pull dels canvis](pulling.html) | Pulls programats, manuals i per API, i els canvis locals |
+| [Dissenyador i push](designer.html) | Editar formularis al dissenyador i fer-ne push al repositori |
diff --git a/i18n/ca/_use/repositories/pulling.md b/i18n/ca/_use/repositories/pulling.md
new file mode 100644
index 0000000..64f6e51
--- /dev/null
+++ b/i18n/ca/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Fer pull dels canvis
+parent: Repositoris Git
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Fer pull dels canvis
+{: .no_toc }
+
+Pulls programats, manuals i per API, i els canvis locals
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fer pull dels canvis
+
+Es fa pull d'un repositori segons la seva programació, en arrencar, des de la pàgina o a través de l'API; no hi ha cap punt final de webhook.
+
+| Disparador | Com |
+|---|---|
+| Programació | **Activa el pull programat** i una **Programació del pull**, per exemple `0 * * * *` per a cada hora |
+| Arrencada | **Fes pull en iniciar l'aplicació** clona el repositori, o en fa pull quan ja està clonat |
+| Pàgina de configuració | **Pull** al menú de la fila, o **Pull de tots** a sobre de la llista |
+| Dissenyador | **Carrega (repositori)**, que fa pull dels repositoris de formularis i recarrega el dissenyador; obtenir el bloqueig del dissenyador també fa primer pull de tots els repositoris de formularis |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` o `showConnectionsSettings`) o `POST /api/v2/forms-repos/pull/<name>` (vegeu més avall) |
+
+### Pull des d'un pipeline o un webhook
+
+AnsibleForms no té cap receptor de webhooks dedicat, però una tasca de CI o un webhook del servidor git poden cridar el punt final de pull.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Crea el token tal com es descriu a [Tokens d'API](../profile/api-token.html), per a un usuari el rol del qual tingui `showSettings` o
+`showConnectionsSettings`. `/api/v2/forms-repos/pull/<name>`, en canvi, necessita `showDesigner` i `allowFormDesign`, amb el dissenyador
+activat ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` retorna el
+`head`, l'`status` i l'`output`, de manera que un pipeline pot comprovar quin commit executa la instància després d'un pull.
+
+### Canvis locals
+
+Un pull no sobreescriu mai feina que encara no s'ha enviat, així que un pull programat comprova la còpia de treball abans d'executar-se.
+
+Un pull programat s'omet mentre la còpia de treball té canvis sense commit o commits sense push, i mentre un dissenyador
+té el bloqueig del dissenyador. Un pull manual d'una còpia de treball amb canvis en conflicte falla amb:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Fes push dels canvis, o descarta'ls amb **Restableix** al menú de la fila, que esborra la còpia de treball i la torna a clonar.
diff --git a/i18n/ca/index.md b/i18n/ca/index.md
new file mode 100644
index 0000000..0551118
--- /dev/null
+++ b/i18n/ca/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Inici
+nav_order: 1
+description: "AnsibleForms: crea formularis dinàmics basats en dades per a l'automatització amb Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Formularis d'autoservei per a <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible és una eina d'automatització potent, però continua sent una aplicació de línia d'ordres, i a AWX/AAP/Ascender li falten
+      formularis que recullin dades de diverses fonts. AnsibleForms et permet construir formularis dinàmics basats en dades, generar extravars
+      i enviar-les a Ansible, AWX/AAP/Ascender, Semaphore, Rundeck o Jenkins i executar-hi plantilles.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">Instal·la AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">Construeix el teu primer formulari</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="El tauler d'AnsibleForms">
+  </div>
+</div>
+
+## Funcionalitats
+
+Què aporta AnsibleForms a la teva instal·lació d'Ansible, i què pot fer un sol formulari:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Aplicació</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Plataformes d'automatització</strong><span>Playbooks en RTE, plantilles a Ascender, Semaphore i més</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Control d'accés</strong><span>Rols i opcions de rol, amb inicis de sessió locals, LDAP, Entra ID i OIDC</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Programació</strong><span>Executa un formulari més tard, o segons una programació cron</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Historial de tasques</strong><span>Segueix, avorta i rellança tasques</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Credencials i secrets</strong><span>Desa credencials, o llegeix-les de Vault o CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Repositoris Git</strong><span>Guarda formularis, playbooks i configuració a Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dissenyador</strong><span>Edita formularis en YAML, amb validació</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP i xat</strong><span>Llança formularis des de scripts, agents d'IA o un xat</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formularis</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Desplegables en cascada</strong><span>Desplegables que reaccionen a altres camps</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Expressions i fonts de dades</strong><span>Omple camps des de bases de dades, API REST, fitxers i JavaScript</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dependències entre camps</strong><span>Mostra o amaga camps segons altres camps</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validació</strong><span>Mínim, màxim, regex i més, opcionalment comprovats al servidor</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflows i formularis amb assistent</strong><span>Encadena playbooks i aprovacions, o reparteix les dades en diverses pàgines</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Camps estructurats</strong><span>Llistes i objectes basats en subformularis reutilitzables</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Punts d'aprovació</strong><span>Atura una tasca fins que algú l'aprovi</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Notificacions</strong><span>Correu, Slack, Teams, Telegram o un webhook segons els esdeveniments de les tasques</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Necessites ajuda?
+
+Les preguntes, els errors i els informes de seguretat tenen cadascun el seu lloc:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Resolució de problemes</strong>
+    <span>Busca un missatge d'error i com solucionar-lo</span>
+    <span class="af-card-more">Resolució de problemes &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Fes una pregunta</strong>
+    <span>Pregunta a la comunitat i als mantenidors</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Informa d'un error</strong>
+    <span>Obre una issue amb els passos per reproduir-lo</span>
+    <span class="af-card-more">Nova issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Obtenir ajuda</strong>
+    <span>Què cal incloure, i com comunicar un problema de seguretat</span>
+    <span class="af-card-more">Obtenir ajuda &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/de.yml b/i18n/de.yml
new file mode 100644
index 0000000..17cff19
--- /dev/null
+++ b/i18n/de.yml
@@ -0,0 +1,42 @@
+# The German docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: de
+docs_language: "de"
+
+title: "AnsibleForms-Dokumentation"
+description: "Technische Dokumentation von AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Alle Rechte vorbehalten."
+
+# "Edit this page on GitHub" opens the German page's source
+gh_edit_link_text: "Diese Seite auf GitHub bearbeiten"
+gh_edit_source: i18n/de
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Einführung"
+    get_started:
+      name: "Erste Schritte"
+    configure:
+      name: "Konfigurieren"
+    build_forms:
+      name: "Formulare erstellen"
+    use:
+      name: "Benutzerhandbuch"
+    integrate:
+      name: "Integrieren"
+    security_assessment:
+      name: "Sicherheit"
+    reference:
+      name: "Referenz"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (aktuell)"
+    url: "/de/"
+  - name: "6"
+    title: "6.x (auf Englisch)"
+    url: "/v6/"
diff --git a/i18n/de/_build_forms/expressions/credentials.md b/i18n/de/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..45bf2e0
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Anmeldedaten
+parent: Ausdrücke
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Anmeldedaten
+{: .no_toc }
+
+Gespeicherte Anmeldedaten in einem Ausdruck lesen
+{: .fs-6 .fw-300 }
+
+---
+
+Gespeicherte Anmeldedaten nach Name oder per regulärem Ausdruck lesen, mit einer Alternative:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Zuerst wird der exakte Name versucht. Gibt es keine Anmeldedaten mit diesem Namen, wird der Name als regulärer Ausdruck verwendet, und danach wird die Alternative versucht.
+
+#### Durch Rollen begrenzt
+
+Wenn eine der Rollen des Benutzers in `config.yaml` die Liste `credentials` enthält, gibt `fn.fnCredentials` nur Anmeldedaten zurück, die eine solche Rolle
+erlaubt: Die Muster der Rolle werden mit dem Namen der gefundenen Anmeldedaten verglichen (per Name, regulärem Ausdruck oder Alternative),
+und alle anderen werden abgelehnt. Rollen ohne diese Liste begrenzen nichts, und ein Admin wird nie begrenzt.
+
+#### Anmeldedaten aus einem Secret Store
+
+Anmeldedaten, die einen [Secret Store](../secret-stores) angeben, erhalten ihren `user` und ihr `password`
+zur Laufzeit aus diesem Store. `fn.fnCredentials('myapp')` funktioniert unverändert weiter.
+
+Ein Secret lässt sich auch ohne Anmeldedaten-Eintrag lesen, überall dort, wo ein Name von Anmeldedaten akzeptiert wird
+(auch in `fnRestBasic`, `fnRestJwtSecure` und den Header-Ersetzungen von `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+Die Schlüssel des Secrets werden wie unter [Schlüsselnamen](../secret-stores#key-names) beschrieben zugeordnet.
+Ein Secret mit anderer Struktur wird mit einem `jq`-Ausdruck als drittem Argument umgeformt:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/de/_build_forms/expressions/index.md b/i18n/de/_build_forms/expressions/index.md
new file mode 100644
index 0000000..e91b5eb
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Ausdrücke
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Ausdrücke
+{: .no_toc }
+
+Feldwerte mit JavaScript berechnen, im Browser oder auf dem Server
+{: .fs-6 .fw-300 }
+
+---
+
+Für Formularautoren: Felder dynamisch mit JavaScript füllen, im Browser berechnet oder auf dem Server abgerufen.
+
+Mit dem Attribut `expression` eines Formularfelds erstellen Sie dynamische Formulare mit JavaScript-Ausdrücken.
+
+---
+
+## Einführung
+
+Das Attribut `expression` gibt es bei mehreren Feldtypen:
+- Feld `enum`: um die Optionen der Dropdown-Liste dynamisch zu füllen
+- Feld `expression`: um beliebige Daten abzurufen oder zu erzeugen
+- Feld `html`: um seinen HTML-Inhalt aufzubauen
+- Felder `yaml` und `list`: um ihre Daten zu füllen
+
+JavaScript-Ausdrücke werden entweder auf der **Serverseite** (Standard) oder auf der **Clientseite** ausgewertet, je nach der Feldeigenschaft `runLocal`.
+Ein `html`-Feld sowie die Feldtypen `local`, `local_out` und `credential` führen ihren Ausdruck immer im Browser aus, egal was
+`runLocal` sagt.
+
+- **Auf der Serverseite** (`runLocal: false`, der Standard): vordefinierte Funktionen, die Daten aus APIs, Dateien und Datenbanken abrufen.
+- **Auf der Clientseite** (`runLocal: true`): Der Code nutzt die volle JavaScript-Engine in der Sandbox des Browsers für Berechnungen, Umformungen und Bearbeitungen.
+
+---
+
+## Sicherheitsaspekte
+
+Da Ausdrücke mit der JavaScript-Funktion `eval` ausgewertet werden, ist Code-Injection ein mögliches Risiko:
+
+- **Serverseitige Ausdrücke** durchlaufen zuerst einen Sanitizer: Jeder Aufruf muss eine `fn.`- oder `fnc.`-Funktion sein, und mehrere Zeilen,
+  `;`, Template-Literale, `process.env` und die Wege aus `eval` heraus (`import`, `require`, `constructor`, ...) werden abgelehnt.
+- **Clientseitige Ausdrücke** werden in der Sandbox des Browsers ausgewertet und können als sicher gelten.
+
+Wie streng der Sanitizer ist, hängt von
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) ab:
+
+| Wert | Serverseitige Ausdrücke |
+|---|---|
+| `strict` (Standard) | `fn.`- und `fnc.`-Aufrufe sowie Methoden auf ihrem Ergebnis, etwa `fn.fnTime().format('YYYY')` |
+| `paranoid` | nur direkte `fn.`- und `fnc.`-Aufrufe, keine Methoden auf ihrem Ergebnis |
+| `off` | jeder serverseitige Ausdruck wird abgelehnt; nur `runLocal`-Ausdrücke funktionieren |
+| `legacy` | die Regeln von 6.2.1, die jeden angemeldeten Benutzer Code auf dem Server ausführen lassen; nur für ein Upgrade, und nur in der echten Umgebung (nicht über die Einstellungsseite) |
+
+Ein leerer oder unbekannter Wert bedeutet `strict`. Eine Änderung gilt ab dem nächsten Ausdruck, ohne Neustart.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Platzhalter](placeholders.html) | Mit `$(...)` auf ein anderes Feld, eine Konstante oder den Benutzer verweisen |
+| [Lokale Ausdrücke](local.html) | JavaScript, das in der Sandbox des Browsers läuft |
+| [Remote-Ausdrücke](remote.html) | Serverseitige Funktionen für Datumswerte, Netzwerke, Dateien, SSH und nummerierte Namen |
+| [REST-APIs](rest-apis.html) | REST-APIs mit Basic-, Token- oder eigener Authentifizierung aufrufen |
+| [Anmeldedaten](credentials.html) | Gespeicherte Anmeldedaten lesen |
+| [Sortierung](sorting.html) | Arrays mit einem Sortierobjekt sortieren |
+| [jq-Abfragen](jq.html) | Daten mit jq umformen |
diff --git a/i18n/de/_build_forms/expressions/jq.md b/i18n/de/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..3d5aaad
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: jq-Abfragen
+parent: Ausdrücke
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# jq-Abfragen
+{: .no_toc }
+
+Daten mit jq umformen, einschließlich der integrierten Funktionen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Eine JSON-Abfrage (jq) auf einem Objekt ausführen
+
+Formen Sie ein Objekt, etwa den Wert eines anderen Felds, mit einem jq-Ausdruck um:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+Ab 7.3.0 läuft ein jq-Filter höchstens [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (standardmäßig 30),
+bevor er gestoppt wird, und seine Ausgabe ist auf 64 MB begrenzt. Das gilt für `fn.fnJq` und für den jq-Ausdruck der Funktionen für REST, Dateien,
+Anmeldedaten und Datenbankabfragen.
+
+---
+
+## Integrierte jq-Funktionen
+
+Alle Funktionen, die Daten abrufen, akzeptieren eine JSON-Abfrage (jq), eine Sprache zum Bearbeiten von Datenobjekten und Arrays.  
+Beim Bearbeiten von Daten müssen Sie eventuell Bytes in KB, MB oder GB umrechnen oder Zahlen runden.  
+Dafür bringt AnsibleForms einige eigene jq-Funktionen mit:
+
+- **fn2KB**: Bytes in KB
+- **fn2MB**: Bytes in MB
+- **fn2GB**: Bytes in GB
+- **fnRound0**: auf 0 Dezimalstellen runden
+- **fnRound1**: auf 1 Dezimalstelle runden
+- **fnRound2**: auf 2 Dezimalstellen runden
+- **fnRound**: auf 2 Dezimalstellen runden
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/de/_build_forms/expressions/local.md b/i18n/de/_build_forms/expressions/local.md
new file mode 100644
index 0000000..bb8a5d0
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Lokale Ausdrücke
+parent: Ausdrücke
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Lokale Ausdrücke
+{: .no_toc }
+
+JavaScript, das in der Sandbox des Browsers läuft
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Die folgenden Beispiele laufen mit der Feldeigenschaft `runLocal: true`.  
+Sie werden in der Sandbox des Browsers ausgeführt und können die volle JavaScript-Engine nutzen.
+
+{: .note }
+> **Tipp**: Verwenden Sie den Typ `local` als Alias für `type: expression, runLocal: true, hide: true, output: false`  
+> **Tipp**: Verwenden Sie den Typ `local_out` als Alias für `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Namenskonvention
+
+Wenden Sie Namenskonventionen mit Zeichenkettenoperationen an.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Berechnung
+
+Rechnen Sie mit mathematischen Funktionen.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Umrechnungen
+
+Bytes in Gigabytes umrechnen.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Ein Array von Objekten in eine HTML-Tabelle umwandeln
+
+Machen Sie aus einem Array von Objekten, etwa aus einem anderen Feld, eine HTML-Tabelle für ein `html`-Feld:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Einen Namen mit fortlaufender Nummerierung ermitteln
+
+Bei automatischer Nummerierung müssen Sie eventuell den nächsten Namen in einem Array nummerierter Zeichenketten finden.  
+Diese Funktion gibt es auch als serverseitigen Ausdruck (mit dem Präfix `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Ist das erste Argument kein Array, gibt die lokale Funktion den Standardwert zurück. Die Serverfunktion `fn.fnGetNumberedName`
+schlägt stattdessen mit einem Fehler fehl.
+
+---
+
+## Arrays von Objekten bearbeiten
+
+Arrays von Objekten müssen oft gefiltert, verändert und sortiert werden.  
+AnsibleForms bringt einen eigenen Helfer mit, der diesen Code kurz hält.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Arrays von Objekten mit reinem JavaScript bearbeiten
+
+Alle Standardmethoden für Arrays in JavaScript stehen weiterhin zur Verfügung, um Ihre Daten zu filtern und zu verändern, etwa `map`, `forEach`, `find`, `filter` und `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/de/_build_forms/expressions/placeholders.md b/i18n/de/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..a81db40
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Platzhalter
+parent: Ausdrücke
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Platzhalter
+{: .no_toc }
+
+Mit `$(...)` auf ein anderes Feld, eine Konstante oder den aktuellen Benutzer verweisen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Was ein Platzhalter ist
+
+Ein Platzhalter ist ein Verweis in der Form `$(reference)`. Er wird durch einen Wert ersetzt, bevor der Text, der ihn enthält, verwendet wird.
+
+Platzhalter funktionieren in `expression`, `query` und `default` eines Felds (ausgewertet mit `evalDefault`) sowie in seinem `label`,
+`help` und `placeholder`. Ein Feld mit einem Platzhalter hängt von dem Feld ab, das dieser nennt: Es wartet, bis dieses Feld einen
+Wert hat, und wird jedes Mal neu ausgewertet, wenn sich dieser Wert ändert. So entstehen kaskadierende Dropdown-Listen.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## Worauf ein Platzhalter verweisen kann
+
+Ein Platzhalter nennt ein Feld des Formulars oder eines der folgenden, die jedes Formular hat:
+
+| Verweis | Was er enthält |
+|---|---|
+| `$(field)` | den Wert eines anderen Felds des Formulars |
+| `$(name)`, eine Konstante | eine [Konstante](../config/constants.html) aus `config.yaml` oder einen Wert aus den `varsFiles` des Formulars |
+| `$(__user__)` | den angemeldeten Benutzer: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | in einem [Unterformular](../forms/subform.html) (eine Listenzeile, ein Wizard-Schritt) einen Wert des übergeordneten Formulars |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Auf Teile eines Werts zugreifen
+
+Punkt- und Indexnotation lesen einen Teil eines Werts, solange der Pfad nur Buchstaben, Ziffern, `_`, `-`, `.` und `[n]` enthält:
+
+| Platzhalter | Auf | Ergibt |
+|---|---|---|
+| `$(field)` | einem Text-, Zahlen- oder Passwortfeld | den Wert |
+| `$(field)` | einem Enum aus Datensätzen | die `placeholderColumn` des ausgewählten Datensatzes, sonst seine erste Spalte |
+| `$(field.col)` | einem Enum aus Datensätzen | diese Spalte des ausgewählten Datensatzes |
+| `$(field)` | einem Enum mit `multiple: true` | die gewählte Spalte jedes ausgewählten Datensatzes, als Array |
+| `$(field)` | einem Ausdruck, einer Liste oder einer Konstante | den ganzen Wert (eine Liste liefert ihre Zeilen) |
+| `$(field.a.b)`, `$(f[0].x)` | einem Ausdruck, einer Liste oder einer Konstante | diesen Teil des Objekts oder Arrays |
+
+Mit `placeholderColumn: "*"` auf einem Enum liefert `$(field)` den ganzen ausgewählten Datensatz statt einer Spalte.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Wie der Wert eingesetzt wird
+
+Wie ein Wert in den Text eingesetzt wird, hängt davon ab, wo der Platzhalter steht.
+
+| Wo | Beispiel | Wird zu |
+|---|---|---|
+| in einem Ausdruck, außerhalb von Anführungszeichen | `$(count) + 1` | einem JavaScript-Literal: Eine Zahl bleibt eine Zahl, ein Text wird zu einer Zeichenkette in Anführungszeichen, ein Objekt oder Array zu einem Literal |
+| in einem Ausdruck, als ganze Zeichenkette in Anführungszeichen | `fn.fnLs('$(dir)')` | demselben Literal, einschließlich der Anführungszeichen, sodass ein Wert mit einem Anführungszeichen nicht ausbrechen kann |
+| in einem Ausdruck, innerhalb einer längeren Zeichenkette | `'$(dir)/vars'` | dem Text, für diese Zeichenkette maskiert |
+| in einer Abfrage, einem Label, einem Hilfetext | `where city='$(city)'` | dem Text |
+
+Ein Feld, dessen Platzhalter noch nicht alle aufgelöst werden können, wird nicht ausgewertet; mit `ignoreIncomplete: true` wird ein fehlender Wert
+stattdessen als `undefined` eingesetzt.
+
+### Backticks und `${` in einem Wert
+
+Ab 7.3.0 kann ein Feldwert nicht als Code laufen, wenn der Server ihn in einen Ausdruck einsetzt (Remote-Ausdrücke, Start-Validierung,
+MCP und Chat). Ein Backtick oder `${` im Wert wird als Unicode-Escape geschrieben (```, `${`), sodass er auch innerhalb
+eines Template-Literals Text bleibt. Serverseitige Ausdrücke lehnen Template-Literale ganz ab; verwenden Sie dafür `runLocal`.
+
+Ein `runLocal`-Ausdruck, der im Browser ausgewertet wird, setzt den Wert so ein, wie die Tabelle oben es beschreibt, ohne dieses Escape; setzen Sie dort
+also keinen Platzhalter in ein Template-Literal.
+
+---
+
+## Siehe auch
+
+Verwandte Seiten und FAQ-Einträge:
+
+- [Lokale Ausdrücke](local.html) und [Remote-Ausdrücke](remote.html): wo die meisten Platzhalter verwendet werden
+- [FAQ: Kaskadierende Dropdowns](../faq.html#cascaded-dropdowns) und [Feldplatzhalter](../faq.html#field-placeholders): weitere Beispiele
+- [FAQ: Wie greife ich in einem Unterformular auf Daten des übergeordneten Formulars zu?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/de/_build_forms/expressions/remote.md b/i18n/de/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..3bc14ba
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Remote-Ausdrücke
+parent: Ausdrücke
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Remote-Ausdrücke
+{: .no_toc }
+
+Serverseitige Funktionen für Datumswerte, Netzwerke, Dateien, SSH und nummerierte Namen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Die folgenden Beispiele laufen mit der Feldeigenschaft `runLocal: false` (Standard).  
+Sie werden auf der Serverseite ausgewertet.
+
+Da das Auswerten von Code auf dem Server ein Sicherheitsrisiko ist, wird der Ausdruck bereinigt und auf die Funktionen beschränkt, die
+AnsibleForms mitbringt, sowie auf die [Funktionen, die Sie selbst hinzufügen](#your-own-functions).  
+Serverseitige Ausdrücke sind dafür gedacht, Informationen aus Datenquellen wie Dateien, REST-APIs und SSH-Befehlen abzurufen.
+
+{: .important }
+Die integrierten serverseitigen Funktionen haben das Präfix `fn.` (zum Beispiel `fn.fnRestBasic`), Ihre eigenen das Präfix `fnc.`.
+
+---
+
+## Datum und Uhrzeit bearbeiten
+
+Arbeiten Sie mit Datum und Uhrzeit über [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## CIDR-Informationen zu einer IP abrufen
+
+Ermitteln Sie das Subnetz einer IP-Adresse und Netzmaske, und prüfen Sie, welche Adressen dazugehören:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## SSH-Ausgabe abrufen
+
+Führen Sie einen Befehl per SSH auf einem entfernten Host aus und verwenden Sie seine Ausgabe:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Dateien in einem Verzeichnis auflisten
+
+Listen Sie die Dateien eines Verzeichnisses auf dem AnsibleForms-Server auf, optional rekursiv und gefiltert:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## HTML-Seite parsen
+
+Rufen Sie eine HTML-Seite ab und extrahieren Sie die Teile, die auf einen regulären Ausdruck passen:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+Die Seite wird unter [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) und
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) abgerufen, wie bei den REST-Funktionen. Anders als diese ignoriert sie
+`REST_IGNORE_CERTS` und `REST_TIMEOUT_SECONDS`: Sie prüft immer das Zertifikat und wartet höchstens 30 Sekunden.
+
+---
+
+## DNS-Informationen abrufen
+
+Lösen Sie einen DNS-Eintrag einer Domain auf:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## JSON-Datei lesen
+
+Lesen Sie eine JSON-Datei auf dem Server, optional mit jq gefiltert:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## YAML-Datei lesen
+
+Lesen Sie eine YAML-Datei auf dem Server, optional mit jq gefiltert:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Einen Namen mit fortlaufender Nummerierung ermitteln
+
+In einem Array von Zeichenketten mit fortlaufenden Nummern (server001, server002, ...) müssen Sie eventuell den nächsten freien Namen finden.  
+Diese Funktion gibt es auch als lokalen Ausdruck (ohne das Präfix `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Auf dem Server schlägt `fn.fnGetNumberedName` mit einem Fehler fehl, wenn das erste Argument kein Array ist. Der lokale Ausdruck
+(ohne `fn.`) gibt stattdessen den Standardwert zurück.
+
+---
+
+## Eigene Funktionen
+
+Fügen Sie eigene JavaScript-Funktionen in `custom.js` hinzu und rufen Sie sie in einem Serverausdruck mit dem Präfix `fnc.` auf.
+
+Die Datei exportiert ein Objekt mit Funktionen. Die im Image mitgelieferte Datei enthält zwei Beispiele:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+Auf die gleiche Weise enthält `jq.custom.definitions` eigene jq-Definitionen. Sie werden jeder jq-Abfrage vorangestellt, die der
+Server ausführt, sodass die [jq-Abfragen](jq.html) aller Funktionen sie verwenden können.
+
+In einem Container mappen Sie beide Dateien über die im Image und starten neu; sie werden beim Start des Servers gelesen:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Eine eigene Funktion läuft im Serverprozess, mit dessen Rechten, jedes Mal wenn ein Ausdruck sie aufruft. Der
+> [Sanitizer](index.html#security-concerns) prüft, dass der Ausdruck nur `fn.`- und `fnc.`-Funktionen aufruft; was eine
+> Funktion mit ihren Argumenten macht, liegt bei Ihnen.
diff --git a/i18n/de/_build_forms/expressions/rest-apis.md b/i18n/de/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..a0bb0f0
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: REST-APIs
+parent: Ausdrücke
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# REST-APIs
+{: .no_toc }
+
+REST-APIs mit Basic-, Token- oder eigener Authentifizierung aufrufen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## REST-API mit Basic-Authentifizierung
+
+Rufen Sie eine REST-API mit Benutzer und Passwort gespeicherter Anmeldedaten auf:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## REST-API mit Token-Authentifizierung
+
+Rufen Sie eine REST-API mit einem Bearer-Token auf, das im Ausdruck steht:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST-API mit gesicherter Token-Authentifizierung
+
+Rufen Sie eine REST-API mit einem Bearer-Token aus gespeicherten Anmeldedaten auf, sodass es nie im Formular erscheint:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST-API mit eigenen Headern
+
+Rufen Sie eine REST-API mit eigenen Headern auf, für jede andere Art der Authentifizierung:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Zertifikate und Timeouts
+
+Ab 7.3.0 prüft jede REST-Hilfsfunktion (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) das TLS-Zertifikat
+des Endpunkts und hört nach einer festgelegten Zeit auf zu warten:
+
+| Einstellung | Was sie ändert |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` überspringt die Zertifikatsprüfung. Bis 7.2.0 wurde nie geprüft; lassen Sie den Wert auf `0` und vertrauen Sie stattdessen einer privaten CA mit `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Wie lange ein Aufruf auf eine Antwort wartet, standardmäßig 60 Sekunden; ein Endpunkt, der nie antwortet, lässt das Feld dann fehlschlagen, statt es zu blockieren |
+
+Ab 7.3.0 schlägt ein Feld, dessen Endpunkt ein selbstsigniertes Zertifikat hat, mit einem Zertifikatsfehler fehl, bis eine der beiden Einstellungen gesetzt ist.
+[REST-Aufrufe und jq](../customization/security.html#rest-calls-and-jq) beschreibt beide und wie Sie einer privaten CA für alle REST-Aufrufe auf einmal vertrauen.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) ist keine REST-Hilfsfunktion: Sie ignoriert beide Einstellungen, prüft immer das
+Zertifikat und wartet höchstens 30 Sekunden.
diff --git a/i18n/de/_build_forms/expressions/sorting.md b/i18n/de/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..bc15657
--- /dev/null
+++ b/i18n/de/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Sortierung
+parent: Ausdrücke
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Sortierung
+{: .no_toc }
+
+Arrays mit einem Sortierobjekt sortieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ein Array sortieren
+
+Sortieren Sie ein Array aus einem Ausdruck, einer REST-API oder einer Datenbank mit einem Sortierobjekt:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## Das Sortierobjekt
+
+Die REST-Funktionen (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) nehmen dieses Sortierobjekt
+als Argument. Jedes andere Ergebnis, etwa von `fn.fnJq` oder einem Dateizugriff, umschließen Sie mit `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/de/_build_forms/formfields/checkbox.md b/i18n/de/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..fcbc94a
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Formularfelder
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Checkbox-Feld
+{: .no_toc }
+
+Ein Wahr- oder Falsch-Wert, um eine Option zu aktivieren oder ein Flag zu setzen
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `checkbox`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `checkbox`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/datetime.md b/i18n/de/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..6f6c201
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Formularfelder
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Datetime-Feld
+{: .no_toc }
+
+Eine Auswahl für Datum, Uhrzeit, Woche, Monat oder Jahr
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `datetime`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `datetime`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/enum.md b/i18n/de/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..ecb4e38
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Formularfelder
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Enum-Feld
+{: .no_toc }
+
+Eine Dropdown-Liste mit Suche, für eine oder mehrere Auswahlen
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `enum`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `enum`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/expression.md b/i18n/de/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..54cbfa2
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Formularfelder
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Expression-Feld
+{: .no_toc }
+
+Ein per JavaScript berechneter Wert, im Browser oder auf dem Server
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `expression`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `expression`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/file.md b/i18n/de/_build_forms/formfields/file.md
new file mode 100644
index 0000000..0c2b105
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Formularfelder
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# File-Feld
+{: .no_toc }
+
+Dateien hochladen, etwa Konfigurationsdateien oder Zertifikate
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `file`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `file`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/html.md b/i18n/de/_build_forms/formfields/html.md
new file mode 100644
index 0000000..5eba4bc
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Formularfelder
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Html-Feld
+{: .no_toc }
+
+Formatierter HTML-Inhalt innerhalb eines Formulars
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `html`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `html`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/index.md b/i18n/de/_build_forms/formfields/index.md
new file mode 100644
index 0000000..0dbc94c
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Formularfelder
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Formularfelder
+{: .no_toc }
+
+Die Eingabeelemente eines Formulars
+{: .fs-6 .fw-300 }
+
+---
+
+Für Formularautoren: die Feldtypen, die ein Formular enthalten kann, und die Eigenschaften, die jeder unterstützt.
+
+Formularfelder definieren die Eingabeelemente eines Formulars. Jeder Feldtyp hat eigene Eigenschaften und ein eigenes Verhalten, um eine bestimmte Art von Daten zu erfassen.
+
+Wählen Sie den Feldtyp, der zu den zu erfassenden Daten passt, von einfachem Text bis zu strukturierten Listen.
+
+---
+
+## Gemeinsame Eigenschaften
+
+Alle Formularfelder haben zwei grundlegende Eigenschaften gemeinsam:
+
+- **name** (string, erforderlich): der eindeutige Bezeichner des Felds
+- **type** (string, erforderlich): der Feldtyp, der bestimmt, welche der folgenden Seiten die verfügbaren Eigenschaften beschreibt
+
+Jeder Feldtyp fügt Eigenschaften hinzu, die zu seiner Funktion gehören. Wählen Sie einen Feldtyp in der Navigationsleiste oder in der Tabelle unten, um seine vollständige Eigenschaftsreferenz zu öffnen:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Feldtyp</th>
+      <th>Beschreibung</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/de/_build_forms/formfields/list.md b/i18n/de/_build_forms/formfields/list.md
new file mode 100644
index 0000000..170e70b
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Formularfelder
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# List-Feld
+{: .no_toc }
+
+Eine Tabelle aus Zeilen, jede in einem Unterformular bearbeitet
+{: .fs-6 .fw-300 }
+
+---
+
+Ein list-Feld zeigt eine Tabelle aus Zeilen, die jeweils in einem eigenen **Unterformular**-Bereich erstellt und bearbeitet werden (ein Drilldown-Muster). Es ersetzt das Feld `table`, das in 7.0.0 entfernt wurde.
+
+---
+
+## Hauptfunktionen
+
+Das list-Feld bietet folgende Möglichkeiten:
+
+- Jede Zeile wird in einem Unterformular im Vollbild bearbeitet, mit Zugriff auf alle Feldtypen, einschließlich verschachtelter Listen.
+- Das Unterformular ist ein eigenes Formular vom Typ `subform` und kann **in mehreren list-Feldern** verschiedener Formulare **wiederverwendet** werden (z. B. ein einziges Unterformular `Address`, das Kunden, Lieferanten, Bestellungen… gemeinsam nutzen).
+- Die Marker-Eigenschaften (`insertMarker`, `updateMarker`, `deleteMarker`) unterstützen idempotente Playbook-Muster.
+- Bei `allowDelete: false` sind bereits vorhandene Zeilen geschützt; nur in der aktuellen Sitzung hinzugefügte Zeilen (mit dem `insertMarker`) können gelöscht werden.
+- Die Eigenschaft `columns` steuert, welche Felder des Unterformulars als Spalten in der Übersichtstabelle erscheinen.
+- Die Ausgabe ist immer ein Array von Objekten. `model`, `output`, `outputObject` und `valueColumn`, die auf Feldern des Unterformulars deklariert sind, werden beim Erzeugen der Extravars berücksichtigt.
+
+---
+
+## Deklaration des Unterformulars
+
+Ein Unterformular ist ein eigenes Formular mit `type: subform`, in einer Datei des Formularordners wie jedes andere Formular. Es akzeptiert dasselbe Array `fields` wie jedes andere Formular, erscheint aber nie in der Kachelliste der Formulare und wird nie direkt abgesendet.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Eigenschaften
+
+Die für ein `list`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Beispiele</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Beispiele
+
+### Gemeinsames Adress-Unterformular
+
+Ein Unterformular `Address`, das von zwei list-Feldern desselben Formulars wiederverwendet wird:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Nachverfolgung mit Markern (idempotent)
+
+Vorab geladene Zeilen sind geschützt, und die Marker teilen dem Playbook mit, welche Zeilen neu, geändert oder entfernt sind:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Zeilen vorab füllen
+
+Eine Liste kann aus drei Quellen vorab gefüllt werden. In jedem Fall müssen die entstehenden Zeilen Objekte sein, deren Schlüssel zu den Feldnamen des referenzierten Unterformulars passen.
+
+#### Statisches `default`
+
+Zeilen, die im Formular selbst stehen:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Aus einer REST-API (`expression`)
+
+Zeilen, die ein serverseitiger Ausdruck aus einer REST-API lädt:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Aus einer Datenbankabfrage (`dbConfig` + `query`)
+
+Zeilen, die aus einer Datenbankabfrage geladen werden:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Aus einem lokalen Ausdruck (`runLocal`)
+
+Zeilen, die ein lokaler Ausdruck im Browser berechnet:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Verschachtelte Listen
+
+Ein Unterformular kann ein eigenes list-Feld enthalten, für eine Liste innerhalb jeder Zeile:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Über `__parent__` auf Daten des übergeordneten Formulars zugreifen
+
+Wenn sich der Zeileneditor eines Unterformulars öffnet, fügt AnsibleForms eine Variable `__parent__` in das Unterformular ein. Sie enthält eine Momentaufnahme **aller Feldwerte des übergeordneten Formulars**, einschließlich Konstanten und Vars.
+
+Verweisen Sie darauf mit der üblichen Ausdruckssyntax `$(...)` in den Felddefinitionen des Unterformulars:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` ist ein Hilfsmittel **nur für das Frontend**. Es wird aus den Ansible-Extravars entfernt und nie an das Playbook gesendet.
+
diff --git a/i18n/de/_build_forms/formfields/number.md b/i18n/de/_build_forms/formfields/number.md
new file mode 100644
index 0000000..5535c79
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Formularfelder
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Number-Feld
+{: .no_toc }
+
+Ein ganzzahliger oder dezimaler Wert, etwa ein Port oder eine Menge
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `number`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `number`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/password.md b/i18n/de/_build_forms/formfields/password.md
new file mode 100644
index 0000000..d2de82b
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Formularfelder
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Password-Feld
+{: .no_toc }
+
+Ein maskierter Wert, für Passwörter, Secrets und Tokens
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `password`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `password`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/radio.md b/i18n/de/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..7d5c2ff
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Formularfelder
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Radio-Feld
+{: .no_toc }
+
+Eine Auswahl aus einer Reihe sich gegenseitig ausschließender Optionen
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `radio`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `radio`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/text.md b/i18n/de/_build_forms/formfields/text.md
new file mode 100644
index 0000000..2628a42
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Formularfelder
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Text-Feld
+{: .no_toc }
+
+Eine einzelne Textzeile, etwa ein Name oder ein Hostname
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `text`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `text`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/textarea.md b/i18n/de/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..84a1bc1
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Formularfelder
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Textarea-Feld
+{: .no_toc }
+
+Mehrzeiliger Text, etwa eine Beschreibung oder ein Konfigurationsausschnitt
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `textarea`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `textarea`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/de/_build_forms/formfields/yaml.md b/i18n/de/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..fe995ac
--- /dev/null
+++ b/i18n/de/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Formularfelder
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# YAML-Feld
+{: .no_toc }
+
+Strukturierte Daten in einem YAML-Editor, mit Validierung und Dateiimport
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschaften
+
+Die für ein `yaml`-Feld verfügbaren Eigenschaften, nach Zweck gruppiert:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wert:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für `yaml`-Felder, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Felddefinition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Über `__parent__` auf Daten des übergeordneten Formulars zugreifen
+
+Wenn ein `yaml`-Feld den Modus `subform` verwendet, fügt AnsibleForms eine Variable `__parent__` in das Unterformular ein. Sie enthält eine Momentaufnahme **aller Feldwerte des übergeordneten Formulars** zum Zeitpunkt, an dem sich der Editor öffnet, einschließlich Konstanten und Vars.
+
+Verweisen Sie darauf mit der üblichen Ausdruckssyntax `$(...)` in den Felddefinitionen des Unterformulars:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` ist ein Hilfsmittel **nur für das Frontend**. Es wird aus den Ansible-Extravars entfernt und nie an das Playbook gesendet.
diff --git a/i18n/de/_build_forms/forms/ansible.md b/i18n/de/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..950103a
--- /dev/null
+++ b/i18n/de/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Ansible-Formulare
+parent: Formulare
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Ansible-Formulare
+{: .no_toc }
+
+Formulare, die ein lokales Ansible-Playbook ausführen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: ansible` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/approval.md b/i18n/de/_build_forms/forms/approval.md
new file mode 100644
index 0000000..5ad5f24
--- /dev/null
+++ b/i18n/de/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Genehmigungspunkte
+parent: Formulare
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Genehmigungspunkte
+{: .no_toc }
+
+Einen Job anhalten, bis jemand ihn genehmigt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Funktionsweise
+
+Ein Genehmigungspunkt hält den Job an seiner Stelle im Formular an, bis ein Genehmiger darauf antwortet:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Den eigenen Job genehmigen
+
+Ab 7.3.0 kann der Benutzer, der einen Job gestartet hat, ihn nicht genehmigen, selbst mit einer der Rollen der Genehmigung; es braucht also eine zweite Person. Ein Admin kann immer genehmigen, auch die eigenen Jobs.
+Der Starter kann seinen eigenen Job weiterhin ablehnen (zurückziehen). Setzen Sie `allowSelf: true`, wenn er ihn auch genehmigen darf, etwa in einem Testformular:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Attribute
+
+Die Attribute eines Genehmigungspunkts:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für Genehmigungspunkte, in YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Definition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/awx.md b/i18n/de/_build_forms/forms/awx.md
new file mode 100644
index 0000000..e7a724c
--- /dev/null
+++ b/i18n/de/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: AWX-Formulare
+parent: Formulare
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# AWX-Formulare
+{: .no_toc }
+
+Formulare, die eine Job-Vorlage von AWX, AAP oder Ascender starten
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: awx` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/common.md b/i18n/de/_build_forms/forms/common.md
new file mode 100644
index 0000000..fb8010c
--- /dev/null
+++ b/i18n/de/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Gemeinsame Eigenschaften
+parent: Formulare
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Gemeinsame Formulareigenschaften
+{: .no_toc }
+
+Eigenschaften, die alle Formulartypen gemeinsam haben
+{: .fs-6 .fw-300 }
+
+---
+
+Diese Eigenschaften gelten für **alle Formulartypen**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (veraltet) und `subform`.
+
+Alle anderen Eigenschaften sind typspezifisch und auf der Seite des jeweiligen Formulartyps dokumentiert.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Eigenschaften
+
+Die Eigenschaften, die alle Formulartypen gemeinsam haben:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/de/_build_forms/forms/index.md b/i18n/de/_build_forms/forms/index.md
new file mode 100644
index 0000000..eb16838
--- /dev/null
+++ b/i18n/de/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formulare
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formulare
+{: .no_toc }
+
+Die Formulare definieren, die Ihre Benutzer ausfüllen
+{: .fs-6 .fw-300 }
+
+---
+
+Für Formularautoren: wie Formulare in YAML geschrieben werden, woher sie geladen werden und welche Eigenschaften jeder Formulartyp hat.
+
+Formulare sind der Kern von AnsibleForms. Jedes Formular ist eine Weboberfläche, die Benutzereingaben sammelt und mit diesen Daten ein
+Ansible-Playbook, eine Vorlage von AWX, AAP oder Ascender, eine Semaphore-Vorlage, einen Rundeck- oder Jenkins-Job oder einen
+[Workflow](../workflows/) ausführt.
+
+Formulare werden in YAML-Dateien im Formularordner definiert. Jede YAML-Datei enthält entweder ein einzelnes Formular oder eine Liste von Formularen, und Unterordner können zur Organisation verwendet werden.
+
+**VIDEO**: [Ihr erstes Formular erstellen](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Aufbau eines Formulars
+
+Jedes Formular in AnsibleForms wird mit einer Reihe von Eigenschaften konfiguriert. **[Gemeinsame Eigenschaften](common.html)** listet die Eigenschaften auf, die für alle Formulartypen gelten; die typspezifischen Seiten beschreiben die zusätzlichen.
+
+---
+
+## Wie Formulare geladen werden
+
+AnsibleForms lädt Formulare von folgenden Orten:
+
+1. **AUS REPOSITORIES** : alle Repositories, bei denen der Schalter „Für Formulare verwenden“ aktiviert ist (mehrere Repositories werden unterstützt)
+   - Formulare aus allen aktivierten Repositories werden automatisch zusammengeführt.
+   - In jedem Repository wird zuerst nach einem Unterordner `forms/` gesucht.
+   - Gibt es keinen Unterordner `forms/`, wird das Stammverzeichnis des Repositorys verwendet.
+   - Formulare, die im Designer erstellt und noch nicht gepusht wurden, liegen in einem Staging-Ordner
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) und werden mit ihnen geladen.
+
+2. **AUS DEM LOKALEN ORDNER** : der lokale Ordner `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), wenn bei keinem Repository „Für Formulare verwenden“ aktiviert ist
+
+{: .warning }
+> **Hinweis:** Ist „Für Formulare verwenden“ bei mehreren Repositories aktiviert, werden alle ihre Formulare zusammengeführt. Formularnamen müssen über alle Repositories hinweg eindeutig sein, um Konflikte zu vermeiden.
+
+---
+
+## Wo ein Formular läuft
+
+Der Typ eines Formulars bestimmt die Art von [Runner](../runners.html), auf dem sein Job läuft: ein RTE für `ansible`, ein AWX-Runner für `awx`,
+`aap` und `ascender` und ein Runner des eigenen Typs für `semaphore`, `rundeck` und `jenkins`.
+
+- `runner: <name>` am Formular wählt einen Runner dieses Typs nach Namen; ohne diese Angabe läuft der Job auf dem Standard-Runner des Typs.
+- Ein unter **Verbindungen > Runner** deaktivierter Runner lässt den Job fehlschlagen, egal ob das Formular ihn nennt oder er der Standard ist. Der Job
+  weicht nie auf einen anderen Runner aus.
+- Wenn eine der Rollen des Benutzers in `config.yaml` die Liste `runners` enthält, darf der Job nur auf einem Runner laufen, den eine solche Rolle aufführt, sonst wird er
+  abgelehnt. Rollen ohne diese Liste begrenzen nichts, und ein Admin wird nie begrenzt.
+
+---
+
+## In diesem Abschnitt
+
+Die folgenden Seiten beschreiben die Formulareigenschaften im Detail:
+
+| Seite | Inhalt |
+|---|---|
+| [Gemeinsame Eigenschaften](common.html) | Eigenschaften, die für alle Formulartypen gelten (`name`, `description`, `help`, `type`, `fields`) |
+| [Ansible-Formulare](ansible.html) | Eigenschaften speziell für `type: ansible` |
+| [AWX-Formulare](awx.html) | Eigenschaften speziell für `type: awx` |
+| [Semaphore-Formulare](semaphore.html) | Eigenschaften speziell für `type: semaphore`, das eine Semaphore-Vorlage ausführt |
+| [Rundeck-Formulare](rundeck.html) | Eigenschaften speziell für `type: rundeck`, das einen Rundeck-Job ausführt |
+| [Jenkins-Formulare](jenkins.html) | Eigenschaften speziell für `type: jenkins`, das einen Jenkins-Job baut |
+| [Mehrstufige Formulare](multistep.html) | Eigenschaften speziell für `type: multistep`, veraltet zugunsten von `workflow` |
+| [Workflow-Formulare](workflow.html) | Eigenschaften speziell für `type: workflow`, das einen [Workflow](../workflows/) ausführt |
+| [Wizard](wizard.html) | Die Eingaben eines Formulars auf mehrere Seiten verteilen (funktioniert mit jedem ausführbaren Formulartyp) |
+| [Unterformular](subform.html) | Unterformulare verwenden nur die gemeinsamen Eigenschaften |
+| [Genehmigungspunkte](approval.html) | Einen Job anhalten, bis er genehmigt wird (`approval`) |
+| [Benachrichtigungen](notifications.html) | E-Mails und Kanalnachrichten bei Jobstatus oder Ereignissen senden (`notifications`) |
+| [Aktionen bei Jobstatus](job-status-action.html) | Auf dem Formular reagieren, wenn ein Job seinen Status ändert (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/de/_build_forms/forms/jenkins.md b/i18n/de/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..6fd1636
--- /dev/null
+++ b/i18n/de/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Jenkins-Formulare
+parent: Formulare
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Jenkins-Formulare
+{: .no_toc }
+
+Formulare, die einen Jenkins-Job bauen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: jenkins` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/job-status-action.md b/i18n/de/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..435efae
--- /dev/null
+++ b/i18n/de/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Aktionen bei Jobstatus
+parent: Formulare
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Aktionen bei Jobstatus
+{: .no_toc }
+
+Auf dem Formular reagieren, wenn sein Job abgesendet wird, erfolgreich ist, fehlschlägt oder endet
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Folgende Hooks stehen zur Verfügung:
+
+- `onSubmit`: wird ausgelöst, wenn das Formular abgesendet wird
+- `onSuccess`: wird ausgelöst, wenn der Job erfolgreich abgeschlossen wird
+- `onFailure`: wird ausgelöst, wenn der Job fehlschlägt
+- `onFinish`: wird ausgelöst, wenn der Job endet, unabhängig von seinem Status
+- `onAbort`: wird ausgelöst, wenn der Job abgebrochen wird
+
+---
+
+## Attribute
+
+Die Attribute einer Aktion bei Jobstatus:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für Aktionen bei Jobstatus, in YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Definition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/multistep.md b/i18n/de/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..3e59e4a
--- /dev/null
+++ b/i18n/de/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Mehrstufige Formulare
+parent: Formulare
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Mehrstufige Formulare
+{: .no_toc }
+
+Mehrere Playbooks oder Vorlagen nacheinander aus einem Formular ausführen
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` ist seit 7 veraltet und wird in 8 entfernt: Verwenden Sie stattdessen einen [Workflow](workflow.html). Ein Workflow kann alles, was ein
+> Multistep kann, dazu Bedingungen, eigene Werte pro Knoten, Genehmigungsknoten und Zweige, die parallel laufen.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaft auf Formularebene
+
+Ein mehrstufiges Formular definiert seine Schritte in einer einzigen Eigenschaft auf Formularebene:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / erforderlich</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Neben `steps` akzeptiert ein mehrstufiges Formular folgende Eigenschaften auf Formularebene, die auf der Seite [Ansible-Formulare](ansible.html) dokumentiert sind:
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (erforderlich){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Eigenschaften der Schritte
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Nur verfügbar bei den Typen:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Hinzugefügt</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Beispiele
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Beispiel
+
+Ein mehrstufiges Formular führt mehrere Jobs nacheinander aus, wobei jeder Schritt sein eigenes Playbook oder seine eigene AWX-Vorlage startet. Alle Schritte teilen sich die Felder des Formulars: Standardmäßig erhält jeder Schritt die vollständigen Extravars, und der `key` eines Schritts beschränkt ihn auf diesen Teil davon.
+
+### Einen Server erstellen und konfigurieren
+
+Jeder Schritt erhält seinen eigenen Teil der Extravars: Ein AWX-Schritt erstellt den Server, ein Ansible-Schritt konfiguriert sein Netzwerk, und ein letzter Schritt sendet immer einen Bericht:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/de/_build_forms/forms/notifications.md b/i18n/de/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..8eb7053
--- /dev/null
+++ b/i18n/de/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Benachrichtigungen
+parent: Formulare
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Benachrichtigungen
+{: .no_toc }
+
+Eine E-Mail oder eine Kanalnachricht senden, wenn ein Job endet oder etwas mit ihm geschieht
+{: .fs-6 .fw-300 }
+
+---
+
+Die `notifications` eines Formulars legen fest, wer über seine Jobs informiert wird und wann:
+
+- **Wer**: `recipients`, E-Mail-Adressen, und `channels`, die Namen von
+  [Benachrichtigungskanälen](../notification-channels.html) (Mail, Slack, Microsoft Teams, Telegram, ein Webhook). Mindestens eines
+  der beiden ist erforderlich.
+- **Wann**: `onStatus`, wenn ein Job endet (`success`, `failed`, `aborted`, `warning` oder `any`), und `onEvent`, wenn
+  etwas mit einem Job geschieht (`launch`, `relaunch`, `delete`, `approve`, `reject` oder `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Attribute
+
+Die Attribute des Objekts `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Beispiele
+
+Beispiele für Benachrichtigungen, in YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Die Definition, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/rundeck.md b/i18n/de/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..9797521
--- /dev/null
+++ b/i18n/de/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Rundeck-Formulare
+parent: Formulare
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Rundeck-Formulare
+{: .no_toc }
+
+Formulare, die einen Rundeck-Job ausführen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: rundeck` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/semaphore.md b/i18n/de/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..1cd8bbf
--- /dev/null
+++ b/i18n/de/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Semaphore-Formulare
+parent: Formulare
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Semaphore-Formulare
+{: .no_toc }
+
+Formulare, die eine Vorlage von Semaphore UI ausführen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: semaphore` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/forms/subform.md b/i18n/de/_build_forms/forms/subform.md
new file mode 100644
index 0000000..cfb078d
--- /dev/null
+++ b/i18n/de/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Unterformular
+parent: Formulare
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Unterformular
+{: .no_toc }
+
+Ein wiederverwendbarer Formularbaustein für list-Felder, yaml-Felder und Wizard-Seiten
+{: .fs-6 .fw-300 }
+
+---
+
+Ein Unterformular ist ein wiederverwendbarer Formularbaustein. Es erscheint nicht in der Kachelansicht und kann nicht direkt abgesendet werden. Stattdessen wird darauf verwiesen von:
+
+- einem [`list`](../formfields/list.html)-Feld: öffnet das Unterformular als Drilldown-Editor für jede Zeile
+- einem [`yaml`](../formfields/yaml.html)-Feld mit der Eigenschaft `subform`: öffnet das Unterformular als Drilldown-Editor für ein einzelnes Objekt
+- einem [`wizard`](wizard.html)-Schritt: stellt das Unterformular als eine Seite des Wizards dar
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Unterformulare haben **keine typspezifischen Eigenschaften**. Sie verwenden nur die [gemeinsamen Formulareigenschaften](common.html): `name`, `description`, `help`, `type` und `fields`.
+
+Dient ein Unterformular als Wizard-Seite, liefern seine `description` und `help` die Standardwerte für `title` und `help` des Schritts. Es kann außerdem `showHelp` setzen, um diese Hilfe beim Laden der Seite aufzuklappen.
+
+Ausführungseigenschaften (`playbook`, `template`, `roles`, `inventory` usw.) gelten nicht für Unterformulare, da ein Unterformular nie direkt abgesendet wird.
+
diff --git a/i18n/de/_build_forms/forms/wizard.md b/i18n/de/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..4eeef8b
--- /dev/null
+++ b/i18n/de/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Wizard
+parent: Formulare
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Wizard
+{: .no_toc }
+
+Die Eingaben eines Formulars mit Zurück und Weiter auf Seiten verteilen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Was ist ein Wizard?
+
+Ein **Wizard** macht aus einem einzelnen Formular eine Folge von Seiten. Jede Seite wird aus einem [`subform`](subform.html) dargestellt, und der Benutzer navigiert mit den Schaltflächen **Zurück** und **Weiter**. Die Validierung gilt pro Seite: Der Benutzer kann erst weitergehen, wenn der aktuelle Schritt gültig ist, es sei denn, der Schritt ist als `optional` markiert.
+
+Am Ende jedes Wizards wird automatisch eine schreibgeschützte **Übersichtsseite** angehängt. Sie listet jeden Schritt mit den gesammelten Werten auf, damit der Benutzer sie vor dem Absenden bestätigen kann. Die Übersichtsseite wird **nicht** in YAML deklariert; ihr Titel stammt aus der aktiven Sprache.
+
+Beim Absenden werden die **gesammelten Werte aller Schritte zu einer einzigen Extravars-Payload zusammengeführt** und an das zugrunde liegende Playbook, die Vorlage oder den Workflow gesendet, genau so, als hätte der Benutzer ein einziges großes Formular ausgefüllt.
+
+Ein Formular mit `wizard` braucht keine eigenen `fields`, kann aber `enableForChat` nicht setzen, und ein `subform` kann selbst keinen `wizard` haben. Die [Start-Validierung](../launch-validation/rolling-it-out.html#wizard-forms) prüft den Start eines Wizards Schritt für Schritt.
+
+{: .note }
+> Wie sich ein `wizard` von einem Workflow unterscheidet und wie sich beide kombinieren lassen, steht im FAQ-Eintrag [Was ist der Unterschied zwischen einem Wizard und einem Workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Eigenschaft auf Formularebene
+
+Ein Wizard wird mit einer einzigen Eigenschaft auf Formularebene aktiviert:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">hinzugefügt in Version {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Beispiele:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften der Wizard-Schritte
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / eindeutig</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Hinzugefügt</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Beispiele
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Einen Wizard mit einem Workflow kombinieren
+
+Ein Wizard lässt sich auf ein [Workflow](workflow.html)-Formular aufsetzen. Wenn das `defaultModel` jedes Wizard-Schritts zum [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) des entsprechenden Workflow-Knotens passt, erhält jedes Playbook und jede Vorlage nur die Werte der eigenen Wizard-Seite.
+
+Die FAQ enthält ein ausgearbeitetes Beispiel und den Aufbau der zusammengeführten Extravars: [Was ist der Unterschied zwischen einem Wizard und einem Workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (Abschnitt *Kombiniert (Wizard auf einem Workflow)*).
+
+Ein Wizard auf einem veralteten [`multistep`](multistep.html)-Formular funktioniert genauso, mit dem [`key`](multistep.html#step_key) des Schritts statt `extra_vars_key`.
+
+---
+
+## Siehe auch
+
+Verwandte Seiten und FAQ-Einträge:
+
+- [Unterformular](subform.html): Wizard-Seiten werden aus Unterformularen dargestellt
+- [Workflow-Formulare](workflow.html): das Gegenstück des Wizards auf der Ausführungsebene
+- [`__parent__` in Unterformularen](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): wie Sie aus einem späteren Schritt auf frühere Wizard-Schritte verweisen
diff --git a/i18n/de/_build_forms/forms/workflow.md b/i18n/de/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..24812a7
--- /dev/null
+++ b/i18n/de/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Workflow-Formulare
+parent: Formulare
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Workflow-Formulare
+{: .no_toc }
+
+Formulare, die einen der Workflows des Designers ausführen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschaften
+
+Eigenschaften, die speziell für `type: workflow` gelten, zusätzlich zu den [gemeinsamen Formulareigenschaften](common.html). Der Abschnitt
+[Workflows](../workflows/) beschreibt die Workflow-Dateien selbst.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Kommentare</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / erforderlich</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">hinzugefügt in Version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Auswahlmöglichkeiten:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (Standard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Beispiele:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/de/_build_forms/launch-validation/file-uploads.md b/i18n/de/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..1fe915a
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Datei-Uploads
+parent: Start-Validierung
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Datei-Uploads
+{: .no_toc }
+
+Wie Dateifelder validiert werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ein Dateifeld vertraut nie dem, was die Startanfrage über eine Datei sagt. Die Start-Validierung prüft die Datei selbst, auf der
+Festplatte des Servers.
+
+---
+
+## Wie ein Upload zu einem Job gelangt
+
+Eine Datei wird hochgeladen, bevor das Formular gestartet wird, in zwei Schritten:
+
+1. Der Browser lädt die Datei mit `POST /api/v2/job/upload` hoch. Der Server speichert sie in `UPLOAD_PATH`.
+2. Die Startanfrage beschreibt diesen Upload in ihrem Teil `files`.
+
+Die Start-Validierung prüft dann die Beschreibung gegen die Festplatte:
+
+* Die Datei muss innerhalb von `UPLOAD_PATH` existieren.
+* Ihr Pfad und ihre Größe werden von der Festplatte gelesen, nie aus der Anfrage.
+
+---
+
+## Was akzeptiert wird
+
+Ein Dateifeld erhält nur aus einem verifizierten Upload einen Wert. Alles andere wird verworfen:
+
+* Ein Pfad, den der Aufrufer in `rawFormData` oder `extravars` schreibt, wird ignoriert.
+* Ein Pflicht-Dateifeld ohne echten Upload wird als `missing` gemeldet.
+
+---
+
+## Dateiregeln
+
+Die Regeln eines Dateifelds werden gegen den echten Upload geprüft, mit Größen in Bytes:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` und `maxSize` vergleichen die echte Größe der Datei, und `regex` ihren Dateinamen. Unabhängig von jedem Formular
+begrenzt `UPLOAD_MAX_GB` die Größe eines einzelnen Uploads (standardmäßig 10 GB).
diff --git a/i18n/de/_build_forms/launch-validation/index.md b/i18n/de/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..5c061d7
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Start-Validierung
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Start-Validierung
+{: .no_toc }
+
+Jeden Start eines Formulars auf dem Server prüfen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren und Formularautoren: Lassen Sie den Server jeden Start prüfen, seine Regeln und seine Extravars, egal wer ihn sendet.
+
+Die Prüfung gilt unabhängig davon, wer oder was das Formular startet: der Browser, ein Skript, das die REST-API aufruft,
+oder ein KI-Agent über den MCP-Server.
+
+---
+
+## Warum es sie gibt
+
+Die Regeln eines Formulars (`required`, `regex`, `minValue`, `sameAs`, ...) wurden schon immer
+im Browser geprüft. Der Browser sendet dann zwei Dinge an `POST /api/v2/job`:
+
+- `rawFormData`: die Feldwerte, wie der Benutzer sie ausgefüllt hat;
+- `extravars`: was das Playbook erhält, im Browser aus diesen Werten aufgebaut.
+
+Ohne Start-Validierung vertraut der Server beidem. Jeder mit einem gültigen Token kann diesen
+Endpunkt direkt aufrufen und beliebige Extravars senden, ohne dass eine Regex, ein Pflichtfeld oder eine Listenregel
+angewendet wird. Für ein Formular, das nur im Browser verwendet wird, mag das akzeptabel sein; für ein
+Formular, das andere Systeme über REST starten, heißt das, dass die Regeln des Formulars überhaupt nicht durchgesetzt werden.
+
+Der Server kann außerdem eine Anfrage aus dem Browser nicht von einer unterscheiden, die ein
+Skript sendet: Beide verwenden denselben Endpunkt, dasselbe Token und denselben Body, und Benutzer können
+jede Anfrage verändern, die ihr eigener Browser sendet. Einer Prüfung kann man nur auf dem Server vertrauen, und die Start-Validierung
+ist diese Prüfung.
+
+---
+
+## Die drei Wege hinein
+
+Wie ein Start validiert wird, hängt davon ab, wie er ankommt, und vom Modus der Start-Validierung:
+
+| Gestartet von | Validiert | Extravars, mit denen der Job läuft |
+|---|---|---|
+| **MCP-Server** (KI-Agent) | immer, auf dem Server | immer vom Server aufgebaut |
+| **Browser** oder **REST-API**, Start-Validierung `off` | nur im Browser | die, die der Browser (oder Aufrufer) gesendet hat |
+| **Browser** oder **REST-API**, Start-Validierung `log` | auf dem Server, Ablehnungen nur protokolliert | die gesendeten; Unterschiede werden protokolliert |
+| **Browser** oder **REST-API**, Start-Validierung `enforce` | auf dem Server, bei Ungültigkeit abgelehnt | **vom Server aufgebaut** |
+
+Der Browser, der MCP-Server und die Start-Validierung verwenden denselben Code für die Regeln (die
+gemeinsame Formular-Engine): dieselben Regeln, in derselben Reihenfolge, mit denselben Meldungen. Einen Fehler, den der
+Browser anzeigt, lehnt der Server mit demselben Text ab.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Einschalten](switching-it-on.html) | Für die ganze Instanz oder für ein Formular |
+| [Log und Enforce](log-and-enforce.html) | Was jeder Modus mit einem Start macht, der die Regeln verletzt |
+| [Listenzeilen](list-rows-and-subforms.html) | Wie Zeilen von list-Feldern validiert werden |
+| [Datei-Uploads](file-uploads.html) | Wie Dateifelder validiert werden |
+| [Passwörter](passwords.html) | Wie Passwortfelder validiert und aus APIs herausgehalten werden |
+| [Neustarten](relaunching.html) | Wie ein neu gestarteter Job validiert wird |
+| [Einführung](rolling-it-out.html) | Eine Instanz auf Enforce umstellen, und die bekannten Einschränkungen |
diff --git a/i18n/de/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/de/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..d623a11
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Listenzeilen
+parent: Start-Validierung
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Listenzeilen
+{: .no_toc }
+
+Wie Zeilen von list-Feldern validiert werden
+{: .fs-6 .fw-300 }
+
+---
+
+Ein `list`-Feld enthält Zeilen; jede Zeile ist eine Instanz seines Unterformulars, ausgefüllt über den Zeileneditor.
+Ein `yaml`-Feld mit einem `subform` ist eine solche Zeile. Der Server behandelt sie genauso
+wie der Zeileneditor des Browsers: Jede Zeile wird über ihr Unterformular aufgelöst, mit den Werten des Formulars
+als `__parent__`, ihre Regeln werden geprüft und ihre berechneten Felder ausgewertet. Verschachtelte Listen funktionieren
+genauso: In der eigenen Liste einer Zeile erreicht `$(__parent__.__parent__.x)` das Formular.
+
+Zeilen werden wie folgt geprüft:
+
+- **Eine Zeile, die der Benutzer** im Editor **hinzugefügt oder bearbeitet hat**, wird aufgelöst und validiert.
+- **Eine Zeile, die niemand angefasst hat**, also eine, die der eigene Standardwert, Ausdruck oder die Abfrage der Liste erzeugt hat
+  (etwa die vorhandenen Einträge einer ACL-Liste), geht **genau so durch, wie sie kam**, wie im
+  Browser: Sie wird nicht erneut validiert, und es wird nichts hinzugefügt. Ein vorhandener Eintrag, der eine später
+  geschriebene Regel verletzt, hält den Start nicht auf.
+- **Eine als gelöscht markierte Zeile** (der `deleteMarker` der Liste) bleibt, wie sie ist, und wird nicht validiert.
+
+Um diese Zeilen zu unterscheiden, ohne der Anfrage zu vertrauen, führt der Server die eigene
+Quelle der Liste (ihren Standardwert, sonst ihren Ausdruck oder ihre Abfrage) unter der Start-Validierung erneut aus. Eine Zeile,
+die nicht durch den Editor ging, geht **nur dann unverändert durch, wenn sie eine der Zeilen ist, die diese
+Quelle erzeugt**. Jede andere Zeile, etwa eine von einem REST-Aufrufer erfundene, wird aufgelöst und
+wie eine bearbeitete Zeile validiert. Eine einfache Zeile kann die Prüfungen also nicht umgehen, während die
+unberührten Zeilen des Browsers weiterhin unverändert durchgehen.
+
+Ein Browser-Benutzer bemerkt das nur in einem Fall: Die Daten der Quelle haben sich zwischen dem Öffnen des
+Formulars und dem Start geändert (ein Eintrag wurde inzwischen geändert oder entfernt), **und** diese Zeile
+verletzt eine Regel ihres Unterformulars. Die Zeile zählt dann nicht mehr als eine der Zeilen der Quelle, wird also
+validiert, und der Start wird mit Nennung der Zeile abgelehnt, zum Beispiel
+`acls[2].user_or_group (regex)`.
+
+Fehlerhafte Zeilen erscheinen in `rowErrors` mit ihrem `index` (ein `yaml`-Feld hat keinen) und im Protokoll als
+`disks[1].size (maxValue)`.
+
+Ein Start darf über alle Verschachtelungsebenen hinweg höchstens **500 Zeilen** enthalten, da jede Zeile die Abfragen ihres Unterformulars ausführt.
+
+---
+
+## Zeilenmarker
+
+Die Marker, die eine Liste auf ihre Zeilen setzt (`insertMarker`, `updateMarker` und `deleteMarker`; ohne
+`insertMarker` erhalten neue Zeilen `__inserted__`, wenn die Liste `allowDelete: false`, einen `deleteMarker` oder einen `updateMarker` setzt),
+erreichen das Playbook bei jeder Zeile, die einen trägt. Eine entfernte Zeile wird mit ihrem Lösch-Marker
+gesendet, damit das Playbook sie entfernen kann. Vor 6.4.1 trug eine Listenzeile nur dann einen Marker, wenn ihr
+Unterformular ihn als (verstecktes) Feld deklarierte.
diff --git a/i18n/de/_build_forms/launch-validation/log-and-enforce.md b/i18n/de/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..806b57b
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Log und Enforce
+parent: Start-Validierung
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Log und Enforce
+{: .no_toc }
+
+Was jeder Modus mit einem Start macht, der die Regeln verletzt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Was `log` macht
+
+Jeder Start wird geprüft, aber für den Benutzer ändert sich nichts. Eine Warnung wird ins Protokoll geschrieben, wenn:
+
+- der Start **abgelehnt würde**, mit dem Grund (nur Feldnamen und Regeltypen, nie
+  Werte):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- die Extravars, die der Client gesendet hat, sich von denen **unterscheiden**, die der Server aufbaut, mit den
+  Schlüsseln der obersten Ebene, die sich unterscheiden:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Lassen Sie `log` zunächst eine Weile auf einer echten Instanz laufen. So sehen Sie, welche Formulare abgelehnt würden und
+welche auf dem Server andere Werte berechnen, bevor jemand betroffen ist.
+
+---
+
+## Was `enforce` macht
+
+Unter `enforce` wird ein ungültiger Start abgelehnt, und ein gültiger läuft mit den Extravars, die der Server
+aufbaut.
+
+### Ein Start, der die Regeln verletzt, wird abgelehnt
+
+`POST /api/v2/job` antwortet mit `422` und den fehlerhaften Feldern:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing`: Pflichtfelder ohne Wert;
+- `invalid`: Felder, die eine Regel verletzen, Auswahlen, die keine der Optionen sind, und list-Felder
+  mit einer fehlerhaften Zeile;
+- `waiting`: Felder, die nicht ausgewertet werden konnten (ein Feld, das sie brauchen, hat nie einen Wert bekommen);
+- `validationErrors`: pro Feld jede verletzte Regel mit der Meldung, die der Browser anzeigt;
+- `rowErrors`: pro list-Feld die fehlerhaften Zeilen (siehe [Listenzeilen](list-rows-and-subforms.html));
+- `uploads`: Dateifelder, deren Upload nicht verifiziert werden konnte.
+
+Ein Start **ohne `rawFormData`** wird ebenfalls abgelehnt: Seine Werte lassen sich nicht prüfen.
+
+### Ein gültiger Start läuft mit den Extravars des Servers
+
+Der Job läuft nicht mit den Extravars, die der Client gesendet hat. Der Server baut sie aus den geprüften
+Werten auf, mit demselben Code wie der Browser, und führt diese aus. Ein Aufrufer, der gültige
+`rawFormData` zusammen mit abweichenden `extravars` sendet, bekommt die Extravars, die zu den Werten passen, nicht
+die, die er gesendet hat.
+
+Aus der Anfrage übernimmt der Server `__verbose__` (nur für Benutzer, die den Verbose-Modus verwenden dürfen). Die
+reservierten Schlüssel (`__playbook__`, `__inventory__`, ...) kommen wie immer aus dem Formular, und
+`ansibleforms_user` ist der startende Benutzer.
+
+### Was der Benutzer sah, ist nicht immer das, was läuft
+
+Die Extravars aufzubauen heißt, das Formular erneut auszuwerten: Jeder Ausdruck und jede Abfrage läuft
+noch einmal auf dem Server, einen Moment nachdem der Browser sie ausgeführt hat, als der startende Benutzer. Ein Wert,
+der davon abhängt, **wann** oder **wo** er ausgewertet wird, kann abweichen, und in diesem Fall wird der
+Wert des Servers verwendet:
+
+| Was | Warum es abweichen kann | Wie stark |
+|---|---|---|
+| `fn.fnTime()`, ein Zeitstempel, ein aus der Uhrzeit gebildeter Name | erneut ausgewertet, ein paar Sekunden später | nur relevant an einer Sekunden- oder Datumsgrenze. `fnTime` läuft auch im Browser-Ablauf schon auf dem Server, mit derselben Zeitzone (dem `TZ` des Containers) |
+| eine Abfrage, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, ein Dateizugriff | die externen Daten haben sich zwischendurch geändert | nur wenn sie sich geändert haben |
+| ein `runLocal`-Ausdruck mit `new Date()`, `toLocaleString`, `Intl` | der Browser verwendet Zeitzone und Sprache des Benutzers, der Server seine eigenen | nur solche Ausdrücke |
+
+Dasselbe gilt für die **Validierung**: Eine Regel, die ein solches Feld liest (`notIn` gegen das Ergebnis einer Abfrage,
+`validIf` auf einem berechneten Flag), wird gegen den Wert des Servers geprüft. Formulare, deren
+Extravars abweichen, erscheinen in den oben beschriebenen `log`-Warnungen; prüfen Sie sie, bevor Sie Enforce einschalten.
diff --git a/i18n/de/_build_forms/launch-validation/passwords.md b/i18n/de/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..d3f4bdf
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Passwörter
+parent: Start-Validierung
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Passwörter
+{: .no_toc }
+
+Wie Passwortfelder validiert, gespeichert und aus APIs herausgehalten werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ein Passwortfeld wird wie jedes andere Feld validiert. Sein Wert bleibt jedoch auf dem Server und wird nie an
+einen Client zurückgegeben.
+
+---
+
+## Wo ein Passwort aufbewahrt wird
+
+Der Server speichert das Passwort mit dem Job, in seinen Extravars:
+
+* Eine **Genehmigung** kann den Job dann mit dem Passwort fortsetzen, das der Benutzer eingegeben hat.
+* Ein **Neustart wie gelaufen** kann es wiederverwenden, wenn die Start-Validierung nicht `enforce` ist.
+
+Das gespeicherte Passwort wird nur auf dem Server verwendet.
+
+---
+
+## Was die APIs zurückgeben
+
+Keine API gibt jemals ein Passwort zurück:
+
+* Ein Job, der über die REST-API oder `get_job` des MCP-Servers gelesen wird, maskiert jedes `password`-Feld seines Formulars, auch in
+  Listenzeilen und YAML-Unterformularen.
+* `MASK_EXTRAVARS_REGEX` (Standard `password|secret|token`) maskiert zusätzlich jede Extravar, deren Name passt, für
+  Secrets, die keine Passwortfelder sind.
+
+---
+
+## Was ein Neustart erhält
+
+Um einen Neustart vorauszufüllen, erhält der Browser die Roh-Formulardaten des Jobs. Diese Daten enthalten nie ein Passwort, auch nicht in
+Listenzeilen oder YAML-Unterformularen, sodass der Benutzer das Passwort erneut eingibt.
+
+Ein Passwortfeld, das die Abhängigkeiten des Formulars ausblenden, wird nicht gebraucht und muss nicht erneut eingegeben werden.
diff --git a/i18n/de/_build_forms/launch-validation/relaunching.md b/i18n/de/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..c52ed57
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Neustarten
+parent: Start-Validierung
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Neustarten
+{: .no_toc }
+
+Wie ein neu gestarteter Job validiert wird
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ein Job kann auf zwei Arten neu gestartet werden. Wie der Neustart geprüft wird, hängt davon ab, welche es ist, und vom Modus der
+Start-Validierung.
+
+---
+
+## Zwei Arten des Neustarts
+
+Die beiden Arten unterscheiden sich darin, ob der Aufrufer neue Werte sendet:
+
+* **Wie gelaufen**: die Schaltfläche Neu starten, `POST /api/v2/job/{id}/relaunch` ohne Body oder `relaunch_job` ohne
+  `values`.
+* **Mit Änderungen**: dieselben Aufrufe mit neuen Werten, die über die gespeicherten Feldwerte des Jobs gelegt werden:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Wie jede geprüft wird
+
+Der Modus der Start-Validierung entscheidet, ob ein Neustart wiederholt oder erneut geprüft wird:
+
+| Neustart | `off` / `log` | `enforce` |
+|---|---|---|
+| **Wie gelaufen** | wiederholt die gespeicherten Extravars des Jobs, Passwörter inklusive | die vollständige Prüfung, aus den gespeicherten Feldwerten |
+| **Mit Änderungen** | die vollständige Prüfung, auf den gespeicherten Werten mit den darübergelegten Änderungen | die vollständige Prüfung, auf dieselbe Weise |
+
+Eine Ausnahme unter `enforce`: Ein Job, den ein Zeitplan auf Admin-Ebene gestartet hat, hat keine eigenen Feldwerte, daher wiederholt ein Neustart wie gelaufen
+die gespeicherten Extravars des Zeitplans, für einen Admin oder einen Benutzer mit der Rollenoption `allowScheduledJobs`.
+
+Ein geprüfter Neustart (siehe [Log und Enforce](log-and-enforce.html)) startet einen neuen Job unter dem Namen des Aufrufers.
+
+---
+
+## Passwortfelder
+
+Gespeicherte Feldwerte enthalten keine Passwörter, daher hat ein geprüfter Neustart keines für ein **sichtbares Passwortfeld**:
+
+* Der Neustart wird als `unsupported` abgelehnt, mit den fehlenden `passwordFields`.
+* Starten Sie das Formular erneut und geben Sie das Passwort ein.
+* Ein Passwortfeld, das die Abhängigkeiten des Formulars **ausblenden**, wird nicht gebraucht und blockiert den Neustart nicht.
+
+Unter `enforce` gilt das auch für die Schaltfläche Neu starten.
+
+---
+
+## Wer neu starten darf
+
+Beide Arten des Neustarts setzen voraus:
+
+* dass das Formular Neustarts erlaubt (`allowRelaunch`, standardmäßig true);
+* die Rollenoption `allowJobRelaunch`;
+* dass der Benutzer **der Besitzer des Jobs** ist, ein Admin oder ein Benutzer mit der Rollenoption `manageAllJobs`.
+
+Alle Jobs sehen zu dürfen (`showAllJobLogs`) reicht nicht, um den Job eines anderen Benutzers neu zu starten. Genehmiger können einen Job sehen, der auf ihre
+Genehmigung wartet, ihn aber ebenfalls nicht neu starten.
diff --git a/i18n/de/_build_forms/launch-validation/rolling-it-out.md b/i18n/de/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..147f8b4
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Einführung
+parent: Start-Validierung
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Einführung
+{: .no_toc }
+
+Eine Instanz auf Enforce umstellen, und die bekannten Einschränkungen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Schrittweise einführen
+
+`enforce` ist der Standard. Auf einer Instanz mit Skripten oder anderen Systemen, die Formulare über
+REST starten, erreichen Sie ihn schrittweise und beobachten das Protokoll, bevor Sie etwas ablehnen:
+
+1. Setzen Sie `LAUNCH_VALIDATION=log` für die ganze Instanz (vor dem Upgrade, bei einem Upgrade).
+2. Lassen Sie die Instanz eine Weile in diesem Modus laufen und prüfen Sie das Protokoll: Warnungen `would refuse` zeigen Starts,
+   die die Regeln verletzen; Warnungen `extravars differ` zeigen Formulare, die auf dem Server etwas
+   anders berechnen (einen Zeitstempel, externe Daten). Entscheiden Sie für jedes Formular, ob das
+   eine Rolle spielt.
+3. Stellen Sie diese Formulare auf `launchValidation: enforce` um. Aufrufer, die ungültige Werte oder
+   erfundene Extravars gesendet haben, erhalten jetzt ein `422` mit dem Grund.
+4. Wenn sich jedes Formular wie erwartet verhält, entfernen Sie `LAUNCH_VALIDATION` (oder setzen Sie es auf `enforce`) für die ganze Instanz.
+
+---
+
+## Einschränkungen
+
+Die Start-Validierung deckt noch nicht alles ab:
+
+- **Wizard-Formulare** können nicht mit Änderungen neu gestartet werden, und ein Wizard-Job, der vor 7.0 gestartet wurde,
+  kann unter `enforce` nicht neu gestartet werden (er hat seine Schrittwerte nicht gespeichert). Der MCP-Server
+  kann keine Wizard-Formulare starten.
+- Die **Auflösung von Platzhaltern** im Browser verwendet noch eine eigene Kopie des Servercodes; in
+  seltenen Grenzfällen (`__undefined__`, Anführungszeichen in Ausdrücken) könnten beide einen
+  Platzhalter unterschiedlich auflösen. `log` zeigt solche Unterschiede.
+- **`runLocal`**-Ausdrücke laufen im Browser in dessen JavaScript-Engine und auf dem Server in einer
+  Sandbox; derselbe Code liefert dasselbe Ergebnis, außer wo er von
+  Zeitzone oder Sprache des Browsers abhängt.
+
+---
+
+## Wizard-Formulare
+
+Ein [Wizard](../forms/wizard.html) wird Schritt für Schritt geprüft: Der Browser sendet die Werte
+jedes Schritts, und der Server prüft jeden Schritt, den der Benutzer absenden würde, gegen dessen eigenes Unterformular.
+
+- Ein Schritt wird ausgelassen, wenn er `optional` ist und der Benutzer ihn übersprungen hat, oder wenn sein `when` false ist.
+- Ein Schritt liest die früheren Schritte über `$(__parent__.<step>.<field>)`, mit ihren geprüften Werten.
+- Fehler nennen den Schritt und das Feld, als `<step>.<field>`.
+- Unter `enforce` werden die Extravars auf dem Server aufgebaut, jeder Schritt unter seinem `defaultModel`.
+- Dateifelder werden in einem Wizard nicht unterstützt.
diff --git a/i18n/de/_build_forms/launch-validation/switching-it-on.md b/i18n/de/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..47aac47
--- /dev/null
+++ b/i18n/de/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Einschalten
+parent: Start-Validierung
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Einschalten
+{: .no_toc }
+
+Für die ganze Instanz oder für ein Formular
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Die Start-Validierung hat zwei Einstellungen. **Es gilt die strengere der beiden.**
+
+---
+
+## Für die ganze Instanz: `LAUNCH_VALIDATION`
+
+Die Umgebungsvariable [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) gilt für jedes Formular:
+
+- `off`: keine serverseitige Prüfung; der Job läuft mit den Extravars, die der Browser oder der Aufrufer gesendet hat.
+- `log`: Jeder Start wird geprüft; was abgelehnt würde, wird als Warnung ins Protokoll
+  geschrieben, und der Start läuft weiterhin wie bisher.
+- `enforce` (Standard): Ein ungültiger Start wird abgelehnt, und ein gültiger läuft mit den Extravars, die der
+  Server aufbaut.
+
+Ein leerer oder unbekannter Wert bedeutet ebenfalls `enforce`. Änderungen wirken ohne Neustart.
+
+{: .warning }
+> **Ein Upgrade ändert das Verhalten.** Eine Instanz, die `LAUNCH_VALIDATION` nicht setzt, erzwingt
+> nach dem Upgrade die Prüfung jedes Starts. Skripte, die `POST /api/v2/job` ohne `rawFormData` aufrufen
+> oder mit Werten, die die Regeln eines Formulars verletzen, werden mit `422` abgelehnt. Setzen Sie
+> `LAUNCH_VALIDATION=log` vor dem Upgrade, um zu sehen, was abgelehnt würde, oder `off`, um das
+> alte Verhalten beizubehalten (siehe [Einführung](rolling-it-out.html)).
+
+---
+
+## Für ein Formular: `launchValidation`
+
+Ein Formular kann seine eigene Stufe setzen:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Verwenden Sie diese Einstellung auf einer Instanz, die mit `off` oder `log` läuft, für ein Formular, von dem Sie wissen, dass es
+über REST gestartet wird: Für dieses Formular wird die Prüfung erzwungen, für den Rest der Instanz nicht. Sie lässt sich auch im Designer setzen, in den
+Formulareinstellungen.
+
+**Ein Formular kann strenger als die Instanz sein, nie lockerer.** Steht `LAUNCH_VALIDATION`
+auf `enforce`, hat `launchValidation: off` in einem Formular keine Wirkung: Ein Formular kann
+die Entscheidung eines Betreibers nicht übergehen.
+
+Wizard-Formulare nutzen sie ebenfalls: Der Start eines Wizards wird Schritt für Schritt geprüft, jeder Schritt gegen sein eigenes
+Unterformular (siehe [Wizard-Formulare](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/de/_build_forms/workflows/designer.md b/i18n/de/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..3c1b9a8
--- /dev/null
+++ b/i18n/de/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Im Designer bearbeiten
+parent: Workflows
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Im Designer bearbeiten
+{: .no_toc }
+
+Einen Workflow zeichnen und ausprobieren, ohne etwas auszuführen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Der Bereich Workflows
+
+**Designer > Workflows** listet die Workflow-Dateien in einem Datei-Explorer auf, mit den Tabs YAML, Visuell und Vorschau, die jeder
+Bereich des [Designers](../designer/) hat.
+
+- **Die Schaltfläche `+`** in der Werkzeugleiste erstellt eine Workflow-Datei mit einem leeren Workflow als Ausgangspunkt.
+- **YAML** zeigt die Datei so, wie sie geschrieben ist. Kommentare und die Reihenfolge der Schlüssel bleiben auch in den anderen Tabs erhalten.
+- **Visuell** zeichnet jeden Workflow der Datei als Graph, mit Name und Beschreibung darüber. Eine Datei mit zwei Workflows
+  zeigt beide, einen unter dem anderen.
+- **Vorschau** ist ein Probelauf des Workflows: siehe [Ausprobieren](#trying-it-out).
+
+Probleme werden über dem Graph aufgelistet, jedes mit einem Link, der das YAML in der betreffenden Zeile öffnet: ein Link zu einem Knoten, den es nicht
+gibt, eine Schleife, ein Playbook, Inventar, Zugangsdaten, ein Runner oder Repository, die der Designer nicht kennt.
+
+---
+
+## Der Graph
+
+Der Graph liest sich von links nach rechts, von **START** bis zu den letzten Knoten. Jeder Knoten zeigt seinen Bezeichner und darunter, was
+er ausführt; die Verbindungen sind danach eingefärbt, was sie auslöst, wie die Legende im Graph sagt: bei Erfolg, bei Fehler,
+immer.
+
+- **Klicken Sie auf START**, um einen ersten Knoten hinzuzufügen: einen Knoten ohne Eltern, der läuft, sobald der Workflow startet.
+- **Klicken Sie auf einen Knoten**, um ihn zu bearbeiten.
+- **Klicken Sie auf eine Verbindung**, um zu ändern, was sie auslöst, oder um sie zu entfernen.
+
+---
+
+## Einen Knoten hinzufügen
+
+Ein neuer Knoten wird mit einem Wizard hinzugefügt: **Neuer Knoten bei Erfolg**, **Neuer Knoten bei Fehler** oder **Neuer Knoten immer** an einem vorhandenen
+Knoten, oder START für einen ersten.
+
+1. **Was er ausführt**: der Bezeichner des Knotens, **Führt aus** (welche Art von Knoten es ist und, bei einem Playbook-Knoten, wo er läuft)
+   und was er ausführt: ein Playbook oder eine Vorlage oder einen Job, einen Workflow, Name und Zeitlimit einer Genehmigung oder ein Repository. Siehe
+   [Wo ein Knoten läuft](#where-a-node-runs).
+2. **Wie er läuft**: die Ausführungseinstellungen: das Inventar, die Zugangsdaten, das Limit, die Tags, die Ausführlichkeit,
+   Check- und Diff-Modus, die Bedingung (**Läuft, wenn**) und **Werte aus** (siehe [die Workflow-Datei](file.html#run-settings)).
+3. **Wohin er führt**: der Knoten, nach dem er läuft, und wann.
+
+**Erstellen** fügt den Knoten in das YAML ein.
+
+---
+
+## Wo ein Knoten läuft
+
+**Führt aus** sagt in einer einzigen Liste, was ein Knoten ausführt und wo: **Playbook auf dem RTE**, **Vorlage auf AWX**, **Vorlage auf
+Semaphore**, **Job auf Rundeck**, **Job auf Jenkins**, dann **Workflow**, **Genehmigung** und **Repository-Pull**.
+
+| Führt aus | Das Feld darunter | Runner |
+|---|---|---|
+| **Playbook auf dem RTE** | **Playbook**: ein Playbook des Designers | **Das Standard-RTE** oder ein RTE-Runner nach Namen |
+| **Vorlage auf AWX** (AAP und Ascender eingeschlossen) | **Vorlage**: der Name der Vorlage, eingetippt | die AWX-Runner, jeder mit seiner Variante |
+| **Vorlage auf Semaphore** | **Vorlage**: der Name der Vorlage, eingetippt | die Semaphore-Runner |
+| **Job auf Rundeck** oder **Job auf Jenkins** | **Job**: der Name des Jobs, eingetippt | die Rundeck- oder Jenkins-Runner |
+
+- **Playbook auf dem RTE** wird immer angeboten, die anderen nur, wenn die Instanz einen [Runner](../runners.html) dieses Typs hat.
+- **Runner** listet nur die Runner dieses Typs auf, der Standard-Runner ist markiert und vorausgewählt (oder der erste nach Namen).
+- Wenn Sie einen anderen Ort wählen, wird geleert, was der Knoten ausführt, sodass es neu gewählt wird.
+- Ein Knoten, dessen Runner der Designer nicht kennt, zeigt **Vorlage oder Job auf** diesem Runner.
+
+Die Workflow-Datei ändert sich nicht: Ein solcher Knoten ist ein `job_template`-Knoten mit einem `runner:` (siehe
+[die Workflow-Datei](file.html#run-settings)).
+
+---
+
+## Einen Knoten bearbeiten
+
+Ein Klick auf einen Knoten öffnet seinen Dialog, mit vier Tabs:
+
+| Tab | Was er enthält |
+|---|---|
+| **Was er ausführt** | Den Bezeichner, **Führt aus**, was er ausführt und, bei einem Playbook-Knoten, den Runner |
+| **Wie er läuft** | Die Ausführungseinstellungen; Zugangsdaten werden aus einer Liste gewählt, jede mit `+` hinzugefügt |
+| **Läuft nach** | Die Verbindungen in den Knoten hinein, und **Alle Eltern müssen zusammenlaufen** |
+| **Danach** | Die Verbindungen aus ihm heraus, mit **Mit einem vorhandenen Knoten verbinden:** und **Mit einem neuen Knoten verbinden:** |
+
+**In YAML zeigen** öffnet das YAML am Knoten, und **Knoten entfernen** entfernt ihn mit seinen Verbindungen. Jede Änderung wird sofort ins
+YAML geschrieben; **Speichern** speichert die Datei.
+
+---
+
+## Ausprobieren
+
+Der Tab **Vorschau** spielt den Workflow durch, ohne etwas zu starten, nach den Regeln von AWX.
+
+Jeder Knoten beginnt als Erfolg. Klicken Sie auf einen Knoten, damit er fehlschlägt, und erneut, damit er gelingt; der Graph zeigt dann,
+welche Knoten laufen würden, welche nicht laufen würden und ob der Workflow fehlschlagen würde. **Zurücksetzen** lässt alle Knoten wieder gelingen.
diff --git a/i18n/de/_build_forms/workflows/file.md b/i18n/de/_build_forms/workflows/file.md
new file mode 100644
index 0000000..d9e9e6c
--- /dev/null
+++ b/i18n/de/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Die Workflow-Datei
+parent: Workflows
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# Die Workflow-Datei
+{: .no_toc }
+
+Die Workflow-Syntax, die Knotentypen und die Ausführungseinstellungen jedes Knotens
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wo Workflow-Dateien liegen
+
+Workflow-Dateien sind YAML-Dateien im lokalen Workflow-Ordner und in jedem Repository, das für Workflows verwendet wird.
+
+- **Der lokale Ordner** ist [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), standardmäßig `workflows` unter dem
+  persistenten Ordner.
+- **Ein Repository**, bei dem **Für Workflows verwenden?** eingeschaltet ist, wird als Ganzes gelesen, sodass seine Workflow-Dateien in jedem Ordner liegen können. Der
+  Designer speichert sie zurück ins Repository, und **Push** sendet sie an das Remote.
+
+Jede YAML-Datei, die `workflow_job_templates` enthält, wird gelesen, bis zu sechs Ordnerebenen tief, und eine Datei kann mehrere
+Workflows enthalten. Ein Formular nennt einen Workflow über seinen `name`, halten Sie die Namen also eindeutig: Wenn zwei Workflows denselben Namen haben, schlägt ein Job, der
+ihn ausführt, fehl und fordert auf, einen davon umzubenennen.
+
+---
+
+## Die Syntax
+
+Eine Workflow-Datei wird in der Syntax eines AWX-Exports geschrieben, mit den Knoten unter `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+Die Struktur der Collection `awx.awx` wird ebenfalls gelesen: `workflow_nodes` direkt unter dem Workflow, und Namen als
+einfache Zeichenketten (`inventory: staging`) statt als Maps (`inventory: {name: staging}`).
+
+### Der Workflow
+
+Ein Workflow-Eintrag hat neben seinen Knoten einige eigene Schlüssel:
+
+| Schlüssel | Was er ist |
+|---|---|
+| `name` | Der Name des Workflows, den das `workflow:` eines Formulars nennt |
+| `description` | Wofür er gedacht ist, im Designer angezeigt |
+| `extra_vars` | Variablen, die jeder Knoten erhält; die Werte des Formulars haben Vorrang |
+| `related.workflow_nodes` | Die Knoten |
+
+### Ein Knoten
+
+Jeder Knoten hat einen Bezeichner, das, was er ausführt, und seine Verbindungen:
+
+| Schlüssel | Was er ist |
+|---|---|
+| `identifier` | Die ID des Knotens: Buchstaben, Ziffern, Punkte, Bindestriche, Doppelpunkte und Unterstriche, eindeutig im Workflow |
+| `unified_job_template.type` | Was der Knoten ausführt: siehe [Knotentypen](#node-types) |
+| `unified_job_template.name` | Das Playbook, der Workflow, die Genehmigung oder das Repository, das er ausführt |
+| `related.success_nodes` | Die Knoten, die laufen, wenn dieser erfolgreich ist |
+| `related.failure_nodes` | Die Knoten, die laufen, wenn dieser fehlschlägt |
+| `related.always_nodes` | Die Knoten, die laufen, wenn dieser beendet ist, egal wie |
+| `all_parents_must_converge` | `true`: Der Knoten wartet, bis jede Verbindung in ihn hinein ausgelöst hat, nicht nur eine |
+
+Verbindungen müssen vorwärts führen: Ein Workflow, dessen Verbindungen eine Schleife bilden, läuft nicht.
+
+---
+
+## Knotentypen
+
+Ein Knoten führt eines von vier Dingen aus, benannt wie in AWX:
+
+| Typ | Was der Knoten ausführt |
+|---|---|
+| `job_template` | Eines der Playbooks des Designers, als eigenen Job auf dem RTE; oder, mit `runner:`, die Vorlage oder den Job dieses Runners |
+| `workflow_job_template` | Einen anderen Workflow, als untergeordneten Workflow-Job; Workflows lassen sich bis zu fünf Ebenen tief verschachteln |
+| `workflow_approval_template` | Eine Genehmigung: Der Workflow-Job wartet, bis jemand genehmigt oder ablehnt |
+| `project` | Einen Pull des genannten Repositorys (das Projekt-Update von AWX) |
+
+Das `unified_job_template.timeout` eines Genehmigungsknotens ist in Sekunden angegeben. Läuft es ohne Antwort ab, schlägt der Knoten fehl; `0` oder kein
+Zeitlimit wartet beliebig lange auf eine Antwort. Eine abgelehnte Genehmigung lässt den Knoten fehlschlagen, und der Workflow geht entlang seiner
+Verbindungen weiter.
+
+---
+
+## Ausführungseinstellungen
+
+Ein `job_template`-Knoten übernimmt die Einstellungen eines AWX-Knotens, direkt am Knoten:
+
+| Schlüssel | Was er bewirkt |
+|---|---|
+| `inventory` | Das Inventar, gegen das das Playbook läuft, über seinen Namen, wie das `inventory:` eines Formulars |
+| `related.credentials` | Die Zugangsdaten: Jeder Eintrag erreicht das Playbook unter seinem eigenen Namen, und der erste vom Typ *SSH* ist auch der Login, mit dem sich Ansible verbindet. Ein Vault-Eintrag öffnet nur die Vaults |
+| `limit` | Läuft nur auf diesen Hosts (`--limit`) |
+| `job_tags` | Führt nur die Tasks mit diesen Tags aus (`--tags`) |
+| `skip_tags` | Überspringt die Tasks mit diesen Tags (`--skip-tags`) |
+| `verbosity` | `0` bis `5`: die Anzahl der `-v` |
+| `diff_mode` | `true`: zeigt die Änderungen (`--diff`) |
+| `job_type` | `check`: ein Probelauf (`--check`); `run` oder nichts: ein echter Lauf |
+| `extra_data` | Variablen, die dieser Knoten erhält, unter den `extra_vars` des Workflows und den Werten des Formulars |
+
+Der Job des Knotens erhält die Werte des Formulars als Extra-Vars. Die Werte des Formulars haben Vorrang vor den `extra_vars` des Workflows, die wiederum Vorrang
+vor dem `extra_data` des Knotens haben, so wie die Antworten eines Surveys in AWX.
+
+---
+
+## Eigene Schlüssel von AnsibleForms
+
+Drei Schlüssel eines Knotens gehören AnsibleForms selbst, und AWX ignoriert sie, sodass ein Workflow das kann, was ein mehrstufiges Formular kann:
+
+| Schlüssel | Was er bewirkt |
+|---|---|
+| `runner` | Führt auf einem `job_template`-Knoten die Vorlage oder den Job dieses Runners statt eines Playbooks des Designers aus: AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins. Ein RTE-Runner führt das Playbook des Knotens dort aus. Ein Workflow kann sie mischen. |
+| `if_extra_var` | Der Knoten läuft nur, wenn diese Extra-Var `true` ist, wie `ifExtraVar` eines Multistep-Schritts. Ist sie nicht erfüllt, wird der Knoten übersprungen, und was ihm folgt, läuft wie nach einem Erfolg. Nicht auf einem Genehmigungsknoten, der immer läuft. |
+| `extra_vars_key` | Der Knoten erhält nur diesen Schlüssel der Extra-Vars, mit dem Benutzer hineinkopiert, wie der `key` eines Multistep-Schritts |
+
+Auf einem Vorlagen-Runner ist `unified_job_template.name` die auszuführende Vorlage bzw. der Job, und `limit`, `job_tags`, Check-Modus
+und Diff-Modus des Knotens werden so übergeben, wie ein Formular vom Typ dieses Runners sie übergeben würde. Eine `verbosity` über `0` schaltet das
+`verbose` des Formulars ein, und `skip_tags` wird nicht übergeben. Nur ein AWX-Runner (AWX, AAP oder Ascender) erhält das Inventar des Knotens und die
+Zugangsdaten als seine AWX-Zugangsdaten; Semaphore, Rundeck und Jenkins erhalten die Zugangsdaten als `credentials` eines Formulars.
diff --git a/i18n/de/_build_forms/workflows/index.md b/i18n/de/_build_forms/workflows/index.md
new file mode 100644
index 0000000..b5bd87e
--- /dev/null
+++ b/i18n/de/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflows
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflows
+{: .no_toc }
+
+Playbooks, Genehmigungen und andere Workflows verketten, wie AWX es tut
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Formularautoren: was ein Workflow ist, wie seine Knoten laufen und wo Sie weiterlesen.
+
+Ein Workflow ist ein Graph aus Knoten. Jeder Knoten führt etwas aus: eines der Playbooks des Designers, einen anderen Workflow, eine Genehmigung
+oder einen Repository-Pull. Verbindungen zwischen den Knoten sagen, was als Nächstes läuft, bei Erfolg, bei Fehler oder immer. Ein Formular vom
+[Typ `workflow`](../forms/workflow.html) startet ihn, und die Jobs-Seite zeichnet ihn live, während er läuft.
+
+Workflows folgen der Syntax und den Regeln von AWX, sodass ein aus AWX exportierter Workflow in AnsibleForms gleich gelesen wird. Sie laufen auf
+dem RTE, ohne AWX: Ein Playbook-Knoten ist ein eigener Job, mit Inventar, Zugangsdaten, Limit und Tags des Knotens.
+
+---
+
+## Wie ein Workflow läuft
+
+Die Knoten laufen nach den Regeln von AWX, und Zweige, die nicht voneinander abhängen, laufen parallel.
+
+- **Ein Knoten ohne Eltern startet sofort**, wenn der Workflow startet.
+- **Eine Verbindung löst aus, wenn ihr Knoten beendet ist**: eine Verbindung *bei Erfolg* nach einem Erfolg, eine Verbindung *bei Fehler* nach einem Fehler,
+  eine Verbindung *immer* nach beidem. Ein abgebrochener Knoten löst keine seiner Verbindungen aus.
+- **Ein Knoten startet, sobald eine Verbindung in ihn hinein auslöst.** Mit eingeschaltetem **Alle Eltern müssen zusammenlaufen** wartet er, bis jede Verbindung
+  in ihn hinein ausgelöst hat.
+- **Ein Knoten, der nicht mehr starten kann, wird als *läuft nicht* markiert**, ebenso die Knoten, die nur er starten könnte.
+- **Der Workflow schlägt fehl, wenn ein Knoten fehlgeschlagen ist und nichts das behandelt**: Dieser Knoten hat keine Verbindung *bei Fehler* und keine *immer*.
+  Ein Fehler, den eine Verbindung behandelt, lässt den Workflow nicht fehlschlagen.
+
+Ein Knoten mit einer nicht erfüllten Bedingung (`if_extra_var`) wird übersprungen. Was ihm folgt, läuft wie nach einem Erfolg. Ein Genehmigungsknoten
+nimmt keine Bedingung: Er wartet immer auf eine Antwort.
+
+---
+
+## Daten zwischen Knoten weitergeben
+
+Was das Playbook eines Knotens mit `set_stats` sammelt, erreicht die nachfolgenden Knoten als Extra-Vars, so wie AWX die Artefakte eines Jobs
+weitergibt. Ein Knoten erhält die Daten jedes Elternknotens, dessen Verbindung in ihn hinein ausgelöst hat, zusammengeführt in der Reihenfolge, in der die Eltern
+geschrieben sind, und gibt weiter, was er erhalten hat, plus die Daten seines eigenen Jobs, wobei seine eigenen bei einem Schlüssel gewinnen, den beide setzen.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Ein nachfolgender Knoten liest dann {% raw %}`{{ version }}` und `{{ build_id }}`{% endraw %} wie jede andere Extra-Var.
+
+Die Extra-Vars eines Knotens kommen aus vier Quellen. Eine davon, `extra_data`, sind die eigenen Variablen des Knotens: der Name, den AWX dafür verwendet,
+am Knoten in der [Workflow-Datei](file.html#run-settings) gesetzt. Wenn zwei denselben Schlüssel setzen, gilt die Rangfolge
+von AWX, die niedrigste zuerst:
+
+| Quelle | Gewinnt gegen |
+|---|---|
+| die eigenen Variablen des Knotens (`extra_data`) | nichts |
+| die mit `set_stats` weitergegebenen Daten | das `extra_data` des Knotens |
+| die `extra_vars` des Workflows | die weitergegebenen Daten |
+| die Werte des Formulars | alles |
+
+- Nur die Playbook-weiten Daten werden weitergegeben: `set_stats` mit `per_host: false`, seinem Standard.
+- Ein Genehmigungsknoten, ein übersprungener Knoten und ein Projektknoten geben weiter, was bei ihnen angekommen ist.
+- Die Ausgabe eines Knotens endet mit den Schlüsseln, die er weitergegeben hat, nur mit Namen, da ihre Werte geheim sein können.
+- Der Job des Knotens behält seine Daten als seine Artefakte (**Artefakte anzeigen** auf seiner Seite), und der Workflow-Job behält die Daten aller seiner
+  Knoten, sodass auch ein verschachtelter Workflow sie an die nachfolgenden Knoten weitergibt.
+- Ein Knoten, der auf einem AWX-Runner läuft, gibt die Artefakte seines AWX-Jobs auf dieselbe Weise weiter.
+---
+
+## In diesem Abschnitt
+
+Die folgenden Seiten beschreiben Workflows im Detail:
+
+| Seite | Inhalt |
+|---|---|
+| [Die Workflow-Datei](file.html) | Die Syntax der Datei, die Knotentypen und die Ausführungseinstellungen jedes Knotens |
+| [Im Designer bearbeiten](designer.html) | Der Bereich Workflows des Designers: der Graph, die Dialoge für Knoten und Verbindungen und der Probelauf |
+| [Einen Workflow ausführen](running.html) | Das Formular, das ihn startet, die Job-Seite, Knotenausgaben, Genehmigungen und Abbruch |
diff --git a/i18n/de/_build_forms/workflows/running.md b/i18n/de/_build_forms/workflows/running.md
new file mode 100644
index 0000000..040953d
--- /dev/null
+++ b/i18n/de/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Einen Workflow ausführen
+parent: Workflows
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Einen Workflow ausführen
+{: .no_toc }
+
+Einen Workflow aus einem Formular starten und auf der Jobs-Seite verfolgen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Das Formular
+
+Ein Formular vom [Typ `workflow`](../forms/workflow.html) startet einen Workflow, der mit `workflow:` benannt wird wie ein Playbook: über
+seine **Datei** im Workflow-Ordner, mit ihren Unterordnern (`team/deploy-app.yml`), oder über den **Namen** des Workflows in
+der Datei (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+Die Felder des Formulars erreichen jeden Knoten als Extra-Vars, ebenso seine [`credentials`](../forms/workflow.html#workflow_credentials), unter den Namen,
+die das Formular ihnen gibt, so wie die eines mehrstufigen Formulars dessen Schritte erreichen:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+Die eigenen Zugangsdaten eines Knotens, in der Workflow-Datei gesetzt, erreichen sein Playbook unter ihrem eigenen Namen und gewinnen bei einem Namen, den beide verwenden. Im Tab Visuell eines Formulars im Designer ist **Workflow** eine Liste der
+Workflow-Dateien des Designers.
+
+Ein bloßer Dateiname wird auch in einem Unterordner gefunden, wenn nur eine Datei ihn trägt. Zwei Workflows mit demselben Namen stoppen ein Formular, das
+ihn über seinen Namen nennt, und der Designer warnt, wenn Sie den zweiten speichern: Benennen Sie einen um oder nennen Sie seine Datei. Ein Workflow, der nicht
+gefunden wird, beendet den Job als fehlgeschlagen, mit dem Grund in seiner Ausgabe.
+
+---
+
+## Der Job
+
+Ein Workflow-Job läuft auf dem AnsibleForms-Server, und jeder Playbook-Knoten läuft als eigener Job, ein Kind des Workflow-Jobs,
+so wie die Schritte eines mehrstufigen Formulars: ein Playbook des Designers auf dem RTE oder, bei einem Knoten mit `runner:`, die Vorlage
+oder der Job dieses Runners auf AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins (siehe [Wo ein Knoten läuft](designer.html#where-a-node-runs)).
+
+Die Seite des Jobs zeichnet den Workflow live: jeden Knoten nach seinem Status eingefärbt, die Verbindungen, die ausgelöst haben, und die Knoten, die
+nicht laufen werden. Die Angaben oben nennen den Workflow anstelle eines Playbooks.
+
+- **Klicken Sie auf einen beendeten Knoten**, um seine Ausgabe in einem Dialog zu öffnen.
+- **Die Ausgabe** enthält die Ausgabe jedes Knotens unter einem Banner `WORKFLOW NODE [identifier] (status)`, in der Reihenfolge, in der die Knoten
+  beendet wurden.
+- **Extra-Variablen anzeigen** und **Artefakte anzeigen**, im Kopf jedes Knotens in der Ausgabe und im Dialog, der aus dem Graph geöffnet wird,
+  zeigen die eigenen Extravars und Artefakte dieses Knotens (`{}`, wenn er keine hat), als JSON oder YAML, mit einer Schaltfläche Kopieren.
+
+Die Extravars eines Knotens enthalten, was die Knoten vor ihm weitergegeben haben, und seine Artefakte, was sein Playbook mit
+`set_stats` gesammelt hat. Die beiden Schaltflächen folgen den [Rollenoptionen](../config/roles.html#role-options) `showExtravars` und
+`showArtifacts`. Dieselben Daten liefert `GET /api/v2/job/{id}/node/{nodeId}`, für jeden, der den Job sehen darf.
+
+Der Job schlägt fehl, wenn ein Knoten fehlgeschlagen ist und nichts das behandelt hat, nach der Regel von AWX; andernfalls ist er erfolgreich.
+
+---
+
+## Genehmigungen
+
+Ein Genehmigungsknoten hält den Workflow-Job an, bis jemand darauf antwortet.
+
+Erreicht der Workflow einen Genehmigungsknoten, wechselt der Status des Jobs zu **Wartet auf Genehmigung**: Das erscheint in der Glocke und auf der
+Seite des Jobs, wie bei einem [Genehmigungspunkt](../forms/approval.html) eines Formulars. Der Name des Knotens ist der Titel der Genehmigung und seine Beschreibung
+die Nachricht; der Rest kommt aus dem `approval` des Formulars:
+
+- seine `roles` entscheiden, wer genehmigen oder ablehnen kann, und `allowSelf`, ob der Starter auch genehmigen darf;
+- an seine `notifications` und `channels` wird die Anfrage gesendet.
+
+Ein Workflow-Formular ohne `approval` hält den Job an einem Genehmigungsknoten trotzdem an, aber dann kann nur ein Admin genehmigen.
+
+- **Genehmigt**: Der Knoten ist erfolgreich, und der Workflow geht entlang seiner Verbindungen *bei Erfolg* weiter.
+- **Abgelehnt**: Der Knoten schlägt fehl, und der Workflow geht entlang seiner Verbindungen *bei Fehler* weiter.
+- **Zeitüberschreitung**: Nach Ablauf des Zeitlimits des Knotens ohne Antwort schlägt der Knoten ebenfalls fehl.
+
+---
+
+## Abbrechen
+
+**Abbrechen** bei einem laufenden Workflow-Job stoppt ihn: Die laufenden Knoten-Jobs werden abgebrochen, es startet nichts mehr, und eine Genehmigung, auf die
+er wartet, wird storniert. Auch ein Workflow-Job, der auf eine Genehmigung wartet, kann abgebrochen werden.
diff --git a/i18n/de/_configure/announcements.md b/i18n/de/_configure/announcements.md
new file mode 100644
index 0000000..9335535
--- /dev/null
+++ b/i18n/de/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Ankündigungen
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Ankündigungen
+{: .no_toc }
+
+Nachrichten unter der Kopfzeile für alle, etwa ein Wartungsfenster, jede von ihrem Beginn bis zu ihrem Ende
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Informieren Sie alle Benutzer über ein Wartungsfenster oder eine Störung, unter **Einstellungen > Erscheinungsbild > Ankündigungen**.
+
+Die Seite benötigt die Rollenoption `showSettings` oder `showAppearanceSettings`. Ab 7.3.0 ist es eine einzige Liste, und jede Ankündigung
+hat ihre eigene Seite und ihren eigenen Schalter Aktiviert.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Allgemein](announcements/general.html) | Der Schalter Aktiviert jeder Ankündigung, der den Schalter für alle ersetzt hat |
+| [Liste](announcements/list.html) | Die Ankündigungen, die noch nicht abgelaufen sind, ihre Spalten und die Seite einer Ankündigung |
+| [Eine hinzufügen](announcements/adding-one.html) | Der Assistent in zwei Schritten: die Nachricht, dann wann sie erscheint |
+
+
+---
+
+## Wo sie erscheinen
+
+Ankündigungen erscheinen als Zeile unter der Kopfzeile jeder Seite, für jeden angemeldeten Benutzer, jede in der Farbe ihres Typs.
+
+Mehrere aktivierte können gleichzeitig erscheinen, die neueste zuerst. Die Anmeldeseite und ein in eine andere Website eingebettetes Formular zeigen keine.
+
+Jede hat eine Schließen-Schaltfläche. Eine geschlossene Ankündigung bleibt in diesem Browser-Tab geschlossen, bis der Tab geschlossen wird oder
+bis sich ihre Nachricht oder ihr Enddatum ändert. Eine gespeicherte Ankündigung erreicht sofort jeden geöffneten Browser; eine, die
+ihr Start- oder Enddatum erreicht, wird dort innerhalb einer Minute ein- oder ausgeblendet.
diff --git a/i18n/de/_configure/announcements/adding-one.md b/i18n/de/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..8993388
--- /dev/null
+++ b/i18n/de/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Eine hinzufügen
+parent: Ankündigungen
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Eine hinzufügen
+{: .no_toc }
+
+Der Assistent in zwei Schritten: die Nachricht, dann wann sie erscheint
+{: .fs-6 .fw-300 }
+
+**Ankündigung hinzufügen** öffnet einen Assistenten in zwei Schritten. **Nachricht** fragt, was sie sagt:
+
+| Feld | Bedeutung |
+|---|---|
+| **Nachricht** | Der Text, höchstens 500 Zeichen. Erforderlich. |
+| **Typ** | Ihre Farbe und ihr Symbol: blau für Info (der Standard), gelb für Warnung, rot für Gefahr |
+
+**Wann** fragt, wann sie erscheint:
+
+| Feld | Bedeutung |
+|---|---|
+| **Startdatum** | Sie erscheint ab diesem Moment. Leer lassen, um sie sofort anzuzeigen. |
+| **Enddatum** | Zu diesem Moment wird sie ausgeblendet und gelöscht. Leer lassen, um sie zu behalten, bis Sie sie löschen. |
+
+Das Enddatum muss nach dem Startdatum und in der Zukunft liegen.
diff --git a/i18n/de/_configure/announcements/general.md b/i18n/de/_configure/announcements/general.md
new file mode 100644
index 0000000..8744c2f
--- /dev/null
+++ b/i18n/de/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Allgemein
+parent: Ankündigungen
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Allgemein
+{: .no_toc }
+
+Der Schalter Aktiviert jeder Ankündigung, der den Schalter für alle ersetzt hat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Eine Ankündigung ein- oder ausschalten
+
+Ab 7.3.0 wird jede Ankündigung einzeln ein- oder ausgeschaltet, mit ihrem Schalter **Aktiviert**.
+
+Eine neue Ankündigung ist aktiviert. **Deaktivieren** im Menü ihrer Zeile oder der Schalter **Aktiviert** auf ihrer Seite blendet sie unter der Kopfzeile aus und behält
+sie in der Liste, und **Aktivieren** zeigt sie wieder von ihrem Startdatum bis zu ihrem Enddatum an. Der Schalter wird sofort gespeichert.
+
+---
+
+## Der Schalter Ankündigungen anzeigen aus 7.2
+
+Bis 7.2 hatte ein Tab **Allgemein** einen Schalter **Ankündigungen anzeigen**, der alle auf einmal ein- oder ausschaltete.
+
+Ab 7.3.0 gibt es diesen Schalter nicht mehr. War er aus, deaktiviert das Upgrade alle Ankündigungen, damit keine plötzlich erscheint: Aktivieren Sie die gewünschten wieder.
diff --git a/i18n/de/_configure/announcements/list.md b/i18n/de/_configure/announcements/list.md
new file mode 100644
index 0000000..74ea66f
--- /dev/null
+++ b/i18n/de/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Liste
+parent: Ankündigungen
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Liste
+{: .no_toc }
+
+Die Ankündigungen, die noch nicht abgelaufen sind, ihre Spalten und die Seite einer Ankündigung
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Liste
+
+**Einstellungen > Erscheinungsbild > Ankündigungen** listet jede Ankündigung auf, die noch nicht abgelaufen ist, mit diesen Spalten:
+
+| Spalte | Bedeutung |
+|---|---|
+| **Aktiviert** | Ob sie von ihrem Beginn bis zu ihrem Ende unter der Kopfzeile erscheint (ab 7.3.0) |
+| **Nachricht** | Der Text unter der Kopfzeile |
+| **Typ** | Info, Warnung oder Gefahr |
+| **Startdatum** | Wann sie zu erscheinen beginnt; `–`, wenn sie sofort erscheint |
+| **Enddatum** | Wann sie endet; `–`, wenn sie bis zum Löschen erscheint |
+| **Erstellt von** | Wer sie hinzugefügt hat |
+
+Ein Klick auf eine Zeile oder **Bearbeiten** im Menü der Zeile öffnet die Seite der Ankündigung. Das Menü enthält außerdem **Aktivieren** oder **Deaktivieren** sowie **Löschen**.
+
+Sobald ihr Enddatum verstrichen ist, wird eine Ankündigung gelöscht: Die Liste behält nur die kommenden und die gerade angezeigten.
+
+---
+
+## Die Seite einer Ankündigung
+
+Ab 7.3.0 öffnet sich jede Ankündigung auf ihrer eigenen Seite, unter `/settings/announcements/<id>`, mit einem Tab, **Details**.
+
+Sie enthält die Nachricht, den Typ, das Start- und das Enddatum sowie den Schalter **Aktiviert**, der sofort gespeichert wird; die übrigen Felder werden
+mit **Speichern** gespeichert, und **Löschen** entfernt die Ankündigung. Der Seitentitel benennt sie nach den ersten Zeichen ihrer Nachricht.
diff --git a/i18n/de/_configure/appearance.md b/i18n/de/_configure/appearance.md
new file mode 100644
index 0000000..693a19e
--- /dev/null
+++ b/i18n/de/_configure/appearance.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Erscheinungsbild
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Erscheinungsbild
+{: .no_toc }
+
+Die Standardwerte, der Name, das Logo, das Browsersymbol, die Links der Kopfzeile und die Labels neben dem Logo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Geben Sie der Instanz Ihr eigenes Aussehen, unter **Einstellungen > Erscheinungsbild**, mit der Rollenoption `showSettings`.
+Die Rollenoption `showAppearanceSettings` allein öffnet diese Seiten ebenfalls, Ankündigungen eingeschlossen, ohne die übrigen Einstellungen.
+
+Die Seiten dieser Gruppe sind **Standardwerte**, **Name**, **Logo**, **Symbol**, **Links**, **Labels** und **Ankündigungen**;
+Ankündigungen haben eine eigene Seite, [Ankündigungen](announcements.html). Ein gespeicherter Standardwert, Name, Link oder ein gespeichertes Label
+erscheint sofort in jedem geöffneten Browser.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Standardwerte](appearance/defaults.html) | Design, Sprache, Zeitzone und Datumsformat für Benutzer, die nichts gewählt haben |
+| [Name](appearance/name.html) | Der Anwendungsname im Browser-Tab und auf der Anmeldeseite |
+| [Logo](appearance/logo.html) | Ihr eigenes Logo in der Kopfzeile |
+| [Symbol](appearance/icon.html) | Ihr eigenes Symbol im Browser-Tab und in Lesezeichen |
+| [Links](appearance/links.html) | Die Links der Kopfzeile, integrierte und eigene |
+| [Labels](appearance/labels.html) | Labels neben dem Logo, die zeigen, welche Instanz das ist; bis 7.2 ein einziges Umgebungslabel |
diff --git a/i18n/de/_configure/appearance/defaults.md b/i18n/de/_configure/appearance/defaults.md
new file mode 100644
index 0000000..ba71270
--- /dev/null
+++ b/i18n/de/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Standardwerte
+parent: Erscheinungsbild
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Standardwerte
+{: .no_toc }
+
+Design, Sprache, Zeitzone und Datumsformat für Benutzer, die nichts gewählt haben
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Standardwerte
+
+**Standardwerte** legt fest, wie die App für einen Benutzer aussieht, der in seinen
+[Einstellungen](../profile/preferences.html) keine eigene Wahl getroffen hat; die eigene Wahl eines Benutzers hat immer Vorrang:
+
+| Feld | Auswahl | Ohne Auswahl |
+|---|---|---|
+| **Standarddesign** | Dem Browser folgen, Hell, Dunkel oder Farbe, mit einer von 12 Farben für Farbe | Dem Browser folgen (bis 7.2 Hell) |
+| **Standardsprache** | Die Sprachen der App, gespeichert in [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Englisch |
+| **Standard-Formularansicht** | Kacheln oder Liste, für die Formularseite | Kacheln |
+| **Standard-Zeitzone** | UTC, der Browser jedes Benutzers oder eine beliebige Zone nach Namen | UTC |
+| **Standard-Datumsformat** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` oder `DD.MM.YYYY`, jeweils mit dem heutigen Datum angezeigt | `YYYY-MM-DD` |
+
+Die Sprache ist eine Umgebungsvariable und gilt ohne Neustart. Ist
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) auf `0` gesetzt, zeigt die Seite sie schreibgeschützt an.
+
+Ab 7.3.0 ist die Seite wie die Einstellungen im Profil in zwei Tabs aufgeteilt, **Darstellung** (Design, Sprache und Formularansicht) und **Datum und
+Uhrzeit** (Zeitzone und Datumsformat, mit einer Vorschau der aktuellen Uhrzeit), und ihr Suchfeld listet die Treffer unter dem Namen jedes Tabs auf.
+
+---
+
+## Dem Browser folgen
+
+Ab 7.3.0 zeigt **Dem Browser folgen** jedem Benutzer das helle oder dunkle Design, das sein Browser verlangt, und wechselt mit ihm.
+
+Es ist der Standard, wenn kein Standarddesign gewählt ist, daher folgt eine neue Installation dem Browser. Fährt man mit dem Mauszeiger über eine der Farben von
+**Farbe**, zeigt das eine Vorschau der App in dieser Farbe; das bisherige Design kehrt zurück, sobald der Zeiger sie verlässt, und nichts wird vor **Speichern** übernommen.
diff --git a/i18n/de/_configure/appearance/icon.md b/i18n/de/_configure/appearance/icon.md
new file mode 100644
index 0000000..e62c855
--- /dev/null
+++ b/i18n/de/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Symbol
+parent: Erscheinungsbild
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Symbol
+{: .no_toc }
+
+Ihr eigenes Symbol im Browser-Tab und in Lesezeichen
+{: .fs-6 .fw-300 }
+
+**Symbol** ersetzt das Symbol von AnsibleForms im Browser-Tab und in Lesezeichen:
+
+| Regel | Wert |
+|---|---|
+| Typen | PNG, ICO, SVG, WEBP, GIF und JPEG |
+| Größte Datei | 256 KB |
+| Bestes Ergebnis | Ein quadratisches Bild von mindestens 64 × 64 px oder ein SVG |
+
+Wählen Sie unter **Neues Symbol** eine Datei aus und klicken Sie auf **Hochladen**; **Eigenes Symbol entfernen** stellt das Standardsymbol wieder her.
diff --git a/i18n/de/_configure/appearance/labels.md b/i18n/de/_configure/appearance/labels.md
new file mode 100644
index 0000000..9f2b9f8
--- /dev/null
+++ b/i18n/de/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Labels
+parent: Erscheinungsbild
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Labels
+{: .no_toc }
+
+Labels neben dem Logo, die zeigen, welche Instanz das ist
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Liste
+
+Ab 7.3.0 enthält **Einstellungen > Erscheinungsbild > Labels** mehrere Labels neben dem Logo der Kopfzeile, etwa PRODUCTION und EU:
+
+| Spalte | Bedeutung |
+|---|---|
+| **Aktiviert** | Ob das Label neben dem Logo und auf der Anmeldeseite erscheint |
+| **Label** | Sein Text, so dargestellt wie die farbige Pille in der Kopfzeile |
+
+Die Zeilen stehen in der Reihenfolge der Kopfzeile. Ein Klick auf eine Zeile oder **Bearbeiten** im Menü der Zeile öffnet die Seite des Labels; das Menü der Zeile enthält außerdem
+**Aktivieren** oder **Deaktivieren**, je nachdem, was zutrifft, **Nach oben** und **Nach unten**, um die Reihenfolge zu ändern, sowie **Löschen**.
+
+Die Kopfzeile und die Anmeldeseite zeigen die aktivierten Labels in ihrer Reihenfolge. Ab dem vierten fasst ein graues **+N** die übrigen in seinem Tooltip zusammen,
+und ein Smartphone zeigt das erste Label und das **+N**. Ein gespeichertes Label erscheint sofort in jedem geöffneten Browser.
+
+---
+
+## Ein Label hinzufügen
+
+**Label hinzufügen** öffnet einen Dialog mit den beiden Feldern des Labels, beide erforderlich:
+
+| Feld | Bedeutung |
+|---|---|
+| **Label** | Der Text des Labels, etwa PRODUCTION |
+| **Farbe** | Blau, Grün, Bernstein, Orange, Rot oder Grau, als runde Farbfelder; anfangs Rot |
+
+Eine Vorschau zeigt die Kopfzeile mit jedem aktivierten Label und dem neuen, während es eingegeben wird. Ein neues Label ist aktiviert und kommt nach den
+anderen. Seine Seite hat einen Tab, **Details**, mit denselben Feldern, dem Schalter **Aktiviert**, der sofort gespeichert wird, und der Vorschau.
+
+---
+
+## Das Umgebungslabel aus 7.2
+
+Bis 7.2 legte **Einstellungen > Erscheinungsbild > Umgebung** ein einziges Label neben dem Logo fest.
+
+Mit nur einem Label zeigen PRODUCTION EU und PRODUCTION US beide PRODUCTION, wenn mehrere Instanzen nebeneinander geöffnet sind. Ab 7.3.0
+macht das Upgrade dieses Label zum ersten der Liste, mit seinem Text, seiner Farbe und dem Wissen, ob es angezeigt wurde, und die alte Adresse **Umgebung**
+öffnet die Liste.
+
+---
+
+## Labels im Config-Seed
+
+Ab 7.3.0 deklariert der [Config-Seed](../seed/) Labels in seinem Abschnitt `labels`, jedes mit seinem Text und optional seiner Farbe:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` ist eines von `blue`, `green`, `amber`, `orange`, `red` oder `grey`, und `position` ordnet sie, das niedrigste zuerst. Ein im Seed
+deklariertes Label ist auf seiner Seite schreibgeschützt, wie jedes [verwaltete Objekt](../seed/managed-objects.html).
diff --git a/i18n/de/_configure/appearance/links.md b/i18n/de/_configure/appearance/links.md
new file mode 100644
index 0000000..5c7196e
--- /dev/null
+++ b/i18n/de/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Links
+parent: Erscheinungsbild
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Links
+{: .no_toc }
+
+Die Links der Kopfzeile, integrierte und eigene
+{: .fs-6 .fw-300 }
+
+**Links** legt die Links der Kopfzeile für jeden angemeldeten Benutzer fest, in zwei Tabs.
+
+**Integriert** enthält den Schalter **Designer**, gespeichert in [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) und angewendet
+ohne Neustart. Ausgeschaltet ist der Designer für alle verschwunden: sein Link, seine Seite und seine API.
+
+**Eigene** enthält Ihre eigenen Links, etwa ein Wiki, ein Runbook oder ein Supportportal. **Link hinzufügen** fügt eine Zeile mit diesen Feldern hinzu:
+
+| Feld | Bedeutung |
+|---|---|
+| **Symbol** | Das Symbol vor der Bezeichnung, aus einer Liste gewählt |
+| **Bezeichnung** | Der Text des Links |
+| **Adresse** | Eine Website (`https://…`) oder eine Seite der App (`/forms/all`) |
+| **Neuer Tab** | Öffnet den Link in einem neuen Browser-Tab |
+
+Die Schaltflächen einer Zeile verschieben sie: **→** legt den Link in den Link darüber, der sich dann in der Kopfzeile als Menü öffnet,
+**←** nimmt ihn wieder heraus in die Kopfzeile, und die Pfeile nach oben und unten verschieben ihn (ein Menü samt den Links darin).
+Ein Menü braucht keine eigene Adresse.
+
+Die Kopfzeile enthält nach den integrierten Links höchstens 5 Ihrer Links und höchstens 10 in jedem Menü.
diff --git a/i18n/de/_configure/appearance/logo.md b/i18n/de/_configure/appearance/logo.md
new file mode 100644
index 0000000..17aa772
--- /dev/null
+++ b/i18n/de/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logo
+parent: Erscheinungsbild
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logo
+{: .no_toc }
+
+Ihr eigenes Logo in der Kopfzeile
+{: .fs-6 .fw-300 }
+
+**Logo** ersetzt das AnsibleForms-Logo in der Kopfzeile durch Ihr eigenes Bild, das in jedem Design angezeigt wird:
+
+| Regel | Wert |
+|---|---|
+| Typen | PNG, JPEG, WEBP, GIF und SVG |
+| Größte Datei | 900 KB |
+| Größe in der Kopfzeile | Höchstens 200 × 33 px, mit beibehaltenen Proportionen |
+
+Wählen Sie unter **Neues Logo** eine Datei aus, um eine Vorschau zu sehen, und klicken Sie dann auf **Hochladen**. **Aktuelles Logo** zeigt das verwendete Logo und die Größe,
+in der die Kopfzeile es anzeigt. **Eigenes Logo entfernen** stellt das Standardlogo wieder her, das dem Design folgt.
diff --git a/i18n/de/_configure/appearance/name.md b/i18n/de/_configure/appearance/name.md
new file mode 100644
index 0000000..17e44cc
--- /dev/null
+++ b/i18n/de/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Name
+parent: Erscheinungsbild
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Name
+{: .no_toc }
+
+Der Anwendungsname im Browser-Tab und auf der Anmeldeseite
+{: .fs-6 .fw-300 }
+
+**Name** enthält den **Anwendungsnamen**, angezeigt im Browser-Tab und auf der Anmeldeseite. Ist er leer, zeigt der Browser-Tab
+`AnsibleForms` und die Anmeldeseite keinen Namen.
diff --git a/i18n/de/_configure/authentication/entra-id.md b/i18n/de/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..211c4e2
--- /dev/null
+++ b/i18n/de/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Authentifizierung
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Single Sign-on mit Microsoft Entra ID (Azure AD), mit Rollen aus den Entra ID-Gruppen des Benutzers
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Funktionsweise
+
+Ist ein Entra ID-Anbieter aktiviert, zeigt die Anmeldeseite unter **Anmelden** eine Entra ID-Schaltfläche. Eine Anmeldung läuft dann so ab:
+
+1. Die Schaltfläche schickt den Browser zu `/api/v2/auth/entraid`, das ihn zu Microsoft weiterleitet.
+2. Der Benutzer meldet sich bei Microsoft an, das mit einem Autorisierungscode zur **Umleitungs-URL** zurückleitet. Der Server
+   tauscht diesen Code bei Microsoft gegen das ID-Token und ein Zugriffstoken für Microsoft Graph.
+3. Der Server liest die Gruppen des Benutzers aus Microsoft Graph (`/v1.0/me/transitiveMemberOf`), sodass auch verschachtelte Gruppen zählen.
+4. Die Gruppen werden mit dem **Gruppenfilter** nach ihrem Anzeigenamen gefiltert, und jede verbleibende Gruppe wird zweimal gespeichert,
+   als `azuread/<object id>` und als `azuread/<display name>`.
+
+Der Benutzername ist der Claim `upn` des Tokens, z. B. `jdoe@example.com`, oder der Claim `preferred_username`, wenn das Token
+kein `upn` hat; bei einem Geschäftskonto enthalten beide denselben Wert.
+
+---
+
+## Die Anwendung registrieren
+
+AnsibleForms braucht eine App-Registrierung im Entra Admin Center, unter **App registrations > New registration**:
+
+1. Geben Sie ihr einen Namen, wählen Sie **Accounts in this organizational directory only** als unterstützte Kontotypen und fügen Sie einen
+   Redirect URI vom Typ **Web** hinzu: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. Erstellen Sie unter **Certificates & secrets** ein Client-Secret und kopieren Sie seinen Wert; er wird nur einmal angezeigt.
+3. Fügen Sie unter **API permissions** die **delegierten** Microsoft Graph-Berechtigungen `User.Read` und `GroupMember.Read.All` hinzu
+   und erteilen Sie dafür die Administratorzustimmung.
+4. Notieren Sie auf der Seite **Overview** die **Application (client) ID** und die **Directory (tenant) ID**.
+
+Der Redirect URI ist die Adresse, unter der Benutzer AnsibleForms erreichen, gefolgt von `/api/v2/auth/entraid/callback`.
+Mit [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms` wird daraus
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Er muss exakt mit der **Umleitungs-URI** der
+Anmeldedaten des Anbieters übereinstimmen.
+
+Bis 7.2.0 lautete der Pfad `/api/v2/auth/azureadoauth2/callback`. Er funktioniert ab 7.3.0 weiterhin, sodass eine bestehende Registrierung
+nicht geändert werden muss; Anmeldedaten mit leerer **Umleitungs-URI** verwenden den neuen Pfad, fügen Sie ihn dann also der Registrierung hinzu.
+
+AnsibleForms liest die Gruppen aus Graph und verwendet keinen Gruppen-Claim im Token, daher muss in der Registrierung kein Gruppen-Claim
+konfiguriert werden.
+
+---
+
+## Den Anbieter hinzufügen
+
+Fügen Sie den Anbieter unter **Zugriff > SSO** hinzu: Ein Assistent fragt seine Felder in vier Schritten ab, mit **Microsoft Entra ID** im Schritt **Typ**:
+
+| Schritt | Feld | Bedeutung |
+|---|---|---|
+| Details | Name, Beschreibung | Ein eindeutiger Name für den Anbieter und eine optionale Beschreibung |
+| Typ | Anbieter | **Microsoft Entra ID**; beim Anlegen festgelegt, bleibt er so |
+| Anmeldedaten | Anmeldedaten-Eintrag | Ein **Microsoft Entra ID**-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html), siehe unten |
+| Gruppen | Gruppenfilter | Regulärer Ausdruck; nur die Gruppen, deren Anzeigename passt, bleiben erhalten. Leer behält jede Gruppe |
+
+Die Anmeldedaten enthalten die App-Registrierung, daher kann nur ein Admin sie hinzufügen oder ändern:
+
+| Feld | Bedeutung |
+|---|---|
+| Tenant-ID | Erforderlich. Die Directory (tenant) ID, eine GUID, oder eine der Domänen des Tenants. Nur Benutzer dieses Tenants können sich anmelden |
+| Client-ID | Die Application (client) ID |
+| Client-Secret | Der Wert des Client-Secrets, verschlüsselt gespeichert oder aus einem [Secret Store](../secret-stores/) gelesen |
+| Umleitungs-URI | Wie registriert, z. B. `https://af.example.com/api/v2/auth/entraid/callback`. Leer: die URL der App und der Callback-Pfad |
+
+Anmeldedaten mit leerer Tenant-ID werden beim Speichern abgewiesen. Die Multi-Tenant-Endpunkte `common`, `organizations`
+und `consumers` werden abgewiesen, wenn der Anbieter gespeichert wird, der diese Anmeldedaten verwendet, da sie Benutzern jedes
+Microsoft-Tenants die Anmeldung erlauben würden. Bei der Anmeldung prüft der Server außerdem, dass das Token vom konfigurierten Tenant stammt. Ein Anbieter,
+der früher ohne Tenant-ID gespeichert wurde, meldet niemanden an: Bis die Tenant-ID eingetragen ist, protokolliert der Server
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Bis 7.2.0 waren Tenant, Client-ID, Secret und Umleitungs-URL Felder des Anbieters. Das Upgrade auf 7.3.0 verschiebt sie in
+Anmeldedaten namens `<provider>-sso`, siehe [Adressen in Anmeldedaten](../credentials/types.html#addresses-in-credentials).
+Wählen Sie für jeden neuen Anbieter Anmeldedaten: Der Server akzeptiert weiterhin einen Anbieter mit eigener Client-ID und eigenem Secret aus der Zeit
+vor 7.3.0, der sich damit anmeldet, bis Anmeldedaten gewählt sind.
+
+Es ist jeweils ein Entra ID-Anbieter aktiviert, der, mit dem sich die Entra ID-Schaltfläche anmeldet. **Aktivieren** im Menü der Zeile eines anderen
+oder sein Schalter **Aktiviert** schaltet die anderen seines Typs aus; die Spalte **Aktiviert** der Liste zeigt, welcher verwendet wird. Ein Anbieter
+kann auch die Anmeldeseite überspringen, siehe [Single Sign-on umschalten](./#switching-single-sign-on). Das Speichern wendet ihn sofort an, ohne Neustart.
+
+---
+
+## Zuordnung zu Rollen
+
+In config.yaml ist eine Entra ID-Gruppe `entraid/<object id>` oder `entraid/<display name>`, und ein Benutzer ist `entraid/<upn>`.
+Die Objekt-ID ist im Tenant eindeutig und daher die sicherere Wahl; ein Anzeigename ist leichter zu lesen:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Bis 7.2.0 war das Präfix `azuread/`. In einer Rolle passt es ab 7.3.0 weiterhin zu denselben Mitgliedern und wird in 8.0 entfernt; der
+Rolleneditor schreibt `entraid/`. Nur die Rollen akzeptieren `entraid/`: Die Gruppen des Benutzers werden als `azuread/<object id>` und
+`azuread/<display name>` gespeichert, und die Profilseite und die Extravar `ansibleforms_user` zeigen sie so. Ein **Gruppenfilter** wie `^AF-` behält nur die Gruppen, die Ihre Rollen verwenden; siehe [Rollen](../config/roles.html). Ab 7.1.0
+enthält das Anmeldetoken die Gruppen nicht mehr, sodass seine Größe nicht mehr mit ihnen wächst. Der Filter ist trotzdem wichtig für
+Benutzer in vielen Gruppen: Bei jeder Anmeldung werden weniger Gruppen mit den Rollen abgeglichen, und der
+[Verzeichniseintrag](../users-and-groups/directory.html) des Benutzers listet nur die Gruppen auf, die zählen. Vor 7.1.0
+braucht ein Benutzer in hundert oder mehr Gruppen ihn, um überhaupt Formulare zu sehen, siehe
+[Leere Formulare und Jobs nach einem Single Sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Endpunkt von Microsoft Graph
+
+Der Server meldet Benutzer standardmäßig bei `https://login.microsoftonline.com` an und ruft Microsoft Graph unter `https://graph.microsoft.com` auf:
+
+| Variable | Was sie ändert |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | Die Anmeldeautorität, für eine nationale Cloud wie `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | Der Graph-Endpunkt, aus dem die Gruppen gelesen werden, etwa `https://graph.microsoft.us` |
+
+Beide nehmen eine Basis-URI ohne abschließenden Schrägstrich und sind neu in 7.3.0. `AZURE_AUTHORITY_URI` und `AZURE_GRAPH_URI` werden weiterhin gelesen,
+wenn sie nicht gesetzt sind, mit einer Warnung im Protokoll, und werden in 8.0 entfernt. Der Server muss Graph erreichen: Eine Anmeldung schlägt fehl, wenn die Gruppen nicht gelesen werden können.
+
+---
+
+## Einschränkungen
+
+Entra ID-Benutzer melden sich bei Microsoft an, daher funktionieren einige Dinge anders als bei lokalen und LDAP-Konten:
+
+- Sie haben kein Passwort in AnsibleForms und können es dort daher nicht ändern; ein [API-Token](../profile/api-token.html) wird aus ihrer Sitzung erstellt.
+- Anzeigenamen sind in Entra ID nicht eindeutig: Zwei Gruppen mit demselben Namen werden derselben Rolle zugeordnet. Benennen Sie die Gruppe in der Rolle über ihre
+  Objekt-ID, `entraid/<object id>`, damit nur diese Gruppe passt.
diff --git a/i18n/de/_configure/authentication/index.md b/i18n/de/_configure/authentication/index.md
new file mode 100644
index 0000000..88e6e7a
--- /dev/null
+++ b/i18n/de/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Authentifizierung
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Authentifizierung
+{: .no_toc }
+
+Wählen Sie, wie sich Benutzer anmelden und wie ihr Konto und ihre Gruppen zu Rollen führen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Anmeldemethoden
+
+AnsibleForms unterstützt vier Anmeldemethoden, und mehrere können gleichzeitig aktiv sein:
+
+| Methode | Wann verwenden | Seite |
+|---|---|---|
+| Lokale Konten | Der integrierte Admin, Dienstkonten, kleine Teams oder ein Rückfall, wenn das Verzeichnis nicht erreichbar ist. | [Lokale Konten](local.html) |
+| LDAP | Benutzer und Gruppen liegen in Active Directory, OpenLDAP oder einem anderen LDAP-Verzeichnis. | [LDAP](ldap.html) |
+| Entra ID | Benutzer melden sich mit ihrem Microsoft 365 / Entra ID-Konto an (Single Sign-on). | [Entra ID](entra-id.html) |
+| OIDC | Single Sign-on über einen anderen OpenID Connect-Anbieter, etwa Keycloak. | [OIDC](oidc.html) |
+
+Lokale Konten und LDAP werden unter **Zugriff > Benutzer**, **Gruppen** und **LDAP** konfiguriert; Entra ID und OIDC unter
+**Zugriff > SSO**.
+
+---
+
+## Wie eine Anmeldung die Methode wählt
+
+Die Anmeldeseite hat ein Formular für Benutzername und Passwort sowie eine Schaltfläche für jeden aktivierten Single-Sign-on-Anbieter:
+
+- **Benutzername und Passwort** werden zuerst mit den lokalen Benutzern abgeglichen. Nur wenn kein lokaler Benutzer diesen Namen hat und LDAP
+  aktiviert ist, wird das Verzeichnis gefragt. Ein lokaler Benutzer mit falschem Passwort wird abgewiesen, ohne LDAP zu fragen.
+- **Die Schaltflächen Entra ID und OpenID** erscheinen unter **Anmelden**, wenn ein solcher Anbieter aktiviert ist. Sie schicken den Browser zum
+  Anbieter und zurück; kein Passwort erreicht AnsibleForms.
+
+Es ist jeweils nur ein Entra ID-Anbieter und ein OIDC-Anbieter aktiviert: Das Aktivieren eines Anbieters schaltet die anderen seines Typs aus.
+Eine fehlgeschlagene Anmeldung mit Benutzername und Passwort zeigt immer dieselbe allgemeine Meldung; der Grund steht im Serverprotokoll und im Audit-Protokoll.
+
+---
+
+## Single Sign-on umschalten
+
+Ab 7.3.0 hat jeder Anbieter unter **Zugriff > SSO** zwei eigene Schalter, die ohne Neustart gelten:
+
+| Schalter | Wirkung |
+|---|---|
+| **Aktiviert** | Zeigt die Schaltfläche des Anbieters auf der Anmeldeseite und akzeptiert seine Anmeldung. Das Einschalten schaltet die anderen Anbieter seines Typs aus. |
+| **Anmeldeseite überspringen** | Benutzer gehen direkt zu diesem Anbieter, ohne Anmeldeseite, solange der Anbieter aktiviert ist. Das Einschalten bei einem Anbieter schaltet es bei den anderen aus; bei einem ausgeschalteten Anbieter ist der Schalter ausgegraut. |
+
+Das Formular für Benutzername und Passwort bleibt unter `/login?local` erreichbar, für den lokalen Admin oder wenn der Anbieter ausfällt,
+und es wird nach dem Abmelden angezeigt sowie wenn eine Single-Sign-on-Anmeldung mit einem Fehler zurückkommt.
+
+Die Variablen `ENABLE_SSO` und `SSO_AUTO_LOGIN` wurden in 7.3.0 entfernt. Der erste Start von 7.3.0 liest sie einmal und
+protokolliert bei jedem Start eine Warnung, solange sie noch gesetzt sind; entfernen Sie sie daher nach dem Upgrade aus der Umgebung:
+
+| Variable vor 7.3.0 | Was das Upgrade tut |
+|---|---|
+| `ENABLE_SSO=0` | Schaltet jeden Anbieter aus: Die Anbieter bleiben konfiguriert, ohne Schaltfläche auf der Anmeldeseite |
+| `SSO_AUTO_LOGIN=1` | Schaltet **Anmeldeseite überspringen** für den aktivierten Anbieter ein, wenn genau einer aktiviert ist und `ENABLE_SSO` nicht `0` ist |
+
+---
+
+## Vom Benutzer zu den Rollen
+
+Jede Anmeldung erzeugt einen Benutzer mit einem **Typ** (`local`, `ldap`, `azuread` oder `oidc`), einem Benutzernamen und einer Liste von Gruppen.
+Jede Gruppe erhält das Präfix ihres Typs, daher wird eine Entra ID-Gruppe als `azuread/...` gespeichert und angezeigt:
+
+| Anmeldemethode | Benutzername | Gruppen |
+|---|---|---|
+| Lokal | der lokale Benutzername | `local/<group>`, eine für jede lokale Gruppe des Benutzers |
+| LDAP, Verzeichnis `main` | der Wert des Benutzername-Attributs | `ldap/<cn>`, der CN jeder Gruppe, die das Verzeichnis zurückgibt |
+| LDAP, ein anderes Verzeichnis | `<directory>/<username>` | `ldap/<directory>/<cn>`, siehe [Mehrere Verzeichnisse](ldap.html#several-directories) |
+| Entra ID | der Claim `upn` oder `preferred_username`, wenn das Token kein `upn` hat | `azuread/<object id>` und `azuread/<display name>` jeder Gruppe, aus Microsoft Graph gelesen |
+| OIDC | der Claim `preferred_username` | `oidc/<name>`, aus dem Claim `groups` des ID-Tokens |
+
+Die [Rollen](../config/roles.html) in config.yaml gleichen dann diese Werte ab: Eine Rolle gilt, wenn eine ihrer `groups` eine
+der Gruppen des Benutzers ist oder wenn ihre `users` `<type>/<username>` enthalten. Jeder Benutzer erhält außerdem die Rolle `default`. Ab 7.3.0
+benennt eine Rolle ein Entra ID-Mitglied als `entraid/<group>` oder `entraid/<upn>`, was dem gespeicherten Wert `azuread/` entspricht; `azuread/`
+in einer Rolle funktioniert weiterhin und wird in 8.0 entfernt. Das Profil und die Extravars des Jobs zeigen weiterhin `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+Die **Profil**-Seite eines Benutzers listet den Anmeldetyp, die Gruppen und die Rollen auf; so lässt sich eine Zuordnung am schnellsten prüfen.
+Die Rollenoption `allowLogin` kann die Anmeldung von Benutzern verweigern, die zu keiner Rolle passen: Setzen Sie sie bei `default` auf `false` und bei
+den Rollen, die sich anmelden dürfen, auf `true`.
diff --git a/i18n/de/_configure/authentication/ldap.md b/i18n/de/_configure/authentication/ldap.md
new file mode 100644
index 0000000..de055ec
--- /dev/null
+++ b/i18n/de/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Authentifizierung
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Lassen Sie Verzeichnisbenutzer sich mit ihrem eigenen Passwort anmelden, und geben Sie ihnen Rollen über ihre Verzeichnisgruppen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Funktionsweise
+
+AnsibleForms verbindet sich mit einem Bind-Konto mit dem Verzeichnis, sucht den Benutzer und bindet sich dann als dieser Benutzer, um
+das Passwort zu prüfen:
+
+1. Der Benutzer meldet sich mit Benutzername und Passwort an. Hat kein **lokaler** Benutzer diesen Namen, wird LDAP versucht.
+2. AnsibleForms bindet sich mit dem Bind-Konto aus den Anmeldedaten des Verzeichnisses und durchsucht **Search Base** nach einem Eintrag, dessen
+   **Benutzername-Attribut** dem Benutzernamen entspricht.
+3. Es bindet sich als der gefundene Eintrag, mit dem eingegebenen Passwort.
+4. Die Gruppen werden aus dem Eintrag (oder aus einer Gruppensuche) gelesen, gefiltert und mit dem Präfix `ldap/` versehen.
+
+Ein Benutzername in UPN-Form (`jdoe@example.com`), der keinen Benutzer findet, wird einmal mit dem Teil vor dem `@` erneut versucht, sodass sich Benutzer
+in beiden Formen anmelden können, auch wenn das Benutzername-Attribut den Kurznamen enthält. Ein falsches Passwort wird nie erneut versucht.
+
+Ein und dieselbe Gruppe von Einstellungen dient Active Directory, OpenLDAP und anderen; ab 7.3.0 kann es [mehrere Verzeichnisse](#several-directories) geben.
+
+---
+
+## Einstellungen
+
+Ab 7.3.0 gelten die Einstellungen pro Verzeichnis. **Zugriff > LDAP** listet die Verzeichnisse auf, in der Reihenfolge, in der ein einfacher Benutzername gesucht wird:
+
+![Zugriff > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menü der Zeile | Was es tut |
+|---|---|
+| Bearbeiten | Öffnet die Seite des Verzeichnisses |
+| Verbindung testen | Versucht eine Anmeldung mit einem Test-Benutzernamen und -Passwort, siehe [Die Verbindung testen](#testing-the-connection) |
+| Aktivieren, Deaktivieren | Schaltet das Verzeichnis ein oder aus; `main` wird ausgeschaltet statt gelöscht |
+| Nach oben, Nach unten | Ändert seine Stelle in der Suchreihenfolge |
+| Löschen | Entfernt das Verzeichnis; bei `main` angezeigt, aber deaktiviert |
+
+Beim Hinzufügen eines Verzeichnisses werden seine Felder in vier Schritten abgefragt, den Tabs seiner Seite. **Details** enthält **Aktiviert**, den **Namen** und eine **Beschreibung**:
+
+| Tab | Einstellung | Bedeutung |
+|---|---|---|
+| Anmeldedaten | Anmeldedaten-Eintrag | Erforderlich. Ein `ldap`-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html), der die Verbindung enthält, siehe unten |
+| Benutzer | Search Base | DN, ab dem die Benutzersuche beginnt, z. B. `OU=Users,DC=example,DC=com`. Unterbäume werden mit durchsucht |
+| Benutzer | Benutzername-Attribut | Attribut, das mit dem Anmeldenamen abgeglichen wird: `sAMAccountName` in AD (der Standard), `uid` in OpenLDAP |
+| Benutzer | Mail-Attribut | Attribut mit der E-Mail-Adresse, meist `mail` |
+| Benutzer | Anmeldedomänen | Domänen, deren Anmeldungen als `user@domain` direkt zu diesem Verzeichnis gehen, siehe [Mehrere Verzeichnisse](#several-directories) |
+| Gruppen | Gruppen-Attribut | Attribut des Benutzereintrags, das die Gruppen enthält (`memberOf`, der Standard), oder `groups` mit einer Gruppensuche |
+| Gruppen | Gruppen-Search-Base | DN, ab dem die Gruppensuche beginnt |
+| Gruppen | Gruppenklasse | objectClass der Gruppen, z. B. `group`, `groupOfNames` oder `posixGroup` |
+| Gruppen | Gruppenmitglied-Attribut | Attribut einer Gruppe, das ihre Mitglieder auflistet, z. B. `member`, `uniqueMember` oder `memberUid`; Standard `member` |
+| Gruppen | Benutzerattribut für Gruppenmitglied | Attribut des Benutzers, das diese Mitgliedswerte enthalten, z. B. `dn` oder `uid`; Standard `dn` |
+| Gruppen | Gruppenfilter | Regulärer Ausdruck; nur die Gruppen, deren Name passt, bleiben erhalten. Leer behält jede Gruppe |
+
+Die Standardwerte der letzten drei Gruppenfelder gelten nur, wenn die Gruppensuche verwendet wird, siehe den nächsten Abschnitt.
+
+Die `ldap`-Anmeldedaten enthalten, wie das Verzeichnis erreicht wird und als wer es durchsucht wird:
+
+| Feld | Bedeutung |
+|---|---|
+| Server | Einer pro Feld, als `host`, `host:port` oder `ldaps://host:port`, in dieser Reihenfolge versucht: Ist einer nicht erreichbar, wird der nächste versucht |
+| Port | `389` für einfaches LDAP, `636` für LDAPS |
+| TLS aktivieren | Mit LDAPS (`ldaps://`) verbinden. StartTLS auf Port 389 wird nicht unterstützt |
+| Zertifikate ignorieren | Die Prüfung des Serverzertifikats überspringen. Nur mit **TLS aktivieren** angezeigt |
+| Zertifikat | Das Client-Zertifikat, das AnsibleForms den Servern vorlegt, in PEM, wenn die Zertifikate geprüft werden |
+| CA-Bundle | Das oder die CA-Zertifikate, die das Serverzertifikat signiert haben, in PEM, wenn die Zertifikate geprüft werden |
+| Bind-User-DN | Der DN des Dienstkontos, das das Verzeichnis durchsucht |
+| Bind-User-Passwort | Sein Passwort, verschlüsselt gespeichert oder aus einem [Secret Store](../secret-stores/) gelesen |
+
+Nur ein Admin kann `ldap`-Anmeldedaten hinzufügen oder ändern, siehe [Wer Anmeldedaten ändern darf](../credentials.html#who-may-change-a-credential).
+Bis 7.2.0 waren die Server, TLS und das Bind-Konto Felder der LDAP-Einstellungen. Das Upgrade auf 7.3.0 verschiebt sie in einen Anmeldedaten-Eintrag,
+siehe [Adressen in Anmeldedaten](../credentials/types.html#addresses-in-credentials):
+
+| Das Verzeichnis vor dem Upgrade | Wohin seine Server gehen |
+|---|---|
+| Eigener Bind-DN und eigenes Passwort, keine Anmeldedaten | Ein neuer `ldap`-Eintrag namens `<directory>-ldap`, etwa `main-ldap` |
+| Anmeldedaten ohne Server | In diese Anmeldedaten |
+| Anmeldedaten, die bereits andere Server enthalten | Eine Kopie der Anmeldedaten namens `<credential>-<directory>`, die das Verzeichnis dann verwendet |
+
+Ein bereits vergebener Name erhält `-2`, `-3` und so weiter. Ein Verzeichnis aus dem Config-Seed bleibt, wie es ist: Der Seed verwaltet es.
+
+---
+
+## Gruppen
+
+Die Gruppen kommen aus einer von zwei Quellen, und das **Gruppen-Attribut** entscheidet, welche verwendet wird:
+
+- **Ein Attribut des Benutzereintrags**, meist `memberOf`. Das ist die übliche Einrichtung für Active Directory und für
+  OpenLDAP mit dem Overlay `memberof`.
+- **Eine Gruppensuche**, für Verzeichnisse ohne `memberOf`. Sie läuft nur, wenn **Gruppen-Search-Base** und **Gruppenklasse**
+  beide gesetzt sind: AnsibleForms sucht dann nach Gruppen dieser Klasse, deren **Gruppenmitglied-Attribut** das
+  **Benutzerattribut für Gruppenmitglied** des Benutzers enthält, und speichert das Ergebnis im Attribut `groups`. Setzen Sie **Gruppen-Attribut** auf `groups`,
+  um es zu verwenden.
+
+{: .note }
+> Mit dem **Gruppen-Attribut** `memberOf` läuft eine konfigurierte Gruppensuche zwar, ihr Ergebnis wird aber nicht für die Rollen verwendet.
+
+Jede Gruppe ist ein DN, und AnsibleForms behält ihren ersten CN: Aus `CN=AF-Admins,OU=Groups,DC=example,DC=com` wird `AF-Admins`.
+Auf diesen Namen wird dann der **Gruppenfilter** angewendet, und die verbleibenden Gruppen erhalten das Präfix `ldap/`: `ldap/AF-Admins`.
+
+In großen Verzeichnissen hält der Filter Token und Jobs klein; ein ungültiger regulärer Ausdruck behält alle Gruppen und wird protokolliert.
+
+---
+
+## Zuordnung zu Rollen
+
+In config.yaml ist eine LDAP-Gruppe `ldap/<group CN>` und ein LDAP-Benutzer `ldap/<username>`, beide mit Beachtung der Groß- und Kleinschreibung:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+Der Benutzername ist der Wert des **Benutzername-Attributs**, wie das Verzeichnis ihn zurückgibt, nicht wie der Benutzer ihn eingegeben hat.
+Siehe [Rollen](../config/roles.html) für die Rollenoptionen.
+
+---
+
+## Mehrere Verzeichnisse
+
+Ab 7.3.0 kann es mehrere Verzeichnisse geben, jedes mit eigenen Servern, Benutzern und Gruppen. Ihre Namen unterscheiden ihre Mitglieder:
+
+| Verzeichnis | Benutzername | Gruppen | In einer Rolle |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Jedes andere, etwa `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Ein Benutzer nennt das Verzeichnis bei der Anmeldung als `corp\jdoe` oder `corp/jdoe`, oder er meldet sich mit einer Adresse einer Domäne an, die dem Verzeichnis
+gehört. Ein einfacher Benutzername wird in jedem aktivierten Verzeichnis versucht, in ihrer Reihenfolge, und ebenso ein Name wie `other\jdoe`, wenn kein
+Verzeichnis `other` heißt: Er wird dann so gesucht, wie er eingegeben wurde.
+
+Das erste Verzeichnis, das den Benutzer kennt, entscheidet: Ein falsches Passwort dort ist die Antwort, und das nächste Verzeichnis wird nicht
+versucht, da es jemand anderen mit diesem Namen enthalten könnte. Ein nicht erreichbares Verzeichnis wird übersprungen.
+
+Das Verzeichnis, das bis 7.2.0 `default` hieß, heißt ab 7.3.0 `main`: Das Upgrade benennt es um, und eine neue Installation beginnt
+mit `main`. Seine Mitglieder behalten ihre Kurznamen, sodass die Rollen, die sie nennen, nicht geändert werden müssen. Das Verzeichnis `main` lässt sich nicht
+umbenennen, und ein Verzeichnisname enthält nur Buchstaben, Ziffern, `-` und `_`.
+
+---
+
+## Die Verbindung testen
+
+**Verbindung testen** fragt nach einem Test-Benutzernamen und -Passwort und versucht eine Anmeldung mit den Einstellungen auf dem Bildschirm, gespeichert oder nicht.
+Bei Erfolg zeigt es den Verzeichniseintrag des Benutzers, der Ihnen die genauen Attributnamen und Gruppen-DNs nennt, die Sie verwenden müssen.
+
+Ein Testbenutzer, der nicht existiert, meldet trotzdem Erfolg: Die Verbindung und das Bind-Konto funktionieren, nur der Benutzer wird nicht
+gefunden. Typische Fehler:
+
+| Meldung | Ursache |
+|---|---|
+| `Bad server or port (connection failed)` | Der Hostname lässt sich nicht auflösen oder der Port ist nicht erreichbar. |
+| `Wrong binding credentials` | Bind-DN oder Passwort in den Anmeldedaten des Verzeichnisses sind falsch. |
+| `Unable to verify the certificate` | Das Serverzertifikat ist nicht vom CA-Bundle der Anmeldedaten signiert. |
+| `Certificate is not valid` | Zertifikat oder CA-Bundle der Anmeldedaten enthalten kein gültiges PEM-Zertifikat. |
+
+---
+
+## Beispiel für Active Directory
+
+Dieses Beispiel verbindet sich über LDAPS mit zwei Domänencontrollern und behält nur die Gruppen, deren Name mit `AF-` beginnt:
+
+| Einstellung | Wert |
+|---|---|
+| Anmeldedaten > Server | `dc01.example.com`, dann `dc02.example.com` |
+| Anmeldedaten > Port | `636` |
+| Anmeldedaten > TLS aktivieren | ein |
+| Anmeldedaten > Zertifikate ignorieren | aus, mit einem Client-Zertifikat und der CA-Kette der Unternehmens-CA |
+| Anmeldedaten > Bind-User-DN | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Search Base | `OU=Users,DC=example,DC=com` |
+| Mail-Attribut | `mail` |
+| Benutzername-Attribut | `sAMAccountName` |
+| Gruppen-Attribut | `memberOf` |
+| Gruppenfilter | `^AF-` |
+
+Mitglieder von `CN=AF-Operators,…` passen zu Rollen mit `ldap/AF-Operators` und melden sich als `jdoe` oder `jdoe@example.com` an.
+
+---
+
+## Beispiel für OpenLDAP
+
+Dieses Beispiel verwendet eine Gruppensuche auf Einträgen vom Typ `groupOfNames` und funktioniert daher ohne das Overlay `memberof`:
+
+| Einstellung | Wert |
+|---|---|
+| Anmeldedaten > Server | `ldap.example.com` |
+| Anmeldedaten > Port | `636` |
+| Anmeldedaten > TLS aktivieren | ein |
+| Anmeldedaten > Bind-User-DN | `cn=readonly,dc=example,dc=com` |
+| Search Base | `ou=people,dc=example,dc=com` |
+| Mail-Attribut | `mail` |
+| Benutzername-Attribut | `uid` |
+| Gruppen-Attribut | `groups` |
+| Gruppen-Search-Base | `ou=groups,dc=example,dc=com` |
+| Gruppenklasse | `groupOfNames` |
+| Gruppenmitglied-Attribut | `member` |
+| Benutzerattribut für Gruppenmitglied | `dn` |
+
+Ein Benutzer, der in `cn=af-admins,ou=groups,dc=example,dc=com` aufgeführt ist, erhält die Gruppe `ldap/af-admins`. Für Gruppen vom Typ `posixGroup`
+verwenden Sie das **Gruppenmitglied-Attribut** `memberUid` und das **Benutzerattribut für Gruppenmitglied** `uid`.
+
+Mit dem Overlay `memberof` lassen Sie die Felder der Gruppensuche leer und setzen das **Gruppen-Attribut** auf `memberOf`.
+
+---
+
+## Häufige Fallstricke
+
+Die meisten LDAP-Probleme lassen sich auf eine dieser Ursachen zurückführen:
+
+- **Ein lokaler Benutzer mit demselben Namen.** Lokale Benutzer werden zuerst geprüft, daher wird das Verzeichnis für diesen Namen nie gefragt.
+- **Keine Gruppen oder die falschen.** Das Gruppen-Attribut muss existieren (`groups` mit einer Gruppensuche); `memberOf` überspringt Verschachtelungen.
+- **Gruppennamen, die nicht passen.** Verwenden Sie `ldap/<CN>` in derselben Schreibweise, und prüfen Sie, dass der Gruppenfilter die Gruppe behält.
+- **Gruppen-DNs, die nicht mit einem CN beginnen.** Nur der erste Wert `CN=` wird als Gruppenname verwendet, daher muss jeder Gruppen-DN
+  mit `CN=` (oder `cn=`) beginnen.
+- **Zertifikate.** TLS braucht beide Zertifikatsfelder der Anmeldedaten und einen passenden Servernamen; Zertifikate ignorieren ist nur zum Testen gedacht.
+- **Einstellungen, die sich nicht speichern lassen.** Stammt ein Verzeichnis aus dem [Config-Seed](../seed/managed-objects.html), ist seine Seite
+  schreibgeschützt: Ändern Sie stattdessen die Seed-Datei.
+
+Eine fehlgeschlagene Anmeldung zeigt eine allgemeine Meldung. Der Grund wird vom Server protokolliert und im Audit-Protokoll festgehalten, und bei Active
+Directory wird er aus dem Code des Verzeichnisses übersetzt, z. B. `Wrong password`, `Account locked` oder `Password expired`.
diff --git a/i18n/de/_configure/authentication/local.md b/i18n/de/_configure/authentication/local.md
new file mode 100644
index 0000000..83fdff6
--- /dev/null
+++ b/i18n/de/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Lokale Konten
+parent: Authentifizierung
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Lokale Konten
+{: .no_toc }
+
+Der integrierte Admin sowie die Benutzer und Gruppen in der AnsibleForms-Datenbank
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Der integrierte Admin
+
+Jeder Start legt die lokale Gruppe `admins` und den Admin-Benutzer an, falls sie fehlen; drei Variablen steuern den Admin:
+
+| Variable | Standard | Bedeutung |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Benutzername des Admins, in der Gruppe `admins` angelegt, wenn kein Benutzer diesen Namen hat. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Passwort, das der Admin beim Anlegen (oder Zurücksetzen) erhält. |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` setzt das Passwort des Admins auf `ADMIN_PASSWORD` zurück und nimmt ihn wieder in `admins` auf. |
+
+`ADMIN_PASSWORD` wird nur beim Anlegen oder Zurücksetzen des Benutzers verwendet: Eine spätere Änderung bewirkt für sich allein nichts.
+
+Ein lokaler Benutzer, der sich mit dem öffentlich bekannten Standardpasswort `AnsibleForms!123` anmeldet, kann nur dieses ändern. Der Browser öffnet eine
+Seite zum Ändern des Passworts, die sich nicht schließen lässt, und der Server beantwortet jede andere Anfrage mit `403` (Code
+`password_change_required`), bis das Passwort geändert ist. Das neue Passwort muss sich vom Standard unterscheiden; nach der
+Änderung meldet sich der Benutzer damit erneut an. Setzen Sie `ADMIN_PASSWORD` vor dem ersten Start auf einen eigenen Wert, um diesen Schritt zu überspringen.
+
+Eine Änderung von `ADMIN_USERNAME` nach dem ersten Start legt einen zweiten Admin-Benutzer mit diesem Namen an; der alte bleibt erhalten.
+
+{: .warning }
+> `REINIT_ADMIN=1` setzt das Passwort bei **jedem** Start zurück, solange es gesetzt ist. Verwenden Sie es, um ein verlorenes Admin-Passwort wiederherzustellen,
+> entfernen Sie es dann und starten Sie neu.
+
+---
+
+## Benutzer und Gruppen
+
+Lokale Benutzer und Gruppen werden unter **Zugriff > Benutzer** und **Zugriff > Gruppen** verwaltet. Ein Benutzer hat diese Felder:
+
+| Feld | Bedeutung |
+|---|---|
+| Benutzername | Der Anmeldename. Muss eindeutig sein. |
+| Beschreibung | Optional. |
+| Passwort | Als Hash gespeichert. Später mit der Aktion **Passwort ändern** änderbar. |
+| E-Mail | Optional. |
+| Gruppe | Die erste lokale Gruppe des Benutzers. Weitere fügen Sie im Tab **Gruppen** der Benutzerseite hinzu. |
+
+Lokale Benutzer ändern ihr eigenes Passwort in ihrem Profil; andere Benutzer tun das in ihrem Verzeichnis oder Identitätsanbieter.
+
+Ein Benutzer kann mehreren Gruppen angehören und erhält die Rollen aller dieser Gruppen. Der Tab **Gruppen** der Benutzerseite fügt
+Gruppen hinzu und entfernt sie, ebenso der Tab **Benutzer** der Gruppenseite. Ein Benutzer behält mindestens eine Gruppe: Die letzte lässt sich nicht
+entfernen.
+
+Eine Gruppe, die noch Benutzer hat, kann nicht gelöscht werden: Entfernen Sie zuerst ihre Benutzer. Die Gruppe `admins` kann nie gelöscht oder
+umbenannt werden, und der Benutzer `admin` kann nie gelöscht werden.
+
+---
+
+## Anmeldung erlauben
+
+Der Tab **Details** der Benutzerseite hat einen Schalter **Anmeldung erlauben**, der auch als **Anmeldung sperren** und **Anmeldung
+erlauben** im Menü der Zeile in der Benutzerliste angeboten wird. Er existiert gleichermaßen für lokale Benutzer und für LDAP- und SSO-Benutzer:
+
+- **Ein**: Der Benutzer meldet sich wie gewohnt an.
+- **Aus**: Die Sitzungen des Benutzers enden sofort und jede Anmeldung wird abgewiesen, bis ein Admin den Schalter wieder einschaltet. Die Seite
+  fragt vorher nach einer Bestätigung.
+
+Der Schalter lässt sich für den Benutzer `admin`, den Weg zurück ins System, nicht ausschalten, und ein Admin kann ihn auch nicht für sein eigenes Konto ausschalten. Die Seite
+eines LDAP- oder SSO-Benutzers hat außerdem **Sitzungen beenden**, das den Benutzer überall abmeldet, ohne ihn zu sperren.
+
+---
+
+## Zuordnung zu Rollen
+
+Rollen benennen lokale Gruppen als `local/<group>` und Benutzer als `local/<user>`; standardmäßig erhält `admins` die Rolle `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Behalten Sie `local/admins` in der Rolle `admin`, damit sich der integrierte Admin immer anmelden kann, auch wenn das Verzeichnis oder der
+Identitätsanbieter nicht verfügbar ist. Lässt sich config.yaml überhaupt nicht laden, erhalten Mitglieder von `local/admins` dennoch die
+Rolle `admin`, sodass Sie sich anmelden und den Fehler beheben können. Siehe [Rollen](../config/roles.html) für die Rollenoptionen.
+
+---
+
+## Lokale Konten und LDAP
+
+Eine Anmeldung mit Benutzername und Passwort prüft die lokalen Benutzer vor LDAP. Hat ein lokaler Benutzer denselben Namen wie ein Verzeichnis-Benutzer,
+gewinnt immer das lokale Konto, und das Verzeichnispasswort funktioniert für diesen Namen nicht. Geben Sie lokalen Konten Namen,
+die nicht mit Verzeichniskonten kollidieren können, zum Beispiel mit dem Präfix `svc-`.
diff --git a/i18n/de/_configure/authentication/oidc.md b/i18n/de/_configure/authentication/oidc.md
new file mode 100644
index 0000000..93a4e66
--- /dev/null
+++ b/i18n/de/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Authentifizierung
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Single Sign-on mit einem OpenID Connect-Anbieter wie Keycloak, mit Rollen aus einem Gruppen-Claim
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Funktionsweise
+
+Ist ein OIDC-Anbieter aktiviert, zeigt die Anmeldeseite unter **Anmelden** eine OpenID-Schaltfläche. Eine Anmeldung läuft dann so ab:
+
+1. Die Schaltfläche schickt den Browser zu `/api/v2/auth/oidc`, das ihn zum Anbieter weiterleitet (Authorization Code Flow
+   mit PKCE).
+2. Der Benutzer meldet sich beim Anbieter an, der zur **Umleitungs-URL** zurückleitet.
+3. Der Server tauscht den Code gegen Token und liest die Claims des ID-Tokens.
+4. Der Benutzername ist der Claim `preferred_username`, und jeder Wert des Claims `groups`, der den
+   **Gruppenfilter** passiert, wird zu einer Gruppe `oidc/<value>`.
+
+AnsibleForms fordert die Scopes `openid profile email` an; die Scopes sind nicht konfigurierbar. Das Abmelden von AnsibleForms
+schickt den Browser außerdem zum End-Session-Endpunkt des Anbieters, sofern der Anbieter einen veröffentlicht.
+
+{: .note }
+> OIDC wurde mit Keycloak getestet. Andere Anbieter funktionieren, wenn sie die folgenden Anforderungen erfüllen.
+
+---
+
+## Anforderungen an den Anbieter
+
+Der Anbieter muss OpenID Connect Discovery und einen vertraulichen Client für AnsibleForms anbieten:
+
+- **Discovery**: AnsibleForms liest `<issuer>/.well-known/openid-configuration`, daher muss der Issuer vom
+  AnsibleForms-Server aus über HTTPS erreichbar sein.
+- **Ein vertraulicher Client** mit dem Authorization Code Flow, einer Client-ID und einem Client-Secret.
+- **Der Redirect URI** `https://af.example.com/api/v2/auth/oidc/callback`, also die Adresse, unter der Benutzer
+  AnsibleForms erreichen, gefolgt von `/api/v2/auth/oidc/callback`. Mit [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms` wird daraus `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Ein Claim `groups` im ID-Token**, der eine Liste von Gruppennamen enthält. Ohne ihn erhält der Benutzer keine OIDC-Gruppen.
+- **Ein Claim `preferred_username`**, der zum Benutzernamen wird.
+
+---
+
+## Beispiel für Keycloak
+
+Dieses Beispiel verwendet ein Realm `example` auf `https://keycloak.example.com`; der Issuer ist dann
+`https://keycloak.example.com/realms/example`. In diesem Realm:
+
+1. Erstellen Sie unter **Clients** einen OpenID Connect-Client mit der Client-ID `ansibleforms`. Schalten Sie **Client authentication** ein,
+   behalten Sie **Standard flow** bei und setzen Sie **Valid redirect URIs** auf `https://af.example.com/api/v2/auth/oidc/callback`.
+2. Kopieren Sie im Tab **Credentials** des Clients das **Client secret**.
+3. Öffnen Sie im Tab **Client scopes** `ansibleforms-dedicated` und fügen Sie einen Mapper **By configuration > Group Membership** hinzu,
+   mit **Token Claim Name** `groups`, **Full group path** aus und **Add to ID token** ein.
+
+Mit eingeschaltetem **Full group path** enthält der Claim Pfade wie `/af-admins`, und die Rolle muss dann `oidc//af-admins` verwenden.
+
+---
+
+## Den Anbieter hinzufügen
+
+Fügen Sie den Anbieter unter **Zugriff > SSO** hinzu: Ein Assistent fragt seine Felder in vier Schritten ab, mit **Open ID** im Schritt **Typ**:
+
+| Schritt | Feld | Bedeutung |
+|---|---|---|
+| Details | Name, Beschreibung | Ein eindeutiger Name für den Anbieter und eine optionale Beschreibung |
+| Typ | Anbieter | **Open ID**; beim Anlegen festgelegt, bleibt er so |
+| Anmeldedaten | Anmeldedaten-Eintrag | Ein **Open ID**-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html), siehe unten |
+| Gruppen | Gruppenfilter | Regulärer Ausdruck; nur die passenden Werte des Claims `groups` bleiben erhalten. Leer behält jede Gruppe |
+
+Die Anmeldedaten enthalten den Client, daher kann nur ein Admin sie hinzufügen oder ändern:
+
+| Feld | Bedeutung |
+|---|---|
+| Issuer | Erforderlich. Die Issuer-URL, z. B. `https://keycloak.example.com/realms/example` |
+| Client-ID | Die Client-ID beim Anbieter, z. B. `ansibleforms` |
+| Client-Secret | Das Client-Secret, verschlüsselt gespeichert oder aus einem [Secret Store](../secret-stores/) gelesen |
+| Umleitungs-URI | Wie registriert, z. B. `https://af.example.com/api/v2/auth/oidc/callback`. Leer: die URL der App und der Callback-Pfad |
+
+Bis 7.2.0 waren Issuer, Client-ID, Secret und Umleitungs-URL Felder des Anbieters. Das Upgrade auf 7.3.0 verschiebt sie in
+Anmeldedaten namens `<provider>-sso`, siehe [Adressen in Anmeldedaten](../credentials/types.html#addresses-in-credentials).
+Wählen Sie für jeden neuen Anbieter Anmeldedaten: Der Server akzeptiert weiterhin einen Anbieter mit eigener Client-ID und eigenem Secret aus der Zeit
+vor 7.3.0, der sich damit anmeldet, bis Anmeldedaten gewählt sind.
+
+Es ist jeweils ein OIDC-Anbieter aktiviert, der, mit dem sich die OpenID-Schaltfläche anmeldet. **Aktivieren** im Menü der Zeile eines anderen
+oder sein Schalter **Aktiviert** schaltet die anderen seines Typs aus; die Spalte **Aktiviert** der Liste zeigt, welcher verwendet wird.
+Ein Anbieter kann auch die Anmeldeseite überspringen, siehe [Single Sign-on umschalten](./#switching-single-sign-on).
+
+Das Speichern des Anbieters wendet ihn sofort an. Ist der Issuer nicht erreichbar, protokolliert der Server
+`Failed to initialize OIDC strategy`, und OIDC-Anmeldungen schlagen fehl, bis der Anbieter erneut gespeichert oder der Server neu gestartet wird.
+
+---
+
+## Zuordnung zu Rollen
+
+In config.yaml ist eine OIDC-Gruppe `oidc/<group>` und ein Benutzer `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+Die Werte werden exakt abgeglichen, einschließlich der Groß- und Kleinschreibung. Siehe [Rollen](../config/roles.html) für die Rollenoptionen.
+
+---
+
+## Einschränkungen
+
+OIDC-Benutzer melden sich beim Anbieter an, daher funktionieren einige Dinge anders als bei lokalen und LDAP-Konten:
+
+- Sie haben kein Passwort in AnsibleForms und können es dort daher nicht ändern; ab 7.2.0 wird ein [API-Token](../profile/api-token.html)
+  aus ihrer Sitzung erstellt.
+- Halten Sie den Claim `groups` kurz: Senden Sie nur die Gruppen, die für AnsibleForms wichtig sind, etwa mit einem eigenen
+  Client-Scope oder einer Gruppenstruktur beim Anbieter, oder filtern Sie sie mit dem **Gruppenfilter**. Ab 7.1.0 enthält das Anmeldetoken
+  von AnsibleForms die Gruppen nicht mehr; vorher konnte ein Benutzer in hundert oder mehr Gruppen keine Formulare sehen, siehe
+  [Leere Formulare und Jobs nach einem Single Sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/de/_configure/config/categories.md b/i18n/de/_configure/config/categories.md
new file mode 100644
index 0000000..95d9458
--- /dev/null
+++ b/i18n/de/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Kategorien
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Kategorien
+{: .no_toc }
+
+Gruppieren Sie die Formulare auf dem Dashboard.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Das Attribut categories
+
+Die Liste `categories` auf oberster Ebene von config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Das Objekt Category
+
+Jeder Eintrag der Liste `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/de/_configure/config/constants.md b/i18n/de/_configure/config/constants.md
new file mode 100644
index 0000000..6b1f325
--- /dev/null
+++ b/i18n/de/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Konstanten
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Konstanten
+{: .no_toc }
+
+Freie Objekte, die jedes Formular wiederverwenden kann.
+{: .fs-6 .fw-300 }
+
+---
+
+## Das Attribut constants
+
+Das Objekt `constants` auf oberster Ebene von config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/de/_configure/config/index.md b/i18n/de/_configure/config/index.md
new file mode 100644
index 0000000..8a5b894
--- /dev/null
+++ b/i18n/de/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Kategorien, Rollen und Konstanten für alle Formulare
+{: .fs-6 .fw-300 }
+
+---
+
+Für Administratoren: die Datei config.yaml, die die Kategorien, Rollen und Konstanten enthält, die alle Formulare gemeinsam nutzen.
+
+AnsibleForms verwendet eine Datei config.yaml, um Kategorien, Rollen und Konstanten zu konfigurieren. Wird keine Datei bereitgestellt, wird eine mit einer minimalen Konfiguration erzeugt. Die Konfiguration kann auch in die Datenbank importiert werden, wodurch keine Datei config.yaml mehr nötig ist.
+
+---
+
+## Überblick
+
+Die Datei config.yaml enthält die Konfiguration für die Kategorien, Rollen und Konstanten, die AnsibleForms verwendet.
+
+**VIDEO**: [Ihr erstes Formular erstellen](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+Die folgende minimale config.yaml dient als Ausgangspunkt. Sie enthält nur die erforderliche Kategorie `Default` und die erforderlichen Rollen `admin` und `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Ladereihenfolge der Konfiguration
+
+AnsibleForms lädt die Datei config.yaml in der folgenden Reihenfolge (der erste Treffer gewinnt):
+
+1. **AUS DER DATENBANK** : die in die Datenbank importierte Konfiguration, nur wenn `ENABLE_CONFIG_IN_DATABASE=1` gilt oder wenn diese
+   Variable nicht gesetzt ist und die in der Datenbank gespeicherte Konfigurationsquelle `database` ist (eine leere Kopie fällt auf die Datei zurück)
+2. **AUS EINEM REPOSITORY (use_for_config)** : das Repository mit eingeschaltetem Schalter „Für Konfiguration verwenden“ (neu in 6.1.0)
+3. **AUS EINEM REPOSITORY (use_for_forms)** : das Repository mit eingeschaltetem Schalter „Für Formulare verwenden“ (Rückfall aus Gründen der Abwärtskompatibilität)
+4. **AUS DER LOKALEN DATEI** : die lokale Datei `config.yaml` (Umgebungsvariable CONFIG_PATH)
+
+{: .warning }
+> **Hinweis:** Schalten Sie „Für Konfiguration verwenden“ nur bei einem Repository ein. Ist es bei mehreren eingeschaltet, wird eine Warnung protokolliert und das erste verwendet.
+
+---
+
+## In diesem Abschnitt
+
+Die Datei hat drei Attribute auf oberster Ebene, und jedes hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Kategorien](categories.html) | Die Formulare auf dem Dashboard in einem Baum von Kategorien mit Symbolen gruppieren |
+| [Rollen](roles.html) | Benutzer und Gruppen Rollen zuordnen und festlegen, was jede Rolle darf |
+| [Konstanten](constants.html) | Freie Objekte, die jedes Formular wiederverwenden kann |
diff --git a/i18n/de/_configure/config/roles.md b/i18n/de/_configure/config/roles.md
new file mode 100644
index 0000000..7b72962
--- /dev/null
+++ b/i18n/de/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Rollen
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Rollen
+{: .no_toc }
+
+Ordnen Sie Benutzer und Gruppen Rollen zu, und legen Sie fest, was jede Rolle darf.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Das Attribut roles
+
+Die Liste `roles` auf oberster Ebene von config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## Die Rolle default
+
+Jeder angemeldete Benutzer hat die Rolle `default`, daher steht ein Formular mit `roles: [default]` jedem offen, der sich anmelden kann. Es
+gibt keinen anonymen Zugriff: Niemand erhält diese Rolle, ohne sich anzumelden.
+
+Die Rolle enthält keine Gruppen und keine Benutzer, da sie bereits für alle gilt. Ihre `options` sind die Standardwerte für alle, wie
+unten unter [Rollenoptionen](#role-options) beschrieben. `config.yaml` muss eine Rolle `admin` und eine Rolle `default` enthalten, und die
+Rollenseite zeigt beide als **Erforderlich**.
+
+`default` hieß vor 7.0.0 `public`, und der alte Name funktioniert weiterhin:
+
+- **In einem Formular** passt `roles: [public]` weiterhin zu jedem Benutzer, daher müssen die Formulare in Ihren Repositories nicht geändert werden.
+- **In `config.yaml`** wird eine Rolle namens `public` beim Laden der Konfiguration in der Datei in `default` umbenannt. Nur der Name
+  ändert sich, vorher wird eine Sicherung der Konfiguration angelegt, und eine in einem Repository gehaltene Konfiguration hat danach eine Änderung zum Pushen.
+- **In einem ytt-Template** wird das Template nicht umgeschrieben: Die daraus erzeugte Konfiguration wird umbenannt, und eine Warnung im Protokoll bittet
+  Sie, die Rolle auch im Template umzubenennen. Version 8 weist dort eine Rolle `public` ab.
+
+Eine Konfiguration mit sowohl einer Rolle `default` als auch einer Rolle `public` wird abgewiesen, da es dieselbe Rolle ist.
+
+---
+
+## Das Objekt Role
+
+Jeder Eintrag der Liste `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Rollenoptionen
+
+Die `options` einer Rolle schalten Funktionen für ihre Mitglieder ein oder aus. Ab 7.3.0 zeigt die Seite der Rolle sie in vier Gruppen,
+jede Option mit einem (i), das sagt, was sie gewährt, derselbe Text, den die Ansicht **Berechtigungen** des Profils zeigt:
+
+| Option | Erlaubt dem Benutzer | Standard |
+|---|---|---|
+| **Einstellungen** | | |
+| `showSettings` | Jede Einstellungsseite sehen und ändern; das Serverprotokoll und die Backups haben eigene Optionen | Nur Admins |
+| `showAppearanceSettings` | Die Erscheinungsbild-Einstellungen ändern, ohne die übrigen Einstellungen (ab 7.3.0) | Aus |
+| `showConnectionsSettings` | Die Verbindungs-Einstellungen verwalten (Anmeldedaten, Runner und mehr), ohne die übrigen Einstellungen (ab 7.3.0) | Aus |
+| `showLogs` | Das Serverprotokoll sehen | Nur Admins |
+| `showAuditLog` | Das Audit-Protokoll sehen, ohne die übrigen Einstellungen (ab 7.3.0) | Nur Admins |
+| `allowBackupOps` | Die Datenbank sichern und wiederherstellen | Nur Admins |
+| **Designer** | | |
+| `showDesigner` | Den Designer sehen und verwenden | Nur Admins |
+| `allowFormDesign` | Die Formularkonfiguration im Designer bearbeiten: Kategorien, Konstanten und Formulare. Ohne sie nur lesen (ab 7.3.0) | Ein |
+| `allowPlaybookDesign` | Die Playbooks im Designer bearbeiten: speichern, erstellen, entfernen und pushen. Ohne sie nur lesen | Ein |
+| `allowWorkflowDesign` | Die Workflows im Designer bearbeiten: speichern, erstellen, entfernen und pushen. Ohne sie nur lesen | Ein |
+| `allowInventoryDesign` | Die Inventare im Designer bearbeiten: speichern, erstellen, entfernen und pushen. Ohne sie nur lesen | Ein |
+| `allowVarsFileDesign` | Die Variablendateien im Designer bearbeiten: speichern, erstellen, entfernen und pushen. Ohne sie nur lesen | Ein |
+| **Jobs** | | |
+| `showJobs` | Die Seite Jobs sehen | Ein |
+| `showAllJobLogs` | Die Jobs jedes Benutzers sehen, nicht nur die eigenen | Nur Admins |
+| `manageAllJobs` | Die Jobs jedes Benutzers abbrechen, löschen und neu starten; Löschen und Neustarten brauchen zusätzlich die beiden Optionen unten (ab 7.3.0) | Nur Admins |
+| `showExtravars` | Die Extravars eines Formulars und eines Jobs sehen | Ein |
+| `showDebugButtons` | Die Debug-Buttons eines Formulars sehen | Ein |
+| `showArtifacts` | Die Artefakte eines Jobs sehen: was ein AWX-Job zurückgibt oder was ein Playbook mit `set_stats` gesammelt hat | Ein |
+| `allowVerboseMode` | Jobs im ausführlichen Modus ausführen | Ein |
+| `allowJobRelaunch` | Einen Job mit den Formulardaten eines früheren Laufs neu starten | Nur Admins |
+| `allowJobDeletion` | Jobs löschen: die eigenen oder mit `manageAllJobs` die aller Benutzer. Ohne sie bleibt der Job-Verlauf vollständig (ab 7.3.0) | Ein |
+| `allowScheduledJobs` | Wiederkehrende und einmalige Zeitpläne erstellen und verwalten, auf der Seite **Zeitpläne** (siehe die Warnung unten) | Nur Admins |
+| `allowPlannedJobs` | Einen Job einplanen, der einmal zu einer festgelegten Zeit läuft (**Später ausführen**) | Ein |
+| `allowStoredJobs` | Die Daten eines Formulars speichern und später wieder laden | Ein |
+| **Zugang und Integrationen** | | |
+| `allowLogin` | Sich bei AnsibleForms anmelden | Ein |
+| `allowChat` | Den [Chat-Assistenten](../chat/) verwenden, wenn er aktiviert ist | Ein |
+| `allowMcp` | Den [MCP-Server](../mcp/) von einem KI-Agenten aus verwenden, wenn er aktiviert ist | `allowChat` der Rolle |
+| `allowFileUploads` | Dateien über die Dateifelder eines Formulars hochladen (ab 7.3.0) | Ein |
+| `allowApiTokens` | [API-Token](../profile/api-token.html) für Skripte erstellen, bis zur längsten Laufzeit, die die Instanz erlaubt (ab 7.3.0) | Aus |
+| `extendedTokenExpiration` | Auch API-Token erstellen, die nie ablaufen; erfordert `allowApiTokens` | Aus |
+
+Manche Optionen schließen andere ein, und die Seite der Rolle zeigt die eingeschlossenen eingeschaltet und ausgegraut:
+
+- **`showSettings`** gewährt auch `showAppearanceSettings`, `showConnectionsSettings` und `showAuditLog`.
+- **`manageAllJobs`** gewährt auch `showAllJobLogs`, da man die Jobs jedes Benutzers sehen muss, um mit ihnen zu arbeiten.
+- **Die Design-Optionen** zählen nur mit `showDesigner`, und `extendedTokenExpiration` nur mit `allowApiTokens`.
+
+Bis 7.2.0 ließ `showAllJobLogs` einen Benutzer auch die angezeigten Jobs abbrechen und löschen; ab 7.3.0 braucht das `manageAllJobs`.
+Eine Rolle aus der Zeit vor 7.3.0 mit `extendedTokenExpiration` und ohne `allowApiTokens` erhält `allowApiTokens`, sodass sie ihre Token behält.
+
+**Nur Admins** bedeutet eingeschaltet für Benutzer mit der Rolle `admin` und ausgeschaltet für alle anderen. Passt ein Benutzer zu mehreren Rollen,
+werden die Optionen wie folgt kombiniert:
+
+- **Zwischen den Rollen des Benutzers** ist eine Option nur eingeschaltet, wenn jede Rolle, die sie setzt, zustimmt: Ein explizites `false` gewinnt.
+- **Die Rolle `default`** ergänzt die Optionen, die keine der anderen Rollen des Benutzers setzt, und kann so Standardwerte für alle enthalten.
+- **Nirgends gesetzte Optionen** übernehmen den Standard aus der Tabelle.
+
+`showExtraVars` mit großem V wird als andere Schreibweise von `showExtravars` akzeptiert; ist eine der beiden Schreibweisen `false`, ist die
+Option ausgeschaltet.
+
+{: .warning }
+> Behandeln Sie `allowScheduledJobs` als Option auf Admin-Ebene. Zeitpläne gehören nicht dem Benutzer, der sie erstellt hat: Jeder Benutzer mit
+> der Option sieht alle Zeitpläne und kann sie ändern. Ein Zeitplan läuft außerdem mit Admin-Rechten, für jedes Formular, unabhängig von den
+> eigenen Zugriffsrechten des Erstellers. Gewähren Sie sie nur Rollen, denen Sie wie Admins vertrauen würden.
+
+{: .warning }
+> `allowLogin: false` auf der Rolle `default` sperrt jeden Benutzer aus, dessen andere Rollen nicht `allowLogin: true` setzen, einschließlich
+> der Admins. Gewähren Sie sie den Rollen, die sich anmelden müssen, wieder, bevor Sie speichern.
diff --git a/i18n/de/_configure/credentials.md b/i18n/de/_configure/credentials.md
new file mode 100644
index 0000000..833cfc6
--- /dev/null
+++ b/i18n/de/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Anmeldedaten
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Anmeldedaten
+{: .no_toc }
+
+Speichern Sie die Anmeldungen, mit denen sich Formulare, Repositories, Secret Stores und Benachrichtigungskanäle verbinden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Hinterlegen Sie die Benutzer, Passwörter und Token, mit denen sich AnsibleForms verbindet, verschlüsselt gespeichert oder aus einem Secret Store gelesen.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Typen von Anmeldedaten](credentials/types.html) | Was jeder Typ enthält und wo er gewählt werden kann |
+| [Die Seite Anmeldedaten](credentials/list.html) | Die Liste der Anmeldedaten und der Dialog, der einen Eintrag hinzufügt |
+| [Die Seite eines Anmeldedaten-Eintrags](credentials/credential-page.html) | Die Tabs eines Eintrags und was ihn verwendet |
+
+---
+
+## Funktionsweise
+
+Ein **Anmeldedaten-Eintrag** ist eine benannte Anmeldung, angelegt unter **Verbindungen > Anmeldedaten**. Formulare und die anderen Admin-Objekte verweisen
+über seinen Namen darauf, sodass das Passwort selbst nie in einem Formular erscheint. Benutzer und Passwort werden entweder in der
+AnsibleForms-Datenbank gespeichert, verschlüsselt mit `ENCRYPTION_SECRET`, oder bei jeder Verwendung der Anmeldedaten aus einem [Secret Store](secret-stores/)
+gelesen.
+
+---
+
+## Wer Anmeldedaten ändern darf
+
+Ab 7.3.0 können Anmeldedaten, von denen eine Verbindung oder eine Anmeldung abhängt, nur von einem Admin hinzugefügt, geändert oder gelöscht werden:
+
+| Anmeldedaten | Warum |
+|---|---|
+| Verbindungstypen: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` und `cyberark` | Ein Runner oder ein Secret Store nimmt daraus seine Adresse und sein Geheimnis |
+| Anmeldetypen: `oidc`, `entraid` und `ldap` | Ein SSO-Anbieter oder ein LDAP-Verzeichnis meldet Benutzer damit an |
+| Alle Anmeldedaten, die ein Runner nennt | Der Runner meldet sich damit an, und eine Änderung am Runner selbst braucht ebenfalls einen Admin |
+
+Andere Benutzer mit Zugriff auf die Anmeldedaten sehen diese schreibgeschützt. Ein Benutzer, der solche Anmeldedaten auf einen anderen
+Server richten könnte, würde jedes darüber gesendete Geheimnis erhalten; deshalb folgt die Regel der für Runner. Drei weitere Regeln
+halten diese Benutzer von Geheimnissen fern, die sie sonst nicht lesen könnten:
+
+- **Geschützte Anmeldedaten nennen**: Nur ein Admin kann einen dieser Einträge an anderer Stelle nennen, etwa in einem Repository,
+  einem Benachrichtigungskanal oder den Einstellungen des Chat-Assistenten. Anmeldedaten, die ihr Passwort aus einem Secret Store lesen, sind
+  unabhängig von ihrem Typ auf dieselbe Weise geschützt.
+- **Einen Secret Store wählen**: Nur ein Admin kann Anmeldedaten auf einen [Secret Store](secret-stores/) richten oder den
+  Store oder die gelesene Referenz ändern; ein anderer Benutzer darf sie trotzdem unverändert zurücksenden oder alle leeren.
+- **Anmeldedaten verschieben**: Ändert ein anderer Benutzer, wo sich Anmeldedaten anmelden (Host, Port, Issuer, Tenant oder
+  Serveradresse), ohne das Passwort erneut einzugeben, wird das gespeicherte Passwort gelöscht, ebenso die gelesene
+  Secret-Store-Referenz, damit das alte Geheimnis nie an das neue Ziel geht.
+
+---
+
+## Verwendete Anmeldedaten
+
+Anmeldedaten, die noch von Datensätzen genannt werden, können weder gelöscht noch umbenannt werden, da diese sonst ins Leere zeigen würden.
+Die Ablehnung nennt, wie viele Datensätze sie verwenden; der Tab **Verwendet von** [ihrer Seite](credentials/credential-page.html) listet sie auf.
+Richten Sie diese zuerst auf andere Anmeldedaten und löschen oder benennen Sie sie dann um.
diff --git a/i18n/de/_configure/credentials/credential-page.md b/i18n/de/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..610a946
--- /dev/null
+++ b/i18n/de/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "Die Seite eines Anmeldedaten-Eintrags"
+parent: Anmeldedaten
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# Die Seite eines Anmeldedaten-Eintrags
+{: .no_toc }
+
+Die Tabs eines Eintrags und was ihn verwendet
+{: .fs-6 .fw-300 }
+
+Die Seite eines Anmeldedaten-Eintrags zeigt die Schritte seines Dialogs als Tabs, dazu was ihn verwendet:
+
+| Tab | Was er enthält |
+|---|---|
+| Details | Name und Beschreibung. |
+| Typ | Wofür die Anmeldedaten sind. |
+| Anmeldung | Jedes Feld seines Typs, wie im Schritt **Anmeldung** des Dialogs: der Benutzer, das Passwort und wo er sich anmeldet (Host und Port, die Datenbank, der Mail-Server, die Server des Verzeichnisses, der Tenant oder Issuer, die Adresse des Servers und sein TLS). Bei CyberArk-Anmeldedaten AppID, Client-Zertifikat und Schlüssel. |
+| Speicher | Datenbank oder Secret Store sowie der Store und die Referenz. Nicht für CyberArk und HashiCorp Vault. |
+| Verwendet von | Alles, was diese Anmeldedaten nennt: Secret Stores, Benachrichtigungskanäle, Repositories, LDAP-Verzeichnisse, SSO-Anbieter, Runner, der Chat-Assistent, Formulare und die Workflows des Designers. Eine Zeile öffnet das Element. |
+
+Das Passwort wird im Tab **Anmeldung** eingegeben und nach dem Speichern nie wieder angezeigt: Leer gelassen bleibt das gespeicherte erhalten. Bei CyberArk-Anmeldedaten
+lassen Sie den Client-Schlüssel leer, um den gespeicherten zu behalten. Oben rechts befinden sich **Verbindung testen** (nur bei Datenbank-Anmeldedaten),
+**Löschen** und **Speichern**.
+
+Ab 7.3.0 werden **Löschen** und ein neuer Name abgewiesen, solange **Verwendet von** etwas auflistet, siehe [Verwendete Anmeldedaten](../credentials.html#credentials-in-use).
+
+Im [Config-Seed](../seed/) deklarierte Anmeldedaten sind auf dieser Seite schreibgeschützt: Ändern Sie sie stattdessen in der Seed-Datei.
diff --git a/i18n/de/_configure/credentials/list.md b/i18n/de/_configure/credentials/list.md
new file mode 100644
index 0000000..8dd7fde
--- /dev/null
+++ b/i18n/de/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Die Seite Anmeldedaten
+parent: Anmeldedaten
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# Die Seite Anmeldedaten
+{: .no_toc }
+
+Die Liste der Anmeldedaten und der Dialog, der einen Eintrag hinzufügt
+{: .fs-6 .fw-300 }
+
+Die Seite unter **Verbindungen > Anmeldedaten** listet alle Anmeldedaten mit **Name**, **Typ**, **Beschreibung** und **Verwendet von** auf, der
+Anzahl der Datensätze, Formulare und Workflows, die sie nennen (siehe [Verwendete Anmeldedaten](../credentials.html#credentials-in-use)).
+
+**Anmeldedaten hinzufügen** öffnet einen Dialog in Schritten:
+
+| Schritt | Felder |
+|---|---|
+| Anmeldedaten | Name und Beschreibung, beide erforderlich. |
+| Typ | Einer von 18 Typen, siehe unten. |
+| Anmeldung | Womit und wo sich der Typ anmeldet, siehe unten. |
+| Speicher | Wo Benutzer und Passwort gespeichert werden: **Datenbank** (verschlüsselt in der AnsibleForms-Datenbank) oder **Secret Store**, mit dem Store und der **Referenz** darin. Nicht für CyberArk und HashiCorp Vault, mit denen sich ein Secret Store anmeldet. |
+
+Der Schritt **Typ** listet die Typen nach Namen auf: AAP, API, Ascender, AWX, CyberArk, Datenbank, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH sowie Benutzer und Passwort (siehe [Typen von Anmeldedaten](types.html)).
+
+Der Schritt **Anmeldung** enthält jedes Feld des Typs, die Adresse eingeschlossen; es gibt keinen eigenen Verbindungsschritt:
+
+| Typen | Felder des Schritts Anmeldung |
+|---|---|
+| Jeder Typ außer CyberArk | Das Passwort oder was dafür steht: das Bind-Passwort bei LDAP, das Client-Secret bei Entra ID und Open ID, das Token bei HashiCorp Vault, das RTE-Token, das API-Token bei Semaphore, Rundeck und Jenkins, ein Token oder Passwort bei AWX, AAP und Ascender |
+| Jeder Typ außer HashiCorp Vault, RTE, Semaphore und Rundeck | Der Benutzer: die AppID bei CyberArk, der Bind-DN bei LDAP, die Client-ID bei Entra ID und Open ID, optional bei AWX, AAP und Ascender |
+| SSH, Datenbank | **Host** und **Port**; bei einer Datenbank außerdem **Datenbanktyp** und **Datenbank** |
+| SMTP | **Mail-Server** (erforderlich), sein **Port** und **TLS verwenden** |
+| LDAP | Die **Server** des Verzeichnisses (erforderlich), sein **Port** und **TLS aktivieren**; mit TLS **Zertifikate ignorieren**, das **CA-Bundle** und ein **Client-Zertifikat** |
+| Microsoft Entra ID | **Tenant-ID** (erforderlich) und **Umleitungs-URI** |
+| Open ID | **Issuer** (erforderlich) und **Umleitungs-URI** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Server**, die Adresse, bei der er sich anmeldet, erforderlich, mit **Zertifikatsprüfung überspringen** und dem **CA-Bundle** |
+| CyberArk | **Client-Zertifikat** und **Client-Schlüssel** |
+
+Eine Zeile öffnet die eigene Seite des Eintrags. Ihr Menü bietet **Bearbeiten**, **Verbindung testen** (nur bei Datenbank-Anmeldedaten) und **Löschen**. Das
+Passwort wird auf der Seite des Eintrags geändert, in seinem Tab **Anmeldung**.
diff --git a/i18n/de/_configure/credentials/types.md b/i18n/de/_configure/credentials/types.md
new file mode 100644
index 0000000..409f20f
--- /dev/null
+++ b/i18n/de/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Typen von Anmeldedaten
+parent: Anmeldedaten
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Typen von Anmeldedaten
+{: .no_toc }
+
+Was jeder Typ enthält und wo er gewählt werden kann
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Typen
+
+Der Typ sagt, wofür Anmeldedaten sind. Er bestimmt, welche Felder der Dialog abfragt und wo sie gewählt werden können:
+
+| Typ | Was er enthält | Verwendet von |
+|---|---|---|
+| Benutzer und Passwort | Benutzer und Passwort für eine beliebige Anmeldung: eine REST-API mit Basic Auth, ein Dienst und mehr. Der Standard | Playbooks, über die `credentials` eines Formulars oder ein Anmeldedaten-Feld; [REST-Ausdrücke](../expressions/credentials.html) |
+| SSH | Benutzer und Passwort für SSH zu einem Server, mit seinem Host und Port | Playbooks, über die `credentials` oder `ansibleCredentials` eines Formulars oder ein Anmeldedaten-Feld, und die Anmeldung eines Workflow-Knotens |
+| Git | Benutzer und Passwort oder Token für Git-Repositories | [Repositories](../repositories/authentication.html) |
+| API | Benutzer und Passwort oder Token für eine REST-API | [REST-Ausdrücke](../expressions/credentials.html), ein Telegram-Bot-Token, das Bearer-Token eines Webhooks, der API-Schlüssel des Chat-Assistenten |
+| Datenbank | Eine Datenbankanmeldung, mit Typ, Host, Port und Datenbankname | Formularabfragen (`dbConfig`) und `fnCredentials`; lässt sich testen |
+| CyberArk | Die Adresse des CyberArk Central Credential Provider (CCP) und sein TLS sowie AppID, Client-Zertifikat und Schlüssel, mit denen sich ein CyberArk-Store anmeldet | Ein [CyberArk](../secret-stores/cyberark.html)-Secret-Store |
+| SMTP | Ein Mailserver, sein Port und TLS und seine Anmeldung (keine für ein Relay) | Ein Mail-[Benachrichtigungskanal](../notification-channels.html) |
+| LDAP | Server, Port, TLS und Zertifikate eines Verzeichnisses sowie sein Bind-DN und Passwort | Ein [LDAP-Verzeichnis](../authentication/ldap.html) |
+| Microsoft Entra ID | Die App-Registrierung eines Anbieters: Tenant-ID, Client-ID, Client-Secret und Umleitungs-URI | Ein [Entra ID-Anbieter](../authentication/entra-id.html) |
+| Open ID | Der Client eines Anbieters: Issuer, Client-ID, Client-Secret und Umleitungs-URI | Ein [OIDC-Anbieter](../authentication/oidc.html) |
+| RTE | Das Token (`RTE_TOKEN`) und die Adresse einer RTE | Ein RTE-[Runner](../runners.html) |
+| AWX, AAP, Ascender | Das Token oder die Anmeldung und die Adresse dieser Plattform | Ein Runner dieses Typs |
+| Semaphore, Rundeck | Das API-Token und die Adresse dieses Produkts | Ein Runner dieses Typs |
+| Jenkins | Ein Benutzer, sein API-Token und die Adresse eines Jenkins | Ein Jenkins-Runner |
+| HashiCorp Vault | Das Token und die Adresse, mit denen sich ein Vault-Store anmeldet | Ein [HashiCorp Vault](../secret-stores/hashicorp-vault.html)-Secret-Store |
+
+Datenbank-Anmeldedaten können vom Typ MySQL, MSSQL, PostgreSQL, Oracle oder MongoDB sein.
+
+In der API und im [Config-Seed](../seed/) heißen die Typen `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` und `vault`. Das Upgrade von 6
+gibt allen Anmeldedaten den Typ `userpass`, oder `database` für Datenbank-Anmeldedaten: Ein Formular verwendet sie wie in 6. Ändern Sie ihn auf SSH für eine
+Anmeldung, mit der sich das Playbook eines Workflow-Knotens verbindet, oder auf API für eine REST-API.
+
+---
+
+## Adressen in Anmeldedaten
+
+Ab 7.3.0 trägt eine Anmeldung, die auf einem Server funktioniert, diesen Server mit sich, sodass der Datensatz, der sie verwendet, nur die Anmeldedaten nennt:
+
+| Datensatz | Was in seine Anmeldedaten verschoben wurde |
+|---|---|
+| Ein LDAP-Verzeichnis | Server, Port, TLS, Zertifikate und Bind-Konto, in `ldap`-Anmeldedaten namens `<directory>-ldap` |
+| Ein SSO-Anbieter | Client-ID und Secret, Tenant oder Issuer sowie Umleitungs-URI, in `entraid`- oder `oidc`-Anmeldedaten namens `<provider>-sso` |
+| Ein Runner | Adresse und TLS sowie Token oder Anmeldung, in Anmeldedaten seines Typs, `<runner>-token` oder `<runner>-login` |
+| Ein Secret Store | Adresse und TLS sowie Token (`<store>-token`) oder CyberArk-AppID und Zertifikat (`<store>-appid`) |
+| Ein Mail-Kanal | Server, Port und TLS, in seine `smtp`-Anmeldedaten oder neue namens `<channel>-smtp` |
+
+Das Upgrade auf 7.3.0 nimmt diese Verschiebungen einmal vor. Ein Datensatz, der bereits Anmeldedaten nannte, behält sie und erhält eine Kopie davon, wenn
+ein anderer Datensatz dieselbe Anmeldung mit einem anderen Server verwendete. Im [Config-Seed](../seed/) deklarierte Datensätze bleiben so, wie der Seed sie hat.
+Die Anmeldedaten der Verbindungen und Anmeldungen können nur von einem Admin geändert werden, siehe [Wer Anmeldedaten ändern darf](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/de/_configure/customization/configuration.md b/i18n/de/_configure/customization/configuration.md
new file mode 100644
index 0000000..11f36f7
--- /dev/null
+++ b/i18n/de/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Konfiguration
+parent: Umgebungsvariablen
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Konfiguration
+{: .no_toc }
+
+Der Config-Seed, wo die Konfiguration gespeichert wird, Git und ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um festzulegen, woher die Konfiguration kommt: aus einem Config-Seed, der Datenbank, Git oder ytt-Templates.
+
+---
+
+## Beispiel
+
+Einen eingehängten Config-Seed anwenden, ihn alle fünf Minuten prüfen und `config.yaml` in der Datenbank halten. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Ein ungültiger Seed verhindert den Start des Servers. Das Dateiformat finden Sie unter [Config-Seed](../seed/).
+
+---
+
+## Woher config.yaml gelesen wird
+
+Die Kategorien, Rollen und Konstanten kommen aus `config.yaml` auf der Festplatte oder aus ihrer Kopie in der Datenbank, entschieden in dieser Reihenfolge:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), wenn sie gesetzt ist, in der Umgebung oder im
+   Tab **Konfiguration** der Einstellungsseite: `1` liest die Datenbank, `0` liest die Datei.
+2. Andernfalls die in der Datenbank gespeicherte Konfigurationsquelle (`file` oder `database`), die vor 6.3.0 eingerichtete
+   Instanzen auf der Einstellungsseite gewählt haben.
+3. Andernfalls die Datei: die `config.yaml` des Repositorys mit eingeschaltetem **Für Konfiguration verwenden**, sonst eines Repositorys mit
+   eingeschaltetem **Für Formulare verwenden**, sonst die unter [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Ein explizit gesetztes `ENABLE_CONFIG_IN_DATABASE` gewinnt immer, sogar `0` gegenüber einem gespeicherten `database`. Es wird bei jedem Laden der
+Konfiguration gelesen, daher gilt eine Änderung ohne Neustart. Die Seite **Status** zeigt die verwendete Quelle im Tab **Informationen**.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/de/_configure/customization/features.md b/i18n/de/_configure/customization/features.md
new file mode 100644
index 0000000..a597fce
--- /dev/null
+++ b/i18n/de/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Funktionen
+parent: Umgebungsvariablen
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Funktionen
+{: .no_toc }
+
+Der Designer, MCP, Chat, Startvalidierung, die Jobliste, Metriken, die AWX-API und Abfrageprotokollierung
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um optionale Teile der Anwendung ein- oder auszuschalten.
+
+---
+
+## Beispiel
+
+Den MCP-Server für KI-Agenten bereitstellen und die Validierungsregeln der Formulare bei jedem Start erzwingen. In der `.env` des Compose-Projekts:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` und `ENABLE_CHAT` gelten ohne Neustart: Sie werden bei jeder Anfrage gelesen, daher können Sie sie auf der
+Einstellungsseite umschalten. Solange eine davon aus ist, antwortet ihr Endpunkt (`/api/v2/mcp` oder `/api/v2/chat`) mit `404`.
+
+Lassen Sie zunächst eine Weile `LAUNCH_VALIDATION=log` laufen: Es protokolliert, was `enforce` abweisen würde, ohne es abzuweisen. Siehe [MCP](../mcp/)
+und [Protokollieren und erzwingen](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/de/_configure/customization/index.md b/i18n/de/_configure/customization/index.md
new file mode 100644
index 0000000..6d19b4a
--- /dev/null
+++ b/i18n/de/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Umgebungsvariablen
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Umgebungsvariablen
+{: .no_toc }
+
+AnsibleForms mit Umgebungsvariablen konfigurieren
+{: .fs-6 .fw-300 }
+
+---
+
+Für Administratoren, die AnsibleForms bereitstellen: die Umgebungsvariablen, die der Server liest, nach Themen gruppiert.
+
+AnsibleForms wird über Umgebungsvariablen eingestellt, ob es mit Docker Compose, auf Kubernetes oder aus dem Quellcode läuft.
+
+---
+
+## Woher die Werte kommen
+
+Der Server liest jede Variable aus der ersten dieser Quellen, die sie setzt; ein weiter oben stehender Wert gewinnt also immer:
+
+1. **Die Prozessumgebung**: `environment:` und `env_file:` in docker-compose (die `.env` des Projekts wird so übergeben),
+   `env` und `envFrom` auf Kubernetes oder die Shell, die `node` startet.
+2. **`persistent/.env`**, die Datei, die die Einstellungsseiten schreiben (`data/.env` im docker-compose-Projekt, ein anderer Pfad mit
+   `MANAGED_ENV_PATH`). Sie wird bei jedem Start gelesen, auch in Produktion, und überschreibt nie eine bereits gesetzte Variable.
+3. **`server/.env.<NODE_ENV>`**, zum Beispiel `.env.development`. Wird nur gelesen, wenn `NODE_ENV` nicht `production` ist (oder mit
+   `FORCE_DOTENV=1`), in der Praxis beim Betrieb [aus dem Quellcode](../installation/from-source.html) im Entwicklungsmodus.
+4. **Der integrierte Standardwert**, in den Tabellen jeder Gruppe angegeben.
+
+Die Einstellungsseiten unter **Einstellungen > Allgemein** zeigen den geltenden Wert und speichern Änderungen in `persistent/.env`. Viele Variablen
+gelten, sobald sie gespeichert sind; die übrigen werden gespeichert, brauchen aber einen Neustart, und die Seite listet sie nach dem Speichern auf. Eine in
+der Prozessumgebung gesetzte Variable lässt sich dort nicht ändern: Die Seite zeigt sie als *In der Umgebung gesetzt und hier nicht änderbar.*
+Einige Variablen, etwa `ENCRYPTION_SECRET` und `ACCESS_TOKEN_SECRET`, können nie über die Seite geändert werden.
+
+Die Variablen, die eine RTE liest, etwa `AF_ROLE`, `RTE_MODE`, `APP_URL` oder `RTE_MAX_JOBS`, stehen gar nicht auf den Einstellungsseiten: Die
+App verwendet sie nicht, setzen Sie sie daher in der Umgebung, in der die RTE läuft. Die `RTE_*`-Variablen, die die App selbst liest,
+`RTE_QUEUE_MINUTES` und `RTE_FILES_MAX_MB`, sind die Ausnahme und bleiben auf den Seiten. Vier RTE-Variablen, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` und `RTE_DRAIN_SECONDS`, lassen sich stattdessen pro RTE auf ihrer Runner-Seite setzen, wo ein Wert die
+Variable übertrifft (siehe [Die Einstellungen einer RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Mit [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` zeigen die Seiten die Werte nur an, und das Speichern wird abgewiesen. Verwenden Sie das,
+wenn die Umgebung in einem Manifest deklariert ist, wie unter [Bearbeitung und Audit](../seed/environment-and-audit.html) beschrieben.
+
+Der [Config-Seed](../seed/) setzt keine Umgebungsvariablen. Er deklariert Objekte, die in der Datenbank gespeichert werden, und die
+`${ENV_VAR}`-Verweise darin werden aus der Umgebung des laufenden Servers aufgelöst.
+
+Einige Variablen werden nur aus der Umgebung gelesen und stehen nicht in den Tabellen: `MANAGED_ENV_PATH` und `FORCE_DOTENV`, oben
+beschrieben, sowie die System-Proxy-Variablen `HTTPS_PROXY` und `NO_PROXY` (auch in Kleinschreibung gelesen). Eine ausgehende RTE wählt sich über
+`HTTPS_PROXY` bei der App ein, und eine eingehende RTE sendet ihren Registrierungsaufruf darüber, es sei denn, der Host der App steht in `NO_PROXY` (Hostnamen,
+`.domain`-Suffixe oder `*` für jeden Host).
+
+Mit <span class="af-badge af-badge-secret">Secret</span> markierte Variablen enthalten ein Passwort, Token oder einen Schlüssel: Halten Sie sie aus der
+Versionsverwaltung heraus, zum Beispiel in einem Kubernetes-Secret oder einer `.env`-Datei, die nicht committet wird.
+
+---
+
+## In diesem Abschnitt
+
+Die Variablen sind nach Themen gruppiert, mit einer Seite pro Gruppe:
+
+| Seite | Inhalt |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Weitere Variablen
+
+Die folgenden Variablen sind noch keiner Gruppe zugeordnet:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/de/_configure/customization/logging.md b/i18n/de/_configure/customization/logging.md
new file mode 100644
index 0000000..8feffe3
--- /dev/null
+++ b/i18n/de/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Protokollierung
+parent: Umgebungsvariablen
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Protokollierung
+{: .no_toc }
+
+Protokollebenen, Dateien, Syslog und Konsolenfarben
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um festzulegen, wie viel protokolliert wird, wohin die Protokolldateien gehen, oder um Zeitstempel in Ihrer eigenen Zeitzone anzuzeigen.
+
+---
+
+## Beispiel
+
+In den Dateien mehr protokollieren als auf der Konsole und Protokoll- und Job-Zeitstempel in Amsterdamer Zeit anzeigen.
+In der `.env` des Compose-Projekts:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Syslog-Server werden nicht mehr hier konfiguriert: Fügen Sie sie unter **Einstellungen > Verbindungen > Syslog** hinzu, siehe [Protokolle](../production/logs.html#syslog).
+Die Variablen `LOG_SYSLOG_*` unten sind seit 7 veraltet. Der erste Start, der `LOG_SYSLOG_HOST` gesetzt vorfindet, importiert sie
+einmal als Syslog-Server `syslog`, der das Serverprotokoll empfängt, und ignoriert sie danach.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/de/_configure/customization/paths.md b/i18n/de/_configure/customization/paths.md
new file mode 100644
index 0000000..fe650c7
--- /dev/null
+++ b/i18n/de/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Pfade
+parent: Umgebungsvariablen
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Pfade
+{: .no_toc }
+
+Wo Konfiguration, Formulare, Playbooks, Uploads und Backups liegen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um einen Teil der Daten auf einem anderen Volume zu halten, zum Beispiel Backups und Uploads auf größerem oder günstigerem Speicher.
+
+---
+
+## Beispiel
+
+Backups und hochgeladene Dateien auf einem eigenen Volume, die übrigen Daten im üblichen persistenten Ordner. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Ein neuer Pfad gilt nur für neue Dateien: Was bereits im alten Ordner liegt, wird nicht verschoben, kopieren Sie es also selbst hinüber.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/de/_configure/customization/retention.md b/i18n/de/_configure/customization/retention.md
new file mode 100644
index 0000000..d1c00cc
--- /dev/null
+++ b/i18n/de/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Backups und Aufbewahrung
+parent: Umgebungsvariablen
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Backups und Aufbewahrung
+{: .no_toc }
+
+Die Backup-Befehle und wie lange Backups, Jobs und Audit-Einträge aufbewahrt werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um zu steuern, wie viel Verlauf die Datenbank behält und wie viele Backups auf der Festplatte bleiben.
+
+---
+
+## Beispiel
+
+Abgeschlossene Jobs 90 Tage und den Audit-Verlauf zwei Jahre lang aufbewahren. In der `.env` des Compose-Projekts:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Eine tägliche Aufgabe entfernt um 2:30 Uhr abgeschlossene Jobs, die älter sind, und um 3:30 Uhr Audit-Einträge. Ein laufender Job oder einer, der auf
+Freigabe wartet, wird nie entfernt. Beide Variablen gelten ohne Neustart, wenn sie auf der Einstellungsseite geändert werden.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/de/_configure/customization/security.md b/i18n/de/_configure/customization/security.md
new file mode 100644
index 0000000..97c9fb1
--- /dev/null
+++ b/i18n/de/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Sicherheitsvariablen
+parent: Umgebungsvariablen
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Sicherheitsvariablen
+{: .no_toc }
+
+Token, Verschlüsselung, ausgehende REST-Hosts, Maskierung und die alten VAULT_*-Einstellungen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, um eigene Token- und Verschlüsselungsgeheimnisse zu setzen und einzuschränken, was Formulare aufrufen und anzeigen dürfen.
+
+---
+
+## Beispiel
+
+Eigene Geheimnisse, REST-Aufrufe auf eine API und ein internes Netz beschränkt und ein weiterer maskierter Schlüssel. In der `.env` des Compose-Projekts:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Setzen Sie `ENCRYPTION_SECRET`, bevor die ersten Anmeldedaten gespeichert werden. Ab 7.3.0 verschlüsselt das Setzen oder Ändern beim nächsten Start jedes gespeicherte
+Geheimnis neu, wobei `ENCRYPTION_SECRET_PREVIOUS` den alten Schlüssel nennt, wenn es Ihr eigener war, siehe
+[Das Verschlüsselungsgeheimnis ändern](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## REST-Aufrufe und jq
+
+Ab 7.3.0 prüfen die REST-Hilfsfunktionen (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) das
+Zertifikat des aufgerufenen Endpunkts, wie jede andere Verbindung; bis 7.2.0 taten sie das nie. Drei Einstellungen gelten für sie:
+
+| Variable | Standard | Wirkung |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` überspringt die Zertifikatsprüfung: nur für Endpunkte mit selbstsigniertem Zertifikat |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Wie lange ein REST-Aufruf auf eine Antwort wartet, bevor er mit einer Zeitüberschreitung fehlschlägt |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Wie lange ein jq-Filter laufen darf, bevor er angehalten wird; die jq-Ausgabe ist außerdem auf 64 MB begrenzt |
+
+Alle drei gelten beim Speichern, ohne Neustart. Für einen Endpunkt, dessen Zertifikat von einer privaten CA signiert ist, lassen Sie die Prüfung eingeschaltet
+und geben Sie Node.js stattdessen diese CA: Setzen Sie `NODE_EXTRA_CA_CERTS` in der Umgebung der App auf eine PEM-Datei, die sie enthält, und starten Sie die App dann neu.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/de/_configure/customization/server.md b/i18n/de/_configure/customization/server.md
new file mode 100644
index 0000000..6b47116
--- /dev/null
+++ b/i18n/de/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Server und Datenbank
+parent: Umgebungsvariablen
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Server und Datenbank
+{: .no_toc }
+
+Der Webserver, die MySQL-Verbindung, das Admin-Konto und was jeder Prozess ausführt (AF_ROLE und die RTE_*-Variablen)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ändern Sie diese, wenn die Anwendung hinter einem Reverse Proxy, auf einem anderen Port oder gegen eine Datenbank außerhalb des Compose-Projekts läuft.
+
+---
+
+## Beispiel
+
+Hinter einem Reverse Proxy, der TLS terminiert, unter `/ansibleforms`, mit einem externen MySQL. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Diese ersetzen die Zeilen `DB_*` und `PORT`, die die Compose-Datei dort bereits hat und die über dieselben Namen in `.env` gewinnen. Entfernen Sie
+den Dienst `mysqldb` und das `depends_on`, das auf ihn wartet, und mappen Sie Port 8000 in `ports`. Die Proxy-Seite ist auf der Seite
+[Reverse Proxy](../production/reverse-proxy.html) beschrieben.
+
+---
+
+## Variablen
+
+Jede Variable dieser Gruppe, mit Typ, Standardwert und Beschreibung:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/de/_configure/disclaimer.md b/i18n/de/_configure/disclaimer.md
new file mode 100644
index 0000000..9c312f8
--- /dev/null
+++ b/i18n/de/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Haftungsausschluss
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Haftungsausschluss
+{: .no_toc }
+
+Bedingungen, die jeder Benutzer einmal akzeptiert, bevor er die App verwendet, samt Aufzeichnung, wer welche Version wann akzeptiert hat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Lassen Sie jeden Benutzer Nutzungsbedingungen akzeptieren, unter **Einstellungen > Zugriff > Haftungsausschluss**, mit der Rollenoption `showSettings`.
+
+Ab 7.3.0 listet die Seite jede Version des Haftungsausschlusses auf, und jede Version öffnet sich auf einer eigenen Seite mit ihren Zustimmungen.
+Bis 7.2 hatte die Seite stattdessen drei Tabs (**Allgemein**, **Versionen** und **Zustimmungen**); das Upgrade behält jede Version.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Allgemein](disclaimer/general.html) | Die Liste der Versionen, eine hinzufügen und die aktivieren, die Benutzer akzeptieren |
+| [Versionen](disclaimer/versions.html) | Die Seite einer Version und das Ändern ihres Textes als Korrektur oder erneut für alle |
+| [Zustimmungen](disclaimer/acceptances.html) | Wer welche Version akzeptiert hat, und ausgewählte Benutzer erneut fragen |
+
+
+---
+
+## Was Benutzer sehen
+
+Ist eine Version aktiviert, erhält jeder Benutzer, der sich anmeldet, sie vor allem anderen in einem Dialog, Admins eingeschlossen:
+
+1. Er liest ihren Titel und ihren Text.
+2. Er setzt das Häkchen im Kontrollkästchen und klickt dann auf **Akzeptieren**. **Ablehnen**, in Rot, meldet ihn stattdessen ab.
+
+Ab 7.3.0 ist die Seite hinter dem Dialog unscharf, bis er antwortet.
+
+Ein Benutzer akzeptiert jede Version einmal: Bei seiner nächsten Anmeldung wird er nicht erneut gefragt, sondern nur, wenn eine neue Version kommt, wenn
+ein Admin einen geänderten Text mit [Alle erneut fragen](disclaimer/versions.html#changing-the-text) speichert oder wenn ein Admin
+[Erneut anfragen](disclaimer/acceptances.html#asking-users-again) auf seine Zustimmung anwendet.
+
+Bis er akzeptiert, beantwortet die API jeden Aufruf seiner Sitzung mit dem Status `403` und dem Code `disclaimer_required`,
+außer den Aufrufen unter `/api/v2/disclaimer` und `/api/v2/profile` sowie den Live-Ereignissen, denen der Browser folgt.
+Ein [API-Token](profile/api-token.html) wird nie gefragt, da bei einem Skript niemand klicken kann.
+
diff --git a/i18n/de/_configure/disclaimer/acceptances.md b/i18n/de/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..abc3eef
--- /dev/null
+++ b/i18n/de/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Zustimmungen
+parent: Haftungsausschluss
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Zustimmungen
+{: .no_toc }
+
+Wer welche Version akzeptiert hat, und ausgewählte Benutzer erneut fragen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wer akzeptiert hat
+
+Jede Zustimmung wird für den Benutzer und die Version festgehalten, und der Tab **Zustimmungen** auf der Seite einer Version listet sie auf, die neueste zuerst:
+
+| Spalte | Bedeutung |
+|---|---|
+| **Benutzer** | Der Benutzername |
+| **Anmeldung** | Wie er sich angemeldet hat: Lokal, LDAP, Microsoft Entra ID oder OpenID Connect |
+| **Akzeptiert** | Wann |
+| **IP-Adresse** | Von wo |
+| **Browser** | Sein Browser |
+
+---
+
+## Benutzer erneut fragen
+
+Ab 7.3.0 lassen sich ausgewählte Benutzer bitten, eine Version erneut zu akzeptieren, ohne alle zu fragen.
+
+**Erneut anfragen** im Menü einer Zeile oder auf den in der Liste angehakten Zeilen löscht diese Zustimmungen nach einer Bestätigung: Diese Benutzer erhalten den
+Haftungsausschluss bei ihrer nächsten Anfrage erneut, ohne sich neu anzumelden. Die Liste lässt sich, wie jede Tabelle, auch exportieren.
+
+Das [Audit-Protokoll](../production/logs.html#audit-trail) hält außerdem jede Zustimmung, jede Ablehnung und jede Änderung des Haftungsausschlusses fest.
diff --git a/i18n/de/_configure/disclaimer/general.md b/i18n/de/_configure/disclaimer/general.md
new file mode 100644
index 0000000..f43f7b9
--- /dev/null
+++ b/i18n/de/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Allgemein
+parent: Haftungsausschluss
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Allgemein
+{: .no_toc }
+
+Die Liste der Versionen, eine hinzufügen und die aktivieren, die Benutzer akzeptieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Liste
+
+Ab 7.3.0 ist **Einstellungen > Zugriff > Haftungsausschluss** eine Liste der Versionen des Haftungsausschlusses, eine pro Text, so wie ihm zugestimmt wurde:
+
+| Spalte | Bedeutung |
+|---|---|
+| **Aktiviert** | Ob dies die Version ist, die Benutzer akzeptieren; höchstens eine ist aktiviert |
+| **Version** | Ihre Nummer, ab 1 hochgezählt |
+| **Titel** | Der Titel ihres Dialogs |
+| **Veröffentlicht von** | Wer sie hinzugefügt hat |
+| **Veröffentlicht** | Wann |
+| **Zustimmungen** | Wie viele Benutzer sie akzeptiert haben |
+
+Ein Klick auf eine Zeile oder **Bearbeiten** im Menü der Zeile öffnet die [Seite der Version](versions.html). Das Menü enthält außerdem **Aktivieren** oder **Deaktivieren** sowie **Löschen**.
+
+---
+
+## Eine Version hinzufügen
+
+**Hinweis hinzufügen** öffnet einen Dialog für eine neue Version mit der nächsten Nummer, die erst aktiviert ist, wenn Sie sie aktivieren:
+
+| Feld | Bedeutung |
+|---|---|
+| **Titel** | Der Titel des Dialogs, etwa Nutzungsbedingungen |
+| **Text** | Das, dem Benutzer zustimmen, höchstens 20000 Zeichen. Reiner Text: Zeilenumbrüche bleiben erhalten. |
+| **Kontrollkästchen** | Was Benutzer anhaken, bevor sie akzeptieren können, anfangs „Ich habe diese Bedingungen gelesen und stimme ihnen zu.“ |
+
+Alle drei sind erforderlich. Die bis dahin aktivierte Version bleibt die, die Benutzer akzeptieren, sodass sich ein neuer Text im Voraus vorbereiten lässt.
+
+---
+
+## Eine Version aktivieren
+
+**Aktivieren** im Menü einer Zeile oder der Schalter **Aktiviert** auf der Seite der Version macht diese Version zu der, die Benutzer akzeptieren, und schaltet die
+anderen aus.
+
+Benutzer, die diese Version bereits akzeptiert haben, werden nicht erneut gefragt, sodass sich eine frühere Version wieder aktivieren lässt, ohne alle zu fragen.
+**Deaktivieren** auf der aktivierten Version schaltet den Haftungsausschluss aus, bis wieder eine Version aktiviert wird; die Versionen und Zustimmungen bleiben erhalten.
+Das Löschen einer Version löscht auch ihre Zustimmungen, und das Löschen der aktivierten schaltet den Haftungsausschluss aus.
diff --git a/i18n/de/_configure/disclaimer/versions.md b/i18n/de/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..6eac374
--- /dev/null
+++ b/i18n/de/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versionen
+parent: Haftungsausschluss
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versionen
+{: .no_toc }
+
+Die Seite einer Version und das Ändern ihres Textes als Korrektur oder erneut für alle
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Seite einer Version
+
+Ab 7.3.0 hat jede Version eine eigene Seite, unter `/settings/disclaimer/<version>`, mit zwei Tabs:
+
+| Tab | Was er enthält |
+|---|---|
+| **Details** | Titel, Text und Text des Kontrollkästchens sowie den Schalter **Aktiviert**, der sofort gespeichert wird |
+| **Zustimmungen** | Wer diese Version akzeptiert hat, siehe [Zustimmungen](acceptances.html) |
+
+**Vorschau** zeigt den Dialog so, wie Benutzer ihn sehen werden, und **Löschen** entfernt die Version samt ihren Zustimmungen. Das Suchfeld über den
+Tabs durchsucht beide gleichzeitig: die passenden Felder unter **Details** und die passenden Zeilen unter **Zustimmungen**.
+
+---
+
+## Den Text ändern
+
+**Speichern** bei einem geänderten Titel, Text oder Text des Kontrollkästchens, den Benutzer bereits akzeptiert haben, fragt **Alle erneut fragen?**:
+
+| Antwort | Was passiert |
+|---|---|
+| **Alle erneut fragen** | Die Zustimmungen zu dieser Version werden gelöscht, und jeder Benutzer akzeptiert sie bei seiner nächsten Anfrage erneut |
+| **Als Korrektur behalten** | Der Text wird überschrieben, etwa wegen eines Tippfehlers, und die Zustimmungen zählen weiterhin: Niemand wird erneut gefragt |
+
+Eine Version, die noch niemand akzeptiert hat, wird ohne Nachfrage gespeichert. Um den vereinbarten Text zu behalten, [fügen Sie eine neue Version hinzu](general.html#adding-a-version) und aktivieren Sie sie.
diff --git a/i18n/de/_configure/notification-channels.md b/i18n/de/_configure/notification-channels.md
new file mode 100644
index 0000000..c54f8eb
--- /dev/null
+++ b/i18n/de/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Benachrichtigungskanäle
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Benachrichtigungskanäle
+{: .no_toc }
+
+Genehmigungsanfragen und Job-Benachrichtigungen per Mail, an Slack, Microsoft Teams, Telegram oder einen beliebigen Webhook senden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Fügen Sie die Mailserver und Chat-Kanäle hinzu, an die Formulare ihre Benachrichtigungen und Genehmigungen senden.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Mail](notification-channels/mail.html) | SMTP-Server, der Standardserver und ihre Anmeldung |
+| [Slack und Microsoft Teams](notification-channels/slack-and-teams.html) | Ein Kanal-Webhook von Slack oder Teams |
+| [Telegram](notification-channels/telegram.html) | Ein Bot, der in einem Telegram-Chat postet |
+| [Webhook](notification-channels/webhook.html) | Eine JSON-Anfrage an einen beliebigen HTTP-Endpunkt |
+| [Kanäle in einem Formular verwenden](notification-channels/in-a-form.html) | Kanäle in Benachrichtigungen und Genehmigungen nennen |
+| [Einen Kanal testen](notification-channels/testing.html) | Test senden und was er beweist |
+
+
+---
+
+## Funktionsweise
+
+Ein **Benachrichtigungskanal** ist ein Ziel für Benachrichtigungen, angelegt unter **Verbindungen > Benachrichtigungen**. Jeder Kanal hat
+einen dieser Typen:
+
+| Typ | Was er sendet |
+|---|---|
+| Mail | Mail über einen SMTP-Server: Genehmigungsanfragen und Job-Benachrichtigungen. |
+| Slack | Eine Nachricht in einem Slack-Kanal, über seinen eingehenden Webhook, mit einer Schaltfläche zum Job. |
+| Microsoft Teams | Eine Karte in einem Teams-Kanal, über einen Workflows-Webhook, mit einer Schaltfläche zum Job. |
+| Telegram | Eine Nachricht eines Bots in einem Telegram-Chat, mit einem Link zum Job. |
+| Webhook | Eine JSON-Anfrage an einen beliebigen HTTP-Endpunkt, aus einem Template erzeugt. |
+
+Ein Formular nennt seine Kanäle in seinen [Benachrichtigungen](forms/notifications.html) und seiner [Genehmigung](forms/approval.html),
+mit `channels:`. Eine Benachrichtigung, die nicht gesendet werden kann, wird ins Protokoll geschrieben; sie lässt nie den Job oder die Genehmigung fehlschlagen.
+
+---
+
+## Die Seite Benachrichtigungen
+
+Die Seite unter **Verbindungen > Benachrichtigungen** listet jeden Kanal mit diesen Spalten auf:
+
+| Spalte | Bedeutung |
+|---|---|
+| Aktiviert | Ob Benachrichtigungen an ihn gesendet werden, siehe [Kanäle in einem Formular verwenden](notification-channels/in-a-form.html). |
+| Name | Wie Formulare in `channels:` auf ihn verweisen. |
+| Typ | Mail, Slack, Microsoft Teams, Telegram oder Webhook. Der Standard-Mail-Kanal zeigt nach seinem Typ eine Pille **Standard**. |
+| Beschreibung | Wofür der Kanal ist. |
+
+**Benachrichtigungskanal hinzufügen** öffnet einen Dialog: **Kanal** (Name und Beschreibung), **Typ**, dann die Schritte des gewählten
+Typs. Der Typ wird beim Anlegen des Kanals festgelegt und bleibt so. Eine Zeile öffnet die eigene Seite des Kanals, mit denselben Schritten als
+Tabs nach **Details**, und **Test senden**, **Löschen** und **Speichern** oben rechts. Das Menü der Zeile bietet
+**Bearbeiten**, **Aktivieren** oder **Deaktivieren** (je nachdem, was zutrifft), **Als Standard festlegen** (Mail), **Test senden** und **Löschen**.
+
+Der Tab **Details** der Seite eines Kanals enthält den Schalter **Aktiviert**, der sofort gespeichert wird, und bei Mail den Schalter **Standard**,
+der mit **Speichern** gespeichert wird.
+
+Ein Benutzer, der diese Seiten mit `showConnectionsSettings`, aber ohne die Rolle admin öffnet, kann keine Anmeldedaten wählen, die nur
+ein Admin nennen darf, siehe [Wer Anmeldedaten ändern darf](credentials.html#who-may-change-a-credential). Ändert ein solcher Benutzer,
+wohin ein Kanal sendet (die URL eines Webhooks oder seine Zertifikatsprüfung, eine Telegram-Bot-API-Adresse), verliert der Kanal die
+Anmeldedaten, die er nannte, es sei denn, der Benutzer wählt in derselben Änderung neue.
+
+Ein im [Config-Seed](seed/) deklarierter Kanal ist auf dieser Seite schreibgeschützt und lässt sich trotzdem testen.
+
diff --git a/i18n/de/_configure/notification-channels/in-a-form.md b/i18n/de/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..51b89ec
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Kanäle in einem Formular verwenden
+parent: Benachrichtigungskanäle
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Kanäle in einem Formular verwenden
+{: .no_toc }
+
+Kanäle in Benachrichtigungen und Genehmigungen nennen
+{: .fs-6 .fw-300 }
+
+Formulare nennen Kanäle über ihren Namen, in `notifications` für Jobstatus und Job-Ereignisse und in `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- Die Chat- und Webhook-Kanäle erhalten eine kurze Nachricht (das Formular, der Job, was passiert ist) mit einem Link zum Job; bei einer
+  Genehmigung ist die Seite des Jobs der Ort, an dem genehmigt oder abgelehnt wird.
+- Ein **Mail**-Kanal in der Liste sendet die übliche Mail an `recipients` (die `notifications`-Adressen einer Genehmigung) über
+  diesen Server statt über den Standardserver.
+- Ein Name, der nicht existiert, oder ein ausgeschalteter Chat- oder Webhook-Kanal wird übersprungen, und das Protokoll vermerkt es.
+- Ein ausgeschalteter **Mail**-Kanal wird nicht übersprungen: Die Mail geht stattdessen über den Standard-Mail-Kanal, und das
+  Protokoll vermerkt es.
diff --git a/i18n/de/_configure/notification-channels/mail.md b/i18n/de/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..70f148e
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Mail
+parent: Benachrichtigungskanäle
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Mail
+{: .no_toc }
+
+SMTP-Server, der Standardserver und ihre Anmeldung
+{: .fs-6 .fw-300 }
+
+Ein Mail-Kanal ist ein SMTP-Server. Sie können mehrere haben; der mit **Standard** markierte ist der Server, über den die App ihre
+Mails sendet, wenn ein Formular keinen Mail-Kanal nennt. Der erste Mail-Kanal wird zum Standard, und **Als Standard festlegen** verschiebt das.
+
+| Schritt | Feld | Bedeutung |
+|---|---|---|
+| Anmeldedaten | Anmeldedaten-Eintrag | Erforderlich. Ein **smtp**-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html): der Mailserver, sein Port und TLS und die Anmeldung. Für ein Relay ohne Anmeldung ein smtp-Eintrag ohne Benutzer. |
+| Absender | Mail-Absender | Die Absenderadresse, die Empfänger sehen. |
+
+Der Schalter **Standard** im Tab **Details** der Seite eines Mail-Kanals macht ihn zum Standard, wie **Als Standard festlegen**.
+Die Mail-Einstellungen des Config-Seeds werden verwendet, solange kein Mail-Kanal der Standard ist oder solange der Standardkanal ausgeschaltet ist.
diff --git a/i18n/de/_configure/notification-channels/slack-and-teams.md b/i18n/de/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..f013989
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack und Microsoft Teams
+parent: Benachrichtigungskanäle
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack und Microsoft Teams
+{: .no_toc }
+
+Ein Kanal-Webhook von Slack oder Teams
+{: .fs-6 .fw-300 }
+
+Slack- und Teams-Kanäle brauchen nur die Adresse des Webhooks des Kanals:
+
+| Typ | Webhook-Adresse |
+|---|---|
+| Slack | Der eingehende Webhook des Kanals (Slack-App > Incoming Webhooks). |
+| Microsoft Teams | Der Workflows-Webhook des Kanals („post to a channel when a webhook request is received“). |
+
+Die Adresse ist das Geheimnis, mit dem jeder in den Kanal posten kann: Sie wird verschlüsselt gespeichert und nach dem Speichern nie wieder angezeigt.
diff --git a/i18n/de/_configure/notification-channels/telegram.md b/i18n/de/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..4631b5f
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Benachrichtigungskanäle
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Ein Bot, der in einem Telegram-Chat postet
+{: .fs-6 .fw-300 }
+
+Ein Telegram-Kanal ist ein Bot, der in einem Chat postet. Sein Schritt **Anmeldedaten** enthält das **Bot-Token**, sein Schritt **Bot** den Rest:
+
+| Feld | Bedeutung |
+|---|---|
+| Bot-Token | Ein **api**-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html), dessen Passwort das Bot-Token von BotFather ist. |
+| Chat-ID | Der Chat, die Gruppe oder der Kanal, in dem der Bot postet; eine negative Zahl bei einer Gruppe oder einem Kanal. |
+| Bot-API-Adresse | Ein eigener Bot-API-Server; leer für `api.telegram.org`. |
diff --git a/i18n/de/_configure/notification-channels/testing.md b/i18n/de/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..0b297f0
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Einen Kanal testen
+parent: Benachrichtigungskanäle
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Einen Kanal testen
+{: .no_toc }
+
+Test senden und was er beweist
+{: .fs-6 .fw-300 }
+
+**Test senden** sendet eine Testbenachrichtigung über den Kanal, wie er gespeichert ist; speichern Sie Ihre Änderungen also zuerst. Es funktioniert auch bei einem
+ausgeschalteten Kanal. Bei einem Mail-Kanal
+fragt der Dialog nach der Zieladresse; die anderen posten in ihren eigenen Kanal. Der Dialog zeigt, ob es funktioniert hat,
+und den Grund, wenn nicht.
diff --git a/i18n/de/_configure/notification-channels/webhook.md b/i18n/de/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..88c26eb
--- /dev/null
+++ b/i18n/de/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Benachrichtigungskanäle
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Eine JSON-Anfrage an einen beliebigen HTTP-Endpunkt
+{: .fs-6 .fw-300 }
+
+Ein Webhook-Kanal sendet eine JSON-Anfrage an einen beliebigen HTTP-Endpunkt. Sein Schritt **Endpunkt** sagt, wohin und wie, und sein
+Schritt **Anmeldedaten** enthält das **Bearer-Token**:
+
+| Feld | Bedeutung |
+|---|---|
+| Url | Die Adresse, an die die Anfrage gesendet wird. |
+| Methode | `POST` (Standard) oder `PUT`. |
+| Bearer-Token | Ein **api**-Eintrag aus [Verbindungen > Anmeldedaten](../credentials.html), dessen Passwort als `Authorization: Bearer <password>` gesendet wird. Leer: kein Token. |
+| TLS-Zertifikat prüfen | Standardmäßig ein; schalten Sie es nur für einen Endpunkt mit selbstsigniertem Zertifikat aus. |
+
+{% raw %}
+Sein Schritt **Inhalt** enthält die **Header**, zusätzliche Header als JSON-Objekt wie `{ "X-Source": "ansibleforms" }`, und den
+**Inhalt**, das JSON-Template des Bodys. Diese Platzhalter werden ausgefüllt:
+
+| Platzhalter | Wert |
+|---|---|
+| `{{title}}` | Der Titel der Benachrichtigung |
+| `{{text}}` | Ihr Text |
+| `{{status}}` | Der Jobstatus |
+| `{{event}}` | Das Job-Ereignis |
+| `{{jobId}}` | Die Job-ID |
+| `{{form}}` | Der Formularname |
+| `{{user}}` | Der Benutzer, der den Job gestartet hat |
+| `{{link}}` | Der Link zum Job |
+
+Ein Platzhalter, der einen ganzen JSON-String bildet (`"{{text}}"`), wird durch den Wert als JSON ersetzt; innerhalb eines längeren Strings wird sein
+Text für JSON maskiert. Ein unbekannter Platzhalter bleibt, wie er geschrieben ist. Ein leerer Inhalt sendet dieses Template:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/de/_configure/production/backups.md b/i18n/de/_configure/production/backups.md
new file mode 100644
index 0000000..0796f4b
--- /dev/null
+++ b/i18n/de/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Backups
+parent: Betrieb in Produktion
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Backups
+{: .no_toc }
+
+Nächtliche Backups, was sie enthalten, Wiederherstellungen und was sonst noch zu sichern ist
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Nächtliche Backups
+
+AnsibleForms sichert sich jede Nacht um Mitternacht selbst, in der Zeitzone von [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(standardmäßig UTC). Diese Einstellungen steuern das:
+
+| Variable | Standard | Bedeutung |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Wohin Backups geschrieben werden, jeweils ein Ordner mit Zeitstempel |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Wie viele nächtliche Backups aufbewahrt werden, `0` behält alle |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | Der Befehl, der die Datenbank dumpt |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | Der Befehl, der bei der Wiederherstellung einen Dump einspielt |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Wie lange Dump und Wiederherstellung laufen dürfen |
+
+Benutzer mit der Rollenoption `allowBackupOps` können auf der Seite **Backups** auch jederzeit ein Backup erstellen. Nur nächtliche
+Backups werden von der Aufbewahrung entfernt, und nur Backups mit einem brauchbaren Dump zählen dazu, sodass eine Reihe fehlgeschlagener
+Nächte nie das letzte gute Backup verdrängt.
+
+Bevor ein Upgrade die Datenbank ändert, erstellt der Worker zuerst ein reguläres Backup, einmal pro Release, namens *Before the upgrade to
+&lt;version&gt;*. Es erscheint auf der Seite **Backups** und wird nie von der nächtlichen Aufbewahrung entfernt. Schlägt es fehl (kein Dump-Werkzeug,
+`BACKUP_PATH` nicht beschreibbar), hält das Upgrade an und nennt den Grund, sodass die App nie auf einer halb aktualisierten Datenbank startet.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` führt das Upgrade ohne Backup durch.
+
+Die Befehle können Wrapper wie `docker exec <container> mysqldump` sein, sofern ihr erstes Wort lokal existiert. Ab 7.3.0 laufen sie
+ohne Shell: Anführungszeichen und `$NAME` aus der Umgebung des Befehls funktionieren, aber `;`, `|`, `&&`, `>` und `<` werden abgewiesen.
+
+---
+
+## Datenbankrechte
+
+Der Dump läuft als [`DB_USER`](../customization/server.html#env_DB_USER) und braucht keine weiteren Rechte als die Anwendung selbst:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Der Dump wird mit `--no-tablespaces` erstellt, daher ist das serverweite Recht `PROCESS` nicht nötig, und er überspringt die Tabellen,
+die die laufenden Prozesse beschreiben (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). Die Wiederherstellung spielt ihn als derselbe Benutzer ein.
+Die Seite **Status** zeigt bei ihrer Prüfung **Datenbankbenutzer** eine Warnung, wenn der Benutzer Rechte auf jede Datenbank hat, wie `root`.
+
+---
+
+## Was ein Backup enthält
+
+Jedes Backup ist ein Ordner unter `BACKUP_PATH`, benannt nach seinem UTC-Zeitstempel (`YYYYMMDDHHmmss`), und enthält:
+
+| Datei | Inhalt |
+|------|---------|
+| `ansibleforms.sql` | Den Dump der Datenbank `AnsibleForms`: Benutzer, Gruppen, Anmeldedaten, Jobs, Einstellungen, den Audit-Verlauf |
+| `config.yaml` | Die Datei unter [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | Den Ordner unter [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | Die Umgebungsdatei, die die Einstellungsseiten schreiben, ohne `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` und `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | Die Beschreibung des Backups |
+
+Ein Backup, dessen Dump fehlschlägt, wird wieder entfernt und als Fehler protokolliert. Die Seite **Status** warnt, wenn es kein Backup gibt,
+wenn das neueste älter als zwei Tage ist oder wenn es keinen brauchbaren Dump hat, und sie prüft, ob das Dump-Werkzeug existiert.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) bestimmt dagegen, wie lange die Wiederherstellungspunkte des Designers aufbewahrt werden (standardmäßig 60 Tage).
+
+---
+
+## Ein Backup wiederherstellen
+
+Stellen Sie über die [Seite **Backups**](../gui/administration.html#restore) wieder her, mit angehaktem **Vor dem Wiederherstellen ein neues Backup erstellen**. Eine Wiederherstellung:
+
+* spielt `ansibleforms.sql` ein, was die gesamte Datenbank ersetzt; ab 7.3.0 wird ein Backup eines älteren Release danach erneut
+  aktualisiert, wie beim Start eines neuen Release, und ein fehlschlagender Patch wird gemeldet
+* kopiert `config.yaml` zurück und ersetzt den Ordner `forms/` durch den des Backups: Ab 7.3.0 werden Formulare, die nicht im Backup sind,
+  entfernt statt behalten, die Links und der Modus des Ordners bleiben, und eine fehlgeschlagene Kopie setzt den Ordner zurück
+* stellt `managed.env` **nicht** wieder her, da sie den Host beschreibt, von dem das Backup stammt. Die Schaltfläche **Umgebung wiederherstellen**
+  stellt sie auf Anfrage wieder her, behält die aktuelle Datei als `.env.bak` und erfordert einen Neustart.
+
+Ein Backup ohne brauchbaren Dump wird abgewiesen; beheben Sie nach einer unterbrochenen Wiederherstellung die Ursache und stellen Sie erneut wieder her.
+
+Setzen Sie auf einem neuen Host vor der Wiederherstellung dasselbe `ENCRYPTION_SECRET`, sonst lassen sich die gespeicherten Anmeldedaten nicht entschlüsseln.
+
+---
+
+## Was sonst noch zu sichern ist
+
+Das nächtliche Backup umfasst die Datenbank, die Konfiguration und die Formulare, aber nichts anderes im persistenten Ordner:
+
+* **`ENCRYPTION_SECRET` und `ACCESS_TOKEN_SECRET`** : absichtlich nie in einem Backup. Bewahren Sie sie in Ihrem Secret Manager auf;
+  ohne das Verschlüsselungsgeheimnis ist ein Datenbank-Dump für die Anmeldedaten nutzlos.
+* **die Backups selbst** : Sie liegen auf demselben Volume wie die Instanz. Kopieren Sie `BACKUP_PATH` auf einen anderen Host.
+* **der Rest des persistenten Ordners** : Playbooks, Uploads, Variablendateien, geklonte Repositories, Zertifikate und Protokolle.
+  Sichern Sie beim docker-compose-Projekt den gesamten Ordner `data/`, der außerdem den SSH-Schlüssel, die eigenen
+  Funktionen sowie die Ansible-Rollen und -Collections enthält.
+
+Inhalte, die aus Git stammen (Repositories, Formulare in einem Repository), lassen sich erneut klonen, daher ist ihr Backup weniger wichtig.
diff --git a/i18n/de/_configure/production/index.md b/i18n/de/_configure/production/index.md
new file mode 100644
index 0000000..216501e
--- /dev/null
+++ b/i18n/de/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Betrieb in Produktion
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# Betrieb in Produktion
+{: .no_toc }
+
+Eine Instanz veröffentlichen, sichern und überwachen, auf die sich Menschen verlassen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Vor dem Livegang
+
+Mit den Standardwerten läuft eine Instanz schnell, aber mehrere davon sind nur für einen ersten Eindruck gedacht. AnsibleForms
+protokolliert beim Start eine Warnung `[SECURITY]`, wenn `ENCRYPTION_SECRET` oder `ACCESS_TOKEN_SECRET` nicht gesetzt ist, und die
+Seite **Status** meldet die Backups, die Aufbewahrungseinstellungen und den Ausdrucks-Sanitizer.
+
+---
+
+## Checkliste für die Produktion
+
+Gehen Sie diese Punkte einmal durch, bevor sich Benutzer auf die Instanz verlassen, und erneut nach einem größeren Upgrade:
+
+| Punkt | Was zu tun ist | Details |
+|------|------------|---------|
+| Admin-Passwort | Das Passwort des lokalen Admin-Kontos ändern | [Härtung](../security/hardening.html#the-admin-account) |
+| Verschlüsselungsgeheimnis | [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) setzen, bevor Sie Anmeldedaten speichern | [Geheimnisse und Verschlüsselung](../security/secrets.html#the-two-master-secrets) |
+| Token-Geheimnis | [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) setzen, damit Sitzungen einen Neustart überstehen | [Geheimnisse und Verschlüsselung](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | TLS mit Ihrem eigenen Zertifikat terminieren, nicht mit dem Beispielzertifikat | [HTTPS](../security/https.html) |
+| Reverse Proxy | Die Instanz hinter einem Proxy veröffentlichen, optional unter [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse Proxy](reverse-proxy.html) |
+| Schema-Endpunkt | [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) auf `0` setzen, sobald das Schema existiert | [Härtung](../security/hardening.html#the-database) |
+| Ausgehende Aufrufe | REST-Ausdrücke mit [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) einschränken | [Härtung](../security/hardening.html#expressions-and-outbound-calls) |
+| Optionale Funktionen | MCP und den Chat-Assistenten ausgeschaltet lassen, sofern Sie sie nicht verwenden | [Härtung](../security/hardening.html#optional-features) |
+| Backups | Prüfen, dass das nächtliche Backup funktioniert, und es auf einen anderen Host kopieren | [Backups](backups.html) |
+| Aufbewahrung | Entscheiden, wie lange Jobs und Audit-Einträge aufbewahrt werden | [Protokolle](logs.html#retention) |
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite; die Absicherung der Instanz wird unter [Sicherheit](../security/) behandelt:
+
+| Seite | Inhalt |
+|---|---|
+| [Reverse Proxy](reverse-proxy.html) | AnsibleForms hinter Nginx, Traefik oder Apache veröffentlichen, im Stamm oder unter einem Unterpfad |
+| [Backups](backups.html) | Nächtliche Backups, was sie enthalten, Wiederherstellungen und was sonst noch zu sichern ist |
+| [Protokolle](logs.html) | Protokolldateien, Syslog, der Audit-Verlauf und die Aufbewahrung von Jobs und Audit-Einträgen |
+| [Skalierung](scaling.html) | Mehrere App-Knoten mit einem Worker; die RTE hat einen eigenen Abschnitt, [Laufzeitumgebungen](../rte/) |
+| [Überwachung](monitoring.html) | Health-Probes, Prometheus-Metriken und die Seite Status |
diff --git a/i18n/de/_configure/production/logs.md b/i18n/de/_configure/production/logs.md
new file mode 100644
index 0000000..8ba15a0
--- /dev/null
+++ b/i18n/de/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Protokolle
+parent: Betrieb in Produktion
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Protokolle
+{: .no_toc }
+
+Protokolldateien, Syslog, der Audit-Verlauf und wie lange Jobs und Audit-Einträge aufbewahrt werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Protokolldateien
+
+AnsibleForms schreibt zwei täglich rotierte Protokolle nach [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), komprimiert ältere Tage und bewahrt sie [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS) lang auf
+(standardmäßig 30, `0` behält jede Datei; eine Änderung auf der Einstellungsseite gilt sofort):
+
+* `ansibleforms.<date>.log` : alles ab [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) aufwärts
+* `ansibleforms.errors.<date>.log` : nur Fehler
+
+Die Konsole, gelesen mit `docker logs` oder `kubectl logs`, hat eine eigene Stufe,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Beide sind standardmäßig `notice`, was für
+die Produktion richtig ist; verwenden Sie `info` oder `debug` nur bei der Fehlersuche, und lassen Sie
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) ausgeschaltet. Die Stufen lassen sich auf
+den Einstellungsseiten ohne Neustart ändern, und die Seite **Serverprotokoll** zeigt das Protokoll Benutzern mit der Option `showLogs`.
+
+---
+
+## JSON-Zeilen
+
+Für einen Log-Collector wie Loki, ELK oder Splunk setzen Sie [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) auf `json`. Jede
+Zeile, auf der Konsole und in den Dateien, ist dann ein JSON-Objekt statt `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Feld | Inhalt |
+|-------|---------|
+| `time` | Die Uhrzeit, in ISO 8601 UTC |
+| `level` | Die Protokollstufe |
+| `message` | Die Meldung |
+| `requestId` | Die Anfrage, zu der die Zeile gehört, wenn sie während deren Bearbeitung geschrieben wurde |
+| `role` | Die Rolle des Prozesses, [`AF_ROLE`](scaling.html), oder `all`, wenn sie nicht gesetzt ist |
+| `host` | Der Hostname der Maschine oder des Containers, in dem der Prozess läuft |
+
+Jede Anfrage erhält eine ID: den Header `X-Request-Id`, den ein Reverse Proxy gesendet hat, oder eine neue. Sie wird im Header
+`X-Request-Id` der Antwort zurückgegeben und von jeder Zeile getragen, die während der Bearbeitung der Anfrage geschrieben wird (als `[req <id>]` in Textzeilen),
+sodass sich eine Anfrage durch das Protokoll verfolgen und mit der des Proxys abgleichen lässt. Eine Änderung auf der Einstellungsseite gilt sofort.
+
+---
+
+## Syslog
+
+Syslog-Server werden unter **Einstellungen > Verbindungen > Syslog** verwaltet, sodass ein Syslog-Server oder SIEM das Protokoll erhält, während es geschrieben wird.
+Sie können mehrere Server hinzufügen, und jeder hat eigene Einstellungen:
+
+| Einstellung | Was sie tut |
+|---------|--------------|
+| Aktiviert | Nur aktivierte Server erhalten etwas, sodass sich ein Server pausieren lässt, ohne ihn zu löschen; **Aktivieren** und **Deaktivieren** im Menü seiner Zeile schalten ihn ebenfalls um |
+| Protokoll | `udp4` (Standard), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` oder `unix-connect` |
+| Host und Port | Der Zielserver, standardmäßig Port `514`; ein `unix`-Protokoll nimmt stattdessen einen Socket-Pfad |
+| Empfängt | Das Serverprotokoll, die Audit-Einträge oder beides (der Standard für einen neuen Server) |
+| Stufe | Die niedrigste Stufe des Serverprotokolls, die er erhält, standardmäßig `info`; Audit-Einträge werden immer gesendet |
+| Format | `BSD` (RFC 3164, der Standard) oder `RFC 5424` |
+
+Eine Änderung gilt auf jedem Knoten ohne Neustart, und die Seite des Servers hat eine Schaltfläche, die ihm eine Testmeldung sendet.
+Ein nicht erreichbarer Server hält die Anwendung nie an: Der Fehler wird auf die Konsole geschrieben.
+
+Ab 7.3.0 brauchen die Syslog-Server die vollen Einstellungsrechte, die Rollenoption [`showSettings`](../config/roles.html#role-options):
+Der Zugriff auf die Verbindungs-Einstellungen allein genügt nicht, da ein Syslog-Server das Serverprotokoll und die Audit-Einträge erhält.
+
+Die Variablen `LOG_SYSLOG_*` früherer Versionen sind seit 7 veraltet. Der erste Start, der
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) gesetzt vorfindet, importiert sie einmal als Server `syslog`,
+der wie bisher das Serverprotokoll empfängt, und ignoriert sie danach. Entfernen Sie sie nach diesem ersten
+Start aus der Umgebung und verwalten Sie den Server auf der Einstellungsseite.
+
+---
+
+## Audit-Verlauf
+
+Die Seite **Audit-Protokoll** (unter **Einstellungen > Protokolle**) hält fest, wer was geändert hat, was die Protokolldateien nicht gut beantworten.
+Sie erfasst:
+
+* jede über die API vorgenommene Änderung (`POST`, `PUT`, `PATCH`, `DELETE`), einschließlich mit 401 oder 403 abgewiesener Versuche
+* Anmeldungen, mit dem versuchten Benutzernamen
+* Ereignisse der Anwendung selbst, etwa nächtliche Backups, entfernte Backups, bereinigte Jobs und Anwendungen des Config-Seeds
+
+Jeder Eintrag hat seine Uhrzeit, den Akteur (ein Benutzer oder die Anwendung selbst für ihre eigenen Aufgaben), die Client-IP-Adresse,
+die Aktion, ihr Ziel und ihr Ergebnis: `success`, `failure` oder `denied`. Die Seite filtert nach Akteur, Aktion und
+Ergebnis, und Benutzer mit der Rollenoption `showSettings` können sie öffnen.
+
+Die IP-Adresse ist die, die AnsibleForms sieht, also die des Proxys, wenn es hinter einem läuft. Setzen Sie
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) auf die Anzahl oder die Adressen Ihrer Proxys, dann erfasst AnsibleForms
+stattdessen die Client-Adresse, die der Proxy in `X-Forwarded-For` meldet; siehe [Reverse Proxy](reverse-proxy.html).
+
+Um den Audit-Verlauf außerhalb der Instanz aufzubewahren, für ein SIEM, fügen Sie einen Syslog-Server hinzu, der die Audit-Einträge empfängt (siehe
+[Syslog](#syslog)). Jeder Eintrag wird sofort gesendet, als eine Zeile `audit {...}` mit dem Eintrag als JSON, unabhängig von der
+Stufe des Servers. Die Syslog-Kopie wird weder von der Aufbewahrung unten entfernt noch durch eine Wiederherstellung der Datenbank ersetzt.
+
+---
+
+## Aufbewahrung
+
+Zwei tägliche Aufgaben mit einer Einstellung verhindern, dass die Datenbank unbegrenzt wächst:
+
+| Variable | Standard | Läuft um | Entfernt |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Audit-Einträge, die älter sind |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (alle behalten) | 2:30 | Abgeschlossene Jobs, die älter sind, samt ihrer Ausgabe |
+
+`0` behält bei beiden alles. Zwei weitere tägliche Aufgaben haben keine Einstellung: Um 3:00 werden die gespeicherten Refresh-Token, die älter als 30 Tage sind, und
+die abgelaufenen Token-Sperren entfernt, und um 4:00 die [gespeicherten Jobs](../jobs/stored-jobs.html), deren Ablauf verstrichen ist.
+Die Zeiten gelten in der Zeitzone von [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), und der Worker führt sie aus.
+
+Die Jobausgabe ist meist die am schnellsten wachsende Tabelle: Die Seite **Status** meldet ihre Größe
+und warnt, wenn sie 1 GB überschreitet, ohne dass eine Aufbewahrung gesetzt ist. Laufende Jobs und Jobs, die auf Genehmigung warten, werden nie entfernt.
+Legen Sie eine Job-Aufbewahrung fest, die Ihren Audit-Anforderungen entspricht, und bewahren Sie den Audit-Verlauf mindestens ebenso lange auf.
diff --git a/i18n/de/_configure/production/monitoring.md b/i18n/de/_configure/production/monitoring.md
new file mode 100644
index 0000000..efd90da
--- /dev/null
+++ b/i18n/de/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Überwachung
+parent: Betrieb in Produktion
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Überwachung
+{: .no_toc }
+
+Health-Probes für einen Load Balancer oder Kubernetes, Prometheus-Metriken und die Seite Status
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Health-Probes
+
+Zwei Endpunkte sagen einem Load Balancer, einem Container-Healthcheck oder Kubernetes, ob ein Prozess Verkehr annehmen kann.
+Keiner braucht eine Anmeldung, und keiner gibt etwas über die Einrichtung preis:
+
+| Endpunkt | Antwortet | Verwendung |
+|----------|---------|------------|
+| `/api/v2/live` | `200` mit `{"status":"live"}`, solange der Prozess läuft | Eine Liveness-Probe: den Prozess neu starten, wenn er nicht mehr antwortet |
+| `/api/v2/ready` | `200` mit `{"status":"ready"}` oder `503` mit `{"status":"not ready","reason":"..."}` | Eine Readiness-Probe: Verkehr nur an bereite Prozesse senden |
+
+Ein Prozess ist bereit, wenn all das zutrifft:
+
+* er fährt nicht gerade herunter (`stopping`)
+* die Datenbank antwortet (`database unreachable`)
+* das Schema existiert (`schema not provisioned`) und ist vollständig, mit jeder Tabelle, jeder Spalte und jedem Index dieser Version
+  (`schema not upgraded`); diese letzte Prüfung wird 30 Sekunden zwischengespeichert, sodass eine Probe alle paar Sekunden günstig bleibt
+
+Unter einer [`BASE_URL`](../customization/server.html#env_BASE_URL) beginnen die Pfade mit ihr, zum Beispiel
+`/ansibleforms/api/v2/ready`. Eine Laufzeitumgebung (RTE) beantwortet dieselben Probes unter `/live` und `/ready`, ohne die
+Prüfung der Vollständigkeit des Schemas; sie ist nicht bereit, während sie beim Herunterfahren ihre Jobs abarbeitet, sodass ihr kein neuer Job gesendet wird. Eine ausgehende RTE
+ist außerdem nicht bereit (`not connected to the app`), bis ihr Socket zur App offen ist.
+Ein mit `AF_ROLE=worker` gestarteter Prozess hat keine Weboberfläche: Er beantwortet nur `/api/v2/version` und `/health` für seinen
+Container-Healthcheck. Die Rollen finden Sie unter [Skalierung](scaling.html).
+
+---
+
+## Prometheus-Metriken
+
+Setzen Sie [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) auf eine lange Zufallszeichenfolge, um Prometheus-Metriken bereitzustellen.
+Ein Prozess, der die Webanwendung bereitstellt, antwortet unter `/api/v2/metrics`, eine RTE unter `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Ohne `METRICS_TOKEN` antworten die Endpunkte mit `404`, als gäbe es sie nicht, und eine Anfrage ohne den richtigen Header
+`Authorization: Bearer <token>` erhält `401`. Jeder Prozess meldet seine eigenen Werte, scrapen Sie also jeden einzeln:
+
+| Metrik | Was sie misst |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | Den Prozess: CPU, Speicher, Event-Loop-Verzögerung, Garbage Collection |
+| `af_http_requests_total{route,method,status}` | Die bearbeiteten Anfragen |
+| `af_http_request_duration_seconds{route}` | Wie lange sie gedauert haben |
+| `af_jobs{status}` | Jobs, die gerade laufen (`running`) oder auf Genehmigung warten (`approve`) |
+| `af_jobs_ended_24h{status}` | Jobs, die in den letzten 24 Stunden geendet haben, nach Status |
+| `af_nodes{role,alive}` | Die in der Datenbank registrierten Prozesse, nach Rolle, lebend oder nicht |
+| `af_login_failures_total`, `af_login_lockouts_total` | Fehlgeschlagene Anmeldungen und Kontosperren |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Auf einer RTE: die Playbooks, die sie gerade ausführt, und wie viele sie gleichzeitig ausführen darf |
+| `af_rte_socket_connected` | Auf einer RTE im Socket-Modus: `1`, solange ihr Socket zur App offen ist, `0`, wenn nicht |
+
+Die Job- und Knotenwerte werden bei jedem Scrape aus der Datenbank gelesen. Antwortet die Datenbank nicht, werden sie
+weggelassen, und der Scrape gelingt trotzdem mit den übrigen Metriken.
+
+---
+
+## Die Seite Status
+
+Die Seite **Status** unter **Einstellungen > System** zeigt Benutzern mit der Rollenoption `showSettings`, wie es der Instanz geht.
+Sie liest nur, daher sendet ein Aktualisieren nie eine Mail und startet nie einen Job. Sie hat zwei Tabs, und die Anzahl der Probleme erscheint in der Beschriftung des Tabs **Prüfungen**.
+
+### Prüfungen
+
+Jede Prüfung ist grün (in Ordnung), gelb (braucht Aufmerksamkeit) oder rot (ein Problem), mit Details beim Aufklappen der Zeile:
+
+| Prüfung | Was sie betrachtet |
+|-------|------------------|
+| Datenbankverbindung | Die Datenbank antwortet |
+| Datenbankbenutzer | Gelb, wenn der Benutzer Rechte auf jede Datenbank hat, wie `root`, statt nur auf `AnsibleForms.*` |
+| Datenbankschema | Jede Tabelle, jede Spalte und jeder Index dieser Version existiert, und welcher Patch fehlgeschlagen ist, wenn nicht |
+| Zeitplaner | Ein Worker führt die Systemaufgaben aus, und keine davon hat aufgehört, eingeplant zu werden |
+| Knoten | Die Prozesse in der Datenbank, gelb, wenn sie unterschiedliche Versionen ausführen |
+| Jobs | Laufende Jobs und Jobs, die auf Genehmigung warten, gelb, wenn ein Job länger als 24 Stunden gelaufen ist |
+| Backup-Werkzeuge | Der Dump-Befehl von [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) existiert, und seine Version |
+| Letztes Backup | Gelb, wenn es keines gibt oder das neueste älter als zwei Tage ist, rot, wenn es keinen brauchbaren Dump hat |
+| Designer-Sperre | Wer die Designer-Sperre hält, gelb, wenn sie länger als 8 Stunden gehalten wurde |
+| Repositories | Rot, wenn ein Repository fehlgeschlagen ist oder kein Arbeitsverzeichnis auf der Festplatte hat |
+| Konfigurations-Seed | Die Datei des [Config-Seeds](../seed/) ist lesbar und lässt sich parsen, und ihr letztes Neuladen hat funktioniert |
+| Secret Stores | Jeder Secret Store antwortet, gelb, wenn das Token eines HashiCorp Vault bald abläuft |
+| Runner | Jeder Runner antwortet, gelb, wenn es keinen gibt oder keine Standard-RTE |
+| Server-Ausdrücke | Gelb, wenn [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) `legacy` ist |
+| Geheimnisse | Gelb, wenn `ENCRYPTION_SECRET` der öffentlich bekannte Standard ist oder `ACCESS_TOKEN_SECRET` nicht gesetzt ist |
+| LDAP | Der LDAP-Server ist erreichbar und sein TLS-Zertifikat gültig, ohne sich bei ihm anzumelden |
+| Job-Speicher | Die Größe der Job-Tabellen, gelb über 1 GB, wenn keine Job-Aufbewahrung gesetzt ist |
+| Beschreibbare Ordner | In jeden konfigurierten Ordner lässt sich schreiben |
+| Speicherplatz | Die Festplatte mit den Backups, gelb ab 85 % Belegung und rot ab 95 % |
+
+### Informationen
+
+Fakten über die Instanz ohne Bewertung, das Erste, wonach ein Support-Gespräch fragt: die Version von
+AnsibleForms, die Basis-URL, Version und Host der Datenbank, die Konfigurationsquelle, der Config-Seed, die
+Aufbewahrungseinstellungen, die Authentifizierungsmethoden, der Server des aktiven [Mail-Kanals](../notification-channels.html),
+Protokollstufe und -pfad, die Betriebszeit, die Zeitzone, die Node.js-Version und die Plattform.
+
+Die Seite liest `/api/v2/health`, das einen angemeldeten Benutzer mit `showSettings` braucht. Für ein Überwachungssystem verwenden Sie
+stattdessen die Probes und die Metriken oben.
diff --git a/i18n/de/_configure/production/reverse-proxy.md b/i18n/de/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..336216e
--- /dev/null
+++ b/i18n/de/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse Proxy
+parent: Betrieb in Produktion
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse Proxy
+{: .no_toc }
+
+AnsibleForms hinter Nginx, Traefik oder Apache veröffentlichen, im Stamm oder unter einem Unterpfad
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wann man einen verwendet
+
+AnsibleForms stellt die Oberfläche, die REST-API und Swagger auf einem Port bereit; ein vorgeschalteter Reverse Proxy ermöglicht Ihnen:
+
+* die Bereitstellung auf Port 443 mit einem Zertifikat, das Ihre vorhandenen Werkzeuge verwalten (ACME, eine Unternehmens-CA)
+* die gemeinsame Nutzung eines Hostnamens mit anderen Anwendungen, indem AnsibleForms unter einem Unterpfad veröffentlicht wird
+* den Anwendungsport und die Datenbank aus dem öffentlichen Netz herauszuhalten
+
+Ein Proxy ist optional: Die Anwendung kann HTTPS auch selbst bereitstellen, siehe [HTTPS](../security/https.html).
+
+---
+
+## Die wichtigen Einstellungen
+
+Nur wenige Einstellungen beeinflussen, wie sich AnsibleForms hinter einem Proxy verhält:
+
+| Einstellung | Hinter einem Proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | Der Port, an den der Proxy weiterleitet, standardmäßig `8000`. Das docker-compose-Projekt setzt ihn auf `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0`, wenn der Proxy TLS terminiert und die Anwendung über ein privates Netz erreicht, `1`, um auch diesen Abschnitt zu verschlüsseln. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | Der Unterpfad, zum Beispiel `/ansibleforms`. Lassen Sie ihn auf `/`, wenn die Anwendung einen eigenen Hostnamen hat. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Welche Proxys die Client-Adresse in `X-Forwarded-For` melden dürfen, meist `1`. Siehe [Client-Adressen](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | Größte JSON-Anfrage, die die Anwendung annimmt, standardmäßig 50 MB. Der Proxy muss mindestens so viel erlauben. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | Größte Datei, die ein Upload-Feld eines Formulars annimmt, standardmäßig 10 GB. Der Proxy muss sie ebenfalls erlauben, sonst schlagen Uploads dort fehl. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | Größte Menge an Anfrage-Headern, die die Anwendung annimmt, standardmäßig 16 KB, ab 7.1.0. Siehe [Größe der Anfrage-Header](#request-header-size). |
+| **Öffentliche Root-URL** | Unter **System > Allgemein**, im Tab **Server**: die Adresse, unter der Benutzer die Anwendung erreichen, einschließlich Unterpfad. Daraus werden die Links in Benachrichtigungsmails, Kanalnachrichten und Genehmigungsanfragen erzeugt. |
+
+Registrieren Sie für Entra ID oder OIDC die öffentliche Adresse als Redirect URI, mit dem Unterpfad aus `BASE_URL`, falls gesetzt.
+
+---
+
+## Bereitstellung unter einem Unterpfad
+
+`BASE_URL` hängt die gesamte Anwendung unter dem Unterpfad ein; der Proxy muss den Pfad **unverändert** weiterleiten.
+Mit `BASE_URL=/ansibleforms`:
+
+* die Oberfläche, `/api/v2/...` und die Swagger-Oberfläche werden alle unter `/ansibleforms/` bereitgestellt
+* das `<base href>` der Oberfläche wird beim Start umgeschrieben, sodass Assets und API-Aufrufe unter dem Unterpfad aufgelöst werden
+* eine Anfrage an `/` oder an `/ansibleforms` (ohne abschließenden Schrägstrich) wird auf `/ansibleforms/` umgeleitet
+
+Behalten Sie das Präfix bei: kein `StripPrefix` in Traefik, keine URI bei `proxy_pass` in Nginx, da die Anwendung es erwartet.
+
+Die Seite **Status** zeigt die geltende Basis-URL.
+
+---
+
+## Zeitüberschreitungen, Uploads und Live-Ausgabe
+
+Die Seite Jobs und die Job-Zähler erfahren von Änderungen über einen langlebigen Strom von Server-Sent Events,
+[`/api/v2/events`](../api/events.html), der pro Browser offen gehalten wird. Der Strom sendet Header, die das Puffern im Proxy abschalten
+(`X-Accel-Buffering: no`), und alle 15 Sekunden eine Keep-alive-Zeile, sodass das übliche Lese-Timeout von 60 Sekunden ihn offen hält;
+schließt ein Proxy ihn trotzdem, verbindet sich der Browser von selbst neu. Die Ausgabe unter einem Formular direkt nach einem Start wird
+stattdessen alle zwei Sekunden gelesen. Ein Job-Start kehrt zurück, sobald der Job angelegt ist, sodass ein langes Playbook keine
+Anfrage offen hält.
+
+Die Anfragen, die lange dauern können, sind:
+
+* **Backup und Wiederherstellung** auf der Seite **Backups**, die warten, bis der Dump- oder Wiederherstellungsbefehl fertig ist, bis zu
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (standardmäßig 3600)
+* **große Uploads** über ein Dateifeld, die die gesamte Datei in einer Anfrage übertragen
+* **Chat-Nachrichten**, wenn der [Chat-Assistent](../chat/) aktiviert ist, die auf die Antwort des Modellanbieters warten
+
+Proxys brechen oft nach 60 Sekunden ab und begrenzen Anfrage-Bodys (Nginx akzeptiert standardmäßig 1 MB). Erhöhen Sie beides für
+die Routen von AnsibleForms, wie in den Beispielen unten.
+
+---
+
+## Runner-WebSockets
+
+Ab 7.3.0 wählt sich ein [ausgehender Runner](../rte/modes.html#outbound) bei der Anwendung ein und hält einen WebSocket auf
+`<BASE_URL>/api/v2/rte/socket` offen. Der Proxy muss das Upgrade weiterreichen, sonst verbindet sich der Runner nie und wählt sich immer wieder ein:
+
+| Proxy | Was der WebSocket braucht |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` und die Header `Upgrade` und `Connection`, die Nginx standardmäßig nicht weiterleitet |
+| Traefik | Nichts: WebSockets werden unverändert durchgereicht |
+| Apache | `upgrade=websocket` in der Zeile `ProxyPass` (ab 2.4.47) oder davor `mod_proxy_wstunnel` |
+
+Beide Enden senden alle 20 Sekunden einen Ping, sodass das übliche Lese-Timeout von 60 Sekunden einen untätigen Socket offen hält.
+
+---
+
+## Größe der Anfrage-Header
+
+Jede Anfrage trägt das Anmeldetoken in ihrem Header `Authorization`, neben Cookies und den Headern, die der Proxy hinzufügt.
+Sowohl der Proxy als auch die Anwendung begrenzen die Größe der Anfrage-Header und weisen eine Anfrage über der Grenze ab, bevor
+AnsibleForms sie sieht, sodass nichts im Serverprotokoll ankommt. Die Standardwerte:
+
+| Komponente | Grenze | Standard | Abgewiesen mit |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), alle Header zusammen | 16384 Bytes | 431 |
+| Nginx | `large_client_header_buffers`, pro Header-Feld | `4 8k`: 8 KB pro Feld | 400 |
+| Traefik | `http.maxHeaderBytes` des Entry Points, alle Header zusammen | 1 MB | 431 |
+| HAProxy | `tune.bufsize` im Abschnitt `global`, der gesamte Header-Block abzüglich der Reserve `tune.maxrewrite` (1024 Bytes) | 16384 Bytes: 15360 Bytes an Headern | 400 |
+| Apache | `LimitRequestFieldSize`, pro Header-Feld | 8190 Bytes | 400 |
+
+Bis 7.0.3 trug das Anmeldetoken jede Gruppe eines Single-Sign-on-Benutzers und konnte über diese Grenzen hinauswachsen, siehe
+[Leere Formulare und Jobs nach einem Single Sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Ab 7.1.0 bleibt das Token klein, und die Standardwerte genügen. Wenn etwas anderes die Header groß macht, etwa
+Cookies anderer Anwendungen auf derselben Domäne oder ein vorgeschaltetes Single-Sign-on-Gateway, erhöhen Sie die Grenzen gemeinsam:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536` oder vor 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; beide werden
+  beim Start gelesen, starten Sie die Anwendung also nach einer Änderung neu
+* Nginx: `large_client_header_buffers 4 32k;` im Block `http` oder `server`
+* HAProxy: `tune.bufsize 65536` im Abschnitt `global`; jeder Stream erhält einen Puffer dieser Größe, daher empfiehlt HAProxy,
+  das globale `maxconn` um denselben Faktor zu senken, und HTTP/2 braucht mindestens den Standard von 16384
+* Apache: `LimitRequestFieldSize 32768` in der Serverkonfiguration oder im virtuellen Host
+
+---
+
+## Client-Adressen
+
+Hinter einem Proxy kommt jede Verbindung vom Proxy. Ohne [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY)
+erfasst der Audit-Verlauf für jede Aktion die Adresse des Proxys, und die adressbezogenen
+[Anmeldegrenzen](../security/hardening.html#sign-in-limits-and-passwords) zählen alle Clients als eine Adresse.
+`TRUST_PROXY` sagt, welchen Proxys die Anwendung glauben darf, wenn sie den Client in `X-Forwarded-For` melden:
+
+| Wert | Client-Adresse |
+|-------|----------------|
+| `0` (Standard) | Die Adresse der Verbindung. `X-Forwarded-For` wird ignoriert; leer, `false`, `off` und `no` bedeuten dasselbe. |
+| Eine Zahl, z. B. `1` | Vertraut so vielen Proxys vor der Anwendung: `1` für einen einzelnen Reverse Proxy, `2` für einen Load Balancer vor einem Ingress. |
+| Eine Liste, z. B. `10.0.0.5,172.16.0.0/12` | Vertraut den Proxys unter diesen Adressen und CIDR-Bereichen. Die Voreinstellungen `loopback`, `linklocal` und `uniquelocal` werden ebenfalls akzeptiert. |
+| `true` | Vertraut jedem Hop: Die linke Adresse von `X-Forwarded-For` wird verwendet. |
+
+Die Anwendung durchläuft `X-Forwarded-For` von rechts, überspringt die vertrauenswürdigen Proxys und nimmt die erste Adresse, die
+keiner von ihnen ist. Verwenden Sie die genaue Anzahl der Proxys oder ihre Adressen:
+
+* `X-Forwarded-For` ist ein einfacher Anfrage-Header, den jeder Client senden kann. Eine zu hohe Zahl oder `true` lässt einen
+  Client die Adresse wählen, die der Audit-Verlauf erfasst. `true` ist nur sicher, wenn die Anwendung ausschließlich über
+  den Proxy erreichbar ist, und der Server protokolliert beim Start eine Warnung `[SECURITY]`, wenn es gesetzt ist.
+* Der Proxy muss die Adresse hinzufügen, von der er die Verbindung empfangen hat, wie es die Beispiele unten tun
+  (`$proxy_add_x_forwarded_for` in Nginx; Traefik und Apache `mod_proxy` fügen sie standardmäßig hinzu).
+* Ein ungültiger Wert wird auf der Einstellungsseite abgewiesen; in der Umgebung gesetzt, wird er beim Start als Fehler protokolliert, und
+  keinem Proxy wird vertraut. Eine auf der Einstellungsseite gespeicherte Änderung gilt ohne Neustart.
+
+---
+
+## Beispiele
+
+Jedes Beispiel veröffentlicht AnsibleForms unter `https://forms.example.com/ansibleforms/`, wobei der Proxy TLS terminiert und
+die Anwendung mit `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` und `TRUST_PROXY=1` läuft:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` nennt keine URI, daher leitet Nginx den Pfad so weiter, wie er hereinkam, einschließlich Präfix. Der Block `map` gehört in den
+Kontext `http` (eine Datei unter `conf.d/` wird dort eingebunden) und reicht das WebSocket-Upgrade der Runner weiter:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Ohne Unterpfad verwenden Sie `location /` und lassen `BASE_URL` ungesetzt.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Labels am Dienst `app` des docker-compose-Projekts, mit Traefik im selben Docker-Netz. Der Dienst
+veröffentlicht keinen eigenen Port, Traefik erreicht ihn über das Netz:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Es gibt absichtlich keine Middleware `StripPrefix`. Traefik setzt die Header `X-Forwarded-*` selbst und begrenzt
+die Body-Größe nicht, prüfen Sie aber die `respondingTimeouts` des Entry Points, wenn Backups oder Uploads länger dauern als sein
+Lese-Timeout. Ohne Unterpfad behalten Sie nur den Teil `Host(...)` der Regel.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Braucht `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl` und Apache 2.4.47 oder neuer für das `upgrade=websocket` der Runner.
+Beide Seiten von `ProxyPass` tragen das Präfix:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Ohne Unterpfad leiten Sie `/` an `http://10.0.0.20:8000/` weiter und lassen `BASE_URL` ungesetzt.
+
+</div>
+</div>
+
+Um den Abschnitt zwischen Proxy und Anwendung verschlüsselt zu halten, betreiben Sie die Anwendung mit `HTTPS=1`, richten den Proxy auf
+`https://` und geben der Anwendung ein Zertifikat, dem der Proxy vertraut, siehe [HTTPS](../security/https.html).
diff --git a/i18n/de/_configure/production/scaling.md b/i18n/de/_configure/production/scaling.md
new file mode 100644
index 0000000..9e15019
--- /dev/null
+++ b/i18n/de/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Skalierung
+parent: Betrieb in Produktion
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Skalierung
+{: .no_toc }
+
+AnsibleForms aufgeteilt auf mehrere App-Knoten und einen Worker, neben einer oder mehreren RTEs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rollen
+
+Jeder AnsibleForms-Container führt denselben Servercode aus, und [`AF_ROLE`](../customization/server.html#env_AF_ROLE) entscheidet, was er tut:
+
+| `AF_ROLE` | Image | Führt aus | Wie viele |
+|---|---|---|---|
+| `all` (nicht gesetzt) | `ansibleforms` | Die Web-App und den Worker in einem Prozess: der Standard | 1 |
+| `app` | `ansibleforms` | Die Weboberfläche und die API | Beliebig viele, hinter einem Load Balancer |
+| `worker` | `ansibleforms` | Die Hintergrundarbeit: das Datenbankschema und seine Upgrades, den Config-Seed, die Zeitpläne, das nächtliche Backup, die Synchronisierung der Repositories und die Bereinigungen | Einer arbeitet; weitere warten und übernehmen |
+| `rte` | `ansibleforms-rte-full` (oder `-rte-core`, `-rte-base`) | Die Playbooks | Beliebig viele |
+
+Die kleinste Installation ist ein Container ohne `AF_ROLE` neben einer RTE: Das ist es, was das [Docker Compose-Projekt](../installation/docker-compose.html)
+und das [Helm-Chart](../installation/kubernetes.html) ausführen. Jeder andere Wert von `AF_ROLE` beendet den Prozess bei seinem Start.
+
+---
+
+## Die RTE
+
+Die RTE, die Laufzeitumgebung, die die Playbooks ausführt, hat einen eigenen Abschnitt: [Laufzeitumgebungen](../rte/). Er behandelt, wie eine RTE
+einen Job ausführt, [ihre Images](../rte/images.html), [wie man eine betreibt](../rte/run.html), [mehrere RTEs](../rte/several.html) als Runner oder
+Replikate und [eine RTE in einem anderen Rechenzentrum](../rte/another-datacenter.html).
+
+---
+
+## Mehrere App-Knoten
+
+Um mehr Benutzer zu bedienen oder den Ausfall eines Knotens zu überstehen, teilen Sie die App in `app`-Knoten hinter einem Load Balancer und einen `worker` auf.
+
+### Was die Knoten teilen
+{: .no_toc }
+
+Die Knoten stimmen sich über die Datenbank und ein gemeinsames Volume miteinander ab:
+
+* **Die Datenbank** : die Jobs, die Worker-Sperre, die Designer-Sperre, die Liste der Knoten, die Runner-Leases (welcher App-Knoten den
+  Socket jeder RTE hält) und die Änderungsmeldungen, die die Caches jedes Knotens aktuell halten. Anmeldedaten, ein Runner oder ein Zeitplan, auf
+  einem Knoten bearbeitet, gelten innerhalb von 5 Sekunden auf allen
+* **Das persistente Volume** (`/app/dist/persistent`) : Formulare, die Konfiguration, Repositories, Uploads, Backups und die verwaltete `.env`.
+  Jeder App-Knoten und der Worker hängen dasselbe ein, mit Lese- und Schreibzugriff
+* **Der ssh-Ordner** (`/home/node/.ssh`) : der Schlüssel und die bekannten Hosts für Git über SSH; der Worker erzeugt den Schlüssel bei seinem ersten Start
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : auf jedem App-Knoten gleich, sonst wird ein von einem
+  Knoten signiertes Token vom nächsten abgewiesen. Ein App-Knoten verweigert ohne es den Start
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : auf jedem App-Knoten und Worker gleich, sonst können
+  von einem gespeicherte Anmeldedaten von einem anderen nicht gelesen werden. Eine RTE im Socket-Modus liest es nie; nur eine veraltete RTE im Datenbankmodus,
+  die sich selbst registriert, braucht es
+
+Geben Sie außerdem jedem Container denselben Datenbankbenutzer: Ein wartender Worker kann die Sitzung eines toten nur beenden, wenn es seine eigene ist.
+
+### Die Worker-Sperre
+{: .no_toc }
+
+Es arbeitet immer nur ein Worker. Er hält die Datenbanksperre `ansibleforms_worker`; hält er an, gibt die Datenbank die Sperre frei, und ein
+wartender Worker übernimmt sie innerhalb von 10 Sekunden. Stirbt der Host des Workers ohne Abschied, könnte die Datenbank die Sperre stundenlang behalten,
+daher beendet ein wartender Worker diese Sitzung, sobald zwei Minuten lang kein Worker einen Heartbeat geschrieben hat, und übernimmt.
+
+Ein Worker, der die Sperre an einen anderen verliert, hält an, und sein Container startet als der wartende neu. Ein Worker, dessen Start fehlschlägt, hält
+ebenfalls an, damit er nie die Sperre hält, ohne etwas zu tun. Galera und Group Replication teilen die Sperre nicht zwischen Datenbankknoten: Richten Sie jeden
+Worker auf denselben Datenbankknoten.
+
+### Jobs und Knoten
+{: .no_toc }
+
+Jeder Container benennt sich selbst als `<role>-<hostname>-<port>`, ohne dass etwas zu setzen ist, und die Seite **Status** listet sie alle mit ihrer Rolle
+und Version auf, welcher der Worker ist, und eine Warnung, wenn sie unterschiedliche Versionen ausführen.
+
+Ein Job, der auf einer RTE läuft, gehört dieser RTE und läuft weiter, wenn der App-Knoten, der ihn gestartet hat, wegfällt. Jeder andere Job (ein Template-Job
+auf AWX oder einem anderen Runner, ein Workflow-Job oder die Schritte eines veralteten mehrstufigen Formulars) gehört dem App-Knoten, der ihn gestartet hat. Ein Container, der neu startet, beendet seine eigenen unvollendeten Jobs, und der
+Worker beendet die Jobs eines Containers, der zwei Minuten lang nicht mehr geantwortet hat, etwa eines ersetzten Pods.
+
+Ein an einen beliebigen Knoten gesendetes `SIGHUP` wendet den [Config-Seed](../seed/) erneut an: Ein App-Knoten bittet den Worker darum.
+
+### Upgrade
+{: .no_toc }
+
+Aktualisieren Sie **zuerst den Worker**, dann die App-Knoten. Der Worker patcht das Schema, und ein App-Knoten der neuen Version wartet, bis das
+Schema gepatcht ist, und protokolliert, worauf er wartet. Zuerst aktualisierte App-Knoten bleiben nicht bereit, bis der Worker nachzieht, während die alten weiter
+bedienen. RTEs können jederzeit folgen, solange sie denselben Vertrag sprechen.
+
+### Grenzen
+{: .no_toc }
+
+Einige Dinge bleiben bei einem Knoten:
+
+* **Der Chat-Assistent** hält seine Unterhaltungen im Speicher eines App-Knotens: Verwenden Sie Sticky Sessions am Load Balancer (nginx
+  `ip_hash`) oder einen einzigen App-Knoten
+* **Protokolle** bleiben in jedem Container. Legen Sie [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) außerhalb des gemeinsamen Volumes ab, da mehrere
+  Prozesse, die eine Datei rotieren, Zeilen verlieren. Der Protokoll-Viewer zeigt das Protokoll des antwortenden Knotens, sammeln Sie die Protokolle also zentral
+* **Einstellungen**, die auf den Einstellungsseiten geändert werden, werden in die verwaltete `.env` auf dem gemeinsamen Volume geschrieben und gelten auf jedem Knoten; die,
+  die einen Neustart brauchen, brauchen ihn auf jedem Knoten
+
+---
+
+## Beispielaufbau
+
+Das App-Repository hat einen vollständigen Ausgangspunkt in [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Dienst | Image | Rolle |
+|---|---|---|
+| `db` | `mariadb:11` | Die Datenbank, mit einem Benutzer, der nur Rechte auf das Schema `AnsibleForms` hat |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, hinter dem Load Balancer |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: der zweite wartet und übernimmt |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Führt die Playbooks mit `RTE_MODE=inbound` und `RTE_FILES=local` aus: die App wählt sich bei ihr ein |
+| `lb` | `nginx:stable` | Terminiert HTTPS auf Port 8443 und verteilt die Browser mit `ip_hash` auf die App-Knoten |
+
+Der Runner `rte` der RTE und die Anmeldedaten, mit denen er sich anmeldet (ihre Adresse `http://rte:8000` und `RTE_TOKEN`), sind im
+[Config-Seed](../seed/) `seed.yaml` deklariert, den der Worker bei jedem Start anwendet; die RTE setzt kein `RTE_URL` und wird auf dem Host nicht veröffentlicht.
+
+Die App-Knoten und die Worker teilen eine `.env`, mit dem Datenbankbenutzer, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` hinter dem Load Balancer und einem `LOG_PATH` außerhalb des gemeinsamen Volumes. Die RTE hat keine `env_file`: Sie erhält
+nur `RTE_TOKEN` aus `compose.yaml` und enthält daher kein Datenbankpasswort. Die App-Knoten, die Worker und die RTE hängen dieselben
+persistenten und ssh-Volumes ein:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/de/_configure/rte/another-datacenter.md b/i18n/de/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..5cf603a
--- /dev/null
+++ b/i18n/de/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Ein anderes Rechenzentrum
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Eine RTE in einem anderen Rechenzentrum
+{: .no_toc }
+
+Von einem leeren Host in einem zweiten Rechenzentrum zu einer ausgehenden RTE, die ihr erstes Playbook ausführt
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Für Administratoren: wenn die verwalteten Hosts eines zweiten Rechenzentrums von einer RTE in diesem Rechenzentrum aus erreicht werden sollen, nicht vom ersten aus.
+
+{: .note }
+> **Der einfache Weg.** Das [Installationsprogramm](../installation/installer.html#a-runner) erledigt jeden der folgenden Schritte auf dem RTE-Host mit einem Befehl:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, mit `--join afj_...`, um sie sofort freigeben zu lassen.
+> Dieses Runbook macht dasselbe von Hand, mit Docker oder Podman, damit Sie jeden Teil sehen und anpassen können.
+
+---
+
+## Was Sie am Ende haben
+
+Die App, ihr Worker und ihre Datenbank bleiben, wo sie sind, in Rechenzentrum 1. Rechenzentrum 2 erhält einen Host, der einen RTE-Container im
+ausgehenden Modus betreibt ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), siehe [Modi](modes.html#outbound)): Er wählt sich über
+HTTPS bei der App ein und hält einen WebSocket offen, tritt als eigener Runner bei und führt die Playbooks der Formulare, die ihn nennen, gegen die verwalteten
+Hosts von Rechenzentrum 2 aus.
+
+| Wo | Was dort läuft | Spricht mit |
+|---|---|---|
+| Rechenzentrum 1 | Die App-Knoten, der Worker, die Datenbank (wie bisher) | Nichts Neues: Es nimmt den Socket der RTE unter seiner üblichen HTTPS-Adresse an |
+| Rechenzentrum 2, der RTE-Host | Docker oder Podman und der RTE-Container | Die App unter `APP_URL` über HTTPS und die verwalteten Hosts von Rechenzentrum 2 |
+
+Die RTE hält keine Datenbank-Anmeldedaten und kein `ENCRYPTION_SECRET`, nur ein eigenes Token. Nichts verbindet sich mit ihr, daher braucht sie keinen offenen
+Port, keinen DNS-Namen und kein Zertifikat. Die App sendet die Playbooks und Inventare mit jedem Job (`RTE_FILES=transfer`, der
+Standard), sodass die RTE keine Kopie davon und keine gemeinsame Festplatte braucht.
+
+Jeder der folgenden Befehle läuft in einem Terminal auf dem RTE-Host, als Benutzer mit `sudo`, sofern nicht anders angegeben. Es dauert etwa 20 Minuten,
+die meiste Zeit davon wartet man auf das Image.
+
+---
+
+## 0. Bevor Sie beginnen
+
+Sammeln Sie Folgendes:
+
+| Was | Woher es kommt |
+|---|---|
+| Die Adresse der App | `APP_URL`: die Adresse, die Benutzer im Browser öffnen, etwa `https://forms.example.com`, mit ihrem Basispfad, falls sie einen hat |
+| Das Zertifikat der App | Von einer öffentlichen CA signiert, von einer privaten CA (Sie brauchen deren Zertifikat, Schritt 6) oder selbstsigniert |
+| Ein Proxy | Der `HTTPS_PROXY`, über den dieses Rechenzentrum Rechenzentrum 1 erreicht, falls vorhanden |
+| Der Name der RTE | Der Name ihres Runners unter **Verbindungen > Runner**, den Formulare mit `runner:` nennen, etwa `rte-dc2`: Buchstaben, Ziffern und `_ . : @ -` |
+| Ein Beitrittstoken | Optional: Ein [Beitrittstoken](../runners/registration.html#join-tokens) (`afj_...`) gibt die RTE sofort frei. Ohne eines gibt ein Admin sie frei (Schritt 8) |
+| Der SSH-Schlüssel | Der private Schlüssel, mit dem die Playbooks die verwalteten Hosts erreichen, oder das Recht, einen zu erstellen |
+
+Die App muss 7.3.0 oder neuer ausführen. Um ein Beitrittstoken für genau diese RTE zu erstellen, ruft ein Admin einmal die API auf (siehe
+[Beitrittstoken](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Den Host vorbereiten
+
+Die RTE ist ein Container, daher braucht der Host eine Container-Engine und sonst nichts: Node.js, Python und Ansible sind im Image.
+
+| Bedarf | Warum |
+|---|---|
+| Linux auf **x86_64** (amd64) | Die RTE-Images werden nur für amd64 veröffentlicht |
+| 2 CPUs und 4 GB Speicher oder mehr | Eine RTE führt bis zu [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) Playbooks gleichzeitig aus (10), jedes mit seinen Forks: Dimensionieren Sie sie dafür |
+| 20 GB freier Festplattenplatz | Das Image `-rte-full` ist etwa 3,3 GB groß, dazu ein Image während Updates, die Jobdateien, die die App sendet, und die temporären Dateien der Jobs |
+| Docker oder Podman mit podman-compose | Um das Image zu ziehen und auszuführen |
+| Die Uhrzeit per NTP gestellt | Die Zeiten der Jobs werden mit denen der App verglichen |
+
+**Docker**, auf Ubuntu oder Debian (andere Distributionen: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, auf RHEL, Rocky oder Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Schreiben Sie mit Podman in jedem der folgenden Befehle `podman` statt `docker` und `podman-compose` statt `docker compose`.
+
+---
+
+## 2. Netzwerk und Firewall
+
+Die RTE öffnet jede Verbindung selbst. Von außen erreicht sie nichts:
+
+| Von | Nach | Port | Warum |
+|---|---|---|---|
+| Der RTE-Host | Die App, unter `APP_URL` (über `HTTPS_PROXY`, falls gesetzt) | Der Port der App, `443` hinter den meisten Proxys | Der Socket, über den die Jobs, ihre Dateien und ihre Ausgabe laufen |
+| Der RTE-Host | Die verwalteten Hosts von Rechenzentrum 2 | ssh (`22`), WinRM, ihre APIs | Die Playbooks laufen von hier aus |
+| Der RTE-Host | `ghcr.io` | `443` | Um das Image zu ziehen, sofern es nicht aus Ihrer eigenen Registry oder einer Datei kommt (Schritt 4) |
+
+Öffnen Sie keinen eingehenden Port für die RTE. Ihr `PORT` (`8000`) bedient nur `/live`, `/ready` und `/metrics`, für die Probes auf diesem Host.
+
+Die RTE wählt `APP_URL` mit angehängtem `/api/v2/rte/socket` an, als WebSocket. Ein Reverse Proxy vor der App muss das Upgrade
+für diesen Pfad weiterreichen (siehe [Runner-WebSockets](../production/reverse-proxy.html#runner-websockets)). Prüfen Sie von hier, dass die App antwortet:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Ordner
+
+Alles liegt unter `/opt/af-rte`. Die RTE läuft als Benutzer `node` (uid 1000), daher gehören ihre Daten dieser uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Ordner | Im Container | Enthält |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | Den Spool (`rte-spool`: Ausgabe und Ende jedes Jobs, bis die App sie gespeichert hat), die von der App gesendeten Jobdateien (`rte-files`), eine private CA, die Python-Bibliotheken, die ein Playbook installiert |
+| `data/ssh/` | `/home/node/.ssh` | Den SSH-Schlüssel und die `known_hosts` der Playbooks |
+| `data/ansible/` | `/etc/ansible/...` | Eine `ansible.cfg`, eigene Rollen und Collections, eingehängt statt eingebaut |
+
+Behalten Sie `data/` auf dem Host: Eine neu gestartete RTE sendet dann noch, was die App nicht gespeichert hatte, und behält ihren Cache an Jobdateien.
+
+**SSH-Schlüssel.** Kopieren Sie den Schlüssel, den die Playbooks in Rechenzentrum 1 verwenden, oder erstellen Sie einen für dieses Rechenzentrum und geben Sie seinen öffentlichen Teil den verwalteten Hosts:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Übergeben Sie dann alles an uid 1000, wobei der Schlüssel nur für seinen Besitzer lesbar ist:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. Das Image
+
+Wählen Sie eine der beiden Optionen.
+
+### Option A: das offizielle Image
+{: .no_toc }
+
+Die veröffentlichten Images liegen in der GitHub Container Registry, öffentlich, ohne Anmeldung (die drei Schichten finden Sie unter [Images](images.html)).
+Nehmen Sie dieselbe Schicht wie in Rechenzentrum 1. `:7` folgt dem neuesten Release 7, wie `:7` der App:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Ein Host ohne Internetzugang erhält das Image von einem, der welchen hat:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Oder pushen Sie es einmal in Ihre eigene Registry (`docker tag` und `docker push`) und verwenden Sie diesen Namen in den nächsten Schritten.
+
+### Option B: ein eigenes Image
+{: .no_toc }
+
+Wenn die Playbooks von Rechenzentrum 2 Collections oder Python-Bibliotheken brauchen, die dem offiziellen Image fehlen (zum Beispiel die VMware-Collections für das
+vCenter dieses Rechenzentrums), bauen Sie auf `ansibleforms-rte-core` auf:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Bauen Sie es bei jedem neuen Release der App neu (siehe [Eine eigene RTE bauen](images.html#build-your-own-rte)). Mit mehreren RTE-Hosts bauen Sie
+einmal und pushen in Ihre eigene Registry. Offline übertragen Sie das gebaute Image mit `docker save` und `docker load` wie in Option A.
+
+---
+
+## 5. Einstellungen
+
+Ein neues eigenes [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), mindestens 16 Zeichen. Es ist das Passwort dieser RTE: Die App
+bewahrt es in den RTE-Anmeldedaten des Runners auf und versiegelt die Geheimnisse jedes Jobs damit.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variable | Bedeutung |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: Die RTE wählt sich bei der App ein. Ohne die Variable startet die RTE im veralteten Datenbankmodus |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Die Adresse der App, `http://` oder `https://`, mit ihrem Basispfad, falls vorhanden |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Der Name ihres Runners. Nicht gesetzt: ihre Knoten-ID, `rte-<hostname>-<port>`, die sich mit dem Container ändert |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Ihr eigenes Token, mindestens 16 Zeichen. Bewahren Sie es auf: Der Runner meldet sich ab jetzt damit an |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Optional: ein Beitrittstoken, nur verwendet, solange ihr Runner noch nicht existiert oder auf Freigabe wartet |
+
+Fügen Sie diese hinzu, wenn das Netz sie braucht:
+
+| Variable | Wann |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | Die RTE erreicht die App über einen Proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Ein in `NO_PROXY` aufgeführter Host (durch Kommas getrennt, `.example.com` für eine Domäne) wird direkt angewählt |
+| `NODE_EXTRA_CA_CERTS` | Das Zertifikat der App stammt von einer privaten CA: Legen Sie das Zertifikat der CA in `/opt/af-rte/data/certificates/ca.pem` ab und setzen Sie `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` akzeptiert jedes Zertifikat der App, auch ein selbstsigniertes. Nur innerhalb eines vertrauenswürdigen Netzes: Ziehen Sie `NODE_EXTRA_CA_CERTS` vor |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (Standard) erhält die Playbooks und Inventare mit jedem Job. Lassen Sie es so, es sei denn, Sie hängen sie selbst bei der RTE ein (`local`) |
+
+Die weiteren Einstellungen, die eine RTE liest, stehen unter [Eine RTE betreiben](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` und
+`RTE_DRAIN_SECONDS` lassen sich später auch auf ihrer Runner-Seite setzen, die über die Variable gewinnt (siehe
+[Die Einstellungen einer RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Starten
+
+Eine Compose-Datei hält die gesamte Definition an einem Ort, neben den Einstellungen. Tragen Sie das Image aus Schritt 4 unter `image:` ein:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker startet sie nach einem Neustart des Hosts wieder (`unless-stopped`). Podman hat keinen Daemon, der das tut: Aktivieren Sie `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`) oder betreiben Sie den Container als systemd-Dienst mit einer Quadlet-Datei. Auf einem Host mit erzwungenem
+SELinux fügen Sie jedem Volume `:Z` hinzu (`./data:/app/dist/persistent:Z`).
+
+Ohne Compose derselbe Container mit einem Befehl:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Auf dem Host prüfen
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+Das Protokoll zeigt, wie die RTE startet, sich bei der App einwählt und verbindet:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Ohne Beitrittstoken sagt eine weitere Zeile, dass sie wartet:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Notieren Sie den Fingerabdruck.
+
+`/ready` antwortet mit `503` und `not connected to the app`, bis der Socket offen ist. Der Healthcheck sagt nur, dass der Prozess lauscht.
+
+---
+
+## 8. Freigeben
+
+Ohne Beitrittstoken hat die RTE um Beitritt gebeten: **Verbindungen > Runner** zeigt über der Liste einen orangefarbenen Hinweis,
+**1 Runner wartet auf Freigabe**. Öffnen Sie ihn, prüfen Sie, dass der **Fingerabdruck** der aus dem Protokoll der RTE ist und dass **Modus**
+Ausgehend lautet, und klicken Sie dann auf **Freigeben** (siehe [Eine RTE freigeben](../runners/registration.html#approving-an-rte)). Nur ein Admin gibt frei. Eine Anfrage,
+die niemand innerhalb von 24 Stunden bearbeitet, wird entfernt, und die RTE fragt erneut, wenn sie sich das nächste Mal bei der App einwählt.
+
+Mit einem Beitrittstoken wird der Runner sofort freigegeben, und seine Beschreibung nennt das Beitrittstoken. In beiden Fällen bewahrt die App das Token der RTE
+in neuen RTE-Anmeldedaten auf, `rte-dc2-rte`, und die RTE meldet sich ab dann mit ihrem eigenen `RTE_TOKEN` an: `RTE_JOIN_TOKEN` wird nicht mehr
+verwendet, und Sie können es aus `rte.env` entfernen.
+
+---
+
+## 9. In AnsibleForms prüfen
+
+1. **Verbindungen > Runner** listet den Runner `rte-dc2`, Typ RTE. Schalten Sie **Spalten > Verbindung** ein, um **Verbunden** in der Liste zu sehen
+2. Öffnen Sie ihn. Sein Tab **RTE** zeigt **Modus** Ausgehend und die Plakette **Verbindung** mit **Verbunden**; beim Überfahren nennt sie den App-Knoten, der
+   den Socket hält, das Release der RTE und wie viele ihrer Jobs laufen
+3. Klicken Sie auf **Verbindung testen**: Es meldet **Runner connection is OK**. Es ruft nichts auf: Es liest, welcher App-Knoten den Socket der RTE hält
+   (`runner_leases`), und prüft den Vertrag, den die RTE beim Verbinden gesprochen hat
+4. Geben Sie ihm eine Beschreibung, etwa *Rechenzentrum 2*
+5. Lassen Sie **Standard** auf dem Runner von Rechenzentrum 1, es sei denn, jedes Playbook-Formular ohne `runner:` soll in Rechenzentrum 2 laufen
+
+Die Seite **Status** listet die neue RTE mit ihrer Version neben den anderen auf.
+
+---
+
+## 10. Ein erster Job
+
+Beweisen Sie den ganzen Weg mit einem Playbook, das nichts ändert. Fügen Sie in den Playbooks der App (ihrem Playbook-Ordner oder Repository, wie in
+Rechenzentrum 1) `ping-dc2.yaml` hinzu:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Fügen Sie dann im Designer ein Formular hinzu, das den neuen Runner nennt:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Starten Sie es. Die App sendet den Playbook-Ordner und das Inventar mit dem Job, und die RTE bewahrt sie nach ihrem Hash auf, sodass ein unveränderter
+Ordner nie zweimal gesendet wird. Die Ausgabe beginnt mit `Running on RTE rte-dc2 (outbound)`, zeigt `pong` für jeden Host, und der Job
+endet erfolgreich. Ein Ordner, der größer ist als [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (standardmäßig 512), wird nicht
+gesendet: Der Job schlägt fehl und sagt das.
+
+---
+
+## 11. Die Formulare dorthin senden
+
+Ein Formular läuft auf der RTE, die es nennt, fügen Sie also jedem Formular für Rechenzentrum 2 dieselbe Zeile hinzu:
+
+```yaml
+runner: rte-dc2
+```
+
+Den Standard-Runner und die anderen Runner-Typen finden Sie unter [Runner](../runners.html).
+
+---
+
+## Wenn etwas fehlschlägt
+
+Die RTE schreibt ab `notice` in `docker logs`. Eine Verbindung, die fehlschlägt, bevor der Socket offen ist (ein DNS-Name, ein abgewiesener Port, ein
+Zertifikat), erscheint nur als `RTE: dialing the app again in <n> seconds`, auf Stufe `info`: Setzen Sie
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) in `rte.env` und starten Sie sie neu, um
+`RTE: socket to wss://...: <the error>` zu sehen.
+
+| Was Sie sehen | Wo | Was zu tun ist |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `RTE_TOKEN` fehlt in `rte.env` oder ist zu kurz |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Setzen Sie `APP_URL` in `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` beginnt mit `https://` (oder `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | `RTE_MODE=outbound` fehlt in `rte.env` |
+| Keine Zeile `connected to the app`, `/ready` bleibt bei `503` | `docker logs`, `/ready` | Das Netz aus Schritt 2: Rufen Sie die App von diesem Host mit `curl` auf, prüfen Sie den Proxy (`HTTPS_PROXY`, `NO_PROXY`) und das Zertifikat der App (`NODE_EXTRA_CA_CERTS`, Schritt 5). Setzen Sie `LOG_CONSOLE_LEVEL=debug`, um den Fehler zu sehen |
+| `the app refused the socket (404)` oder ein anderer Status als 401, 403 und 409 | `docker logs` | Ein Reverse Proxy reicht den WebSocket auf `/api/v2/rte/socket` nicht weiter, oder `APP_URL` fehlt der Basispfad der App |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Ein Runner `rte-dc2` existiert mit einem anderen Token. Geben Sie der RTE dieses Token (das Passwort der Anmeldedaten des Runners) oder löschen Sie den Runner, damit sie um Beitritt bittet |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Erstellen Sie ein neues Beitrittstoken oder entfernen Sie `RTE_JOIN_TOKEN` und geben Sie die RTE frei (Schritt 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | Die RTE wurde mit einem neuen Token neu installiert: Verwenden Sie das Token aus den Anmeldedaten ihres Runners oder lassen Sie es von einem Admin ändern |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Folgt auf eine Ablehnung. Beheben Sie die Ursache und führen Sie dann `docker restart af_rte_dc2` aus, statt zu warten |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Geben Sie sie frei (Schritt 8). Sie ist verbunden, nimmt aber bis dahin keinen Job an |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | Die App und die RTE führen Releases eines anderen [Vertrags](images.html#the-contract) aus: Aktualisieren Sie die RTE auf das Release der App (siehe Aktualisieren) |
+| **Nicht verbunden**, oder **Verbindung testen** meldet *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | Die App | Kein App-Knoten hält ihren Socket: Die RTE ist angehalten oder erreicht die App nicht. Lesen Sie ihre `docker logs` |
+| Ein Job wartet und schlägt dann fehl mit *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | Die Ausgabe des Jobs | Die RTE war nicht verbunden, während der Job wartete |
+| `Permission denied` beim SSH-Schlüssel | Die Ausgabe des Jobs | Die Dateien von `data/` müssen uid 1000 gehören (Schritt 3) |
+| `UNREACHABLE` für die verwalteten Hosts | Die Ausgabe des Jobs | SSH von diesem Host aus: der Schlüssel, `known_hosts` und die Firewall zu den Hosts |
+
+Auf der Seite der App erscheint eine abgewiesene RTE im Protokoll der App als `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Aktualisieren
+
+Wenn die App auf ein neues Release wechselt, ziehen Sie auch auf diesem Host nach. Eine RTE desselben Vertrags funktioniert in der Zwischenzeit weiter; wenn ein Release
+den Vertrag ändert, sagen seine Release Notes das (siehe [Der Vertrag](images.html#the-contract)). Mit `:7` in `compose.yml` oder im
+`FROM` Ihres Dockerfiles:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Aktualisieren Sie sie, wenn kein Playbook darauf läuft: Ein Anhalten wartet `RTE_DRAIN_SECONDS` (25) auf die laufenden Playbooks, und die dann noch laufenden
+enden als verwaist. Was sie vor dem Anhalten ausgegeben haben, bleibt im Spool und wird gesendet, sobald die RTE zurück ist. Offline laden Sie
+das neue Image mit `docker load` (Schritt 4) vor `docker compose up -d`.
+
+---
+
+## Zurückrollen
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+Der Socket schließt sich, und der Runner zeigt sofort **Nicht verbunden**: Kein App-Knoten hält mehr seinen Socket (`runner_leases`). Ein Host,
+der verschwindet, ohne ihn zu schließen, zeigt innerhalb etwa einer Minute **Nicht verbunden**, sobald der App-Knoten nichts mehr auf dem Socket hört. Der
+Runner bleibt: Ein über einen Socket beigetretener Runner wird nie von selbst entfernt. Löschen Sie ihn unter **Verbindungen > Runner** und seine
+Anmeldedaten `rte-dc2-rte` unter **Verbindungen > Anmeldedaten**. Entfernen Sie zuerst die Zeile `runner:` aus den Formularen, die ihn nannten: Bis
+dahin warten ihre Jobs auf die RTE, bis zu `RTE_QUEUE_MINUTES`, und schlagen fehl.
+
+---
+
+## Mehr Kapazität in Rechenzentrum 2
+
+Wiederholen Sie die Schritte 1 bis 9 auf weiteren Hosts von Rechenzentrum 2, jeder mit eigenem `RTE_NAME` und `RTE_TOKEN`, etwa `rte-dc2-b`: Jede tritt als
+eigener Runner bei und übernimmt bis zu [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) Playbooks. Ein Formular wählt eine mit
+`runner:`. Zwei RTEs mit demselben `RTE_NAME` teilen sich die Arbeit nicht: Die zweite übernimmt den Socket von der ersten (siehe
+[Mehrere RTEs](several.html#several-rtes)).
+
+---
+
+## Eine RTE im Datenbankmodus
+
+Vor 7.3.0 richtete dieses Runbook eine RTE im Datenbankmodus ein: Sie hielt die Anmeldedaten der Datenbank (`DB_*`, `ENCRYPTION_SECRET`), verband sich
+über Port `3306` mit der Datenbank von Rechenzentrum 1, und die App rief sie auf ihrem Port `8000` auf. Dieser Modus ist seit 7.3.0 veraltet und wird
+in 8.0.0 entfernt. Um eine solche RTE ohne neuen Runner auf ausgehend umzustellen, setzen Sie `RTE_MODE=outbound`, `APP_URL` und `RTE_NAME` (den Namen
+ihres Runners) auf ihr, behalten Sie ihr `RTE_TOKEN` und entfernen Sie `DB_*`, `ENCRYPTION_SECRET` und `RTE_REGISTER`: siehe
+[Datenbank (veraltet)](modes.html#database-deprecated). Schließen Sie dann Port `8000` und den Datenbankport, die sie nicht mehr braucht.
diff --git a/i18n/de/_configure/rte/images.md b/i18n/de/_configure/rte/images.md
new file mode 100644
index 0000000..c018d51
--- /dev/null
+++ b/i18n/de/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Images
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# RTE-Images
+{: .no_toc }
+
+Die drei veröffentlichten RTE-Images und eine eigene RTE mit den Collections und Bibliotheken, die Ihre Playbooks verwenden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die RTE-Images
+
+Die RTE wird in drei Schichten veröffentlicht, jede auf der vorherigen aufgebaut, mit denselben Tags wie die App (siehe [Image-Tags](../installation/#image-tags)):
+
+| Image | Was es enthält | Verwendung |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js und den AnsibleForms-Server, git, ssh und sshpass. Kein Python und kein Ansible, daher führt es allein kein Playbook aus | Um eine RTE mit eigenen Python- und Ansible-Versionen zu bauen |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | Die Basis plus Python 3.14, ansible-core und einige gängige Bibliotheken (`jmespath`, `netaddr`, `requests`, `paramiko`). Keine Collections | Um eine kleinere RTE mit nur den Collections und Bibliotheken zu bauen, die Ihre Playbooks verwenden |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Der Core plus das Paket `ansible` auf demselben ansible-core und das, was das Image von AnsibleForms 6.5 hatte: die Collections von NetApp, AWS und der Community, `pandas`, `pyvmomi`, `boto3`, den mariadb-Client, ytt und einige OS-Werkzeuge | **Der Standard.** Unverändert verwenden: Playbooks aus 6.5 finden, was sie verwendet haben |
+
+Wie das App-Image läuft jede Schicht als Benutzer `node` (uid 1000), und auch die Playbooks laufen als dieser Benutzer.
+
+---
+
+## Eine eigene RTE bauen
+
+Bauen Sie auf `ansibleforms-rte-core` auf und fügen Sie die Collections und Python-Bibliotheken hinzu, die Ihre Playbooks verwenden. Dieses NetApp-Beispiel ist eines
+der Dockerfiles in [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+Die Python-Umgebung und der Collections-Ordner gehören `node`, daher brauchen diese Installationen kein root. Eine Schicht, die OS-Pakete installiert,
+wechselt dafür zu `USER root` und am Ende zurück zu `USER node`. Um eigenes Python und Ansible mitzubringen, bauen Sie auf
+`ansibleforms-rte-base` auf (`Dockerfile.own-ansible` im selben Ordner).
+
+Halten Sie das Image auf dem Release der App: `:7` folgt `:7` der App. Collections und Rollen lassen sich auch einhängen statt einbacken, unter
+`/etc/ansible/collections` und `/etc/ansible/roles`. Dann ist pro Änderung kein Neubau nötig, aber was läuft, hängt von diesem Volume ab;
+Python-Bibliotheken gehören immer ins Image. Alles einzubacken ist reproduzierbar und startet schnell, daher ist es der Weg für die Produktion.
+
+---
+
+## Der Vertrag
+
+Was die App und eine RTE gemeinsam haben müssen, ist ihr Vertrag, eine Nummer, die beide melden. Eine RTE eines älteren Release funktioniert weiter mit einer neueren
+App, solange beide denselben Vertrag sprechen; ändert ein Release ihn, sagen seine Release Notes, dass RTEs aktualisiert werden müssen. Jeder Modus
+hat seinen eigenen:
+
+| Modus | Vertrag | Bei einer Abweichung |
+|---|---|---|
+| Ausgehend, Eingehend | 3, neu in 7.3.0 | Die App schließt den Socket der RTE mit dem Code `4409` und protokolliert *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Eine ausgehende RTE protokolliert *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Ein mit einem anderen Vertrag gesendeter Job wird abgewiesen |
+| Datenbank (veraltet) | 2, seit 7.0.0 | Die RTE weist die Jobs der App ab |
+
+**Verbindung testen** am Runner sagt, welchen Vertrag die RTE spricht und welchen die App braucht (siehe
+[Verbindung testen](../runners/runner-page.html#test-connection)), und die Zeile **Runner** der Seite **Status** führt dieselbe Prüfung aus.
diff --git a/i18n/de/_configure/rte/index.md b/i18n/de/_configure/rte/index.md
new file mode 100644
index 0000000..1c8ff73
--- /dev/null
+++ b/i18n/de/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Laufzeitumgebungen (RTE)
+{: .no_toc }
+
+Was eine RTE ist, wie sie ein Playbook ausführt und worauf sie zugreifen darf
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Verstehen Sie die RTE, bevor Sie eine betreiben, dimensionieren oder in ein anderes Netz verlegen.
+
+| Seite | Inhalt |
+|---|---|
+| [Images](images.html) | Die drei RTE-Images und der Bau eines eigenen mit den Collections, die Ihre Playbooks verwenden |
+| [Modi](modes.html) | Ausgehend, eingehend oder Datenbank: wer die Verbindung öffnet, der Spool, die Dateien des Jobs |
+| [Eine RTE betreiben](run.html) | Die Einstellungen jedes Modus und jeweils ein Beispiel mit `docker run` |
+| [Mehrere RTEs](several.html) | Kapazität, Replikate hinter einer Adresse und was passiert, wenn eine RTE anhält oder ausfällt |
+| [Ein anderes Rechenzentrum](another-datacenter.html) | Ein Runbook: eine RTE in einem zweiten Rechenzentrum hinzufügen, vom leeren Host bis zu ihrem ersten Job |
+
+---
+
+## Was eine RTE ist
+
+AnsibleForms 7 führt kein Playbook im App-Container aus. Der Job eines `ansible`-Formulars wird an einen [Runner](../runners.html) vom Typ
+`rte` übergeben, eine Laufzeitumgebung: der AnsibleForms-Server, gestartet mit `AF_ROLE=rte`, neben Python und Ansible, ohne
+Weboberfläche. Sie spricht mit der App über einen WebSocket und hält keine Datenbank-Anmeldedaten
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` oder `inbound`, siehe [Modi](modes.html)): Die App sendet ihr den Job,
+die RTE führt `ansible-playbook` aus, und die App speichert die Ausgabe und den Endstatus, die sie zurückschickt, wo der Browser sie liest.
+
+Die App löst die Anmeldedaten des Jobs auf und übergibt sie der RTE versiegelt, nur für diese RTE und diesen Job. Die RTE liest weder die
+Tabelle der Anmeldedaten noch einen Secret Store, und ein Playbook erbt nicht die Umgebungsvariablen von AnsibleForms selbst
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` und die anderen): Übergeben Sie einen solchen Wert als Extravar oder Anmeldedaten. Die RTE von 7.0 bis 7.2,
+die selbst in der Datenbank las und schrieb, läuft in 7.x weiterhin als veralteter Datenbankmodus (siehe [Datenbankmodus](#database-mode-deprecated)).
+
+---
+
+## Wie die RTE läuft
+
+Die RTE ist ein Container, den Sie selbst betreiben, neben der App oder in einem anderen Netz: AnsibleForms erzeugt nie einen. Dieser Abschnitt geht durch,
+wo sie läuft, was sie mit der App teilt und was in ihr geschieht, vom Start eines Formulars an bis der Prozess des Playbooks
+beendet ist:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Wie die RTE ein Playbook ausführt</title>
+<desc id="afr-desc">Auf einem Container-Host oder in einem Kubernetes-Cluster, beide vom Betreiber betrieben, halten der App-Container und ein oder mehrere RTE-Container jeweils einen WebSocket zwischen sich, geöffnet von der App (eingehend) oder von der RTE (ausgehend). Nur die App spricht mit der Datenbank. 1: Der Browser startet ein Formular in der App. 2: Die App speichert den Job in der Datenbank, wählt den Runner und versiegelt die Geheimnisse des Jobs für ihn. 3: Die App sendet den Job über den Socket. 4: Die RTE übernimmt ihn und holt die Dateien des Jobs aus ihrem Cache oder von der App. 5: Die RTE startet ansible-playbook als Kindprozess, einen pro Job, bis zu RTE_MAX_JOBS. 6: Das Playbook erreicht die verwalteten Hosts. 7: Die RTE schreibt die Ausgabe, die Ereignisse und das Ende in ihren Spool und sendet sie über den Socket; die App speichert sie in der Datenbank und bestätigt sie. 8: Der Browser verfolgt den Job über die App. Das Volume der App wird nur mit RTE_FILES=local in die RTE eingehängt.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Container-Host oder Kubernetes-Cluster</text>
+<text class="afr-s" x="181" y="61">von Ihnen betrieben; eine ausgehende RTE kann in einem anderen Netz liegen</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Browser</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">Formulare, Jobseite</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">App-Container</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">Web-App, API, Worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runners</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">versiegeln Geheimnisse</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">RTE-Hub</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">speichert, bestätigt</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">RTE-Container</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">Job-Dateien</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">nach Hash im Cache</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">bis zu RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">bis zur Bestätigung</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">ein</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Verwaltete Hosts</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volume der App</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">Playbooks, Inventare</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">nur RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">nur die der App</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+Das Diagramm zeigt einen Socket pro RTE, egal welche Seite ihn geöffnet hat: Die App wählt sich bei einer eingehenden RTE ein, eine ausgehende RTE wählt sich bei der App ein (siehe
+[Modi](modes.html)). Sobald er offen ist, gehen dieselben Nachrichten in beide Richtungen, und nur die App liest und schreibt die Datenbank.
+
+**Wer sie startet.** Eine RTE ist ein langlebiger Container, gestartet von dem, was auch Ihre anderen Container betreibt. Sie wartet auf Jobs und läuft
+zwischen ihnen weiter:
+
+| Wie Sie AnsibleForms betreiben | Wer die RTE startet |
+|---|---|
+| `docker run` oder `podman run` | Sie, mit einem Befehl wie dem in [Eine RTE betreiben](run.html), auf einem beliebigen Host, der die App erreicht oder den die App erreicht |
+| [Docker Compose](../installation/docker-compose.html) | Der Dienst `rte` von `docker-compose.yml`, neben `app` und `mysqldb`. Sein Config-Seed deklariert ihn als Standard-Runner `rte`, eingehend, unter `http://rte:8000` |
+| [Helm-Chart](../installation/kubernetes.html) | Kubernetes, als zweiter Container namens `rte` im Pod der App (`containers.rte`). Die App wählt sich unter `127.0.0.1` ein, eingehend, und der Seed des Charts deklariert ihn als Standard-Runner |
+| [Das Installationsprogramm](../installation/installer.html) | Docker Compose oder das Helm-Chart wie oben, oder ein systemd-Dienst [ohne Container](../installation/native.html); ein eigener Runner, der um Beitritt bittet und auf die Freigabe eines Admins wartet |
+
+Die Container-Engine gehört Ihnen: Docker oder Podman auf dem Host oder die Container-Runtime Ihres Kubernetes-Clusters, von Ihnen installiert und aktuell
+gehalten. AnsibleForms spricht nie mit ihr. Weder die App noch die RTE ruft Docker oder Podman auf, hängt deren Socket ein oder startet einen
+Container: Die App spricht mit der RTE nur über deren Socket.
+
+**Was drin ist.** Ein Container, mit dem, was zum Ausführen eines Playbooks nötig ist, und nichts weiter:
+
+* **Der Server** : derselbe Node.js-Server wie die App, gestartet mit `AF_ROLE=rte` (im Image gesetzt) unter `tini`
+* **Weggelassen** : die Weboberfläche, die Anmeldung, der Zeitplaner, der Worker und jedes Datenbankmodul, die diese Rolle nicht lädt
+* **Worauf sie lauscht** : ihren `PORT` (`8000`): `/live` und `/ready` für Probes und `/metrics` für Prometheus, und eingehend den Socket,
+  bei dem sich die App einwählt, `/rte/v1/socket`. Eine ausgehende RTE nimmt keine Verbindung von der App an
+* **Python und Ansible** : mitgebracht von der gewählten Image-Schicht (siehe [Die RTE-Images](images.html))
+* **Der Benutzer** : Der Server und jedes Playbook laufen als `node` (uid 1000), nie als root
+
+**Was sie mit der App teilt.** Ihr Token und mit `RTE_FILES=local` die Dateien der App. Mit `RTE_FILES=transfer`, dem Standard, kommen die
+Playbooks und Inventare mit jedem Job, und die RTE braucht keine gemeinsame Festplatte:
+
+| Mit der App geteilt | Was die RTE damit tut |
+|---|---|
+| `RTE_TOKEN` | Legt es vor, wenn sie sich bei der App einwählt (ausgehend), oder prüft es, wenn die App sich bei ihr einwählt (eingehend). Die App hält denselben Wert in den RTE-Anmeldedaten des Runners, und die Geheimnisse des Jobs werden damit versiegelt |
+| Das persistente Volume, `/app/dist/persistent`, nur mit `RTE_FILES=local` | Der Playbook-Ordner ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) oder das Playbook-Repository, das der Worker unter [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) geklont hat, die Inventare ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) und die Inventar-Repositories) und die Uploads. Die RTE schreibt die Extravars-Dateien des Jobs in den Playbook-Ordner, hängen Sie ihn also mit Schreibzugriff ein |
+| Der ssh-Ordner, `/home/node/.ssh` | Der private Schlüssel und die `known_hosts`, die die SSH-Verbindungen des Playbooks verwenden: Hängen Sie den der App ein, der auf ihren Einstellungsseiten verwaltet wird, oder geben Sie der RTE einen eigenen |
+
+Die RTE klont nichts: Ein Repository erreicht sie in den Dateien eines Jobs oder auf dem Volume, das sie mit der App teilt. Collections, Rollen und
+`ansible.cfg` kommen aus dem Image, aus den Ordnern `/etc/ansible/collections`, `/etc/ansible/roles` und `/etc/ansible/ansible.cfg`, wenn
+Sie sie dort einhängen (das Docker Compose-Projekt tut das), oder aus einer `ansible.cfg` neben den Playbooks.
+
+**Das Leben eines Jobs.** Die Nummern unten sind die Nummern im Diagramm, für ein Playbook-Formular, das aus dem Browser oder über die API gestartet wird:
+
+1. **Start** : Die App prüft das Formular und seine Werte, baut die Extravars und speichert den Job mit dem Status `running`. Ein Formular mit einer
+   [Genehmigung](../forms/approval.html) hält hier an, bis ein Genehmiger es akzeptiert, und erreicht vorher keine RTE
+2. **Den Runner wählen** : Die App nimmt die RTE, die das Formular mit `runner: <name>` nennt, sonst den Standard-Runner vom Typ RTE, und speichert seinen
+   Namen am Job. Sie löst die Anmeldedaten des Jobs aus der Datenbank oder einem [Secret Store](../secret-stores/) auf, seine Ansible-Anmeldung und sein
+   Vault-Passwort, und versiegelt sie mit AES-256-GCM unter einem Schlüssel, der aus dem Token dieses Runners und der Job-ID abgeleitet ist
+3. **Übergabe** : Der App-Knoten, der den Socket der RTE hält, sendet ihr den Job: die Extravars, die Optionen des Formulars, die versiegelten Geheimnisse und
+   die Hashes der Dateien des Jobs. Jeder App-Knoten kann den Job starten; der Knoten mit dem Socket sendet ihn innerhalb von zwei Sekunden. Eine volle RTE
+   oder eine nicht verbundene lässt den Job warten, bis zu [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Übernahme** : Die RTE antwortet `claimed` oder `refused`, wenn sie voll ist, anhält, die Geheimnisse nicht öffnen kann oder der Job mit einem anderen
+   [Vertrag](images.html#the-contract) als ihrem eigenen kommt. Mit `RTE_FILES=transfer` nimmt sie die Playbooks und Inventare anhand ihres Hashs aus ihrem
+   Cache, fragt die App nach einem Hash, den sie nicht hat, und entpackt sie in einen eigenen Ordner des Jobs
+5. **Start des Prozesses** : Im Playbook-Ordner (plus dem `playbookSubPath` des Formulars, der existieren muss) schreibt sie zwei Dateien: `extravars_<id>.json`
+   mit den Werten des Formulars und den Anmeldedaten sowie eine versteckte mit der Ansible-Anmeldung. Dann startet sie `ansible-playbook` als eigenen Kindprozess,
+   ohne Shell, in einer eigenen Prozessgruppe, mit `-e @` auf diese Dateien, einem `-i` pro Inventar sowie Tags, Limit, Check,
+   Diff und Ausführlichkeit des Formulars. Das Vault-Passwort geht über stdin hinein, nie in eine Datei oder auf die Befehlszeile, und der Prozess läuft als
+   `node` mit gefilterter Umgebung (siehe unten)
+6. **Ausführung** : Das Playbook verbindet sich vom RTE-Container aus mit den verwalteten Hosts, über SSH mit dem Schlüssel und den `known_hosts` aus
+   `/home/node/.ssh`, mit `sshpass` für eine Passwortanmeldung, oder über die APIs, die seine Module aufrufen. Die RTE, nicht die App, muss sie erreichen
+7. **Ausgabe und Ende** : Die RTE bündelt stdout und stderr jede halbe Sekunde oder alle 64 KB, mit maskierten Anmeldedaten, und nummeriert jedes
+   Bündel. Sie schreibt jedes Element in den Spool des Jobs auf ihrer Festplatte, bevor sie es sendet: die Ausgabe, die Ereignisse, das Job-Protokoll aus
+   `.joblogs/job_log_<id>.log` (alle 2 Sekunden), den Start und das Ende mit dem Endstatus (`success`, `failed` oder `aborted`). Die App
+   speichert jedes Element einmal und bestätigt es, und die RTE verwirft den Spool, sobald das Ende gespeichert ist. Jenseits von
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) Bytes auf einem Stream (standardmäßig 50 MB) sendet sie nichts mehr, und
+   das Playbook läuft weiter. Die App sendet dann die [Benachrichtigungen](../forms/notifications.html) des Formulars
+8. **Verfolgen** : Der Browser spricht nie mit der RTE: Die Formularseite liest den Job alle 2 Sekunden über die App neu, und die Seite Jobs
+   verfolgt ihn live, während die App jedes Element speichert
+
+**Ein abgerissener Socket.** Das Playbook läuft weiter. Die RTE wählt sich erneut ein (ausgehend), oder ein App-Knoten wählt sich erneut bei ihr ein (eingehend), und sie sendet erneut, was
+die App noch nicht bestätigt hatte: Die App überspringt, was sie bereits gespeichert hat, sodass keine Zeile verloren geht oder doppelt gespeichert wird. Das gilt, solange der Socket
+innerhalb von zwei Minuten zurück ist: Die App schreibt den Heartbeat der RTE nur, solange ihr Socket offen ist, und sobald dieser Heartbeat zwei Minuten
+alt ist, beendet der Worker die laufenden Jobs der RTE als verwaist, auch wenn ihre Playbooks noch laufen. Halten Sie den Spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) auf einem Volume, damit eine neu gestartete RTE noch sendet, was sie aufbewahrt hatte. Ein
+Playbook, das lief, als seine RTE neu startete, kann nicht weiterlaufen: Die App beendet seinen Job als verwaist, wenn die RTE ohne ihn zurückkommt.
+
+**Abbruch.** Ein Abbruch setzt das Abbruch-Flag des Jobs, und der App-Knoten, der den Socket der RTE hält, sendet innerhalb von zwei Sekunden `cancel`. Die RTE
+sendet `SIGTERM` an die Prozessgruppe des Playbooks, sodass `ansible-playbook` und jeder von ihm gestartete Fork gemeinsam anhalten, und der Job endet
+`aborted`. Ein Abbruch, der vor seinem Job eintrifft, wird eine Minute aufbewahrt, und der Job startet dann abgebrochen.
+
+**Aufräumen.** Sobald der Prozess endet, unabhängig vom Ergebnis, entfernt die RTE beide Extravars-Dateien (ein Formular mit `keepExtravars`
+behält die sichtbare, nie die versteckte), die Artefaktdatei in `/tmp`, die Job-Protokolldatei und den eigenen Dateiordner des Jobs. Das
+Ende wird einmal gespeichert: Ein zweiter Schreiber, etwa die App, die einen Job fehlschlagen lässt, den die RTE bereits beendet hat, ändert nichts.
+
+**Ein Prozess pro Job, nicht ein Container pro Job.** AWX und AAP starten für jeden Job einen neuen Pod oder Container aus einem Execution-Environment-Image.
+AnsibleForms startet nichts: Der RTE-Container läuft bereits, und jeder Job ist ein Kindprozess darin. Ein Job startet,
+ohne ein Image zu ziehen oder einen Pod einzuplanen, und AnsibleForms braucht keine Rechte auf Ihrer Container-Engine oder Ihrem Cluster. Im Gegenzug
+teilen sich die Playbooks, die auf einer RTE laufen, deren CPU, Speicher, `/tmp`, Home-Ordner und Python: Geben Sie dem Container genug Ressourcen für
+`RTE_MAX_JOBS` Playbooks mit ihren Forks. Um zu ändern, was ein Playbook verwenden kann, ändern Sie das Image, nicht den Job.
+
+---
+
+## Die Sicherheitsgrenze
+
+Die RTE führt Code aus, den Formularautoren geschrieben haben, daher ist sie so gebaut, dass sie so wenig wie möglich enthält:
+
+* **Nur ihr Token** : Die RTE hält keine Datenbank-Anmeldedaten und kein `ENCRYPTION_SECRET`. Sie nimmt keinen Aufruf an außer dem Socket der App, mit
+  ihrem Token, und hat keine Benutzer, keine Anmeldung und keine Webseiten. Über den Socket kann sie nur die Jobs ausführen, die die App ihr sendet, über sie berichten und
+  nach ihren Dateien fragen: Sie kann keinen Job anlegen, keinen anderen Job lesen und keine Anmeldedaten herausgeben
+* **Versiegelte Geheimnisse** : Um einen Job auszuführen, liest die RTE nie die Tabelle der Anmeldedaten oder einen Secret Store. Sie erhält die Geheimnisse der Jobs, die sie
+  ausführt, versiegelt nur für ihr Token und diese Job-ID, sodass sich ein Bündel für eine andere RTE oder einen anderen Job nicht öffnen lässt, und ein geändertes Byte
+  wird abgewiesen
+* **Eine geprüfte Verbindung** : Ausgehend prüft die RTE das Zertifikat der App. Eingehend über HTTPS pinnt die App beim Beitritt das eigene Zertifikat der RTE
+  und wählt sich nur ein, wenn sie dieses vorlegt (siehe [Modi](modes.html#inbound)). Eine eingehende RTE über einfaches HTTP gehört
+  in ein privates Netz, wie das des Docker Compose-Projekts
+* **Keine geerbte Umgebung** : `ansible-playbook` erhält die Umgebung der RTE ohne jede Variable, die AnsibleForms selbst liest
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, die `MYSQL_*`-Variablen und die anderen), sodass
+  `lookup('env', ...)` sie nicht erreicht. Was Sie für Playbooks setzen (`PATH`, Proxys, `ANSIBLE_*`), wird unverändert durchgereicht
+* **Keine Templates von Benutzern** : {% raw %}Ein Formularwert, der `{{`, `{%` oder `{#` enthält, erreicht das Playbook als unsicherer String,{% endraw %}
+  den Ansible nie als Template auswertet, es sei denn, das Formular setzt `allowJinjaInExtravars`, und keine Shell führt je die Befehlszeile aus
+* **Nicht root** : Die RTE und ihre Playbooks laufen als `node` (uid 1000), sodass ein Playbook tun kann, was dieser Benutzer im Container kann, etwa
+  seine Dateien und den SSH-Schlüssel lesen, und nicht mehr
+
+Behandeln Sie ihren Container, ihr Image und ihre Umgebung mit derselben Sorgfalt wie die der App.
+
+---
+
+## Datenbankmodus (veraltet)
+
+Die RTE von 7.0 bis 7.2, ohne `RTE_MODE`, läuft die ganze Reihe 7.x hindurch und wird in 8.0.0 entfernt. Sie unterscheidet sich in vier Punkten von den obigen Schritten:
+
+* **Sie hält die Datenbank** : ihre `DB_*`-Einstellungen und `ENCRYPTION_SECRET`, wenn sie sich selbst registriert
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **Die Übergabe ist ein HTTP-Aufruf** : Die App ruft `POST <address>/rte/v1/jobs` mit dem Token und den versiegelten Geheimnissen auf, und die RTE übernimmt
+  den Job, indem sie ihren Namen in der Datenbank daran schreibt (Schritte 3 und 4)
+* **Sie schreibt die Ausgabe selbst** : in die Datenbank, gebündelt, ohne Spool (Schritt 7). Ein Abbruch erreicht sie über das Abbruch-Flag des Jobs,
+  das sie alle 2 Sekunden liest, und einen Aufruf `/cancel`
+* **Sie liest die Dateien vom Volume der App** : Sie braucht dieselbe Festplatte wie die App, wie bei `RTE_FILES=local`
+
+Ihre Runner-Seite hat keine der [RTE-Einstellungen](../runners/runner-page.html#an-rtes-settings): Sie liest ihre eigenen Variablen. Um sie in einen
+Socket-Modus zu überführen, siehe [Modi](modes.html#database-deprecated).
diff --git a/i18n/de/_configure/rte/modes.md b/i18n/de/_configure/rte/modes.md
new file mode 100644
index 0000000..a85ae07
--- /dev/null
+++ b/i18n/de/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modi
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Wie eine RTE mit der App spricht
+{: .no_toc }
+
+Ausgehend, eingehend oder Datenbank: wer die Verbindung öffnet und was darüber läuft
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Seit 7.3.0 spricht eine RTE über einen WebSocket mit der App und hält keine Datenbank-Anmeldedaten. Wählen Sie den Modus,
+der zum Netz zwischen beiden passt: wer zu wem eine Verbindung öffnen darf und durch welche Proxys und Firewalls sie läuft.
+
+---
+
+## Die drei Modi
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) auf der RTE sagt, wie sie die App erreicht; ihr Runner hat denselben **Modus**:
+
+| Modus | Wer die Verbindung öffnet | Was die RTE hält | Für |
+|---|---|---|---|
+| `outbound` | Die RTE wählt sich unter [`APP_URL`](../customization/server.html#env_APP_URL) bei der App ein und hält einen WebSocket offen | Ihr `RTE_TOKEN`, keine Datenbank-Anmeldedaten | Eine DMZ, NAT oder eine Zone, die keine eingehenden Verbindungen erlaubt: Von außen erreicht nichts die RTE |
+| `inbound` | Die App wählt sich unter der Adresse ihres Runners bei der RTE ein und hält einen WebSocket offen | Ihr `RTE_TOKEN`, keine Datenbank-Anmeldedaten | Ein Netz, in dem die zentrale Seite jede Verbindung öffnet, ein Compose-Projekt, ein Pod |
+| `database` (veraltet) | Die App ruft die API der RTE über HTTP auf, und die RTE liest und schreibt selbst die Datenbank der App | Die Anmeldedaten der Datenbank (`DB_*`) und `ENCRYPTION_SECRET` | Das Verhalten von 7.0 bis 7.2, in 8.0.0 entfernt |
+
+Eine RTE ohne `RTE_MODE` läuft die ganze Reihe 7.x hindurch im Datenbankmodus und protokolliert bei ihrem Start die Warnung `[DEPRECATED] This RTE runs in database mode`.
+Ein vor 7.3.0 hinzugefügter Runner hat den Modus **Datenbank (veraltet)**; setzen Sie ihn auf den Modus, in dem seine RTE läuft, wenn Sie sie umstellen.
+
+---
+
+## Ausgehend
+
+Die RTE öffnet die Verbindung, daher funktioniert sie aus einem Netz, das überhaupt keine eingehende Verbindung annimmt:
+
+* **Der Socket** : Die RTE wählt `APP_URL` mit angehängtem `/api/v2/rte/socket` an, über `wss://` (`ws://` bei einer `http://`-Adresse), mit ihrem
+  `RTE_TOKEN` und dem Namen ihres Runners, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Sie wählt sich erneut ein, wenn der Socket abreißt
+* **Beim ersten Mal** : Sie bittet um Beitritt, und ihr Runner wartet unter **Verbindungen > Runner** auf die Freigabe eines Admins, verbunden,
+  aber ohne Jobs (siehe [Um Beitritt bitten](../runners/registration.html#asking-to-join)). Ein Beitrittstoken,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), gibt sie sofort frei. Danach meldet sie sich mit ihrem eigenen Token an
+* **Das Netz** : nur von der Zone der RTE zur App, auf dem Port der App, über einen Proxy, wenn `HTTPS_PROXY` das sagt. Ein Reverse
+  Proxy vor der App muss den WebSocket auf diesem Pfad durchlassen (siehe [Runner-WebSockets](../production/reverse-proxy.html#runner-websockets))
+* **Das Zertifikat** : Das Zertifikat der App wird geprüft. Nennen Sie eine private CA mit `NODE_EXTRA_CA_CERTS` oder schalten Sie die Prüfung, nur innerhalb eines
+  vertrauenswürdigen Netzes, mit [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) ab
+* **Der Runner** : Er braucht keine Adresse, daher enthalten seine RTE-Anmeldedaten nur das Token
+* **Bereit** : `/ready` antwortet mit `503`, bis der Socket zur App offen ist
+
+Mit mehreren App-Knoten hinter einem Load Balancer hält der Knoten, den die RTE erreicht, ihren Socket. Jeder Knoten kann einen Job starten: Der Knoten, der
+den Socket hält, sendet ihn an die RTE, innerhalb von zwei Sekunden, wenn der Job auf einem anderen Knoten gestartet wurde.
+
+---
+
+## Eingehend
+
+Die RTE lauscht auf ihrem `PORT`, und die App wählt sich unter der Adresse ihres Runners bei ihr ein, mit angehängtem `/rte/v1/socket` und dem Token der RTE. Bei
+mehreren App-Knoten hält jeweils einer den Socket jedes eingehenden Runners; hält dieser Knoten an, übernimmt ein anderer und wählt sich erneut ein.
+
+Die App braucht den Runner der RTE, bevor sie sich einwählen kann: Typ RTE, Modus **Eingehend** und RTE-Anmeldedaten mit der Adresse der RTE und ihrem
+`RTE_TOKEN`. Er entsteht auf einem von zwei Wegen:
+
+| Wie | Was zu setzen ist |
+|---|---|
+| Die RTE bittet um Beitritt | `APP_URL` und [`RTE_URL`](../customization/server.html#env_RTE_URL) (die Adresse, unter der die App sich einwählt). Die RTE macht einen Aufruf, `POST /api/v2/rte/register`, und ihr Runner wartet auf die Freigabe eines Admins: Die App wählt sich ein, sobald er freigegeben ist (siehe [Um Beitritt bitten](../runners/registration.html#asking-to-join)). Mit `RTE_JOIN_TOKEN` wird er sofort freigegeben. Eine eingehende RTE mit `APP_URL`, aber ohne `RTE_URL` verweigert den Start |
+| Sie fügen den Runner hinzu | Kein `APP_URL`: Fügen Sie den Runner unter **Verbindungen > Runner** oder im [Config-Seed](../seed/) hinzu, wie in [Eine RTE betreiben](run.html#start-it) |
+
+Das Docker Compose-Projekt, das Helm-Chart und der Controller des Installationsprogramms betreiben ihre eigene RTE auf diese Weise, eingehend, vom Seed deklariert.
+
+**Über HTTPS.** Mit [`HTTPS=1`](../customization/server.html#env_HTTPS) stellt die RTE ihren Socket über TLS bereit, mit Schlüssel und Zertifikat
+aus [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) und [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(standardmäßig `key.pem` und `cert.pem` in ihrem Ordner `certificates`). Eine RTE mit einer `https://`-`RTE_URL` sendet dieses Zertifikat, wenn sie
+um Beitritt bittet, und die App pinnt es: Sie wählt sich nur bei der RTE ein, wenn diese dasselbe Zertifikat vorlegt, daher funktioniert ein selbstsigniertes ohne CA.
+Die RTE protokolliert beim Start den Fingerabdruck des Zertifikats (die ersten 8 Hexadezimalziffern des SHA-256 seiner DER-Bytes, als `abcd-ef12`),
+und der Freigabedialog zeigt den, den die App erhalten hat: Prüfen Sie, dass sie übereinstimmen, bevor Sie freigeben.
+Das [Installationsprogramm](../installation/installer.html#a-runner) richtet seine eingehenden Runner so ein, mit einem Zertifikat für ihre eigene Adresse.
+
+---
+
+## Datenbank (veraltet)
+
+Die RTE von 7.0 bis 7.2: Die App ruft ihre API über HTTP auf, und die RTE übernimmt den Job in der Datenbank, schreibt die Ausgabe dort und hält ihre
+eigene Runner-Zeile aktuell, mit [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Datenbankmodus](./#database-mode-deprecated)
+beschreibt, wie sich ihre Schritte unterscheiden. Sie funktioniert in 7.x weiterhin, mit einer Warnung bei jedem Start, und wird in 8.0.0 entfernt.
+
+Um eine solche RTE in einen Socket-Modus zu überführen, behalten Sie ihren Runner und ihr Token:
+
+1. Ein Runner des [Config-Seeds](../seed/): Setzen Sie zuerst im Seed `rte_mode: outbound` oder `rte_mode: inbound` für ihn (eingehend: mit
+   der Adresse, unter der sich die App einwählt, in der `url` seiner Anmeldedaten). Die RTE kann einen Runner aus dem Seed nicht selbst umstellen
+2. Setzen Sie auf der RTE `RTE_MODE=outbound` mit `APP_URL` oder `RTE_MODE=inbound` (mit `APP_URL` und `RTE_URL`, damit sie ihren einen
+   Registrierungsaufruf macht), und setzen Sie [`RTE_NAME`](../customization/server.html#env_RTE_NAME) auf den Namen, den ihr Runner unter
+   **Verbindungen > Runner** hat. Behalten Sie ihr `RTE_TOKEN`
+3. Entfernen Sie `DB_*` und `ENCRYPTION_SECRET` aus ihrer Umgebung sowie `RTE_REGISTER`, das nur der Datenbankmodus liest, und starten Sie sie dann neu
+
+Meldet sich die aktualisierte RTE mit dem Namen des Runners und dem eigenen Token des Runners an, stellt die App diesen Runner sofort
+auf den Modus der RTE um, ohne Freigabe, und protokolliert *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. Der Runner ist dann keine Zeile mehr, die seine RTE registriert hat, daher entfernt ihn der Worker nie, wenn der alte Container nicht mehr antwortet. Ein
+Runner des Config-Seeds, der noch im Datenbankmodus ist, wird stattdessen abgewiesen, mit *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. Verwenden Sie dafür kein Beitrittstoken: Ein
+Beitrittstoken wird für einen bereits freigegebenen Runner abgewiesen. Eine eingehende RTE ohne `APP_URL` macht keinen Aufruf: Setzen Sie stattdessen den **Modus** ihres Runners unter
+**Verbindungen > Runner** auf **Eingehend**, und die App wählt sich bei ihr ein. Das [Installationsprogramm](../installation/installer.html#a-72-runner)
+aktualisiert einen Runner aus 7.2 auf diese Weise.
+
+---
+
+## Was über den Socket läuft
+
+In beiden Socket-Modi sendet die App der RTE jeden Job mit allem, was die RTE früher in der Datenbank las, und speichert, was zurückkommt,
+die Ausgabe, die Ereignisse, das Job-Protokoll und das Ende, genau einmal. Die App sendet auch die Benachrichtigungen zum Ende.
+
+**Der Spool.** Jedes Ausgabebündel, Ereignisbündel, Protokoll, jeder Start und jedes Ende wird nummeriert und in die Spool-Datei des Jobs
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) geschrieben, bevor es gesendet wird, und aufbewahrt, bis die App meldet, dass sie es gespeichert hat.
+Nach einer Neuverbindung, zum selben App-Knoten oder zu einem anderen, sendet die RTE erneut, was nicht bestätigt wurde, und die App überspringt, was sie bereits
+gespeichert hat: Nichts geht verloren, und nichts wird doppelt gespeichert. Halten Sie den Spool auf einem Volume, damit eine neu gestartete RTE noch sendet, was sie nicht
+ausgeliefert hatte. Ein Playbook, das lief, als die RTE neu startete, kann nicht weiterlaufen: Sein Job endet als verwaist.
+
+**Kapazität.** Die RTE führt bis zu [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) Playbooks gleichzeitig aus, oder den Wert, der
+auf ihrer [Runner-Seite](../runners/runner-page.html#an-rtes-settings) gesetzt ist, und meldet der App alle 20 Sekunden, wie viele laufen. Ein Job für eine volle
+RTE wartet, wie unter [Mehrere RTEs](several.html#several-jobs-on-one-rte) beschrieben.
+
+**Die Dateien des Jobs.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES) oder die Einstellung **Jobdateien** auf ihrer Runner-Seite sagt,
+woher die RTE die Playbooks und Inventare bezieht:
+
+| `RTE_FILES` | Woher die Dateien kommen |
+|---|---|
+| `transfer` (Standard) | Die App sendet den Playbook-Ordner und die Inventare mit dem Job, jeweils gepackt und nach einem Hash ihres Inhalts benannt. Die RTE bewahrt sie gepackt unter [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) auf, die zuletzt verwendeten bis zu [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (standardmäßig 1024 MB), und fragt nur nach einem Hash, den sie nicht hat: Ein unveränderter Ordner wird nie zweimal gesendet. Die RTE braucht keine gemeinsame Festplatte und keinen Zugriff auf die Repositories |
+| `local` | Die RTE arbeitet aus ihren eigenen Ordnern, wie eine RTE im Datenbankmodus: Hängen Sie die Playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) und die Repositories ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) bei ihr ein |
+
+Mit `transfer` entpackt jeder Job seine Dateien in einen eigenen privaten Ordner, der beim Ende des Jobs entfernt wird: Kein Job sieht, was ein anderer
+geschrieben hat, und keine Inventar- oder Extravars-Datei bleibt entpackt auf der Festplatte der RTE. RTEs können sich ein `RTE_CACHE_PATH` teilen; jede hält ihre Jobs in
+einem eigenen Ordner, und der Ordner einer RTE, die angehalten hat (mitten im Job beendet oder mit einem anderen Hostnamen neu erstellt), wird von den anderen
+nach 10 Minuten entfernt. Ein Ordner, der größer ist als [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (standardmäßig 512, von
+der App gelesen, ohne Neustart angewendet), wird nicht gesendet: Der Job schlägt fehl und sagt, dass der Ordner stattdessen bei der RTE eingehängt werden soll. Der ssh-Ordner wird nie gesendet: Die RTE behält ihren eigenen
+privaten Schlüssel und ihre `known_hosts` in `/home/node/.ssh`.
+
+**Hosts und Tasks.** Seit 7.3.0 erfasst eine RTE in jedem Modus die strukturierten Ereignisse eines Playbooks neben seiner Textausgabe: jedes Play, jeden Task und
+jedes Host-Ergebnis sowie die Zusammenfassung, geschrieben von ihrem Callback-Plugin `af_events`. Die Jobseite zeigt sie unter **Hosts und Tasks** (siehe
+[Einen Job verfolgen](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Netzwerk
+
+Was zwischen der App, der RTE und den verwalteten Hosts zu öffnen ist, pro Modus:
+
+| Modus | Von | Nach | Port |
+|---|---|---|---|
+| Ausgehend | Die RTE | Die App, unter `APP_URL` | Der Port der App (`443` hinter den meisten Proxys) |
+| Eingehend | Die App-Knoten | Die RTE, unter der Adresse ihres Runners | Der `PORT` der RTE (`8000`) |
+| Datenbank (veraltet) | Die RTE sowie die App-Knoten und der Worker | Die Datenbank und die RTE | `3306` und der `PORT` der RTE |
+| Jeder Modus | Die RTE | Die verwalteten Hosts | ssh (`22`), WinRM, ihre APIs |
+
+In einem Socket-Modus verbindet sich die RTE nie mit der Datenbank. Ihre API beantwortet nur den Socket und die Probes: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/de/_configure/rte/run.md b/i18n/de/_configure/rte/run.md
new file mode 100644
index 0000000..4eb95f9
--- /dev/null
+++ b/i18n/de/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Eine RTE betreiben
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Eine RTE betreiben
+{: .no_toc }
+
+Die Einstellungen jedes Modus und wie man eine RTE startet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Einstellungen
+
+Was eine RTE braucht, hängt von ihrem Modus ab (siehe [Modi](modes.html)). Jede RTE liest diese:
+
+| Variable | Bedeutung |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Seit 7.3.0: `outbound` (sie wählt sich bei der App ein), `inbound` (die App wählt sich bei ihr ein) oder `database` (veraltet, der Standard in ganz 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Das Token zwischen der App und der RTE, mindestens 16 Zeichen; ohne es verweigert die RTE den Start |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Wie viele Playbooks sie gleichzeitig ausführt, standardmäßig `10` (`0` setzt keine Grenze). Ein Job für eine volle RTE wartet, bis ein Playbook endet |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Wie lange sie beim Anhalten auf ihre laufenden Playbooks wartet, standardmäßig `25`; die dann noch laufenden enden als verwaist |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Von den App-Knoten und dem Worker gelesen, nicht von der RTE: wie lange ein Job auf eine volle oder anhaltende RTE wartet, standardmäßig `60` |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | Der Playbook-Ordner und die Ausgabegrenze: von der RTE gelesen, setzen Sie sie also in ihrer Umgebung |
+| `LISTEN_HOST` | Seit 7.3.0: die Adresse, an die sich ihre Listener binden, standardmäßig jede Schnittstelle; `127.0.0.1`, wenn sich niemand von außen bei ihr einwählt (eine ausgehende RTE) |
+
+Eine RTE in einem Socket-Modus, `outbound` oder `inbound`, liest außerdem diese, und kein `DB_*` und kein `ENCRYPTION_SECRET`:
+
+| Variable | Bedeutung |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Die Adresse der App, wie Benutzer sie öffnen, etwa `https://forms.example.com`. Ausgehend: die Adresse, bei der sie sich einwählt. Eingehend: die Adresse ihres einen Registrierungsaufrufs |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (Standard): Das Zertifikat der App muss gültig sein. `0` akzeptiert jedes, nur innerhalb eines vertrauenswürdigen Netzes |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Der Name ihres Runners, den Formulare mit `runner:` nennen. Nicht gesetzt: ihre Knoten-ID, `rte-<hostname>-<port>`, die sich mit dem Container ändert: Setzen Sie ihn in Produktion |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Optional, nur beim ersten Mal: ein über die API erstelltes Beitrittstoken, das ihren Runner sofort freigibt, statt auf einen Admin zu warten (siehe [Beitrittstoken](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Eingehend, wenn sie um Beitritt bittet: die Adresse, unter der sich die App einwählt, etwa `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (Standard): Die App sendet die Playbooks und Inventare mit dem Job. `local`: Sie arbeitet aus ihren eigenen eingehängten Ordnern |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Wo Ausgabe, Ereignisse und Ende jedes Jobs warten, bis die App sie gespeichert hat, standardmäßig `<persistent>/rte-spool`: Halten Sie es auf einem Volume |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Mit `transfer`: wo die von der App gesendeten Ordner aufbewahrt werden, standardmäßig `<persistent>/rte-files` |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Mit `transfer`: wie viel Platz diese Ordner belegen dürfen, standardmäßig `1024`; die am längsten nicht verwendeten gehen zuerst, und `0` behält keine |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Von der App gelesen, nicht von der RTE: der größte Ordner, den sie mit `transfer` sendet, standardmäßig `512` |
+
+Bei einer RTE in einem Socket-Modus lassen sich `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` und `RTE_CACHE_MB` auch auf ihrer Runner-Seite setzen,
+im Tab RTE: Ein Wert dort gewinnt über die Variable, die dann nur ein leer gelassenes Feld füllt (siehe
+[Die Einstellungen einer RTE](../runners/runner-page.html#an-rtes-settings)). Ein Wert außerhalb des Bereichs wird auf seine Grenze gesetzt, und die RTE meldet das
+beim Start.
+
+Eine RTE im Datenbankmodus (veraltet) liest stattdessen die Datenbankeinstellungen und registriert sich selbst:
+
+| Variable | Bedeutung |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Die eigenen Werte der App: Die RTE liest ihre Jobs aus der Datenbank und schreibt deren Ausgabe dorthin |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Die Adresse, unter der die App die RTE aufruft, etwa `http://rte:8000`. Der Runner wird nach seinem Host benannt (`rte`), sodass Formulare `runner: rte` verwenden können |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | In 7.3.0 veraltet, zusammen mit dem Datenbankmodus: Eine RTE im Socket-Modus tritt stattdessen mit einem Beitrittstoken bei. `1` (Standard): Die RTE fügt sich bei ihrem Start selbst unter **Verbindungen > Runner** hinzu, und die erste wird zum Standard-Runner. `0`: Fügen Sie sie dort selbst hinzu oder im [Config-Seed](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Der eigene Wert der App, nur zum Selbstregistrieren nötig (das Token des Runners wird verschlüsselt gespeichert); lassen Sie es mit `RTE_REGISTER=0` weg |
+
+Im Datenbankmodus registriert die RTE ohne `RTE_URL` ihre IP-Adresse und ihren Port unter dem Namen `rte-<hostname>-<port>`, die sich ändern, wenn
+der Container neu erstellt wird: Setzen Sie `RTE_URL` in Produktion. Der Worker entfernt einen Runner, den die RTE selbst registriert hat, 10 Minuten nach dem
+letzten Heartbeat der RTE.
+
+---
+
+## Starten
+
+Die RTE führt die Playbooks aus, daher braucht sie ihren ssh-Ordner mit dem privaten Schlüssel und den `known_hosts`, die die Playbooks verwenden, sowie einen persistenten
+Ordner für ihren Spool und die Dateien, die die App sendet. Wählen Sie den Modus:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Ausgehend</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Eingehend</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Datenbank (veraltet)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Starten Sie die RTE auf einem beliebigen Host, der die App erreicht, mit ihrem eigenen Token und dem Namen, den ihr Runner erhält:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Sie wählt sich bei der App ein und bittet um Beitritt: **Verbindungen > Runner** zeigt den Runner `rte-dmz` als wartend auf Freigabe, und ihr Protokoll zeigt
+den Fingerabdruck ihres Tokens. Prüfen Sie, dass ihre Prüfansicht denselben Fingerabdruck zeigt, und geben Sie sie dann mit **Freigeben** frei (siehe
+[Eine RTE freigeben](../runners/registration.html#approving-an-rte)): Ab dann erhält sie Jobs und meldet sich mit ihrem eigenen `RTE_TOKEN` an.
+Für einen unbeaufsichtigten Start fügen Sie `-e RTE_JOIN_TOKEN=<a join token, afj_...>` hinzu, das sie sofort freigibt. Nichts muss diesen
+Host erreichen: Veröffentlichen Sie keinen Port. Auf ihrem `PORT` lauschen nur `/live`, `/ready` und `/metrics`, für die Probes.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Starten Sie die RTE dort, wo die App sie erreicht. Diese läuft neben der App und führt die Playbooks aus deren Ordnern aus (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Geben Sie der App dann ihren Runner: im [Config-Seed](../seed/) RTE-Anmeldedaten und einen eingehenden Runner, der sich damit anmeldet:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Oder fügen Sie dieselben beiden von Hand hinzu: die Anmeldedaten unter **Verbindungen > Anmeldedaten**, Typ RTE, und den Runner unter
+**Verbindungen > Runner**, Typ RTE, Modus **Eingehend**, mit diesen Anmeldedaten. Damit die RTE stattdessen um Beitritt bittet, starten Sie sie mit
+`APP_URL` und `RTE_URL` und geben sie unter **Verbindungen > Runner** frei (siehe [Eingehend](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Seit 7.3.0 veraltet und in 8.0.0 entfernt. Die RTE führt die Playbooks von ihrer eigenen Festplatte aus, hängen Sie daher das persistente Volume der App
+(Playbooks, Repositories, Uploads) und ihren ssh-Ordner ebenfalls bei ihr ein. Ein Docker-Beispiel, mit der App erreichbar als `ansibleforms` im
+selben Netz:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Halten Sie eine eingehende RTE aus dem öffentlichen Netz heraus: Ihr Socket antwortet jedem Aufrufer, der das Token hat. `docker stop` wartet nur 10 Sekunden, bevor
+es einen Container beendet, geben Sie der RTE daher ein längeres Stop-Timeout (`--stop-timeout` oder `stop_grace_period` in Compose) oder senken Sie
+`RTE_DRAIN_SECONDS`. Kubernetes wartet standardmäßig 30 Sekunden.
+
+Das [Installationsprogramm](../installation/installer.html) richtet eine ausgehende oder eingehende RTE auf einem eigenen Server ein, mit Docker, Podman oder
+[ohne Container](../installation/native.html), und gibt den Fingerabdruck aus, anhand dessen Sie sie freigeben. Um eine RTE in einem anderen Rechenzentrum
+von Hand zu betreiben, folgen Sie [Ein anderes Rechenzentrum](another-datacenter.html).
diff --git a/i18n/de/_configure/rte/several.md b/i18n/de/_configure/rte/several.md
new file mode 100644
index 0000000..c45ff78
--- /dev/null
+++ b/i18n/de/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Mehrere RTEs
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Mehrere RTEs
+{: .no_toc }
+
+Wie viele Playbooks eine RTE ausführt, weitere RTEs als Runner oder Replikate und was passiert, wenn eine anhält oder ausfällt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Mehrere Jobs auf einer RTE
+
+Eine RTE führt bis zu [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) Playbooks nebeneinander aus, standardmäßig 10
+(`0` setzt keine Grenze). Ein Job für eine volle RTE wird nicht übernommen. In einem Socket-Modus sendet die App ihn nicht, solange der letzte
+Zustandsbericht der RTE keinen freien Platz zeigt, und eine RTE, die voll ist oder anhält, antwortet `refused` als ausgelastet; im Datenbankmodus antwortet die RTE
+mit `503`. In beiden Fällen schreibt die App einmal `Waiting for a free slot on RTE <name>` in die Ausgabe und bietet den Job alle 10 Sekunden erneut an,
+höchstens [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) lang (standardmäßig 60). Dann schlägt der Job fehl mit
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Ein Job, der während des Wartens abgebrochen wird, endet `aborted`, ohne je
+die RTE zu erreichen.
+
+---
+
+## Mehrere RTEs
+
+Die App verteilt Jobs nicht selbst auf Runner: Jeder Job geht an einen Runner, den, den das Formular nennt, oder den
+Standard-Runner. Mehr RTE-Container helfen auf zwei Arten:
+
+* **Als eigene Runner** : Jede RTE hat ihren eigenen `RTE_NAME` und tritt als eigener Runner bei: Sie bittet um Beitritt und ein Admin
+  gibt sie frei, oder sie legt ein Beitrittstoken vor (siehe [Registrierung](../runners/registration.html)). Ein Formular wählt eine mit `runner: <name>`,
+  zum Beispiel eine RTE mit den VMware-Collections oder eine in einer anderen Netzwerkzone; die anderen laufen auf der Standard-RTE
+* **Als Replikate hinter einer Adresse** (nur Datenbankmodus) : Mehrere RTE-Container mit derselben `RTE_URL` und demselben `RTE_TOKEN`,
+  etwa die Pods hinter einem Kubernetes-Service, teilen sich einen Runner, und die Adresse verteilt die Aufrufe auf sie. Ein volles Replikat antwortet
+  mit `503`, und der nächste Versuch landet vielleicht bei einem anderen. Die App verfolgt einen Job über die Datenbank, daher spielt es keine Rolle, welches Replikat
+  ihre Statusaufrufe beantwortet
+
+In einem Socket-Modus (siehe [Modi](modes.html)) hält ein Runner einen Socket zu einer RTE, und eine zweite RTE, die sich mit demselben
+`RTE_NAME` anmeldet, übernimmt den Socket von der ersten. Geben Sie jeder RTE einen eigenen Namen und einen eigenen Runner, und lassen Sie Formulare mit
+`runner:` zwischen ihnen wählen.
+
+Jede RTE im Datenbankmodus schreibt alle 10 Sekunden einen Heartbeat in die Datenbank, und eine, die sich selbst registriert, prüft ihre Runner-Zeile alle
+30 Sekunden. Für eine RTE in einem Socket-Modus schreibt der App-Knoten, der ihren Socket hält, alle 20 Sekunden den Heartbeat für sie, solange der
+Socket offen ist. Die Seite **Status** listet jede RTE mit ihrer Version auf. Der Worker entfernt einen Runner, den eine RTE im Datenbankmodus selbst registriert hat,
+sobald diese RTE 10 Minuten lang keinen Heartbeat geschrieben hat, und wenn der Standard-Runner eine solche Zeile ist, deren RTE angehalten hat, übernimmt die nächste RTE,
+die prüft, den Standard. Ein Runner aus dem Config-Seed, von Hand hinzugefügt oder über einen Socket beigetreten, wird auf diese Weise nie entfernt.
+
+---
+
+## Wenn eine RTE anhält oder ausfällt
+
+**Wenn eine RTE anhält.** Bei `SIGTERM` (`docker stop`, ein Rolling Update, ein Herunterskalieren) nimmt die RTE keine Jobs mehr an: `/ready` antwortet mit `503`,
+und ein neuer Job wird als ausgelastet abgewiesen (`503` im Datenbankmodus), sodass die App wartet oder im Datenbankmodus die Adresse ihn an ein anderes
+Replikat sendet. Die laufenden Playbooks erhalten [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS), um fertig zu werden, standardmäßig 25,
+dann beendet sich die RTE.
+
+**Wenn eine RTE ausfällt.** Ein beendeter Container (Speicher erschöpft, ein verlorener Knoten, das Ende des Stop-Timeouts) nimmt seine Playbooks mit: Nichts
+verschiebt sie auf eine andere RTE, und nichts führt sie erneut aus. Ihre Jobs werden als `abandoned` beendet, von der RTE selbst oder von der App, wenn sie
+unter derselben ID zurückkommt, die ein neu gestarteter Container behält (`rte-<hostname>-<port>`), oder vom Worker, sobald der Heartbeat der RTE
+zwei Minuten alt ist. Prüfen Sie auf den verwalteten Hosts, was das Playbook getan hat, bevor Sie es erneut starten.
+
+**Solange eine RTE ausgefallen ist.** In einem Socket-Modus wartet ein neuer Job für sie auf ihren Socket, bis zu `RTE_QUEUE_MINUTES` und eine weitere Minute, und schlägt dann
+fehl mit *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+Im Datenbankmodus schlägt er sofort fehl mit *the RTE at ... is unreachable*, es sei denn, ein anderes Replikat antwortet unter ihrer Adresse.
diff --git a/i18n/de/_configure/runners.md b/i18n/de/_configure/runners.md
new file mode 100644
index 0000000..7391871
--- /dev/null
+++ b/i18n/de/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Runner
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runner
+{: .no_toc }
+
+Wo Jobs laufen: Laufzeitumgebungs-Container für Playbooks sowie AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins für Templates
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Fügen Sie die Runner hinzu, auf denen Ihre Jobs laufen, wählen Sie den Standard jedes Typs, geben Sie die RTEs frei, die um Beitritt bitten, und testen Sie sie.
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Die Seite Runner](runners/list.html) | Die Liste der Runner, einen hinzufügen, einen ein- oder ausschalten, und der Standard jedes Typs |
+| [Runner-Typen](runners/types.html) | Die Produkte, die ein Runner sein kann, ihre Adresse und Anmeldung |
+| [Registrierung](runners/registration.html) | Wie eine RTE um Beitritt bittet und freigegeben wird, Beitrittstoken für unbeaufsichtigte Installationen und der Datenbankmodus |
+| [Die Seite eines Runners](runners/runner-page.html) | Die Tabs eines Runners, Modus und Verbindung einer RTE und Verbindung testen |
+| [Wer Runner verwaltet](runners/permissions.html) | Wer Runner hinzufügen, ändern und testen darf |
+
+
+---
+
+## Funktionsweise
+
+Seit Version 7 führt die App selbst nichts aus: Jeder Job läuft auf einem **Runner**, angelegt unter **Verbindungen > Runner**.
+Der Typ eines Formulars bestimmt, welchen Runner-Typ es braucht:
+
+| Formulartyp | Läuft auf einem Runner vom Typ | Was läuft |
+|---|---|---|
+| `ansible` | RTE | Ein Playbook, in einem Laufzeitumgebungs-Container |
+| `awx`, `aap`, `ascender` | AWX (die Varianten AWX, AAP und Ascender) | Ein Job- oder Workflow-Template |
+| `semaphore` | Semaphore | Ein Semaphore UI-Template |
+| `rundeck` | Rundeck | Ein Rundeck-Job |
+| `jenkins` | Jenkins | Ein Jenkins-Job |
+
+Ein Formular vom Typ `workflow` oder `subform` hat keinen eigenen Runner: Jeder Knoten eines [Workflows](workflows/) wählt seinen eigenen. Ein Knoten
+mit `runner:` läuft auf diesem Runner (einer RTE oder einem Template oder Job auf AWX, Semaphore, Rundeck oder Jenkins), jeder andere auf
+der Standard-RTE, sodass die Knoten eines Jobs auf verschiedenen Runnern laufen können. Das Formular `multistep`, seit 7 veraltet und
+durch Workflows ersetzt, funktioniert genauso: Jeder seiner Schritte läuft auf dem Runner, den sein eigener Typ braucht.
+
+Ein Formular wählt seinen Runner auf eine von zwei Arten:
+
+- **Nach Namen**: `runner: <name>` am Formular, an einem Workflow-Knoten oder an einem Schritt eines veralteten Multistep (auch in den
+  Formulareinstellungen des Designers). Der Runner muss den Typ haben, den das Formular braucht, sonst schlägt der Job fehl. Das ältere `awx: <name>`
+  funktioniert weiterhin, protokolliert eine Veraltungswarnung und entfällt in 8.
+- **Als Standard**: Ein Formular, das keinen Runner nennt, läuft auf dem Standard-Runner seines Typs. Gibt es keinen, schlägt der Job fehl,
+  mit einer Meldung, die sagt, welcher Runner-Typ hinzuzufügen ist.
+
+Ein unter **Verbindungen > Runner** ausgeschalteter Runner erhält keinen Job, weder nach Namen noch als Standard: Der Job schlägt fehl und sagt, man solle ihn aktivieren
+oder einen anderen Runner nennen (siehe [Standard und Aktiviert](runners/list.html#default-and-enabled)).
+
diff --git a/i18n/de/_configure/runners/list.md b/i18n/de/_configure/runners/list.md
new file mode 100644
index 0000000..bc577b7
--- /dev/null
+++ b/i18n/de/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: Die Seite Runner
+parent: Runner
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# Die Seite Runner
+{: .no_toc }
+
+Die Liste der Runner, einen hinzufügen, einen ein- oder ausschalten, und der Standard jedes Typs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Liste
+
+Die Seite unter **Verbindungen > Runner** listet jeden Runner mit diesen Spalten auf:
+
+| Spalte | Bedeutung |
+|---|---|
+| Aktiviert | Ob er Jobs annimmt. Ein ausgeschalteter Runner erhält keinen Job, auch nicht als Standard seines Typs. |
+| Name | Wie Formulare auf ihn verweisen, mit `runner: <name>`. |
+| Typ | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck oder Jenkins. Der Standard-Runner seines Typs hat danach eine Pille **Standard**. |
+| Beschreibung | Wofür er ist. |
+
+**Spalten** fügt zwei weitere hinzu, standardmäßig aus: **Modus**, der Modus einer RTE (Ausgehend, Eingehend oder Datenbank (veraltet), siehe
+[Modi](../rte/modes.html)), und **Verbindung**, ob ein App-Knoten einen Socket zu einer RTE in einem Socket-Modus hält: **Verbunden** oder
+**Nicht verbunden**.
+
+Ab 7.3.0 stehen die auf Freigabe wartenden Runner nicht in der Liste, sondern in einem Hinweis darüber, siehe [Eine RTE freigeben](registration.html#approving-an-rte).
+**Runner hinzufügen** öffnet einen Dialog in Schritten: **Runner** (Name und Beschreibung), **Typ** und **Anmeldedaten**, bei einer RTE mit einem Schritt **Modus** nach
+**Typ** (Ausgehend, der Standard für eine neue, Eingehend oder Datenbank (veraltet)): vier Schritte für eine RTE, drei für die
+anderen. Im Schritt **Typ** hat jedes Produkt einen Hinweis: Der der RTE nennt ihren vollen Namen, *Laufzeitumgebung*. Eine Zeile öffnet die eigene Seite des
+Runners, und ihr Menü bietet:
+
+| Aktion | Was sie tut |
+|---|---|
+| Bearbeiten | Öffnet seine Seite |
+| Verbindung testen | Prüft, dass er antwortet und seine Anmeldedaten akzeptiert, siehe [Verbindung testen](runner-page.html#test-connection) |
+| Aktivieren, Deaktivieren | Schaltet ihn ein oder aus, je nachdem, was er nicht ist |
+| Anmeldeinformationen ändern | Öffnet den Tab Anmeldedaten seiner Seite |
+| Löschen | Entfernt ihn |
+
+---
+
+## Standard und Aktiviert
+
+Der Standard jedes Typs ist der Ort, an dem die Formulare dieses Typs laufen, wenn sie keinen Runner nennen:
+
+| Standard für | Wo diese Formulare laufen, wenn sie keinen Runner nennen |
+|---|---|
+| Playbook-Formulare | `ansible`-Formulare, auf einer RTE |
+| AWX-, AAP- und Ascender-Formulare | `awx`-, `aap`- und `ascender`-Formulare, auf einem AWX-Runner |
+| Semaphore-Formulare | `semaphore`-Formulare |
+| Rundeck-Formulare | `rundeck`-Formulare |
+| Jenkins-Formulare | `jenkins`-Formulare |
+
+Der erste Runner eines Typs wird zu dessen Standard, daher braucht ein einzelner Runner pro Typ keinen zusätzlichen Schritt. Um einen anderen Runner zum Standard zu machen,
+schalten Sie auf seiner Seite den Schalter **Standard** ein (siehe [Die Seite eines Runners](runner-page.html)).
+
+Ein ausgeschalteter Runner bleibt mit seinen Einstellungen in der Liste, aber kein Job geht an ihn, auch nicht als Standard seines Typs. Ein Job für ihn schlägt fehl mit
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Schalten Sie ihn mit **Aktivieren** oder **Deaktivieren** im Menü seiner Zeile oder mit dem Schalter **Aktiviert** auf seiner Seite ein oder aus. Ein neuer Runner ist eingeschaltet, und die
+Runner, die vor 7.3.0 existierten, sind nach dem Upgrade eingeschaltet. Der [Config-Seed](../seed/example.html) kann einen mit
+`enabled: false` ausschalten.
diff --git a/i18n/de/_configure/runners/permissions.md b/i18n/de/_configure/runners/permissions.md
new file mode 100644
index 0000000..6003af0
--- /dev/null
+++ b/i18n/de/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Wer Runner verwaltet
+parent: Runner
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Wer Runner verwaltet
+{: .no_toc }
+
+Wer Runner hinzufügen, ändern und testen darf
+{: .fs-6 .fw-300 }
+
+Ein Runner erhält die Anmeldedaten jedes Jobs, den er ausführt, daher fügt nur die Rolle **admin** Runner hinzu, ändert sie, schaltet sie ein oder aus und löscht sie,
+und gibt eine RTE, die um Beitritt gebeten hat, frei oder lehnt sie ab. Benutzer mit Zugriff auf die Einstellungen sehen sie und können sie testen, aber nicht ändern.
+
+Ein im [Config-Seed](../seed/) deklarierter Runner ist auf dieser Seite schreibgeschützt: Ändern Sie ihn stattdessen in der Seed-Datei.
diff --git a/i18n/de/_configure/runners/registration.md b/i18n/de/_configure/runners/registration.md
new file mode 100644
index 0000000..e1f0446
--- /dev/null
+++ b/i18n/de/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Registrierung
+parent: Runner
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Registrierung
+{: .no_toc }
+
+Wie eine RTE um Beitritt bittet und freigegeben wird, Beitrittstoken für unbeaufsichtigte Installationen und der Datenbankmodus
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Um Beitritt bitten
+
+Seit 7.3.0 bittet eine RTE in einem Socket-Modus (`outbound` oder `inbound`), die die App noch nicht kennt, um Beitritt, und ein Admin gibt sie frei.
+Sie meldet sich mit ihrem eigenen `RTE_TOKEN` und ihrem `RTE_NAME`: eine ausgehende RTE, wenn sie sich zum ersten Mal bei der App einwählt, eine eingehende in ihrem einen
+Registrierungsaufruf. Ohne Beitrittstoken tut die App dann Folgendes:
+
+1. Sie speichert das `RTE_TOKEN` der RTE in neuen Anmeldedaten vom Typ RTE namens `<name>-rte` (mit angehängter Nummer, wenn der Name vergeben ist) und
+   bei einer eingehenden RTE deren Adresse, `RTE_URL`
+2. Sie fügt einen nach `RTE_NAME` benannten Runner hinzu, Typ RTE, im Modus der RTE, der sich mit diesen Anmeldedaten anmeldet, markiert als **Wartet auf Freigabe**
+   und ausgeschaltet. Seine Beschreibung nennt den Host, von dem die Anfrage kam
+
+Eine ausgehende RTE bleibt verbunden, während sie wartet, erhält aber keinen Job. Bei einer eingehenden wählt sich die App erst ein, wenn sie freigegeben ist. Beide protokollieren,
+dass sie darauf warten, dass ein Admin sie unter **Verbindungen > Runner** freigibt, mit dem Fingerabdruck ihres Tokens.
+
+Eine eingehende RTE mit einer `https://`-`RTE_URL` sendet beim Bitten um Beitritt außerdem ihr Zertifikat, und die App pinnt es: Ab dann
+wählt sich die App bei dieser RTE nur ein, wenn sie dasselbe Zertifikat vorlegt, daher funktioniert ein selbstsigniertes ohne CA (siehe [Eingehend](../rte/modes.html#inbound)).
+
+Höchstens 20 RTEs warten gleichzeitig auf Freigabe: Weitere werden abgewiesen, bis einige freigegeben oder abgelehnt sind. Eine Anfrage, die niemand innerhalb von
+24 Stunden bearbeitet, wird vom Worker entfernt, samt ihren Anmeldedaten.
+
+Eine RTE, die nach einem Runner benannt ist, den die App bereits kennt, aber ein anderes Token hat, wird abgewiesen und bittet nicht um Beitritt. Geben Sie ihr das Token
+dieses Runners oder löschen Sie den Runner, damit sie um Beitritt bittet. Ein [Beitrittstoken](#join-tokens) hilft nur, solange dieser Runner noch auf Freigabe wartet.
+
+---
+
+## Eine RTE freigeben
+
+Die auf Freigabe wartenden Runner verlassen die Liste von **Verbindungen > Runner** und erscheinen in einem orangefarbenen Hinweis darüber, etwa
+**2 Runner warten auf Freigabe**, mit einer Zeile pro Runner: Name, Host, IP-Adresse, Modus, Adresse und Fingerabdruck.
+Die Glocke in der Kopfzeile zählt sie, für die Benutzer, die die Runner sehen können (siehe [die Glocke](../jobs/#the-jobs-page)).
+
+Ein Klick auf den Hinweis öffnet den Dialog **Genehmigung prüfen** für jeden Runner nacheinander; ein Klick auf einen Namen öffnet nur diesen.
+Seine Seite zeigt dieselben Fakten in einem gelben Kasten, **Diese RTE möchte beitreten**. Prüfen Sie, dass es eine ist, die Sie gestartet haben, bevor Sie sie freigeben:
+
+| Feld | Was es zeigt |
+|---|---|
+| Fingerabdruck | Die ersten 8 Hexadezimalziffern des SHA-256 ihres `RTE_TOKEN`, als `abcd-ef12`. Die RTE protokolliert ihn bei ihrem Start, und das [Installationsprogramm](../installation/installer.html#a-runner) gibt ihn am Ende aus. Er muss derselbe sein |
+| Zertifikat-Fingerabdruck | Im Dialog, bei einer eingehenden RTE über HTTPS: die ersten 8 Hexadezimalziffern des SHA-256 des Zertifikats, das die App pinnt (seine DER-Bytes), als `abcd-ef12`. Die RTE protokolliert ihn bei ihrem Start, und das [Installationsprogramm](../installation/installer.html#a-runner) gibt ihn am Ende aus. Er muss derselbe sein |
+| Host | Der Host, auf dem sie läuft |
+| IP-Adresse | Die Adresse, von der aus sie die App aufgerufen hat |
+| Modus | Ausgehend oder Eingehend |
+| URI | Die Adresse einer eingehenden RTE, unter der sich die App einwählt |
+| Version | Ihr Release |
+| Angefragt am | Wann sie um Beitritt gebeten hat |
+
+**Freigeben** und **Ablehnen**, im Dialog oder im Kasten auf ihrer Seite, entscheiden:
+
+| Aktion | Was passiert |
+|---|---|
+| Freigeben | Der Runner wird aktiviert und erhält ab jetzt Jobs. Er wird zum Standard seines Typs, wenn es keinen gibt |
+| Ablehnen | Der Runner wird samt seinen Anmeldedaten entfernt, und sein Socket wird geschlossen. Die RTE kann erneut um Beitritt bitten; sie wartet dann wieder auf Freigabe |
+
+Nur ein Admin gibt eine RTE frei oder lehnt sie ab.
+
+---
+
+## Beitrittstoken
+
+Ein Beitrittstoken gibt eine RTE sofort frei, für unbeaufsichtigte Installationen: Eine mit
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) gestartete RTE oder ein mit `--join` des Installationsprogramms installierter Runner legt es einmal vor,
+und ihr Runner wird aktiviert hinzugefügt, ohne zu warten. Beitrittstoken haben keine Seite in der Oberfläche: Ein Admin erstellt sie über die
+[REST-API](../api/), unter `/api/v2/runner`:
+
+| Aufruf | Was er tut |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Erstellt ein Beitrittstoken. Der Body enthält seinen `name` und optional `expiresInHours` (keiner: Es läuft nie ab) und `maxUses` (keiner: beliebig viele RTEs) |
+| `GET /api/v2/runner/jointoken` | Listet die Beitrittstoken auf, die neuesten zuerst, mit ihren Verwendungen und ob sie noch verwendbar sind; nie die Token selbst |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Widerruft es: Es fügt keinen Runner mehr hinzu und bleibt in der Liste |
+| `DELETE /api/v2/runner/jointoken/<id>` | Löscht es |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+Die Antwort enthält das Token, das mit `afj_` beginnt, nur dieses eine Mal: Gespeichert wird nur sein SHA-256. Eine RTE, die es vorlegt, erhält dieselben
+Anmeldedaten und denselben Runner wie eine, die [um Beitritt bittet](#asking-to-join), aktiviert, und seine Beschreibung nennt das Beitrittstoken. Ab dann meldet sich die
+RTE mit ihrem eigenen Token an, sodass das Beitrittstoken ablaufen oder widerrufen werden kann, ohne sie zu beeinträchtigen. Das Widerrufen oder Löschen eines Beitrittstokens
+lässt die Runner bestehen, die es hinzugefügt hat.
+
+Ein Beitrittstoken gibt einem freigegebenen Runner nie ein neues Token. Wenn bereits ein RTE-Runner dieses Namens existiert:
+
+| Der Runner | Was passiert |
+|---|---|
+| Wartet auf Freigabe | Er erhält das neue Token in seinen Anmeldedaten und wartet weiterhin auf die Freigabe eines Admins |
+| Ist freigegeben | Abgewiesen mit `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. Das Beitrittstoken wird nicht verbraucht |
+| Stammt aus dem [Config-Seed](../seed/) | Abgewiesen: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Eine mit einem neuen Token neu installierte RTE meldet sich daher mit dem Token aus den Anmeldedaten ihres Runners an, oder ein Admin ändert dieses Token
+unter **Verbindungen > Anmeldedaten** oder löscht den Runner, damit die RTE als neue beitritt.
+
+---
+
+## Registrierung im Datenbankmodus
+
+Eine RTE im Datenbankmodus, seit 7.3.0 veraltet, registriert sich standardmäßig selbst, unter ihrer `RTE_URL` oder sonst unter ihrer eigenen Adresse und ihrem Port. Der
+Worker entfernt einen solchen Runner, sobald seine RTE 10 Minuten lang keinen Heartbeat geschrieben hat. Ein von Hand, vom Config-Seed oder von einer
+RTE in einem Socket-Modus hinzugefügter Runner wird auf diese Weise nie entfernt.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), das diese Registrierung ein- oder ausschaltet, ist in 7.3.0 zusammen mit dem
+Datenbankmodus veraltet: Eine RTE in einem Socket-Modus bittet um Beitritt oder tritt mit einem Beitrittstoken bei. Um solche Runner in der Zwischenzeit selbst zu verwalten, starten Sie die
+RTE mit `RTE_REGISTER=0` und fügen Sie sie hier mit Typ RTE, Modus **Datenbank (veraltet)** und RTE-Anmeldedaten mit ihrer Adresse und demselben
+Token hinzu. Um sie in einen Socket-Modus zu überführen, siehe [Modi](../rte/modes.html#database-deprecated).
diff --git a/i18n/de/_configure/runners/runner-page.md b/i18n/de/_configure/runners/runner-page.md
new file mode 100644
index 0000000..184f305
--- /dev/null
+++ b/i18n/de/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "Die Seite eines Runners"
+parent: Runner
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# Die Seite eines Runners
+{: .no_toc }
+
+Die Tabs eines Runners, Modus, Verbindung und Einstellungen einer RTE und Verbindung testen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tabs
+
+Die Seite eines Runners zeigt die Schritte seines Dialogs als Tabs, dazu was auf ihm läuft:
+
+| Tab | Was er enthält |
+|---|---|
+| Details | Name und Beschreibung, den Schalter **Standard** und den Schalter **Aktiviert**, für jeden Runner-Typ gleich |
+| Typ | Das Produkt, wie im Dialog. Bei einer RTE außerdem ihren **Modus**: **Datenbank (veraltet)**, **Eingehend** oder **Ausgehend**, das `RTE_MODE`, mit dem ihre RTE läuft (siehe [Modi](../rte/modes.html)) |
+| RTE | Nur bei einer RTE: ihren **Modus** in Worten und in einem Socket-Modus ihre **Verbindung** und ihre Einstellungen (siehe [Die Einstellungen einer RTE](#an-rtes-settings)) |
+| Anmeldedaten | Den **Anmeldedaten-Eintrag**, mit dem er sich anmeldet, Anmeldedaten aus Verbindungen > Anmeldedaten vom Typ des Runners, die sein Token oder seine Anmeldung und die Adresse seines Servers enthalten. Die einer RTE enthalten ihr `RTE_TOKEN` und die Adresse der RTE, sofern sie nicht ausgehend ist. **Projekt** bei Semaphore, Rundeck und Jenkins |
+| Formulare | Die Formulare, die auf ihm laufen, und wie: **Nennt ihn** oder **Als Standard-Runner**. Eine Zeile öffnet das Formular |
+| Jobs | Die letzten 100 Jobs, die auf ihm liefen, mit Status, Start, Ende und Dauer. Eine Zeile öffnet den Job |
+
+Jeder Tab hat eine eigene Adresse, etwa `/settings/runners/<id>/rte`, sodass ein Link oder ein Lesezeichen ihn öffnet. Ein Runner ohne diesen Tab öffnet sich auf
+Details.
+
+Die beiden Schalter des Tabs Details werden sofort gespeichert. **Standard** macht den Runner zum Standard seines Typs; ausgeschaltet wird er, indem man
+einen anderen Runner zum Standard macht. **Aktiviert** schaltet den Runner ein oder aus: Ausgeschaltet geht kein Job an ihn, auch nicht als Standard seines Typs (siehe
+[Standard und Aktiviert](list.html#default-and-enabled)).
+
+Eine RTE, die um Beitritt gebeten hat, öffnet sich mit einem gelben Kasten, **Diese RTE möchte beitreten**, mit ihrem Fingerabdruck und dem, was sie über sich gesagt hat, sowie
+**Freigeben** und **Ablehnen** (siehe [Eine RTE freigeben](registration.html#approving-an-rte)). Ein Runner des [Config-Seeds](../seed/) sagt
+das oben auf seiner Seite und ist schreibgeschützt.
+
+---
+
+## Die Einstellungen einer RTE
+
+Der Tab RTE verwaltet eine RTE aus der App heraus, ohne ihre Umgebung auf der Maschine zu bearbeiten, auf der sie läuft.
+
+**Verbindung.** Eine RTE in einem Socket-Modus zeigt eine Plakette: **Verbunden** oder **Nicht verbunden**. Beim Überfahren zeigt **Verbunden** den App-Knoten,
+der ihren Socket hält, das Release der RTE und wie viele ihrer Jobs laufen. **Nicht verbunden** bedeutet, dass kein App-Knoten einen Socket zu ihr hält:
+Prüfen Sie, ob die RTE läuft, ihre Adresse oder `APP_URL` und ihr Token.
+
+**Einstellungen.** Eine RTE im ausgehenden oder eingehenden Modus hat vier Einstellungen, jede standardmäßig leer:
+
+| Einstellung | Entspricht | Was sie tut |
+|---|---|---|
+| Max. gleichzeitige Jobs | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Wie viele Playbooks sie gleichzeitig ausführt, standardmäßig `10`; `0` setzt keine Grenze |
+| Cache für Jobdateien | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Wie viel der von der App gesendeten Jobdateien sie behält, in MB, standardmäßig `1024`; `0` behält keine |
+| Wartezeit beim Stoppen | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Wie lange eine anhaltende RTE auf ihre laufenden Playbooks wartet, standardmäßig `25` Sekunden |
+| Jobdateien | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Übertragung**: Die App sendet die Dateien eines Jobs mit dem Job. **Lokal**: Sie arbeitet aus ihren eigenen eingehängten Ordnern |
+
+**Welcher Wert gewinnt.** Ein Wert auf der Seite gewinnt über dieselbe auf der RTE gesetzte Variable. Ein leer gelassenes Feld verwendet die eigene Variable der RTE,
+sonst den Standard. Unter jedem Feld sagt die Seite, welcher: **Überschreibt RTE_MAX_JOBS auf dem RTE (3).** oder **Leer: Das RTE nutzt seine eigene
+RTE_MAX_JOBS, 3.**; der Platzhalter zeigt den Wert, für den ein leeres Feld steht.
+
+**Wie sie die RTE erreichen.** Die Einstellungen werden mit dem Runner in der Datenbank der App gespeichert. Die App sendet sie über den Socket der RTE,
+wenn diese sich verbindet und wann immer sie gespeichert werden, und die RTE wendet sie sofort an: Ein kleinerer Cache wird gekürzt, eine neue Grenze zählt ab dem
+nächsten Job. Die RTE hält sie nur im Speicher und schreibt keine Datei: Nach einem Neustart erhält sie sie beim Verbinden erneut, vor ihrem ersten Job.
+
+Eine RTE im Datenbankmodus (veraltet) hat keinen Socket: Sie liest diese Einstellungen aus ihren eigenen Variablen, und der Tab sagt das.
+
+---
+
+## Verbindung testen
+
+Die Schaltflächen oben rechts wirken auf den Runner, wie er gespeichert ist.
+
+Neben **Speichern** stehen **Verbindung testen** und **Löschen** und im Tab Anmeldedaten **Anmeldedaten hinzufügen**, das Anmeldedaten vom
+Typ des Runners anlegt und auswählt. Ein Token oder Passwort wird nach dem Speichern nie wieder angezeigt: Ändern Sie es in den Anmeldedaten.
+
+**Verbindung testen** prüft, dass der Runner antwortet und sein Token oder seine Anmeldung akzeptiert, und sagt das in einer Meldung: **Runner connection is
+OK** oder warum es fehlschlug. Es führt keinen Job aus. Bei einer RTE prüft es außerdem den Vertrag, den die RTE spricht (siehe
+[Der Vertrag](../rte/images.html#the-contract)):
+
+| RTE | Was der Test liest | Wann er fehlschlägt |
+|---|---|---|
+| Ausgehend oder Eingehend | Wer ihren Socket hält, wie jeder App-Knoten es festhält, und was die RTE beim Verbinden gesagt hat. Er ruft nichts auf | Kein App-Knoten hält einen Socket zu ihr: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, oder bei einer eingehenden *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Oder die RTE spricht einen anderen Vertrag als 3 |
+| Datenbank (veraltet) | Den Endpunkt `/rte/v1/health` der RTE, mit ihrem Token aufgerufen | Die RTE antwortet nicht unter ihrer Adresse, weist das Token ab oder spricht einen anderen Vertrag als 2 |
+
+Die Plakette **Verbindung** im Tab RTE zeigt denselben Socket-Zustand ohne Test.
diff --git a/i18n/de/_configure/runners/types.md b/i18n/de/_configure/runners/types.md
new file mode 100644
index 0000000..e1fe4eb
--- /dev/null
+++ b/i18n/de/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Runner-Typen
+parent: Runner
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Runner-Typen
+{: .no_toc }
+
+Die Produkte, die ein Runner sein kann, ihre Adresse und Anmeldung
+{: .fs-6 .fw-300 }
+
+Der Schritt **Typ** bietet eine Auswahl pro Produkt, jede mit einem Hinweis; der der RTE schreibt ihren Namen aus, *Laufzeitumgebung*. AAP und
+Ascender werden als Runner vom Typ `awx` mit einer Variante (`aap` oder `ascender`) gespeichert, was auch der Config-Seed verwendet:
+
+| Typ | Beispiel für die URI | Projekt | Authentifizierung |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | Das `RTE_TOKEN` der RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Ein API-Token oder ein Benutzer und ein Passwort |
+| Ascender | `https://ascender.example.com/api/v2` | | Ein API-Token oder ein Benutzer und ein Passwort |
+| AWX | `https://awx.example.com/api/v2` | | Ein API-Token oder ein Benutzer und ein Passwort |
+| Jenkins | `https://jenkins.example.com` | Der Ordner, in dem die Jobs liegen (optional) | Ein Benutzer und das API-Token dieses Benutzers |
+| Rundeck | `https://rundeck.example.com` | Der Projektname | Das API-Token eines Benutzers |
+| Semaphore | `https://semaphore.example.com` | Die Projekt-ID, die Zahl in `/project/<id>` | Das API-Token eines Benutzers |
+
+Eine Adresse von AWX, AAP oder Ascender trägt ihren API-Pfad: `/api/v2` oder `/api/controller/v2` für AAP 2.5 und neuer.
+Eine RTE ist das AnsibleForms-Image, gestartet mit `AF_ROLE=rte`; wie man eine betreibt, ist unter
+[Laufzeitumgebungen](../rte/) beschrieben.
diff --git a/i18n/de/_configure/secret-stores/cyberark.md b/i18n/de/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..3327201
--- /dev/null
+++ b/i18n/de/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Secret Stores
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Anmeldedaten aus dem CyberArk Central Credential Provider (CCP) lesen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Experimentell.** Noch nicht gegen eine echte CyberArk-Installation getestet; bitte melden Sie Ihre Erfahrungen.
+
+Der CCP ist die REST-Schnittstelle des Application Access Manager von CyberArk.
+
+---
+
+## Felder des Stores
+
+Zusätzlich zu den [Feldern, die jeder Store hat](./#adding-a-store), hat ein CyberArk-Store diese Felder:
+
+| Feld | Bedeutung |
+|---|---|
+| Anmeldeinformation | **CyberArk**-Anmeldedaten aus [Verbindungen > Anmeldedaten](../credentials.html): die Basis-URL des CCP, z. B. `https://ccp.example.com` (`/AIMWebService/api/Accounts` wird angehängt), seine TLS-Einstellungen, seine AppID (die in CyberArk für AnsibleForms definierte Anwendung) sowie ein Client-Zertifikat und ein Schlüssel in PEM, nur wenn die AppID eines verlangt. |
+
+---
+
+## Secret-Referenz
+
+Die Secret-Referenz bezeichnet das Konto als durch `;` getrennte Schlüssel-Wert-Paare:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Erlaubte Schlüssel: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` übergibt den Rest der Referenz als native CCP-Abfrage, mit `QueryFormat=Exact`,
+  sofern Sie nichts anderes setzen.
+- Eine `AppID` in der Referenz wird ignoriert: Es wird immer die AppID des Stores verwendet.
+- Das Passwort des Kontos (`Content`) wird zum Passwort; `UserName`, `Address`, `Port` und
+  `Database` füllen Benutzer, Host, Port und Datenbankname.
+
+---
+
+## Zusätzliche Optionen
+
+Die zusätzlichen Optionen des Stores werden als JSON-Objekt gesetzt:
+
+| Schlüssel | Bedeutung |
+|---|---|
+| `reason` | Wird als `Reason` gesendet, wenn die Referenz keinen hat, für das Audit von CyberArk. |
+| `check_ref` | Eine Referenz, die **Verbindung testen** tatsächlich liest. Ohne sie prüft der Test nur, dass der CCP antwortet und die AppID akzeptiert. |
+| `timeout_ms` | Zeitlimit der Anfrage, Standard 10000. |
+
+Zum Beispiel, um einen Grund zu senden und **Verbindung testen** ein Prüfkonto lesen zu lassen:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/de/_configure/secret-stores/hashicorp-vault.md b/i18n/de/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..148a203
--- /dev/null
+++ b/i18n/de/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Secret Stores
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Anmeldedaten aus HashiCorp Vault lesen, aus KV v1 oder v2 oder einer Engine für dynamische Secrets
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Felder des Stores
+
+Zusätzlich zu den [Feldern, die jeder Store hat](./#adding-a-store), hat ein HashiCorp Vault-Store diese Felder:
+
+| Feld | Bedeutung |
+|---|---|
+| Anmeldeinformation | **HashiCorp Vault**-Anmeldedaten aus [Verbindungen > Anmeldedaten](../credentials.html): die Adresse des Vault, seine TLS-Einstellungen und das Token als Passwort, mit Lesezugriff auf die Pfade, die Ihre Anmeldedaten verwenden. **Anmeldedaten hinzufügen** legt welche dieses Typs an. AnsibleForms erneuert das Token nicht. |
+| Namespace | Der Namespace von Vault Enterprise, gesendet als `X-Vault-Namespace`. Wird angezeigt, sobald im Schritt **Typ** **Vault Enterprise** eingeschaltet ist. |
+| KV-Version | `2` (Standard) oder `1`. |
+| Standard-Mount | Wird für eine Referenz ohne Schrägstrich verwendet, z. B. wird `myapp` zu `secret/data/myapp`. |
+
+Die Secret-Referenz ist der Pfad, z. B. `secret/myapp/prod`. Bei KV v2 wird das Segment `/data/`
+eingefügt, wenn Sie es weglassen.
+
+---
+
+## Dynamische Datenbank-Anmeldedaten
+
+Eine Referenz der Form `<mount>/creds/<role>`, z. B. `database/creds/readonly`, liest aus einer
+Engine für dynamische Secrets wie der Datenbank-Engine von Vault. Vault erstellt dann bei jedem Lesen ein neues
+Datenbankkonto, gültig für die Dauer des Leases.
+
+- Ein Konto wird für 80 % seines Leases wiederverwendet, nicht für die Cache-Zeit; mit Cache `0` liest jede Abfrage ein neues.
+- Vault gibt nur Benutzer und Passwort zurück: Tragen Sie den Rest der Verbindung in die Anmeldedaten-Zeile ein.
+- Das Lease wird nie vorzeitig widerrufen; das Konto läuft ab, wenn Vault das Lease beendet.
diff --git a/i18n/de/_configure/secret-stores/index.md b/i18n/de/_configure/secret-stores/index.md
new file mode 100644
index 0000000..a7bb4c7
--- /dev/null
+++ b/i18n/de/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Secret Stores
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Secret Stores
+{: .no_toc }
+
+Anmeldedaten aus einem Secret Manager lesen, statt sie in AnsibleForms zu speichern
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Binden Sie einen Secret Manager an, und lassen Sie Anmeldedaten ihren Benutzer und ihr Passwort daraus lesen.
+
+---
+
+## Funktionsweise
+
+Ein **Secret Store** ist eine Verbindung zu einem Secret Manager, angelegt unter
+**Verbindungen > Secret Stores**. **Anmeldedaten** können dann einen Store und eine Stelle darin nennen
+(die *Secret-Referenz*). Wenn ein Formular, ein Playbook oder ein Ausdruck diese Anmeldedaten verwendet:
+
+- werden **Benutzer** und **Passwort** jedes Mal aus dem Store gelesen (innerhalb der Cache-Zeit des Stores);
+- bleiben **Host**, **Port** und **Datenbank** die der Anmeldedaten-Zeile. Lässt die Zeile
+  eines davon leer und das Secret enthält es, wird der Wert aus dem Secret verwendet.
+
+Formulare verweisen weiterhin über den Namen auf die Anmeldedaten, daher ändert das Verschieben eines Passworts in einen Store
+nichts an Ihren Formularen.
+
+| Store-Typ | Status |
+|---|---|
+| HashiCorp Vault (KV v1 und v2, Token-Authentifizierung) | verfügbar |
+| Dynamische Anmeldedaten von HashiCorp Vault (`<mount>/creds/<role>`) | experimentell |
+| CyberArk Central Credential Provider (CCP) | experimentell |
+
+---
+
+## Einen Store hinzufügen
+
+Ab 7.3.0 kann nur ein Admin einen Store hinzufügen, ändern oder löschen, da sein Token oder Schlüssel an seine Adresse gesendet wird. Jeder Store hat diese Felder:
+
+| Feld | Bedeutung |
+|---|---|
+| Name | Wie Anmeldedaten auf den Store verweisen. |
+| Typ | Der Secret Manager. |
+| Anmeldeinformation | Wie und wo sich der Store anmeldet: Anmeldedaten aus [Verbindungen > Anmeldedaten](../credentials.html), im Schritt **Anmeldedaten**, vom Typ **HashiCorp Vault** (Token und Adresse) oder **CyberArk**. Sie enthalten die Basis-URL, z. B. `https://vault.example.com:8200`, und die TLS-Einstellungen: Zertifikatsprüfung überspringen oder ein CA-Bundle in PEM für eine private CA. Sie können selbst nicht aus einem Secret Store lesen. |
+| Cache (Sekunden) | Wie lange ein gelesenes Secret wiederverwendet wird. `0` liest es bei jeder Verwendung. Standard 60. |
+| Zusätzliche Optionen (JSON) | Typspezifische Optionen als JSON-Objekt. |
+
+Bis 7.2.0 waren Adresse, Token und TLS-Einstellungen Felder des Stores. Das Upgrade auf 7.3.0 verschiebt sie in seine
+Anmeldedaten namens `<store>-token` (oder `<store>-appid` bei CyberArk), siehe [Adressen in Anmeldedaten](../credentials/types.html#addresses-in-credentials).
+
+**Verbindung testen** prüft den Zugriff, ohne ein Secret zu lesen. Die Seite **Status** prüft jeden Store und warnt 7 Tage
+bevor ein Vault-Token abläuft.
+
+Jeder Secret Manager hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 und v2 mit Token-Authentifizierung sowie dynamische Datenbank-Anmeldedaten |
+| [CyberArk](cyberark.html) | Der Central Credential Provider (CCP) des Application Access Manager von CyberArk |
+
+---
+
+## Einen Store verwenden
+
+### In Anmeldedaten
+
+Wählen Sie unter **Verbindungen > Anmeldedaten** im Schritt **Speicher** der Anmeldedaten **Secret Store**, wählen Sie dann den
+**Secret Store** und füllen Sie die **Referenz** aus. Benutzer und Passwort werden dann aus dem Store gelesen, nicht eingegeben.
+
+### Inline, ohne Anmeldedaten-Zeile
+
+Überall, wo ein Name von Anmeldedaten akzeptiert wird, können Sie stattdessen direkt auf einen Store verweisen (`fnCredentials`, `fnRestBasic`,
+die `credentials:` eines Formulars, die `dbConfig` einer Abfrage).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Ohne Anmeldedaten-Zeile braucht ein Datenbank-Secret mindestens einen `db_type` und einen Host, zum Beispiel:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Ohne `db_type` ist das Secret eine einfache Anmeldung (Benutzer, Passwort und weitere Schlüssel), und eine Abfrage darauf nimmt `mysql` an.
+
+### Schlüsselnamen
+
+Ein Secret wird mit diesen Aliasen auf Anmeldedaten abgebildet. Andere Schlüssel werden durchgereicht.
+
+| Feld der Anmeldedaten | Akzeptierte Schlüssel im Secret |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | gleicher Name (nur bei Inline-Secrets) |
+
+Bei einer Anmeldedaten-Zeile werden Host, Port und Datenbankname aus dem Secret nur verwendet, wo die
+Zeile sie leer lässt.
+
+Ein Secret mit einer anderen Struktur lässt sich mit einem `jq`-Ausdruck umformen, der als drittes Argument von
+`fnCredentials` übergeben wird:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## Im Config-Seed
+
+Stores lassen sich wie die anderen Admin-Objekte auch im Config-Seed deklarieren:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+Der Store meldet sich mit seinen Anmeldedaten an: `vault`-Anmeldedaten enthalten die Adresse des Vault in `url` und das Token als Passwort, `cyberark`-Anmeldedaten
+die AppID und die Adresse des CCP. Ohne Anmeldedaten werden `url` und `token` des Stores selbst verwendet.
+Details finden Sie unter [Config-Seed](../seed).
+
+---
+
+## Upgrade von den VAULT_*-Variablen
+
+Vor 7 war der einzige Store ein HashiCorp Vault, konfiguriert mit
+`VAULT_*`-Umgebungsvariablen, und Anmeldedaten verwiesen mit **Vault-Pfad** darauf.
+
+- **Die Variablen werden einmal importiert**, als Store namens `vault`; entfernen Sie sie danach.
+- **Anmeldedaten mit einem `vault_path`** verwenden jetzt diesen Store; `vault_path` entfällt in 8.
diff --git a/i18n/de/_configure/security/hardening.md b/i18n/de/_configure/security/hardening.md
new file mode 100644
index 0000000..22fba94
--- /dev/null
+++ b/i18n/de/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Härtung
+parent: Sicherheit
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Härtung
+{: .no_toc }
+
+Das Admin-Konto, Anmeldegrenzen, die Datenbank, Ausdrücke, Jobdaten, die Browser-Richtlinie, optionale Funktionen und Rollenoptionen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Das Admin-Konto
+
+Das lokale Admin-Konto wird beim ersten Start aus [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+und [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) angelegt, dessen Standard `AnsibleForms!123` ist.
+
+* Eine Anmeldung mit dem öffentlich bekannten Standardpasswort `AnsibleForms!123` muss es zuerst ändern: Bis dahin beantwortet der Server
+  jede Anfrage außer der Passwortänderung mit `403` (Code `password_change_required`), und der Browser zeigt eine
+  Seite zum Ändern des Passworts, die sich nicht schließen lässt. Das neue Passwort darf nicht wieder der Standard sein.
+* `ADMIN_PASSWORD` wird nur beim ersten Anlegen des Kontos gelesen: Setzen Sie vor dem ersten Start einen eigenen Wert.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` setzt das Passwort bei jedem Start auf `ADMIN_PASSWORD`
+  zurück. Verwenden Sie es nur, um ein verlorenes Passwort wiederherzustellen, entfernen Sie es dann und starten Sie neu.
+* Setzen Sie zuerst die beiden Hauptgeheimnisse: siehe [Geheimnisse und Verschlüsselung](secrets.html).
+* Sobald die Anmeldung über LDAP oder SSO funktioniert, behalten Sie den lokalen Admin nur für Notfälle, mit einem langen Passwort in Ihrem Tresor.
+
+---
+
+## Anmeldegrenzen und Passwörter
+
+Das Erraten von Passwörtern wird durch drei Grenzen gebremst. Die Fehlschläge werden in der Datenbank gezählt, sodass jeder App-Knoten dieselben
+Versuche sieht, und jede Grenze gilt ohne Neustart:
+
+| Variable | Standard | Was sie tut |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Nach so vielen fehlgeschlagenen Anmeldungen wird ein lokales oder LDAP-Konto für `LOGIN_LOCKOUT_MINUTES` gesperrt. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Eine Adresse mit so vielen fehlgeschlagenen Anmeldungen innerhalb von `LOGIN_LOCKOUT_MINUTES` wird bis zum Ende dieses Zeitfensters zurückgehalten: eine Adresse, die viele Konten probiert. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Wie lange ein Konto gesperrt bleibt, und das Zeitfenster, in dem Fehlschläge gezählt werden. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Anfragen pro Minute von einer Adresse, pro App-Knoten, an Anmeldung, Abmeldung, Token-Erneuerung und die Single-Sign-on-Callbacks. |
+
+Ein gesperrtes Konto oder eine zurückgehaltene Adresse erhält `429` mit einem Header `Retry-After`, bevor ein Passwort geprüft wird, und
+unabhängig davon, ob das Konto existiert; über `AUTH_RATE_LIMIT` lautet die Antwort ebenfalls `429`. Eine erfolgreiche Anmeldung setzt den
+Zähler des Kontos zurück, ebenso ein Admin, der das Passwort des Benutzers setzt. `0` schaltet eine Grenze ab; `LOGIN_LOCKOUT_MINUTES=0`
+schaltet sowohl die Sperre als auch die adressbezogene Grenze ab.
+
+`LOGIN_MAX_FAILURES_PER_IP` und `AUTH_RATE_LIMIT` zählen pro Client-Adresse: Setzen Sie hinter einem Reverse Proxy `TRUST_PROXY`,
+damit die Adresse die des Clients und nicht die des Proxys ist, siehe [Client-Adressen](../production/reverse-proxy.html#client-addresses).
+
+Ein über die Anwendung gesetztes lokales Passwort, für einen neuen Benutzer, durch einen Admin oder durch Benutzer, die ihr eigenes ändern, muss
+mindestens [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) Zeichen haben (standardmäßig `8`,
+`0` prüft keine Länge). Es darf weder der Benutzername noch das öffentlich bekannte Standardpasswort sein. `ADMIN_PASSWORD` wird nicht geprüft.
+
+---
+
+## Die Datenbank
+
+AnsibleForms hält alle Anmeldedaten und Jobs in seiner MySQL-Datenbank, halten Sie diese Datenbank also vom Netz fern:
+
+* Das docker-compose-Projekt veröffentlicht MySQL auf dem Host (`MYSQLDB_LOCAL_PORT`, `3306`) und wird mit dem
+  root-Passwort `AnsibleForms!123` ausgeliefert. Entfernen Sie dieses Port-Mapping oder binden Sie es an `127.0.0.1`, und ändern Sie das Passwort.
+* Verbinden Sie sich mit einem eigenen Konto statt mit `root`, gesetzt in [`DB_USER`](../customization/server.html#env_DB_USER) und
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Es braucht nur Rechte auf das Schema `AnsibleForms`:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Das deckt das Anlegen des Schemas (einschließlich `CREATE DATABASE`), das Patchen bei Upgrades sowie die
+  [Backups](../production/backups.html) und Wiederherstellungen ab, die als derselbe Benutzer laufen: Der Dump wird mit
+  `--no-tablespaces` erstellt, daher ist kein serverweites Recht wie `PROCESS` nötig. Ersetzen Sie `%` wo möglich durch die Adresse der
+  Anwendung. Ein Benutzer mit Rechten auf jede Datenbank, wie `root` sie hat, macht aus einer Lücke in der Anwendung
+  eine Lücke im gesamten Datenbankserver: Die Seite **Status** warnt davor in ihrer Prüfung **Datenbankbenutzer**, und das Protokoll
+  bei jedem Start.
+* Setzen Sie [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) auf `0`, sobald das Schema existiert.
+  Das Anlegen des Schemas löscht zuerst jede Tabelle; mit `0` können es weder der Bootstrap beim Start noch der Endpunkt
+  `/api/v2/schema` ausführen.
+
+---
+
+## Ausdrücke und ausgehende Aufrufe
+
+Server-Ausdrücke laufen für jeden angemeldeten Benutzer auf dem Server, daher sind der Sanitizer und die ausgehenden Filter wichtig:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` oder `paranoid`, nie `legacy`, das Benutzer Servercode ausführen lässt.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : Hosts, die REST-Ausdrücke nicht erreichen dürfen, z. B. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : Wenn gesetzt, können REST-Ausdrücke
+  nur diese Hosts und Bereiche erreichen. Die Sperrliste gewinnt über sie.
+
+Beide Listen decken nur die REST-Hilfsfunktionen von AnsibleForms selbst ab; Playbooks laufen außerhalb davon und werden nicht gefiltert.
+
+Ab 7.3.0 prüfen die REST-Hilfsfunktionen das Zertifikat des Endpunkts, wie jede andere Verbindung.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` schaltet die Prüfung ab: Verwenden Sie es nur für
+Endpunkte mit selbstsigniertem Zertifikat.
+
+---
+
+## Jobdaten
+
+Extravars und Ausgabe von Jobs werden in der Datenbank gespeichert und jedem angezeigt, der den Job sehen kann:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : Extravars, deren Schlüssel passt, werden
+  als `********` angezeigt. Der Standard ist `password|secret|token`; Passwortfelder werden immer maskiert. Erweitern Sie ihn um
+  die Namen, die Ihre Formulare verwenden, zum Beispiel `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : kürzt das Objekt `ansibleforms_user`,
+  das mit jedem Job gesendet wird und sonst alle Gruppenmitgliedschaften des Benutzers enthält.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) blendet nur geschwätzige Tasks aus; verbergen Sie Geheimnisse mit `no_log`.
+
+---
+
+## Die Content-Security-Policy
+
+Die Oberfläche wird mit einem Header Content-Security-Policy ausgeliefert, der begrenzt, was eine Seite im Browser laden und ausführen darf:
+
+* Skripte kommen nur von der Anwendung selbst, daher läuft ein in eine Seite eingeschleustes Skript nicht.
+* Keine andere Website darf die Oberfläche in einem Frame anzeigen.
+* Sie erlaubt, was die Anwendung braucht: lokale Formularausdrücke, die im Browser ausgewertet werden (`'unsafe-eval'`),
+  Inline-Styles, Bilder von beliebigen URLs (Formular- und Kategoriebilder) und die Worker des Code-Editors.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) ist standardmäßig `1` und sollte
+so bleiben. Mit `0` wird die Richtlinie als `Content-Security-Policy-Report-Only` gesendet: Die Browserkonsole listet auf, was sie
+blockieren würde, und nichts wird blockiert. Verwenden Sie `0` nur für eine Einrichtung, die noch nicht mit der Richtlinie funktioniert, etwa ein Reverse Proxy,
+der ein eigenes Skript einschleust. Eine Änderung auf der Einstellungsseite gilt ohne Neustart.
+
+---
+
+## Die Einstellungsseiten und der Designer
+
+Administratoren können einen Großteil der Konfiguration im Browser ändern. Schränken Sie das ein, wo die Konfiguration anderswo liegt:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : schreibgeschützte Einstellungen, für eine [verwaltete Umgebung](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : entfernt den integrierten Designer, wenn Formulare
+  in Git gepflegt werden.
+
+---
+
+## Optionale Funktionen
+
+Diese Funktionen sind standardmäßig aus. Schalten Sie sie nur ein, wenn Sie sie verwenden; eine Änderung auf der Einstellungsseite gilt ohne Neustart:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : stellt den [MCP-Server](../mcp/) unter `/api/v2/mcp` bereit,
+  sodass MCP-Clients Formulare mit dem Token eines Benutzers starten können.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : der [Chat-Assistent](../chat/). Formulardefinitionen
+  und die gerade eingegebenen Werte werden an den konfigurierten Modellanbieter gesendet.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) funktioniert umgekehrt: Es ist standardmäßig `enforce`,
+daher weist der Server einen Start ab, dessen Werte die Regeln des Formulars verletzen, einschließlich Starts über die REST-API.
+Lassen Sie es dabei: `log` protokolliert nur, was abgewiesen würde, und `off` prüft nichts, siehe [Startvalidierung](../launch-validation/).
+
+---
+
+## Rollenoptionen
+
+Einige Rollenoptionen in [config.yaml](../config/roles.html) gewähren mehr, als ihr Name vermuten lässt. Vergeben Sie sie mit Bedacht:
+
+| Option | Warum sie wichtig ist |
+|--------|----------------|
+| `allowScheduledJobs` | Ein Benutzer mit ihr sieht jeden Zeitplan und kann ihn ändern, und ein Zeitplan läuft mit Admin-Rechten, für jedes Formular. Behandeln Sie sie als Option auf Admin-Ebene. |
+| `allowBackupOps` | Umfasst die **Wiederherstellung**, die die gesamte Datenbank ersetzt. |
+| `showSettings` | Öffnet die Administrationsseiten. Ohne die Rolle admin kann sie die Konten und Gruppen, die die Rolle admin nennt, nicht ändern, siehe [Benutzer und Gruppen](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Zeigt das Serverprotokoll, das Hostnamen, Benutzernamen und Fehlerdetails enthalten kann. |
+| `showConnectionsSettings` | Öffnet die Verbindungsseiten: Anmeldedaten, Runner, Benachrichtigungskanäle und mehr. Das Hinzufügen, Ändern und Löschen von Runnern und Secret Stores bleibt Sache eines Admins, ebenso die Anmeldedaten von Verbindungen und Anmeldungen. Bei einem Repository bleiben das Hinzufügen oder Löschen sowie das Ändern seiner Adresse, seines Branches oder seiner `use_for_*`-Flags Sache eines Admins. |
+| `showAllJobLogs` | Zeigt die Jobs jedes Benutzers, nicht nur die eigenen. |
+| `manageAllJobs` | Bricht die Jobs jedes Benutzers ab, löscht sie und startet sie neu. |
+| `allowApiTokens` | Lässt den Benutzer API-Token erstellen, die bis zu [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (standardmäßig 90) leben. Abmelden mit einem Token oder sein Widerruf beendet es, und eine Passwortänderung beendet alle Token des Benutzers, siehe [Token](secrets.html#tokens). |
+| `extendedTokenExpiration` | Lässt den Benutzer mit `allowApiTokens` auch API-Token erstellen, die nie ablaufen. |
+| `allowFileUploads` | Lässt den Benutzer Dateien über die Dateifelder eines Formulars hochladen. Für jeden Benutzer eingeschaltet, sofern keine Rolle es ausschaltet. |
+| `allowChat`, `allowMcp` | Lassen den Benutzer den Chat-Assistenten und den MCP-Server verwenden, wenn sie eingeschaltet sind. `allowChat` ist für jeden Benutzer eingeschaltet, sofern keine Rolle es ausschaltet, und `allowMcp` folgt `allowChat`, sofern keine Rolle es setzt. |
+
+Ein Benutzer ohne die Rolle `admin` erhält keine der obigen Optionen auf Admin-Ebene, sofern keine Rolle sie ihm gibt. Setzt die Rolle `admin`
+keine Optionen, erhalten ihre Benutzer `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` und `allowScheduledJobs`. `allowApiTokens` und
+`extendedTokenExpiration` bleiben selbst für die Rolle `admin` aus: Setzen Sie sie bei den Rollen, die sie brauchen.
+
+Setzen mehrere Rollen eines Benutzers dieselbe Option, gewinnt `false`. Die Optionen der Rolle `default` ergänzen nur die Optionen,
+die keine der eigenen Rollen des Benutzers setzt; sie setzen sie nie außer Kraft.
diff --git a/i18n/de/_configure/security/https.md b/i18n/de/_configure/security/https.md
new file mode 100644
index 0000000..fde80e7
--- /dev/null
+++ b/i18n/de/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Sicherheit
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+HTTPS aus der Anwendung selbst bereitstellen und das Beispielzertifikat ersetzen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wo TLS endet
+
+TLS kann an einer von drei Stellen enden, und nur die erste betrifft die Einstellungen auf dieser Seite:
+
+* **in AnsibleForms**, mit `HTTPS=1` : HTTPS auf [`PORT`](../customization/server.html#env_PORT) mit den Dateien unten, wie es docker-compose auf 443 tut.
+* **in einem Reverse Proxy**, mit `HTTPS=0` dahinter : siehe [Reverse Proxy](../production/reverse-proxy.html).
+* **in einem Kubernetes-Ingress** : siehe den Tab Ingress unter [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) und das README des Charts.
+
+Sie können die erste mit den beiden anderen kombinieren, um auch den Abschnitt zwischen Proxy und Anwendung zu verschlüsseln.
+
+---
+
+## Die Einstellungen
+
+Drei Variablen steuern HTTPS in der Anwendung:
+
+| Variable | Standard | Bedeutung |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` stellt HTTPS bereit, `0` einfaches HTTP |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | Der private Schlüssel, PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | Das Serverzertifikat, PEM |
+
+Im Container-Image ist der persistente Ordner `/app/dist/persistent`, daher sind die Standarddateien
+`/app/dist/persistent/certificates/key.pem` und `cert.pem`. Beim docker-compose-Projekt ist das `data/certificates/`
+auf dem Host.
+
+---
+
+## Das Beispielzertifikat
+
+Ist `HTTPS=1` und fehlt beim Start eine der beiden Dateien, protokolliert AnsibleForms `httpsKey or httpsCert not found, copying from
+templates` und kopiert einen Beispielschlüssel und ein Beispielzertifikat aus dem Image an die konfigurierten Pfade. Schlägt diese Kopie fehl, hält die
+Anwendung an.
+
+Dieses Zertifikat ist für `CN=ansibleforms` selbstsigniert, und es ist **auf jeder Installation dasselbe**: Sein privater Schlüssel
+wird im öffentlichen Image mitgeliefert. Für einen ersten Eindruck reicht es, aber Browser warnen davor, und jeder kann damit geschützten Verkehr
+entschlüsseln. Ersetzen Sie es, bevor die Instanz echte Anmeldedaten enthält.
+
+---
+
+## Das Zertifikat ersetzen
+
+Verwenden Sie ein Zertifikat, das für den Hostnamen ausgestellt ist, den Benutzer eingeben, von Ihrer CA oder einem ACME-Client, im PEM-Format.
+Die Zertifikatsdatei kann die vollständige Kette enthalten: zuerst das Serverzertifikat, dann die Zwischenzertifikate.
+
+1. Kopieren Sie die Dateien in den persistenten Ordner oder an eine beliebige Stelle, die die Anwendung lesen kann:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Liegen sie anderswo, setzen Sie `HTTPS_KEY` und `HTTPS_CERT` auf ihre Pfade **im Container**.
+
+3. Starten Sie die Anwendung neu, die beide Dateien beim Start liest.
+
+Für ein schnelles eigenes selbstsigniertes Zertifikat (eine Testinstanz oder den Abschnitt hinter einem Proxy) erstellt `openssl` eines:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Erneuern ohne Neustart
+
+Eine Änderung von `HTTPS_KEY` oder `HTTPS_CERT` auf den Einstellungsseiten lädt Schlüssel und Zertifikat im laufenden Server neu.
+Neue Verbindungen erhalten das neue Zertifikat, offene behalten das alte. Lassen sich die neuen Dateien nicht lesen oder bilden sie kein gültiges
+Paar, bleibt das aktuelle Zertifikat bestehen, und eine Warnung wird protokolliert.
+
+Das funktioniert nur, wenn die Einstellungsseiten die Umgebung schreiben dürfen ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+ist `1`) und die Variable nicht in der echten Umgebung gesetzt ist. Ersetzt eine Erneuerung die Dateien unter denselben
+Pfaden, starten Sie die Anwendung neu.
diff --git a/i18n/de/_configure/security/index.md b/i18n/de/_configure/security/index.md
new file mode 100644
index 0000000..6efadaa
--- /dev/null
+++ b/i18n/de/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Sicherheit
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Sicherheit
+{: .no_toc }
+
+Eine Instanz absichern: das Admin-Konto, ihre Geheimnisse, HTTPS und was Benutzer und Formulare dürfen
+{: .fs-6 .fw-300 }
+
+---
+
+Für Administratoren, die eine Instanz für die Produktion vorbereiten, und für Sicherheitsprüfungen einer bestehenden.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Härtung](hardening.html) | Das Admin-Konto, Anmeldegrenzen, die Datenbank, Ausdrücke, Jobdaten, die Browser-Richtlinie, optionale Funktionen und Rollenoptionen |
+| [HTTPS](https.html) | Wo TLS endet, HTTPS aus der Anwendung bereitstellen und das Beispielzertifikat ersetzen |
+| [Geheimnisse und Verschlüsselung](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET` und Token-Laufzeiten |
+
+Verwandte Seiten: [Authentifizierung](../authentication/) für Anmeldemethoden, [Startvalidierung](../launch-validation/) für
+serverseitige Prüfungen jedes Starts und die [Sicherheitsvariablen](../customization/security.html).
diff --git a/i18n/de/_configure/security/secrets.md b/i18n/de/_configure/security/secrets.md
new file mode 100644
index 0000000..6b43faf
--- /dev/null
+++ b/i18n/de/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Geheimnisse und Verschlüsselung
+parent: Sicherheit
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Geheimnisse und Verschlüsselung
+{: .no_toc }
+
+Die beiden Hauptgeheimnisse, was sie schützen und wie lange Sitzungen und Token gelten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die beiden Hauptgeheimnisse
+
+Zwei Geheimnisse schützen alles andere. Setzen Sie beide, bevor die Instanz echte Daten enthält, bewahren Sie sie außerhalb der Instanz auf
+und ändern Sie sie nie leichtfertig:
+
+| Geheimnis | Was es schützt | Wenn es nicht gesetzt ist | Wenn es verloren geht oder geändert wird |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Jedes in der Datenbank gespeicherte Passwort und Token: Anmeldedaten, das LDAP-Bind-Passwort, Runner-Token, SSO-Client-Secrets, Webhook-Adressen von Slack und Teams, der API-Schlüssel des Chats | Ein Standardschlüssel wird verwendet, der im Quellcode öffentlich ist | Verloren: Jedes gespeicherte Geheimnis muss neu eingegeben werden. Geändert: Ab 7.3.0 wird jedes gespeicherte Geheimnis neu verschlüsselt, siehe [unten](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | Die Signatur von Zugriffs- und Refresh-Token, einschließlich langlebiger [API-Token](../profile/api-token.html) | Bei jedem Start wird ein zufälliges Geheimnis erzeugt, sodass jeder Neustart alle abmeldet | Jede Sitzung und jedes API-Token wird ungültig |
+
+Beide werden beim Start als Warnung `[SECURITY]` protokolliert, solange sie fehlen. Die Einstellungsseiten verweigern ihre Bearbeitung,
+die API gibt sie nie zurück, und Backups lassen sie absichtlich weg, sodass ein verlorenes `ENCRYPTION_SECRET` nirgendwo
+wiederhergestellt werden kann: Bewahren Sie eine Kopie in Ihrem Secret Manager auf. Das Verschlüsselungsgeheimnis wird als Schlüssel mit 32 Zeichen verwendet; ein kürzerer oder
+längerer Wert wird aufgefüllt oder abgeschnitten.
+
+Eine Änderung von `ACCESS_TOKEN_SECRET` beendet sofort jede Sitzung und jedes API-Token. Um die Token eines Benutzers oder einer
+Sitzung zu beenden, verwenden Sie die unter [Token](#tokens) beschriebenen Sperren.
+
+---
+
+## Das Verschlüsselungsgeheimnis ändern
+
+Ab 7.3.0 gehen beim Setzen oder Ändern von `ENCRYPTION_SECRET` die gespeicherten Geheimnisse nicht mehr verloren. Beim nächsten Start verschlüsselt der Worker
+jedes davon mit dem neuen Schlüssel neu, in einer Datenbanktransaktion, bevor irgendetwas anderes ein Geheimnis schreibt:
+
+| Situation | Was zu setzen ist |
+|---|---|
+| Die Instanz lief ohne `ENCRYPTION_SECRET`, mit dem öffentlichen Standardschlüssel | Nur `ENCRYPTION_SECRET`: Die Geheimnisse werden vom Standardschlüssel aus neu verschlüsselt |
+| Die Instanz lief mit einem eigenen Schlüssel | `ENCRYPTION_SECRET` auf den neuen Schlüssel und [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) auf den alten, für diesen einen Start |
+
+Wurden die gespeicherten Geheimnisse mit einem Schlüssel verschlüsselt, der keiner von beiden ist, wird nichts geändert, und die App verweigert den Start, bis
+`ENCRYPTION_SECRET_PREVIOUS` diesen Schlüssel nennt. Entfernen Sie `ENCRYPTION_SECRET_PREVIOUS`, sobald der Start sie neu verschlüsselt hat, und setzen Sie das
+neue `ENCRYPTION_SECRET` auf jedem App-Knoten, dem Worker und jeder RTE im Datenbankmodus, die sich selbst registriert. Diese
+Selbstregistrierung (`RTE_REGISTER`) ist in 7.3.0 veraltet: Eine RTE, die im Socket-Modus mit einem Beitrittstoken (`RTE_JOIN_TOKEN`) beitritt,
+braucht kein `ENCRYPTION_SECRET`, siehe [RTE-Modi](../rte/modes.html).
+
+---
+
+## Token
+
+Eine Anmeldung gibt ein kurzlebiges Zugriffstoken und ein längeres Refresh-Token zurück, mit dem der Browser ein neues Paar erhält:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : standardmäßig `30m`. Kürzer
+  begrenzt die Nutzung eines abgefangenen Tokens.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : standardmäßig `24h`.
+  So lange bleibt ein untätiger Browser angemeldet.
+* Die Rollenoption `allowApiTokens` lässt einen Benutzer ein API-Token anfordern, das eine Anzahl von Tagen gültig ist, und
+  `extendedTokenExpiration` fügt eines hinzu, das nie abläuft. Gewähren Sie sie nur Rollen, die API-Zugriff aus Skripten brauchen.
+  Auf der [Profilseite](../profile/api-token.html) wird ein Token aus einer Browsersitzung erstellt, die sich vor höchstens 10 Minuten angemeldet hat,
+  und nie aus einem anderen API-Token. Ein Token, das nie abläuft, lebt 50 Jahre, und die Ereignisse unten beenden es trotzdem.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : standardmäßig `90`. Die längste Lebensdauer eines
+  API-Tokens: Eine längere Anforderung wird darauf gekürzt.
+
+Ein Token ist ein signiertes JWT, aber der Server führt außerdem eine Liste gesperrter Token, die alle App-Knoten teilen, sodass ein Token
+vor seinem Ablauf enden kann:
+
+| Ereignis | Was endet |
+|-------|-----------|
+| Abmelden | Jedes Token dieser Anmeldung: das Zugriffstoken, sein Refresh-Token und ein API-Token, wenn die Abmeldung es verwendet |
+| Eine Passwortänderung, durch den Benutzer oder durch einen Admin | Jedes vor der Änderung ausgestellte Token des Benutzers, API-Token eingeschlossen, auf jedem Gerät |
+| Der Schalter **Anmeldung erlauben** eines Benutzers ausgeschaltet (lokaler, LDAP- oder SSO-Benutzer) oder ein lokaler Benutzer gelöscht | Jedes Token des Benutzers |
+| **Sitzungen beenden** auf der Seite eines LDAP- oder SSO-Benutzers | Jedes Token des Benutzers; er kann sich erneut anmelden, sofern er nicht gesperrt ist |
+| **Widerrufen** bei einem API-Token, auf der Profilseite oder im Tab **API-Tokens** des Benutzers | Genau dieses API-Token, sofort |
+
+Ein Skript beendet sein eigenes API-Token, indem es sich damit abmeldet: `POST /api/v2/auth/logout` mit dem Token im
+Header `Authorization`.
diff --git a/i18n/de/_configure/seed/environment-and-audit.md b/i18n/de/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..e301e99
--- /dev/null
+++ b/i18n/de/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Bearbeitung und Audit
+parent: Config-Seed
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Bearbeitung und Audit
+{: .no_toc }
+
+Die Einstellungsseiten sperren, und was das Audit-Protokoll festhält
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Bearbeitung der Umgebung abschalten
+
+`ALLOW_ENV_EDIT=0` macht die Einstellungsseiten schreibgeschützt. Jede Variable wird weiterhin mit
+dem geltenden Wert und dem Grund angezeigt, warum sie nicht geändert werden kann, und der Speicher-Endpunkt antwortet mit
+403.
+
+Verwenden Sie es immer, wenn die Umgebung anderswo deklariert ist. Sonst schreibt die Einstellungsseite
+`persistent/.env`, die auf einem flüchtigen Volume beim nächsten Neustart stillschweigend verloren geht und auf
+einem dauerhaften vom Manifest abweicht, das maßgeblich sein soll.
+
+{: .note }
+> Backups enthalten `persistent/.env` als `managed.env`, sodass ein Neuaufbau die Datenbank- und
+> Pfadeinstellungen zurückerhält. **`ENCRYPTION_SECRET` und `ACCESS_TOKEN_SECRET` werden entfernt**:
+> Der Dump daneben enthält alle gespeicherten Anmeldedaten als AES-Chiffretext, und den Schlüssel, der
+> ihn entschlüsselt, in denselben Ordner zu schreiben, würde eine kopierte Sicherung genügen lassen, um sie alle zu lesen. Setzen Sie
+> diese beiden stattdessen auf dem Zielhost; ein Kommentar in der Datei sagt das.
+>
+> Was übrig bleibt, kann noch Anmeldedaten enthalten (`DB_PASSWORD`, `METRICS_TOKEN`, ein altes `VAULT_TOKEN`), daher wird die Datei
+> mit `0600` geschrieben. Ihre Wiederherstellung ist ein eigener, ausdrücklich zu wählender Schritt statt Teil einer normalen Wiederherstellung,
+> da Datenbank-Host und Pfade darin die Maschine beschreiben, von der das Backup stammt. Der
+> Wiederherstellungsdialog listet die Datei auf und bietet eine eigene Schaltfläche *Umgebung wiederherstellen*
+> (`POST /api/v2/backup/:folder/restore-env`), die die vorherige Datei als `.env.bak` behält.
+
+---
+
+## Was festgehalten wird
+
+Jede Anwendung, die etwas ändert, schreibt einen Eintrag `seed.apply` ins Audit-Protokoll, der
+die angelegten, aktualisierten, freigegebenen und bereinigten Objekte nennt. Werte werden nie festgehalten, da die meisten
+davon Geheimnisse sind. Eine Anwendung ohne Änderung schreibt nichts, was den Verlauf aussagekräftig hält. Eine
+Abfrage, die die Datei unverändert vorfindet, ist eine Anwendung ohne Änderung, daher erhält der Verlauf nicht jede Minute eine Zeile.
+
+Eine über den Endpunkt angeforderte Anwendung wird absichtlich zweimal festgehalten, und die beiden Zeilen
+halten Verschiedenes fest: `config-seed.apply.create` ist, **wer** sie angefordert hat, `seed.apply`, **was**
+sie geändert hat.
+
+Die Seite Status meldet den Seed zweimal: eine **Prüfung**, ob die Datei noch lesbar ist und sich parsen lässt
+und ob das letzte Neuladen gelungen ist, und eine Zeile unter **Informationen**, die sagt, wie viele Datensätze er
+derzeit verwaltet. Die Prüfung ist die einzige Stelle, die meldet, wenn die Datei auf der Festplatte und die geltende
+Konfiguration auseinandergelaufen sind, denn ein fehlgeschlagenes Neuladen lässt die Instanz weiterlaufen.
diff --git a/i18n/de/_configure/seed/example.md b/i18n/de/_configure/seed/example.md
new file mode 100644
index 0000000..184c852
--- /dev/null
+++ b/i18n/de/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Beispiel
+parent: Config-Seed
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Beispiel
+{: .no_toc }
+
+Eine vollständige Seed-Datei, Abschnitt für Abschnitt
+{: .fs-6 .fw-300 }
+
+---
+
+Die folgende Seed-Datei deklariert jeden Abschnitt außer `oauth2` und dem veralteten `awx`; Geheimnisse kommen aus
+Umgebungsvariablen wie `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` ist einer von:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : jeder andere OpenAI-kompatible Endpunkt
+
+Wie `ldap` ist der Abschnitt `chat` eine einzelne Zeile, daher ist jedes Feld erforderlich, außer den optionalen;
+ein ausgelassenes optionales Feld bleibt unverändert.
+
+Der Chat-Assistent braucht außerdem `ENABLE_CHAT=1`; siehe die Seite [Chat-Assistent](../chat).
+
+Seit 7.3.0 meldet sich ein Runner mit Anmeldedaten seines Typs an, die die Adresse seines Servers in `url` enthalten. Ein Runner mit eigenem `token`
+oder `username` und `password` funktioniert weiterhin: Der Seed protokolliert eine Warnung und macht daraus solche Anmeldedaten, benannt nach dem Runner. Ein
+Runner, der `api`- oder `userpass`-Anmeldedaten nennt, funktioniert ebenfalls weiterhin, mit einer Warnung: Geben Sie diesen Anmeldedaten stattdessen den Typ des Runners.
+Beides ist seit 7.3.0 veraltet und wird in 8.0.0 entfernt. Ein RTE-Runner ohne `rte_mode` ist im Datenbankmodus, veraltet (siehe
+[Modi](../rte/modes.html)). Ein Runner mit `enabled: false` erhält keinen Job, auch nicht als Standard seines Typs (siehe
+[Standard und Aktiviert](../runners/list.html#default-and-enabled)); ohne `enabled` lässt der Seed ihn, wie er ist.
+
+Ein Runner-Element nimmt neben `name`, `type`, `description`, `credential`, `is_default` und `enabled` diese Schlüssel:
+
+| Schlüssel | Was er setzt |
+|---|---|
+| `rte_mode` | Den Modus einer RTE: `outbound`, `inbound` oder `database` (veraltet, der Standard) |
+| `rte_max_jobs` | **Max. gleichzeitige Jobs** einer RTE im Socket-Modus, `0` bis `10000` (`0`: keine Grenze) |
+| `rte_cache_mb` | Ihren **Cache für Jobdateien** in MB, `0` bis `1048576` (`0` behält keine) |
+| `rte_files` | Ihre **Jobdateien**: `transfer` oder `local` |
+| `rte_drain_seconds` | Ihre **Wartezeit beim Stoppen** in Sekunden, `0` bis `86400` |
+| `flavour` | Ein `awx`-Runner, der ein AAP oder Ascender ist: `aap` oder `ascender`; keiner für AWX |
+| `project` | Die Projekt-ID eines Semaphore-Runners, den Projektnamen eines Rundeck-Runners, den Ordner eines Jenkins-Runners |
+| `uri`, `ignore_certs`, `ca_bundle` | Die eigene Adresse und das TLS des Runners aus der Zeit vor 7.3.0: nur verwendet, solange seine Anmeldedaten keine `url` enthalten |
+
+Die vier `rte_*`-Einstellungen sind die des Tabs RTE der Runner-Seite (siehe [Die Einstellungen einer RTE](../runners/runner-page.html#an-rtes-settings)):
+Sie gewinnen über dieselben auf der RTE gesetzten Variablen, und eine RTE im Datenbankmodus ignoriert sie. Ein Wert außerhalb seines Bereichs lässt die
+Validierung des Seeds fehlschlagen.
+
+Eine RTE im Datenbankmodus kann sich selbst registrieren, bevor der Seed angewendet wird. Ein RTE-Runner aus dem Seed, dessen `uri` die Adresse ist, unter der eine solche RTE
+sich registriert hat, **übernimmt** diese Zeile: Sie erhält den deklarierten Namen und die Felder, und der Worker entfernt sie nicht mehr, wenn die RTE nicht mehr
+antwortet, statt eines zweiten Runners für dieselbe RTE.
diff --git a/i18n/de/_configure/seed/index.md b/i18n/de/_configure/seed/index.md
new file mode 100644
index 0000000..d181ff9
--- /dev/null
+++ b/i18n/de/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Config-Seed
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Config-Seed
+{: .no_toc }
+
+Die Admin-Objekte in einer Datei deklarieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren, die aus Git bereitstellen: Deklarieren Sie die Admin-Objekte in einer Datei, damit sich eine Instanz auf einer leeren Datenbank neu aufbauen lässt.
+
+---
+
+## Was er abdeckt
+
+Setzen Sie `CONFIG_SEED_PATH` auf eine YAML-Datei, und AnsibleForms wendet sie beim Start an. Die Datei
+deklariert Objekte, die früher nur in der Datenbank existierten:
+
+| Abschnitt               | Was er deklariert                                                   |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Wo Jobs laufen: RTEs, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Secret Stores (HashiCorp Vault, ...)                                |
+| `credentials`           | Anmeldedaten                                                        |
+| `oauth2`                | SSO-Anbieter: Entra ID und OIDC                                     |
+| `repositories`          | Git-Repositories                                                    |
+| `syslog_servers`        | Die Syslog-Server, die das Serverprotokoll und die Audit-Einträge erhalten |
+| `notification_channels` | Mailserver, Slack, Teams, Telegram und Webhooks für Benachrichtigungen |
+| `labels`                | Die Labels neben dem Logo der Kopfzeile, ab 7.3.0                   |
+| `ldap`                  | Die LDAP-Konfiguration                                              |
+| `settings`              | Die öffentliche URL und die Mail-Einstellungen, die verwendet werden, wenn kein Mail-Kanal aktiv ist |
+| `chat`                  | Der Modellanbieter des Chat-Assistenten                             |
+| `awx`                   | Seit 7 veraltet, in 8 entfernt: Verwenden Sie `runners` mit `type: awx` |
+
+Ein vor 7 geschriebener Seed funktioniert weiterhin: Jedes Element seines Abschnitts `awx` wird als Runner vom Typ `awx` angewendet, und das Protokoll
+warnt bei jeder Anwendung. Verschieben Sie diese Elemente vor dem Upgrade auf 8 unter `runners` mit `type: awx`.
+
+Der Seed ist **nicht** dasselbe wie `config.yaml`, die die Kategorien, Rollen und Konstanten enthält
+und ihren eigenen `CONFIG_PATH` hat. Die beiden werden absichtlich getrennt gehalten: Das
+Repository, das `config.yaml` *enthält*, ist eines der Objekte, die der Seed deklariert, daher kann der Seed
+nicht darin liegen.
+
+Benutzer und Gruppen bleiben außen vor: Sie kommen aus LDAP oder SSO, und der erste Admin aus `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Beispiel](example.html) | Eine vollständige Seed-Datei, Abschnitt für Abschnitt |
+| [Verwaltete Objekte](managed-objects.html) | Wie der Seed die aufgeführten Objekte verwaltet und wie er Geheimnisse heraushält |
+| [Neuladen und Start](reloading.html) | Die Datei ohne Neustart ändern, und was beim Start passiert |
+| [Kubernetes](kubernetes.html) | AnsibleForms aus einer ConfigMap und Secrets bereitstellen |
+| [Bearbeitung und Audit](environment-and-audit.html) | Die Einstellungsseiten sperren, und was das Audit-Protokoll festhält |
diff --git a/i18n/de/_configure/seed/kubernetes.md b/i18n/de/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..3291fe9
--- /dev/null
+++ b/i18n/de/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Config-Seed
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+AnsibleForms aus einer ConfigMap und Secrets bereitstellen
+{: .fs-6 .fw-300 }
+
+---
+
+Hängen Sie den Seed aus einer `ConfigMap` und seine Geheimnisse aus einem `Secret` ein:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Ein Pod, mit nicht gesetztem `AF_ROLE`.** Dieser Pod führt die Web-App und den Worker in einem Prozess aus. Die Zeitpläne, das nächtliche
+> Backup und die übrige Hintergrundarbeit laufen nur in dem Prozess, der die Worker-Sperre in der Datenbank hält, die
+> Designer-Sperre ist eine Datenbanktabelle, und die Playbooks laufen auf einer RTE, nicht in diesem Pod. Behalten Sie trotzdem `replicas: 1` mit der
+> Strategie `Recreate`: Bei einem Upgrade wartet der neue Pod, bis der Worker das Schema gepatcht hat, und der alte Pod hält die
+> Worker-Sperre, bis er anhält. Um mehrere Web-Knoten zu betreiben, teilen Sie sie in `AF_ROLE=app`-Knoten und einen Worker auf, wie
+> [Skalierung](../production/scaling.html) beschreibt.
+
+`ENCRYPTION_SECRET` muss gesetzt sein, bevor Anmeldedaten eingegeben werden. Sobald die Anmeldedaten
+aus dem Seed kommen, ist die Datenbank im Grunde ein Cache, sodass ihr Austausch bedeutet, den Seed erneut
+anzuwenden, statt alles von Hand neu einzugeben.
+
+Die beiden Probes brauchen keine Anmeldung. Unter einer [`BASE_URL`](../customization/server.html#env_BASE_URL) beginnen ihre Pfade mit ihr, und
+[Überwachung](../production/monitoring.html) beschreibt, was jede prüft.
diff --git a/i18n/de/_configure/seed/managed-objects.md b/i18n/de/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..4785963
--- /dev/null
+++ b/i18n/de/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Verwaltete Objekte
+parent: Config-Seed
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Verwaltete Objekte
+{: .no_toc }
+
+Wie der Seed die aufgeführten Objekte verwaltet und wie er Geheimnisse heraushält
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Einzeilige Abschnitte gelten ganz oder gar nicht
+
+`ldap`, `settings` und `chat` sind jeweils eine **einzelne Zeile**, daher muss der Seed alle ihre Felder deklarieren; die anderen Abschnitte sind Listen.
+
+Ein Seed, der ein Feld auslässt, verweigert den Start und nennt es:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Deklarieren Sie einen leeren Wert ausdrücklich mit `""` oder `false`. Einige Felder sind optional, und ein ausgelassenes bleibt unverändert:
+
+| Abschnitt | Optionale Felder |
+|---|---|
+| `ldap` | `description`, `credential` (Anmeldedaten zum Binden) und `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` und `extra_headers` |
+| `settings` | Keine |
+
+`settings` deckt nur die Mail-Felder und die URL ab; alle übrigen Einstellungen bleiben bearbeitbar.
+
+---
+
+## Die Datei enthält keine Geheimnisse
+
+Jedes `${VARIABLE}` wird durch diese Umgebungsvariable ersetzt (auf Kubernetes aus einem `Secret`), sodass die Datei in Git liegen kann.
+
+Eine nicht gesetzte Variable ist ein **fataler Fehler**, sodass nie ein Platzhalter als Passwort gespeichert werden kann.
+
+Anmeldedaten können auch einen [Secret Store](../secret-stores) verwenden (`secret_store`, `secret_ref`); `vault_path` entfällt in 8.
+
+---
+
+## Verwaltete Objekte
+
+Ein Objekt, das aus dem Seed stammt, wird als **verwaltet** markiert:
+
+- Es wird bei **jedem** Start durchgesetzt, sodass die Datei maßgeblich bleibt.
+- Es ist schreibgeschützt: Die API antwortet mit **403**, die Oberfläche deaktiviert Bearbeiten und Löschen, und seine eigene Seite sagt, dass es aus der
+  Config-Seed-Datei stammt und schreibgeschützt ist.
+- Nur der Seed kann die Markierung setzen oder entfernen.
+
+Von Hand angelegte Objekte werden **nie angefasst**, es sei denn, der Seed deklariert denselben Namen. Dieser Datensatz wird dann **übernommen**:
+Die deklarierten Felder werden durchgesetzt, und er wird schreibgeschützt. Die Übernahme wird als Warnung und im Audit-Verlauf protokolliert.
+
+Das Anwenden des Seeds ist idempotent: Datensätze, die bereits passen, bleiben unberührt, daher meldet ein Neustart normalerweise `0 updated`.
+
+Ein deklariertes Repository, dessen Arbeitsverzeichnis fehlt, wird bei jedem Start **erneut geklont**, sodass ein fehlgeschlagener erster Klon
+wiederholt wird. Die Zeile *Repositories* der Seite Status zeigt jedes Repository ohne Arbeitsverzeichnis.
+
+### Ein Objekt entfernen
+
+Ein Objekt aus der Datei zu entfernen, **gibt es frei**: Der Datensatz bleibt und wird wieder bearbeitbar. Einen ganzen Abschnitt zu löschen,
+bewirkt dasselbe.
+
+Fügen Sie einem Listenabschnitt `prune: true` hinzu, um die verwalteten Datensätze zu **löschen**, die die Datei nicht mehr deklariert:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` löscht nie einen von Hand angelegten Datensatz.
+
+### Den Seed abschalten
+
+Das Entfernen von `CONFIG_SEED_PATH` gibt **nichts** frei: Der Seed wird nicht mehr angewendet, und die von ihm verwalteten Datensätze bleiben verwaltet
+und schreibgeschützt. Um sie wieder zu bearbeiten, geben Sie sie zuerst frei: Richten Sie `CONFIG_SEED_PATH` auf eine Datei ohne sie (eine leere Datei deklariert
+nichts und gibt jeden Datensatz frei), lassen Sie sie bei einem Start oder Neuladen anwenden und entfernen Sie dann die Variable. Die freigegebenen Datensätze bleiben, wie
+sie sind, und werden bearbeitbar.
diff --git a/i18n/de/_configure/seed/reloading.md b/i18n/de/_configure/seed/reloading.md
new file mode 100644
index 0000000..585282f
--- /dev/null
+++ b/i18n/de/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Neuladen und Start
+parent: Config-Seed
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Neuladen und Start
+{: .no_toc }
+
+Die Datei ohne Neustart ändern, und was beim Start passiert
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Datei ohne Neustart ändern
+
+Der Seed wird alle `CONFIG_SEED_RELOAD_SECONDS` neu gelesen (standardmäßig 60, `0` schaltet es ab)
+und erneut angewendet, wenn sich sein Inhalt geändert hat. Eine in Git committete Änderung erreicht daher
+eine laufende Instanz automatisch: Auf Kubernetes wird eine `ConfigMap` innerhalb von etwa einer Minute unter dem Pod neu
+eingehängt, und die nächste Prüfung übernimmt sie. Es gibt keinen Rollout und keinen Neustart, und kein
+Hook muss etwas aufrufen.
+
+Bei einer unveränderten Datei berechnet die Abfrage einen Hash und hört auf, sodass sie nie eine bereits
+angewendete Zeile neu schreibt.
+
+Um die Datei sofort anzuwenden, statt auf die nächste Prüfung zu warten, verwenden Sie eine dieser Möglichkeiten:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Beide **erzwingen** eine Anwendung, auch wenn sich die Datei nicht geändert hat. Eine erzwungene Anwendung setzt einen
+verwalteten Datensatz, der direkt in der Datenbank bearbeitet wurde, erneut durch und klont ein deklariertes Repository erneut,
+dessen Arbeitsverzeichnis fehlt.
+
+{: .note }
+> Ein Neuladen ist **nie fatal**, anders als die Anwendung beim Start. Eine Instanz, die bereits
+> bedient, behält ihre aktuelle Konfiguration, der Grund wird protokolliert, und die Zeile *Konfigurations-Seed*
+> auf der Seite Status wird rot und nennt ihn. Ein in Git gepushter Tippfehler darf keine laufende Instanz
+> lahmlegen, ohne dass ein Betreiber etwas tut.
+>
+> Derselbe fehlerhafte Inhalt wird auch nicht bei jeder Prüfung erneut versucht; sonst würde eine einzige schlechte Änderung
+> denselben Fehler endlos ins Protokoll schreiben. Korrigieren Sie die Datei oder rufen Sie den Endpunkt auf, um es
+> sofort erneut zu versuchen.
+
+---
+
+## Ein fehlerhafter Seed verweigert den Start
+
+Eine unlesbare Datei, ungültiges YAML, ein unbekanntes Feld, ein doppelter Name oder eine nicht aufgelöste
+`${VARIABLE}` lassen den Server **beenden**, statt zu starten. Das gilt nur für den **Start**:
+Was dieselbe Datei mit einer bereits laufenden Instanz macht, steht im Hinweis oben.
+
+Das ist Absicht. Mit der vorherigen Konfiguration weiterzumachen, würde eine Instanz hinterlassen, deren
+Verhalten nicht mehr dem Manifest entspricht, das sie beschreiben soll, ohne dass etwas
+die Abweichung meldet. Der Grund wird sowohl auf die Standardfehlerausgabe als auch in die Protokolldatei geschrieben, sodass
+`kubectl logs` und `docker logs` ihn zeigen.
+
+Die Validierung ist streng: Unbekannte Felder werden abgewiesen statt ignoriert, und der Fehler nennt
+den betroffenen Schlüssel:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Eine leere Datenbank richtet sich selbst ein
+
+Mit eingeschaltetem `ALLOW_SCHEMA_CREATION` (dem Standard) erhält eine Datenbank, die **überhaupt keine
+AnsibleForms-Tabellen** enthält, beim Start ihr Schema. Eine frische Bereitstellung startet daher,
+ohne dass jemand den Endpunkt `/schema` von Hand aufrufen muss.
+
+Die Vorbedingung ist absichtlich streng: Das Anlegen des Schemas **löscht zuerst jede Tabelle**, daher
+läuft es nur gegen eine vollständig leere Datenbank. Eine Datenbank, der eine
+Spalte fehlt oder die Tabellen, aber keine Benutzerkonten hat, ist *nicht* leer und bleibt unberührt;
+die Schema-Patches behandeln diese Fälle.
diff --git a/i18n/de/_configure/users-and-groups.md b/i18n/de/_configure/users-and-groups.md
new file mode 100644
index 0000000..9bea9f9
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Benutzer und Gruppen
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Benutzer und Gruppen
+{: .no_toc }
+
+Die lokalen Benutzer und Gruppen, die aus LDAP und Single Sign-on daneben und das Sperren einer Anmeldung
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: Verwalten Sie unter **Einstellungen > Zugriff > Benutzer** und **Gruppen**, wer sich anmelden darf, mit der Rollenoption `showSettings`.
+
+Der integrierte Admin, die Anmeldereihenfolge und die Rollenzuordnung lokaler Konten stehen unter [Lokale Konten](authentication/local.html).
+
+---
+
+## In diesem Abschnitt
+
+| Seite | Inhalt |
+|---|---|
+| [Ein lokaler Benutzer](users-and-groups/local-user.html) | Einen lokalen Benutzer hinzufügen und die Tabs seiner Seite |
+| [Mehrere Gruppen](users-and-groups/several-groups.html) | Ein lokaler Benutzer in mehreren Gruppen und seine Rollen |
+| [Eine lokale Gruppe](users-and-groups/local-group.html) | Die Seite einer lokalen Gruppe und ihre Tabs |
+| [Verzeichnisbenutzer und -gruppen](users-and-groups/directory.html) | Benutzer und Gruppen aus LDAP, Entra ID und OIDC, wie zuletzt gesehen |
+| [Eine Anmeldung sperren](users-and-groups/blocking-a-sign-in.html) | Anmeldung erlauben: einen Benutzer sperren, ohne etwas zu löschen |
+
+
+---
+
+## Die Listen
+
+Die Listen **Benutzer** und **Gruppen** zeigen die lokalen Benutzer und Gruppen und daneben die aus LDAP und Single Sign-on.
+
+Ein Benutzer oder eine Gruppe aus LDAP, Entra ID oder OIDC wird aufgeführt, sobald er sich angemeldet hat (oder bei einer Anmeldung gesehen wurde) oder sobald eine Rolle ihn nennt.
+Die Spalte **Herkunft** sagt, woher jeder stammt: Lokal, LDAP, Microsoft Entra ID oder OIDC. Ab 7.3.0 hat die Liste **Benutzer** außerdem
+eine Spalte **Letzte Anmeldung**, die sagt, wann sich jeder Benutzer zuletzt angemeldet hat.
+
+Eine Zeile öffnet die Seite ihres Benutzers oder ihrer Gruppe. **Benutzer hinzufügen** und **Gruppe hinzufügen** legen einen lokalen an.
+
+---
+
+## Konten, die Admin-Rechte gewähren
+
+Die Rolle admin in config.yaml nennt lokale Gruppen und Benutzer, daher darf nur ein Admin die Konten und Gruppen ändern, die sie nennt.
+
+Ein Benutzer mit `showSettings`, aber ohne die Rolle admin kann ein lokales Konto, das die Rolle admin nennt (direkt oder über eine seiner Gruppen), weder ändern noch sperren,
+umgruppieren, sein Passwort setzen oder löschen. Ebenso wenig kann er eine Gruppe, die die Rolle admin nennt, anlegen, umbenennen oder löschen
+oder einen Benutzer in eine solche aufnehmen. Dasselbe gilt für einen LDAP- oder SSO-Benutzer, der der Rolle admin zugeordnet ist: Ihn zu sperren,
+seine Sitzungen zu beenden, ihn zu vergessen und seine API-Token zu widerrufen, ist Sache eines Admins. Der Server beantwortet eine solche Anfrage mit `403`.
+
diff --git a/i18n/de/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/de/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..b27b592
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Eine Anmeldung sperren
+parent: Benutzer und Gruppen
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Eine Anmeldung sperren
+{: .no_toc }
+
+Anmeldung erlauben: einen Benutzer sperren, ohne etwas zu löschen
+{: .fs-6 .fw-300 }
+
+Der Schalter **Anmeldung erlauben** sperrt einen Benutzer, lokal oder aus einem Verzeichnis, ohne etwas zu löschen.
+
+Ausgeschaltet, nach einer Bestätigung, enden die Sitzungen des Benutzers sofort, und jede Anmeldung wird abgewiesen, bis Sie den Schalter wieder einschalten.
+Die Benutzerliste hat dafür **Anmeldung sperren** und **Anmeldung erlauben** im Menü jeder Zeile.
+
+Sie können den Benutzer `admin` nicht sperren, und auch nicht Ihre eigene Anmeldung.
diff --git a/i18n/de/_configure/users-and-groups/directory.md b/i18n/de/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..cba99fb
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Verzeichnisbenutzer und -gruppen
+parent: Benutzer und Gruppen
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Verzeichnisbenutzer und -gruppen
+{: .no_toc }
+
+Benutzer und Gruppen aus LDAP, Entra ID und OIDC, wie zuletzt gesehen
+{: .fs-6 .fw-300 }
+
+Ein Benutzer aus LDAP, Entra ID oder OIDC hat seine Seite unter `/settings/users/<source>/<name>`, mit `ldap`, `azuread` oder `oidc`
+als Herkunft, etwa `/settings/users/ldap/jdoe`. Sie zeigt schreibgeschützt, was bei der letzten Anmeldung des Benutzers festgehalten wurde,
+da das Verzeichnis oder der Identitätsanbieter bestimmt, wer der Benutzer ist und welche Gruppen er hat.
+
+Ihre Tabs sind die eines lokalen Benutzers. **Details** hat den Schalter **Anmeldung erlauben**, den Benutzernamen, die Herkunft, den Namen,
+die E-Mail, wann der Benutzer zum ersten Mal gesehen wurde, und seine letzte Anmeldung. **Gruppen** listet die Gruppen der letzten Anmeldung auf.
+**API-Tokens** listet die API-Token des Benutzers auf, und **Widerrufen** beendet eines sofort.
+
+Oben rechts meldet **Sitzungen beenden** den Benutzer jetzt überall ab. **Vergessen** entfernt den Datensatz, der bei seiner nächsten Anmeldung
+zurückkommt; seine Jobs, gespeicherten Jobs und Zeitpläne bleiben. Ein gesperrter Benutzer kann nicht vergessen werden, da ihn das
+wieder hereinlassen würde: Der Server antwortet mit `409`, erlauben Sie also zuerst seine Anmeldung.
+
+Die Gruppen dieses Datensatzes sind auch die Gruppen, mit denen die Sitzung des Benutzers arbeitet, live gelesen. Einen angemeldeten Benutzer zu vergessen,
+lässt ihn ohne Gruppen und ohne die Rollen, die diese Gruppen gewähren, bis er sich erneut anmeldet.
+
+Eine Verzeichnisgruppe hat ihre Seite unter `/settings/groups/<source>/<name>`, schreibgeschützt, mit den Tabs **Details**,
+**Benutzer** (die Benutzer, die bei ihrer letzten Anmeldung darin gesehen wurden), **Rollen** und **Formulare**.
diff --git a/i18n/de/_configure/users-and-groups/local-group.md b/i18n/de/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..e3a7e2f
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Eine lokale Gruppe
+parent: Benutzer und Gruppen
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Eine lokale Gruppe
+{: .no_toc }
+
+Die Seite einer lokalen Gruppe und ihre Tabs
+{: .fs-6 .fw-300 }
+
+Die Seite einer Gruppe, `/settings/groups/<id>`, hat diese Tabs:
+
+| Tab | Was er zeigt |
+|---|---|
+| **Details** | Den Namen und die Beschreibung |
+| **Benutzer** | Die Benutzer in der Gruppe; **Benutzer hinzufügen** fügt einen hinzu, das Menü einer Zeile oder die Kontrollkästchen entfernen einen |
+| **Rollen** | Die Rollen, die die Gruppe nennen |
+| **Formulare** | Die Formulare, die diese Rollen öffnen |
+
+Eine Gruppe mit Benutzern kann nicht gelöscht werden: Entfernen Sie zuerst ihre Benutzer. Die Gruppe `admins` kann nie gelöscht oder umbenannt werden.
diff --git a/i18n/de/_configure/users-and-groups/local-user.md b/i18n/de/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..438e830
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Ein lokaler Benutzer
+parent: Benutzer und Gruppen
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Ein lokaler Benutzer
+{: .no_toc }
+
+Einen lokalen Benutzer hinzufügen und die Tabs seiner Seite
+{: .fs-6 .fw-300 }
+
+**Benutzer hinzufügen** öffnet einen Assistenten in drei Schritten: **Benutzer** (Benutzername, Beschreibung, E-Mail), **Passwort** und **Gruppe**.
+
+Die Seite eines Benutzers, `/settings/users/<id>`, hat diese Tabs:
+
+| Tab | Was er zeigt |
+|---|---|
+| **Details** | Den Schalter **Anmeldung erlauben**, den Benutzernamen, die Beschreibung, die E-Mail und ab 7.3.0 die **Letzte Anmeldung** |
+| **Gruppen** | Die Gruppen, denen der Benutzer angehört |
+| **Rollen** | Die Rollen des Benutzers und was jede vergibt: **Direkt**, **Über** eine Gruppe oder **Alle** |
+| **Formulare** | Die Formulare, die diese Rollen öffnen |
+| **Jobs** | Die Jobs, die der Benutzer gestartet hat, die neuesten zuerst |
+| **Gespeicherte Jobs** | Die Formularwerte, die der Benutzer gespeichert hat, um sie erneut auszuführen |
+| **Zeitpläne** | Die Jobs, die der Benutzer mit Später ausführen eingeplant hat |
+| **Aktivität** | Was das Audit-Protokoll über die Aktionen des Benutzers festgehalten hat |
+| **API-Tokens** | Die API-Token des Benutzers, mit Erstellung, Ablauf und letzter Verwendung; **Widerrufen** beendet eines sofort |
+
+Ab 7.3.0 werden die Anmeldungen eines lokalen Benutzers festgehalten, wie es bei LDAP- und SSO-Benutzern bereits geschah: **Letzte Anmeldung** zeigt die neueste, und
+die Benutzerliste hat für jede Herkunft eine sortierbare Spalte **Letzte Anmeldung**, sodass ein Konto, das niemand verwendet, auffällt. Eine abgewiesene Anmeldung wird nicht
+festgehalten, und ein lokaler Benutzer, der sich seit dem Upgrade nicht angemeldet hat, zeigt `–`.
+
+**Passwort ändern** und **Löschen** befinden sich oben rechts. Der Benutzer `admin` kann nie gelöscht oder umbenannt werden.
diff --git a/i18n/de/_configure/users-and-groups/several-groups.md b/i18n/de/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..0d1872d
--- /dev/null
+++ b/i18n/de/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Mehrere Gruppen
+parent: Benutzer und Gruppen
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Mehrere Gruppen
+{: .no_toc }
+
+Ein lokaler Benutzer in mehreren Gruppen und seine Rollen
+{: .fs-6 .fw-300 }
+
+Ein lokaler Benutzer kann mehreren Gruppen angehören und erhält die Rollen jeder davon: Rollen nennen eine Gruppe als `local/<group>`.
+
+Im Tab **Gruppen** fügt **Gruppe hinzufügen** den Benutzer einer weiteren Gruppe hinzu, und das Menü einer Zeile oder die Kontrollkästchen entfernen eine.
+Ein Benutzer behält mindestens eine Gruppe. Die Benutzerliste hat dafür **Zu Gruppe hinzufügen** im Menü jeder Zeile.
diff --git a/i18n/de/_get_started/first-form.md b/i18n/de/_get_started/first-form.md
new file mode 100644
index 0000000..7ed604c
--- /dev/null
+++ b/i18n/de/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: Ihr erstes Formular
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# Ihr erstes Formular
+{: .no_toc }
+
+Schreiben Sie ein Playbook, bauen Sie im Designer ein Formular dafür, starten Sie es und finden Sie den Job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dieses Tutorial geht von einer frischen Installation aus, siehe [Installation](installation/). Es dauert etwa fünfzehn Minuten.
+
+---
+
+## 1. Anmelden
+
+Öffnen Sie AnsibleForms im Browser und melden Sie sich als Administrator an.
+
+Das Standardkonto ist `admin` / `AnsibleForms!123` (oder Ihre [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)-Werte); die Seite **Formulare** öffnet sich:
+
+![Die Seite Formulare mit Beispielformularen](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Das Playbook schreiben
+
+Ein `ansible`-Formular führt ein Playbook aus dem Playbook-Ordner aus, daher kommt das Playbook zuerst. Speichern Sie dies als `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+Das Playbook liest vier Variablen. Das Formular, das Sie als Nächstes bauen, sendet sie als Extravars, eine pro Feld.
+
+Legen Sie die Datei in den Ordner `playbooks` des persistenten Ordners
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); legen Sie den Ordner an, falls er noch nicht existiert:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Aus dem Quellcode</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Der Ordner, den Sie unter `/app/dist/persistent` eingehängt haben, im Installationsbeispiel `/srv/apps/ansibleforms/persistent`:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+Der Ordner `data/playbooks` des docker-compose-Projekts:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+Das persistente Volume, im AnsibleForms-Pod unter `/app/dist/persistent` eingehängt. Ermitteln Sie den Namen des Pods und kopieren Sie die Datei hinein:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+Der Ordner `persistent/playbooks` des Servers, im Installationsbeispiel `/srv/apps/ansibleforms/server`:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Wenn bei einem Git-Repository **Für Playbooks verwenden?** eingeschaltet ist, werden die Playbooks stattdessen aus diesem Repository ausgeführt:
+> committen Sie `hello.yaml` dort. Siehe [Designer und Git](gui/designer-and-git.html).
+
+---
+
+## 3. Das Formular erstellen
+
+Formulare sind YAML-Dateien im Formularordner. Der Designer bearbeitet sie im Browser und prüft sie vor dem Speichern.
+
+1. Klicken Sie im oberen Menü auf **Designer** und dann im linken Menü auf **Formulare**.
+2. Klicken Sie auf den Schalter oben rechts (**Designer starten**). Er sperrt die Konfiguration, damit niemand anderes sie gleichzeitig
+   bearbeitet, und zeigt danach **Von mir gesperrt**.
+3. Klicken Sie auf **Neue Datei**, die erste Schaltfläche der Werkzeugleiste, und geben Sie den Dateinamen `hello-world.yaml` ein. Der Designer fügt
+   ihr ein Formular namens `New Form` hinzu.
+4. Ersetzen Sie das YAML im Editor durch dieses Formular:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Klicken Sie auf **Validieren** (das Häkchen) und dann auf **Speichern**. Beim Speichern wird `hello-world.yaml` in den Formularordner geschrieben.
+6. Klicken Sie erneut auf den Schalter, um die Sperre freizugeben.
+
+![Der Designer beim Bearbeiten eines Formulars](assets/screenshots/designer.jpg)
+
+Das Formular verwendet vier Feldtypen:
+
+| Feld | Typ | Was es tut |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Ein Pflicht-Textfeld |
+| `target_env` | [`enum`](formfields/enum.html) | Eine Auswahlliste mit einer festen Liste von `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Eine Auswahlliste, gefüllt von einem lokalen [Ausdruck](expressions/local.html); `__auto__` wählt den ersten Eintrag |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Ein Kontrollkästchen, gesendet als `true` oder `false` |
+
+`vm_size` zeigt beide Spalten, `size` und `cpus`, und sendet `size`, die erste; `valueColumn` wählt eine andere.
+
+`roles: [default]` erlaubt jedem angemeldeten Benutzer, das Formular auszuführen, und `categories: [Default]` legt es in die Kategorie, die die Standard-`config.yaml`
+definiert.
+
+{: .note }
+> Sie können `hello-world.yaml` auch nach [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) kopieren und [in VS Code validieren](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Starten
+
+Öffnen Sie das Formular über die Seite **Formulare**: klicken Sie im oberen Menü auf **Formulare** und wählen Sie **Hello world** in der Kategorie **Default**.
+
+Geben Sie Ihren Namen ein und ändern Sie die anderen Felder nach Belieben. Klicken Sie auf **Extra-Variablen anzeigen**, um zu sehen, was das Playbook
+erhält, und dann auf **Senden**:
+
+![Ein Formular](assets/screenshots/form.jpg)
+
+---
+
+## 5. Die Ausgabe verfolgen
+
+Der Job startet sofort, und seine Ausgabe erscheint während der Ausführung unter dem Formular und endet mit einem Balken **Abgeschlossen**:
+
+![Die Ausgabe eines Jobs](assets/screenshots/run.jpg)
+
+Der Debug-Task gibt Ihre Werte aus, zum Beispiel `Hello Alice: a small machine in development (dry run: True)`.
+
+Die Warnung zum impliziten localhost ist ohne Inventar zu erwarten; ein echtes Formular setzt [`inventory`](forms/ansible.html).
+
+---
+
+## 6. In der Job-Historie finden
+
+Jeder Start wird als Job aufbewahrt. Klicken Sie im oberen Menü auf **Jobs**: der neue Job steht ganz oben unter **Alle Jobs**.
+
+Klicken Sie auf den Job, um seine Ausgabe erneut zu sehen, und auf **Extra-Variablen anzeigen**, um zu sehen, was gesendet wurde. Die Symbole vor jedem Job
+starten ihn erneut oder löschen ihn:
+
+![Die Job-Historie](assets/screenshots/job-output.jpg)
+
+---
+
+## Nächste Schritte
+
+Bauen Sie mit den Referenzseiten auf diesem Formular auf:
+
+* **[Formulare](forms/)** : alle Formulareigenschaften, Vorlagen auf Runnern, Workflow-Formulare, Genehmigungspunkte und Benachrichtigungen
+* **[Formularfelder](formfields/)** : alle Feldtypen, mit Validierung, Abhängigkeiten und Layout
+* **[Ausdrücke](expressions/)** : Felder aus REST-APIs, Datenbanken und Dateien füllen
+* **[Rollen](config/roles.html)** und **[Kategorien](config/categories.html)** in `config.yaml` : festlegen, wer welches Formular sieht
+* **[Wie es funktioniert](how-it-works.html)** : was hinter einem Start passiert und wo alles gespeichert wird
diff --git a/i18n/de/_get_started/installation/docker-compose.md b/i18n/de/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..667410d
--- /dev/null
+++ b/i18n/de/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Installation
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+AnsibleForms, seine RTE und MySQL gemeinsam mit docker-compose oder podman-compose installieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Das [docker-compose-Projekt](https://github.com/ansibleforms/docker) betreibt drei Container: MySQL, die AnsibleForms-App und die RTE
+(Laufzeitumgebung), die die Playbooks ausführt. Es enthält ihre Einstellungen, Beispielformulare und Playbooks, daher ist die einzige weitere Voraussetzung
+Docker oder Podman mit dem zugehörigen Compose-Werkzeug.
+
+Der [Installer](installer.html) lädt dieses Projekt herunter, füllt seine Einstellungen und Secrets aus und startet es mit einem Befehl. Diese Seite
+richtet es von Hand ein.
+
+---
+
+## Voraussetzungen
+
+Bevor Sie beginnen, benötigen Sie:
+
+* **Linux-Rechner** : eine beliebige Distribution, mit bescheidener CPU und wenig Arbeitsspeicher
+* **Zugriff auf GitHub** : um das docker-compose-Projekt von GitHub herunterzuladen oder zu klonen
+* **Docker oder Podman** : eine Container-Engine, deren Installation weiter unten beschrieben ist
+* **Ein Compose-Werkzeug** : Docker Compose oder podman-compose, um die drei Container aus wenigen Konfigurationsdateien zu starten
+
+**VIDEO**: [So installieren Sie AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Einen Installationsort wählen
+
+Legen Sie einen Ordner für das Projekt an; die Beispiele verwenden `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Das docker-compose-Projekt klonen
+
+Installieren Sie Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Klonen Sie dann das docker-compose-Projekt in diesen Ordner:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Die richtigen Berechtigungen setzen
+
+Die App und die RTE laufen als Benutzer `node` (uid 1000), geben Sie diesem Benutzer daher den Ordner `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Wenn Sie von 6 kommen, dessen Container als root lief, führen Sie dasselbe `chown` einmal aus, bevor Sie 7 starten. MySQL holt sich beim Start seinen eigenen Ordner zurück.
+
+---
+
+## Eine Container-Engine installieren
+
+Installieren Sie Docker oder Podman, jeweils mit dem zugehörigen Compose-Werkzeug:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Installieren Sie Docker Engine mit dem Compose-Plugin aus dem Repository von Docker
+(siehe die [Docker-Installationsanleitungen](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Sorgen Sie dann dafür, dass Namen innerhalb der Container aufgelöst werden, und starten Sie Docker als Dienst:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman braucht keinen Dienst. Installieren Sie es zusammen mit podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Anpassen
+
+Prüfen Sie die Variablen in den Dateien `.env` und `docker-compose.yml` und ändern Sie jedes Passwort: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` und `RTE_TOKEN`. [Mehr über die Umgebungsvariablen](../customization)
+
+Die App verbindet sich mit MySQL als `ansibleforms` (`MYSQLDB_USER`), mit allen Rechten auf dem Schema `AnsibleForms` und keinen
+anderswo; root ist nur für MySQL selbst da. MySQL legt diesen Benutzer nur bei seinem ersten Start an: eine Installation, die sich bisher als root
+verbunden hat, legt ihn einmalig an, wie das [README](https://github.com/ansibleforms/docker#database) des Projekts zeigt.
+
+Die RTE wird nicht auf dem Host veröffentlicht. Seit 7.3.0 verbindet sich die App mit `RTE_TOKEN` auf `http://rte:8000` und hält einen WebSocket offen
+(`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)): die RTE bekommt keine Datenbankeinstellungen und nicht die `.env`, nur ihr Token und einige
+eigene Einstellungen in `docker-compose.yml`. Der Konfigurations-Seed `data/seed.yaml` deklariert RTE-Anmeldedaten mit dem Token und dieser
+Adresse sowie den Standard-Runner `rte`, Modus inbound, der sich damit anmeldet. Die RTE führt die Playbooks aus demselben Ordner `data` aus
+(`RTE_FILES=local`). Wenn Ihre Playbooks weitere Collections oder Python-Bibliotheken brauchen, bauen Sie eine eigene RTE
+und lassen den Dienst `rte` darauf zeigen (siehe [Eine eigene RTE bauen](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Das docker-compose-Projekt starten
+
+Starten Sie die drei Container im Hintergrund. Die App wartet, bis MySQL gesund ist, und verbindet sich dann mit der RTE:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Die Anwendung testen
+
+Sobald die Container laufen, öffnen Sie AnsibleForms im Browser:
+
+* Öffnen Sie `https://your_ip` (Port 443, siehe `WEBAPP_LOCAL_PORT` in der .env-Datei)
+* Melden Sie sich als `admin` mit dem `ADMIN_PASSWORD` aus der `.env`-Datei an; solange es noch das Standardpasswort `AnsibleForms!123` ist, wählen Sie ein neues Passwort
+* Prüfen Sie unter **Verbindungen > Runner**, dass die RTE als `rte` aufgeführt ist, der Standard-Runner, und dass ihre Seite die
+  **Verbindung** als **Verbunden** zeigt
+* Nächste Schritte:
+  * Erstellen Sie Formulare, indem Sie YAML-Dateien in den Ordner data/forms/ legen oder den eingebauten Designer verwenden
+  * Legen Sie Ihre Playbooks in den Ordner data/playbooks/
+  * Fügen Sie eine LDAP-Verbindung hinzu
+  * Fügen Sie Benutzer und Gruppen hinzu
+  * Fügen Sie Runner für Vorlagenformulare hinzu: AWX, AAP oder Ascender, Semaphore, Rundeck oder Jenkins
+  * Fügen Sie Anmeldedaten für externe Verbindungen hinzu, etwa andere MySQL-Server oder REST-APIs, oder um sie an Ansible-Playbooks zu übergeben
+  * Verbinden Sie Git-Repositories und legen Sie fest, ob Ihre Formulare und/oder Playbooks mit einem Repository synchronisiert werden
+
+---
+
+## Dateistruktur
+
+Das docker-compose-Projekt hat folgende Ordnerstruktur:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/de/_get_started/installation/docker.md b/i18n/de/_get_started/installation/docker.md
new file mode 100644
index 0000000..ac109fb
--- /dev/null
+++ b/i18n/de/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Installation
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Die Images der AnsibleForms-App und der RTE mit Docker oder Podman betreiben, neben einem eigenen MySQL-Server
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Sie können AnsibleForms mit Docker oder Podman als zwei Container betreiben, die App und die RTE, die die Playbooks ausführt, verbunden mit einer MySQL-Datenbank.
+
+---
+
+## Voraussetzungen
+
+Bevor Sie beginnen, benötigen Sie:
+
+* **Docker oder Podman** : eines davon installiert und laufend
+* **MySQL** : installiert und laufend
+
+---
+
+## MySQL installieren
+
+Installieren Sie MySQL 8+ oder MariaDB auf einem Linux-Server, den der Container erreichen kann:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu liefert MySQL 8 mit:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian liefert statt MySQL MariaDB mit, das AnsibleForms ebenfalls unterstützt:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 und neuer sowie seine Nachbauten liefern MySQL 8 in AppStream mit:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms verbindet sich über das Netzwerk mit der Datenbank, als `DB_USER` mit `DB_PASSWORD`. Geben Sie ihm einen eigenen Benutzer, mit Rechten nur auf
+dem Schema `AnsibleForms`, nicht root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Mehr braucht AnsibleForms nicht: damit legt es sein Schema an, aktualisiert es und erstellt seine Backups. Die Seite **Status** und das Protokoll
+warnen, wenn der Benutzer Rechte auf jeder Datenbank hat. Unter Ubuntu und Debian lauscht der Server nur auf localhost: setzen Sie `bind-address` in seiner
+Konfiguration, damit die Container ihn erreichen.
+
+---
+
+## Die Ordner vorbereiten
+
+AnsibleForms 7 läuft in zwei Containern: der App und der RTE (Laufzeitumgebung), die die Playbooks ausführt. Beide hängen einen Ordner für
+Ihre `config.yaml`, Formulare, Playbooks, Protokolle und Zertifikate ein sowie einen Ordner für den SSH-Schlüssel. Die Images laufen als Benutzer `node` (uid 1000),
+geben Sie diesem Benutzer daher beide Ordner:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Legen Sie die Einstellungen der App in eine Umgebungsdatei: die Datenbankverbindung,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET), bevor Sie Anmeldedaten speichern, das Token, das App und
+RTE teilen ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), mindestens 16 Zeichen), und den Konfigurations-Seed, der die RTE deklariert:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+Die RTE bekommt eine eigene Datei, ohne die Einstellungen der Datenbank: seit 7.3.0 verbindet sich die App mit ihr und hält einen WebSocket offen
+(`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)), und sie führt die Playbooks aus denselben Ordnern aus (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+Der [Konfigurations-Seed](../seed/) deklariert RTE-Anmeldedaten mit der Adresse der RTE und ihrem Token sowie den Standard-Runner `rte`, der sich
+damit anmeldet:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Die Container starten
+
+Starten Sie die veröffentlichten Images aus der GitHub Container Registry (siehe [Image-Tags](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) für die App und
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) für die RTE.
+
+Der Seed fügt die RTE unter **Verbindungen > Runner** als Runner `rte` hinzu, den Standard-Runner, sodass Playbook-Formulare ohne weitere
+Einrichtung darauf laufen. Die App legt das Schema beim ersten Start an und verbindet sich mit der RTE, sobald beide laufen (eine Beispiel-`config.yaml` liegt im
+[docker-compose-Projekt](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Nach dem Start sind beide Container aufgeführt:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman nimmt dieselben Optionen und braucht keinen Dienst:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Nach dem Start sind beide Container aufgeführt:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+Die App lauscht auf Port `8000`, über HTTP, sofern Sie nicht `HTTPS=1` setzen. Die RTE wird nicht auf dem Host veröffentlicht: nur die App verbindet sich mit ihr, innerhalb
+des Netzwerks. `--stop-timeout 30` gibt der RTE beim Stoppen Zeit, ihre laufenden Playbooks zu Ende laufen zu lassen (siehe
+[Eine RTE betreiben](../rte/run.html) für die RTE-Einstellungen und für den Bau einer eigenen RTE).
+
+---
+
+## Die Anwendung testen
+
+Sobald die Container laufen, öffnen Sie AnsibleForms im Browser:
+
+* Öffnen Sie `http://your_ip:8000` (oder HTTPS, wenn Sie `HTTPS=1` gesetzt haben)
+* Melden Sie sich als `admin` / `AnsibleForms!123` an (oder mit dem Passwort, das Sie mit `ADMIN_PASSWORD` gesetzt haben), und wählen Sie ein neues Passwort
+* Prüfen Sie unter **Verbindungen > Runner**, dass die RTE als `rte` aufgeführt ist, der Standard-Runner, und dass ihre Seite die
+  **Verbindung** als **Verbunden** zeigt
+* Nächste Schritte:
+  * Erstellen Sie Formulare, indem Sie YAML-Dateien in den Ordner `forms` legen oder den eingebauten Designer verwenden
+  * Legen Sie Ihre Playbooks in den Ordner `playbooks` des eingehängten persistenten Ordners
+  * Fügen Sie eine LDAP-Verbindung hinzu
+  * Fügen Sie Benutzer und Gruppen hinzu
+  * Fügen Sie Runner für Vorlagenformulare hinzu: AWX, AAP oder Ascender, Semaphore, Rundeck oder Jenkins
+  * Fügen Sie Anmeldedaten für externe Verbindungen hinzu, etwa andere MySQL-Server oder REST-APIs, oder um sie an Ansible-Playbooks zu übergeben
diff --git a/i18n/de/_get_started/installation/from-source.md b/i18n/de/_get_started/installation/from-source.md
new file mode 100644
index 0000000..1d4ac19
--- /dev/null
+++ b/i18n/de/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Aus dem Quellcode
+parent: Installation
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Aus dem Quellcode
+{: .no_toc }
+
+AnsibleForms aus dem Quellcode bauen und mit Node.js betreiben
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wie der Code aufgebaut ist
+
+Das Repository enthält zwei Node.js-Anwendungen, die ein Build zu einer zusammenführt:
+
+* **client** : die Weboberfläche, in Vue 3 geschrieben und mit Vite zu statischen Dateien gebaut
+* **server** : die API, in Express geschrieben. Sie übergibt die Jobs an Runner, verbindet sich mit der Datenbank und liefert den gebauten Client aus.
+  Mit `AF_ROLE=rte` gestartet, ist derselbe Server die RTE (Laufzeitumgebung), die die Playbooks ausführt
+
+Nur der Client wird gebaut; seine Ausgabe landet im Ordner `views` des Servers, wie im [Docker-Image](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Voraussetzungen
+
+Bauen und Betreiben aus dem Quellcode erfordert solide Linux-Kenntnisse und etwas Wissen über Node.js. Sie installieren jede Komponente selbst. Um
+AnsibleForms ohne Container und ohne eigenen Build zu betreiben, erledigt die [native Installation](native.html) des Installers all das für Sie:
+
+* **Node.js 26** (die Version in `.nvmrc`; mindestens 24), mit npm
+* **Git**, um den Code zu holen und Repositories zu synchronisieren
+* **OpenSSH-Client**, für Git über SSH, und **sshpass**, für Playbooks, die sich mit einem SSH-Passwort verbinden
+* **MariaDB-Client** (`mariadb`, `mariadb-dump`), für Backups und Wiederherstellungen, auch bei einem MySQL-Server
+* **MySQL 8+ oder MariaDB**, vom Server aus erreichbar
+* **Ansible**, für den RTE-Prozess, der die Playbooks ausführt (`ansible-playbook` im Pfad). Der App-Prozess selbst braucht weder
+  Ansible noch Python, und mit ausschließlich Vorlagenformularen (AWX, AAP, Ascender und die anderen Runner) brauchen Sie gar keine RTE
+
+Installieren Sie sie für Ihre Distribution:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 kommt aus dem NodeSource-Repository, die anderen Werkzeuge aus Ubuntu selbst:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 kommt aus dem NodeSource-Repository, die anderen Werkzeuge aus Debian selbst:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js kommt von NodeSource und `sshpass` aus EPEL (auf RHEL selbst aktivieren Sie EPEL, wie Red Hat es beschreibt):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Prüfen Sie `node --version` (26) und `ansible-playbook --version`; für die Datenbank und ihren Benutzer siehe [MySQL installieren](docker.html#install-mysql).
+
+---
+
+## Den Code holen
+
+Klonen Sie das Repository in einen Ordner Ihrer Wahl, der dem Benutzer gehört, der die Anwendung betreiben wird. Die Beispiele verwenden `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Bauen
+
+Bauen Sie in drei Schritten, vom Repository-Ordner aus. Bauen Sie zuerst den Client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Installieren Sie dann die Abhängigkeiten des Servers:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Kopieren Sie zuletzt den gebauten Client in den Ordner `views` des Servers:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Konfigurieren
+
+Der Server liest seine Einstellungen aus Umgebungsvariablen und, in Produktion, zusätzlich aus `server/persistent/.env`, der Datei,
+in die die Einstellungsseiten schreiben.
+
+Gehen Sie von der Beispieldatei im Wurzelverzeichnis des Repositorys aus und setzen Sie mindestens die MySQL-Verbindung (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Alle Variablen sind unter [Umgebungsvariablen](../customization) beschrieben. Alles andere wird standardmäßig in `server/persistent` gespeichert:
+`config.yaml`, der Ordner `forms` und selbstsignierte Zertifikate werden dort beim ersten Start angelegt, neben den Protokollen.
+Legen Sie Ihre Playbooks in `server/persistent/playbooks` ab, oder lassen Sie `ANSIBLE_PATH` in der Umgebung der RTE, die es liest, auf einen anderen Ort zeigen.
+
+---
+
+## Ausführen
+
+Betreiben Sie AnsibleForms in Produktion oder im Entwicklungsmodus, um am Code selbst zu arbeiten:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Produktion</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Entwicklung</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Starten Sie den Server im Produktionsmodus aus dem Ordner `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Eine von der Kommandozeile gestartete Anwendung stoppt, wenn Sie sich abmelden. [PM2](https://pm2.keymetrics.io/) hält sie im
+Hintergrund am Laufen, startet sie nach einem Absturz neu und startet sie beim Booten wieder:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Playbooks laufen auf einer RTE: starten Sie denselben Server ein zweites Mal mit `AF_ROLE=rte`, auf einem eigenen Port. Die App verbindet sich mit ihr und hält
+einen WebSocket offen (`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)), und sie führt die Playbooks aus denselben Ordnern aus
+(`RTE_FILES=local`). Sie liest ebenfalls `persistent/.env`, verwendet aber keine der Datenbankeinstellungen daraus. Fügen Sie das Token, das App und RTE teilen,
+mindestens 16 Zeichen, und den Konfigurations-Seed, der die RTE deklariert, zu `persistent/.env` hinzu:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+Der [Konfigurations-Seed](../seed/) deklariert RTE-Anmeldedaten mit der Adresse der RTE und ihrem Token sowie den Standard-Runner `rte`, der sich
+damit anmeldet:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Ohne Seed fügen Sie sie unter **Verbindungen > Anmeldedaten** (RTE-Anmeldedaten mit dieser Adresse und dem Token) und
+**Verbindungen > Runner** (Typ RTE, **Modus** **Eingehend**) hinzu. Starten Sie dann die RTE, nur auf `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+Die RTE-Einstellungen sind auf der Seite [Eine RTE betreiben](../rte/run.html) beschrieben. Prüfen Sie, dass PM2 beide Prozesse aufführt:
+
+```bash
+pm2 status
+```
+
+Beide sind `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Um am Code selbst zu arbeiten, starten Sie alles aus dem Wurzelverzeichnis des Repositorys mit Live-Reload: den Server auf Port 3001, eine RTE auf Port 8010
+und den Client auf `https://localhost:8443`. In diesem Modus lesen Server und RTE stattdessen `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+Die RTE (`npm run dev:rte`) braucht `ansible-playbook` im Pfad und trägt sich selbst als Runner im Datenbankmodus ein, der veraltet ist und nur
+für die Entwicklung gedacht; `npm run dev:local` startet Client und Server ohne sie. Der [Leitfaden für Beiträge](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) beschreibt die auszuführenden Tests und Prüfungen.
+
+</div>
+</div>
+
+---
+
+## Erster Start
+
+Öffnen Sie den Server im Browser (mit der Beispiel-`.env` unter `https://your_ip:8443`). Bei einer leeren Datenbank wird das Schema beim
+ersten Start angelegt.
+
+Die Standard-Anmeldedaten des Administrators sind:
+
+* Benutzername : `admin`
+* Passwort : `AnsibleForms!123`
diff --git a/i18n/de/_get_started/installation/index.md b/i18n/de/_get_started/installation/index.md
new file mode 100644
index 0000000..800fd39
--- /dev/null
+++ b/i18n/de/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Installation
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Installation
+{: .no_toc }
+
+Wählen Sie eine Installationsmethode für AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Für Administratoren, die eine neue Instanz einrichten: wählen Sie eine Installationsmethode und folgen Sie dann ihrer Seite.
+
+---
+
+## In diesem Abschnitt
+
+AnsibleForms unterstützt mehrere Installationsmethoden, jede auf einer eigenen Seite beschrieben:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Installer](installer.html) | Ein Befehl, der einen Controller oder einen Runner auf Docker, Podman, Kubernetes oder nativ installiert und ihn danach aktualisiert und sichert |
+| [Nativ](native.html) | Die Installation des Installers ohne Container: Node.js, MariaDB und Ansible auf dem Server, AnsibleForms als systemd-Dienste |
+| [Docker](docker.html) | MySQL installieren und das fertige Docker-Image mit den nötigen Umgebungsvariablen starten |
+| [Docker Compose](docker-compose.html) | Das [docker-compose-Projekt](https://github.com/ansibleforms/docker) herunterladen und mit docker-compose sowohl MySQL als auch AnsibleForms starten |
+| [Aus dem Quellcode](from-source.html) | Alle Abhängigkeiten von Hand installieren, dann den Code bauen und starten |
+| [Kubernetes](kubernetes.html) | Das Helm-Chart installieren und AnsibleForms samt MySQL-Datenbank mit Kubernetes starten |
+
+{: .note }
+> **Empfehlung** Der Installer ist seit 7.3.0 der schnellste Weg zu einer funktionierenden Instanz: er richtet aus wenigen Fragen das Docker-Compose-Projekt auf
+> Docker oder Podman oder eine der anderen Methoden ein. Die Docker-Images enthalten alle Abhängigkeiten.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Um eine bestehende Installation auf eine neuere Version zu bringen, siehe [Aktualisieren](../upgrading/).
+
+Jede Methode betreibt neben der App eine RTE, den Container (oder Dienst), der die Playbooks ausführt. Um eine weitere hinzuzufügen, auf einem anderen Host oder in einem anderen
+Rechenzentrum, installieren Sie einen Runner mit dem [Installer](installer.html#a-runner): er verbindet sich über einen WebSocket mit AnsibleForms (ausgehend, siehe
+[Modi](../rte/modes.html)) und hält keine Datenbank-Anmeldedaten. Siehe auch [Laufzeitumgebungen](../rte/) und das Runbook
+[Eine RTE in einem anderen Rechenzentrum](../rte/another-datacenter.html).
+
+---
+
+## Image-Tags
+
+Das Image wird als `ghcr.io/ansibleforms/ansibleforms` in der GitHub Container Registry veröffentlicht, die zum
+Projekt gehört und anonyme Pulls nicht drosselt. Jede Version ab 7.0.0 wird nur dort veröffentlicht, und die 6.x-Versionen
+liegen ebenfalls dort.
+
+Seit 7 laufen Playbooks auf einer RTE, die in drei Schichten neben der App veröffentlicht wird (siehe [Die RTE-Images](../rte/images.html)):
+
+| Image | Was es ist |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | Die Webanwendung und die API, ohne python und ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Die RTE ohne python und ansible: die Basis für eine eigene |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | Die Basis mit python, ansible-core und einigen Bibliotheken: das Image, dem Sie Ihre Collections hinzufügen |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Das Core-Image mit dem Paket `ansible`, seinen Collections und Bibliotheken: die Standard-RTE |
+
+Die vier Images werden im selben Lauf gebaut und tragen dieselben Tags, daher passt ein RTE-Tag immer zu dem der App.
+
+Das alte Docker-Hub-Repository, `ansibleguy/ansibleforms`, wird nicht mehr aktualisiert. Es behält seine bisherigen
+Versionen, erhält aber keine neuen Versionen mehr, in keiner der beiden Linien. Wenn Sie von dort ziehen, wechseln Sie
+zu `ghcr.io/ansibleforms/ansibleforms` mit demselben Tag, um weiterhin Updates zu erhalten.
+
+Auf jedem Image gibt es die folgenden Tags; die RTE-Images beginnen bei 7.0.0 und haben daher keine 6.x-Tags:
+
+| Tag | Zeigt auf |
+|---|---|
+| `latest` | die neueste Version der neuesten Hauptversion |
+| `7`, `6` | die neueste Version dieser Hauptversion |
+| `7.0`, `6.5` | die neueste Version dieser Nebenversion |
+| `7.0.0`, `6.5.5` | genau diese Version |
+| `latest-rc` | den neuesten Release Candidate, oder die neueste Version, wenn diese neuer ist; jeder Kandidat hat zusätzlich ein eigenes Tag |
+
+`latest` bewegt sich nur vorwärts: ein Patch für eine ältere Hauptversion (zum Beispiel ein 6.5.x, das
+nach 7.0.0 erscheint) verschiebt `6` und `6.5`, aber nie `latest`.
+
+Um bei einer Hauptversion zu bleiben, verwenden Sie ihre Nummer (`6`) statt `latest`.
diff --git a/i18n/de/_get_started/installation/installer.md b/i18n/de/_get_started/installation/installer.md
new file mode 100644
index 0000000..33107ed
--- /dev/null
+++ b/i18n/de/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Installer
+parent: Installation
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# Der Installer
+{: .no_toc }
+
+AnsibleForms auf einem Linux-Server installieren, aktualisieren und pflegen, mit einem Befehl
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren: der schnellste Weg zu einer funktionierenden Instanz oder zu einem Runner für ein anderswo installiertes AnsibleForms. Seit 7.3.0.
+
+---
+
+## Was er installiert
+
+Der Installer stellt in einem Vollbild-Assistenten einige Fragen, zeigt jede Antwort zur Prüfung an und ändert erst dann den Server.
+Er installiert eine von zwei Rollen, auf einer von vier Engines:
+
+| Rolle | Was sie ist |
+|---|---|
+| Controller | Die vollständige Anwendung: die Weboberfläche, ihre Datenbank und ihr eigener Runner. Wählen Sie dies für eine Erstinstallation |
+| Runner | Eine RTE, die die Playbooks eines anderswo installierten AnsibleForms ausführt, etwa in einem anderen Netzwerk, einer DMZ oder einem anderen Rechenzentrum. Sie spricht mit AnsibleForms über einen einzigen WebSocket und hält keine Datenbank-Anmeldedaten |
+
+Die Engines, auf denen er sie installiert:
+
+| Engine | Wie sie läuft |
+|---|---|
+| Docker | Das [Docker-Compose-Projekt](docker-compose.html), auf Docker Engine mit dem Compose-Plugin. Die Container starten zusammen mit Docker neu |
+| Podman | Dasselbe Projekt auf Podman, rootless oder als root, mit podman-compose. Eine systemd-Unit startet die Container beim Booten |
+| Kubernetes | Das [Helm-Chart](kubernetes.html), auf dem Cluster, den `kubectl` erreicht. Ein Controller wird hinter einem Ingress bereitgestellt; ein Runner nutzt den Runner-Modus des Charts |
+| Direkt auf diesem Server | Keine Container: Node.js, MariaDB und Ansible auf dem Server und AnsibleForms als systemd-Dienste. Siehe [Native Installation](native.html) |
+
+Nach der Installation aktualisiert dasselbe Programm die Installation, sichert sie, zeigt ihren Status und entfernt sie. Es übernimmt auch ein
+AnsibleForms, das es nicht installiert hat, etwa eines, das von Hand aus dem Docker-Compose-Projekt eingerichtet wurde (siehe [Eine bestehende Installation](#an-existing-installation)).
+
+---
+
+## Ausführen
+
+Das Installationsskript lädt den Installer für diesen Server herunter und startet ihn:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Die üblichen Varianten: als root, um Docker oder Podman zu installieren, um direkt auf dem Server oder unter `/opt` zu installieren; mit einem Befehl oder
+Flags (siehe [Flags](#flags)); und ein Installer einer bestimmten Version statt der neuesten:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+Das Skript:
+
+1. Prüft, dass der Server Linux auf amd64 oder arm64 betreibt, und sucht `curl` oder `wget` sowie `sha256sum`
+2. Lädt `ansibleforms-installer_linux_<arch>` aus der neuesten Version von
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases) herunter, oder aus der Version, die `AF_INSTALLER_VERSION` nennt
+3. Prüft ihn gegen die `checksums.txt` der Version und verwendet keinen Download, dessen Prüfsumme abweicht
+4. Behält ihn als `ansibleforms-installer`, in `/usr/local/bin` für root und sonst in `~/.local/bin`, für die späteren Aktualisierungen und Backups.
+   Über sudo starten Sie ihn mit seinem vollständigen Pfad: der `secure_path` von sudo, etwa auf Red-Hat-Systemen, lässt `/usr/local/bin` oft weg
+5. Startet ihn mit den angegebenen Flags und liest die Tastatur vom Terminal, obwohl das Skript über eine Pipe kam
+
+Ohne Terminal, etwa in einem CI-Job, läuft der Installer unbeaufsichtigt (siehe [Unbeaufsichtigt](#unattended)).
+
+---
+
+## Der Assistent
+
+Der Assistent stellt eine Frage nach der anderen, mit den Schritten links aufgelistet. **Esc** geht zum vorherigen Schritt zurück, dessen Antwort erhalten bleibt:
+
+| Schritt | Was er fragt |
+|---|---|
+| Sprache | Die Sprache des Installers, standardmäßig aus der Locale dieses Servers: Katalanisch, Deutsch, Englisch, Spanisch, Französisch, Italienisch, Japanisch, Niederländisch, Polnisch, Portugiesisch oder Chinesisch. Wird zuerst gefragt, bevor der Installer etwas über eine gefundene Installation sagt |
+| Release Notes | Was in der installierten Version neu ist, mit den inkompatiblen Änderungen, Entfernungen und Abkündigungen zuerst |
+| Rolle | Controller oder Runner |
+| Engine | Docker, Podman, Kubernetes oder direkt auf diesem Server |
+| Ordner | Der Installationsordner und der Instanzname |
+| Beitreten, App, Modus | Nur ein Runner: siehe [Ein Runner](#a-runner). Den Modus nicht auf Kubernetes |
+| Netzwerk | Der Port der Weboberfläche oder des Runners. Nicht auf Kubernetes |
+| HTTPS | Wie Browser sich mit einem Controller verbinden |
+| Admin | Das Passwort des ersten Admins, zweimal eingegeben |
+| Cluster, Ingress, Speicher | Nur Kubernetes: Namespace und Release, der Ingress (ein Controller), die Storage-Klasse |
+| Prüfung | Jede Antwort: **Installieren** oder **Antworten ändern** |
+
+**Engine.** Die Liste zeigt, was dieser Server hat. Eine fehlende Engine wird als *Docker (nicht installiert: der Installer installiert es)*
+angeboten, ebenso für Podman: sobald Sie bestätigen, installiert der Installer Docker mit dem eigenen Skript von Docker (`get.docker.com`, mit
+Compose-Plugin) oder Podman mit podman-compose aus den Paketen der Distribution. Das erfordert root. Kubernetes wird angeboten, wenn `kubectl` und
+`helm` installiert sind und einen Cluster erreichen. *Direkt auf diesem Server* erfordert root und ein unterstütztes Linux und sagt, warum, wenn es ausgegraut ist.
+
+**Ordner.** Die Standardwerte:
+
+| | Controller | Runner |
+|---|---|---|
+| Ordner, als root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Ordner, als anderer Benutzer | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Instanzname, Docker oder Podman | `af` | `runner` |
+| Instanzname, nativ | `ansibleforms` | `ansibleforms-runner` |
+
+Bei Docker oder Podman enthält der Ordner die Compose-Datei und ihre `.env` mit den Secrets sowie alle Daten: Datenbank, Formulare, Playbooks
+und Protokolle. Er muss leer sein. Der Instanzname, aus Kleinbuchstaben, Ziffern und `-`, ist das Präfix der Container (`af_app`, `af_db`, `af_rte`), sodass mehrere
+Instanzen sich einen Server teilen können. Der Instanzname eines Runners ist auch der Name seines Runners unter **Verbindungen > Runner** (`RTE_NAME`).
+
+**Netzwerk.** Die Weboberfläche eines Controllers lauscht auf `443` oder dem nächsten freien Port. **HTTPS** bietet dann an:
+
+| Auswahl | Was sie bewirkt |
+|---|---|
+| HTTPS mit einem für diesen Server erstellten selbstsignierten Zertifikat | Ein Zertifikat für die Namen dieses Servers, zehn Jahre gültig. Browser bitten Sie einmal, es zu akzeptieren |
+| HTTPS mit eigenem Zertifikat und Schlüssel | Ihr eigenes Zertifikat und Ihr eigener Schlüssel im PEM-Format, von Ihrer CA oder von Let's Encrypt |
+| HTTP, HTTPS übernimmt ein vorgeschalteter Reverse Proxy | Reines HTTP auf dem Port, für nginx, Traefik oder einen Load Balancer, der HTTPS übernimmt |
+
+**Admin.** Das Passwort des Benutzers `admin`, zweimal eingegeben, damit ein Tippfehler Sie nicht aussperrt. Bleibt es leer, erzeugt der Installer ein
+starkes.
+
+**Der Abschluss.** Der Installer erzeugt das Datenbankpasswort und die Secrets, startet AnsibleForms und wartet, bis es antwortet. Dann
+zeigt er die zu öffnende Adresse, den Benutzer und das Passwort sowie den Ordner. Für ihn installierte Runner bitten um Beitritt, und ein Admin gibt sie
+unter **Verbindungen > Runner** frei (siehe [Ein Runner](#a-runner)).
+
+---
+
+## Ein Runner
+
+Ein Runner ist eine RTE für ein AnsibleForms, das anderswo läuft, ab Version 7.3.0. Er hält keine Datenbank-Anmeldedaten: er meldet sich
+mit einem eigenen Token an, das AnsibleForms in RTE-Anmeldedaten aufbewahrt (siehe [Modi](../rte/modes.html)). Nach dem Ordner fragt der Assistent
+drei weitere Dinge:
+
+| Schritt | Was er fragt |
+|---|---|
+| App | Die Adresse des AnsibleForms, für das dieser Runner arbeitet, die Adresse, die man im Browser öffnet |
+| Modus | **Ausgehend: der Runner verbindet sich mit AnsibleForms** (Standard) oder **Eingehend: AnsibleForms verbindet sich mit dem Runner** |
+| Netzwerk | Der Port des Runners, standardmäßig `8000`. Ausgehend lauschen darauf nur die Health Checks, nur von diesem Server aus erreichbar. Eingehend zusätzlich die Adresse dieses Servers, wie AnsibleForms sie erreicht |
+
+`--role runner` überspringt die Frage nach der Rolle, sodass dieser Befehl, auf dem Server des Runners ausgeführt, mit den Fragen eines Runners beginnt:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+Der Installer verbindet sich dann mit AnsibleForms. Bei einem selbstsignierten Zertifikat oder einem von einer privaten CA fragt er **Diesem Zertifikat vertrauen?**:
+ja setzt [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) auf dem Runner. Er liest die Version, die AnsibleForms betreibt,
+lehnt eine ältere als 7.3.0 ab und installiert den Runner mit genau dieser Version, unabhängig davon, welche Version der Installer selbst installieren würde.
+
+Wählen Sie ausgehend für eine DMZ, NAT oder eine Zone, die keine eingehenden Verbindungen erlaubt: nur Verkehr von diesem Server zu AnsibleForms, auf dessen
+Port. Wählen Sie eingehend für Netzwerke, in denen die zentrale Seite jede Verbindung öffnet.
+
+Die Prüfung zeigt **Registrierung: bittet um Freigabe** oder **selbst, mit einem Beitritts-Token**, wenn `--join` eines angegeben hat. Am Ende zeigt der Installer
+den Namen des Runners, seinen Modus, die App und, bei eingehend, seine Adresse, und sagt dann, dass er um Beitritt zu AnsibleForms gebeten hat: geben Sie ihn unter
+**Verbindungen > Runner** frei, nachdem Sie geprüft haben, dass der dort angezeigte Fingerabdruck derjenige ist, den er ausgibt:
+
+```
+Fingerprint: abcd-ef12
+```
+
+Der Fingerabdruck sind die ersten 8 Hexadezimalziffern des SHA-256 des Tokens des Runners, `RTE_TOKEN`, das in der `.env`-Datei des Ordners
+aufbewahrt wird (`rte.env` bei einer [nativen Installation](native.html)). Siehe [Eine RTE freigeben](../runners/registration.html#approving-an-rte). Mit `--join` wird der Runner sofort freigegeben:
+er hat sich selbst registriert und erscheint unter **Verbindungen > Runner** als verbunden.
+
+Ein eingehender Runner stellt seinen Socket über HTTPS bereit. Der Installer erstellt ein selbstsigniertes Zertifikat für die Adresse, unter der AnsibleForms
+ihn erreicht, zehn Jahre gültig, im Ordner `data/certificates`, und setzt `RTE_URL` auf `https://<address>:<port>`.
+Der Runner sendet das Zertifikat, wenn er um Beitritt bittet, und AnsibleForms pinnt es: es verbindet sich mit diesem Runner nur, wenn er genau
+dieses Zertifikat vorlegt, daher ist keine CA nötig. Der Installer gibt den Fingerabdruck des Zertifikats unter dem des Tokens aus:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+Es sind die ersten 8 Hexadezimalziffern des SHA-256 der DER-Bytes des Zertifikats, als `xxxx-xxxx`. Bevor Sie den Runner freigeben,
+prüfen Sie, dass der Freigabedialog denselben Zertifikat-Fingerabdruck zeigt. Ein mit `--join` registrierter Runner gibt ihn ebenfalls aus.
+
+Auf Kubernetes ist ein Runner der Runner-Modus des Helm-Charts und immer ausgehend: der Assistent fragt weder nach Modus noch nach Netzwerk, da ihn
+nichts von außen erreicht (siehe [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Für einen Controller auf Kubernetes installiert der Installer das [Helm-Chart](kubernetes.html) auf dem Cluster, den `kubectl` erreicht:
+
+| Frage | Standard |
+|---|---|
+| Namespace | `ansibleforms` |
+| Name des Helm-Release | `ansibleforms` |
+| Vom Ingress bereitgestellter Hostname | Keiner: Pflichtangabe, etwa `ansibleforms.example.com` |
+| Ingress-Klasse | Eine des Clusters, standardmäßig `nginx` |
+| Über HTTPS bereitstellen (mit dem Zertifikat des Ingress)? | Ja |
+| Storage-Klasse für die Volumes | Der Standard des Clusters |
+
+Das Admin-Passwort steht im Secret `<release>-secrets` dieses Namespace, unter dem Schlüssel `ADMIN_PASSWORD`. Der Installer bewahrt die
+Chart-Values in einer Datei neben seiner Statusdatei auf, `<release>-values.yaml`, und wendet sie bei Aktualisierungen erneut an; `--values` fügt eine eigene Datei hinzu. Das Chart einer Version wird kurz nach ihr veröffentlicht.
+
+Für einen Runner installiert der Installer dasselbe Chart in seinem [Runner-Modus](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): eine RTE
+allein, ohne App, ohne Datenbank und ohne Ingress, die sich mit AnsibleForms verbindet (ausgehend). Nach der Adresse der App fragt der Assistent:
+
+| Frage | Standard |
+|---|---|
+| Namespace | `ansibleforms` |
+| Name des Helm-Release | `ansibleforms-runner`, das ist auch der Name seines Runners unter **Verbindungen > Runner** |
+| Storage-Klasse für die Volumes | Der Standard des Clusters |
+
+Der Installer erzeugt das Token des Runners und setzt die Adresse der App, den Namen des Runners und, wenn Sie dem Zertifikat der App vertrauen,
+`runner.appTlsVerify: false`. Mit `--join` gibt das Beitritts-Token den Runner sofort frei; ohne es bittet der Runner um Beitritt, und der
+Installer gibt seinen Fingerabdruck aus, den Sie prüfen, bevor Sie ihn unter **Verbindungen > Runner** freigeben.
+
+---
+
+## Befehle
+
+Der Installer nimmt einen Befehl, vor oder nach seinen Flags. Ohne Befehl installiert er:
+
+| Befehl | Was er tut |
+|---|---|
+| `install` | AnsibleForms installieren, als Controller oder Runner (Standard). Auf einem Server, der bereits eine Installation hat, eine eigene oder eine gefundene, bietet er an, sie zu aktualisieren |
+| `upgrade` | Auf eine neuere Version aktualisieren, mit vorheriger Anzeige ihrer Release Notes (siehe [Aktualisieren](#upgrade)) |
+| `status` | Die Installation (ihre Rolle, Engine und Version) und ihre Container, Pods oder Dienste zeigen, und ob sie antwortet. Danach listet er jedes weitere AnsibleForms auf, das er auf dem Server findet |
+| `backup` | Die Datenbank jetzt sichern, nach `installer-backups` im Installationsordner (auf Kubernetes nach `backups` neben der Statusdatei des Installers). Ein Runner hält keine zu sichernden Daten |
+| `release-notes` | Die Release Notes einer Version zeigen, `--version` oder die dieses Installers, inkompatible Änderungen zuerst |
+| `uninstall` | Die Installation entfernen, und mit `--purge` ihre Daten |
+| `version` | Die Version des Installers ausgeben |
+
+Der Installer merkt sich die Installation in `/etc/ansibleforms/installer.json` für root oder `~/.config/ansibleforms/installer.json`
+für einen anderen Benutzer, sodass die Befehle nach `install` keine Flags brauchen und die Installation selbst finden. Dieser Ordner enthält kein Binary
+und existiert erst, wenn der Installer ein AnsibleForms installiert oder übernommen hat:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` fragt **Auch die Daten löschen (Datenbank, Formulare, Playbooks, Logs)?**. Um sie zu löschen, geben Sie den Namen der Instanz ein (auf Kubernetes das Helm-Release);
+andernfalls entfernt er die Container, Pods oder Dienste und behält die Daten.
+
+---
+
+## Flags
+
+Jedes Flag beantwortet eine Frage, die der Assistent dann überspringt. `ansibleforms-installer --help` listet sie auf:
+
+| Flag | Was es beantwortet |
+|---|---|
+| `--lang <code>` | Die Sprache: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` oder `zh` |
+| `--version <version>` | Die AnsibleForms-Version, die installiert oder auf die aktualisiert wird; standardmäßig die dieses Installers |
+| `--role <role>` | `controller` oder `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` oder `native` |
+| `--runtime <runtime>` | `docker` oder `podman` (compose) |
+| `--install-runtime` | Docker oder Podman installieren, wenn sie fehlen, ohne zu fragen |
+| `--dir <folder>` | Der Installationsordner (compose) |
+| `--name <name>` | Der Instanzname, das Präfix seiner Container (compose, standardmäßig `af`) |
+| `--port <port>` | Der Port auf dem Host: die Weboberfläche bei einem Controller, die RTE bei einem Runner |
+| `--tls <choice>` | `self`, `own` oder `off` (ein Compose-Controller) |
+| `--cert <file>`, `--key <file>` | Die Zertifikats- und Schlüsseldateien, mit `--tls own` |
+| `--admin-password <password>` | Das Passwort des ersten Admins; standardmäßig erzeugt |
+| `--join <token>` | Ein über die API erstelltes Beitritts-Token (`afj_...`), das den Runner sofort freigibt (ein Runner, unbeaufsichtigt; siehe [Beitritts-Tokens](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | Die Adresse der App, etwa `https://forms.example.com` (ein Runner) |
+| `--runner-mode <mode>` | `outbound` (die RTE verbindet sich mit der App) oder `inbound` (die App verbindet sich mit der RTE) (ein Runner) |
+| `--host <address>` | Die Adresse dieses Servers, mit der sich die App verbindet (ein eingehender Runner) |
+| `--namespace <namespace>` | Der Kubernetes-Namespace, standardmäßig `ansibleforms` |
+| `--release <release>` | Das Helm-Release, standardmäßig `ansibleforms` |
+| `--hostname <name>` | Der Hostname des Ingress (kubernetes) |
+| `--ingress-class <class>` | Die Ingress-Klasse (kubernetes) |
+| `--storage-class <class>` | Die Storage-Klasse (kubernetes) |
+| `--values <file>` | Eine zusätzliche Helm-Values-Datei (kubernetes) |
+| `--purge` | Mit `uninstall`: auch die Daten löschen |
+| `--source <folder>` | Eine lokale Kopie des Repositorys [ansibleforms/docker](https://github.com/ansibleforms/docker), aus der installiert wird (air-gapped) |
+| `--bundle <file>` | Ein Release-Bundle, `ansibleforms-<version>-linux-<arch>.tar.gz`, aus dem nativ installiert wird (siehe [Native Installation](native.html#air-gapped)) |
+| `--yes` | Jede Frage mit ihrem Standard beantworten (unbeaufsichtigt) |
+| `--verbose` | Jeden ausgeführten Befehl anzeigen |
+
+---
+
+## Unbeaufsichtigt
+
+Mit `--yes` oder ohne Terminal fragt der Installer nichts: die Flags beantworten ihre Fragen, die Standardwerte den Rest. Er
+überspringt die Sprache, die Release Notes, das Admin-Passwort (erzeugt, sofern `--admin-password` keines angibt) und die Prüfung und gibt
+stattdessen den Link zu den Release Notes aus. Ein fehlendes Docker oder Podman installiert er nur mit `--install-runtime` oder `--yes`, und ein Runner
+braucht `--app-url`. Ohne `--join` bittet der Runner um Beitritt und wartet auf die Freigabe durch einen Admin; mit dem Flag wird er sofort freigegeben.
+
+Ein Controller auf Docker, der Docker installiert, wenn es fehlt:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Ein eingehender Runner auf Podman, mit dem sich die App unter `rte-dmz.example.com:8000` verbindet:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Eine bestehende Installation
+
+Der Installer merkt sich in `installer.json`, was er installiert hat. Ohne diese Datei suchen `install`, `upgrade` und `status` zuerst nach einem
+AnsibleForms, das bereits auf dem Server ist, egal womit es installiert wurde:
+
+| Gefunden | Wie es gefunden wird | Übernommen, wenn |
+|---|---|---|
+| Docker oder Podman | Container des App- oder RTE-Images, nach Compose-Projekt gruppiert | Der Ordner enthält die Compose-Datei und die `.env` des Repositorys [ansibleforms/docker](https://github.com/ansibleforms/docker): die Dienste `mysqldb`, `app` und `rte`, in den Containern `<name>_db`, `<name>_app` und `<name>_rte` |
+| Ein 7.2-Runner | Eine RTE allein in ihrem Compose-Projekt, mit den `DB_*` der App und ohne `RTE_MODE` (Datenbankmodus) | Seine Compose-Datei ist lesbar. Seine Aktualisierung stellt ihn auf einen Socket-Modus um (siehe [Ein 7.2-Runner](#a-72-runner)) |
+| Kubernetes | Helm-Releases des Charts `ansibleforms` sowie Deployments und StatefulSets seiner Images | Es ist ein Release des Charts: seine aktuellen Values werden zu seiner Values-Datei |
+| Nativ | systemd-Dienste, die AnsibleForms mit Node.js betreiben | Sie folgen dem Layout des Installers: `releases/`, `current`, `app.env` und `rte.env` (siehe [Native Installation](native.html#the-folder)) |
+| Keine Engine | Die App oder eine RTE, die auf einem üblichen Port antwortet: 443, 3000, 3001, 8000, 8001, 8010 oder 8443 | Nie: es läuft aus dem Quellcode oder von Hand. Der Installer meldet es nur |
+
+Nur die Images der App und der RTE zählen: ein nach AnsibleForms benannter MySQL-Container ist keine Installation. Der Installer listet auf, was
+er gefunden hat, eine Zeile pro Fund, mit dem Grund und dem, was von Hand zu tun ist, wenn er eine nicht übernehmen kann: ihre Compose-Datei ist nicht die des Repositorys,
+ihre Datenbank liegt außerhalb ihres Compose-Projekts, sie läuft auf Kubernetes ohne das Helm-Chart, sie wird von Argo CD verwaltet (aktualisieren Sie sie dort,
+indem Sie die Chart-Version der Application ändern), oder ihre Version ist nicht lesbar.
+
+Für eine Installation, die er übernehmen kann, bietet `install` drei Möglichkeiten an:
+
+| Auswahl | Was sie bewirkt |
+|---|---|
+| Übernehmen und aktualisieren | Zeigt, was er sich merken wird, schreibt dann nach Ihrer Bestätigung `installer.json` und fährt mit der [Aktualisierung](#upgrade) fort |
+| Trotzdem ein neues AnsibleForms daneben installieren | Eine zweite Installation, mit eigenem Ordner, eigenen Ports und eigener Datenbank, nach einer eigenen Bestätigung |
+| Abbrechen | Es wird nichts geändert |
+
+Für eine Installation, die bereits die Version betreibt, die der Installer installieren würde, heißt die erste Möglichkeit stattdessen **Übernehmen**: der Installer
+merkt sich, wo sie liegt und wie sie läuft, für ihre Backups, ihren Status und die nächsten Aktualisierungen, und jetzt wird nichts geändert.
+
+`upgrade` bietet dasselbe ohne die zweite Möglichkeit an und bricht ab, wenn nichts übernommen werden kann. Unbeaufsichtigt bricht `install` mit einer Meldung ab,
+und `upgrade --yes` übernimmt eine Installation nur, wenn es genau eine findet, die es übernehmen kann. Die aktuellen Values eines Kubernetes-Release werden
+neben `installer.json` gespeichert, und die Aktualisierungen wenden sie mit dem Chart der neuen Version erneut an.
+
+---
+
+## Aktualisieren
+
+`ansibleforms-installer upgrade` bringt die Installation auf eine neuere Version derselben Hauptversion. Er listet die neueren Versionen auf,
+die neueste zuerst (unbeaufsichtigt nimmt er die neueste), und zeigt die Release Notes jeder Version, die er überspringt, mit den inkompatiblen Änderungen
+und Entfernungen zuerst. Enthalten sie inkompatible Änderungen, bittet er Sie zu bestätigen, dass Sie sie gelesen haben; unbeaufsichtigt geht es nur mit `--yes` weiter.
+
+Der Installer sichert die Datenbank, bevor sich irgendetwas ändert. Antwortet die neue Version nicht, bietet er ein Zurücksetzen an: die vorherige
+Version kommt zurück, und ihre Datenbank wird aus diesem Backup wiederhergestellt. Er führt kein Downgrade durch und überschreitet keine Hauptversion: folgen Sie
+dafür der [Upgrade-Anleitung](../upgrade-7.html), zum Beispiel von 6.x auf 7.x, mit dem, was auf 6.5 vor der Aktualisierung zu tun ist.
+
+Auf Docker oder Podman bringt die Aktualisierung eines Controllers auch seine Dateien auf den Stand der neuen Version des docker-Repositorys:
+
+| Datei | Was die Aktualisierung tut |
+|---|---|
+| `docker-compose.yml` | Durch die der neuen Version ersetzt, nachdem eine Kopie in `installer-backups` gespeichert wurde |
+| `.env` | Jede bestehende Zeile bleibt erhalten, und die Schlüssel, die die neue Version braucht, werden hinzugefügt, mit Secrets, die so erzeugt werden wie bei einer Neuinstallation. Vorher wird eine Kopie gespeichert |
+| `data/seed.yaml` | Ersetzt, wenn es ein unveränderter Seed aus dem docker-Repository ist. Ein von Hand geänderter bleibt erhalten, und der neue wird daneben gespeichert |
+| `data/` | Die neuen Dateien, die die Version mitbringt, etwa ein neues Playbook, werden hinzugefügt. Jede vorhandene Datei bleibt erhalten |
+
+Eine fehlende Datenbankeinstellung (`MYSQLDB_USER` oder ein Passwort) lässt sich für eine bestehende Datenbank nicht erfinden, daher bricht die Aktualisierung dann vor
+jeder Änderung ab. Ein Zurücksetzen stellt die Compose-Datei, die `.env` und den Seed wieder so her, wie sie waren.
+
+Ein Runner betreibt dieselbe Version wie sein AnsibleForms: aktualisieren Sie zuerst AnsibleForms, dann seine Runner. Die Aktualisierung eines Runners schreibt seine
+Compose-Datei für das neue RTE-Image neu und behält seine `.env` und seine Daten unverändert.
+
+---
+
+## Ein 7.2-Runner
+
+Ein Runner aus 7.2 läuft im Datenbankmodus, der seit 7.3.0 veraltet ist: seine RTE hält die Datenbankeinstellungen von AnsibleForms. Der Installer findet
+ihn (siehe [Eine bestehende Installation](#an-existing-installation)), und seine Aktualisierung stellt ihn unter demselben Runner auf einen Socket-Modus um:
+
+1. Er liest den Namen des Runners (`RTE_NAME`) und das Token (`RTE_TOKEN`) aus dem alten RTE-Container. Hat sich die RTE nicht selbst registriert
+   (`RTE_REGISTER=0`), geben Sie den Namen ein, den ihr Runner unter **Verbindungen > Runner** hat
+2. Er fragt nach der Adresse der App und dem Modus, standardmäßig **ausgehend** oder eingehend, und bei eingehend nach dem Port und der Adresse dieses Servers
+3. Er zeigt den Plan und sichert dann die alte Compose-Datei und die `.env` nach `installer-backups`
+4. Er schreibt das Runner-Layout des Installers ohne die `DB_*`-Einstellungen. Er behält `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` und `METRICS_TOKEN`, die eine RTE im Socket-Modus weiterhin liest
+5. Er startet die neue RTE neben der alten. Die neue RTE meldet sich mit dem eigenen Token des Runners an, und AnsibleForms stellt den Runner selbst auf den
+   neuen Modus um, **ohne Freigabe**: seine Jobs und die Formulare, die ihn nennen, bleiben unverändert
+6. Sobald die neue RTE verbunden ist, wird der alte Container gestoppt und entfernt
+
+Ein eingehender Runner stellt HTTPS mit einem gepinnten Zertifikat bereit, wie ein neuer (siehe [Ein Runner](#a-runner)), und der Installer gibt seinen
+Zertifikat-Fingerabdruck aus. Belegt die alte RTE den Port, den die neue braucht, wird sie zuerst gestoppt, sodass der Runner offline ist, bis sich die
+neue verbindet. Die neue RTE eines ausgehenden Runners nimmt einen freien Port auf `127.0.0.1` und läuft ohne Unterbrechung neben der alten.
+
+Wenn der Installer kein Token aus der alten RTE lesen kann, wählen Sie, wie sich die neue RTE anmeldet:
+
+| Auswahl | Was folgt |
+|---|---|
+| Token des Runners eingeben | Das Passwort der RTE-Anmeldedaten des Runners unter **Verbindungen > Anmeldedaten**. Der Runner behält seinen Namen und seine Jobs |
+| Als neuer Runner mit einem Beitritts-Token beitreten | Ein [Beitritts-Token](../runners/registration.html#join-tokens) fügt einen neuen Runner unter einem anderen Namen hinzu. Nehmen Sie den alten Runner von Hand außer Betrieb |
+
+Verbindet sich die neue RTE nicht, bietet der Installer an, die alten Dateien zurückzulegen und den alten Container wieder zu starten; hatte AnsibleForms
+den Runner bereits umgestellt, setzen Sie seinen Modus unter **Verbindungen > Runner** wieder auf Datenbank. Sobald die neue RTE verbunden ist, gibt es
+kein Zurück: die alten Dateien bleiben in `installer-backups`.
+
+Kennt AnsibleForms keinen Runner mit diesem Namen, bittet die neue RTE stattdessen um Beitritt und wartet auf eine Freigabe. Lehnen Sie diese Anfrage unter
+**Verbindungen > Runner** ab und führen Sie die Aktualisierung dann erneut mit dem Namen aus, den der Runner dort hat.
+
+---
+
+## Versionen
+
+Die Version des Installers folgt der der App: jede AnsibleForms-Version kommt mit einem Installer derselben Version, der mit ihr veröffentlicht wird, und
+dieser Installer installiert standardmäßig diese Version. `--version` installiert eine andere. Jede Version auf der
+[Releases-Seite des Installers](https://github.com/ansibleforms/installer/releases) hat Binaries für Linux auf amd64 und arm64, mit ihren
+Prüfsummen.
diff --git a/i18n/de/_get_started/installation/kubernetes.md b/i18n/de/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..de28cf5
--- /dev/null
+++ b/i18n/de/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Installation
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+AnsibleForms und seine MySQL-Datenbank mit dem Helm-Chart installieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Das Helm-Chart deployt AnsibleForms mit MySQL und der RTE, die die Playbooks ausführt (siehe die [Values-Referenz](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+Der [Installer](installer.html) installiert das Chart ebenfalls, anhand weniger Fragen, und aktualisiert auch ein Release, das er nicht installiert hat. Dasselbe
+Chart installiert auch einen einzelnen Runner, für ein AnsibleForms, das anderswo läuft (siehe [Ein Runner auf Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Voraussetzungen
+
+Bevor Sie beginnen, benötigen Sie:
+
+* **Kubernetes-Cluster** : mit einem `kubectl`, das so konfiguriert ist, dass es ihn erreicht
+* **Helm 3** : um das Chart zu installieren und zu aktualisieren
+* **Speicher** : eine StorageClass für dynamische Bereitstellung oder vorab angelegte PersistentVolumes
+* **Ingress-Controller** : nur, wenn Sie AnsibleForms über einen Ingress veröffentlichen wollen
+
+---
+
+## 1. Die Chart-Values holen
+
+Holen Sie die Standard-Values des Charts in eine eigene Datei, aus dem Chart-Repository oder aus der OCI-Registry:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Chart-Repository</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">OCI-Registry</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Kein Repository hinzuzufügen: das Chart wird aus der GitHub Container Registry gezogen.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Den Speicher konfigurieren
+
+Sowohl AnsibleForms als auch MySQL speichern ihre Daten auf einem persistenten Volume. Setzen Sie für jedes die StorageClass und die Größe:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Ein leerer `className` verwendet die Standard-StorageClass des Clusters. Der Zugriffsmodus ist standardmäßig `ReadWriteMany`, den viele Storage-Klassen
+nicht anbieten; `ReadWriteOnce` reicht bei einer einzelnen Replika. Für vorab angelegte PersistentVolumes siehe das
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) des Charts.
+
+---
+
+## 3. Die Anmeldedaten setzen
+
+AnsibleForms braucht ein Admin-Konto, ein Datenbankpasswort und ein `ENCRYPTION_SECRET`, den Schlüssel, der die in AnsibleForms gespeicherten
+Anmeldedaten verschlüsselt. Um diesen Schlüssel später zu ändern, setzen Sie [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+für einen Start auf den alten: jedes gespeicherte Secret wird dann mit dem neuen Schlüssel neu verschlüsselt. Sie können sie auf eine von drei Arten angeben:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">In der Values-Datei</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Vom Chart erzeugt</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Bestehendes Secret</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Setzen Sie sie in `my_values.yaml`. Das Chart speichert sie in einem Secret namens `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Lassen Sie das Chart bei der ersten Installation alles erzeugen, was Sie nicht angeben. Es behält danach bei jeder
+Aktualisierung dieselben Werte:
+
+```bash
+--set secrets.generate=true
+```
+
+Das funktioniert nicht mit Argo CD oder Flux, die das Chart ohne Zugriff auf den Cluster rendern. Das erzeugte Secret
+überlebt `helm uninstall`; sichern Sie es, denn `ENCRYPTION_SECRET` lässt sich nicht wiederherstellen.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Lassen Sie das Chart auf ein Secret zeigen, das Sie selbst verwalten, zum Beispiel mit External Secrets, Sealed Secrets oder SOPS. Das Chart
+legt dann keines an:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+Das Secret muss `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` und `ADMIN_PASSWORD` enthalten.
+
+</div>
+</div>
+
+---
+
+## 4. Das RTE-Image wählen
+
+AnsibleForms 7 führt selbst kein Playbook aus: das tut die RTE (Laufzeitumgebung). Das Chart betreibt sie als zweiten Container im
+Server-Pod, auf demselben Volume, und registriert sie als Standard-Runner `rte`, sodass Playbook-Formulare ohne jede Einrichtung funktionieren. Seit 7.3.0
+verbindet sich die App mit ihr auf `127.0.0.1` und hält einen WebSocket offen (`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)): die RTE bekommt keine
+Datenbankeinstellungen und keinen Verschlüsselungsschlüssel. Der Konfigurations-Seed des Charts deklariert RTE-Anmeldedaten mit dem Token und dieser Adresse sowie
+den Runner, Modus inbound, der sich damit anmeldet.
+
+Das Standard-Image, `ghcr.io/ansibleforms/ansibleforms-rte-full`, enthält ansible mit seinen Collections und die Python-Bibliotheken, die das 6.5-Image hatte.
+Für mehr oder weniger bauen Sie ein eigenes auf einer der drei RTE-Schichten (`ansibleforms-rte-base`, `-rte-core` oder `-rte-full`, siehe
+[Die RTE-Images](../rte/images.html)) und lassen das Chart darauf zeigen:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+Das Token zwischen App und RTE und der Schlüssel, der die Sitzungen signiert, werden bei der ersten Installation im
+Secret `<release>-keys` erzeugt und bei jeder Aktualisierung beibehalten. Mit einem eigenen Konfigurations-Seed fügen Sie diese Anmeldedaten und diesen Runner dort hinzu: die Hinweise, die Helm nach der Installation ausgibt, zeigen wie
+(siehe das [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) des Charts).
+
+---
+
+## 5. Das Chart installieren
+
+Installieren Sie das Chart mit Ihren Values in einen eigenen Namespace:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Mit der OCI-Registry verwenden Sie `oci://ghcr.io/ansibleforms/charts/ansibleforms` als Chart. In allem, was unbeaufsichtigt läuft,
+fixieren Sie die Chart-Version mit `--version`, damit nie von selbst ein neues Release installiert wird.
+
+---
+
+## 6. Die Installation prüfen
+
+Das Chart enthält einen Test, der sowohl den Webserver als auch die Datenbankverbindung prüft:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+Der Test endet mit `OK`, wenn AnsibleForms antwortet und seine Datenbank Verbindungen annimmt.
+
+---
+
+## 7. AnsibleForms öffnen
+
+Wie Sie AnsibleForms erreichen, hängt davon ab, wie der Server veröffentlicht ist:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port-Forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Mit dem Standarddienst `ClusterIP` und ohne Ingress ist nichts außerhalb des Clusters erreichbar. Leiten Sie einen lokalen Port weiter,
+um einen Blick darauf zu werfen:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Öffnen Sie dann `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Setzen Sie `services.server.type: LoadBalancer` (optional mit einer festen Adresse in `services.server.loadbalancer.ip`)
+und warten Sie, bis der Dienst seine Adresse erhält:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Aktivieren Sie den Ingress und setzen Sie den Hostnamen, der zu Ihrem Ingress-Controller führt:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+Das [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) des Charts behandelt TLS hinter einem Ingress, einschließlich der Backend-Einstellung, die HTTPS auf dem
+Server braucht.
+
+</div>
+</div>
+
+---
+
+## 8. Anmelden
+
+Melden Sie sich als Admin-Benutzer an, standardmäßig `admin`. So lesen Sie das Passwort aus dem Secret:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Mit `secrets.existingSecret` lesen Sie es stattdessen aus Ihrem eigenen Secret.
+
+---
+
+## Ein Runner auf Kubernetes
+
+Mit `runner.enabled` installiert das Chart nur eine RTE: einen Runner für ein AnsibleForms, das anderswo installiert ist, in einem anderen Namespace, einem anderen
+Cluster oder auf einer VM. Er verbindet sich mit der App und hält einen WebSocket offen (`RTE_MODE=outbound`, siehe [Modi](../rte/modes.html)), daher braucht er
+keine Datenbank, keinen Verschlüsselungsschlüssel und keinen eingehenden Port. Er rendert keine App, kein MySQL, keinen Service und keinen Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Value | Was er bewirkt |
+|---|---|
+| `runner.enabled` | Installiert nur den Runner: keine App, kein MySQL, kein Service, kein Ingress |
+| `runner.appUrl` | Die Adresse der App, wie man sie öffnet, gegebenenfalls mit ihrer `BASE_URL`. Pflichtangabe |
+| `runner.name` | Der Runner-Name, unter dem er beitritt (`RTE_NAME`). Leer: der Name des Release |
+| `runner.joinToken` | Ein in der App erstelltes [Beitritts-Token](../runners/registration.html#join-tokens), das beim ersten Start gelesen wird, um den Runner sofort freizugeben |
+| `runner.appTlsVerify` | `false` akzeptiert das selbstsignierte Zertifikat der App (`APP_TLS_VERIFY=0`), nur innerhalb eines vertrauenswürdigen Netzwerks |
+
+Ohne Beitritts-Token bittet der Runner um Beitritt und wartet, bis ein Admin ihn unter **Verbindungen > Runner** freigibt. Nach der Freigabe
+meldet er sich mit seinem eigenen `RTE_TOKEN` an, das im Secret `<release>-keys` aufbewahrt wird: behalten Sie dieses Secret zusammen mit dem Release. Der
+[Installer](installer.html#kubernetes) installiert diesen Runner-Modus ebenfalls, wenn Sie die Rolle Runner und Kubernetes wählen.
+
+---
+
+## Nächste Schritte
+
+Das [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) des Charts behandelt den Rest der Konfiguration:
+
+* **Ihre eigene Datenbank** : setzen Sie `mysql.enabled: false` und lassen Sie AnsibleForms auf einen bestehenden MySQL-Server zeigen
+* **Formulare aus ConfigMaps** : `config.yaml` und die Formulardateien über ConfigMaps bereitstellen
+* **HTTPS hinter einem Ingress**, Ressourcen, Node-Platzierung und private Registries
+* **Die RTE** : ihr Token, ein eigenes RTE-Image oder gar keine RTE
+
+Um auf ein neueres Release zu wechseln, siehe [Aktualisieren auf Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/de/_get_started/installation/native.md b/i18n/de/_get_started/installation/native.md
new file mode 100644
index 0000000..28d2256
--- /dev/null
+++ b/i18n/de/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Nativ
+parent: Installation
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Native Installation
+{: .no_toc }
+
+AnsibleForms direkt auf dem Server, ohne Container, als systemd-Dienste, die der Installer einrichtet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren von Servern, auf denen Container nicht erlaubt sind: der [Installer](installer.html) installiert alles, was AnsibleForms braucht, auf
+dem Server selbst und aktualisiert und entfernt es danach. Er installiert AnsibleForms 7.3.0 oder neuer.
+
+---
+
+## Was sie braucht
+
+Wählen Sie im Schritt **Engine** des Installers **Direkt auf diesem Server, ohne Container**, oder übergeben Sie `--mode native`. Sie braucht:
+
+* **Root** : starten Sie den Installer mit `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : die Dienste laufen als systemd-Units
+* **Ein unterstütztes Linux** : Ubuntu, Debian, RHEL und seine Nachbauten wie Rocky Linux und AlmaLinux, SUSE Linux Enterprise oder openSUSE
+* **amd64 oder arm64**
+* **Internetzugang** : zu den Repositories der Distribution, GitHub, nodejs.org und den Paketindizes von Python und Ansible (siehe
+  [Air-gapped](#air-gapped) für das, was ein Release-Bundle ersetzt)
+
+Auf einem Server, der diese Bedingungen nicht erfüllt, erscheint die Engine als *Direkt auf diesem Server (erfordert root: Installer mit sudo starten)* oder
+*Direkt auf diesem Server (auf diesem Linux nicht unterstützt)*. Beide Rollen lassen sich so installieren: ein Controller und ein [Runner](installer.html#a-runner).
+
+---
+
+## Was sie installiert
+
+Der Installer installiert für beide Rollen Folgendes aus den Paketen der Distribution:
+
+| Paket | Wofür |
+|---|---|
+| `git` | Die Repositories |
+| Der ssh-Client | Die Verbindungen der Playbooks |
+| Der MariaDB-Client | Die Backups der App: `app.env` setzt [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) und [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) auf den gefundenen Client, `mariadb-dump` und `mariadb` oder die älteren `mysqldump` und `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | Die Downloads |
+| `libatomic` | Node.js linkt dagegen, und minimalen Servern fehlt es |
+| `sshpass` | Playbooks, die sich mit einem ssh-Passwort anmelden. Auf RHEL und seinen Nachbauten kommt es aus EPEL, das der Installer mit `epel-release` zu aktivieren versucht; lässt es sich nicht installieren, geht die Installation weiter und sagt es |
+| Der MariaDB-Server | Nur ein Controller: seine Datenbank |
+
+Danach, in den Installationsordner, wobei jeder Download gegen seine veröffentlichte Prüfsumme geprüft wird:
+
+* **AnsibleForms** : das Release-Bundle `ansibleforms-<version>-linux-<arch>.tar.gz` aus dem GitHub-Release der App, die für
+  Node.js gebaute App. Eine Version ohne Bundle meldet *Ohne Container ist AnsibleForms 7.3.0 oder neuer erforderlich.*
+* **Node.js** : die neueste Version der Hauptversion, die das Bundle nennt, von nodejs.org
+* **Python und Ansible** : uv, dann damit das Python der RTE-Images und eine virtuelle Umgebung mit Ansible und den Bibliotheken
+  des vollen RTE-Images, dann seine Ansible-Collections (siehe [Die RTE-Images](../rte/images.html)). Das dauert einige Minuten
+* **Die Startdateien** : die Formulare, Playbooks und Einstellungen aus dem Ordner `data` des [docker-compose-Projekts](https://github.com/ansibleforms/docker),
+  so wie eine neue Docker-Compose-Installation sie erhält. Ein Runner behält nur seine Ansible-Konfiguration sowie die ssh- und git-Einstellungen
+
+Für einen Controller legt er dann das Schema `AnsibleForms` in MariaDB an sowie einen nach der Instanz benannten Datenbankbenutzer mit allen Rechten auf diesem
+Schema und keinen anderswo, der sich nur von diesem Server aus anmeldet.
+
+---
+
+## Der Ordner
+
+Alles liegt im Installationsordner, standardmäßig `/opt/ansibleforms` (oder `/opt/ansibleforms-runner` für einen Runner):
+
+| Pfad | Was er enthält |
+|---|---|
+| `releases/<version>/` | Ein Release: das Bundle, seinen Link zu Node.js, seine virtuelle Python-Umgebung und seine Collections |
+| `current` | Der Link zum laufenden Release; eine Aktualisierung verschiebt ihn, ein Zurücksetzen ebenso |
+| `runtime/` | Node.js, uv und Python, von den Releases gemeinsam genutzt |
+| `data/` | Was die Container als `/app/dist/persistent` einhängen: Formulare, Playbooks, `config.yaml`, der Konfigurations-Seed, Zertifikate und Protokolle |
+| `home/` | Das Home des Systembenutzers: `.ssh` und `.gitconfig`, verlinkt auf `data/ssh` und `data/git` |
+| `app.env`, `rte.env` | Die Einstellungen und Secrets der Dienste, nur für root und den Systembenutzer lesbar. Die der RTE enthält keine Datenbankeinstellungen |
+| `installer-backups/` | Die Datenbank-Backups, die der Installer vor einer Aktualisierung oder mit `backup` erstellt |
+
+Die Releases und die Laufzeiten gehören root, sodass die Dienste ihren eigenen Code nicht ändern können; `data/` und `home/` gehören dem Systembenutzer.
+Die Datenbankdateien selbst verwaltet MariaDB, außerhalb des Ordners.
+
+---
+
+## Die Dienste
+
+Ein Controller betreibt zwei systemd-Dienste, ein Runner einen. Jeder läuft als Systembenutzer, der nach der Instanz benannt ist (standardmäßig `ansibleforms`),
+aus `current/server`, mit seiner Einstellungsdatei:
+
+| Dienst | Was er ausführt | Einstellungen |
+|---|---|---|
+| `<name>` | Die App: die Weboberfläche, die API und den Worker. Nur ein Controller | `app.env` |
+| `<name>-rte` | Die RTE, die die Playbooks ausführt | `rte.env` |
+
+Die RTE eines Controllers ist `inbound` auf einem eigenen Port auf `127.0.0.1` (`8001` oder dem nächsten freien, mit
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), führt die Playbooks aus den Ordnern der App aus (`RTE_FILES=local`)
+und wird vom Konfigurations-Seed `data/seed.yaml` als Standard-Runner deklariert.
+
+Die RTE eines Runners bekommt den Modus, `APP_URL`, `RTE_NAME` und, mit `--join`, das Beitritts-Token, und erhält die Playbooks mit jedem Job (siehe
+[Modi](../rte/modes.html)). Eine ausgehende nimmt keinen Aufruf der App an und lauscht daher nur auf `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Eine eingehende stellt HTTPS mit einem selbstsignierten Zertifikat ihrer eigenen Adresse in `data/certificates` bereit, das AnsibleForms pinnt.
+Ohne Beitritts-Token bittet sie um Beitritt, und ein Admin gibt sie unter **Verbindungen > Runner** frei.
+
+Sie starten beim Booten und nach einem Fehler neu. Verwalten Sie sie und lesen Sie ihre Protokolle mit den eigenen Werkzeugen von systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+Die App darf ohne root auf einem Port unter 1024 lauschen, etwa `443`. Die RTE behält das Recht, `sudo` zu verwenden, das Playbooks mit
+`become` auf diesem Server brauchen, sodass ein Playbook den Server verwalten kann, auf dem die RTE läuft.
+
+---
+
+## Aktualisieren und zurücksetzen
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` aktualisiert eine native Installation wie die anderen (siehe [Aktualisieren](installer.html#upgrade)), in
+dieser Reihenfolge:
+
+1. Legt das neue Release neben das laufende: sein Bundle, Node.js, Python, Ansible und die Collections. Die laufenden
+   Dienste werden noch nicht angefasst
+2. Fügt die neuen Startdateien hinzu, die das Release mitbringt, und behält jede vorhandene Datei
+3. Sichert die Datenbank (ein Controller) nach `installer-backups/`, mit einer Kopie von `app.env` und `rte.env`
+4. Stoppt die Dienste, lässt `current` auf das neue Release zeigen und startet sie wieder
+5. Wartet, bis die App mit der neuen Version antwortet (ein Runner: bis seine RTE wieder lauscht)
+
+Antwortet die neue Version nicht, bietet der Installer ein Zurücksetzen an: `current` zeigt wieder auf das vorherige Release, die
+Datenbank wird aus dem Backup wiederhergestellt, und die Dienste starten. Nur das laufende Release und das davor werden aufbewahrt.
+
+Native Dienste im Layout des Installers ohne `installer.json` daneben, zum Beispiel nachdem sie gelöscht wurde, werden von `install`
+und `upgrade` gefunden, die anbieten, sie zu übernehmen (siehe [Eine bestehende Installation](installer.html#an-existing-installation)).
+
+---
+
+## Deinstallieren
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` stoppt und entfernt die Dienste. Er behält den Ordner und die Datenbank, sofern Sie nicht wählen,
+die Daten zu löschen (oder `--purge` übergeben), und zur Bestätigung den Namen der Instanz eingeben. Dann löscht er auch die Datenbank und ihren Benutzer (ein Controller),
+löscht den Ordner und entfernt den Systembenutzer.
+
+Die Pakete bleiben installiert, MariaDB eingeschlossen: andere Software kann sie verwenden.
+
+---
+
+## Air-gapped
+
+`--bundle` installiert aus einem Release-Bundle, das Sie auf den Server kopiert haben, statt es von GitHub herunterzuladen. Nehmen Sie die Datei für seine
+Architektur, `ansibleforms-<version>-linux-amd64.tar.gz` oder `-arm64`, aus den [Releases](https://github.com/ansibleforms/ansibleforms/releases) der App:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` tut dasselbe für die Startdateien, aus einer lokalen Kopie des Repositorys [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python mit seinen Paketen und die Ansible-Collections werden während der Installation weiterhin heruntergeladen.
diff --git a/i18n/de/_get_started/upgrade-7.md b/i18n/de/_get_started/upgrade-7.md
new file mode 100644
index 0000000..197cee5
--- /dev/null
+++ b/i18n/de/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Auf v7 aktualisieren
+parent: Aktualisieren
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Auf v7 aktualisieren
+{: .no_toc }
+
+Was Sie noch auf 6.5 ändern sollten und was sich beim Wechsel auf Version 7 ändert
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Version 7 entfernt alles, was 6.x als veraltet markiert hat; beheben Sie es zuerst auf 6.5, wo Alt und Neu beide funktionieren, und aktualisieren Sie dann.
+
+---
+
+## Vor der Aktualisierung (auf 6.5)
+
+### Formulare liegen in eigenen Dateien
+
+Formulare liegen nur noch im Formularordner (`FORMS_FOLDER_PATH`) oder in einem Formular-Repository; `config.yaml` behält Kategorien, Rollen und Konstanten.
+
+- **Eine Datei `forms.yaml`:** benennen Sie sie in `config.yaml` um. Auf 6.5 hat die Einstellungsseite dafür eine Schaltfläche
+  **Convert forms.yaml to config.yaml**.
+- **Ein Abschnitt `forms:` in der Basiskonfiguration:** Version 7 lehnt ihn ab. Verschieben Sie jedes Formular in eine eigene Datei, zum Beispiel
+  indem Sie es im Designer von 6.5 auf eine Datei ziehen.
+- **Umgebungsvariablen:**
+
+  | Entfernt | Stattdessen verwenden |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` und `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### Das Feld `table`
+
+Version 7 lehnt Felder vom Typ `table` ab, und ihre Eigenschaften (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`) fallen mit ihnen weg: verwenden Sie ein Feld `list` mit einem `subform` und machen Sie aus dem `from` jeder Spalte einen Ausdruck
+auf `__parent__` (siehe die [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Umbenannte Eigenschaften
+
+Jede entfernte Eigenschaft hat einen direkten Ersatz:
+
+| Entfernt | Stattdessen verwenden |
+|---|---|
+| `disableRelaunch: true` (Formular) | `allowRelaunch: false` |
+| `noOutput: true` (Feld) | `output: false` |
+| `enableLogin` (Rollenoption) | `allowLogin` |
+
+### Datenquellen und Datenschemas
+
+Die Datenquellen-Importe und ihre Admin-Seiten wurden entfernt, ebenso die
+Galaxy-Collection von AnsibleForms, deren Module nur ihnen dienten.
+
+- Geplante Importe stoppen, und die Datenquellen-Tabellen werden gelöscht: notieren Sie sich vorher, was Sie brauchen.
+- Die Datenschemas, die ein Import gefüllt hat, sind eigene Datenbanken und bleiben bestehen. Ein Formular, das
+  sie über Anmeldedaten abfragt, funktioniert weiter.
+- Um diese Daten aktuell zu halten, führen Sie den Import als eigenes Playbook aus, zum Beispiel über einen
+  Zeitplan.
+
+### API v1
+
+`/api/v1/*` wurde entfernt; verwenden Sie `/api/v2/*` (interaktive Dokumentation unter `/api/v2/docs`). Die Aufrufe,
+die Skripte typischerweise verwenden, sind:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+v2 antwortet mit HTTP-Statuscodes (`400`, `403`, `404`, `422`) und einem einfachen JSON-Body, nicht mit der Hülle
+`{ status, message, data }` von v1.
+
+**Auch die Single-Sign-On-Callbacks.** Eine Weiterleitungs-URL mit `/api/v1/` antwortet nicht mehr: die Anmeldung kehrt zur
+Anmeldeseite zurück, ohne anzumelden. Ändern Sie sie an zwei Stellen auf `/api/v2/`, beim SSO-Anbieter in
+AnsibleForms und beim Identitätsanbieter (die Umleitungs-URIs der Entra-ID-App-Registrierung, die gültigen Umleitungs-URIs des OIDC-
+Clients):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback`, oder ab 7.3.0 `/api/v2/auth/entraid/callback`
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Was sich in 7 ändert
+
+Version 7 ändert, wie Playbooks laufen, und verschärft mehrere Standardwerte. Prüfen Sie jeden der folgenden Punkte, wenn Sie von 6.5 wechseln.
+
+### Playbooks laufen auf einer RTE
+
+Version 7 führt `ansible-playbook` nicht mehr im AnsibleForms-Container aus. Playbooks laufen auf einer Laufzeitumgebung (RTE),
+einem eigenen Container, und das App-Image enthält weder ansible noch python. Starten Sie eine RTE neben der App, aus dem
+Image `ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Seit 7.3.0 verbindet sich die App mit der RTE und hält einen WebSocket offen (siehe
+[Modi](rte/modes.html)): die RTE bekommt keine Datenbankeinstellungen und kein `ENCRYPTION_SECRET`. Ihre Einstellungen:
+
+| Einstellung | Wert |
+|---|---|
+| `AF_ROLE` | `rte`. Die RTE-Images setzen es bereits. |
+| `RTE_MODE` | `inbound`: die App verbindet sich mit der RTE. Ein Runner in einem anderen Netzwerk verwendet `outbound` (siehe [Modi](rte/modes.html)). |
+| `RTE_TOKEN` | Ein Token mit mindestens 16 Zeichen. Die App meldet sich damit am Socket der RTE an, und die RTE verweigert ohne Token den Start. |
+| `RTE_FILES` | `local`, wenn die RTE denselben persistenten Ordner einhängt wie die App, wie wenn sie neben ihr läuft. |
+
+Verschieben Sie dann die Ansible-Mounts vom App-Container auf die RTE:
+
+- `ansible.cfg` unter `/etc/ansible/ansible.cfg`, Ihre Rollen unter `/etc/ansible/roles` und Ihre Collections unter
+  `/etc/ansible/collections`.
+- Hängen Sie denselben persistenten Ordner wie bei der App auch in die RTE ein, damit sie die Playbooks und die Repositories findet.
+
+Deklarieren Sie die RTE dann als Runner, im [Konfigurations-Seed](seed/), wie es das Docker-Compose-Projekt tut, oder unter **Verbindungen → Runner**:
+RTE-Anmeldedaten mit der Adresse der RTE (zum Beispiel `http://rte:8000`) und demselben Token sowie einen Runner vom Typ RTE, Modus inbound,
+der sie nennt:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Der Seed liest `RTE_TOKEN` aus der Umgebung der App. Siehe [Runner](runners.html) und [Laufzeitumgebungen](rte/).
+
+{: .warning }
+> **Derselbe Vertrag für App und RTE** Die App löst die Anmeldedaten eines Jobs auf und übergibt sie der RTE, versiegelt für
+> genau diese RTE (RTE-Vertrag 2, neu in 7.0.0). Eine RTE mit einem anderen Vertrag lehnt die Jobs der App ab: betreiben Sie das RTE-Image derselben
+> Version wie die App und aktualisieren Sie beide gemeinsam. Spätere 7er-Versionen funktionieren weiter mit einer älteren 7er-RTE, solange der Vertrag
+> gleich bleibt (siehe [Skalierung](../rte/images.html#build-your-own-rte)).
+
+
+### Was das RTE-Image enthält
+
+Die RTE gibt es in drei Schichten, jede auf der vorherigen aufgebaut. Wählen Sie die, die zu Ihren Playbooks passt:
+
+| Image | Inhalt |
+|---|---|
+| `ansibleforms-rte-full` | Der Standard. Ansible 14 mit ansible-core 2.21 sowie die Collections und Python-Bibliotheken, die das 6.5-Image hatte. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core und einige gängige Bibliotheken, ohne Collections. Fügen Sie Ihre eigenen in einem darauf aufgebauten Image hinzu. |
+| `ansibleforms-rte-base` | Nur der Server, ohne python und ansible, um eine RTE mit eigenen Versionen zu bauen. |
+
+Der Wechsel von 6.5 (ansible 12 mit ansible-core 2.19) ändert für Ihre Playbooks außerdem Folgendes:
+
+- **ansible-core 2.21:** lesen Sie die [Porting Guides](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  für 2.20 und 2.21.
+- **Python 3.14:** die RTE-Schichten laufen auf python 3.14.
+- **Kein `boto` mehr:** die alte Bibliothek `boto` 2 ist weg. Die Collection `amazon.aws` verwendet `boto3`, das enthalten ist.
+
+Zwei Umgebungsvariablen gehören jetzt zur RTE und werden von der App nicht mehr gelesen, setzen Sie sie daher im RTE-Container:
+
+| Variable | Änderung |
+|---|---|
+| `ANSIBLE_PATH` | Der Playbook-Ordner, auf der RTE. |
+| `PROCESS_MAX_BUFFER` | Jetzt standardmäßig 50 MB. Darüber hinaus wird die Job-Ausgabe nicht mehr gespeichert (der Job sagt es), aber das Playbook läuft weiter, statt gestoppt zu werden. |
+
+
+### Die Container laufen als uid 1000
+
+Die App- und RTE-Images laufen als Benutzer `node` (uid 1000) statt als root, und ihr Home-Ordner ist `/home/node`:
+
+- **Geben Sie uid 1000 einmalig die Volumes.** Für die persistenten und ssh-Volumes führen Sie
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v` aus; für einen Host-Ordner `sudo chown -R 1000:1000 <folder>`.
+  Auf Kubernetes setzen Sie `fsGroup: 1000`.
+- **Hängen Sie den ssh-Ordner unter `/home/node/.ssh` ein**, nicht unter `/root/.ssh`. Wenn Sie
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) auf `/root` gesetzt haben, entfernen Sie es oder setzen Sie es auf `/home/node`.
+- **Ihr eigenes RTE-Image**, das auf einer RTE-Schicht aufbaut, wechselt für seine Installationen zu `USER root` und am Ende zurück zu `USER node`.
+
+
+### Die Startvalidierung ist eingeschaltet
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) ist jetzt standardmäßig `enforce` (6.5: `off`). Jeder
+Start, aus dem Browser oder über `POST /api/v2/job`, wird gegen die Regeln des Formulars geprüft, und der Job läuft mit den Extravars und
+Anmeldedaten, die der Server aus den geprüften Werten aufbaut.
+
+- **REST-Aufrufer müssen `rawFormData` senden**, die rohen Feldwerte, wie der Browser sie sendet. Ein Start mit nur
+  `extravars` wird abgelehnt, weil seine Werte nicht geprüft werden können.
+- **Um zuerst zu sehen, was abgelehnt würde**, setzen Sie `LAUNCH_VALIDATION=log` und lesen Sie die Warnungen im Protokoll. `off` stellt das
+  Verhalten von 6.5 wieder her.
+
+Siehe [Startvalidierung](launch-validation/) für die Details.
+
+
+### Playbooks sehen die Einstellungen der App nicht mehr
+
+Ein Playbook erbt nicht mehr die Umgebungsvariablen, die AnsibleForms selbst liest: `ENCRYPTION_SECRET`, die `DB_*`-Einstellungen,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, die `VAULT_*`-Einstellungen, jede andere dokumentierte Variable und jede `MYSQL_*`-Variable.
+Der Rest der Umgebung der RTE, etwa `PATH`, Proxys, `ANSIBLE_*`-Einstellungen und Cloud-Anmeldedaten, wird wie bisher weitergegeben.
+
+Ein Playbook, das eine davon mit `lookup('env', ...)` gelesen hat, muss den Wert anders bekommen: übergeben Sie ihn als Extravar oder als
+Anmeldedaten, oder setzen Sie ihn auf der RTE unter einem anderen Namen.
+
+### Nur die Admin-Rolle verwaltet Runner und Admins
+
+Ein Benutzer mit Zugriff auf die Einstellungen hat nicht mehr die volle Kontrolle darüber, wer Admin ist und wohin Anmeldedaten gehen:
+
+- **Runner:** nur die Admin-Rolle fügt einen Runner hinzu, ändert oder löscht ihn, denn ein Runner erhält die Anmeldedaten der Jobs,
+  die er ausführt. Benutzer mit Zugriff auf die Einstellungen können Runner weiterhin sehen und testen.
+- **Admin-Konten und -Gruppen:** nur die Admin-Rolle vergibt Admin-Rechte. Ohne sie kann ein Benutzer kein Konto in eine Gruppe aufnehmen, die die
+  Admin-Rolle nennt, und weder ein Admin-Konto noch eine solche Gruppe ändern, zurücksetzen oder löschen.
+- **Rollen:** ein Designer ohne Admin-Rolle kann die Rollen nicht ändern. Ein Speichern oder Wiederherstellen mit abweichenden Rollen wird abgelehnt.
+
+Geben Sie die Admin-Rolle denjenigen, die Runner, Admins und Rollen verwalten.
+
+### Das Standardpasswort muss geändert werden
+
+Ein Benutzer, der sich mit dem öffentlichen Standardpasswort `AnsibleForms!123` anmeldet, muss es zuerst ändern. Bis dahin beantwortet jeder andere API-
+Aufruf `403` mit dem Code `password_change_required`, und der Browser zeigt die Seite zum Ändern des Passworts.
+
+Melden Sie sich einmal an und wählen Sie ein neues Passwort, oder setzen Sie [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) vor dem
+ersten Start. Skripte, die sich mit dem Standardpasswort anmelden, müssen ein anderes verwenden.
+
+### Tokens enden bei Abmeldung und Passwortänderung
+
+Eine Abmeldung beendet jetzt die Tokens dieser Sitzung, und eine Passwortänderung beendet jede Sitzung dieses Benutzers; melden Sie sich daher nach
+einer Passwortänderung erneut an.
+
+Ein mit `?expiryDays=` angefordertes API-Token lebt höchstens [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) Tage
+(standardmäßig 90). Skripte, die langlebige API-Tokens verwenden, müssen ein neues anfordern, bevor es abläuft.
+
+### Entra ID braucht Ihren Tenant
+
+Die Anmeldung über Entra ID (Azure AD) verwendet jetzt OpenID Connect nur noch gegen Ihren eigenen Tenant, und ein Benutzer eines anderen Tenants kann sich nicht
+anmelden. Ein Anbieter ohne Tenant-ID oder mit `common`, `organizations` oder `consumers` wird abgelehnt.
+
+- **Setzen Sie die Tenant-ID** beim SSO-Anbieter: die Verzeichnis-ID (Mandanten-ID), eine GUID, oder die Domain des Tenants.
+- **Erteilen Sie die Graph-Berechtigungen:** die Anmeldung fragt nach `openid profile email User.Read GroupMember.Read.All`. Geben Sie der App-
+  Registrierung die delegierten Microsoft-Graph-Berechtigungen `User.Read` und `GroupMember.Read.All`, mit Administratorzustimmung.
+- **Bevorzugen Sie Gruppen-IDs in Rollen:** nennen Sie eine Gruppe als `azuread/<object id>` (ab 7.3.0 `entraid/<object id>`) statt mit ihrem Anzeigenamen.
+
+Siehe [Entra ID](authentication/entra-id.html) für die Einrichtung.
+
+### Passwörter haben eine Mindestlänge
+
+Ein lokales Passwort, das über die Anwendung gesetzt wird, braucht mindestens
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) Zeichen (standardmäßig 8) und darf weder der Benutzername noch das
+Standardpasswort sein. `PASSWORD_MIN_LENGTH=0` schaltet die Längenprüfung ab. Bestehende Passwörter funktionieren weiter.
+
+### Betreiben Sie die Container mit einer Neustart-Richtlinie
+
+Eine nicht abgefangene Ausnahme beendet jetzt den Prozess, protokolliert auf Stufe `crit`, statt ihn in einem unbekannten Zustand weiterlaufen zu lassen. Betreiben Sie
+die Container mit einer Neustart-Richtlinie, etwa `--restart unless-stopped` mit Docker (das docker-compose-Projekt setzt sie).
+Kubernetes startet die Pods von selbst neu.
+
+### AWX-Verbindungen und der Home-Link
+
+Zwei weitere Dinge sind in 7 weggefallen, ohne dass auf 6.5 etwas zu tun ist:
+
+- **AWX- und AAP-Verbindungen:** die Tabelle `awx`, `/api/v2/awx` und die Seite A.A.P. sind weg. Die Aktualisierung verschiebt jede AWX- oder
+  AAP-Verbindung nach **Verbindungen → Runner**, als Runner vom Typ `awx`, und Formulare mit `awx:` funktionieren weiter.
+- **`NAV_HOME_LABEL` und `NAV_HOME_ICON`:** werden nicht mehr gelesen. Der erste Link der Kopfzeile ist immer Formulare.
+
+### Veraltet in 7, entfernt in 8
+
+Diese funktionieren in 7 noch, aber jede protokolliert bei Verwendung eine Warnung. Wechseln Sie vor Version 8 zum Ersatz:
+
+| Veraltet | Stattdessen verwenden |
+|---|---|
+| Umgebungsvariablen `VAULT_*` | Ein Secret Store namens `vault` (**Verbindungen → Secret Stores**). Der erste Start von 7 importiert die Variablen einmalig als diesen Store und ignoriert sie danach. |
+| Umgebungsvariablen `LOG_SYSLOG_*` | Ein Syslog-Server (**Verbindungen → Syslog**). Wenn `LOG_SYSLOG_HOST` gesetzt ist, importiert der erste Start von 7 sie einmalig als den Server `syslog`, der wie bisher das Serverprotokoll erhält, und ignoriert sie danach. Um auch die Audit-Einträge zu senden, stellen Sie ihn so ein, dass er beides empfängt. |
+| `vault_path` bei Anmeldedaten (API, Konfigurations-Seed) | `secret_store` und `secret_ref`. Siehe [Secret Stores](secret-stores/). |
+| Die Rolle `public` in `config.yaml` | Die Rolle `default`. Die Datei wird beim Laden der Konfiguration umbenannt; ein ytt-Template benennen Sie von Hand um. `public` in den `roles:` eines Formulars passt weiterhin. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` bei einem Formular oder einem Schritt | `approval`. `hasApproval` hat keine Wirkung. |
+| `awx: <name>` bei einem Formular | `runner: <name>`. Eine AWX-Verbindung ist ein Runner vom Typ `awx`. |
+| `type: multistep` bei einem Formular, mit seinen `steps` | `type: workflow`, mit Knoten, die einen `runner` nennen. Siehe [Workflow-Formulare](forms/workflow.html). |
+| Der Abschnitt `awx:` des Konfigurations-Seeds | Einträge in `runners:` mit `type: awx` |
+| `LOCK_PATH` | Nichts: wird nicht mehr gelesen, die Designer-Sperre wird in der Datenbank gehalten. |
+| Eine RTE im Datenbankmodus, seit 7.3.0: `RTE_MODE=database` oder kein `RTE_MODE`, mit den `DB_*` der Datenbank und `ENCRYPTION_SECRET` auf der RTE | `RTE_MODE=outbound` oder `RTE_MODE=inbound`, ohne `DB_*`. Die RTE tritt einmalig mit einem Beitritts-Token bei (`RTE_JOIN_TOKEN`), oder ihr Runner wird unter **Verbindungen → Runner** oder im Konfigurations-Seed (`rte_mode`) auf diesen Modus gesetzt. Siehe [Modi](rte/modes.html). |
+| `RTE_REGISTER`, seit 7.3.0 (nur Datenbankmodus) | Ein Beitritts-Token (`RTE_JOIN_TOKEN`): die RTE fügt sich selbst als Runner hinzu, der sich mit RTE-Anmeldedaten anmeldet. |
+| Anmeldedaten vom Typ `api` oder `userpass` bei einem Runner des Konfigurations-Seeds, seit 7.3.0 | Anmeldedaten von der Art des Runners (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` oder `jenkins`), mit dem Server in `url`. |
+| Ein Runner des Konfigurations-Seeds mit eigenem `token` oder `username` und `password`, seit 7.3.0 | Anmeldedaten von der Art des Runners im Abschnitt `credentials`, mit dem Server in `url`, die der Runner mit `credential:` nennt. Der Seed legt so lange welche an, die nach dem Runner benannt sind. |
+
+`ENABLE_SSO` und `SSO_AUTO_LOGIN` werden seit 7.3.0 nicht mehr gelesen. Der erste Start von 7.3 übernimmt sie einmalig: `ENABLE_SSO=0` deaktiviert
+jeden SSO-Anbieter, und `SSO_AUTO_LOGIN=1` setzt **Anmeldeseite überspringen** beim einzigen aktivierten Anbieter. Danach werden sie ignoriert: jeder Start
+protokolliert eine Warnung, solange sie gesetzt sind, und jeder Anbieter hat **Aktiviert** und **Anmeldeseite überspringen** unter **Zugriff → SSO**.
+
+---
+
+## Image-Tags
+
+`latest` wechselt mit 7.0.0 auf 7. Um bei 6 zu bleiben, verwenden Sie das Tag `6` (oder `6.5`) statt `latest`.
+Alle Tags sind unter [Image-Tags](installation/#image-tags) aufgeführt.
+
+---
+
+## Zurücksetzen
+
+Erstellen Sie vor der Aktualisierung ein Backup (**Einstellungen → Backups**). 6.5 läuft auf einer auf 7 aktualisierten Datenbank, aber nur
+das Backup stellt die gelöschten Datenquellen-Definitionen wieder her.
diff --git a/i18n/de/_get_started/upgrading/docker-compose.md b/i18n/de/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..d10bb99
--- /dev/null
+++ b/i18n/de/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Aktualisieren
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Eine mit dem docker-compose-Projekt angelegte Installation aktualisieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Das docker-compose-Projekt betreibt drei Container: MySQL (`mysqldb`), AnsibleForms (`app`) und die RTE, die die
+Playbooks ausführt (`rte`). AnsibleForms und die RTE verwenden das Image-Tag `7`, das immer auf die neueste 7.x-Version zeigt. Eine
+Aktualisierung zieht die Images erneut und erstellt die Container neu, deren Image sich geändert hat. Alles, was erhalten bleiben muss, liegt
+im Ordner `data` und bleibt bewahrt.
+
+---
+
+## Vor der Aktualisierung
+
+Bereiten Sie die Aktualisierung so vor, dass Sie zurückkehren können, falls etwas schiefgeht:
+
+* **Erstellen Sie ein Backup** unter **Einstellungen → Backups**. Die neue Version aktualisiert das Datenbankschema bei ihrem ersten Start.
+* **Lesen Sie das [Changelog](../changelog)** für die Versionen zwischen Ihrer und der neuen.
+* **Wechsel auf eine neue Hauptversion?** Folgen Sie zuerst [Auf v7 aktualisieren](../upgrade-7.html).
+* **Sie kommen von 6.5?** Das 6.x-Projekt, auf seinem Branch `v6`, hat keinen Container `rte`. Bringen Sie Ihre Kopie des Projekts auf
+  den Branch `main`, behalten Sie Ihre `.env`-Einstellungen und Ihren Ordner `data`, damit `docker-compose.yml` den Dienst `rte`
+  hat. Diese Compose-Datei setzt `CONFIG_SEED_PATH`, und ein `data`-Ordner aus 6.x hat keine `seed.yaml`: kopieren Sie `data/seed.yaml` aus
+  dem Repository und fügen Sie `RTE_TOKEN` (mindestens 16 Zeichen) zu Ihrer `.env` hinzu, wie in der `.env` des Repositorys. Ohne sie verweigert die
+  App den Start. Die 7er-Images laufen als uid 1000 statt als root: geben Sie diesem Benutzer einmalig den Ordner `data` und lassen Sie die MySQL-
+  Dateien MySQL, mit `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  Der Ordner `data/ssh` wird jetzt unter `/home/node/.ssh` statt `/root/.ssh` eingehängt.
+* **Sie kommen von 7.2?** Aktualisieren Sie `docker-compose.yml` und `data/seed.yaml` gemeinsam: siehe zuerst [Von 7.2 auf 7.3](#from-72-to-73).
+
+---
+
+## Von 7.2 auf 7.3
+
+Bis 7.2.0 erhielt der Dienst `rte` die Einstellungen der Datenbank, und sein in `data/seed.yaml` deklarierter Runner lief im Datenbankmodus,
+der in 7.3.0 als veraltet markiert und in 8.0.0 entfernt wird. Seit 7.3.0 verbindet sich die App mit der RTE auf `http://rte:8000` und hält einen WebSocket offen
+(`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)), und die RTE hält keine Datenbankeinstellungen. Nehmen Sie beide Dateien vom Branch
+`main` des Repositorys und behalten Sie Ihre `.env`:
+
+| Datei | Was sich ändert |
+|---|---|
+| `docker-compose.yml` | Der Dienst `rte` liest `.env` nicht mehr: er bekommt `RTE_MODE=inbound`, `RTE_TOKEN` und `RTE_FILES=local` und kein `DB_*` |
+| `data/seed.yaml` | RTE-Anmeldedaten `rte` mit `url: http://rte:8000` und `password: ${RTE_TOKEN}` sowie der Runner `rte` mit `rte_mode: inbound` und `credential: rte` |
+
+Ändern Sie beide. Nur mit der neuen Compose-Datei behält der Seed den Runner `rte` im Datenbankmodus: die App ruft die RTE wie eine aus 7.2 auf,
+worauf die neue RTE nicht antwortet, und kein Playbook läuft. Ein Seed, den Sie selbst geändert haben, braucht dieselben Anmeldedaten und dasselbe `rte_mode`.
+
+Ein Runner, den der Seed angelegt hat, bleibt verwaltet, schreibgeschützt unter **Verbindungen → Runner**, auch nachdem Sie `CONFIG_SEED_PATH` entfernt haben: nur ein
+Seed, der angewendet wird, gibt einen Runner frei, den er nicht mehr deklariert. Behalten Sie also den Seed und setzen Sie `rte_mode` dort, statt
+`CONFIG_SEED_PATH` zu entfernen, um den Runner von Hand zu ändern.
+
+Der [Installer](../installation/installer.html#upgrade) erledigt das selbst: seine Aktualisierung ersetzt `docker-compose.yml`, und `data/seed.yaml`,
+wenn es ein unveränderter Seed aus dem Repository ist. Ein von Hand geänderter bleibt erhalten, und der neue wird daneben gespeichert.
+
+---
+
+## 1. Die neuen Images ziehen
+
+Laden Sie die neuesten Images der Tags in `docker-compose.yml` herunter:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Die Container neu erstellen
+
+Starten Sie das Projekt erneut; die Container, deren Image sich geändert hat, werden neu erstellt:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Die Aktualisierung prüfen
+
+Verfolgen Sie das Protokoll von AnsibleForms beim Start. Der erste Start einer neuen Version aktualisiert das Datenbankschema, und die RTE
+startet, sobald AnsibleForms gesund ist:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+In AnsibleForms zeigt **Hilfe → Info** die laufende Version, und **Einstellungen → Status** zeigt den Zustand der
+Datenbank, des Schemas und der anderen Systeme, von denen AnsibleForms abhängt.
+
+---
+
+## Zurücksetzen
+
+Um zur vorher betriebenen Version zurückzukehren, der Version, die **Hilfe → Info** vor der Aktualisierung zeigte, fixieren Sie ihr exaktes Tag in
+`docker-compose.yml`, sowohl beim AnsibleForms- als auch beim RTE-Image, anstelle von `7`, und führen Sie Schritt 2 erneut aus. Startet diese Version
+nicht auf der aktualisierten Datenbank, stellen Sie das Backup wieder her, das Sie unter **Einstellungen → Backups** erstellt haben. Setzen Sie die Tags wieder auf
+`7`, um wieder Updates zu erhalten.
+
+**VIDEO**: [So aktualisieren Sie AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/de/_get_started/upgrading/docker.md b/i18n/de/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..6feab2f
--- /dev/null
+++ b/i18n/de/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Aktualisieren
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Einen eigenständigen Container ohne docker-compose aktualisieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Eine eigenständige Installation wird aktualisiert, indem man ihre Container ersetzt: die neuen Images ziehen, die alten Container entfernen und
+neue mit denselben `run`-Befehlen starten. Seit Version 7 sind es zwei: AnsibleForms und die RTE, die die
+Playbooks ausführt, immer auf derselben Version. Ihre Dateien liegen im eingehängten Ordner `/app/dist/persistent` und Ihre Daten in
+MySQL, daher bleibt beides erhalten.
+
+---
+
+## Vor der Aktualisierung
+
+Bereiten Sie die Aktualisierung so vor, dass Sie zurückkehren können, falls etwas schiefgeht:
+
+* **Erstellen Sie ein Backup** unter **Einstellungen → Backups**. Die neue Version aktualisiert das Datenbankschema bei ihrem ersten Start.
+* **Lesen Sie das [Changelog](../changelog)** für die Versionen zwischen Ihrer und der neuen.
+* **Wechsel auf eine neue Hauptversion?** Folgen Sie zuerst [Auf v7 aktualisieren](../upgrade-7.html).
+* **Sie kommen von 6.5?** Die 7er-Images laufen als uid 1000 statt als root: geben Sie diesem Benutzer einmalig die eingehängten Ordner, zum
+  Beispiel `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Sie kommen von 7.2?** Die RTE bekommt eine eigene Datei, und die App verbindet sich mit ihr: siehe zuerst [Von 7.2 auf 7.3](#from-72-to-73).
+
+---
+
+## Von 7.2 auf 7.3
+
+Bis 7.2.0 las die RTE die Umgebungsdatei der App, mit den Einstellungen der Datenbank, und fügte sich selbst aus `RTE_URL` als Runner hinzu. Das
+ist der Datenbankmodus, in 7.3.0 als veraltet markiert und in 8.0.0 entfernt. Seit 7.3.0 verbindet sich die App mit der RTE und hält einen WebSocket offen
+(`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)), und die RTE hält keine Datenbankeinstellungen. Einmalig, vor Schritt 2:
+
+1. Legen Sie `/srv/apps/ansibleforms/rte.env` an, wie es die [Installation](../installation/docker.html#prepare-the-folders) tut, mit
+   `RTE_MODE=inbound`, demselben `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` und `HTTPS=0`. Kein `DB_*`, kein `ENCRYPTION_SECRET`, kein `RTE_URL`
+2. Deklarieren Sie den Runner in diesem Modus. Fügen Sie entweder den [Konfigurations-Seed](../seed/) der Installation hinzu, `persistent/seed.yaml` mit den RTE-Anmeldedaten
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) und dem Runner `rte` (`rte_mode: inbound`), und fügen Sie
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` zur Umgebungsdatei der App hinzu. Oder öffnen Sie, ohne Seed, den Runner unter
+   **Verbindungen → Runner**, setzen Sie seinen **Modus** auf **Eingehend** und wählen Sie RTE-Anmeldedaten, die `http://rte:8000` und das Token enthalten
+
+Mit dem Seed enthält auch die Umgebungsdatei der App `RTE_TOKEN`, dasselbe Token, da der Seed es von dort liest.
+
+---
+
+## 1. Die neuen Images ziehen
+
+Laden Sie die neuesten AnsibleForms- und RTE-Images des Tags herunter, das Sie betreiben:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Die Container ersetzen
+
+Entfernen Sie die alten Container und starten Sie neue mit den `run`-Befehlen der [Installation](../installation/docker.html). Die App
+liest die Datenbankverbindung aus ihrer Umgebungsdatei, mit dem Datenbankbenutzer von AnsibleForms (nicht root). Die RTE liest ihre eigene
+`rte.env`, ohne die Einstellungen der Datenbank, und die App verbindet sich mit ihr über ein Netzwerk, das beide Container teilen:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Wenn Sie von 6.5 kommen, gibt es noch keinen RTE-Container: die Befehle `stop` und `rm` finden nur die App. Legen Sie das gemeinsame Netzwerk
+einmalig mit `docker network create ansibleforms` (oder `podman network create ansibleforms`) an. Wie bei der
+[Installation](../installation/docker.html#prepare-the-folders) legen Sie die Datenbankverbindung, `ENCRYPTION_SECRET`, ein `RTE_TOKEN`
+mit mindestens 16 Zeichen und `CONFIG_SEED_PATH` in die Umgebungsdatei der App und legen `rte.env` und den Konfigurations-Seed an. Verwenden Sie Ihre eigenen
+Ordner, wo Ihre 6.5-Installation andere eingehängt hat. Der Seed fügt die RTE unter **Verbindungen → Runner** als Standard-Runner `rte` hinzu;
+siehe [Auf v7 aktualisieren](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Die Aktualisierung prüfen
+
+Verfolgen Sie das Protokoll von AnsibleForms beim Start. Der erste Start einer neuen Version aktualisiert das Datenbankschema:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+Die RTE schreibt ein eigenes Protokoll, das `docker logs rte` zeigt. In AnsibleForms zeigt **Hilfe → Info** die laufende Version, und **Einstellungen → Status** zeigt den Zustand der
+Datenbank, des Schemas und der anderen Systeme, von denen AnsibleForms abhängt.
+
+---
+
+## Zurücksetzen
+
+Um zur vorher betriebenen Version zurückzukehren, der Version, die **Hilfe → Info** vor der Aktualisierung zeigte, führen Sie Schritt 2 erneut mit
+ihrem exakten Tag anstelle von `7` aus, sowohl beim AnsibleForms- als auch beim RTE-Image. Startet diese Version nicht auf der aktualisierten
+Datenbank, stellen Sie das Backup wieder her, das Sie unter **Einstellungen → Backups** erstellt haben.
diff --git a/i18n/de/_get_started/upgrading/from-source.md b/i18n/de/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..347f7ca
--- /dev/null
+++ b/i18n/de/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Aus dem Quellcode
+parent: Aktualisieren
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Aus dem Quellcode
+{: .no_toc }
+
+Eine aus dem Quellcode gebaute Installation aktualisieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Eine aus dem Quellcode gebaute Installation wird aktualisiert, indem man die neue Version auscheckt, sie neu baut und die
+Anwendung neu startet. Ihre Einstellungen, Formulare, Playbooks, Zertifikate und Protokolle liegen in `server/persistent`, das weder Git noch der
+Build verändern.
+
+---
+
+## Vor der Aktualisierung
+
+Bereiten Sie die Aktualisierung so vor, dass Sie zurückkehren können, falls etwas schiefgeht:
+
+* **Erstellen Sie ein Backup** unter **Einstellungen → Backups**. Die neue Version aktualisiert das Datenbankschema bei ihrem ersten Start.
+* **Lesen Sie das [Changelog](../changelog)** für die Versionen zwischen Ihrer und der neuen.
+* **Wechsel auf eine neue Hauptversion?** Folgen Sie zuerst [Auf v7 aktualisieren](../upgrade-7.html).
+* **Prüfen Sie die Node.js-Version**, die die neue Version verlangt, im Changelog.
+
+---
+
+## 1. Die neue Version holen
+
+Holen Sie die Release-Tags und checken Sie die gewünschte Version aus. Release-Tags tragen die Versionsnummer, und `git tag` listet
+sie auf; der Branch `main` kann Änderungen enthalten, die noch nicht veröffentlicht sind:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Neu bauen
+
+Bauen Sie in denselben drei Schritten neu wie bei der Installation. Bauen Sie zuerst den Client neu:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Aktualisieren Sie dann die Abhängigkeiten des Servers:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Kopieren Sie zuletzt den neu gebauten Client wieder in den Ordner `views` des Servers:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Vergleichen Sie `.env.example` im Wurzelverzeichnis des Repositorys mit Ihrer `persistent/.env`, um Einstellungen zu übernehmen, die die Version hinzufügt.
+
+---
+
+## 3. Neu starten
+
+Starten Sie die Anwendung und ihre RTE neu, um den neuen Code zu laden. Das Datenbankschema wird beim ersten Start aktualisiert:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Wenn Sie von 7.2 kommen, lief die RTE im Datenbankmodus, mit den Datenbankeinstellungen und `RTE_URL`, in 7.3.0 als veraltet markiert und in 8.0.0 entfernt.
+Starten Sie sie erneut im eingehenden Modus und deklarieren Sie ihren Runner mit RTE-Anmeldedaten im Seed oder unter **Verbindungen → Runner**, wie die
+[Installation](../installation/from-source.html#run) zeigt: `pm2 delete ansibleforms-rte`, dann ihren Befehl `pm2 start`.
+
+Wenn Sie die Anwendung ohne PM2 betreiben, stoppen Sie `npm run start` und starten Sie es erneut.
+
+---
+
+## 4. Die Aktualisierung prüfen
+
+Verfolgen Sie das Anwendungsprotokoll beim Start:
+
+```bash
+pm2 logs ansibleforms
+```
+
+In AnsibleForms zeigt **Hilfe → Info** die laufende Version, und **Einstellungen → Status** zeigt den Zustand der
+Datenbank, des Schemas und der anderen Systeme, von denen AnsibleForms abhängt.
+
+---
+
+## Zurücksetzen
+
+Um zur vorher betriebenen Version zurückzukehren, der Version, die **Hilfe → Info** vor der Aktualisierung zeigte, checken Sie ihr Tag mit
+`git checkout <version>` aus und bauen und starten Sie dann wie in den Schritten 2 und 3 neu. Startet diese Version nicht auf der aktualisierten Datenbank, stellen Sie das Backup wieder her, das Sie unter
+**Einstellungen → Backups** erstellt haben.
diff --git a/i18n/de/_get_started/upgrading/index.md b/i18n/de/_get_started/upgrading/index.md
new file mode 100644
index 0000000..8f20289
--- /dev/null
+++ b/i18n/de/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Aktualisieren
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Aktualisieren
+{: .no_toc }
+
+AnsibleForms auf eine neuere Version bringen
+{: .fs-6 .fw-300 }
+
+---
+
+Für Administratoren einer laufenden Instanz: wechseln Sie auf eine neuere Version, mit der Methode, mit der Sie installiert haben.
+
+---
+
+## In diesem Abschnitt
+
+Das Vorgehen beim Aktualisieren hängt davon ab, wie Sie AnsibleForms installiert haben. Jede Methode ist auf einer eigenen Seite beschrieben:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Auf v7 aktualisieren](../upgrade-7.html) | Was Sie noch auf 6.5 ändern sollten, bevor Sie auf 7 wechseln |
+| [Mit dem Installer](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, für eine Installation, die der Installer angelegt hat: Backup, Release Notes und Zurücksetzen |
+| [Docker](docker.html) | Das neue Image ziehen und den Container mit denselben Einstellungen neu erstellen |
+| [Docker Compose](docker-compose.html) | Das neue Image ziehen und das docker-compose-Projekt neu starten |
+| [Aus dem Quellcode](from-source.html) | Den neuen Code holen, neu bauen und die Anwendung neu starten |
+| [Kubernetes](kubernetes.html) | Das Chart-Repository aktualisieren und `helm upgrade` mit Ihren Values ausführen |
+
+{: .note }
+> **Zuerst ein Backup** Erstellen Sie vor der Aktualisierung ein Backup (**Einstellungen → Backups**). Das Datenbankschema wird beim ersten
+> Start der neuen Version aktualisiert, daher ist das Backup Ihr Rückkehrpunkt, falls etwas schiefgeht. Ab 7.3.0 erstellt der Worker auch
+> selbst eines, bevor er von einer älteren Version aktualisiert, benannt nach der Version, sofern
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) nicht `0` ist.
+
+Welche Version Sie erhalten, hängt vom Image-Tag ab, das Sie betreiben: `latest` folgt der neuesten Hauptversion, während ein Tag wie `7`
+bei dieser Hauptversion bleibt. Alle Tags sind unter [Image-Tags](../installation/#image-tags) aufgeführt.
diff --git a/i18n/de/_get_started/upgrading/kubernetes.md b/i18n/de/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..9902343
--- /dev/null
+++ b/i18n/de/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Aktualisieren
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Eine mit dem Helm-Chart angelegte Installation aktualisieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Jede Chart-Version deployt eine AnsibleForms-Version. Eine Aktualisierung installiert eine neuere Chart-Version mit Ihren bestehenden Values;
+die Daten auf den persistenten Volumes bleiben erhalten. Eine Aktualisierung, die nichts ändert, lässt die Pods unberührt.
+
+---
+
+## Vor der Aktualisierung
+
+Bereiten Sie die Aktualisierung so vor, dass Sie zurückkehren können, falls etwas schiefgeht:
+
+* **Erstellen Sie ein Backup** unter **Einstellungen → Backups**. Die neue Version aktualisiert das Datenbankschema bei ihrem ersten Start.
+* **Lesen Sie das [Changelog](../changelog)** für die Versionen zwischen Ihrer und der neuen.
+* **Wechsel auf eine neue Hauptversion?** Folgen Sie zuerst [Auf v7 aktualisieren](../upgrade-7.html).
+* **Lesen Sie das [Changelog](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) des Charts** auf Änderungen an den Values.
+* **Mit erzeugten Anmeldedaten** (`secrets.generate`) sichern Sie das Secret `<release>-secrets`: `ENCRYPTION_SECRET` lässt sich nicht wiederherstellen.
+* **Sie kommen von 7.2?** Die RTE im Server-Pod wechselt den Modus: siehe [Von 7.2 auf 7.3](#from-72-to-73).
+
+---
+
+## Von 7.2 auf 7.3
+
+Chart 7.3.0 holt die RTE neben der App aus dem Datenbankmodus, der in 7.3.0 als veraltet markiert und in 8.0.0 entfernt wird. Die App verbindet sich mit ihr auf
+`127.0.0.1` und hält einen WebSocket offen (`RTE_MODE=inbound`, siehe [Modi](../rte/modes.html)):
+
+* Der RTE-Container bekommt kein `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` oder `RTE_URL` mehr und nimmt die Dateien des Jobs vom
+  gemeinsamen Volume (`RTE_FILES=local`)
+* Der Konfigurations-Seed des Charts deklariert RTE-Anmeldedaten mit dem Token und der Adresse sowie den Runner, `rte_mode: inbound`, der sich
+  damit anmeldet. Mit dem Seed des Charts ist nichts zu tun
+* Mit `containers.rte.seedRunner: false` oder einem eigenen Konfigurations-Seed (`CONFIG_SEED_PATH`) fügt sich die RTE nicht mehr selbst als Runner hinzu.
+  Deklarieren Sie sie selbst, in Ihrem Seed oder unter **Verbindungen → Runner**: RTE-Anmeldedaten mit `http://127.0.0.1:<port>` und dem Token
+  sowie einen Runner vom Typ RTE mit `rte_mode: inbound`, der sie nennt. Die Hinweise, die Helm nach der Aktualisierung ausgibt, zeigen wie
+
+Das Chart installiert seit 7.3.0 mit `runner.enabled` auch einen einzelnen Runner (siehe
+[Ein Runner auf Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Die neue Chart-Version finden
+
+Aktualisieren Sie das Chart-Repository und listen Sie die verfügbaren Chart-Versionen auf:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Das Release aktualisieren
+
+Führen Sie denselben Befehl `helm upgrade` wie bei der Installation aus, mit Ihrer Values-Datei und der neuen Chart-Version:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Mit der OCI-Registry verwenden Sie `oci://ghcr.io/ansibleforms/charts/ansibleforms` als Chart.
+
+---
+
+## 3. Die Aktualisierung prüfen
+
+Warten Sie auf die neuen Pods und führen Sie dann den Test des Charts aus, der sowohl den Webserver als auch die Datenbankverbindung prüft:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+In AnsibleForms zeigt **Hilfe → Info** die laufende Version, und **Einstellungen → Status** zeigt den Zustand der
+Datenbank, des Schemas und der anderen Systeme, von denen AnsibleForms abhängt.
+
+---
+
+## Zurücksetzen
+
+Helm bewahrt die Historie des Release auf. Um zur vorherigen Revision zurückzukehren:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Startet sie nicht auf der aktualisierten Datenbank, stellen Sie Ihr Backup wieder her (siehe das [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) des Charts).
diff --git a/i18n/de/_integrate/api/authentication.md b/i18n/de/_integrate/api/authentication.md
new file mode 100644
index 0000000..07e3612
--- /dev/null
+++ b/i18n/de/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Authentifizierung
+parent: REST-API
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Authentifizierung
+{: .no_toc }
+
+Anmelden, das Token erneuern oder ein langlebiges Token verwenden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Jeder Aufruf braucht ein Access Token im Header `Authorization`. Ein Token erhält man durch Anmelden, und es wird mit
+dem Refresh Token frisch gehalten.
+
+---
+
+## Anmelden
+
+Melden Sie sich mit Basic Authentication an, mit dem Namen und dem Passwort des Benutzers:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+Die Antwort enthält zwei Tokens, das Access Token und das Refresh Token:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Die API aufrufen
+
+Senden Sie das Access Token bei jedem Aufruf als Bearer Token:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Das Token erneuern
+
+Das Access Token läuft ab (`ACCESS_TOKEN_EXPIRATION`, standardmäßig 30 Minuten). Holen Sie mit dem Refresh Token ein neues,
+ohne das Passwort:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+Die Antwort enthält ein neues Paar, im selben Aufbau wie bei der Anmeldung. Ein Refresh Token funktioniert einmal: behalten Sie das neue für die nächste Erneuerung.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Langlebige Tokens
+
+Ein Skript, das unbeaufsichtigt läuft, kann ein Token verwenden, das länger hält. Ab 7.3.0 braucht es dafür die Rollenoption `allowApiTokens`:
+
+* Erstellen Sie eines unter [Profil > API-Tokens](../profile/api-token.html).
+* Oder melden Sie sich mit dem Query-Parameter `expiryDays` an, für ein Token, das so viele Tage gültig ist:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` wird nur aus der URL gelesen, nie aus dem Body. Für einen Benutzer, dessen Rollen `allowApiTokens` fehlt, wird es ignoriert,
+und die Anmeldung gibt ein Token mit der üblichen Lebensdauer zurück. `expiryDays=never` braucht zusätzlich `extendedTokenExpiration`. Fügen Sie den Query-Parameter `name`
+hinzu (`?expiryDays=90&name=nightly-backup`), um das Token in der Token-Liste des Benutzers zu benennen.
+
+Ein langlebiges Token lebt höchstens [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) Tage, standardmäßig
+90: ein längeres `expiryDays` wird darauf gekürzt, sofern es nicht `never` ist. Seine Erneuerung gibt ein gewöhnliches Token zurück, melden Sie sich daher erneut an, wenn es abläuft.
+
+### Tokens des angemeldeten Benutzers
+
+Die Ansicht **API-Tokens** des Profils verwendet diese Endpunkte, die für jedes Konto funktionieren, SSO eingeschlossen, da sie kein Passwort brauchen:
+
+| Aufruf | Was er tut |
+|---|---|
+| `GET /api/v2/profile/tokens` | Listet Ihre API-Tokens auf, mit ihrer `sid`, `name`, Erstellung, Ablauf und letzten Verwendung |
+| `POST /api/v2/profile/tokens` | Erstellt ein Token aus Ihrer Sitzung; der Body enthält `expiryDays` (eine Zahl oder `never`) und optional `name` |
+| `DELETE /api/v2/profile/tokens/{sid}` | Widerruft eines Ihrer Tokens |
+
+`POST` antwortet `403`, wenn es mit einem API-Token aufgerufen wird (ein Token kann kein anderes erstellen), ohne `allowApiTokens` oder wenn die
+Sitzung sich vor mehr als 10 Minuten angemeldet hat (Code `sign_in_again`): melden Sie sich zuerst erneut an. Eine Lebensdauer über dem Maximum antwortet `400`.
+
+---
+
+## Wenn ein Token vorzeitig endet
+
+Ein Token, langlebig oder nicht, funktioniert vor seinem Ablauf nicht mehr, wenn eines davon eintritt:
+
+* **Eine Abmeldung seiner Sitzung**: `POST /api/v2/auth/logout` mit dem Token beendet die Tokens dieser Anmeldung, und nur diese. Eine
+  Abmeldung im Browser beendet nicht das Token eines Skripts.
+* **Eine Passwortänderung**: der Benutzer ändert sein Passwort, oder ein Admin setzt es. Jedes zuvor ausgestellte Token wird abgelehnt.
+* **Der Benutzer wird entfernt oder gesperrt**: das Löschen eines lokalen Benutzers oder das Sperren eines Benutzers beendet alle seine Tokens. Ein Admin kann auch
+  die Sitzungen eines LDAP- oder SSO-Benutzers beenden.
+
+Ein abgelehntes Token antwortet `401`. Melden Sie sich erneut an, mit dem neuen Passwort, falls es sich geändert hat.
+
+---
+
+## Skripte, die sich bei jedem Lauf anmelden
+
+Die Endpunkte für Anmeldung und Tokens sind gegen Überflutung und das Erraten von Passwörtern geschützt, daher sollte ein Skript, das sich bei jedem Lauf anmeldet,
+diese Grenzen kennen:
+
+| Grenze | Standard | Was passiert |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 Anfragen pro Minute von einer Adresse | Anmeldung, Abmeldung, Erneuerung, die SSO-Endpunkte, `PUT /api/v2/profile` (Passwortänderung) und `POST` oder `DELETE /api/v2/profile/tokens` antworten `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 fehlgeschlagene Anmeldungen in Folge | Das Konto wird für [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15) gesperrt, jede Anmeldung antwortet `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 fehlgeschlagene Anmeldungen von einer Adresse | Jede Anmeldung von dieser Adresse antwortet `429`, bis das Zeitfenster endet |
+
+Eine `429` trägt einen Header `Retry-After` mit den zu wartenden Sekunden: halten Sie an und warten Sie, versuchen Sie es nicht sofort erneut. Ein gesperrtes Konto
+lehnt selbst das richtige Passwort ab, bis die Sperre endet, daher sperrt ein Skript mit falschem Passwort seinen Benutzer für alle aus.
+Ein falsches aktuelles Passwort bei einer Passwortänderung (`PUT /api/v2/profile`) zählt ebenfalls als fehlgeschlagene Anmeldung, und ein gesperrtes Konto
+kann sein Passwort nicht ändern. Eine erfolgreiche Anmeldung setzt den Zähler des Kontos zurück, ebenso ein Admin, der das Passwort setzt.
+
+Um diese Grenzen zu meiden, melden Sie sich einmal an und verwenden Sie das Token wieder, oder verwenden Sie ein langlebiges Token, statt sich für
+jeden Aufruf anzumelden. Hinter einem Reverse Proxy setzen Sie [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY), damit der Server
+die Adresse des Clients sieht, sonst zählt jeder Client als einer.
diff --git a/i18n/de/_integrate/api/events.md b/i18n/de/_integrate/api/events.md
new file mode 100644
index 0000000..475cbeb
--- /dev/null
+++ b/i18n/de/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Live-Ereignisse
+parent: REST-API
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Live-Ereignisse
+{: .no_toc }
+
+Erfahren, wann sich Jobs und Einstellungen ändern, statt abzufragen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Der Server teilt seinen Clients mit, was sich ändert, sobald es sich ändert. Auch ein Skript kann zuhören, statt alle paar Sekunden einen Job zu lesen.
+
+---
+
+## Der Stream
+
+`GET /api/v2/events` ist ein Stream von [Server-Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events),
+der offen bleibt. Jeder angemeldete Benutzer darf ihn öffnen, mit dem üblichen Bearer Token:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Wenn sich etwas ändert, sendet er ein Ereignis `changed` mit dem Namen dessen, was sich geändert hat:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Ereignisnamen
+
+Ein Ereignis trägt nur einen Namen, nie Daten, daher verrät es nichts, was der Benutzer nicht sehen darf. Diese Namen werden gesendet:
+
+| Name | Was sich geändert hat |
+|---|---|
+| `jobs` | Ein Job: gestartet, sein Status oder seine Ausgabe, gelöscht |
+| `appearance` | Die Einstellungen, die die Kopfzeile zeigt: das Theme, der Name, eine Ankündigung, eine Umgebungsvariable |
+| `designer` | Eine Sperre des Designers, gesetzt oder freigegeben |
+| `runners` | Ein Runner (ab 7.3.0): eine RTE hat sich verbunden oder getrennt, um Beitritt gebeten, wurde freigegeben oder abgelehnt, oder hat ihren Modus oder ihre Einstellungen geändert |
+
+Wenn Sie einen Namen empfangen, lesen Sie das, was Sie anzeigen, über die normale API neu (zum Beispiel `GET /api/v2/job/42`), mit Ihren eigenen
+Berechtigungen. Ein häufiger Name wird höchstens einmal pro Sekunde gesendet.
+
+---
+
+## Offen halten
+
+Der Stream ist darauf ausgelegt, Proxys und Load Balancer zu überstehen, und ein Client verbindet sich von selbst neu:
+
+* Beim Verbinden sendet der Server ein Ereignis `hello` und bittet den Client, 3 Sekunden zu warten, bevor er sich neu verbindet.
+* Alle 15 Sekunden sendet er eine Kommentarzeile (`: ping`), damit eine untätige Verbindung nicht geschlossen wird. Ignorieren Sie Zeilen, die mit `:` beginnen.
+* Ereignisse von jedem App-Knoten erreichen jeden Stream, egal mit welchem Knoten der Client verbunden ist.
+* Lesen Sie nach einer Neuverbindung das, was Sie anzeigen, neu: ein Ereignis, das gesendet wurde, während der Stream unterbrochen war, wird nicht erneut gesendet.
+
+---
+
+## Health und Metriken
+
+Die Liveness- und Readiness-Probes (`/api/v2/live`, `/api/v2/ready`) und die Prometheus-Metriken (`/api/v2/metrics`) sind
+für Monitoring-Werkzeuge gedacht, nicht für Skripte, die als Benutzer handeln. Siehe [Monitoring](../production/monitoring.html).
diff --git a/i18n/de/_integrate/api/index.md b/i18n/de/_integrate/api/index.md
new file mode 100644
index 0000000..f80f7f8
--- /dev/null
+++ b/i18n/de/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: REST-API
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# REST-API
+{: .no_toc }
+
+Formulare starten und AnsibleForms aus Skripten verwalten
+{: .fs-6 .fw-300 }
+
+---
+
+Für Entwickler und Automatisierungsingenieure: Formulare starten und AnsibleForms aus Skripten verwalten.
+
+Alles, was die Weboberfläche tut, läuft über die REST-API, daher können Skripte und andere Werkzeuge dasselbe tun.
+
+---
+
+## Überblick
+
+Die API wird auf dem AnsibleForms-Server unter `/api/v2` bereitgestellt:
+
+* **Vollständige Referenz** : diese Seiten behandeln, was Skripte am häufigsten verwenden. Jeder Endpunkt ist auf der
+  eingebauten Swagger-Seite des Servers beschrieben und lässt sich dort ausprobieren, `https://<your server>/api/v2/docs`.
+* **Berechtigungen** : ein Aufruf läuft als der Benutzer, dessen Token er trägt, mit den Rollen dieses Benutzers, wie im Browser.
+* **Startvalidierung** : über die API gestartete Jobs können wie Starts aus dem Browser geprüft werden
+  (siehe [Startvalidierung](../launch-validation/)).
+* **Ratenbegrenzungen** : begrenzt sind nur die Endpunkte für Anmeldung, Abmeldung, Token-Erneuerung und Single Sign-On, die Passwortänderung
+  (`PUT /api/v2/profile`) und die Endpunkte für API-Tokens (`POST` und `DELETE /api/v2/profile/tokens`) (siehe
+  [Authentifizierung](authentication.html)). Andere Aufrufe haben keine Ratenbegrenzung (der [Chat-Assistent](../chat/) hat eigene
+  Grenzen), daher sollte ein Skript sein Tempo selbst drosseln, zum Beispiel wenn es einen Job verfolgt.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Authentifizierung](authentication.html) | Anmelden, das Token erneuern oder ein langlebiges Token verwenden |
+| [Jobs](jobs.html) | Ein Formular starten, den Job verfolgen, abbrechen, erneut starten oder genehmigen |
+| [Antworten und Fehler](responses.html) | Der Aufbau einer Antwort und die Statuscodes |
+| [Live-Ereignisse](events.html) | Erfahren, wann sich Jobs und Einstellungen ändern, statt abzufragen |
diff --git a/i18n/de/_integrate/api/jobs.md b/i18n/de/_integrate/api/jobs.md
new file mode 100644
index 0000000..2e1b9c8
--- /dev/null
+++ b/i18n/de/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Jobs
+parent: REST-API
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Jobs
+{: .no_toc }
+
+Ein Formular starten, den Job verfolgen, abbrechen, erneut starten oder genehmigen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ein Job ist ein Lauf eines Formulars. Starten Sie ihn mit dem Namen und den Werten des Formulars und verfolgen Sie ihn dann über seine ID.
+
+---
+
+## Ein Formular starten
+
+Senden Sie den Formularnamen und seine Werte an `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+Die Anfrage nimmt diese Eigenschaften:
+
+| Eigenschaft | Bedeutung |
+|---|---|
+| `formName` | Der Name des zu startenden Formulars. Pflichtangabe. |
+| `extravars` | Die Extra-Variablen für den Job. `payload` wird als anderer Name dafür akzeptiert. |
+| `rawFormData` | Die Werte der Formularfelder, wie der Browser sie hält. Die [Startvalidierung](../launch-validation/) prüft diese und baut daraus die Extravars auf. |
+| `credentials` | Anmeldedaten, die dem Job übergeben werden, nach Namen. |
+| `files` | Die Uploads der Dateifelder des Formulars (siehe [Datei-Uploads](../launch-validation/file-uploads.html)). |
+
+Die Antwort enthält die ID des neuen Jobs:
+
+```json
+{ "id": 42 }
+```
+
+Um den Job im ausführlichen Modus laufen zu lassen, fügen Sie den Extravars `"__verbose__": true` hinzu. Das braucht die Rollenoption `allowVerboseMode`,
+sonst antwortet der Start `403`.
+
+---
+
+## Eine Datei hochladen
+
+Ein Formular mit einem Dateifeld braucht zuerst die hochgeladene Datei. Senden Sie sie als Multipart-Teil `file` an `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+Die Antwort beschreibt den gespeicherten Upload:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Übergeben Sie sie unverändert in den `files` des Starts, unter dem Namen des Dateifelds: `"files": { "firmware": { ... } }`. Der Server
+prüft sie gegen seine eigene Festplatte (siehe [Datei-Uploads](../launch-validation/file-uploads.html)).
+
+---
+
+## Den Job verfolgen
+
+Lesen Sie den Job über seine ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+Der Job enthält seinen `status`, seine `extravars` (auch als `payload`, dasselbe Objekt), seine `subjobs` und seinen `output`. Die
+Ausgabe ist HTML mit den Farben der Job-Seite; fügen Sie `?text=true` für reinen Text hinzu, was zu einem Skript oder einem Protokoll passt:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+Sein `status` ist `running`, solange er läuft, und `approve`, solange er auf eine Genehmigung wartet. Ein Job endet mit einem dieser Werte:
+
+| Status | Bedeutung |
+|---|---|
+| `success` | Der Job wurde ohne Fehler beendet |
+| `failed` | Der Job ist fehlgeschlagen |
+| `warning` | Ein Multistep-Job wurde beendet, aber ein Schritt mit gesetztem `continue` ist unterwegs fehlgeschlagen |
+| `aborted` | Der Job wurde abgebrochen |
+| `rejected` | Die Genehmigung wurde verweigert, daher lief nicht, was darauf wartete |
+| `abandoned` | Der Prozess, der den Job verfolgte, wurde gestoppt (ein Neustart, ein ersetzter Container), und der Job wurde aufgegeben |
+
+Ein Job, der auf einem Runner lief, als er aufgegeben wurde, kann dennoch mit seinem tatsächlichen Ergebnis enden, wenn dieser Runner ihn doch noch zu Ende bringt.
+
+---
+
+## Jobs finden
+
+`GET /api/v2/job` listet die neuesten Jobs zuerst auf, als `{ "count": ..., "records": [ ... ] }`. Diese Query-Parameter grenzen die Liste ein:
+
+| Parameter | Bedeutung |
+|---|---|
+| `records` | Wie viele Jobs höchstens. Der Standard ist [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), und 5000 das Maximum, sofern `JOBS_LIST_SIZE` nicht höher ist. |
+| `user`, `user_type` | Nur die Jobs dieses Benutzers. `user_type` ist `local`, wenn es weggelassen wird (`ldap`, `azuread`, `oidc` für die anderen). |
+| `runner` | Nur die Jobs, die auf diesem Runner liefen |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Ein Benutzer sieht seine eigenen Jobs und die Jobs, die auf eine Genehmigung warten, die eine seiner Rollen erteilen darf. Ein Admin oder eine Rolle mit der
+Option `showAllJobLogs` oder `manageAllJobs` sieht jeden Job. Ein Datensatz enthält die Zusammenfassung des Jobs (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); lesen Sie
+den Job selbst für seine Extravars und seine Ausgabe.
+
+`GET /api/v2/job/approvals` antwortet mit einer Zahl: wie viele Jobs auf eine Genehmigung warten, die der Benutzer erteilen darf.
+
+---
+
+## Mehr über einen Job
+
+Diese Endpunkte lesen mehr von einem Job:
+
+| Aufruf | Was er zurückgibt |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | Die Feldwerte, mit denen der Job gestartet wurde, wie das Formular sie hielt. Es gelten dieselben Berechtigungen wie für einen erneuten Start: Ihr eigener Job (oder jeder Job für einen Admin oder eine Rolle mit `manageAllJobs`), ein Formular, das den erneuten Start erlaubt, und die Rollenoption `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Die strukturierten Ereignisse eines Playbook-Jobs (ab 7.3.0, für ein Playbook auf einer RTE ab 7.3.0): jedes Play, jeder Task, jedes Host-Ergebnis und die Zusammenfassung, mit ihren `order`, `type`, `play`, `task`, `host`, `duration` und `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Eines dieser Ereignisse mit seinem ganzen `result`, wie der Dialog **Ergebnis der Aufgabe** es zeigt; `400`, wenn `order` keine ganze Zahl ist, `404`, wenn der Job kein solches Ereignis hat |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Ein Knoten eines Workflow-Jobs: `{ "node", "job", "extravars", "artifacts" }`, wobei `job` die ID des eigenen Jobs des Knotens ist, oder `null`, wenn der Knoten nicht lief. |
+
+---
+
+## Weitere Aktionen
+
+Diese Endpunkte wirken auf einen bestehenden Job:
+
+| Aufruf | Aktion |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Einen laufenden Job abbrechen |
+| `POST /api/v2/job/{id}/relaunch` | Einen Job erneut starten, wie er lief oder mit Änderungen (siehe [Erneut starten](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Einen Job genehmigen, der auf Genehmigung wartet; Ihr eigener Job antwortet `403`, sofern seine Genehmigung nicht `allowSelf: true` setzt oder Sie Admin sind |
+| `POST /api/v2/job/{id}/reject` | Einen Job ablehnen, der auf Genehmigung wartet |
+| `GET /api/v2/job/{id}/download` | Die Ausgabe des Jobs herunterladen |
+| `DELETE /api/v2/job/{id}` | Einen Job löschen |
+
+Abbrechen, Genehmigen, Ablehnen und Löschen antworten mit einer Meldung, ein erneuter Start zusätzlich mit der ID des neuen Jobs:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Fügen Sie einem erneuten Start `?verbose=true` hinzu, um den neuen Job im ausführlichen Modus laufen zu lassen, mit der Rollenoption `allowVerboseMode`. Ein Job, der
+sich im falschen Zustand für die Aktion befindet, zum Beispiel beim Abbrechen eines bereits beendeten Jobs, antwortet `409`.
diff --git a/i18n/de/_integrate/api/responses.md b/i18n/de/_integrate/api/responses.md
new file mode 100644
index 0000000..cc3e8ff
--- /dev/null
+++ b/i18n/de/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Antworten und Fehler
+parent: REST-API
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Antworten und Fehler
+{: .no_toc }
+
+Der Aufbau einer Antwort und die Statuscodes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Antworten sind einfaches JSON, und der HTTP-Statuscode sagt, ob ein Aufruf erfolgreich war.
+
+---
+
+## Antworten
+
+Ein erfolgreicher Aufruf gibt das Objekt selbst zurück oder eine Liste mit ihrer Größe:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Ein Fehler gibt eine Meldung zurück, und Details, wenn es welche gibt:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Statuscodes
+
+Der Statuscode sagt, was schiefgelaufen ist:
+
+| Code | Bedeutung |
+|---|---|
+| `200` | Der Aufruf war erfolgreich |
+| `400` | Die Anfrage ist fehlerhaft, zum Beispiel eine Token-Erneuerung ohne Refresh Token oder ein Upload ohne Datei |
+| `401` | Das Token fehlt, ist falsch oder abgelaufen: melden Sie sich an oder erneuern Sie es |
+| `403` | Die Rollen des Benutzers erlauben den Aufruf nicht (einschließlich des Genehmigens des eigenen Jobs, sofern seine Genehmigung nicht `allowSelf: true` setzt oder Sie Admin sind), oder das Konto muss zuerst etwas tun (siehe unten) |
+| `404` | Das Objekt existiert nicht |
+| `409` | Die Anfrage ist unvollständig (ein Start ohne Daten), oder das Objekt ist nicht in einem Zustand, der die Aktion erlaubt |
+| `422` | Die [Startvalidierung](../launch-validation/) hat die Werte des Formulars abgelehnt; `details` listet die Gründe auf |
+| `429` | Zu viele Anfragen an die Endpunkte für Anmeldung und Tokens oder zu viele fehlgeschlagene Anmeldungen (siehe [Authentifizierung](authentication.html)) |
+| `500` | Der Server ist gescheitert; das Serverprotokoll enthält den Grund |
+
+Bei einem Job bedeutet `409`, dass er im falschen Zustand für die Aktion ist: einen Job abbrechen, der nicht läuft (oder dessen Abbruch bereits angefordert wurde),
+einen Job erneut starten, der noch läuft, oder einen Job genehmigen oder ablehnen, der nicht mehr auf eine Genehmigung wartet.
+
+---
+
+## Eine 403 mit Code
+
+Einige `403`-Antworten tragen einen `code`, für etwas, das der Benutzer im Browser tun muss, bevor irgendein anderer Aufruf funktioniert:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Code | Was zu tun ist |
+|---|---|
+| `password_change_required` | Der Benutzer hat sich mit dem öffentlichen Standardpasswort angemeldet: ändern Sie es zuerst im Profil |
+| `disclaimer_required` | Der Haftungsausschluss ist eingeschaltet, und der Benutzer hat seine aktuelle Version noch nicht akzeptiert: akzeptieren Sie ihn im Browser |
+
+Ein langlebiges API-Token (siehe [Authentifizierung](authentication.html#long-lived-tokens)) wird vom Haftungsausschluss nie aufgehalten.
diff --git a/i18n/de/_integrate/chat/index.md b/i18n/de/_integrate/chat/index.md
new file mode 100644
index 0000000..574ac50
--- /dev/null
+++ b/i18n/de/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Chat-Assistent
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Chat-Assistent
+{: .no_toc }
+
+Formulare in einem Gespräch ausfüllen und starten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren, die ihn einschalten, und für die Benutzer, die mit ihm chatten: Formulare in einem Gespräch ausfüllen und starten.
+
+Eine Chat-Schaltfläche auf jeder Seite öffnet einen
+Assistenten, der das passende Formular findet, nach fehlenden Angaben fragt, die Auswahlmöglichkeiten des Formulars
+als Schaltflächen anbietet und eine Zusammenfassung mit einer Schaltfläche **Starten** zeigt. Ein Job startet erst, wenn der Benutzer darauf klickt.
+
+---
+
+## Wie es funktioniert
+
+Der Assistent kommuniziert über den Server mit dem KI-Modell, und der Server beantwortet die Anfragen des Modells mit derselben Formular-Engine wie der Browser:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Modellaufrufe kommen vom Server**, nie vom Browser, daher bleibt der API-Schlüssel auf dem Server
+  (siehe [Anbieter](providers.html)).
+- **Das Modell kann nichts starten.** Es bereitet eine einmalige Zusammenfassung vor; Starten prüft sie vor der Ausführung erneut.
+- **Der Benutzer wählt die Ziele.** Auswahlen und erforderliche Namen kommen vom Benutzer, nie vom Modell.
+- **„Ja“ oder „starten“ zu tippen bewirkt nichts.** Nur die Schaltfläche startet einen Job.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Einschalten](switching-it-on.html) | Den Assistenten aktivieren und Formulare darin anbieten |
+| [Anbieter](providers.html) | Das Sprachmodell hinter dem Assistenten, und Proxys |
+| [Datenschutz und Grenzen](privacy-and-limits.html) | Was das Netzwerk verlässt, und die Grenzen pro Benutzer |
+| [Erneut starten und Audit](relaunching-and-audit.html) | Erneut starten aus dem Chat, der Audit-Trail und die Einschränkungen |
diff --git a/i18n/de/_integrate/chat/privacy-and-limits.md b/i18n/de/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..3307458
--- /dev/null
+++ b/i18n/de/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Datenschutz und Grenzen
+parent: Chat-Assistent
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Datenschutz und Grenzen
+{: .no_toc }
+
+Was das Netzwerk verlässt, und die Grenzen pro Benutzer
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Was das Netzwerk verlässt
+
+Für die teilnehmenden Formulare wird Folgendes an den Anbieter gesendet:
+
+- die Formularnamen und -beschreibungen, die Feldbeschriftungen, Hilfetexte, Auswahlmöglichkeiten und die Werte, die gerade
+  ausgefüllt werden;
+- das Gespräch.
+
+Folgendes wird nie an den Anbieter, die Seite oder das Protokoll gesendet:
+
+- Passwörter (der Benutzer gibt diese im Browser ein), gespeicherte Anmeldedaten und der API-Schlüssel;
+- die Ausgabe eines Jobs und seine gespeicherten Extravars (der Assistent liest nur den Status eines Jobs, und nur
+  wenn **Den Assistenten seine Jobs verfolgen lassen** in den Einstellungen eingeschaltet ist).
+
+Alles unter einem Schlüssel, der wie ein Secret aussieht (`password`, `secret`, `token`, `api_key`, ...),
+wird maskiert, bevor das Modell oder die Seite es sieht.
+
+Um Formulardaten im Haus zu behalten, verwenden Sie Ihren eigenen Tenant (Azure OpenAI) oder ein lokales Modell (Ollama), keine öffentliche API.
+
+---
+
+## Grenzen
+
+Die folgenden Grenzen werden auf der Einstellungsseite festgelegt:
+
+- **Nachrichten pro Gespräch** (20) - danach muss der Benutzer ein neues Gespräch beginnen.
+- **Tool-Runden pro Nachricht** (6) - wie oft das Modell ein Tool aufrufen darf, bevor es antwortet.
+- **Zeitlimit** (60 s) - pro Aufruf beim Anbieter.
+
+Die folgenden Grenzen sind fest: eine Nachricht gleichzeitig pro Gespräch, höchstens 4000 Zeichen pro Nachricht, 60 Nachrichten pro
+Benutzer und Stunde und 5 Gespräche pro Benutzer. Ein Gespräch wird nach 2 Stunden ohne Nachricht verworfen.
+
+Eine Zusammenfassungskarte mit einer Schaltfläche **Starten** lässt sich einmal verwenden und läuft nach 15 Minuten ab: Starten antwortet dann, dass die
+Zusammenfassung abgelaufen ist, und der Benutzer bittet den Assistenten um eine neue. Gespräche und Zusammenfassungen werden im Arbeitsspeicher gehalten, daher muss
+der Benutzer nach einem Neustart ein neues Gespräch beginnen.
diff --git a/i18n/de/_integrate/chat/providers.md b/i18n/de/_integrate/chat/providers.md
new file mode 100644
index 0000000..62c0c2f
--- /dev/null
+++ b/i18n/de/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Anbieter
+parent: Chat-Assistent
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Anbieter
+{: .no_toc }
+
+Das Sprachmodell hinter dem Assistenten, und Proxys
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wählen Sie den Anbieter auf der Einstellungsseite. Das füllt die Basis-URL, die Authentifizierung und
+die API-Version aus, die alle bearbeitbar bleiben. Leere Felder fallen auf die Standardwerte des Anbieters zurück.
+
+| Anbieter | Protokoll | Basis-URL (Standard) | Schlüssel gesendet als |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | Pflichtangabe: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, API-Version `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | keiner |
+| **Andere OpenAI-kompatible** (LiteLLM, ein Gateway, vLLM, LM Studio, ...) | OpenAI | Pflichtangabe, endet meist auf `/v1` | Bearer |
+
+Die Modell-ID ist die, die der Anbieter oder Proxy verwendet (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). Der Assistent braucht ein Modell, das **Tool Calling** unterstützt; bei kleinen lokalen Modellen ist die Unterstützung
+unterschiedlich.
+
+Für lokale Server und Proxys, die keinen Schlüssel brauchen, genügt eine Basis-URL allein; es wird kein Authorization-Header gesendet.
+
+---
+
+## Der API-Schlüssel
+
+Der Schlüssel kommt aus Anmeldedaten, daher wird er wie jedes andere Secret gespeichert und rotiert:
+
+* Legen Sie Anmeldedaten vom Typ **api** unter **Einstellungen > Verbindungen > Anmeldedaten** an (siehe [Anmeldedaten](../credentials.html)),
+  mit dem Schlüssel als Passwort. Sie können den Schlüssel auch aus einem [Secret Store](../secret-stores/) lesen.
+* Wählen Sie sie im Feld **Anmeldeinformation** der Chat-Einstellungen. Der Schlüssel wird für jede Nachricht gelesen, daher gilt ein
+  geändertes Passwort ab der nächsten Nachricht.
+
+Ein Schlüssel, der auf der Einstellungsseite gespeichert wurde, bevor es Anmeldedaten gab, funktioniert weiter, solange keine Anmeldedaten gewählt sind. Der
+[Konfigurations-Seed](../seed/) setzt den Schlüssel selbst, als `api_key`.
+
+---
+
+## Für einen Proxy
+
+Ein Proxy oder Gateway vor dem Modell kann diese Einstellungen brauchen:
+
+- **Authentifizierung** - wie der Schlüssel gesendet wird: `Authorization: Bearer`, `api-key`, `x-api-key`
+  oder keiner. Leer verwendet den Standard des Anbieters.
+- **API-Version** - der Header `anthropic-version` oder `?api-version=` in der URL bei OpenAI-kompatiblen (Azure).
+- **Benutzer** - wird bei jedem Aufruf als `user` (OpenAI-kompatibel) oder `metadata.user_id`
+  (Anthropic) gesendet. Manche Proxys verlangen es. Leer sendet nichts.
+- **Zertifikatsfehler ignorieren** - unsicher; vertrauen Sie stattdessen der CA des Proxys mit `NODE_EXTRA_CA_CERTS`.
+- **Zusätzliche Header** - ein JSON-Objekt, z. B. `{"X-Org": "ops"}`. Einzeilige Textwerte, höchstens 20;
+  die Schlüssel- und Content-Header lassen sich nicht ersetzen.
+
+---
+
+## In einem Container, hinter einem Proxy
+
+Der Chat verwendet einfaches ausgehendes HTTPS aus dem Container des AnsibleForms-Servers. Hinter einem
+Egress-Proxy des Unternehmens setzen Sie `HTTPS_PROXY` **und** `NODE_USE_ENV_PROXY=1`; ohne das Zweite
+ignoriert der eingebaute HTTP-Client von Node `HTTPS_PROXY`. Ein Anbieter mit einem Zertifikat von einer
+internen CA erfordert, dass Node dieser CA vertraut (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Mit `NODE_USE_ENV_PROXY=1` muss ein Modell oder Proxy innerhalb des Netzwerks in
+`NO_PROXY` aufgeführt sein, sonst geht der Aufruf an den Egress-Proxy, der es nicht erreichen kann.
+
+Ein fehlgeschlagener Verbindungstest nennt den Host und den Grund (DNS, abgelehnte Verbindung oder nicht vertrauenswürdiges Zertifikat).
diff --git a/i18n/de/_integrate/chat/relaunching-and-audit.md b/i18n/de/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..c7be89d
--- /dev/null
+++ b/i18n/de/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Erneut starten und Audit
+parent: Chat-Assistent
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Erneut starten und Audit
+{: .no_toc }
+
+Erneut starten aus dem Chat, der Audit-Trail und die Einschränkungen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Erneut starten
+
+Eine Anfrage wie „Starte Job 1234 erneut“ (der Benutzer muss die Job-ID eintippen) zeigt eine Vorschau des erneuten Starts
+nach denselben Regeln wie `relaunch_job` des MCP-Servers, einschließlich der Passwortregel der
+[Startvalidierung](../launch-validation), und zeigt eine Zusammenfassung **Erneut starten**; die Schaltfläche
+startet ihn einmal. „Starte Job 1234 erneut mit Server web02“ ändert nur dieses Feld.
+
+---
+
+## Audit
+
+Jeder Start aus dem Chat wird als **chat.launch** aufgezeichnet, mit dem Benutzer, dem Job, dem Formular,
+dem Anbieter und dem Payload-Hash der genehmigten Zusammenfassung. Änderungen an den Chat-Einstellungen werden
+wie jede andere Änderung der Einstellungen aufgezeichnet.
+
+---
+
+## Einschränkungen
+
+Der Chat-Assistent kann noch nicht alles, was ein Browser kann:
+
+- **Wizard-Formulare** können nicht teilnehmen (`enableForChat` wird für sie abgelehnt), ebenso wenig
+  die Felder, die der Assistent nicht ausfüllt: Passwörter und Datei-Uploads.
+- Antworten kommen in einem Stück; Streaming wird noch nicht unterstützt.
+- Das Modell kann eine Anfrage missverstehen. Die Zusammenfassungskarte zeigt genau, was gesendet wird;
+  prüfen Sie sie, bevor Sie auf **Starten** klicken.
diff --git a/i18n/de/_integrate/chat/switching-it-on.md b/i18n/de/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..7eabdd0
--- /dev/null
+++ b/i18n/de/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Einschalten
+parent: Chat-Assistent
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Einschalten
+{: .no_toc }
+
+Den Assistenten aktivieren und Formulare darin anbieten
+{: .fs-6 .fw-300 }
+
+---
+
+Der Assistent braucht alle vier der folgenden Punkte:
+
+1. **`ENABLE_CHAT=1`** - die Umgebungsvariable. Auf der Einstellungsseite geändert, gilt sie sofort, ohne Neustart; solange
+   sie aus ist, antworten die Chat-Endpunkte `404`. Siehe [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Ein Modellanbieter** - Einstellungen -> Verbindungen -> **Chat-Assistent** (oder der [Konfigurations-Seed](../seed) auf Kubernetes).
+3. **Formulare, die teilnehmen** - `enableForChat: true` bei jedem Formular; der Assistent ignoriert alle anderen.
+4. **Benutzer, die ihn verwenden dürfen** - die Rollenoption `allowChat` (Standard: true). Setzen Sie
+   `allowChat: false` bei einer Rolle, um ihre Mitglieder auszuschließen.
+
+Die Chat-Schaltfläche erscheint für einen Benutzer, sobald alle vier Bedingungen erfüllt sind.
diff --git a/i18n/de/_integrate/mcp/index.md b/i18n/de/_integrate/mcp/index.md
new file mode 100644
index 0000000..8f96499
--- /dev/null
+++ b/i18n/de/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: MCP-Server
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# MCP-Server
+{: .no_toc }
+
+KI-Agenten Ihre Formulare über das Model Context Protocol nutzen lassen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Administratoren und Integratoren: MCP-Clients Formulare auflisten, ausfüllen und starten lassen, als der Benutzer, dessen Token sie halten.
+
+AnsibleForms kann einen
+[Model-Context-Protocol](https://modelcontextprotocol.io)-Server bereitstellen, sodass ein MCP-Client, etwa
+ein Chat-Backend oder ein IDE-Assistent, die Formulare auflisten kann, die ein Benutzer verwenden darf, ihre Felder ermitteln,
+Jobs starten und deren Fortschritt verfolgen kann.
+
+---
+
+## Was er ist und was nicht
+
+Der MCP-Server ist eine technische Schnittstelle zum selben Formularablauf, den der Browser verwendet. Er läuft
+**als der Benutzer, dessen Token er erhält**: dieselben Formularrollen, dieselbe Sichtbarkeit der Jobs, dieselben
+Prüfungen reservierter Extravars wie bei einer Übermittlung im Browser.
+
+Er fügt keine eigene KI-Richtlinie hinzu. Ob ein Agent vor einem Start um Bestätigung bitten muss,
+welche Formulare er verwenden darf oder wie viele Anfragen er stellen darf, liegt beim MCP-Client. Das
+Start-Tool ist als destruktiv markiert, daher fragt ein gut erzogener Client zuerst nach einer Bestätigung,
+aber der Server erzwingt das nicht.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Einrichtung](setup.html) | Den Server einschalten und den Client authentifizieren |
+| [Tools](tools.html) | Die Tools, mit denen ein Agent Formulare ausfüllt, genehmigt und erneut startet |
+| [Einschränkungen](limitations.html) | Ausdrücke laufen auf dem Server, und was der MCP-Server nicht tut |
diff --git a/i18n/de/_integrate/mcp/limitations.md b/i18n/de/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..faa3414
--- /dev/null
+++ b/i18n/de/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Einschränkungen
+parent: MCP-Server
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Einschränkungen
+{: .no_toc }
+
+Ausdrücke laufen auf dem Server, und was der MCP-Server nicht tut
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## runLocal-Ausdrücke
+
+`runLocal`-Ausdrücke, Felder vom Typ `local` / `credential` / `html` und `evalDefault`-Standardwerte werden
+auf dem Server ausgewertet, in einem separaten V8-Kontext: kein `process`, `require`, kein Netzwerk und keine
+Timer, kein Kompilieren von Strings zu Code, ein Zeitlimit von 2 Sekunden und nur die Hilfsfunktionen,
+die der Browser anbietet (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Das schützt vor fehlerhaften oder außer Kontrolle geratenen Ausdrücken. Es ist keine Sandbox für feindseligen Code,
+und muss es auch nicht sein: der Code stammt aus der Formulardefinition, nie vom MCP-
+Aufrufer, und jeder Wert, den ein Aufrufer sendet, wird als JavaScript-Literal eingesetzt.
+
+Ein Ausdruck, der eine Browser-API verwendet (`window`, `document`, `fetch`), kann hier nicht laufen und
+gibt `status: error` zurück.
+
+Serverseitige Ausdrücke (ohne `runLocal`) durchlaufen dieselben
+[`EXPRESSION_SANITIZER`](../customization)-Regeln wie für den Browser.
+
+---
+
+## Einschränkungen
+
+Einige Formulare und Felder lassen sich noch nicht über den MCP-Server verwenden:
+
+- **Wizard-Formulare** lassen sich noch nicht starten. Ihre Schritte lassen sich mit `subform` auflösen.
+- **Dateifelder** lassen sich nicht ausfüllen; ein Formular, dessen Dateifeld einen Wert hat, wird abgelehnt.
+- **Listenzeilen** (und ein `yaml`-Feld mit einem Subform, das eine solche Zeile ist): jede Zeile, die Sie
+  senden, außer einer, die den `deleteMarker` der Liste trägt, wird über ihr Subform aufgelöst, mit
+  den Werten des Formulars als `__parent__`, und dann validiert. Das schließt verschachtelte Listen ein, bei denen
+  `__parent__.__parent__` das Formular erreicht. Senden Sie einfache Zeilen, also die rohen Feldwerte des Subforms.
+  Fehlerhafte Zeilen werden pro Listenfeld in `rowErrors` aufgeführt
+  (`vms[1].disks[0].size (missing)` in der Meldung). Höchstens 500 Zeilen werden pro Aufruf akzeptiert,
+  über alle Ebenen hinweg.
+- Ein Enum, das auf `__auto__` belassen wird, wird nie mit seiner ersten Option gefüllt; der Aufrufer muss wählen.
+- Jede MCP-Anfrage erzeugt einen Eintrag im Audit-Protokoll (Aktion „MCP-Anfrage (KI-Agent)“); der
+  Job selbst wird unter dem Benutzer aufgezeichnet, wie bei jedem anderen Start.
diff --git a/i18n/de/_integrate/mcp/setup.md b/i18n/de/_integrate/mcp/setup.md
new file mode 100644
index 0000000..47e9004
--- /dev/null
+++ b/i18n/de/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Einrichtung
+parent: MCP-Server
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Einrichtung
+{: .no_toc }
+
+Den Server einschalten und den Client authentifizieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Aktivieren
+
+Setzen Sie [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) auf `1` oder schalten Sie es unter **Einstellungen > Verbindungen > MCP** ein
+(siehe [Die MCP-Seite](#the-mcp-page)). Auf der Einstellungsseite geändert, gilt der Schalter sofort, ohne Neustart. Solange er
+aus ist, antwortet der Endpunkt `404`. Der Endpunkt ist:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Er verwendet zustandsloses Streamable HTTP mit einfachen JSON-Antworten, daher geben `GET` und `DELETE` 405 zurück.
+
+---
+
+## Begrenzen, was Agenten tun können
+
+Zwei weitere Schalter schränken den MCP-Server für jeden Client ein. Wie `ENABLE_MCP` gelten sie ohne Neustart:
+
+| Variable | Mit `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | Der Server bietet keines der Tools an, die starten, planen oder ändern (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), und lehnt sie ab. Agenten können Formulare auflisten, lesen und ausfüllen, Zeitpläne und gespeicherte Jobs lesen und Jobs verfolgen, aber nichts starten oder ändern: eine sichere Art, einen Agenten auszuprobieren. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Agenten sehen nur die Formulare, die `enableForChat: true` setzen, dieselbe Liste wie der [Chat-Assistent](../chat/). Jedes andere Formular und jeder Job eines solchen antwortet als nicht gefunden. |
+
+Beide sind standardmäßig aus: Agenten sehen jedes Formular, das die Rollen des Benutzers erlauben, und dürfen es starten.
+
+---
+
+## Die MCP-Seite
+
+**Einstellungen > Verbindungen > MCP** enthält die Einstellungen des MCP-Servers in zwei Reitern.
+
+- **Allgemein** hat die drei Schalter, `ENABLE_MCP`, `MCP_READ_ONLY` und `MCP_CHAT_FORMS_ONLY`, gespeichert mit **Speichern**. Die beiden
+  anderen lassen sich nur ändern, solange der MCP-Server eingeschaltet ist.
+- **Client-Konfiguration** zeigt den **Endpunkt**, mit einer Schaltfläche zum Kopieren, und eine fertige Konfiguration für **Claude Code**
+  (`.mcp.json` oder ein Befehl `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, das beim ersten Start des Servers
+  nach dem Token fragt) und **Codex** (`~/.codex/config.toml`, mit dem Token in der
+  Umgebungsvariable `ANSIBLEFORMS_TOKEN`). Jede hat ihre Kopierschaltfläche; ersetzen Sie `<your-token>` durch ein eigenes Token, erstellt
+  über den Link **Token erstellen**.
+
+Der Endpunkt wird aus der URL der App (**Einstellungen > URL**) gebildet, wenn sie gesetzt ist, sonst aus der Adresse des Browsers.
+
+---
+
+## Authentifizierung
+
+Jede Anfrage braucht ein AnsibleForms-Access-Token:
+
+```
+Authorization: Bearer <token>
+```
+
+Holen Sie eines auf dem üblichen Weg (`POST /api/v2/auth/login` oder die Abläufe für OIDC / Entra ID) und
+erneuern Sie es mit `POST /api/v2/token`. Es gibt bewusst **kein Login-Tool**: ein als
+Tool-Argument übergebenes Passwort würde im Kontext des Sprachmodells und in seinem Chatverlauf landen.
+
+Die Rollen des Benutzers müssen den MCP-Server außerdem erlauben, über die [Rollenoption](../config/roles.html) `allowMcp`. Wenn keine Rolle
+des Benutzers sie setzt, folgt sie `allowChat`, das standardmäßig eingeschaltet ist. Ein Benutzer, dem sie verweigert ist, erhält bei jeder Anfrage `403`.
+
+- **Ein Chat-Backend** meldet den Benutzer selbst an, behält das Refresh Token und übergibt das Access
+  Token bei jedem MCP-Aufruf.
+- **Ein IDE-Client** braucht ein Token, das lange genug hält, um einmal konfiguriert zu werden. Mit einer Rolle,
+  die die Option `allowApiTokens` hat, erstellen Sie eines unter
+  [Profil > API-Tokens](../profile/api-token.html), oder melden Sie sich mit `?expiryDays=<n>` an der
+  Anmelde-URL an, für ein Token, das so viele Tage gültig ist.
+
+So verbinden Sie einen Coding-Agenten mit einem solchen Token:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Fügen Sie den Server mit dem Token als Header hinzu:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Fügen Sie den Server zu `~/.codex/config.toml` hinzu, mit dem Token aus einer Umgebungsvariable:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Setzen Sie dann die Variable, bevor Sie Codex starten:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/de/_integrate/mcp/tools.md b/i18n/de/_integrate/mcp/tools.md
new file mode 100644
index 0000000..01360a6
--- /dev/null
+++ b/i18n/de/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Tools
+parent: MCP-Server
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Tools
+{: .no_toc }
+
+Die Tools, mit denen ein Agent Formulare ausfüllt, genehmigt und erneut startet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Der MCP-Server bietet bis zu 15 Tools an. Sechs werden jedem Benutzer angeboten; die anderen folgen den Rollenoptionen des Benutzers, sodass einem Benutzer
+ohne eine Option deren Tools gar nicht erst angeboten werden:
+
+| Tool | Was es tut | Angeboten mit |
+|---|---|---|
+| `list_forms` | Die Formulare, die der Benutzer verwenden darf: Name, Beschreibung, Kategorien und `enableForChat` (ob der Chat-Assistent es anbietet). | immer |
+| `get_form` | Die vollständige Definition eines Formulars. Jedes Feld trägt zusätzlich `dynamic` (aus einem Ausdruck oder einer Abfrage ausgewertet) und `dependsOn` (die Felder, die es liest). | immer |
+| `resolve_field` | Wertet das Formular für die bisher ausgefüllten Werte aus. Siehe unten. | immer |
+| `launch_job` | Startet das Formular mit den angegebenen Werten, genau wie eine Übermittlung im Browser. Gibt die Job-ID zurück. | immer |
+| `relaunch_job` | Startet einen Job erneut, mit einigen geänderten Feldern. Siehe unten. | immer |
+| `get_job` | Status und Ausgabe eines Jobs (`tail` begrenzt die Ausgabe auf die letzten Zeilen). | immer |
+| `plan_job` | Führt das Formular einmal später aus, als der Benutzer: was **Später ausführen (einmalig)** im Formular tut. | `allowPlannedJobs` |
+| `create_schedule` | Legt einen Zeitplan an, wiederkehrend (`cron`) oder einmalig (`run_at`), wie auf der Seite **Zeitpläne**. | `allowScheduledJobs` |
+| `list_schedules` | Die Zeitpläne, die der Benutzer sehen darf: alle mit `allowScheduledJobs`, sonst die Läufe, die er geplant hat. | `allowPlannedJobs` oder `allowScheduledJobs` |
+| `get_schedule` | Ein Zeitplan, mit seinen Extra-Variablen (geheim aussehende maskiert) und der Ausgabe seines letzten Laufs. | `allowPlannedJobs` oder `allowScheduledJobs` |
+| `delete_schedule` | Bricht einen geplanten Lauf ab oder löscht einen Zeitplan, den der Benutzer sehen darf. | `allowPlannedJobs` oder `allowScheduledJobs` |
+| `list_stored_jobs` | Die [gespeicherten Jobs](../jobs/stored-jobs.html), die der Benutzer sehen darf, ohne ihre Werte. | `allowStoredJobs` |
+| `get_stored_job` | Ein gespeicherter Job mit seinen Werten, über `id` oder über `form` und `name` unter den eigenen des Benutzers. | `allowStoredJobs` |
+| `store_job` | Speichert Werte eines Formulars unter einem Namen, wie **Speichern** im Formular. | `allowStoredJobs` |
+| `delete_stored_job` | Löscht einen gespeicherten Job, den der Benutzer sehen darf. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` und `plan_job` nehmen `verbose: true`, um den Job im ausführlichen Modus laufen zu lassen, was die
+Rollenoption `allowVerboseMode` braucht. Mit [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) werden die Tools, die starten, planen oder
+ändern (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` und `delete_stored_job`),
+nicht angeboten.
+
+Es gibt kein Tool, um beliebige Ausdrücke, Abfragen, Playbooks oder Extravars auszuführen. Ausdrücke
+und Abfragen laufen immer nur so, wie das Formular sie definiert.
+
+Der [Chat-Assistent](../chat) verwendet diese Tools ebenfalls, mit einer Schaltfläche **Starten** anstelle von `launch_job`.
+
+---
+
+## Ein Formular ausfüllen
+
+Rufen Sie `resolve_field` mit dem Formularnamen und den bisherigen Werten auf, und erneut nach jeder Antwort. Es arbeitet sich
+in Abhängigkeitsreihenfolge durch die Felder und meldet für jedes:
+
+- `status`: `resolved`, `waiting` (mit `waitingFor`), `hidden` oder `error` (das Feld fällt auf seinen Standard zurück);
+- `value`, `default` und, für Auswahlfelder, `options` (höchstens `maxOptions`, Standard 200);
+- `needsInput`: ein Pflichtfeld ohne Wert oder eine Auswahl, die noch auf `__auto__` steht;
+- `validationErrors`: die Regeln, die der Wert verletzt, als `[{type, description}]`, mit der Meldung des Browsers.
+
+Für das ganze Formular listen `missing` und `invalid` auf, was noch zu beheben ist; `launch_job` lehnt es ab, bis `complete` true ist.
+
+Die Validierung ist der eigene Code des Browsers, geteilt mit der [Startvalidierung](../launch-validation). Versteckte Felder werden nicht
+validiert, und ein leeres optionales Feld ist gültig.
+
+---
+
+## Zeitpläne und geplante Läufe
+
+`plan_job` nimmt dieselben `form`, `values` und `expectedPayloadHash` wie `launch_job`, mit einem `name` für den Lauf und `run_at`, einer
+ISO-8601-Zeit mit ihrem Offset oder `Z` (`2026-10-15T22:00:00+02:00`); eine Zeit ohne Zone wird abgelehnt. Die Werte werden jetzt aufgelöst
+und validiert und beim Auslösen des Laufs erneut geprüft, wie bei einem [geplanten Lauf](../jobs/schedules.html#planned-runs) im
+Browser. Die Antwort gibt die Laufzeit in UTC und nach der Uhr der App an.
+
+`create_schedule` nimmt ein `form`, einen `name`, entweder `cron` (fünf Felder, etwa `0 22 * * 1-5`) oder `run_at`, und die
+`extraVars`, die der Job bekommt. Ein solcher Zeitplan läuft als `Schedule Service`, ohne die Validierung des Formulars; um ein Formular einmal als
+der Benutzer auszuführen, verwenden Sie `plan_job`. Zeitplannamen sind eindeutig.
+
+---
+
+## Gespeicherte Jobs
+
+Ein gespeicherter Job sind die unter einem Namen gespeicherten Werte eines Formulars; die Tools arbeiten auf denselben gespeicherten Jobs wie der Browser.
+
+`list_stored_jobs` listet die eigenen gespeicherten Jobs des Benutzers auf, oder die aller für einen Benutzer mit `showSettings`, mit ihrem Namen, ihrer Beschreibung,
+ihrem Formular, ihrer Erstellung und ihrem Ablauf. Einer, der als `usable` markiert ist (ein eigener des Benutzers, zu einem Formular, das er starten darf), lässt sich als `storedJob`
+(`{ "id": 7 }` oder `{ "name": "..." }` unter den eigenen des Benutzers für dieses Formular) an `resolve_field`, `launch_job` oder `plan_job` übergeben: seine
+Werte sind der Ausgangspunkt, und `values` werden darübergelegt. Passwortfelder werden nicht gespeichert, geben Sie sie daher in `values` an.
+`launch_job` und `plan_job` aus einem gespeicherten Job brauchen den `expectedPayloadHash`, den `resolve_field` dafür zurückgegeben hat, und
+`resolve_field` lehnt `storedJob` zusammen mit `subform` ab.
+
+`store_job` nimmt das `form`, einen `name`, der unter den gespeicherten Jobs des Benutzers für dieses Formular eindeutig ist, die `values` und optional eine
+`description` und `expires_at` (ISO 8601 mit seinem Offset oder `Z`). Seine Antwort sagt, welche Passwortfelder weggelassen wurden.
+
+---
+
+## Werte übergeben
+
+Übergeben Sie `field`, um nur dieses Feld und das, wovon es abhängt, aufzulösen. Für eine Listenzeile oder einen Wizard-Schritt übergeben Sie `subform` (und
+optional `parent`, die Werte des übergeordneten Formulars).
+
+Senden Sie Werte so, wie der Browser sie hält. Ein Auswahlfeld akzeptiert auch einen Teildatensatz oder seinen `valueColumn`-Wert
+(`"vol1"`), und ein Array, wenn es `multiple` ist. Berechnete Felder ignorieren gesendete Werte, sofern sie nicht `editable` sind.
+
+---
+
+## Genau die Payload genehmigen
+
+Wenn das Formular vollständig ist, gibt `resolve_field` auch zurück, was `launch_job` übermitteln wird:
+
+- `modeledExtravars`: die Extravars, nachdem `model`, `valueColumn` und `output` angewendet wurden,
+  mit maskierten Passwortfeldern;
+- `credentials`: die AnsibleForms-Anmeldedaten, die der Job verwenden wird (Namen, keine Secrets);
+- `payloadHash`: ein SHA-256-Hash aus dem Formularnamen, den echten Extravars und den Anmeldedaten.
+
+Zeigen Sie `modeledExtravars` dem Bediener und übergeben Sie den `payloadHash`, den er genehmigt hat, an
+`launch_job` als `expectedPayloadHash`. Der Start löst das Formular erneut auf und wird abgelehnt,
+wenn die Payload abweicht, zum Beispiel weil eine Abfrage jetzt anders antwortet.
+`ansibleforms_user`, `__jobid__` und `__verbose__` werden beim Start hinzugefügt und gehören nicht zum Hash.
+
+`launch_job` prüft nur die Payload. Eine Bearbeitung des Formulars, die die Payload gleich lässt, lehnt den Start nicht ab.
+Jede Antwort von `resolve_field` trägt außerdem einen `formFingerprint`, einen SHA-256-Hash der Formulardefinition: um einen
+Start nach jeder Bearbeitung des Formulars abzulehnen, vergleichen Sie ihn selbst, bevor Sie `launch_job` aufrufen, wie es die Schaltfläche
+**Starten** des Chat-Assistenten tut.
+
+---
+
+## Erneut starten mit Änderungen
+
+`relaunch_job` nimmt eine Job-`id` und `values`: nur die zu ändernden Felder, als Rohwerte.
+`values` wird über die Werte gelegt, mit denen der Job ursprünglich gestartet wurde, und das Ergebnis wird
+genau wie bei `launch_job` aufgelöst und validiert, Listenzeilen eingeschlossen, und dann als
+neuer Job von Ihnen gestartet (`ansibleforms_user` sind Sie, nicht der ursprüngliche Absender). Datei-Uploads aus
+dem ursprünglichen Job werden wiederverwendet.
+
+Ohne `values` ist es ein erneuter Start **so, wie der Job lief**: seine gespeicherten Extravars werden auf dem
+Server wieder abgespielt, Passwörter eingeschlossen (die Vorschau maskiert sie). Steht das Formular jedoch unter der Startvalidierung
+`enforce`, durchläuft der erneute Start dieselbe Prüfung wie ein erneuter Start mit
+Änderungen.
+
+**Passwörter werden nie mit den Feldwerten gespeichert**, daher wird ein erneuter Start, der die
+Prüfung durchläuft, abgelehnt, wenn das Formular ein Passwortfeld zeigt, auf oberster Ebene oder in einer Listenzeile
+(`unsupported`, mit den `passwordFields`). Ein Passwortfeld, das durch seine Abhängigkeiten verborgen ist,
+blockiert den erneuten Start nicht. Siehe [Startvalidierung](../launch-validation).
+
+Rufen Sie es zuerst mit `preview: true` auf: es gibt `modeledExtravars` (Passwörter maskiert),
+`credentials` und einen `payloadHash` zurück, ohne zu starten. Bestätigen Sie sie mit dem Benutzer und rufen Sie
+es dann erneut mit `expectedPayloadHash` auf. Es gelten dieselben Berechtigungen wie für einen erneuten Start im Browser:
+das Formular muss den erneuten Start erlauben, und Ihre Rollen brauchen die Option `allowJobRelaunch`. Ein
+Job ohne gespeicherte Formulardaten (gestartet, bevor es den erneuten Start gab) und ein Wizard-Formular lassen sich nicht
+mit Änderungen erneut starten.
+
+Die REST-API bietet dasselbe über `POST /api/v2/job/{id}/relaunch` mit dem Body
+`{ "values": { ... } }`; ohne Body spielt sie den Job so ab, wie er lief.
+
+---
+
+## Fehler
+
+Ein abgelehnter Aufruf ist ein Tool-Fehler, dessen strukturierter Inhalt einen `code` und die Details trägt:
+
+| Code | Wann |
+|---|---|
+| `form_incomplete` | `launch_job` oder `relaunch_job` bei einem Formular, das nicht vollständig ist, mit `missing`, `invalid`, `waiting`, `validationErrors` und `rowErrors` |
+| `payload_mismatch` | die Payload weicht von `expectedPayloadHash` ab, mit beiden Hashes |
+| `access_denied` | die Rollen des Benutzers gewähren das Formular, den Job, den Zeitplan oder den gespeicherten Job nicht, oder den ausführlichen Modus, oder der Server ist schreibgeschützt |
+| `not_found` | kein solches Formular, Subform oder Job |
+| `unsupported` | ein Wizard-Formular, ein Subform für sich allein, ein Dateifeld oder ein `relaunch_job`, das ein angezeigtes Passwortfeld bräuchte |
+| `no_form_data` | `relaunch_job` mit Änderungen für einen Job, der keine Formularwerte gespeichert hat, etwa einen von einem Zeitplan gestarteten; starten Sie ihn stattdessen ohne Änderungen erneut |
+| `invalid_request` | eine Anfrage, die der Server als fehlerhaft ablehnt |
+| `internal_error` | alles andere |
diff --git a/i18n/de/_introduction/concepts.md b/i18n/de/_introduction/concepts.md
new file mode 100644
index 0000000..e518dae
--- /dev/null
+++ b/i18n/de/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Konzepte
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Konzepte
+{: .no_toc }
+
+Die in dieser Dokumentation verwendeten Begriffe, jeweils mit ihrer Seite verlinkt
+{: .fs-6 .fw-300 }
+
+---
+
+## Glossar
+
+Die in dieser Dokumentation verwendeten Begriffe:
+
+| Begriff | Bedeutung |
+|---|---|
+| **[Formular](forms/)** | Eine YAML-Definition, die Eingaben sammelt und ein Playbook, eine Vorlage oder einen Workflow ausführt |
+| **[Formularfeld](formfields/)** | Eine Eingabe eines Formulars, etwa `text`, `enum` oder `checkbox`; ihr Wert wird zu einer Extravar |
+| **[Kategorie](config/categories.html)** | Eine Gruppe im Baum der Formulare auf der Seite Formulare, definiert in `config.yaml` |
+| **[Rolle](config/roles.html)** | Eine Menge von Benutzern und Gruppen; ein Formular listet die Rollen auf, die es sehen und ausführen dürfen, `default` für alle |
+| **[Ausdruck](expressions/)** | JavaScript, das einen Feldwert berechnet, im Browser (`runLocal: true`) oder auf dem Server |
+| **[Extravars](formfields/)** | Die Variablen, die an das Playbook oder die Vorlage gesendet werden, aufgebaut aus den Feldwerten |
+| **[Anmeldedaten](expressions/credentials.html)** | Ein gespeicherter Login, verschlüsselt mit `ENCRYPTION_SECRET`: ein Benutzer und ein Passwort (und Host, Port, Datenbank), oder seit 7.3.0 die Adresse und Secrets eines LDAP-Verzeichnisses, eines SSO-Anbieters, eines Runners oder eines HashiCorp Vault |
+| **[Secret Store](secret-stores/)** | Eine Verbindung zu HashiCorp Vault oder CyberArk, die Benutzer und Passwort von Anmeldedaten liefert |
+| **[Job](gui/forms-and-jobs.html)** | Ein Lauf eines Formulars, mit seinem Status, seinen Extravars und seiner Ausgabe, in der Job-Historie aufbewahrt |
+| **[Runner](runners.html)** | Wo ein Job läuft, hinzugefügt unter **Verbindungen > Runner**: `rte` für Playbooks, `awx` (AWX oder die Variante `aap` oder `ascender`), `semaphore`, `rundeck` oder `jenkins` für Vorlagen und Jobs. Ein Formular wählt einen mit `runner:` oder läuft auf dem Standard-Runner `rte` (Playbooks) oder `awx` (Vorlagen) |
+| **[RTE](rte/)** | Eine Laufzeitumgebung: der AnsibleForms-Server, mit `AF_ROLE=rte` in einem eigenen Container gestartet, neben python und ansible, der die Playbooks eines Runners vom Typ `rte` ausführt |
+| **[Genehmigungspunkt](forms/approval.html)** | Eine Pause in einem Job, bis ein Benutzer mit einer Genehmigungsrolle ihn genehmigt oder ablehnt |
+| **[Workflow](workflows/)** | Ein Graph aus Playbooks, Genehmigungen und anderen Workflows, verknüpft bei Erfolg, bei Fehler oder immer, in der Syntax von AWX |
+| **[Multistep-Formular](forms/multistep.html)** | Seit 7 veraltet: ein Formular, das mehrere Playbooks oder Vorlagen nacheinander ausführt; ein Workflow ersetzt es |
+| **[Benachrichtigungskanal](notification-channels.html)** | Ein Mailserver, ein Slack- oder Teams-Webhook, ein Telegram-Chat oder ein Webhook, an den Benachrichtigungen und Genehmigungsanfragen gehen |
+| **[Designer](designer/)** | Der Browser-Editor für Formulare, Playbooks, Inventare und Workflows, den jeweils eine Person gleichzeitig verwendet |
+| **[Subform](forms/subform.html)** | Eine wiederverwendbare Gruppe von Feldern, die die Zeilen eines Felds `list` oder das Objekt eines Felds `yaml` beschreibt |
+| **[config.yaml](config/)** | Die Datei mit den Kategorien, den Rollen und den Konstanten; die Formulare liegen in eigenen Dateien |
+| **[Konfigurations-Seed](seed/)** | Eine YAML-Datei (`CONFIG_SEED_PATH`), die die Admin-Objekte deklariert, etwa Runner und Anmeldedaten |
+| **[Persistenter Ordner](customization/paths.html)** | Der Ordner mit den Dateien, die AnsibleForms über Neustarts und Aktualisierungen hinweg behalten muss |
diff --git a/i18n/de/_introduction/gui/administration.md b/i18n/de/_introduction/gui/administration.md
new file mode 100644
index 0000000..6af359a
--- /dev/null
+++ b/i18n/de/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Administration
+parent: Rundgang durch die Oberfläche
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Administration
+{: .no_toc }
+
+Das Menü Einstellungen: das System, sein Erscheinungsbild, Zugriff, Verbindungen und Protokolle
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Das Menü Einstellungen
+
+**Einstellungen** in der Kopfzeile öffnet die Administrationsseiten, im linken Menü gruppiert unter **System**, **Erscheinungsbild**,
+**Zugriff**, **Verbindungen** und **Protokolle**. Jeder Eintrag erscheint nur für einen Benutzer mit der Rollenoption, die seine Seite braucht:
+`allowBackupOps` für **Backups**, `showLogs` für **Serverprotokoll** und `showSettings` für jede andere Seite.
+Ab 7.3.0 öffnen drei Optionen einen Teil davon ohne den Rest:
+
+| Rollenoption | Öffnet |
+|---|---|
+| `showAppearanceSettings` | Die Seiten unter **Erscheinungsbild** |
+| `showConnectionsSettings` | Die Seiten unter **Verbindungen**, außer **Syslog**; Repositories, Secret Stores und geschützte Anmeldedaten zu ändern bleibt Sache eines Admins |
+| `showAuditLog` | Das **Audit-Protokoll** |
+
+Siehe [Rollen](../config/roles.html#role-options) für die Rollenoptionen.
+
+---
+
+## Listen und Datensatzseiten
+
+Ab 7.3.0 teilen sich die Einstellungslisten und Datensatzseiten ein Layout, mit ihren Bedienelementen in einer eigenen Zeile unter dem Titel:
+
+| Teil | Wie es funktioniert |
+|---|---|
+| Suchfeld | Auf jeder Einstellungs- und Datensatzseite das Erste in dieser Zeile. Ein Wort grenzt alle Reiter auf einmal ein: die passenden Felder, Zeilen oder Einträge erscheinen unter dem Namen ihres Reiters |
+| Seitengröße | Eine Tabelle zeigt so viele Zeilen, wie auf den Bildschirm passen, bis eine Seitengröße gewählt wird: 10, 20, 50 oder 100 |
+| Spalten | Jede benannte Spalte sortiert, und eine leere Zelle zeigt `–` |
+| Kontrollkästchen | Zeilen haben sie nur dort, wo sich mit den angehakten Zeilen etwas tun lässt, und das Zeilenmenü (⋮) bietet dieselbe Aktion an |
+| Zeilenmenü | Kurze Beschriftungen, etwa **Bearbeiten** und **Löschen**. Eine Liste mit einer Spalte **Aktiviert** hat sie an erster Stelle und bietet in jedem Zeilenmenü **Aktivieren** oder **Deaktivieren** an, je nachdem, was zutrifft |
+
+Die Listen mit einer Spalte **Aktiviert** sind die SSO-Anbieter, die LDAP-Verzeichnisse, die Runner, die Zeitpläne, die Benachrichtigungskanäle,
+die Syslog-Server, die Ankündigungen, die Labels und die Versionen des Haftungsausschlusses.
+
+---
+
+## System
+
+Die Instanz selbst: ihre Einstellungen, ihr Zustand und ihre Backups.
+
+| Seite | Wofür sie da ist |
+|---|---|
+| **Allgemein** | Die Umgebungsvariablen, in Reitern von Konfiguration bis Protokollierung. Siehe [Umgebungsvariablen](../customization/). |
+| **Status** | Der Zustand der Instanz und der Systeme, von denen sie abhängt, in den Reitern Prüfungen und Informationen. Siehe [Monitoring](../production/monitoring.html). |
+| **Backups** | Backups der Datenbank, der config.yaml und der Formulare erstellen, wiederherstellen und löschen. Siehe [Backups](../production/backups.html). |
+
+![Einstellungen > Allgemein, der Reiter Konfiguration](../assets/screenshots/settings.jpg)
+
+### Backups
+
+Die Liste der Backups, nächtliche und manuelle: **Backup hinzufügen** erstellt sofort eines, und das Menü einer Zeile hat **Backup anzeigen**, **Wiederherstellen** und **Löschen**.
+
+![Einstellungen > Backups](../assets/screenshots/backups.jpg)
+
+### Wiederherstellen
+
+**Wiederherstellen** zeigt, was das Backup enthält, und stellt es dann wieder her; **Vor dem Wiederherstellen ein neues Backup erstellen (empfohlen)** ist standardmäßig angehakt.
+
+![Ein Backup wiederherstellen](../assets/screenshots/restore.jpg)
+
+---
+
+## Erscheinungsbild
+
+Wie die Instanz für alle aussieht, und die Meldungen, die sie zeigt.
+
+| Seite | Wofür sie da ist |
+|---|---|
+| **Standardwerte** | Theme, Sprache, Formularansicht, Zeitzone und Datumsformat für Benutzer, die keine gewählt haben. Siehe [Standardwerte](../appearance/defaults.html). |
+| **Name** | Der Name im Browser-Tab und auf der Anmeldeseite. Siehe [Name](../appearance/name.html). |
+| **Logo** | Ihr eigenes Logo in der Kopfzeile. Siehe [Logo](../appearance/logo.html). |
+| **Symbol** | Ihr eigenes Symbol im Browser-Tab. Siehe [Symbol](../appearance/icon.html). |
+| **Links** | Der Designer-Link und Ihre eigenen Links und Menüs in der Kopfzeile. Siehe [Links](../appearance/links.html). |
+| **Labels** | Labels neben dem Logo, etwa PRODUCTION und EU. Siehe [Labels](../appearance/labels.html). |
+| **Ankündigungen** | Meldungen unter der Kopfzeile, jede von ihrem Beginn bis zu ihrem Ende. Siehe [Ankündigungen](../announcements.html). |
+
+---
+
+## Zugriff
+
+Wer sich anmelden darf und was er danach tun darf.
+
+| Seite | Wofür sie da ist |
+|---|---|
+| **Haftungsausschluss** | Bedingungen, die jeder Benutzer einmal akzeptiert, und wer welche Version akzeptiert hat. Siehe [Haftungsausschluss](../disclaimer.html). |
+| **Benutzer** | Die lokalen Benutzer sowie die aus LDAP und Single Sign-On. Siehe [Benutzer und Gruppen](../users-and-groups.html). |
+| **Gruppen** | Die lokalen Gruppen sowie die aus LDAP und Single Sign-On. Siehe [Benutzer und Gruppen](../users-and-groups/local-group.html). |
+| **Rollen** | Die Rollen der config.yaml: wer sie hat und was sie erlauben. Siehe [Rollen](../config/roles.html). |
+| **LDAP** | Anmeldung mit einem LDAP-Verzeichnis oder Active Directory. Siehe [LDAP](../authentication/ldap.html). |
+| **SSO** | Single Sign-On mit Entra ID oder OpenID-Connect-Anbietern. Siehe [Authentifizierung](../authentication/). |
+
+![Zugriff > LDAP, das Hauptverzeichnis](../assets/screenshots/ldap.jpg)
+
+---
+
+## Verbindungen
+
+Die Systeme, die AnsibleForms erreicht, und womit es sich bei ihnen anmeldet.
+
+| Seite | Wofür sie da ist |
+|---|---|
+| **Repositories** | Die Git-Repositories, aus denen die Formulare und Playbooks kommen. Siehe [Git-Repositories](../repositories/). |
+| **Anmeldedaten** | Die Konten und Secrets, die Formulare, Playbooks und Verbindungen verwenden. Siehe [Anmeldedaten](../credentials.html). |
+| **Secret Stores** | HashiCorp Vault und CyberArk, aus denen sich Anmeldedaten lesen lassen. Siehe [Secret Stores](../secret-stores/). |
+| **Runner** | Wo Jobs laufen: RTE-Container für Playbooks und AWX und Ähnliches für Vorlagen. Siehe [Runner](../runners.html). |
+| **SSH** | Das Schlüsselpaar, mit dem sich die App mit Git verbindet, und die bekannten Hosts. Siehe [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Benachrichtigungen** | SMTP-Server, Slack, Microsoft Teams, Telegram und Webhooks. Siehe [Benachrichtigungskanäle](../notification-channels.html). |
+| **Chat-Assistent** | Der KI-Anbieter des Chat-Assistenten. Siehe [Chat-Assistent](../chat/). |
+| **MCP** | Der MCP-Server für KI-Agenten. Siehe [MCP](../mcp/). |
+| **Syslog** | Syslog-Server, die das Serverprotokoll, das Audit-Protokoll oder beides empfangen. Siehe [Syslog](../production/logs.html#syslog). |
+
+![Verbindungen > Anmeldedaten, der Reiter Verbindung von Anmeldedaten](../assets/screenshots/credentials.jpg)
+
+---
+
+## Protokolle
+
+Was auf der Instanz passiert ist.
+
+| Seite | Wofür sie da ist |
+|---|---|
+| **Audit-Protokoll** | Wer was geändert hat und ob es erlaubt war, gefiltert nach Benutzer, Aktion und Ergebnis. Siehe [Audit-Trail](../production/logs.html#audit-trail). |
+| **Serverprotokoll** | Das eigene Protokoll des Servers, zur Fehlersuche. Siehe [Protokolle](../production/logs.html). |
+
+### Serverprotokoll
+
+Die letzten Zeilen des Protokolls, die neueste unten, laufend verfolgt, während sie geschrieben werden. Das Suchfeld filtert sie (ein regulärer
+Ausdruck), **Leeren** leert die Ansicht, nicht das Protokoll, und **Herunterladen** speichert das ganze Protokoll.
+
+![Protokolle > Serverprotokoll](../assets/screenshots/logs.jpg)
+
+---
+
+## API-Dokumentation
+
+**API-Dokumentation** im Hilfemenü (das Fragezeichen in der Kopfzeile) verlinkt auf die Swagger UI der REST-API unter `/api/v2/docs`.
+Siehe [API](../api/).
+
+![Swagger-Oberfläche](../assets/screenshots/swagger.jpg)
diff --git a/i18n/de/_introduction/gui/designer-and-git.md b/i18n/de/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..fe3d363
--- /dev/null
+++ b/i18n/de/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Designer und Git
+parent: Rundgang durch die Oberfläche
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Designer und Git
+{: .no_toc }
+
+Formulare bearbeiten und in Git aufbewahren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Eingebauter Designer
+
+Bearbeiten Sie Formulare, Kategorien, Konstanten, Vars-Dateien, Playbooks, Inventare und Workflows, jeweils als YAML, mit Feldern (Visuell)
+und als Vorschau. Die Seiten zum [Designer](../designer/) beschreiben jeden Bereich.
+
+![Eingebauter Designer](../assets/screenshots/designer.jpg)
+
+---
+
+## Git-Repositories
+
+Binden Sie Git-Repositories ein, um Ihre Formulare und Playbooks unter Versionskontrolle zu stellen.
+
+![Git-Repositories](../assets/screenshots/git.jpg)
+
+---
+
+## Git-Repository-Editor
+
+Bearbeiten und konfigurieren Sie die Einstellungen der Git-Repository-Anbindung.
+
+![Git-Repository-Editor](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/de/_introduction/gui/forms-and-jobs.md b/i18n/de/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..f89c3e1
--- /dev/null
+++ b/i18n/de/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formulare und Jobs
+parent: Rundgang durch die Oberfläche
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formulare und Jobs
+{: .no_toc }
+
+Die Anmeldung, das Dashboard, das Ausfüllen eines Formulars und das Verfolgen seiner Jobs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Anmeldung
+
+Die Seite zur Benutzerauthentifizierung, mit Unterstützung für lokale, LDAP-, Entra-ID- und OIDC-Authentifizierung.
+
+![Anmeldung](../assets/screenshots/login.jpg)
+
+---
+
+## Das Dashboard
+
+Das Haupt-Dashboard zeigt alle verfügbaren Formulare, nach Kategorie geordnet.
+
+![Dashboard](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Ein Formular
+
+Ein Beispiel für ein Formular mit externen Datenquellen und dynamischen Feldern.
+
+![Beispielformular](../assets/screenshots/form.jpg)
+
+---
+
+## JSON-Vorschau des Formulars
+
+Zeigen Sie vor dem Ausführen des Jobs eine Vorschau der JSON-Payload und der Extra-Variablen an, die an Ansible übergeben werden.
+
+![JSON-Vorschau des Formulars](../assets/screenshots/form-json.jpg)
+
+---
+
+## Laufender Job
+
+Ausführung eines Ansible-Playbooks in Echtzeit mit Live-Ausgabe.
+
+![Laufender Job](../assets/screenshots/run.jpg)
+
+---
+
+## Job-Ausgabe
+
+Die vollständige Ausgabe eines ausgeführten Ansible-Playbooks.
+
+![Job-Ausgabe](../assets/screenshots/job-output.jpg)
+
+---
+
+## Job-Protokolle
+
+Alle Jobs mit ihrem Status und ihren Zeiten, über das linke Menü nach Status gefiltert.
+
+![Job-Protokolle](../assets/screenshots/job-log.jpg)
+
+---
+
+## Multistep
+
+Ein Multistep-Job, mit der Ausgabe jedes Schritts unter dem Hauptjob. Multistep-Formulare sind seit 7 veraltet: ein
+[Workflow](../workflows/) verkettet stattdessen Playbooks, Vorlagen und Genehmigungen.
+
+![Multistep-Formular](../assets/screenshots/multistep.jpg)
+
+---
+
+## Zeitpläne
+
+Planen Sie Formulare zu bestimmten Zeiten oder in Intervallen ein. Die [Cron-Beispiele](../faq.html#which-cron-expressions-can-i-use) listen gängige
+Ausdrücke auf und erklären, in welcher Zeitzone ein Zeitplan läuft.
+
+![Zeitpläne](../assets/screenshots/schedules.jpg)
diff --git a/i18n/de/_introduction/gui/index.md b/i18n/de/_introduction/gui/index.md
new file mode 100644
index 0000000..c0b146b
--- /dev/null
+++ b/i18n/de/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Rundgang durch die Oberfläche
+nav_order: 3
+has_children: true
+has_toc: false
+description: Screenshots und ein Rundgang durch die grafische Benutzeroberfläche
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Rundgang durch die Oberfläche
+{: .no_toc }
+
+Ein bebilderter Rundgang durch die Weboberfläche von AnsibleForms, vom Dashboard bis zu den fortgeschrittenen Administrationsfunktionen.
+{: .fs-6 .fw-300 }
+
+---
+
+Für alle Benutzer und Administratoren: die Bildschirme der Weboberfläche, gruppiert nach dem, was Sie damit tun.
+
+---
+
+## In diesem Abschnitt
+
+Jede Gruppe von Bildschirmen hat eine eigene Seite:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Formulare und Jobs](forms-and-jobs.html) | Die Anmeldung, das Dashboard, das Ausfüllen eines Formulars und das Verfolgen seiner Jobs |
+| [Designer und Git](designer-and-git.html) | Formulare bearbeiten und in Git aufbewahren |
+| [Administration](administration.html) | Das Menü Einstellungen: das System, sein Erscheinungsbild, Zugriff, Verbindungen und Protokolle |
+| [Persönliche Einstellungen](personal-settings.html) | Ihr Profil und das dunkle Theme |
diff --git a/i18n/de/_introduction/gui/personal-settings.md b/i18n/de/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..0724f30
--- /dev/null
+++ b/i18n/de/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Persönliche Einstellungen
+parent: Rundgang durch die Oberfläche
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Persönliche Einstellungen
+{: .no_toc }
+
+Ihr Profil und das dunkle Theme
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Benutzerprofil
+
+Ihr Konto, Ihre Einstellungen, Ihr Passwort, Ihre Berechtigungen und Ihre API-Tokens.
+
+Siehe [Ihr Profil](../profile).
+
+![Benutzerprofil](../assets/screenshots/profile.jpg)
+
+---
+
+## Dunkler Modus
+
+AnsibleForms unterstützt einen dunklen Modus, der die Augen schont.
+
+![Dunkler Modus](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/de/_introduction/how-it-works.md b/i18n/de/_introduction/how-it-works.md
new file mode 100644
index 0000000..c9df075
--- /dev/null
+++ b/i18n/de/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Wie es funktioniert
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Wie es funktioniert
+{: .no_toc }
+
+Die Teile einer Installation, was bei einem Start passiert und wo Daten aufbewahrt werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Architektur
+
+AnsibleForms ist ein Node.js-Server, der die Webanwendung und eine REST-API bereitstellt, gestützt auf eine MySQL-Datenbank. Er liest Formulare
+aus YAML-Dateien und führt selbst nichts aus: er übergibt jeden Job an einen [Runner](runners.html). Ein Playbook geht an einen Ihrer RTE-Container
+(Laufzeitumgebung), der `ansible-playbook` ausführt, und eine Vorlage oder ein Job geht an AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Architektur von AnsibleForms</title>
+<desc id="afd-desc">Der Browser und ein optionaler MCP-Client sprechen mit dem AnsibleForms-Server. Der Server speichert seine Daten in MySQL und im persistenten Ordner und verbindet sich mit Datenquellen, Secret Stores, Git-Repositories, Anmeldeanbietern, Benachrichtigungskanälen, Syslog-Servern und einem optionalen Modellanbieter. Seine Runner übergeben jedes Playbook an einen von einem oder mehreren RTE-Containern, jeweils über einen WebSocket, die ansible-playbook ausführen und die Ausgabe an den Server zurücksenden, und jede Vorlage oder jeden Job an AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Browser</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">Formulare, Designer,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">Jobs, Chat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">MCP-Client</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">optional</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">AnsibleForms-Server</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Web-App und REST-API</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formulare, Ausdrücke</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflows, Zeitpläne</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">MCP-Server (optional)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runner</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">geben Jobs an ihren Runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Datenquellen</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">Datenbanken, APIs, Dateien</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Secret Stores</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Git-Repositories</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">Formulare, Playbooks, Config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Anmeldeanbieter</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Benachrichtigungen</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">Mail, Slack, Teams, Webhooks</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Syslog-Server</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">Protokoll, Audit-Trail</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Modellanbieter</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">optional, Chat-Assistent</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Persistenter Ordner</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">Config, Formulare, Playbooks</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">Jobs, Benutzer,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">Anmeldedaten</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">RTE-Container</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">starten ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">Playbooks,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">Vorlagen, Jobs</text>
+</svg>
+</div>
+
+Die Komponenten im Diagramm haben jeweils eine eigene Rolle:
+
+| Komponente | Rolle |
+|---|---|
+| **Browser** | Die Vue-Webanwendung: die Formulare, der [Designer](gui/designer-and-git.html), die Job-Historie und die Einstellungen |
+| **AnsibleForms-Server** | Wertet die Formulare aus, zeichnet die Jobs auf, führt die Workflows und die Zeitpläne aus, übergibt jeden Job an seinen Runner und verfolgt ihn, und stellt die [REST-API](api/) bereit |
+| **Runner** | Wo Jobs laufen, hinzugefügt unter **Verbindungen > Runner**: ein Formular nennt einen mit `runner: <name>` oder verwendet den Standard-Runner seines Typs (siehe [Runner](runners.html)) |
+| **RTE-Container** | Ein oder mehrere Container mit Laufzeitumgebung, derselbe Server mit `AF_ROLE=rte` gestartet: jeder führt `ansible-playbook` für [Ansible-Formulare](forms/ansible.html) aus, mit den Python-Bibliotheken und Collections seines Images, und sendet die Ausgabe und den Endstatus über einen WebSocket an den Server zurück, ohne Datenbank-Anmeldedaten (siehe [Wie die RTE läuft](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runner für Vorlagen und Jobs: [AWX-Formulare](forms/awx.html) starten eine Job- oder Workflow-Vorlage, Formulare für [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) und [Jenkins](forms/jenkins.html) starten einen ihrer Jobs, und der Server verfolgt seine Ausgabe |
+| **MySQL / MariaDB** | Enthält die Jobs und ihre Ausgabe, die Benutzer, die Anmeldedaten und die Verbindungen; nur der Server liest und schreibt sie |
+| **Persistenter Ordner** | Enthält `config.yaml`, die Formulardateien, die Playbooks, die Protokolle und die Backups |
+| **Datenquellen** | Füllen die Felder: [Datenbankabfragen](formfields/enum.html), [REST-APIs](expressions/rest-apis.html), Dateien und [andere Funktionen](expressions/remote.html) |
+| **Secret Stores** | Liefern Benutzer und Passwort von Anmeldedaten zum Zeitpunkt der Verwendung, siehe [Secret Stores](secret-stores/) |
+| **Git-Repositories** | Halten die Formulare, die Playbooks und `config.yaml` unter Versionskontrolle |
+| **Anmeldeanbieter** | Melden die Benutzer an: [LDAP, Entra ID und OIDC](authentication/), neben den lokalen Benutzern |
+| **Benachrichtigungskanäle** | Transportieren die [Benachrichtigungen](forms/notifications.html) und die Genehmigungsanfragen: [Mail, Slack, Microsoft Teams, Telegram oder ein Webhook](notification-channels.html) |
+| **Syslog-Server** | Empfangen das Protokoll und den Audit-Trail, während sie geschrieben werden, siehe [Syslog](production/logs.html#syslog) |
+| **MCP-Client, Chat** | Optional, beide standardmäßig aus: der [MCP-Server](mcp/) und der [Chat-Assistent](chat/), der einen Modellanbieter braucht |
+
+Standardmäßig betreibt ein Container den Server, die Web-App und die Hintergrundarbeit gemeinsam, neben einer RTE. Für mehrere App-Knoten hinter einem
+Load Balancer, einen Worker für die Hintergrundarbeit und mehr RTEs siehe [Skalierung](production/scaling.html).
+
+### Gebaut mit
+
+Server und Weboberfläche bauen auf diesen Komponenten auf:
+
+| Teil | Technologie |
+|---|---|
+| **Server** | Node.js und Express |
+| **Datenbank** | MySQL oder MariaDB |
+| **Weboberfläche** | Vue 3, mit Bootstrap 5 und Font Awesome |
+
+---
+
+## Was passiert, wenn Sie ein Formular starten
+
+Ein Start durchläuft dieselben Schritte, ob er aus dem Browser oder über die [REST-API](api/jobs.html) kommt:
+
+1. **Laden** : der Server sendet nur die Formulare, die die [Rollen](config/roles.html) des Benutzers erlauben, und wertet Server-Ausdrücke aus
+2. **Übermitteln** : der Browser macht aus den Feldwerten Extravars und sendet sie an `POST /api/v2/job`
+3. **Prüfen** : der Server lädt das Formular für die Rollen des Benutzers neu und prüft, bei eingeschalteter [Startvalidierung](launch-validation/), die Werte
+4. **Aufzeichnen** : der Job wird mit dem Status `running` gespeichert, und seine ID wird den Extravars als `__jobid__` hinzugefügt
+5. **Genehmigen** : ein Formular mit einem [`approval`](forms/approval.html)-Punkt wartet, bis ein Genehmiger den Job annimmt
+6. **Anmeldedaten** : für ein Playbook liest die App (nie die RTE) die Anmeldedaten des Formulars aus der Datenbank oder einem [Secret Store](secret-stores/)
+7. **Ausführen** : der Job geht an seinen Runner, den, den das Formular mit `runner:` nennt, oder den Standard seines Typs. Für ein Playbook sendet die App den Job über den
+   WebSocket der RTE an ihre RTE, mit den für sie versiegelten Anmeldedaten, und die RTE führt `ansible-playbook` aus (siehe [Wie die RTE läuft](rte/#how-the-rte-runs)),
+   und AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins führt eine Vorlage oder einen Job aus. Ein [Workflow](workflows/) führt seine Knoten aus, jeden als
+   eigenen Job auf seinem eigenen Runner
+8. **Verfolgen** : der Server speichert die Ausgabe in der Datenbank, sobald sie ankommt, bei einem Playbook von der RTE über ihren Socket gesendet, oder von den
+   anderen Runnern gelesen. Die Formularseite liest den Job alle zwei Sekunden neu, und die Seite Jobs verfolgt ihn live, während der Server
+   jede Änderung ankündigt
+9. **Beenden** : der Job erhält seinen Endstatus, und seine [`notifications`](forms/notifications.html) gehen per Mail und an seine
+   [Benachrichtigungskanäle](notification-channels.html) hinaus, wenn das Formular sie anfordert
+
+---
+
+## Wo was gespeichert wird
+
+AnsibleForms hält seinen Zustand an zwei Orten: in der MySQL-Datenbank und im persistenten Ordner. Sichern Sie beide.
+
+### In der Datenbank
+{: .no_toc }
+
+Die Datenbank, `AnsibleForms`, wird beim ersten Start angelegt (sofern `ALLOW_SCHEMA_CREATION` nicht `0` ist) und enthält:
+
+* die Jobs, ihre Extravars und ihre Ausgabe, die Zeitpläne und die gespeicherten Jobs
+* die lokalen Benutzer, die Gruppen und die API-Tokens
+* die Anmeldedaten, verschlüsselt mit `ENCRYPTION_SECRET`, und die Verbindungen zu Secret Stores
+* die Runner, die Benachrichtigungskanäle (Mail eingeschlossen), die Syslog-Server sowie die Einstellungen für LDAP, SSO, Repositories und den Chat-Assistenten
+* das Audit-Protokoll
+
+### Im persistenten Ordner
+{: .no_toc }
+
+Er ist `/app/dist/persistent` im Image und `server/persistent` aus dem Quellcode; jeder Pfad hat seine eigene [Variable](customization/paths.html):
+
+| Standardpfad | Variable | Inhalt |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | Die Kategorien, die Rollen und die Konstanten |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | Die Formulardateien, `.yaml` oder `.yml`, nach Belieben in Unterordnern |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | Die Playbooks der `ansible`-Formulare und ihr Arbeitsverzeichnis |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Die Klone der Git-Repositories |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | Die Kopien, die der Designer vor dem Speichern anlegt |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | Die Datenbank-Backups |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | Die über `file`-Felder hochgeladenen Dateien |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` und `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | Das Zertifikat und der Schlüssel, wenn `HTTPS` `1` ist |
+| `.env` | | Die von den Einstellungsseiten gespeicherten Umgebungsvariablen (sofern `ALLOW_ENV_EDIT` nicht `0` ist) |
+
+Der erzeugte SSH-Schlüssel liegt in [`HOME_PATH`](customization/paths.html#env_HOME_PATH), standardmäßig außerhalb des persistenten Ordners.
diff --git a/i18n/de/_introduction/prerequisites.md b/i18n/de/_introduction/prerequisites.md
new file mode 100644
index 0000000..f6af111
--- /dev/null
+++ b/i18n/de/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Voraussetzungen
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Voraussetzungen
+{: .no_toc }
+
+Was Sie vor der Installation von AnsibleForms brauchen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Laufzeit
+
+AnsibleForms läuft als Container, als systemd-Dienste auf dem Server selbst oder, für diejenigen, die es selbst bauen, als Node.js-Anwendung:
+
+| Installation | Sie brauchen |
+|---|---|
+| [Installer](installation/installer.html) | Linux auf amd64 oder arm64, `curl` oder `wget` und `sha256sum`, sowie die Anforderungen der Engine, auf der er installiert (unten) |
+| [Nativ](installation/native.html) | Root, systemd und ein unterstütztes Linux (Ubuntu, Debian, RHEL und seine Nachbauten, SUSE); den Rest installiert der Installer |
+| [Docker](installation/docker.html) | Docker oder Podman und einen eigenen MySQL-Server |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose oder podman-compose; das Projekt startet auch MySQL |
+| [Kubernetes](installation/kubernetes.html) | Einen Cluster, Helm 3 und eine StorageClass (oder vorab angelegte PersistentVolumes) |
+| [Aus dem Quellcode](installation/from-source.html) | Node.js 26 (mindestens 24) mit npm, Git und Ansible für den RTE-Prozess, der die Playbooks ausführt |
+
+Das App-Image, `ghcr.io/ansibleforms/ansibleforms`, enthält Node.js und die Werkzeuge, die der Server aufruft (git, ssh, den mariadb-Client und
+ytt), aber weder Python noch Ansible. Playbooks laufen auf einer RTE (Laufzeitumgebung), einem zweiten Container aus
+`ghcr.io/ansibleforms/ansibleforms-rte-full` oder aus einem Image, das Sie auf `ansibleforms-rte-core` bauen (siehe [Skalierung](rte/)).
+Formulare, die nur Vorlagen auf AWX, AAP, Ascender, Semaphore, Rundeck oder Jenkins starten, brauchen keine RTE.
+
+---
+
+## Datenbank
+
+AnsibleForms speichert seine Jobs, Benutzer, Anmeldedaten und Verbindungen in MySQL 8 oder neuer oder in MariaDB.
+
+Beim ersten Start legt es das Schema `AnsibleForms` selbst an. Geben Sie ihm einen eigenen Datenbankbenutzer, mit Rechten nur auf diesem Schema,
+nicht root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Mehr braucht es nicht: es legt das Schema an und aktualisiert es, erstellt seine Backups und beendet, bei mehreren Workern, die Sitzung eines toten.
+Die Seite **Status** und das Protokoll warnen, wenn der Benutzer Rechte auf jeder Datenbank hat. Die App-Knoten und die Worker verbinden sich mit diesem
+Benutzer. Eine RTE in einem Socket-Modus (ausgehend oder eingehend, siehe [Modi](rte/modes.html)) hält keine Datenbank-Anmeldedaten: nur eine im Datenbankmodus,
+seit 7.3.0 veraltet, verbindet sich ebenfalls. Um das Schema selbst anzulegen, setzen Sie [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) auf `0`.
+Das Docker-Compose-Projekt und das Helm-Chart (das `mysql:8.4` verwendet) starten eine Datenbank für Sie.
+
+---
+
+## Dimensionierung
+
+Es gibt keine gemessenen Anforderungen: die Last hängt vor allem davon ab, wie viele Jobs gleichzeitig laufen und wie viel Ausgabe sie schreiben.
+Die Standardressourcen des Helm-Charts sind ein vernünftiger Ausgangspunkt für ein kleines Team:
+
+| Komponente | Requests | Limits | Volume |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB Arbeitsspeicher | 4 CPU, 4 GiB Arbeitsspeicher | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB Arbeitsspeicher | 2 CPU, 2 GiB Arbeitsspeicher | 10 GiB |
+
+Der App-Container führt kein Playbook aus. Jedes Playbook ist ein `ansible-playbook`-Prozess, mit seinen Forks, auf einer RTE: dimensionieren Sie CPU und
+Arbeitsspeicher jeder RTE für die Playbooks, die sie gleichzeitig ausführt, höchstens [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (standardmäßig `10`), und betreiben Sie mehr
+RTEs, um mehr auszuführen. Jobs, die auf AWX, AAP, Ascender oder den anderen Vorlagen-Runnern laufen, kosten AnsibleForms wenig.
+
+Die Job-Ausgabe wird standardmäßig für immer in der Datenbank aufbewahrt. Setzen Sie [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+auf einer ausgelasteten Instanz, damit die Datenbank nicht unbegrenzt wächst.
+
+---
+
+## Netzwerk
+
+Die App und jede RTE lauschen auf einem eigenen Port und öffnen ausgehende Verbindungen zu den Systemen, die Ihre Formulare und Einstellungen verwenden.
+
+### Eingehend
+{: .no_toc }
+
+Der Server lauscht auf Port `8000` ([`PORT`](customization/server.html#env_PORT)), über HTTP oder, mit
+[`HTTPS`](customization/server.html#env_HTTPS) auf `1` gesetzt, über HTTPS. Das Docker-Compose-Projekt veröffentlicht ihn auf Port 443,
+und das Helm-Chart stellt ihn über einen Service oder einen Ingress bereit. Eine RTE lauscht ebenfalls auf ihrem eigenen `PORT`, aber nur die App ruft sie auf:
+halten Sie sie aus dem öffentlichen Netzwerk heraus. Eine ausgehende RTE braucht überhaupt keinen eingehenden Port: sie verbindet sich auf dem Port der App mit der App.
+
+### Ausgehend
+{: .no_toc }
+
+Öffnen Sie die Verbindungen von AnsibleForms zu den Systemen, die Sie verwenden:
+
+| Ziel | Verwendet für |
+|---|---|
+| MySQL / MariaDB | Die AnsibleForms-Datenbank (`DB_HOST`, `DB_PORT`, Standard `3306`) |
+| Die RTE | Die Verbindung zu einer eingehenden RTE unter der Adresse ihres Runners über einen WebSocket, oder der Aufruf einer RTE im Datenbankmodus unter ihrer [`RTE_URL`](customization/server.html#env_RTE_URL), die sich dann selbst mit MySQL verbindet; eine ausgehende RTE verbindet sich stattdessen mit der App (siehe [Modi](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Starten und Verfolgen von Vorlagen und Jobs auf [Runnern](runners.html), über ihre HTTP(S)-API |
+| Die verwalteten Hosts | Playbooks verbinden sich von der RTE aus mit ihnen, zum Beispiel über SSH oder WinRM |
+| LDAP, Entra ID, OIDC | Anmeldung mit Verzeichnis- oder Single-Sign-On-Konten |
+| Git-Server | Klonen und Pullen von Repositories, über HTTPS oder SSH |
+| REST-APIs und Datenbanken | Die Datenquellen der Ausdrücke und Abfragen in Ihren Formularen |
+| HashiCorp Vault, CyberArk | Lesen von Anmeldedaten aus einem [Secret Store](secret-stores/) |
+| Mailserver, Slack, Teams, Telegram, Webhooks | Job-Benachrichtigungen und Genehmigungsanfragen, über die [Benachrichtigungskanäle](notification-channels.html) |
+| Modellanbieter | Der [Chat-Assistent](chat/), nur wenn er eingeschaltet ist |
+
+Um einzuschränken, welche Hosts die REST-Funktionen von Ausdrücken aufrufen dürfen, siehe
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) und
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Browser
+
+Die Webanwendung ist für aktuelle Browser gebaut: Chrome oder Edge 111, Firefox 114, Safari 16.4 oder neuer.
+Ältere Browser werden nicht unterstützt.
+
+---
+
+## Skalierung
+
+Standardmäßig betreibt ein AnsibleForms-Container die Web-App und die Hintergrundarbeit gemeinsam, neben einer RTE.
+
+Um mehr Benutzer zu bedienen, betreiben Sie mehrere App-Knoten hinter einem Load Balancer (`AF_ROLE=app`) neben einem Worker (`AF_ROLE=worker`), der die
+Zeitpläne, die Backups und die andere Hintergrundarbeit ausführt; nur ein Worker arbeitet gleichzeitig, und ein zweiter wartet darauf, zu übernehmen. Sie teilen
+die Datenbank, den persistenten Ordner, `ACCESS_TOKEN_SECRET` und `ENCRYPTION_SECRET`. Siehe [Skalierung](production/scaling.html). Betreiben Sie mehr
+RTEs, um mehr Playbooks gleichzeitig auszuführen: siehe [Mehrere RTEs](rte/several.html).
diff --git a/i18n/de/_introduction/what-is-ansibleforms.md b/i18n/de/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..19ed2ac
--- /dev/null
+++ b/i18n/de/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Was ist AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Was ist AnsibleForms
+{: .no_toc }
+
+Self-Service-Formulare vor Ansible und AWX, und wann Sie sie brauchen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Was es tut
+
+AnsibleForms stellt ein Webformular vor ein Playbook, einen Workflow oder eine Vorlage oder einen Job auf AWX, AAP, Ascender, Semaphore, Rundeck
+oder Jenkins, damit Menschen Automatisierung ohne Kommandozeile ausführen können.
+
+Ein Formular sammelt die Eingaben, prüft sie, formt sie zu Extravars und startet den Job. Die Daten in einem Formular können aus Datenbanken,
+REST-APIs, Dateien und anderen Feldern stammen, und jeder Start wird mit seiner Ausgabe in der Job-Historie aufgezeichnet.
+
+---
+
+## Typische Einsatzzwecke
+
+Teams verwenden AnsibleForms, um Routine-Automatisierung den Menschen zu übergeben, die sie anfordern:
+
+* **Self-Service-Anfragen** : eine virtuelle Maschine, ein Speicher-Volume, eine Freigabe oder ein Benutzerkonto, vom Anfragenden ausgefüllt
+* **Abgesicherte Vorgänge** : Aktionen mit Genehmigungspunkten, sodass eine zweite Person zustimmt, bevor der Job läuft
+* **Datengesteuerte Auswahl** : Auswahllisten, gefüllt aus einer CMDB, einer Datenbank oder einer REST-API, kaskadiert von einem Feld zum nächsten
+* **Wiederkehrende Jobs** : Formulare, die später oder nach einem Cron-Zeitplan laufen, jedes Mal mit denselben validierten Eingaben
+* **Automatisierung für Werkzeuge und Agenten** : die REST-API, der MCP-Server und der Chat-Assistent starten dieselben Formulare
+
+---
+
+## AnsibleForms oder AWX-Surveys?
+
+AWX, AAP und Ascender haben eigene Surveys. Was passt, hängt davon ab, was die Menschen brauchen, die die Jobs starten.
+
+Ein **Survey** reicht, wenn:
+
+* die Fragen fest sind: Text, Zahlen, Passwörter und Auswahlen aus einer statischen Liste
+* die Benutzer bereits in AWX, AAP oder Ascender arbeiten und dessen Berechtigungen zu ihnen passen
+* Sie keine weitere Anwendung samt Datenbank betreiben und pflegen wollen
+
+**AnsibleForms** hilft, wenn:
+
+* die Auswahlen von anderswo kommen: aus einer Datenbank, einer REST-API, einer Datei oder einem anderen Feld (kaskadierende Auswahllisten)
+* die Eingaben Validierung, Struktur (Listen, verschachtelte Objekte) oder berechnete Werte brauchen, bevor sie das Playbook erreichen
+* die Jobs Genehmigungspunkte, Zeitplanung oder einen Workflow brauchen, der Playbooks, Vorlagen und Genehmigungen aus einem Formular verkettet
+* die Benutzer AWX gar nicht sehen sollen, oder Sie auch Playbooks ohne AWX ausführen
+
+AnsibleForms startet Vorlagen von AWX, AAP und Ascender, daher arbeiten beide zusammen: die Formulare sammeln und formen die Eingaben, und
+AWX führt weiterhin die Jobs aus.
+
+---
+
+## Wie es weitergeht
+
+Der Rest dieses Abschnitts erklärt die beweglichen Teile, bevor Sie installieren:
+
+| Seite | Was sie behandelt |
+|---|---|
+| [Wie es funktioniert](how-it-works.html) | Die Architektur, die Schritte eines Starts und wo Daten aufbewahrt werden |
+| [Rundgang durch die Oberfläche](gui/) | Screenshots jedes Bildschirms, von der Anmeldung bis zu den Administrationsseiten |
+| [Konzepte](concepts.html) | Die in dieser Dokumentation verwendeten Begriffe |
+| [Voraussetzungen](prerequisites.html) | Was Sie vor der Installation brauchen |
diff --git a/i18n/de/_reference/faq.md b/i18n/de/_reference/faq.md
new file mode 100644
index 0000000..36045f2
--- /dev/null
+++ b/i18n/de/_reference/faq.md
@@ -0,0 +1,1279 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Häufig gestellte Fragen
+{: .no_toc }
+
+Häufige Fragen und Antworten zu AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Erste Schritte
+
+### Bereitstellungstopologie: ein Container oder mehrere Knoten
+
+Standardmäßig betreibt ein AnsibleForms-Container die Webanwendung und die Hintergrundarbeit in einem Prozess, neben einem RTE-Container, der
+die Playbooks ausführt. Betreiben Sie ihn mit einer Neustart-Richtlinie (zum Beispiel `restart: unless-stopped` in Docker) und sichern Sie sowohl die Datenbank als auch
+das persistente Volume.
+
+Um mehrere Replikas hinter einem Load Balancer zu betreiben, teilen Sie den Prozess mit `AF_ROLE` auf:
+
+- `app`-Knoten stellen die Weboberfläche und die API bereit: betreiben Sie so viele, wie Sie möchten, jeden mit demselben `ACCESS_TOKEN_SECRET`
+- ein `worker` erledigt die Hintergrundarbeit: das Schema und seine Aktualisierungen, den Konfigurations-Seed, die Zeitpläne, das nächtliche Backup, die Repository-
+  Synchronisierungen und die Aufräumarbeiten. Ein Worker arbeitet gleichzeitig und hält dabei eine Datenbanksperre; ein zweiter wartet und übernimmt, wenn der erste stoppt
+- `rte`-Container führen die Playbooks aus: betreiben Sie mehr davon, um mehr Playbooks gleichzeitig auszuführen
+
+Die App-Knoten und der Worker teilen sich die Datenbank, das persistente Volume und `ENCRYPTION_SECRET`. Eine RTE in einem Socket-Modus (ausgehend oder
+eingehend, siehe [Modi](rte/modes.html)) braucht weder die Datenbank noch `ENCRYPTION_SECRET`. Der Chat-Assistent braucht Sticky Sessions, und
+jeder Knoten führt sein eigenes Protokoll. Siehe [Skalierung](production/scaling.html) und das Setup
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Formulare aus mehreren Repositories verwalten
+
+Formulare aus jedem Git-Repository mit eingeschaltetem **Für Formulare verwenden?** werden automatisch zusammengeführt; bei doppelten Formularnamen gewinnt das erste,
+und eine Warnung wird protokolliert. Behalten Sie `config.yaml` in nur einem Repository. Siehe [Git-Repositories](repositories/).
+
+### Über Repositories
+
+AnsibleForms klont und pullt Git-Repositories unter dem Repository-Pfad (`REPO_PATH`), verwaltet unter **Einstellungen > Repositories**.
+Schalter an jedem Repository legen fest, was es enthält: Konfiguration, Formulare, Playbooks oder Vars-Dateien. Siehe [Git-Repositories](repositories/).
+
+### VS-Code-Validierung für Formulardateien
+
+Fügen Sie Ihren Formular-YAML-Dateien einen Schema-Header hinzu, um in VS Code Live-Validierung und Autovervollständigung zu erhalten.
+
+Installieren Sie die [YAML-Erweiterung](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) und fügen Sie diesen Kommentar als **erste Zeile** jeder Formulardatei ein:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Das funktioniert sowohl für Dateien mit einem Formular (ein YAML-Dict) als auch für Dateien mit mehreren Formularen (eine YAML-Liste):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code hebt unbekannte Eigenschaften, fehlende Pflichtfelder und falsche Typen schon beim Tippen hervor.
+
+---
+
+## Job-Verwaltung
+
+### Job erneut starten mit vorausgefüllten Daten
+
+Die Schaltfläche zum erneuten Start öffnet das Formular, vorausgefüllt mit den Werten des früheren Jobs; Passwortfelder werden nie gespeichert.
+Sie erfordert die Rollenoption `allowJobRelaunch`, und ein Formular kann sie mit `allowRelaunch: false` abschalten. Siehe [Einen Job erneut starten](jobs/actions.html#relaunch-a-job).
+
+### Logdatei eines Jobs
+
+Den Fortschritt über eine jobspezifische Logdatei verfolgen (v6.1.2).
+
+AnsibleForms kann neben der Ansible-Ausgabe eine **jobspezifische Logdatei** anzeigen. So lässt sich der Fortschritt lang laufender eigener Module verfolgen, die während der Ausführung sonst keine sichtbare Rückmeldung liefern würden.
+
+{: .note }
+> Diese Funktion funktioniert nur für Playbooks, die auf einer RTE laufen. Vorlagen und Jobs auf AWX, AAP, Ascender, Semaphore, Rundeck oder
+> Jenkins haben keine Logdatei.
+
+**Wie es funktioniert:**
+- Während eines Joblaufs beobachtet die RTE eine Logdatei unter einem bekannten Pfad im Playbook-Ordner
+- Alle zwei Sekunden, wenn sich die Datei geändert hat, kopiert die RTE ihren Inhalt in den Job, und noch einmal, wenn das Playbook endet
+- Die Logdatei wird in einem Abschnitt **Logdatei** der Job-Ausgabe angezeigt, nummeriert wie die Zeilen der Ausgabe : Zeitstempel und Stufe einer Logzeile (ERROR, WARNING, INFO, DEBUG) werden gelesen und wie in der Ausgabe eingefärbt, und ANSI-Farben werden unterstützt
+
+**Konvention für den Pfad der Logdatei:**
+
+Die Logdatei muss unter diesen Pfad geschrieben werden:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms übergibt `__jobid__` automatisch**, sodass Sie den Pfad in Ihrem Playbook ohne zusätzliche Konfiguration zusammensetzen können:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Übergeben Sie diese Variable an jede Rolle oder jedes eigene Modul, das Fortschritt in die Datei schreiben soll.
+
+**Aufgaben des Playbook- / Modulentwicklers:**
+- **Anlegen** der Logdatei (und ihres Verzeichnisses `.joblogs/`) zu Beginn des Vorgangs
+- **Schreiben** aussagekräftiger Fortschrittsmeldungen, während der Vorgang läuft
+
+Die RTE löscht die Datei, sobald das Playbook endet und der letzte Inhalt im Job gespeichert ist.
+
+**ANSI-Farbcodes werden unterstützt.**
+Standard-ANSI-Escape-Codes (zum Beispiel `\033[92m` für Grün und `\033[91m` für Rot) in Ihren Logmeldungen werden in der Oberfläche als Farben dargestellt, sodass sich Erfolg, Warnung und Fehler auf einen Blick unterscheiden lassen.
+
+**Typischer Anwendungsfall:**
+Ein eigenes Python-Modul für Ansible, das eine lange Folge von API-Aufrufen oder Datenoperationen ausführt (zum Beispiel einen SnapMirror-DR-Workflow), kann pro Schritt eine Zeile an die Logdatei anhängen. Ein Bediener, der den Job in AnsibleForms beobachtet, sieht dann im Abschnitt Logdatei den Fortschritt live, während die Job-Seite den Job verfolgt.
+
+### Jobid
+
+Die aktuelle Job-ID übergeben.
+
+AnsibleForms sendet die aktuelle Job-ID automatisch in den Extravars als `__jobid__`; es ist keine Konfiguration nötig.
+
+### Benutzerinfo
+
+Den aktuellen Benutzer übergeben.
+
+AnsibleForms sendet die Benutzerinformationen automatisch in den Extravars als `ansibleforms_user`; es ist keine Konfiguration nötig.
+
+Sie können wählen, wie viel davon gesendet wird. `EXTRAVARS_USER_FIELDS` nimmt eine kommagetrennte Liste von Schlüsseln der obersten Ebene
+(`username,email,type`) oder `none`, um nichts zu senden; ein Formular kann es mit seiner eigenen Eigenschaft `userExtravars` überschreiben.
+Der Standard ist das ganze Objekt, wie bisher. Das unten beschriebene `__user__` auf Formularseite kommt aus dem Login-Token und ist davon nie betroffen.
+
+### Benutzerinfo im Formular
+
+Auf die Informationen des aktuellen Benutzers im Formular zugreifen (v4.0.2).
+
+Das Feld `__user__` wird dem Formular automatisch hinzugefügt und kann in Ausdrücken referenziert werden:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Formularfelder
+
+### Kaskadierende Auswahllisten
+
+Kaskadierende Auswahllisten bauen.
+
+`enum`-Felder (Auswahllisten) können in ihrer Eigenschaft `query` oder `expression` Platzhalter enthalten, im Format `$(another_field)` oder `$(another_field[0].name)`.
+Sobald sich das referenzierte Feld ändert, wird das referenzierende Feld neu ausgewertet, was dynamische, kaskadierende Auswahllisten ergibt.
+Die Client-Webanwendung wertet Felder alle 100 ms neu aus; mit aktuellen Prozessoren und der Chromium-Engine ergibt das ein nahtloses Erlebnis.
+
+{: .note }
+> Eine Referenz auf ein anderes Enum-Feld gibt die ausgewählten Werte zurück, **nicht** die ganze Auswahlliste. Verwenden Sie die Eigenschaft `placeholderColumn` oder die Punktnotation wie `$(city.name)`.
+> **Neu in v4.0.20**: wird placeholderColumn auf "*" gesetzt, wird der ganze Datensatz statt einer einzelnen Spalte ausgegeben.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Feld-Platzhalter
+
+Auf den Wert eines anderen Felds verweisen.
+
+Platzhalter sind Verweise auf andere Felder im Formular.
+Ein Platzhalter hat immer das Format `$(reference)`, und sowohl Ausdrücke als auch Abfragen können Platzhalter enthalten.
+Ein Platzhalter, der auf ein einfaches Feld (Text, Zahl, Passwort) zeigt, enthält den Wert dieses Felds.
+Ein Platzhalter, der auf ein objektbasiertes Enum-Feld zeigt, muss entweder die Eigenschaft `placeholderColumn` oder die Punktnotation wie `$(city.name)` verwenden.
+Ein Platzhalter, der auf ein Ausdrucksfeld zeigt, gibt das ganze Objekt zurück, oder Sie verwenden einen fortgeschrittenen, JavaScript-ähnlichen Verweis wie `$(myarray[0].name)`.
+
+{: .important }
+> Der Platzhalter wird ersetzt, **bevor** der Ausdruck ausgewertet wird. Wenn Sie als Ergebnis einen String erwarten, müssen Sie ihn in Anführungszeichen setzen.
+> **Neu in v4.0.20**: wird placeholderColumn auf "*" gesetzt, wird der ganze Datensatz statt einer einzelnen Spalte ausgegeben.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Ein Feld verbergen
+
+Ein Feld verbergen.
+
+Verbergen Sie ein Feld mit der Feldeigenschaft `hide`, oder zeigen und verbergen Sie es dynamisch mit den Feldeigenschaften `dependencies` und `dependencyFn`.
+
+### Felder gruppieren
+
+Felder in einem Block zusammenfassen.
+
+Verwenden Sie die Feldeigenschaft `group`. Felder mit demselben Gruppennamen werden in einem Block zusammengefasst.
+
+### Feldvalidierung
+
+Ein Feld validieren.
+
+Verwenden Sie die Validierungseigenschaften der Felder, etwa `regex`, `minValue` und `notIn`.
+
+### Standardwert bei Enum
+
+Standardwert eines Enum.
+
+Die Feldeigenschaft `default` setzt einen Standardwert, und bei `enum`-Feldern können Sie Werte wie `__auto__` verwenden, um automatisch den ersten Eintrag zu wählen.
+
+Für einen dynamischen Standard auf Grundlage eines Ausdrucks verschieben Sie den Standardeintrag an den Anfang der Liste, wie im folgenden Beispiel.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Standardwert per Ausdruck
+
+Standardwert per Ausdruck.
+
+Bei Text-, Zahl- oder Datumsfeldern setzt die Eigenschaft `default` einen statischen Standardwert.
+
+Um den Standard dynamisch zu machen, auf Grundlage eines Ausdrucks, verwenden Sie eine von zwei Eigenschaften:
+* `editable`: mit der Eigenschaft editable machen Sie ein Ausdrucksfeld bearbeitbar
+* `evalDefault`: mit der Eigenschaft evalDefault wird der Standard als Ausdruck ausgewertet
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Wizard und Workflows
+
+### Was ist der Unterschied zwischen einem Wizard und einem Workflow?
+
+Ein **Wizard** und ein **Workflow** kommen beide in Schritten, arbeiten aber auf unterschiedlichen Ebenen und lassen sich kombinieren.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Ebene** | Ausführung | Formular / Oberfläche |
+| **Was es aufteilt** | Den Job in Knoten, die nacheinander oder nebeneinander laufen | Die Eingaben eines Formulars auf mehrere Seiten |
+| **Ergebnis** | 1 Workflow-Job, mit einem Job pro Knoten (jeder mit eigenem Playbook oder eigener Vorlage) | 1 Job läuft am Ende |
+| **Formular-`type`** | Muss `workflow` sein | Funktioniert mit jedem Formulartyp außer `subform` |
+| **Definiert durch** | Eine [Workflow-Datei](workflows/file.html) des Designers (`workflow:`) | Eine Liste von [Subform](forms/subform.html)-Verweisen (`wizard:`) |
+| **Verwenden, wenn** | „Mach A, dann B, dann C als separate Jobs“ | „Mein Formular hat zu viele Felder für eine Seite“ |
+
+**Kernaussage:** bei einem Workflow geht es darum, *was läuft und in welcher Reihenfolge*; bei `wizard` darum, *wie der Benutzer das Formular ausfüllt*.
+
+{: .note }
+> Der Formulartyp `multistep` übernahm mit seinen `steps` vor 7 den Teil der Ausführung. Er ist seit 7 veraltet und wird in
+> 8 entfernt: ein Workflow kann alles, was ein Multistep kann, siehe [Multistep-Formulare](forms/multistep.html).
+
+#### Nur Workflow
+{: .no_toc }
+
+Ein Formular mit `type: workflow` führt einen der Workflows des Designers aus. Der Benutzer füllt eine einzige Seite mit Feldern aus und drückt Senden,
+und der Workflow führt seine Knoten aus, jeden mit den Werten des Formulars als Extra-Variablen:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Nur Wizard
+{: .no_toc }
+
+Ein Block `wizard:` in einem Formular verteilt die Erfassung der Eingaben auf mehrere Seiten. Am Ende läuft nur **ein** Job: die zusammengeführten Extravars aller Seiten gehen an ein einziges Playbook, eine einzige Vorlage oder einen einzigen Workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Eine schreibgeschützte Übersichtsseite wird automatisch als letzte Seite des Wizards angehängt; Sie deklarieren sie nicht in YAML.
+
+#### Kombiniert (Wizard über einem Workflow)
+{: .no_toc }
+
+Ein Wizard lässt sich über ein Workflow-Formular legen. Der Benutzer füllt die Seiten des Wizards aus und drückt Senden, und **dann** startet der
+Workflow. Indem Sie das `defaultModel` eines Wizard-Schritts mit dem
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) eines Knotens in Übereinstimmung bringen, können Sie **eine Seite des Wizards an einen Knoten** leiten:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+Und der Workflow `provision-host`, in einer Workflow-Datei des Designers:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` ist ein Nachschlagen auf nur einer Ebene, verwenden Sie daher einen flachen Namen in `defaultModel` (zum Beispiel `defaultModel: basics`, nicht `defaultModel: input.basics`), wenn beide übereinstimmen sollen.
+
+Siehe die [Seite zum Wizard](forms/wizard.html) für die vollständige Referenz der Eigenschaften.
+
+### Wie zeige oder überspringe ich Schritte des Wizards bedingt?
+
+Verwenden Sie `when:`, um einen Schritt ganz zu **verbergen**, oder `optional: true`, damit der Benutzer einen sichtbaren Schritt **überspringen** kann. Beide sind unabhängig voneinander und sollten in der Regel nicht kombiniert werden.
+
+#### `when:`: bedingte Sichtbarkeit
+{: .no_toc }
+
+Der Schritt wird verborgen, wenn der Ausdruck einen falsy Wert ergibt. Der Benutzer sieht ihn nie, und seine Werte werden nicht erfasst. Der Ausdruck kann frühere Schritte über `__parent__.<stepname>.<field>` lesen:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Nur die Seite, die zur gewählten `kind` passt, wird gezeigt. Schritte nach einem verborgenen werden automatisch neu nummeriert.
+
+#### `optional: true`: einen sichtbaren Schritt überspringen lassen
+{: .no_toc }
+
+Der Schritt wird im Stepper **immer gezeigt**, aber der Benutzer kann **Weiter** drücken, ohne ihn auszufüllen, und **Senden** ist erlaubt, auch wenn die Seite nie besucht oder ausgefüllt wurde:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+Der Benutzer kann die Seite Advanced öffnen, sie leer lassen, Weiter drücken und direkt zur Übersichtsseite weitergehen.
+
+{: .note }
+> `when:` steuert die *Sichtbarkeit*; `optional:` steuert, *ob die Seite ausgefüllt werden muss*. Kombinieren Sie sie nicht: um eine Seite verschwinden zu lassen, verwenden Sie `when:`; um sie sichtbar, aber überspringbar zu halten, verwenden Sie `optional:`.
+
+### Wie verweise ich auf Werte aus einem früheren Schritt des Wizards?
+
+Verwenden Sie `$(__parent__.<stepname>.<field>)` in einem beliebigen Feld eines späteren Schritts.
+
+Der `name` eines Wizard-Schritts (standardmäßig der Name seines `subform`) ist der Namensraum, unter dem seine Werte späteren Schritten zur Verfügung stehen:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+Das ist derselbe `__parent__`-Mechanismus, den `list`- und `yaml`-Subforms verwenden; siehe [Wie greife ich in einem Subform auf Daten des übergeordneten Formulars zu?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Sicherheit und Anmeldedaten
+
+### Anmeldedaten
+
+Anmeldedaten übergeben.
+
+Anmeldedaten lassen sich auf mehrere Arten übergeben:
+* mit der Feldeigenschaft `asCredential`
+* mit der Formulareigenschaft `credentials` (Schlüssel-Wert-Paare)
+* mit einer Extravar namens `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Ein verlorenes Admin-Passwort wiederherstellen
+
+Wenn Sie das Passwort des lokalen Kontos `admin` verloren haben und kein anderer Admin-Benutzer verfügbar ist, verwenden Sie die Wiederherstellungsoption `REINIT_ADMIN`. **Das ist keine Umgehung der Authentifizierung zur Laufzeit**: sie erzwingt beim Start nur ein einmaliges Zurücksetzen des lokalen Admin-Kontos, danach läuft die normale Authentifizierung.
+
+**Wie es funktioniert**
+
+Wenn `REINIT_ADMIN=1` beim Start gesetzt ist, tut AnsibleForms Folgendes:
+
+1. Es stellt sicher, dass die Gruppe `admins` existiert (und legt sie an, falls sie fehlt).
+2. Es sucht den lokalen Admin-Benutzer (Standard-Benutzername `admin`, überschrieben durch `ADMIN_USERNAME`).
+3. Wenn er existiert, setzt es sein Passwort auf den Wert von `ADMIN_PASSWORD` zurück und fügt ihn wieder der Gruppe `admins` hinzu.
+4. Wenn er nicht existiert, legt es ihn an (wie bei einer Neuinstallation).
+5. Es protokolliert die Aktion deutlich sichtbar, damit sie in den Protokollen auffällt.
+
+**Schritte**
+
+1. Stoppen Sie AnsibleForms.
+2. Setzen Sie die Umgebungsvariablen (verwenden Sie ein starkes Passwort):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   In Docker Compose fügen Sie sie dem Block `environment:` des AnsibleForms-Dienstes hinzu.
+3. Starten Sie AnsibleForms und achten Sie in den Protokollen auf eine Zeile wie:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Melden Sie sich mit `admin` / `YourNewStrongPasswordHere` an.
+5. **Entfernen Sie `REINIT_ADMIN` (oder setzen Sie es wieder auf `0`)** und starten Sie neu, damit künftige Neustarts das Admin-Passwort nicht erneut zurücksetzen.
+
+**Hinweise**
+
+- Wenn Sie ausgesperrt waren, weil LDAP die einzige konfigurierte Anmeldemethode war und ausgefallen ist, fällt das wiederhergestellte lokale Konto `admin` immer auf die Authentifizierung gegen die lokale Datenbank zurück, was genügt, um sich anzumelden und LDAP zu reparieren.
+- Die frühere Umgebungsvariable `ENABLE_BYPASS` wurde entfernt. Sie erlaubte die Anmeldung als Admin mit beliebigem Passwort und war unsicher, wenn sie eingeschaltet blieb. `REINIT_ADMIN` setzt nur das Passwort zurück; danach gilt die normale Authentifizierung.
+- `REINIT_ADMIN` macht bestehende Sitzungen und Tokens nicht ungültig; nur der Passwort-Hash und die Gruppenmitgliedschaft ändern sich.
+
+### Ziele der REST-Hilfsfunktionen einschränken (Erlaubt-/Sperrlisten)
+
+Die Hilfsfunktionen `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` und `fn.fnRestJwtSecure` lassen sich aus den `expression`-Eigenschaften von Formularen aufrufen, um Daten über HTTP zu holen. Standardmäßig können Autoren von Ausdrücken **jede** URL ansprechen, die der AnsibleForms-Host erreicht, was Sie in einem sensiblen Netzwerk einschränken möchten.
+
+Zwei Umgebungsvariablen liefern eine Erlaubtliste und eine Sperrliste:
+
+| Variable | Verhalten |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Kommagetrennte Hostnamen oder CIDRs. Wenn gesetzt, sind **nur** diese Ziele erlaubt. |
+| `REST_DENIED_HOSTS` | Kommagetrennte Hostnamen oder CIDRs. Immer gesperrt. Hat Vorrang vor der Erlaubtliste. |
+
+Hostnamen werden ohne Beachtung der Groß- und Kleinschreibung mit dem Host der URL verglichen. CIDRs werden mit jeder IP verglichen, zu der der Host aufgelöst wird, daher sperrt `10.0.0.0/8` jeden DNS-Namen, der in den privaten Bereich auflöst.
+
+**Beispiele:**
+
+Die erste Zeile erlaubt nur zwei Hosts; die zweite sperrt bestimmte Ziele:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Dieser Schutz schützt nur den Node.js-Prozess von AnsibleForms.** Sobald ein Playbook läuft, kann Ansible selbst alles vom Host aus erreichen, außerhalb der Kontrolle von AnsibleForms. Verwenden Sie diese Listen, um zu verhindern, dass Formularautoren Ausdrücke in einen Proxy für Metadatendienste oder interne Oberflächen verwandeln; verlassen Sie sich nicht auf sie als Netzwerk-Firewall.
+
+Seit 7.3.0 prüfen die REST-Hilfsfunktionen das TLS-Zertifikat des Endpunkts, wie jede andere Verbindung auch, und geben nach
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) auf (standardmäßig `60`). Vertrauen Sie einer privaten CA mit
+`NODE_EXTRA_CA_CERTS`, oder setzen Sie [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) nur für Endpunkte mit einem
+selbstsignierten Zertifikat auf `1`.
+
+### Anbindung an HashiCorp Vault
+
+Anmeldedaten können ihren Benutzer und ihr Passwort aus HashiCorp Vault lesen, konfiguriert als
+**Secret Store**. Siehe [Secret Stores](secret-stores). Die `VAULT_*`-Umgebungsvariablen
+früherer Versionen werden beim ersten Start von 7.x einmalig als Store `vault` importiert.
+
+Für Secrets, die nur innerhalb eines Playbooks verwendet werden, können Sie auch das Lookup-Plugin `community.hashi_vault`
+verwenden, das direkt aus Vault liest und AnsibleForms umgeht.
+
+---
+
+## Integration
+
+### AWX/Tower/AAP abfragen
+
+Informationen aus AWX oder der Ansible Automation Platform abfragen.
+
+Um Auswahllisten mit Daten aus AWX oder Tower zu füllen, verwenden Sie `fn.fnRestBasic` oder `fn.fnRestJwtSecure`. Seit 7.3.0 prüfen diese Hilfsfunktionen
+das Zertifikat der AWX-Adresse: bei einem selbstsignierten vertrauen Sie seiner CA mit `NODE_EXTRA_CA_CERTS`, oder setzen Sie
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) auf `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Anpassung
+
+### Anpassung
+
+AnsibleForms anpassen.
+
+AnsibleForms ist eine Webanwendung. Wenn Sie es nativ in Node.js betreiben, können Sie seine Dateien ersetzen oder ändern.
+Empfohlen ist jedoch, es als Docker-Image zu betreiben und Volume- oder Datei-Mappings hinzuzufügen. Die Docker-Compose-Projekte mappen bereits Verzeichnisse, damit Datenbank, Playbooks, Protokolle, Zertifikate und SSH-Schlüssel persistent bleiben, und Sie können weitere Mappings hinzufügen. Ein eigenes Logo wird auf der Einstellungsseite **Logo** hochgeladen.
+Die Datei `custom.js` enthält Ihre eigenen JavaScript-Funktionen zur Verwendung in Ausdrücken. Die eingebauten Funktionen verwenden das Präfix `fn.` (zum Beispiel fn.fnRestBasic); eigene Funktionen verwenden das Präfix `fnc.`.
+Auf dieselbe Weise können Sie eigene jq-Definitionen in der Datei `jq.custom.definitions` hinzufügen.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### YTT aktivieren
+
+ytt aktivieren.
+
+Um ytt zu verwenden, setzen Sie `USE_YTT=1`.
+Mehr Informationen über ytt finden Sie unter https://carvel.dev/ytt/.
+
+{: .important }
+> Diese Funktion wurde nicht umfassend getestet, und seit sie als Erweiterung hinzugefügt wurde, kam keine Rückmeldung dazu.
+> Wenn Sie ytt verwenden, müssen Sie den Designer deaktivieren: der Designer wandelt die YAML-Dateien in zwischengeschaltetes JSON um und verwirft dabei die ytt-Syntax (die aus YAML-Kommentaren besteht).
+
+Im Wurzelverzeichnis muss ein Verzeichnis `lib` existieren; es wird automatisch in den ytt-Aufruf einbezogen.
+Daten lassen sich global bereitstellen, indem man Umgebungsvariablen mit Präfix setzt:
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Alternativ stellen Sie Bibliotheks-Datendateien bereit:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**Die Bibliothek `demo` muss im ytt-Kontext existieren (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+Die geladenen Daten lassen sich dann verwenden:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Zugriffskontrolle
+
+### Wie schränke ich ein, was Benutzer tun können (Rollenoptionen)?
+
+Über die Einschränkung hinaus, welche Formulare eine Rolle sehen kann, schalten die `options` einer Rolle Funktionen der Oberfläche für ihre Mitglieder ein oder aus.
+Siehe [Rollenoptionen](config/roles.html#role-options) für jede Option, ihren Standard und wie sich Optionen über Rollen hinweg kombinieren.
+
+### Wie setze ich eigene RBAC-Logik in meinen Playbooks oder Formularen um?
+
+Die Identität des Benutzers steht bei jeder Ausführung sowohl im Frontend als auch im Backend zur Verfügung.
+
+Bei jeder Übermittlung eines Formulars fügt AnsibleForms automatisch die vollständige Identität des aktuellen Benutzers in die Extravars ein, die an Ansible gesendet werden:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+Ihr Playbook oder jedes eigene Ansible-Modul kann daher `ansibleforms_user` direkt für feingranulare Entscheidungen verwenden, zum Beispiel um nur bestimmten Gruppen das Ändern des Produktionsinventars zu erlauben oder um einen Audit-Trail mit dem Benutzernamen des Absenders zu schreiben.
+
+Im **Frontend** steht dasselbe Objekt über das spezielle Feld `__user__` zur Verfügung:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Typische Muster:**
+
+Die Benutzeridentität unterstützt Muster wie die folgenden:
+
+- **Abgleich mit einer RBAC-Konfigurationsdatei oder -Datenbank**: laden Sie eine YAML- oder JSON-Datei (mit `fn.fnReadYamlFile` oder einem Ausdruck), die Gruppen auf erlaubte Ressourcen abbildet, und filtern Sie dann nach `$(__user__.groups)`
+- **Audit-Trail**: übergeben Sie `ansibleforms_user.username` als Extra-Variable, um festzuhalten, wer den Job ausgelöst hat
+- **Dynamische Feldwerte**: zeigen Sie eine andere Menge von Enum-Auswahlen, füllen Sie Felder vor oder verbergen Sie Abschnitte abhängig von den Gruppen oder Rollen des Benutzers
+- **Autorisierung im Playbook**: stellen Sie sicher, dass `ansibleforms_user.groups` eine erforderliche Gruppe enthält, bevor das Playbook fortfährt, als zusätzliche Prüfung unabhängig von der `roles`-Liste des Formulars
+
+{: .note }
+> Das obige Objekt wird standardmäßig gesendet. Wenn die Instanz `EXTRAVARS_USER_FIELDS` setzt
+> oder das Formular `userExtravars` setzt, werden nur die dort genannten Schlüssel gesendet, daher braucht ein Playbook, das
+> auf `ansibleforms_user.groups` prüft, `groups` unter diesen Schlüsseln. Das Feld `__user__` im Frontend
+> kommt aus dem Login-Token und wird von keiner der beiden Einstellungen gekürzt.
+
+---
+
+## Job-Zeitplanung
+
+### Wie plane ich ein Formular so ein, dass es automatisch läuft?
+
+Öffnen Sie die Auswahl neben **Senden** und wählen Sie **Planen (wiederkehrend)** oder **Später ausführen (einmalig)**; sie erfordern die Rollen-
+optionen `allowScheduledJobs` (Admin-Ebene) und `allowPlannedJobs`. Siehe [Zeitpläne](jobs/schedules.html).
+
+### Welche Cron-Ausdrücke kann ich verwenden?
+
+Ein wiederkehrender Zeitplan nimmt einen Standard-Cron-Ausdruck mit 5 Feldern (Minute, Stunde, Tag des Monats, Monat, Wochentag).
+
+| Ausdruck | Läuft |
+|---|---|
+| `*/15 * * * *` | Alle 15 Minuten |
+| `0 * * * *` | Jede Stunde, zur vollen Stunde |
+| `0 */6 * * *` | Alle 6 Stunden, um 00:00, 06:00, 12:00 und 18:00 |
+| `0 2 * * *` | Jeden Tag um 02:00 |
+| `30 7 * * 1-5` | Montag bis Freitag um 07:30 |
+| `0 8 * * MON` | Jeden Montag um 08:00 (Tages- und Monatsnamen werden akzeptiert) |
+| `0 0 1 * *` | Um Mitternacht am ersten Tag jedes Monats |
+| `0 22 L * *` | Um 22:00 am letzten Tag jedes Monats |
+| `0 6 * * 1#1` | Um 06:00 am ersten Montag jedes Monats |
+| `*/30 * * * * *` | Alle 30 Sekunden (ein optionales sechstes Feld vorn ist die Sekunde) |
+
+Wenn sowohl der Tag des Monats als auch der Wochentag gesetzt sind, läuft der Zeitplan, sobald eines davon passt: `0 0 13 * 5` läuft am 13.
+und an jedem Freitag. Der Server lehnt einen Ausdruck ab, den er nicht ausführen kann, oder einen, der nie eintreten kann (`0 0 30 2 *`).
+
+Auf der Seite **Zeitpläne** beschreibt der Cron-Editor den Ausdruck und zeigt eine Vorschau seiner nächsten Läufe. Er akzeptiert keine Kurznamen
+wie `@daily`, keinen Platzhalter `?` und keinen Modifikator `W` (nächster Werktag), halten Sie sich daher an die Formen in der Tabelle.
+
+{: .note }
+> **Zeitzone** Cron-Zeitpläne laufen in der Zeitzone des Servers, gesetzt mit [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (Standard `UTC`), nicht in der Zeitzone Ihres Profils oder Ihres Browsers. `0 2 * * *` mit `LOG_TZ=Europe/Madrid` läuft das ganze Jahr um 02:00
+> Madrider Zeit und folgt dabei der Sommerzeit. Der Cron-Editor zeigt die Vorschau der nächsten Läufe in derselben Zone. Pull-Zeitpläne für Repositories
+> verwenden dieselbe Zone.
+
+---
+
+## Formulardaten speichern und laden
+
+### Wie speichere und lade ich Formulardaten, ohne einen Job auszuführen?
+
+Wählen Sie **Speichern** in der Auswahl neben **Senden**, um die Feldwerte zu speichern, und später **Aus Speicher laden**, um sie wiederherzustellen.
+Passwortfelder werden nie gespeichert. Das erfordert die Rollenoption `allowStoredJobs`. Siehe [Gespeicherte Jobs](jobs/stored-jobs.html).
+
+---
+
+## Verschachtelte Formulare und strukturierte Felder
+
+### Wie erfasse ich strukturierte oder wiederholte Daten in einem Formular?
+
+Verwenden Sie `list`- und `yaml`-Felder mit Subforms (6.2.0+).
+
+Um komplexe strukturierte Daten zu erfassen, etwa eine Liste von Servern, eine Menge von Netzwerkschnittstellen oder ein einzelnes verschachteltes Objekt, verwenden Sie den Feldtyp `list` oder `yaml` zusammen mit einem `subform`.
+
+Ein **Subform** ist ein wiederverwendbares Formularfragment (definiert mit `type: subform`), das nie als eigenständige Kachel gezeigt wird. Es existiert nur, um von Feldern in anderen Formularen referenziert zu werden. Siehe die [Dokumentation zu Subforms](forms/subform.html) für die vollständige Referenz.
+
+**Eine Liste strukturierter Zeilen erfassen: Feld `list`:**
+
+Ein Feld `list` öffnet das referenzierte Subform einmal pro Zeile:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+Die Extravar `servers`, die an Ansible gesendet wird, ist ein Array von Objekten: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Ein einzelnes strukturiertes Objekt bearbeiten: Feld `yaml`:**
+
+Das Feld `yaml` hat drei Modi:
+
+| Modus | Wie | Verhalten |
+|---|---|---|
+| **Editor** | Standard | Zeigt einen vollständigen YAML-Editor mit Syntaxhervorhebung, in den der Benutzer direkt tippen kann |
+| **Schreibgeschützt** | `readonly: true` | Stellt den YAML-Wert als formatierten, schreibgeschützten Text dar, ohne Bearbeitung |
+| **Subform** | `subform: MySubform` | Verbirgt den rohen Editor; öffnet das Subform beim Klick als Drilldown-Editor |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Hoch- und Herunterladen: Felder `list` und `yaml`:**
+
+Beide Feldtypen unterstützen clientseitige Dateiübertragung über zwei optionale Eigenschaften:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> Das Feld `list` und der Formulartyp `subform` haben das Feld `table` und `tableFields` ersetzt, die in 7.0.0 entfernt wurden.
+
+### Wie greife ich in einem Subform auf Daten des übergeordneten Formulars zu?
+
+Auf Feldwerte des übergeordneten Formulars aus einem Subform heraus über `__parent__` verweisen (v6.3.0+).
+
+Wenn sich ein Subform öffnet, ob aus einem Feld **`list`** (jeder Zeileneditor) oder einem Feld **`yaml`** im Subform-Modus, fügt AnsibleForms automatisch ein spezielles schreibgeschütztes Feld namens `__parent__` in das Subform ein. Es enthält eine Momentaufnahme **jedes Feldwerts des übergeordneten Formulars zum Zeitpunkt, als das Subform geöffnet wurde**, einschließlich Konstanten und Vars.
+
+So können Subform-Felder Ausdrücke verwenden, die auf Daten des übergeordneten Formulars verweisen, ohne zusätzliche Konfiguration.
+
+#### Was steht in `__parent__`?
+{: .no_toc }
+
+`__parent__` ist ein einfaches Objekt, dessen Schlüssel die Feldnamen des übergeordneten Formulars sind:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` wird **nicht an Ansible gesendet**; wie `__user__` wird es aus den Extravars entfernt. Es ist eine reine Frontend-Hilfe für Ausdrücke in Subforms.
+
+#### Auf Werte des übergeordneten Formulars in Subform-Ausdrücken zugreifen
+{: .no_toc }
+
+Verweisen Sie mit der üblichen Ausdruckssyntax `$(...)` auf Werte des übergeordneten Formulars:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Verschachtelte Subforms
+{: .no_toc }
+
+`__parent__` verweist immer auf das **unmittelbar übergeordnete** Formular. Wenn Sie eine `list` in ein Subform verschachteln, das selbst aus einem übergeordneten Formular geöffnet wird, enthält das `__parent__` des inneren Subforms die Daten des mittleren Subforms. Um weitere Ebenen zu erreichen, verketten Sie Verweise wie `$(__parent__.__parent__.someField)`, sofern das mittlere Subform sein eigenes `__parent__` ebenfalls weitergibt.
+
+### Wie migriere ich von `table` / `tableFields` zu `list` / `subform`?
+
+Das Feld `table` und die Eigenschaft `tableFields` wurden in 6.2.0 als veraltet markiert und in 7.0.0 entfernt, und ein Formular, das sie noch verwendet, besteht die Validierung nicht. So migrieren Sie:
+
+1. Übernehmen Sie die Spalten aus `tableFields` in ein neues Formular mit `type: subform` und regulären `formfields`
+2. Ersetzen Sie das Feld `table` durch ein Feld `list`, das über `subform: MySubformName` auf das Subform verweist
+
+**Vorher:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Nachher:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### `from` in `tableFields` zu `__parent__`-Ausdrücken migrieren
+{: .no_toc }
+
+Die Eigenschaft `from` von Enum-Spalten in `tableFields` füllte die Auswahlmöglichkeiten aus einem anderen Feld des übergeordneten Formulars. In einem `subform` wird sie durch eine `expression` ersetzt, die denselben Wert über `__parent__` liest.
+
+**Vorher: `tableFields` mit `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Nachher: Subform mit `__parent__`-Ausdruck:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` gibt den **aktuellen Wert** dieses Felds zurück; ist dieses Feld selbst ein dynamisches Ausdrucksfeld, sieht das Subform daher immer das zuletzt ausgewertete Ergebnis aus dem übergeordneten Formular.
+
diff --git a/i18n/de/_reference/getting-help.md b/i18n/de/_reference/getting-help.md
new file mode 100644
index 0000000..eb6257b
--- /dev/null
+++ b/i18n/de/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Hilfe erhalten
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Hilfe erhalten
+{: .no_toc }
+
+Wo Sie eine Frage stellen, einen Fehler oder ein Sicherheitsproblem melden und eine Verbesserung vorschlagen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Bevor Sie fragen
+
+Die meisten Antworten sind bereits aufgeschrieben; ein kurzer Blick erspart oft eine Rückfrage:
+
+1. Durchsuchen Sie diese Website mit dem Suchfeld oben auf jeder Seite.
+2. Schlagen Sie die genaue Fehlermeldung unter [Fehlerbehebung](troubleshooting.html) nach und überfliegen Sie die [FAQ](faq.html).
+3. Prüfen Sie das Serverprotokoll (**Einstellungen**, dann **Serverprotokoll**) und die Seite **Status**, die die meisten Konfigurationsprobleme melden.
+4. Prüfen Sie das [Changelog](changelog.html): das Problem ist vielleicht in einer neueren Version bereits behoben.
+
+---
+
+## Wohin Sie sich wenden
+
+Jede Art von Anliegen hat ihren eigenen Ort, alle auf GitHub:
+
+| Sie möchten | Gehen Sie zu |
+|---|---|
+| Eine Frage stellen oder eine Idee teilen | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Einen Fehler melden | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Eine Funktion vorschlagen | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Ein Sicherheitsproblem melden | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), vertraulich |
+| Diese Dokumentation korrigieren oder verbessern | **Edit this page on GitHub** unten auf jeder Seite, oder ein [Issue zur Website](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Einen Fehler melden
+
+Ein Bericht, der sich reproduzieren lässt, wird am schnellsten behoben. Die Vorlage für Fehlerberichte fragt nach Folgendem:
+
+* **Version** : angezeigt unter **Info** im Hilfemenü (**?**) der oberen Leiste
+* **Bereitstellung** : Docker, Docker Compose, Kubernetes, der Installer (und seine Engine), eine native Installation oder aus dem Quellcode
+* **Schritte zur Reproduktion** : was Sie getan haben, was Sie erwartet haben und was stattdessen passiert ist
+* **Belege** : die relevanten Zeilen des Serverprotokolls und ein Screenshot, wenn das Problem sichtbar ist
+
+Bei einem Problem mit einem Formular fügen Sie eine minimale Formulardefinition bei, die es zeigt. Entfernen Sie Passwörter, Tokens, Hostnamen und alle
+anderen privaten Daten aus Protokollen und Formularen, bevor Sie sie veröffentlichen: Issues und Discussions sind öffentlich.
+
+---
+
+## Ein Sicherheitsproblem melden
+
+**Eröffnen Sie dafür nie ein öffentliches Issue:** verwenden Sie [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), das nur die Maintainer sehen.
+
+Die [Sicherheitsrichtlinie](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) listet die unterstützten Versionen auf und
+beschreibt, was nach Ihrer Meldung passiert.
diff --git a/i18n/de/_reference/troubleshooting.md b/i18n/de/_reference/troubleshooting.md
new file mode 100644
index 0000000..55b6178
--- /dev/null
+++ b/i18n/de/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Fehlerbehebung
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Fehlerbehebung
+{: .no_toc }
+
+Fehlermeldungen und Symptome, warum sie auftreten und wie Sie sie beheben
+{: .fs-6 .fw-300 }
+
+---
+
+Jedes der folgenden Probleme ist mit der Meldung oder dem Symptom überschrieben, das Sie sehen, gefolgt von der Ursache und der Lösung. Meldungen sind
+genau so zitiert, wie AnsibleForms sie schreibt; `<name>` steht für einen Wert, der sich von Fall zu Fall unterscheidet. Die meisten landen im
+Serverprotokoll, das Sie unter [Serverprotokoll](gui/administration.html#server-log) oder mit `docker logs` lesen können.
+
+**Datenbank und Start**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Konfiguration und Formulare**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [Die Basiskonfiguration hat einen Abschnitt forms](#the-base-config-has-a-forms-section)
+* [Ein Formular fehlt im Dashboard](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Anmeldung**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Die Authentifizierung über Azure AD oder OIDC schlägt fehl](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Abgemeldet nach einem Neustart oder nach einem Tag](#logged-out-after-a-restart-or-after-a-day)
+* [Leere Formulare und Jobs nach einem Single Sign-On (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Jobs**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Ein Job zeigt den Status abandoned](#a-job-shows-the-status-abandoned)
+* [Eine RTE verbindet sich nicht](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Git-Repositories und Backups**
+
+* [Klonen oder Pull eines Repositorys schlägt fehl](#a-repository-clone-or-pull-failed)
+* [Das Formular-Repository ist noch nicht geklont](#the-forms-repository-is-not-cloned-yet)
+* [Ein Backup schlägt fehl](#a-backup-failed)
+
+Die [FAQ](faq.html) behandelt zwei verwandte Probleme ausführlich: ein
+[verlorenes Admin-Passwort](faq.html#recovering-a-lost-admin-password) und das
+[Einschränken der Ziele von REST-Hilfsfunktionen](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms startet nicht, und das Protokoll wiederholt diese Zeilen alle 5 Sekunden:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Warum das passiert**
+
+Beim Start wartet AnsibleForms, bis die Datenbank eine Abfrage beantwortet, und wartet so lange weiter, wie sie das nicht tut.
+`<reason>` ist die eigene Meldung des Datenbanktreibers: eine abgelehnte oder abgelaufene Verbindung deutet auf den Host oder den Port,
+eine Meldung über verweigerten Zugriff auf den Benutzernamen oder das Passwort.
+
+**Wie Sie es beheben**
+
+Prüfen Sie [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) und [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Innerhalb eines Containers ist `localhost` der Container selbst, nicht der Host, auf dem MySQL läuft. Stellen Sie sicher, dass MySQL
+auf einer Netzwerkadresse lauscht und dass sich der Benutzer vom AnsibleForms-Host aus verbinden darf. AnsibleForms macht von selbst weiter, sobald
+die Datenbank antwortet; ein Neustart ist nicht nötig.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+Der Browser öffnet statt der Anmeldeseite eine Datenbankseite, und das Protokoll zeigt:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Warum das passiert**
+
+Das Schema `AnsibleForms` fehlt oder ist unvollständig. Eine *leere* Datenbank wird beim Start automatisch eingerichtet, sofern
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) nicht `0` ist. Scheitert das, zum Beispiel weil
+der Datenbankbenutzer kein Schema anlegen darf, meldet das Protokoll `Failed to create the schema automatically : <reason>`. Ein Schema,
+das existiert, aber dem Tabellen fehlen (`Table '<name>' is not present`), wird nie automatisch neu angelegt, denn das Anlegen des
+Schemas löscht zuerst jede Tabelle. Die Datenbankseite sagt dann *It appears that you have an unuseable schema*.
+
+**Wie Sie es beheben**
+
+Geben Sie bei einer Neuinstallation dem Datenbankbenutzer das Recht, das Schema `AnsibleForms` anzulegen, und starten Sie neu, oder drücken Sie
+**Erstellen** auf der Datenbankseite. Bei einem nur teilweise vorhandenen Schema stellen Sie ein Backup wieder her oder entfernen das unvollständige Schema
+`AnsibleForms`, damit AnsibleForms es neu anlegen kann. Das Protokoll listet auf, welche Tabellen und Patches fehlgeschlagen sind.
+
+---
+
+## Schema creation is disabled
+
+Das Anlegen des Schemas, über die Datenbankseite oder mit `POST /api/v2/schema`, schlägt fehl mit:
+
+```
+Schema creation is disabled
+```
+
+**Warum das passiert**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) ist `0`, was sowohl das automatische
+Anlegen beim Start als auch den Endpunkt abschaltet. Auf einer Datenbank, die bereits Benutzer hat, lehnt der Endpunkt außerdem Aufrufer ab, die nicht
+als Administrator angemeldet sind, mit `Schema creation requires an authenticated administrator`.
+
+**Wie Sie es beheben**
+
+Legen Sie das Schema einmal mit `ALLOW_SCHEMA_CREATION=1` an (das ist der Standard) oder stellen Sie es aus einem Backup wieder her, und setzen Sie die
+Variable dann wieder auf `0`. Melden Sie sich auf einer eingerichteten Datenbank als Administrator an, bevor Sie das Schema neu anlegen, und denken Sie daran,
+dass dabei jede Tabelle gelöscht und neu angelegt wird.
+
+---
+
+## Config seed failed, refusing to start
+
+Der Container beendet sich direkt nach dem Start, und seine Ausgabe endet mit:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Warum das passiert**
+
+Die Datei in [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) ließ sich nicht anwenden: sie ist zum Beispiel kein gültiges
+YAML oder verletzt das Seed-Schema; `<reason>` sagt, was schiefgelaufen ist. AnsibleForms verweigert lieber den Start, als
+mit der Hälfte seiner deklarierten Objekte zu laufen. Der Grund wird auch auf die Standardfehlerausgabe geschrieben, daher zeigen ihn `docker logs` und `kubectl logs`.
+
+**Wie Sie es beheben**
+
+Korrigieren Sie, was `<reason>` nennt, und starten Sie erneut. Siehe [Neu laden und Start](seed/reloading.html) dazu, wie der Seed
+angewendet wird, und [Beispiel](seed/example.html) für eine gültige Datei.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Jeder Start protokolliert diese Warnung:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Oder der Worker verweigert den Start mit:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Warum das passiert**
+
+Gespeicherte Secrets werden mit [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET) verschlüsselt: seit 7.3.0 liegen sie in
+Anmeldedaten (unter anderem die Passwörter und Tokens von LDAP-Verzeichnissen, SSO-Anbietern, Runnern und Secret Stores), neben den Adressen der Slack-
+und Teams-Webhooks. Ohne es wird ein Schlüssel verwendet, der im Quellcode öffentlich ist. Seit 7.3.0 verschlüsselt ein Start mit einem neuen
+`ENCRYPTION_SECRET` jedes gespeicherte Secret damit neu, in einer Transaktion: vom Standardschlüssel, wenn es zum ersten Mal gesetzt wird,
+oder von [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS), wenn es sich ändert. Wenn die
+gespeicherten Secrets mit keinem von beiden verschlüsselt wurden, wird nichts geändert, und AnsibleForms startet nicht.
+
+**Wie Sie es beheben**
+
+Setzen Sie `ENCRYPTION_SECRET` und bewahren Sie es bei Ihren anderen Secrets auf: Backups enthalten es nie. Der nächste Start protokolliert
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Um es später zu ändern, setzen Sie für einen Start den neuen Wert in
+`ENCRYPTION_SECRET` und den alten in `ENCRYPTION_SECRET_PREVIOUS` und entfernen Sie dann `ENCRYPTION_SECRET_PREVIOUS`. Wenn der
+Worker den Start verweigert, setzen Sie `ENCRYPTION_SECRET_PREVIOUS` auf den Schlüssel, mit dem die Secrets verschlüsselt wurden, oder setzen Sie den alten Wert zurück.
+
+---
+
+## Could not load the forms
+
+Das Dashboard zeigt keine Formulare und meldet:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Warum das passiert**
+
+Die Basiskonfiguration (`config.yaml`) ließ sich nicht lesen oder ist nicht gültig. `<reason>` sagt, was davon:
+
+| Grund | Ursache |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Ein YAML-Syntaxfehler |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Eine leere Datei oder eine mit nur Kommentaren |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | Dieselbe Rolle ist zweimal definiert |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` fehlt, und ihr Ordner ist nicht beschreibbar |
+| `There is no forms directory nor could there be one created from template.` | Der Formularordner fehlt und lässt sich nicht anlegen |
+| Jede andere Zeile | Die Konfiguration verletzt das Schema, zum Beispiel eine Rolle ohne `groups` |
+
+**Wie Sie es beheben**
+
+Korrigieren Sie die Datei, die [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) nennt, oder die `config.yaml` im
+Repository, das für die Konfiguration verwendet wird. Wenn Dateien fehlen, lassen Sie [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) und
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) auf einen beschreibbaren, persistenten Ort zeigen. Siehe
+[config.yaml](config/) für die Struktur.
+
+---
+
+## Die Basiskonfiguration hat einen Abschnitt forms
+
+Nach einer Aktualisierung von 6.x ist das Dashboard leer, und der Warnungsbereich zeigt:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Warum das passiert**
+
+Seit 7.0.0 liegt jedes Formular in einer eigenen Datei im Formularordner. Formulare, die noch in `config.yaml` aufgeführt sind, werden
+ignoriert.
+
+**Wie Sie es beheben**
+
+Verschieben Sie jedes Formular in eine eigene Datei in [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Siehe
+[Auf 7.x aktualisieren](upgrade-7.html).
+
+---
+
+## Ein Formular fehlt im Dashboard
+
+Eine Formulardatei existiert, aber ein Benutzer sieht das Formular nicht im Dashboard.
+
+**Warum das passiert**
+
+Ein Benutzer sieht ein Formular nur, wenn eine der `roles` des Formulars eine seiner Rollen ist; Admins sehen jedes Formular. Jeder Benutzer hat
+die Rolle `default`, daher ist ein Formular mit `roles: [default]` für alle sichtbar. Die Rollen eines Benutzers kommen aus den Gruppen und Benutzern,
+die unter `roles` in `config.yaml` aufgeführt sind. Ein Formular ohne `categories` erscheint unter **Default**, fehlt also in den
+anderen Kategorien, ist aber weiterhin unter **Alle Formulare** aufgeführt. Schließlich wird ein Formular, das die Validierung nicht besteht, übersprungen. Das
+Dashboard zeigt dann eine Schaltfläche **Diese Konfiguration hat Warnungen oder Fehler**, die Meldungen wie diese öffnet:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Wie Sie es beheben**
+
+Öffnen Sie den Warnungsbereich und korrigieren Sie, was er auflistet. Prüfen Sie die Rollen des Benutzers unter
+[Berechtigungen](profile/permissions.html) im Profil sowie die `roles` und `categories` des Formulars. Siehe
+[Rollen](config/roles.html) und [Kategorien](config/categories.html). Wenn zwei Dateien denselben Formularnamen definieren,
+gewinnt die zuerst geladene.
+
+---
+
+## Could not save the forms
+
+Das Speichern im Designer schlägt fehl mit:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Warum das passiert**
+
+Der Designer validiert jedes Formular gegen das Schema, bevor er irgendetwas schreibt. Jede Zeile von `<messages>` nennt das
+Formular und das Feld, die eine Regel verletzen. Für in 7.0.0 entfernte Optionen gibt es eine eigene Meldung, zum Beispiel
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Wie Sie es beheben**
+
+Korrigieren Sie die Felder, die die Meldungen nennen. Für Optionen, die 7.0.0 entfernt hat, folgen Sie [Auf 7.x aktualisieren](upgrade-7.html).
+Um Formulardateien zu validieren, bevor sie AnsibleForms erreichen, siehe
+[VS-Code-Validierung für Formulardateien](faq.html#vs-code-validation-for-form-files) in der FAQ.
+
+---
+
+## The editor is read-only
+
+Der Designer zeigt **Gesperrt** mit dem Namen eines anderen Benutzers, und das Speichern schlägt fehl mit:
+
+```
+The editor is read-only
+```
+
+**Warum das passiert**
+
+Nur eine Person gleichzeitig kann die Formulare bearbeiten. Die Sperre wird gesetzt, wenn jemand den Designer startet, und bleibt bestehen, bis
+er ihn stoppt, auch wenn er den Browser geschlossen hat, ohne ihn zu stoppen. Die API lehnt ein Speichern durch jemand anderen mit
+`Designer is locked by <username>` ab.
+
+**Wie Sie es beheben**
+
+Bitten Sie `<username>`, den Designer zu stoppen. Wenn das nicht möglich ist, verwenden Sie **Force Unlock** im Designer. Wer die
+Sperre hält, verliert die Änderungen, die er noch nicht gespeichert hat.
+
+---
+
+## Abuse attempt of eval function
+
+Ein Ausdrucksfeld zeigt einen Fehler, und das Protokoll hat eine Zeile wie:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Warum das passiert**
+
+Serverseitige Ausdrücke werden geprüft, bevor sie laufen. Sie dürfen nur `fn.`- und `fnc.`-Funktionen aufrufen; mehrere Anweisungen,
+mehrere Zeilen, Template-Literale, `process.env` und Wörter wie `require` oder `constructor` werden abgelehnt. Die Meldung
+sagt, welche Regel verletzt wurde. Mit [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) auf
+`off` schlägt jeder Server-Ausdruck fehl mit
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Wie Sie es beheben**
+
+Schreiben Sie den Ausdruck als einen einzigen `fn.`-Aufruf oder eine einfache Operation um, oder führen Sie ihn mit `runLocal: true` im Browser aus. Siehe
+[Ausdrücke](expressions/) und [Lokale Ausdrücke](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Ein Feld, das eine REST-API aufruft, bleibt leer, und das Protokoll zeigt:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Warum das passiert**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) ist gesetzt, und der Host der URL steht nicht darin.
+Ein Host, der zu [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) passt, wird mit
+`blocked by REST_DENIED_HOSTS entry "<entry>"` abgelehnt, und ein Host, der sich nicht auflösen lässt, mit `cannot resolve <host>`.
+
+**Wie Sie es beheben**
+
+Fügen Sie den Hostnamen oder ein CIDR, das seine Adressen abdeckt, zu `REST_ALLOWED_HOSTS` hinzu, oder entfernen Sie den Eintrag, der ihn sperrt, aus
+`REST_DENIED_HOSTS`. Siehe [Ziele der REST-Hilfsfunktionen einschränken](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+Die Anmeldeseite lehnt einen Benutzernamen und ein Passwort ab mit:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Warum das passiert**
+
+Die Anmeldeseite gibt bei jedem Fehlschlag dieselbe Antwort, damit sie nicht verrät, ob ein Benutzer existiert. AnsibleForms
+versucht zuerst die lokalen Benutzer und danach LDAP: bei mehreren Verzeichnissen wird ein Benutzername in deren Reihenfolge unter **Zugriff > LDAP** gesucht,
+sofern er kein Verzeichnis (`corp\jane`) oder eine seiner Anmeldedomänen (`jane@corp.example`) nennt. Der echte Grund geht ins Protokoll. LDAP-
+Fehlschläge werden als `Error connecting to ldap: <reason>` protokolliert, mit Gründen wie `Wrong binding credentials` oder
+`Unable to verify the certificate`; Active-Directory-Codes werden übersetzt in `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` oder `Password expired`.
+
+**Wie Sie es beheben**
+
+Lesen Sie den Grund im Protokoll. Für den vollständigen Grund jeder fehlgeschlagenen Anmeldung setzen Sie
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) auf `debug`, das `Ldap authentication failed: <reason>` protokolliert.
+Wenn das lokale Admin-Passwort verloren ist, siehe [Ein verlorenes Admin-Passwort wiederherstellen](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Der Test eines LDAP-Verzeichnisses unter **Zugriff > LDAP** schlägt mit einer dieser Meldungen fehl:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Warum das passiert**
+
+Der Bind-Benutzer oder sein Passwort ist falsch, der Server oder Port ist nicht erreichbar, oder, mit TLS, das Zertifikat des Servers lässt sich nicht
+gegen das CA-Bundle prüfen. Seit 7.3.0 liegen diese Angaben in den LDAP-Anmeldedaten des Verzeichnisses, unter **Verbindungen > Anmeldedaten**. Ein Testbenutzer, der nicht existiert,
+zählt dennoch als erfolgreicher Test, weil Verbindung und Bind funktioniert haben.
+
+**Wie Sie es beheben**
+
+Öffnen Sie die Anmeldedaten, die das Verzeichnis nennt (das Standardverzeichnis ist `main`), unter **Verbindungen > Anmeldedaten** und korrigieren Sie den Bind-
+DN und sein Passwort, die Server und den Port (meist 389, oder 636 für LDAPS). Bei TLS-Problemen fügen Sie das CA-Bundle ein, das das Zertifikat des
+LDAP-Servers signiert hat; das Überspringen der Zertifikatsprüfung ist nichts für die Produktion. Siehe [LDAP](authentication/ldap.html).
+
+---
+
+## Die Authentifizierung über Azure AD oder OIDC schlägt fehl
+
+Eine Single-Sign-On-Anmeldung kehrt zur Anmeldeseite zurück mit:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Warum das passiert**
+
+Der Identitätsanbieter hat den Benutzer zurückgeschickt, aber AnsibleForms konnte die Anmeldung nicht abschließen. Häufige Gründe sind
+`azuread login is not enabled` oder `oidc login is not enabled` (der Anbieter ist ausgeschaltet) und `jwt expired`, weil
+die Übergabe vom Anbieter nur 5 Minuten gültig ist. Ein Fehler beim Callback vom Anbieter wird ebenfalls auf der Anmeldeseite
+angezeigt und protokolliert.
+
+**Wie Sie es beheben**
+
+Aktivieren Sie den Anbieter unter **Zugriff > SSO** und registrieren Sie die Callback-URL beim Identitätsanbieter genau so, wie
+AnsibleForms sie verwendet: `https://<your host>/api/v2/auth/entraid/callback` für Entra ID (ab 7.3.0; `azureadoauth2` funktioniert weiterhin) oder
+`https://<your host>/api/v2/auth/oidc/callback` für OIDC. Eine Callback-URL mit `/api/v1/`, aus der Zeit vor 7 oder vor
+6.1.5, muss aktualisiert werden: die Anmeldeseite lädt dann neu, ohne anzumelden und ohne Fehler. Versuchen Sie die Anmeldung nach
+einer abgelaufenen Übergabe erneut.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Ein Benutzer mit gültigem Passwort kann sich nicht anmelden und erhält:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Warum das passiert**
+
+Eine der Rollen des Benutzers setzt die Rollenoption `allowLogin` auf `false`. Das Protokoll sagt
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Wie Sie es beheben**
+
+Entfernen Sie `allowLogin: false` aus der Rolle oder nehmen Sie den Benutzer aus dieser Rolle heraus. Siehe [Rollen](config/roles.html).
+
+---
+
+## Abgemeldet nach einem Neustart oder nach einem Tag
+
+Jeder Benutzer wird nach einem Neustart von AnsibleForms oder nach einem Tag Nutzung zur Anmeldeseite zurückgeschickt.
+
+**Warum das passiert**
+
+Wenn [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) nicht gesetzt ist, erzeugt jeder Start einen
+neuen Signaturschlüssel und protokolliert
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Tokens aus der Zeit vor dem
+Neustart werden dann nicht mehr akzeptiert. Unabhängig davon endet eine Sitzung, wenn ihr Refresh Token abläuft
+(`Refresh token is expired`), nach
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), standardmäßig 24 Stunden.
+
+**Wie Sie es beheben**
+
+Setzen Sie `ACCESS_TOKEN_SECRET` auf einen festen, geheimen Wert. Erhöhen Sie `ACCESS_TOKEN_REFRESH_EXPIRATION`, wenn ein Tag zu kurz ist. Für
+langlebigen API-Zugriff verwenden Sie ein [API-Token](profile/api-token.html).
+
+---
+
+## Leere Formulare und Jobs nach einem Single Sign-On (HTTP 431)
+
+Ein Benutzer meldet sich ohne Fehler mit Entra ID oder OIDC an, aber die Seiten Formulare und Jobs bleiben leer. Der Netzwerk-Tab
+des Browsers zeigt die API-Aufrufe beantwortet mit:
+
+```
+431 Request Header Fields Too Large
+```
+
+Das Serverprotokoll zeigt für diese Aufrufe nichts, und derselbe Benutzer kann mit einem LDAP- oder lokalen Konto problemlos arbeiten.
+
+**Warum das passiert**
+
+Vor 7.1.0 trug das Anmelde-Token jede Gruppe des Benutzers, und Entra-ID-Gruppen standen doppelt darin, mit Objekt-ID
+und mit Namen. Der Browser sendet dieses Token im Header `Authorization` jeder Anfrage, daher kommt ein Benutzer in etwa hundert
+Gruppen oder mehr auf einen Header von weit über 16 KB. Node.js lehnt Request-Header über 16 KB mit einer 431 ab,
+bevor die Anfrage AnsibleForms erreicht, weshalb nichts protokolliert wird. Ein vorgeschalteter Reverse Proxy kann die
+Anfrage noch früher ablehnen: Nginx erlaubt standardmäßig 8 KB pro Header-Feld
+(`large_client_header_buffers 4 8k`) und antwortet stattdessen mit 400.
+
+**Wie Sie es beheben**
+
+Aktualisieren Sie auf 7.1.0 oder neuer: das Anmelde-Token trägt die Gruppen nicht mehr, daher hängt seine Größe nicht mehr davon ab, in wie vielen
+Gruppen ein Benutzer ist, und die Oberfläche sagt es, wenn eine Anfrage mit 431 abgelehnt wird, statt leere Seiten zu zeigen.
+Bis Sie aktualisieren können, entweder:
+
+* setzen Sie einen **Gruppenfilter** beim Anbieter unter **Zugriff > SSO**, einen regulären Ausdruck, der nur die Gruppen behält, die Ihre
+  Rollen verwenden, siehe [Entra ID](authentication/entra-id.html) oder [OIDC](authentication/oidc.html); der Benutzer meldet sich erneut an,
+  um ein kleineres Token zu erhalten
+* oder erhöhen Sie die Grenze von Node.js mit der Umgebungsvariable `NODE_OPTIONS=--max-http-header-size=65536` und
+  starten Sie AnsibleForms neu
+
+Ab 7.1.0 setzt [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) dieselbe Grenze, standardmäßig 16384
+Bytes und beim Start gelesen, für andere große Header, etwa große Cookies, die ein vorgeschaltetes Single-Sign-On-Gateway setzt.
+Erhöhen Sie auch die Header-Grenzen des Proxys, siehe [Größe der Request-Header](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Ein Ansible-Job endet als fehlgeschlagen, und die letzte Zeile seiner Ausgabe ist:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Warum das passiert**
+
+`ansible-playbook` hat sich mit einem Code ungleich null beendet. Die Zeilen darüber enthalten den eigenen Fehler von Ansible: das Playbook wurde nicht
+gefunden, ein Host war nicht erreichbar, ein Task ist fehlgeschlagen oder das Inventar ist falsch. Das Playbook wird im Repository mit
+eingeschaltetem **Für Playbooks verwenden?** gesucht oder in [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); die Protokollzeile
+`Running from directory : <path>` zeigt den verwendeten Ordner.
+
+**Wie Sie es beheben**
+
+Lesen Sie die Job-Ausgabe oberhalb der letzten Zeile. Wenn das Playbook nicht gefunden wird, vergleichen Sie das `playbook` des Formulars mit dem
+Ordner in `Running from directory`. Siehe [Ansible-Formulare](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Ein Ansible-Job endet als fehlgeschlagen mit:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Warum das passiert**
+
+Der Prozess `ansible-playbook` auf der RTE wurde durch ein Signal beendet, und niemand hat den Job abgebrochen. Seit 7.0.0 führt die Größe der
+Ausgabe nicht mehr dazu: jenseits von [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (standardmäßig 50 MB pro Stream)
+wird der Rest der Ausgabe nicht gespeichert, der Job zeigt
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+und das Playbook läuft bis zu seinem Ende. Die übliche Ursache ist jetzt der Arbeitsspeicher: der RTE-Container hat seine Speichergrenze erreicht, und der
+Kernel hat das Playbook beendet, zum Beispiel bei vielen Forks oder großen Facts.
+
+**Wie Sie es beheben**
+
+Prüfen Sie den Arbeitsspeicher des RTE-Containers, während das Playbook läuft (`docker stats`, `kubectl top pod`), und erhöhen Sie seine Grenze, oder senken Sie
+den Speicherverbrauch des Playbooks (weniger `forks`, kein unnötiges Sammeln von Facts). Wenn Sie nur die Warnung zu `PROCESS_MAX_BUFFER` sehen und
+die ganze Ausgabe brauchen, erhöhen Sie `PROCESS_MAX_BUFFER` in der Umgebung des RTE-Containers; es wird von der RTE gelesen, nicht von der App.
+---
+
+## Failed to launch awx template
+
+Ein AWX-Job endet als fehlgeschlagen, mit einer Ausgabe, die beginnt mit:
+
+```
+failed to launch awx template <name>
+```
+
+**Warum das passiert**
+
+Die nächste Zeile nennt den Grund. `Request failed with status code 401` bedeutet, dass das Token oder Benutzername und Passwort in den
+Anmeldedaten des AWX-Runners abgelehnt werden. `could not find job template <name>` bedeutet, dass weder eine Job-Vorlage noch eine Workflow-Job-Vorlage
+genau diesen Namen hat, oder dass der Benutzer der Verbindung sie nicht sehen kann. Ein Zertifikatsfehler, etwa
+`unable to verify the first certificate`, bedeutet, dass dem AWX-Zertifikat nicht vertraut wird.
+
+**Wie Sie es beheben**
+
+Verwenden Sie **Verbindung testen** beim Runner (**Verbindungen > Runner**), das `Runner connection is OK` antwortet, wenn es funktioniert. Seit
+7.3.0 liegen das Token oder Benutzer und Passwort, die Adresse und das **CA-Bundle** in den Anmeldedaten des Runners, unter
+**Verbindungen > Anmeldedaten**: erneuern Sie dort das Token oder Passwort, und fügen Sie bei Zertifikatsfehlern die CA in sein **CA-Bundle** ein.
+Prüfen Sie den Namen und die Berechtigungen der Vorlage. Geben Sie die Adresse ohne `/api/v2` ein: AnsibleForms fügt
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX) selbst hinzu.
+Siehe [AWX-Formulare](forms/awx.html).
+
+---
+
+## Ein Job zeigt den Status abandoned
+
+Ein Job, der lief, ist jetzt als `abandoned` markiert, und das Protokoll eines Knotens oder einer RTE zeigt eine dieser Meldungen:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Eine RTE im Datenbankmodus, veraltet, protokolliert ihre eigene:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Warum das passiert**
+
+Ein Job gehört zu dem Container, der ihn ausführt oder verfolgt: ein Playbook zu seiner RTE, jeder andere Job (ein AWX-Job, die Schritte eines Multistep-
+Formulars) zu dem App-Knoten, der ihn gestartet hat. Wenn dieser Container neu startet, beendet er seine eigenen unfertigen Jobs. Wenn er verschwindet, etwa ein ersetzter
+Pod, beendet der Worker seine Jobs, sobald er zwei Minuten lang nicht geantwortet hat. Kommt eine RTE in einem Socket-Modus ohne
+einen Job zurück, den sie ausführte, zum Beispiel ein neuer Container ohne seinen Spool, endet dieser Job als abandoned. Eine stoppende RTE wartet
+zuerst [`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) auf ihre Playbooks. Jede Stunde werden außerdem Jobs, die seit mehr
+als einem Tag laufen, als abandoned markiert.
+
+Seit 7.3.0 läuft ein Job auf AWX, AAP oder Ascender auf seinem Runner weiter: gleich nachdem ein Neustart ihn aufgegeben hat, verfolgt ein Knoten ihn erneut,
+wenn er in den letzten 24 Stunden gestartet wurde, und er endet mit dem, was dort tatsächlich passiert ist. Das Protokoll sagt dann `Following <n> abandoned job(s) again on their runner`.
+
+**Wie Sie es beheben**
+
+Starten Sie einen Playbook-Job erneut. Starten oder aktualisieren Sie RTEs und App-Knoten, während kein Job läuft, und geben Sie einer stoppenden RTE genug Zeit
+(siehe [Skalierung](rte/run.html)). Prüfen Sie, ob das Playbook auf den verwalteten Hosts wirklich fertig wurde, bevor Sie es
+erneut starten, denn es kann teilweise gelaufen sein.
+
+---
+
+## Eine RTE verbindet sich nicht
+
+**Verbindung testen** bei einem RTE-Runner (**Verbindungen > Runner**) schlägt fehl mit:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Warum das passiert**
+
+Eine RTE in einem Socket-Modus spricht über einen WebSocket mit der App: ausgehend verbindet sie sich mit der App, eingehend verbindet sich die App mit ihr (siehe
+[Modi](rte/modes.html)). Die Protokolle der App und der RTE sagen, warum der Socket nicht offen ist:
+
+| Meldung | Wo | Was sie bedeutet |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | Die RTE (eingehend) | Das Token der RTE-Anmeldedaten des Runners ist nicht das `RTE_TOKEN` der RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | Die App (eingehend) | Dasselbe, von der App aus gesehen |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | Die App und die abgelehnte RTE (`401`) | Die RTE meldet sich mit einem anderen Token an als dem, das die App für ihren Runner aufbewahrt |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | Die RTE (ausgehend) | Sie hat um Beitritt gebeten und wartet auf eine Freigabe |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | Die RTE (eingehend, mit `APP_URL`) | Dasselbe, für eine eingehende RTE |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | Die App und die abgelehnte RTE (`409`) | Der Konfigurations-Seed deklariert den Runner ohne `rte_mode`, also im Datenbankmodus, und der Seed bestimmt seinen Modus. Eine eingehende RTE erhält `rte_mode: inbound` und `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | Die RTE | Eine eingehende RTE, die sich selbst registriert, braucht die Adresse, unter der die App sie erreicht |
+| `Runner '<name>': dialing <address>: <reason>` | Die App, auf Stufe `debug` | Die App kann den Socket nicht öffnen, zum Beispiel weil das Zertifikat der RTE nicht das für ihren Runner gepinnte ist |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | Die RTE | Sie läuft im Datenbankmodus und öffnet überhaupt keinen Socket |
+
+**Wie Sie es beheben**
+
+* **Ein abgelehntes Token** : geben Sie der RTE das Token der RTE-Anmeldedaten ihres Runners (**Verbindungen > Anmeldedaten**), oder umgekehrt
+* **Wartet auf Freigabe** : geben Sie sie unter **Verbindungen > Runner** frei, nachdem Sie geprüft haben, dass der dort angezeigte Fingerabdruck der in ihrem
+  Protokoll ist (siehe [Eine RTE freigeben](runners/registration.html#approving-an-rte))
+* **Vom Konfigurations-Seed im Datenbankmodus verwaltet** : setzen Sie `rte_mode` beim Runner im Seed, mit RTE-Anmeldedaten (bei eingehend mit ihrer
+  Adresse), und starten Sie dann die RTE neu
+* **Eingehend ohne `RTE_URL`** : setzen Sie `RTE_URL` auf die Adresse, unter der die App die RTE erreicht, oder lassen Sie `APP_URL` weg und deklarieren Sie den
+  Runner im Seed oder unter **Verbindungen > Runner**
+* **Ein Zertifikat, das nicht das gepinnte ist** : eine eingehende RTE über HTTPS sendet ihr Zertifikat, wenn sie sich registriert, und die App verbindet sich
+  nur mit diesem. Nach einem neuen Zertifikat sendet die RTE es bei der Registrierung erneut; wurde das CA-Bundle der Anmeldedaten
+  von Hand gesetzt, behält die App es und protokolliert
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **Die Warnung [DEPRECATED]** : setzen Sie `RTE_MODE` auf der RTE, entfernen Sie `DB_*` aus ihrer Umgebung und setzen Sie ihren Runner auf diesen Modus (siehe
+  [Modi](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Mit der Startvalidierung auf `enforce` wird ein Start mit `422` abgelehnt und:
+
+```
+The form data is not valid
+```
+
+**Warum das passiert**
+
+Der Server hat die Feldwerte gegen die Regeln des Formulars geprüft und fehlende oder ungültige Felder gefunden; die Antwort listet
+sie unter `details` auf. Ein Start ohne `rawFormData` wird ebenfalls abgelehnt. Ein Formular, das sich noch nicht prüfen lässt, etwa ein Wizard,
+wird mit `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>` abgelehnt.
+
+**Wie Sie es beheben**
+
+Korrigieren Sie die Felder, die die Details nennen, oder die Regeln des Formulars, wenn sie zu streng sind. Lassen Sie es zuerst unter `log` laufen: das protokolliert
+`Launch validation would refuse form '<name>' ...`, ohne etwas abzulehnen. Siehe
+[Was enforce tut](launch-validation/log-and-enforce.html#what-enforce-does) und
+[Einführung](launch-validation/rolling-it-out.html).
+
+---
+
+## Klonen oder Pull eines Repositorys schlägt fehl
+
+Ein Repository zeigt einen fehlgeschlagenen Status, und seine Ausgabe enthält den Fehler von Git, oder das Protokoll zeigt
+`Background clone of '<name>' failed : <reason>`.
+
+**Warum das passiert**
+
+Git konnte das Remote nicht erreichen oder sich dort nicht authentifizieren. Bei SSH-URLs (`git@host:path`) muss das Remote den öffentlichen
+Schlüssel von AnsibleForms akzeptieren; bei HTTPS müssen Benutzername und Token gültig sein. Ein Pull wird auch abgelehnt, wenn der Arbeitsbaum
+Änderungen hat, mit
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Wie Sie es beheben**
+
+Bei SSH kopieren Sie den öffentlichen Schlüssel aus dem Reiter **Schlüssel** von **Verbindungen > SSH** und fügen ihn als Deploy Key hinzu oder einem Benutzer mit
+Zugriff auf das Repository. AnsibleForms fügt den Remote-Host beim Klonen zu den bekannten Hosts hinzu; für andere Hosts verwenden Sie den
+Reiter **Bekannte Hosts** derselben Seite. Bei
+HTTPS erneuern Sie das Token. Siehe [Git-Repositories](gui/designer-and-git.html#git-repositories) und
+[Über Repositories](faq.html#about-repositories).
+
+---
+
+## Das Formular-Repository ist noch nicht geklont
+
+Das Speichern von Formularen im Designer schlägt fehl mit:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Warum das passiert**
+
+Ein Repository mit eingeschaltetem **Für Formulare verwenden?** hat noch keinen Arbeitsbaum, weil das Klonen noch nicht gelaufen oder fehlgeschlagen ist.
+
+**Wie Sie es beheben**
+
+Klonen Sie das Repository in den Repository-Einstellungen. Wenn das Klonen fehlschlägt, siehe
+[Klonen oder Pull eines Repositorys schlägt fehl](#a-repository-clone-or-pull-failed).
+
+---
+
+## Ein Backup schlägt fehl
+
+Ein Backup schlägt fehl, und der Liste der Backups wird nichts hinzugefügt. Der Grund ist einer von:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Warum das passiert**
+
+Der Dump-Befehl, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), ist nicht installiert, konnte sich nicht
+verbinden oder hat eine leere Datei erzeugt. Eine große Datenbank kann auch länger brauchen als
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), standardmäßig eine Stunde.
+Ein fehlgeschlagenes Backup hinterlässt keinen Ordner; das Protokoll sagt `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Wie Sie es beheben**
+
+Installieren Sie die Client-Werkzeuge von MySQL oder MariaDB, oder setzen Sie `MYSQLDUMP_COMMAND` (und `MYSQL_COMMAND` für Wiederherstellungen) auf einen Befehl,
+der auf diesem Host und gegen die Version Ihres Servers funktioniert. Erhöhen Sie `BACKUP_COMMAND_TIMEOUT_SECONDS` für eine große Datenbank.
+Siehe [Backups](gui/administration.html#backups).
diff --git a/i18n/de/_security_assessment/security-assessment/advisories.md b/i18n/de/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..d890137
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Security Advisories
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Security Advisories
+{: .no_toc }
+
+Jede veröffentlichte Schwachstelle, ihr Schweregrad und ihre Behebung
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Veröffentlichte Advisories
+
+Bei jedem Build dieser Website aus dem [Security-Tab des Repositorys](https://github.com/ansibleforms/ansibleforms/security/advisories) gelesen:
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Advisory</th>
+      <th>Schweregrad</th>
+      <th>Schwäche</th>
+      <th>Betroffen</th>
+      <th>Behoben in</th>
+      <th>Veröffentlicht</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Es wurde kein Advisory veröffentlicht.
+{% endif %}
+
+Jedes Advisory auf GitHub nennt die Details: die Auswirkung, die Bedingungen, den CVSS-Vektor und die Behebung.
+
+---
+
+## Was das für Ihre Version bedeutet
+
+Ein Advisory nennt die betroffenen Versionen und die erste behobene Version. Die Behebung erscheint in den unterstützten Releases,
+[7.x und 6.5.x](development.html#supported-versions), ältere Releases werden nicht gepatcht: Die Lösung ist ein Upgrade.
+
+Vergleichen Sie die Version einer Instanz (**Info** im Hilfemenü oder `GET /api/v2/version`) mit **Betroffen**.
+
+---
+
+## Über neue Advisories informiert werden
+
+GitHub benachrichtigt die Beobachter des Repositorys, wenn ein Advisory veröffentlicht wird:
+
+* Auf [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), wählen Sie **Watch > Custom > Security alerts**.
+* Das [Changelog](../changelog.html) listet jede Sicherheitskorrektur unter dem Release auf, das sie enthält.
diff --git a/i18n/de/_security_assessment/security-assessment/development.md b/i18n/de/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..ea1ea00
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Sichere Entwicklung
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Sichere Entwicklung
+{: .no_toc }
+
+Wie Änderungen geprüft und veröffentlicht werden, und was unterstützt wird
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Der Quellcode
+
+AnsibleForms ist Open Source, daher lässt sich alles auf dieser Seite im Repository selbst überprüfen:
+
+* Der Code, seine Historie und seine Build-Pipelines sind öffentlich auf [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* Die [Lizenz](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) ist GPL-3.0.
+* Das [Changelog](../changelog.html) listet jede Änderung jedes Releases auf, Sicherheitskorrekturen eingeschlossen.
+
+---
+
+## Wie eine Änderung gemergt wird
+
+Jede Änderung gelangt über einen Pull Request nach `main`, unter einem Ruleset, das niemand umgehen kann:
+
+| Regel | Was sie bedeutet |
+|---|---|
+| Pull Request erforderlich | Nichts wird direkt nach `main` gepusht |
+| Erforderliche Checks | Der Pull Request wird nur gemergt, wenn jeder der folgenden Checks besteht |
+| Kein Force Push, kein Löschen | Die Historie von `main` kann weder umgeschrieben noch entfernt werden |
+| Lineare Historie | Jeder Pull Request wird zu einem Commit, sodass jede Änderung einzeln nachverfolgt und rückgängig gemacht werden kann |
+
+Die Checks, die ein Pull Request bestehen muss:
+
+| Check | Was er macht |
+|---|---|
+| Client, Server | Die Unit-Tests der Weboberfläche und des Servers |
+| CodeQL | Die statische Analyse von GitHub für den JavaScript- und TypeScript-Code, auf Injection, Cross-Site-Scripting und andere Schwächen |
+| Public schema is up to date | Das Datenbankschema, das der Code erwartet, stimmt mit dem mitgelieferten überein |
+| Title, Branch | Der Pull Request folgt den Namensregeln, damit das Changelog korrekt bleibt |
+
+Zwei weitere laufen bei jedem Pull Request und berichten darüber:
+
+* **Database** testet den Server auf MySQL und MariaDB, und **Browser** bedient die Oberfläche in einem Browser.
+* **Dependency review** blockiert eine neue Abhängigkeit mit einer bekannten Schwachstelle der Stufe High oder Critical.
+
+---
+
+## Codeanalyse und Abhängigkeiten
+
+Der Code und seine Abhängigkeiten werden nach dem Merge erneut geprüft:
+
+* **CodeQL** analysiert außerdem jeden Push nach `main` und in die Release-Branches sowie jede Woche die gesamte Codebasis:
+  Eine neue CodeQL-Regel prüft dann auch den Code, der vor ihr gemergt wurde.
+* **Dependabot** öffnet für jede neue Version einer Abhängigkeit einen Pull Request: für die npm-Pakete des Servers und der
+  Oberfläche, die Python-Pakete der Laufzeitumgebung und die GitHub Actions der Pipelines jede Woche, und für
+  die Basis-Images der Container jeden Tag.
+* Die Basis-Images sind per Digest fixiert (`node:26-trixie-slim@sha256:...`), sodass ein Build genau das geprüfte Image verwendet.
+  Dependabot aktualisiert den Digest, wenn das Image upstream neu gebaut wird.
+
+---
+
+## Releases und Images
+
+Ein Release wird ausschließlich von GitHub Actions gebaut und veröffentlicht, nie vom Rechner eines Entwicklers:
+
+* Ein Release wird aus `main` (oder `release/6.x`) erstellt, mit einem Changelog, das aus seinen Pull Requests gebaut wird.
+* Die Images werden vom [Publish-Workflow](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  gebaut und in die GitHub Container Registry `ghcr.io/ansibleforms/ansibleforms` gepusht, mit den Images der Laufzeitumgebung
+  daneben. Der Workflow und seine Logs sind öffentlich, sodass jeder sehen kann, was in ein Image eingeflossen ist.
+* Die Images der Anwendung und der Laufzeitumgebung laufen als unprivilegierter Benutzer `node` (uid 1000), nie als root.
+
+---
+
+## Unterstützte Versionen
+
+Sicherheitskorrekturen kommen in das neueste Release jeder unterstützten Linie:
+
+| Version | Erhält Sicherheitskorrekturen |
+|---|---|
+| 7.x | Ja |
+| 6.5.x | Ja |
+| Älter als 6.5 | Nein: Die Lösung ist ein Upgrade |
+
+Die [Upgrade-Anleitung](../upgrading/) beschreibt den Wechsel auf ein neueres Release, und [Upgrade auf v7](../upgrade-7.html) den Wechsel von 6.5.
diff --git a/i18n/de/_security_assessment/security-assessment/faq.md b/i18n/de/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..3f681f8
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: FAQ zur Bewertung
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# FAQ zur Bewertung
+{: .no_toc }
+
+Kurze Antworten auf die Fragen, die Sicherheitsfragebögen am häufigsten stellen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Daten und Hosting
+
+Wo die Daten liegen und wer darauf zugreifen kann:
+
+| Frage | Antwort |
+|---|---|
+| Wo werden unsere Daten gespeichert? | In der MySQL- oder MariaDB-Datenbank, die Sie betreiben, und im persistenten Ordner Ihrer Instanz. AnsibleForms ist selbst gehostet, ohne Cloud-Dienst dahinter. |
+| Sendet es Daten an seine Entwickler? | Nein. Es gibt keine Telemetrie, keine Nutzungsberichte und keine Update-Prüfung. |
+| Womit verbindet es sich? | Nur mit den Systemen, die ein Administrator konfiguriert: siehe [Ausgehende Verbindungen](measures.html#outbound-connections). |
+| Verwendet es KI oder sendet es Daten an einen Modellanbieter? | Nur mit eingeschaltetem [Chat-Assistenten](../chat/), der standardmäßig aus ist. Dann sendet es Formulardefinitionen und die gerade eingegebenen Werte an den Anbieter, den Sie konfigurieren. |
+| Kann es ohne Internetzugang laufen? | Ja. Die Anwendung braucht keinen Internetzugang; die Playbooks brauchen, was ihre Tasks erreichen. |
+
+---
+
+## Verschlüsselung
+
+Was verschlüsselt wird und mit welchen Schlüsseln:
+
+| Frage | Antwort |
+|---|---|
+| Werden Daten bei der Übertragung verschlüsselt? | Mit [HTTPS](../security/https.html), bereitgestellt von der Anwendung oder Ihrem Reverse Proxy, und `wss://` zwischen der Anwendung und ihren Laufzeitumgebungen. |
+| Werden Daten im Ruhezustand verschlüsselt? | Jedes gespeicherte Secret wird von der Anwendung mit AES-256 verschlüsselt. Jobs und ihre Ausgabe werden so gespeichert, wie sie sind: Verwenden Sie die Verschlüsselung im Ruhezustand der Datenbank selbst. Siehe [Gespeicherte Secrets](measures.html#stored-secrets). |
+| Wer hält die Schlüssel? | Sie: Das [`ENCRYPTION_SECRET`](../security/secrets.html) setzen Sie selbst, es bleibt aus Backups heraus und kann rotiert werden. |
+| Können Secrets in unserem Vault bleiben? | Ja: [HashiCorp Vault und CyberArk](../secret-stores/) werden gelesen, wenn ein Job sie braucht. |
+
+---
+
+## Zugriff und Nachvollziehbarkeit
+
+Wer sich anmelden kann, was er tun kann und was aufgezeichnet wird:
+
+| Frage | Antwort |
+|---|---|
+| Unterstützt es Single Sign-on? | Ja: LDAP / Active Directory, OpenID Connect und Entra ID. Siehe [Authentifizierung](../authentication/). |
+| Unterstützt es Multi-Faktor-Authentifizierung? | Über Single Sign-on: Die MFA Ihres Identitätsanbieters gilt. Lokale Konten haben keine eigene. |
+| Wie werden Berechtigungen verwaltet? | Mit Rollen, die Gruppen zugeordnet sind und vom Server bei jeder Anfrage geprüft werden. Siehe [Berechtigungen](measures.html#permissions). |
+| Gibt es ein Audit-Protokoll? | Ja: jede Änderung und jeder abgelehnte Versuch, standardmäßig 365 Tage aufbewahrt und an Syslog weiterleitbar. Siehe [Audit-Trail](measures.html#audit-trail). |
+| Gibt es ein Standardpasswort? | Das erste Admin-Konto hat ein öffentliches Standardpasswort, das bei der ersten Anmeldung geändert werden muss. Siehe [Das Admin-Konto](../security/hardening.html#the-admin-account). |
+
+---
+
+## Schwachstellen und Updates
+
+Wie Probleme gefunden, behoben und angekündigt werden:
+
+| Frage | Antwort |
+|---|---|
+| Wurden Schwachstellen gefunden? | Ja. Jede veröffentlichte steht in [Security Advisories](advisories.html), mit der Version, die sie behoben hat. |
+| Wie melden wir eine? | Vertraulich, über GitHub: siehe [Eine Schwachstelle melden](reporting.html). |
+| Wie wird der Code geprüft? | Statische Analyse mit CodeQL und Dependency Review bei jedem Pull Request, automatisierte Tests und Updates durch Dependabot. Siehe [Sichere Entwicklung](development.html). |
+| Welche Versionen erhalten Sicherheitskorrekturen? | 7.x und 6.5.x. Siehe [Unterstützte Versionen](development.html#supported-versions). |
+| Wie erfahren wir von einem neuen Advisory? | Beobachten Sie die Security Alerts des Repositorys auf GitHub. Siehe [Über neue Advisories informiert werden](advisories.html#being-told-of-new-advisories). |
+| Wurde ein Penetrationstest durchgeführt? | Es ist kein Bericht eines externen Penetrationstests veröffentlicht. Der Code ist öffentlich, sodass Ihr eigenes Team oder Ihr Tester ihn bewerten kann, und Befunde werden wie oben gemeldet. |
+
+---
+
+## Images und Lieferkette
+
+Woher die Images kommen und wie man sie prüft:
+
+| Frage | Antwort |
+|---|---|
+| Wo werden die Images veröffentlicht? | In der GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, gebaut von öffentlichen GitHub-Actions-Workflows. Siehe [Releases und Images](development.html#releases-and-images). |
+| Laufen die Container als root? | Nein: als unprivilegierter Benutzer `node`. |
+| Sind die Images signiert? | Noch nicht. Ziehen Sie sie per Digest (`@sha256:...`), um sicherzugehen, dass Sie das geprüfte Image ausführen. |
+| Gibt es eine SBOM? | Mit den Images wird noch keine veröffentlicht. Ein Scanner wie Trivy oder Syft erstellt eine aus dem Image. |
+| Werden die Images auf Schwachstellen gescannt? | Nicht in der Release-Pipeline. Ihre Basis-Images sind per Digest fixiert und werden von Dependabot aktuell gehalten; scannen Sie die Images in Ihrer eigenen Registry, um Ihre eigene Richtlinie anzuwenden. |
+| Unter welcher Lizenz steht es? | GPL-3.0, Open Source, ohne Gewährleistung. |
diff --git a/i18n/de/_security_assessment/security-assessment/index.md b/i18n/de/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..6aee5cd
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Überblick
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Sicherheitsbewertung
+{: .no_toc }
+
+Für Sicherheitsprüfungen: Maßnahmen, Entwicklung und Advisories
+{: .fs-6 .fw-300 }
+
+---
+
+## Kurz gesagt
+
+AnsibleForms führt Playbooks aus und verwahrt deren Zugangsdaten, ist also Teil Ihrer Vertrauenskette:
+
+* Es ist **selbst gehostet**: Es läuft auf Ihrer Infrastruktur, speichert seine Daten in Ihrer Datenbank und sendet nichts an seine Entwickler.
+* Es ist **Open Source** (GPL-3.0): Der Code, seine Pipelines und jedes Advisory sind öffentlich.
+* Jedes gespeicherte Secret ist **verschlüsselt**, jede Änderung wird **auditiert**, und **Rollen** werden bei jeder Anfrage geprüft.
+* Schwachstellen werden **vertraulich gemeldet**, in jeder unterstützten Version behoben und **veröffentlicht**.
+
+---
+
+## In diesem Abschnitt
+
+Die Seiten beantworten die Fragen einer Sicherheitsprüfung, vom Design bis zur CVE-Liste:
+
+| Seite | Inhalt |
+|---|---|
+| [Sicherheitsmaßnahmen](measures.html) | Anmeldung, Berechtigungen, gespeicherte Secrets, der Audit-Trail, der Browser, der Server, Verbindungen und Container |
+| [Sichere Entwicklung](development.html) | Wie eine Änderung geprüft und getestet wird, Code- und Abhängigkeitsanalyse, wie Images gebaut werden, unterstützte Versionen |
+| [Eine Schwachstelle melden](reporting.html) | Wie Sie ein Problem vertraulich melden und was danach passiert |
+| [Security Advisories](advisories.html) | Jede veröffentlichte Schwachstelle, mit CVE, Schweregrad und behobener Version |
+| [FAQ zur Bewertung](faq.html) | Kurze Antworten auf die Fragen, die Sicherheitsfragebögen am häufigsten stellen |
+
+Um eine Instanz abzusichern statt sie zu bewerten, siehe [Sicherheit](../security/) im Administratorhandbuch.
diff --git a/i18n/de/_security_assessment/security-assessment/measures.md b/i18n/de/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..151cb07
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Sicherheitsmaßnahmen
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Sicherheitsmaßnahmen
+{: .no_toc }
+
+Wie Anmeldung, Berechtigungen, Secrets und Verbindungen geschützt sind
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wo es läuft
+
+AnsibleForms ist selbst gehostet, auf Ihrer Infrastruktur, mit seinen Daten in einer Datenbank, die Sie betreiben.
+
+* Es gibt keinen AnsibleForms-Cloud-Dienst und keinen Lizenzserver, und keine Telemetrie oder Update-Prüfung.
+* Die Oberfläche wird von der Anwendung selbst ausgeliefert und lädt nichts von einer anderen Website.
+* Die Anwendung verbindet sich nur mit den Systemen, die ein Administrator konfiguriert, aufgeführt unter [Ausgehende Verbindungen](#outbound-connections).
+
+Die Bestandteile und was jeder enthält:
+
+| Bestandteil | Was er macht | Was er enthält |
+|---|---|---|
+| Anwendung | Die Weboberfläche, die REST-API, der Scheduler | Keine eigenen Daten: Alles liegt in der Datenbank |
+| MySQL oder MariaDB | Die Datenbank der Anwendung | Benutzer, Gruppen, Zugangsdaten (verschlüsselt), Jobs mit ihren Extravars und ihrer Ausgabe, das Audit-Protokoll |
+| Laufzeitumgebung (RTE) | Führt die Playbooks aus, in einem eigenen Container | Die Dateien der Jobs, die sie ausführt, und die Secrets eines Jobs nur, solange dieser Job läuft |
+| Persistenter Ordner | Die Konfiguration, Formulare, Playbooks und Uploads | Die Dateien, die die Formulare und Playbooks verwenden |
+
+Siehe [Wie es funktioniert](../how-it-works.html) für das Gesamtbild und [RTE](../rte/) für die Laufzeitumgebung.
+
+---
+
+## Anmeldung
+
+Jede Seite und jeder API-Aufruf, der Daten liest oder ändert, braucht einen angemeldeten Benutzer. Die wenigen Endpunkte, die ohne Anmeldung offen sind, bedienen die
+Anmeldung selbst, die Version, Name und Logo der Instanz, die API-Dokumentation und die Datenbankeinrichtung beim ersten Start,
+die [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` schließt:
+
+| Methode | Wie sie funktioniert |
+|---|---|
+| Lokale Konten | Passwörter mit bcrypt gehasht, eine [Mindestlänge](../security/hardening.html#sign-in-limits-and-passwords), und das öffentliche Standardpasswort des Admins muss bei der ersten Anmeldung geändert werden |
+| LDAP / Active Directory | Das Verzeichnis prüft das Passwort, und seine Gruppen werden Rollen zugeordnet. Siehe [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Single Sign-on über Ihren Identitätsanbieter, der auch seine eigene Multi-Faktor-Authentifizierung mitbringt. Siehe [Authentifizierung](../authentication/) |
+
+* Fehlgeschlagene Anmeldungen [sperren das Konto](../security/hardening.html#sign-in-limits-and-passwords), und die Anmeldung ist ratenbegrenzt.
+* Eine Anmeldung liefert ein signiertes Access-Token, 30 Minuten gültig, und ein Refresh-Token, 24 Stunden gültig.
+* Tokens lassen sich vor ihrem Ablauf beenden: Abmelden, eine Passwortänderung, ein gesperrter Benutzer und ein widerrufenes API-Token beenden sie auf
+  allen Knoten gleichzeitig, siehe [Tokens](../security/secrets.html#tokens).
+* AnsibleForms hat keine eigene Multi-Faktor-Authentifizierung: Verwenden Sie Single Sign-on, wo sie erforderlich ist.
+
+---
+
+## Berechtigungen
+
+Was ein Benutzer tun darf, ergibt sich aus den Rollen seiner Gruppen und wird vom Server bei jeder Anfrage geprüft:
+
+* Rollen werden in [config.yaml](../config/roles.html) definiert: welche Formulare ein Benutzer sieht und welche Optionen er hat,
+  etwa den Designer, die Einstellungsseiten oder die Jobs anderer Benutzer.
+* Der Server prüft jeden Start gegen die Regeln des Formulars (seine Felder, ihre Werte und den Zugriff des Benutzers), einschließlich
+  Starts über die REST-API, siehe [Start-Validierung](../launch-validation/).
+* Die Admin-Rolle führt bewusst jedes Playbook aus. Andere Rollen erhalten nur, was gewährt wird: Ein Benutzer mit mehreren Rollen erhält eine
+  Option nur, wenn keine dieser Rollen sie verweigert, sodass eine einzige restriktive Rolle genügt, um sie vorzuenthalten.
+
+---
+
+## Gespeicherte Secrets
+
+Passwörter, Tokens und Schlüssel werden verschlüsselt, bevor sie in die Datenbank geschrieben werden:
+
+* Jedes gespeicherte Secret, also Zugangsdaten, das LDAP-Bind-Passwort, Runner-Tokens, Client-Secrets für Single Sign-on, Webhook-Adressen
+  und API-Schlüssel, wird mit AES-256 und einem zufälligen Initialisierungsvektor pro Wert verschlüsselt, unter dem
+  [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets), das Sie setzen.
+* Kein API-Aufruf und keine Einstellungsseite zeigt ein gespeichertes Secret, und Backups lassen die Hauptschlüssel weg.
+* Secrets können in Ihrem Vault bleiben: [HashiCorp Vault und CyberArk](../secret-stores/) werden gelesen, wenn ein Job sie braucht.
+* Die Secrets eines Jobs erreichen die Laufzeitumgebung mit AES-256-GCM versiegelt, unter einem aus ihrem Token abgeleiteten Schlüssel.
+* Extravars, deren Name nach einem Secret aussieht, werden in der Jobansicht maskiert, Passwortfelder immer, siehe [Jobdaten](../security/hardening.html#job-data).
+
+Der Rest der Datenbank, also Jobs, ihre Extravars und ihre Ausgabe, wird so gespeichert, wie er ist: Schützen Sie ihn mit der eigenen
+Verschlüsselung im Ruhezustand und der Zugriffskontrolle der Datenbank, siehe [Die Datenbank](../security/hardening.html#the-database).
+
+---
+
+## Audit-Trail
+
+Jede Änderung und jeder abgelehnte Versuch wird aufgezeichnet:
+
+* Jedes Erstellen, Ändern und Löschen, über die Oberfläche oder die API, wird mit dem Benutzer, seiner
+  Adresse, der Aktion, dem Objekt und dem Ergebnis ins Audit-Protokoll geschrieben. Ablehnungen und Anmeldungen werden ebenfalls aufgezeichnet, fehlgeschlagene eingeschlossen.
+* Werte, die nach Secrets aussehen, werden vor dem Schreiben geschwärzt.
+* Das Protokoll wird standardmäßig 365 Tage aufbewahrt und kann über UDP, TCP oder TLS an Syslog kopiert werden.
+
+---
+
+## Im Browser
+
+Die Oberfläche ist gegen in eine Seite eingeschleusten Code geschützt:
+
+* Eine [Content-Security-Policy](../security/hardening.html#the-content-security-policy) erlaubt nur die eigenen Skripte und Frames der Anwendung.
+* Jede Antwort trägt Schutz-Header: nosniff, Frame-Schutz und HSTS über HTTPS.
+* Das HTML von Formularen, Hilfetexten und Chat-Antworten wird bereinigt, und die Jobausgabe wird maskiert.
+
+---
+
+## Auf dem Server
+
+Der Code, der Benutzereingaben verarbeitet, vermeidet die klassischen Injections:
+
+* Datenbankabfragen übergeben ihre Werte als Parameter, nie als in die Abfrage geklebten Text.
+* Befehle, git eingeschlossen, laufen aus einer Argumentliste, nie über eine Shell, sodass Shell-Zeichen nichts bewirken.
+* Serverausdrücke durchlaufen einen [Sanitizer für Ausdrücke](../security/hardening.html#expressions-and-outbound-calls) und ihre REST-Aufrufe einen Hostfilter.
+* Der [MCP-Server](../mcp/), der [Chat-Assistent](../chat/) und der Metrics-Endpunkt sind aus, bis Sie sie einschalten.
+
+---
+
+## Verbindungen
+
+Der Datenverkehr zu und von AnsibleForms lässt sich durchgehend verschlüsseln:
+
+* Die Anwendung stellt [HTTPS](../security/https.html) selbst bereit oder steht hinter Ihrem Reverse Proxy.
+* Eine Laufzeitumgebung spricht mit der Anwendung über einen WebSocket, `wss://` mit einer HTTPS-Adresse, und die Anwendung
+  pinnt das Zertifikat einer eingehenden, siehe [RTE-Modi](../rte/modes.html).
+* LDAP, Single Sign-on, die Runner, git, die Secret Stores und die REST-Aufrufe von Ausdrücken prüfen das Zertifikat des
+  Servers, den sie erreichen, sofern ein Administrator die Prüfung für einen Server mit selbstsigniertem Zertifikat nicht abschaltet.
+
+### Ausgehende Verbindungen
+
+AnsibleForms verbindet sich nur mit dem, was ein Administrator konfiguriert:
+
+| Verbindung | Wann |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (Microsoft-Anmeldung und Graph) | Wenn diese Anmeldemethode eingerichtet ist |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Wenn ein Formular auf diesem Runner läuft |
+| Git-Server | Wenn ein Repository eingerichtet ist |
+| Mailserver, Slack, Teams, Telegram, Webhooks | Wenn ein Benachrichtigungskanal eingerichtet ist |
+| HashiCorp Vault, CyberArk | Wenn ein Secret Store eingerichtet ist |
+| Ein Modellanbieter (Anthropic, OpenAI und andere) | Nur mit eingeschaltetem [Chat-Assistenten](../chat/), der standardmäßig aus ist |
+| In Formularen genannte Hosts und APIs | Wenn die Ausdrücke eines Formulars oder ein Playbook sie aufrufen |
+| Syslog-Server | Wenn die Weiterleitung von Audit oder Protokollen eingerichtet ist |
+
+---
+
+## Die Container
+
+Die Images sind so gebaut, dass sie mit so wenig Rechten wie möglich laufen:
+
+* Die Anwendung und die Laufzeitumgebung laufen als unprivilegierter Benutzer `node`, nicht als root.
+* Sie basieren auf schlanken, per Digest fixierten Debian-Images, siehe [Sichere Entwicklung](development.html#code-analysis-and-dependencies).
+* Die Anwendung lauscht auf einem Port, 8000.
+
+Für die Schritte, die eine neue Instanz absichern, folgen Sie der [Härtung](../security/hardening.html).
diff --git a/i18n/de/_security_assessment/security-assessment/reporting.md b/i18n/de/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..888e8a4
--- /dev/null
+++ b/i18n/de/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Eine Schwachstelle melden
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Eine Schwachstelle melden
+{: .no_toc }
+
+Wie Sie ein Sicherheitsproblem vertraulich melden und was danach passiert
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Vertraulich melden
+
+AnsibleForms verwahrt Zugangsdaten und Vault-Tokens, melden Sie ein Sicherheitsproblem also nie in einem öffentlichen Issue:
+
+1. Öffnen Sie **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: ein privates Advisory, das nur die Maintainer sehen.
+2. Steht Ihnen diese Seite nicht zur Verfügung, öffnen Sie ein normales Issue, das nur sagt, dass Sie eine Sicherheitsmeldung haben, und
+   um einen privaten Kanal bittet: keine Details, kein Reproduktionsbeispiel, keine Versionsnummern. Ein Maintainer öffnet ein privates Advisory und
+   lädt Sie dazu ein.
+
+Die vollständige Richtlinie ist die [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) des Repositorys.
+
+---
+
+## Was eine Meldung enthalten sollte
+
+Je mehr davon eine Meldung enthält, desto schneller wird das Problem behoben:
+
+* Was ein Angreifer gewinnt: die Daten eines anderen Benutzers, ein Playbook, das er nicht ausführen darf, den Host oder Admin-Rechte.
+* Die Version und wie sie bereitgestellt ist: Docker, Kubernetes oder nativ installiert.
+* Ein Reproduktionsbeispiel oder die Anfrage, die das Problem auslöst.
+* Ob ein angemeldeter Benutzer nötig ist, und mit welchen [Rollenoptionen](../config/roles.html).
+
+---
+
+## Was danach passiert
+
+Eine Meldung läuft von der ersten Nachricht bis zur Veröffentlichung über dasselbe private Advisory:
+
+| Schritt | Was Sie erhalten |
+|---|---|
+| Eingangsbestätigung | Die Bestätigung, dass die Meldung angekommen ist, und ob sie sich reproduzieren lässt |
+| Angenommen | Eine Korrektur im nächsten Release jeder [unterstützten Version](development.html#supported-versions) und ein veröffentlichtes Advisory, das Sie nennt, sofern Sie nicht lieber ungenannt bleiben |
+| Abgelehnt | Die Begründung, meist dass das Verhalten eine Berechtigung voraussetzt, die der Meldende bereits hatte |
+
+Sobald die Korrektur veröffentlicht ist, wird das Advisory veröffentlicht und erscheint unter [Security Advisories](advisories.html).
+
+---
+
+## Geltungsbereich
+
+Die Richtlinie zieht die Grenze dort, wo das Rollenmodell sie zieht:
+
+| Im Geltungsbereich | Außerhalb des Geltungsbereichs |
+|---|---|
+| Alles, was ein angemeldeter Benutzer über das hinaus erreicht, was seine Rolle erlaubt | Befunde, die ein bereits kompromittiertes Admin-Konto voraussetzen: Ein Admin, der beliebige Playbooks ausführt, ist das Produkt |
+| Alles, was ohne Anmeldung erreichbar ist | Scannerberichte ohne nachgewiesene Auswirkung |
+| Gespeicherte Zugangsdaten, die lesbar werden oder in ein Protokoll geschrieben werden | |
+| Injection in die Shell, die Datenbank oder den Browser | |
diff --git a/i18n/de/_use/designer/index.md b/i18n/de/_use/designer/index.md
new file mode 100644
index 0000000..a989f1b
--- /dev/null
+++ b/i18n/de/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Designer
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Designer
+{: .no_toc }
+
+Formulare, Playbooks, Inventare und Workflows im Browser bearbeiten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für Formularautoren: die Bereiche des Designers und was jeder ihrer Tabs zeigt.
+
+Der Designer braucht die [Rollenoption](../config/roles.html#role-options) `showDesigner`. Er bearbeitet jeweils ein Element, ein
+Formular, ein Playbook oder eine Workflow-Datei, mit seinen Bereichen im linken Menü. Jede Dateiart braucht außerdem eine eigene Option, alle
+standardmäßig eingeschaltet: `allowPlaybookDesign` für die **Playbooks**, `allowWorkflowDesign` für die **Workflows**,
+`allowInventoryDesign` für die **Inventare** und `allowVarsFileDesign` für die **Variablendateien**. Fehlt eine, ist ihr Bereich
+schreibgeschützt, und der Server verweigert das Speichern, Erstellen, Entfernen und Pushen ihrer Dateien; Formulare und Workflows können sie trotzdem auswählen. Die
+**Formulare**, **Kategorien** und **Konstanten** brauchen auf dieselbe Weise `allowFormDesign`: Ohne diese Option sind sie schreibgeschützt, und der Server
+verweigert das Speichern, Pullen und Pushen. Es bearbeitet immer nur eine Person gleichzeitig: siehe [Die Designer-Sperre](lock.html).
+
+---
+
+## Seine Bereiche
+
+Jeder Bereich bearbeitet eine Dateiart, lokal oder in einem [Repository](../repositories/) abgelegt:
+
+| Bereich | Was er bearbeitet |
+|---|---|
+| **Formulare** | Die Formulardateien |
+| **Kategorien** | Die Kategorien von `config.yaml` |
+| **Konstanten** | Die Konstanten von `config.yaml` |
+| **Variablendateien** | Die Variablendateien, die Formulare laden |
+| **Playbooks** | Die Playbooks, die Formulare und Workflows ausführen |
+| **Inventare** | Die Inventare: `inventory.yaml`, `group_vars` und `host_vars` |
+| **Workflows** | Die [Workflow](../workflows/)-Dateien |
+
+Die Bereiche mit Dateien listen sie in einem Datei-Explorer auf und öffnen die erste; ein Bereich ohne Dateien sagt das. Der
+Bereich **Formulare** und jeder Dateibereich haben an erster Stelle ihrer Werkzeugleiste eine Schaltfläche **Neue Datei**: In den Inventaren erstellt sie ein neues
+Inventar, in den Workflows einen neuen, leeren Workflow. Die Lupe des Explorers öffnet ein Feld, das seine Dateien nach Namen filtert.
+
+Das Suchfeld in der Titelzeile findet einen Text im geöffneten YAML: Es markiert jede Stelle, an der er vorkommt. Es funktioniert im
+Tab **YAML**, sobald Sie die Designer-Sperre haben.
+
+---
+
+## Seine Tabs
+
+Jeder Bereich hat dieselben drei Tabs, alle auf demselben YAML: Eine Änderung in einem erscheint in den anderen, und **Speichern** speichert sie.
+
+- **YAML** ist die Datei, wie sie geschrieben ist.
+- **Visuell** bearbeitet sie mit Feldern. Nur die Schlüssel, die eine Änderung berührt, ändern sich, sodass Kommentare und der Rest so bleiben, wie sie geschrieben sind.
+- **Vorschau** zeigt, was sie bewirkt, und bearbeitet nichts.
+
+Was die Tabs Visuell und Vorschau zeigen, Bereich für Bereich:
+
+| Bereich | Visuell | Vorschau |
+|---|---|---|
+| **Formulare** | Die Einstellungen des Formulars und seine Felder, mit Listen der Playbooks, Inventare und Workflows des Designers | Das Formular, wie es gerade ist, nicht gespeicherte Änderungen eingeschlossen; sein Absenden führt nichts aus |
+| **Kategorien** | Die Kategorien als Tabelle, bearbeitbar | Das Menü der Seite Formulare, daraus aufgebaut |
+| **Konstanten** | Die Konstanten als Gliederung, bearbeitbar (ein Schlüssel lässt sich mit den Pfeiltasten verschieben) | Jede Konstante mit ihrem Verweis, `$(NAME)`, zum Kopieren, und die Formulare, die sie verwenden |
+| **Variablendateien** | Die Variablen, bearbeitbar | Jede Variable mit ihrem Verweis in einem Playbook, {% raw %}`{{ name }}`{% endraw %}, zum Kopieren, und die Formulare, die die Datei laden |
+| **Playbooks** | Die Plays: Name, Hosts, **Become**, **Facts sammeln** und Rollen jedes Plays, und seine Tasks, jeder mit Modul und Argumenten | Die Gliederung des Playbooks: seine Plays, mit ihren Hosts, Rollen und Tasks, und die Playbooks, die es importiert |
+| **Inventare** | Die Gruppen, ihre Untergruppen, ihre Hosts und die Variablen, die jede setzt | Das Inventar als Baum, mit seinen `group_vars` und `host_vars` |
+| **Workflows** | Der Graph des Workflows, um [ihn zu bearbeiten](../workflows/designer.html) | Ein [Probelauf](../workflows/designer.html#trying-it-out): Klicken Sie auf einen Knoten, damit er fehlschlägt |
+
+Wenn das YAML nicht gelesen werden kann, sagen die Tabs Visuell und Vorschau, warum, mit **In YAML zeigen**, um das YAML in der Zeile zu öffnen.
diff --git a/i18n/de/_use/designer/lock.md b/i18n/de/_use/designer/lock.md
new file mode 100644
index 0000000..25d3a85
--- /dev/null
+++ b/i18n/de/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: Die Designer-Sperre
+parent: Designer
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# Die Designer-Sperre
+{: .no_toc }
+
+Es bearbeitet immer nur eine Person gleichzeitig
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Sperre übernehmen
+
+Der Designer ist aus, bis Sie ihn mit dem Schalter oben rechts im Designer einschalten. Das Einschalten übernimmt die
+Sperre: Ab dann sind Sie der Einzige, der speichern kann, bis Sie ihn wieder ausschalten.
+
+Ohne die Sperre zeigt der Designer **Designer ist nicht aktiv**, und es lässt sich nichts bearbeiten.
+
+Speichervorgänge überschneiden sich nie: Ab 7.3.0 wird, solange ein Speichern, ein Push oder ein Laden läuft, ein zweites **Speichern** (ein Doppelklick oder gedrückt gehaltenes Strg+S)
+ignoriert, sodass es kein zweites Backup und keinen zweiten Commit schreiben kann, der mit dem ersten konkurriert.
+
+---
+
+## Wenn jemand anderes sie hat
+
+Solange ein anderer Benutzer die Sperre hält, zeigt der Designer **Der Designer wird von** diesem Benutzer **verwendet**, und sonst nichts: keine Bereiche,
+keine Dateien.
+
+Der Schalter erscheint eingeschaltet, aber ausgegraut, mit **Gesperrt von** und dem Namen des Benutzers daneben. Sie können die Sperre übernehmen, sobald dieser
+den Designer ausschaltet. Jeder geöffnete Designer sieht sofort, wenn die Sperre übernommen oder freigegeben wird, ohne Neuladen.
+
+Wenn zwei Benutzer den Designer im selben Moment einschalten, erhält einer von ihnen die Sperre. Ab 7.3.0 sieht der andere, wer sie hält,
+und jeder Editor bleibt schreibgeschützt, sodass sich nichts eintippen lässt, was nicht gespeichert werden könnte.
+
+---
+
+## Die Sperre eines anderen freigeben
+
+Ein Admin kann eine Sperre freigeben, die jemand anderes hält, etwa wenn dieser mit geöffnetem Designer nach Hause gegangen ist.
+
+**Freigeben**, neben **Gesperrt von**, erscheint nur für Admins. Es fragt zuerst nach: Die nicht gespeicherten Änderungen des Benutzers gehen verloren.
+
+Ab 7.3.0 erfährt der Benutzer, dessen Sperre freigegeben wurde, davon und von wem: **Ihre Designer-Sperre wurde von** dem Namen des Admins **freigegeben**,
+mit **Nicht gespeicherte Änderungen können nicht mehr gespeichert werden.** Sein Designer übernimmt die Sperre nicht von selbst zurück; er schaltet ihn wieder ein,
+wenn er weitermachen will.
+
+---
+
+## Eine vergessene Sperre
+
+Eine Sperre, die niemand nutzt, gibt sich selbst frei, sodass niemand auf einen Designer wartet, den niemand geöffnet hat.
+
+Der geöffnete Designer des Inhabers teilt dem Server laufend mit, dass er noch da ist. Hat der Server
+5 Minuten lang nichts von ihm gehört, weil der Browser geschlossen, der Computer heruntergefahren wurde oder das Netzwerk weg ist, ist die Sperre wieder frei. Kehrt
+der Inhaber zum Designer zurück, übernimmt dieser die Sperre wieder, sofern niemand anderes sie hat. Die Freigabe durch einen Admin ist die Ausnahme: Danach wird die
+Sperre nicht zurückgenommen.
diff --git a/i18n/de/_use/jobs/actions.md b/i18n/de/_use/jobs/actions.md
new file mode 100644
index 0000000..aaebfeb
--- /dev/null
+++ b/i18n/de/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Job-Aktionen
+parent: Jobs
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Job-Aktionen
+{: .no_toc }
+
+Einen Job starten, abbrechen, neu starten, genehmigen oder ablehnen und löschen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Einen Job starten
+
+Jeder Job beginnt mit einem Formular. Öffnen Sie es auf der Seite **Formulare**, füllen Sie die Felder aus und klicken Sie auf **Senden**:
+
+1. Das Formular wird im Browser validiert, und die Feldwerte werden an den Server gesendet.
+2. Der Server erstellt den Job und gibt seine Nummer zurück; die [`onSubmit`](../forms/job-status-action.html)-Aktionen des Formulars laufen.
+3. Die Ausgabe des Jobs erscheint unter dem Formular und wird alle zwei Sekunden aktualisiert, bis der Job endet.
+
+Der Job erscheint auch auf der Seite **Jobs**, wo Sie ihn später verfolgen können.
+
+### Wer ein Formular starten kann
+
+Ein Formular wird für Benutzer aufgelistet und kann von ihnen gestartet werden, die eine der [Rollen](../config/roles.html) in seiner Liste `roles` haben.
+Die Rolle `default`, die jeder Benutzer hat, macht ein Formular für alle verfügbar, die sich anmelden können.
+
+### Vor dem Senden
+
+Die Leiste über den Feldern bietet einige Werkzeuge, jedes nur sichtbar, wenn Ihre Rolle es erlaubt:
+
+| Schaltfläche | Was sie macht | Rollenoption |
+|---|---|---|
+| **Extra-Variablen anzeigen** | Zeigt eine Vorschau der Extravars, die der Job erhalten wird, während Sie die Felder ausfüllen | `showExtraVars` |
+| **verbose** | Führt den Job im Verbose-Modus aus | `allowVerboseMode` |
+| **Aus Speicher laden** | Füllt die Felder aus einem [gespeicherten Job](stored-jobs.html) | `allowStoredJobs` |
+| **Dieses Formular neu laden** | Lädt das Formular erneut, mit seinen Standardwerten | keine |
+
+### Auswahl beim Start
+
+Ein Formular kann seine Benutzer beim Start einige Ansible-Optionen wählen lassen, indem es ein Feld mit einem reservierten Namen deklariert. Der
+Wert des Felds überschreibt dann die eigene Einstellung des Formulars:
+
+| Feldname | Überschreibt | Typischer Feldtyp |
+|---|---|---|
+| `__check__` | Check-Modus, ein Probelauf, der nichts ändert | `checkbox` |
+| `__diff__` | Diff-Modus, der zeigt, was sich ändern würde | `checkbox` |
+| `__limit__` | Die Hosts, auf denen das Playbook läuft | `text` oder `enum` |
+| `__tags__` | Die auszuführenden Tags | `text` oder `enum` |
+| `__inventory__` | Das Inventar | `enum` |
+| `__playbook__`, `__template__` | Das Playbook oder die AWX-/AAP-Vorlage | `enum` |
+
+Zum Beispiel ein Formular, das einen Probelauf und eine Host-Begrenzung anbietet:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+Der Server akzeptiert diese Namen nur von einem Formular, das sie als Felder deklariert, sodass ein Start über die API sie nicht
+eigenmächtig hinzufügen kann. Die Eigenschaften, die sie überschreiben, sind bei [Ansible-Formulare](../forms/ansible.html) und [AWX-Formulare](../forms/awx.html) beschrieben.
+
+### Was einen Start aufhalten kann
+
+Ein Start wird nicht immer sofort zu einem laufenden Job:
+
+* **Ungültige Felder** : Das Formular wird nicht abgesendet, und jedes Feld, das seine Validierung nicht besteht, zeigt den Grund.
+* **Start-Validierung** : Mit der [Start-Validierung](../launch-validation/) auf `enforce` prüft der Server die Werte
+  erneut und lehnt einen Start ab, der die Regeln des Formulars verletzt.
+* **Genehmigung** : Ein Formular mit einem [Genehmigungspunkt](../forms/approval.html) erstellt den Job, der dann im Status
+  `approve` wartet; siehe [Einen Job genehmigen oder ablehnen](#approve-or-reject-a-job).
+
+Wenn der Job endet, senden die [Benachrichtigungen](../forms/notifications.html) des Formulars ihre Mails und Kanalnachrichten, und seine
+Aktionen bei Jobstatus laufen.
+
+### Andere Wege, einen Job zu starten
+
+Ein Formular kann einen Job auch starten, ohne dass eine Person auf **Senden** klickt:
+
+| Gestartet von | Wie | Seite |
+|---|---|---|
+| Später ausführen oder ein Cron-Zeitplan | **Später ausführen (einmalig)** oder **Planen (wiederkehrend)** neben **Senden** | [Zeitpläne](schedules.html) |
+| Ein Skript oder eine Pipeline | `POST /api/v2/job` mit einem API-Token | [Jobs über die REST-API](../api/jobs.html) |
+| Ein KI-Agent | Das Tool `launch_job` des MCP-Servers | [MCP-Tools](../mcp/tools.html) |
+| Eine Unterhaltung | Der Chat-Assistent füllt das Formular aus und startet es | [Chat-Assistent](../chat/) |
+| Ein früherer Job | **Neu starten**, siehe unten | [Einen Job neu starten](#relaunch-a-job) |
+
+---
+
+## Einen Job abbrechen
+
+**Abbrechen** im Zeilenmenü (⋮) der Liste oder **Job abbrechen** auf der Seite des Jobs stoppt einen Job mit Status `running`. Nach Ihrer Bestätigung
+markiert AnsibleForms den Job zum Abbruch:
+
+* **`ansible`**: Das RTE stoppt den Playbook-Prozess (mit allen seinen Workern), und der Job endet als `aborted` mit
+  `... was aborted by the operator`. Ein Job, der noch auf ein freies RTE wartet, wird abgebrochen, bevor er startet.
+* **Ein Vorlagen-Job** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): AnsibleForms bittet den Runner, den Job abzubrechen oder zu stoppen,
+  und der Job endet als `aborted`. Lehnt der Runner ab, zeigt die Ausgabe `Abort request denied`, gefolgt von
+  `reverting abort request`, und der Job läuft weiter. Ein Jenkins-Build, der noch in der Warteschlange steht, wird daraus entfernt.
+* **`workflow`**: Die laufenden Knoten-Jobs werden abgebrochen, und es startet nichts mehr (siehe
+  [Einen Workflow ausführen](../workflows/running.html#abort)).
+* **`multistep`**: Die Schritte, die noch nicht gestartet sind, werden übersprungen (`skipping: [Abort is requested]`), und der Hauptjob
+  endet als `aborted`. Ein Schritt, der bereits läuft, ist ein eigener Job: Öffnen Sie ihn und brechen Sie ihn ab, um auch ihn zu stoppen.
+
+Sie können Ihre eigenen Jobs abbrechen; ein Admin oder ab 7.3.0 ein Benutzer, dessen Rolle `manageAllJobs` setzt, kann jeden Job abbrechen. `showAllJobLogs` lässt einen
+Benutzer die Jobs anderer Benutzer sehen, aber nicht abbrechen.
+
+---
+
+## Einen Job neu starten
+
+**Neu starten** im Zeilenmenü (⋮) der Liste oder **Job neu starten** auf der Seite des Jobs startet einen neuen Job aus einem beendeten. Es wird bei jedem
+Job angeboten, der weder `running` ist noch auf eine Genehmigung wartet, für Benutzer, deren Rolle die Rollenoption `allowJobRelaunch` setzt.
+
+Der Dialog bietet:
+
+* **Neu starten**: Führt den Job erneut mit den Werten aus, mit denen er lief, als neuen Job unter Ihrem Namen.
+* **Verbose-Modus**: Startet im Verbose-Modus neu; sichtbar mit der Rollenoption `allowVerboseMode`.
+* **Werte vor dem Neustart bearbeiten**, dann **Bearbeiten und neu starten**: Öffnet das Formular mit den Werten des Jobs vorausgefüllt, sodass Sie
+  sie vor dem Absenden ändern können.
+
+Ein Neustart setzt außerdem voraus, dass das Formular ihn erlaubt (`allowRelaunch`, standardmäßig true) und dass der Job **Ihr eigener** ist, es sei denn,
+Sie sind Admin oder haben ab 7.3.0 `manageAllJobs`; `showAllJobLogs`, womit sich bis 7.2 jeder Job neu starten ließ, reicht dafür nicht mehr. Wie ein Neustart gegen die Regeln des Formulars geprüft wird und warum ein Formular mit einem
+Passwortfeld ihn ablehnen kann, ist unter [Neustarten](../launch-validation/relaunching.html) beschrieben.
+
+### Mit vorausgefüllten Daten neu starten
+
+**Bearbeiten und neu starten** öffnet das Formular mit dem URL-Parameter `prefillJobId`, den Sie auch in einem eigenen Link verwenden können:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+Das Formular lädt die mit Job `61` gespeicherten Feldwerte und zeigt `Formular mit den Daten des vorherigen Jobs #61 vorausgefüllt`.
+Das Absenden startet einen neuen Job, der wie jeder andere Start geprüft wird. Das Vorausfüllen folgt denselben Regeln wie ein Neustart:
+
+* **Passwortfelder werden nie gespeichert**, also auch nie vorausgefüllt: Geben Sie sie erneut ein. Konstanten werden ebenfalls nicht gespeichert.
+* Die Rollenoption `allowJobRelaunch` ist erforderlich, und der Job muss Ihr eigener sein (oder Sie sind Admin oder haben `manageAllJobs`).
+* Ein Formular mit `allowRelaunch: false` kann weder neu gestartet noch vorausgefüllt werden:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Ein Job aus der Zeit, bevor die Feldwerte gespeichert wurden, kann nicht vorausgefüllt werden, und das Formular zeigt stattdessen einen Fehler:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Einen Job genehmigen oder ablehnen
+
+Ein Job mit einem [Genehmigungspunkt](../forms/approval.html) hält im Status `approve` an und wartet. Er wird auf der Jobs-Seite
+seiner Genehmiger aufgelistet, der Benutzer mit einer der Rollen der Genehmigung, damit sie ihn finden; ab 7.3.0 sehen andere Benutzer ihn nicht mehr.
+
+**Genehmigung prüfen** wird Admins und Benutzern angeboten, die eine der Rollen der Genehmigung haben: ein Klick auf die Zeile des Jobs,
+**Genehmigung prüfen** im Zeilenmenü oder die Schaltfläche **Genehmigung prüfen** auf der Seite des Jobs. Der Dialog zeigt die Nachricht
+der Genehmigung, mit den eingesetzten Werten des Jobs (oder eine allgemeine Zeile, wenn es keine gibt), sowie das Formular, die Job-ID, wer ihn gestartet hat und
+wann, mit einem Link zum Job; **Ablehnen** und **Freigeben** beantworten sie:
+
+* **Freigeben**: Der Job läuft weiter, und sein Status wechselt zurück zu `running`.
+* **Ablehnen**: Der Job endet als `rejected`, und seine Ausgabe vermerkt `rejected by <username>`.
+
+Ein Job, der auf eine Genehmigung wartet, kann auf der Jobs-Seite weder neu gestartet noch gelöscht werden; genehmigen oder lehnen Sie ihn zuerst ab.
+
+Ab 7.3.0 kann der Benutzer, der einen Job gestartet hat, ihn nicht genehmigen, sodass immer eine zweite Person ihn ansieht; ablehnen kann er ihn aber weiterhin, um
+ihn zurückzuziehen. Ein Admin kann immer genehmigen, auch die eigenen Jobs. Ein Formular, dessen Genehmigungspunkt
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) setzt, lässt auch den Starter seinen eigenen Job genehmigen.
+
+---
+
+## Einen Job löschen
+
+**Löschen** im Zeilenmenü (⋮) der Liste oder **Job löschen** auf der Seite des Jobs löscht einen Job mit seiner Ausgabe nach Ihrer Bestätigung.
+Das Löschen eines Multistep-Jobs löscht auch seine Schritte. Um mehrere Jobs auf einmal zu löschen, markieren Sie sie in der ersten Spalte der Liste und
+klicken Sie darüber auf **Löschen (n)**.
+
+Sie können Ihre eigenen Jobs löschen. Admins und ab 7.3.0 Benutzer mit der Rollenoption `manageAllJobs` können jeden Job löschen; `showAllJobLogs`
+kann das nicht mehr. Eine Rolle, die `allowJobDeletion: false` setzt, löscht gar keinen Job, nicht einmal die eigenen, sodass der Jobverlauf vollständig bleibt. Auf der Seite
+des Jobs ist die Schaltfläche ausgeblendet, solange der Job läuft oder abgebrochen wird (außer für Admins und `manageAllJobs`) und solange er auf eine Genehmigung wartet; in der Liste sind
+Menüeintrag und Kontrollkästchen für einen Job, den Sie nicht löschen können, ausgegraut.
diff --git a/i18n/de/_use/jobs/cleanup.md b/i18n/de/_use/jobs/cleanup.md
new file mode 100644
index 0000000..3950210
--- /dev/null
+++ b/i18n/de/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Bereinigung
+parent: Jobs
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Bereinigung
+{: .no_toc }
+
+Durch einen Neustart abgeschnittene Jobs, und wie lange beendete Jobs aufbewahrt werden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Verwaiste Jobs
+
+Ein laufender Job wird von dem AnsibleForms-Prozess verfolgt, der ihn gestartet hat. Endet diese Verfolgung, wird der Job als
+`abandoned` markiert:
+
+* **Beim Start** werden die Jobs, die dieser Prozess vor seinem Neustart verfolgt hat, und die Jobs aus der Zeit vor 7, die kein Prozess
+  verfolgt, als verwaist markiert, wenn sie noch `running` sind oder abgebrochen werden; das Protokoll zeigt `Abandoned <n> jobs`. Ein Job, der
+  auf einem RTE läuft, bleibt unberührt: Er läuft ohne den Prozess, der ihn gestartet hat, weiter.
+* **Jede Minute** werden die Jobs, die ein anderer AnsibleForms-Prozess (oder ein RTE) verfolgt, der seit 2 Minuten nicht mehr antwortet,
+  als verwaist markiert; das Protokoll zeigt `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Jede Stunde** werden Jobs, die vor mehr als einem Tag gestartet wurden, noch `running` sind und seit einem Tag keine Ausgabe geschrieben haben, als verwaist markiert.
+  Ein Job, der auf einem RTE läuft, bleibt auch hier unberührt: Das RTE räumt seine eigenen Jobs auf, wenn es neu startet.
+
+Ab 7.3.0 wird ein Vorlagen-Job auf AWX, AAP oder Ascender, den ein Neustart oder ein gestoppter Knoten verwaist hat, wieder aufgenommen, wenn er
+innerhalb der letzten 24 Stunden gestartet wurde: Ein AnsibleForms-Prozess übernimmt ihn, verfolgt ihn wieder auf dem Runner, und der Job endet mit dem, was
+dort tatsächlich passiert ist. Jobs auf den anderen Runnern, Playbooks, Workflows und Multistep-Jobs bleiben verwaist.
+
+Ein verwaistes Playbook ist möglicherweise teilweise gelaufen. Prüfen Sie die verwalteten Hosts, bevor Sie es neu starten; siehe
+[Ein Job zeigt den Status abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Aufbewahrung von Jobs
+
+Jobs werden aufbewahrt, bis sie gelöscht werden, sofern der Administrator keine Aufbewahrungsfrist setzt.
+
+Ist [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) gesetzt, löscht eine nächtliche Aufgabe (um 2:30)
+die beendeten Jobs, mit ihrer Ausgabe und ihren Schritten, die vor mehr als so vielen Tagen geendet haben. Sie entfernt nur Jobs mit
+Status `success`, `failed`, `warning`, `aborted`, `rejected` oder `abandoned`, sodass laufende Jobs und Jobs, die auf eine
+Genehmigung warten, unabhängig von ihrem Alter erhalten bleiben. Der Standard, `0`, bewahrt jeden Job auf.
diff --git a/i18n/de/_use/jobs/following.md b/i18n/de/_use/jobs/following.md
new file mode 100644
index 0000000..bad601d
--- /dev/null
+++ b/i18n/de/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Einen Job verfolgen
+parent: Jobs
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Einen Job verfolgen
+{: .no_toc }
+
+Live-Ausgabe, Extravars, Filter und Downloads
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Einen Job verfolgen
+
+Ein Klick auf einen Job öffnet seine Seite: das Formular des Jobs als Titel, seine Aktionen im Kopfbereich und darunter seine Ausgabe.
+
+![Die Ausgabe eines Jobs](../assets/screenshots/job-output.jpg)
+
+Ab 7.3.0 besteht die Seite aus Karten, und jede lässt sich unter ihrem Kopf einklappen:
+
+| Karte | Was sie zeigt |
+|---|---|
+| **Zusammenfassung** | Name, Status und Typ des Jobs als Kopf, und darunter seine Angaben in einem Raster mit drei Spalten (zwei, dann eine, auf einer schmalen Seite) |
+| **Workflow** | Bei einem Workflow-Job, auch einem Workflow-Job von AWX oder AAP, seinen Graph und seine Anzahl Knoten (siehe [Der Workflow-Graph](#the-workflow-graph)) |
+| **Ausgabe** | Die Ausgabe des Jobs und ihre Werkzeugleiste |
+
+Ein Job, der auf AWX, AAP, Ascender, Jenkins, Semaphore oder Rundeck lief, zeigt dort seine Nummer als Link zu seiner Seite in diesem Tool, geöffnet
+in einem neuen Tab. Der Link wird am Job gespeichert, sodass er auch funktioniert, wenn der Runner später umbenannt oder entfernt wird.
+
+Die Seite aktualisiert sich live: Der Server sendet jedes Mal ein Ereignis, wenn ein Job gestartet wird, seinen Status ändert, Ausgabe schreibt oder
+gelöscht wird, und die Seite liest den Job erneut, sodass die Ausgabe wächst, während der Job sie schreibt. Die Jobliste aktualisiert sich auf dieselbe Weise.
+**Aktualisieren** lädt den Job von Hand neu.
+
+Solange Sie am Ende der Ausgabe sind, folgt die Seite ihr nach unten, wenn neue Zeilen hinzukommen. Scrollen Sie nach oben, um eine frühere Zeile zu lesen,
+bleibt die Seite, wo Sie sind: **Zum Neuesten springen** erscheint dann über dem unteren Rand der Ausgabe und wird zu **Neue Zeilen**, sobald
+weitere hinzugekommen sind. Klicken Sie darauf oder scrollen Sie zurück ans Ende, um den neuen Zeilen wieder zu folgen. Die Ausgabe auf der Seite des Formulars nach
+**Senden** und das [Serverprotokoll](../production/logs.html) folgen ihren neuen Zeilen auf dieselbe Weise.
+
+Die Werkzeugleiste der Ausgabe enthält:
+
+| Schaltfläche | Was sie macht |
+|---|---|
+| **Extra-Variablen anzeigen** | Zeigt die Extravars, mit denen der Job lief, in einem Bereich über der Ausgabe, mit einem Umschalter **JSON** / **YAML** und **Kopieren** |
+| **Artefakte anzeigen** | Zeigt die Artefakte des Jobs im selben Bereich (siehe unten) |
+| **Parameter anzeigen** | Ersetzt bei einem Jenkins-Job **Extra-Variablen anzeigen**: die Werte, mit denen er lief, seine Build-Parameter |
+| **Payload anzeigen** | Ersetzt bei einem Rundeck-Job **Extra-Variablen anzeigen**: die Payload, die ihm gesendet wurde |
+| **Hosts und Tasks** | Zeigt die Hosts und Tasks eines Playbooks über seiner Ausgabe (siehe [Hosts und Tasks](#hosts-and-tasks)) |
+| **Aktualisieren** | Lädt die Ausgabe neu |
+| **Filter anwenden** | Blendet die Tasks aus, deren Name auf den Ausgabefilter passt; **Filter entfernen** zeigt sie wieder |
+| **Ausgabe kopieren** | Kopiert die Ausgabe als reinen Text, mit oder ohne angewendeten Filter |
+| **Ausgabe herunterladen** | Lädt die Ausgabe als `ansibleforms-job-<id>.txt` herunter |
+
+**Artefakte anzeigen** wird für jeden Job angeboten, der kein Vorlagen-Job ist, etwa ein Playbook auf dem RTE oder ein Workflow (leer, wenn
+seine Playbooks keine Artefakte mit `set_stats` gesammelt haben), und für einen Vorlagen-Job, der auf AWX, AAP oder Ascender lief. Jobs von Semaphore, Rundeck
+und Jenkins haben keine Artefakte, daher wird es für sie nie angeboten.
+
+Links in der Werkzeugleiste klappt die Schaltfläche **Alle einklappen** jeden Abschnitt der Ausgabe (jedes Play und jeden Task) ein und wird zu
+**Alle ausklappen**, das sie wieder aufklappt.
+
+**Extra-Variablen anzeigen** setzt die Rollenoption `showExtravars` voraus und **Artefakte anzeigen** die Rollenoption `showArtifacts` (siehe
+[Rollenoptionen](../config/roles.html#role-options)). Werte von Passwortfeldern und von Schlüsseln, die auf
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) passen, werden maskiert.
+
+Der Filter wird über [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) gesetzt, standardmäßig `\[low\]`.
+Setzen Sie `[low]` in den Namen eines geschwätzigen Tasks, und **Filter anwenden** blendet diesen Task und seine Zeilen aus.
+
+Die Seite eines Multistep-Jobs zeigt jeden Schritt unter dem Hauptjob, einen unter dem anderen, jeden unter einer Titelleiste wie
+**Schritt 1 · Prepare the server (Job-ID 98)** mit seinem Status. Klicken Sie auf einen Titel (oder drücken Sie darauf Enter oder Leertaste), um diese Ausgabe
+einzuklappen, und erneut, um sie aufzuklappen. AWX/AAP-Workflows zeigen auch den Status ihrer Knoten.
+
+[Workflow](../workflows/running.html#the-job)-Jobs enthalten die Ausgabe jedes Knotens in ihrer eigenen, unter einem Banner `WORKFLOW NODE` pro
+Knoten; sie zeichnen ihren Graph live, und ein Klick auf einen Knoten öffnet seine Ausgabe.
+
+---
+
+## Einen Text in der Ausgabe finden
+
+Ab 7.3.0 hat die Seite des Jobs in ihrer Titelzeile, links von den Aktionen des Jobs, ein Suchfeld, **In der Ausgabe suchen**.
+
+Jede Stelle, an der der Text in der Ausgabe vorkommt, wird hervorgehoben, unabhängig von Groß- und Kleinschreibung, und die Seite springt zur ersten. **Enter** geht zur
+nächsten, die stärker hervorgehoben wird, und die Werkzeugleiste zeigt, welche von wie vielen (**2 von 4**), oder **Nicht gefunden**. Die Suche klappt zuerst die Ausgabe und
+ihre Abschnitte auf, und während der Job läuft, werden auch die neuen Zeilen durchsucht, ohne dass die Seite springt.
+
+---
+
+## Durch eine lange Ausgabe navigieren
+
+Ab 7.3.0 bietet eine lange Ausgabe, auf der Seite des Jobs und unter einem Formular nach **Senden**, folgende Wege hindurch:
+
+| Element | Was es macht |
+|---|---|
+| Fixierte Köpfe | Der Kopf eines Abschnitts (ein Workflow-Knoten, das Playbook des Jobs, ein Schritt eines Multistep-Jobs) bleibt oben, während seine Zeilen vorbeiscrollen |
+| **2 fehlgeschlagen** | Zählt die fehlgeschlagenen Tasks, ohne die Fehler, die Ansible ignorieren sollte; jeder Klick springt zum nächsten, aufgeklappt und hervorgehoben. Ohne fehlgeschlagene Tasks zählt **1 Fehler** stattdessen die Fehlerzeilen |
+| Zeilennummern | Jede Zeilennummer verlinkt auf ihre Zeile, etwa `#L45` in der Adresse: Das Öffnen dieser Adresse scrollt zur Zeile und hebt sie hervor |
+| Schaltflächen nach oben und unten | Erscheinen unten rechts, sobald die Seite gescrollt ist, um zum Anfang oder ans Ende zu gelangen |
+| **Läuft** und **Abbrechen** | Während der Job läuft, bleibt die Leiste auf der Seite des Formulars am unteren Fensterrand, und **Abbrechen** dort stoppt den Job sofort |
+
+---
+
+## Task-Ergebnisse
+
+Ab 7.3.0 öffnet die Ergebniszeile eines Hosts in der Ausgabe eines Playbooks dieses Ergebnis in einem Dialog **Ergebnis der Aufgabe**, wie in AWX.
+
+Die Zeile, der Ergebnisinhalt danach (`=> { ... }`) und der vor einem fehlgeschlagenen Ergebnis ausgegebene Fehler werden beim Darüberfahren als ein Block hervorgehoben, und ein
+Klick öffnet den Dialog. Das funktioniert auf der Seite des Jobs und unter einem Formular nach **Senden**, für ein Playbook, das auf einem RTE ab 7.3.0
+lief, da das Ergebnis aus denselben Ereignissen stammt wie [Hosts und Tasks](#hosts-and-tasks). Der Dialog hat folgende Tabs:
+
+| Tab | Was er zeigt |
+|---|---|
+| **Details** | Status, Host, Play, Aufgabe, Modul, Schleifenelement, Startzeit, Dauer, Rückgabecode und Meldung |
+| **JSON** und **YAML** | Das gesamte Ergebnis des Moduls, farbig und mit nummerierten Zeilen |
+| **Standardausgabe** und **Standardfehler** | `stdout` und `stderr` des Ergebnisses, sofern vorhanden |
+
+Das gesamte Ergebnis, und damit die Tabs **JSON**, **YAML** und die Ausgabe-Tabs, wird nur gespeichert, wenn der Job im Verbose-Modus läuft, da die Ausgabe
+es dann ebenfalls zeigt; andernfalls zeigt der Dialog nur die Details. Auch im Verbose-Modus werden die Argumente des Moduls (`invocation`)
+weggelassen, Werte von Schlüsseln, die nach einem Secret aussehen, maskiert, und ein Ergebnis wird abgeschnitten, sobald es größer als 64 KB JSON ist.
+
+---
+
+## Der Workflow-Graph
+
+Ab 7.3.0 verschiebt sich der Graph eines laufenden Workflows, um den laufenden Knoten im Blick zu behalten.
+
+Scrollen Sie den Graph weg, bleibt er, wo Sie ihn hingesetzt haben, mit einer Schaltfläche **Dem laufenden Knoten folgen**, um ihm wieder zu folgen. Das Darüberfahren über einen Knoten
+zeigt seine Karte mit dem vollständigen Namen und rückt den Knoten und seine Verbindungen in den Fokus, der Rest des Graphs wird abgeblendet. Der Graph hat die Schaltflächen **An
+Bildschirm anpassen** und **Vollbild**, und unter einem Formular nach **Senden** öffnet ein Klick auf einen Knoten seine Ausgabe wie auf der Seite des Jobs.
+
+---
+
+## Hosts und Tasks
+
+Seit 7.3.0 zeichnet ein Playbook-Job, der auf einem RTE ab 7.3.0 lief, neben seiner Textausgabe seine strukturierten Ereignisse auf: jedes Play, jeden Task
+und jedes Host-Ergebnis sowie das Recap. **Hosts und Tasks** in der Werkzeugleiste der Ausgabe zeigt sie in einem Bereich über der Ausgabe, auf der Seite des Jobs und
+unter einem Formular nach **Senden**. Es wird angeboten, sobald der Job Ereignisse hat, und der Bereich wird alle paar Sekunden neu gelesen, während der Job läuft:
+
+| Ansicht | Was sie zeigt |
+|---|---|
+| **Raster** | Das Recap pro Host (ok, geändert, fehlgeschlagen, nicht erreichbar, übersprungen, gerettet, ignoriert), dann ein Raster aus Hosts und Tasks: Jede Zelle ist nach dem Ergebnis des Hosts für diesen Task eingefärbt, mit Meldung und Zeit beim Darüberfahren, oder *nicht ausgeführt* |
+| **Zeitleiste** | Jeden Task als Balken, so lang wie sein langsamster Host gebraucht hat, mit seiner Zeit in Sekunden und der Gesamtzeit |
+
+Die Textausgabe bleibt, wie sie ist. Die Ereignisse schreibt das eigene Callback-Plugin `af_events` des RTE, sodass das Playbook keine Änderung braucht.
diff --git a/i18n/de/_use/jobs/index.md b/i18n/de/_use/jobs/index.md
new file mode 100644
index 0000000..6d22f4e
--- /dev/null
+++ b/i18n/de/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Jobs
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Jobs
+{: .no_toc }
+
+Die Jobs, die Ihre Formulare starten, verfolgen, abbrechen, neu starten, genehmigen und löschen
+{: .fs-6 .fw-300 }
+
+---
+
+Für alle, die Formulare starten: was ein Job ist, wo Sie ihn finden und wer ihn sehen kann.
+
+---
+
+## Was ein Job ist
+
+Ein Job ist ein Lauf eines Formulars: AnsibleForms zeichnet ihn mit Status, Extravars und Ausgabe auf, sobald das Formular abgesendet wird.
+
+Jeder Job enthält:
+
+* das **Formular**, das er ausgeführt hat, und den **Benutzer**, der ihn gestartet hat (mit dem Benutzertyp, etwa `local` oder `ldap`);
+* seinen **Job-Typ** und **Status** sowie seine **Startzeit** und **Endzeit**;
+* seine **Ausgabe**, die Extravars und Zugangsdaten, mit denen er lief, und die im Formular eingegebenen Feldwerte.
+
+Ein mehrstufiges Formular erstellt einen Job für das Formular und einen Job pro Schritt. Die Schritte sind mit dem Hauptjob verknüpft und werden darunter aufgelistet.
+
+Dieselben Jobs lassen sich über die [REST-API](../api/jobs.html) starten, verfolgen und verwalten.
+
+---
+
+## Die Seite Jobs
+
+Der Link **Jobs** im Kopfbereich öffnet die Liste aller Jobs, die neuesten zuerst (`/jobs/all`). Die Seite und ihr Link werden Benutzern angezeigt,
+deren Rolle die [Rollenoption](../config/roles.html#role-options) `showJobs` setzt.
+
+![Die Jobliste](../assets/screenshots/job-log.jpg)
+
+Das linke Menü ordnet die Jobs zeitlich, mit der Anzahl der Jobs in jedem Eintrag; ein Statuseintrag filtert die Liste nach diesem Status:
+
+| Abschnitt | Menüeintrag | Zeigt |
+|---|---|---|
+| **Vergangenheit** | **Erfolgreich** | Jobs mit Status `success` |
+| | **Fehlgeschlagen** | Jobs mit Status `failed` |
+| | **Abgebrochen** | Jobs mit Status `aborted` |
+| | **Abgelehnt** | Jobs mit Status `rejected` |
+| | **Verwaist** | Jobs mit Status `abandoned` |
+| **Gegenwart** | **Läuft** | Jobs mit Status `running` |
+| | **Wartet auf Genehmigung** | Jobs mit Status `approve`; die Anzahl wird orange, wenn einer wartet |
+| **Zukunft** | **Geplant** | Die Seite [Zeitpläne](schedules.html) (Rollenoption `allowScheduledJobs`) |
+| | **Gespeichert** | Die Seite [Gespeicherte Jobs](stored-jobs.html) (Rollenoption `allowStoredJobs`) |
+
+Das Menü hat keinen Eintrag für alle Jobs: Der Link **Jobs** im Kopfbereich zeigt sie alle, auch die `warning`-Jobs.
+
+Über der Tabelle, in der Titelzeile:
+
+* das **Suchfeld** behält die Jobs, deren angezeigte Spalten den Text enthalten (ohne Beachtung der Groß- und Kleinschreibung), oder bei denen einer der Schritte ihn als ID
+  oder Ziel hat;
+* **Löschen** (mit der Anzahl der markierten Jobs) löscht die in der ersten Spalte markierten Jobs gemeinsam;
+* **Spalten** blendet die Spalten `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` und `user` ein oder aus;
+  die Dauer eines laufenden Jobs zählt hoch;
+* **Aktualisieren** lädt die Liste neu.
+
+Die Liste lädt die neuesten Jobs, so viele, wie die Einstellung [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) angibt
+(**Einstellungen > System > Allgemein**, Tab **Jobs**, standardmäßig `1000`); ihre Seiten, Suche und Filter beziehen sich auf diese Jobs.
+
+Jede Spalte lässt sich sortieren und hat ein eigenes Filterfeld. Ein Multistep-Job hat direkt vor seinem `form` einen Pfeil, der
+seine Schritte aufklappt; ein Klick auf den Rest einer Zeile öffnet den Job.
+
+Die Glocke im Kopfbereich zählt die Jobs, die auf Ihre Genehmigung warten, und öffnet die Liste bei **Wartet auf Genehmigung**. Für die Benutzer, die
+die Runner sehen können, zählt sie auch die [Runner, die auf Freigabe warten](../runners/registration.html#approving-an-rte), also RTEs, die beitreten wollen,
+und öffnet **Verbindungen > Runner**, wenn nur Runner warten. Warten beide, öffnet sie ein Menü, **Jobs warten auf Freigabe** und
+**Runner warten auf Freigabe**, jeweils mit ihrer Anzahl.
+
+---
+
+## Wer welche Jobs sieht
+
+Welche Jobs ein Benutzer sieht, hängt von seinen Rollen ab:
+
+| Benutzer | Sieht |
+|---|---|
+| Admin (Rolle `admin`) | Jeden Job |
+| Rollenoption `showAllJobLogs` | Jeden Job |
+| Rollenoption `manageAllJobs` (ab 7.3.0) | Jeden Job, und darf ihn abbrechen, löschen und neu starten |
+| Jeder andere Benutzer | Seine eigenen Jobs und die Jobs, die auf eine Genehmigung warten, die eine seiner Rollen nennt |
+
+Bis 7.2 konnte jeder Benutzer jeden Job öffnen, der auf eine Genehmigung wartete, einschließlich Extravars und Ausgabe; ab 7.3.0 können das nur sein Besitzer und seine
+Genehmiger. Einen Job zu sehen, erlaubt nicht jede Aktion darauf: Den Job eines anderen Benutzers abzubrechen, zu löschen und neu zu starten, erfordert einen Admin oder
+`manageAllJobs`, und `showAllJobLogs` zeigt die Jobs nur an. Löschen braucht außerdem `allowJobDeletion` und Neustarten `allowJobRelaunch`.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Status und Typen](statuses.html) | Jeder Status, den ein Job haben kann, und die Arten von Jobs |
+| [Einen Job verfolgen](following.html) | Live-Ausgabe, Extravars, Filter und Downloads |
+| [Job-Aktionen](actions.html) | Einen Job starten, abbrechen, neu starten, genehmigen oder ablehnen und löschen |
+| [Zeitpläne](schedules.html) | Ein Formular später oder nach einem Cron-Zeitplan ausführen, und alle Zeitpläne verwalten |
+| [Gespeicherte Jobs](stored-jobs.html) | Die Daten eines Formulars aufbewahren, um sie später wieder zu laden |
+| [Bereinigung](cleanup.html) | Durch einen Neustart abgeschnittene Jobs, und wie lange beendete Jobs aufbewahrt werden |
diff --git a/i18n/de/_use/jobs/schedules.md b/i18n/de/_use/jobs/schedules.md
new file mode 100644
index 0000000..eacf71b
--- /dev/null
+++ b/i18n/de/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Zeitpläne
+parent: Jobs
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Zeitpläne
+{: .no_toc }
+
+Ein Formular später oder nach einem Cron-Zeitplan ausführen, und alle Zeitpläne verwalten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Formularaktionen
+
+Ein Formular kann mehr als sofort ausgeführt werden: Das Dropdown neben seiner Schaltfläche **Senden** enthält drei weitere Aktionen.
+
+| Aktion | Was sie macht | Rollenoption |
+|---|---|---|
+| **Planen (wiederkehrend)** | Erstellt einen Zeitplan, der das Formular nach einem Cron-Ausdruck ausführt | `allowScheduledJobs` |
+| **Später ausführen (einmalig)** | Erstellt einen Zeitplan, der das Formular einmal ausführt, zu einem Datum und einer Uhrzeit Ihrer Wahl | `allowPlannedJobs` |
+| **Speichern** | Speichert die Feldwerte, um sie später wieder ins Formular zu laden | `allowStoredJobs` |
+
+Eine Aktion, deren Rollenoption aus ist, wird nicht angezeigt. Das Formular wird vor jeder von ihnen validiert, wie bei **Senden**. Beide
+Planungsaktionen erstellen einen Eintrag auf der Seite **Zeitpläne**; **Speichern** erstellt einen Eintrag auf der Seite **Gespeicherte Jobs**. Die
+Seitenleiste der Seite [Jobs](./) öffnet sie unter **Zukunft**, als **Geplant** und **Gespeichert**. Die Rollenoptionen sind
+unter [Rollenoptionen](../config/roles.html#role-options) beschrieben.
+
+{: .warning }
+> Behandeln Sie `allowScheduledJobs` als Option auf Admin-Ebene. Ihre Zeitpläne gehören nicht dem Benutzer, der sie erstellt hat: Jeder Benutzer
+> mit der Option sieht alle Zeitpläne und kann sie ändern. Ein solcher Zeitplan läuft außerdem mit Admin-Rechten, für jedes Formular, unabhängig vom
+> eigenen Zugriff seines Erstellers. Gewähren Sie sie nur Rollen, denen Sie wie Admins vertrauen würden.
+
+{: .note }
+> **Später ausführen (einmalig)** braucht nur `allowPlannedJobs`. Für einen Benutzer ohne `allowScheduledJobs` plant es einen Lauf **als dieser
+> Benutzer**: Der Server prüft, ob der Benutzer das Formular ausführen darf, und der Job läuft als er, in seinem Besitz, wenn seine Zeit gekommen ist
+> (siehe [Geplante Läufe](#planned-runs)).
+
+---
+
+## Ein Formular planen
+
+Füllen Sie das Formular aus, öffnen Sie dann das Dropdown neben **Senden** und wählen Sie eine der Planungsaktionen.
+
+- **Planen (wiederkehrend)** öffnet **Zeitplan erstellen**: Geben Sie einen **Namen** und einen **Cron-Ausdruck** ein (der Standard, `0 0 * * *`,
+  läuft täglich um Mitternacht), und wählen Sie dann **Zeitplan erstellen**.
+- **Später ausführen (einmalig)** öffnet **Später ausführen**: Geben Sie einen **Namen** ein und wählen Sie Datum und Uhrzeit unter **Ausführen um**, dann
+  **Job planen**.
+
+Der Name muss über alle Zeitpläne hinweg eindeutig sein. Der Zeitplan behält den Namen des Formulars und eine Kopie der Extravars, die das Formular
+in diesem Moment erzeugt hat, als YAML geschrieben; jeder Lauf verwendet diese Kopie, bearbeiten Sie sie also auf der Seite **Zeitpläne**, um zu ändern, was der Job erhält.
+
+![Zeitpläne](../assets/screenshots/schedules.jpg)
+
+---
+
+## Die Seite Zeitpläne
+
+Die Seite **Zeitpläne** listet jeden Zeitplan auf, ab 7.3.0 mit der Spalte **Aktiviert**, und braucht `allowScheduledJobs`. Das Menü jeder Zeile bietet:
+
+| Aktion | Was sie macht |
+|---|---|
+| **Bearbeiten** | Ändert Name, Typ, Cron-Ausdruck oder Ausführungszeit, Formular und Extra-Variablen |
+| **Jetzt ausführen** | Führt den Zeitplan jetzt aus, ohne auf seinen Cron-Ausdruck oder seine Ausführungszeit zu warten |
+| **Aktivieren** oder **Deaktivieren** | Schaltet den Zeitplan ein oder aus, je nachdem, was zutrifft, wie seine Spalte **Aktiviert** zeigt (ab 7.3.0) |
+| **Löschen** | Entfernt den Zeitplan; er läuft sofort nicht mehr |
+| **Letzte Ausgabe** | Auf der Seite des Zeitplans, was der letzte Lauf gemeldet hat, etwa die Nummer des Jobs, den er gestartet hat |
+
+Ein Zeitplan lässt sich hier auch von Grund auf erstellen. Wählen Sie das **Formular**, dann markieren Sie entweder **Einmaliger Lauf** und setzen
+**Ausführen um**, oder Sie lassen es leer und setzen einen **Cron-Zeitplan**. **Extra-Variablen** ist YAML ohne Formular, das es füllt; fügen Sie die
+Werte, die das Playbook braucht, also selbst hinzu, als Dictionary (Schlüssel-Wert-Paare).
+
+Das Feld **Cron-Zeitplan** ist ein Cron-Editor: Er beschreibt den Ausdruck in Worten, bietet Vorlagen und zeigt eine Vorschau der nächsten
+Läufe. Der Server lehnt einen Ausdruck ab, den er nicht ausführen kann oder der nie eintreten kann.
+
+Ab 7.3.0 hat jeder Zeitplan einen Schalter **Aktiviert**, um ihn zu pausieren, ohne ihn zu löschen. Ein ausgeschalteter Zeitplan bleibt mit seinen Einstellungen
+auf der Seite, läuft aber nicht von selbst: Ein wiederkehrender überspringt seine Cron-Zeitpunkte, und ein einmaliger wartet über sein
+**Ausführen um** hinaus, bis er wieder eingeschaltet wird. **Jetzt ausführen** führt ihn weiterhin bei Bedarf aus. Ein neuer Zeitplan ist eingeschaltet, und die Zeitpläne,
+die vor 7.3.0 existierten, sind nach dem Upgrade eingeschaltet.
+
+---
+
+## Cron-Ausdrücke und Zeitzone
+
+Ein wiederkehrender Zeitplan nimmt einen Standard-Cron-Ausdruck mit 5 Feldern: Minute, Stunde, Tag des Monats, Monat und Wochentag.
+
+| Ausdruck | Läuft |
+|---|---|
+| `*/15 * * * *` | Alle 15 Minuten |
+| `0 2 * * *` | Jeden Tag um 02:00 |
+| `30 7 * * 1-5` | Montag bis Freitag um 07:30 |
+| `0 0 1 * *` | Um Mitternacht am ersten Tag jedes Monats |
+
+Weitere Beispiele und die Cron-Funktionen, die der Editor nicht akzeptiert, stehen in der FAQ unter
+[Welche Cron-Ausdrücke kann ich verwenden?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Cron-Zeitpläne laufen in der Zeitzone des Servers, gesetzt mit [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (Standard `UTC`),
+> nicht in der Zeitzone Ihres Profils oder Ihres Browsers. Der Cron-Editor zeigt die nächsten Läufe in derselben Zone an.
+
+---
+
+## Wie ein Zeitplan läuft
+
+Wenn ein Zeitplan fällig ist, wird er in die Warteschlange gestellt, und der Server startet Zeitpläne aus der Warteschlange einzeln nacheinander und prüft die Warteschlange alle 10 Sekunden.
+
+- **Wiederkehrende** Zeitpläne überspringen einen Zeitpunkt, solange der vorherige Lauf noch in der Warteschlange steht oder läuft, sodass sich Läufe nie überschneiden.
+- **Einmalige** Zeitpläne laufen innerhalb einer Minute nach **Ausführen um** und werden dann gelöscht, auch wenn sie mit **Jetzt ausführen** gestartet wurden.
+- **Status** ist `success`, wenn der Job gestartet wurde, und `failed`, wenn er nicht gestartet werden konnte. Ein `success` sagt nur, dass der Job
+  gestartet wurde: Öffnen Sie den Job, um zu sehen, wie er endete.
+
+Ein mit `allowScheduledJobs` erstellter Zeitplan läuft als integrierter Benutzer `Schedule Service` (Typ `schedule`) mit der
+Rolle `admin`. Er kann jedes Formular ausführen, unabhängig vom Zugriff der Person, die den Zeitplan erstellt hat, und `ansibleforms_user` in
+seinen Extravars beschreibt diesen Benutzer. Ein [geplanter Lauf](#planned-runs) läuft stattdessen als der Benutzer, der ihn geplant hat.
+
+Der Job erhält außerdem ein Objekt `schedule` (mit `id`, `name` und `form`), sodass ein Playbook weiß, dass ein Zeitplan es gestartet hat:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Geplante Läufe
+
+**Später ausführen (einmalig)** durch einen Benutzer ohne `allowScheduledJobs` erstellt einen geplanten Lauf: einen einmaligen Zeitplan, der an diesen Benutzer gebunden ist.
+
+- **Beim Planen** prüft der Server, ob der Benutzer das Formular ausführen darf (seine `roles`), und der Verbose-Modus braucht
+  `allowVerboseMode`. Ein geplanter Lauf ist immer einmalig; ein Cron-Ausdruck wird abgelehnt.
+- **Unter der Start-Validierung `enforce`** werden die Feldwerte beim Planen geprüft, sodass ein Lauf, der abgelehnt würde,
+  abgelehnt wird, während der Benutzer noch hinsieht.
+- **Beim Ausführen** läuft der Job als dieser Benutzer, in seinem Besitz, mit denselben Prüfungen wie ein Start aus dem Browser: die
+  Rollen des Formulars, wie sie dann sind, die entfernten reservierten Extravars und die Start-Validierung. `ansibleforms_user` beschreibt ihn.
+
+Der Planende sieht die Seite **Zeitpläne** nicht, die `allowScheduledJobs` braucht; der Job erscheint in seinem eigenen Jobverlauf.
+
+---
+
+## Wenn sich das Formular ändert
+
+Ein Zeitplan verweist über den Namen auf sein Formular und führt es so aus, wie es zum Zeitpunkt jedes Laufs definiert ist.
+
+- **Das Formular wird bearbeitet**: Der nächste Lauf verwendet die neue Definition (Playbook, Vorlage, Inventar) mit den im
+  Zeitplan gespeicherten Extravars. Das Formular wird nicht gerendert, sodass kein Feld neu berechnet wird; passen Sie die Extra-Variablen des Zeitplans entsprechend an.
+- **Das Formular wird umbenannt oder entfernt**: Der Lauf schlägt fehl, **Status** wird `failed`, und **Letzte Ausgabe** lautet
+  `Failed to launch : No such form '<name>'`. Bearbeiten Sie den Zeitplan und wählen Sie das richtige Formular, oder löschen Sie ihn.
+
+---
+
+## Geplante Jobs im Jobverlauf
+
+Jeder Lauf eines Zeitplans erstellt einen gewöhnlichen Job, der auf der Seite [Jobs](./) mit `Schedule Service` als Benutzer aufgeführt wird, oder,
+bei einem geplanten Lauf, mit dem Benutzer, der ihn geplant hat.
+
+Ein Job von `Schedule Service` gehört nicht der Person, die den Zeitplan erstellt hat, daher ist er nur für Admins und für
+Benutzer mit `showAllJobLogs` sichtbar; der Job eines geplanten Laufs ist auch für seinen Benutzer sichtbar. Die **Letzte Ausgabe** des Zeitplans nennt den Job, den er gestartet hat, sodass Sie ihn in der Liste finden.
diff --git a/i18n/de/_use/jobs/statuses.md b/i18n/de/_use/jobs/statuses.md
new file mode 100644
index 0000000..25bd6a1
--- /dev/null
+++ b/i18n/de/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Status und Typen
+parent: Jobs
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Status und Typen
+{: .no_toc }
+
+Jeder Status, den ein Job haben kann, und die Arten von Jobs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jobstatus
+
+AnsibleForms setzt folgende Status auf einem Job. Die Liste zeigt jeden Status als farbiges Badge:
+
+| Status | Bedeutung | Was Sie tun können |
+|---|---|---|
+| `running` | Der Job läuft, oder ein genehmigter Job wurde fortgesetzt | Seine Ausgabe verfolgen, ihn abbrechen |
+| `approve` | Der Job wartet an einem [Genehmigungspunkt](../forms/approval.html), bevor er läuft (oder bevor ein Schritt eines Multistep läuft) | Ihn genehmigen oder ablehnen, wenn eine Ihrer Rollen ein Genehmiger ist |
+| `success` | Das Playbook, die Vorlage oder jeder Schritt wurde ohne Fehler beendet | Ausgabe ansehen, neu starten, löschen |
+| `failed` | Der Job endete mit einem Fehler, oder der Start selbst schlug fehl | Ausgabe ansehen, um den Grund zu sehen, neu starten, löschen |
+| `warning` | Ein Multistep wurde beendet, aber ein Schritt mit gesetztem `continue` schlug fehl | Ausgabe ansehen, neu starten, löschen |
+| `aborted` | Der Job wurde aus AnsibleForms abgebrochen, oder der AWX-/AAP-Job wurde abgebrochen | Ausgabe ansehen, neu starten, löschen |
+| `rejected` | Ein Genehmiger hat den Job abgelehnt; er lief nie | Ausgabe ansehen, neu starten, löschen |
+| `abandoned` | AnsibleForms hat aufgehört, den Job zu verfolgen (siehe [Verwaiste Jobs](cleanup.html#abandoned-jobs)) | Die verwalteten Hosts prüfen, neu starten, löschen |
+
+`running` ist blau, `success` grün und lautet **Erfolgreich**, und `failed` rot. `approve` ist orange und lautet **Wartet auf Genehmigung**,
+sodass sich ein Job, der auf eine Person wartet, von den gestoppten abhebt; `warning`, `aborted` und `rejected` sind bernsteinfarben. `abandoned` ist
+grau: Niemand hat ihn gestoppt, was ihn ausführte, ist weg.
+
+---
+
+## Job-Typen
+
+Der Job-Typ folgt dem `type` des Formulars, das den Job gestartet hat, wie die Liste und die Seite des Jobs ihn anzeigen:
+
+| Angezeigter Typ | Was läuft |
+|---|---|
+| `ansible` | Ein Ansible-Playbook, auf einem RTE ausgeführt |
+| `awx`, `aap`, `ascender` | Eine Job-Vorlage oder Workflow-Vorlage auf AWX, AAP oder Ascender |
+| `semaphore` | Eine Vorlage auf Semaphore UI |
+| `rundeck`, `jenkins` | Ein Job auf Rundeck oder Jenkins |
+| `workflow` | Ein [Workflow](../workflows/), dessen Playbook-Knoten als eigene Jobs darunter laufen |
+| `multistep` | Veraltet, verwenden Sie `workflow`: eine Folge von Schritten, jeder als eigener Job unter dem Hauptjob aufgezeichnet |
+
+Ein Vorlagen-Job wird als `awx`-Job gespeichert (auch in der REST-API) und mit der Art des Runners angezeigt, auf dem er lief, egal wie das
+Formular ihn nannte: Ein Formular vom Typ `awx`, das auf einem AAP-Runner läuft, zeigt `aap`.
+
+Siehe [Ansible-Formulare](../forms/ansible.html), [AWX-Formulare](../forms/awx.html), [Workflow-Formulare](../forms/workflow.html) und
+[Mehrstufige Formulare](../forms/multistep.html) für die Seite der Formulare.
diff --git a/i18n/de/_use/jobs/stored-jobs.md b/i18n/de/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..41d1c37
--- /dev/null
+++ b/i18n/de/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Gespeicherte Jobs
+parent: Jobs
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Gespeicherte Jobs
+{: .no_toc }
+
+Die Daten eines Formulars aufbewahren, um sie später wieder zu laden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gespeicherte Jobs
+
+Gespeicherte Jobs bewahren die Werte eines Formulars auf, damit Sie sie wieder laden können, statt jedes Mal dieselben Felder auszufüllen.
+
+Zum Speichern füllen Sie das Formular aus, öffnen das Dropdown neben **Senden** und wählen **Speichern**. Geben Sie in **Formulardaten speichern** einen
+**Namen**, eine optionale **Beschreibung** und ein Datum unter **Ablaufdatum (optional)** ein und speichern Sie. Passwort- und Konstantenfelder werden
+nie gespeichert. Ein Unterformular hat dieselbe Aktion **Speichern** neben seiner Schaltfläche **Speichern** und bewahrt unfertige Werte auf, ohne
+sie zu validieren.
+
+Zum Laden wählen Sie oben im Formular **Aus Speicher laden**. **Gespeichertes Formular laden** listet Ihre gespeicherten Jobs für dieses Formular auf, mit
+ihrem Erstellungs- und Ablaufdatum; wählen Sie einen aus, um das Formular mit seinen Werten zu füllen. Es läuft nichts, bis Sie absenden.
+
+Gespeicherte Jobs liegen in der AnsibleForms-Datenbank (Tabelle `stored_jobs`), mit dem Formularnamen, Ihrem Benutzer als
+`<type>/<username>` (zum Beispiel `local/admin`) und den Werten als JSON. Ein Name muss pro Benutzer und Formular eindeutig sein; das Speichern
+eines zweiten mit demselben Namen schlägt mit „Ein gespeichertes Formular mit diesem Namen existiert bereits“ fehl.
+
+---
+
+## Gespeicherte Jobs verwalten
+
+Die Seite **Gespeicherte Jobs** listet gespeicherte Jobs mit Formular, Benutzer, Erstellungs- und Ablaufdatum auf und braucht `allowStoredJobs`.
+
+- **Bearbeiten** öffnet die eigene Seite des gespeicherten Jobs: seine **Details** (Name, Formular, Ablauf) und seine **Werte**, die gespeicherten
+  Feldwerte als YAML, die sich dort ändern und speichern lassen.
+- **Im Formular öffnen** öffnet sein Formular mit den gespeicherten Werten ausgefüllt; es läuft nichts, bis Sie absenden.
+- **Löschen** entfernt ihn. Sie können Ihre eigenen gespeicherten Jobs löschen; Benutzer mit `showSettings` können jeden löschen.
+- Gespeicherte Jobs, deren **Ablaufdatum** in der Vergangenheit liegt, werden jeden Tag um 04:00 (in `LOG_TZ`) automatisch gelöscht.
diff --git a/i18n/de/_use/profile/account.md b/i18n/de/_use/profile/account.md
new file mode 100644
index 0000000..694ff94
--- /dev/null
+++ b/i18n/de/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Konto
+parent: Ihr Profil
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Konto
+{: .no_toc }
+
+Als wer Sie angemeldet sind
+{: .fs-6 .fw-300 }
+
+---
+
+Die Ansicht Konto zeigt, als wer Sie angemeldet sind und was Ihren Zugriff bestimmt:
+
+- **Benutzername** und **Anmeldeart**: ein lokales Konto, LDAP, Microsoft Entra ID oder OpenID Connect.
+- **Gruppen**: die Gruppen, die mit Ihrer Anmeldung kommen, etwa `local/admins` oder `ldap/Domain Admins`.
+- **Rollen**: die Rollen in `config.yaml`, die zu diesen Gruppen und Ihrem Benutzer passen. Sie bestimmen,
+  welche Formulare Sie sehen und welche Optionen Sie haben.
diff --git a/i18n/de/_use/profile/api-token.md b/i18n/de/_use/profile/api-token.md
new file mode 100644
index 0000000..994f54b
--- /dev/null
+++ b/i18n/de/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: API-Token
+parent: Ihr Profil
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# API-Token
+{: .no_toc }
+
+Ein Token für Skripte und KI-Agenten erstellen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wer eines erstellen kann
+
+Ein langlebiges Token lässt Skripte die API ohne Ihr Passwort aufrufen. Ab 7.3.0 braucht es die Rollenoption `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Bis 7.2.0 gab es nur die Option `extendedTokenExpiration`. Eine Rolle aus der Zeit vor 7.3.0, die nur diese Option setzt, erhält
+`allowApiTokens`, sodass sie ihre Tokens behält; mit beiden lässt sich auch ein Token erstellen, das nie abläuft. Siehe [Rollenoptionen](../config/roles.html#role-options).
+
+---
+
+## Ein Token erstellen
+
+**Neues Token** in der Titelzeile von **Profil > API-Tokens** öffnet einen Wizard mit drei Schritten:
+
+1. **Details**: ein Name, damit Sie das Token in der Liste wiedererkennen, und wie lange es gültig bleibt. Zur Wahl stehen 30, 90, 180
+   oder 365 Tage bis [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (standardmäßig 90), dieses
+   Maximum selbst und, mit `extendedTokenExpiration`, **Läuft nie ab**. Wählen Sie die kürzeste Zeit, die Ihr Skript braucht.
+2. **Bestätigen**: Ein lokales oder LDAP-Konto gibt sein Passwort ein, das nicht im Token gespeichert wird. Ein Konto von Microsoft Entra ID oder
+   OIDC hat hier kein Passwort: Sein Token wird aus seiner Sitzung erstellt, die sich höchstens 10 Minuten
+   vorher angemeldet haben muss, daher kann der Anbieter Sie bitten, sich zuerst erneut anzumelden.
+3. **Kopieren**: das Token, **nur einmal** angezeigt. Kopieren Sie es mit **Kopieren** und bewahren Sie es so sicher auf wie ein Passwort.
+
+Senden Sie das Token im Header `Authorization` jedes API-Aufrufs:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Ein API-Token kann kein weiteres erstellen. Das Token eines SSO-Kontos trägt die Rollen seiner letzten Anmeldung: Eine Gruppenänderung beim
+Identitätsanbieter erreicht es erst, wenn Sie sich erneut anmelden und ein neues Token erstellen.
+
+---
+
+## Ihre Tokens
+
+Die Tokens, die Sie erstellt haben, werden mit ihrem Namen aufgelistet und damit, wann jedes erstellt wurde, abläuft und zuletzt verwendet wurde; **Widerrufen** im Menü einer Zeile beendet eines.
+Ein Admin sieht und widerruft sie auch auf Ihrer Seite unter **Einstellungen > Benutzer**. Ein Token endet mit seinem Ablauf, oder früher:
+
+- durch **einen Widerruf** aus der Liste;
+- durch **eine Abmeldung mit dem Token** (`POST /api/v2/auth/logout` mit dem Token im Header `Authorization`), die es zusammen mit
+  der Sitzung beendet, in der es erstellt wurde;
+- durch **eine Passwortänderung**, die jedes vorher erstellte Token und jede Sitzung Ihres Kontos beendet, und durch eine Sperrung Ihres Kontos.
+
+Ein Token, das nie abläuft, endet in diesen Fällen trotzdem. Ein Skript kann auch selbst ein Token über die Login-API und
+ihren Parameter `expiryDays` anfordern (`POST /api/v2/auth/login?expiryDays=90` oder `expiryDays=never`); ein längeres `expiryDays` wird
+auf `API_TOKEN_MAX_DAYS` gekürzt.
diff --git a/i18n/de/_use/profile/index.md b/i18n/de/_use/profile/index.md
new file mode 100644
index 0000000..ff4f12f
--- /dev/null
+++ b/i18n/de/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: Ihr Profil
+nav_order: 4
+description: Ihr Konto, Ihre Einstellungen, Ihr Passwort, Ihre Berechtigungen und Ihre API-Tokens
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# Ihr Profil
+{: .no_toc }
+
+Ihr Konto, Ihre Einstellungen, Ihr Passwort, Ihre Berechtigungen und Ihre API-Tokens
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Für jeden Benutzer: Ihr eigenes Konto, Ihre Einstellungen, Ihr Passwort, Ihre Berechtigungen und Ihre API-Tokens.
+
+Öffnen Sie Ihr Profil über den Avatar oben rechts: **Profil**.
+
+---
+
+## Eine Ansicht öffnen
+
+Das linke Menü listet die Ansichten des Profils in alphabetischer Reihenfolge auf. Jede Ansicht hat ihre eigene Adresse,
+sodass Sie direkt darauf verlinken können:
+
+| Ansicht | Adresse |
+|---|---|
+| Konto | `/profile/account` |
+| API-Tokens | `/profile/token` |
+| Passwort | `/profile/password` |
+| Berechtigungen | `/profile/permissions` |
+| Einstellungen | `/profile/preferences` |
+
+`/profile` allein öffnet die erste Ansicht des Menüs. Ansichten, die Ihre Rollen nicht erlauben, sind ausgeblendet; ihre Adresse öffnet stattdessen die erste
+Ansicht. **API-Tokens** wird nur angezeigt, wenn eine Ihrer Rollen die Rollenoption `allowApiTokens` hat.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema ist auf einer eigenen Seite beschrieben:
+
+| Seite | Inhalt |
+|---|---|
+| [Konto](account.html) | Als wer Sie angemeldet sind |
+| [Einstellungen](preferences.html) | Sprache, Design, Zeitzone, Datumsformat und Desktop-Benachrichtigungen |
+| [Passwort](password.html) | Das Passwort eines lokalen Kontos ändern |
+| [Berechtigungen](permissions.html) | Was Ihre Rollen Ihnen erlauben |
+| [API-Tokens](api-token.html) | Ein Token für Skripte und KI-Agenten erstellen |
diff --git a/i18n/de/_use/profile/password.md b/i18n/de/_use/profile/password.md
new file mode 100644
index 0000000..01a938c
--- /dev/null
+++ b/i18n/de/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Passwort
+parent: Ihr Profil
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Passwort
+{: .no_toc }
+
+Das Passwort eines lokalen Kontos ändern
+{: .fs-6 .fw-300 }
+
+---
+
+Geben Sie Ihr aktuelles Passwort und zweimal das neue ein, und klicken Sie dann auf **Passwort ändern**.
+
+Konten von LDAP, Entra ID und OpenID Connect ändern ihr Passwort stattdessen bei diesem Anbieter.
diff --git a/i18n/de/_use/profile/permissions.md b/i18n/de/_use/profile/permissions.md
new file mode 100644
index 0000000..7ac06ad
--- /dev/null
+++ b/i18n/de/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Berechtigungen
+parent: Ihr Profil
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Berechtigungen
+{: .no_toc }
+
+Was Ihre Rollen Ihnen erlauben
+{: .fs-6 .fw-300 }
+
+---
+
+Die Rollenoptionen sind in Tabs gruppiert, jeder mit der Anzahl seiner Optionen, die Sie haben, etwa `5/8`:
+
+| Tab | Optionen zu |
+|---|---|
+| **Zugang und Integrationen** | Anmeldung, Chat-Assistent, MCP-Server, Datei-Uploads und API-Tokens |
+| **Designer** | Den Designer öffnen und Formulare, Playbooks, Workflows, Inventare und Variablendateien bearbeiten |
+| **Jobs** | Jobs und ihre Extravars oder Artefakte sehen, Jobs neu starten, löschen, planen und speichern |
+| **Einstellungen** | Die Einstellungsseiten, die Protokolle, das Audit-Protokoll und Backups |
+| **Sonstiges** | Eine von Hand in einer Rolle gesetzte Option, die in keinem anderen Tab steht; immer der letzte Tab |
+
+Die anderen Tabs stehen in alphabetischer Reihenfolge. Jeder Tab ist eine Tabelle mit den Spalten **Einstellung** (die Option), **Beschreibung**
+(was sie bewirkt) und **Ihr Zugriff**: **Erlaubt** oder **Nicht erlaubt**. Eine Option, die wegen einer anderen gilt, sagt das
+unter ihrer Beschreibung: **In** einer Option **enthalten**, die Sie haben, schaltet sie ein, und **Benötigt** eine Option, die Ihnen fehlt, hält sie aus.
+
+Optionen kommen aus den `options` Ihrer Rollen in `config.yaml`; die Seite [Rollen](../config/roles.html) erklärt, wie
+sie sich kombinieren.
diff --git a/i18n/de/_use/profile/preferences.md b/i18n/de/_use/profile/preferences.md
new file mode 100644
index 0000000..8cc9b97
--- /dev/null
+++ b/i18n/de/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Einstellungen
+parent: Ihr Profil
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Einstellungen
+{: .no_toc }
+
+Sprache, Design, Zeitzone, Datumsformat und Desktop-Benachrichtigungen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Einstellungen
+
+Die Ansicht Einstellungen ändert, wie AnsibleForms für Sie aussieht. Jede Auswahl wird in dem Browser gespeichert,
+in dem Sie sie treffen, sodass ein anderer Browser oder Computer mit den Standardwerten beginnt.
+
+| Einstellung | Auswahl | Auch einstellbar über |
+|---|---|---|
+| Sprache | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (Japanisch), 简体中文 (vereinfachtes Chinesisch) | die Flagge in der Kopfzeile |
+| Design | Dem Browser folgen, Hell, Dunkel oder Farbe (eine Kopfzeile in einer Farbe Ihrer Wahl) | das Sonnensymbol in der Kopfzeile |
+| Formularansicht | Kacheln oder Liste | die Schaltfläche auf der Seite Formulare |
+| Zeitzone | UTC, die Zone dieses Browsers oder jede Zone nach Namen | nur hier |
+| Datumsformat | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` oder `DD.MM.YYYY` | nur hier |
+| Desktop-Benachrichtigungen | Ein oder aus | nur hier |
+
+Ab 7.3.0 ist die Ansicht in Tabs gegliedert, jeder unter seiner eigenen Adresse (`/profile/preferences/<tab>`): **Darstellung** (Sprache, Design und Formularansicht),
+**Datum und Uhrzeit** (Zeitzone und Datumsformat) und **Benachrichtigungen**. Das Suchfeld darüber listet die passenden Einstellungen
+unter dem Namen ihres Tabs auf. Eine Auswahl ist ein Entwurf bis **Speichern**, und wer die Ansicht mit einer ungespeicherten Änderung verlässt, wird zuerst gefragt.
+
+**Dem Browser folgen** wechselt zwischen hell und dunkel wie der Browser und ändert sich mit ihm. Es ist ab 7.3.0 das Standarddesign, sofern Ihr
+Administrator kein anderes wählt. Das Darüberfahren über eine Farbe des Designs **Farbe**, hier oder im Designmenü der Kopfzeile, zeigt die App in dieser
+Farbe als Vorschau, und das vorherige Design kehrt zurück, wenn der Zeiger die Palette verlässt; es ändert sich nichts bis zu einem Klick.
+
+---
+
+## Desktop-Benachrichtigungen
+
+Ab 7.3.0 schaltet der Tab **Benachrichtigungen** Desktop-Benachrichtigungen in diesem Browser ein, für Benutzer, deren Rolle `showJobs` setzt.
+
+Der Browser fragt beim ersten Mal nach seiner Erlaubnis. Blockiert er Benachrichtigungen für die Website, bleibt der Schalter aus und sagt, wie man
+sie erlaubt, und eine Website über reines `http` kann sie gar nicht anzeigen. Einmal eingeschaltet, kommt eine Benachrichtigung:
+
+| Wann | Sie sagt | Ein Klick darauf |
+|---|---|---|
+| Ein Job, den Sie gestartet haben, endet | Das Formular und sein Ergebnis, etwa *Patch Linux servers: Erfolgreich*, mit Jobnummer und Dauer | Holt den Tab mit diesem Job in den Vordergrund |
+| Ein Job wartet auf Ihre Genehmigung | Das Formular, die Jobnummer und wer ihn gestartet hat, mit den Schaltflächen **Freigeben** und **Ablehnen** | Öffnet die Jobs, die auf Genehmigung warten |
+
+Die Schaltflächen **Freigeben** und **Ablehnen** erscheinen in Chrome und Edge; Firefox und Safari zeigen die Benachrichtigung ohne sie, ebenso eine
+Website mit selbstsigniertem Zertifikat, da die Schaltflächen einen Service Worker brauchen. Benachrichtigungen kommen nur, solange ein AnsibleForms-Tab geöffnet ist,
+auch im Hintergrund: Sobald jeder Tab geschlossen ist, wird nichts mehr gesendet. Jede erscheint einmal, egal wie viele Tabs geöffnet sind, und die Schritte eines
+Multistep-Jobs sowie der Job, den Sie gerade ansehen, bleiben still.
+
+---
+
+## Zeitzone
+
+Datum und Uhrzeit werden in ganz AnsibleForms in der Zeitzone angezeigt, die Sie wählen. Das umfasst Start-
+und Endzeiten von Jobs, das Audit-Protokoll, die Statusseite, Backups, gespeicherte Jobs und den Ablauf eines API-Tokens.
+Eine Änderung der Zeitzone aktualisiert jede Seite sofort, ohne Neuladen.
+
+Solange Sie keine wählen, gilt die Zeitzone, die Ihr Administrator für alle festgelegt hat (**Einstellungen > Erscheinungsbild > Standardwerte**, siehe
+[Erscheinungsbild](../appearance.html)), **UTC**, sofern nicht geändert. **Dieser Browser** folgt der Zeitzone Ihres Computers, und die
+Liste enthält jede Zone nach Namen, etwa `Europe/Madrid`. Die Karte zeigt die aktuelle Uhrzeit in der gewählten Zone und im gewählten Format.
+
+---
+
+## Datumsformat
+
+Das Datumsformat legt fest, wie der Datumsteil jedes Datums aussieht, jede Auswahl mit dem heutigen Datum angezeigt: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` oder `DD.MM.YYYY`. Solange Sie keines wählen, gilt das Standard-Datumsformat Ihres Administrators,
+`YYYY-MM-DD`, sofern nicht geändert. Wie die anderen Auswahlen wird es in diesem Browser gespeichert.
+
+---
+
+## Was die Zeiten des Servers behält
+
+Zwei Ausnahmen behalten die eigenen Zeiten des Servers:
+
+- **Das Serverprotokoll und die Jobausgabe** sind Text mit den Zeiten, die der Server hineingeschrieben hat.
+- **Zeiten, die Sie eingeben**, etwa wann ein geplanter Job laufen soll, und Cron-Zeitpläne funktionieren wie
+  bisher.
diff --git a/i18n/de/_use/repositories/adding.md b/i18n/de/_use/repositories/adding.md
new file mode 100644
index 0000000..aba28db
--- /dev/null
+++ b/i18n/de/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Ein Repository hinzufügen
+parent: Git-Repositories
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Ein Repository hinzufügen
+{: .no_toc }
+
+Die Seite Repositories, jedes Feld eines Repositorys, und eines im Config-Seed deklarieren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Die Seite Repositories
+
+Repositories werden unter **Einstellungen > Verbindungen > Repositories** verwaltet, was die [Rollenoption](../config/roles.html#role-options) `showSettings` oder, ab 7.3.0,
+`showConnectionsSettings` braucht. Manche Änderungen sind einem Admin vorbehalten, siehe [unten](#who-may-change-a-repository).
+
+![Repositories](../assets/screenshots/git.jpg)
+
+Die Liste zeigt **Name**, **Beschreibung**, **Branch**, **Head** (der kurze Hash des ausgecheckten Commits), **Pull** und
+**Push**. Der Tab **Details** eines Repositorys zeigt dieselben Pull- und Push-Badges über seinem Head:
+
+| Spalte | Was sie sagt |
+|---|---|
+| **Pull** | Der letzte Clone, Pull oder Reset: **Läuft**, während git arbeitet, dann **Erfolgreich** oder **Fehlgeschlagen**; ein Strich vor dem ersten |
+| **Push** | **Fehlgeschlagen**, wenn der letzte Push fehlgeschlagen ist; **Ausstehende Änderungen**, wenn hier vom Designer gespeicherte Änderungen noch nicht zum Remote gepusht sind; **Erfolgreich**, wenn nichts wartet; ein Strich vor dem ersten Push |
+
+**Erfolgreich** in der Spalte Push bedeutet nur, dass nichts auf einen Push wartet: Das Remote kann trotzdem neuere Commits enthalten, die ein
+Pull holt. Das Menü jeder Zeile enthält folgende Aktionen:
+
+| Aktion | Was sie macht |
+|---|---|
+| **Bearbeiten** | Die Felder unten ändern |
+| **Pull** | Das Repository klonen oder pullen, wenn die Arbeitskopie schon existiert |
+| **Push** | Die Arbeitskopie committen und pushen; nur bei Repositories, die für Formulare, Konfiguration, Playbooks, Workflows oder Inventare verwendet werden, und nur aktiv, solange es noch nicht gepushte Änderungen gibt |
+| **Zurücksetzen** | Die Arbeitskopie löschen und neu klonen, wodurch lokale Änderungen verworfen werden |
+| **Anmeldeinformationen ändern** | Den Tab **Anmeldedaten** des Repositorys öffnen, um die Anmeldedaten zu wählen, die git verwendet |
+| **Ausgabe des letzten Pulls anzeigen** | Die Ausgabe von git beim letzten Clone, Pull oder Reset anzeigen, mit maskiertem Passwort |
+| **Ausgabe des letzten Pushs anzeigen** | Die Ausgabe von git beim letzten Push anzeigen, mit maskiertem Passwort |
+| **Löschen** | Den Eintrag und seine Arbeitskopie unter `REPO_PATH` entfernen; nur für Admins |
+
+**Alle pullen** über der Liste pullt alle Repositories auf einmal.
+
+Auf einem Repository läuft immer nur eine git-Operation gleichzeitig. Eine zweite wird mit
+`Repository '<name>' not found or already running, try again later` abgelehnt.
+
+---
+
+## Ein Repository hinzufügen
+
+Klicken Sie auf **Repository hinzufügen**: Ein Wizard fragt die Felder in vier Schritten ab (**Repository**, **Anmeldedaten**, **Verwendung**, **Pull-Zeitplan**),
+und AnsibleForms startet den Clone im Hintergrund, sobald Sie speichern.
+
+![Repository bearbeiten](../assets/screenshots/git-edit.jpg)
+
+| Feld | Erforderlich | Bedeutung |
+|---|---|---|
+| **Name** | ja | Der Ordnername unter `REPO_PATH`; Buchstaben, Ziffern, Bindestrich, Unterstrich und Punkt |
+| **Branch** | ja | Der Branch, der geklont, gepullt und gepusht wird, zum Beispiel `main`; ab 7.3.0 erforderlich. Nur ein Repository aus dem Config-Seed darf ihn weglassen, um den Standard-Branch des Remotes zu klonen |
+| **Anmeldedaten** | nein | Anmeldedaten aus [Verbindungen > Anmeldedaten](../credentials.html) mit dem Benutzer und dem Passwort oder Token, die git verwendet; **Anmeldedaten hinzufügen** erstellt welche |
+| **URI** | ja | Das Remote, `https://...` oder SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Geplanten Pull aktivieren** | nein | Das Repository nach Zeitplan pullen |
+| **Pull-Zeitplan** | nein | Wann gepullt wird, als Cron-Ausdruck; erscheint, sobald der geplante Pull aktiviert ist |
+| **Beschreibung** | ja | Eine frei wählbare Beschreibung |
+| **Für Konfiguration verwenden?** ... **Für Inventare verwenden?** | nein | Was das Repository enthält, siehe [oben](./#what-a-repository-is-for) |
+| **Beim Start der App pullen** | nein | Das Repository bei jedem Start von AnsibleForms klonen oder pullen |
+
+Das Umbenennen eines Repositorys verschiebt seine Arbeitskopie in den neuen Ordner und seinen Pull-Zeitplan mit. Ein Repository aus der Zeit
+vor 7, das noch einen eigenen Benutzer hat, sagt das auf seinem Tab **Anmeldedaten**: Wählen Sie Anmeldedaten, um ihn zu ersetzen.
+
+---
+
+## Wer ein Repository ändern darf
+
+Der Inhalt eines Repositorys wird zu dem, was AnsibleForms lädt und ausführt, daher kann ab 7.3.0 ein Benutzer ohne die Rolle `admin` nicht mehr:
+
+- ein Repository hinzufügen oder löschen;
+- seine **URI** oder seinen **Branch** ändern;
+- eines seiner **Verwenden**-Flags ein- oder ausschalten.
+
+Er kann weiterhin Beschreibung, Pull-Zeitplan und Anmeldedaten ändern sowie es pullen, pushen oder zurücksetzen. Anmeldedaten, die ein Runner,
+eine Verbindung oder eine Anmeldemethode verwendet, kann er nicht auswählen; die Ablehnung nennt sie und sagt nichts darüber, was sie enthalten.
+
+---
+
+## Repositories im Config-Seed deklarieren
+
+Repositories lassen sich auch im [Config-Seed](../seed/) deklarieren, sodass eine neue Instanz sie bei ihrem ersten Start klont.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+Die Felder sind die der Seite, einschließlich `credential` (Anmeldedaten aus dem Seed oder der App), `rebase_on_start` (**Beim Start der App
+pullen**) und `cron` (der Pull-Zeitplan); `user` und `password` werden statt Anmeldedaten weiterhin akzeptiert. Ein
+per Seed angelegtes Repository ist in der Oberfläche schreibgeschützt und wird beim Start neu geklont, wenn seine Arbeitskopie fehlt; siehe
+[Verwaltete Objekte](../seed/managed-objects.html).
diff --git a/i18n/de/_use/repositories/authentication.md b/i18n/de/_use/repositories/authentication.md
new file mode 100644
index 0000000..ec48541
--- /dev/null
+++ b/i18n/de/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Authentifizierung
+parent: Git-Repositories
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Authentifizierung
+{: .no_toc }
+
+HTTPS mit einem Token, SSH mit dem erzeugten Schlüssel und eigene git-Befehle
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Authentifizierung
+
+Wie sich AnsibleForms authentifiziert, hängt von der Form der **URI** ab.
+
+### HTTPS mit einem Token
+
+Für ein privates HTTPS-Remote wählen Sie **Anmeldedaten**, deren Benutzer der git-Benutzer ist und deren Passwort ein Personal Access Token
+(oder das Passwort) ist.
+
+Ab 7.3.0 meldet sich git über `GIT_ASKPASS` an: Benutzer und Token gehen an jeden git-Befehl, der mit dem Server spricht, nie in
+die URL, sodass sie nicht in der `.git/config` des Clones bleiben und ein geändertes Token beim nächsten Pull oder Push verwendet wird. Das Token braucht
+Lesezugriff zum Pullen und Schreibzugriff zum Pushen. Ein öffentliches Remote braucht keine Anmeldedaten.
+
+Bis 7.2.0 wurden beide in die URL eingefügt, als `https://<user>:<token>@git.example.com/team/forms.git`. Ein damals erstellter Clone behält
+diese URL bis zu seinem nächsten Pull oder Push, der sein Remote wieder auf die eigene **URI** des Repositorys setzt.
+
+### SSH mit dem erzeugten Schlüssel
+
+Für ein SSH-Remote authentifiziert sich AnsibleForms mit einem eigenen Schlüsselpaar, das es beim ersten Start erzeugt.
+
+1. Öffnen Sie **Einstellungen > Verbindungen > SSH**, dort den Tab **Schlüssel**, und kopieren Sie den **Öffentlichen Schlüssel**.
+2. Fügen Sie ihn auf dem git-Server hinzu, als Deploy-Key des Repositorys (mit Schreibzugriff, wenn Sie pushen) oder bei einem Benutzer mit Zugriff.
+3. Fügen Sie das Repository mit einer SSH-**URI** hinzu, zum Beispiel `git@git.example.com:team/forms.git`, und wählen Sie keine Anmeldedaten.
+
+Das Schlüsselpaar liegt in `.ssh/id_rsa` unter [`HOME_PATH`](../customization/paths.html#env_HOME_PATH); halten Sie diesen Ordner also auf
+persistentem Speicher, sonst ändert sich der Schlüssel, wenn der Container neu erstellt wird.
+
+Bei einem Clone mit einer URI der Form `user@host:path` führt AnsibleForms zuerst `ssh-keyscan` auf dem Host aus und fügt seinen Schlüssel zu den
+bekannten Hosts hinzu. Für andere Remotes fügen Sie den Host vor dem ersten Clone im Tab **Bekannte Hosts** von **Einstellungen > Verbindungen > SSH**
+hinzu.
+
+### Eigene git-Befehle
+
+Die Befehle für Clone, Pull und Push lassen sich ersetzen, etwa um git-Optionen hinzuzufügen, mit drei Einstellungen.
+
+| Einstellung | Standard | Was AnsibleForms hinzufügt |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, die URI und den Namen |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+Ab 7.3.0 laufen diese Befehle ohne Shell: Anführungszeichen funktionieren, aber ein Shell-Operator wie `;`, `|`, `&&` oder `>` wird abgelehnt.
diff --git a/i18n/de/_use/repositories/designer.md b/i18n/de/_use/repositories/designer.md
new file mode 100644
index 0000000..b5f816b
--- /dev/null
+++ b/i18n/de/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Designer und Push
+parent: Git-Repositories
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Designer und Push
+{: .no_toc }
+
+Formulare im Designer bearbeiten und ins Repository pushen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Aus dem Designer bearbeiten und pushen
+
+Mit einem Repository, das für Formulare verwendet wird, bearbeitet der Designer die Dateien in dessen Arbeitskopie und pusht sie zurück zum Remote.
+
+| Schaltfläche | Was sie macht |
+|---|---|
+| **Speichern (lokal)** | Schreibt die Formulare und `config.yaml` in die Arbeitskopien, ohne zu committen |
+| **Speichern (Repository)** | Committet und pusht die gespeicherten Änderungen; aktiv, sobald es nicht gepushte Änderungen gibt |
+| **Laden (Repository)** | Pullt die Formular-Repositories und lädt den Designer neu, nach einer Bestätigung, wenn Änderungen nicht gespeichert sind |
+
+Formulare bleiben in ihrem Repository; neue warten, bereits nutzbar, in [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH), bis Sie pushen.
+Ein in einem Unterordner gespeichertes Formular behält seinen relativen Pfad: `team/deploy.yaml` wird nach `team/deploy.yaml` unter dem Formularordner
+des Repositorys gepusht. Ein neues Formular, dessen Pfad dort schon existiert, wird nicht überschrieben; es bleibt im Staging, benennen Sie es also um.
+Mit mehreren Formular-Repositories fragen **Speichern (Repository)** und **Laden (Repository)**, welches gemeint ist, standardmäßig das mit `config.yaml`.
+
+Ein Push stellt alle Änderungen bereit, committet sie als `AnsibleForms` mit der Nachricht `Forms sync by <user>`, holt dann die Änderungen, rebased auf
+das Remote und pusht, mit bis zu fünf Wiederholungen. Ein Rebase-Konflikt wird abgebrochen, und die betroffenen Dateien werden aufgelistet;
+beheben Sie sie im Remote oder verwenden Sie **Zurücksetzen** auf der Seite Repositories. **Push** auf der Seite Repositories macht dasselbe.
+
+Wird ein einzelnes Formular-Repository leer geklont, kopiert AnsibleForms die lokale `config.yaml` und die Formulare in seine
+Arbeitskopie, sodass ein Push (**Speichern (Repository)** oder **Push** auf der Seite Repositories) sie veröffentlicht. Mehr zum Designer steht unter [Designer und git](../gui/designer-and-git.html).
diff --git a/i18n/de/_use/repositories/index.md b/i18n/de/_use/repositories/index.md
new file mode 100644
index 0000000..adaf260
--- /dev/null
+++ b/i18n/de/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Git-Repositories
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Git-Repositories
+{: .no_toc }
+
+Formulare, Variablendateien, Konfiguration und Playbooks in git aufbewahren
+{: .fs-6 .fw-300 }
+
+---
+
+Für Admins, die Formulare, Konfiguration und Playbooks in git aufbewahren: was ein Repository enthalten kann und welche Quelle Vorrang hat.
+
+---
+
+## Wofür ein Repository da ist
+
+Ein Repository ist ein git-Remote, das AnsibleForms klont und aktuell hält, und jedes hat Schalter, die sagen, was es enthält:
+
+| Schalter | Was AnsibleForms daraus liest | Ordner im Repository |
+|---|---|---|
+| **Für Konfiguration verwenden?** | `config.yaml` mit den Kategorien, Rollen und Konstanten | das Stammverzeichnis |
+| **Für Formulare verwenden?** | Die Formulardateien, die der Designer auch dorthin zurückspeichert, und ihre Variablendateien | `forms` oder das Stammverzeichnis; Variablendateien in `vars` |
+| **Für Playbooks verwenden?** | Die Ansible-Playbooks, die Jobs ausführen | `playbooks` oder das Stammverzeichnis |
+| **Für Workflows verwenden?** | Die [Workflow](../workflows/)-Dateien, die der Designer auch dorthin zurückspeichert | jeder Ordner |
+| **Für Inventare verwenden?** | Ein Inventar, nach dem Repository benannt, das ein Formular mit `inventory:` nennt | das Stammverzeichnis: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Ohne den Unterordner wird das Stammverzeichnis des Repositorys verwendet. Ein Repository kann alles enthalten; wenn Sie aufteilen, dürfen nur **Für
+Formulare verwenden**, **Für Workflows verwenden** und **Für Inventare verwenden** bei mehreren eingeschaltet sein: Die anderen Schalter nehmen das erste Repository
+und protokollieren eine Warnung.
+
+Jedes Repository wird in einen nach ihm benannten Unterordner unter [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) geklont.
+
+### Ein Repository für alles
+
+Ein einzelnes Repository kann Formulare, Variablendateien, Konfiguration und Playbooks enthalten, mit eingeschalteten Schaltern und einem Unterordner pro Art.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Ein Repository pro Zweck
+
+Getrennte Repositories lassen Teams ihren Teil besitzen, mit je einem Schalter und den Dateien direkt im Stammverzeichnis.
+
+| Repository | Schalter | Inhalt im Stammverzeichnis |
+|---|---|---|
+| `af-config` | **Für Konfiguration verwenden?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Für Formulare verwenden?** | Die Formulardateien jedes Teams, zu einer Liste zusammengeführt |
+| `af-playbooks` | **Für Playbooks verwenden?** | Die Playbooks und Rollen |
+
+Nur Formulare können aus mehreren Repositories kommen; Konfiguration und Playbooks kommen jeweils aus einem. Die Variablendateien kommen aus dem Ordner `vars`
+des ersten Formular-Repositorys, das einen hat.
+
+---
+
+## Wie Repositories mit lokalen Ordnern zusammenspielen
+
+Der Inhalt eines Repositorys ersetzt den passenden lokalen Ordner; diese Tabelle fasst zusammen, woher jede Dateiart gelesen wird.
+
+| Inhalt | Gelesen aus, der erste Treffer gewinnt |
+|---|---|
+| Konfiguration | 1. der Datenbank, wenn die Konfiguration dort gehalten wird ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. `config.yaml` des Repositorys **Für Konfiguration verwenden** <br> 3. `config.yaml` eines Repositorys **Für Formulare verwenden**, wenn kein Repository für die Konfiguration verwendet wird <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formulare | Jedes Repository **Für Formulare verwenden** plus `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) nur, wenn es keines gibt |
+| Playbooks | Das Repository **Für Playbooks verwenden**, sonst [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Variablendateien | Der Ordner `vars` des ersten Repositorys **Für Formulare verwenden**, das einen hat, sonst [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflows | Jedes Repository **Für Workflows verwenden** plus [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), zusammen |
+
+Formulare aus mehreren Repositories werden zu einer Liste zusammengeführt. Enthalten zwei davon ein Formular mit demselben Namen, wird das zuerst
+geladene behalten und die Warnung `skipping duplicate form <name>` protokolliert; halten Sie Formularnamen also über alle Repositories hinweg eindeutig.
+
+---
+
+## Fehlerbehebung
+
+Die meisten Probleme zeigen sich in der Spalte **Pull** und in **Ausgabe des letzten Pulls anzeigen** (oder **Ausgabe des letzten Pushs anzeigen**), die die eigene
+Fehlermeldung von git enthalten.
+
+- [Ein Clone oder Pull eines Repositorys ist fehlgeschlagen](../troubleshooting.html#a-repository-clone-or-pull-failed): Authentifizierung, bekannte
+  Hosts und lokale Änderungen.
+- [Das Formular-Repository ist noch nicht geklont](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): Der Designer
+  kann vor dem ersten Clone nicht speichern.
+- Ein Repository, das in `running` hängt, wird auf `failed` zurückgesetzt: nach einem Neustart beim nächsten Start; innerhalb einer Minute, sobald der Knoten,
+  der seine git-Operation ausführt, seit 2 Minuten nicht mehr antwortet; und in jedem Fall nach 2 Stunden. Führen Sie **Pull** erneut aus.
+
+---
+
+## In diesem Abschnitt
+
+Jedes Thema hat eine eigene Seite:
+
+| Seite | Inhalt |
+|---|---|
+| [Ein Repository hinzufügen](adding.html) | Die Seite Repositories, jedes Feld eines Repositorys, und eines im Config-Seed deklarieren |
+| [Authentifizierung](authentication.html) | HTTPS mit einem Token, SSH mit dem erzeugten Schlüssel und eigene git-Befehle |
+| [Änderungen pullen](pulling.html) | Geplante, manuelle und API-Pulls, und lokale Änderungen |
+| [Designer und Push](designer.html) | Formulare im Designer bearbeiten und ins Repository pushen |
diff --git a/i18n/de/_use/repositories/pulling.md b/i18n/de/_use/repositories/pulling.md
new file mode 100644
index 0000000..237022f
--- /dev/null
+++ b/i18n/de/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Änderungen pullen
+parent: Git-Repositories
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Änderungen pullen
+{: .no_toc }
+
+Geplante, manuelle und API-Pulls, und lokale Änderungen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Änderungen pullen
+
+Ein Repository wird nach seinem Zeitplan, beim Start, von der Seite aus oder über die API gepullt; es gibt keinen Webhook-Endpunkt.
+
+| Auslöser | Wie |
+|---|---|
+| Zeitplan | **Geplanten Pull aktivieren** und ein **Pull-Zeitplan**, zum Beispiel `0 * * * *` für jede Stunde |
+| Start | **Beim Start der App pullen** klont das Repository oder pullt es, wenn es schon geklont ist |
+| Einstellungsseite | **Pull** im Zeilenmenü oder **Alle pullen** über der Liste |
+| Designer | **Laden (Repository)**, das die Formular-Repositories pullt und den Designer neu lädt; auch das Übernehmen der Designer-Sperre pullt zuerst jedes Formular-Repository |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` oder `showConnectionsSettings`) oder `POST /api/v2/forms-repos/pull/<name>` (siehe unten) |
+
+### Aus einer Pipeline oder einem Webhook pullen
+
+AnsibleForms hat keinen eigenen Webhook-Empfänger, aber ein CI-Job oder ein Webhook des git-Servers kann den Pull-Endpunkt aufrufen.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Erstellen Sie das Token wie unter [API-Tokens](../profile/api-token.html) beschrieben, für einen Benutzer, dessen Rolle `showSettings` oder
+`showConnectionsSettings` hat. `/api/v2/forms-repos/pull/<name>` braucht stattdessen `showDesigner` und `allowFormDesign`, bei eingeschaltetem
+Designer ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` liefert
+`head`, `status` und `output`, sodass eine Pipeline prüfen kann, welchen Commit die Instanz nach einem Pull ausführt.
+
+### Lokale Änderungen
+
+Ein Pull überschreibt nie Arbeit, die noch nicht gepusht ist, daher prüft ein geplanter Pull die Arbeitskopie, bevor er läuft.
+
+Ein geplanter Pull wird übersprungen, solange die Arbeitskopie nicht committete Änderungen oder nicht gepushte Commits hat und solange ein Designer
+die Designer-Sperre hält. Ein manueller Pull einer Arbeitskopie mit kollidierenden Änderungen schlägt fehl mit:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Pushen Sie die Änderungen oder verwerfen Sie sie mit **Zurücksetzen** im Zeilenmenü, das die Arbeitskopie löscht und neu klont.
diff --git a/i18n/de/index.md b/i18n/de/index.md
new file mode 100644
index 0000000..83c502a
--- /dev/null
+++ b/i18n/de/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Startseite
+nav_order: 1
+description: "AnsibleForms: dynamische, datengetriebene Formulare für die Automatisierung mit Ansible erstellen"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Self-Service-Formulare für <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible ist ein leistungsfähiges Automatisierungswerkzeug, bleibt aber eine Kommandozeilenanwendung, und AWX/AAP/Ascender fehlen
+      Formulare, die Daten aus mehreren Quellen sammeln. Mit AnsibleForms erstellen Sie dynamische, datengetriebene Formulare, erzeugen Extravars,
+      senden sie an Ansible, AWX/AAP/Ascender, Semaphore, Rundeck oder Jenkins und führen dort Vorlagen aus.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">AnsibleForms installieren</a>
+      <a href="first-form.html" class="btn btn-outline">Ihr erstes Formular erstellen</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="Das Dashboard von AnsibleForms">
+  </div>
+</div>
+
+## Funktionen
+
+Was AnsibleForms Ihrer Ansible-Umgebung bringt und was ein einzelnes Formular kann:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Anwendung</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Automatisierungsplattformen</strong><span>Playbooks auf RTEs, Vorlagen auf Ascender, Semaphore und mehr</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Zugriffskontrolle</strong><span>Rollen und Rollenoptionen, mit lokaler, LDAP-, Entra-ID- und OIDC-Anmeldung</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Zeitplanung</strong><span>Ein Formular später oder nach einem Cron-Zeitplan ausführen</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Jobverlauf</strong><span>Jobs verfolgen, abbrechen und neu starten</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Anmeldedaten und Secrets</strong><span>Anmeldedaten speichern oder aus Vault oder CyberArk lesen</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Git-Repositories</strong><span>Formulare, Playbooks und Konfiguration in Git aufbewahren</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Designer</strong><span>Formulare als YAML bearbeiten, mit Validierung</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP und Chat</strong><span>Formulare aus Skripten, KI-Agenten oder einem Chat starten</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formulare</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Kaskadierende Dropdowns</strong><span>Dropdowns, die auf andere Felder reagieren</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Ausdrücke und Datenquellen</strong><span>Felder aus Datenbanken, REST-APIs, Dateien und JavaScript füllen</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Feldabhängigkeiten</strong><span>Felder abhängig von anderen Feldern ein- oder ausblenden</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validierung</strong><span>Min, Max, Regex und mehr, optional auf dem Server geprüft</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflows und Wizard-Formulare</strong><span>Playbooks und Genehmigungen verketten oder Eingaben auf Seiten verteilen</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Strukturierte Felder</strong><span>Listen und Objekte auf Basis wiederverwendbarer Unterformulare</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Genehmigungspunkte</strong><span>Einen Job anhalten, bis jemand ihn genehmigt</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Benachrichtigungen</strong><span>Mail, Slack, Teams, Telegram oder ein Webhook bei Job-Ereignissen</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Brauchen Sie Hilfe?
+
+Fragen, Fehler und Sicherheitsmeldungen haben jeweils ihren eigenen Ort:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Fehlerbehebung</strong>
+    <span>Eine Fehlermeldung nachschlagen und erfahren, wie man sie behebt</span>
+    <span class="af-card-more">Fehlerbehebung &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Eine Frage stellen</strong>
+    <span>Die Community und die Maintainer fragen</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Einen Fehler melden</strong>
+    <span>Ein Issue mit den Schritten zur Reproduktion öffnen</span>
+    <span class="af-card-more">Neues Issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Hilfe bekommen</strong>
+    <span>Was Sie angeben sollten, und wie Sie ein Sicherheitsproblem melden</span>
+    <span class="af-card-more">Hilfe bekommen &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/fr.yml b/i18n/fr.yml
new file mode 100644
index 0000000..6a5702f
--- /dev/null
+++ b/i18n/fr.yml
@@ -0,0 +1,42 @@
+# The French docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: fr
+docs_language: "fr"
+
+title: "Documentation d'AnsibleForms"
+description: "Documentation technique d'AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Tous droits réservés."
+
+# "Edit this page on GitHub" opens the French page's source
+gh_edit_link_text: "Modifier cette page sur GitHub"
+gh_edit_source: i18n/fr
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Introduction"
+    get_started:
+      name: "Premiers pas"
+    configure:
+      name: "Configurer"
+    build_forms:
+      name: "Créer des formulaires"
+    use:
+      name: "Guide de l'utilisateur"
+    integrate:
+      name: "Intégrer"
+    security_assessment:
+      name: "Sécurité"
+    reference:
+      name: "Référence"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (dernière)"
+    url: "/fr/"
+  - name: "6"
+    title: "6.x (en anglais)"
+    url: "/v6/"
diff --git a/i18n/fr/_build_forms/expressions/credentials.md b/i18n/fr/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..8c0521b
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Identifiants
+parent: Expressions
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Identifiants
+{: .no_toc }
+
+Lire un identifiant enregistré dans une expression
+{: .fs-6 .fw-300 }
+
+---
+
+Lisez un identifiant enregistré par son nom ou par expression régulière, avec une solution de repli :
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Le nom exact est essayé en premier. Si aucun identifiant ne porte ce nom, le nom est utilisé comme expression régulière, puis la solution de repli est essayée.
+
+#### Limité par rôle
+
+Lorsque l'un des rôles de l'utilisateur liste `credentials` dans `config.yaml`, `fn.fnCredentials` ne renvoie qu'un identifiant autorisé
+par un tel rôle : les motifs du rôle sont comparés au nom de l'identifiant trouvé (par nom, expression régulière ou repli),
+et tout autre est refusé. Les rôles sans cette liste ne le limitent pas, et un administrateur n'est jamais limité.
+
+#### Identifiants depuis un coffre de secrets
+
+Un identifiant qui désigne un [coffre de secrets](../secret-stores) obtient son `user` et son `password`
+de ce coffre à l'exécution. `fn.fnCredentials('myapp')` continue de fonctionner sans changement.
+
+Un secret peut aussi être lu sans ligne d'identifiant, partout où un nom d'identifiant est accepté
+(y compris `fnRestBasic`, `fnRestJwtSecure` et les substitutions d'en-têtes de `fnRestAdvanced`) :
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+Les clés du secret sont associées comme décrit dans [Noms des clés](../secret-stores#key-names).
+Un secret d'une autre forme est remodelé avec une expression `jq` passée en troisième argument :
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/fr/_build_forms/expressions/index.md b/i18n/fr/_build_forms/expressions/index.md
new file mode 100644
index 0000000..b425639
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Expressions
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Expressions
+{: .no_toc }
+
+Calculer les valeurs des champs en JavaScript, dans le navigateur ou sur le serveur
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les auteurs de formulaires : remplissez des champs dynamiquement en JavaScript, calculés dans le navigateur ou récupérés sur le serveur.
+
+L'attribut `expression` d'un champ de formulaire vous permet de créer des formulaires dynamiques avec des expressions JavaScript.
+
+---
+
+## Introduction
+
+L'attribut `expression` est disponible sur plusieurs types de champ :
+- champ `enum` : pour remplir dynamiquement les options d'une liste déroulante
+- champ `expression` : pour récupérer ou générer n'importe quel type de données
+- champ `html` : pour construire son contenu HTML
+- champs `yaml` et `list` : pour remplir leurs données
+
+Les expressions JavaScript sont évaluées soit **côté serveur** (par défaut), soit **côté client**, selon la propriété `runLocal` du champ.
+Un champ `html`, ainsi que les types de champ `local`, `local_out` et `credential`, exécutent toujours leur expression dans le navigateur, quelle que soit
+la valeur de `runLocal`.
+
+- **Côté serveur** (`runLocal: false`, la valeur par défaut) : des fonctions prédéfinies qui récupèrent des données depuis des API, des fichiers et des bases de données.
+- **Côté client** (`runLocal: true`) : le code exploite tout le moteur JavaScript dans le bac à sable du navigateur pour les calculs, transformations et manipulations.
+
+---
+
+## Questions de sécurité
+
+Comme les expressions sont évaluées avec la fonction JavaScript `eval`, l'injection de code est un risque potentiel :
+
+- **Les expressions côté serveur** passent d'abord par un filtre : chaque appel doit être une fonction `fn.` ou `fnc.`, et les lignes multiples,
+  `;`, les template literals, `process.env` et les moyens de sortir d'`eval` (`import`, `require`, `constructor`, ...) sont refusés.
+- **Les expressions côté client** sont évaluées dans le bac à sable du navigateur et peuvent être considérées comme sûres.
+
+La sévérité du filtre dépend de
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) :
+
+| Valeur | Expressions côté serveur |
+|---|---|
+| `strict` (par défaut) | appels `fn.` et `fnc.`, et méthodes sur leur résultat, comme `fn.fnTime().format('YYYY')` |
+| `paranoid` | uniquement des appels directs `fn.` et `fnc.`, sans méthode sur leur résultat |
+| `off` | toute expression côté serveur est refusée ; seules les expressions `runLocal` fonctionnent |
+| `legacy` | les règles de la 6.2.1, qui permettaient à tout utilisateur authentifié d'exécuter du code sur le serveur ; uniquement pour une mise à niveau, et uniquement dans l'environnement réel (pas depuis la page des paramètres) |
+
+Une valeur vide ou inconnue équivaut à `strict`. Un changement s'applique à l'expression suivante, sans redémarrage.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Contenu |
+|---|---|
+| [Espaces réservés](placeholders.html) | Faire référence à un autre champ, une constante ou l'utilisateur avec `$(...)` |
+| [Expressions locales](local.html) | Du JavaScript exécuté dans le bac à sable du navigateur |
+| [Expressions distantes](remote.html) | Fonctions côté serveur pour les dates, réseaux, fichiers, SSH et noms numérotés |
+| [API REST](rest-apis.html) | Appeler des API REST avec une authentification basique, par jeton ou personnalisée |
+| [Identifiants](credentials.html) | Lire un identifiant enregistré |
+| [Tri](sorting.html) | Trier des tableaux avec un objet de tri |
+| [Requêtes jq](jq.html) | Remodeler des données avec jq |
diff --git a/i18n/fr/_build_forms/expressions/jq.md b/i18n/fr/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..09e16ce
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Requêtes jq
+parent: Expressions
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# Requêtes jq
+{: .no_toc }
+
+Remodeler des données avec jq, y compris avec les fonctions intégrées
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Exécuter une requête JSON (jq) sur un objet
+
+Remodelez un objet, par exemple la valeur d'un autre champ, avec une expression jq :
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+Depuis la 7.3.0, un filtre jq s'exécute au maximum [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (30 par défaut)
+avant d'être arrêté, et sa sortie est plafonnée à 64 Mo. Cela s'applique à `fn.fnJq` et à l'expression jq des fonctions REST, fichier,
+identifiant et requête de base de données.
+
+---
+
+## Fonctions jq intégrées
+
+Toutes les fonctions de récupération de données acceptent une requête JSON (jq), un langage pour manipuler des objets et des tableaux de données.  
+En manipulant des données, vous aurez peut-être besoin de convertir des octets en Ko, Mo ou Go, ou d'arrondir des nombres.  
+Pour cela, AnsibleForms inclut quelques fonctions jq personnalisées :
+
+- **fn2KB** : octets en Ko
+- **fn2MB** : octets en Mo
+- **fn2GB** : octets en Go
+- **fnRound0** : arrondi à 0 décimale
+- **fnRound1** : arrondi à 1 décimale
+- **fnRound2** : arrondi à 2 décimales
+- **fnRound** : arrondi à 2 décimales
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/fr/_build_forms/expressions/local.md b/i18n/fr/_build_forms/expressions/local.md
new file mode 100644
index 0000000..49d28c9
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Expressions locales
+parent: Expressions
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Expressions locales
+{: .no_toc }
+
+Du JavaScript exécuté dans le bac à sable du navigateur
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Les exemples suivants s'exécutent avec la propriété de champ `runLocal: true`.  
+Ils s'exécutent dans le bac à sable du navigateur et peuvent exploiter tout le moteur JavaScript.
+
+{: .note }
+> **Astuce** : utilisez le type `local` comme alias de `type: expression, runLocal: true, hide: true, output: false`  
+> **Astuce** : utilisez le type `local_out` comme alias de `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Convention de nommage
+
+Utilisez des manipulations de chaînes pour appliquer des conventions de nommage.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Calcul
+
+Utilisez les mathématiques pour faire des calculs.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Conversions
+
+Convertir des octets en gigaoctets.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Convertir un tableau d'objets en tableau HTML
+
+Transformez un tableau d'objets, par exemple provenant d'un autre champ, en tableau HTML pour un champ `html` :
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Obtenir un nom avec une numérotation incrémentale
+
+Avec une numérotation automatique, vous aurez peut-être besoin de trouver le nom suivant dans un tableau de chaînes numérotées.  
+Cette fonction est aussi disponible comme expression côté serveur (préfixée par `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Quand le premier argument n'est pas un tableau, la fonction locale renvoie la valeur par défaut. La fonction serveur `fn.fnGetNumberedName`
+échoue plutôt avec une erreur.
+
+---
+
+## Manipulation de tableaux d'objets
+
+Les tableaux d'objets doivent souvent être filtrés, modifiés et triés.  
+AnsibleForms inclut un outil personnalisé qui garde ce code concis.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Manipulation de tableaux d'objets en JavaScript standard
+
+Toutes les méthodes standard des tableaux JavaScript restent disponibles pour filtrer et modifier vos données, comme `map`, `forEach`, `find`, `filter` et `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/fr/_build_forms/expressions/placeholders.md b/i18n/fr/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..4f3b7c4
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Espaces réservés
+parent: Expressions
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Espaces réservés
+{: .no_toc }
+
+Faire référence à un autre champ, à une constante ou à l'utilisateur actuel avec `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Qu'est-ce qu'un espace réservé
+
+Un espace réservé est une référence écrite sous la forme `$(reference)`. Il est remplacé par une valeur avant que le texte qui le contient soit utilisé.
+
+Les espaces réservés fonctionnent dans `expression`, `query` et `default` (évalué avec `evalDefault`) d'un champ, ainsi que dans son `label`,
+son `help` et son `placeholder`. Un champ qui contient un espace réservé dépend du champ qu'il nomme : il attend que ce champ ait une
+valeur, et il est réévalué chaque fois que cette valeur change. C'est ainsi que l'on construit des listes déroulantes en cascade.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## À quoi un espace réservé peut faire référence
+
+Un espace réservé nomme un champ du formulaire, ou l'une des références suivantes, présentes dans tout formulaire :
+
+| Référence | Ce qu'elle contient |
+|---|---|
+| `$(field)` | la valeur d'un autre champ du formulaire |
+| `$(name)`, une constante | une [constante](../config/constants.html) de `config.yaml`, ou une valeur des `varsFiles` du formulaire |
+| `$(__user__)` | l'utilisateur connecté : `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | dans un [sous-formulaire](../forms/subform.html) (une ligne de liste, une étape d'assistant), une valeur du formulaire parent |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Accéder à une partie d'une valeur
+
+La notation par point et par index lit une partie d'une valeur, tant que le chemin ne contient que des lettres, des chiffres, `_`, `-`, `.` et `[n]` :
+
+| Espace réservé | Sur | Donne |
+|---|---|---|
+| `$(field)` | un champ texte, nombre ou mot de passe | la valeur |
+| `$(field)` | un enum d'enregistrements | la `placeholderColumn` de l'enregistrement sélectionné, sinon sa première colonne |
+| `$(field.col)` | un enum d'enregistrements | cette colonne de l'enregistrement sélectionné |
+| `$(field)` | un enum avec `multiple: true` | la colonne choisie de chaque enregistrement sélectionné, sous forme de tableau |
+| `$(field)` | une expression, une liste ou une constante | la valeur entière (une liste donne ses lignes) |
+| `$(field.a.b)`, `$(f[0].x)` | une expression, une liste ou une constante | cette partie de l'objet ou du tableau |
+
+Définir `placeholderColumn: "*"` sur un enum fait que `$(field)` donne tout l'enregistrement sélectionné au lieu d'une seule colonne.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Comment la valeur est insérée
+
+La manière dont une valeur est insérée dans le texte dépend de l'endroit où se trouve l'espace réservé.
+
+| Où | Exemple | Devient |
+|---|---|---|
+| une expression, hors guillemets | `$(count) + 1` | un littéral JavaScript : un nombre reste un nombre, un texte devient une chaîne entre guillemets, un objet ou un tableau un littéral |
+| une expression, une chaîne entre guillemets entière | `fn.fnLs('$(dir)')` | le même littéral, guillemets compris, pour qu'une valeur contenant un guillemet ne puisse pas en sortir |
+| une expression, à l'intérieur d'une chaîne plus longue | `'$(dir)/vars'` | le texte, échappé pour cette chaîne |
+| une requête, un libellé, un texte d'aide | `where city='$(city)'` | le texte |
+
+Un champ dont les espaces réservés ne peuvent pas encore tous être résolus n'est pas évalué ; avec `ignoreIncomplete: true`, une valeur manquante est
+insérée sous la forme `undefined` à la place.
+
+### Backticks et `${` dans une valeur
+
+Depuis la 7.3.0, une valeur de champ ne peut pas s'exécuter comme du code quand le serveur l'insère dans une expression (expressions distantes, validation
+au lancement, MCP et chat). Un backtick ou `${` dans la valeur est écrit sous forme d'échappement unicode (`\u0060`, `\u0024{`), pour qu'il reste
+du texte même à l'intérieur d'un template literal. Les expressions côté serveur refusent complètement les template literals ; utilisez `runLocal` pour ceux-ci.
+
+Une expression `runLocal` évaluée dans le navigateur insère la valeur comme l'indique le tableau ci-dessus, sans cet échappement : ne mettez donc pas
+d'espace réservé à l'intérieur d'un template literal dans ce cas.
+
+---
+
+## Voir aussi
+
+Pages et entrées de FAQ liées :
+
+- [Expressions locales](local.html) et [Expressions distantes](remote.html) : là où la plupart des espaces réservés sont utilisés
+- [FAQ : Listes déroulantes en cascade](../faq.html#cascaded-dropdowns) et [Espaces réservés de champ](../faq.html#field-placeholders) : d'autres exemples
+- [FAQ : Comment accéder aux données du formulaire parent dans un sous-formulaire ?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/fr/_build_forms/expressions/remote.md b/i18n/fr/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..1de4bdc
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Expressions distantes
+parent: Expressions
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Expressions distantes
+{: .no_toc }
+
+Fonctions côté serveur pour les dates, réseaux, fichiers, SSH et noms numérotés
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Les exemples suivants s'exécutent avec la propriété de champ `runLocal: false` (par défaut).  
+Ils sont évalués côté serveur.
+
+Comme évaluer du code sur le serveur présente un risque de sécurité, l'expression est filtrée et limitée aux fonctions
+fournies avec AnsibleForms et aux [fonctions que vous ajoutez vous-même](#your-own-functions).  
+Les expressions côté serveur servent à récupérer des informations depuis des sources de données comme des fichiers, des API REST et des commandes SSH.
+
+{: .important }
+Les fonctions côté serveur intégrées sont préfixées par `fn.` (par exemple `fn.fnRestBasic`), les vôtres par `fnc.`.
+
+---
+
+## Manipuler la date et l'heure
+
+Travaillez avec les dates et les heures grâce à [Day.js](https://day.js.org) :
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## Obtenir les informations CIDR d'une IP
+
+Obtenez le sous-réseau d'une adresse IP et d'un masque, et vérifiez quelles adresses en font partie :
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## Obtenir la sortie SSH
+
+Exécutez une commande sur un hôte distant via SSH et utilisez sa sortie :
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Lister les fichiers d'un répertoire
+
+Listez les fichiers d'un répertoire sur le serveur AnsibleForms, éventuellement de façon récursive et filtrée :
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Analyser une page HTML
+
+Récupérez une page HTML et extrayez les parties qui correspondent à une expression régulière :
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+La page est récupérée sous [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) et
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), comme les fonctions REST. Contrairement à elles, elle ignore
+`REST_IGNORE_CERTS` et `REST_TIMEOUT_SECONDS` : elle vérifie toujours le certificat et attend au maximum 30 secondes.
+
+---
+
+## Obtenir des informations DNS
+
+Résolvez un enregistrement DNS d'un domaine :
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Lire un fichier JSON
+
+Lisez un fichier JSON sur le serveur, éventuellement filtré avec jq :
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Lire un fichier YAML
+
+Lisez un fichier YAML sur le serveur, éventuellement filtré avec jq :
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Obtenir un nom avec une numérotation incrémentale
+
+Dans un tableau de chaînes à numéros incrémentaux (server001, server002, ...), vous aurez peut-être besoin de trouver le prochain nom disponible.  
+Cette fonction est aussi disponible comme expression locale (sans le préfixe `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Sur le serveur, `fn.fnGetNumberedName` échoue avec une erreur quand le premier argument n'est pas un tableau. L'expression locale
+(sans `fn.`) renvoie plutôt la valeur par défaut.
+
+---
+
+## Vos propres fonctions
+
+Ajoutez vos propres fonctions JavaScript à `custom.js`, et appelez-les dans une expression serveur avec le préfixe `fnc.`.
+
+Le fichier exporte un objet de fonctions. Celui fourni avec l'image contient deux exemples :
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+De la même façon, `jq.custom.definitions` contient vos propres définitions jq. Elles sont placées devant chaque requête jq que le
+serveur exécute, de sorte que les [requêtes jq](jq.html) de toutes les fonctions peuvent les utiliser.
+
+Dans un conteneur, montez les deux fichiers par-dessus ceux de l'image, puis redémarrez ; ils sont lus au démarrage du serveur :
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Une fonction personnalisée s'exécute dans le processus du serveur, avec ses droits, chaque fois qu'une expression l'appelle. Le
+> [filtre](index.html#security-concerns) vérifie que l'expression n'appelle que des fonctions `fn.` et `fnc.` ; ce qu'une
+> fonction fait de ses arguments dépend de vous.
diff --git a/i18n/fr/_build_forms/expressions/rest-apis.md b/i18n/fr/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..ffd5067
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: API REST
+parent: Expressions
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# API REST
+{: .no_toc }
+
+Appeler des API REST avec une authentification basique, par jeton ou personnalisée
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## API REST avec authentification basique
+
+Appelez une API REST avec l'utilisateur et le mot de passe d'un identifiant enregistré :
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## API REST avec authentification par jeton
+
+Appelez une API REST avec un jeton bearer écrit dans l'expression :
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST avec authentification par jeton sécurisé
+
+Appelez une API REST avec un jeton bearer tiré d'un identifiant enregistré, pour qu'il n'apparaisse jamais dans le formulaire :
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST avec en-têtes personnalisés
+
+Appelez une API REST avec vos propres en-têtes, pour tout autre type d'authentification :
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certificats et délais d'attente
+
+Depuis la 7.3.0, chaque fonction d'aide REST (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) vérifie le certificat
+TLS du point de terminaison et cesse d'attendre après un délai fixé :
+
+| Paramètre | Ce qu'il change |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` désactive la vérification du certificat. Jusqu'à la 7.2.0, il n'était jamais vérifié ; laissez-le à `0` et faites plutôt confiance à une CA privée avec `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Combien de temps un appel attend une réponse, 60 secondes par défaut ; un point de terminaison qui ne répond jamais fait alors échouer le champ au lieu de le bloquer |
+
+Depuis la 7.3.0, un champ dont le point de terminaison a un certificat auto-signé échoue avec une erreur de certificat tant que l'un des deux n'est pas défini.
+[Appels REST et jq](../customization/security.html#rest-calls-and-jq) décrit les deux, et comment faire confiance à une CA privée pour tous les appels REST à la fois.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) n'est pas une fonction d'aide REST : elle ignore les deux paramètres, vérifie toujours le
+certificat et attend au maximum 30 secondes.
diff --git a/i18n/fr/_build_forms/expressions/sorting.md b/i18n/fr/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..b33618a
--- /dev/null
+++ b/i18n/fr/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Tri
+parent: Expressions
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Tri
+{: .no_toc }
+
+Trier des tableaux avec un objet de tri
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Trier un tableau
+
+Triez un tableau provenant d'une expression, d'une API REST ou d'une base de données avec un objet de tri :
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## L'objet de tri
+
+Les fonctions REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) prennent cet objet de tri
+en argument. Pour tout autre résultat, comme `fn.fnJq` ou la lecture d'un fichier, enveloppez-le dans `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/fr/_build_forms/formfields/checkbox.md b/i18n/fr/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..76365c9
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Champs de formulaire
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Champ Checkbox
+{: .no_toc }
+
+Une valeur vraie ou fausse, pour activer une option ou positionner un indicateur
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `checkbox`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `checkbox`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/datetime.md b/i18n/fr/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..614f39b
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Champs de formulaire
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Champ Datetime
+{: .no_toc }
+
+Un sélecteur de date, d'heure, de semaine, de mois ou d'année
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `datetime`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `datetime`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/enum.md b/i18n/fr/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..4fa6159
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Champs de formulaire
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Champ Enum
+{: .no_toc }
+
+Une liste déroulante avec recherche, pour un choix simple ou multiple
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `enum`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `enum`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/expression.md b/i18n/fr/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..980c6cf
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Champs de formulaire
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Champ Expression
+{: .no_toc }
+
+Une valeur calculée en JavaScript, dans le navigateur ou sur le serveur
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `expression`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `expression`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/file.md b/i18n/fr/_build_forms/formfields/file.md
new file mode 100644
index 0000000..e7dd5cb
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Champs de formulaire
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Champ File
+{: .no_toc }
+
+Envoyer des fichiers, comme des fichiers de configuration ou des certificats
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `file`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `file`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/html.md b/i18n/fr/_build_forms/formfields/html.md
new file mode 100644
index 0000000..5c68dfa
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Champs de formulaire
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Champ Html
+{: .no_toc }
+
+Du contenu HTML riche dans un formulaire
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `html`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `html`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/index.md b/i18n/fr/_build_forms/formfields/index.md
new file mode 100644
index 0000000..6b15b97
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Champs de formulaire
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Champs de formulaire
+{: .no_toc }
+
+Les contrôles de saisie d'un formulaire
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les auteurs de formulaires : les types de champ qu'un formulaire peut contenir, et les propriétés prises en charge par chacun.
+
+Les champs de formulaire définissent les contrôles de saisie d'un formulaire. Chaque type de champ a ses propres propriétés et son propre comportement pour recueillir un type de données particulier.
+
+Choisissez le type de champ qui correspond aux données à recueillir, du texte simple aux listes structurées.
+
+---
+
+## Propriétés communes
+
+Tous les champs de formulaire partagent deux propriétés fondamentales :
+
+- **name** (string, obligatoire) : l'identifiant unique du champ
+- **type** (string, obligatoire) : le type de champ, qui détermine laquelle des pages ci-dessous décrit les propriétés disponibles
+
+Chaque type de champ ajoute des propriétés propres à sa fonction. Sélectionnez un type de champ dans la barre de navigation latérale ou dans le tableau ci-dessous pour ouvrir la référence complète de ses propriétés :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Type de champ</th>
+      <th>Description</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/fr/_build_forms/formfields/list.md b/i18n/fr/_build_forms/formfields/list.md
new file mode 100644
index 0000000..903d774
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Champs de formulaire
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Champ List
+{: .no_toc }
+
+Un tableau de lignes, chacune modifiée dans un sous-formulaire
+{: .fs-6 .fw-300 }
+
+---
+
+Un champ list affiche un tableau de lignes, chacune créée et modifiée dans un volet de **sous-formulaire** dédié (un modèle d'exploration). Il remplace le champ `table`, supprimé dans la 7.0.0.
+
+---
+
+## Fonctionnalités clés
+
+Le champ list offre les possibilités suivantes :
+
+- Chaque ligne est modifiée dans un sous-formulaire plein écran, qui donne accès à tous les types de champ, y compris les listes imbriquées.
+- Le sous-formulaire est un formulaire à part entière, de type `subform`, et peut être **réutilisé par plusieurs champs list** dans différents formulaires (par ex. un seul sous-formulaire `Address` partagé par les clients, les fournisseurs, les commandes…).
+- Les propriétés de marqueur (`insertMarker`, `updateMarker`, `deleteMarker`) permettent des modèles de playbook idempotents.
+- Avec `allowDelete: false`, les lignes préexistantes sont protégées ; seules les lignes ajoutées pendant la session en cours (qui portent l'`insertMarker`) peuvent être supprimées.
+- La propriété `columns` contrôle quels champs du sous-formulaire apparaissent comme colonnes dans le tableau récapitulatif.
+- La sortie est toujours un tableau d'objets. `model`, `output`, `outputObject` et `valueColumn` déclarés sur les champs du sous-formulaire sont respectés lors de la génération des extravars.
+
+---
+
+## Déclaration d'un sous-formulaire
+
+Un sous-formulaire est un formulaire à part entière avec `type: subform`, dans un fichier du dossier des formulaires comme n'importe quel autre formulaire. Il accepte le même tableau `fields` que tout autre formulaire, mais il n'apparaît jamais dans la liste des tuiles de formulaires et n'est jamais soumis directement.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `list`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Exemples</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Exemples
+
+### Sous-formulaire d'adresse partagé
+
+Un sous-formulaire `Address` réutilisé par deux champs list du même formulaire :
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Suivi par marqueurs (compatible avec l'idempotence)
+
+Les lignes préchargées sont protégées, et les marqueurs indiquent au playbook quelles lignes sont nouvelles, modifiées ou supprimées :
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Pré-remplir les lignes
+
+Une liste peut être pré-remplie depuis trois sources. Dans tous les cas, les lignes obtenues doivent être des objets dont les clés correspondent aux noms des champs du sous-formulaire référencé.
+
+#### `default` statique
+
+Des lignes écrites dans le formulaire lui-même :
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Depuis une API REST (`expression`)
+
+Des lignes chargées depuis une API REST par une expression côté serveur :
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Depuis une requête de base de données (`dbConfig` + `query`)
+
+Des lignes chargées depuis une requête de base de données :
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Depuis une expression locale (`runLocal`)
+
+Des lignes calculées dans le navigateur par une expression locale :
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Listes imbriquées
+
+Un sous-formulaire peut contenir son propre champ list, pour avoir une liste dans chaque ligne :
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Accéder aux données du formulaire parent via `__parent__`
+
+Quand l'éditeur de ligne d'un sous-formulaire s'ouvre, AnsibleForms injecte une variable `__parent__` dans le sous-formulaire. Elle contient un instantané de **toutes les valeurs des champs du formulaire parent**, y compris les constantes et les vars.
+
+Faites-y référence avec la syntaxe d'expression standard `$(...)` dans les définitions de champ du sous-formulaire :
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` est une aide **propre au frontend**. Elle est retirée des extravars Ansible et n'est jamais envoyée au playbook.
+
diff --git a/i18n/fr/_build_forms/formfields/number.md b/i18n/fr/_build_forms/formfields/number.md
new file mode 100644
index 0000000..3c5a3d4
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Champs de formulaire
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Champ Number
+{: .no_toc }
+
+Une valeur entière ou décimale, comme un port ou une quantité
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `number`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `number`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/password.md b/i18n/fr/_build_forms/formfields/password.md
new file mode 100644
index 0000000..4478783
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Champs de formulaire
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Champ Password
+{: .no_toc }
+
+Une valeur masquée, pour les mots de passe, secrets et jetons
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `password`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `password`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/radio.md b/i18n/fr/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..5c4e410
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Champs de formulaire
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Champ Radio
+{: .no_toc }
+
+Un choix parmi un ensemble d'options mutuellement exclusives
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `radio`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `radio`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/text.md b/i18n/fr/_build_forms/formfields/text.md
new file mode 100644
index 0000000..8b1c1c3
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Champs de formulaire
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Champ Text
+{: .no_toc }
+
+Une seule ligne de texte, comme un nom ou un nom d'hôte
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `text`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `text`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/textarea.md b/i18n/fr/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..87f22fb
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Champs de formulaire
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Champ Textarea
+{: .no_toc }
+
+Du texte sur plusieurs lignes, comme une description ou un extrait de configuration
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `textarea`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `textarea`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/fr/_build_forms/formfields/yaml.md b/i18n/fr/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..8644a1c
--- /dev/null
+++ b/i18n/fr/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Champs de formulaire
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Champ YAML
+{: .no_toc }
+
+Des données structurées dans un éditeur YAML, avec validation et import de fichier
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriétés
+
+Les propriétés disponibles pour un champ `yaml`, regroupées par usage :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valeur :</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de champs `yaml`, en YAML :
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition du champ, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Accéder aux données du formulaire parent via `__parent__`
+
+Quand un champ `yaml` utilise le mode `subform`, AnsibleForms injecte une variable `__parent__` dans le sous-formulaire. Elle contient un instantané de **toutes les valeurs des champs du formulaire parent** au moment où l'éditeur s'ouvre, y compris les constantes et les vars.
+
+Faites-y référence avec la syntaxe d'expression standard `$(...)` dans les définitions de champ du sous-formulaire :
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` est une aide **propre au frontend**. Elle est retirée des extravars Ansible et n'est jamais envoyée au playbook.
diff --git a/i18n/fr/_build_forms/forms/ansible.md b/i18n/fr/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..096f465
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulaires Ansible
+parent: Formulaires
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Formulaires Ansible
+{: .no_toc }
+
+Des formulaires qui exécutent un playbook Ansible local
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: ansible`, en plus des [propriétés communes des formulaires](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/approval.md b/i18n/fr/_build_forms/forms/approval.md
new file mode 100644
index 0000000..de7ce35
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Points d'approbation
+parent: Formulaires
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Points d'approbation
+{: .no_toc }
+
+Mettre un job en pause jusqu'à ce que quelqu'un l'approuve
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fonctionnement
+
+Un point d'approbation met le job en pause à son emplacement dans le formulaire jusqu'à ce qu'un approbateur y réponde :
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Approuver son propre job
+
+Depuis la 7.3.0, l'utilisateur qui a lancé un job ne peut pas l'approuver, même avec l'un des rôles de l'approbation : il faut donc une deuxième personne ; un admin peut toujours approuver, y compris ses propres jobs.
+Celui qui l'a lancé peut toujours rejeter (retirer) son propre job. Définissez `allowSelf: true` s'il peut aussi l'approuver, par exemple dans un formulaire de test :
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Attributs
+
+Les attributs d'un point d'approbation :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de points d'approbation, en YAML :
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/awx.md b/i18n/fr/_build_forms/forms/awx.md
new file mode 100644
index 0000000..9ab9c79
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulaires AWX
+parent: Formulaires
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# Formulaires AWX
+{: .no_toc }
+
+Des formulaires qui lancent un job template AWX, AAP ou Ascender
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: awx`, en plus des [propriétés communes des formulaires](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/common.md b/i18n/fr/_build_forms/forms/common.md
new file mode 100644
index 0000000..15fcf09
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Propriétés communes
+parent: Formulaires
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Propriétés communes des formulaires
+{: .no_toc }
+
+Les propriétés partagées par tous les types de formulaire
+{: .fs-6 .fw-300 }
+
+---
+
+Ces propriétés s'appliquent à **tous les types de formulaire** : `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (obsolète) et `subform`.
+
+Toutes les autres propriétés sont propres à un type et documentées sur la page du type de formulaire concerné.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Propriétés
+
+Les propriétés partagées par tous les types de formulaire :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/fr/_build_forms/forms/index.md b/i18n/fr/_build_forms/forms/index.md
new file mode 100644
index 0000000..da7b001
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formulaires
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formulaires
+{: .no_toc }
+
+Définir les formulaires que remplissent vos utilisateurs
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les auteurs de formulaires : comment les formulaires s'écrivent en YAML, d'où ils sont chargés, et les propriétés de chaque type de formulaire.
+
+Les formulaires sont au cœur d'AnsibleForms. Chaque formulaire est une interface web qui recueille les saisies de l'utilisateur et, avec ces données, exécute
+un playbook Ansible, un template AWX, AAP ou Ascender, un template Semaphore, un job Rundeck ou Jenkins, ou un
+[workflow](../workflows/).
+
+Les formulaires sont définis dans des fichiers YAML du dossier des formulaires. Chaque fichier YAML contient soit un seul formulaire, soit une liste de formulaires, et des sous-dossiers peuvent servir à les organiser.
+
+**VIDÉO** : [Créer votre premier formulaire](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Comprendre la structure d'un formulaire
+
+Chaque formulaire d'AnsibleForms est configuré avec un ensemble de propriétés. **[Propriétés communes](common.html)** liste les propriétés qui s'appliquent à tous les types de formulaire ; les pages propres à chaque type décrivent les propriétés supplémentaires.
+
+---
+
+## Comment les formulaires sont chargés
+
+AnsibleForms charge les formulaires depuis les emplacements suivants :
+
+1. **DEPUIS LES DÉPÔTS** : tous les dépôts dont l'interrupteur « Utiliser pour les formulaires ? » est activé (plusieurs dépôts sont pris en charge)
+   - Les formulaires de tous les dépôts activés sont fusionnés automatiquement.
+   - Dans chaque dépôt, on cherche d'abord un sous-dossier `forms/`.
+   - S'il n'existe pas de sous-dossier `forms/`, la racine du dépôt est utilisée.
+   - Les formulaires créés dans le concepteur et pas encore poussés sont conservés dans un dossier de préparation
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) et chargés avec eux.
+
+2. **DEPUIS LE DOSSIER LOCAL** : le dossier local `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), quand aucun dépôt n'a « Utiliser pour les formulaires ? » activé
+
+{: .warning }
+> **Remarque :** quand « Utiliser pour les formulaires ? » est activé sur plusieurs dépôts, tous leurs formulaires sont fusionnés. Les noms de formulaire doivent être uniques entre les dépôts pour éviter les conflits.
+
+---
+
+## Où un formulaire s'exécute
+
+Le type d'un formulaire décide du genre de [runner](../runners.html) sur lequel son job s'exécute : un RTE pour `ansible`, un runner AWX pour `awx`,
+`aap` et `ascender`, et un runner de son propre type pour `semaphore`, `rundeck` et `jenkins`.
+
+- `runner: <name>` sur le formulaire choisit un runner de ce type par son nom ; sans cela, le job s'exécute sur le runner par défaut du type.
+- Un runner désactivé dans **Connexions > Runners** fait échouer le job, que le formulaire le nomme ou qu'il soit celui par défaut. Le job
+  ne se rabat jamais sur un autre runner.
+- Lorsque l'un des rôles de l'utilisateur liste `runners` dans `config.yaml`, le job ne peut s'exécuter que sur un runner listé par un tel rôle, sinon il est
+  refusé. Les rôles sans cette liste ne le limitent pas, et un administrateur n'est jamais limité.
+
+---
+
+## Dans cette section
+
+Les pages suivantes décrivent en détail les propriétés des formulaires :
+
+| Page | Contenu |
+|---|---|
+| [Propriétés communes](common.html) | Les propriétés qui s'appliquent à tous les types de formulaire (`name`, `description`, `help`, `type`, `fields`) |
+| [Formulaires Ansible](ansible.html) | Les propriétés propres à `type: ansible` |
+| [Formulaires AWX](awx.html) | Les propriétés propres à `type: awx` |
+| [Formulaires Semaphore](semaphore.html) | Les propriétés propres à `type: semaphore`, qui exécute un template Semaphore |
+| [Formulaires Rundeck](rundeck.html) | Les propriétés propres à `type: rundeck`, qui exécute un job Rundeck |
+| [Formulaires Jenkins](jenkins.html) | Les propriétés propres à `type: jenkins`, qui lance le build d'un job Jenkins |
+| [Formulaires multistep](multistep.html) | Les propriétés propres à `type: multistep`, obsolète au profit de `workflow` |
+| [Formulaires workflow](workflow.html) | Les propriétés propres à `type: workflow`, qui exécute un [workflow](../workflows/) |
+| [Assistant](wizard.html) | Répartir la saisie d'un formulaire sur plusieurs pages (fonctionne avec tout type de formulaire exécutable) |
+| [Sous-formulaire](subform.html) | Les sous-formulaires n'utilisent que les propriétés communes |
+| [Points d'approbation](approval.html) | Mettre un job en pause jusqu'à son approbation (`approval`) |
+| [Notifications](notifications.html) | Envoyer des e-mails et des messages sur des canaux selon le statut ou les événements d'un job (`notifications`) |
+| [Actions sur statut de job](job-status-action.html) | Agir sur le formulaire quand un job change de statut (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/fr/_build_forms/forms/jenkins.md b/i18n/fr/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..05f357c
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulaires Jenkins
+parent: Formulaires
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Formulaires Jenkins
+{: .no_toc }
+
+Des formulaires qui lancent le build d'un job Jenkins
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: jenkins`, en plus des [propriétés communes des formulaires](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/job-status-action.md b/i18n/fr/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..cc176d6
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Actions sur statut de job
+parent: Formulaires
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Actions sur statut de job
+{: .no_toc }
+
+Agir sur le formulaire quand son job est soumis, réussit, échoue ou se termine
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Les hooks suivants sont disponibles :
+
+- `onSubmit` : déclenché quand le formulaire est soumis
+- `onSuccess` : déclenché quand le job se termine avec succès
+- `onFailure` : déclenché quand le job échoue
+- `onFinish` : déclenché quand le job se termine, quel que soit son statut
+- `onAbort` : déclenché quand le job est interrompu
+
+---
+
+## Attributs
+
+Les attributs d'une action sur statut de job :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples d'actions sur statut de job, en YAML :
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/multistep.md b/i18n/fr/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..b1dbe4a
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Formulaires multistep
+parent: Formulaires
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Formulaires multistep
+{: .no_toc }
+
+Exécuter plusieurs playbooks ou templates à la suite depuis un seul formulaire
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` est obsolète depuis la 7 et supprimé dans la 8 : utilisez plutôt un [workflow](workflow.html). Un workflow fait tout ce que
+> fait un multistep, avec des conditions, des valeurs propres à chaque nœud, des nœuds d'approbation et des branches qui s'exécutent en parallèle.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriété au niveau du formulaire
+
+Un formulaire multistep définit ses étapes dans une seule propriété au niveau du formulaire :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / obligatoire</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Outre `steps`, un formulaire multistep accepte ces propriétés au niveau du formulaire, documentées sur la page [Formulaires Ansible](ansible.html) :
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (obligatoire){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Propriétés des étapes
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Disponible uniquement avec les types :</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Ajouté</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Exemples
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Exemple
+
+Un formulaire multistep exécute plusieurs jobs à la suite, chaque étape lançant son propre playbook ou template AWX. Toutes les étapes partagent les champs du formulaire : par défaut, chaque étape reçoit toutes les extravars, et la `key` d'une étape la limite à cette partie d'entre elles.
+
+### Créer et configurer un serveur
+
+Chaque étape reçoit sa propre partie des extravars : une étape AWX crée le serveur, une étape Ansible configure son réseau, et une dernière étape envoie toujours un rapport :
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/fr/_build_forms/forms/notifications.md b/i18n/fr/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..87c8f89
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Notifications
+parent: Formulaires
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Notifications
+{: .no_toc }
+
+Envoyer un e-mail ou un message sur un canal quand un job se termine ou qu'il lui arrive quelque chose
+{: .fs-6 .fw-300 }
+
+---
+
+Les `notifications` d'un formulaire indiquent qui est informé de ses jobs, et quand :
+
+- **Qui** : `recipients`, des adresses e-mail, et `channels`, les noms de
+  [canaux de notification](../notification-channels.html) (mail, Slack, Microsoft Teams, Telegram, un webhook). Au moins l'un
+  des deux est obligatoire.
+- **Quand** : `onStatus`, quand un job se termine (`success`, `failed`, `aborted`, `warning` ou `any`), et `onEvent`, quand
+  il arrive quelque chose à un job (`launch`, `relaunch`, `delete`, `approve`, `reject` ou `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Attributs
+
+Les attributs de l'objet `notifications` :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemples
+
+Exemples de notifications, en YAML :
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La définition, en YAML :{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/rundeck.md b/i18n/fr/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..af9212e
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulaires Rundeck
+parent: Formulaires
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Formulaires Rundeck
+{: .no_toc }
+
+Des formulaires qui exécutent un job Rundeck
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: rundeck`, en plus des [propriétés communes des formulaires](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/semaphore.md b/i18n/fr/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..22c98f2
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulaires Semaphore
+parent: Formulaires
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Formulaires Semaphore
+{: .no_toc }
+
+Des formulaires qui exécutent un template Semaphore UI
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: semaphore`, en plus des [propriétés communes des formulaires](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/forms/subform.md b/i18n/fr/_build_forms/forms/subform.md
new file mode 100644
index 0000000..ace0ef6
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Sous-formulaire
+parent: Formulaires
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Sous-formulaire
+{: .no_toc }
+
+Un fragment de formulaire réutilisable pour les champs list, les champs yaml et les pages d'assistant
+{: .fs-6 .fw-300 }
+
+---
+
+Un sous-formulaire est un fragment de formulaire réutilisable. Il n'apparaît pas dans la vue en tuiles et ne peut pas être soumis directement. Il est référencé par :
+
+- Un champ [`list`](../formfields/list.html) : ouvre le sous-formulaire comme éditeur détaillé pour chaque ligne
+- Un champ [`yaml`](../formfields/yaml.html) avec la propriété `subform` : ouvre le sous-formulaire comme éditeur détaillé pour un seul objet
+- Une étape d'[`wizard`](wizard.html) : affiche le sous-formulaire comme une page de l'assistant
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Les sous-formulaires n'ont **aucune propriété propre à leur type**. Ils n'utilisent que les [propriétés communes des formulaires](common.html) : `name`, `description`, `help`, `type` et `fields`.
+
+Quand un sous-formulaire sert de page d'assistant, sa `description` et son `help` fournissent les valeurs par défaut du `title` et du `help` de l'étape. Il peut aussi définir `showHelp` pour déplier cette aide au chargement de la page.
+
+Les propriétés d'exécution (`playbook`, `template`, `roles`, `inventory`, etc.) ne s'appliquent pas aux sous-formulaires, car un sous-formulaire n'est jamais soumis directement.
+
diff --git a/i18n/fr/_build_forms/forms/wizard.md b/i18n/fr/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..2d4a96b
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Assistant
+parent: Formulaires
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Assistant
+{: .no_toc }
+
+Répartir la saisie d'un formulaire sur plusieurs pages avec Retour et Suivant
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Qu'est-ce qu'un assistant ?
+
+Un **assistant** (`wizard`) transforme un formulaire unique en une suite de pages. Chaque page est rendue à partir d'un [`subform`](subform.html) et l'utilisateur navigue avec les boutons **Retour** et **Suivant**. La validation s'applique page par page : l'utilisateur ne peut pas avancer tant que l'étape en cours n'est pas valide, sauf si l'étape est marquée `optional`.
+
+Une **page de récapitulatif** en lecture seule est ajoutée automatiquement à la fin de chaque assistant. Elle liste chaque étape avec les valeurs recueillies pour que l'utilisateur puisse les confirmer avant de soumettre. La page de récapitulatif n'est **pas** déclarée en YAML ; son titre provient de la langue active.
+
+À la soumission, les **valeurs recueillies à toutes les étapes sont fusionnées en un seul ensemble d'extravars** et envoyées au playbook, au template ou au workflow sous-jacent, exactement comme si l'utilisateur avait rempli un seul grand formulaire.
+
+Un formulaire avec un `wizard` n'a pas besoin de ses propres `fields`, mais il ne peut pas définir `enableForChat`, et un `subform` ne peut pas avoir lui-même de `wizard`. La [validation au lancement](../launch-validation/rolling-it-out.html#wizard-forms) vérifie le lancement d'un assistant étape par étape.
+
+{: .note }
+> Pour savoir en quoi un `wizard` diffère d'un workflow, et comment combiner les deux, consultez l'entrée de FAQ [Quelle est la différence entre un assistant et un workflow ?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Propriété au niveau du formulaire
+
+Un assistant s'active avec une seule propriété au niveau du formulaire :
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">ajouté dans la version {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Exemples :**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés des étapes de l'assistant
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unique</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Ajouté</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Exemples
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Combiner un assistant avec un workflow
+
+Un assistant peut se superposer à un formulaire [workflow](workflow.html). Quand le `defaultModel` de chaque étape de l'assistant correspond à l'[`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) du nœud de workflow correspondant, chaque playbook ou template ne reçoit que les valeurs de sa propre page d'assistant.
+
+La FAQ contient un exemple complet et la structure des extravars fusionnées : [Quelle est la différence entre un assistant et un workflow ?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (section *Combiné (assistant par-dessus un workflow)*).
+
+Un assistant sur un formulaire [`multistep`](multistep.html) obsolète fonctionne de la même façon, avec la [`key`](multistep.html#step_key) de l'étape à la place d'`extra_vars_key`.
+
+---
+
+## Voir aussi
+
+Pages et entrées de FAQ liées :
+
+- [Sous-formulaire](subform.html) : les pages de l'assistant sont rendues à partir de sous-formulaires
+- [Formulaires workflow](workflow.html) : l'équivalent de l'assistant du côté de l'exécution
+- [`__parent__` dans les sous-formulaires](../faq.html#how-do-i-access-parent-form-data-inside-a-subform) : comment faire référence aux étapes précédentes de l'assistant depuis une étape ultérieure
diff --git a/i18n/fr/_build_forms/forms/workflow.md b/i18n/fr/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..55aeb66
--- /dev/null
+++ b/i18n/fr/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Formulaires workflow
+parent: Formulaires
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Formulaires workflow
+{: .no_toc }
+
+Des formulaires qui exécutent l'un des workflows du concepteur
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriétés
+
+Propriétés propres à `type: workflow`, en plus des [propriétés communes des formulaires](common.html). La section
+[Workflows](../workflows/) décrit les fichiers de workflow eux-mêmes.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribut</th>
+      <th>Commentaires</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obligatoire</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">ajouté dans la version {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Choix :</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (par défaut)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Par défaut :</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemples :</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/fr/_build_forms/launch-validation/file-uploads.md b/i18n/fr/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..7097ab2
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Envois de fichiers
+parent: Validation au lancement
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Envois de fichiers
+{: .no_toc }
+
+Comment les champs fichier sont validés
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un champ fichier ne fait jamais confiance à ce que la requête de lancement dit d'un fichier. La validation au lancement vérifie le fichier lui-même, sur le
+disque du serveur.
+
+---
+
+## Comment un envoi parvient à un job
+
+Un fichier est envoyé avant le lancement du formulaire, en deux étapes :
+
+1. Le navigateur envoie le fichier avec `POST /api/v2/job/upload`. Le serveur le stocke dans `UPLOAD_PATH`.
+2. La requête de lancement décrit cet envoi dans sa partie `files`.
+
+La validation au lancement compare ensuite la description au disque :
+
+* Le fichier doit exister dans `UPLOAD_PATH`.
+* Son chemin et sa taille sont lus sur le disque, jamais dans la requête.
+
+---
+
+## Ce qui est accepté
+
+Un champ fichier ne reçoit de valeur que d'un envoi vérifié. Tout le reste est écarté :
+
+* Un chemin que l'appelant écrit dans `rawFormData` ou `extravars` est ignoré.
+* Un champ fichier obligatoire sans envoi réel est signalé comme `missing`.
+
+---
+
+## Règles de fichier
+
+Les règles d'un champ fichier sont vérifiées sur l'envoi réel, avec des tailles en octets :
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` et `maxSize` comparent la taille réelle du fichier, et `regex` son nom. Indépendamment de tout formulaire,
+`UPLOAD_MAX_GB` plafonne la taille d'un envoi (10 Go par défaut).
diff --git a/i18n/fr/_build_forms/launch-validation/index.md b/i18n/fr/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..88a98cd
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Validation au lancement
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Validation au lancement
+{: .no_toc }
+
+Vérifier chaque lancement d'un formulaire sur le serveur
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs et les auteurs de formulaires : faites vérifier par le serveur chaque lancement, ses règles et ses extravars, quel que soit son expéditeur.
+
+La vérification s'applique quel que soit qui ou ce qui lance le formulaire : le navigateur, un script qui appelle l'API REST,
+ou un agent IA via le serveur MCP.
+
+---
+
+## Pourquoi elle existe
+
+Les règles d'un formulaire (`required`, `regex`, `minValue`, `sameAs`, ...) ont toujours été vérifiées
+dans le navigateur. Le navigateur envoie ensuite deux choses à `POST /api/v2/job` :
+
+- `rawFormData` : les valeurs des champs telles que l'utilisateur les a saisies ;
+- `extravars` : ce que reçoit le playbook, construit à partir de ces valeurs dans le navigateur.
+
+Sans validation au lancement, le serveur fait confiance aux deux. N'importe qui disposant d'un jeton valide peut appeler ce
+point de terminaison directement et envoyer n'importe quelles extravars, sans qu'aucune regex, aucun champ obligatoire ni aucune règle de liste
+ne s'applique. Pour un formulaire utilisé uniquement dans le navigateur, cela peut être acceptable ; pour un
+formulaire que d'autres systèmes lancent via REST, cela signifie que les règles du formulaire ne sont pas du tout appliquées.
+
+Le serveur n'a pas non plus de moyen de distinguer une requête du navigateur d'une requête envoyée par un
+script : les deux utilisent le même point de terminaison, le même jeton et le même corps, et les utilisateurs peuvent modifier
+toute requête que leur propre navigateur envoie. Une vérification n'est fiable que sur le serveur, et la validation au lancement
+est cette vérification.
+
+---
+
+## Les trois points d'entrée
+
+La manière dont un lancement est validé dépend de son origine et du mode de validation au lancement :
+
+| Lancé par | Validé | Extravars avec lesquelles le job s'exécute |
+|---|---|---|
+| **Serveur MCP** (agent IA) | toujours, sur le serveur | toujours construites par le serveur |
+| **Navigateur** ou **API REST**, validation au lancement `off` | uniquement dans le navigateur | celles envoyées par le navigateur (ou l'appelant) |
+| **Navigateur** ou **API REST**, validation au lancement `log` | sur le serveur, refus seulement journalisés | celles envoyées ; différences journalisées |
+| **Navigateur** ou **API REST**, validation au lancement `enforce` | sur le serveur, refusé s'il est invalide | **construites par le serveur** |
+
+Le navigateur, le serveur MCP et la validation au lancement utilisent le même code pour les règles (le
+moteur de formulaire partagé) : les mêmes règles, dans le même ordre, avec les mêmes messages. Une erreur affichée
+par le navigateur est refusée par le serveur avec le même texte.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Contenu |
+|---|---|
+| [L'activer](switching-it-on.html) | Pour toute l'instance, ou pour un seul formulaire |
+| [Log et enforce](log-and-enforce.html) | Ce que fait chaque mode d'un lancement qui enfreint les règles |
+| [Lignes de liste](list-rows-and-subforms.html) | Comment les lignes des champs list sont validées |
+| [Envois de fichiers](file-uploads.html) | Comment les champs fichier sont validés |
+| [Mots de passe](passwords.html) | Comment les champs mot de passe sont validés et tenus à l'écart des API |
+| [Relancer](relaunching.html) | Comment un job relancé est validé |
+| [Déploiement](rolling-it-out.html) | Faire passer une instance en enforce, et les limitations connues |
diff --git a/i18n/fr/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/fr/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..7271f8e
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Lignes de liste
+parent: Validation au lancement
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Lignes de liste
+{: .no_toc }
+
+Comment les lignes des champs list sont validées
+{: .fs-6 .fw-300 }
+
+---
+
+Un champ `list` contient des lignes ; chaque ligne est une instance de son sous-formulaire, remplie via l'éditeur
+de ligne. Un champ `yaml` avec un `subform` est une telle ligne. Le serveur les traite de la même façon
+que l'éditeur de ligne du navigateur : chaque ligne est résolue via son sous-formulaire, avec les valeurs du formulaire
+comme `__parent__`, ses règles vérifiées et ses champs calculés évalués. Les listes imbriquées fonctionnent de la
+même façon : dans la liste propre à une ligne, `$(__parent__.__parent__.x)` atteint le formulaire.
+
+Les lignes sont vérifiées comme suit :
+
+- **Une ligne que l'utilisateur a ajoutée ou modifiée** dans l'éditeur est résolue et validée.
+- **Une ligne que personne n'a touchée**, produite par la valeur par défaut, l'expression ou la requête de la liste
+  (comme les entrées existantes d'une liste d'ACL), passe **exactement telle qu'elle est arrivée**, comme dans le
+  navigateur : elle n'est pas revalidée et rien n'y est ajouté. Une entrée existante qui enfreint une règle
+  écrite plus tard n'empêche pas le lancement.
+- **Une ligne marquée comme supprimée** (le `deleteMarker` de la liste) est conservée telle quelle et n'est pas validée.
+
+Pour distinguer ces lignes sans faire confiance à la requête, le serveur exécute de nouveau la source propre à la liste
+(sa valeur par défaut, sinon son expression ou sa requête) sous la validation au lancement. Une ligne
+qui n'est pas passée par l'éditeur passe inchangée **uniquement si elle fait partie des lignes que produit cette
+source**. Toute autre ligne, comme une ligne inventée par un appelant REST, est résolue et
+validée comme une ligne modifiée. Une simple ligne ne peut donc pas contourner les vérifications, tandis que les
+lignes intactes du navigateur passent toujours inchangées.
+
+Un utilisateur du navigateur ne s'en aperçoit que dans un seul cas : les données de la source ont changé entre l'ouverture du
+formulaire et son lancement (une entrée a été modifiée ou supprimée entre-temps), **et** cette ligne
+enfreint une règle de son sous-formulaire. La ligne ne compte alors plus comme une des lignes de la source : elle
+est donc validée, et le lancement est refusé en nommant la ligne, par exemple
+`acls[2].user_or_group (regex)`.
+
+Les lignes en échec apparaissent dans `rowErrors` avec leur `index` (un champ `yaml` n'en a pas) et dans le journal sous la forme
+`disks[1].size (maxValue)`.
+
+Un lancement peut contenir au maximum **500 lignes** sur tous les niveaux d'imbrication, puisque chaque ligne exécute les requêtes de son sous-formulaire.
+
+---
+
+## Marqueurs de ligne
+
+Les marqueurs qu'une liste pose sur ses lignes (`insertMarker`, `updateMarker` et `deleteMarker` ; sans
+`insertMarker`, les nouvelles lignes reçoivent `__inserted__` quand la liste définit `allowDelete: false`, un `deleteMarker` ou un `updateMarker`)
+parviennent au playbook sur chaque ligne qui en porte un. Une ligne supprimée est envoyée avec son marqueur de
+suppression, pour que le playbook puisse la supprimer. Avant la 6.4.1, une ligne de liste ne portait de marqueur que si son
+sous-formulaire le déclarait comme champ (masqué).
diff --git a/i18n/fr/_build_forms/launch-validation/log-and-enforce.md b/i18n/fr/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..b775561
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Log et enforce
+parent: Validation au lancement
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Log et enforce
+{: .no_toc }
+
+Ce que fait chaque mode d'un lancement qui enfreint les règles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ce que fait `log`
+
+Chaque lancement est vérifié, mais rien ne change pour l'utilisateur. Un avertissement est écrit dans le journal quand :
+
+- le lancement **serait refusé**, avec la raison (noms de champ et types de règle uniquement, jamais
+  les valeurs) :
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- les extravars envoyées par le client **diffèrent** de celles que construit le serveur, avec les
+  clés de premier niveau qui diffèrent :
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Faites d'abord tourner `log` un moment sur une instance réelle. Il montre quels formulaires seraient refusés et
+lesquels calculent des valeurs différemment sur le serveur, avant que quiconque soit affecté.
+
+---
+
+## Ce que fait `enforce`
+
+Avec `enforce`, un lancement invalide est refusé, et un lancement valide s'exécute avec les extravars que construit
+le serveur.
+
+### Un lancement qui enfreint les règles est refusé
+
+`POST /api/v2/job` répond `422` avec les champs en échec :
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing` : les champs obligatoires sans valeur ;
+- `invalid` : les champs qui enfreignent une règle, les choix qui ne font pas partie des options, et les champs list
+  avec une ligne en échec ;
+- `waiting` : les champs qui n'ont pas pu être évalués (un champ dont ils ont besoin n'a jamais reçu de valeur) ;
+- `validationErrors` : par champ, chaque règle en échec avec le message qu'affiche le navigateur ;
+- `rowErrors` : par champ list, les lignes en échec (voir [Lignes de liste](list-rows-and-subforms.html)) ;
+- `uploads` : les champs fichier dont l'envoi n'a pas pu être vérifié.
+
+Un lancement **sans `rawFormData`** est refusé lui aussi : ses valeurs ne peuvent pas être vérifiées.
+
+### Un lancement valide s'exécute avec les extravars du serveur
+
+Le job ne s'exécute pas avec les extravars envoyées par le client. Le serveur les construit à partir des valeurs
+vérifiées, avec le même code que le navigateur, et exécute celles-ci. Un appelant qui envoie un `rawFormData` valide
+à côté d'`extravars` différentes obtient les extravars qui correspondent aux valeurs, et non
+celles qu'il a envoyées.
+
+De la requête, le serveur conserve `__verbose__` (uniquement pour les utilisateurs autorisés à utiliser le mode verbeux). Les
+clés réservées (`__playbook__`, `__inventory__`, ...) proviennent du formulaire, comme toujours, et
+`ansibleforms_user` est l'utilisateur qui lance.
+
+### Ce que l'utilisateur a vu n'est pas toujours ce qui s'exécute
+
+Construire les extravars signifie évaluer de nouveau le formulaire : chaque expression et chaque requête s'exécute
+une fois de plus sur le serveur, un instant après le navigateur, en tant qu'utilisateur qui lance. Une valeur
+qui dépend du **moment** ou de l'**endroit** où elle est évaluée peut différer, et dans ce cas c'est la
+valeur du serveur qui est utilisée :
+
+| Quoi | Pourquoi cela peut différer | Dans quelle mesure |
+|---|---|---|
+| `fn.fnTime()`, un horodatage, un nom construit à partir de l'heure | évalué de nouveau, quelques secondes plus tard | ne compte qu'à la limite d'une seconde ou d'une date. `fnTime` s'exécute déjà sur le serveur dans le flux du navigateur aussi, avec le même fuseau horaire (le `TZ` du conteneur) |
+| une requête, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, la lecture d'un fichier | les données externes ont changé entre-temps | seulement quand elles ont changé |
+| une expression `runLocal` qui utilise `new Date()`, `toLocaleString`, `Intl` | le navigateur utilise le fuseau horaire et la langue de l'utilisateur, le serveur les siens | seulement ces expressions |
+
+Il en va de même pour la **validation** : une règle qui lit un tel champ (`notIn` sur le résultat d'une requête,
+`validIf` sur un indicateur calculé) est vérifiée avec la valeur du serveur. Les formulaires dont les
+extravars diffèrent apparaissent dans les avertissements `log` décrits ci-dessus ; examinez-les avant de passer en enforce.
diff --git a/i18n/fr/_build_forms/launch-validation/passwords.md b/i18n/fr/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..62745b8
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Mots de passe
+parent: Validation au lancement
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Mots de passe
+{: .no_toc }
+
+Comment les champs mot de passe sont validés, stockés et tenus à l'écart des API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un champ mot de passe est validé comme n'importe quel autre champ. Sa valeur, en revanche, reste sur le serveur et n'est jamais renvoyée à
+un client.
+
+---
+
+## Où un mot de passe est conservé
+
+Le serveur stocke le mot de passe avec le job, dans ses extravars :
+
+* Une **approbation** peut alors poursuivre le job avec le mot de passe que l'utilisateur a saisi.
+* Une **relance à l'identique** peut le rejouer, quand la validation au lancement n'est pas `enforce`.
+
+Le mot de passe stocké n'est utilisé que sur le serveur.
+
+---
+
+## Ce que renvoient les API
+
+Aucune API ne renvoie jamais un mot de passe :
+
+* Un job lu via l'API REST ou le `get_job` du serveur MCP masque tous les champs `password` de son formulaire, y compris dans
+  les lignes de liste et les sous-formulaires YAML.
+* `MASK_EXTRAVARS_REGEX` (par défaut `password|secret|token`) masque aussi toute extravar dont le nom correspond, pour
+  les secrets qui ne sont pas des champs mot de passe.
+
+---
+
+## Ce que reçoit une relance
+
+Pour pré-remplir une relance, le navigateur reçoit les données brutes du formulaire du job. Ces données ne contiennent jamais de mot de passe, pas même dans
+les lignes de liste ou les sous-formulaires YAML : l'utilisateur saisit donc de nouveau le mot de passe.
+
+Un champ mot de passe que les dépendances du formulaire masquent n'est pas nécessaire et n'a pas à être saisi de nouveau.
diff --git a/i18n/fr/_build_forms/launch-validation/relaunching.md b/i18n/fr/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..ea12d7a
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Relancer
+parent: Validation au lancement
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Relancer
+{: .no_toc }
+
+Comment un job relancé est validé
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un job peut être relancé de deux façons. La manière dont la relance est vérifiée dépend de celle utilisée, et du mode de
+validation au lancement.
+
+---
+
+## Deux types de relance
+
+Les deux types diffèrent selon que l'appelant envoie ou non de nouvelles valeurs :
+
+* **À l'identique** : le bouton Relancer, `POST /api/v2/job/{id}/relaunch` sans corps, ou `relaunch_job` sans
+  `values`.
+* **Avec des modifications** : les mêmes appels avec de nouvelles valeurs, superposées aux valeurs de champ stockées du job :
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Comment chacune est vérifiée
+
+Le mode de validation au lancement décide si une relance est rejouée ou vérifiée de nouveau :
+
+| Relance | `off` / `log` | `enforce` |
+|---|---|---|
+| **À l'identique** | rejoue les extravars stockées du job, mots de passe compris | la vérification complète, à partir des valeurs de champ stockées |
+| **Avec des modifications** | la vérification complète, sur les valeurs stockées avec les modifications superposées | la vérification complète, de la même façon |
+
+Une exception avec `enforce` : un job lancé par une planification de niveau admin n'a pas de valeurs de champ propres ; le relancer à l'identique
+rejoue donc les extravars stockées de la planification, pour un admin ou un utilisateur disposant de l'option de rôle `allowScheduledJobs`.
+
+Une relance vérifiée (voir [Log et enforce](log-and-enforce.html)) démarre un nouveau job au nom de l'appelant.
+
+---
+
+## Champs mot de passe
+
+Les valeurs de champ stockées ne contiennent pas de mot de passe : une relance vérifiée n'en a donc pas pour un **champ mot de passe visible** :
+
+* La relance est refusée comme `unsupported`, avec les `passwordFields` qui lui manquent.
+* Lancez de nouveau le formulaire et saisissez le mot de passe.
+* Un champ mot de passe que les dépendances du formulaire **masquent** n'est pas nécessaire et ne bloque pas la relance.
+
+Avec `enforce`, cela s'applique aussi au bouton Relancer.
+
+---
+
+## Qui peut relancer
+
+Les deux types de relance exigent :
+
+* que le formulaire autorise la relance (`allowRelaunch`, true par défaut) ;
+* l'option de rôle `allowJobRelaunch` ;
+* que l'utilisateur soit **le propriétaire du job**, un admin, ou un utilisateur disposant de l'option de rôle `manageAllJobs`.
+
+Voir tous les jobs (`showAllJobLogs`) ne suffit pas pour relancer le job d'un autre utilisateur. Les approbateurs peuvent voir un job qui attend leur
+approbation, mais ne peuvent pas non plus le relancer.
diff --git a/i18n/fr/_build_forms/launch-validation/rolling-it-out.md b/i18n/fr/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..49ce895
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Déploiement
+parent: Validation au lancement
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Déploiement
+{: .no_toc }
+
+Faire passer une instance en enforce, et les limitations connues
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Déploiement
+
+`enforce` est la valeur par défaut. Sur une instance où des scripts ou d'autres systèmes lancent des formulaires via
+REST, atteignez-la par étapes, en surveillant le journal avant de refuser quoi que ce soit :
+
+1. Définissez `LAUNCH_VALIDATION=log` pour toute l'instance (avant la mise à niveau, lors d'une mise à niveau).
+2. Restez un moment dans ce mode et examinez le journal : les avertissements `would refuse` signalent des lancements
+   qui enfreignent les règles ; les avertissements `extravars differ` signalent des formulaires qui calculent quelque chose
+   différemment sur le serveur (un horodatage, des données externes). Décidez pour chaque formulaire si cela
+   compte.
+3. Passez ces formulaires en `launchValidation: enforce`. Les appelants qui envoyaient des valeurs invalides ou
+   des extravars inventées reçoivent désormais un `422` avec la raison.
+4. Quand chaque formulaire se comporte comme prévu, retirez `LAUNCH_VALIDATION` (ou définissez-la à `enforce`) pour toute l'instance.
+
+---
+
+## Limitations
+
+La validation au lancement ne couvre pas encore tout :
+
+- **Les formulaires assistant** ne peuvent pas être relancés avec des modifications, et un job d'assistant lancé avant la 7.0
+  ne peut pas être relancé avec `enforce` (il ne stockait pas les valeurs de ses étapes). Le serveur MCP
+  ne peut pas lancer de formulaires assistant.
+- **La résolution des espaces réservés** dans le navigateur utilise toujours sa propre copie du code du serveur ; dans
+  de rares cas limites (`__undefined__`, guillemets à l'intérieur d'expressions), les deux pourraient résoudre un
+  espace réservé différemment. `log` révèle de telles différences.
+- **Les expressions `runLocal`** s'exécutent dans le moteur JavaScript du navigateur côté navigateur, et dans un
+  bac à sable sur le serveur ; le même code produit le même résultat, sauf quand il dépend du
+  fuseau horaire ou de la langue du navigateur.
+
+---
+
+## Formulaires assistant
+
+Un [assistant](../forms/wizard.html) est vérifié étape par étape : le navigateur envoie les valeurs de
+chaque étape, et le serveur vérifie chaque étape que l'utilisateur soumettrait avec son propre sous-formulaire.
+
+- Une étape est omise quand elle est `optional` et que l'utilisateur l'a passée, ou quand son `when` est faux.
+- Une étape lit les étapes précédentes via `$(__parent__.<step>.<field>)`, avec leurs valeurs vérifiées.
+- Les erreurs nomment l'étape et le champ, sous la forme `<step>.<field>`.
+- Avec `enforce`, les extravars sont construites sur le serveur, chaque étape sous son `defaultModel`.
+- Les champs fichier ne sont pas pris en charge dans un assistant.
diff --git a/i18n/fr/_build_forms/launch-validation/switching-it-on.md b/i18n/fr/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..8b086df
--- /dev/null
+++ b/i18n/fr/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: L'activer
+parent: Validation au lancement
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# L'activer
+{: .no_toc }
+
+Pour toute l'instance, ou pour un seul formulaire
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La validation au lancement a deux réglages. **C'est le plus strict des deux qui s'applique.**
+
+---
+
+## Pour toute l'instance : `LAUNCH_VALIDATION`
+
+La variable d'environnement [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) s'applique à tous les formulaires :
+
+- `off` : aucune vérification côté serveur ; le job s'exécute avec les extravars envoyées par le navigateur ou l'appelant.
+- `log` : chaque lancement est vérifié ; ce qui serait refusé est écrit dans le journal comme
+  avertissement, et le lancement s'exécute comme avant.
+- `enforce` (par défaut) : un lancement invalide est refusé, et un lancement valide s'exécute avec les extravars que
+  construit le serveur.
+
+Une valeur vide ou inconnue signifie aussi `enforce`. Les changements prennent effet sans redémarrage.
+
+{: .warning }
+> **La mise à niveau change le comportement.** Une instance qui ne définit pas `LAUNCH_VALIDATION` applique enforce
+> à chaque lancement après la mise à niveau. Les scripts qui appellent `POST /api/v2/job` sans `rawFormData`,
+> ou avec des valeurs qui enfreignent les règles d'un formulaire, sont refusés avec un `422`. Définissez
+> `LAUNCH_VALIDATION=log` avant la mise à niveau pour voir ce qui serait refusé, ou `off` pour garder
+> l'ancien comportement (voir [Déploiement](rolling-it-out.html)).
+
+---
+
+## Pour un seul formulaire : `launchValidation`
+
+Un formulaire peut définir son propre niveau :
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Utilisez ce réglage sur une instance qui tourne en `off` ou en `log`, pour un formulaire dont vous savez qu'il sera
+lancé via REST : ce formulaire est en enforce, alors que le reste de l'instance ne l'est pas. Il peut aussi être défini dans le concepteur, dans les
+paramètres du formulaire.
+
+**Un formulaire peut être rendu plus strict que l'instance, jamais plus permissif.** Avec `LAUNCH_VALIDATION`
+sur `enforce`, le `launchValidation: off` d'un formulaire n'a aucun effet : un formulaire ne peut pas passer outre
+la décision d'un opérateur.
+
+Les formulaires assistant l'utilisent aussi : le lancement d'un assistant est vérifié étape par étape, chaque étape avec son propre
+sous-formulaire (voir [Formulaires assistant](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/fr/_build_forms/workflows/designer.md b/i18n/fr/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..a8c4a8b
--- /dev/null
+++ b/i18n/fr/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Modifier dans le concepteur
+parent: Workflows
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Modifier dans le concepteur
+{: .no_toc }
+
+Dessiner un workflow, et l'essayer sans rien exécuter
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La section Workflows
+
+**Concepteur > Workflows** liste les fichiers de workflow dans un explorateur de fichiers, avec les onglets YAML, Visuel et Aperçu de chaque
+section du [concepteur](../designer/).
+
+- **Le bouton `+`** de la barre d'outils crée un fichier de workflow, avec un workflow vide comme point de départ.
+- **YAML** montre le fichier tel qu'il est écrit. Les commentaires et l'ordre des clés sont aussi conservés par les autres onglets.
+- **Visuel** dessine chaque workflow du fichier sous forme de graphe, avec son nom et sa description au-dessus. Un fichier contenant deux workflows
+  les affiche tous les deux, l'un sous l'autre.
+- **Aperçu** est une exécution à blanc du workflow : voir [L'essayer](#trying-it-out).
+
+Les problèmes sont listés au-dessus du graphe, chacun avec un lien qui ouvre le YAML à sa ligne : un lien vers un nœud qui n'existe
+pas, une boucle, un playbook, un inventaire, un identifiant, un runner ou un dépôt que le concepteur ne connaît pas.
+
+---
+
+## Le graphe
+
+Le graphe se lit de gauche à droite, de **START** jusqu'aux derniers nœuds. Chaque nœud affiche son identifiant et, en dessous, ce
+qu'il exécute ; les liens sont colorés selon ce qui les déclenche, comme l'indique la légende dans le graphe : en cas de succès, en cas d'échec,
+toujours.
+
+- **Cliquez sur START** pour ajouter un premier nœud : un nœud sans parent, qui s'exécute dès que le workflow démarre.
+- **Cliquez sur un nœud** pour le modifier.
+- **Cliquez sur un lien** pour changer ce qui le déclenche, ou pour le retirer.
+
+---
+
+## Ajouter un nœud
+
+Un nouveau nœud s'ajoute avec un assistant : **Nouveau nœud en cas de succès**, **Nouveau nœud en cas d'échec** ou **Nouveau nœud toujours** sur un nœud
+existant, ou START pour un premier nœud.
+
+1. **Ce qu'il exécute** : l'identifiant du nœud, **Exécute** (le genre de nœud et, pour un nœud playbook, où il s'exécute)
+   et ce qu'il exécute : un playbook, un modèle ou un job, un workflow, le nom et le délai d'une approbation, ou un dépôt. Voir
+   [Où un nœud s'exécute](#where-a-node-runs).
+2. **Comment il s'exécute** : les réglages d'exécution : l'inventaire, les identifiants, la limite, les tags, la verbosité,
+   les modes check et diff, la condition (**S'exécute si**) et **Valeurs de** (voir [le fichier de workflow](file.html#run-settings)).
+3. **Où il va** : le nœud après lequel il s'exécute, et dans quel cas.
+
+**Créer** ajoute le nœud au YAML.
+
+---
+
+## Où un nœud s'exécute
+
+**Exécute** indique ce qu'un nœud exécute et où, dans une seule liste : **Playbook sur le RTE**, **Modèle sur AWX**, **Modèle sur
+Semaphore**, **Job sur Rundeck**, **Job sur Jenkins**, puis **Workflow**, **Approbation** et **Pull de dépôt**.
+
+| Exécute | Le champ en dessous | Runner |
+|---|---|---|
+| **Playbook sur le RTE** | **Playbook** : un playbook du concepteur | **Le RTE par défaut**, ou un runner RTE par son nom |
+| **Modèle sur AWX** (AAP et Ascender compris) | **Modèle** : le nom du modèle, saisi | les runners AWX, chacun avec sa variante |
+| **Modèle sur Semaphore** | **Modèle** : le nom du modèle, saisi | les runners Semaphore |
+| **Job sur Rundeck** ou **Job sur Jenkins** | **Job** : le nom du job, saisi | les runners Rundeck ou Jenkins |
+
+- **Playbook sur le RTE** est toujours proposé ; les autres uniquement quand l'instance a un [runner](../runners.html) de ce type.
+- **Runner** ne liste que les runners de ce type, celui par défaut étant marqué et présélectionné (ou le premier par nom).
+- Choisir un autre emplacement efface ce que le nœud exécute, pour qu'il soit choisi de nouveau.
+- Un nœud dont le concepteur ne connaît pas le runner affiche **Modèle ou job sur** ce runner.
+
+Le fichier de workflow ne change pas : un tel nœud est un nœud `job_template` avec un `runner:` (voir
+[le fichier de workflow](file.html#run-settings)).
+
+---
+
+## Modifier un nœud
+
+Cliquer sur un nœud ouvre sa boîte de dialogue, en quatre onglets :
+
+| Onglet | Ce qu'il contient |
+|---|---|
+| **Ce qu'il exécute** | L'identifiant, **Exécute**, ce qu'il exécute et, pour un nœud playbook, le runner |
+| **Comment il s'exécute** | Les réglages d'exécution ; les identifiants sont choisis dans une liste, chacun ajouté avec `+` |
+| **S'exécute après** | Les liens qui mènent au nœud, et **Tous les parents doivent converger** |
+| **Exécute ensuite** | Les liens qui en partent, avec **Lier à un nœud existant :** et **Lier à un nouveau nœud :** |
+
+**Voir en YAML** ouvre le YAML sur le nœud, et **Retirer le nœud** le retire avec ses liens. Chaque modification est écrite immédiatement dans le
+YAML ; **Enregistrer** enregistre le fichier.
+
+---
+
+## L'essayer
+
+L'onglet **Aperçu** déroule le workflow sans rien lancer, selon les règles d'AWX.
+
+Chaque nœud démarre comme un succès. Cliquez sur un nœud pour le faire échouer, et cliquez de nouveau pour le faire réussir ; le graphe montre alors
+quels nœuds s'exécuteraient, lesquels ne s'exécuteraient pas, et si le workflow échouerait. **Réinitialiser** fait de nouveau réussir chaque nœud.
diff --git a/i18n/fr/_build_forms/workflows/file.md b/i18n/fr/_build_forms/workflows/file.md
new file mode 100644
index 0000000..3ba4247
--- /dev/null
+++ b/i18n/fr/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Le fichier de workflow
+parent: Workflows
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# Le fichier de workflow
+{: .no_toc }
+
+La syntaxe des workflows, les types de nœud et les réglages d'exécution de chaque nœud
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Où se trouvent les fichiers de workflow
+
+Les fichiers de workflow sont des fichiers YAML du dossier local des workflows et de chaque dépôt utilisé pour les workflows.
+
+- **Le dossier local** est [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), par défaut `workflows` dans le
+  dossier persistant.
+- **Un dépôt** avec **Utiliser pour les workflows ?** activé est lu en entier : ses fichiers de workflow peuvent donc se trouver dans n'importe quel dossier. Le
+  concepteur les enregistre dans le dépôt, et **Push** les envoie au dépôt distant.
+
+Chaque fichier YAML qui contient `workflow_job_templates` est lu, jusqu'à six niveaux de dossiers, et un fichier peut contenir plusieurs
+workflows. Un formulaire désigne un workflow par son `name` : gardez donc des noms uniques. Quand deux workflows partagent un nom, un job qui
+l'exécute échoue et demande de renommer l'un d'eux.
+
+---
+
+## La syntaxe
+
+Un fichier de workflow s'écrit dans la syntaxe d'un export AWX, avec les nœuds sous `related.workflow_nodes` :
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+La forme de la collection `awx.awx` est lue aussi : `workflow_nodes` directement sous le workflow, et des noms écrits comme
+de simples chaînes (`inventory: staging`) plutôt que comme des maps (`inventory: {name: staging}`).
+
+### Le workflow
+
+Une entrée de workflow a quelques clés propres, à côté de ses nœuds :
+
+| Clé | Ce que c'est |
+|---|---|
+| `name` | Le nom du workflow, celui que désigne le `workflow:` d'un formulaire |
+| `description` | À quoi il sert, affiché dans le concepteur |
+| `extra_vars` | Des variables que reçoit chaque nœud ; les valeurs du formulaire l'emportent sur elles |
+| `related.workflow_nodes` | Les nœuds |
+
+### Un nœud
+
+Chaque nœud a un identifiant, ce qu'il exécute et ses liens :
+
+| Clé | Ce que c'est |
+|---|---|
+| `identifier` | L'id du nœud : lettres, chiffres, points, tirets, deux-points et tirets bas, unique dans le workflow |
+| `unified_job_template.type` | Ce que le nœud exécute : voir [les types de nœud](#node-types) |
+| `unified_job_template.name` | Le playbook, le workflow, l'approbation ou le dépôt qu'il exécute |
+| `related.success_nodes` | Les nœuds qui s'exécutent quand celui-ci réussit |
+| `related.failure_nodes` | Les nœuds qui s'exécutent quand celui-ci échoue |
+| `related.always_nodes` | Les nœuds qui s'exécutent quand celui-ci est terminé, dans un cas comme dans l'autre |
+| `all_parents_must_converge` | `true` : le nœud attend que tous les liens qui y mènent se déclenchent, pas un seul |
+
+Les liens doivent aller vers l'avant : un workflow dont les liens forment une boucle ne s'exécute pas.
+
+---
+
+## Types de nœud
+
+Un nœud exécute l'une de quatre choses, nommées comme AWX les nomme :
+
+| Type | Ce que le nœud exécute |
+|---|---|
+| `job_template` | L'un des playbooks du concepteur, comme un job à part entière sur le RTE ; ou, avec `runner:`, le template ou le job de ce runner |
+| `workflow_job_template` | Un autre workflow, comme job de workflow enfant ; les workflows s'imbriquent jusqu'à cinq niveaux |
+| `workflow_approval_template` | Une approbation : le job de workflow attend que quelqu'un l'approuve ou la rejette |
+| `project` | Un pull du dépôt qu'il nomme (la mise à jour de projet d'AWX) |
+
+Le `unified_job_template.timeout` d'un nœud d'approbation est en secondes. Quand il s'écoule sans réponse, le nœud échoue ; `0` ou l'absence
+de délai attend une réponse aussi longtemps qu'il le faut. Une approbation rejetée fait échouer le nœud, et le workflow continue le long de ses
+liens.
+
+---
+
+## Réglages d'exécution
+
+Un nœud `job_template` prend les réglages d'un nœud AWX, sur le nœud lui-même :
+
+| Clé | Ce qu'elle fait |
+|---|---|
+| `inventory` | L'inventaire sur lequel le playbook s'exécute, par son nom, comme l'`inventory:` d'un formulaire |
+| `related.credentials` | Les identifiants : chacun parvient au playbook sous son propre nom, et le premier de type *SSH* est aussi le login avec lequel ansible se connecte. Un identifiant vault ne fait qu'ouvrir les vaults |
+| `limit` | N'exécute que sur ces hôtes (`--limit`) |
+| `job_tags` | N'exécute que les tâches portant ces tags (`--tags`) |
+| `skip_tags` | Ignore les tâches portant ces tags (`--skip-tags`) |
+| `verbosity` | `0` à `5` : le nombre de `-v` |
+| `diff_mode` | `true` : affiche les changements (`--diff`) |
+| `job_type` | `check` : une exécution à blanc (`--check`) ; `run` ou rien : une exécution réelle |
+| `extra_data` | Des variables que reçoit ce nœud, en dessous des `extra_vars` du workflow et des valeurs du formulaire |
+
+Le job du nœud reçoit les valeurs du formulaire comme extra vars. Les valeurs du formulaire l'emportent sur les `extra_vars` du workflow, qui l'emportent
+sur l'`extra_data` du nœud, comme les réponses d'un survey dans AWX.
+
+---
+
+## Les clés propres à AnsibleForms
+
+Trois clés d'un nœud sont propres à AnsibleForms, et AWX les ignore : un workflow peut ainsi faire ce que fait un formulaire multistep :
+
+| Clé | Ce qu'elle fait |
+|---|---|
+| `runner` | Sur un nœud `job_template`, exécute le template ou le job de ce runner au lieu d'un playbook du concepteur : AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins. Un runner RTE y exécute le playbook du nœud. Un même workflow peut les mélanger. |
+| `if_extra_var` | Le nœud ne s'exécute que si cette extra var vaut `true`, comme l'`ifExtraVar` d'une étape multistep. Si la condition n'est pas remplie, le nœud est ignoré, et ce qui le suit s'exécute comme après un succès. Pas sur un nœud d'approbation, qui s'exécute toujours. |
+| `extra_vars_key` | Le nœud ne reçoit que cette clé des extra vars, avec l'utilisateur recopié, comme la `key` d'une étape multistep |
+
+Sur un runner de templates, `unified_job_template.name` est le template ou le job à exécuter, et les `limit`, `job_tags`, mode check
+et mode diff du nœud sont transmis comme le ferait un formulaire du type de ce runner. Une `verbosity` supérieure à `0` active le
+`verbose` du formulaire, et `skip_tags` n'est pas transmis. Seul un runner AWX (AWX, AAP ou Ascender) reçoit l'inventaire du nœud, et les
+identifiants comme ses identifiants AWX ; Semaphore, Rundeck et Jenkins reçoivent les identifiants comme les `credentials` d'un formulaire.
diff --git a/i18n/fr/_build_forms/workflows/index.md b/i18n/fr/_build_forms/workflows/index.md
new file mode 100644
index 0000000..fc7f01c
--- /dev/null
+++ b/i18n/fr/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflows
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflows
+{: .no_toc }
+
+Enchaîner des playbooks, des approbations et d'autres workflows, comme le fait AWX
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les auteurs de formulaires : ce qu'est un workflow, comment ses nœuds s'exécutent, et où en lire davantage.
+
+Un workflow est un graphe de nœuds. Chaque nœud exécute quelque chose : l'un des playbooks du concepteur, un autre workflow, une approbation,
+ou un pull de dépôt. Les liens entre les nœuds indiquent ce qui s'exécute ensuite, en cas de succès, en cas d'échec ou toujours. Un formulaire de
+[type `workflow`](../forms/workflow.html) le lance, et la page des jobs le dessine en direct pendant son exécution.
+
+Les workflows suivent la syntaxe et les règles d'AWX : un workflow exporté d'AWX se lit donc de la même façon dans AnsibleForms. Ils s'exécutent sur
+le RTE, sans AWX : un nœud playbook est un job à part entière, avec l'inventaire, les identifiants, la limite et les tags du nœud.
+
+---
+
+## Comment un workflow s'exécute
+
+Les nœuds s'exécutent selon les règles d'AWX, et les branches qui ne dépendent pas les unes des autres s'exécutent en parallèle.
+
+- **Un nœud sans parent démarre immédiatement**, au démarrage du workflow.
+- **Un lien se déclenche quand son nœud est terminé** : un lien *en cas de succès* après un succès, un lien *en cas d'échec* après un échec,
+  un lien *toujours* après l'un ou l'autre. Un nœud annulé ne déclenche aucun de ses liens.
+- **Un nœud démarre dès qu'un lien qui y mène se déclenche.** Avec **Tous les parents doivent converger** activé, il attend que tous les liens
+  qui y mènent se soient déclenchés.
+- **Un nœud qui ne peut plus démarrer est marqué *ne pas exécuter***, ainsi que les nœuds que lui seul pouvait démarrer.
+- **Le workflow échoue quand un nœud a échoué et que rien ne le prend en charge** : ce nœud n'a ni lien *en cas d'échec* ni lien *toujours*.
+  Un échec pris en charge par un lien ne fait pas échouer le workflow.
+
+Un nœud avec une condition (`if_extra_var`) non remplie est ignoré. Ce qui le suit s'exécute comme après un succès. Un nœud
+d'approbation ne prend pas de condition : il attend toujours une réponse.
+
+---
+
+## Transmettre des données entre nœuds
+
+Ce que le playbook d'un nœud rassemble avec `set_stats` parvient aux nœuds suivants comme extra vars, de la même façon qu'AWX transmet
+les artefacts d'un job. Un nœud reçoit les données de chaque parent dont le lien vers lui s'est déclenché, fusionnées dans l'ordre où les parents sont
+écrits, et transmet ce qu'il a reçu plus les données de son propre job, les siennes l'emportant sur une clé définie des deux côtés.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Un nœud suivant lit alors {% raw %}`{{ version }}` et `{{ build_id }}`{% endraw %} comme n'importe quelle autre extra var.
+
+Les extra vars d'un nœud proviennent de quatre endroits. L'un d'eux, `extra_data`, contient les variables propres au nœud : c'est le nom qu'AWX leur donne,
+définies sur le nœud dans le [fichier de workflow](file.html#run-settings). Quand deux sources définissent la même clé, l'ordre de priorité est
+celui d'AWX, de la plus faible à la plus forte :
+
+| Source | L'emporte sur |
+|---|---|
+| les variables propres au nœud (`extra_data`) | rien |
+| les données transmises avec `set_stats` | l'`extra_data` du nœud |
+| les `extra_vars` du workflow | les données transmises |
+| les valeurs du formulaire | tout |
+
+- Seules les données au niveau du playbook sont transmises : `set_stats` avec `per_host: false`, sa valeur par défaut.
+- Un nœud d'approbation, un nœud ignoré et un nœud de projet transmettent ce qu'ils ont reçu.
+- La sortie d'un nœud se termine par les clés qu'il a transmises, par leur nom seulement, car leurs valeurs peuvent être secrètes.
+- Le job du nœud conserve ses données comme artefacts (**Afficher les artefacts** sur sa page), et le job du workflow conserve les données de tous ses
+  nœuds : un workflow imbriqué les transmet donc lui aussi aux nœuds qui le suivent.
+- Un nœud qui s'exécute sur un runner AWX transmet de la même façon les artefacts de son job AWX.
+---
+
+## Dans cette section
+
+Les pages suivantes décrivent les workflows en détail :
+
+| Page | Contenu |
+|---|---|
+| [Le fichier de workflow](file.html) | La syntaxe du fichier, les types de nœud et les réglages d'exécution de chaque nœud |
+| [Modifier dans le concepteur](designer.html) | La section Workflows du concepteur : le graphe, les boîtes de dialogue des nœuds et des liens, et l'exécution à blanc |
+| [Exécuter un workflow](running.html) | Le formulaire qui le lance, la page du job, les sorties des nœuds, les approbations et l'interruption |
diff --git a/i18n/fr/_build_forms/workflows/running.md b/i18n/fr/_build_forms/workflows/running.md
new file mode 100644
index 0000000..13de3b1
--- /dev/null
+++ b/i18n/fr/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Exécuter un workflow
+parent: Workflows
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Exécuter un workflow
+{: .no_toc }
+
+Lancer un workflow depuis un formulaire, et le suivre sur la page des jobs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le formulaire
+
+Un formulaire de [type `workflow`](../forms/workflow.html) lance un workflow, désigné avec `workflow:` comme on désigne un playbook : par
+son **fichier** dans le dossier des workflows, avec ses sous-dossiers (`team/deploy-app.yml`), ou par le **nom** du workflow dans
+le fichier (`deploy-app`) :
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+Les champs du formulaire parviennent à chaque nœud comme extra vars, tout comme ses [`credentials`](../forms/workflow.html#workflow_credentials), sous les noms
+que le formulaire leur donne, comme ceux d'un formulaire multistep parviennent à ses étapes :
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+Les identifiants propres à un nœud, définis dans le fichier de workflow, parviennent à son playbook sous leur propre nom et l'emportent sur un nom utilisé des deux côtés. Dans l'onglet Visuel du concepteur pour un formulaire, **Workflow** est une liste des
+fichiers de workflow du concepteur.
+
+Un nom de fichier seul est trouvé aussi dans un sous-dossier, quand un seul fichier porte ce nom. Deux workflows du même nom bloquent un formulaire qui le
+désigne par son nom, et le concepteur vous avertit quand vous enregistrez le second : renommez-en un, ou désignez son fichier. Un workflow introuvable
+termine le job en échec, avec la raison dans sa sortie.
+
+---
+
+## Le job
+
+Un job de workflow s'exécute sur le serveur AnsibleForms, et chaque nœud playbook s'exécute comme un job à part entière, enfant du job de
+workflow comme le sont les étapes d'un formulaire multistep : un playbook du concepteur sur le RTE ou, pour un nœud avec un `runner:`, le
+template ou le job de ce runner sur AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins (voir [Où un nœud s'exécute](designer.html#where-a-node-runs)).
+
+La page du job dessine le workflow en direct : chaque nœud coloré selon son statut, les liens qui se sont déclenchés, et les nœuds qui ne
+s'exécuteront pas. Les informations en haut nomment le workflow à la place d'un playbook.
+
+- **Cliquez sur un nœud** terminé pour ouvrir sa sortie dans une boîte de dialogue.
+- **La sortie** contient la sortie de chaque nœud sous une bannière `WORKFLOW NODE [identifier] (status)`, dans l'ordre où les nœuds
+  se sont terminés.
+- **Afficher les variables supplémentaires** et **Afficher les artefacts**, sur l'en-tête de chaque nœud dans la sortie et dans la boîte de dialogue ouverte depuis le graphe,
+  montrent les extravars et les artefacts propres à ce nœud (`{}` quand il n'en a pas), en JSON ou en YAML, avec un bouton Copier.
+
+Les extravars d'un nœud contiennent ce que les nœuds précédents lui ont transmis, et ses artefacts ce que son playbook a rassemblé avec
+`set_stats`. Les deux boutons suivent les [options de rôle](../config/roles.html#role-options) `showExtravars` et
+`showArtifacts`. Les mêmes données sont disponibles via `GET /api/v2/job/{id}/node/{nodeId}`, pour quiconque peut voir le job.
+
+Le job échoue quand un nœud a échoué et que rien ne l'a pris en charge, selon la règle d'AWX ; sinon il réussit.
+
+---
+
+## Approbations
+
+Un nœud d'approbation retient le job de workflow jusqu'à ce que quelqu'un y réponde.
+
+Quand le workflow atteint un nœud d'approbation, le statut du job passe à **En attente d'approbation** : il apparaît dans la cloche et sur la
+page du job, comme le [point d'approbation](../forms/approval.html) d'un formulaire. Le nom du nœud est le titre de l'approbation et sa description
+le message ; le reste provient de l'`approval` du formulaire :
+
+- ses `roles` décident qui peut l'approuver ou la rejeter, et `allowSelf` si celui qui a lancé le job peut aussi l'approuver ;
+- ses `notifications` et ses `channels` reçoivent la demande.
+
+Un formulaire workflow sans `approval` retient tout de même le job à un nœud d'approbation, mais seul un admin peut alors l'approuver.
+
+- **Approuvée**, le nœud réussit et le workflow continue le long de ses liens *en cas de succès*.
+- **Rejetée**, le nœud échoue et le workflow continue le long de ses liens *en cas d'échec*.
+- **Expirée**, après le délai du nœud sans réponse, le nœud échoue aussi.
+
+---
+
+## Arrêt
+
+**Arrêter** sur un job de workflow en cours l'arrête : les jobs des nœuds en cours sont interrompus, plus rien ne démarre, et une approbation qu'il
+attend est annulée. Un job de workflow qui attend une approbation peut lui aussi être arrêté.
diff --git a/i18n/fr/_configure/announcements.md b/i18n/fr/_configure/announcements.md
new file mode 100644
index 0000000..46f7339
--- /dev/null
+++ b/i18n/fr/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Annonces
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Annonces
+{: .no_toc }
+
+Des messages sous l'en-tête pour tous, comme une fenêtre de maintenance, chacun de son début à sa fin
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : informez tous les utilisateurs d'une fenêtre de maintenance ou d'un incident, dans **Paramètres > Apparence > Annonces**.
+
+La page nécessite l'option de rôle `showSettings` ou `showAppearanceSettings`. Depuis la 7.3.0, c'est une seule liste, et chaque annonce
+a sa propre page et son interrupteur Activée.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Général](announcements/general.html) | L'interrupteur Activée de chaque annonce, qui a remplacé l'interrupteur commun à toutes |
+| [Liste](announcements/list.html) | Les annonces qui ne sont pas terminées, leurs colonnes et la page d'une annonce |
+| [Ajouter une annonce](announcements/adding-one.html) | L'assistant en deux étapes : le message, puis quand il s'affiche |
+
+
+---
+
+## Où elles s'affichent
+
+Les annonces s'affichent sous forme de ligne sous l'en-tête de chaque page, pour chaque utilisateur connecté, chacune dans la couleur de son type.
+
+Plusieurs annonces activées peuvent s'afficher en même temps, la plus récente en premier. La page de connexion et un formulaire intégré dans un autre site n'en affichent aucune.
+
+Chacune a un bouton de fermeture. Une annonce fermée reste fermée dans cet onglet du navigateur jusqu'à la fermeture de l'onglet, ou
+jusqu'à ce que son message ou sa date de fin change. Une annonce enregistrée atteint tous les navigateurs ouverts en même temps ; celle qui
+atteint sa date de début ou de fin s'y affiche ou s'y masque en moins d'une minute.
diff --git a/i18n/fr/_configure/announcements/adding-one.md b/i18n/fr/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..24fce07
--- /dev/null
+++ b/i18n/fr/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Ajouter une annonce
+parent: Annonces
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Ajouter une annonce
+{: .no_toc }
+
+L'assistant en deux étapes : le message, puis quand il s'affiche
+{: .fs-6 .fw-300 }
+
+**Ajouter une annonce** ouvre un assistant en deux étapes. **Message** demande ce qu'elle dit :
+
+| Champ | Signification |
+|---|---|
+| **Message** | Le texte, 500 caractères au plus. Obligatoire. |
+| **Type** | Sa couleur et son icône : bleu pour Info (par défaut), ambre pour Avertissement, rouge pour Danger |
+
+**Quand** demande quand elle s'affiche :
+
+| Champ | Signification |
+|---|---|
+| **Date de début** | Elle s'affiche à partir de ce moment. Laissez vide pour l'afficher tout de suite. |
+| **Date de fin** | À ce moment, elle est masquée et supprimée. Laissez vide pour la garder jusqu'à ce que vous la supprimiez. |
+
+La date de fin doit être postérieure à la date de début, et se situer dans le futur.
diff --git a/i18n/fr/_configure/announcements/general.md b/i18n/fr/_configure/announcements/general.md
new file mode 100644
index 0000000..24b6de0
--- /dev/null
+++ b/i18n/fr/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Général
+parent: Annonces
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Général
+{: .no_toc }
+
+L'interrupteur Activée de chaque annonce, qui a remplacé l'interrupteur commun à toutes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Activer ou désactiver une annonce
+
+Depuis la 7.3.0, chaque annonce s'active ou se désactive séparément, avec son interrupteur **Activée**.
+
+Une nouvelle annonce est activée. **Désactiver** dans le menu de sa ligne, ou l'interrupteur **Activée** sur sa page, la masque sous l'en-tête et la garde
+dans la liste, et **Activer** l'affiche à nouveau de sa date de début à sa date de fin. L'interrupteur est enregistré immédiatement.
+
+---
+
+## L'interrupteur Afficher les annonces de la 7.2
+
+Jusqu'à la 7.2, un onglet **Général** avait un interrupteur **Afficher les annonces** qui les activait ou désactivait toutes à la fois.
+
+Depuis la 7.3.0, cet interrupteur a disparu. S'il était désactivé, la mise à jour désactive toutes les annonces, si bien qu'aucune ne commence à s'afficher : réactivez celles que vous voulez.
diff --git a/i18n/fr/_configure/announcements/list.md b/i18n/fr/_configure/announcements/list.md
new file mode 100644
index 0000000..f0a4e24
--- /dev/null
+++ b/i18n/fr/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Liste
+parent: Annonces
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Liste
+{: .no_toc }
+
+Les annonces qui ne sont pas terminées, leurs colonnes et la page d'une annonce
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La liste
+
+**Paramètres > Apparence > Annonces** liste toutes les annonces qui ne sont pas terminées, avec ces colonnes :
+
+| Colonne | Signification |
+|---|---|
+| **Activée** | Si elle s'affiche sous l'en-tête de son début à sa fin (depuis la 7.3.0) |
+| **Message** | Le texte sous l'en-tête |
+| **Type** | Info, Avertissement ou Danger |
+| **Date de début** | Quand elle commence à s'afficher ; `–` quand elle s'affiche tout de suite |
+| **Date de fin** | Quand elle se termine ; `–` quand elle s'affiche jusqu'à sa suppression |
+| **Créée par** | Qui l'a ajoutée |
+
+Un clic sur une ligne, ou **Modifier** dans le menu de sa ligne, ouvre la page de l'annonce. Le menu propose aussi **Activer** ou **Désactiver**, et **Supprimer**.
+
+Une fois sa date de fin passée, une annonce est supprimée : la liste ne garde que celles à venir et celles qui s'affichent.
+
+---
+
+## La page d'une annonce
+
+Depuis la 7.3.0, chaque annonce s'ouvre sur sa propre page, à `/settings/announcements/<id>`, avec un seul onglet, **Détails**.
+
+Elle contient le message, le type, les dates de début et de fin et l'interrupteur **Activée**, qui est enregistré immédiatement ; les autres champs sont enregistrés
+avec **Enregistrer**, et **Supprimer** retire l'annonce. Le titre de la page la nomme par les premiers caractères de son message.
diff --git a/i18n/fr/_configure/appearance.md b/i18n/fr/_configure/appearance.md
new file mode 100644
index 0000000..12b5571
--- /dev/null
+++ b/i18n/fr/_configure/appearance.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Apparence
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Apparence
+{: .no_toc }
+
+Les valeurs par défaut, le nom, le logo, l'icône du navigateur, les liens de l'en-tête et les étiquettes à côté du logo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : donnez à l'instance votre image, dans **Paramètres > Apparence**, avec l'option de rôle `showSettings`.
+L'option de rôle `showAppearanceSettings` seule ouvre aussi ces pages, annonces comprises, sans le reste des paramètres.
+
+Les pages de ce groupe sont **Valeurs par défaut**, **Nom**, **Logo**, **Icône**, **Liens**, **Étiquettes** et **Annonces** ;
+les annonces ont leur propre page, [Annonces](announcements.html). Une valeur par défaut, un nom, un lien ou une étiquette enregistrés
+s'affichent immédiatement dans tous les navigateurs ouverts.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Valeurs par défaut](appearance/defaults.html) | Le thème, la langue, le fuseau horaire et le format de date pour les utilisateurs qui n'en ont choisi aucun |
+| [Nom](appearance/name.html) | Le nom de l'application dans l'onglet du navigateur et sur la page de connexion |
+| [Logo](appearance/logo.html) | Votre propre logo dans l'en-tête |
+| [Icône](appearance/icon.html) | Votre propre icône dans l'onglet du navigateur et dans les favoris |
+| [Liens](appearance/links.html) | Les liens de l'en-tête, intégrés et les vôtres |
+| [Étiquettes](appearance/labels.html) | Des étiquettes à côté du logo qui indiquent de quelle instance il s'agit ; une seule étiquette Environnement jusqu'à la 7.2 |
+
diff --git a/i18n/fr/_configure/appearance/defaults.md b/i18n/fr/_configure/appearance/defaults.md
new file mode 100644
index 0000000..e9d1875
--- /dev/null
+++ b/i18n/fr/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Valeurs par défaut
+parent: Apparence
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Valeurs par défaut
+{: .no_toc }
+
+Le thème, la langue, le fuseau horaire et le format de date pour les utilisateurs qui n'en ont choisi aucun
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les valeurs par défaut
+
+**Valeurs par défaut** définit l'apparence de l'application pour un utilisateur qui n'a pas fait son propre choix dans ses
+[préférences](../profile/preferences.html) ; le choix propre d'un utilisateur l'emporte toujours :
+
+| Champ | Choix | Sans choix |
+|---|---|---|
+| **Thème par défaut** | Suivre le navigateur, Clair, Sombre ou Couleur, avec l'une des 12 couleurs pour Couleur | Suivre le navigateur (Clair jusqu'à la 7.2) |
+| **Langue par défaut** | Les langues de l'application, conservée dans [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Anglais |
+| **Vue des formulaires par défaut** | Tuiles ou Liste, pour la page des formulaires | Tuiles |
+| **Fuseau horaire par défaut** | UTC, le navigateur de chaque utilisateur, ou n'importe quel fuseau par son nom | UTC |
+| **Format de date par défaut** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY`, affiché avec la date du jour | `YYYY-MM-DD` |
+
+La langue est une variable d'environnement et s'applique sans redémarrage. Avec
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) à `0`, la page l'affiche en lecture seule.
+
+Depuis la 7.3.0, la page est répartie dans les deux onglets des préférences du profil, **Apparence** (thème, langue et vue des formulaires) et **Date et
+heure** (fuseau horaire et format de date, avec un aperçu de l'heure actuelle), et sa zone de recherche liste les résultats sous le nom de chaque onglet.
+
+---
+
+## Suivre le navigateur
+
+Depuis la 7.3.0, **Suivre le navigateur** montre à chaque utilisateur le thème clair ou sombre que demande son navigateur, et change avec lui.
+
+C'est la valeur par défaut quand aucun thème par défaut n'est choisi, si bien qu'une nouvelle installation suit le navigateur. Survoler l'une des couleurs de
+**Couleur** donne un aperçu de l'application dans cette couleur ; le thème que vous aviez revient quand le pointeur s'éloigne, et rien n'est conservé avant **Enregistrer**.
diff --git a/i18n/fr/_configure/appearance/icon.md b/i18n/fr/_configure/appearance/icon.md
new file mode 100644
index 0000000..f8db60f
--- /dev/null
+++ b/i18n/fr/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Icône
+parent: Apparence
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Icône
+{: .no_toc }
+
+Votre propre icône dans l'onglet du navigateur et dans les favoris
+{: .fs-6 .fw-300 }
+
+**Icône** remplace l'icône d'AnsibleForms dans l'onglet du navigateur et dans les favoris :
+
+| Règle | Valeur |
+|---|---|
+| Types | PNG, ICO, SVG, WEBP, GIF et JPEG |
+| Taille maximale du fichier | 256 Ko |
+| Meilleur résultat | Une image carrée d'au moins 64 × 64 px, ou un SVG |
+
+Choisissez un fichier sous **Nouvelle icône** et cliquez sur **Téléverser** ; **Supprimer l'icône personnalisée** rétablit l'icône par défaut.
diff --git a/i18n/fr/_configure/appearance/labels.md b/i18n/fr/_configure/appearance/labels.md
new file mode 100644
index 0000000..bddeea7
--- /dev/null
+++ b/i18n/fr/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Étiquettes
+parent: Apparence
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Étiquettes
+{: .no_toc }
+
+Des étiquettes à côté du logo qui indiquent de quelle instance il s'agit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La liste
+
+Depuis la 7.3.0, **Paramètres > Apparence > Étiquettes** contient plusieurs étiquettes à côté du logo de l'en-tête, comme PRODUCTION et EU :
+
+| Colonne | Signification |
+|---|---|
+| **Activée** | Si l'étiquette s'affiche à côté du logo et sur la page de connexion |
+| **Étiquette** | Son texte, affiché sous la forme de la pastille colorée que montre l'en-tête |
+
+Les lignes suivent l'ordre de l'en-tête. Un clic sur une ligne, ou **Modifier** dans le menu de sa ligne, ouvre la page de l'étiquette ; le menu de la ligne propose aussi
+**Activer** ou **Désactiver**, selon le cas, **Monter** et **Descendre** pour changer l'ordre, et **Supprimer**.
+
+L'en-tête et la page de connexion affichent les étiquettes activées dans leur ordre. Au-delà de trois, un **+N** gris regroupe les autres dans son infobulle,
+et un téléphone affiche la première étiquette et le **+N**. Une étiquette enregistrée s'affiche immédiatement dans tous les navigateurs ouverts.
+
+---
+
+## Ajouter une étiquette
+
+**Ajouter une étiquette** ouvre une boîte de dialogue avec les deux champs de l'étiquette, tous deux obligatoires :
+
+| Champ | Signification |
+|---|---|
+| **Étiquette** | Le texte de l'étiquette, comme PRODUCTION |
+| **Couleur** | Bleu, vert, ambre, orange, rouge ou gris, sous forme de pastilles rondes ; rouge au départ |
+
+Un aperçu montre l'en-tête avec toutes les étiquettes activées et la nouvelle au fil de la saisie. Une nouvelle étiquette est activée et vient après les
+autres. Sa page a un seul onglet, **Détails**, avec les mêmes champs, l'interrupteur **Activée**, qui est enregistré immédiatement, et l'aperçu.
+
+---
+
+## L'étiquette d'environnement de la 7.2
+
+Jusqu'à la 7.2, **Paramètres > Apparence > Environnement** définissait une seule étiquette à côté du logo.
+
+Avec une seule étiquette, PRODUCTION EU et PRODUCTION US s'affichent toutes deux PRODUCTION quand plusieurs instances sont ouvertes côte à côte. Depuis la 7.3.0,
+la mise à jour fait de cette étiquette la première de la liste, avec son texte, sa couleur et le fait qu'elle s'affichait ou non, et l'ancienne adresse
+**Environnement** ouvre la liste.
+
+---
+
+## Les étiquettes dans le seed de configuration
+
+Depuis la 7.3.0, le [seed de configuration](../seed/) déclare les étiquettes dans sa section `labels`, chacune avec son texte et, en option, sa couleur :
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` vaut `blue`, `green`, `amber`, `orange`, `red` ou `grey`, et `position` les ordonne, la plus basse en premier. Une étiquette déclarée
+dans le seed est en lecture seule sur sa page, comme tout [objet géré](../seed/managed-objects.html).
diff --git a/i18n/fr/_configure/appearance/links.md b/i18n/fr/_configure/appearance/links.md
new file mode 100644
index 0000000..90d7968
--- /dev/null
+++ b/i18n/fr/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Liens
+parent: Apparence
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Liens
+{: .no_toc }
+
+Les liens de l'en-tête, intégrés et les vôtres
+{: .fs-6 .fw-300 }
+
+**Liens** définit les liens de l'en-tête, pour chaque utilisateur connecté, dans deux onglets.
+
+**Intégrés** contient l'interrupteur **Designer**, conservé dans [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) et appliqué
+sans redémarrage. Désactivé, le designer disparaît pour tout le monde : son lien, sa page et son API.
+
+**Personnalisés** contient vos propres liens, comme un wiki, un runbook ou un portail de support. **Ajouter un lien** ajoute une ligne avec ces champs :
+
+| Champ | Signification |
+|---|---|
+| **Icône** | L'icône avant le libellé, choisie dans une liste |
+| **Libellé** | Le texte du lien |
+| **Adresse** | Un site (`https://…`) ou une page de l'application (`/forms/all`) |
+| **Nouvel onglet** | Ouvre le lien dans un nouvel onglet du navigateur |
+
+Les boutons d'une ligne la déplacent : **→** place le lien dans le lien du dessus, qui s'ouvre alors comme un menu dans l'en-tête,
+**←** le ressort dans l'en-tête, et les flèches haut et bas le déplacent (un menu avec les liens qu'il contient).
+Un menu n'a pas besoin d'adresse propre.
+
+L'en-tête contient au plus 5 de vos liens après les liens intégrés, et au plus 10 dans chaque menu.
diff --git a/i18n/fr/_configure/appearance/logo.md b/i18n/fr/_configure/appearance/logo.md
new file mode 100644
index 0000000..493ed35
--- /dev/null
+++ b/i18n/fr/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logo
+parent: Apparence
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logo
+{: .no_toc }
+
+Votre propre logo dans l'en-tête
+{: .fs-6 .fw-300 }
+
+**Logo** remplace le logo d'AnsibleForms dans l'en-tête par votre propre image, affichée dans tous les thèmes :
+
+| Règle | Valeur |
+|---|---|
+| Types | PNG, JPEG, WEBP, GIF et SVG |
+| Taille maximale du fichier | 900 Ko |
+| Taille dans l'en-tête | Au plus 200 × 33 px, proportions conservées |
+
+Choisissez un fichier sous **Nouveau logo** pour l'apercevoir, puis cliquez sur **Télécharger**. **Logo actuel** montre le logo utilisé et la taille
+à laquelle l'en-tête l'affiche. **Supprimer le logo personnalisé** rétablit le logo par défaut, qui suit le thème.
diff --git a/i18n/fr/_configure/appearance/name.md b/i18n/fr/_configure/appearance/name.md
new file mode 100644
index 0000000..2538865
--- /dev/null
+++ b/i18n/fr/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Nom
+parent: Apparence
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Nom
+{: .no_toc }
+
+Le nom de l'application dans l'onglet du navigateur et sur la page de connexion
+{: .fs-6 .fw-300 }
+
+**Nom** contient le **Nom de l'application**, affiché dans l'onglet du navigateur et sur la page de connexion. Vide, l'onglet du navigateur affiche
+`AnsibleForms` et la page de connexion n'affiche aucun nom.
diff --git a/i18n/fr/_configure/authentication/entra-id.md b/i18n/fr/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..41983ab
--- /dev/null
+++ b/i18n/fr/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Authentification
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Authentification unique avec Microsoft Entra ID (Azure AD), avec des rôles issus des groupes Entra ID de l'utilisateur
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fonctionnement
+
+Avec un fournisseur Entra ID activé, la page de connexion affiche un bouton Entra ID sous **Se connecter**. Une connexion se déroule alors ainsi :
+
+1. Le bouton envoie le navigateur vers `/api/v2/auth/entraid`, qui le redirige vers Microsoft.
+2. L'utilisateur se connecte chez Microsoft, qui le redirige vers l'**URL de redirection** avec un code d'autorisation. Le serveur
+   échange ce code auprès de Microsoft contre l'ID token et un access token pour Microsoft Graph.
+3. Le serveur lit les groupes de l'utilisateur depuis Microsoft Graph (`/v1.0/me/transitiveMemberOf`), si bien que les groupes imbriqués comptent aussi.
+4. Les groupes sont filtrés avec le **Filtre de groupe** sur leur nom d'affichage, et chaque groupe conservé est stocké deux fois,
+   comme `azuread/<object id>` et comme `azuread/<display name>`.
+
+Le nom d'utilisateur est le claim `upn` du token, par ex. `jdoe@example.com`, ou le claim `preferred_username` quand le token
+n'a pas de `upn` ; pour un compte professionnel, les deux contiennent la même valeur.
+
+---
+
+## Inscrire l'application
+
+AnsibleForms a besoin d'une inscription d'application dans le Entra admin center, dans **App registrations > New registration** :
+
+1. Donnez-lui un nom, choisissez **Accounts in this organizational directory only** comme types de comptes pris en charge, et ajoutez un
+   URI de redirection de type **Web** : `https://af.example.com/api/v2/auth/entraid/callback`.
+2. Dans **Certificates & secrets**, créez un secret client et copiez sa valeur ; elle n'est affichée qu'une seule fois.
+3. Dans **API permissions**, ajoutez les permissions Microsoft Graph **déléguées** `User.Read` et `GroupMember.Read.All`,
+   et accordez-leur le consentement administrateur.
+4. Sur la page **Overview**, notez l'**Application (client) ID** et le **Directory (tenant) ID**.
+
+L'URI de redirection est l'adresse à laquelle les utilisateurs accèdent à AnsibleForms, suivie de `/api/v2/auth/entraid/callback`.
+Avec [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms`, il devient
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Il doit correspondre exactement à l'**URI de redirection** de l'identifiant
+du fournisseur.
+
+Jusqu'à la 7.2.0, le chemin était `/api/v2/auth/azureadoauth2/callback`. Il fonctionne toujours depuis la 7.3.0, si bien qu'une inscription existante
+n'a pas besoin d'être modifiée ; un identifiant avec une **URI de redirection** vide utilise le nouveau chemin, ajoutez-le donc alors à l'inscription.
+
+AnsibleForms lit les groupes depuis Graph et n'utilise pas de claim de groupes dans le token, donc aucun claim de groupe n'a besoin
+d'être configuré sur l'inscription.
+
+---
+
+## Ajouter le fournisseur
+
+Ajoutez le fournisseur dans **Accès > SSO** : un assistant demande ses champs en quatre étapes, avec **Microsoft Entra ID** à l'étape **Type** :
+
+| Étape | Champ | Signification |
+|---|---|---|
+| Détails | Nom, Description | Un nom unique pour le fournisseur, et une description facultative |
+| Type | Fournisseur | **Microsoft Entra ID** ; défini à la création, il ne change plus |
+| Identifiants | Identifiant | Un identifiant **Microsoft Entra ID** de [Connexions > Identifiants](../credentials.html), voir plus bas |
+| Groupes | Filtre de groupe | Expression régulière ; seuls les groupes dont le nom d'affichage correspond sont conservés. Vide, tous les groupes sont conservés |
+
+L'identifiant contient l'inscription d'application, donc seul un admin peut l'ajouter ou le modifier :
+
+| Champ | Signification |
+|---|---|
+| ID du tenant | Obligatoire. Le Directory (tenant) ID, un GUID, ou l'un des domaines du tenant. Seuls les utilisateurs de ce tenant peuvent se connecter |
+| ID client | L'Application (client) ID |
+| Secret client | La valeur du secret client, stockée chiffrée ou lue depuis un [coffre de secrets](../secret-stores/) |
+| URI de redirection | Telle qu'inscrite, par ex. `https://af.example.com/api/v2/auth/entraid/callback`. Vide : l'URL de l'application et le chemin de callback |
+
+Un identifiant avec un ID de tenant vide est refusé à l'enregistrement. Les endpoints multi-tenant `common`, `organizations`
+et `consumers` sont refusés à l'enregistrement du fournisseur qui référence l'identifiant, car ils laisseraient se connecter les utilisateurs de n'importe quel
+tenant Microsoft. À la connexion, le serveur vérifie aussi que le token provient du tenant configuré. Un fournisseur
+enregistré auparavant sans ID de tenant ne connecte personne : tant que l'ID de tenant n'est pas renseigné, le serveur journalise
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Jusqu'à la 7.2.0, le tenant, l'ID client, le secret et l'URL de redirection étaient des champs du fournisseur. La mise à jour vers la 7.3.0 les déplace dans un
+identifiant nommé `<provider>-sso`, voir [Adresses dans les identifiants](../credentials/types.html#addresses-in-credentials).
+Choisissez un identifiant pour chaque nouveau fournisseur : le serveur accepte toujours un fournisseur d'avant la 7.3.0 avec son propre ID client et son propre secret,
+qui se connecte avec eux jusqu'à ce qu'un identifiant soit choisi.
+
+Un seul fournisseur Entra ID est activé à la fois, celui avec lequel le bouton Entra ID connecte. **Activer** dans le menu de ligne d'un autre,
+ou son interrupteur **Activé**, désactive les autres du même type ; la colonne **Activé** de la liste montre lequel est utilisé. Un fournisseur
+peut aussi passer la page de connexion, voir [Basculer l'authentification unique](./#switching-single-sign-on). L'enregistrement l'applique immédiatement, sans redémarrage.
+
+---
+
+## Correspondance avec les rôles
+
+Dans config.yaml, un groupe Entra ID est `entraid/<object id>` ou `entraid/<display name>`, et un utilisateur est `entraid/<upn>`.
+L'object id est unique dans le tenant, c'est donc le choix le plus sûr ; un nom d'affichage est plus lisible :
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Jusqu'à la 7.2.0, le préfixe était `azuread/`. Dans un rôle, il correspond toujours aux mêmes membres depuis la 7.3.0 et sera supprimé dans la 8.0 ; l'éditeur
+de rôles écrit `entraid/`. Seuls les rôles acceptent `entraid/` : les groupes de l'utilisateur sont stockés comme `azuread/<object id>` et
+`azuread/<display name>`, et la page de profil et l'extravar `ansibleforms_user` les affichent ainsi. Un **Filtre de groupe** comme `^AF-` ne garde que les groupes qu'utilisent vos rôles ; voir [Rôles](../config/roles.html). Depuis la 7.1.0,
+le jeton de connexion ne transporte plus les groupes, sa taille n'augmente donc plus avec eux. Le filtre reste utile pour
+les utilisateurs membres de nombreux groupes : moins de groupes sont comparés aux rôles à chaque connexion, et la
+[fiche d'annuaire](../users-and-groups/directory.html) de l'utilisateur ne liste que les groupes qui comptent. Avant la 7.1.0,
+un utilisateur membre d'une centaine de groupes ou plus en a besoin pour voir le moindre formulaire, voir
+[Formulaires et jobs vides après une authentification unique](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Endpoint Microsoft Graph
+
+Le serveur connecte les utilisateurs sur `https://login.microsoftonline.com` et appelle Microsoft Graph sur `https://graph.microsoft.com` par défaut :
+
+| Variable | Ce qu'elle change |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | L'autorité de connexion, pour un cloud national comme `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | L'endpoint Graph depuis lequel les groupes sont lus, comme `https://graph.microsoft.us` |
+
+Les deux prennent une URI de base sans barre oblique finale, et sont nouvelles dans la 7.3.0. `AZURE_AUTHORITY_URI` et `AZURE_GRAPH_URI` sont toujours lues
+lorsqu'elles ne sont pas définies, avec un avertissement dans le journal, et seront supprimées dans la 8.0. Le serveur doit pouvoir joindre Graph : une connexion échoue quand les groupes ne peuvent pas être lus.
+
+---
+
+## Limites
+
+Les utilisateurs Entra ID se connectent chez Microsoft, donc quelques points fonctionnent différemment des comptes locaux et LDAP :
+
+- Ils n'ont pas de mot de passe dans AnsibleForms, ils ne peuvent donc pas le changer ici ; un [jeton d'API](../profile/api-token.html) est créé à partir de leur session.
+- Les noms d'affichage ne sont pas uniques dans Entra ID : deux groupes portant le même nom correspondent au même rôle. Nommez le groupe par son
+  object id dans le rôle, `entraid/<object id>`, pour ne correspondre qu'à ce groupe.
diff --git a/i18n/fr/_configure/authentication/index.md b/i18n/fr/_configure/authentication/index.md
new file mode 100644
index 0000000..3f5aa09
--- /dev/null
+++ b/i18n/fr/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Authentification
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Authentification
+{: .no_toc }
+
+Choisissez comment les utilisateurs se connectent, et comment leur compte et leurs groupes mènent aux rôles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Méthodes de connexion
+
+AnsibleForms prend en charge quatre méthodes de connexion, et plusieurs peuvent être actives en même temps :
+
+| Méthode | Quand l'utiliser | Page |
+|---|---|---|
+| Comptes locaux | L'admin intégré, les comptes de service, les petites équipes, ou une solution de repli quand l'annuaire est indisponible. | [Comptes locaux](local.html) |
+| LDAP | Les utilisateurs et les groupes se trouvent dans Active Directory, OpenLDAP ou un autre annuaire LDAP. | [LDAP](ldap.html) |
+| Entra ID | Les utilisateurs se connectent avec leur compte Microsoft 365 / Entra ID (authentification unique). | [Entra ID](entra-id.html) |
+| OIDC | Authentification unique via un autre fournisseur OpenID Connect, comme Keycloak. | [OIDC](oidc.html) |
+
+Les comptes locaux et LDAP se configurent dans **Accès > Utilisateurs**, **Groupes** et **LDAP** ; Entra ID et OIDC dans
+**Accès > SSO**.
+
+---
+
+## Comment une connexion choisit la méthode
+
+La page de connexion a un formulaire nom d'utilisateur et mot de passe, plus un bouton par fournisseur d'authentification unique activé :
+
+- **Le nom d'utilisateur et le mot de passe** sont d'abord vérifiés auprès des utilisateurs locaux. L'annuaire n'est essayé que lorsqu'aucun utilisateur local ne porte ce nom et que LDAP
+  est activé. Un utilisateur local avec un mauvais mot de passe est refusé sans interroger LDAP.
+- **Les boutons Entra ID et OpenID** apparaissent sous **Se connecter** quand un tel fournisseur est activé. Ils envoient le navigateur vers
+  le fournisseur puis le ramènent ; aucun mot de passe n'atteint AnsibleForms.
+
+Un seul fournisseur Entra ID et un seul fournisseur OIDC sont activés à la fois : en activer un désactive les autres du même type.
+Une connexion par nom d'utilisateur et mot de passe qui échoue affiche toujours le même message générique ; la raison se trouve dans le journal du serveur et le journal d'audit.
+
+---
+
+## Basculer l'authentification unique
+
+Depuis la 7.3.0, chaque fournisseur dans **Accès > SSO** a deux interrupteurs propres, qui s'appliquent sans redémarrage :
+
+| Interrupteur | Effet |
+|---|---|
+| **Activé** | Affiche le bouton du fournisseur sur la page de connexion et accepte sa connexion. L'activer désactive les autres fournisseurs du même type. |
+| **Passer la page de connexion** | Les utilisateurs vont directement vers ce fournisseur, sans la page de connexion, tant que le fournisseur est activé. L'activer pour un fournisseur le désactive pour les autres ; il est grisé sur un fournisseur désactivé. |
+
+Le formulaire nom d'utilisateur et mot de passe reste accessible à `/login?local`, pour l'admin local ou quand le fournisseur est en panne,
+et il s'affiche après la déconnexion et quand une connexion par authentification unique revient avec une erreur.
+
+Les variables `ENABLE_SSO` et `SSO_AUTO_LOGIN` sont supprimées dans la 7.3.0. Le premier démarrage de la 7.3.0 les lit une fois, et
+journalise un avertissement à chaque démarrage tant qu'elles restent définies : retirez-les donc de l'environnement après la mise à jour :
+
+| Variable avant la 7.3.0 | Ce que fait la mise à jour |
+|---|---|
+| `ENABLE_SSO=0` | Désactive tous les fournisseurs : ils restent configurés, sans bouton sur la page de connexion |
+| `SSO_AUTO_LOGIN=1` | Active **Passer la page de connexion** pour le fournisseur activé, quand exactement un est activé et que `ENABLE_SSO` ne vaut pas `0` |
+
+---
+
+## De l'utilisateur aux rôles
+
+Chaque connexion produit un utilisateur avec un **type** (`local`, `ldap`, `azuread` ou `oidc`), un nom d'utilisateur et une liste de groupes.
+Chaque groupe reçoit le préfixe de son type, si bien qu'un groupe Entra ID est stocké et affiché comme `azuread/...` :
+
+| Méthode de connexion | Nom d'utilisateur | Groupes |
+|---|---|---|
+| Local | le nom d'utilisateur local | `local/<group>`, un pour chaque groupe local de l'utilisateur |
+| LDAP, annuaire `main` | la valeur de l'attribut de nom d'utilisateur | `ldap/<cn>`, le CN de chaque groupe que renvoie l'annuaire |
+| LDAP, un autre annuaire | `<directory>/<username>` | `ldap/<directory>/<cn>`, voir [Plusieurs annuaires](ldap.html#several-directories) |
+| Entra ID | le claim `upn`, ou `preferred_username` quand le token n'a pas de `upn` | `azuread/<object id>` et `azuread/<display name>` de chaque groupe, lus depuis Microsoft Graph |
+| OIDC | le claim `preferred_username` | `oidc/<name>`, depuis le claim `groups` de l'ID token |
+
+Les [rôles](../config/roles.html) de config.yaml font ensuite correspondre ces valeurs : un rôle s'applique quand l'un de ses `groups` est l'un
+des groupes de l'utilisateur, ou quand ses `users` contiennent `<type>/<username>`. Chaque utilisateur reçoit aussi le rôle `default`. Depuis la 7.3.0, un
+rôle nomme un membre Entra ID `entraid/<group>` ou `entraid/<upn>`, ce qui correspond à la valeur `azuread/` stockée ; `azuread/`
+dans un rôle fonctionne toujours et sera supprimé dans la 8.0. Le profil et les extravars du job continuent d'afficher `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+La page **Profil** d'un utilisateur liste le type de connexion, les groupes et les rôles, ce qui est le moyen le plus rapide de vérifier une correspondance.
+L'option de rôle `allowLogin` peut refuser la connexion des utilisateurs qui ne correspondent à aucun rôle : mettez-la à `false` sur `default` et à
+`true` sur les rôles autorisés à se connecter.
diff --git a/i18n/fr/_configure/authentication/ldap.md b/i18n/fr/_configure/authentication/ldap.md
new file mode 100644
index 0000000..40a3596
--- /dev/null
+++ b/i18n/fr/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Authentification
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Permettez aux utilisateurs de l'annuaire de se connecter avec leur propre mot de passe, et attribuez-leur des rôles via leurs groupes d'annuaire
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fonctionnement
+
+AnsibleForms se connecte à l'annuaire avec un compte de bind, recherche l'utilisateur, puis effectue un bind en tant que cet utilisateur pour vérifier
+le mot de passe :
+
+1. L'utilisateur se connecte avec son nom d'utilisateur et son mot de passe. Quand aucun utilisateur **local** ne porte ce nom, LDAP est essayé.
+2. AnsibleForms effectue un bind avec le compte de bind de l'identifiant de l'annuaire, et cherche dans **Base de recherche** une entrée dont
+   l'**Attribut nom d'utilisateur** est égal au nom d'utilisateur.
+3. Il effectue un bind en tant que l'entrée trouvée, avec le mot de passe saisi.
+4. Les groupes sont lus depuis l'entrée (ou depuis une recherche de groupes), filtrés, et préfixés par `ldap/`.
+
+Un nom d'utilisateur au format UPN (`jdoe@example.com`) qui ne trouve aucun utilisateur est réessayé une fois avec la partie avant le `@`, afin que les utilisateurs
+puissent se connecter sous l'une ou l'autre forme même quand l'attribut nom d'utilisateur contient le nom court. Un mauvais mot de passe n'est jamais réessayé.
+
+Un même jeu de paramètres sert pour Active Directory, OpenLDAP et d'autres ; depuis la 7.3.0, il peut y avoir [plusieurs annuaires](#several-directories).
+
+---
+
+## Paramètres
+
+Depuis la 7.3.0, les paramètres sont propres à chaque annuaire. **Accès > LDAP** liste les annuaires, dans l'ordre où un nom d'utilisateur simple est recherché :
+
+![Accès > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menu de ligne | Ce qu'il fait |
+|---|---|
+| Modifier | Ouvre la page de l'annuaire |
+| Tester la connexion | Essaie une connexion avec un nom d'utilisateur et un mot de passe de test, voir [Tester la connexion](#testing-the-connection) |
+| Activer, Désactiver | Active ou désactive l'annuaire ; `main` est désactivé plutôt que supprimé |
+| Monter, Descendre | Change sa place dans l'ordre de recherche |
+| Supprimer | Retire l'annuaire ; affiché mais désactivé sur `main` |
+
+L'ajout d'un annuaire demande ses champs en quatre étapes, les onglets de sa page. **Détails** contient **Activé**, le **Nom** et une **Description** :
+
+| Onglet | Paramètre | Signification |
+|---|---|---|
+| Identifiants | Identifiant | Obligatoire. Un identifiant `ldap` de [Connexions > Identifiants](../credentials.html), qui contient la connexion, voir plus bas |
+| Utilisateurs | Base de recherche | DN où commence la recherche d'utilisateurs, par ex. `OU=Users,DC=example,DC=com`. Les sous-arbres sont aussi parcourus |
+| Utilisateurs | Attribut nom d'utilisateur | Attribut comparé au nom de connexion : `sAMAccountName` dans AD (par défaut), `uid` dans OpenLDAP |
+| Utilisateurs | Attribut mail | Attribut contenant l'adresse e-mail, généralement `mail` |
+| Utilisateurs | Domaines de connexion | Domaines dont les connexions `user@domain` vont directement vers cet annuaire, voir [Plusieurs annuaires](#several-directories) |
+| Groupes | Attribut groupes | Attribut de l'entrée utilisateur qui contient les groupes (`memberOf`, par défaut), ou `groups` avec une recherche de groupes |
+| Groupes | Base de recherche des groupes | DN où commence la recherche de groupes |
+| Groupes | Classe de groupe | objectClass des groupes, par ex. `group`, `groupOfNames` ou `posixGroup` |
+| Groupes | Attribut membre du groupe | Attribut d'un groupe qui liste ses membres, par ex. `member`, `uniqueMember` ou `memberUid` ; par défaut `member` |
+| Groupes | Attribut utilisateur pour membre du groupe | Attribut de l'utilisateur que contiennent ces valeurs de membre, par ex. `dn` ou `uid` ; par défaut `dn` |
+| Groupes | Filtre de groupe | Expression régulière ; seuls les groupes dont le nom correspond sont conservés. Vide, tous les groupes sont conservés |
+
+Les valeurs par défaut des trois derniers champs de groupe ne s'appliquent que lorsque la recherche de groupes est utilisée, voir la section suivante.
+
+L'identifiant `ldap` indique comment l'annuaire est joint et sous quel compte il est interrogé :
+
+| Champ | Signification |
+|---|---|
+| Serveurs | Un par champ, sous la forme `host`, `host:port` ou `ldaps://host:port`, essayés dans cet ordre : quand l'un est injoignable, on passe au suivant |
+| Port | `389` pour LDAP en clair, `636` pour LDAPS |
+| Activer TLS | Se connecter en LDAPS (`ldaps://`). StartTLS sur le port 389 n'est pas pris en charge |
+| Ignorer les certificats | Ne pas valider le certificat du serveur. Affiché uniquement avec **Activer TLS** |
+| Certificat | Le certificat client qu'AnsibleForms présente aux serveurs, en PEM, quand les certificats sont vérifiés |
+| Bundle CA | Le ou les certificats de CA qui ont signé le certificat du serveur, en PEM, quand les certificats sont vérifiés |
+| DN de l'utilisateur de bind | Le DN du compte de service qui interroge l'annuaire |
+| Mot de passe de l'utilisateur de bind | Son mot de passe, stocké chiffré ou lu depuis un [coffre de secrets](../secret-stores/) |
+
+Seul un admin peut ajouter ou modifier un identifiant `ldap`, voir [Qui peut modifier un identifiant](../credentials.html#who-may-change-a-credential).
+Jusqu'à la 7.2.0, les serveurs, TLS et le compte de bind étaient des champs des paramètres LDAP. La mise à jour vers la 7.3.0 les déplace dans un identifiant,
+voir [Adresses dans les identifiants](../credentials/types.html#addresses-in-credentials) :
+
+| L'annuaire avant la mise à jour | Où vont ses serveurs |
+|---|---|
+| Son propre DN et mot de passe de bind, sans identifiant | Un nouvel identifiant `ldap` nommé `<directory>-ldap`, comme `main-ldap` |
+| Un identifiant sans serveurs | Dans cet identifiant |
+| Un identifiant qui contient déjà d'autres serveurs | Une copie de l'identifiant nommée `<credential>-<directory>`, que l'annuaire référence ensuite |
+
+Un nom déjà pris reçoit `-2`, `-3` et ainsi de suite. Un annuaire issu du seed de configuration est laissé tel quel : c'est le seed qui le gère.
+
+---
+
+## Groupes
+
+Les groupes proviennent de l'un de deux endroits, et l'**Attribut groupes** décide lequel est utilisé :
+
+- **Un attribut de l'entrée utilisateur**, généralement `memberOf`. C'est la configuration courante pour Active Directory, et pour
+  OpenLDAP avec l'overlay `memberof`.
+- **Une recherche de groupes**, pour les annuaires sans `memberOf`. Elle ne s'exécute que lorsque **Base de recherche des groupes** et **Classe de groupe**
+  sont tous deux définis : AnsibleForms cherche alors les groupes de cette classe dont l'**Attribut membre du groupe** contient
+  l'**Attribut utilisateur pour membre du groupe** de l'utilisateur, et stocke le résultat dans l'attribut `groups`. Mettez **Attribut groupes** à `groups`
+  pour l'utiliser.
+
+{: .note }
+> Avec **Attribut groupes** à `memberOf`, une recherche de groupes configurée s'exécute mais son résultat n'est pas utilisé pour les rôles.
+
+Chaque groupe est un DN, et AnsibleForms garde son premier CN : `CN=AF-Admins,OU=Groups,DC=example,DC=com` devient `AF-Admins`.
+Le **Filtre de groupe** est ensuite appliqué à ce nom, et les groupes restants reçoivent le préfixe `ldap/` : `ldap/AF-Admins`.
+
+Dans les grands annuaires, le filtre garde les jetons et les jobs légers ; une expression régulière invalide conserve tous les groupes et est journalisée.
+
+---
+
+## Correspondance avec les rôles
+
+Dans config.yaml, un groupe LDAP est `ldap/<group CN>` et un utilisateur LDAP est `ldap/<username>`, tous deux sensibles à la casse :
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+Le nom d'utilisateur est la valeur de l'**Attribut nom d'utilisateur** telle que l'annuaire la renvoie, et non telle que l'utilisateur l'a saisie.
+Voir [Rôles](../config/roles.html) pour les options de rôle.
+
+---
+
+## Plusieurs annuaires
+
+Depuis la 7.3.0, il peut y avoir plusieurs annuaires, chacun avec ses propres serveurs, utilisateurs et groupes. Leurs noms distinguent leurs membres :
+
+| Annuaire | Nom d'utilisateur | Groupes | Dans un rôle |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Tout autre, comme `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Un utilisateur nomme l'annuaire à la connexion sous la forme `corp\jdoe` ou `corp/jdoe`, ou se connecte avec une adresse d'un domaine que possède
+l'annuaire. Un nom d'utilisateur simple est essayé dans chaque annuaire activé, dans leur ordre, et il en va de même pour un nom comme `other\jdoe` quand aucun
+annuaire ne s'appelle `other` : il est alors recherché tel que saisi.
+
+Le premier annuaire qui connaît l'utilisateur tranche : un mauvais mot de passe y est la réponse, et l'annuaire suivant n'est pas
+essayé, puisqu'il pourrait contenir quelqu'un d'autre portant ce nom. Un annuaire injoignable est ignoré.
+
+L'annuaire nommé `default` jusqu'à la 7.2.0 s'appelle `main` depuis la 7.3.0 : la mise à jour le renomme, et une nouvelle installation démarre
+avec `main`. Ses membres gardent leurs noms courts, si bien que les rôles qui les nomment n'ont pas besoin d'être modifiés. L'annuaire `main` ne peut pas être
+renommé, et un nom d'annuaire ne contient que des lettres, des chiffres, `-` et `_`.
+
+---
+
+## Tester la connexion
+
+**Tester la connexion** demande un nom d'utilisateur et un mot de passe de test, et essaie une connexion avec les paramètres affichés à l'écran, enregistrés ou non.
+En cas de succès, il affiche l'entrée d'annuaire de l'utilisateur, qui vous indique les noms d'attributs exacts et les DN de groupes à utiliser.
+
+Un utilisateur de test qui n'existe pas renvoie quand même un succès : la connexion et le compte de bind fonctionnent, seul l'utilisateur est
+introuvable. Erreurs typiques :
+
+| Message | Cause |
+|---|---|
+| `Bad server or port (connection failed)` | Le nom d'hôte ne se résout pas ou le port n'est pas joignable. |
+| `Wrong binding credentials` | Le DN ou le mot de passe de bind de l'identifiant de l'annuaire est incorrect. |
+| `Unable to verify the certificate` | Le certificat du serveur n'est pas signé par le bundle CA de l'identifiant. |
+| `Certificate is not valid` | Le certificat ou le bundle CA de l'identifiant ne contient pas de certificat PEM valide. |
+
+---
+
+## Exemple Active Directory
+
+Cet exemple se connecte à deux contrôleurs de domaine en LDAPS et ne garde que les groupes dont le nom commence par `AF-` :
+
+| Paramètre | Valeur |
+|---|---|
+| Identifiant > Serveurs | `dc01.example.com`, puis `dc02.example.com` |
+| Identifiant > Port | `636` |
+| Identifiant > Activer TLS | activé |
+| Identifiant > Ignorer les certificats | désactivé, avec un certificat client et la chaîne de CA de l'autorité d'entreprise |
+| Identifiant > DN de l'utilisateur de bind | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Base de recherche | `OU=Users,DC=example,DC=com` |
+| Attribut mail | `mail` |
+| Attribut nom d'utilisateur | `sAMAccountName` |
+| Attribut groupes | `memberOf` |
+| Filtre de groupe | `^AF-` |
+
+Les membres de `CN=AF-Operators,…` correspondent aux rôles avec `ldap/AF-Operators`, et se connectent en tant que `jdoe` ou `jdoe@example.com`.
+
+---
+
+## Exemple OpenLDAP
+
+Cet exemple utilise une recherche de groupes sur des entrées `groupOfNames`, il fonctionne donc sans l'overlay `memberof` :
+
+| Paramètre | Valeur |
+|---|---|
+| Identifiant > Serveurs | `ldap.example.com` |
+| Identifiant > Port | `636` |
+| Identifiant > Activer TLS | activé |
+| Identifiant > DN de l'utilisateur de bind | `cn=readonly,dc=example,dc=com` |
+| Base de recherche | `ou=people,dc=example,dc=com` |
+| Attribut mail | `mail` |
+| Attribut nom d'utilisateur | `uid` |
+| Attribut groupes | `groups` |
+| Base de recherche des groupes | `ou=groups,dc=example,dc=com` |
+| Classe de groupe | `groupOfNames` |
+| Attribut membre du groupe | `member` |
+| Attribut utilisateur pour membre du groupe | `dn` |
+
+Un utilisateur listé dans `cn=af-admins,ou=groups,dc=example,dc=com` reçoit le groupe `ldap/af-admins`. Pour des groupes `posixGroup`,
+utilisez **Attribut membre du groupe** `memberUid` et **Attribut utilisateur pour membre du groupe** `uid`.
+
+Avec l'overlay `memberof`, laissez vides les champs de recherche de groupes et mettez **Attribut groupes** à `memberOf`.
+
+---
+
+## Pièges courants
+
+La plupart des problèmes LDAP se ramènent à l'un de ceux-ci :
+
+- **Un utilisateur local portant le même nom.** Les utilisateurs locaux sont vérifiés en premier, donc l'annuaire n'est jamais interrogé pour ce nom.
+- **Aucun groupe, ou pas les bons.** L'attribut groupes doit exister (`groups` avec une recherche de groupes) ; `memberOf` ignore l'imbrication.
+- **Des noms de groupe qui ne correspondent pas.** Utilisez `ldap/<CN>` avec la même casse, et vérifiez que le filtre de groupe conserve le groupe.
+- **Des DN de groupe qui ne commencent pas par un CN.** Seule la première valeur `CN=` sert de nom de groupe, donc chaque DN de groupe
+  doit commencer par `CN=` (ou `cn=`).
+- **Les certificats.** TLS nécessite les deux champs de certificat de l'identifiant et un nom de serveur correspondant ; Ignorer les certificats est réservé aux tests.
+- **Des paramètres impossibles à enregistrer.** Quand un annuaire provient du [seed de configuration](../seed/managed-objects.html), sa page
+  est en lecture seule : modifiez plutôt le fichier seed.
+
+Une connexion qui échoue affiche un message générique. La raison est journalisée par le serveur et conservée dans le journal d'audit, et pour Active
+Directory elle est traduite depuis le code de l'annuaire, par ex. `Wrong password`, `Account locked` ou `Password expired`.
diff --git a/i18n/fr/_configure/authentication/local.md b/i18n/fr/_configure/authentication/local.md
new file mode 100644
index 0000000..4fb7f6e
--- /dev/null
+++ b/i18n/fr/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Comptes locaux
+parent: Authentification
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Comptes locaux
+{: .no_toc }
+
+L'admin intégré, et les utilisateurs et groupes stockés dans la base de données d'AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'admin intégré
+
+Chaque démarrage crée le groupe local `admins` et l'utilisateur admin s'ils manquent ; trois variables pilotent l'admin :
+
+| Variable | Défaut | Signification |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Nom d'utilisateur de l'admin, créé dans le groupe `admins` quand aucun utilisateur ne porte ce nom. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Mot de passe donné à l'admin lors de sa création (ou réinitialisation). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` réinitialise le mot de passe de l'admin à `ADMIN_PASSWORD` et le remet dans `admins`. |
+
+`ADMIN_PASSWORD` ne sert qu'à la création ou à la réinitialisation de l'utilisateur : le modifier ensuite ne fait rien à lui seul.
+
+Un utilisateur local qui se connecte avec le mot de passe par défaut public `AnsibleForms!123` ne peut que le changer. Le navigateur ouvre une
+page de changement de mot de passe impossible à fermer, et le serveur répond à toute autre requête par `403` (code
+`password_change_required`) jusqu'à ce que le mot de passe soit changé. Le nouveau mot de passe doit être différent de celui par défaut ; après le
+changement, l'utilisateur se reconnecte avec lui. Définissez `ADMIN_PASSWORD` avec votre propre valeur avant le premier démarrage pour éviter cette étape.
+
+Changer `ADMIN_USERNAME` après le premier démarrage crée un second utilisateur admin portant ce nom ; l'ancien est conservé.
+
+{: .warning }
+> `REINIT_ADMIN=1` réinitialise le mot de passe à **chaque** démarrage tant qu'elle est définie. Utilisez-la pour récupérer un mot de passe admin perdu,
+> puis retirez-la et redémarrez.
+
+---
+
+## Utilisateurs et groupes
+
+Les utilisateurs et groupes locaux se gèrent dans **Accès > Utilisateurs** et **Accès > Groupes**. Un utilisateur a ces champs :
+
+| Champ | Signification |
+|---|---|
+| Nom d'utilisateur | Le nom de connexion. Doit être unique. |
+| Description | Facultatif. |
+| Mot de passe | Stocké sous forme de hash. Changez-le plus tard avec l'action **Changer le mot de passe**. |
+| E-mail | Facultatif. |
+| Groupe | Le premier groupe local de l'utilisateur. Ajoutez-en d'autres dans l'onglet **Groupes** de la page de l'utilisateur. |
+
+Les utilisateurs locaux changent leur propre mot de passe dans leur profil ; les autres utilisateurs le font dans leur annuaire ou leur fournisseur d'identité.
+
+Un utilisateur peut appartenir à plusieurs groupes, et reçoit les rôles de tous. L'onglet **Groupes** de la page d'un utilisateur ajoute et
+retire des groupes, tout comme l'onglet **Utilisateurs** de la page d'un groupe. Un utilisateur garde au moins un groupe : le dernier ne peut pas
+être retiré.
+
+Un groupe qui a encore des utilisateurs ne peut pas être supprimé : retirez d'abord ses utilisateurs. Le groupe `admins` ne peut jamais être supprimé ni
+renommé, et l'utilisateur `admin` ne peut jamais être supprimé.
+
+---
+
+## Autoriser la connexion
+
+L'onglet **Détails** de la page d'un utilisateur a un interrupteur **Autoriser la connexion**, proposé aussi comme **Bloquer la connexion** et **Autoriser
+la connexion** dans le menu de ligne de la liste des utilisateurs. Il existe aussi bien pour les utilisateurs locaux que pour les utilisateurs LDAP et SSO :
+
+- **Activé** : l'utilisateur se connecte normalement.
+- **Désactivé** : les sessions de l'utilisateur se terminent immédiatement et toute connexion est refusée, jusqu'à ce qu'un admin le réactive. La page
+  demande d'abord une confirmation.
+
+L'interrupteur ne peut pas être désactivé pour l'utilisateur `admin`, le moyen de revenir, ni par un admin pour son propre compte. La page
+d'un utilisateur LDAP ou SSO a aussi **Terminer les sessions**, qui déconnecte l'utilisateur partout sans le bloquer.
+
+---
+
+## Correspondance avec les rôles
+
+Les rôles nomment les groupes locaux `local/<group>` et les utilisateurs `local/<user>` ; par défaut, `admins` reçoit `admin` :
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Gardez `local/admins` dans le rôle `admin`, pour que l'admin intégré puisse toujours se connecter, même quand l'annuaire ou le
+fournisseur d'identité est indisponible. Quand config.yaml ne peut pas du tout être chargé, les membres de `local/admins` reçoivent quand même le
+rôle `admin`, pour que vous puissiez vous connecter et le corriger. Voir [Rôles](../config/roles.html) pour les options de rôle.
+
+---
+
+## Comptes locaux et LDAP
+
+Une connexion par nom d'utilisateur et mot de passe vérifie les utilisateurs locaux avant LDAP. Quand un utilisateur local porte le même nom qu'un utilisateur
+de l'annuaire, le compte local l'emporte toujours et le mot de passe de l'annuaire ne fonctionne pas pour ce nom. Donnez aux comptes locaux des noms
+qui ne peuvent pas entrer en conflit avec les comptes de l'annuaire, par exemple avec un préfixe `svc-`.
diff --git a/i18n/fr/_configure/authentication/oidc.md b/i18n/fr/_configure/authentication/oidc.md
new file mode 100644
index 0000000..edd1d36
--- /dev/null
+++ b/i18n/fr/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Authentification
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Authentification unique avec un fournisseur OpenID Connect comme Keycloak, avec des rôles issus d'un claim de groupes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fonctionnement
+
+Avec un fournisseur OIDC activé, la page de connexion affiche un bouton OpenID sous **Se connecter**. Une connexion se déroule alors ainsi :
+
+1. Le bouton envoie le navigateur vers `/api/v2/auth/oidc`, qui le redirige vers le fournisseur (flux authorization code
+   avec PKCE).
+2. L'utilisateur se connecte chez le fournisseur, qui le redirige vers l'**URL de redirection**.
+3. Le serveur échange le code contre des tokens et lit les claims de l'ID token.
+4. Le nom d'utilisateur est le claim `preferred_username`, et chaque valeur du claim `groups` qui passe le
+   **Filtre de groupe** devient un groupe `oidc/<value>`.
+
+AnsibleForms demande les scopes `openid profile email` ; les scopes ne sont pas configurables. Se déconnecter d'AnsibleForms
+envoie aussi le navigateur vers l'endpoint de fin de session du fournisseur, quand celui-ci en publie un.
+
+{: .note }
+> OIDC a été testé avec Keycloak. Les autres fournisseurs fonctionnent s'ils remplissent les exigences ci-dessous.
+
+---
+
+## Exigences du fournisseur
+
+Le fournisseur doit proposer la découverte OpenID Connect, et un client confidentiel pour AnsibleForms :
+
+- **Découverte** : AnsibleForms lit `<issuer>/.well-known/openid-configuration`, l'issuer doit donc être joignable depuis
+  le serveur AnsibleForms, en HTTPS.
+- **Un client confidentiel** avec le flux authorization code, un ID client et un secret client.
+- **L'URI de redirection** `https://af.example.com/api/v2/auth/oidc/callback`, c'est-à-dire l'adresse à laquelle les utilisateurs accèdent à
+  AnsibleForms suivie de `/api/v2/auth/oidc/callback`. Avec [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms`, elle devient `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Un claim `groups` dans l'ID token**, contenant une liste de noms de groupes. Sans lui, l'utilisateur n'a aucun groupe OIDC.
+- **Un claim `preferred_username`**, qui devient le nom d'utilisateur.
+
+---
+
+## Exemple Keycloak
+
+Cet exemple utilise un realm `example` sur `https://keycloak.example.com` ; l'issuer est alors
+`https://keycloak.example.com/realms/example`. Dans ce realm :
+
+1. Dans **Clients**, créez un client OpenID Connect avec le client ID `ansibleforms`. Activez **Client authentication**,
+   gardez **Standard flow**, et mettez **Valid redirect URIs** à `https://af.example.com/api/v2/auth/oidc/callback`.
+2. Dans l'onglet **Credentials** du client, copiez le **Client secret**.
+3. Dans l'onglet **Client scopes**, ouvrez `ansibleforms-dedicated` et ajoutez un mapper **By configuration > Group Membership**,
+   avec **Token Claim Name** `groups`, **Full group path** désactivé et **Add to ID token** activé.
+
+Avec **Full group path** activé, le claim contient des chemins comme `/af-admins`, et le rôle doit alors utiliser `oidc//af-admins`.
+
+---
+
+## Ajouter le fournisseur
+
+Ajoutez le fournisseur dans **Accès > SSO** : un assistant demande ses champs en quatre étapes, avec **Open ID** à l'étape **Type** :
+
+| Étape | Champ | Signification |
+|---|---|---|
+| Détails | Nom, Description | Un nom unique pour le fournisseur, et une description facultative |
+| Type | Fournisseur | **Open ID** ; défini à la création, il ne change plus |
+| Identifiants | Identifiant | Un identifiant **Open ID** de [Connexions > Identifiants](../credentials.html), voir plus bas |
+| Groupes | Filtre de groupe | Expression régulière ; seules les valeurs du claim `groups` qui correspondent sont conservées. Vide, tous les groupes sont conservés |
+
+L'identifiant contient le client, donc seul un admin peut l'ajouter ou le modifier :
+
+| Champ | Signification |
+|---|---|
+| Issuer | Obligatoire. L'URL de l'issuer, par ex. `https://keycloak.example.com/realms/example` |
+| ID client | L'ID du client chez le fournisseur, par ex. `ansibleforms` |
+| Secret client | Le secret client, stocké chiffré ou lu depuis un [coffre de secrets](../secret-stores/) |
+| URI de redirection | Telle qu'inscrite, par ex. `https://af.example.com/api/v2/auth/oidc/callback`. Vide : l'URL de l'application et le chemin de callback |
+
+Jusqu'à la 7.2.0, l'issuer, l'ID client, le secret et l'URL de redirection étaient des champs du fournisseur. La mise à jour vers la 7.3.0 les déplace dans un
+identifiant nommé `<provider>-sso`, voir [Adresses dans les identifiants](../credentials/types.html#addresses-in-credentials).
+Choisissez un identifiant pour chaque nouveau fournisseur : le serveur accepte toujours un fournisseur d'avant la 7.3.0 avec son propre ID client et son propre secret,
+qui se connecte avec eux jusqu'à ce qu'un identifiant soit choisi.
+
+Un seul fournisseur OIDC est activé à la fois, celui avec lequel le bouton OpenID connecte. **Activer** dans le menu de ligne d'un autre,
+ou son interrupteur **Activé**, désactive les autres du même type ; la colonne **Activé** de la liste montre lequel est utilisé.
+Un fournisseur peut aussi passer la page de connexion, voir [Basculer l'authentification unique](./#switching-single-sign-on).
+
+L'enregistrement du fournisseur l'applique immédiatement. Quand l'issuer est injoignable, le serveur journalise
+`Failed to initialize OIDC strategy` et les connexions OIDC échouent jusqu'à ce que le fournisseur soit enregistré à nouveau ou que le serveur redémarre.
+
+---
+
+## Correspondance avec les rôles
+
+Dans config.yaml, un groupe OIDC est `oidc/<group>` et un utilisateur est `oidc/<preferred_username>` :
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+Les valeurs sont comparées exactement, casse comprise. Voir [Rôles](../config/roles.html) pour les options de rôle.
+
+---
+
+## Limites
+
+Les utilisateurs OIDC se connectent chez le fournisseur, donc quelques points fonctionnent différemment des comptes locaux et LDAP :
+
+- Ils n'ont pas de mot de passe dans AnsibleForms, ils ne peuvent donc pas le changer ici ; depuis la 7.2.0, un [jeton d'API](../profile/api-token.html)
+  est créé à partir de leur session.
+- Gardez le claim `groups` court : n'envoyez que les groupes qui comptent pour AnsibleForms, par exemple avec un client scope
+  dédié ou une structure de groupes chez le fournisseur, ou filtrez-les avec le **Filtre de groupe**. Depuis la 7.1.0, le jeton
+  de connexion d'AnsibleForms ne transporte plus les groupes ; auparavant, un utilisateur membre d'une centaine de groupes ou plus pouvait ne voir aucun formulaire, voir
+  [Formulaires et jobs vides après une authentification unique](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/fr/_configure/config/categories.md b/i18n/fr/_configure/config/categories.md
new file mode 100644
index 0000000..8acb644
--- /dev/null
+++ b/i18n/fr/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Catégories
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Catégories
+{: .no_toc }
+
+Regroupez les formulaires du tableau de bord.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'attribut categories
+
+La liste `categories` de premier niveau de config.yaml :
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Objet Category
+
+Chaque entrée de la liste `categories` :
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/fr/_configure/config/constants.md b/i18n/fr/_configure/config/constants.md
new file mode 100644
index 0000000..346c96f
--- /dev/null
+++ b/i18n/fr/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Constantes
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Constantes
+{: .no_toc }
+
+Des objets libres que chaque formulaire peut réutiliser.
+{: .fs-6 .fw-300 }
+
+---
+
+## L'attribut constants
+
+L'objet `constants` de premier niveau de config.yaml :
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/fr/_configure/config/index.md b/i18n/fr/_configure/config/index.md
new file mode 100644
index 0000000..2ad2013
--- /dev/null
+++ b/i18n/fr/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Catégories, rôles et constantes pour tous les formulaires
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les administrateurs : le fichier config.yaml qui contient les catégories, les rôles et les constantes partagés par tous les formulaires.
+
+AnsibleForms utilise un fichier config.yaml pour configurer les catégories, les rôles et les constantes. Si aucun fichier n'est fourni, il en génère un avec une configuration minimale. La configuration peut aussi être importée dans la base de données, ce qui rend le fichier config.yaml inutile.
+
+---
+
+## Vue d'ensemble
+
+Le fichier config.yaml contient la configuration des catégories, des rôles et des constantes utilisés par AnsibleForms.
+
+**VIDÉO** : [Créez votre premier formulaire](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+Le config.yaml minimal suivant sert de point de départ. Il ne contient que la catégorie obligatoire `Default` et les rôles obligatoires `admin` et `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Priorité de chargement de la configuration
+
+AnsibleForms charge le fichier config.yaml dans l'ordre suivant (la première correspondance l'emporte) :
+
+1. **DEPUIS LA BASE DE DONNÉES** : la configuration importée dans la base de données, uniquement quand `ENABLE_CONFIG_IN_DATABASE=1`, ou quand cette
+   variable n'est pas définie et que la source de configuration stockée dans la base de données est `database` (une copie vide se rabat sur le fichier)
+2. **DEPUIS UN DÉPÔT (use_for_config)** : le dépôt dont l'interrupteur « use for config » est activé (nouveau dans la 6.1.0)
+3. **DEPUIS UN DÉPÔT (use_for_forms)** : le dépôt dont l'interrupteur « use for forms » est activé (repli pour la rétrocompatibilité)
+4. **DEPUIS LE FICHIER LOCAL** : le fichier local `config.yaml` (variable d'environnement CONFIG_PATH)
+
+{: .warning }
+> **Remarque :** activez « use for config » sur un seul dépôt. Si plusieurs l'ont activé, un avertissement est journalisé et le premier est utilisé.
+
+---
+
+## Dans cette section
+
+Le fichier a trois attributs de premier niveau, et chacun a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Catégories](categories.html) | Regrouper les formulaires du tableau de bord dans une arborescence de catégories avec des icônes |
+| [Rôles](roles.html) | Associer les utilisateurs et les groupes à des rôles, et définir ce que chaque rôle peut faire |
+| [Constantes](constants.html) | Des objets libres que chaque formulaire peut réutiliser |
diff --git a/i18n/fr/_configure/config/roles.md b/i18n/fr/_configure/config/roles.md
new file mode 100644
index 0000000..1505816
--- /dev/null
+++ b/i18n/fr/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Rôles
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Rôles
+{: .no_toc }
+
+Associez les utilisateurs et les groupes à des rôles, et définissez ce que chaque rôle peut faire.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'attribut roles
+
+La liste `roles` de premier niveau de config.yaml :
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## Le rôle default
+
+Chaque utilisateur connecté a le rôle `default`, si bien qu'un formulaire avec `roles: [default]` est ouvert à tous ceux qui peuvent se connecter. Il
+n'y a pas d'accès anonyme : personne ne reçoit ce rôle sans se connecter.
+
+Le rôle ne contient ni groupes ni utilisateurs, puisqu'il s'applique déjà à tout le monde. Ses `options` sont les valeurs par défaut de tous, comme
+décrit dans [Options de rôle](#role-options) plus bas. `config.yaml` doit avoir un rôle `admin` et un rôle `default`, et la
+page des rôles les affiche tous deux comme **Requis**.
+
+`default` s'appelait `public` avant la 7.0.0, et l'ancien nom fonctionne toujours :
+
+- **Dans un formulaire**, `roles: [public]` correspond toujours à tous les utilisateurs, les formulaires de vos dépôts n'ont donc pas besoin d'être modifiés.
+- **Dans `config.yaml`**, un rôle appelé `public` est renommé `default` dans le fichier au chargement de la config. Seul le nom
+  change, une sauvegarde de la config est faite d'abord, et une config conservée dans un dépôt a alors une modification à pousser.
+- **Dans un modèle ytt**, le modèle n'est pas réécrit : la config qu'il produit est renommée, et un avertissement dans le journal vous demande
+  de renommer aussi le rôle dans le modèle. La version 8 y refuse un rôle `public`.
+
+Une config qui a à la fois un rôle `default` et un rôle `public` est refusée, car il s'agit du même rôle.
+
+---
+
+## Objet Role
+
+Chaque entrée de la liste `roles` :
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Options de rôle
+
+Les `options` d'un rôle activent ou désactivent des fonctionnalités pour ses membres. Depuis la 7.3.0, la page du rôle les affiche en quatre groupes,
+chaque option avec un (i) qui explique ce qu'elle donne, le même texte que celui de la vue **Autorisations** du profil :
+
+| Option | Permet à l'utilisateur de | Défaut |
+|---|---|---|
+| **Paramètres** | | |
+| `showSettings` | Voir et modifier toutes les pages de paramètres ; le journal du serveur et les sauvegardes ont leurs propres options | Admins uniquement |
+| `showAppearanceSettings` | Modifier les paramètres d'apparence, sans les autres paramètres (depuis la 7.3.0) | Désactivé |
+| `showConnectionsSettings` | Gérer les paramètres de connexions (identifiants, runners et plus), sans les autres paramètres (depuis la 7.3.0) | Désactivé |
+| `showLogs` | Voir le journal du serveur | Admins uniquement |
+| `showAuditLog` | Voir le journal d'audit, sans les autres paramètres (depuis la 7.3.0) | Admins uniquement |
+| `allowBackupOps` | Sauvegarder et restaurer la base de données | Admins uniquement |
+| **Concepteur** | | |
+| `showDesigner` | Voir et utiliser le concepteur | Admins uniquement |
+| `allowFormDesign` | Modifier la config des formulaires dans le concepteur : catégories, constantes et formulaires. Sans elle, lecture seule (depuis la 7.3.0) | Activé |
+| `allowPlaybookDesign` | Modifier les playbooks dans le concepteur : les enregistrer, créer, retirer et pousser. Sans elle, lecture seule | Activé |
+| `allowWorkflowDesign` | Modifier les workflows dans le concepteur : les enregistrer, créer, retirer et pousser. Sans elle, lecture seule | Activé |
+| `allowInventoryDesign` | Modifier les inventaires dans le concepteur : les enregistrer, créer, retirer et pousser. Sans elle, lecture seule | Activé |
+| `allowVarsFileDesign` | Modifier les fichiers de variables dans le concepteur : les enregistrer, créer, retirer et pousser. Sans elle, lecture seule | Activé |
+| **Jobs** | | |
+| `showJobs` | Voir la page des jobs | Activé |
+| `showAllJobLogs` | Voir les jobs de tous les utilisateurs, pas seulement les siens | Admins uniquement |
+| `manageAllJobs` | Interrompre, supprimer et relancer les jobs de tous les utilisateurs ; supprimer et relancer nécessitent aussi les deux options ci-dessous (depuis la 7.3.0) | Admins uniquement |
+| `showExtravars` | Voir les extravars d'un formulaire et d'un job | Activé |
+| `showDebugButtons` | Voir les boutons de débogage d'un formulaire | Activé |
+| `showArtifacts` | Voir les artefacts d'un job : ce que renvoie un job AWX, ou ce qu'un playbook a collecté avec `set_stats` | Activé |
+| `allowVerboseMode` | Exécuter des jobs en mode verbeux | Activé |
+| `allowJobRelaunch` | Relancer un job avec les données de formulaire d'une exécution précédente | Admins uniquement |
+| `allowJobDeletion` | Supprimer des jobs : les siens, ou ceux de tous les utilisateurs avec `manageAllJobs`. Sans elle, l'historique des jobs reste complet (depuis la 7.3.0) | Activé |
+| `allowScheduledJobs` | Créer et gérer des planifications récurrentes et ponctuelles, sur la page **Planifications** (voir l'avertissement ci-dessous) | Admins uniquement |
+| `allowPlannedJobs` | Planifier un job pour qu'il s'exécute une fois à une heure donnée (**Exécuter plus tard**) | Activé |
+| `allowStoredJobs` | Enregistrer les données d'un formulaire et les recharger plus tard | Activé |
+| **Accès et intégrations** | | |
+| `allowLogin` | Se connecter à AnsibleForms | Activé |
+| `allowChat` | Utiliser l'[assistant de chat](../chat/), quand il est activé | Activé |
+| `allowMcp` | Utiliser le [serveur MCP](../mcp/) depuis un agent IA, quand il est activé | Le `allowChat` du rôle |
+| `allowFileUploads` | Téléverser des fichiers via les champs fichier d'un formulaire (depuis la 7.3.0) | Activé |
+| `allowApiTokens` | Créer des [jetons d'API](../profile/api-token.html) pour des scripts, jusqu'à la durée de vie maximale qu'autorise l'instance (depuis la 7.3.0) | Désactivé |
+| `extendedTokenExpiration` | Créer aussi des jetons d'API qui n'expirent jamais ; nécessite `allowApiTokens` | Désactivé |
+
+Certaines options en incluent d'autres, et la page du rôle affiche celles qui sont incluses activées et grisées :
+
+- **`showSettings`** donne aussi `showAppearanceSettings`, `showConnectionsSettings` et `showAuditLog`.
+- **`manageAllJobs`** donne aussi `showAllJobLogs`, car agir sur les jobs de tous les utilisateurs suppose de les voir.
+- **Les options de conception** ne comptent qu'avec `showDesigner`, et `extendedTokenExpiration` qu'avec `allowApiTokens`.
+
+Jusqu'à la 7.2.0, `showAllJobLogs` permettait aussi à un utilisateur d'interrompre et de supprimer les jobs qu'elle affichait ; depuis la 7.3.0, il faut `manageAllJobs`.
+Un rôle d'avant la 7.3.0 avec `extendedTokenExpiration` et sans `allowApiTokens` reçoit `allowApiTokens`, et garde donc ses jetons.
+
+**Admins uniquement** signifie activé pour les utilisateurs qui ont le rôle `admin`, et désactivé pour tous les autres. Quand un utilisateur correspond à plusieurs rôles,
+les options se combinent comme suit :
+
+- **Entre les rôles de l'utilisateur**, une option n'est activée que si tous les rôles qui la définissent sont d'accord : un `false` explicite l'emporte.
+- **Le rôle `default`** complète les options qu'aucun des autres rôles de l'utilisateur ne définit, il peut donc contenir des valeurs par défaut pour tous.
+- **Les options définies nulle part** prennent la valeur par défaut du tableau.
+
+`showExtraVars`, avec un V majuscule, est accepté comme autre orthographe de `showExtravars` ; quand l'une des deux orthographes vaut `false`,
+l'option est désactivée.
+
+{: .warning }
+> Traitez `allowScheduledJobs` comme une option de niveau admin. Les planifications n'appartiennent pas à l'utilisateur qui les a créées : chaque utilisateur ayant
+> l'option voit et peut modifier toutes les planifications. Une planification s'exécute aussi avec des droits d'admin, pour n'importe quel formulaire, quels que soient les
+> accès propres de son créateur. Ne l'accordez qu'aux rôles auxquels vous feriez confiance comme admins.
+
+{: .warning }
+> `allowLogin: false` sur le rôle `default` bloque tous les utilisateurs dont les autres rôles ne définissent pas `allowLogin: true`, y compris
+> les admins. Réaccordez-la sur les rôles qui doivent se connecter avant d'enregistrer.
diff --git a/i18n/fr/_configure/credentials.md b/i18n/fr/_configure/credentials.md
new file mode 100644
index 0000000..445f840
--- /dev/null
+++ b/i18n/fr/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Identifiants
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Identifiants
+{: .no_toc }
+
+Stockez les accès avec lesquels se connectent les formulaires, les dépôts, les coffres de secrets et les canaux de notification
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : ajoutez les utilisateurs, mots de passe et jetons avec lesquels AnsibleForms se connecte, conservés chiffrés ou lus depuis un coffre de secrets.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Types d'identifiants](credentials/types.html) | Ce que contient chaque type, et où il peut être choisi |
+| [La page des identifiants](credentials/list.html) | La liste des identifiants, et la boîte de dialogue qui en ajoute un |
+| [La page d'un identifiant](credentials/credential-page.html) | Les onglets d'un identifiant, et ce qui l'utilise |
+
+---
+
+## Fonctionnement
+
+Un **identifiant** est un accès nommé, ajouté dans **Connexions > Identifiants**. Les formulaires et les autres objets d'administration y font référence
+par son nom, si bien que le mot de passe lui-même n'apparaît jamais dans un formulaire. Son utilisateur et son mot de passe sont soit conservés dans la
+base de données d'AnsibleForms, chiffrés avec `ENCRYPTION_SECRET`, soit lus depuis un [coffre de secrets](secret-stores/) à chaque utilisation de
+l'identifiant.
+
+---
+
+## Qui peut modifier un identifiant
+
+Depuis la 7.3.0, un identifiant dont dépend une connexion ou une authentification ne peut être ajouté, modifié ou supprimé que par un admin :
+
+| Identifiants | Pourquoi |
+|---|---|
+| Types de connexion : `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` et `cyberark` | Un runner ou un coffre de secrets en tire son adresse et son secret |
+| Types d'authentification : `oidc`, `entraid` et `ldap` | Un fournisseur SSO ou un annuaire LDAP connecte les utilisateurs avec lui |
+| Tout identifiant que nomme un runner | Le runner se connecte avec lui, et la modification du runner lui-même nécessite aussi un admin |
+
+Les autres utilisateurs ayant accès aux identifiants les voient en lecture seule. Un utilisateur qui pourrait pointer un tel identifiant vers un autre
+serveur recevrait tous les secrets envoyés à travers lui, c'est pourquoi la règle suit celle des runners. Trois autres règles
+tiennent ces utilisateurs à l'écart de secrets qu'ils ne pourraient pas lire autrement :
+
+- **Nommer un identifiant protégé** : seul un admin peut nommer l'un de ces identifiants ailleurs, comme dans un dépôt,
+  un canal de notification ou les paramètres de l'assistant de chat. Un identifiant qui lit son mot de passe depuis un coffre de secrets est
+  protégé de la même façon, quel que soit son type.
+- **Choisir un coffre de secrets** : seul un admin peut pointer un identifiant vers un [coffre de secrets](secret-stores/), ou changer le
+  coffre ou la référence qu'il lit ; un autre utilisateur peut toujours les renvoyer inchangés, ou les vider tous.
+- **Déplacer un identifiant** : quand un autre utilisateur change l'endroit où un identifiant se connecte (son hôte, son port, son issuer, son tenant ou
+  l'adresse de son serveur) sans ressaisir son mot de passe, le mot de passe stocké est effacé, de même que la référence au coffre de secrets
+  qu'il lit, afin que l'ancien secret n'aille jamais vers la nouvelle cible.
+
+---
+
+## Identifiants utilisés
+
+Un identifiant que des enregistrements nomment encore ne peut être ni supprimé ni renommé, car ils pointeraient alors vers rien.
+Le refus indique combien d'enregistrements l'utilisent ; l'onglet **Utilisé par** de [sa page](credentials/credential-page.html) les liste.
+Pointez-les d'abord vers un autre identifiant, puis supprimez-le ou renommez-le.
diff --git a/i18n/fr/_configure/credentials/credential-page.md b/i18n/fr/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..9907d7d
--- /dev/null
+++ b/i18n/fr/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "La page d'un identifiant"
+parent: Identifiants
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# La page d'un identifiant
+{: .no_toc }
+
+Les onglets d'un identifiant, et ce qui l'utilise
+{: .fs-6 .fw-300 }
+
+La page d'un identifiant affiche les étapes de sa boîte de dialogue sous forme d'onglets, plus ce qui l'utilise :
+
+| Onglet | Ce qu'il contient |
+|---|---|
+| Détails | Nom et description. |
+| Type | À quoi sert l'identifiant. |
+| Connexion | Tous les champs de son type, comme à l'étape **Connexion** de la boîte de dialogue : l'utilisateur, le mot de passe, et l'endroit où il se connecte (hôte et port, la base de données, le serveur mail, les serveurs de l'annuaire, le tenant ou l'issuer, l'adresse du serveur et son TLS). L'AppID, le certificat client et la clé d'un identifiant CyberArk. |
+| Stockage | Base de données ou Coffre de secrets, et le coffre et la référence. Pas pour CyberArk ni HashiCorp Vault. |
+| Utilisé par | Tout ce qui nomme cet identifiant : coffres de secrets, canaux de notification, dépôts, annuaires LDAP, fournisseurs SSO, runners, l'assistant de chat, les formulaires et les workflows du concepteur. Une ligne l'ouvre. |
+
+Le mot de passe se saisit dans l'onglet **Connexion**, et n'est plus jamais affiché une fois enregistré : laissé vide, celui qui est stocké est conservé. Pour un identifiant
+CyberArk, laissez la clé client vide pour garder celle qui est stockée. En haut à droite se trouvent **Tester la connexion** (identifiants de base de données uniquement),
+**Supprimer** et **Enregistrer**.
+
+Depuis la 7.3.0, **Supprimer** et un nouveau nom sont refusés tant que **Utilisé par** liste quelque chose, voir [Identifiants utilisés](../credentials.html#credentials-in-use).
+
+Un identifiant déclaré dans le [seed de configuration](../seed/) est en lecture seule sur cette page : modifiez-le plutôt dans le fichier seed.
diff --git a/i18n/fr/_configure/credentials/list.md b/i18n/fr/_configure/credentials/list.md
new file mode 100644
index 0000000..f2570a1
--- /dev/null
+++ b/i18n/fr/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: La page des identifiants
+parent: Identifiants
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# La page des identifiants
+{: .no_toc }
+
+La liste des identifiants, et la boîte de dialogue qui en ajoute un
+{: .fs-6 .fw-300 }
+
+La page **Connexions > Identifiants** liste chaque identifiant avec son **Nom**, son **Type**, sa **Description** et **Utilisé par**, le
+nombre d'enregistrements, de formulaires et de workflows qui le nomment (voir [Identifiants utilisés](../credentials.html#credentials-in-use)).
+
+**Ajouter un identifiant** ouvre une boîte de dialogue en étapes :
+
+| Étape | Champs |
+|---|---|
+| Identifiant | Nom et description, tous deux obligatoires. |
+| Type | L'un des 18 types, voir plus bas. |
+| Connexion | Ce avec quoi le type se connecte et où, voir plus bas. |
+| Stockage | Où sont conservés l'utilisateur et le mot de passe : **Base de données** (chiffrés dans la base de données d'AnsibleForms) ou **Coffre de secrets**, avec le coffre et la **Référence** qu'il contient. Pas pour CyberArk ni HashiCorp Vault, avec lesquels un coffre de secrets se connecte. |
+
+L'étape **Type** liste les types par leur nom : AAP, API, Ascender, AWX, CyberArk, Base de données, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH, et Utilisateur et mot de passe (voir [Types d'identifiants](types.html)).
+
+L'étape **Connexion** contient tous les champs du type, adresse comprise ; il n'y a pas d'étape de connexion séparée :
+
+| Types | Champs de l'étape Connexion |
+|---|---|
+| Tous les types sauf CyberArk | Le mot de passe, ou ce qui en tient lieu : le mot de passe de bind de LDAP, le secret client d'Entra ID et d'Open ID, le jeton de HashiCorp Vault, le jeton RTE, le jeton d'API de Semaphore, Rundeck et Jenkins, un jeton ou mot de passe pour AWX, AAP et Ascender |
+| Tous les types sauf HashiCorp Vault, RTE, Semaphore et Rundeck | L'utilisateur : l'AppID de CyberArk, le DN de bind de LDAP, l'ID client d'Entra ID et d'Open ID, facultatif pour AWX, AAP et Ascender |
+| SSH, Base de données | **Hôte** et **Port** ; pour une base de données, aussi le **Type de base de données** et **Base de données** |
+| SMTP | **Serveur mail** (obligatoire), son **Port** et **Utiliser TLS** |
+| LDAP | Les **Serveurs** de l'annuaire (obligatoire), son **Port** et **Activer TLS** ; avec TLS, **Ignorer les certificats**, le **Bundle CA** et un **Certificat client** |
+| Microsoft Entra ID | **ID du tenant** (obligatoire) et **URI de redirection** |
+| Open ID | **Issuer** (obligatoire) et **URI de redirection** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Serveur**, l'adresse à laquelle il se connecte, obligatoire, avec **Ignorer la vérification du certificat** et le **Bundle CA** |
+| CyberArk | **Certificat client** et **Clé client** |
+
+Une ligne ouvre la page de l'identifiant. Son menu propose **Modifier**, **Tester la connexion** (identifiants de base de données uniquement) et **Supprimer**. Le
+mot de passe se change sur la page de l'identifiant, dans son onglet **Connexion**.
diff --git a/i18n/fr/_configure/credentials/types.md b/i18n/fr/_configure/credentials/types.md
new file mode 100644
index 0000000..2fa13fb
--- /dev/null
+++ b/i18n/fr/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Types d'identifiants
+parent: Identifiants
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Types d'identifiants
+{: .no_toc }
+
+Ce que contient chaque type, et où il peut être choisi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les types
+
+Le type indique à quoi sert un identifiant. Il décide des champs que demande la boîte de dialogue, et de l'endroit où il peut être choisi :
+
+| Type | Ce qu'il contient | Utilisé par |
+|---|---|---|
+| Utilisateur et mot de passe | Un utilisateur et un mot de passe pour n'importe quel accès : une API REST avec authentification basique, un service et plus. Le type par défaut | Les playbooks, via les `credentials` d'un formulaire ou un champ d'identifiant ; les [expressions REST](../expressions/credentials.html) |
+| SSH | Un utilisateur et un mot de passe pour SSH vers un serveur, avec son hôte et son port | Les playbooks, via les `credentials` ou `ansibleCredentials` d'un formulaire ou un champ d'identifiant, et l'accès d'un nœud de workflow |
+| Git | Un utilisateur et un mot de passe ou un jeton pour des dépôts git | Les [dépôts](../repositories/authentication.html) |
+| API | Un utilisateur et un mot de passe ou un jeton pour une API REST | Les [expressions REST](../expressions/credentials.html), un jeton de bot Telegram, le bearer token d'un webhook, la clé d'API de l'assistant de chat |
+| Base de données | Un accès à une base de données, avec son type, son hôte, son port et le nom de la base | Les requêtes de formulaire (`dbConfig`) et `fnCredentials` ; il peut être testé |
+| CyberArk | L'adresse du CyberArk Central Credential Provider (CCP) et son TLS, ainsi que l'AppID, le certificat client et la clé avec lesquels se connecte un coffre CyberArk | Un coffre de secrets [CyberArk](../secret-stores/cyberark.html) |
+| SMTP | Un serveur mail, son port et son TLS, et son accès (aucun pour un relais) | Un [canal de notification](../notification-channels.html) mail |
+| LDAP | Les serveurs, le port, le TLS et les certificats d'un annuaire, et son DN et mot de passe de bind | Un [annuaire LDAP](../authentication/ldap.html) |
+| Microsoft Entra ID | L'inscription d'application d'un fournisseur : son ID de tenant, son ID client, son secret client et son URI de redirection | Un [fournisseur Entra ID](../authentication/entra-id.html) |
+| Open ID | Le client d'un fournisseur : son issuer, son ID client, son secret client et son URI de redirection | Un [fournisseur OIDC](../authentication/oidc.html) |
+| RTE | Le jeton (`RTE_TOKEN`) et l'adresse d'un RTE | Un [runner](../runners.html) RTE |
+| AWX, AAP, Ascender | Le jeton ou l'accès, et l'adresse, de cette plateforme | Un runner de ce type |
+| Semaphore, Rundeck | Le jeton d'API et l'adresse de ce produit | Un runner de ce type |
+| Jenkins | Un utilisateur, son jeton d'API et l'adresse d'un Jenkins | Un runner Jenkins |
+| HashiCorp Vault | Le jeton et l'adresse avec lesquels se connecte un coffre Vault | Un coffre de secrets [HashiCorp Vault](../secret-stores/hashicorp-vault.html) |
+
+Un identifiant de base de données peut être de type MySQL, MSSQL, PostgreSQL, Oracle ou MongoDB.
+
+Dans l'API et le [seed de configuration](../seed/), les types sont `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` et `vault`. La mise à jour depuis la 6
+donne à chaque identifiant le type `userpass`, ou `database` pour un identifiant de base de données : un formulaire l'utilise comme dans la 6. Passez-le en SSH pour un
+accès avec lequel se connecte le playbook d'un nœud de workflow, ou en API pour une API REST.
+
+---
+
+## Adresses dans les identifiants
+
+Depuis la 7.3.0, un accès qui fonctionne sur un serveur porte ce serveur, si bien que l'enregistrement qui l'utilise ne fait que nommer l'identifiant :
+
+| Enregistrement | Ce qui est passé dans son identifiant |
+|---|---|
+| Un annuaire LDAP | Ses serveurs, son port, son TLS, ses certificats et son compte de bind, dans un identifiant `ldap` nommé `<directory>-ldap` |
+| Un fournisseur SSO | Son ID client et son secret, son tenant ou son issuer, et son URI de redirection, dans un identifiant `entraid` ou `oidc` nommé `<provider>-sso` |
+| Un runner | Son adresse et son TLS, et son jeton ou son accès, dans un identifiant de son type, `<runner>-token` ou `<runner>-login` |
+| Un coffre de secrets | Son adresse et son TLS, et son jeton (`<store>-token`) ou son AppID et son certificat CyberArk (`<store>-appid`) |
+| Un canal mail | Son serveur, son port et son TLS, dans son identifiant `smtp`, ou un nouveau nommé `<channel>-smtp` |
+
+La mise à jour vers la 7.3.0 effectue ces déplacements une seule fois. Un enregistrement qui nommait déjà un identifiant le conserve, et en reçoit une copie quand
+un autre enregistrement utilisait le même accès avec un autre serveur. Les enregistrements déclarés dans le [seed de configuration](../seed/) sont laissés tels que le seed les définit.
+Les identifiants des connexions et des authentifications ne peuvent être modifiés que par un admin, voir [Qui peut modifier un identifiant](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/fr/_configure/customization/configuration.md b/i18n/fr/_configure/customization/configuration.md
new file mode 100644
index 0000000..6a9f604
--- /dev/null
+++ b/i18n/fr/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Configuration
+parent: Variables d'environnement
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Configuration
+{: .no_toc }
+
+Le seed de configuration, l'endroit où la configuration est conservée, git et ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour décider d'où vient la configuration : un seed de configuration, la base de données, git ou des modèles ytt.
+
+---
+
+## Exemple
+
+Appliquer un seed de configuration monté, le vérifier toutes les cinq minutes, et conserver `config.yaml` dans la base de données. Dans `docker-compose.yml` :
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Un seed invalide empêche le serveur de démarrer. Voir [Seed de configuration](../seed/) pour le format du fichier.
+
+---
+
+## D'où config.yaml est lu
+
+Les catégories, les rôles et les constantes proviennent de `config.yaml` sur le disque ou de sa copie dans la base de données, selon cet ordre :
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), quand elle est définie, dans l'environnement ou dans
+   l'onglet **Configuration** de la page de paramètres : `1` lit la base de données, `0` lit le fichier.
+2. Sinon, la source de configuration stockée dans la base de données (`file` ou `database`), que les instances mises en place
+   avant la 6.3.0 choisissaient sur la page de paramètres.
+3. Sinon, le fichier : le `config.yaml` du dépôt avec **Utiliser pour la configuration** activé, à défaut celui d'un dépôt avec
+   **Utiliser pour les formulaires** activé, à défaut celui de [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Une `ENABLE_CONFIG_IN_DATABASE` définie explicitement l'emporte toujours, même `0` sur un `database` stocké. Elle est lue à chaque chargement de la
+configuration, si bien qu'une modification s'applique sans redémarrage. La page **Statut** montre la source utilisée dans son onglet **Informations**.
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/fr/_configure/customization/features.md b/i18n/fr/_configure/customization/features.md
new file mode 100644
index 0000000..1f245f1
--- /dev/null
+++ b/i18n/fr/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Fonctionnalités
+parent: Variables d'environnement
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Fonctionnalités
+{: .no_toc }
+
+Le concepteur, MCP, le chat, la validation au lancement, la liste des jobs, les métriques, l'API AWX et la journalisation des requêtes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour activer ou désactiver les parties facultatives de l'application.
+
+---
+
+## Exemple
+
+Servir le serveur MCP pour les agents IA et imposer les règles de validation du formulaire à chaque lancement. Dans le `.env` du projet compose :
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` et `ENABLE_CHAT` s'appliquent sans redémarrage : elles sont lues à chaque requête, vous pouvez donc les activer sur la
+page de paramètres. Tant que l'une est désactivée, son endpoint (`/api/v2/mcp` ou `/api/v2/chat`) répond `404`.
+
+Lancez d'abord `LAUNCH_VALIDATION=log` pendant un moment : il journalise ce que `enforce` refuserait sans le refuser. Voir [MCP](../mcp/)
+et [Journaliser et imposer](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/fr/_configure/customization/index.md b/i18n/fr/_configure/customization/index.md
new file mode 100644
index 0000000..f37d7dd
--- /dev/null
+++ b/i18n/fr/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Variables d'environnement
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Variables d'environnement
+{: .no_toc }
+
+Configurez AnsibleForms avec des variables d'environnement
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les administrateurs qui déploient AnsibleForms : les variables d'environnement que lit le serveur, regroupées par thème.
+
+AnsibleForms se règle avec des variables d'environnement, qu'il tourne avec Docker Compose, sur Kubernetes ou depuis les sources.
+
+---
+
+## D'où viennent les valeurs
+
+Le serveur lit chaque variable depuis la première de ces sources qui la définit, si bien qu'une valeur plus haut dans la liste l'emporte toujours :
+
+1. **L'environnement du processus** : `environment:` et `env_file:` dans docker-compose (le `.env` du projet est transmis ainsi),
+   `env` et `envFrom` sur Kubernetes, ou le shell qui lance `node`.
+2. **`persistent/.env`**, le fichier qu'écrivent les pages de paramètres (`data/.env` dans le projet docker-compose, un autre chemin avec
+   `MANAGED_ENV_PATH`). Il est lu à chaque démarrage, en production aussi, et ne remplace jamais une variable déjà définie.
+3. **`server/.env.<NODE_ENV>`**, par exemple `.env.development`. Lu uniquement quand `NODE_ENV` ne vaut pas `production` (ou avec
+   `FORCE_DOTENV=1`), en pratique lors d'une exécution [depuis les sources](../installation/from-source.html) en mode développement.
+4. **La valeur par défaut intégrée**, indiquée dans les tableaux de chaque groupe.
+
+Les pages de paramètres, dans **Paramètres > Général**, affichent la valeur en vigueur et enregistrent les modifications dans `persistent/.env`. Beaucoup de variables
+s'appliquent dès leur enregistrement ; les autres sont enregistrées mais nécessitent un redémarrage, et la page les liste après l'enregistrement. Une variable définie dans
+l'environnement du processus ne peut pas y être modifiée : la page l'affiche comme *Définie dans l'environnement, non modifiable ici.*
+Quelques variables, comme `ENCRYPTION_SECRET` et `ACCESS_TOKEN_SECRET`, ne peuvent jamais être modifiées depuis la page.
+
+Les variables que lit un RTE, comme `AF_ROLE`, `RTE_MODE`, `APP_URL` ou `RTE_MAX_JOBS`, ne figurent pas du tout sur les pages de paramètres :
+l'application ne les utilise pas, définissez-les donc dans l'environnement où tourne le RTE. Les variables `RTE_*` que lit l'application elle-même,
+`RTE_QUEUE_MINUTES` et `RTE_FILES_MAX_MB`, font exception et restent sur les pages. Quatre variables de RTE, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` et `RTE_DRAIN_SECONDS`, peuvent à la place être définies par RTE sur sa page de runner, où une valeur l'emporte sur la
+variable (voir [Les paramètres d'un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Avec [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0`, les pages ne font qu'afficher les valeurs et l'enregistrement est refusé. Utilisez-le
+quand l'environnement est déclaré dans un manifeste, comme décrit dans [Modification et audit](../seed/environment-and-audit.html).
+
+Le [seed de configuration](../seed/) ne définit aucune variable d'environnement. Il déclare des objets qui sont stockés dans la base de données, et les
+références `${ENV_VAR}` qu'il contient sont résolues depuis l'environnement du serveur en cours d'exécution.
+
+Quelques variables ne sont lues que depuis l'environnement et ne figurent pas dans les tableaux : `MANAGED_ENV_PATH` et `FORCE_DOTENV`, décrites
+plus haut, et les variables de proxy système `HTTPS_PROXY` et `NO_PROXY` (lues aussi en minuscules). Un RTE sortant joint l'application via
+`HTTPS_PROXY`, et un RTE entrant y fait passer son appel d'enregistrement, sauf si l'hôte de l'application figure dans `NO_PROXY` (noms d'hôte,
+suffixes `.domain`, ou `*` pour tous les hôtes).
+
+Les variables marquées <span class="af-badge af-badge-secret">Secret</span> contiennent un mot de passe, un jeton ou une clé : gardez-les hors du contrôle
+de version, par exemple dans un Secret Kubernetes ou un fichier `.env` qui n'est pas commité.
+
+---
+
+## Dans cette section
+
+Les variables sont regroupées par thème, avec une page par groupe :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Autres variables
+
+Les variables suivantes ne sont pas encore affectées à un groupe :
+
+{{ other }}
+{% endif %}
diff --git a/i18n/fr/_configure/customization/logging.md b/i18n/fr/_configure/customization/logging.md
new file mode 100644
index 0000000..fe513f2
--- /dev/null
+++ b/i18n/fr/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Journalisation
+parent: Variables d'environnement
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Journalisation
+{: .no_toc }
+
+Niveaux de journalisation, fichiers, syslog et couleurs de la console
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour régler la quantité de journalisation, l'emplacement des fichiers de journaux, ou afficher les horodatages dans votre propre fuseau horaire.
+
+---
+
+## Exemple
+
+Journaliser davantage dans les fichiers que sur la console, et afficher les horodatages des journaux et des jobs à l'heure d'Amsterdam.
+Dans le `.env` du projet compose :
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Les serveurs syslog ne se configurent plus ici : ajoutez-les dans **Paramètres > Connexions > Syslog**, voir [Journaux](../production/logs.html#syslog).
+Les variables `LOG_SYSLOG_*` ci-dessous sont dépréciées depuis la 7. Le premier démarrage qui trouve `LOG_SYSLOG_HOST` défini les importe
+une fois comme serveur syslog `syslog`, qui reçoit le journal du serveur, puis les ignore par la suite.
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/fr/_configure/customization/paths.md b/i18n/fr/_configure/customization/paths.md
new file mode 100644
index 0000000..ae273c9
--- /dev/null
+++ b/i18n/fr/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Chemins
+parent: Variables d'environnement
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Chemins
+{: .no_toc }
+
+Où se trouvent la configuration, les formulaires, les playbooks, les fichiers téléversés et les sauvegardes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour conserver une partie des données sur un autre volume, par exemple les sauvegardes et les fichiers téléversés sur un stockage plus grand ou moins cher.
+
+---
+
+## Exemple
+
+Les sauvegardes et les fichiers téléversés sur un volume séparé, le reste des données dans le dossier persistant habituel. Dans `docker-compose.yml` :
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Un nouveau chemin ne s'applique qu'aux nouveaux fichiers : ce qui se trouve déjà dans l'ancien dossier n'est pas déplacé, copiez-le donc vous-même.
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/fr/_configure/customization/retention.md b/i18n/fr/_configure/customization/retention.md
new file mode 100644
index 0000000..250fdb3
--- /dev/null
+++ b/i18n/fr/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Sauvegardes et conservation
+parent: Variables d'environnement
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Sauvegardes et conservation
+{: .no_toc }
+
+Les commandes de sauvegarde, et la durée de conservation des sauvegardes, des jobs et des entrées d'audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour contrôler la quantité d'historique que conserve la base de données, et le nombre de sauvegardes qui restent sur le disque.
+
+---
+
+## Exemple
+
+Conserver les jobs terminés pendant 90 jours et la piste d'audit pendant deux ans. Dans le `.env` du projet compose :
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Une tâche quotidienne supprime les jobs terminés plus anciens que cela à 2 h 30 et les entrées d'audit à 3 h 30. Un job en cours, ou un job qui attend une
+approbation, n'est jamais supprimé. Les deux variables s'appliquent sans redémarrage quand elles sont modifiées sur la page de paramètres.
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/fr/_configure/customization/security.md b/i18n/fr/_configure/customization/security.md
new file mode 100644
index 0000000..a45f171
--- /dev/null
+++ b/i18n/fr/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Variables de sécurité
+parent: Variables d'environnement
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Variables de sécurité
+{: .no_toc }
+
+Jetons, chiffrement, hôtes REST sortants, masquage et les anciens paramètres VAULT_*
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les pour définir vos propres secrets de jeton et de chiffrement, et pour limiter ce que les formulaires peuvent appeler et afficher.
+
+---
+
+## Exemple
+
+Vos propres secrets, des appels REST limités à une API et à un réseau interne, et une clé masquée de plus. Dans le `.env` du projet compose :
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Définissez `ENCRYPTION_SECRET` avant que le premier identifiant soit stocké. Depuis la 7.3.0, la définir ou la modifier rechiffre tous les secrets
+stockés au démarrage suivant, `ENCRYPTION_SECRET_PREVIOUS` indiquant l'ancienne clé quand c'était la vôtre, voir
+[Changer le secret de chiffrement](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## Appels REST et jq
+
+Depuis la 7.3.0, les fonctions d'aide REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) vérifient le
+certificat de l'endpoint qu'elles appellent, comme toute autre connexion ; jusqu'à la 7.2.0, elles ne le faisaient jamais. Trois paramètres s'y appliquent :
+
+| Variable | Défaut | Effet |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` saute la vérification du certificat : uniquement pour les endpoints avec un certificat auto-signé |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Combien de temps un appel REST attend une réponse avant d'échouer sur un délai dépassé |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Combien de temps un filtre jq peut s'exécuter avant d'être arrêté ; la sortie de jq est aussi plafonnée à 64 Mo |
+
+Les trois prennent effet à l'enregistrement, sans redémarrage. Pour un endpoint dont le certificat est signé par une CA privée, laissez la vérification active
+et fournissez plutôt cette CA à Node.js : définissez `NODE_EXTRA_CA_CERTS` sur un fichier PEM qui la contient dans l'environnement de l'application, puis redémarrez l'application.
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/fr/_configure/customization/server.md b/i18n/fr/_configure/customization/server.md
new file mode 100644
index 0000000..664aaf7
--- /dev/null
+++ b/i18n/fr/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Serveur et base de données
+parent: Variables d'environnement
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Serveur et base de données
+{: .no_toc }
+
+Le serveur web, la connexion MySQL, le compte admin, et ce qu'exécute chaque processus (AF_ROLE et les variables RTE_*)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modifiez-les quand l'application tourne derrière un reverse proxy, sur un autre port, ou avec une base de données hors du projet compose.
+
+---
+
+## Exemple
+
+Derrière un reverse proxy qui termine TLS, sous `/ansibleforms`, avec un MySQL externe. Dans `docker-compose.yml` :
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Elles remplacent les lignes `DB_*` et `PORT` que le fichier compose a déjà à cet endroit, et qui l'emportent sur les mêmes noms dans `.env`. Retirez
+le service `mysqldb` et le `depends_on` qui l'attend, et mappez le port 8000 dans `ports`. Le côté proxy est décrit sur la page
+[Reverse proxy](../production/reverse-proxy.html).
+
+---
+
+## Variables
+
+Toutes les variables de ce groupe, avec leur type, leur valeur par défaut et leur description :
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/fr/_configure/disclaimer.md b/i18n/fr/_configure/disclaimer.md
new file mode 100644
index 0000000..d3506f6
--- /dev/null
+++ b/i18n/fr/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Avertissement
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Avertissement
+{: .no_toc }
+
+Des conditions que chaque utilisateur accepte une fois avant d'utiliser l'application, enregistrées avec qui a accepté quelle version et quand
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : demandez à chaque utilisateur d'accepter des conditions d'utilisation, dans **Paramètres > Accès > Avertissement**, avec l'option de rôle `showSettings`.
+
+Depuis la 7.3.0, la page liste toutes les versions de l'avertissement, et chaque version s'ouvre sur sa propre page avec ses acceptations.
+Jusqu'à la 7.2, la page avait à la place trois onglets (**Général**, **Versions** et **Acceptations**) ; la mise à jour conserve toutes les versions.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Général](disclaimer/general.html) | La liste des versions, l'ajout d'une version, et l'activation de celle qu'acceptent les utilisateurs |
+| [Versions](disclaimer/versions.html) | La page d'une version, et la modification de son texte comme correction ou pour tout le monde à nouveau |
+| [Acceptations](disclaimer/acceptances.html) | Qui a accepté quelle version, et redemander à des utilisateurs choisis |
+
+
+---
+
+## Ce que voient les utilisateurs
+
+Avec une version activée, chaque utilisateur qui se connecte la reçoit dans une boîte de dialogue avant toute chose, admins compris :
+
+1. Il lit son titre et son texte.
+2. Il coche la case, puis clique sur **Accepter**. **Refuser**, en rouge, le déconnecte à la place.
+
+Depuis la 7.3.0, la page derrière la boîte de dialogue est floutée jusqu'à sa réponse.
+
+Un utilisateur accepte chaque version une seule fois : on ne lui redemande pas à sa prochaine connexion, seulement quand une nouvelle version arrive, quand
+un admin enregistre un texte modifié avec [Redemander à tout le monde](disclaimer/versions.html#changing-the-text), ou quand un admin utilise
+[Redemander](disclaimer/acceptances.html#asking-users-again) sur son acceptation.
+
+Tant qu'il n'a pas accepté, l'API répond à chaque appel de sa session avec le statut `403` et le code `disclaimer_required`,
+sauf aux appels sous `/api/v2/disclaimer` et `/api/v2/profile`, et aux événements en direct que suit le navigateur.
+Un [jeton d'API](profile/api-token.html) n'est jamais sollicité, puisqu'un script n'a personne pour cliquer.
+
diff --git a/i18n/fr/_configure/disclaimer/acceptances.md b/i18n/fr/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..729cfc5
--- /dev/null
+++ b/i18n/fr/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Acceptations
+parent: Avertissement
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Acceptations
+{: .no_toc }
+
+Qui a accepté quelle version, et redemander à des utilisateurs choisis
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Qui a accepté
+
+Chaque acceptation est enregistrée pour l'utilisateur et la version, et l'onglet **Acceptations** de la page d'une version les liste, la plus récente en premier :
+
+| Colonne | Signification |
+|---|---|
+| **Utilisateur** | Le nom d'utilisateur |
+| **Connexion** | Comment il s'est connecté : Local, LDAP, Microsoft Entra ID ou OpenID Connect |
+| **Accepté** | Quand |
+| **Adresse IP** | D'où |
+| **Navigateur** | Son navigateur |
+
+---
+
+## Redemander aux utilisateurs
+
+Depuis la 7.3.0, on peut demander à des utilisateurs choisis d'accepter à nouveau une version, sans le redemander à tout le monde.
+
+**Redemander** dans un menu de ligne, ou sur les lignes cochées dans la liste, efface ces acceptations après une confirmation : ces utilisateurs reçoivent à nouveau
+l'avertissement à leur prochaine requête, sans se reconnecter. La liste peut aussi être exportée, comme tout tableau.
+
+Le [journal d'audit](../production/logs.html#audit-trail) enregistre aussi chaque acceptation, chaque refus et chaque modification de l'avertissement.
diff --git a/i18n/fr/_configure/disclaimer/general.md b/i18n/fr/_configure/disclaimer/general.md
new file mode 100644
index 0000000..30b3d86
--- /dev/null
+++ b/i18n/fr/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Général
+parent: Avertissement
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Général
+{: .no_toc }
+
+La liste des versions, l'ajout d'une version, et l'activation de celle qu'acceptent les utilisateurs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La liste
+
+Depuis la 7.3.0, **Paramètres > Accès > Avertissement** est une liste des versions de l'avertissement, une par texte tel qu'il a été accepté :
+
+| Colonne | Signification |
+|---|---|
+| **Activé** | Si c'est la version qu'acceptent les utilisateurs ; une au plus est activée |
+| **Version** | Son numéro, compté à partir de 1 |
+| **Titre** | Le titre de sa boîte de dialogue |
+| **Publiée par** | Qui l'a ajoutée |
+| **Publiée** | Quand |
+| **Acceptations** | Combien d'utilisateurs l'ont acceptée |
+
+Un clic sur une ligne, ou **Modifier** dans le menu de sa ligne, ouvre la [page de la version](versions.html). Le menu propose aussi **Activer** ou **Désactiver**, et **Supprimer**.
+
+---
+
+## Ajouter une version
+
+**Ajouter un avertissement** ouvre une boîte de dialogue pour une nouvelle version, avec le numéro suivant, qui n'est pas activée tant que vous ne l'activez pas :
+
+| Champ | Signification |
+|---|---|
+| **Titre** | Le titre de la boîte de dialogue, comme Conditions d'utilisation |
+| **Texte** | Ce que les utilisateurs acceptent, 20000 caractères au plus. Texte brut : les retours à la ligne sont conservés. |
+| **Case** | Ce que les utilisateurs cochent avant de pouvoir accepter, au départ « J'ai lu et j'accepte ces conditions. » |
+
+Les trois sont obligatoires. La version activée jusque-là reste celle qu'acceptent les utilisateurs, si bien qu'un nouveau texte peut être préparé à l'avance.
+
+---
+
+## Activer une version
+
+**Activer** dans un menu de ligne, ou l'interrupteur **Activé** sur la page de la version, fait de cette version celle qu'acceptent les utilisateurs et désactive les
+autres.
+
+Les utilisateurs qui ont déjà accepté cette version ne sont pas sollicités à nouveau, si bien qu'une version antérieure peut être réactivée sans redemander à tout le monde.
+**Désactiver** sur la version activée désactive l'avertissement jusqu'à ce qu'une version soit de nouveau activée ; les versions et les acceptations restent.
+Supprimer une version supprime aussi ses acceptations, et supprimer la version activée désactive l'avertissement.
diff --git a/i18n/fr/_configure/disclaimer/versions.md b/i18n/fr/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..74ee8ac
--- /dev/null
+++ b/i18n/fr/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versions
+parent: Avertissement
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versions
+{: .no_toc }
+
+La page d'une version, et la modification de son texte comme correction ou pour tout le monde à nouveau
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La page d'une version
+
+Depuis la 7.3.0, chaque version a sa propre page, à `/settings/disclaimer/<version>`, avec deux onglets :
+
+| Onglet | Ce qu'il contient |
+|---|---|
+| **Détails** | Le titre, le texte et le libellé de la case, et l'interrupteur **Activé**, qui est enregistré immédiatement |
+| **Acceptations** | Qui a accepté cette version, voir [Acceptations](acceptances.html) |
+
+**Aperçu** montre la boîte de dialogue telle que la verront les utilisateurs, et **Supprimer** retire la version avec ses acceptations. La zone de recherche au-dessus des
+onglets cherche dans les deux à la fois : les champs correspondants sous **Détails** et les lignes correspondantes sous **Acceptations**.
+
+---
+
+## Modifier le texte
+
+**Enregistrer** sur un titre, un texte ou un libellé de case modifié que des utilisateurs ont déjà accepté demande **Redemander à tout le monde ?** :
+
+| Réponse | Ce qui se passe |
+|---|---|
+| **Redemander à tout le monde** | Les acceptations de cette version sont effacées, et chaque utilisateur l'accepte à nouveau à sa prochaine requête |
+| **Garder comme correction** | Le texte est réécrit, par exemple pour une coquille, et les acceptations comptent toujours : personne n'est sollicité à nouveau |
+
+Une version que personne n'a encore acceptée est enregistrée sans rien demander. Pour conserver le texte accepté, [ajoutez une nouvelle version](general.html#adding-a-version) et activez-la.
diff --git a/i18n/fr/_configure/notification-channels.md b/i18n/fr/_configure/notification-channels.md
new file mode 100644
index 0000000..a277c65
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Canaux de notification
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Canaux de notification
+{: .no_toc }
+
+Envoyez les demandes d'approbation et les notifications de job par mail, vers Slack, Microsoft Teams, Telegram ou n'importe quel webhook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : ajoutez les serveurs mail et les canaux de chat vers lesquels les formulaires envoient leurs notifications et leurs approbations.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Mail](notification-channels/mail.html) | Les serveurs SMTP, celui par défaut, et leur accès |
+| [Slack et Microsoft Teams](notification-channels/slack-and-teams.html) | Un webhook de canal Slack ou Teams |
+| [Telegram](notification-channels/telegram.html) | Un bot qui publie dans un chat Telegram |
+| [Webhook](notification-channels/webhook.html) | Une requête JSON vers n'importe quel endpoint HTTP |
+| [Utiliser les canaux dans un formulaire](notification-channels/in-a-form.html) | Nommer des canaux dans les notifications et les approbations |
+| [Tester un canal](notification-channels/testing.html) | Envoyer un test, et ce que cela prouve |
+
+
+---
+
+## Fonctionnement
+
+Un **canal de notification** est un endroit où vont les notifications, ajouté dans **Connexions > Notifications**. Chaque canal a
+l'un de ces types :
+
+| Type | Ce qu'il envoie |
+|---|---|
+| Mail | Du mail via un serveur SMTP : demandes d'approbation et notifications de job. |
+| Slack | Un message dans un canal Slack, via son webhook entrant, avec un bouton vers le job. |
+| Microsoft Teams | Une carte dans un canal Teams, via un webhook Workflows, avec un bouton vers le job. |
+| Telegram | Un message d'un bot dans un chat Telegram, avec un lien vers le job. |
+| Webhook | Une requête JSON vers n'importe quel endpoint HTTP, construite à partir d'un modèle. |
+
+Un formulaire nomme ses canaux dans ses [notifications](forms/notifications.html) et son [approbation](forms/approval.html),
+avec `channels:`. Une notification qui ne peut pas être envoyée est écrite dans le journal ; elle ne fait jamais échouer le job ni l'approbation.
+
+---
+
+## La page des notifications
+
+La page **Connexions > Notifications** liste chaque canal avec ces colonnes :
+
+| Colonne | Signification |
+|---|---|
+| Activé | Si des notifications lui sont envoyées, voir [Utiliser les canaux dans un formulaire](notification-channels/in-a-form.html). |
+| Nom | Comment les formulaires y font référence dans `channels:`. |
+| Type | Mail, Slack, Microsoft Teams, Telegram ou Webhook. Le canal mail par défaut affiche une pastille **Par défaut** après son type. |
+| Description | À quoi sert le canal. |
+
+**Ajouter un canal de notification** ouvre une boîte de dialogue : **Canal** (nom et description), **Type**, puis les étapes du type
+choisi. Le type est défini à la création du canal et ne change plus. Une ligne ouvre la page du canal, avec les mêmes étapes en
+onglets après **Détails**, et **Envoyer un test**, **Supprimer** et **Enregistrer** en haut à droite. Le menu de ligne propose
+**Modifier**, **Activer** ou **Désactiver** (selon le cas), **Définir par défaut** (mail), **Envoyer un test** et **Supprimer**.
+
+L'onglet **Détails** de la page d'un canal contient l'interrupteur **Activé**, qui est enregistré immédiatement, et pour le mail l'interrupteur **Par défaut**,
+qui est enregistré avec **Enregistrer**.
+
+Un utilisateur qui ouvre ces pages avec `showConnectionsSettings` mais sans le rôle admin ne peut pas choisir un identifiant que seul
+un admin peut nommer, voir [Qui peut modifier un identifiant](credentials.html#who-may-change-a-credential). Quand un tel utilisateur change
+l'endroit où un canal envoie (l'url d'un webhook ou sa vérification de certificat, une adresse de Bot API Telegram), le canal perd
+l'identifiant qu'il nommait, sauf s'il en choisit un dans la même modification.
+
+Un canal déclaré dans le [seed de configuration](seed/) est en lecture seule sur cette page, et peut toujours être testé.
+
diff --git a/i18n/fr/_configure/notification-channels/in-a-form.md b/i18n/fr/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..dbc10bb
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Utiliser les canaux dans un formulaire
+parent: Canaux de notification
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Utiliser les canaux dans un formulaire
+{: .no_toc }
+
+Nommer des canaux dans les notifications et les approbations
+{: .fs-6 .fw-300 }
+
+Les formulaires nomment les canaux par leur nom, dans `notifications` pour le statut et les événements du job, et dans `approval` :
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- Les canaux de chat et de webhook reçoivent un court message (le formulaire, le job, ce qui s'est passé) avec un lien vers le job ; pour une
+  approbation, c'est sur la page du job qu'elle est approuvée ou rejetée.
+- Un canal **mail** dans la liste envoie le mail habituel aux `recipients` (les adresses des `notifications` d'une approbation) via
+  ce serveur au lieu de celui par défaut.
+- Un nom qui n'existe pas, ou un canal de chat ou de webhook désactivé, est ignoré et signalé dans le journal.
+- Un canal **mail** désactivé n'est pas ignoré : le mail passe à la place par le canal mail par défaut, et le
+  journal l'indique.
diff --git a/i18n/fr/_configure/notification-channels/mail.md b/i18n/fr/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..1248c5b
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Mail
+parent: Canaux de notification
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Mail
+{: .no_toc }
+
+Les serveurs SMTP, celui par défaut, et leur accès
+{: .fs-6 .fw-300 }
+
+Un canal mail est un serveur SMTP. Vous pouvez en garder plusieurs ; celui marqué **Par défaut** est le serveur avec lequel l'application envoie son
+mail quand un formulaire ne nomme aucun canal mail. Le premier canal mail devient celui par défaut, et **Définir par défaut** change ce choix.
+
+| Étape | Champ | Signification |
+|---|---|---|
+| Identifiants | Identifiant | Obligatoire. Un identifiant **smtp** de [Connexions > Identifiants](../credentials.html) : le serveur mail, son port et son TLS, et l'accès. Pour un relais sans accès, un identifiant smtp sans utilisateur. |
+| Expéditeur | Expéditeur mail | L'adresse d'expéditeur que voient les destinataires. |
+
+L'interrupteur **Par défaut** de l'onglet **Détails** de la page d'un canal mail en fait celui par défaut, comme le fait **Définir par défaut**.
+Les paramètres mail du seed de configuration sont utilisés tant qu'aucun canal mail n'est celui par défaut, ou tant que celui par défaut est désactivé.
diff --git a/i18n/fr/_configure/notification-channels/slack-and-teams.md b/i18n/fr/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..e35b074
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack et Microsoft Teams
+parent: Canaux de notification
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack et Microsoft Teams
+{: .no_toc }
+
+Un webhook de canal Slack ou Teams
+{: .fs-6 .fw-300 }
+
+Les canaux Slack et Teams n'ont besoin que de l'adresse du webhook du canal :
+
+| Type | Adresse du webhook |
+|---|---|
+| Slack | Le webhook entrant du canal (application Slack > Incoming Webhooks). |
+| Microsoft Teams | Le webhook Workflows du canal (« post to a channel when a webhook request is received »). |
+
+L'adresse est le secret qui permet à n'importe qui de publier dans le canal : elle est stockée chiffrée et n'est plus jamais affichée une fois enregistrée.
diff --git a/i18n/fr/_configure/notification-channels/telegram.md b/i18n/fr/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..e2de0d2
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Canaux de notification
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Un bot qui publie dans un chat Telegram
+{: .fs-6 .fw-300 }
+
+Un canal Telegram est un bot qui publie dans un chat. Son étape **Identifiants** contient le **Jeton du bot**, son étape **Bot** le reste :
+
+| Champ | Signification |
+|---|---|
+| Jeton du bot | Un identifiant **api** de [Connexions > Identifiants](../credentials.html) dont le mot de passe est le jeton du bot fourni par BotFather. |
+| Id du chat | Le chat, le groupe ou le canal dans lequel le bot publie ; un nombre négatif pour un groupe ou un canal. |
+| Adresse de l'API Bot | Un serveur Bot API à vous ; vide pour `api.telegram.org`. |
diff --git a/i18n/fr/_configure/notification-channels/testing.md b/i18n/fr/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..fcdb77e
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Tester un canal
+parent: Canaux de notification
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Tester un canal
+{: .no_toc }
+
+Envoyer un test, et ce que cela prouve
+{: .fs-6 .fw-300 }
+
+**Envoyer un test** envoie une notification de test via le canal tel qu'il est enregistré, enregistrez donc d'abord vos modifications. Cela fonctionne aussi sur un canal
+désactivé. Pour un canal mail,
+la boîte de dialogue demande l'adresse de destination ; les autres publient dans leur propre canal. La boîte de dialogue indique si cela a fonctionné,
+et la raison dans le cas contraire.
diff --git a/i18n/fr/_configure/notification-channels/webhook.md b/i18n/fr/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..854a391
--- /dev/null
+++ b/i18n/fr/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Canaux de notification
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Une requête JSON vers n'importe quel endpoint HTTP
+{: .fs-6 .fw-300 }
+
+Un canal webhook envoie une requête JSON vers n'importe quel endpoint HTTP. Son étape **Point de terminaison** indique où et comment, et son
+étape **Identifiants** contient le **Jeton bearer** :
+
+| Champ | Signification |
+|---|---|
+| Url | L'adresse à laquelle la requête est envoyée. |
+| Méthode | `POST` (par défaut) ou `PUT`. |
+| Jeton bearer | Un identifiant **api** de [Connexions > Identifiants](../credentials.html) dont le mot de passe est envoyé sous la forme `Authorization: Bearer <password>`. Vide : pas de jeton. |
+| Vérifier le certificat TLS | Activé par défaut ; ne le désactivez que pour un endpoint avec un certificat auto-signé. |
+
+{% raw %}
+Son étape **Contenu** contient les **En-têtes**, des en-têtes supplémentaires sous forme d'objet JSON comme `{ "X-Source": "ansibleforms" }`, et le
+**Contenu**, le modèle JSON du corps. Ces placeholders sont remplis :
+
+| Placeholder | Valeur |
+|---|---|
+| `{{title}}` | Le titre de la notification |
+| `{{text}}` | Son texte |
+| `{{status}}` | Le statut du job |
+| `{{event}}` | L'événement du job |
+| `{{jobId}}` | L'id du job |
+| `{{form}}` | Le nom du formulaire |
+| `{{user}}` | L'utilisateur qui a lancé le job |
+| `{{link}}` | Le lien vers le job |
+
+Un placeholder qui constitue une chaîne JSON entière (`"{{text}}"`) est remplacé par la valeur au format JSON ; à l'intérieur d'une chaîne plus longue, son
+texte est échappé pour JSON. Un placeholder inconnu est laissé tel quel. Un contenu vide envoie ce modèle :
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/fr/_configure/production/backups.md b/i18n/fr/_configure/production/backups.md
new file mode 100644
index 0000000..6ebd48c
--- /dev/null
+++ b/i18n/fr/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Sauvegardes
+parent: Exploitation en production
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Sauvegardes
+{: .no_toc }
+
+Les sauvegardes nocturnes, leur contenu, les restaurations, et ce qu'il faut conserver d'autre
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sauvegardes nocturnes
+
+AnsibleForms se sauvegarde chaque nuit à minuit, dans le fuseau horaire de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(UTC par défaut). Ces paramètres la pilotent :
+
+| Variable | Défaut | Signification |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Où les sauvegardes sont écrites, chacune dans un dossier horodaté |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Combien de sauvegardes nocturnes sont conservées, `0` les garde toutes |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | La commande qui fait le dump de la base de données |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | La commande qui rejoue un dump lors d'une restauration |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Combien de temps le dump et la restauration peuvent durer |
+
+Les utilisateurs ayant l'option de rôle `allowBackupOps` peuvent aussi faire une sauvegarde à tout moment sur la page **Sauvegardes**. Seules les sauvegardes
+nocturnes sont supprimées par la conservation, et seules les sauvegardes avec un dump utilisable y sont comptées, si bien qu'une série de nuits
+en échec n'évince jamais la dernière bonne.
+
+Avant qu'une mise à jour ne modifie la base de données, le worker fait d'abord une sauvegarde normale, une fois par version, nommée *Before the upgrade to
+&lt;version&gt;*. Elle apparaît sur la page **Sauvegardes** et n'est jamais supprimée par la conservation nocturne. Si elle échoue (pas d'outil de dump,
+`BACKUP_PATH` non accessible en écriture), la mise à jour s'arrête et explique pourquoi, afin que l'application ne démarre jamais sur une base à moitié mise à jour.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` met à jour sans sauvegarde.
+
+Les commandes peuvent être des wrappers comme `docker exec <container> mysqldump`, si leur premier mot existe localement. Depuis la 7.3.0, elles s'exécutent
+sans shell : les guillemets et `$NAME` provenant de l'environnement de la commande fonctionnent, mais `;`, `|`, `&&`, `>` et `<` sont refusés.
+
+---
+
+## Droits sur la base de données
+
+Le dump s'exécute en tant que [`DB_USER`](../customization/server.html#env_DB_USER), et n'a pas besoin de plus de droits que l'application elle-même :
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Le dump est fait avec `--no-tablespaces`, si bien que le droit `PROCESS` au niveau du serveur n'est pas nécessaire, et il ignore les tables
+qui décrivent les processus en cours (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). La restauration le rejoue avec le même utilisateur.
+La page **Statut** affiche un avertissement sur sa vérification **Utilisateur de la base de données** quand l'utilisateur a des droits sur toutes les bases, comme `root`.
+
+---
+
+## Contenu d'une sauvegarde
+
+Chaque sauvegarde est un dossier sous `BACKUP_PATH`, nommé d'après son horodatage UTC (`YYYYMMDDHHmmss`), qui contient :
+
+| Fichier | Contenu |
+|------|---------|
+| `ansibleforms.sql` | Le dump de la base de données `AnsibleForms` : utilisateurs, groupes, identifiants, jobs, paramètres, la piste d'audit |
+| `config.yaml` | Le fichier situé à [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | Le dossier situé à [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | Le fichier d'environnement qu'écrivent les pages de paramètres, sans `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` ni `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | La description de la sauvegarde |
+
+Une sauvegarde dont le dump échoue est à nouveau supprimée et journalisée comme une erreur. La page **Statut** avertit quand il n'y a aucune sauvegarde,
+quand la plus récente a plus de deux jours, ou quand elle n'a pas de dump utilisable, et elle vérifie que l'outil de dump existe.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) conserve quant à elle les points de restauration du concepteur (60 jours par défaut).
+
+---
+
+## Restaurer une sauvegarde
+
+Restaurez depuis la [page **Sauvegardes**](../gui/administration.html#restore), avec **Créer une nouvelle sauvegarde avant la restauration** coché. Une restauration :
+
+* rejoue `ansibleforms.sql`, qui remplace toute la base de données ; depuis la 7.3.0, une sauvegarde d'une version plus ancienne est ensuite mise à jour
+  à nouveau, comme au démarrage d'une nouvelle version, et un patch qui échoue est signalé
+* recopie `config.yaml`, et remplace le dossier `forms/` par celui de la sauvegarde : depuis la 7.3.0, les formulaires absents de la sauvegarde sont
+  supprimés au lieu d'être conservés, les liens et le mode du dossier restent, et une copie qui échoue remet le dossier dans son état précédent
+* ne restaure **pas** `managed.env`, car il décrit l'hôte d'où provient la sauvegarde. Le bouton **Restaurer l'environnement**
+  le remet en place à la demande, conserve le fichier actuel sous `.env.bak`, et nécessite un redémarrage.
+
+Une sauvegarde sans dump utilisable est refusée ; après une restauration interrompue, corrigez la cause et restaurez à nouveau.
+
+Sur un nouvel hôte, définissez le même `ENCRYPTION_SECRET` avant de restaurer, sinon les identifiants stockés ne pourront pas être déchiffrés.
+
+---
+
+## Quoi sauvegarder d'autre
+
+La sauvegarde nocturne couvre la base de données, la configuration et les formulaires, mais rien d'autre du dossier persistant :
+
+* **`ENCRYPTION_SECRET` et `ACCESS_TOKEN_SECRET`** : jamais dans une sauvegarde, à dessein. Conservez-les dans votre gestionnaire de secrets ;
+  sans le secret de chiffrement, un dump de la base de données est inutilisable pour les identifiants.
+* **les sauvegardes elles-mêmes** : elles se trouvent sur le même volume que l'instance. Copiez `BACKUP_PATH` vers un autre hôte.
+* **le reste du dossier persistant** : playbooks, fichiers téléversés, fichiers de variables, dépôts clonés, certificats et journaux.
+  Avec le projet docker-compose, sauvegardez tout le dossier `data/`, qui contient aussi la clé SSH, les fonctions
+  personnalisées et les rôles et collections Ansible.
+
+Le contenu qui provient de git (dépôts, formulaires dans un dépôt) peut être cloné à nouveau, sa sauvegarde compte donc moins.
diff --git a/i18n/fr/_configure/production/index.md b/i18n/fr/_configure/production/index.md
new file mode 100644
index 0000000..7c982f2
--- /dev/null
+++ b/i18n/fr/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Exploitation en production
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# Exploitation en production
+{: .no_toc }
+
+Publiez, sauvegardez et surveillez une instance dont des personnes dépendent
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avant la mise en service
+
+Les valeurs par défaut permettent de lancer rapidement une instance, mais plusieurs d'entre elles ne servent qu'à un premier aperçu. AnsibleForms
+journalise un avertissement `[SECURITY]` au démarrage quand `ENCRYPTION_SECRET` ou `ACCESS_TOKEN_SECRET` n'est pas défini, et la
+page **Statut** rend compte des sauvegardes, des paramètres de conservation et du filtre d'expressions.
+
+---
+
+## Liste de contrôle de production
+
+Passez ces points en revue une fois avant que des utilisateurs dépendent de l'instance, puis à nouveau après une mise à jour majeure :
+
+| Point | Que faire | Détails |
+|------|------------|---------|
+| Mot de passe admin | Changez le mot de passe du compte admin local | [Renforcement](../security/hardening.html#the-admin-account) |
+| Secret de chiffrement | Définissez [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) avant de stocker le moindre identifiant | [Secrets et chiffrement](../security/secrets.html#the-two-master-secrets) |
+| Secret des jetons | Définissez [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET), pour que les sessions survivent à un redémarrage | [Secrets et chiffrement](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Terminez TLS avec votre propre certificat, pas celui d'exemple | [HTTPS](../security/https.html) |
+| Reverse proxy | Publiez l'instance derrière un proxy, éventuellement sous [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse proxy](reverse-proxy.html) |
+| Endpoint de schéma | Mettez [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) à `0` une fois le schéma créé | [Renforcement](../security/hardening.html#the-database) |
+| Appels sortants | Restreignez les expressions REST avec [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Renforcement](../security/hardening.html#expressions-and-outbound-calls) |
+| Fonctionnalités facultatives | Laissez MCP et l'assistant de chat désactivés sauf si vous les utilisez | [Renforcement](../security/hardening.html#optional-features) |
+| Sauvegardes | Vérifiez que la sauvegarde nocturne fonctionne, et copiez-la hors de l'hôte | [Sauvegardes](backups.html) |
+| Conservation | Décidez combien de temps les jobs et les entrées d'audit sont conservés | [Journaux](logs.html#retention) |
+
+---
+
+## Dans cette section
+
+Chaque thème a sa propre page ; la sécurisation de l'instance est traitée dans [Sécurité](../security/) :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Reverse proxy](reverse-proxy.html) | Publier AnsibleForms derrière Nginx, Traefik ou Apache, à la racine ou sous un sous-chemin |
+| [Sauvegardes](backups.html) | Les sauvegardes nocturnes, leur contenu, les restaurations, et ce qu'il faut conserver d'autre |
+| [Journaux](logs.html) | Les fichiers de journaux, syslog, la piste d'audit, et la conservation des jobs et des entrées d'audit |
+| [Mise à l'échelle](scaling.html) | Plusieurs nœuds d'application avec un worker ; le RTE a sa propre section, [Environnements d'exécution](../rte/) |
+| [Supervision](monitoring.html) | Les sondes de santé, les métriques Prometheus et la page Statut |
diff --git a/i18n/fr/_configure/production/logs.md b/i18n/fr/_configure/production/logs.md
new file mode 100644
index 0000000..69e08ca
--- /dev/null
+++ b/i18n/fr/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Journaux
+parent: Exploitation en production
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Journaux
+{: .no_toc }
+
+Les fichiers de journaux, syslog, la piste d'audit, et la durée de conservation des jobs et des entrées d'audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fichiers de journaux
+
+AnsibleForms écrit deux journaux à rotation quotidienne dans [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), compresse les jours plus anciens et les conserve pendant [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+(30 par défaut, `0` garde tous les fichiers ; une modification sur la page de paramètres s'applique immédiatement) :
+
+* `ansibleforms.<date>.log` : tout ce qui est au niveau [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) et au-dessus
+* `ansibleforms.errors.<date>.log` : les erreurs uniquement
+
+La console, lue avec `docker logs` ou `kubectl logs`, a son propre niveau,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Les deux valent `notice` par défaut, ce qui convient à la
+production ; n'utilisez `info` ou `debug` que pendant un dépannage, et laissez
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) désactivée. Les niveaux peuvent être modifiés sur
+les pages de paramètres sans redémarrage, et la page **Journal du serveur** montre le journal aux utilisateurs ayant l'option `showLogs`.
+
+---
+
+## Lignes JSON
+
+Pour un collecteur de journaux comme Loki, ELK ou Splunk, mettez [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) à `json`. Chaque
+ligne, sur la console et dans les fichiers, est alors un objet JSON au lieu de `<time> <level>: <message>` :
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Champ | Contenu |
+|-------|---------|
+| `time` | L'heure, en ISO 8601 UTC |
+| `level` | Le niveau de journalisation |
+| `message` | Le message |
+| `requestId` | La requête à laquelle appartient la ligne, quand elle a été écrite pendant le traitement d'une requête |
+| `role` | Le rôle du processus, [`AF_ROLE`](scaling.html), ou `all` quand il n'est pas défini |
+| `host` | Le nom d'hôte de la machine ou du conteneur où tourne le processus |
+
+Chaque requête reçoit un id : l'en-tête `X-Request-Id` qu'a envoyé un reverse proxy, ou un nouveau. Il est renvoyé dans l'en-tête
+`X-Request-Id` de la réponse et porté par chaque ligne écrite pendant le traitement de la requête (sous la forme `[req <id>]` dans les lignes texte),
+si bien qu'une requête peut être suivie à travers le journal et rapprochée de celle du proxy. Une modification sur la page de paramètres s'applique immédiatement.
+
+---
+
+## Syslog
+
+Les serveurs syslog se gèrent dans **Paramètres > Connexions > Syslog**, afin qu'un serveur syslog ou un SIEM reçoive le journal au fil de son écriture.
+Vous pouvez ajouter plusieurs serveurs, et chacun a ses propres paramètres :
+
+| Paramètre | Ce qu'il fait |
+|---------|--------------|
+| Activé | Seuls les serveurs activés reçoivent quelque chose, un serveur peut donc être mis en pause sans être supprimé ; **Activer** et **Désactiver** dans son menu de ligne le basculent aussi |
+| Protocole | `udp4` (par défaut), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` ou `unix-connect` |
+| Hôte et port | Le serveur de destination, port `514` par défaut ; un protocole `unix` prend à la place un chemin de socket |
+| Reçoit | Le journal du serveur, les entrées d'audit, ou les deux (par défaut pour un nouveau serveur) |
+| Niveau | Le niveau le plus bas du journal du serveur qu'il reçoit, `info` par défaut ; les entrées d'audit sont toujours envoyées |
+| Type | `BSD` (RFC 3164, par défaut) ou `RFC 5424` |
+
+Une modification s'applique sur chaque nœud sans redémarrage, et la page du serveur a un bouton qui lui envoie un message de test.
+Un serveur injoignable n'arrête jamais l'application : l'erreur est écrite sur la console.
+
+Depuis la 7.3.0, les serveurs syslog nécessitent les droits complets sur les paramètres, l'option de rôle [`showSettings`](../config/roles.html#role-options) :
+l'accès aux seuls paramètres de connexions ne suffit pas, car un serveur syslog reçoit le journal du serveur et les entrées d'audit.
+
+Les variables `LOG_SYSLOG_*` des versions précédentes sont dépréciées depuis la 7. Le premier démarrage qui trouve
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) définie les importe une fois comme serveur `syslog`,
+qui reçoit le journal du serveur comme avant, puis les ignore par la suite. Retirez-les de l'environnement après ce premier
+démarrage, et gérez le serveur sur la page de paramètres.
+
+---
+
+## Piste d'audit
+
+La page **Journal d'audit** (dans **Paramètres > Journaux**) enregistre qui a modifié quoi, ce à quoi les fichiers de journaux répondent mal.
+Elle enregistre :
+
+* chaque modification faite via l'API (`POST`, `PUT`, `PATCH`, `DELETE`), y compris les tentatives refusées avec 401 ou 403
+* les connexions, avec le nom d'utilisateur essayé
+* les événements de l'application elle-même, comme les sauvegardes nocturnes, les sauvegardes supprimées, les jobs purgés et les applications du seed de configuration
+
+Chaque entrée a son heure, l'acteur (un utilisateur, ou l'application elle-même pour ses propres tâches), l'adresse IP du client,
+l'action, sa cible et son résultat : `success`, `failure` ou `denied`. La page filtre sur l'acteur, l'action et
+le résultat, et les utilisateurs ayant l'option de rôle `showSettings` peuvent l'ouvrir.
+
+L'adresse IP est celle que voit AnsibleForms, c'est-à-dire celle du proxy quand il tourne derrière un proxy. Mettez
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) au nombre ou aux adresses de vos proxies, et AnsibleForms
+enregistre à la place l'adresse du client que le proxy indique dans `X-Forwarded-For` ; voir [Reverse proxy](reverse-proxy.html).
+
+Pour conserver la piste d'audit hors de l'instance, pour un SIEM, ajoutez un serveur syslog qui reçoit les entrées d'audit (voir
+[Syslog](#syslog)). Chaque entrée est envoyée au moment où elle se produit, sous la forme d'une ligne `audit {...}` contenant l'entrée en JSON, quel que soit le
+niveau du serveur. La copie syslog n'est ni supprimée par la conservation ci-dessous, ni remplacée par une restauration de la base de données.
+
+---
+
+## Conservation
+
+Deux tâches quotidiennes avec un paramètre empêchent la base de données de grossir sans limite :
+
+| Variable | Défaut | S'exécute à | Supprime |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Les entrées d'audit plus anciennes que cela |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (tout garder) | 2:30 | Les jobs terminés plus anciens que cela, avec leur sortie |
+
+`0` garde tout pour les deux. Deux autres tâches quotidiennes n'ont pas de paramètre : à 3:00, les refresh tokens stockés de plus de 30 jours et
+les révocations de jetons expirées sont supprimés, et à 4:00 les [jobs enregistrés](../jobs/stored-jobs.html) dont l'échéance est passée.
+Les heures sont dans le fuseau horaire de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), et c'est le worker qui exécute ces tâches.
+
+La sortie des jobs est généralement la table qui grossit le plus vite : la page **Statut** indique sa taille
+et avertit quand elle dépasse 1 Go sans conservation définie. Les jobs en cours et les jobs en attente d'approbation ne sont jamais supprimés.
+Choisissez une conservation des jobs qui corresponde à vos exigences d'audit, et gardez la piste d'audit au moins aussi longtemps.
diff --git a/i18n/fr/_configure/production/monitoring.md b/i18n/fr/_configure/production/monitoring.md
new file mode 100644
index 0000000..dcd5065
--- /dev/null
+++ b/i18n/fr/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Supervision
+parent: Exploitation en production
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Supervision
+{: .no_toc }
+
+Les sondes de santé pour un répartiteur de charge ou Kubernetes, les métriques Prometheus, et la page Statut
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sondes de santé
+
+Deux endpoints indiquent à un répartiteur de charge, à un healthcheck de conteneur ou à Kubernetes si un processus peut recevoir du trafic.
+Aucun ne nécessite de connexion, et aucun ne renvoie quoi que ce soit sur la configuration :
+
+| Endpoint | Répond | À utiliser pour |
+|----------|---------|------------|
+| `/api/v2/live` | `200` avec `{"status":"live"}` tant que le processus tourne | Une sonde de vivacité (liveness) : redémarrer le processus quand il ne répond plus |
+| `/api/v2/ready` | `200` avec `{"status":"ready"}`, ou `503` avec `{"status":"not ready","reason":"..."}` | Une sonde de disponibilité (readiness) : n'envoyer du trafic qu'aux processus prêts |
+
+Un processus est prêt quand toutes ces conditions sont réunies :
+
+* il n'est pas en cours d'arrêt (`stopping`)
+* la base de données répond (`database unreachable`)
+* le schéma existe (`schema not provisioned`) et est complet, avec chaque table, colonne et index de cette version
+  (`schema not upgraded`) ; cette dernière vérification est mise en cache 30 secondes, si bien qu'une sonde toutes les quelques secondes reste peu coûteuse
+
+Sous un [`BASE_URL`](../customization/server.html#env_BASE_URL), les chemins commencent par celui-ci, par exemple
+`/ansibleforms/api/v2/ready`. Un environnement d'exécution (RTE) répond aux mêmes sondes sur `/live` et `/ready`, sans la
+vérification de complétude du schéma ; il n'est pas prêt pendant qu'il vide ses jobs à l'arrêt, si bien qu'aucun nouveau job ne lui est envoyé. Un RTE sortant
+n'est pas non plus prêt (`not connected to the app`) tant que son socket vers l'application n'est pas ouvert.
+Un processus démarré avec `AF_ROLE=worker` n'a pas d'interface web : il ne répond qu'à `/api/v2/version` et `/health` pour le healthcheck
+de son conteneur. Voir [Mise à l'échelle](scaling.html) pour les rôles.
+
+---
+
+## Métriques Prometheus
+
+Mettez [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) à une longue chaîne aléatoire pour servir des métriques Prometheus.
+Un processus qui sert l'application web répond sur `/api/v2/metrics`, un RTE sur `/metrics` :
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Sans `METRICS_TOKEN`, les endpoints répondent `404`, comme s'ils n'existaient pas, et une requête sans le bon en-tête
+`Authorization: Bearer <token>` reçoit `401`. Chaque processus rapporte ses propres chiffres, collectez donc chacun d'eux :
+
+| Métrique | Ce qu'elle mesure |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | Le processus : CPU, mémoire, latence de la boucle d'événements, ramasse-miettes |
+| `af_http_requests_total{route,method,status}` | Les requêtes servies |
+| `af_http_request_duration_seconds{route}` | Leur durée |
+| `af_jobs{status}` | Les jobs en cours (`running`) ou en attente d'approbation (`approve`) en ce moment |
+| `af_jobs_ended_24h{status}` | Les jobs terminés au cours des dernières 24 heures, par statut |
+| `af_nodes{role,alive}` | Les processus enregistrés dans la base de données, par rôle, vivants ou non |
+| `af_login_failures_total`, `af_login_lockouts_total` | Les connexions échouées et les verrouillages de compte |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Sur un RTE : les playbooks qu'il exécute en ce moment, et combien il peut en exécuter à la fois |
+| `af_rte_socket_connected` | Sur un RTE en mode socket : `1` tant que son socket vers l'application est ouvert, `0` sinon |
+
+Les chiffres des jobs et des nœuds sont lus dans la base de données à chaque collecte. Quand la base de données ne répond pas, ils sont
+omis, et la collecte réussit quand même avec les autres métriques.
+
+---
+
+## La page Statut
+
+La page **Statut**, dans **Paramètres > Système**, montre aux utilisateurs ayant l'option de rôle `showSettings` l'état de l'instance.
+Elle ne fait que lire, si bien que l'actualiser n'envoie jamais de mail et ne lance jamais de job. Elle a deux onglets, et le nombre de problèmes s'affiche sur le libellé de l'onglet **Vérifications**.
+
+### Vérifications
+
+Chaque vérification est verte (sain), orange (attention requise) ou rouge (un problème), avec ses détails en dépliant la ligne :
+
+| Vérification | Ce qu'elle examine |
+|-------|------------------|
+| Connexion à la base de données | La base de données répond |
+| Utilisateur de la base de données | Orange quand l'utilisateur a des droits sur toutes les bases, comme `root`, au lieu de `AnsibleForms.*` uniquement |
+| Schéma de base de données | Chaque table, colonne et index de cette version existe, et quel patch a échoué sinon |
+| Planificateur | Un worker exécute les tâches système, et aucune d'elles n'a cessé d'être planifiée |
+| Nœuds | Les processus dans la base de données, orange quand ils exécutent des versions différentes |
+| Tâches | Les jobs en cours et les jobs en attente d'approbation, orange quand un job tourne depuis plus de 24 heures |
+| Outils de sauvegarde | La commande de dump de [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) existe, et sa version |
+| Dernière sauvegarde | Orange quand il n'y en a aucune ou que la plus récente a plus de deux jours, rouge quand elle n'a pas de dump utilisable |
+| Verrou du designer | Qui détient le verrou du concepteur, orange quand il est détenu depuis plus de 8 heures |
+| Dépôts | Rouge quand un dépôt a échoué ou n'a pas d'arbre de travail sur le disque |
+| Seed de configuration | Le fichier de [seed de configuration](../seed/) est lisible et s'analyse, et son dernier rechargement a fonctionné |
+| Coffres de secrets | Chaque coffre de secrets répond, orange quand le jeton d'un HashiCorp Vault expire bientôt |
+| Runners | Chaque runner répond, orange quand il n'y en a aucun ou aucun RTE par défaut |
+| Expressions serveur | Orange quand [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) vaut `legacy` |
+| Secrets | Orange quand `ENCRYPTION_SECRET` est la valeur publique par défaut ou que `ACCESS_TOKEN_SECRET` n'est pas défini |
+| LDAP | Le serveur LDAP est joignable et son certificat TLS est valide, sans s'y connecter |
+| Stockage des tâches | La taille des tables de jobs, orange au-delà de 1 Go quand aucune conservation des jobs n'est définie |
+| Dossiers accessibles en écriture | Chaque dossier configuré est accessible en écriture |
+| Espace disque | Le disque qui contient les sauvegardes, orange à partir de 85 % d'occupation et rouge à partir de 95 % |
+
+### Informations
+
+Des faits sur l'instance sans verdict, les premières choses que demande un échange avec le support : la version
+d'AnsibleForms, l'URL de base, la version et l'hôte de la base de données, la source de configuration, le seed de configuration, les paramètres
+de conservation, les méthodes d'authentification, le serveur du [canal mail](../notification-channels.html) actif, le niveau
+et le chemin des journaux, le temps de fonctionnement, le fuseau horaire, la version de Node.js et la plateforme.
+
+La page lit `/api/v2/health`, qui nécessite un utilisateur connecté avec `showSettings`. Pour un système de supervision, utilisez plutôt les
+sondes et les métriques ci-dessus.
diff --git a/i18n/fr/_configure/production/reverse-proxy.md b/i18n/fr/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..e9c7bd6
--- /dev/null
+++ b/i18n/fr/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse proxy
+parent: Exploitation en production
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse proxy
+{: .no_toc }
+
+Publiez AnsibleForms derrière Nginx, Traefik ou Apache, à la racine ou sous un sous-chemin
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quand en utiliser un
+
+AnsibleForms sert l'interface, l'API REST et Swagger sur un seul port ; un reverse proxy placé devant vous permet de :
+
+* le servir sur le port 443 avec un certificat géré par vos outils existants (ACME, une CA d'entreprise)
+* partager un nom d'hôte avec d'autres applications, en publiant AnsibleForms sous un sous-chemin
+* garder le port de l'application et la base de données hors du réseau public
+
+Un proxy est facultatif : l'application peut servir HTTPS elle-même, voir [HTTPS](../security/https.html).
+
+---
+
+## Les paramètres qui comptent
+
+Seuls quelques paramètres influent sur le comportement d'AnsibleForms derrière un proxy :
+
+| Paramètre | Derrière un proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | Le port vers lequel le proxy transfère, `8000` par défaut. Le projet docker-compose le met à `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` quand le proxy termine TLS et joint l'application via un réseau privé, `1` pour chiffrer aussi ce saut. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | Le sous-chemin, par exemple `/ansibleforms`. Laissez-le à `/` quand l'application a son propre nom d'hôte. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Quels proxies peuvent indiquer l'adresse du client dans `X-Forwarded-For`, généralement `1`. Voir [Adresses des clients](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | La plus grande requête JSON qu'accepte l'application, 50 Mo par défaut. Le proxy doit autoriser au moins cela. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | Le plus gros fichier qu'accepte un champ de téléversement de formulaire, 10 Go par défaut. Le proxy doit l'autoriser aussi, sinon les téléversements y échouent. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | Le plus grand ensemble d'en-têtes de requête qu'accepte l'application, 16 Ko par défaut, depuis la 7.1.0. Voir [Taille des en-têtes de requête](#request-header-size). |
+| **URL racine publique** | Dans **Système > Général**, onglet **Serveur** : l'adresse à laquelle accèdent les utilisateurs, sous-chemin compris. Elle construit les liens des mails de notification, des messages de canal et des demandes d'approbation. |
+
+Pour Entra ID ou OIDC, inscrivez l'adresse publique comme URI de redirection, avec le sous-chemin de `BASE_URL` s'il est défini.
+
+---
+
+## Servir sous un sous-chemin
+
+`BASE_URL` monte toute l'application sous le sous-chemin ; le proxy doit transférer le chemin **inchangé**.
+Avec `BASE_URL=/ansibleforms` :
+
+* l'interface, `/api/v2/...` et l'interface Swagger sont toutes servies sous `/ansibleforms/`
+* le `<base href>` de l'interface est réécrit au démarrage, si bien que les ressources et les appels d'API se résolvent sous le sous-chemin
+* une requête vers `/` ou vers `/ansibleforms` (sans barre oblique finale) est redirigée vers `/ansibleforms/`
+
+Gardez le préfixe : pas de `StripPrefix` dans Traefik, pas d'URI sur `proxy_pass` dans Nginx, car l'application l'attend.
+
+La page **Statut** montre l'URL de base en vigueur.
+
+---
+
+## Délais, téléversements et sortie en direct
+
+La page des jobs et les compteurs de jobs apprennent les changements via un flux de server-sent events de longue durée,
+[`/api/v2/events`](../api/events.html), maintenu ouvert par navigateur. Le flux envoie des en-têtes qui désactivent la mise en tampon du proxy
+(`X-Accel-Buffering: no`) et une ligne keep-alive toutes les 15 secondes, si bien que le délai de lecture habituel de 60 secondes le garde ouvert ;
+quand un proxy le ferme malgré tout, le navigateur se reconnecte tout seul. La sortie sous un formulaire, juste après un lancement, est
+lue à la place toutes les deux secondes. Le lancement d'un job revient dès que le job est créé, si bien qu'un long playbook ne garde pas
+une requête ouverte.
+
+Les requêtes qui peuvent durer longtemps sont :
+
+* **la sauvegarde et la restauration** depuis la page **Sauvegardes**, qui attendent la fin de la commande de dump ou de restauration, jusqu'à
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (3600 par défaut)
+* **les gros téléversements** via un champ fichier, qui transmettent tout le fichier en une seule requête
+* **les messages de chat**, quand l'[assistant de chat](../chat/) est activé, qui attendent la réponse du fournisseur du modèle
+
+Les proxies expirent souvent au bout de 60 secondes et plafonnent les corps de requête (Nginx accepte 1 Mo par défaut). Augmentez les deux pour
+les routes d'AnsibleForms, comme dans les exemples ci-dessous.
+
+---
+
+## WebSockets des runners
+
+Depuis la 7.3.0, un [Runner sortant](../rte/modes.html#outbound) contacte l'application et garde un WebSocket ouvert sur
+`<BASE_URL>/api/v2/rte/socket`. Le proxy doit transmettre l'upgrade, sinon le Runner ne se connecte jamais et continue de rappeler :
+
+| Proxy | Ce dont le WebSocket a besoin |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` et les en-têtes `Upgrade` et `Connection`, que Nginx ne transmet pas par défaut |
+| Traefik | Rien : les WebSockets passent tels quels |
+| Apache | `upgrade=websocket` sur la ligne `ProxyPass` (2.4.47 et ultérieures), ou `mod_proxy_wstunnel` avant |
+
+Les deux extrémités envoient un ping toutes les 20 secondes, si bien que le délai de lecture habituel de 60 secondes garde ouvert un socket inactif.
+
+---
+
+## Taille des en-têtes de requête
+
+Chaque requête porte le jeton de connexion dans son en-tête `Authorization`, à côté des cookies et des en-têtes qu'ajoute le proxy.
+Le proxy comme l'application plafonnent la taille des en-têtes de requête, et refusent une requête au-delà du plafond avant
+qu'AnsibleForms ne la voie, si bien que rien n'atteint le journal du serveur. Les valeurs par défaut :
+
+| Composant | Limite | Défaut | Refusée avec |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), tous les en-têtes ensemble | 16384 octets | 431 |
+| Nginx | `large_client_header_buffers`, par champ d'en-tête | `4 8k` : 8 Ko par champ | 400 |
+| Traefik | `http.maxHeaderBytes` du point d'entrée, tous les en-têtes ensemble | 1 Mo | 431 |
+| HAProxy | `tune.bufsize` dans la section `global`, tout le bloc d'en-têtes, moins la réserve `tune.maxrewrite` (1024 octets) | 16384 octets : 15360 octets d'en-têtes | 400 |
+| Apache | `LimitRequestFieldSize`, par champ d'en-tête | 8190 octets | 400 |
+
+Jusqu'à la 7.0.3, le jeton de connexion portait tous les groupes d'un utilisateur en authentification unique, et pouvait dépasser ces limites, voir
+[Formulaires et jobs vides après une authentification unique](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Depuis la 7.1.0, le jeton reste petit, et les valeurs par défaut suffisent. Quand autre chose fait grossir les en-têtes, comme
+les cookies d'autres applications sur le même domaine ou une passerelle d'authentification unique placée devant, augmentez les limites ensemble :
+
+* AnsibleForms : `MAX_HTTP_HEADER_SIZE=65536`, ou avant la 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536` ; les deux sont
+  lues au démarrage, redémarrez donc l'application après une modification
+* Nginx : `large_client_header_buffers 4 32k;` dans le bloc `http` ou `server`
+* HAProxy : `tune.bufsize 65536` dans la section `global` ; chaque flux reçoit un tampon de cette taille, HAProxy conseille donc
+  de diminuer le `maxconn` global du même facteur, et HTTP/2 nécessite au moins la valeur par défaut de 16384
+* Apache : `LimitRequestFieldSize 32768` dans la configuration du serveur ou dans l'hôte virtuel
+
+---
+
+## Adresses des clients
+
+Derrière un proxy, chaque connexion vient du proxy. Sans [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY),
+la piste d'audit enregistre l'adresse du proxy pour chaque action, et les
+[limites de connexion](../security/hardening.html#sign-in-limits-and-passwords) par adresse comptent tous les clients comme une seule adresse.
+`TRUST_PROXY` indique quels proxies l'application peut croire quand ils indiquent le client dans `X-Forwarded-For` :
+
+| Valeur | Adresse du client |
+|-------|----------------|
+| `0` (par défaut) | L'adresse de la connexion. `X-Forwarded-For` est ignoré ; vide, `false`, `off` et `no` signifient la même chose. |
+| Un nombre, par ex. `1` | Fait confiance à autant de proxies devant l'application : `1` pour un seul reverse proxy, `2` pour un répartiteur de charge devant un ingress. |
+| Une liste, par ex. `10.0.0.5,172.16.0.0/12` | Fait confiance aux proxies situés à ces adresses et plages CIDR. Les préréglages `loopback`, `linklocal` et `uniquelocal` sont aussi acceptés. |
+| `true` | Fait confiance à chaque saut : l'adresse la plus à gauche de `X-Forwarded-For` est utilisée. |
+
+L'application parcourt `X-Forwarded-For` depuis la droite, saute les proxies de confiance, et prend la première adresse qui n'en
+fait pas partie. Utilisez le nombre exact de proxies, ou leurs adresses :
+
+* `X-Forwarded-For` est un simple en-tête de requête que n'importe quel client peut envoyer. Un nombre trop élevé, ou `true`, permet à un
+  client de choisir l'adresse qu'enregistre la piste d'audit. `true` n'est sûr que lorsque l'application n'est joignable qu'à travers
+  le proxy, et le serveur journalise un avertissement `[SECURITY]` au démarrage quand il est défini.
+* Le proxy doit ajouter l'adresse depuis laquelle il a reçu la connexion, comme le font les exemples ci-dessous
+  (`$proxy_add_x_forwarded_for` dans Nginx ; Traefik et Apache `mod_proxy` l'ajoutent par défaut).
+* Une valeur invalide est refusée sur la page de paramètres ; définie dans l'environnement, elle est journalisée comme une erreur au démarrage et
+  aucun proxy n'est considéré de confiance. Une modification enregistrée sur la page de paramètres s'applique sans redémarrage.
+
+---
+
+## Exemples
+
+Chaque exemple publie AnsibleForms à `https://forms.example.com/ansibleforms/`, avec TLS terminé par le proxy et
+l'application tournant avec `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` et `TRUST_PROXY=1` :
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` ne nomme aucune URI, Nginx transfère donc le chemin tel qu'il est arrivé, préfixe compris. Le bloc `map` se place dans le
+contexte `http` (un fichier sous `conf.d/` y est inclus), et transmet l'upgrade WebSocket des Runners :
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Sans sous-chemin, utilisez `location /` et laissez `BASE_URL` non défini.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Des labels sur le service `app` du projet docker-compose, avec Traefik sur le même réseau Docker. Le service
+ne publie aucun port propre, Traefik le joint sur le réseau :
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Il n'y a volontairement pas de middleware `StripPrefix`. Traefik définit lui-même les en-têtes `X-Forwarded-*` et ne plafonne pas
+la taille du corps, mais vérifiez les `respondingTimeouts` du point d'entrée quand les sauvegardes ou les téléversements durent plus longtemps que son
+délai de lecture. Sans sous-chemin, ne gardez que la partie `Host(...)` de la règle.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Nécessite `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl`, et Apache 2.4.47 ou ultérieur pour le `upgrade=websocket` des Runners.
+Les deux côtés de `ProxyPass` portent le préfixe :
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Sans sous-chemin, faites pointer `/` vers `http://10.0.0.20:8000/` et laissez `BASE_URL` non défini.
+
+</div>
+</div>
+
+Pour garder chiffré le saut entre le proxy et l'application, exécutez l'application avec `HTTPS=1`, pointez le proxy vers
+`https://`, et donnez à l'application un certificat auquel le proxy fait confiance, voir [HTTPS](../security/https.html).
diff --git a/i18n/fr/_configure/production/scaling.md b/i18n/fr/_configure/production/scaling.md
new file mode 100644
index 0000000..334f399
--- /dev/null
+++ b/i18n/fr/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Mise à l'échelle
+parent: Exploitation en production
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Mise à l'échelle
+{: .no_toc }
+
+AnsibleForms réparti sur plusieurs nœuds d'application et un worker, à côté d'un ou plusieurs RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rôles
+
+Chaque conteneur AnsibleForms exécute le même code serveur, et [`AF_ROLE`](../customization/server.html#env_AF_ROLE) décide de ce qu'il fait :
+
+| `AF_ROLE` | Image | Exécute | Combien |
+|---|---|---|---|
+| `all` (non défini) | `ansibleforms` | L'application web et le worker dans un seul processus : le choix par défaut | 1 |
+| `app` | `ansibleforms` | L'interface web et l'API | Autant que vous voulez, derrière un répartiteur de charge |
+| `worker` | `ansibleforms` | Le travail en arrière-plan : le schéma de la base de données et ses mises à jour, le seed de configuration, les planifications, la sauvegarde nocturne, les synchronisations de dépôts et les nettoyages | Un seul au travail ; les autres attendent et prennent le relais |
+| `rte` | `ansibleforms-rte-full` (ou `-rte-core`, `-rte-base`) | Les playbooks | Autant que vous voulez |
+
+La plus petite installation est un conteneur sans `AF_ROLE` à côté d'un RTE : c'est ce qu'exécutent le [projet Docker Compose](../installation/docker-compose.html)
+et le [chart Helm](../installation/kubernetes.html). Toute autre valeur d'`AF_ROLE` arrête le processus dès son démarrage.
+
+---
+
+## Le RTE
+
+Le RTE, l'environnement d'exécution qui exécute les playbooks, a sa propre section : [Environnements d'exécution](../rte/). Elle explique comment un RTE
+exécute un job, [ses images](../rte/images.html), [comment en exécuter un](../rte/run.html), [plusieurs RTE](../rte/several.html) comme runners ou
+répliques, et [un RTE dans un autre datacenter](../rte/another-datacenter.html).
+
+---
+
+## Plusieurs nœuds d'application
+
+Pour servir plus d'utilisateurs, ou survivre à la perte d'un nœud, répartissez l'application en nœuds `app` derrière un répartiteur de charge et un `worker`.
+
+### Ce que partagent les nœuds
+{: .no_toc }
+
+Les nœuds se coordonnent via la base de données et un volume partagé :
+
+* **La base de données** : les jobs, le verrou du worker, le verrou du concepteur, la liste des nœuds, les baux des runners (quel nœud d'application détient le
+  socket de chaque RTE) et les avis de modification qui gardent à jour les caches de chaque nœud. Un identifiant, un runner ou une planification modifiés
+  sur un nœud sont en vigueur sur tous en moins de 5 secondes
+* **Le volume persistant** (`/app/dist/persistent`) : formulaires, config, dépôts, fichiers téléversés, sauvegardes et le `.env` géré.
+  Chaque nœud d'application et le worker montent le même, en lecture-écriture
+* **Le dossier ssh** (`/home/node/.ssh`) : la clé et les hôtes connus pour git via ssh ; le worker crée la clé à son premier démarrage
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : le même sur chaque nœud d'application, sinon un jeton signé
+  par un nœud est refusé par le suivant. Un nœud d'application refuse de démarrer sans lui
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : le même sur chaque nœud d'application et chaque worker, sinon un
+  identifiant stocké par l'un ne peut pas être lu par un autre. Un RTE en mode socket ne le lit jamais ; seul un RTE en mode base de données, déprécié,
+  qui s'enregistre lui-même en a besoin
+
+Donnez aussi à chaque conteneur le même utilisateur de base de données : un worker en attente ne peut mettre fin à la session d'un worker mort que si c'est la sienne.
+
+### Le verrou du worker
+{: .no_toc }
+
+Un seul worker travaille à la fois. Il détient le verrou de base de données `ansibleforms_worker` ; quand il s'arrête, la base de données libère le verrou et un
+worker en attente le prend en moins de 10 secondes. Quand l'hôte du worker meurt sans prévenir, la base de données pourrait garder le verrou pendant des heures,
+si bien qu'un worker en attente met fin à cette session dès qu'aucun worker n'a écrit de heartbeat pendant deux minutes, et prend le relais.
+
+Un worker qui perd le verrou au profit d'un autre s'arrête, et son conteneur redémarre comme worker en attente. Un worker dont le démarrage échoue s'arrête
+aussi, afin de ne jamais détenir le verrou sans rien faire. Galera et la réplication de groupe ne partagent pas le verrou entre les nœuds de base de données : pointez chaque
+worker vers le même nœud de base de données.
+
+### Jobs et nœuds
+{: .no_toc }
+
+Chaque conteneur se nomme `<role>-<hostname>-<port>`, sans rien à définir, et la page **Statut** les liste tous avec leur rôle
+et leur version, celui qui est le worker, et un avertissement quand ils exécutent des versions différentes.
+
+Un job qui tourne sur un RTE appartient à ce RTE, et continue quand le nœud d'application qui l'a lancé disparaît. Tout autre job (un job de modèle
+sur AWX ou un autre runner, un job de workflow, ou les étapes d'un formulaire multistep déprécié) appartient au nœud d'application qui l'a lancé. Un conteneur qui redémarre termine ses propres jobs inachevés, et le
+worker termine les jobs d'un conteneur qui ne répond plus depuis deux minutes, comme un pod remplacé.
+
+Un `SIGHUP` envoyé à n'importe quel nœud réapplique le [seed de configuration](../seed/) : un nœud d'application demande au worker de le faire.
+
+### Mise à jour
+{: .no_toc }
+
+Mettez à jour **le worker d'abord**, puis les nœuds d'application. Le worker patche le schéma, et un nœud d'application de la nouvelle version attend que le
+schéma soit patché et journalise ce qu'il attend. Les nœuds d'application mis à jour en premier restent non prêts jusqu'à ce que le worker suive, tandis que les anciens continuent
+de servir. Les RTE peuvent suivre à tout moment, tant qu'ils parlent le même contrat.
+
+### Limites
+{: .no_toc }
+
+Quelques éléments restent liés à un seul nœud :
+
+* **L'assistant de chat** garde ses conversations dans la mémoire d'un nœud d'application : utilisez des sessions persistantes sur le répartiteur de charge (nginx
+  `ip_hash`), ou un seul nœud d'application
+* **Les journaux** restent dans chaque conteneur. Placez [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) hors du volume partagé, car plusieurs
+  processus qui font tourner un même fichier perdent des lignes. La visionneuse de journaux montre le journal du nœud qui répond, centralisez donc la collecte des journaux
+* **Les paramètres** modifiés sur les pages de paramètres sont écrits dans le `.env` géré sur le volume partagé et s'appliquent sur chaque nœud ; ceux
+  qui nécessitent un redémarrage le nécessitent sur chaque nœud
+
+---
+
+## Exemple de disposition
+
+Le dépôt de l'application contient un point de départ complet dans [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale) :
+
+| Service | Image | Rôle |
+|---|---|---|
+| `db` | `mariadb:11` | La base de données, avec un utilisateur qui n'a de droits que sur le schéma `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, derrière le répartiteur de charge |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker` : le second attend et prend le relais |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Exécute les playbooks avec `RTE_MODE=inbound` et `RTE_FILES=local` : l'application le contacte |
+| `lb` | `nginx:stable` | Termine HTTPS sur le port 8443 et répartit les navigateurs sur les nœuds d'application avec `ip_hash` |
+
+Le runner `rte` du RTE et l'identifiant avec lequel il se connecte (son adresse `http://rte:8000` et `RTE_TOKEN`) sont déclarés dans le
+[seed de configuration](../seed/) `seed.yaml`, que le worker applique à chaque démarrage ; le RTE ne définit aucun `RTE_URL` et n'est pas publié sur l'hôte.
+
+Les nœuds d'application et les workers partagent un même `.env`, avec l'utilisateur de la base de données, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` derrière le répartiteur de charge et un `LOG_PATH` hors du volume partagé. Le RTE n'a pas d'`env_file` : il ne reçoit
+que `RTE_TOKEN` depuis `compose.yaml`, il ne détient donc aucun mot de passe de base de données. Les nœuds d'application, les workers et le RTE montent les mêmes
+volumes persistant et ssh :
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/fr/_configure/rte/another-datacenter.md b/i18n/fr/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..7d1004b
--- /dev/null
+++ b/i18n/fr/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Un autre datacenter
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Un RTE dans un autre datacenter
+{: .no_toc }
+
+D'un hôte nu dans un second datacenter à un RTE sortant qui exécute son premier playbook
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Pour les administrateurs : quand les hôtes gérés d'un second datacenter doivent être joints depuis un RTE de ce datacenter, et non depuis le premier.
+
+{: .note }
+> **La voie facile.** L'[installeur](../installation/installer.html#a-runner) réalise toutes les étapes ci-dessous sur l'hôte du RTE en une seule commande :
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, avec `--join afj_...` pour le faire approuver immédiatement.
+> Ce runbook fait la même chose à la main, avec Docker ou Podman, pour que vous puissiez voir et adapter chaque partie.
+
+---
+
+## Le résultat
+
+L'application, son worker et sa base de données restent où ils sont, dans le datacenter 1. Le datacenter 2 reçoit un hôte qui exécute un conteneur RTE en
+mode sortant ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), voir [Modes](modes.html#outbound)) : il contacte l'application en
+HTTPS et garde un WebSocket ouvert, rejoint comme runner à part entière, et exécute les playbooks des formulaires qui le nomment sur les hôtes
+gérés du datacenter 2.
+
+| Où | Ce qui y tourne | Parle à |
+|---|---|---|
+| Datacenter 1 | Les nœuds d'application, le worker, la base de données (comme aujourd'hui) | Rien de nouveau : il accepte le socket du RTE sur son adresse HTTPS habituelle |
+| Datacenter 2, l'hôte du RTE | Docker ou Podman, et le conteneur RTE | L'application à `APP_URL` en HTTPS, et les hôtes gérés du datacenter 2 |
+
+Le RTE ne détient aucun identifiant de base de données ni `ENCRYPTION_SECRET`, seulement un jeton à lui. Rien ne s'y connecte, il n'a donc besoin d'aucun port
+ouvert, d'aucun nom DNS ni d'aucun certificat. L'application envoie les playbooks et les inventaires avec chaque job (`RTE_FILES=transfer`, la valeur
+par défaut), le RTE n'a donc besoin ni d'en avoir une copie ni d'un disque partagé.
+
+Toutes les commandes ci-dessous s'exécutent dans un terminal sur l'hôte du RTE, en tant qu'utilisateur disposant de `sudo`, sauf indication contraire. Comptez environ 20 minutes,
+dont la plupart à attendre l'image.
+
+---
+
+## 0. Avant de commencer
+
+Rassemblez ceci :
+
+| Quoi | D'où cela vient |
+|---|---|
+| L'adresse de l'application | `APP_URL` : l'adresse que les gens ouvrent dans un navigateur, comme `https://forms.example.com`, avec son chemin de base s'il en a un |
+| Le certificat de l'application | Signé par une CA publique, une CA privée (il vous faut son certificat, étape 6), ou auto-signé |
+| Un proxy | Le `HTTPS_PROXY` qu'utilise ce datacenter pour joindre le datacenter 1, s'il y en a un |
+| Le nom du RTE | Le nom de son runner dans **Connexions > Runners**, que les formulaires nomment avec `runner:`, comme `rte-dc2` : lettres, chiffres et `_ . : @ -` |
+| Un jeton d'adhésion | Facultatif : un [jeton d'adhésion](../runners/registration.html#join-tokens) (`afj_...`) approuve le RTE immédiatement. Sans lui, un admin l'approuve (étape 8) |
+| La clé ssh | La clé privée qu'utilisent les playbooks pour joindre les hôtes gérés, ou le droit d'en créer une |
+
+L'application doit être en 7.3.0 ou ultérieure. Pour créer un jeton d'adhésion pour ce seul RTE, un admin appelle l'API une fois (voir
+[Jetons d'adhésion](../runners/registration.html#join-tokens)) :
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Préparer l'hôte
+
+Le RTE est un conteneur, l'hôte n'a donc besoin que d'un moteur de conteneurs : Node.js, python et ansible sont dans l'image.
+
+| Besoin | Pourquoi |
+|---|---|
+| Linux sur **x86_64** (amd64) | Les images RTE ne sont publiées que pour amd64 |
+| 2 CPU et 4 Go de mémoire, ou plus | Un RTE exécute jusqu'à [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks à la fois (10), chacun avec ses forks : dimensionnez-le en conséquence |
+| 20 Go d'espace disque libre | L'image `-rte-full` fait environ 3,3 Go, plus une image pendant les mises à jour, les fichiers de job qu'envoie l'application et les fichiers temporaires des jobs |
+| Docker, ou Podman avec podman-compose | Pour tirer et exécuter l'image |
+| L'heure réglée par NTP | Les heures des jobs sont comparées à celles de l'application |
+
+**Docker**, sur Ubuntu ou Debian (autres distributions : [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)) :
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, sur RHEL, Rocky ou Alma Linux :
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Avec Podman, écrivez `podman` au lieu de `docker` et `podman-compose` au lieu de `docker compose` dans toutes les commandes ci-dessous.
+
+---
+
+## 2. Réseau et pare-feu
+
+Le RTE ouvre lui-même chaque connexion. Rien ne l'atteint depuis l'extérieur :
+
+| De | Vers | Port | Pourquoi |
+|---|---|---|---|
+| L'hôte du RTE | L'application, à `APP_URL` (via `HTTPS_PROXY` s'il est défini) | Le port de l'application, `443` derrière la plupart des proxies | Le socket par lequel passent les jobs, leurs fichiers et leur sortie |
+| L'hôte du RTE | Les hôtes gérés du datacenter 2 | ssh (`22`), WinRM, leurs API | Les playbooks s'exécutent d'ici |
+| L'hôte du RTE | `ghcr.io` | `443` | Pour tirer l'image, sauf si elle vient de votre propre registre ou d'un fichier (étape 4) |
+
+N'ouvrez aucun port entrant pour le RTE. Son `PORT` (`8000`) ne sert que `/live`, `/ready` et `/metrics`, pour les sondes sur cet hôte.
+
+Le RTE contacte `APP_URL` suivi de `/api/v2/rte/socket`, en WebSocket. Un reverse proxy devant l'application doit transmettre l'upgrade
+pour ce chemin (voir [WebSockets des runners](../production/reverse-proxy.html#runner-websockets)). Vérifiez d'ici que l'application répond :
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Dossiers
+
+Tout se trouve sous `/opt/af-rte`. Le RTE tourne en tant qu'utilisateur `node` (uid 1000), ses données appartiennent donc à cet uid :
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Dossier | Dans le conteneur | Contient |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | Le spool (`rte-spool` : la sortie et la fin de chaque job jusqu'à ce que l'application les ait enregistrées), les fichiers de job qu'a envoyés l'application (`rte-files`), une CA privée, les bibliothèques python qu'installe un playbook |
+| `data/ssh/` | `/home/node/.ssh` | La clé ssh et le `known_hosts` des playbooks |
+| `data/ansible/` | `/etc/ansible/...` | Un `ansible.cfg`, des rôles et des collections à vous, montés au lieu d'être intégrés |
+
+Gardez `data/` sur l'hôte : un RTE redémarré envoie encore ce que l'application n'avait pas enregistré, et garde son cache de fichiers de job.
+
+**Clé ssh.** Copiez la clé qu'utilisent les playbooks dans le datacenter 1, ou créez-en une pour ce datacenter et donnez sa partie publique aux hôtes gérés :
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Donnez ensuite tout à l'uid 1000, avec la clé lisible par son seul propriétaire :
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. L'image
+
+Choisissez l'une des deux.
+
+### Option A : l'image officielle
+{: .no_toc }
+
+Les images publiées se trouvent sur le GitHub Container Registry, publiques, sans connexion nécessaire (voir [Images](images.html) pour les trois couches).
+Prenez la même couche que dans le datacenter 1. `:7` suit la dernière version 7, comme le fait le `:7` de l'application :
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Un hôte sans accès à internet obtient l'image depuis un hôte qui en a un :
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Ou poussez-la une fois vers votre propre registre (`docker tag` et `docker push`), et utilisez ce nom dans les étapes suivantes.
+
+### Option B : votre propre image
+{: .no_toc }
+
+Quand les playbooks du datacenter 2 ont besoin de collections ou de bibliothèques python absentes de l'image officielle (celles de VMware pour le vCenter
+de ce datacenter, par exemple), partez de `ansibleforms-rte-core` :
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Reconstruisez-la à chaque nouvelle version de l'application (voir [Construire votre propre RTE](images.html#build-your-own-rte)). Avec plusieurs hôtes RTE, construisez
+une fois et poussez vers votre propre registre. Hors ligne, faites `docker save` et `docker load` de l'image construite comme dans l'option A.
+
+---
+
+## 5. Paramètres
+
+Un nouveau [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) qui lui est propre, d'au moins 16 caractères. C'est le mot de passe de ce RTE : l'application
+le conserve dans l'identifiant RTE du runner, et scelle avec lui les secrets de chaque job.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variable | Signification |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound` : le RTE contacte l'application. Sans elle, le RTE démarre dans le mode base de données déprécié |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'adresse de l'application, `http://` ou `https://`, avec son chemin de base s'il y en a un |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Le nom de son runner. Non définie : son id de nœud, `rte-<hostname>-<port>`, qui change avec le conteneur |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Son propre jeton, d'au moins 16 caractères. Gardez-le : le runner se connecte avec lui à partir de maintenant |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Facultative : un jeton d'adhésion, utilisé uniquement tant que son runner n'existe pas encore ou attend l'approbation |
+
+Ajoutez celles-ci quand le réseau l'exige :
+
+| Variable | Quand |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | Le RTE joint l'application via un proxy : `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Un hôte listé dans `NO_PROXY` (séparé par des virgules, `.example.com` pour un domaine) est contacté directement |
+| `NODE_EXTRA_CA_CERTS` | Le certificat de l'application provient d'une CA privée : placez le certificat de la CA dans `/opt/af-rte/data/certificates/ca.pem` et définissez `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` accepte n'importe quel certificat de l'application, y compris un certificat auto-signé. Uniquement à l'intérieur d'un réseau de confiance : préférez `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (par défaut) reçoit les playbooks et les inventaires avec chaque job. Laissez-la, sauf si vous les montez vous-même sur le RTE (`local`) |
+
+Les autres paramètres que lit un RTE sont sur [Exécuter un RTE](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` et
+`RTE_DRAIN_SECONDS` peuvent aussi être définies plus tard sur sa page de runner, qui l'emporte sur la variable (voir
+[Les paramètres d'un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Le démarrer
+
+Un fichier compose garde toute la définition au même endroit, à côté des paramètres. Mettez l'image de l'étape 4 dans `image:` :
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker le redémarre après un reboot (`unless-stopped`). Podman n'a pas de démon pour cela : activez `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`), ou exécutez le conteneur comme service systemd avec un fichier Quadlet. Sur un hôte avec SELinux
+en mode enforcing, ajoutez `:Z` à chaque volume (`./data:/app/dist/persistent:Z`).
+
+Sans compose, le même conteneur en une seule commande :
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Le vérifier sur l'hôte
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+Le journal montre le RTE démarrer, contacter l'application et se connecter :
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Sans jeton d'adhésion, une ligne de plus indique qu'il attend :
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Notez l'empreinte.
+
+`/ready` répond `503` avec `not connected to the app` tant que le socket n'est pas ouvert. Le healthcheck indique seulement que le processus écoute.
+
+---
+
+## 8. L'approuver
+
+Sans jeton d'adhésion, le RTE a demandé à rejoindre : **Connexions > Runners** affiche un avis orange au-dessus de la liste,
+**1 Runner attend l'approbation**. Ouvrez-le, vérifiez que l'**Empreinte** est celle du journal du RTE et que **Mode** indique
+Sortant, puis **Approuver** (voir [Approuver un RTE](../runners/registration.html#approving-an-rte)). Seul un admin approuve. Une demande
+que personne ne traite dans les 24 heures est supprimée, et le RTE redemande à son prochain contact avec l'application.
+
+Avec un jeton d'adhésion, le runner est approuvé immédiatement et sa description nomme le jeton d'adhésion. Dans les deux cas, l'application conserve le jeton du RTE
+dans un nouvel identifiant RTE, `rte-dc2-rte`, et le RTE se connecte avec son propre `RTE_TOKEN` à partir de là : `RTE_JOIN_TOKEN` n'est plus
+utilisé, et vous pouvez le retirer de `rte.env`.
+
+---
+
+## 9. Le vérifier dans AnsibleForms
+
+1. **Connexions > Runners** liste le runner `rte-dc2`, de type RTE. Activez **Colonnes > Connexion** pour voir **Connecté** dans la liste
+2. Ouvrez-le. Son onglet **RTE** montre **Mode** Sortant et le badge **Connexion** **Connecté** ; au survol, il nomme le nœud d'application qui
+   détient le socket, la version du RTE et combien de ses jobs tournent
+3. Cliquez sur **Tester la connexion** : il indique **Runner connection is OK**. Il n'appelle rien : il lit quel nœud d'application détient le socket du RTE
+   (`runner_leases`) et vérifie le contrat qu'a parlé le RTE à sa connexion
+4. Donnez-lui une description, comme *Datacenter 2*
+5. Laissez **Par défaut** sur le runner du datacenter 1, sauf si chaque formulaire de playbook sans `runner:` doit s'exécuter dans le datacenter 2
+
+La page **Statut** liste le nouveau RTE avec sa version, à côté des autres.
+
+---
+
+## 10. Un premier job
+
+Prouvez tout le chemin avec un playbook qui ne change rien. Dans les playbooks de l'application (son dossier ou son dépôt de playbooks, comme dans le
+datacenter 1), ajoutez `ping-dc2.yaml` :
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Ajoutez ensuite dans le concepteur un formulaire qui nomme le nouveau runner :
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Lancez-le. L'application envoie le dossier des playbooks et l'inventaire avec le job, et le RTE les conserve par leur hash, si bien qu'un dossier inchangé
+n'est jamais envoyé deux fois. La sortie commence par `Running on RTE rte-dc2 (outbound)`, montre `pong` pour chaque hôte, et le job
+se termine en succès. Un dossier plus gros que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 par défaut) n'est pas
+envoyé : le job échoue et l'indique.
+
+---
+
+## 11. Lui envoyer les formulaires
+
+Un formulaire s'exécute sur le RTE qu'il nomme, ajoutez donc la même ligne à chaque formulaire destiné au datacenter 2 :
+
+```yaml
+runner: rte-dc2
+```
+
+Voir [Runners](../runners.html) pour le runner par défaut et les autres types de runners.
+
+---
+
+## Quand quelque chose échoue
+
+Le RTE écrit dans `docker logs` à partir de `notice`. Une connexion qui échoue avant l'ouverture du socket (un nom DNS, un port refusé, un
+certificat) n'apparaît que sous la forme `RTE: dialing the app again in <n> seconds`, au niveau `info` : définissez
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) dans `rte.env` et redémarrez-le pour voir
+`RTE: socket to wss://...: <the error>`.
+
+| Ce que vous voyez | Où | Que faire |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `RTE_TOKEN` manque ou est trop court dans `rte.env` |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Définissez `APP_URL` dans `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` doit commencer par `https://` (ou `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | `RTE_MODE=outbound` manque dans `rte.env` |
+| Aucune ligne `connected to the app`, `/ready` reste à `503` | `docker logs`, `/ready` | Le réseau de l'étape 2 : faites un `curl` de l'application depuis cet hôte, le proxy (`HTTPS_PROXY`, `NO_PROXY`), le certificat de l'application (`NODE_EXTRA_CA_CERTS`, étape 5). Définissez `LOG_CONSOLE_LEVEL=debug` pour voir l'erreur |
+| `the app refused the socket (404)` ou un autre statut que 401, 403 et 409 | `docker logs` | Un reverse proxy ne transmet pas le WebSocket sur `/api/v2/rte/socket`, ou il manque à `APP_URL` le chemin de base de l'application |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Un runner `rte-dc2` existe avec un autre jeton. Donnez ce jeton au RTE (le mot de passe de l'identifiant du runner), ou supprimez le runner pour qu'il demande à rejoindre |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Créez un nouveau jeton d'adhésion, ou retirez `RTE_JOIN_TOKEN` et approuvez le RTE (étape 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | Le RTE a été réinstallé avec un nouveau jeton : utilisez le jeton de l'identifiant de son runner, ou faites-le changer par un admin |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Suit un refus. Corrigez-en la cause, puis faites `docker restart af_rte_dc2` au lieu d'attendre |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Approuvez-le (étape 8). Il est connecté, mais ne prend aucun job d'ici là |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | L'application et le RTE exécutent des versions d'un autre [contrat](images.html#the-contract) : mettez le RTE à la version de l'application (voir Le mettre à jour) |
+| **Non connecté**, ou **Tester la connexion** indique *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | L'application | Aucun nœud d'application ne détient son socket : le RTE est arrêté, ou ne peut pas joindre l'application. Lisez ses `docker logs` |
+| Un job attend, puis échoue avec *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | La sortie du job | Le RTE n'était pas connecté pendant l'attente du job |
+| `Permission denied` sur la clé ssh | La sortie du job | Les fichiers de `data/` doivent appartenir à l'uid 1000 (étape 3) |
+| `UNREACHABLE` pour les hôtes gérés | La sortie du job | Le ssh depuis cet hôte : la clé, `known_hosts`, et le pare-feu vers les hôtes |
+
+Côté application, un RTE refusé apparaît dans le journal de l'application sous la forme `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Le mettre à jour
+
+Quand l'application passe à une nouvelle version, suivez-la aussi sur cet hôte. Un RTE du même contrat continue de fonctionner entre-temps ; quand une version
+change le contrat, ses notes de version l'indiquent (voir [Le contrat](images.html#the-contract)). Avec `:7` dans `compose.yml`, ou dans le
+`FROM` de votre Dockerfile :
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Mettez-le à jour quand aucun playbook n'y tourne : un arrêt attend `RTE_DRAIN_SECONDS` (25) pour les playbooks en cours, et ceux qui tournent encore
+se terminent alors comme abandonnés. Ce qu'ils ont affiché avant l'arrêt est conservé dans le spool et envoyé une fois le RTE revenu. Hors ligne, faites `docker load`
+de la nouvelle image (étape 4) avant `docker compose up -d`.
+
+---
+
+## Revenir en arrière
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+Le socket se ferme, et le runner affiche immédiatement **Non connecté** : plus aucun nœud d'application ne détient son socket (`runner_leases`). Un hôte
+qui disparaît sans le fermer affiche **Non connecté** en environ une minute, une fois que le nœud d'application n'entend plus rien sur le socket. Le
+runner reste : un runner qui a rejoint via un socket n'est jamais supprimé de lui-même. Supprimez-le dans **Connexions > Runners**, et son
+identifiant `rte-dc2-rte` dans **Connexions > Identifiants**. Retirez d'abord la ligne `runner:` des formulaires qui le nommaient : d'ici là,
+leurs jobs attendent le RTE, jusqu'à `RTE_QUEUE_MINUTES`, et échouent.
+
+---
+
+## Plus de capacité dans le datacenter 2
+
+Répétez les étapes 1 à 9 sur d'autres hôtes du datacenter 2, chacun avec son propre `RTE_NAME` et son propre `RTE_TOKEN`, comme `rte-dc2-b` : chacun rejoint comme
+runner à part entière et prend jusqu'à [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks. Un formulaire en choisit un avec
+`runner:`. Deux RTE avec le même `RTE_NAME` ne se partagent pas le travail : le second reprend le socket au premier (voir
+[Plusieurs RTE](several.html#several-rtes)).
+
+---
+
+## Un RTE en mode base de données
+
+Avant la 7.3.0, ce runbook mettait en place un RTE en mode base de données : il détenait les identifiants de la base de données (`DB_*`, `ENCRYPTION_SECRET`), se connectait
+à la base de données du datacenter 1 sur le port `3306`, et l'application l'appelait sur son port `8000`. Ce mode est déprécié depuis la 7.3.0 et
+sera supprimé dans la 8.0.0. Pour passer un tel RTE en sortant sans nouveau runner, définissez sur lui `RTE_MODE=outbound`, `APP_URL` et `RTE_NAME` (le nom de
+son runner), gardez son `RTE_TOKEN`, et retirez `DB_*`, `ENCRYPTION_SECRET` et `RTE_REGISTER` : voir
+[Base de données (obsolète)](modes.html#database-deprecated). Fermez ensuite le port `8000` et le port de la base de données dont il n'a plus besoin.
diff --git a/i18n/fr/_configure/rte/images.md b/i18n/fr/_configure/rte/images.md
new file mode 100644
index 0000000..a47bfc4
--- /dev/null
+++ b/i18n/fr/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Images
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# Images RTE
+{: .no_toc }
+
+Les trois images RTE publiées, et un RTE à vous avec les collections et les bibliothèques qu'utilisent vos playbooks
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les images RTE
+
+Le RTE est publié en trois couches, chacune construite sur la précédente, avec les mêmes tags que l'application (voir [Tags d'image](../installation/#image-tags)) :
+
+| Image | Ce qu'elle contient | À utiliser |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js et le serveur AnsibleForms, git, ssh et sshpass. Ni python ni ansible, elle n'exécute donc aucun playbook à elle seule | Pour construire un RTE avec vos propres versions de python et d'ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base, plus python 3.14, ansible-core et quelques bibliothèques courantes (`jmespath`, `netaddr`, `requests`, `paramiko`). Aucune collection | Pour construire un RTE plus petit avec uniquement les collections et les bibliothèques qu'utilisent vos playbooks |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Le core, plus le paquet `ansible` sur le même ansible-core, et ce que contenait l'image d'AnsibleForms 6.5 : les collections NetApp, AWS et community, `pandas`, `pyvmomi`, `boto3`, le client mariadb, ytt et quelques outils système | **La valeur par défaut.** Exécutez-la telle quelle : les playbooks de la 6.5 y trouvent ce qu'ils utilisaient |
+
+Comme l'image de l'application, chaque couche tourne en tant qu'utilisateur `node` (uid 1000), et les playbooks tournent aussi sous cet utilisateur.
+
+---
+
+## Construire votre propre RTE
+
+Partez de `ansibleforms-rte-core` et ajoutez les collections et les bibliothèques python qu'utilisent vos playbooks. Cet exemple NetApp est l'un
+des Dockerfiles de [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte) :
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+L'environnement python et le dossier des collections appartiennent à `node`, ces installations n'ont donc pas besoin de root. Une couche qui installe des paquets
+système passe en `USER root` pour eux et revient à `USER node` à la fin. Pour apporter votre propre python et votre propre ansible, partez de
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` dans le même dossier).
+
+Gardez l'image alignée sur la version de l'application : `:7` suit le `:7` de l'application. Les collections et les rôles peuvent aussi être montés au lieu d'être intégrés, dans
+`/etc/ansible/collections` et `/etc/ansible/roles`. Aucune reconstruction n'est alors nécessaire à chaque modification, mais ce qui s'exécute dépend de ce volume ;
+les bibliothèques python vont toujours dans l'image. Tout intégrer est reproductible et démarre vite, c'est donc la voie à suivre en production.
+
+---
+
+## Le contrat
+
+Ce que l'application et un RTE doivent partager, c'est leur contrat, un numéro que les deux annoncent. Un RTE d'une version plus ancienne continue de fonctionner avec une
+application plus récente tant que les deux parlent le même contrat ; quand une version le change, ses notes de version indiquent que les RTE doivent être mis à jour. Chaque mode
+a le sien :
+
+| Mode | Contrat | En cas de discordance |
+|---|---|---|
+| Sortant, Entrant | 3, nouveau dans la 7.3.0 | L'application ferme le socket du RTE avec le code `4409` et journalise *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Un RTE sortant journalise *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Un job envoyé avec un autre contrat est refusé |
+| Base de données (obsolète) | 2, depuis la 7.0.0 | Le RTE refuse les jobs de l'application |
+
+**Tester la connexion** sur le runner indique quel contrat parle le RTE et lequel il faut à l'application (voir
+[Tester la connexion](../runners/runner-page.html#test-connection)), et la ligne **Runners** de la page **Statut** exécute la même vérification.
diff --git a/i18n/fr/_configure/rte/index.md b/i18n/fr/_configure/rte/index.md
new file mode 100644
index 0000000..b71aca5
--- /dev/null
+++ b/i18n/fr/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Environnements d'exécution (RTE)
+{: .no_toc }
+
+Ce qu'est un RTE, comment il exécute un playbook, et ce à quoi il peut toucher
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : comprenez le RTE avant d'en exécuter un, de le dimensionner ou de le déplacer vers un autre réseau.
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Images](images.html) | Les trois images RTE, et la construction de la vôtre avec les collections qu'utilisent vos playbooks |
+| [Modes](modes.html) | Sortant, entrant ou base de données : qui ouvre la connexion, le spool, les fichiers du job |
+| [Exécuter un RTE](run.html) | Les paramètres de chaque mode, et un exemple `docker run` pour chacun |
+| [Plusieurs RTE](several.html) | La capacité, les répliques derrière une même adresse, et ce qui se passe quand un RTE s'arrête ou meurt |
+| [Un autre datacenter](another-datacenter.html) | Un runbook : ajouter un RTE dans un second datacenter, d'un hôte nu jusqu'à son premier job |
+
+---
+
+## Ce qu'est un RTE
+
+AnsibleForms 7 n'exécute aucun playbook dans le conteneur de l'application. Le job d'un formulaire `ansible` est confié à un [runner](../runners.html) de type
+`rte`, un environnement d'exécution : le serveur AnsibleForms démarré avec `AF_ROLE=rte`, à côté de python et d'ansible, sans interface
+web. Il parle à l'application via un seul WebSocket et ne détient aucun identifiant de base de données
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` ou `inbound`, voir [Modes](modes.html)) : l'application lui envoie le job,
+le RTE exécute `ansible-playbook`, et l'application enregistre la sortie et le statut final qu'il lui renvoie, là où le navigateur les lit.
+
+L'application résout les identifiants du job et les remet au RTE scellés pour ce RTE et ce job uniquement. Le RTE ne lit jamais la
+table des identifiants ni un coffre de secrets, et un playbook n'hérite pas des variables d'environnement propres à AnsibleForms
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` et les autres) : passez une telle valeur comme extravar ou comme identifiant. Le RTE de la 7.0 à la 7.2,
+qui lisait et écrivait lui-même la base de données, tourne encore en 7.x sous la forme du mode base de données déprécié (voir [Mode base de données](#database-mode-deprecated)).
+
+---
+
+## Fonctionnement du RTE
+
+Le RTE est un conteneur que vous exécutez vous-même, à côté de l'application ou dans un autre réseau : AnsibleForms n'en crée jamais. Voici
+où il tourne, ce qu'il partage avec l'application, et ce qui se passe à l'intérieur depuis le moment où un formulaire est lancé jusqu'à la disparition
+du processus du playbook :
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Comment le RTE exécute un playbook</title>
+<desc id="afr-desc">Sur un hôte de conteneurs ou dans un cluster Kubernetes, tous deux gérés par l'opérateur, le conteneur de l'application et un ou plusieurs conteneurs RTE maintiennent chacun un WebSocket entre eux, ouvert par l'application (entrant) ou par le RTE (sortant). Seule l'application parle à la base de données. 1 : le navigateur lance un formulaire sur l'application. 2 : l'application enregistre le job dans la base de données, choisit le runner et scelle pour lui les secrets du job. 3 : l'application envoie le job par le socket. 4 : le RTE le réclame et obtient les fichiers du job, depuis son cache ou depuis l'application. 5 : le RTE lance ansible-playbook comme processus enfant, un par job, jusqu'à RTE_MAX_JOBS. 6 : le playbook atteint les hôtes gérés. 7 : le RTE écrit la sortie, les événements et la fin dans son spool et les envoie par le socket ; l'application les enregistre dans la base de données et en accuse réception. 8 : le navigateur suit le job via l'application. Le volume de l'application n'est monté dans le RTE qu'avec RTE_FILES=local.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Hôte de conteneurs ou cluster Kubernetes</text>
+<text class="afr-s" x="181" y="61">géré par vous ; un RTE sortant peut être dans un autre réseau</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Navigateur</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">formulaires, job</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">Conteneur app</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">web, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runners</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">scellent les secrets</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">Hub RTE</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">stocke, puis acquitte</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">Conteneur RTE</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">Fichiers du job</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">en cache par hash</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">jusqu'à RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">gardé jusqu'à l'acquit</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">un</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Hôtes gérés</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volume de l'app</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbooks, inventaires</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">RTE_FILES=local seul</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">réservé à l'app</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+Le schéma montre un socket par RTE, quel que soit le côté qui l'a ouvert : l'application contacte un RTE entrant, un RTE sortant contacte l'application (voir
+[Modes](modes.html)). Une fois ouvert, les mêmes messages circulent dans les deux sens, et seule l'application lit et écrit la base de données.
+
+**Qui le démarre.** Un RTE est un conteneur de longue durée, démarré par ce qui exécute vos autres conteneurs. Il attend des jobs et continue
+de tourner entre eux :
+
+| Comment vous exécutez AnsibleForms | Qui démarre le RTE |
+|---|---|
+| `docker run` ou `podman run` | Vous, avec une commande comme celle de [Exécuter un RTE](run.html), sur n'importe quel hôte qui joint l'application, ou que l'application joint |
+| [Docker Compose](../installation/docker-compose.html) | Le service `rte` de `docker-compose.yml`, à côté de `app` et `mysqldb`. Son seed de configuration le déclare comme runner par défaut `rte`, entrant, à `http://rte:8000` |
+| [Chart Helm](../installation/kubernetes.html) | Kubernetes, comme second conteneur nommé `rte` dans le pod de l'application (`containers.rte`). L'application le contacte sur `127.0.0.1`, en entrant, et le seed du chart le déclare comme runner par défaut |
+| [L'installeur](../installation/installer.html) | Docker Compose ou le chart Helm comme ci-dessus, ou un service systemd [sans conteneurs](../installation/native.html) ; un Runner à part entière, qui demande à rejoindre et attend l'approbation d'un admin |
+
+Le moteur de conteneurs est le vôtre : Docker ou Podman sur l'hôte, ou le runtime de conteneurs de votre cluster Kubernetes, installé et tenu
+à jour par vous. AnsibleForms ne lui parle jamais. Ni l'application ni le RTE n'appellent Docker ou Podman, ne montent leur socket ni ne démarrent de
+conteneur : l'application ne parle au RTE que via son socket.
+
+**Ce qu'il contient.** Un conteneur, avec ce qu'il faut pour exécuter un playbook et rien de plus :
+
+* **Le serveur** : le même serveur Node.js que l'application, démarré avec `AF_ROLE=rte` (défini dans l'image) sous `tini`
+* **Ce qui est laissé de côté** : l'interface web, la connexion, le planificateur, le worker et tous les modules de base de données, que ce rôle ne charge pas
+* **Ce sur quoi il écoute** : son `PORT` (`8000`) : `/live` et `/ready` pour les sondes et `/metrics` pour Prometheus, et en entrant le socket
+  que contacte l'application, `/rte/v1/socket`. Un RTE sortant n'accepte aucune connexion de l'application
+* **Python et ansible** : apportés par la couche d'image que vous choisissez (voir [Les images RTE](images.html))
+* **L'utilisateur** : le serveur et chaque playbook tournent en tant que `node` (uid 1000), jamais en root
+
+**Ce qu'il partage avec l'application.** Son jeton, et avec `RTE_FILES=local` les fichiers de l'application. Avec `RTE_FILES=transfer`, la valeur par défaut, les
+playbooks et les inventaires arrivent avec chaque job, et le RTE n'a besoin d'aucun disque partagé :
+
+| Partagé avec l'application | Ce qu'en fait le RTE |
+|---|---|
+| `RTE_TOKEN` | Il le présente quand il contacte l'application (sortant), ou le vérifie quand l'application le contacte (entrant). L'application détient la même valeur dans l'identifiant RTE du runner, et les secrets du job sont scellés avec |
+| Le volume persistant, `/app/dist/persistent`, avec `RTE_FILES=local` uniquement | Le dossier des playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)), ou le dépôt de playbooks que le worker a cloné sous [`REPO_PATH`](../customization/paths.html#env_REPO_PATH), les inventaires ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) et les dépôts d'inventaires) et les fichiers téléversés. Le RTE écrit les fichiers d'extravars du job dans le dossier du playbook, montez-le donc en lecture-écriture |
+| Le dossier ssh, `/home/node/.ssh` | La clé privée et le `known_hosts` qu'utilisent les connexions ssh du playbook : montez ceux de l'application, gérés sur ses pages de paramètres, ou donnez au RTE les siens |
+
+Le RTE ne clone rien : un dépôt lui parvient dans les fichiers d'un job, ou sur le volume qu'il partage avec l'application. Les collections, les rôles et
+`ansible.cfg` proviennent de l'image, des dossiers `/etc/ansible/collections`, `/etc/ansible/roles` et `/etc/ansible/ansible.cfg` quand
+vous les y montez (le projet Docker Compose le fait), ou d'un `ansible.cfg` à côté des playbooks.
+
+**La vie d'un job.** Les numéros ci-dessous sont ceux du schéma, pour un formulaire de playbook lancé depuis le navigateur ou l'API :
+
+1. **Lancement** : l'application vérifie le formulaire et ses valeurs, construit les extravars et enregistre le job avec le statut `running`. Un formulaire avec une
+   [approbation](../forms/approval.html) s'arrête là jusqu'à ce qu'un approbateur l'accepte, et n'atteint aucun RTE avant cela
+2. **Choix du runner** : l'application prend le RTE que nomme le formulaire avec `runner: <name>`, sinon le runner par défaut de type RTE, et enregistre son
+   nom sur le job. Elle résout les identifiants du job depuis la base de données ou un [coffre de secrets](../secret-stores/), son accès ansible et son
+   mot de passe vault, et les scelle en AES-256-GCM avec une clé dérivée du jeton de ce runner et de l'id du job
+3. **Remise** : le nœud d'application qui détient le socket du RTE lui envoie le job : les extravars, les options du formulaire, les secrets scellés et
+   les hashes des fichiers du job. N'importe quel nœud d'application peut lancer le job ; celui qui détient le socket l'envoie en moins de deux secondes. Un RTE plein,
+   ou non connecté, fait attendre le job, jusqu'à [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Réclamation** : le RTE répond `claimed`, ou `refused` quand il est plein, en cours d'arrêt, ne peut pas ouvrir les secrets, ou que le job arrive avec un autre
+   [contrat](images.html#the-contract) que le sien. Avec `RTE_FILES=transfer`, il prend les playbooks et les inventaires dans son
+   cache par leur hash, demande à l'application un hash qu'il n'a pas, et les décompresse dans un dossier propre au job
+5. **Démarrage** : dans le dossier du playbook (plus le `playbookSubPath` du formulaire, qui doit exister), il écrit deux fichiers : `extravars_<id>.json`
+   avec les valeurs du formulaire et les identifiants, et un fichier caché avec l'accès ansible. Puis il lance `ansible-playbook` comme son propre processus
+   enfant, sans shell, dans un groupe de processus à part, avec `-e @` ces fichiers, un `-i` par inventaire, et les tags, la limite, le check,
+   le diff et la verbosité du formulaire. Le mot de passe vault entre par stdin, jamais dans un fichier ni sur la ligne de commande, et le processus tourne en tant que
+   `node` avec un environnement filtré (voir plus bas)
+6. **Exécution** : le playbook se connecte aux hôtes gérés depuis le conteneur RTE, en ssh avec la clé et le `known_hosts` de
+   `/home/node/.ssh`, avec `sshpass` pour un accès par mot de passe, ou via les API qu'appellent ses modules. C'est le RTE, pas l'application, qui doit pouvoir les joindre
+7. **Sortie et fin** : le RTE regroupe stdout et stderr toutes les demi-secondes ou tous les 64 Ko, avec les identifiants masqués, et numérote chaque
+   lot. Il écrit chaque élément dans le spool du job sur son disque avant de l'envoyer : la sortie, les événements, le journal du job
+   `.joblogs/job_log_<id>.log` (toutes les 2 secondes), le début et la fin avec le statut final (`success`, `failed` ou `aborted`). L'application
+   enregistre chaque élément une seule fois et en accuse réception, et le RTE abandonne le spool une fois la fin enregistrée. Au-delà de
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) octets sur un flux (50 Mo par défaut), il n'envoie plus rien, et
+   le playbook continue. L'application envoie ensuite les [notifications](../forms/notifications.html) du formulaire
+8. **Suivi** : le navigateur ne parle jamais au RTE : la page du formulaire relit le job via l'application toutes les 2 secondes, et la page Jobs
+   le suit en direct à mesure que l'application enregistre chaque élément
+
+**Un socket coupé.** Le playbook continue. Le RTE rappelle (sortant), ou un nœud d'application le recontacte (entrant), et renvoie ce que
+l'application n'avait pas acquitté : l'application ignore ce qu'elle a déjà enregistré, si bien qu'aucune ligne n'est perdue ni enregistrée deux fois. Cela tient tant que le socket
+revient dans les deux minutes : l'application n'écrit le heartbeat du RTE que tant que son socket est ouvert, et une fois que ce heartbeat a deux minutes,
+le worker termine les jobs en cours du RTE comme abandonnés, même si leurs playbooks tournent encore. Gardez le spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) sur un volume, afin qu'un RTE redémarré envoie encore ce qu'il avait conservé. Un
+playbook qui tournait quand son RTE a redémarré ne peut pas continuer : l'application termine son job comme abandonné quand le RTE revient sans lui.
+
+**Interruption.** Une interruption positionne l'indicateur d'interruption du job, et le nœud d'application qui détient le socket du RTE envoie `cancel` en moins de deux secondes. Le RTE
+envoie `SIGTERM` au groupe de processus du playbook, si bien que `ansible-playbook` et chaque fork qu'il a lancé s'arrêtent ensemble, et le job se termine
+`aborted`. Un cancel qui arrive avant son job est conservé une minute, et le job démarre alors interrompu.
+
+**Nettoyage.** Dès que le processus se termine, quelle qu'en soit l'issue, le RTE supprime les deux fichiers d'extravars (un formulaire avec `keepExtravars`
+garde le fichier visible, jamais le caché), le fichier d'artefacts dans `/tmp`, le fichier de journal du job et le dossier de fichiers propre au job. La
+fin est enregistrée une seule fois : un second écrivain, comme l'application qui fait échouer un job que le RTE a déjà terminé, ne change rien.
+
+**Un processus par job, pas un conteneur par job.** AWX et AAP démarrent un nouveau pod ou conteneur depuis une image d'execution environment pour
+chaque job. AnsibleForms ne démarre rien : le conteneur RTE tourne déjà, et chaque job est un processus enfant à l'intérieur. Un job démarre
+sans tirer d'image ni planifier de pod, et AnsibleForms n'a besoin d'aucun droit sur votre moteur de conteneurs ou votre cluster. En contrepartie, les
+playbooks qui tournent sur un même RTE partagent son CPU, sa mémoire, `/tmp`, son dossier personnel et son python : donnez au conteneur assez de ressources pour
+`RTE_MAX_JOBS` playbooks avec leurs forks. Pour changer ce qu'un playbook peut utiliser, changez l'image, pas le job.
+
+---
+
+## La frontière de sécurité
+
+Le RTE exécute du code écrit par les auteurs de formulaires, il est donc conçu pour détenir le moins possible :
+
+* **Son jeton uniquement** : le RTE ne détient aucun identifiant de base de données ni `ENCRYPTION_SECRET`. Il n'accepte aucun appel sauf le socket de l'application, avec
+  son jeton, et n'a ni utilisateurs, ni connexion, ni pages web. Via le socket, il peut seulement exécuter les jobs que l'application lui envoie, en rendre compte et
+  demander leurs fichiers : il ne peut ni créer un job, ni lire un autre job, ni distribuer des identifiants
+* **Des secrets scellés** : pour exécuter un job, le RTE ne lit jamais la table des identifiants ni un coffre de secrets. Il reçoit les secrets des jobs qu'il
+  exécute, scellés pour son jeton et cet id de job uniquement, si bien qu'un paquet destiné à un autre RTE ou à un autre job ne s'ouvre pas, et qu'un octet modifié
+  est refusé
+* **Une connexion vérifiée** : en sortant, le RTE vérifie le certificat de l'application. En entrant via HTTPS, l'application épingle le certificat propre du RTE
+  quand il rejoint, et ne le contacte que s'il présente celui-là (voir [Modes](modes.html#inbound)). Un RTE entrant en HTTP simple a sa place
+  sur un réseau privé, comme celui du projet Docker Compose
+* **Aucun environnement hérité** : `ansible-playbook` reçoit l'environnement du RTE privé de chaque variable que lit AnsibleForms lui-même
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, les `MYSQL_*` et les autres), si bien que
+  `lookup('env', ...)` ne peut pas les atteindre. Ce que vous définissez pour les playbooks (`PATH`, proxies, `ANSIBLE_*`) passe tel quel
+* **Aucun modèle venant des utilisateurs** : {% raw %}une valeur de formulaire qui contient `{{`, `{%` ou `{#` atteint le playbook comme une chaîne unsafe{% endraw %}
+  qu'ansible ne passe jamais au moteur de templates, sauf si le formulaire définit `allowJinjaInExtravars`, et aucun shell n'exécute jamais la ligne de commande
+* **Pas root** : le RTE et ses playbooks tournent en tant que `node` (uid 1000), si bien qu'un playbook peut faire ce que cet utilisateur peut faire dans le conteneur, comme
+  lire ses fichiers et la clé ssh, et rien de plus
+
+Traitez son conteneur, son image et son environnement avec le même soin que ceux de l'application.
+
+---
+
+## Mode base de données (déprécié)
+
+Le RTE de la 7.0 à la 7.2, sans `RTE_MODE`, tourne pendant toute la 7.x et sera supprimé dans la 8.0.0. Il diffère des étapes ci-dessus sur quatre points :
+
+* **Il détient la base de données** : ses paramètres `DB_*`, et `ENCRYPTION_SECRET` quand il s'enregistre lui-même
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **La remise est un appel HTTP** : l'application appelle `POST <address>/rte/v1/jobs` avec le jeton et les secrets scellés, et le RTE réclame
+  le job en y écrivant son nom dans la base de données (étapes 3 et 4)
+* **Il écrit lui-même la sortie** : dans la base de données, par lots, sans spool (étape 7). Une interruption lui parvient via l'indicateur d'interruption du job,
+  qu'il lit toutes les 2 secondes, et un appel `/cancel`
+* **Il lit les fichiers depuis le volume de l'application** : il a besoin du même disque que l'application, comme avec `RTE_FILES=local`
+
+Sa page de runner n'a aucun des [paramètres RTE](../runners/runner-page.html#an-rtes-settings) : il lit ses propres variables. Pour le passer à un
+mode socket, voir [Modes](modes.html#database-deprecated).
diff --git a/i18n/fr/_configure/rte/modes.md b/i18n/fr/_configure/rte/modes.md
new file mode 100644
index 0000000..89c3601
--- /dev/null
+++ b/i18n/fr/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modes
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Comment un RTE parle à l'application
+{: .no_toc }
+
+Sortant, entrant ou base de données : qui ouvre la connexion, et ce qui y circule
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : depuis la 7.3.0, un RTE parle à l'application via un seul WebSocket et ne détient aucun identifiant de base de données. Choisissez le mode
+qui convient au réseau entre eux : qui peut ouvrir une connexion vers qui, et à travers quels proxies et pare-feux elle passe.
+
+---
+
+## Les trois modes
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) sur le RTE indique comment il joint l'application ; son runner a le même **Mode** :
+
+| Mode | Qui ouvre la connexion | Ce que détient le RTE | Pour |
+|---|---|---|---|
+| `outbound` | Le RTE contacte l'application à [`APP_URL`](../customization/server.html#env_APP_URL) et garde un WebSocket ouvert | Son `RTE_TOKEN`, aucun identifiant de base de données | Une DMZ, du NAT, ou une zone qui n'autorise aucune connexion entrante : rien n'atteint le RTE depuis l'extérieur |
+| `inbound` | L'application contacte le RTE à l'adresse de son runner et garde un WebSocket ouvert | Son `RTE_TOKEN`, aucun identifiant de base de données | Un réseau où le côté central ouvre toutes les connexions, un projet compose, un pod |
+| `database` (obsolète) | L'application appelle l'API du RTE en HTTP, et le RTE lit et écrit lui-même la base de données de l'application | Les identifiants de la base de données (`DB_*`) et `ENCRYPTION_SECRET` | Le comportement de la 7.0 à la 7.2, supprimé dans la 8.0.0 |
+
+Un RTE sans `RTE_MODE` tourne en mode base de données pendant toute la 7.x, et journalise un avertissement `[DEPRECATED] This RTE runs in database mode` à
+son démarrage. Un runner ajouté avant la 7.3.0 a le mode **Base de données (obsolète)** ; mettez-le au mode dans lequel tourne son RTE quand vous le migrez.
+
+---
+
+## Sortant
+
+Le RTE ouvre la connexion, cela fonctionne donc depuis un réseau qui n'accepte aucune connexion entrante :
+
+* **Le socket** : le RTE contacte `APP_URL` suivi de `/api/v2/rte/socket`, en `wss://` (`ws://` pour une adresse `http://`), avec son
+  `RTE_TOKEN` et le nom de son runner, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Il rappelle quand le socket tombe
+* **La première fois** : il demande à rejoindre, et son runner attend l'approbation d'un admin dans **Connexions > Runners**, connecté
+  mais sans jobs (voir [Demander à rejoindre](../runners/registration.html#asking-to-join)). Un jeton d'adhésion,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), l'approuve immédiatement. À partir de là, il se connecte avec son propre jeton
+* **Le réseau** : uniquement de la zone du RTE vers l'application, sur le port de l'application, via un proxy quand `HTTPS_PROXY` l'indique. Un reverse
+  proxy devant l'application doit laisser passer le WebSocket sur ce chemin (voir [WebSockets des runners](../production/reverse-proxy.html#runner-websockets))
+* **Le certificat** : le certificat de l'application est vérifié. Indiquez une CA privée avec `NODE_EXTRA_CA_CERTS`, ou, uniquement à l'intérieur d'un réseau de confiance,
+  désactivez la vérification avec [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **Le runner** : il n'a besoin d'aucune adresse, son identifiant RTE ne contient donc que le jeton
+* **Prêt** : `/ready` répond `503` tant que le socket vers l'application n'est pas ouvert
+
+Avec plusieurs nœuds d'application derrière un répartiteur de charge, le nœud que joint le RTE détient son socket. N'importe quel nœud peut lancer un job : le nœud qui détient
+le socket l'envoie au RTE, en moins de deux secondes quand le job a été lancé sur un autre nœud.
+
+---
+
+## Entrant
+
+Le RTE écoute sur son `PORT`, et l'application le contacte à l'adresse de son runner, suivie de `/rte/v1/socket`, avec le jeton du RTE. Avec
+plusieurs nœuds d'application, un seul à la fois détient le socket de chaque runner entrant ; quand ce nœud s'arrête, un autre prend le relais et rappelle.
+
+L'application a besoin du runner du RTE avant de pouvoir le contacter : type RTE, mode **Entrant**, et un identifiant RTE avec l'adresse du RTE et son
+`RTE_TOKEN`. Il y parvient de l'une de deux façons :
+
+| Comment | Que définir |
+|---|---|
+| Le RTE demande à rejoindre | `APP_URL` et [`RTE_URL`](../customization/server.html#env_RTE_URL) (l'adresse que contacte l'application). Le RTE fait un seul appel, `POST /api/v2/rte/register`, et son runner attend l'approbation d'un admin : l'application le contacte une fois approuvé (voir [Demander à rejoindre](../runners/registration.html#asking-to-join)). Avec `RTE_JOIN_TOKEN`, il est approuvé immédiatement. Un RTE entrant avec `APP_URL` mais sans `RTE_URL` refuse de démarrer |
+| Vous ajoutez le runner | Pas d'`APP_URL` : ajoutez le runner dans **Connexions > Runners**, ou dans le [seed de configuration](../seed/), comme dans [Exécuter un RTE](run.html#start-it) |
+
+Le projet Docker Compose, le chart Helm et le contrôleur de l'installeur exécutent leur propre RTE de cette façon, en entrant, déclaré par le seed.
+
+**Via HTTPS.** Avec [`HTTPS=1`](../customization/server.html#env_HTTPS), le RTE sert son socket en TLS, avec la clé et le certificat
+de [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) et [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(`key.pem` et `cert.pem` dans son dossier `certificates` par défaut). Un RTE avec un `RTE_URL` en `https://` envoie ce certificat quand il
+demande à rejoindre, et l'application l'épingle : elle ne contacte le RTE que s'il présente le même certificat, si bien qu'un certificat auto-signé fonctionne sans CA.
+Le RTE journalise l'empreinte du certificat à son démarrage (les 8 premiers chiffres hexadécimaux du SHA-256 de ses octets DER, sous la forme `abcd-ef12`),
+et la boîte de dialogue d'approbation montre celle qu'a reçue l'application : vérifiez qu'elles correspondent avant de l'approuver.
+L'[installeur](../installation/installer.html#a-runner) configure ainsi ses Runners entrants, avec un certificat pour leur propre adresse.
+
+---
+
+## Base de données (obsolète)
+
+Le RTE de la 7.0 à la 7.2 : l'application appelle son API en HTTP, et le RTE réclame le job dans la base de données, y écrit la sortie et tient à jour sa
+propre ligne de runner, avec [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Mode base de données](./#database-mode-deprecated)
+explique en quoi ses étapes diffèrent. Il fonctionne encore en 7.x, avec un avertissement à chaque démarrage, et sera supprimé dans la 8.0.0.
+
+Pour passer un tel RTE à un mode socket, gardez son runner et son jeton :
+
+1. Un runner du [seed de configuration](../seed/) : définissez d'abord `rte_mode: outbound` ou `rte_mode: inbound` pour lui dans le seed (entrant : avec
+   l'adresse que contacte l'application dans le `url` de son identifiant). Le RTE ne peut pas déplacer lui-même un runner issu du seed
+2. Sur le RTE, définissez `RTE_MODE=outbound` avec `APP_URL`, ou `RTE_MODE=inbound` (avec `APP_URL` et `RTE_URL` pour faire son unique
+   appel d'enregistrement), et mettez [`RTE_NAME`](../customization/server.html#env_RTE_NAME) au nom qu'a son runner dans
+   **Connexions > Runners**. Gardez son `RTE_TOKEN`
+3. Retirez `DB_*` et `ENCRYPTION_SECRET` de son environnement, ainsi que `RTE_REGISTER`, que seul le mode base de données lit, puis redémarrez-le
+
+Quand le RTE mis à jour se connecte avec le nom du runner et le jeton propre du runner, l'application passe immédiatement ce runner au mode du RTE,
+sans approbation, et journalise *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. Le runner n'est plus une ligne que son RTE a enregistrée, si bien que le worker ne le supprime jamais quand l'ancien conteneur cesse de répondre. Un
+runner du seed de configuration encore en mode base de données est refusé à la place, avec *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. N'utilisez pas de jeton d'adhésion pour cela : un jeton
+d'adhésion est refusé pour un runner déjà approuvé. Un RTE entrant sans `APP_URL` ne fait aucun appel : mettez plutôt le **Mode** de son runner à
+**Entrant** dans **Connexions > Runners**, et l'application le contacte. L'[installeur](../installation/installer.html#a-72-runner)
+met à jour un Runner 7.2 de cette façon.
+
+---
+
+## Ce qui circule sur le socket
+
+Dans les deux modes socket, l'application envoie au RTE chaque job avec tout ce que le RTE lisait auparavant dans la base de données, et enregistre ce qui revient,
+la sortie, les événements, le journal du job et la fin, exactement une fois. L'application envoie aussi les notifications de fin.
+
+**Le spool.** Chaque lot de sortie, lot d'événements, journal, début et fin est numéroté et écrit dans le fichier spool du job
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) avant d'être envoyé, et conservé jusqu'à ce que l'application indique l'avoir enregistré.
+Après une reconnexion, au même nœud d'application ou à un autre, le RTE renvoie ce qui n'a pas été acquitté, et l'application ignore ce qu'elle a déjà
+enregistré : rien n'est perdu, et rien n'est enregistré deux fois. Gardez le spool sur un volume, afin qu'un RTE qui redémarre envoie encore ce qu'il n'avait pas
+livré. Un playbook qui tournait quand le RTE a redémarré ne peut pas continuer : son job se termine comme abandonné.
+
+**Capacité.** Le RTE exécute jusqu'à [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks à la fois, ou la valeur définie
+sur sa [page de runner](../runners/runner-page.html#an-rtes-settings), et indique à l'application toutes les 20 secondes combien tournent. Un job destiné à un RTE
+plein attend, comme décrit dans [Plusieurs RTE](several.html#several-jobs-on-one-rte).
+
+**Les fichiers du job.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES), ou le paramètre **Fichiers de job** de sa page de runner, indique
+où le RTE obtient les playbooks et les inventaires :
+
+| `RTE_FILES` | D'où viennent les fichiers |
+|---|---|
+| `transfer` (par défaut) | L'application envoie le dossier des playbooks et les inventaires avec le job, chacun empaqueté et nommé par un hash de son contenu. Le RTE les garde empaquetés sous [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), les derniers utilisés jusqu'à [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (1024 Mo par défaut), et ne demande qu'un hash qu'il n'a pas : un dossier inchangé n'est jamais envoyé deux fois. Le RTE n'a besoin d'aucun disque partagé ni d'aucun accès aux dépôts |
+| `local` | Le RTE exécute depuis ses propres dossiers, comme un RTE en mode base de données : montez-y les playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) et les dépôts ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) |
+
+Avec `transfer`, chaque job décompresse ses fichiers dans un dossier privé qui lui est propre, supprimé à la fin du job : aucun job ne voit ce qu'un autre
+a écrit, et aucun fichier d'inventaire ou d'extravars ne reste décompressé sur le disque du RTE. Des RTE peuvent partager un même `RTE_CACHE_PATH` ; chacun garde ses jobs dans
+un dossier à lui, et le dossier d'un RTE qui s'est arrêté (tué en plein job, ou recréé avec un autre nom d'hôte) est supprimé par les autres
+au bout de 10 minutes. Un dossier plus gros que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 par défaut, lu par
+l'application, appliqué sans redémarrage) n'est pas envoyé : le job échoue et indique de monter plutôt le dossier sur le RTE. Le dossier ssh n'est jamais envoyé : le RTE garde sa propre
+clé privée et son `known_hosts` dans `/home/node/.ssh`.
+
+**Hôtes et tâches.** Depuis la 7.3.0, un RTE dans n'importe quel mode enregistre les événements structurés d'un playbook à côté de sa sortie texte : chaque play, tâche et
+résultat d'hôte, et le récapitulatif, écrits par son plugin de callback `af_events`. La page du job les affiche sous **Hôtes et tâches** (voir
+[Suivre un job](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Réseau
+
+Ce qu'il faut ouvrir entre l'application, le RTE et les hôtes gérés, par mode :
+
+| Mode | De | Vers | Port |
+|---|---|---|---|
+| Sortant | Le RTE | L'application, à `APP_URL` | Le port de l'application (`443` derrière la plupart des proxies) |
+| Entrant | Les nœuds d'application | Le RTE, à l'adresse de son runner | Le `PORT` du RTE (`8000`) |
+| Base de données (obsolète) | Le RTE, ainsi que les nœuds d'application et le worker | La base de données, et le RTE | `3306`, et le `PORT` du RTE |
+| Tous les modes | Le RTE | Les hôtes gérés | ssh (`22`), WinRM, leurs API |
+
+En mode socket, le RTE ne se connecte jamais à la base de données. Son API ne répond qu'au socket et aux sondes : `/live`, `/ready`, `/metrics`.
diff --git a/i18n/fr/_configure/rte/run.md b/i18n/fr/_configure/rte/run.md
new file mode 100644
index 0000000..e115698
--- /dev/null
+++ b/i18n/fr/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Exécuter un RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Exécuter un RTE
+{: .no_toc }
+
+Les paramètres de chaque mode, et comment démarrer un RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Paramètres
+
+Ce dont un RTE a besoin dépend de son mode (voir [Modes](modes.html)). Tout RTE lit celles-ci :
+
+| Variable | Signification |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Depuis la 7.3.0 : `outbound` (il contacte l'application), `inbound` (l'application le contacte) ou `database` (obsolète, la valeur par défaut pendant toute la 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Le jeton entre l'application et le RTE, d'au moins 16 caractères ; le RTE refuse de démarrer sans lui |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Combien de playbooks il exécute à la fois, `10` par défaut (`0` ne fixe aucune limite). Un job destiné à un RTE plein attend qu'un playbook se termine |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | À l'arrêt, combien de temps il attend ses playbooks en cours, `25` par défaut ; ceux qui tournent encore se terminent alors comme abandonnés |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Lue par les nœuds d'application et le worker, pas par le RTE : combien de temps un job attend un RTE plein ou en cours d'arrêt, `60` par défaut |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | Le dossier des playbooks et la limite de sortie : lues par le RTE, définissez-les donc dans son environnement |
+| `LISTEN_HOST` | Depuis la 7.3.0 : l'adresse à laquelle se lient ses écouteurs, toutes les interfaces par défaut ; `127.0.0.1` quand rien ne le contacte depuis l'extérieur (un RTE sortant) |
+
+Un RTE en mode socket, `outbound` ou `inbound`, lit aussi celles-ci, et aucune `DB_*` ni `ENCRYPTION_SECRET` :
+
+| Variable | Signification |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'adresse de l'application telle que les gens l'ouvrent, comme `https://forms.example.com`. Sortant : l'adresse qu'il contacte. Entrant : l'adresse de son unique appel d'enregistrement |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (par défaut) : le certificat de l'application doit être valide. `0` accepte n'importe lequel, uniquement à l'intérieur d'un réseau de confiance |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Le nom de son runner, que les formulaires nomment avec `runner:`. Non définie : son id de nœud, `rte-<hostname>-<port>`, qui change avec le conteneur : définissez-la en production |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Facultative, la première fois uniquement : un jeton d'adhésion, créé via l'API, qui approuve son runner immédiatement au lieu d'attendre un admin (voir [Jetons d'adhésion](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Entrant, quand il demande à rejoindre : l'adresse que contacte l'application, comme `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (par défaut) : l'application envoie les playbooks et les inventaires avec le job. `local` : il exécute depuis ses propres dossiers montés |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Où la sortie, les événements et la fin de chaque job attendent que l'application les ait enregistrés, `<persistent>/rte-spool` par défaut : gardez-le sur un volume |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Avec `transfer` : où sont conservés les dossiers envoyés par l'application, `<persistent>/rte-files` par défaut |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Avec `transfer` : combien de place ces dossiers peuvent prendre, `1024` par défaut ; ceux utilisés il y a le plus longtemps partent en premier, et `0` n'en garde aucun |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Lue par l'application, pas par le RTE : le plus gros dossier qu'elle envoie avec `transfer`, `512` par défaut |
+
+Sur un RTE en mode socket, `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` et `RTE_CACHE_MB` peuvent aussi être définies sur sa page de runner,
+dans l'onglet RTE : une valeur saisie là l'emporte sur la variable, qui ne remplit alors qu'un champ laissé vide (voir
+[Les paramètres d'un RTE](../runners/runner-page.html#an-rtes-settings)). Une valeur hors limites est ramenée à sa limite, et le RTE l'indique
+à son démarrage.
+
+Un RTE en mode base de données (obsolète) lit à la place les paramètres de la base de données, et s'enregistre lui-même :
+
+| Variable | Signification |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Les valeurs propres à l'application : le RTE lit ses jobs dans la base de données et y écrit leur sortie |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | L'adresse à laquelle l'application appelle le RTE, comme `http://rte:8000`. Le runner est nommé d'après son hôte (`rte`), les formulaires peuvent donc utiliser `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Dépréciée dans la 7.3.0, avec le mode base de données : un RTE en mode socket rejoint plutôt avec un jeton d'adhésion. `1` (par défaut) : le RTE s'ajoute lui-même dans **Connexions > Runners** à son démarrage, et le premier devient le runner par défaut. `0` : ajoutez-le vous-même là, ou dans le [seed de configuration](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | La valeur propre à l'application, nécessaire uniquement pour s'enregistrer lui-même (le jeton du runner est stocké chiffré) ; omettez-la avec `RTE_REGISTER=0` |
+
+En mode base de données, sans `RTE_URL`, le RTE enregistre son adresse IP et son port sous le nom `rte-<hostname>-<port>`, qui changent quand
+le conteneur est recréé : définissez `RTE_URL` en production. Le worker supprime un runner que le RTE a enregistré lui-même 10 minutes après le
+dernier heartbeat du RTE.
+
+---
+
+## Le démarrer
+
+Le RTE exécute les playbooks, il a donc besoin de son dossier ssh, avec la clé privée et le `known_hosts` qu'utilisent les playbooks, et d'un dossier
+persistant pour son spool et les fichiers qu'envoie l'application. Choisissez le mode :
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Sortant</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Entrant</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Base de données (obsolète)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Démarrez le RTE sur n'importe quel hôte qui joint l'application, avec son propre jeton et le nom que reçoit son runner :
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Il contacte l'application et demande à rejoindre : **Connexions > Runners** montre le runner `rte-dmz` en attente d'approbation, et son journal montre
+l'empreinte de son jeton. Vérifiez que son examen montre la même empreinte, puis **Approuvez**-le (voir
+[Approuver un RTE](../runners/registration.html#approving-an-rte)) : il reçoit des jobs à partir de là, en se connectant avec son propre `RTE_TOKEN`.
+Pour un démarrage sans intervention, ajoutez `-e RTE_JOIN_TOKEN=<a join token, afj_...>`, qui l'approuve immédiatement. Rien n'a besoin de joindre cet
+hôte : ne publiez aucun port. Seuls `/live`, `/ready` et `/metrics` écoutent sur son `PORT`, pour les sondes.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Démarrez le RTE là où l'application le joint. Celui-ci tourne à côté de l'application et exécute les playbooks depuis ses dossiers (`RTE_FILES=local`) :
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Donnez ensuite à l'application son runner : dans le [seed de configuration](../seed/), un identifiant RTE et un runner entrant qui se connecte avec lui :
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Ou ajoutez les deux à la main : l'identifiant dans **Connexions > Identifiants**, type RTE, et le runner dans
+**Connexions > Runners**, type RTE, mode **Entrant**, avec cet identifiant. Pour laisser plutôt le RTE demander à rejoindre, démarrez-le avec
+`APP_URL` et `RTE_URL`, et approuvez-le dans **Connexions > Runners** (voir [Entrant](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Déprécié depuis la 7.3.0 et supprimé dans la 8.0.0. Le RTE exécute les playbooks depuis son propre disque, montez donc aussi le volume persistant de l'application
+(playbooks, dépôts, fichiers téléversés) et son dossier ssh sur lui. Un exemple Docker, avec l'application joignable sous le nom `ansibleforms` sur le
+même réseau :
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Gardez un RTE entrant hors du réseau public : son socket répond à tout appelant qui a le jeton. `docker stop` n'attend que 10 secondes avant
+de tuer un conteneur, donnez donc au RTE un délai d'arrêt plus long (`--stop-timeout`, ou `stop_grace_period` dans compose) ou diminuez
+`RTE_DRAIN_SECONDS`. Kubernetes attend 30 secondes par défaut.
+
+L'[installeur](../installation/installer.html) met en place un RTE sortant ou entrant sur un serveur dédié, avec Docker, Podman ou
+[sans conteneurs](../installation/native.html), et affiche l'empreinte avec laquelle l'approuver. Pour exécuter à la main un RTE dans un autre datacenter,
+suivez [Un autre datacenter](another-datacenter.html).
diff --git a/i18n/fr/_configure/rte/several.md b/i18n/fr/_configure/rte/several.md
new file mode 100644
index 0000000..4f2295c
--- /dev/null
+++ b/i18n/fr/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Plusieurs RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Plusieurs RTE
+{: .no_toc }
+
+Combien de playbooks exécute un RTE, davantage de RTE comme runners ou comme répliques, et ce qui se passe quand l'un s'arrête ou meurt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Plusieurs jobs sur un RTE
+
+Un RTE exécute jusqu'à [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks côte à côte, 10 par
+défaut (`0` ne fixe aucune limite). Un job destiné à un RTE plein n'est pas réclamé. En mode socket, l'application ne l'envoie pas tant que le dernier
+rapport de santé du RTE ne montre aucun emplacement libre, et un RTE plein ou en cours d'arrêt répond `refused` comme occupé ; en mode base de données, le RTE répond
+`503`. Dans les deux cas, l'application écrit une fois `Waiting for a free slot on RTE <name>` dans la sortie et propose à nouveau le job toutes les 10 secondes,
+pendant [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) au plus (60 par défaut). Le job échoue alors avec
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Un job interrompu pendant son attente se termine `aborted` sans jamais
+atteindre le RTE.
+
+---
+
+## Plusieurs RTE
+
+L'application ne répartit pas d'elle-même les jobs entre les runners : chaque job va à un seul runner, celui que nomme le formulaire ou celui
+par défaut. Davantage de conteneurs RTE aident de deux façons :
+
+* **Comme runners à part entière** : chaque RTE a son propre `RTE_NAME` et rejoint comme runner à part entière : il demande à rejoindre et un admin
+  l'approuve, ou il présente un jeton d'adhésion (voir [Enregistrement](../runners/registration.html)). Un formulaire en choisit un avec `runner: <name>`,
+  par exemple un RTE avec les collections VMware, ou un dans une autre zone réseau ; les autres tournent sur le RTE par défaut
+* **Comme répliques derrière une même adresse** (mode base de données uniquement) : plusieurs conteneurs RTE avec le même `RTE_URL` et le même `RTE_TOKEN`,
+  comme les pods derrière un Service Kubernetes, partagent un runner, et l'adresse répartit les appels entre eux. Une réplique pleine répond
+  `503`, et l'essai suivant peut tomber sur une autre. L'application suit un job via la base de données, peu importe donc quelle réplique
+  répond à ses appels de statut
+
+En mode socket (voir [Modes](modes.html)), un runner détient un socket vers un seul RTE, et un second RTE qui se connecte avec le même
+`RTE_NAME` reprend le socket au premier. Donnez à chaque RTE un nom et un runner à lui, et laissez les formulaires choisir entre eux avec
+`runner:`.
+
+Chaque RTE en mode base de données écrit un heartbeat dans la base de données toutes les 10 secondes, et celui qui s'enregistre lui-même vérifie sa ligne de runner toutes les
+30 secondes. Pour un RTE en mode socket, le nœud d'application qui détient son socket écrit le heartbeat pour lui toutes les 20 secondes, tant que le
+socket est ouvert. La page **Statut** liste chaque RTE avec sa version. Le worker supprime un runner qu'un RTE en mode base de données a enregistré
+lui-même dès que ce RTE n'a écrit aucun heartbeat pendant 10 minutes, et quand le runner par défaut est une telle ligne dont le RTE s'est arrêté, le prochain RTE
+qui vérifie prend le rôle par défaut. Un runner issu du seed de configuration, ajouté à la main ou ayant rejoint via un socket n'est jamais supprimé de cette façon.
+
+---
+
+## Quand un RTE s'arrête ou meurt
+
+**Quand un RTE s'arrête.** Sur `SIGTERM` (`docker stop`, une mise à jour progressive, une réduction d'échelle), le RTE cesse de prendre des jobs : `/ready` répond `503`,
+et un nouveau job est refusé comme occupé (`503` en mode base de données), si bien que l'application attend, ou, en mode base de données, l'adresse l'envoie à une autre
+réplique. Les playbooks en cours disposent de [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) pour se terminer, 25 par défaut,
+puis le RTE s'arrête.
+
+**Quand un RTE meurt.** Un conteneur tué (mémoire épuisée, nœud perdu, fin du délai d'arrêt) emporte ses playbooks avec lui : rien
+ne les déplace vers un autre RTE, et rien ne les exécute à nouveau. Leurs jobs sont terminés comme `abandoned`, par le RTE lui-même ou par l'application quand il
+revient sous le même id, qu'un conteneur redémarré conserve (`rte-<hostname>-<port>`), ou par le worker, une fois que le heartbeat du RTE
+a deux minutes. Vérifiez sur les hôtes gérés ce qu'a fait le playbook avant de le relancer.
+
+**Pendant qu'un RTE est indisponible.** En mode socket, un nouveau job pour lui attend son socket, jusqu'à `RTE_QUEUE_MINUTES` plus une minute, puis
+échoue avec *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+En mode base de données, il échoue immédiatement avec *the RTE at ... is unreachable*, sauf si une autre réplique répond à son adresse.
diff --git a/i18n/fr/_configure/runners.md b/i18n/fr/_configure/runners.md
new file mode 100644
index 0000000..03aac5c
--- /dev/null
+++ b/i18n/fr/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Runners
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runners
+{: .no_toc }
+
+Où les jobs s'exécutent : des conteneurs d'environnement d'exécution pour les playbooks, et AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins pour les modèles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : ajoutez les runners sur lesquels s'exécutent vos jobs, choisissez celui par défaut de chaque type, approuvez les RTE qui demandent à rejoindre, testez-les.
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [La page des runners](runners/list.html) | La liste des runners, l'ajout d'un runner, son activation ou sa désactivation, et le runner par défaut de chaque type |
+| [Types de runners](runners/types.html) | Les produits que peut être un runner, leur adresse et leur accès |
+| [Enregistrement](runners/registration.html) | Comment un RTE demande à rejoindre et est approuvé, les jetons d'adhésion pour les installations sans intervention, et le mode base de données |
+| [La page d'un runner](runners/runner-page.html) | Les onglets d'un runner, le mode et la connexion d'un RTE, et Tester la connexion |
+| [Qui gère les runners](runners/permissions.html) | Qui peut ajouter, modifier et tester des runners |
+
+
+---
+
+## Fonctionnement
+
+Depuis la version 7, l'application n'exécute rien elle-même : chaque job s'exécute sur un **runner**, ajouté dans **Connexions > Runners**.
+Le type d'un formulaire décide du type de runner dont il a besoin :
+
+| Type de formulaire | S'exécute sur un runner de type | Ce qui s'exécute |
+|---|---|---|
+| `ansible` | RTE | Un playbook, dans un conteneur d'environnement d'exécution |
+| `awx`, `aap`, `ascender` | AWX (les variantes AWX, AAP et Ascender) | Un modèle de job ou de workflow |
+| `semaphore` | Semaphore | Un modèle Semaphore UI |
+| `rundeck` | Rundeck | Un job Rundeck |
+| `jenkins` | Jenkins | Un job Jenkins |
+
+Un formulaire `workflow` ou `subform` n'a pas de runner propre : chaque nœud d'un [workflow](workflows/) choisit le sien. Un nœud
+avec un `runner:` s'exécute sur ce runner (un RTE, ou un modèle ou un job sur AWX, Semaphore, Rundeck ou Jenkins), tout autre sur
+le RTE par défaut, si bien que les nœuds d'un même job peuvent s'exécuter sur des runners différents. Le formulaire `multistep`, déprécié depuis la 7 et
+remplacé par les workflows, fonctionne de la même façon : chacune de ses étapes s'exécute sur le runner dont son propre type a besoin.
+
+Un formulaire choisit son runner de l'une de deux façons :
+
+- **Par son nom** : `runner: <name>` sur le formulaire, sur un nœud de workflow, ou sur une étape d'un multistep déprécié (aussi dans les
+  paramètres du formulaire du concepteur). Le runner doit être du type dont le formulaire a besoin, sinon le job échoue. L'ancien `awx: <name>`
+  fonctionne toujours, journalise un avertissement de dépréciation, et disparaîtra dans la 8.
+- **Par défaut** : un formulaire qui ne nomme aucun runner s'exécute sur le runner par défaut de son type. Sans lui, le job échoue
+  avec un message qui indique quel type de runner ajouter.
+
+Un runner désactivé dans **Connexions > Runners** ne reçoit aucun job, ni par son nom ni par défaut : le job échoue et indique de l'activer
+ou de nommer un autre runner (voir [Par défaut et Activé](runners/list.html#default-and-enabled)).
+
diff --git a/i18n/fr/_configure/runners/list.md b/i18n/fr/_configure/runners/list.md
new file mode 100644
index 0000000..46a6c8b
--- /dev/null
+++ b/i18n/fr/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: La page des runners
+parent: Runners
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# La page des runners
+{: .no_toc }
+
+La liste des runners, l'ajout d'un runner, son activation ou sa désactivation, et le runner par défaut de chaque type
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La liste
+
+La page **Connexions > Runners** liste chaque runner avec ces colonnes :
+
+| Colonne | Signification |
+|---|---|
+| Activé | S'il reçoit des jobs. Un runner désactivé ne reçoit aucun job, même comme runner par défaut de son type. |
+| Nom | Comment les formulaires y font référence, avec `runner: <name>`. |
+| Type | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck ou Jenkins. Le runner par défaut de son type a une pastille **Par défaut** après lui. |
+| Description | À quoi il sert. |
+
+**Colonnes** en ajoute deux autres, masquées par défaut : **Mode**, le mode d'un RTE (Sortant, Entrant ou Base de données (obsolète), voir
+[Modes](../rte/modes.html)), et **Connexion**, si un nœud d'application détient un socket vers un RTE en mode socket : **Connecté** ou
+**Non connecté**.
+
+Depuis la 7.3.0, les runners en attente d'approbation ne figurent pas dans la liste mais dans un avis au-dessus, voir [Approuver un RTE](registration.html#approving-an-rte).
+**Ajouter un runner** ouvre une boîte de dialogue en étapes : **Runner** (nom et description), **Type** et **Identifiants**, avec une étape **Mode** après
+**Type** pour un RTE (Sortant, la valeur par défaut pour un nouveau, Entrant ou Base de données (obsolète)) : quatre étapes pour un RTE, trois pour les
+autres. Dans l'étape **Type**, chaque produit a une indication : celle du RTE donne son nom complet, *Environnement d'exécution*. Une ligne ouvre la page
+du runner, et son menu propose :
+
+| Action | Ce qu'elle fait |
+|---|---|
+| Modifier | Ouvre sa page |
+| Tester la connexion | Vérifie qu'il répond et accepte son identifiant, voir [Tester la connexion](runner-page.html#test-connection) |
+| Activer, Désactiver | L'active ou le désactive, selon son état |
+| Modifier les identifiants | Ouvre l'onglet Identifiants de sa page |
+| Supprimer | Le retire |
+
+---
+
+## Par défaut et Activé
+
+Le runner par défaut de chaque type est celui où s'exécutent les formulaires de ce type quand ils ne nomment aucun runner :
+
+| Par défaut pour | Où s'exécutent ces formulaires quand ils ne nomment aucun runner |
+|---|---|
+| Formulaires playbook | Les formulaires `ansible`, sur un RTE |
+| Formulaires AWX, AAP et Ascender | Les formulaires `awx`, `aap` et `ascender`, sur un runner AWX |
+| Formulaires Semaphore | Les formulaires `semaphore` |
+| Formulaires Rundeck | Les formulaires `rundeck` |
+| Formulaires Jenkins | Les formulaires `jenkins` |
+
+Le premier runner d'un type devient celui par défaut, si bien qu'un seul runner par type ne nécessite aucune étape supplémentaire. Pour faire d'un autre runner celui par défaut,
+activez l'interrupteur **Par défaut** sur sa page (voir [La page d'un runner](runner-page.html)).
+
+Un runner désactivé reste listé avec ses paramètres, mais aucun job ne lui est envoyé, y compris comme runner par défaut de son type. Un job qui lui est destiné échoue avec
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Activez-le ou désactivez-le avec **Activer** ou **Désactiver** dans le menu de sa ligne, ou avec l'interrupteur **Activé** sur sa page. Un nouveau runner est activé, et les
+runners qui existaient avant la 7.3.0 sont activés après la mise à jour. Le [seed de configuration](../seed/example.html) peut en désactiver un avec
+`enabled: false`.
diff --git a/i18n/fr/_configure/runners/permissions.md b/i18n/fr/_configure/runners/permissions.md
new file mode 100644
index 0000000..b914f58
--- /dev/null
+++ b/i18n/fr/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Qui gère les runners
+parent: Runners
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Qui gère les runners
+{: .no_toc }
+
+Qui peut ajouter, modifier et tester des runners
+{: .fs-6 .fw-300 }
+
+Un runner reçoit les identifiants de chaque job qu'il exécute, c'est pourquoi seul le rôle **admin** ajoute, modifie, active ou désactive et supprime des runners,
+et approuve ou refuse un RTE qui a demandé à rejoindre. Les utilisateurs ayant accès aux paramètres les voient et peuvent les tester, mais pas les modifier.
+
+Un runner déclaré dans le [seed de configuration](../seed/) est en lecture seule sur cette page : modifiez-le plutôt dans le fichier seed.
diff --git a/i18n/fr/_configure/runners/registration.md b/i18n/fr/_configure/runners/registration.md
new file mode 100644
index 0000000..76aaac5
--- /dev/null
+++ b/i18n/fr/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Enregistrement
+parent: Runners
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Enregistrement
+{: .no_toc }
+
+Comment un RTE demande à rejoindre et est approuvé, les jetons d'adhésion pour les installations sans intervention, et le mode base de données
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Demander à rejoindre
+
+Depuis la 7.3.0, un RTE en mode socket (`outbound` ou `inbound`) que l'application ne connaît pas encore demande à rejoindre, et un admin l'approuve.
+Il se présente avec son propre `RTE_TOKEN` et son `RTE_NAME` : un RTE sortant lors de son premier contact avec l'application, un RTE entrant lors de son unique
+appel d'enregistrement. Sans jeton d'adhésion, l'application alors :
+
+1. Stocke le `RTE_TOKEN` du RTE dans un nouvel identifiant de type RTE nommé `<name>-rte` (avec un numéro ajouté quand ce nom est pris), et
+   pour un RTE entrant son adresse, `RTE_URL`
+2. Ajoute un runner nommé d'après `RTE_NAME`, de type RTE, dans le mode du RTE, qui se connecte avec cet identifiant, marqué **En attente d'approbation**
+   et désactivé. Sa description indique l'hôte depuis lequel il a fait la demande
+
+Un RTE sortant reste connecté pendant qu'il attend, mais ne reçoit aucun job. L'application ne contacte pas un RTE entrant tant qu'il n'est pas approuvé. Les deux journalisent
+qu'ils attendent qu'un admin les approuve dans **Connexions > Runners**, avec l'empreinte de leur jeton.
+
+Un RTE entrant avec un `RTE_URL` en `https://` envoie aussi son certificat quand il demande à rejoindre, et l'application l'épingle : à partir de là,
+l'application ne contacte ce RTE que s'il présente le même certificat, si bien qu'un certificat auto-signé fonctionne sans CA (voir [Entrant](../rte/modes.html#inbound)).
+
+Au plus 20 RTE attendent l'approbation en même temps : les suivants sont refusés jusqu'à ce que certains soient approuvés ou refusés. Une demande que personne ne traite dans les
+24 heures est supprimée par le worker, avec son identifiant.
+
+Un RTE nommé d'après un runner que l'application connaît déjà, mais avec un autre jeton, est refusé et ne demande pas à rejoindre. Donnez-lui le jeton de ce runner,
+ou supprimez le runner pour qu'il demande à rejoindre. Un [jeton d'adhésion](#join-tokens) n'aide que tant que ce runner attend encore l'approbation.
+
+---
+
+## Approuver un RTE
+
+Les runners en attente d'approbation quittent la liste de **Connexions > Runners** pour un avis orange au-dessus d'elle, comme
+**2 Runners attendent l'approbation**, avec une ligne par runner : son nom, son hôte, son adresse IP, son mode, son adresse et son empreinte.
+La cloche de l'en-tête les compte, pour les utilisateurs qui peuvent voir les runners (voir [la cloche](../jobs/#the-jobs-page)).
+
+Un clic sur l'avis ouvre la boîte de dialogue **Examiner l'approbation** pour chaque runner tour à tour ; un clic sur un nom n'ouvre que celui-là.
+Sa page montre les mêmes informations dans un encadré jaune, **Ce RTE demande à rejoindre**. Vérifiez que c'est bien un RTE que vous avez démarré avant de l'approuver :
+
+| Champ | Ce qu'il montre |
+|---|---|
+| Empreinte | Les 8 premiers chiffres hexadécimaux du SHA-256 de son `RTE_TOKEN`, sous la forme `abcd-ef12`. Le RTE la journalise à son démarrage, et l'[installeur](../installation/installer.html#a-runner) l'affiche à la fin. Elle doit être identique |
+| Empreinte du certificat | Dans la boîte de dialogue, pour un RTE entrant en HTTPS : les 8 premiers chiffres hexadécimaux du SHA-256 du certificat qu'épingle l'application (ses octets DER), sous la forme `abcd-ef12`. Le RTE la journalise à son démarrage et l'[installeur](../installation/installer.html#a-runner) l'affiche à la fin. Elle doit être identique |
+| Hôte | L'hôte sur lequel il tourne |
+| Adresse IP | L'adresse depuis laquelle il a appelé l'application |
+| Mode | Sortant ou Entrant |
+| URI | L'adresse d'un RTE entrant, là où l'application le contacte |
+| Version | Sa version |
+| Demandé le | Quand il a demandé à rejoindre |
+
+**Approuver** et **Refuser**, dans la boîte de dialogue ou dans l'encadré de sa page, décident :
+
+| Action | Ce qui se passe |
+|---|---|
+| Approuver | Le runner est activé et reçoit des jobs dès maintenant. Il devient le runner par défaut de son type quand il n'y en a aucun |
+| Refuser | Le runner est supprimé avec son identifiant, et son socket est fermé. Le RTE peut redemander à rejoindre ; il attend alors à nouveau l'approbation |
+
+Seul un admin approuve ou refuse un RTE.
+
+---
+
+## Jetons d'adhésion
+
+Un jeton d'adhésion approuve un RTE immédiatement, pour les installations sans intervention : un RTE démarré avec
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), ou un Runner installé avec le `--join` de l'installeur, le présente une fois
+et son runner est ajouté activé, sans attente. Les jetons d'adhésion n'ont pas de page dans l'interface : un admin les crée via
+l'[API REST](../api/), sous `/api/v2/runner` :
+
+| Appel | Ce qu'il fait |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Crée un jeton d'adhésion. Le corps contient son `name`, et en option `expiresInHours` (absent : il n'expire jamais) et `maxUses` (absent : un nombre quelconque de RTE) |
+| `GET /api/v2/runner/jointoken` | Liste les jetons d'adhésion, du plus récent au plus ancien, avec leurs utilisations et s'ils sont encore utilisables ; jamais les jetons eux-mêmes |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Le révoque : il n'ajoute plus aucun runner, et reste dans la liste |
+| `DELETE /api/v2/runner/jointoken/<id>` | Le supprime |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+La réponse contient le jeton, qui commence par `afj_`, cette seule fois : seul son SHA-256 est stocké. Un RTE qui le présente reçoit le même
+identifiant et le même runner qu'un RTE qui [demande à rejoindre](#asking-to-join), activé, et sa description nomme le jeton d'adhésion. À partir de là, le
+RTE se connecte avec son propre jeton, si bien que le jeton d'adhésion peut expirer ou être révoqué sans l'affecter. Révoquer ou supprimer un jeton d'adhésion
+laisse les runners qu'il a ajoutés.
+
+Un jeton d'adhésion ne donne jamais un nouveau jeton à un runner approuvé. Quand un runner RTE de ce nom existe déjà :
+
+| Le runner | Ce qui se passe |
+|---|---|
+| Attend l'approbation | Il reçoit le nouveau jeton dans son identifiant, et attend toujours l'approbation d'un admin |
+| Est approuvé | Refusé avec `409` : *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. Le jeton d'adhésion n'est pas consommé |
+| Provient du [seed de configuration](../seed/) | Refusé : *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Un RTE réinstallé avec un nouveau jeton se connecte donc avec le jeton de l'identifiant de son runner, ou un admin change ce jeton
+dans **Connexions > Identifiants**, ou supprime le runner pour que le RTE rejoigne comme nouveau.
+
+---
+
+## Enregistrement en mode base de données
+
+Un RTE en mode base de données, déprécié depuis la 7.3.0, s'enregistre lui-même par défaut, à son `RTE_URL` ou sinon à sa propre adresse et son propre port. Le
+worker supprime un tel runner dès que son RTE n'a écrit aucun heartbeat pendant 10 minutes. Un runner ajouté à la main, par le seed de configuration ou par un
+RTE en mode socket n'est jamais supprimé de cette façon.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), qui active ou désactive cet enregistrement, est dépréciée dans la 7.3.0 avec
+le mode base de données : un RTE en mode socket demande à rejoindre, ou rejoint avec un jeton d'adhésion. Pour gérer vous-même de tels runners en attendant, démarrez le
+RTE avec `RTE_REGISTER=0` et ajoutez-le ici avec le type RTE, le mode **Base de données (obsolète)**, et un identifiant RTE avec son adresse et le
+même jeton. Pour le passer à un mode socket, voir [Modes](../rte/modes.html#database-deprecated).
diff --git a/i18n/fr/_configure/runners/runner-page.md b/i18n/fr/_configure/runners/runner-page.md
new file mode 100644
index 0000000..f8b68fb
--- /dev/null
+++ b/i18n/fr/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "La page d'un runner"
+parent: Runners
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# La page d'un runner
+{: .no_toc }
+
+Les onglets d'un runner, le mode, la connexion et les paramètres d'un RTE, et Tester la connexion
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Onglets
+
+La page d'un runner affiche les étapes de sa boîte de dialogue sous forme d'onglets, plus ce qui s'exécute sur lui :
+
+| Onglet | Ce qu'il contient |
+|---|---|
+| Détails | Le nom et la description, l'interrupteur **Par défaut** et l'interrupteur **Activé**, identiques pour tous les types de runners |
+| Type | Le produit, comme dans la boîte de dialogue. Pour un RTE, aussi son **Mode** : **Base de données (obsolète)**, **Entrant** ou **Sortant**, le `RTE_MODE` avec lequel tourne son RTE (voir [Modes](../rte/modes.html)) |
+| RTE | Propre à un RTE : son **Mode** en toutes lettres et, en mode socket, sa **Connexion** et ses paramètres (voir [Les paramètres d'un RTE](#an-rtes-settings)) |
+| Identifiants | L'**Identifiant** avec lequel il se connecte, un identifiant de Connexions > Identifiants du type du runner, qui contient son jeton ou son accès et l'adresse de son serveur. Celui d'un RTE contient son `RTE_TOKEN`, et l'adresse du RTE sauf s'il est sortant. **Projet** pour Semaphore, Rundeck et Jenkins |
+| Formulaires | Les formulaires qui s'exécutent sur lui, et comment : **Le nomme** ou **Comme runner par défaut**. Une ligne ouvre le formulaire |
+| Jobs | Les 100 derniers jobs exécutés sur lui, avec leur statut, leur début, leur fin et leur durée. Une ligne ouvre le job |
+
+Chaque onglet a sa propre adresse, comme `/settings/runners/<id>/rte`, si bien qu'un lien ou un favori l'ouvre. Un runner sans cet onglet s'ouvre sur
+Détails.
+
+Les deux interrupteurs de l'onglet Détails sont enregistrés immédiatement. **Par défaut** fait du runner celui par défaut de son type ; il se désactive en faisant
+d'un autre runner celui par défaut. **Activé** active ou désactive le runner : désactivé, aucun job ne lui est envoyé, y compris comme runner par défaut de son type (voir
+[Par défaut et Activé](list.html#default-and-enabled)).
+
+Un RTE qui a demandé à rejoindre s'ouvre avec un encadré jaune, **Ce RTE demande à rejoindre**, avec son empreinte et ce qu'il a dit de lui-même, et
+**Approuver** et **Refuser** (voir [Approuver un RTE](registration.html#approving-an-rte)). Un runner du [seed de configuration](../seed/) l'indique
+en haut de sa page, et est en lecture seule.
+
+---
+
+## Les paramètres d'un RTE
+
+L'onglet RTE gère un RTE depuis l'application, sans modifier son environnement sur la machine où il tourne.
+
+**Connexion.** Un RTE en mode socket affiche un badge : **Connecté** ou **Non connecté**. Au survol, **Connecté** montre le nœud d'application
+qui détient son socket, la version du RTE, et combien de ses jobs tournent. **Non connecté** signifie qu'aucun nœud d'application ne détient de socket vers lui :
+vérifiez que le RTE tourne, son adresse ou `APP_URL`, et son jeton.
+
+**Paramètres.** Un RTE en mode sortant ou entrant a quatre paramètres, chacun vide par défaut :
+
+| Paramètre | Équivalent de | Ce qu'il fait |
+|---|---|---|
+| Jobs simultanés max. | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Combien de playbooks il exécute à la fois, `10` par défaut ; `0` ne fixe aucune limite |
+| Cache des fichiers | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Quelle quantité des fichiers de job envoyés par l'application il conserve, en Mo, `1024` par défaut ; `0` n'en garde aucun |
+| Délai d'arrêt | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Combien de temps un RTE qui s'arrête attend ses playbooks en cours, `25` secondes par défaut |
+| Fichiers de job | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Transfert** : l'application envoie les fichiers d'un job avec le job. **Local** : il exécute depuis ses propres dossiers montés |
+
+**Quelle valeur l'emporte.** Une valeur sur la page l'emporte sur la même variable définie sur le RTE. Un champ laissé vide utilise la variable propre du RTE,
+sinon la valeur par défaut. Sous chaque champ, la page indique laquelle : **Remplace RTE_MAX_JOBS défini sur le RTE (3)**, ou **Vide : le RTE utilise sa
+propre RTE_MAX_JOBS, 3** ; le texte indicatif montre la valeur que représente un champ vide.
+
+**Comment ils atteignent le RTE.** Les paramètres sont stockés avec le runner dans la base de données de l'application. L'application les envoie par le socket du RTE
+quand il se connecte et chaque fois qu'ils sont enregistrés, et le RTE les applique immédiatement : un cache plus petit est réduit, une nouvelle limite compte à partir du
+job suivant. Le RTE ne les garde qu'en mémoire et n'écrit aucun fichier : après un redémarrage, il les reçoit à nouveau en se connectant, avant son premier job.
+
+Un RTE en mode base de données (obsolète) n'a pas de socket : il lit ces paramètres depuis ses propres variables, et l'onglet l'indique.
+
+---
+
+## Tester la connexion
+
+Les boutons en haut à droite agissent sur le runner tel qu'il est enregistré.
+
+À côté d'**Enregistrer** se trouvent **Tester la connexion** et **Supprimer**, et dans l'onglet Identifiants **Ajouter un identifiant**, qui crée un identifiant du
+type du runner et le choisit. Un jeton ou un mot de passe n'est plus jamais affiché une fois enregistré : changez-le sur l'identifiant.
+
+**Tester la connexion** vérifie que le runner répond et accepte son jeton ou son accès, et l'indique dans un message : **Runner connection is
+OK**, ou la raison de l'échec. Il n'exécute aucun job. Pour un RTE, il vérifie aussi le contrat que parle le RTE (voir
+[Le contrat](../rte/images.html#the-contract)) :
+
+| RTE | Ce que lit le test | Quand il échoue |
+|---|---|---|
+| Sortant ou Entrant | Qui détient son socket, tel que chaque nœud d'application l'enregistre, et ce qu'a dit le RTE à sa connexion. Il n'appelle rien | Aucun nœud d'application ne détient de socket vers lui : *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, ou pour un RTE entrant, *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Ou le RTE parle un autre contrat que le 3 |
+| Base de données (obsolète) | Le `/rte/v1/health` du RTE, appelé avec son jeton | Le RTE ne répond pas à son adresse, refuse le jeton, ou parle un autre contrat que le 2 |
+
+Le badge **Connexion** de l'onglet RTE montre le même état du socket sans test.
diff --git a/i18n/fr/_configure/runners/types.md b/i18n/fr/_configure/runners/types.md
new file mode 100644
index 0000000..29f7c5d
--- /dev/null
+++ b/i18n/fr/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Types de runners
+parent: Runners
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Types de runners
+{: .no_toc }
+
+Les produits que peut être un runner, leur adresse et leur accès
+{: .fs-6 .fw-300 }
+
+L'étape **Type** propose un choix par produit, chacun avec une indication ; celle du RTE donne son nom en toutes lettres, *Environnement d'exécution*. AAP et
+Ascender sont stockés comme un runner de type `awx` avec une variante (`aap` ou `ascender`), ce qu'utilise aussi le seed de configuration :
+
+| Type | Exemple d'URI | Projet | Authentification |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | Le `RTE_TOKEN` du RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Un jeton d'API, ou un utilisateur et un mot de passe |
+| Ascender | `https://ascender.example.com/api/v2` | | Un jeton d'API, ou un utilisateur et un mot de passe |
+| AWX | `https://awx.example.com/api/v2` | | Un jeton d'API, ou un utilisateur et un mot de passe |
+| Jenkins | `https://jenkins.example.com` | Le dossier qui contient les jobs (facultatif) | Un utilisateur et son jeton d'API |
+| Rundeck | `https://rundeck.example.com` | Le nom du projet | Le jeton d'API d'un utilisateur |
+| Semaphore | `https://semaphore.example.com` | L'id du projet, le nombre dans `/project/<id>` | Le jeton d'API d'un utilisateur |
+
+Une adresse AWX, AAP ou Ascender porte son chemin d'API : `/api/v2`, ou `/api/controller/v2` pour AAP 2.5 et ultérieur.
+Un RTE est l'image AnsibleForms démarrée avec `AF_ROLE=rte` ; la façon d'en exécuter un est décrite dans
+[Environnements d'exécution](../rte/).
diff --git a/i18n/fr/_configure/secret-stores/cyberark.md b/i18n/fr/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..b17928c
--- /dev/null
+++ b/i18n/fr/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Coffres de secrets
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Lisez les identifiants depuis le CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Expérimental.** Pas encore testé sur une installation CyberArk réelle ; merci de nous faire part de vos constats.
+
+Le CCP est l'interface REST de l'Application Access Manager de CyberArk.
+
+---
+
+## Champs du coffre
+
+En plus des [champs communs à tous les coffres](./#adding-a-store), un coffre CyberArk a ces champs :
+
+| Champ | Signification |
+|---|---|
+| Identifiant | Un identifiant **CyberArk** de [Connexions > Identifiants](../credentials.html) : l'URL de base du CCP, par ex. `https://ccp.example.com` (`/AIMWebService/api/Accounts` est ajouté), ses paramètres TLS, son AppID (l'application définie pour AnsibleForms dans CyberArk), et un certificat client et une clé en PEM, uniquement quand l'AppID en exige un. |
+
+---
+
+## Référence du secret
+
+La référence du secret identifie le compte sous la forme de paires clé-valeur séparées par `;` :
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Clés autorisées : `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` transmet le reste de la référence comme une requête CCP native, avec `QueryFormat=Exact`
+  sauf si vous le définissez autrement.
+- Un `AppID` dans la référence est ignoré : c'est toujours l'AppID du coffre qui est utilisé.
+- Le mot de passe du compte (`Content`) devient le mot de passe ; `UserName`, `Address`, `Port` et
+  `Database` remplissent l'utilisateur, l'hôte, le port et le nom de la base de données.
+
+---
+
+## Options supplémentaires
+
+Les options supplémentaires du coffre se définissent sous forme d'objet JSON :
+
+| Clé | Signification |
+|---|---|
+| `reason` | Envoyée comme `Reason` quand la référence n'en a pas, pour l'audit de CyberArk. |
+| `check_ref` | Une référence que **Tester la connexion** lit réellement. Sans elle, le test vérifie seulement que le CCP répond et accepte l'AppID. |
+| `timeout_ms` | Délai d'expiration de la requête, 10000 par défaut. |
+
+Par exemple, pour envoyer une raison et laisser **Tester la connexion** lire un compte de test :
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/fr/_configure/secret-stores/hashicorp-vault.md b/i18n/fr/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..54a643f
--- /dev/null
+++ b/i18n/fr/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Coffres de secrets
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Lisez les identifiants depuis HashiCorp Vault, depuis KV v1 ou v2 ou un moteur de secrets dynamiques
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Champs du coffre
+
+En plus des [champs communs à tous les coffres](./#adding-a-store), un coffre HashiCorp Vault a ces champs :
+
+| Champ | Signification |
+|---|---|
+| Identifiant | Un identifiant **HashiCorp Vault** de [Connexions > Identifiants](../credentials.html) : l'adresse du Vault, ses paramètres TLS, et le jeton comme mot de passe, avec un accès en lecture aux chemins qu'utilisent vos identifiants. **Ajouter un identifiant** en crée un de ce type. AnsibleForms ne renouvelle pas le jeton. |
+| Namespace | Le namespace Vault Enterprise, envoyé comme `X-Vault-Namespace`. Affiché une fois **Vault Enterprise** activé, à l'étape **Type**. |
+| Version KV | `2` (par défaut) ou `1`. |
+| Montage par défaut | Utilisé pour une référence sans barre oblique, par ex. `myapp` devient `secret/data/myapp`. |
+
+La référence du secret est le chemin, par ex. `secret/myapp/prod`. Pour KV v2, le segment `/data/`
+est inséré quand vous l'omettez.
+
+---
+
+## Identifiants de base de données dynamiques
+
+Une référence de la forme `<mount>/creds/<role>`, par ex. `database/creds/readonly`, lit depuis un
+moteur de secrets dynamiques comme le moteur database de Vault. Vault crée alors un nouveau compte de base de données
+à chaque lecture, valable pendant la durée du bail.
+
+- Un compte est réutilisé pendant 80 % de son bail, et non la durée de cache ; avec un cache à `0`, chaque requête en lit un nouveau.
+- Vault ne renvoie qu'un utilisateur et un mot de passe : mettez le reste de la connexion dans la ligne de l'identifiant.
+- Le bail n'est jamais révoqué de façon anticipée ; le compte expire quand Vault met fin au bail.
diff --git a/i18n/fr/_configure/secret-stores/index.md b/i18n/fr/_configure/secret-stores/index.md
new file mode 100644
index 0000000..27249b3
--- /dev/null
+++ b/i18n/fr/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Coffres de secrets
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Coffres de secrets
+{: .no_toc }
+
+Lisez les identifiants depuis un gestionnaire de secrets au lieu de les stocker dans AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : connectez un gestionnaire de secrets, et laissez les identifiants y lire leur utilisateur et leur mot de passe.
+
+---
+
+## Fonctionnement
+
+Un **coffre de secrets** est une connexion vers un gestionnaire de secrets, ajoutée dans
+**Connexions > Coffres de secrets**. Un **identifiant** peut alors nommer un coffre et un emplacement dans celui-ci
+(la *référence du secret*). Quand un formulaire, un playbook ou une expression utilise cet identifiant :
+
+- **l'utilisateur** et **le mot de passe** sont lus depuis le coffre, à chaque fois (dans la limite de la durée de cache du coffre) ;
+- **l'hôte**, **le port** et **la base de données** restent ceux de la ligne de l'identifiant. Quand la ligne laisse
+  l'un d'eux vide et que le secret le contient, la valeur du secret est utilisée.
+
+Les formulaires continuent de faire référence à l'identifiant par son nom, si bien que déplacer un mot de passe dans un coffre ne change
+rien à vos formulaires.
+
+| Type de coffre | Statut |
+|---|---|
+| HashiCorp Vault (KV v1 et v2, authentification par jeton) | disponible |
+| Identifiants dynamiques HashiCorp Vault (`<mount>/creds/<role>`) | expérimental |
+| CyberArk Central Credential Provider (CCP) | expérimental |
+
+---
+
+## Ajouter un coffre
+
+Depuis la 7.3.0, seul un admin peut ajouter, modifier ou supprimer un coffre, car son jeton ou sa clé est envoyé à son adresse. Chaque coffre a ces champs :
+
+| Champ | Signification |
+|---|---|
+| Nom | Comment les identifiants font référence au coffre. |
+| Type | Le gestionnaire de secrets. |
+| Identifiant | Comment et où le coffre se connecte : un identifiant de [Connexions > Identifiants](../credentials.html), à l'étape **Identifiants**, de type **HashiCorp Vault** (son jeton et son adresse) ou **CyberArk**. Il contient l'URL de base, par ex. `https://vault.example.com:8200`, et les paramètres TLS : ignorer la vérification du certificat, ou un bundle CA en PEM pour une CA privée. Il ne peut pas lui-même lire depuis un coffre de secrets. |
+| Cache (secondes) | Combien de temps un secret lu est réutilisé. `0` le lit à chaque utilisation. Par défaut 60. |
+| Options supplémentaires (JSON) | Des options propres au type, sous forme d'objet JSON. |
+
+Jusqu'à la 7.2.0, l'adresse, le jeton et les paramètres TLS étaient des champs du coffre. La mise à jour vers la 7.3.0 les déplace dans son
+identifiant, nommé `<store>-token` (ou `<store>-appid` pour CyberArk), voir [Adresses dans les identifiants](../credentials/types.html#addresses-in-credentials).
+
+**Tester la connexion** vérifie l'accès sans lire de secret. La page **Statut** vérifie chaque coffre, et avertit 7 jours
+avant l'expiration d'un jeton Vault.
+
+Chaque gestionnaire de secrets a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 et v2 avec authentification par jeton, et les identifiants de base de données dynamiques |
+| [CyberArk](cyberark.html) | Le Central Credential Provider (CCP) de l'Application Access Manager de CyberArk |
+
+---
+
+## Utiliser un coffre
+
+### Dans un identifiant
+
+Dans **Connexions > Identifiants**, à l'étape **Stockage** de l'identifiant, choisissez **Coffre de secrets**, puis sélectionnez le
+**Coffre de secrets** et renseignez la **Référence**. L'utilisateur et le mot de passe sont alors lus depuis le coffre, et non saisis.
+
+### En ligne, sans ligne d'identifiant
+
+Partout où un nom d'identifiant est accepté, vous pouvez à la place référencer directement un coffre (`fnCredentials`, `fnRestBasic`,
+les `credentials:` d'un formulaire, le `dbConfig` d'une requête).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Sans ligne d'identifiant, un secret de base de données nécessite au moins un `db_type` et un hôte, par exemple :
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Sans `db_type`, le secret est un identifiant simple (utilisateur, mot de passe et toute autre clé), et une requête sur lui suppose `mysql`.
+
+### Noms des clés
+
+Un secret est associé à un identifiant avec ces alias. Les autres clés sont transmises telles quelles.
+
+| Champ de l'identifiant | Clés acceptées dans le secret |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | même nom (secrets en ligne uniquement) |
+
+Pour une ligne d'identifiant, l'hôte, le port et le nom de la base de données issus du secret ne sont utilisés que là où la
+ligne les laisse vides.
+
+Un secret d'une autre structure peut être remodelé avec une expression `jq`, passée en troisième argument de
+`fnCredentials` :
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## Dans le seed de configuration
+
+Les coffres peuvent aussi être déclarés dans le seed de configuration, comme les autres objets d'administration :
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+Le coffre se connecte avec son identifiant : un identifiant `vault` contient l'adresse du Vault dans `url` et le jeton comme mot de passe, un identifiant `cyberark`
+l'AppID et l'adresse du CCP. Sans identifiant, ce sont le `url` et le `token` propres au coffre qui sont utilisés.
+Pour les détails, voir [Seed de configuration](../seed).
+
+---
+
+## Mise à jour depuis les variables VAULT_*
+
+Avant la 7, le seul coffre était un HashiCorp Vault configuré avec des variables d'environnement `VAULT_*`,
+et un identifiant pointait vers lui avec **Vault path**.
+
+- **Les variables sont importées une fois** comme un coffre nommé `vault` ; retirez-les ensuite.
+- **Les identifiants avec un `vault_path`** utilisent désormais ce coffre ; `vault_path` disparaîtra dans la 8.
diff --git a/i18n/fr/_configure/security/hardening.md b/i18n/fr/_configure/security/hardening.md
new file mode 100644
index 0000000..9923182
--- /dev/null
+++ b/i18n/fr/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Renforcement
+parent: Sécurité
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Renforcement
+{: .no_toc }
+
+Le compte admin, les limites de connexion, la base de données, les expressions, les données des jobs, la politique du navigateur, les fonctionnalités facultatives et les options de rôle
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le compte admin
+
+Le compte admin local est créé au premier démarrage à partir de [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+et [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), dont la valeur par défaut est `AnsibleForms!123`.
+
+* Une connexion avec le mot de passe public par défaut `AnsibleForms!123` doit d'abord le changer : d'ici là, le serveur répond
+  à toute requête autre que le changement de mot de passe par `403` (code `password_change_required`), et le navigateur affiche une
+  page de changement de mot de passe impossible à fermer. Le nouveau mot de passe ne peut pas être à nouveau celui par défaut.
+* `ADMIN_PASSWORD` n'est lu qu'à la première création du compte : définissez votre propre valeur avant le premier démarrage.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` réinitialise le mot de passe à `ADMIN_PASSWORD` à chaque
+  démarrage. Ne l'utilisez que pour récupérer un mot de passe perdu, puis retirez-la et redémarrez.
+* Définissez d'abord les deux secrets maîtres : voir [Secrets et chiffrement](secrets.html).
+* Une fois la connexion LDAP ou SSO fonctionnelle, gardez l'admin local pour les urgences uniquement, avec un long mot de passe conservé dans votre coffre.
+
+---
+
+## Limites de connexion et mots de passe
+
+Les tentatives de deviner un mot de passe sont freinées par trois limites. Les échecs sont comptés dans la base de données, si bien que chaque nœud d'application voit les
+mêmes tentatives, et chaque limite s'applique sans redémarrage :
+
+| Variable | Défaut | Ce qu'elle fait |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Après ce nombre de connexions échouées, un compte local ou LDAP est verrouillé pendant `LOGIN_LOCKOUT_MINUTES`. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Une adresse qui atteint ce nombre de connexions échouées en `LOGIN_LOCKOUT_MINUTES` est retenue jusqu'à la fin de cette fenêtre : une adresse qui essaie de nombreux comptes. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Combien de temps un compte reste verrouillé, et la fenêtre pendant laquelle les échecs sont comptés. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Les requêtes par minute depuis une adresse, par nœud d'application, sur la connexion, la déconnexion, le rafraîchissement du jeton et les callbacks d'authentification unique. |
+
+Un compte verrouillé ou une adresse retenue reçoit `429` avec un en-tête `Retry-After`, avant toute vérification de mot de passe et
+que le compte existe ou non ; au-delà de `AUTH_RATE_LIMIT`, la réponse est aussi `429`. Une connexion réussie remet à zéro le compteur
+du compte, tout comme un admin qui définit le mot de passe de l'utilisateur. `0` désactive une limite ; `LOGIN_LOCKOUT_MINUTES=0`
+désactive à la fois le verrouillage et la limite par adresse.
+
+`LOGIN_MAX_FAILURES_PER_IP` et `AUTH_RATE_LIMIT` comptent par adresse du client : derrière un reverse proxy, définissez `TRUST_PROXY`
+pour que l'adresse soit celle du client et non celle du proxy, voir [Adresses des clients](../production/reverse-proxy.html#client-addresses).
+
+Un mot de passe local défini via l'application, pour un nouvel utilisateur, par un admin ou par un utilisateur qui change le sien, doit avoir
+au moins [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) caractères (`8` par défaut,
+`0` ne vérifie aucune longueur). Il ne peut être ni le nom d'utilisateur ni le mot de passe public par défaut. `ADMIN_PASSWORD` n'est pas vérifié.
+
+---
+
+## La base de données
+
+AnsibleForms conserve chaque identifiant et chaque job dans sa base de données MySQL, gardez donc cette base hors du réseau :
+
+* Le projet docker-compose publie MySQL sur l'hôte (`MYSQLDB_LOCAL_PORT`, `3306`) et est livré avec le mot de passe root
+  `AnsibleForms!123`. Retirez ce mappage de port, ou liez-le à `127.0.0.1`, et changez le mot de passe.
+* Connectez-vous avec un compte dédié plutôt qu'avec `root`, défini dans [`DB_USER`](../customization/server.html#env_DB_USER) et
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Il n'a besoin de droits que sur le schéma `AnsibleForms` :
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Cela couvre la création du schéma (le `CREATE DATABASE` compris), ses patchs lors des mises à jour, et les
+  [sauvegardes](../production/backups.html) et restaurations, qui s'exécutent avec le même utilisateur : le dump est fait avec
+  `--no-tablespaces`, si bien qu'aucun droit au niveau du serveur comme `PROCESS` n'est nécessaire. Remplacez `%` par l'adresse de
+  l'application quand vous le pouvez. Un utilisateur qui a des droits sur toutes les bases, comme `root`, transforme une faille de l'application en
+  faille de tout le serveur de bases de données : la page **Statut** le signale dans sa vérification **Utilisateur de la base de données**, et le journal
+  à chaque démarrage.
+* Mettez [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) à `0` une fois le schéma créé.
+  La création du schéma supprime d'abord toutes les tables ; avec `0`, ni l'initialisation au démarrage ni l'endpoint `/api/v2/schema`
+  ne peuvent l'exécuter.
+
+---
+
+## Expressions et appels sortants
+
+Les expressions serveur s'exécutent sur le serveur pour tout utilisateur connecté, le filtre et les filtres sortants comptent donc :
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` ou `paranoid`, jamais `legacy`, qui permet aux utilisateurs d'exécuter du code serveur.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : les hôtes que les expressions REST ne peuvent pas atteindre, par ex. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : quand elle est définie, les expressions REST ne peuvent atteindre
+  que ces hôtes et ces plages. La liste des refus l'emporte sur elle.
+
+Les deux listes ne couvrent que les fonctions d'aide REST d'AnsibleForms lui-même ; les playbooks s'exécutent en dehors et ne sont pas filtrés.
+
+Depuis la 7.3.0, les fonctions d'aide REST vérifient le certificat de l'endpoint, comme toute autre connexion.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` désactive la vérification : ne l'utilisez que pour
+des endpoints avec un certificat auto-signé.
+
+---
+
+## Données des jobs
+
+Les extravars et la sortie des jobs sont stockées dans la base de données et montrées à tous ceux qui peuvent voir le job :
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : les extravars dont la clé correspond sont
+  affichées sous la forme `********`. La valeur par défaut est `password|secret|token` ; les champs mot de passe sont toujours masqués. Étendez-la avec
+  les noms qu'utilisent vos formulaires, par exemple `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : réduit l'objet `ansibleforms_user`
+  envoyé avec chaque job, qui contient sinon toutes les appartenances aux groupes de l'utilisateur.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) ne masque que les tâches bavardes ; masquez les secrets avec `no_log`.
+
+---
+
+## La Content-Security-Policy
+
+L'interface est servie avec un en-tête Content-Security-Policy, qui limite ce qu'une page peut charger et exécuter dans le navigateur :
+
+* Les scripts ne proviennent que de l'application elle-même, si bien qu'un script injecté dans une page ne s'exécute pas.
+* Aucun autre site ne peut afficher l'interface dans un cadre.
+* Elle autorise ce dont l'application a besoin : les expressions locales de formulaire évaluées dans le navigateur (`'unsafe-eval'`), les styles
+  en ligne, les images depuis n'importe quelle URL (images de formulaires et de catégories), et les workers de l'éditeur de code.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) vaut `1` par défaut et devrait
+le rester. Avec `0`, la politique est envoyée en `Content-Security-Policy-Report-Only` : la console du navigateur liste ce qu'elle
+bloquerait, et rien n'est bloqué. N'utilisez `0` que pour une configuration qui ne peut pas encore fonctionner avec la politique, comme un reverse proxy
+qui injecte son propre script. Une modification sur la page de paramètres s'applique sans redémarrage.
+
+---
+
+## Les pages de paramètres et le concepteur
+
+Les administrateurs peuvent modifier une grande partie de la configuration depuis le navigateur. Restreignez cela quand la configuration est gérée ailleurs :
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : des paramètres en lecture seule, pour un [environnement géré](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : retire le concepteur intégré quand les formulaires
+  sont maintenus dans git.
+
+---
+
+## Fonctionnalités facultatives
+
+Ces fonctionnalités sont désactivées par défaut. Ne les activez que si vous les utilisez ; une modification sur la page de paramètres s'applique sans redémarrage :
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : sert le [serveur MCP](../mcp/) sur `/api/v2/mcp`,
+  pour que des clients MCP puissent lancer des formulaires avec le jeton d'un utilisateur.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : l'[assistant de chat](../chat/). Les définitions de formulaires
+  et les valeurs en cours de saisie sont envoyées au fournisseur de modèle configuré.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) fonctionne à l'inverse : elle vaut `enforce`
+par défaut, si bien que le serveur refuse un lancement dont les valeurs enfreignent les règles du formulaire, y compris les lancements via l'API REST.
+Laissez-la ainsi : `log` ne fait que journaliser ce qui serait refusé et `off` ne vérifie rien, voir [Validation au lancement](../launch-validation/).
+
+---
+
+## Options de rôle
+
+Certaines options de rôle de [config.yaml](../config/roles.html) donnent plus que ce que suggère leur nom. Accordez-les avec prudence :
+
+| Option | Pourquoi elle compte |
+|--------|----------------|
+| `allowScheduledJobs` | Un utilisateur qui l'a voit et peut modifier toutes les planifications, et une planification s'exécute avec des droits d'admin, pour n'importe quel formulaire. Traitez-la comme une option de niveau admin. |
+| `allowBackupOps` | Inclut la **restauration**, qui remplace toute la base de données. |
+| `showSettings` | Ouvre les pages d'administration. Sans le rôle admin, elle ne permet pas de modifier les comptes et les groupes que nomme le rôle admin, voir [Utilisateurs et groupes](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Montre le journal du serveur, qui peut contenir des noms d'hôtes, des noms d'utilisateurs et des détails d'erreurs. |
+| `showConnectionsSettings` | Ouvre les pages de connexions : identifiants, runners, canaux de notification et plus. Ajouter, modifier et supprimer des runners et des coffres de secrets reste réservé à un admin, de même que les identifiants des connexions et des authentifications. Pour un dépôt, l'ajouter ou le supprimer et changer son adresse, sa branche ou ses indicateurs `use_for_*` restent réservés à un admin. |
+| `showAllJobLogs` | Montre les jobs de tous les utilisateurs, pas seulement ceux de l'utilisateur. |
+| `manageAllJobs` | Interrompt, supprime et relance les jobs de tous les utilisateurs. |
+| `allowApiTokens` | Permet à l'utilisateur de créer des jetons d'API qui vivent jusqu'à [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 par défaut). Se déconnecter avec un jeton ou le révoquer y met fin, et un changement de mot de passe met fin à tous les jetons de l'utilisateur, voir [Jetons](secrets.html#tokens). |
+| `extendedTokenExpiration` | Avec `allowApiTokens`, permet aussi à l'utilisateur de créer des jetons d'API qui n'expirent jamais. |
+| `allowFileUploads` | Permet à l'utilisateur de téléverser des fichiers via les champs fichier d'un formulaire. Activée pour chaque utilisateur sauf si un rôle la désactive. |
+| `allowChat`, `allowMcp` | Permettent à l'utilisateur d'utiliser l'assistant de chat et le serveur MCP, quand ils sont activés. `allowChat` est activée pour chaque utilisateur sauf si un rôle la désactive, et `allowMcp` suit `allowChat` sauf si un rôle la définit. |
+
+Un utilisateur sans le rôle `admin` ne reçoit aucune des options de niveau admin ci-dessus sauf si un rôle les lui donne. Quand le rôle `admin`
+ne définit aucune option, ses utilisateurs reçoivent `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` et `allowScheduledJobs`. `allowApiTokens` et
+`extendedTokenExpiration` restent désactivées même pour le rôle `admin` : définissez-les sur les rôles qui en ont besoin.
+
+Quand plusieurs rôles d'un utilisateur définissent la même option, `false` l'emporte. Les options du rôle `default` ne font que compléter les options
+qu'aucun des rôles propres de l'utilisateur ne définit ; elles ne les annulent jamais.
diff --git a/i18n/fr/_configure/security/https.md b/i18n/fr/_configure/security/https.md
new file mode 100644
index 0000000..631d474
--- /dev/null
+++ b/i18n/fr/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Sécurité
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+Servez HTTPS depuis l'application elle-même, et remplacez le certificat d'exemple
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Où se termine TLS
+
+TLS peut se terminer à l'un de trois endroits, et seul le premier fait intervenir les paramètres de cette page :
+
+* **dans AnsibleForms**, avec `HTTPS=1` : HTTPS sur [`PORT`](../customization/server.html#env_PORT) avec les fichiers ci-dessous, comme le fait docker-compose sur le 443.
+* **dans un reverse proxy**, avec `HTTPS=0` derrière lui : voir [Reverse proxy](../production/reverse-proxy.html).
+* **dans un ingress Kubernetes** : voir l'onglet Ingress de [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) et le README du chart.
+
+Vous pouvez combiner le premier avec les deux autres pour chiffrer aussi le saut entre le proxy et l'application.
+
+---
+
+## Les paramètres
+
+Trois variables pilotent HTTPS dans l'application :
+
+| Variable | Défaut | Signification |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` sert HTTPS, `0` du HTTP simple |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | La clé privée, en PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | Le certificat du serveur, en PEM |
+
+Dans l'image du conteneur, le dossier persistant est `/app/dist/persistent`, les fichiers par défaut sont donc
+`/app/dist/persistent/certificates/key.pem` et `cert.pem`. Avec le projet docker-compose, c'est `data/certificates/`
+sur l'hôte.
+
+---
+
+## Le certificat d'exemple
+
+Quand `HTTPS=1` et que l'un des fichiers manque au démarrage, AnsibleForms journalise `httpsKey or httpsCert not found, copying from
+templates` et copie une clé et un certificat d'exemple depuis l'image vers les chemins configurés. Si cette copie échoue,
+l'application s'arrête.
+
+Ce certificat est auto-signé pour `CN=ansibleforms`, et il est **identique sur chaque installation** : sa clé privée
+est livrée dans l'image publique. Il convient pour un premier aperçu, mais les navigateurs le signalent et n'importe qui peut déchiffrer le trafic
+qu'il protège. Remplacez-le avant que l'instance ne contienne de vrais identifiants.
+
+---
+
+## Remplacer le certificat
+
+Utilisez un certificat émis pour le nom d'hôte que saisissent les utilisateurs, par votre CA ou un client ACME, au format PEM.
+Le fichier du certificat peut contenir la chaîne complète : le certificat du serveur d'abord, puis les intermédiaires.
+
+1. Copiez les fichiers dans le dossier persistant, ou à tout endroit que l'application peut lire :
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. S'ils se trouvent ailleurs, mettez dans `HTTPS_KEY` et `HTTPS_CERT` leurs chemins **à l'intérieur du conteneur**.
+
+3. Redémarrez l'application, qui lit les deux fichiers au démarrage.
+
+Pour un certificat auto-signé rapide à vous (une instance de test, ou le saut derrière un proxy), `openssl` en crée un :
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Renouveler sans redémarrage
+
+Modifier `HTTPS_KEY` ou `HTTPS_CERT` sur les pages de paramètres recharge la clé et le certificat dans le serveur en cours d'exécution.
+Les nouvelles connexions reçoivent le nouveau certificat, celles déjà ouvertes gardent l'ancien. Si les nouveaux fichiers ne peuvent pas être lus ou ne forment pas une
+paire valide, le certificat actuel reste en place et un avertissement est journalisé.
+
+Cela ne fonctionne que lorsque les pages de paramètres peuvent écrire l'environnement ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+vaut `1`) et que la variable n'est pas définie dans l'environnement réel. Quand un renouvellement remplace les fichiers aux mêmes
+chemins, redémarrez l'application.
diff --git a/i18n/fr/_configure/security/index.md b/i18n/fr/_configure/security/index.md
new file mode 100644
index 0000000..bde66c0
--- /dev/null
+++ b/i18n/fr/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Sécurité
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Sécurité
+{: .no_toc }
+
+Verrouillez une instance : le compte admin, ses secrets, HTTPS et ce que peuvent faire les utilisateurs et les formulaires
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les administrateurs qui préparent une instance pour la production, et pour les revues de sécurité d'une instance existante.
+
+---
+
+## Dans cette section
+
+Chaque thème a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Renforcement](hardening.html) | Le compte admin, les limites de connexion, la base de données, les expressions, les données des jobs, la politique du navigateur, les fonctionnalités facultatives et les options de rôle |
+| [HTTPS](https.html) | Où se termine TLS, servir HTTPS depuis l'application, et remplacer le certificat d'exemple |
+| [Secrets et chiffrement](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, et la durée de vie des jetons |
+
+Pages liées : [Authentification](../authentication/) pour les méthodes de connexion, [Validation au lancement](../launch-validation/) pour
+les vérifications côté serveur de chaque lancement, et les [Variables de sécurité](../customization/security.html).
diff --git a/i18n/fr/_configure/security/secrets.md b/i18n/fr/_configure/security/secrets.md
new file mode 100644
index 0000000..1ed39ed
--- /dev/null
+++ b/i18n/fr/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Secrets et chiffrement
+parent: Sécurité
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Secrets et chiffrement
+{: .no_toc }
+
+Les deux secrets maîtres, ce qu'ils protègent, et la durée des sessions et des jetons
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les deux secrets maîtres
+
+Deux secrets protègent tout le reste. Définissez-les tous deux avant que l'instance ne contienne de vraies données, conservez-les hors de l'instance,
+et ne les changez jamais à la légère :
+
+| Secret | Ce qu'il protège | S'il n'est pas défini | S'il est perdu ou changé |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Chaque mot de passe et chaque jeton stocké dans la base de données : identifiants, mot de passe de bind LDAP, jetons des runners, secrets client SSO, adresses des webhooks Slack et Teams, clé d'API du chat | Une clé par défaut est utilisée, publique dans le code source | Perdu : chaque secret stocké doit être ressaisi. Changé : depuis la 7.3.0, chaque secret stocké est rechiffré, voir [plus bas](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | La signature des jetons d'accès et de rafraîchissement, y compris les [jetons d'API](../profile/api-token.html) de longue durée | Un secret aléatoire est généré à chaque démarrage, si bien que chaque redémarrage déconnecte tout le monde | Chaque session et chaque jeton d'API deviennent invalides |
+
+Tous deux sont journalisés sous forme d'avertissement `[SECURITY]` au démarrage tant qu'ils manquent. Les pages de paramètres refusent de les modifier,
+l'API ne les renvoie jamais, et les sauvegardes les omettent volontairement, si bien qu'un `ENCRYPTION_SECRET` perdu ne peut être récupéré
+nulle part : gardez-en une copie dans votre gestionnaire de secrets. Le secret de chiffrement sert de clé de 32 caractères ; une valeur plus courte ou
+plus longue est complétée ou tronquée.
+
+Changer `ACCESS_TOKEN_SECRET` met fin d'un coup à chaque session et à chaque jeton d'API. Pour mettre fin aux jetons d'un utilisateur ou d'une
+session, utilisez les révocations décrites dans [Jetons](#tokens).
+
+---
+
+## Changer le secret de chiffrement
+
+Depuis la 7.3.0, définir ou changer `ENCRYPTION_SECRET` ne fait plus perdre les secrets stockés. Au démarrage suivant, le worker rechiffre
+chacun d'eux avec la nouvelle clé, dans une seule transaction de base de données, avant que quoi que ce soit d'autre n'écrive un secret :
+
+| Situation | Que définir |
+|---|---|
+| L'instance tournait sans `ENCRYPTION_SECRET`, sur la clé publique par défaut | Seulement `ENCRYPTION_SECRET` : les secrets sont rechiffrés depuis la clé par défaut |
+| L'instance tournait avec une clé à vous | `ENCRYPTION_SECRET` avec la nouvelle clé et [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) avec l'ancienne, pour ce seul démarrage |
+
+Quand les secrets stockés ont été chiffrés avec une clé qui n'est ni l'une ni l'autre, rien n'est modifié et l'application refuse de démarrer tant que
+`ENCRYPTION_SECRET_PREVIOUS` ne nomme pas cette clé. Retirez `ENCRYPTION_SECRET_PREVIOUS` une fois que le démarrage les a rechiffrés, et définissez le
+nouveau `ENCRYPTION_SECRET` sur chaque nœud d'application, le worker et chaque RTE en mode base de données qui s'enregistre lui-même. Cet
+auto-enregistrement (`RTE_REGISTER`) est déprécié dans la 7.3.0 : un RTE qui rejoint avec un jeton d'adhésion (`RTE_JOIN_TOKEN`) en mode
+socket n'a besoin d'aucun `ENCRYPTION_SECRET`, voir [Modes du RTE](../rte/modes.html).
+
+---
+
+## Jetons
+
+Une connexion renvoie un jeton d'accès de courte durée et un jeton de rafraîchissement plus long, que le navigateur utilise pour obtenir une nouvelle paire :
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : `30m` par défaut. Plus court, il
+  limite l'usage d'un jeton intercepté.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : `24h` par
+  défaut. C'est la durée pendant laquelle un navigateur inactif reste connecté.
+* L'option de rôle `allowApiTokens` permet à un utilisateur de demander un jeton d'API valable un certain nombre de jours, et
+  `extendedTokenExpiration` en ajoute un qui n'expire jamais. Ne les accordez qu'aux rôles qui ont besoin d'un accès API depuis des scripts.
+  Sur la [page de profil](../profile/api-token.html), un jeton se crée depuis une session de navigateur connectée il y a 10 minutes
+  au plus, et jamais depuis un autre jeton d'API. Un jeton qui n'expire jamais vit 50 ans, et les événements ci-dessous y mettent quand même fin.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : `90` par défaut. La durée de vie maximale d'un jeton
+  d'API : une demande plus longue y est ramenée.
+
+Un jeton est un JWT signé, mais le serveur tient aussi une liste de jetons révoqués, partagée par tous les nœuds d'application, si bien qu'un jeton
+peut prendre fin avant son expiration :
+
+| Événement | Ce qui prend fin |
+|-------|-----------|
+| La déconnexion | Chaque jeton de cette connexion : le jeton d'accès, son jeton de rafraîchissement, et un jeton d'API quand la déconnexion l'utilise |
+| Un changement de mot de passe, par l'utilisateur ou par un admin | Chaque jeton de l'utilisateur émis avant le changement, jetons d'API compris, sur chaque appareil |
+| L'interrupteur **Autoriser la connexion** d'un utilisateur désactivé (utilisateur local, LDAP ou SSO), ou un utilisateur local supprimé | Chaque jeton de l'utilisateur |
+| **Terminer les sessions** sur la page d'un utilisateur LDAP ou SSO | Chaque jeton de l'utilisateur ; il peut se reconnecter sauf s'il est bloqué |
+| **Révoquer** sur un jeton d'API, sur la page de profil ou dans l'onglet **Jetons d'API** de l'utilisateur | Ce seul jeton d'API, immédiatement |
+
+Un script met fin à son propre jeton d'API en se déconnectant avec lui : `POST /api/v2/auth/logout` avec le jeton dans l'en-tête
+`Authorization`.
diff --git a/i18n/fr/_configure/seed/environment-and-audit.md b/i18n/fr/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..05d7ae2
--- /dev/null
+++ b/i18n/fr/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Modification et audit
+parent: Seed de configuration
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Modification et audit
+{: .no_toc }
+
+Verrouiller les pages de paramètres, et ce qu'enregistre le journal d'audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Désactiver la modification de l'environnement
+
+`ALLOW_ENV_EDIT=0` met les pages de paramètres en lecture seule. Chaque variable reste affichée avec
+la valeur en vigueur et la raison pour laquelle elle ne peut pas être modifiée, et l'endpoint d'enregistrement répond par
+403.
+
+Utilisez-la chaque fois que l'environnement est déclaré ailleurs. Sinon, la page de paramètres écrit
+`persistent/.env`, qui sur un volume éphémère est perdu sans bruit au redémarrage suivant, et sur
+un volume durable s'écarte du manifeste censé faire foi.
+
+{: .note }
+> Les sauvegardes incluent `persistent/.env` sous le nom `managed.env`, si bien qu'une reconstruction récupère les paramètres de base de données et
+> de chemins. **`ENCRYPTION_SECRET` et `ACCESS_TOKEN_SECRET` en sont retirés** :
+> le dump à côté contient chaque identifiant stocké sous forme de texte chiffré AES, et écrire la clé qui
+> le déchiffre dans le même dossier suffirait, avec une copie de la sauvegarde, à tous les lire. Définissez
+> plutôt ces deux variables sur l'hôte cible ; un commentaire dans le fichier l'indique.
+>
+> Ce qui reste peut encore contenir des identifiants (`DB_PASSWORD`, `METRICS_TOKEN`, un ancien `VAULT_TOKEN`), le fichier est donc
+> écrit en `0600`. Le restaurer est une étape à part, sur demande, et non une partie d'une restauration normale,
+> car l'hôte de base de données et les chemins qu'il contient décrivent la machine d'où provient la sauvegarde. La
+> boîte de dialogue de restauration liste le fichier et propose son propre bouton *Restaurer l'environnement*
+> (`POST /api/v2/backup/:folder/restore-env`), qui conserve le fichier précédent sous `.env.bak`.
+
+---
+
+## Ce qui est enregistré
+
+Chaque application qui change quelque chose écrit une entrée `seed.apply` dans le journal d'audit, qui nomme
+les objets créés, mis à jour, libérés et purgés. Les valeurs ne sont jamais enregistrées, car la plupart
+sont des secrets. Une application sans effet n'écrit rien, ce qui garde la piste pertinente. Une
+vérification qui trouve le fichier inchangé est sans effet, si bien que la piste ne gagne pas une ligne par minute.
+
+Une application demandée via l'endpoint est volontairement enregistrée deux fois, et les deux lignes
+enregistrent des choses différentes : `config-seed.apply.create` indique **qui** l'a demandée, `seed.apply`
+**ce qu'**elle a changé.
+
+La page Statut rend compte du seed deux fois : une **vérification** que le fichier est toujours lisible et s'analyse,
+et que le dernier rechargement a réussi, et une ligne d'**informations** indiquant combien d'enregistrements il
+possède actuellement. La vérification est le seul endroit qui signale quand le fichier sur le disque et la configuration
+en vigueur ont divergé, car un rechargement échoué laisse l'instance tourner.
diff --git a/i18n/fr/_configure/seed/example.md b/i18n/fr/_configure/seed/example.md
new file mode 100644
index 0000000..8f54087
--- /dev/null
+++ b/i18n/fr/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Exemple
+parent: Seed de configuration
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Exemple
+{: .no_toc }
+
+Un fichier seed complet, section par section
+{: .fs-6 .fw-300 }
+
+---
+
+Le fichier seed suivant déclare toutes les sections sauf `oauth2` et l'`awx` déprécié ; les secrets viennent de variables
+d'environnement comme `${SEED_AWX_TOKEN}` :
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` vaut l'une de ces valeurs :
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : tout autre endpoint compatible OpenAI
+
+Comme `ldap`, la section `chat` est une seule ligne, si bien que chaque champ est obligatoire sauf les champs
+facultatifs ; un champ facultatif omis est laissé inchangé.
+
+L'assistant de chat nécessite aussi `ENABLE_CHAT=1` ; voir la page [Assistant de chat](../chat).
+
+Depuis la 7.3.0, un runner se connecte avec un identifiant de son type, qui contient l'adresse de son serveur dans `url`. Un runner avec son propre `token`,
+ou `username` et `password`, fonctionne toujours : le seed journalise un avertissement et les transforme en un tel identifiant, nommé d'après le runner. Un
+runner qui nomme un identifiant `api` ou `userpass` fonctionne aussi, avec un avertissement : donnez plutôt à cet identifiant le type du runner.
+Les deux sont dépréciés depuis la 7.3.0 et seront supprimés dans la 8.0.0. Un runner RTE sans `rte_mode` est en mode base de données, déprécié (voir
+[Modes](../rte/modes.html)). Un runner avec `enabled: false` ne reçoit aucun job, y compris comme runner par défaut de son type (voir
+[Par défaut et Activé](../runners/list.html#default-and-enabled)) ; sans `enabled`, le seed le laisse tel quel.
+
+Un élément de runner accepte ces clés en plus de `name`, `type`, `description`, `credential`, `is_default` et `enabled` :
+
+| Clé | Ce qu'elle définit |
+|---|---|
+| `rte_mode` | Le mode d'un RTE : `outbound`, `inbound` ou `database` (obsolète, par défaut) |
+| `rte_max_jobs` | Les **Jobs simultanés max.** d'un RTE en mode socket, de `0` à `10000` (`0` : aucune limite) |
+| `rte_cache_mb` | Son **Cache des fichiers** en Mo, de `0` à `1048576` (`0` n'en garde aucun) |
+| `rte_files` | Ses **Fichiers de job** : `transfer` ou `local` |
+| `rte_drain_seconds` | Son **Délai d'arrêt** en secondes, de `0` à `86400` |
+| `flavour` | Un runner `awx` qui est un AAP ou un Ascender : `aap` ou `ascender` ; rien pour AWX |
+| `project` | L'id de projet d'un runner Semaphore, le nom de projet d'un runner Rundeck, le dossier d'un runner Jenkins |
+| `uri`, `ignore_certs`, `ca_bundle` | L'adresse et le TLS propres au runner, d'avant la 7.3.0 : utilisés uniquement tant que son identifiant ne contient pas de `url` |
+
+Les quatre paramètres `rte_*` sont ceux de l'onglet RTE de la page du runner (voir [Les paramètres d'un RTE](../runners/runner-page.html#an-rtes-settings)) :
+ils l'emportent sur les mêmes variables définies sur le RTE, et un RTE en mode base de données les ignore. Une valeur hors de sa plage fait échouer la
+validation du seed.
+
+Un RTE en mode base de données peut s'enregistrer lui-même avant que le seed soit appliqué. Un runner RTE du seed dont le `uri` est l'adresse à laquelle un tel RTE
+s'est enregistré **adopte** cette ligne : il prend le nom et les champs déclarés, et le worker ne le supprime plus quand le RTE cesse de
+répondre, au lieu d'avoir un second runner pour le même RTE.
diff --git a/i18n/fr/_configure/seed/index.md b/i18n/fr/_configure/seed/index.md
new file mode 100644
index 0000000..b0795a8
--- /dev/null
+++ b/i18n/fr/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Seed de configuration
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Seed de configuration
+{: .no_toc }
+
+Déclarez les objets d'administration dans un fichier
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs qui provisionnent depuis git : déclarez les objets d'administration dans un fichier, pour qu'une instance puisse être reconstruite sur une base de données vide.
+
+---
+
+## Ce qu'il couvre
+
+Mettez dans `CONFIG_SEED_PATH` le chemin d'un fichier YAML, et AnsibleForms l'applique au démarrage. Le fichier
+déclare des objets qui n'existaient auparavant que dans la base de données :
+
+| Section                 | Ce qu'elle déclare                                                  |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Où s'exécutent les jobs : RTE, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Les coffres de secrets (HashiCorp Vault, ...)                       |
+| `credentials`           | Les identifiants                                                    |
+| `oauth2`                | Les fournisseurs SSO : Entra ID et OIDC                             |
+| `repositories`          | Les dépôts Git                                                      |
+| `syslog_servers`        | Les serveurs syslog qui reçoivent le journal du serveur et les entrées d'audit |
+| `notification_channels` | Les serveurs mail, Slack, Teams, Telegram et les webhooks pour les notifications |
+| `labels`                | Les étiquettes à côté du logo de l'en-tête, depuis la 7.3.0          |
+| `ldap`                  | La configuration LDAP                                               |
+| `settings`              | L'URL publique, et les paramètres mail utilisés quand aucun canal mail n'est actif |
+| `chat`                  | Le fournisseur de modèle de l'assistant de chat                     |
+| `awx`                   | Déprécié depuis la 7, supprimé dans la 8 : utilisez `runners` avec `type: awx` |
+
+Un seed écrit avant la 7 continue de fonctionner : chaque élément de sa section `awx` est appliqué comme un runner de type `awx`, et le journal
+avertit à chaque application. Déplacez ces éléments sous `runners` avec `type: awx` avant de passer à la 8.
+
+Le seed n'est **pas** la même chose que `config.yaml`, qui contient les catégories, les rôles et les constantes
+et a son propre `CONFIG_PATH`. Les deux sont volontairement séparés : le
+dépôt qui *contient* `config.yaml` fait partie des objets que déclare le seed, le seed
+ne peut donc pas se trouver à l'intérieur.
+
+Les utilisateurs et les groupes sont laissés de côté : ils viennent de LDAP ou du SSO, et le premier admin de `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## Dans cette section
+
+Chaque thème a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Exemple](example.html) | Un fichier seed complet, section par section |
+| [Objets gérés](managed-objects.html) | Comment le seed possède les objets qu'il liste, et comment il garde les secrets à l'écart |
+| [Rechargement et démarrage](reloading.html) | Modifier le fichier sans redémarrage, et ce qui se passe au démarrage |
+| [Kubernetes](kubernetes.html) | Provisionner AnsibleForms depuis une ConfigMap et des Secrets |
+| [Modification et audit](environment-and-audit.html) | Verrouiller les pages de paramètres, et ce qu'enregistre le journal d'audit |
diff --git a/i18n/fr/_configure/seed/kubernetes.md b/i18n/fr/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..d94c236
--- /dev/null
+++ b/i18n/fr/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Seed de configuration
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+Provisionnez AnsibleForms depuis une ConfigMap et des Secrets
+{: .fs-6 .fw-300 }
+
+---
+
+Montez le seed depuis une `ConfigMap` et ses secrets depuis un `Secret` :
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Un seul pod, avec `AF_ROLE` non défini.** Ce pod exécute l'application web et le worker dans un seul processus. Les planifications, la sauvegarde
+> nocturne et les autres travaux en arrière-plan ne s'exécutent que dans le processus qui détient le verrou du worker dans la base de données, le verrou du
+> concepteur est une table de la base de données, et les playbooks s'exécutent sur un RTE, pas dans ce pod. Gardez malgré tout `replicas: 1` avec la stratégie
+> `Recreate` : lors d'une mise à jour, le nouveau pod attend que le worker patche le schéma, et l'ancien pod détient le
+> verrou du worker jusqu'à son arrêt. Pour exécuter plusieurs nœuds web, répartissez-les en nœuds `AF_ROLE=app` et un worker, comme
+> le décrit [Mise à l'échelle](../production/scaling.html).
+
+`ENCRYPTION_SECRET` doit être défini avant la saisie du moindre identifiant. Une fois que les identifiants viennent
+du seed, la base de données n'est en pratique qu'un cache, si bien que la renouveler revient à réappliquer le
+seed plutôt qu'à tout ressaisir à la main.
+
+Les deux sondes ne nécessitent aucune connexion. Sous un [`BASE_URL`](../customization/server.html#env_BASE_URL), leurs chemins commencent par lui, et
+[Supervision](../production/monitoring.html) décrit ce que vérifie chacune.
diff --git a/i18n/fr/_configure/seed/managed-objects.md b/i18n/fr/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..ea70dbd
--- /dev/null
+++ b/i18n/fr/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Objets gérés
+parent: Seed de configuration
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Objets gérés
+{: .no_toc }
+
+Comment le seed possède les objets qu'il liste, et comment il garde les secrets à l'écart
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les sections à une seule ligne : tout ou rien
+
+`ldap`, `settings` et `chat` sont chacune une **seule ligne**, le seed doit donc déclarer tous leurs champs ; les autres sections sont des listes.
+
+Un seed qui omet un champ refuse de démarrer et le nomme :
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Déclarez explicitement une valeur vide avec `""` ou `false`. Quelques champs sont facultatifs, et un champ omis est laissé inchangé :
+
+| Section | Champs facultatifs |
+|---|---|
+| `ldap` | `description`, `credential` (un identifiant avec lequel faire le bind) et `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` et `extra_headers` |
+| `settings` | Aucun |
+
+`settings` ne couvre que les champs mail et l'URL ; tous les autres paramètres restent modifiables.
+
+---
+
+## Le fichier ne contient aucun secret
+
+Chaque `${VARIABLE}` est remplacée par cette variable d'environnement (sur Kubernetes, depuis un `Secret`), si bien que le fichier peut vivre dans Git.
+
+Une variable non définie est une **erreur fatale**, si bien qu'un placeholder ne peut jamais finir stocké comme mot de passe.
+
+Les identifiants peuvent aussi utiliser un [coffre de secrets](../secret-stores) (`secret_store`, `secret_ref`) ; `vault_path` disparaîtra dans la 8.
+
+---
+
+## Objets gérés
+
+Un objet qui vient du seed est marqué **géré** :
+
+- Il est imposé à **chaque** démarrage, si bien que le fichier fait toujours foi.
+- Il est en lecture seule : l'API répond **403**, l'interface désactive Modifier et Supprimer, et sa propre page indique qu'il provient du fichier
+  de seed de configuration et est en lecture seule.
+- Seul le seed peut poser ou retirer ce marqueur.
+
+Les objets créés à la main ne sont **jamais touchés**, sauf si le seed déclare le même nom. Cet enregistrement est alors **adopté** :
+les champs déclarés sont imposés et il passe en lecture seule. L'adoption est journalisée comme un avertissement et dans la piste d'audit.
+
+L'application du seed est idempotente : les enregistrements qui correspondent déjà sont laissés tels quels, si bien qu'un redémarrage indique normalement `0 updated`.
+
+Un dépôt déclaré dont l'arbre de travail manque est **cloné à nouveau** à chaque démarrage, si bien qu'un premier clonage échoué est
+retenté. La ligne *Dépôts* de la page Statut montre tout dépôt sans arbre de travail.
+
+### Retirer un objet
+
+Retirer un objet du fichier le **libère** : l'enregistrement reste et redevient modifiable. Supprimer une section entière
+fait de même.
+
+Ajoutez `prune: true` à une section de liste pour **supprimer** les enregistrements gérés que le fichier ne déclare plus :
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` ne supprime jamais un enregistrement créé à la main.
+
+### Désactiver le seed
+
+Retirer `CONFIG_SEED_PATH` ne libère **rien** : le seed n'est plus appliqué, et les enregistrements qu'il gérait restent gérés
+et en lecture seule. Pour les modifier à nouveau, libérez-les d'abord : pointez `CONFIG_SEED_PATH` vers un fichier qui ne les contient pas (un fichier vide ne déclare
+rien et libère tous les enregistrements), laissez-le s'appliquer à un démarrage ou à un rechargement, puis retirez la variable. Les enregistrements libérés restent tels
+quels, et deviennent modifiables.
diff --git a/i18n/fr/_configure/seed/reloading.md b/i18n/fr/_configure/seed/reloading.md
new file mode 100644
index 0000000..8b6e40b
--- /dev/null
+++ b/i18n/fr/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Rechargement et démarrage
+parent: Seed de configuration
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Rechargement et démarrage
+{: .no_toc }
+
+Modifier le fichier sans redémarrage, et ce qui se passe au démarrage
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Modifier le fichier sans redémarrer
+
+Le seed est relu toutes les `CONFIG_SEED_RELOAD_SECONDS` (60 par défaut, `0` le désactive)
+et réappliqué quand son contenu a changé. Une modification commitée dans git atteint donc
+automatiquement une instance en cours d'exécution : sur Kubernetes, une `ConfigMap` est remontée sous le pod en
+une minute environ, et la vérification suivante la prend en compte. Il n'y a ni rollout ni redémarrage, et aucun
+hook n'a besoin d'appeler quoi que ce soit.
+
+Pour un fichier inchangé, la vérification calcule un hash et s'arrête, si bien qu'elle ne réécrit jamais une ligne qu'elle a
+déjà appliquée.
+
+Pour appliquer le fichier immédiatement au lieu d'attendre la vérification suivante, utilisez l'un des deux :
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Les deux **forcent** une application même quand le fichier n'a pas changé. Une application forcée réimpose un
+enregistrement géré qui a été modifié directement dans la base de données, et reclone un dépôt déclaré
+dont l'arbre de travail manque.
+
+{: .note }
+> Un rechargement n'est **jamais fatal**, contrairement à l'application au démarrage. Une instance qui sert déjà
+> garde sa configuration actuelle, la raison est journalisée, et la ligne *Seed de configuration*
+> de la page Statut passe au rouge et la nomme. Une coquille poussée dans git ne doit pas pouvoir faire tomber
+> une instance en cours d'exécution sans la moindre action d'un opérateur.
+>
+> Le même contenu cassé n'est pas non plus retenté à chaque vérification ; sinon, une seule mauvaise modification
+> écrirait indéfiniment la même erreur dans le journal. Corrigez le fichier, ou appelez l'endpoint pour réessayer
+> immédiatement.
+
+---
+
+## Un seed cassé refuse de démarrer
+
+Un fichier illisible, un YAML invalide, un champ inconnu, un nom en double ou une
+`${VARIABLE}` non résolue fait **quitter** le serveur au lieu de démarrer. Cela ne concerne que le chemin du **démarrage** :
+voir la note ci-dessus pour ce que le même fichier fait à une instance déjà lancée.
+
+C'est voulu. Continuer avec la configuration précédente laisserait une instance dont le
+comportement ne correspond plus au manifeste censé la décrire, sans que rien ne
+signale l'écart. La raison est écrite sur la sortie d'erreur standard ainsi que dans le fichier de journal, si bien que
+`kubectl logs` et `docker logs` l'affichent.
+
+La validation est stricte : les champs inconnus sont rejetés au lieu d'être ignorés, et l'erreur nomme
+la clé fautive :
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Une base de données vide se provisionne elle-même
+
+Avec `ALLOW_SCHEMA_CREATION` activée (par défaut), une base de données qui ne contient **aucune table
+AnsibleForms** voit son schéma créé au démarrage. Un nouveau déploiement démarre donc
+sans que personne n'ait à appeler manuellement l'endpoint `/schema`.
+
+La condition est volontairement stricte : créer le schéma **supprime d'abord toutes les tables**, si bien
+qu'elle ne s'exécute jamais que sur une base de données complètement vide. Une base de données à laquelle il manque
+une colonne, ou qui a des tables mais aucun compte utilisateur, n'est *pas* vide et est laissée intacte ;
+les patchs du schéma traitent ces cas.
diff --git a/i18n/fr/_configure/users-and-groups.md b/i18n/fr/_configure/users-and-groups.md
new file mode 100644
index 0000000..b3f55f2
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Utilisateurs et groupes
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Utilisateurs et groupes
+{: .no_toc }
+
+Les utilisateurs et groupes locaux, ceux de LDAP et de l'authentification unique à côté, et le blocage d'une connexion
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : gérez qui peut se connecter dans **Paramètres > Accès > Utilisateurs** et **Groupes**, avec l'option de rôle `showSettings`.
+
+L'admin intégré, l'ordre de connexion et la correspondance des rôles des comptes locaux se trouvent sur [Comptes locaux](authentication/local.html).
+
+---
+
+## Dans cette section
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Un utilisateur local](users-and-groups/local-user.html) | Ajouter un utilisateur local, et les onglets de sa page |
+| [Plusieurs groupes](users-and-groups/several-groups.html) | Un utilisateur local dans plusieurs groupes, et ses rôles |
+| [Un groupe local](users-and-groups/local-group.html) | La page d'un groupe local et ses onglets |
+| [Utilisateurs et groupes d'annuaire](users-and-groups/directory.html) | Les utilisateurs et groupes LDAP, Entra ID et OIDC, tels que vus en dernier |
+| [Bloquer une connexion](users-and-groups/blocking-a-sign-in.html) | Autoriser la connexion : bloquer un utilisateur sans rien supprimer |
+
+
+---
+
+## Les listes
+
+Les listes **Utilisateurs** et **Groupes** montrent les utilisateurs et groupes locaux et, à côté, ceux de LDAP et de l'authentification unique.
+
+Un utilisateur ou un groupe LDAP, Entra ID ou OIDC est listé dès qu'il s'est connecté (ou a été vu lors d'une connexion), ou dès qu'un rôle le nomme.
+La colonne **Origine** indique d'où vient chacun : Local, LDAP, Microsoft Entra ID ou OIDC. Depuis la 7.3.0, la liste **Utilisateurs** a aussi
+une colonne **Dernière connexion**, qui indique quand chaque utilisateur s'est connecté pour la dernière fois.
+
+Une ligne ouvre la page de son utilisateur ou de son groupe. **Ajouter un utilisateur** et **Ajouter un groupe** en créent un local.
+
+---
+
+## Comptes qui donnent le rôle admin
+
+Le rôle admin de config.yaml nomme des groupes et des utilisateurs locaux, si bien que seul un admin peut modifier les comptes et les groupes qu'il nomme.
+
+Un utilisateur avec `showSettings` mais sans le rôle admin ne peut pas modifier, bloquer, changer de groupe, définir le mot de passe ni supprimer un
+compte local que nomme le rôle admin (directement ou via l'un de ses groupes). Il ne peut pas non plus créer, renommer ou supprimer un groupe
+que nomme le rôle admin, ni y placer un utilisateur. Il en va de même pour un utilisateur LDAP ou SSO qui correspond au rôle admin : le bloquer,
+terminer ses sessions, l'oublier et révoquer ses jetons d'API reviennent à un admin. Le serveur répond à une telle requête par `403`.
+
diff --git a/i18n/fr/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/fr/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..1e87314
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Bloquer une connexion
+parent: Utilisateurs et groupes
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Bloquer une connexion
+{: .no_toc }
+
+Autoriser la connexion : bloquer un utilisateur sans rien supprimer
+{: .fs-6 .fw-300 }
+
+L'interrupteur **Autoriser la connexion** bloque un utilisateur, local ou issu d'un annuaire, sans rien supprimer.
+
+Une fois désactivé, après une confirmation, les sessions de l'utilisateur se terminent immédiatement et toute connexion est refusée jusqu'à ce que vous le réactiviez.
+La liste des utilisateurs propose **Bloquer la connexion** et **Autoriser la connexion** dans le menu de chaque ligne pour la même chose.
+
+Vous ne pouvez bloquer ni l'utilisateur `admin`, ni votre propre connexion.
diff --git a/i18n/fr/_configure/users-and-groups/directory.md b/i18n/fr/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..b9c96c1
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Utilisateurs et groupes d'annuaire
+parent: Utilisateurs et groupes
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Utilisateurs et groupes d'annuaire
+{: .no_toc }
+
+Les utilisateurs et groupes LDAP, Entra ID et OIDC, tels que vus en dernier
+{: .fs-6 .fw-300 }
+
+Un utilisateur LDAP, Entra ID ou OIDC a sa page à `/settings/users/<source>/<name>`, avec `ldap`, `azuread` ou `oidc`
+comme source, par exemple `/settings/users/ldap/jdoe`. Elle montre ce qui a été enregistré lors de la dernière connexion de l'utilisateur, en lecture seule,
+puisque c'est l'annuaire ou le fournisseur d'identité qui détermine qui est l'utilisateur et quels sont ses groupes.
+
+Ses onglets sont ceux d'un utilisateur local. **Détails** contient l'interrupteur **Autoriser la connexion**, le nom d'utilisateur, l'origine, le nom,
+l'e-mail, quand l'utilisateur a été vu la première fois et sa dernière connexion. **Groupes** liste les groupes de la dernière connexion.
+**Jetons d'API** liste les jetons d'API de l'utilisateur, et **Révoquer** met fin à l'un d'eux immédiatement.
+
+En haut à droite, **Terminer les sessions** déconnecte l'utilisateur partout, tout de suite. **Oublier** supprime la fiche, qui revient
+à sa prochaine connexion ; ses jobs, jobs enregistrés et planifications restent. Un utilisateur bloqué ne peut pas être oublié, car cela
+le laisserait entrer à nouveau : le serveur répond `409`, autorisez donc d'abord sa connexion.
+
+Les groupes de cette fiche sont aussi les groupes avec lesquels fonctionne la session de l'utilisateur, lus en direct. Oublier un utilisateur connecté
+le laisse sans groupes, et sans les rôles que ces groupes donnent, jusqu'à ce qu'il se reconnecte.
+
+Un groupe d'annuaire a sa page à `/settings/groups/<source>/<name>`, en lecture seule, avec les onglets **Détails**,
+**Utilisateurs** (les utilisateurs vus dans ce groupe lors de leur dernière connexion), **Rôles** et **Formulaires**.
diff --git a/i18n/fr/_configure/users-and-groups/local-group.md b/i18n/fr/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..1b12df4
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Un groupe local
+parent: Utilisateurs et groupes
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Un groupe local
+{: .no_toc }
+
+La page d'un groupe local et ses onglets
+{: .fs-6 .fw-300 }
+
+La page d'un groupe, `/settings/groups/<id>`, a ces onglets :
+
+| Onglet | Ce qu'il montre |
+|---|---|
+| **Détails** | Le nom et la description |
+| **Utilisateurs** | Les utilisateurs du groupe ; **Ajouter un utilisateur** en ajoute un, le menu d'une ligne ou les cases à cocher en retirent un |
+| **Rôles** | Les rôles qui nomment le groupe |
+| **Formulaires** | Les formulaires qu'ouvrent ces rôles |
+
+Un groupe qui a des utilisateurs ne peut pas être supprimé : retirez d'abord ses utilisateurs. Le groupe `admins` ne peut jamais être supprimé ni renommé.
diff --git a/i18n/fr/_configure/users-and-groups/local-user.md b/i18n/fr/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..3592b1b
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Un utilisateur local
+parent: Utilisateurs et groupes
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Un utilisateur local
+{: .no_toc }
+
+Ajouter un utilisateur local, et les onglets de sa page
+{: .fs-6 .fw-300 }
+
+**Ajouter un utilisateur** ouvre un assistant en trois étapes : **Utilisateur** (nom d'utilisateur, description, e-mail), **Mot de passe** et **Groupe**.
+
+La page d'un utilisateur, `/settings/users/<id>`, a ces onglets :
+
+| Onglet | Ce qu'il montre |
+|---|---|
+| **Détails** | L'interrupteur **Autoriser la connexion**, le nom d'utilisateur, la description, l'e-mail et, depuis la 7.3.0, la **Dernière connexion** |
+| **Groupes** | Les groupes auxquels appartient l'utilisateur |
+| **Rôles** | Les rôles qu'a l'utilisateur, et ce qui donne chacun : **Directement**, **Via** un groupe, ou **Tout le monde** |
+| **Formulaires** | Les formulaires qu'ouvrent ces rôles |
+| **Jobs** | Les jobs lancés par l'utilisateur, le plus récent en premier |
+| **Jobs enregistrés** | Les valeurs de formulaire que l'utilisateur a enregistrées pour les relancer |
+| **Planifications** | Les jobs que l'utilisateur a planifiés avec Exécuter plus tard |
+| **Activité** | Ce que le journal d'audit a enregistré des actions de l'utilisateur |
+| **Jetons d'API** | Les jetons d'API de l'utilisateur, avec leur date de création, d'expiration et de dernière utilisation ; **Révoquer** met fin à l'un d'eux immédiatement |
+
+Depuis la 7.3.0, les connexions d'un utilisateur local sont enregistrées, comme l'étaient déjà celles d'un utilisateur LDAP ou SSO : **Dernière connexion** montre la plus récente, et
+la liste des utilisateurs a une colonne triable **Dernière connexion** pour chaque origine, si bien qu'un compte que personne n'utilise saute aux yeux. Une connexion refusée n'est pas
+enregistrée, et un utilisateur local qui ne s'est pas connecté depuis la mise à jour affiche `–`.
+
+**Changer le mot de passe** et **Supprimer** se trouvent en haut à droite. L'utilisateur `admin` ne peut jamais être supprimé ni renommé.
diff --git a/i18n/fr/_configure/users-and-groups/several-groups.md b/i18n/fr/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..26a81a4
--- /dev/null
+++ b/i18n/fr/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Plusieurs groupes
+parent: Utilisateurs et groupes
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Plusieurs groupes
+{: .no_toc }
+
+Un utilisateur local dans plusieurs groupes, et ses rôles
+{: .fs-6 .fw-300 }
+
+Un utilisateur local peut appartenir à plusieurs groupes, et reçoit les rôles de chacun d'eux : les rôles nomment un groupe `local/<group>`.
+
+Dans l'onglet **Groupes**, **Ajouter un groupe** ajoute l'utilisateur à un autre groupe, et le menu d'une ligne ou les cases à cocher en retirent un.
+Un utilisateur garde au moins un groupe. La liste des utilisateurs propose **Ajouter à un groupe** dans le menu de chaque ligne pour la même chose.
diff --git a/i18n/fr/_get_started/first-form.md b/i18n/fr/_get_started/first-form.md
new file mode 100644
index 0000000..0879939
--- /dev/null
+++ b/i18n/fr/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: Votre premier formulaire
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# Votre premier formulaire
+{: .no_toc }
+
+Écrire un playbook, lui construire un formulaire dans le Concepteur, le lancer et retrouver le job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ce tutoriel part d'une installation neuve, voir [Installation](installation/). Il prend environ un quart d'heure.
+
+---
+
+## 1. Se connecter
+
+Ouvrez AnsibleForms dans un navigateur et connectez-vous en tant qu'administrateur.
+
+Le compte par défaut est `admin` / `AnsibleForms!123` (ou vos valeurs [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)) ; la page **Formulaires** s'ouvre :
+
+![La page Formulaires, avec des formulaires d'exemple](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Écrire le playbook
+
+Un formulaire `ansible` exécute un playbook du dossier des playbooks, le playbook vient donc en premier. Enregistrez ceci sous `hello.yaml` :
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+Le playbook lit quatre variables. Le formulaire que vous construisez ensuite les envoie comme extravars, une par champ.
+
+Placez le fichier dans le dossier `playbooks` du dossier persistant
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)) ; créez le dossier s'il n'existe pas encore :
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Depuis les sources</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Le dossier que vous avez monté sur `/app/dist/persistent`, `/srv/apps/ansibleforms/persistent` dans l'exemple d'installation :
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+Le dossier `data/playbooks` du projet docker-compose :
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+Le volume persistant, monté sur `/app/dist/persistent` dans le pod AnsibleForms. Cherchez le nom du pod, puis copiez-y le fichier :
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+Le dossier `persistent/playbooks` du serveur, `/srv/apps/ansibleforms/server` dans l'exemple d'installation :
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Quand un dépôt git a **Utiliser pour les playbooks ?** activé, les playbooks sont exécutés depuis ce dépôt à la place :
+> commitez-y `hello.yaml`. Voir [Concepteur et git](gui/designer-and-git.html).
+
+---
+
+## 3. Créer le formulaire
+
+Les formulaires sont des fichiers YAML dans le dossier des formulaires. Le Concepteur les modifie dans le navigateur et les vérifie avant d'enregistrer.
+
+1. Cliquez sur **Concepteur** dans le menu du haut, puis sur **Formulaires** dans le menu de gauche.
+2. Cliquez sur l'interrupteur en haut à droite (**Démarrer le concepteur**). Il verrouille la configuration pour que personne d'autre ne la modifie en même
+   temps, puis affiche **Verrouillé par moi**.
+3. Cliquez sur **Nouveau fichier**, le premier bouton de la barre d'outils, et saisissez le nom de fichier `hello-world.yaml`. Le Concepteur y ajoute un formulaire
+   appelé `New Form`.
+4. Remplacez le YAML de l'éditeur par ce formulaire :
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Cliquez sur **Valider** (la coche), puis sur **Enregistrer**. L'enregistrement écrit `hello-world.yaml` dans le dossier des formulaires.
+6. Cliquez à nouveau sur l'interrupteur pour libérer le verrou.
+
+![Le Concepteur, en train de modifier un formulaire](assets/screenshots/designer.jpg)
+
+Le formulaire utilise quatre types de champs :
+
+| Champ | Type | Ce qu'il fait |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Une zone de texte obligatoire |
+| `target_env` | [`enum`](formfields/enum.html) | Une liste déroulante avec une liste fixe de `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Une liste déroulante remplie par une [expression](expressions/local.html) locale ; `__auto__` sélectionne le premier élément |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Une case à cocher, envoyée comme `true` ou `false` |
+
+`vm_size` affiche les deux colonnes, `size` et `cpus`, et envoie `size`, la première ; `valueColumn` en choisit une autre.
+
+`roles: [default]` permet à tout utilisateur connecté d'exécuter le formulaire, et `categories: [Default]` le place dans la catégorie que définit le
+`config.yaml` par défaut.
+
+{: .note }
+> Vous pouvez aussi copier `hello-world.yaml` dans [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH), et [le valider dans VS Code](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Le lancer
+
+Ouvrez le formulaire depuis la page **Formulaires** : cliquez sur **Formulaires** dans le menu du haut et choisissez **Hello world** dans la catégorie **Default**.
+
+Saisissez votre nom et modifiez les autres champs si vous le souhaitez. Cliquez sur **Afficher les variables supplémentaires** pour voir ce que le playbook va
+recevoir, puis cliquez sur **Soumettre** :
+
+![Un formulaire](assets/screenshots/form.jpg)
+
+---
+
+## 5. Suivre la sortie
+
+Le job démarre immédiatement, et sa sortie apparaît sous le formulaire pendant son exécution, pour se terminer par une barre **Terminé** :
+
+![La sortie d'un job](assets/screenshots/run.jpg)
+
+La tâche debug affiche vos valeurs, par exemple `Hello Alice: a small machine in development (dry run: True)`.
+
+L'avertissement sur le localhost implicite est normal sans inventaire ; un vrai formulaire définit un [`inventory`](forms/ansible.html).
+
+---
+
+## 6. Le retrouver dans l'historique des jobs
+
+Chaque lancement est conservé comme un job. Cliquez sur **Jobs** dans le menu du haut : le nouveau job est en tête de **Tous les jobs**.
+
+Cliquez sur le job pour revoir sa sortie, et sur **Afficher les variables supplémentaires** pour voir ce qui a été envoyé. Les icônes devant chaque job
+le relancent ou le suppriment :
+
+![L'historique des jobs](assets/screenshots/job-output.jpg)
+
+---
+
+## Étapes suivantes
+
+Développez ce formulaire à l'aide des pages de référence :
+
+* **[Formulaires](forms/)** : chaque propriété de formulaire, les modèles sur les runners, les formulaires workflow, les points d'approbation et les notifications
+* **[Champs de formulaire](formfields/)** : tous les types de champs, avec la validation, les dépendances et la mise en page
+* **[Expressions](expressions/)** : remplir les champs depuis des API REST, des bases de données et des fichiers
+* **[Rôles](config/roles.html)** et **[catégories](config/categories.html)** dans `config.yaml` : décider qui voit quel formulaire
+* **[Comment ça marche](how-it-works.html)** : ce qui se passe derrière un lancement, et où tout est stocké
diff --git a/i18n/fr/_get_started/installation/docker-compose.md b/i18n/fr/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..47f1a50
--- /dev/null
+++ b/i18n/fr/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Installation
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Installer AnsibleForms, son RTE et MySQL ensemble avec docker-compose ou podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le [projet docker-compose](https://github.com/ansibleforms/docker) fait tourner trois conteneurs : MySQL, l'application AnsibleForms et le RTE
+(runtime environment) qui exécute les playbooks. Il contient leurs paramètres, des formulaires et des playbooks d'exemple, la seule autre exigence est donc
+Docker ou Podman avec son outil compose.
+
+L'[installateur](installer.html) télécharge ce projet, remplit ses paramètres et ses secrets, et le démarre en une seule commande. Cette page
+le met en place à la main.
+
+---
+
+## Prérequis
+
+Avant de commencer, il vous faut :
+
+* **Une machine Linux** : n'importe quelle distribution, avec un CPU et une mémoire modestes
+* **Un accès à GitHub** : pour télécharger ou cloner le projet docker-compose depuis GitHub
+* **Docker ou Podman** : un moteur de conteneurs, installé plus bas
+* **Un outil compose** : Docker Compose ou podman-compose, pour démarrer les trois conteneurs à partir de quelques fichiers de configuration
+
+**VIDÉO** : [Comment installer AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Choisir un emplacement d'installation
+
+Créez un dossier pour le projet ; les exemples utilisent `/srv/apps` :
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Cloner le projet docker-compose
+
+Installez Git :
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Clonez ensuite le projet docker-compose dans ce dossier :
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Définir les bonnes permissions
+
+L'application et le RTE tournent sous l'utilisateur `node` (uid 1000), donnez donc le dossier `data` à cet utilisateur :
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Si vous venez de la 6, dont le conteneur tournait en root, lancez le même `chown` une fois avant de démarrer la 7. MySQL reprend son propre dossier à son démarrage.
+
+---
+
+## Installer un moteur de conteneurs
+
+Installez Docker ou Podman, chacun avec son outil compose :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Installez Docker Engine avec le plugin Compose depuis le dépôt de Docker
+(voir les [manuels d'installation de Docker](https://docs.docker.com/engine/install)) :
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Faites ensuite en sorte que les noms se résolvent dans les conteneurs, et démarrez Docker comme service :
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman ne nécessite pas de service. Installez-le avec podman-compose :
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Personnaliser
+
+Passez en revue les variables des fichiers `.env` et `docker-compose.yml`, et changez tous les mots de passe : `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` et `RTE_TOKEN`. [En savoir plus sur les variables d'environnement](../customization)
+
+L'application se connecte à MySQL en tant que `ansibleforms` (`MYSQLDB_USER`), avec tous les droits sur le schéma `AnsibleForms` et aucun
+ailleurs ; root ne sert qu'à MySQL lui-même. MySQL ne crée cet utilisateur qu'à son premier démarrage : une installation qui se connectait jusqu'ici en root
+le crée une fois, comme le montre le [README](https://github.com/ansibleforms/docker#database) du projet.
+
+Le RTE n'est pas publié sur l'hôte. Depuis la 7.3.0, l'application l'appelle sur `http://rte:8000` avec `RTE_TOKEN` et garde un WebSocket ouvert
+(`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)) : le RTE ne reçoit aucun paramètre de base de données ni le `.env`, seulement son jeton et quelques
+paramètres à lui dans `docker-compose.yml`. Le seed de configuration `data/seed.yaml` déclare un identifiant RTE avec le jeton et cette
+adresse, et le runner par défaut `rte`, en mode entrant, qui s'authentifie avec. Le RTE exécute les playbooks depuis le même dossier `data`
+(`RTE_FILES=local`). Quand vos playbooks ont besoin de plus de collections ou de bibliothèques Python, construisez votre propre RTE
+et faites pointer le service `rte` dessus (voir [Construire votre propre RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Démarrer le projet docker-compose
+
+Démarrez les trois conteneurs en arrière-plan. L'application attend que MySQL soit en bonne santé, puis appelle le RTE :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Tester l'application
+
+Une fois les conteneurs démarrés, ouvrez AnsibleForms dans un navigateur :
+
+* Ouvrez `https://your_ip` (port 443, voir `WEBAPP_LOCAL_PORT` dans le fichier .env)
+* Connectez-vous en tant que `admin` avec le `ADMIN_PASSWORD` du fichier `.env` ; tant que c'est encore la valeur par défaut `AnsibleForms!123`, choisissez un nouveau mot de passe
+* Vérifiez sous **Connexions > Runners** que le RTE est listé comme `rte`, le runner par défaut, et que sa page affiche sa
+  **Connexion** comme **Connecté**
+* Étapes suivantes :
+  * Créez des formulaires en ajoutant des fichiers YAML au dossier data/forms/ ou en utilisant le concepteur intégré
+  * Ajoutez vos playbooks au dossier data/playbooks/
+  * Ajoutez une connexion LDAP
+  * Ajoutez des utilisateurs et des groupes
+  * Ajoutez des runners pour les formulaires de modèle : AWX, AAP ou Ascender, Semaphore, Rundeck ou Jenkins
+  * Ajoutez des identifiants pour les connexions externes, comme d'autres serveurs MySQL ou des API REST, ou à transmettre aux playbooks Ansible
+  * Connectez des dépôts Git et choisissez si vos formulaires et/ou vos playbooks se synchronisent avec un dépôt
+
+---
+
+## Structure des fichiers
+
+Le projet docker-compose a la structure de dossiers suivante :
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/fr/_get_started/installation/docker.md b/i18n/fr/_get_started/installation/docker.md
new file mode 100644
index 0000000..44fee0f
--- /dev/null
+++ b/i18n/fr/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Installation
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Lancer les images de l'application et du RTE d'AnsibleForms avec Docker ou Podman, à côté de votre propre serveur MySQL
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Vous pouvez faire tourner AnsibleForms avec Docker ou Podman sous forme de deux conteneurs, l'application et le RTE qui exécute les playbooks, connectés à une base de données MySQL.
+
+---
+
+## Prérequis
+
+Avant de commencer, il vous faut :
+
+* **Docker ou Podman** : l'un des deux installé et en fonctionnement
+* **MySQL** : installé et en fonctionnement
+
+---
+
+## Installer MySQL
+
+Installez MySQL 8+, ou MariaDB, sur un serveur Linux que le conteneur peut joindre :
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu fournit MySQL 8 :
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian fournit MariaDB à la place de MySQL, qu'AnsibleForms prend aussi en charge :
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 et ultérieur, ainsi que ses recompilations, fournissent MySQL 8 dans AppStream :
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms se connecte à la base de données par le réseau, en tant que `DB_USER` avec `DB_PASSWORD`. Donnez-lui un utilisateur dédié, avec des droits sur
+le seul schéma `AnsibleForms`, pas root :
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+C'est tout ce dont AnsibleForms a besoin : avec cela, il crée et met à jour son schéma et fait ses sauvegardes. La page **Statut** et le journal
+avertissent quand l'utilisateur a des droits sur toutes les bases de données. Sur Ubuntu et Debian, le serveur n'écoute que sur localhost : définissez `bind-address` dans sa
+configuration pour que les conteneurs puissent le joindre.
+
+---
+
+## Préparer les dossiers
+
+AnsibleForms 7 tourne dans deux conteneurs : l'application, et le RTE (runtime environment) qui exécute les playbooks. Les deux montent un dossier pour
+votre `config.yaml`, vos formulaires, playbooks, journaux et certificats, et un dossier pour la clé SSH. Les images tournent sous l'utilisateur `node` (uid 1000),
+donnez donc les deux dossiers à cet utilisateur :
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Mettez les paramètres de l'application dans un fichier d'environnement : la connexion à la base de données,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) avant d'enregistrer le moindre identifiant, le jeton que l'application et le
+RTE partagent ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), au moins 16 caractères) et le seed de configuration qui déclare le RTE :
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+Le RTE reçoit son propre fichier, sans les paramètres de la base de données : depuis la 7.3.0, l'application l'appelle et garde un WebSocket ouvert
+(`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)), et il exécute les playbooks depuis les mêmes dossiers (`RTE_FILES=local`) :
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+Le [seed de configuration](../seed/) déclare un identifiant RTE avec l'adresse du RTE et son jeton, et le runner par défaut `rte` qui s'authentifie
+avec :
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Démarrer les conteneurs
+
+Lancez les images publiées sur le GitHub Container Registry (voir [Tags d'image](./#image-tags)) :
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) pour l'application et
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) pour le RTE.
+
+Le seed ajoute le RTE sous **Connexions > Runners** comme runner `rte`, celui par défaut, les formulaires de playbook s'exécutent donc dessus sans autre
+configuration. L'application crée le schéma à son premier démarrage, et appelle le RTE dès que les deux tournent (un exemple de `config.yaml` se trouve dans le
+[projet docker-compose](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)) :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Une fois démarrés, les deux conteneurs sont listés :
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman accepte les mêmes options et ne nécessite pas de service :
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Une fois démarrés, les deux conteneurs sont listés :
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+L'application écoute sur le port `8000`, en HTTP sauf si vous définissez `HTTPS=1`. Le RTE n'est pas publié sur l'hôte : seule l'application l'appelle, à l'intérieur
+du réseau. `--stop-timeout 30` laisse au RTE le temps de terminer ses playbooks en cours lors d'un arrêt (voir
+[Faire tourner un RTE](../rte/run.html) pour les paramètres du RTE et pour construire votre propre RTE).
+
+---
+
+## Tester l'application
+
+Une fois les conteneurs démarrés, ouvrez AnsibleForms dans un navigateur :
+
+* Ouvrez `http://your_ip:8000` (ou HTTPS, si vous avez défini `HTTPS=1`)
+* Connectez-vous en tant que `admin` / `AnsibleForms!123` (ou avec le mot de passe défini par `ADMIN_PASSWORD`), et choisissez un nouveau mot de passe
+* Vérifiez sous **Connexions > Runners** que le RTE est listé comme `rte`, le runner par défaut, et que sa page affiche sa
+  **Connexion** comme **Connecté**
+* Étapes suivantes :
+  * Créez des formulaires en ajoutant des fichiers YAML au dossier `forms` ou en utilisant le concepteur intégré
+  * Ajoutez vos playbooks au dossier `playbooks` du dossier persistant monté
+  * Ajoutez une connexion LDAP
+  * Ajoutez des utilisateurs et des groupes
+  * Ajoutez des runners pour les formulaires de modèle : AWX, AAP ou Ascender, Semaphore, Rundeck ou Jenkins
+  * Ajoutez des identifiants pour les connexions externes, comme d'autres serveurs MySQL ou des API REST, ou à transmettre aux playbooks Ansible
diff --git a/i18n/fr/_get_started/installation/from-source.md b/i18n/fr/_get_started/installation/from-source.md
new file mode 100644
index 0000000..9745120
--- /dev/null
+++ b/i18n/fr/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Depuis les sources
+parent: Installation
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Depuis les sources
+{: .no_toc }
+
+Construire AnsibleForms depuis les sources et le faire tourner avec Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Organisation du code
+
+Le dépôt contient deux applications Node.js, qu'une construction réunit en une seule :
+
+* **client** : l'interface web, écrite en Vue 3 et construite en fichiers statiques avec Vite
+* **server** : l'API, écrite avec Express. Elle confie les jobs aux runners, se connecte à la base de données et sert le client construit.
+  Démarré avec `AF_ROLE=rte`, le même serveur est le RTE (runtime environment) qui exécute les playbooks
+
+Seul le client est construit ; sa sortie va dans le dossier `views` du serveur, comme dans l'[image Docker](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Prérequis
+
+Construire et exécuter depuis les sources demande de solides compétences Linux et quelques connaissances de Node.js. Vous installez chaque composant vous-même. Pour
+faire tourner AnsibleForms sans conteneurs et sans le construire, l'[installation native](native.html) de l'installateur fait tout cela pour vous :
+
+* **Node.js 26** (la version de `.nvmrc` ; 24 au minimum), avec npm
+* **Git**, pour récupérer le code et synchroniser les dépôts
+* **Le client OpenSSH**, pour git en SSH, et **sshpass**, pour les playbooks qui se connectent avec un mot de passe SSH
+* **Le client MariaDB** (`mariadb`, `mariadb-dump`), pour les sauvegardes et les restaurations, y compris avec un serveur MySQL
+* **MySQL 8+ ou MariaDB**, joignable depuis le serveur
+* **Ansible**, pour le processus RTE qui exécute les playbooks (`ansible-playbook` dans son path). Le processus de l'application lui-même n'a besoin
+  ni d'Ansible ni de Python, et avec seulement des formulaires de modèle (AWX, AAP, Ascender et les autres runners), vous n'avez besoin d'aucun RTE
+
+Installez-les pour votre distribution :
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 vient du dépôt NodeSource, les autres outils d'Ubuntu lui-même :
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 vient du dépôt NodeSource, les autres outils de Debian lui-même :
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js vient de NodeSource et `sshpass` d'EPEL (sur RHEL lui-même, activez EPEL comme Red Hat le documente) :
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Vérifiez `node --version` (26) et `ansible-playbook --version` ; pour la base de données et son utilisateur, voir [Installer MySQL](docker.html#install-mysql).
+
+---
+
+## Récupérer le code
+
+Clonez le dépôt dans un dossier de votre choix, appartenant à l'utilisateur qui fera tourner l'application. Les exemples utilisent `/srv/apps/ansibleforms` :
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Construire
+
+Construisez en trois étapes, depuis le dossier du dépôt. Construisez d'abord le client :
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Installez ensuite les dépendances du serveur :
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Enfin, copiez le client construit dans le dossier `views` du serveur :
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Configurer
+
+Le serveur lit ses paramètres dans des variables d'environnement et, en production, aussi dans `server/persistent/.env`, le fichier
+dans lequel écrivent les pages de paramètres.
+
+Partez du fichier d'exemple à la racine du dépôt et définissez au moins la connexion MySQL (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`) :
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Toutes les variables sont décrites sous [Variables d'environnement](../customization). Tout le reste est stocké par défaut dans `server/persistent` :
+`config.yaml`, le dossier `forms` et des certificats auto-signés y sont créés au premier démarrage, à côté des journaux.
+Mettez vos playbooks dans `server/persistent/playbooks`, ou faites pointer `ANSIBLE_PATH` ailleurs dans l'environnement du RTE, qui la lit.
+
+---
+
+## Exécuter
+
+Faites tourner AnsibleForms en production, ou en mode développement pour travailler sur le code lui-même :
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Production</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Développement</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Démarrez le serveur en mode production depuis le dossier `server` :
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Une application démarrée depuis la ligne de commande s'arrête quand vous vous déconnectez. [PM2](https://pm2.keymetrics.io/) la fait tourner en
+arrière-plan, la redémarre après un plantage et la relance au boot :
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Les playbooks s'exécutent sur un RTE : démarrez le même serveur une seconde fois avec `AF_ROLE=rte`, sur un port à lui. L'application l'appelle et garde
+un WebSocket ouvert (`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)), et il exécute les playbooks depuis les mêmes dossiers
+(`RTE_FILES=local`). Il lit aussi `persistent/.env`, mais n'utilise aucun de ses paramètres de base de données. Ajoutez à `persistent/.env` le jeton que l'application et le RTE partagent,
+d'au moins 16 caractères, et le seed de configuration qui déclare le RTE :
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+Le [seed de configuration](../seed/) déclare un identifiant RTE avec l'adresse du RTE et son jeton, et le runner par défaut `rte` qui s'authentifie
+avec :
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Sans seed, ajoutez-les sous **Connexions > Identifiants** (un identifiant RTE avec cette adresse et le jeton) et
+**Connexions > Runners** (type RTE, **Mode** **Entrant**). Démarrez ensuite le RTE, sur `127.0.0.1` uniquement :
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+Les paramètres du RTE sont décrits sur la page [Faire tourner un RTE](../rte/run.html). Vérifiez que PM2 liste les deux processus :
+
+```bash
+pm2 status
+```
+
+Les deux sont `online` :
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Pour travailler sur le code lui-même, démarrez tout depuis la racine du dépôt avec rechargement à chaud : le serveur sur le port 3001, un RTE sur le port 8010
+et le client sur `https://localhost:8443`. Dans ce mode, le serveur et le RTE lisent `server/.env.development` à la place :
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+Le RTE (`npm run dev:rte`) a besoin de `ansible-playbook` dans le path, et s'ajoute lui-même comme runner en mode base de données, obsolète, pour
+le développement seulement ; `npm run dev:local` démarre le client et le serveur sans lui. Le [guide de contribution](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) décrit les tests et les vérifications à lancer.
+
+</div>
+</div>
+
+---
+
+## Premier démarrage
+
+Ouvrez le serveur dans un navigateur (avec le `.env` d'exemple, `https://your_ip:8443`). Sur une base de données vide, le schéma est créé au
+premier démarrage.
+
+Les identifiants admin par défaut sont :
+
+* nom d'utilisateur : `admin`
+* mot de passe : `AnsibleForms!123`
diff --git a/i18n/fr/_get_started/installation/index.md b/i18n/fr/_get_started/installation/index.md
new file mode 100644
index 0000000..a622e03
--- /dev/null
+++ b/i18n/fr/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Installation
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Installation
+{: .no_toc }
+
+Choisir une méthode d'installation pour AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les administrateurs qui mettent en place une nouvelle instance : choisissez une méthode d'installation, puis suivez sa page.
+
+---
+
+## Dans cette section
+
+AnsibleForms prend en charge plusieurs méthodes d'installation, chacune décrite sur sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Installateur](installer.html) | Une seule commande qui installe un contrôleur ou un Runner sur Docker, Podman, Kubernetes ou en natif, puis le met à niveau et le sauvegarde |
+| [Natif](native.html) | L'installation de l'installateur sans conteneurs : Node.js, MariaDB et Ansible sur le serveur, AnsibleForms sous forme de services systemd |
+| [Docker](docker.html) | Installer MySQL et lancer l'image Docker préconstruite avec les variables d'environnement requises |
+| [Docker Compose](docker-compose.html) | Télécharger le [projet docker-compose](https://github.com/ansibleforms/docker) et utiliser docker-compose pour démarrer à la fois MySQL et AnsibleForms |
+| [Depuis les sources](from-source.html) | Installer toutes les dépendances à la main, puis construire et démarrer le code |
+| [Kubernetes](kubernetes.html) | Installer le chart Helm et utiliser Kubernetes pour démarrer AnsibleForms et sa base de données MySQL |
+
+{: .note }
+> **Recommandation** L'installateur, depuis la 7.3.0, est le moyen le plus rapide d'obtenir une instance fonctionnelle : il met en place le projet Docker Compose sur
+> Docker ou Podman, ou l'une des autres méthodes, à partir de quelques questions. Les images Docker contiennent toutes les dépendances.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Pour passer une installation existante à une version plus récente, voir [Mise à niveau](../upgrading/).
+
+Chaque méthode fait tourner un RTE à côté de l'application, le conteneur (ou le service) qui exécute les playbooks. Pour en ajouter un autre, sur un autre hôte ou dans un autre
+datacenter, installez un Runner avec l'[installateur](installer.html#a-runner) : il appelle AnsibleForms via un WebSocket (sortant, voir
+[Modes](../rte/modes.html)) et ne détient aucun identifiant de base de données. Voir aussi [Environnements d'exécution](../rte/) et son guide pratique
+[Un RTE dans un autre datacenter](../rte/another-datacenter.html).
+
+---
+
+## Tags d'image
+
+L'image est publiée sous `ghcr.io/ansibleforms/ansibleforms` sur le GitHub Container Registry, qui appartient au
+projet et ne limite pas le débit des récupérations anonymes. Toutes les versions à partir de la 7.0.0 sont publiées uniquement là, et les versions 6.x
+s'y trouvent aussi.
+
+Depuis la 7, les playbooks s'exécutent sur un RTE, publié en trois couches à côté de l'application (voir [Les images RTE](../rte/images.html)) :
+
+| Image | Ce que c'est |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | L'application web et l'API, sans python ni ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Le RTE sans python ni ansible : la base pour le vôtre |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base avec python, ansible-core et quelques bibliothèques : celle à laquelle ajouter vos collections |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Le core avec le paquet `ansible`, ses collections et ses bibliothèques : le RTE par défaut |
+
+Les quatre images sont construites dans la même exécution et portent les mêmes tags, un tag RTE correspond donc toujours à celui de l'application.
+
+L'ancien dépôt Docker Hub, `ansibleguy/ansibleforms`, n'est plus mis à jour. Il garde ses versions
+existantes mais ne reçoit aucune nouvelle version d'aucune des deux branches. Si vous récupérez vos images depuis là, passez
+à `ghcr.io/ansibleforms/ansibleforms` avec le même tag pour continuer à recevoir les mises à jour.
+
+Les tags suivants sont disponibles sur chaque image ; les images RTE commencent à la 7.0.0, elles n'ont donc pas de tags 6.x :
+
+| Tag | Pointe vers |
+|---|---|
+| `latest` | la version la plus récente de la version majeure la plus récente |
+| `7`, `6` | la version la plus récente de cette version majeure |
+| `7.0`, `6.5` | la version la plus récente de cette version mineure |
+| `7.0.0`, `6.5.5` | exactement cette version |
+| `latest-rc` | la release candidate la plus récente, ou la version la plus récente quand elle est plus récente ; chaque candidate a aussi son propre tag |
+
+`latest` ne fait qu'avancer : un correctif pour une version majeure plus ancienne (par exemple une 6.5.x publiée
+après la 7.0.0) fait avancer `6` et `6.5`, mais jamais `latest`.
+
+Pour rester sur une version majeure, utilisez son numéro (`6`) au lieu de `latest`.
diff --git a/i18n/fr/_get_started/installation/installer.md b/i18n/fr/_get_started/installation/installer.md
new file mode 100644
index 0000000..9f970bf
--- /dev/null
+++ b/i18n/fr/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Installateur
+parent: Installation
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# L'installateur
+{: .no_toc }
+
+Installer, mettre à niveau et entretenir AnsibleForms sur un serveur Linux, en une seule commande
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs : le moyen le plus rapide d'obtenir une instance fonctionnelle, ou un Runner pour un AnsibleForms installé ailleurs. Depuis la 7.3.0.
+
+---
+
+## Ce qu'il installe
+
+L'installateur pose quelques questions dans un assistant en plein écran, affiche chaque réponse pour vérification, et seulement ensuite modifie le serveur.
+Il installe l'un de deux rôles, sur l'un de quatre moteurs :
+
+| Rôle | Ce que c'est |
+|---|---|
+| Contrôleur | L'application complète : l'interface web, sa base de données et son propre Runner. Choisissez-le pour une première installation |
+| Runner | Un RTE qui exécute les playbooks d'un AnsibleForms installé ailleurs, par exemple dans un autre réseau, une DMZ ou un autre datacenter. Il communique avec AnsibleForms via un seul WebSocket et ne détient aucun identifiant de base de données |
+
+Les moteurs sur lesquels il les installe :
+
+| Moteur | Comment il tourne |
+|---|---|
+| Docker | Le [projet Docker Compose](docker-compose.html), sur Docker Engine avec son plugin compose. Les conteneurs redémarrent avec Docker |
+| Podman | Le même projet sur Podman, rootless ou en root, avec podman-compose. Une unité systemd démarre les conteneurs au boot |
+| Kubernetes | Le [chart Helm](kubernetes.html), sur le cluster que `kubectl` atteint. Un contrôleur est servi derrière un ingress ; un Runner utilise le mode runner du chart |
+| Directement sur ce serveur | Sans conteneurs : Node.js, MariaDB et Ansible sur le serveur, et AnsibleForms sous forme de services systemd. Voir [Installation native](native.html) |
+
+Après l'installation, le même programme met à niveau l'installation, la sauvegarde, affiche son état et la supprime. Il prend aussi en charge un
+AnsibleForms qu'il n'a pas installé, comme un AnsibleForms mis en place à la main à partir du projet Docker Compose (voir [Une installation existante](#an-existing-installation)).
+
+---
+
+## Le lancer
+
+Le script d'installation télécharge l'installateur pour ce serveur et le démarre :
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Les variantes habituelles : en root, pour installer Docker ou Podman, pour installer directement sur le serveur ou sous `/opt` ; avec une commande ou
+des options (voir [Options](#flags)) ; et l'installateur d'une version donnée au lieu de la dernière :
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+Le script :
+
+1. Vérifie que le serveur tourne sous Linux sur amd64 ou arm64, et trouve `curl` ou `wget` et `sha256sum`
+2. Télécharge `ansibleforms-installer_linux_<arch>` depuis la dernière release de
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases), ou depuis la release que nomme `AF_INSTALLER_VERSION`
+3. Le vérifie avec le `checksums.txt` de la release, et n'utilise aucun téléchargement dont la somme de contrôle diffère
+4. Le garde sous le nom `ansibleforms-installer`, dans `/usr/local/bin` pour root et `~/.local/bin` sinon, pour les mises à niveau et les sauvegardes ultérieures.
+   Via sudo, lancez-le par son chemin complet : le `secure_path` de sudo, comme sur les systèmes Red Hat, omet souvent `/usr/local/bin`
+5. Le démarre avec les options données, en lisant le clavier depuis le terminal même si le script est arrivé par un pipe
+
+Sans terminal, par exemple dans un job de CI, l'installateur tourne sans surveillance (voir [Sans surveillance](#unattended)).
+
+---
+
+## L'assistant
+
+L'assistant pose une question à la fois, avec les étapes listées à gauche. **Échap** revient à l'étape précédente, en gardant sa réponse :
+
+| Étape | Ce qu'elle demande |
+|---|---|
+| Langue | La langue de l'installateur, d'après la locale de ce serveur par défaut : catalan, allemand, anglais, espagnol, français, italien, japonais, néerlandais, polonais, portugais ou chinois. Demandée en premier, avant que l'installateur ne dise quoi que ce soit d'une installation qu'il a trouvée |
+| Nouveautés | Ce qui est nouveau dans la version qu'il installe, avec d'abord les changements incompatibles, les suppressions et les obsolescences |
+| Rôle | Contrôleur ou Runner |
+| Moteur | Docker, Podman, Kubernetes, ou directement sur ce serveur |
+| Dossier | Le dossier d'installation, et le nom de l'instance |
+| Adhésion, Application, Mode | Un Runner seulement : voir [Un Runner](#a-runner). Pas le mode sur Kubernetes |
+| Réseau | Le port de l'interface web, ou du Runner. Pas sur Kubernetes |
+| HTTPS | La façon dont les navigateurs se connectent à un contrôleur |
+| Admin | Le mot de passe du premier admin, saisi deux fois |
+| Cluster, Ingress, Stockage | Kubernetes seulement : le namespace et la release, l'ingress (un contrôleur), la classe de stockage |
+| Vérification | Toutes les réponses : **Installer**, ou **Modifier les réponses** |
+
+**Moteur.** La liste montre ce que ce serveur possède. Un moteur absent est proposé comme *Docker (non installé : l'installateur l'installe)*
+ou de même pour Podman : une fois que vous confirmez, l'installateur installe Docker avec le script de Docker lui-même (`get.docker.com`, plugin compose
+inclus) ou Podman avec podman-compose depuis les paquets de la distribution. Cela nécessite root. Kubernetes est proposé quand `kubectl` et
+`helm` sont installés et atteignent un cluster. *Directement sur ce serveur* nécessite root et un Linux pris en charge, et indique pourquoi quand il est grisé.
+
+**Dossier.** Les valeurs par défaut :
+
+| | Contrôleur | Runner |
+|---|---|---|
+| Dossier, en root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Dossier, avec un autre utilisateur | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Nom d'instance, Docker ou Podman | `af` | `runner` |
+| Nom d'instance, natif | `ansibleforms` | `ansibleforms-runner` |
+
+Avec Docker ou Podman, le dossier contient le fichier compose et son `.env` avec les secrets, ainsi que toutes les données : base de données, formulaires, playbooks
+et journaux. Il doit être vide. Le nom d'instance, en lettres minuscules, chiffres et `-`, préfixe les conteneurs (`af_app`, `af_db`, `af_rte`), si bien que plusieurs
+instances peuvent partager un serveur. Le nom d'instance d'un Runner est aussi le nom de son runner sous **Connexions > Runners** (`RTE_NAME`).
+
+**Réseau.** L'interface web d'un contrôleur écoute sur `443`, ou sur le port libre suivant. **HTTPS** propose ensuite :
+
+| Choix | Ce qu'il fait |
+|---|---|
+| HTTPS avec un certificat autosigné créé pour ce serveur | Un certificat pour les noms de ce serveur, valable dix ans. Les navigateurs vous demandent de l'accepter une fois |
+| HTTPS avec mon propre certificat et ma clé | Votre propre certificat et votre clé, au format PEM, de votre CA ou de Let's Encrypt |
+| HTTP, avec HTTPS géré par un reverse proxy placé devant | Du HTTP simple sur le port, pour nginx, Traefik ou un répartiteur de charge qui gère le HTTPS |
+
+**Admin.** Le mot de passe de l'utilisateur `admin`, saisi deux fois pour qu'une faute de frappe ne vous bloque pas. Laissé vide, l'installateur en génère
+un robuste.
+
+**La fin.** L'installateur génère le mot de passe de la base de données et les secrets, démarre AnsibleForms et attend qu'il réponde. Il
+affiche ensuite l'adresse à ouvrir, l'utilisateur et le mot de passe, et le dossier. Les Runners installés pour lui demandent à rejoindre, et un admin les approuve
+sous **Connexions > Runners** (voir [Un Runner](#a-runner)).
+
+---
+
+## Un Runner
+
+Un Runner est un RTE pour un AnsibleForms qui tourne ailleurs, en version 7.3.0 ou ultérieure. Il ne détient aucun identifiant de base de données : il s'authentifie
+avec un jeton à lui, qu'AnsibleForms garde dans un identifiant RTE (voir [Modes](../rte/modes.html)). Après le dossier, l'assistant
+demande trois choses de plus :
+
+| Étape | Ce qu'elle demande |
+|---|---|
+| Application | L'adresse de l'AnsibleForms pour lequel travaille ce Runner, celle que les gens ouvrent dans un navigateur |
+| Mode | **Sortant : le Runner se connecte à AnsibleForms** (par défaut), ou **Entrant : AnsibleForms se connecte au Runner** |
+| Réseau | Le port du Runner, `8000` par défaut. En sortant, seuls les contrôles de santé y écoutent, joignables depuis ce serveur uniquement. En entrant, aussi l'adresse de ce serveur telle qu'AnsibleForms l'atteint |
+
+`--role runner` saute la question du rôle, si bien que cette commande, lancée sur le serveur du Runner, commence par les questions d'un Runner :
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+L'installateur se connecte ensuite à AnsibleForms. Un certificat autosigné, ou d'une CA privée, fait demander **Faire confiance à ce certificat ?** :
+oui définit [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) sur le Runner. Il lit la version qu'exécute AnsibleForms,
+refuse une version antérieure à la 7.3.0, et installe le Runner avec cette même version, quelle que soit la version que l'installateur lui-même installerait.
+
+Choisissez sortant pour une DMZ, du NAT, ou une zone qui n'autorise aucune connexion entrante : uniquement du trafic de ce serveur vers AnsibleForms, sur son
+port. Choisissez entrant pour les réseaux où c'est le côté central qui ouvre chaque connexion.
+
+La vérification affiche **Inscription : demande l'approbation**, ou **lui-même, avec un jeton d'adhésion** quand `--join` en a fourni un. À la fin, l'installateur
+affiche le nom du Runner, son mode, l'application et, en entrant, son adresse, puis indique qu'il a demandé à rejoindre AnsibleForms : approuvez-le sous
+**Connexions > Runners**, après avoir vérifié que l'empreinte qui y est affichée est celle qu'il imprime :
+
+```
+Fingerprint: abcd-ef12
+```
+
+L'empreinte correspond aux 8 premiers chiffres hexadécimaux du SHA-256 du jeton du Runner, `RTE_TOKEN`, qui est conservé dans le fichier
+`.env` du dossier (`rte.env` pour une [installation native](native.html)). Voir [Approuver un RTE](../runners/registration.html#approving-an-rte). Avec `--join`, le Runner est approuvé tout de suite :
+il s'est inscrit lui-même, et apparaît comme connecté sous **Connexions > Runners**.
+
+Un Runner entrant sert son socket en HTTPS. L'installateur crée un certificat autosigné pour l'adresse par laquelle AnsibleForms
+l'atteint, valable dix ans, dans le `data/certificates` du dossier, et définit `RTE_URL` à `https://<address>:<port>`.
+Le Runner envoie le certificat quand il demande à rejoindre, et AnsibleForms l'épingle : il n'appelle ce Runner que lorsqu'il présente
+ce même certificat, aucune CA n'est donc nécessaire. L'installateur imprime l'empreinte du certificat sous celle du jeton :
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+Ce sont les 8 premiers chiffres hexadécimaux du SHA-256 des octets DER du certificat, sous la forme `xxxx-xxxx`. Avant d'approuver le Runner,
+vérifiez que la boîte de dialogue d'approbation affiche la même empreinte de certificat. Un Runner inscrit avec `--join` l'imprime aussi.
+
+Sur Kubernetes, un Runner est le mode runner du chart Helm, et toujours sortant : l'assistant ne demande ni mode ni réseau, puisque rien
+ne l'atteint de l'extérieur (voir [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Pour un contrôleur sur Kubernetes, l'installateur installe le [chart Helm](kubernetes.html) sur le cluster que `kubectl` atteint :
+
+| Question | Valeur par défaut |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nom de la release Helm | `ansibleforms` |
+| Nom d'hôte servi par l'ingress | Aucune : obligatoire, par exemple `ansibleforms.example.com` |
+| Classe d'ingress | L'une de celles du cluster, `nginx` par défaut |
+| Le servir en HTTPS (avec le certificat de l'ingress) ? | Oui |
+| Classe de stockage pour les volumes | Celle par défaut du cluster |
+
+Le mot de passe admin se trouve dans le Secret `<release>-secrets` de ce namespace, sous la clé `ADMIN_PASSWORD`. L'installateur garde les
+valeurs du chart dans un fichier à côté de son fichier d'état, `<release>-values.yaml`, et les réapplique lors des mises à niveau ; `--values` ajoute un fichier à vous. Le chart d'une version est publié peu après elle.
+
+Pour un Runner, l'installateur installe le même chart dans son [mode runner](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`) : un RTE
+seul, sans application, sans base de données et sans ingress, qui appelle AnsibleForms (sortant). Après l'adresse de l'application, l'assistant demande :
+
+| Question | Valeur par défaut |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nom de la release Helm | `ansibleforms-runner`, qui est aussi le nom de son runner sous **Connexions > Runners** |
+| Classe de stockage pour les volumes | Celle par défaut du cluster |
+
+L'installateur crée le jeton du Runner et définit l'adresse de l'application, le nom du runner et, quand vous faites confiance au certificat de l'application,
+`runner.appTlsVerify: false`. Avec `--join`, le jeton d'adhésion approuve le Runner tout de suite ; sans lui, le Runner demande à rejoindre, et
+l'installateur imprime son empreinte à vérifier avant que vous ne l'approuviez sous **Connexions > Runners**.
+
+---
+
+## Commandes
+
+L'installateur prend une commande, avant ou après ses options. Sans commande, il installe :
+
+| Commande | Ce qu'elle fait |
+|---|---|
+| `install` | Installe AnsibleForms, comme contrôleur ou comme Runner (par défaut). Sur un serveur qui a déjà une installation, la sienne ou une qu'il trouve, il propose de la mettre à niveau |
+| `upgrade` | Met à niveau vers une version plus récente, en affichant d'abord ses notes de version (voir [Mise à niveau](#upgrade)) |
+| `status` | Affiche l'installation (son rôle, son moteur et sa version) et ses conteneurs, pods ou services, et si elle répond. Il liste ensuite tout autre AnsibleForms qu'il trouve sur le serveur |
+| `backup` | Sauvegarde la base de données tout de suite, dans `installer-backups` du dossier d'installation (sur Kubernetes, `backups` à côté du fichier d'état de l'installateur). Un Runner n'a aucune donnée à sauvegarder |
+| `release-notes` | Affiche les notes de version d'une version, `--version` ou celle de cet installateur, les changements incompatibles d'abord |
+| `uninstall` | Supprime l'installation, et avec `--purge` ses données |
+| `version` | Affiche la version de l'installateur |
+
+L'installateur mémorise l'installation dans `/etc/ansibleforms/installer.json` pour root, ou `~/.config/ansibleforms/installer.json`
+pour un autre utilisateur, si bien que les commandes après `install` n'ont besoin d'aucune option et trouvent l'installation d'elles-mêmes. Ce dossier ne contient aucun binaire,
+et n'existe qu'une fois que l'installateur a installé un AnsibleForms ou en a pris un en charge :
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` demande **Supprimer aussi ses données (base, formulaires, playbooks, journaux) ?**. Pour les supprimer, tapez le nom de l'instance (la release Helm
+sur Kubernetes) ; sinon il supprime les conteneurs, pods ou services et garde les données.
+
+---
+
+## Options
+
+Chaque option répond à une question, que l'assistant saute alors. `ansibleforms-installer --help` les liste :
+
+| Option | Ce à quoi elle répond |
+|---|---|
+| `--lang <code>` | La langue : `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` ou `zh` |
+| `--version <version>` | La version d'AnsibleForms à installer ou vers laquelle mettre à niveau ; celle de cet installateur par défaut |
+| `--role <role>` | `controller` ou `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` ou `native` |
+| `--runtime <runtime>` | `docker` ou `podman` (compose) |
+| `--install-runtime` | Installer Docker ou Podman s'il manque, sans demander |
+| `--dir <folder>` | Le dossier d'installation (compose) |
+| `--name <name>` | Le nom de l'instance, le préfixe de ses conteneurs (compose, `af` par défaut) |
+| `--port <port>` | Le port sur l'hôte : l'interface web pour un contrôleur, le RTE pour un Runner |
+| `--tls <choice>` | `self`, `own` ou `off` (un contrôleur compose) |
+| `--cert <file>`, `--key <file>` | Les fichiers du certificat et de la clé, avec `--tls own` |
+| `--admin-password <password>` | Le mot de passe du premier admin ; généré par défaut |
+| `--join <token>` | Un jeton d'adhésion (`afj_...`), créé via l'API, qui approuve le Runner tout de suite (un Runner, sans surveillance ; voir [Jetons d'adhésion](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | L'adresse de l'application, par exemple `https://forms.example.com` (un Runner) |
+| `--runner-mode <mode>` | `outbound` (le RTE appelle l'application) ou `inbound` (l'application appelle le RTE) (un Runner) |
+| `--host <address>` | L'adresse de ce serveur, que l'application appelle (un Runner entrant) |
+| `--namespace <namespace>` | Le namespace Kubernetes, `ansibleforms` par défaut |
+| `--release <release>` | La release Helm, `ansibleforms` par défaut |
+| `--hostname <name>` | Le nom d'hôte de l'ingress (kubernetes) |
+| `--ingress-class <class>` | La classe d'ingress (kubernetes) |
+| `--storage-class <class>` | La classe de stockage (kubernetes) |
+| `--values <file>` | Un fichier de valeurs Helm supplémentaire (kubernetes) |
+| `--purge` | Avec `uninstall` : supprimer aussi les données |
+| `--source <folder>` | Une copie locale du dépôt [ansibleforms/docker](https://github.com/ansibleforms/docker) à partir de laquelle installer (hors ligne) |
+| `--bundle <file>` | Un bundle de version, `ansibleforms-<version>-linux-<arch>.tar.gz`, à partir duquel installer en natif (voir [Installation native](native.html#air-gapped)) |
+| `--yes` | Répondre à chaque question avec sa valeur par défaut (sans surveillance) |
+| `--verbose` | Afficher chaque commande exécutée |
+
+---
+
+## Sans surveillance
+
+Avec `--yes`, ou sans terminal, l'installateur ne demande rien : les options répondent à leurs questions et les valeurs par défaut au reste. Il
+saute la langue, les nouveautés, le mot de passe admin (généré, sauf si `--admin-password` en fournit un) et la vérification, et affiche
+à la place le lien vers les notes de version. Il n'installe un Docker ou un Podman manquant qu'avec `--install-runtime` ou `--yes`, et un Runner
+a besoin de `--app-url`. Sans `--join`, le Runner demande à rejoindre et attend l'approbation d'un admin ; avec, il est approuvé tout de suite.
+
+Un contrôleur sur Docker, en installant Docker s'il manque :
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Un Runner entrant sur Podman, que l'application appelle sur `rte-dmz.example.com:8000` :
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Une installation existante
+
+L'installateur mémorise ce qu'il a installé dans `installer.json`. Sans ce fichier, `install`, `upgrade` et `status` cherchent d'abord un
+AnsibleForms déjà présent sur le serveur, quel que soit ce qui l'a installé :
+
+| Trouvé | Comment il est trouvé | Pris en charge quand |
+|---|---|---|
+| Docker ou Podman | Des conteneurs de l'image de l'application ou du RTE, regroupés par projet compose | Le dossier contient le fichier compose et le `.env` du dépôt [ansibleforms/docker](https://github.com/ansibleforms/docker) : les services `mysqldb`, `app` et `rte`, dans les conteneurs `<name>_db`, `<name>_app` et `<name>_rte` |
+| Un Runner 7.2 | Un RTE seul dans son projet compose, avec les `DB_*` de l'application et sans `RTE_MODE` (mode base de données) | Son fichier compose est lisible. Sa mise à niveau le fait passer en mode socket (voir [Un Runner 7.2](#a-72-runner)) |
+| Kubernetes | Des releases Helm du chart `ansibleforms`, et des Deployments et StatefulSets de ses images | C'est une release du chart : ses valeurs actuelles deviennent son fichier de valeurs |
+| Natif | Des services systemd qui font tourner AnsibleForms avec Node.js | Ils suivent la disposition de l'installateur : `releases/`, `current`, `app.env` et `rte.env` (voir [Installation native](native.html#the-folder)) |
+| Aucun moteur | L'application ou un RTE qui répond sur un port habituel : 443, 3000, 3001, 8000, 8001, 8010 ou 8443 | Jamais : il tourne depuis les sources ou à la main. L'installateur se contente de le signaler |
+
+Seules les images de l'application et du RTE comptent : un conteneur MySQL nommé d'après AnsibleForms n'est pas une installation. L'installateur liste ce
+qu'il a trouvé, une ligne par élément, avec la raison et ce qu'il faut faire à la main pour un élément qu'il ne peut pas prendre en charge : son fichier compose n'est pas celui du dépôt,
+sa base de données est hors de son projet compose, il tourne sur Kubernetes sans le chart Helm, il est géré par Argo CD (mettez-le à niveau là,
+en changeant la version du chart de l'Application), ou sa version ne peut pas être lue.
+
+Pour une installation qu'il peut prendre en charge, `install` propose trois choix :
+
+| Choix | Ce qu'il fait |
+|---|---|
+| Prendre en charge et mettre à jour | Montre ce qu'il va mémoriser, puis écrit `installer.json` une fois que vous confirmez, et continue avec la [mise à niveau](#upgrade) |
+| Installer quand même un nouvel AnsibleForms à côté | Une seconde installation, avec son propre dossier, ses ports et sa base de données, après une confirmation à part |
+| Arrêter | Rien n'est modifié |
+
+Pour une installation qui exécute déjà la version que l'installateur installerait, le premier choix est **Prendre en charge** à la place : l'installateur
+mémorise où elle se trouve et comment elle tourne, pour ses sauvegardes, son état et ses prochaines mises à niveau, et rien n'est modifié pour l'instant.
+
+`upgrade` propose la même chose sans le deuxième choix, et s'arrête quand rien ne peut être pris en charge. Sans surveillance, `install` s'arrête avec un message,
+et `upgrade --yes` ne prend une installation en charge que lorsqu'il en trouve exactement une qu'il peut prendre en charge. Les valeurs actuelles d'une release Kubernetes sont
+enregistrées à côté de `installer.json`, et les mises à niveau les réappliquent avec le chart de la nouvelle version.
+
+---
+
+## Mise à niveau
+
+`ansibleforms-installer upgrade` fait passer l'installation à une version plus récente de la même version majeure. Il liste les versions plus récentes,
+la dernière en premier (sans surveillance, il prend la dernière), et affiche les notes de version de chaque version qu'il franchit, avec d'abord les changements incompatibles
+et les suppressions. Quand elles contiennent des changements incompatibles, il vous demande de confirmer que vous les avez lues ; sans surveillance, seul `--yes` permet de continuer.
+
+L'installateur sauvegarde la base de données avant tout changement. Quand la nouvelle version ne répond pas, il propose de revenir en arrière : la version
+précédente revient, et sa base de données est restaurée depuis cette sauvegarde. Il ne rétrograde pas, et il ne franchit pas de version majeure : suivez
+le [guide de mise à niveau](../upgrade-7.html) pour cela, par exemple de la 6.x à la 7.x, avec ce qu'il faut faire en 6.5 avant la mise à niveau.
+
+Sur Docker ou Podman, la mise à niveau d'un contrôleur met aussi ses fichiers à jour avec la nouvelle version du dépôt docker :
+
+| Fichier | Ce que fait la mise à niveau |
+|---|---|
+| `docker-compose.yml` | Remplacé par celui de la nouvelle version, après en avoir enregistré une copie dans `installer-backups` |
+| `.env` | Chaque ligne existante est conservée, et les clés dont la nouvelle version a besoin sont ajoutées, avec des secrets créés comme lors d'une nouvelle installation. Une copie est enregistrée d'abord |
+| `data/seed.yaml` | Remplacé quand c'est un seed livré par le dépôt docker, non modifié. Un seed modifié à la main est conservé, et le nouveau est enregistré à côté |
+| `data/` | Les nouveaux fichiers qu'apporte la version, comme un nouveau playbook, sont ajoutés. Chaque fichier existant est conservé |
+
+Un paramètre de base de données manquant (`MYSQLDB_USER` ou un mot de passe) ne peut pas être inventé pour une base de données qui existe, la mise à niveau s'arrête donc alors avant
+tout changement. Un retour arrière remet le fichier compose, le `.env` et le seed tels qu'ils étaient.
+
+Un Runner exécute la même version que son AnsibleForms : mettez d'abord AnsibleForms à niveau, puis ses Runners. La mise à niveau d'un Runner réécrit son
+fichier compose pour la nouvelle image RTE et garde son `.env` et ses données tels quels.
+
+---
+
+## Un Runner 7.2
+
+Un Runner de la 7.2 tourne en mode base de données, obsolète depuis la 7.3.0 : son RTE détient les paramètres de base de données d'AnsibleForms. L'installateur le
+trouve (voir [Une installation existante](#an-existing-installation)), et sa mise à niveau le fait passer en mode socket sous le même runner :
+
+1. Il lit le nom du runner (`RTE_NAME`) et son jeton (`RTE_TOKEN`) dans l'ancien conteneur RTE. Quand le RTE ne s'est pas inscrit lui-même
+   (`RTE_REGISTER=0`), vous tapez le nom qu'a son runner sous **Connexions > Runners**
+2. Il demande l'adresse de l'application et le mode, **sortant** par défaut ou entrant, et pour le mode entrant le port et l'adresse de ce serveur
+3. Il montre le plan, puis sauvegarde l'ancien fichier compose et le `.env` dans `installer-backups`
+4. Il écrit la disposition de Runner de l'installateur sans les paramètres `DB_*`. Il garde `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` et `METRICS_TOKEN`, qu'un RTE en mode socket lit toujours
+5. Il démarre le nouveau RTE à côté de l'ancien. Le nouveau RTE s'authentifie avec le propre jeton du runner, et AnsibleForms fait passer le runner au
+   nouveau mode de lui-même, **sans approbation** : ses jobs et les formulaires qui le nomment restent inchangés
+6. Une fois le nouveau RTE connecté, l'ancien conteneur est arrêté et supprimé
+
+Un Runner entrant sert du HTTPS avec un certificat épinglé, comme un nouveau (voir [Un Runner](#a-runner)), et l'installateur imprime l'empreinte de son
+certificat. Quand l'ancien RTE occupe le port dont le nouveau a besoin, il est arrêté d'abord, le Runner est donc hors ligne jusqu'à ce que le
+nouveau se connecte. Le nouveau RTE d'un Runner sortant prend un port libre sur `127.0.0.1` et tourne à côté de l'ancien sans interruption.
+
+Quand l'installateur ne parvient pas à lire un jeton dans l'ancien RTE, vous choisissez comment le nouveau RTE s'authentifie :
+
+| Choix | Ce qui suit |
+|---|---|
+| Saisir le jeton du runner | Le mot de passe de l'identifiant RTE du runner sous **Connexions > Identifiants**. Le runner garde son nom et ses jobs |
+| Rejoindre comme nouveau runner avec un jeton d'adhésion | Un [jeton d'adhésion](../runners/registration.html#join-tokens) ajoute un nouveau runner sous un autre nom. Retirez l'ancien runner à la main |
+
+Quand le nouveau RTE ne se connecte pas, l'installateur propose de remettre les anciens fichiers et de redémarrer l'ancien conteneur ; si AnsibleForms
+avait déjà fait passer le runner au nouveau mode, remettez son mode à base de données sous **Connexions > Runners**. Une fois le nouveau RTE connecté, il n'y a
+plus de retour possible : les anciens fichiers restent dans `installer-backups`.
+
+Quand AnsibleForms ne connaît aucun runner de ce nom, le nouveau RTE demande à rejoindre à la place et attend une approbation. Rejetez cette demande sous
+**Connexions > Runners**, puis relancez la mise à niveau avec le nom qu'a le runner à cet endroit.
+
+---
+
+## Versions
+
+La version de l'installateur suit celle de l'application : chaque version d'AnsibleForms est accompagnée d'un installateur de la même version, publié avec elle, et
+cet installateur installe cette version par défaut. `--version` en installe une autre. Chaque release de la
+[page Releases de l'installateur](https://github.com/ansibleforms/installer/releases) a des binaires pour Linux sur amd64 et arm64, avec leurs
+sommes de contrôle.
diff --git a/i18n/fr/_get_started/installation/kubernetes.md b/i18n/fr/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..ef47af5
--- /dev/null
+++ b/i18n/fr/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Installation
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Installer AnsibleForms et sa base de données MySQL avec le chart Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le chart Helm déploie AnsibleForms avec MySQL et le RTE qui exécute les playbooks (voir la [référence des valeurs](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+L'[installateur](installer.html) installe aussi le chart, à partir de quelques questions, et met à niveau une release qu'il n'a pas installée. Le même
+chart installe aussi un Runner seul, pour un AnsibleForms qui tourne ailleurs (voir [Un Runner sur Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Prérequis
+
+Avant de commencer, il vous faut :
+
+* **Un cluster Kubernetes** : avec `kubectl` configuré pour le joindre
+* **Helm 3** : pour installer et mettre à niveau le chart
+* **Du stockage** : une StorageClass pour le provisionnement dynamique, ou des PersistentVolumes créés à l'avance
+* **Un contrôleur d'ingress** : seulement si vous voulez exposer AnsibleForms via un ingress
+
+---
+
+## 1. Récupérer les valeurs du chart
+
+Récupérez les valeurs par défaut du chart dans un fichier à vous, depuis le dépôt du chart ou depuis le registre OCI :
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Dépôt du chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">Registre OCI</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Aucun dépôt à ajouter : le chart est récupéré depuis le GitHub Container Registry.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Configurer le stockage
+
+AnsibleForms et MySQL stockent tous deux leurs données sur un volume persistant. Définissez la StorageClass et la taille de chacun :
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Un `className` vide utilise la StorageClass par défaut du cluster. Le mode d'accès vaut `ReadWriteMany` par défaut, ce que beaucoup de classes de stockage
+ne proposent pas ; `ReadWriteOnce` convient avec un seul réplica. Pour des PersistentVolumes créés à l'avance, voir le
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) du chart.
+
+---
+
+## 3. Définir les identifiants
+
+AnsibleForms a besoin d'un compte admin, d'un mot de passe de base de données et d'un `ENCRYPTION_SECRET`, la clé qui chiffre les identifiants
+stockés dans AnsibleForms. Pour changer cette clé plus tard, mettez l'ancienne dans [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+le temps d'un démarrage : chaque secret stocké est alors rechiffré avec la nouvelle clé. Fournissez-les de l'une de ces trois façons :
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">Dans le fichier de valeurs</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Générés par le chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Secret existant</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Définissez-les dans `my_values.yaml`. Le chart les stocke dans un Secret nommé `<release>-secrets` :
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Laissez le chart générer ce que vous ne fournissez pas, à la première installation. Il garde ensuite les mêmes valeurs à chaque
+mise à niveau :
+
+```bash
+--set secrets.generate=true
+```
+
+Cela ne fonctionne pas avec Argo CD ou Flux, qui génèrent le rendu du chart sans accès au cluster. Le Secret généré
+survit à `helm uninstall` ; sauvegardez-le, car `ENCRYPTION_SECRET` ne peut pas être récupéré.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Faites pointer le chart vers un Secret que vous gérez, par exemple avec External Secrets, Sealed Secrets ou SOPS. Le chart
+n'en crée alors aucun :
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+Le Secret doit contenir `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` et `ADMIN_PASSWORD`.
+
+</div>
+</div>
+
+---
+
+## 4. Choisir l'image RTE
+
+AnsibleForms 7 n'exécute lui-même aucun playbook : c'est le RTE (runtime environment) qui le fait. Le chart le fait tourner comme second conteneur dans le
+pod du serveur, sur le même volume, et l'enregistre comme runner par défaut `rte`, les formulaires de playbook fonctionnent donc sans aucune configuration. Depuis la 7.3.0,
+l'application l'appelle sur `127.0.0.1` et garde un WebSocket ouvert (`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)) : le RTE ne reçoit aucun
+paramètre de base de données ni aucune clé de chiffrement. Le seed de configuration du chart déclare un identifiant RTE avec le jeton et cette adresse, et
+le runner, en mode entrant, qui s'authentifie avec.
+
+L'image par défaut, `ghcr.io/ansibleforms/ansibleforms-rte-full`, contient ansible avec ses collections et les bibliothèques Python qu'avait l'image 6.5.
+Pour plus, ou moins, construisez la vôtre sur l'une des trois couches RTE (`ansibleforms-rte-base`, `-rte-core` ou `-rte-full`, voir
+[Les images RTE](../rte/images.html)) et faites pointer le chart dessus :
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+Le jeton entre l'application et le RTE, et la clé qui signe les sessions, sont générés à la première installation dans
+le Secret `<release>-keys` et conservés à chaque mise à niveau. Avec un seed de configuration à vous, ajoutez-y cet identifiant et ce runner : les notes que Helm affiche après l'installation montrent comment faire
+(voir le [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) du chart).
+
+---
+
+## 5. Installer le chart
+
+Installez le chart dans son propre namespace avec vos valeurs :
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Avec le registre OCI, utilisez `oci://ghcr.io/ansibleforms/charts/ansibleforms` comme chart. Dans tout ce qui tourne sans surveillance,
+fixez la version du chart avec `--version`, pour qu'une nouvelle version ne soit jamais installée d'elle-même.
+
+---
+
+## 6. Vérifier l'installation
+
+Le chart inclut un test qui vérifie à la fois le serveur web et la connexion à la base de données :
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+Le test se termine par `OK` quand AnsibleForms répond et que sa base de données accepte les connexions.
+
+---
+
+## 7. Ouvrir AnsibleForms
+
+La façon d'atteindre AnsibleForms dépend de la manière dont le serveur est exposé :
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Avec le service `ClusterIP` par défaut et sans ingress, rien n'est exposé hors du cluster. Redirigez un port local pour
+y jeter un œil :
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Ouvrez ensuite `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Définissez `services.server.type: LoadBalancer` (éventuellement avec une adresse fixe dans `services.server.loadbalancer.ip`),
+puis attendez que le service obtienne son adresse :
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Activez l'ingress et définissez le nom d'hôte qui mène à votre contrôleur d'ingress :
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+Le [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) du chart couvre le TLS derrière un ingress, y compris le paramètre de backend dont le HTTPS sur le
+serveur a besoin.
+
+</div>
+</div>
+
+---
+
+## 8. Se connecter
+
+Connectez-vous avec l'utilisateur admin, `admin` par défaut. Pour lire le mot de passe dans le Secret :
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Avec `secrets.existingSecret`, lisez-le plutôt dans votre propre Secret.
+
+---
+
+## Un Runner sur Kubernetes
+
+Avec `runner.enabled`, le chart n'installe qu'un RTE : un Runner pour un AnsibleForms installé ailleurs, dans un autre namespace, un autre
+cluster ou sur une VM. Il appelle l'application et garde un WebSocket ouvert (`RTE_MODE=outbound`, voir [Modes](../rte/modes.html)), il n'a donc besoin
+d'aucune base de données, d'aucune clé de chiffrement ni d'aucun port entrant. Il ne génère ni application, ni MySQL, ni Service, ni Ingress :
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Valeur | Ce qu'elle fait |
+|---|---|
+| `runner.enabled` | N'installe que le Runner : ni application, ni MySQL, ni Service, ni Ingress |
+| `runner.appUrl` | L'adresse de l'application telle que les gens l'ouvrent, avec son `BASE_URL` s'il y en a un. Obligatoire |
+| `runner.name` | Le nom de runner sous lequel il rejoint (`RTE_NAME`). Vide : le nom de la release |
+| `runner.joinToken` | Un [jeton d'adhésion](../runners/registration.html#join-tokens) créé dans l'application, lu au premier démarrage pour approuver le Runner tout de suite |
+| `runner.appTlsVerify` | `false` accepte le certificat auto-signé de l'application (`APP_TLS_VERIFY=0`), à l'intérieur d'un réseau de confiance uniquement |
+
+Sans jeton d'adhésion, le Runner demande à rejoindre et attend qu'un admin l'approuve sous **Connexions > Runners**. Une fois approuvé, il
+s'authentifie avec son propre `RTE_TOKEN`, conservé dans le Secret `<release>-keys` : gardez ce Secret avec la release.
+L'[installateur](installer.html#kubernetes) installe aussi ce mode runner, quand vous choisissez le rôle Runner et Kubernetes.
+
+---
+
+## Étapes suivantes
+
+Le [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) du chart couvre le reste de la configuration :
+
+* **Votre propre base de données** : définissez `mysql.enabled: false` et faites pointer AnsibleForms vers un serveur MySQL existant
+* **Des formulaires depuis des ConfigMaps** : fournissez `config.yaml` et les fichiers de formulaires via des ConfigMaps
+* **Le HTTPS derrière un ingress**, les ressources, le placement sur les nœuds et les registres privés
+* **Le RTE** : son jeton, votre propre image RTE, ou pas de RTE du tout
+
+Pour passer à une version plus récente, voir [Mise à niveau sur Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/fr/_get_started/installation/native.md b/i18n/fr/_get_started/installation/native.md
new file mode 100644
index 0000000..91163b3
--- /dev/null
+++ b/i18n/fr/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Natif
+parent: Installation
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Installation native
+{: .no_toc }
+
+AnsibleForms directement sur le serveur, sans conteneurs, sous forme de services systemd que l'installateur met en place
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs de serveurs où les conteneurs ne sont pas autorisés : l'[installateur](installer.html) installe tout ce dont AnsibleForms a besoin sur
+le serveur lui-même, puis le met à niveau et le désinstalle. Il installe AnsibleForms 7.3.0 ou ultérieur.
+
+---
+
+## Ce qu'il faut
+
+Choisissez **Directement sur ce serveur, sans conteneurs** à l'étape **Moteur** de l'installateur, ou passez `--mode native`. Il faut :
+
+* **Root** : lancez l'installateur avec `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : les services tournent comme des unités systemd
+* **Un Linux pris en charge** : Ubuntu, Debian, RHEL et ses recompilations comme Rocky Linux et AlmaLinux, SUSE Linux Enterprise ou openSUSE
+* **amd64 ou arm64**
+* **Un accès à Internet** : vers les dépôts de la distribution, GitHub, nodejs.org et les index de paquets Python et Ansible (voir
+  [Hors ligne](#air-gapped) pour ce qu'un bundle de version remplace)
+
+Sur un serveur qui ne remplit pas ces conditions, le moteur apparaît comme *Directement sur ce serveur (nécessite root : lancez-le avec sudo)* ou
+*Directement sur ce serveur (non pris en charge sur ce Linux)*. Les deux rôles s'installent ainsi : un contrôleur, et un [Runner](installer.html#a-runner).
+
+---
+
+## Ce qu'il installe
+
+L'installateur installe ceci depuis les paquets de la distribution, pour les deux rôles :
+
+| Paquet | Pourquoi |
+|---|---|
+| `git` | Les dépôts |
+| Le client ssh | Les connexions des playbooks |
+| Le client MariaDB | Les sauvegardes de l'application : `app.env` définit [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) et [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) sur le client trouvé, `mariadb-dump` et `mariadb` ou les plus anciens `mysqldump` et `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | Les téléchargements |
+| `libatomic` | Node.js en dépend, et les serveurs minimaux ne l'ont pas |
+| `sshpass` | Les playbooks qui se connectent avec un mot de passe ssh. Sur RHEL et ses recompilations, il vient d'EPEL, que l'installateur tente d'activer avec `epel-release` ; quand il ne peut pas être installé, l'installation continue et le signale |
+| Le serveur MariaDB | Un contrôleur seulement : sa base de données |
+
+Ensuite, dans le dossier d'installation, chaque téléchargement étant vérifié avec sa somme de contrôle publiée :
+
+* **AnsibleForms** : le bundle de version `ansibleforms-<version>-linux-<arch>.tar.gz` de la release GitHub de l'application, l'application construite pour
+  Node.js. Une version sans bundle affiche *Sans conteneurs, il faut AnsibleForms 7.3.0 ou une version ultérieure.*
+* **Node.js** : la version la plus récente de la version majeure que nomme le bundle, depuis nodejs.org
+* **Python et Ansible** : uv, puis avec lui le Python des images RTE et un environnement virtuel avec Ansible et les bibliothèques de
+  l'image RTE full, puis ses collections Ansible (voir [Les images RTE](../rte/images.html)). Cela prend quelques minutes
+* **Les fichiers de départ** : les formulaires, les playbooks et les paramètres du dossier `data` du [projet docker-compose](https://github.com/ansibleforms/docker),
+  tels qu'une nouvelle installation Docker Compose les reçoit. Un Runner ne garde que sa configuration Ansible et ses paramètres ssh et git
+
+Pour un contrôleur, il crée ensuite le schéma `AnsibleForms` dans MariaDB, et un utilisateur de base de données nommé d'après l'instance avec tous les droits sur ce
+schéma et aucun ailleurs, qui ne se connecte que depuis ce serveur.
+
+---
+
+## Le dossier
+
+Tout se trouve dans le dossier d'installation, `/opt/ansibleforms` (ou `/opt/ansibleforms-runner` pour un Runner) par défaut :
+
+| Chemin | Ce qu'il contient |
+|---|---|
+| `releases/<version>/` | Une version : le bundle, son lien vers Node.js, son environnement virtuel Python et ses collections |
+| `current` | Le lien vers la version qui tourne ; une mise à niveau le déplace, un retour arrière aussi |
+| `runtime/` | Node.js, uv et Python, partagés par les versions |
+| `data/` | Ce que les conteneurs montent comme `/app/dist/persistent` : formulaires, playbooks, `config.yaml`, le seed de configuration, les certificats et les journaux |
+| `home/` | Le dossier personnel de l'utilisateur système : `.ssh` et `.gitconfig`, liés à `data/ssh` et `data/git` |
+| `app.env`, `rte.env` | Les paramètres et les secrets des services, lisibles uniquement par root et l'utilisateur système. Celui du RTE ne contient aucun paramètre de base de données |
+| `installer-backups/` | Les sauvegardes de la base de données que fait l'installateur, avant une mise à niveau ou avec `backup` |
+
+Les versions et les runtimes appartiennent à root, les services ne peuvent donc pas modifier leur propre code ; `data/` et `home/` appartiennent à l'utilisateur système.
+Les fichiers de la base de données eux-mêmes sont gérés par MariaDB, hors du dossier.
+
+---
+
+## Les services
+
+Un contrôleur fait tourner deux services systemd, un Runner un seul. Chacun tourne sous un utilisateur système nommé d'après l'instance (`ansibleforms` par défaut),
+depuis `current/server`, avec son fichier de paramètres :
+
+| Service | Ce qu'il exécute | Paramètres |
+|---|---|---|
+| `<name>` | L'application : l'interface web, l'API et le worker. Un contrôleur seulement | `app.env` |
+| `<name>-rte` | Le RTE qui exécute les playbooks | `rte.env` |
+
+Le RTE d'un contrôleur est `inbound` sur un port à lui sur `127.0.0.1` (`8001`, ou le suivant de libre, avec
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), exécute les playbooks depuis les dossiers de l'application (`RTE_FILES=local`),
+et est déclaré par le seed de configuration `data/seed.yaml` comme runner par défaut.
+
+Le RTE d'un Runner reçoit le mode, `APP_URL`, `RTE_NAME` et, avec `--join`, le jeton d'adhésion, et reçoit les playbooks avec chaque job (voir
+[Modes](../rte/modes.html)). Un RTE sortant ne reçoit aucun appel de l'application, il n'écoute donc que sur `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Un RTE entrant sert du HTTPS avec un certificat auto-signé de sa propre adresse dans `data/certificates`, qu'AnsibleForms épingle.
+Sans jeton d'adhésion, il demande à rejoindre, et un admin l'approuve sous **Connexions > Runners**.
+
+Ils démarrent au boot et redémarrent après une défaillance. Gérez-les et lisez leurs journaux avec les outils de systemd :
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+L'application peut écouter sur un port inférieur à 1024, comme `443`, sans root. Le RTE garde le droit d'utiliser `sudo`, dont les playbooks avec
+`become` ont besoin sur ce serveur, si bien qu'un playbook peut gérer le serveur sur lequel tourne le RTE.
+
+---
+
+## Mettre à niveau et revenir en arrière
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` met à niveau une installation native comme les autres (voir [Mise à niveau](installer.html#upgrade)), dans
+cet ordre :
+
+1. Met la nouvelle version en place à côté de celle qui tourne : son bundle, Node.js, Python, Ansible et les collections. Les services en cours
+   ne sont pas encore touchés
+2. Ajoute les nouveaux fichiers de départ qu'apporte la version, en gardant chaque fichier existant
+3. Sauvegarde la base de données (un contrôleur) dans `installer-backups/`, avec une copie de `app.env` et `rte.env`
+4. Arrête les services, fait pointer `current` vers la nouvelle version, et les redémarre
+5. Attend que l'application réponde avec la nouvelle version (un Runner : que son RTE écoute à nouveau)
+
+Quand la nouvelle version ne répond pas, l'installateur propose de revenir en arrière : `current` pointe à nouveau vers la version précédente, la
+base de données est restaurée depuis la sauvegarde, et les services démarrent. Seules la version en cours et la précédente sont conservées.
+
+Des services natifs dans la disposition de l'installateur sans `installer.json` à côté, par exemple après sa suppression, sont détectés par `install`
+et `upgrade`, qui proposent de les reprendre (voir [Une installation existante](installer.html#an-existing-installation)).
+
+---
+
+## Désinstaller
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` arrête et supprime les services. Il garde le dossier et la base de données, sauf si vous choisissez de supprimer
+les données (ou passez `--purge`) et tapez le nom de l'instance pour confirmer. Il supprime alors aussi la base de données et son utilisateur (un contrôleur),
+efface le dossier et supprime l'utilisateur système.
+
+Les paquets restent installés, MariaDB comprise : d'autres logiciels peuvent les utiliser.
+
+---
+
+## Hors ligne
+
+`--bundle` installe depuis un bundle de version que vous avez copié sur le serveur, au lieu de le télécharger depuis GitHub. Prenez le fichier de son
+architecture, `ansibleforms-<version>-linux-amd64.tar.gz` ou `-arm64`, dans les [Releases](https://github.com/ansibleforms/ansibleforms/releases) de l'application :
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` fait de même pour les fichiers de départ, depuis une copie locale du dépôt [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python avec ses paquets et les collections Ansible sont toujours téléchargés pendant l'installation.
diff --git a/i18n/fr/_get_started/upgrade-7.md b/i18n/fr/_get_started/upgrade-7.md
new file mode 100644
index 0000000..9688202
--- /dev/null
+++ b/i18n/fr/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Passer à la v7
+parent: Mise à niveau
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Passer à la v7
+{: .no_toc }
+
+Ce qu'il faut changer encore en 6.5, et ce qui change quand vous passez à la version 7
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La version 7 supprime tout ce que la 6.x avait rendu obsolète ; corrigez-le d'abord en 6.5, où l'ancien et le nouveau fonctionnent tous les deux, puis mettez à niveau.
+
+---
+
+## Avant la mise à niveau (en 6.5)
+
+### Les formulaires sont dans leurs propres fichiers
+
+Les formulaires ne se trouvent que dans le dossier des formulaires (`FORMS_FOLDER_PATH`) ou dans un dépôt de formulaires ; `config.yaml` garde les catégories, les rôles et les constantes.
+
+- **Un fichier `forms.yaml` :** renommez-le en `config.yaml`. En 6.5, la page des paramètres propose pour cela un bouton
+  **Convert forms.yaml to config.yaml**.
+- **Une section `forms:` dans la configuration de base :** la version 7 la rejette. Déplacez chaque formulaire dans son propre fichier, par exemple
+  en le faisant glisser vers un fichier dans le concepteur de la 6.5.
+- **Variables d'environnement :**
+
+  | Supprimée | À utiliser à la place |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` et `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### Le champ `table`
+
+La version 7 rejette les champs `table`, et leurs propriétés (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`) disparaissent avec eux : utilisez un champ `list` avec un `subform`, et transformez le `from` de chaque colonne en expression
+sur `__parent__` (voir la [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Propriétés renommées
+
+Chaque propriété supprimée a un remplacement direct :
+
+| Supprimée | À utiliser à la place |
+|---|---|
+| `disableRelaunch: true` (formulaire) | `allowRelaunch: false` |
+| `noOutput: true` (champ) | `output: false` |
+| `enableLogin` (option de rôle) | `allowLogin` |
+
+### Sources de données et schémas de données
+
+Les imports de sources de données et leurs pages d'administration ont été supprimés, de même que
+la collection Galaxy d'AnsibleForms, dont les modules ne servaient qu'à eux.
+
+- Les imports planifiés s'arrêtent et les tables des sources de données sont supprimées : notez d'abord ce dont vous avez besoin.
+- Les schémas de données qu'un import remplissait sont des bases de données à part et restent en place. Un formulaire qui
+  les interroge via un identifiant continue de fonctionner.
+- Pour garder ces données à jour, exécutez l'import comme un playbook à vous, par exemple depuis une
+  planification.
+
+### API v1
+
+`/api/v1/*` a été supprimé ; utilisez `/api/v2/*` (documentation interactive sur `/api/v2/docs`). Les appels
+qu'utilisent habituellement les scripts sont :
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+La v2 répond avec des codes de statut HTTP (`400`, `403`, `404`, `422`) et un corps JSON simple, et non avec l'enveloppe
+`{ status, message, data }` de la v1.
+
+**Les callbacks de l'authentification unique aussi.** Une URL de redirection avec `/api/v1/` ne répond plus : la connexion revient à
+la page de connexion sans connecter l'utilisateur. Remplacez-la par `/api/v2/` à deux endroits, sur le fournisseur SSO dans
+AnsibleForms et dans le fournisseur d'identité (les URI de redirection de l'inscription d'application Entra ID, les URI de redirection valides
+du client OIDC) :
+
+- Entra ID : `https://<your host>/api/v2/auth/azureadoauth2/callback`, ou `/api/v2/auth/entraid/callback` depuis la 7.3.0
+- OIDC : `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Ce qui change en 7
+
+La version 7 change la façon dont les playbooks s'exécutent et resserre plusieurs valeurs par défaut. Vérifiez chacun des points ci-dessous quand vous quittez la 6.5.
+
+### Les playbooks s'exécutent sur un RTE
+
+La version 7 n'exécute plus `ansible-playbook` dans le conteneur AnsibleForms. Les playbooks s'exécutent sur un environnement d'exécution (RTE),
+un conteneur à part, et l'image de l'application ne contient plus ni ansible ni python. Démarrez un RTE à côté de l'application, à partir de
+l'image `ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Depuis la 7.3.0, l'application appelle le RTE et garde un WebSocket ouvert (voir
+[Modes](rte/modes.html)) : le RTE ne reçoit aucun paramètre de base de données ni d'`ENCRYPTION_SECRET`. Ses paramètres :
+
+| Paramètre | Valeur |
+|---|---|
+| `AF_ROLE` | `rte`. Les images RTE le définissent déjà. |
+| `RTE_MODE` | `inbound` : l'application appelle le RTE. Un Runner dans un autre réseau utilise `outbound` (voir [Modes](rte/modes.html)). |
+| `RTE_TOKEN` | Un jeton d'au moins 16 caractères. L'application s'authentifie avec auprès du socket du RTE, et le RTE refuse de démarrer sans. |
+| `RTE_FILES` | `local` quand le RTE monte le même dossier persistant que l'application, comme lorsqu'il est à côté d'elle. |
+
+Déplacez ensuite les montages ansible du conteneur de l'application vers le RTE :
+
+- `ansible.cfg` sur `/etc/ansible/ansible.cfg`, vos rôles sur `/etc/ansible/roles` et vos collections sur
+  `/etc/ansible/collections`.
+- Montez aussi sur le RTE le même dossier persistant que l'application, pour qu'il trouve les playbooks et les dépôts.
+
+Déclarez ensuite le RTE comme runner, dans le [seed de configuration](seed/) comme le fait le projet Docker Compose, ou sous **Connexions → Runners** :
+un identifiant RTE avec l'adresse du RTE (par exemple `http://rte:8000`) et le même jeton, et un runner de type RTE, en mode entrant,
+qui le nomme :
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Le seed lit `RTE_TOKEN` dans l'environnement de l'application. Voir [Runners](runners.html) et [Environnements d'exécution](rte/).
+
+{: .warning }
+> **Le même contrat pour l'application et le RTE** L'application résout les identifiants d'un job et les remet au RTE scellés pour
+> ce RTE (contrat RTE 2, nouveau en 7.0.0). Un RTE d'un autre contrat refuse les jobs de l'application : utilisez l'image RTE de la même
+> version que l'application, et mettez les deux à niveau ensemble. Les versions 7 ultérieures continuent de fonctionner avec un RTE 7 plus ancien tant que le contrat
+> reste le même (voir [Mise à l'échelle](../rte/images.html#build-your-own-rte)).
+
+
+### Ce que contient l'image RTE
+
+Le RTE existe en trois couches, chacune construite sur la précédente. Choisissez celle qui convient à vos playbooks :
+
+| Image | Contenu |
+|---|---|
+| `ansibleforms-rte-full` | Celle par défaut. Ansible 14 avec ansible-core 2.21, et les collections et bibliothèques python qu'avait l'image 6.5. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core et quelques bibliothèques courantes, sans collections. Ajoutez les vôtres dans une image construite dessus. |
+| `ansibleforms-rte-base` | Le serveur seul, sans python ni ansible, pour construire un RTE avec vos propres versions. |
+
+Passer de la 6.5 (ansible 12 avec ansible-core 2.19) change aussi ceci pour vos playbooks :
+
+- **ansible-core 2.21 :** lisez les [guides de portage](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  de la 2.20 et de la 2.21.
+- **Python 3.14 :** les couches RTE tournent sur python 3.14.
+- **Plus de `boto` :** l'ancienne bibliothèque `boto` 2 a disparu. La collection `amazon.aws` utilise `boto3`, qui est inclus.
+
+Deux variables d'environnement appartiennent désormais au RTE et ne sont plus lues par l'application, définissez-les donc dans le conteneur RTE :
+
+| Variable | Changement |
+|---|---|
+| `ANSIBLE_PATH` | Le dossier des playbooks, sur le RTE. |
+| `PROCESS_MAX_BUFFER` | Désormais 50 MB par défaut. Au-delà, la sortie du job n'est plus stockée (le job l'indique), mais le playbook continue au lieu d'être arrêté. |
+
+
+### Les conteneurs tournent sous l'uid 1000
+
+Les images de l'application et du RTE tournent sous l'utilisateur `node` (uid 1000) au lieu de root, et leur dossier personnel est `/home/node` :
+
+- **Donnez les volumes à l'uid 1000, une fois.** Pour les volumes persistant et ssh, lancez
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v` ; pour un dossier de l'hôte, `sudo chown -R 1000:1000 <folder>`.
+  Sur Kubernetes, définissez `fsGroup: 1000`.
+- **Montez le dossier ssh sur `/home/node/.ssh`**, et non sur `/root/.ssh`. Si vous avez mis
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) à `/root`, supprimez-le ou mettez-le à `/home/node`.
+- **Votre propre image RTE**, construite sur une couche RTE, passe en `USER root` pour ses installations et revient en `USER node` à la fin.
+
+
+### La validation au lancement est activée
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) vaut désormais `enforce` par défaut (6.5 : `off`). Chaque
+lancement, depuis le navigateur ou depuis `POST /api/v2/job`, est vérifié selon les règles du formulaire, et le job utilise les extravars et
+les identifiants que le serveur construit à partir des valeurs vérifiées.
+
+- **Les appelants REST doivent envoyer `rawFormData`**, les valeurs brutes des champs telles que le navigateur les envoie. Un lancement avec seulement
+  des `extravars` est refusé, car ses valeurs ne peuvent pas être vérifiées.
+- **Pour voir d'abord ce qui serait refusé**, mettez `LAUNCH_VALIDATION=log` et lisez les avertissements dans le journal. `off` rétablit le
+  comportement de la 6.5.
+
+Voir [Validation au lancement](launch-validation/) pour les détails.
+
+
+### Les playbooks ne voient plus les paramètres de l'application
+
+Un playbook n'hérite plus des variables d'environnement qu'AnsibleForms lit lui-même : `ENCRYPTION_SECRET`, les paramètres `DB_*`,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, les paramètres `VAULT_*`, toutes les autres variables documentées et toutes les variables `MYSQL_*`.
+Le reste de l'environnement du RTE, comme `PATH`, les proxys, les paramètres `ANSIBLE_*` et les identifiants cloud, est transmis comme avant.
+
+Un playbook qui lisait l'une de ces variables avec `lookup('env', ...)` doit obtenir la valeur autrement : passez-la comme extravar ou comme
+identifiant, ou définissez-la sur le RTE sous un autre nom.
+
+### Seul le rôle admin gère les runners et les admins
+
+Un utilisateur qui a accès aux paramètres n'a plus le contrôle total sur qui est admin et sur la destination des identifiants :
+
+- **Runners :** seul le rôle admin ajoute, modifie ou supprime un runner, car un runner reçoit les identifiants des jobs
+  qu'il exécute. Les utilisateurs qui ont accès aux paramètres peuvent toujours voir et tester les runners.
+- **Comptes et groupes admin :** seul le rôle admin accorde le statut d'admin. Sans lui, un utilisateur ne peut pas mettre un compte dans un groupe que
+  le rôle admin nomme, ni modifier, réinitialiser ou supprimer un compte admin ou un tel groupe.
+- **Rôles :** un concepteur sans le rôle admin ne peut pas modifier les rôles. Un enregistrement ou une restauration dont les rôles diffèrent est refusé.
+
+Donnez le rôle admin à la personne qui gère les runners, les admins et les rôles.
+
+### Le mot de passe par défaut doit être changé
+
+Un utilisateur qui se connecte avec le mot de passe par défaut public `AnsibleForms!123` doit d'abord le changer. D'ici là, tous les autres appels
+d'API répondent `403` avec le code `password_change_required`, et le navigateur affiche la page de changement de mot de passe.
+
+Connectez-vous une fois et choisissez un nouveau mot de passe, ou définissez [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) avant le
+premier démarrage. Les scripts qui se connectent avec le mot de passe par défaut doivent en utiliser un autre.
+
+### Les jetons prennent fin à la déconnexion et au changement de mot de passe
+
+Une déconnexion met désormais fin aux jetons de cette session, et un changement de mot de passe met fin à toutes les sessions de cet utilisateur : reconnectez-vous donc après
+avoir changé un mot de passe.
+
+Un jeton d'API demandé avec `?expiryDays=` vit au plus [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) jours
+(90 par défaut). Les scripts qui utilisent des jetons d'API de longue durée doivent en demander un nouveau avant son expiration.
+
+### Entra ID a besoin de votre tenant
+
+La connexion Entra ID (Azure AD) utilise désormais OpenID Connect sur votre propre tenant uniquement, et un utilisateur d'un autre tenant ne peut pas se
+connecter. Un fournisseur sans tenant id, ou avec `common`, `organizations` ou `consumers`, est refusé.
+
+- **Définissez le tenant id** sur le fournisseur SSO : le Directory (tenant) ID, un GUID, ou le domaine du tenant.
+- **Accordez les permissions Graph :** la connexion demande `openid profile email User.Read GroupMember.Read.All`. Donnez à l'inscription
+  d'application les permissions déléguées Microsoft Graph `User.Read` et `GroupMember.Read.All`, avec le consentement administrateur.
+- **Préférez les id de groupe dans les rôles :** nommez un groupe `azuread/<object id>` (`entraid/<object id>` depuis la 7.3.0) plutôt que par son nom d'affichage.
+
+Voir [Entra ID](authentication/entra-id.html) pour la configuration.
+
+### Les mots de passe ont une longueur minimale
+
+Un mot de passe local défini via l'application doit compter au moins
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) caractères (8 par défaut), et ne peut pas être le nom d'utilisateur ni le
+mot de passe par défaut. `PASSWORD_MIN_LENGTH=0` désactive la vérification de longueur. Les mots de passe existants continuent de fonctionner.
+
+### Lancez les conteneurs avec une politique de redémarrage
+
+Une exception non interceptée termine désormais le processus, journalisée au niveau `crit`, au lieu de le laisser tourner dans un état inconnu. Lancez
+les conteneurs avec une politique de redémarrage, comme `--restart unless-stopped` avec Docker (le projet docker-compose la définit).
+Kubernetes redémarre les pods de lui-même.
+
+### Les connexions AWX et le lien d'accueil
+
+Deux autres choses disparaissent en 7, sans rien à faire en 6.5 :
+
+- **Connexions AWX et AAP :** la table `awx`, `/api/v2/awx` et la page A.A.P. ont disparu. La mise à niveau déplace chaque connexion AWX ou
+  AAP vers **Connexions → Runners**, comme runner de type `awx`, et les formulaires avec `awx:` continuent de fonctionner.
+- **`NAV_HOME_LABEL` et `NAV_HOME_ICON` :** ne sont plus lus. Le premier lien de l'en-tête est toujours Formulaires.
+
+### Obsolète en 7, supprimé en 8
+
+Ces éléments fonctionnent encore en 7, mais chacun écrit un avertissement dans le journal quand il est utilisé. Passez au remplacement avant la version 8 :
+
+| Obsolète | À utiliser à la place |
+|---|---|
+| Variables d'environnement `VAULT_*` | Un coffre de secrets nommé `vault` (**Connexions → Coffres de secrets**). Le premier démarrage en 7 importe les variables une fois comme ce coffre, puis les ignore. |
+| Variables d'environnement `LOG_SYSLOG_*` | Un serveur syslog (**Connexions → Syslog**). Quand `LOG_SYSLOG_HOST` est défini, le premier démarrage en 7 les importe une fois comme le serveur `syslog`, qui reçoit le journal du serveur comme avant, puis les ignore. Pour envoyer aussi les entrées d'audit, configurez-le pour recevoir les deux. |
+| `vault_path` sur un identifiant (API, seed de configuration) | `secret_store` et `secret_ref`. Voir [Coffres de secrets](secret-stores/). |
+| Le rôle `public` dans `config.yaml` | Le rôle `default`. Le fichier est renommé au chargement de la configuration ; renommez un modèle ytt à la main. `public` dans les `roles:` d'un formulaire continue de correspondre. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` sur un formulaire ou une étape | `approval`. `hasApproval` n'a aucun effet. |
+| `awx: <name>` sur un formulaire | `runner: <name>`. Une connexion AWX est un runner de type `awx`. |
+| `type: multistep` sur un formulaire, avec ses `steps` | `type: workflow`, avec des nœuds qui nomment un `runner`. Voir [Formulaires workflow](forms/workflow.html). |
+| La section `awx:` du seed de configuration | Des éléments `runners:` avec `type: awx` |
+| `LOCK_PATH` | Rien : n'est plus lu, le verrou du concepteur est conservé dans la base de données. |
+| Un RTE en mode base de données, depuis la 7.3.0 : `RTE_MODE=database` ou pas de `RTE_MODE`, avec les `DB_*` de la base de données et `ENCRYPTION_SECRET` sur le RTE | `RTE_MODE=outbound` ou `RTE_MODE=inbound`, sans `DB_*`. Le RTE rejoint une fois avec un jeton d'adhésion (`RTE_JOIN_TOKEN`), ou son runner est passé dans ce mode sous **Connexions → Runners** ou dans le seed de configuration (`rte_mode`). Voir [Modes](rte/modes.html). |
+| `RTE_REGISTER`, depuis la 7.3.0 (mode base de données uniquement) | Un jeton d'adhésion (`RTE_JOIN_TOKEN`) : le RTE s'ajoute lui-même comme runner qui s'authentifie avec un identifiant RTE. |
+| Un identifiant `api` ou `userpass` sur un runner du seed de configuration, depuis la 7.3.0 | Un identifiant du type du runner (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` ou `jenkins`), avec son serveur dans `url`. |
+| Un runner du seed de configuration avec son propre `token`, ou `username` et `password`, depuis la 7.3.0 | Un identifiant du type du runner dans la section `credentials`, avec son serveur dans `url`, que le runner nomme avec `credential:`. En attendant, le seed en crée un nommé d'après le runner. |
+
+`ENABLE_SSO` et `SSO_AUTO_LOGIN` ne sont plus lus depuis la 7.3.0. Le premier démarrage en 7.3 les reprend une fois : `ENABLE_SSO=0` désactive
+tous les fournisseurs SSO, et `SSO_AUTO_LOGIN=1` coche **Passer la page de connexion** sur le seul fournisseur activé. Ils sont ensuite ignorés : chaque démarrage
+écrit un avertissement tant qu'ils sont définis, et chaque fournisseur a **Activé** et **Passer la page de connexion** sous **Accès → SSO**.
+
+---
+
+## Tags d'image
+
+`latest` passe à la 7 avec la 7.0.0. Pour rester en 6, utilisez le tag `6` (ou `6.5`) au lieu de `latest`.
+Tous les tags sont listés sous [Tags d'image](installation/#image-tags).
+
+---
+
+## Revenir en arrière
+
+Faites une sauvegarde avant la mise à niveau (**Paramètres → Sauvegardes**). La 6.5 tourne sur une base de données mise à niveau en 7, mais seule
+la sauvegarde restaure les définitions de sources de données supprimées.
diff --git a/i18n/fr/_get_started/upgrading/docker-compose.md b/i18n/fr/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..0935dc5
--- /dev/null
+++ b/i18n/fr/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Mise à niveau
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Mettre à niveau une installation faite avec le projet docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le projet docker-compose fait tourner trois conteneurs : MySQL (`mysqldb`), AnsibleForms (`app`) et le RTE qui exécute les
+playbooks (`rte`). AnsibleForms et le RTE utilisent le tag d'image `7`, qui pointe toujours vers la version 7.x la plus récente. Une
+mise à niveau récupère à nouveau les images et recrée les conteneurs dont l'image a changé. Tout ce qui doit persister est stocké
+dans le dossier `data` et est conservé.
+
+---
+
+## Avant la mise à niveau
+
+Préparez la mise à niveau pour pouvoir revenir en arrière si quelque chose se passe mal :
+
+* **Faites une sauvegarde** sous **Paramètres → Sauvegardes**. La nouvelle version met à niveau le schéma de la base de données à son premier démarrage.
+* **Lisez le [changelog](../changelog)** des versions entre la vôtre et la nouvelle.
+* **Vous passez à une nouvelle version majeure ?** Suivez d'abord [Passer à la v7](../upgrade-7.html).
+* **Vous venez de la 6.5 ?** Le projet 6.x, sur sa branche `v6`, n'a pas de conteneur `rte`. Mettez votre copie du projet à jour sur
+  sa branche `main`, en gardant vos paramètres `.env` et votre dossier `data`, pour que `docker-compose.yml` contienne le service `rte`.
+  Ce fichier compose définit `CONFIG_SEED_PATH`, et un dossier `data` de la 6.x n'a pas de `seed.yaml` : copiez `data/seed.yaml` depuis
+  le dépôt, et ajoutez `RTE_TOKEN` (au moins 16 caractères) à votre `.env`, comme dans le `.env` du dépôt. Sans eux,
+  l'application refuse de démarrer. Les images 7 tournent sous l'uid 1000 au lieu de root : donnez une fois le dossier `data` à cet utilisateur, en laissant les fichiers
+  MySQL à MySQL, avec `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  Le dossier `data/ssh` est désormais monté sur `/home/node/.ssh` au lieu de `/root/.ssh`.
+* **Vous venez de la 7.2 ?** Mettez à jour `docker-compose.yml` et `data/seed.yaml` ensemble : voir d'abord [De la 7.2 à la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 à la 7.3
+
+Jusqu'à la 7.2.0, le service `rte` recevait les paramètres de la base de données et son runner, déclaré dans `data/seed.yaml`, tournait en mode base de données,
+obsolète en 7.3.0 et supprimé en 8.0.0. Depuis la 7.3.0, l'application appelle le RTE sur `http://rte:8000` et garde un WebSocket ouvert
+(`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)), et le RTE ne détient aucun paramètre de base de données. Prenez les deux fichiers sur la branche
+`main` du dépôt, en gardant votre `.env` :
+
+| Fichier | Ce qui change |
+|---|---|
+| `docker-compose.yml` | Le service `rte` ne lit plus `.env` : il reçoit `RTE_MODE=inbound`, `RTE_TOKEN` et `RTE_FILES=local`, et aucun `DB_*` |
+| `data/seed.yaml` | Un identifiant RTE `rte`, avec `url: http://rte:8000` et `password: ${RTE_TOKEN}`, et le runner `rte` avec `rte_mode: inbound` et `credential: rte` |
+
+Changez les deux. Avec seulement le nouveau fichier compose, le seed garde le runner `rte` en mode base de données : l'application appelle le RTE comme un RTE 7.2,
+ce à quoi le nouveau RTE ne répond pas, et aucun playbook ne s'exécute. Un seed que vous avez modifié vous-même a besoin du même identifiant et du même `rte_mode`.
+
+Un runner que le seed a créé reste géré, en lecture seule sous **Connexions → Runners**, même après la suppression de `CONFIG_SEED_PATH` : seul un
+seed appliqué libère un runner qu'il ne déclare plus. Gardez donc le seed et définissez-y `rte_mode`, plutôt que de supprimer
+`CONFIG_SEED_PATH` pour modifier le runner à la main.
+
+L'[installateur](../installation/installer.html#upgrade) le fait tout seul : sa mise à niveau remplace `docker-compose.yml`, et `data/seed.yaml`
+quand c'est celui livré par le dépôt, non modifié. Un seed modifié à la main est conservé, et le nouveau est enregistré à côté.
+
+---
+
+## 1. Récupérer les nouvelles images
+
+Téléchargez les images les plus récentes des tags de `docker-compose.yml` :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Recréer les conteneurs
+
+Redémarrez le projet ; les conteneurs dont l'image a changé sont recréés :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Vérifier la mise à niveau
+
+Suivez le journal d'AnsibleForms pendant son démarrage. Le premier démarrage d'une nouvelle version met à niveau le schéma de la base de données, et le RTE
+démarre dès qu'AnsibleForms est en bonne santé :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+Dans AnsibleForms, **Aide → À propos** affiche la version en cours d'exécution, et **Paramètres → Statut** affiche l'état de santé de la
+base de données, du schéma et des autres systèmes dont AnsibleForms dépend.
+
+---
+
+## Revenir en arrière
+
+Pour revenir à la version que vous utilisiez avant, celle qu'affichait **Aide → À propos** avant la mise à niveau, fixez son tag exact dans
+`docker-compose.yml` pour l'image AnsibleForms comme pour l'image RTE, à la place de `7`, et relancez l'étape 2. Si cette version
+ne démarre pas sur la base de données mise à niveau, restaurez la sauvegarde faite sous **Paramètres → Sauvegardes**. Remettez les tags à
+`7` pour recevoir à nouveau les mises à jour.
+
+**VIDÉO** : [Comment mettre à niveau AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/fr/_get_started/upgrading/docker.md b/i18n/fr/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..9082c3b
--- /dev/null
+++ b/i18n/fr/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Mise à niveau
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Mettre à niveau un conteneur autonome, sans docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Une installation autonome se met à niveau en remplaçant ses conteneurs : récupérez les nouvelles images, supprimez les anciens conteneurs et
+démarrez-en de nouveaux avec les mêmes commandes `run`. Depuis la version 7, il y en a deux : AnsibleForms et le RTE qui exécute les
+playbooks, toujours sur la même version. Vos fichiers sont stockés dans le dossier monté `/app/dist/persistent` et vos données dans
+MySQL, les deux sont donc conservés.
+
+---
+
+## Avant la mise à niveau
+
+Préparez la mise à niveau pour pouvoir revenir en arrière si quelque chose se passe mal :
+
+* **Faites une sauvegarde** sous **Paramètres → Sauvegardes**. La nouvelle version met à niveau le schéma de la base de données à son premier démarrage.
+* **Lisez le [changelog](../changelog)** des versions entre la vôtre et la nouvelle.
+* **Vous passez à une nouvelle version majeure ?** Suivez d'abord [Passer à la v7](../upgrade-7.html).
+* **Vous venez de la 6.5 ?** Les images 7 tournent sous l'uid 1000 au lieu de root : donnez une fois à cet utilisateur les dossiers que vous montez, par
+  exemple `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Vous venez de la 7.2 ?** Le RTE reçoit son propre fichier et l'application l'appelle : voir d'abord [De la 7.2 à la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 à la 7.3
+
+Jusqu'à la 7.2.0, le RTE lisait le fichier d'environnement de l'application, avec les paramètres de la base de données, et s'ajoutait lui-même comme runner à partir de `RTE_URL`. C'est
+le mode base de données, obsolète en 7.3.0 et supprimé en 8.0.0. Depuis la 7.3.0, l'application appelle le RTE et garde un WebSocket ouvert
+(`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)), et le RTE ne détient aucun paramètre de base de données. Une seule fois, avant l'étape 2 :
+
+1. Créez `/srv/apps/ansibleforms/rte.env` comme le fait l'[installation](../installation/docker.html#prepare-the-folders), avec
+   `RTE_MODE=inbound`, le même `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` et `HTTPS=0`. Pas de `DB_*`, pas d'`ENCRYPTION_SECRET`, pas de `RTE_URL`
+2. Déclarez le runner dans ce mode. Soit vous ajoutez le [seed de configuration](../seed/) de l'installation, `persistent/seed.yaml` avec l'identifiant RTE
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) et le runner `rte` (`rte_mode: inbound`), et vous ajoutez
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` au fichier d'environnement de l'application. Soit, sans seed, vous ouvrez le runner sous
+   **Connexions → Runners**, mettez son **Mode** à **Entrant**, et choisissez un identifiant RTE qui contient `http://rte:8000` et le jeton
+
+Avec le seed, le fichier d'environnement de l'application contient aussi `RTE_TOKEN`, le même jeton, puisque le seed le lit à cet endroit.
+
+---
+
+## 1. Récupérer les nouvelles images
+
+Téléchargez les images AnsibleForms et RTE les plus récentes du tag que vous utilisez :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Remplacer les conteneurs
+
+Supprimez les anciens conteneurs et démarrez-en de nouveaux avec les commandes `run` de l'[installation](../installation/docker.html). L'application
+lit la connexion à la base de données dans son fichier d'environnement, avec l'utilisateur de base de données d'AnsibleForms (pas root). Le RTE lit son propre
+`rte.env`, sans les paramètres de la base de données, et l'application l'appelle sur un réseau que les deux conteneurs partagent :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Si vous venez de la 6.5, il n'y a pas encore de conteneur RTE : les commandes `stop` et `rm` ne trouvent que l'application. Créez le réseau partagé
+une fois avec `docker network create ansibleforms` (ou `podman network create ansibleforms`). Comme le fait
+l'[installation](../installation/docker.html#prepare-the-folders), mettez la connexion à la base de données, `ENCRYPTION_SECRET`, un `RTE_TOKEN`
+d'au moins 16 caractères et `CONFIG_SEED_PATH` dans le fichier d'environnement de l'application, et créez `rte.env` et le seed de configuration. Utilisez vos propres
+dossiers là où votre installation 6.5 en montait d'autres. Le seed ajoute le RTE sous **Connexions → Runners** comme runner par défaut `rte` ;
+voir [Passer à la v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Vérifier la mise à niveau
+
+Suivez le journal d'AnsibleForms pendant son démarrage. Le premier démarrage d'une nouvelle version met à niveau le schéma de la base de données :
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+Le RTE écrit son propre journal, que `docker logs rte` affiche. Dans AnsibleForms, **Aide → À propos** affiche la version en cours d'exécution, et **Paramètres → Statut** affiche l'état de santé de la
+base de données, du schéma et des autres systèmes dont AnsibleForms dépend.
+
+---
+
+## Revenir en arrière
+
+Pour revenir à la version que vous utilisiez avant, celle qu'affichait **Aide → À propos** avant la mise à niveau, relancez l'étape 2 avec
+son tag exact à la place de `7`, pour l'image AnsibleForms comme pour l'image RTE. Si cette version ne démarre pas sur la base de données
+mise à niveau, restaurez la sauvegarde faite sous **Paramètres → Sauvegardes**.
diff --git a/i18n/fr/_get_started/upgrading/from-source.md b/i18n/fr/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..2984e84
--- /dev/null
+++ b/i18n/fr/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Depuis les sources
+parent: Mise à niveau
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Depuis les sources
+{: .no_toc }
+
+Mettre à niveau une installation construite depuis les sources
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Une installation construite depuis les sources se met à niveau en récupérant la nouvelle version, en la reconstruisant et en redémarrant
+l'application. Vos paramètres, formulaires, playbooks, certificats et journaux sont stockés dans `server/persistent`, que Git et la
+construction ne modifient pas.
+
+---
+
+## Avant la mise à niveau
+
+Préparez la mise à niveau pour pouvoir revenir en arrière si quelque chose se passe mal :
+
+* **Faites une sauvegarde** sous **Paramètres → Sauvegardes**. La nouvelle version met à niveau le schéma de la base de données à son premier démarrage.
+* **Lisez le [changelog](../changelog)** des versions entre la vôtre et la nouvelle.
+* **Vous passez à une nouvelle version majeure ?** Suivez d'abord [Passer à la v7](../upgrade-7.html).
+* **Vérifiez la version de Node.js** que demande la nouvelle version, dans le changelog.
+
+---
+
+## 1. Récupérer la nouvelle version
+
+Récupérez les tags de version et passez sur la version souhaitée. Les tags de version portent le numéro de version, et `git tag` les
+liste ; la branche `main` peut contenir des changements qui ne sont pas encore publiés :
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Reconstruire
+
+Reconstruisez avec les trois mêmes étapes qu'à l'installation. Reconstruisez d'abord le client :
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Mettez ensuite à jour les dépendances du serveur :
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Enfin, copiez à nouveau le client reconstruit dans le dossier `views` du serveur :
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Comparez `.env.example`, à la racine du dépôt, avec votre `persistent/.env` pour reprendre les paramètres que la version ajoute.
+
+---
+
+## 3. Redémarrer
+
+Redémarrez l'application et son RTE pour charger le nouveau code. Le schéma de la base de données est mis à niveau au premier démarrage :
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Si vous venez de la 7.2, le RTE tournait en mode base de données, avec les paramètres de base de données et `RTE_URL`, obsolète en 7.3.0 et supprimé en 8.0.0.
+Redémarrez-le en mode entrant, et déclarez son runner avec un identifiant RTE dans le seed ou sous **Connexions → Runners**, comme le montre
+l'[installation](../installation/from-source.html#run) : `pm2 delete ansibleforms-rte`, puis sa commande `pm2 start`.
+
+Si vous faites tourner l'application sans PM2, arrêtez `npm run start` et relancez-le.
+
+---
+
+## 4. Vérifier la mise à niveau
+
+Suivez le journal de l'application pendant son démarrage :
+
+```bash
+pm2 logs ansibleforms
+```
+
+Dans AnsibleForms, **Aide → À propos** affiche la version en cours d'exécution, et **Paramètres → Statut** affiche l'état de santé de la
+base de données, du schéma et des autres systèmes dont AnsibleForms dépend.
+
+---
+
+## Revenir en arrière
+
+Pour revenir à la version que vous utilisiez avant, celle qu'affichait **Aide → À propos** avant la mise à niveau, passez sur son tag avec
+`git checkout <version>`, puis reconstruisez et redémarrez comme aux étapes 2 et 3. Si cette version ne démarre pas sur la base de données mise à niveau, restaurez la sauvegarde faite sous
+**Paramètres → Sauvegardes**.
diff --git a/i18n/fr/_get_started/upgrading/index.md b/i18n/fr/_get_started/upgrading/index.md
new file mode 100644
index 0000000..44f07be
--- /dev/null
+++ b/i18n/fr/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Mise à niveau
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Mise à niveau
+{: .no_toc }
+
+Passer AnsibleForms à une version plus récente
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les administrateurs d'une instance en service : passer à une version plus récente, avec la méthode utilisée pour l'installer.
+
+---
+
+## Dans cette section
+
+La procédure de mise à niveau dépend de la façon dont vous avez installé AnsibleForms. Chaque méthode est décrite sur sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Passer à la v7](../upgrade-7.html) | Ce qu'il faut changer encore en 6.5, avant de passer à la 7 |
+| [Avec l'installateur](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, pour une installation faite par l'installateur : sauvegarde, notes de version et retour arrière |
+| [Docker](docker.html) | Récupérer la nouvelle image et recréer le conteneur avec les mêmes paramètres |
+| [Docker Compose](docker-compose.html) | Récupérer la nouvelle image et redémarrer le projet docker-compose |
+| [Depuis les sources](from-source.html) | Récupérer le nouveau code, le reconstruire et redémarrer l'application |
+| [Kubernetes](kubernetes.html) | Rafraîchir le dépôt du chart et lancer `helm upgrade` avec vos valeurs |
+
+{: .note }
+> **Sauvegardez d'abord** Faites une sauvegarde avant la mise à niveau (**Paramètres → Sauvegardes**). Le schéma de la base de données est mis à niveau au premier
+> démarrage de la nouvelle version, la sauvegarde est donc votre point de retour si quelque chose se passe mal. Depuis la 7.3.0, le worker en fait
+> aussi une lui-même avant de mettre à niveau depuis une version plus ancienne, nommée d'après la version, sauf si
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) vaut `0`.
+
+La version que vous recevez dépend du tag d'image que vous utilisez : `latest` suit la version majeure la plus récente, tandis qu'un tag comme `7`
+reste sur cette version majeure. Tous les tags sont listés sous [Tags d'image](../installation/#image-tags).
diff --git a/i18n/fr/_get_started/upgrading/kubernetes.md b/i18n/fr/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..df287c5
--- /dev/null
+++ b/i18n/fr/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Mise à niveau
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Mettre à niveau une installation faite avec le chart Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Chaque version du chart déploie une version d'AnsibleForms. Une mise à niveau installe une version plus récente du chart avec vos valeurs existantes ;
+les données des volumes persistants sont conservées. Une mise à niveau qui ne change rien laisse les pods intacts.
+
+---
+
+## Avant la mise à niveau
+
+Préparez la mise à niveau pour pouvoir revenir en arrière si quelque chose se passe mal :
+
+* **Faites une sauvegarde** sous **Paramètres → Sauvegardes**. La nouvelle version met à niveau le schéma de la base de données à son premier démarrage.
+* **Lisez le [changelog](../changelog)** des versions entre la vôtre et la nouvelle.
+* **Vous passez à une nouvelle version majeure ?** Suivez d'abord [Passer à la v7](../upgrade-7.html).
+* **Lisez le [changelog](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) du chart** pour les changements des valeurs.
+* **Avec des identifiants générés** (`secrets.generate`), sauvegardez le Secret `<release>-secrets` : `ENCRYPTION_SECRET` ne peut pas être récupéré.
+* **Vous venez de la 7.2 ?** Le RTE du pod serveur change de mode : voir [De la 7.2 à la 7.3](#from-72-to-73).
+
+---
+
+## De la 7.2 à la 7.3
+
+Le chart 7.3.0 sort le RTE placé à côté de l'application du mode base de données, obsolète en 7.3.0 et supprimé en 8.0.0. L'application l'appelle sur
+`127.0.0.1` et garde un WebSocket ouvert (`RTE_MODE=inbound`, voir [Modes](../rte/modes.html)) :
+
+* Le conteneur RTE ne reçoit plus `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` ni `RTE_URL`, et prend les fichiers du job sur
+  le volume partagé (`RTE_FILES=local`)
+* Le seed de configuration du chart déclare un identifiant RTE avec le jeton et l'adresse, et le runner, `rte_mode: inbound`, qui s'authentifie
+  avec. Avec le seed du chart, il n'y a rien à faire
+* Avec `containers.rte.seedRunner: false`, ou un seed de configuration à vous (`CONFIG_SEED_PATH`), le RTE ne s'ajoute plus lui-même comme runner.
+  Déclarez-le vous-même, dans votre seed ou sous **Connexions → Runners** : un identifiant RTE avec `http://127.0.0.1:<port>` et le jeton,
+  et un runner de type RTE avec `rte_mode: inbound` qui le nomme. Les notes que Helm affiche après la mise à niveau montrent comment faire
+
+Depuis la 7.3.0, le chart installe aussi un Runner à part, avec `runner.enabled` (voir
+[Un Runner sur Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Trouver la nouvelle version du chart
+
+Rafraîchissez le dépôt du chart et listez les versions disponibles :
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Mettre à niveau la release
+
+Lancez la même commande `helm upgrade` qu'à l'installation, avec votre fichier de valeurs et la nouvelle version du chart :
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Avec le registre OCI, utilisez `oci://ghcr.io/ansibleforms/charts/ansibleforms` comme chart.
+
+---
+
+## 3. Vérifier la mise à niveau
+
+Attendez les nouveaux pods, puis lancez le test du chart, qui vérifie à la fois le serveur web et la connexion à la base de données :
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+Dans AnsibleForms, **Aide → À propos** affiche la version en cours d'exécution, et **Paramètres → Statut** affiche l'état de santé de la
+base de données, du schéma et des autres systèmes dont AnsibleForms dépend.
+
+---
+
+## Revenir en arrière
+
+Helm conserve l'historique de la release. Pour revenir à la révision précédente :
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Si elle ne démarre pas sur la base de données mise à niveau, restaurez votre sauvegarde (voir le [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) du chart).
diff --git a/i18n/fr/_integrate/api/authentication.md b/i18n/fr/_integrate/api/authentication.md
new file mode 100644
index 0000000..cd6398e
--- /dev/null
+++ b/i18n/fr/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Authentification
+parent: API REST
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Authentification
+{: .no_toc }
+
+Se connecter, rafraîchir le jeton, ou utiliser un jeton de longue durée
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Chaque appel a besoin d'un jeton d'accès dans l'en-tête `Authorization`. On obtient un jeton en se connectant, et on le garde valide avec
+le jeton de rafraîchissement.
+
+---
+
+## Se connecter
+
+Connectez-vous en authentification basique, avec le nom et le mot de passe de l'utilisateur :
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+La réponse contient deux jetons, le jeton d'accès et le jeton de rafraîchissement :
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Appeler l'API
+
+Envoyez le jeton d'accès comme jeton bearer à chaque appel :
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Rafraîchir le jeton
+
+Le jeton d'accès expire (`ACCESS_TOKEN_EXPIRATION`, 30 minutes par défaut). Obtenez-en un nouveau avec le jeton de rafraîchissement,
+sans le mot de passe :
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+La réponse contient une nouvelle paire, sous la même forme que la connexion. Un jeton de rafraîchissement ne sert qu'une fois : gardez le nouveau pour le prochain rafraîchissement.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Jetons de longue durée
+
+Un script qui tourne sans surveillance peut utiliser un jeton qui dure plus longtemps. Depuis la 7.3.0, il faut l'option de rôle `allowApiTokens` :
+
+* Créez-en un sous [Profil > Jetons d'API](../profile/api-token.html).
+* Ou connectez-vous avec le paramètre de requête `expiryDays`, pour un jeton valable ce nombre de jours :
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` n'est lu que dans l'URL, jamais dans le corps. Pour un utilisateur dont les rôles n'ont pas `allowApiTokens`, il est ignoré,
+et la connexion renvoie un jeton de durée habituelle. `expiryDays=never` nécessite aussi `extendedTokenExpiration`. Ajoutez le paramètre de requête `name`
+(`?expiryDays=90&name=nightly-backup`) pour nommer le jeton dans la liste des jetons de l'utilisateur.
+
+Un jeton de longue durée vit au plus [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) jours, 90 par
+défaut : un `expiryDays` plus long est ramené à cette valeur, sauf s'il vaut `never`. Le rafraîchir renvoie un jeton ordinaire, reconnectez-vous donc quand il expire.
+
+### Jetons de l'utilisateur connecté
+
+La vue **Jetons d'API** du profil utilise ces endpoints, qui fonctionnent pour tout compte, SSO compris, puisqu'ils n'ont besoin d'aucun mot de passe :
+
+| Appel | Ce qu'il fait |
+|---|---|
+| `GET /api/v2/profile/tokens` | Liste vos jetons d'API, avec leur `sid`, leur `name`, leur création, leur expiration et leur dernière utilisation |
+| `POST /api/v2/profile/tokens` | Crée un jeton à partir de votre session ; le corps contient `expiryDays` (un nombre, ou `never`) et un `name` facultatif |
+| `DELETE /api/v2/profile/tokens/{sid}` | Révoque l'un de vos jetons |
+
+`POST` répond `403` quand il est appelé avec un jeton d'API (un jeton ne peut pas en créer un autre), sans `allowApiTokens`, ou quand la
+session s'est connectée il y a plus de 10 minutes (code `sign_in_again`) : reconnectez-vous d'abord. Une durée de vie au-delà du maximum répond `400`.
+
+---
+
+## Quand un jeton prend fin plus tôt
+
+Un jeton, de longue durée ou non, cesse de fonctionner avant son expiration quand l'une de ces situations se produit :
+
+* **Une déconnexion de sa session** : `POST /api/v2/auth/logout` avec le jeton met fin aux jetons de cette connexion, et à eux seuls. Une
+  déconnexion dans le navigateur ne met pas fin au jeton d'un script.
+* **Un changement de mot de passe** : l'utilisateur change son mot de passe, ou un admin le définit. Tout jeton émis auparavant est refusé.
+* **L'utilisateur est supprimé ou bloqué** : supprimer un utilisateur local, ou bloquer un utilisateur, met fin à tous ses jetons. Un admin peut aussi
+  mettre fin aux sessions d'un utilisateur LDAP ou SSO.
+
+Un jeton refusé répond `401`. Reconnectez-vous, avec le nouveau mot de passe s'il a changé.
+
+---
+
+## Scripts qui se connectent à chaque exécution
+
+Les endpoints de connexion et de jeton sont protégés contre les afflux de requêtes et la devinette de mots de passe, un script qui se connecte à chaque exécution
+doit donc connaître ces limites :
+
+| Limite | Par défaut | Ce qui se passe |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 requêtes par minute depuis une même adresse | La connexion, la déconnexion, le rafraîchissement, les endpoints SSO, `PUT /api/v2/profile` (changement de mot de passe) et `POST` ou `DELETE /api/v2/profile/tokens` répondent `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 échecs de connexion d'affilée | Le compte est verrouillé pendant [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), chaque connexion répond `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 échecs de connexion depuis une même adresse | Chaque connexion depuis cette adresse répond `429` jusqu'à la fin de la fenêtre |
+
+Un `429` porte un en-tête `Retry-After` avec le nombre de secondes à attendre : arrêtez-vous et attendez, ne réessayez pas tout de suite. Un compte verrouillé
+refuse même le bon mot de passe jusqu'à la fin du verrouillage, un script avec un mauvais mot de passe verrouille donc son utilisateur pour tout le monde.
+Un mauvais mot de passe actuel lors d'un changement de mot de passe (`PUT /api/v2/profile`) compte aussi comme un échec de connexion, et un compte verrouillé
+ne peut pas changer son mot de passe. Une connexion réussie remet à zéro le compteur du compte, tout comme un admin qui définit le mot de passe.
+
+Pour rester à l'écart de ces limites, connectez-vous une fois et réutilisez le jeton, ou utilisez un jeton de longue durée, au lieu de vous connecter à
+chaque appel. Derrière un reverse proxy, définissez [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) pour que le serveur voie
+l'adresse du client, sinon tous les clients comptent comme un seul.
diff --git a/i18n/fr/_integrate/api/events.md b/i18n/fr/_integrate/api/events.md
new file mode 100644
index 0000000..360b15c
--- /dev/null
+++ b/i18n/fr/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Événements en direct
+parent: API REST
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Événements en direct
+{: .no_toc }
+
+Être prévenu quand les jobs et les paramètres changent, au lieu d'interroger en boucle
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le serveur indique à ses clients ce qui change, au moment où cela change. Un script peut écouter aussi, plutôt que de relire un job toutes les quelques secondes.
+
+---
+
+## Le flux
+
+`GET /api/v2/events` est un flux de [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+qui reste ouvert. Tout utilisateur connecté peut l'ouvrir, avec le jeton bearer habituel :
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Quand quelque chose change, il envoie un événement `changed` avec le nom de ce qui a changé :
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Noms d'événements
+
+Un événement ne porte qu'un nom, jamais de données, il ne révèle donc rien que l'utilisateur n'ait pas le droit de voir. Ces noms sont envoyés :
+
+| Nom | Ce qui a changé |
+|---|---|
+| `jobs` | Un job : lancé, son statut ou sa sortie, supprimé |
+| `appearance` | Les paramètres qu'affiche l'en-tête : le thème, le nom, une annonce, une variable d'environnement |
+| `designer` | Un verrou du concepteur, pris ou libéré |
+| `runners` | Un runner (depuis la 7.3.0) : un RTE connecté ou déconnecté, qui a demandé à rejoindre, a été approuvé ou rejeté, ou a changé de mode ou de paramètres |
+
+En recevant un nom, relisez ce que vous affichez via l'API normale (par exemple `GET /api/v2/job/42`), avec vos propres
+permissions. Un nom très actif est envoyé au plus une fois par seconde.
+
+---
+
+## Le garder ouvert
+
+Le flux est conçu pour survivre aux proxys et aux répartiteurs de charge, et un client se reconnecte de lui-même :
+
+* À la connexion, le serveur envoie un événement `hello`, et demande au client d'attendre 3 secondes avant de se reconnecter.
+* Toutes les 15 secondes, il envoie une ligne de commentaire (`: ping`), pour qu'une connexion inactive ne soit pas fermée. Ignorez les lignes qui commencent par `:`.
+* Les événements de chaque nœud d'application atteignent chaque flux, quel que soit le nœud auquel le client est connecté.
+* Après une reconnexion, relisez ce que vous affichez : un événement envoyé pendant que le flux était coupé n'est pas renvoyé.
+
+---
+
+## Santé et métriques
+
+Les sondes de liveness et de readiness (`/api/v2/live`, `/api/v2/ready`) et les métriques Prometheus (`/api/v2/metrics`) sont
+destinées aux outils de supervision plutôt qu'aux scripts qui agissent en tant qu'utilisateur. Voir [Supervision](../production/monitoring.html).
diff --git a/i18n/fr/_integrate/api/index.md b/i18n/fr/_integrate/api/index.md
new file mode 100644
index 0000000..af502e9
--- /dev/null
+++ b/i18n/fr/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: API REST
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# API REST
+{: .no_toc }
+
+Lancer des formulaires et gérer AnsibleForms depuis des scripts
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les développeurs et les ingénieurs en automatisation : lancer des formulaires et gérer AnsibleForms depuis des scripts.
+
+Tout ce que fait l'interface web passe par l'API REST, les scripts et les autres outils peuvent donc faire de même.
+
+---
+
+## Vue d'ensemble
+
+L'API est servie sous `/api/v2` sur le serveur AnsibleForms :
+
+* **Référence complète** : ces pages couvrent ce que les scripts utilisent le plus. Chaque endpoint est décrit, et peut être essayé, sur la
+  page Swagger intégrée du serveur, `https://<your server>/api/v2/docs`.
+* **Permissions** : un appel s'exécute sous l'utilisateur dont il porte le jeton, avec les rôles de cet utilisateur, comme dans le navigateur.
+* **Validation au lancement** : les jobs lancés via l'API peuvent être vérifiés comme les lancements depuis le navigateur
+  (voir [Validation au lancement](../launch-validation/)).
+* **Limites de débit** : seuls les endpoints de connexion, de déconnexion, de rafraîchissement du jeton et d'authentification unique, le changement de mot de passe
+  (`PUT /api/v2/profile`) et les endpoints des jetons d'API (`POST` et `DELETE /api/v2/profile/tokens`) sont limités (voir
+  [Authentification](authentication.html)). Les autres appels n'ont pas de limite de débit (l'[assistant de chat](../chat/) a ses propres
+  limites), un script doit donc modérer son rythme lui-même, par exemple quand il suit un job.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Authentification](authentication.html) | Se connecter, rafraîchir le jeton, ou utiliser un jeton de longue durée |
+| [Jobs](jobs.html) | Lancer un formulaire, suivre le job, l'interrompre, le relancer ou l'approuver |
+| [Réponses et erreurs](responses.html) | La forme d'une réponse, et les codes de statut |
+| [Événements en direct](events.html) | Être prévenu quand les jobs et les paramètres changent, au lieu d'interroger en boucle |
diff --git a/i18n/fr/_integrate/api/jobs.md b/i18n/fr/_integrate/api/jobs.md
new file mode 100644
index 0000000..018d802
--- /dev/null
+++ b/i18n/fr/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Jobs
+parent: API REST
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Jobs
+{: .no_toc }
+
+Lancer un formulaire, suivre le job, l'interrompre, le relancer ou l'approuver
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un job est une exécution d'un formulaire. Lancez-le avec le nom et les valeurs du formulaire, puis suivez-le par son ID.
+
+---
+
+## Lancer un formulaire
+
+Envoyez le nom du formulaire et ses valeurs à `POST /api/v2/job` :
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+La requête accepte ces propriétés :
+
+| Propriété | Signification |
+|---|---|
+| `formName` | Le nom du formulaire à lancer. Obligatoire. |
+| `extravars` | Les variables supplémentaires du job. `payload` est accepté comme autre nom. |
+| `rawFormData` | Les valeurs des champs du formulaire, telles que le navigateur les détient. La [validation au lancement](../launch-validation/) les vérifie, et construit les extravars à partir d'elles. |
+| `credentials` | Les identifiants à transmettre au job, par nom. |
+| `files` | Les fichiers téléversés des champs fichier du formulaire (voir [Téléversement de fichiers](../launch-validation/file-uploads.html)). |
+
+La réponse contient l'ID du nouveau job :
+
+```json
+{ "id": 42 }
+```
+
+Pour exécuter le job en mode verbeux, ajoutez `"__verbose__": true` aux extravars. Il faut l'option de rôle `allowVerboseMode`,
+sinon le lancement répond `403`.
+
+---
+
+## Téléverser un fichier
+
+Un formulaire avec un champ fichier a besoin que le fichier soit d'abord téléversé. Envoyez-le comme partie multipart `file` à `POST /api/v2/job/upload` :
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+La réponse décrit le fichier stocké :
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Transmettez-la telle quelle dans les `files` du lancement, sous le nom du champ fichier : `"files": { "firmware": { ... } }`. Le serveur
+la vérifie par rapport à son propre disque (voir [Téléversement de fichiers](../launch-validation/file-uploads.html)).
+
+---
+
+## Suivre le job
+
+Lisez le job par son ID :
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+Le job contient son `status`, ses `extravars` (aussi sous `payload`, le même objet), ses `subjobs` et son `output`. La
+sortie est du HTML avec les couleurs de la page du job ; ajoutez `?text=true` pour du texte brut, qui convient à un script ou à un journal :
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+Son `status` vaut `running` pendant son exécution, et `approve` pendant qu'il attend une approbation. Un job se termine avec l'un de ces statuts :
+
+| Statut | Signification |
+|---|---|
+| `success` | Le job s'est terminé sans erreur |
+| `failed` | Le job a échoué |
+| `warning` | Un job multi-étapes s'est terminé, mais une étape qui a `continue` défini a échoué en cours de route |
+| `aborted` | Le job a été interrompu |
+| `rejected` | L'approbation a été refusée, ce qui l'attendait ne s'est donc pas exécuté |
+| `abandoned` | Le processus qui suivait le job s'est arrêté (un redémarrage, un conteneur remplacé) et le job a été abandonné |
+
+Un job qui tournait sur un runner au moment où il a été abandonné peut encore se terminer avec son vrai résultat, si ce runner finit par le mener à bien.
+
+---
+
+## Trouver des jobs
+
+`GET /api/v2/job` liste les jobs les plus récents en premier, sous la forme `{ "count": ..., "records": [ ... ] }`. Ces paramètres de requête affinent la liste :
+
+| Paramètre | Signification |
+|---|---|
+| `records` | Le nombre maximal de jobs. La valeur par défaut est [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), et 5000 au maximum sauf si `JOBS_LIST_SIZE` est plus élevé. |
+| `user`, `user_type` | Seulement les jobs de cet utilisateur. `user_type` vaut `local` quand il est omis (`ldap`, `azuread`, `oidc` pour les autres). |
+| `runner` | Seulement les jobs exécutés sur ce runner |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Un utilisateur voit ses propres jobs et les jobs qui attendent une approbation que l'un de ses rôles peut donner. Un admin, ou un rôle avec l'option
+`showAllJobLogs` ou `manageAllJobs`, voit tous les jobs. Un enregistrement contient le résumé du job (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...) ; lisez
+le job lui-même pour ses extravars et sa sortie.
+
+`GET /api/v2/job/approvals` répond par un nombre : combien de jobs attendent une approbation que l'utilisateur peut donner.
+
+---
+
+## Plus d'informations sur un job
+
+Ces endpoints lisent davantage d'informations sur un job :
+
+| Appel | Ce qu'il renvoie |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | Les valeurs des champs avec lesquelles le job a été lancé, telles que le formulaire les détenait. Les mêmes permissions que pour une relance s'appliquent : votre propre job (ou tous les jobs pour un admin ou un rôle avec `manageAllJobs`), un formulaire qui autorise la relance, et l'option de rôle `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Les événements structurés d'un job de playbook (depuis la 7.3.0, pour un playbook sur un RTE 7.3.0 ou ultérieur) : chaque play, tâche, résultat d'hôte et le récapitulatif, avec leurs `order`, `type`, `play`, `task`, `host`, `duration` et `time` |
+| `GET /api/v2/job/{id}/events/{order}` | L'un de ces événements avec son `result` complet, tel que l'affiche la boîte de dialogue **Résultat de la tâche** ; `400` quand `order` n'est pas un nombre entier, `404` quand le job n'a pas cet événement |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Un nœud d'un job de workflow : `{ "node", "job", "extravars", "artifacts" }`, où `job` est l'ID du job propre au nœud, ou `null` quand le nœud ne s'est pas exécuté. |
+
+---
+
+## Autres actions
+
+Ces endpoints agissent sur un job existant :
+
+| Appel | Action |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Interrompre un job en cours |
+| `POST /api/v2/job/{id}/relaunch` | Relancer un job, tel qu'il s'est exécuté ou avec des changements (voir [Relancer](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Approuver un job qui attend une approbation ; votre propre job répond `403`, sauf si son approbation définit `allowSelf: true` ou si vous êtes admin |
+| `POST /api/v2/job/{id}/reject` | Rejeter un job qui attend une approbation |
+| `GET /api/v2/job/{id}/download` | Télécharger la sortie du job |
+| `DELETE /api/v2/job/{id}` | Supprimer un job |
+
+L'interruption, l'approbation, le rejet et la suppression répondent par un message, et une relance aussi par l'ID du nouveau job :
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Ajoutez `?verbose=true` à une relance pour exécuter le nouveau job en mode verbeux, avec l'option de rôle `allowVerboseMode`. Un job qui
+n'est pas dans le bon état pour l'action, par exemple l'interruption d'un job déjà terminé, répond `409`.
diff --git a/i18n/fr/_integrate/api/responses.md b/i18n/fr/_integrate/api/responses.md
new file mode 100644
index 0000000..e365124
--- /dev/null
+++ b/i18n/fr/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Réponses et erreurs
+parent: API REST
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Réponses et erreurs
+{: .no_toc }
+
+La forme d'une réponse, et les codes de statut
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Les réponses sont du JSON simple, et le code de statut HTTP indique si un appel a réussi.
+
+---
+
+## Réponses
+
+Un appel réussi renvoie l'objet lui-même, ou une liste avec sa taille :
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Une erreur renvoie un message, et des détails quand il y en a :
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Codes de statut
+
+Le code de statut indique ce qui n'a pas fonctionné :
+
+| Code | Signification |
+|---|---|
+| `200` | L'appel a réussi |
+| `400` | La requête est mal formée, par exemple un rafraîchissement de jeton sans jeton de rafraîchissement, ou un téléversement sans fichier |
+| `401` | Le jeton est absent, erroné ou expiré : connectez-vous ou rafraîchissez-le |
+| `403` | Les rôles de l'utilisateur n'autorisent pas l'appel (y compris approuver votre propre job, sauf si son approbation définit `allowSelf: true` ou si vous êtes admin), ou le compte doit d'abord faire quelque chose (voir plus bas) |
+| `404` | L'objet n'existe pas |
+| `409` | La requête est incomplète (un lancement sans données), ou l'objet n'est pas dans un état qui permet l'action |
+| `422` | La [validation au lancement](../launch-validation/) a refusé les valeurs du formulaire ; `details` en donne les raisons |
+| `429` | Trop de requêtes vers les endpoints de connexion et de jeton, ou trop d'échecs de connexion (voir [Authentification](authentication.html)) |
+| `500` | Le serveur a échoué ; le journal du serveur en donne la raison |
+
+Pour un job, un `409` signifie qu'il n'est pas dans le bon état pour l'action : interrompre un job qui ne tourne pas (ou dont l'interruption a déjà été demandée),
+relancer un job encore en cours, ou approuver ou rejeter un job qui n'attend plus d'approbation.
+
+---
+
+## Un 403 avec un code
+
+Certaines réponses `403` portent un `code`, pour quelque chose que l'utilisateur doit faire dans le navigateur avant que tout autre appel fonctionne :
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Code | Que faire |
+|---|---|
+| `password_change_required` | L'utilisateur s'est connecté avec le mot de passe par défaut public : changez-le d'abord dans le profil |
+| `disclaimer_required` | L'avertissement est activé et l'utilisateur n'a pas encore accepté sa version actuelle : acceptez-le dans le navigateur |
+
+Un jeton d'API de longue durée (voir [Authentification](authentication.html#long-lived-tokens)) n'est jamais bloqué par l'avertissement.
diff --git a/i18n/fr/_integrate/chat/index.md b/i18n/fr/_integrate/chat/index.md
new file mode 100644
index 0000000..ec315d9
--- /dev/null
+++ b/i18n/fr/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Assistant de chat
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Assistant de chat
+{: .no_toc }
+
+Remplir et lancer des formulaires au fil d'une conversation
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs qui l'activent, et les utilisateurs qui discutent avec lui : remplir et lancer des formulaires au fil d'une conversation.
+
+Un bouton de chat sur chaque page ouvre un
+assistant qui trouve le bon formulaire, demande les informations manquantes, propose les choix du formulaire
+sous forme de boutons, et affiche un résumé avec un bouton **Lancer**. Un job ne démarre que lorsque l'utilisateur clique dessus.
+
+---
+
+## Comment ça marche
+
+L'assistant communique avec le modèle d'IA via le serveur, qui répond aux demandes du modèle avec le même moteur de formulaires que le navigateur :
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Les appels au modèle partent du serveur**, jamais du navigateur, la clé d'API reste donc sur le serveur
+  (voir [Fournisseurs](providers.html)).
+- **Le modèle ne peut rien lancer.** Il prépare un résumé à usage unique ; Lancer le revérifie avant l'exécution.
+- **L'utilisateur choisit les cibles.** Les choix et les noms obligatoires viennent de l'utilisateur, jamais du modèle.
+- **Taper « oui » ou « lance » ne fait rien.** Seul le bouton lance un job.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [L'activer](switching-it-on.html) | Activer l'assistant et y proposer des formulaires |
+| [Fournisseurs](providers.html) | Le modèle de langage derrière l'assistant, et les proxys |
+| [Confidentialité et limites](privacy-and-limits.html) | Ce qui sort du réseau, et les limites par utilisateur |
+| [Relance et audit](relaunching-and-audit.html) | La relance depuis le chat, la piste d'audit et les limitations |
diff --git a/i18n/fr/_integrate/chat/privacy-and-limits.md b/i18n/fr/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..4c5423d
--- /dev/null
+++ b/i18n/fr/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Confidentialité et limites
+parent: Assistant de chat
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Confidentialité et limites
+{: .no_toc }
+
+Ce qui sort du réseau, et les limites par utilisateur
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ce qui sort du réseau
+
+Pour les formulaires qui participent, ceci est envoyé au fournisseur :
+
+- les noms et descriptions des formulaires, les libellés des champs, les textes d'aide, les choix et les valeurs en cours
+  de saisie ;
+- la conversation.
+
+Ceci n'est jamais envoyé au fournisseur, à la page ni au journal :
+
+- les mots de passe (l'utilisateur les saisit dans le navigateur), les identifiants stockés et la clé d'API ;
+- la sortie d'un job, et ses extravars stockées (l'assistant ne lit que le statut d'un job, et seulement
+  quand **Laisser l'assistant suivre ses jobs** est activé dans les paramètres).
+
+Tout ce qui se trouve sous une clé qui ressemble à un secret (`password`, `secret`, `token`, `api_key`, ...)
+est masqué avant que le modèle ou la page ne le voie.
+
+Pour garder les données des formulaires en interne, utilisez votre propre tenant (Azure OpenAI) ou un modèle local (Ollama), pas une API publique.
+
+---
+
+## Limites
+
+Les limites suivantes se règlent sur la page des paramètres :
+
+- **Messages par conversation** (20) : après quoi l'utilisateur doit commencer une nouvelle conversation.
+- **Tours d'outils par message** (6) : combien de fois le modèle peut appeler un outil avant de répondre.
+- **Délai d'attente** (60 s) : par appel au fournisseur.
+
+Les limites suivantes sont fixes : un message à la fois par conversation, au plus 4000 caractères par message, 60 messages par
+utilisateur et par heure, et 5 conversations par utilisateur. Une conversation est supprimée après 2 heures sans message.
+
+Une carte de résumé avec un bouton **Lancer** ne sert qu'une fois, et expire au bout de 15 minutes : Lancer répond alors que le
+résumé a expiré, et l'utilisateur en demande un nouveau à l'assistant. Les conversations et les résumés sont gardés en mémoire, donc après
+un redémarrage l'utilisateur doit commencer une nouvelle conversation.
diff --git a/i18n/fr/_integrate/chat/providers.md b/i18n/fr/_integrate/chat/providers.md
new file mode 100644
index 0000000..1b99b14
--- /dev/null
+++ b/i18n/fr/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Fournisseurs
+parent: Assistant de chat
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Fournisseurs
+{: .no_toc }
+
+Le modèle de langage derrière l'assistant, et les proxys
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Choisissez le fournisseur sur la page des paramètres. Cela remplit l'URL de base, l'authentification et
+la version d'API, qui restent toutes modifiables. Les champs vides reprennent les valeurs par défaut du fournisseur.
+
+| Fournisseur | Protocole | URL de base (par défaut) | Clé envoyée comme |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | obligatoire : `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, version d'API `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | aucune |
+| **Autre compatible OpenAI** (LiteLLM, une passerelle, vLLM, LM Studio, ...) | OpenAI | obligatoire, se termine généralement par `/v1` | Bearer |
+
+L'ID du modèle est celui qu'utilise le fournisseur ou le proxy (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). L'assistant a besoin d'un modèle qui prend en charge **l'appel d'outils** (tool calling) ; la prise en charge varie selon
+les petits modèles locaux.
+
+Pour les serveurs locaux et les proxys qui n'ont besoin d'aucune clé, une URL de base suffit ; aucun en-tête d'autorisation n'est envoyé.
+
+---
+
+## La clé d'API
+
+La clé vient d'un identifiant, elle est donc stockée et renouvelée comme tout autre secret :
+
+* Créez un identifiant de type **api** sous **Paramètres > Connexions > Identifiants** (voir [Identifiants](../credentials.html)),
+  avec la clé comme mot de passe. Il peut aussi lire la clé depuis un [coffre de secrets](../secret-stores/).
+* Choisissez-le dans le champ **Identifiant** des paramètres du chat. La clé est lue à chaque message, un
+  mot de passe modifié s'applique donc au message suivant.
+
+Une clé enregistrée sur la page des paramètres avant l'existence des identifiants continue de fonctionner tant qu'aucun identifiant n'est choisi. Le
+[seed de configuration](../seed/) définit la clé lui-même, sous `api_key`.
+
+---
+
+## Pour un proxy
+
+Un proxy ou une passerelle devant le modèle peut avoir besoin de ces paramètres :
+
+- **Authentification** : la façon dont la clé est envoyée : `Authorization: Bearer`, `api-key`, `x-api-key`,
+  ou aucune. Vide utilise la valeur par défaut du fournisseur.
+- **Version d'API** : l'en-tête `anthropic-version`, ou `?api-version=` dans l'URL pour les compatibles OpenAI (Azure).
+- **Utilisateur** : envoyé à chaque appel sous `user` (compatibles OpenAI) ou `metadata.user_id`
+  (Anthropic). Certains proxys l'exigent. Vide n'envoie rien.
+- **Ignorer les erreurs de certificat** : non sécurisé ; faites plutôt confiance à la CA du proxy avec `NODE_EXTRA_CA_CERTS`.
+- **En-têtes supplémentaires** : un objet JSON, p. ex. `{"X-Org": "ops"}`. Des valeurs texte sur une ligne, 20 au maximum ;
+  les en-têtes de clé et de contenu ne peuvent pas être remplacés.
+
+---
+
+## Dans un conteneur, derrière un proxy
+
+Le chat utilise du HTTPS sortant simple depuis le conteneur du serveur AnsibleForms. Derrière un
+proxy de sortie d'entreprise, définissez `HTTPS_PROXY` **et** `NODE_USE_ENV_PROXY=1` ; sans le second,
+le client HTTP intégré de Node ignore `HTTPS_PROXY`. Un fournisseur avec un certificat émis par une
+CA interne exige que Node fasse confiance à cette CA (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Avec `NODE_USE_ENV_PROXY=1`, un modèle ou un proxy à l'intérieur du réseau doit être listé dans
+`NO_PROXY`, sinon l'appel part vers le proxy de sortie, qui ne peut pas l'atteindre.
+
+Un test de connexion qui échoue nomme l'hôte et la raison (DNS, connexion refusée ou certificat non approuvé).
diff --git a/i18n/fr/_integrate/chat/relaunching-and-audit.md b/i18n/fr/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..babb091
--- /dev/null
+++ b/i18n/fr/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Relance et audit
+parent: Assistant de chat
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Relance et audit
+{: .no_toc }
+
+La relance depuis le chat, la piste d'audit et les limitations
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Relance
+
+Une demande comme « Relance le job 1234 » (l'utilisateur doit taper l'ID du job) prépare un aperçu de relance
+selon les mêmes règles que le `relaunch_job` du serveur MCP, y compris la règle des mots de passe de la
+[validation au lancement](../launch-validation), et affiche un résumé **Relancer** ; le bouton
+la lance une fois. « Relance le job 1234 avec le serveur web02 » ne change que ce champ.
+
+---
+
+## Audit
+
+Chaque lancement depuis le chat est enregistré comme **chat.launch** avec l'utilisateur, le job, le formulaire,
+le fournisseur, et le hash du contenu du résumé qui a été approuvé. Les changements des paramètres du chat sont
+enregistrés comme tout autre changement de paramètres.
+
+---
+
+## Limitations
+
+L'assistant de chat ne fait pas encore tout ce que fait un navigateur :
+
+- **Les formulaires assistant (wizard)** ne peuvent pas participer (`enableForChat` y est refusé), pas plus que
+  les champs que l'assistant ne remplit pas : les mots de passe et les téléversements de fichiers.
+- Les réponses arrivent d'un seul bloc ; le streaming n'est pas encore pris en charge.
+- Le modèle peut mal comprendre une demande. La carte de résumé montre exactement ce qui sera envoyé ;
+  relisez-la avant de cliquer sur **Lancer**.
diff --git a/i18n/fr/_integrate/chat/switching-it-on.md b/i18n/fr/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..7422cf5
--- /dev/null
+++ b/i18n/fr/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: L'activer
+parent: Assistant de chat
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# L'activer
+{: .no_toc }
+
+Activer l'assistant et y proposer des formulaires
+{: .fs-6 .fw-300 }
+
+---
+
+L'assistant a besoin des quatre éléments suivants :
+
+1. **`ENABLE_CHAT=1`** : la variable d'environnement. Modifiée sur la page des paramètres, elle s'applique immédiatement, sans redémarrage ; tant
+   qu'elle est désactivée, les endpoints du chat répondent `404`. Voir [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Un fournisseur de modèles** : Paramètres -> Connexions -> **Assistant de chat** (ou le [seed de configuration](../seed) sur Kubernetes).
+3. **Des formulaires qui participent** : `enableForChat: true` sur chaque formulaire ; l'assistant ignore tous les autres.
+4. **Des utilisateurs qui ont le droit de l'utiliser** : l'option de rôle `allowChat` (par défaut : true). Définissez
+   `allowChat: false` sur un rôle pour en exclure les membres.
+
+Le bouton de chat apparaît pour un utilisateur dès que les quatre conditions sont remplies.
diff --git a/i18n/fr/_integrate/mcp/index.md b/i18n/fr/_integrate/mcp/index.md
new file mode 100644
index 0000000..cc5fc07
--- /dev/null
+++ b/i18n/fr/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Serveur MCP
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# Serveur MCP
+{: .no_toc }
+
+Laisser les agents d'IA utiliser vos formulaires via le Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les administrateurs et les intégrateurs : laisser les clients MCP lister, remplir et lancer des formulaires en tant que l'utilisateur dont ils détiennent le jeton.
+
+AnsibleForms peut servir un
+serveur [Model Context Protocol](https://modelcontextprotocol.io), pour qu'un client MCP, comme
+un backend de chat ou un assistant d'IDE, puisse lister les formulaires qu'un utilisateur peut utiliser, déterminer leurs champs,
+lancer des jobs et suivre leur progression.
+
+---
+
+## Ce que c'est, et ce que ce n'est pas
+
+Le serveur MCP est une interface technique vers le même parcours de formulaire que celui du navigateur. Il s'exécute
+**en tant que l'utilisateur dont il reçoit le jeton** : les mêmes rôles de formulaire, la même visibilité des jobs, les
+mêmes vérifications des extravars réservées qu'une soumission depuis le navigateur.
+
+Il n'ajoute aucune politique d'IA à lui. C'est au client MCP de décider si un agent doit demander une confirmation avant un lancement,
+quels formulaires il peut utiliser, ou combien de requêtes il peut faire. L'outil de
+lancement est marqué comme destructif, un client bien conçu demande donc d'abord une confirmation,
+mais le serveur ne l'impose pas.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Configuration](setup.html) | Activer le serveur et authentifier le client |
+| [Outils](tools.html) | Les outils qu'un agent utilise pour remplir, approuver et relancer des formulaires |
+| [Limitations](limitations.html) | Les expressions exécutées sur le serveur, et ce que le serveur MCP ne fait pas |
diff --git a/i18n/fr/_integrate/mcp/limitations.md b/i18n/fr/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..c5e53ed
--- /dev/null
+++ b/i18n/fr/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Limitations
+parent: Serveur MCP
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Limitations
+{: .no_toc }
+
+Les expressions exécutées sur le serveur, et ce que le serveur MCP ne fait pas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Expressions runLocal
+
+Les expressions `runLocal`, les champs `local` / `credential` / `html` et les valeurs par défaut `evalDefault` sont
+évalués sur le serveur, dans un contexte V8 séparé : pas de `process`, de `require`, de réseau ni de
+timers, pas de compilation de chaînes en code, une limite de temps de 2 secondes, et seulement les fonctions
+utilitaires que propose le navigateur (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Cela protège contre les expressions boguées ou qui s'emballent. Ce n'est pas un bac à sable pour du code hostile,
+et cela n'a pas besoin de l'être : le code vient de la définition du formulaire, jamais de l'appelant
+MCP, et chaque valeur qu'envoie un appelant est substituée comme littéral JavaScript.
+
+Une expression qui utilise une API du navigateur (`window`, `document`, `fetch`) ne peut pas s'exécuter ici et
+renvoie `status: error`.
+
+Les expressions côté serveur (sans `runLocal`) passent par les mêmes règles
+[`EXPRESSION_SANITIZER`](../customization) que pour le navigateur.
+
+---
+
+## Limitations
+
+Certains formulaires et champs ne peuvent pas encore être utilisés via le serveur MCP :
+
+- **Les formulaires assistant (wizard)** ne peuvent pas encore être lancés. Leurs étapes peuvent être résolues avec `subform`.
+- **Les champs fichier** ne peuvent pas être remplis ; un formulaire dont le champ fichier a une valeur est refusé.
+- **Les lignes de liste** (et un champ `yaml` avec un sous-formulaire, qui est une telle ligne) : chaque ligne que vous
+  envoyez, sauf une ligne portant le `deleteMarker` de la liste, est résolue via son sous-formulaire avec
+  les valeurs du formulaire comme `__parent__`, puis validée. Cela inclut les listes imbriquées, où
+  `__parent__.__parent__` atteint le formulaire. Envoyez des lignes simples, c'est-à-dire les valeurs brutes des champs
+  du sous-formulaire. Les lignes en échec sont listées par champ de liste dans `rowErrors`
+  (`vms[1].disks[0].size (missing)` dans le message). Au plus 500 lignes sont acceptées par appel,
+  tous niveaux confondus.
+- Un enum laissé sur `__auto__` n'est jamais rempli avec sa première option ; l'appelant doit choisir.
+- Chaque requête MCP crée une entrée dans le journal d'audit (action « Requête MCP (agent IA) ») ; le
+  job lui-même est enregistré au nom de l'utilisateur, comme pour tout autre lancement.
diff --git a/i18n/fr/_integrate/mcp/setup.md b/i18n/fr/_integrate/mcp/setup.md
new file mode 100644
index 0000000..eae1d3b
--- /dev/null
+++ b/i18n/fr/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Configuration
+parent: Serveur MCP
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Configuration
+{: .no_toc }
+
+Activer le serveur et authentifier le client
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'activer
+
+Mettez [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) à `1`, ou activez-le sous **Paramètres > Connexions > MCP**
+(voir [La page MCP](#the-mcp-page)). Modifié sur la page des paramètres, l'interrupteur s'applique immédiatement, sans redémarrage. Tant qu'il est
+désactivé, l'endpoint répond `404`. L'endpoint est :
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Il utilise du Streamable HTTP sans état avec des réponses JSON simples, `GET` et `DELETE` renvoient donc 405.
+
+---
+
+## Limiter ce que les agents peuvent faire
+
+Deux autres interrupteurs restreignent le serveur MCP pour tous les clients. Comme `ENABLE_MCP`, ils s'appliquent sans redémarrage :
+
+| Variable | Avec `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | Le serveur ne propose aucun des outils qui lancent, planifient ou modifient (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), et les refuse. Les agents peuvent lister, lire et remplir des formulaires, lire les planifications et les jobs enregistrés, et suivre les jobs, mais ne lancent ni ne modifient rien : une façon sûre d'essayer un agent. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Les agents ne voient que les formulaires qui définissent `enableForChat: true`, la même liste que pour l'[assistant de chat](../chat/). Tout autre formulaire, et tout job de l'un d'eux, répond comme introuvable. |
+
+Les deux sont désactivés par défaut : les agents voient chaque formulaire que les rôles de l'utilisateur autorisent, et peuvent les lancer.
+
+---
+
+## La page MCP
+
+**Paramètres > Connexions > MCP** contient les paramètres du serveur MCP dans deux onglets.
+
+- **Général** a les trois interrupteurs, `ENABLE_MCP`, `MCP_READ_ONLY` et `MCP_CHAT_FORMS_ONLY`, enregistrés avec **Enregistrer**. Les deux
+  autres ne peuvent être modifiés que lorsque le serveur MCP est activé.
+- **Configuration du client** affiche le **Point de terminaison**, avec un bouton pour le copier, et une configuration prête pour **Claude Code**
+  (`.mcp.json`, ou une commande `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, qui demande
+  le jeton au premier démarrage du serveur) et **Codex** (`~/.codex/config.toml`, avec le jeton dans la
+  variable d'environnement `ANSIBLEFORMS_TOKEN`). Chacune a son bouton de copie ; remplacez `<your-token>` par un jeton à vous, créé
+  avec le lien **Créer un jeton**.
+
+L'endpoint est construit à partir de l'URL de l'application (**Paramètres > URL**) quand elle est définie, sinon à partir de l'adresse du navigateur.
+
+---
+
+## Authentification
+
+Chaque requête a besoin d'un jeton d'accès AnsibleForms :
+
+```
+Authorization: Bearer <token>
+```
+
+Obtenez-en un de la manière habituelle (`POST /api/v2/auth/login`, ou les flux OIDC / Entra ID) et
+rafraîchissez-le avec `POST /api/v2/token`. Il n'y a délibérément **aucun outil de connexion** : un mot de passe passé comme
+argument d'outil finirait dans le contexte du modèle de langage et dans son historique de chat.
+
+Les rôles de l'utilisateur doivent aussi autoriser le serveur MCP, via l'[option de rôle](../config/roles.html) `allowMcp`. Quand aucun rôle
+de l'utilisateur ne la définit, elle suit `allowChat`, activée par défaut. Un utilisateur à qui il est refusé reçoit `403` à chaque requête.
+
+- **Un backend de chat** connecte lui-même l'utilisateur, garde le jeton de rafraîchissement et transmet le jeton
+  d'accès à chaque appel MCP.
+- **Un client d'IDE** a besoin d'un jeton qui dure assez longtemps pour n'être configuré qu'une fois. Avec un rôle
+  qui a l'option `allowApiTokens`, créez-en un sous
+  [Profil > Jetons d'API](../profile/api-token.html), ou connectez-vous avec `?expiryDays=<n>` sur
+  l'URL de connexion pour un jeton valable ce nombre de jours.
+
+Pour connecter un agent de code avec un tel jeton :
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Ajoutez le serveur avec le jeton comme en-tête :
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Ajoutez le serveur à `~/.codex/config.toml`, avec le jeton lu dans une variable d'environnement :
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Définissez ensuite la variable avant de démarrer Codex :
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/fr/_integrate/mcp/tools.md b/i18n/fr/_integrate/mcp/tools.md
new file mode 100644
index 0000000..44ef068
--- /dev/null
+++ b/i18n/fr/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Outils
+parent: Serveur MCP
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Outils
+{: .no_toc }
+
+Les outils qu'un agent utilise pour remplir, approuver et relancer des formulaires
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le serveur MCP propose jusqu'à 15 outils. Six sont proposés à tous les utilisateurs ; les autres suivent les options de rôle de l'utilisateur, si bien qu'un utilisateur
+sans une option ne se voit pas du tout proposer ses outils :
+
+| Outil | Ce qu'il fait | Proposé avec |
+|---|---|---|
+| `list_forms` | Les formulaires que l'utilisateur peut utiliser : nom, description, catégories, et `enableForChat` (si l'assistant de chat le propose). | toujours |
+| `get_form` | La définition complète d'un formulaire. Chaque champ porte aussi `dynamic` (évalué à partir d'une expression ou d'une requête) et `dependsOn` (les champs qu'il lit). | toujours |
+| `resolve_field` | Évalue le formulaire pour les valeurs remplies jusqu'ici. Voir plus bas. | toujours |
+| `launch_job` | Lance le formulaire avec les valeurs données, exactement comme le ferait une soumission depuis le navigateur. Renvoie l'id du job. | toujours |
+| `relaunch_job` | Relance un job avec certains champs modifiés. Voir plus bas. | toujours |
+| `get_job` | Le statut et la sortie d'un job (`tail` limite la sortie aux dernières lignes). | toujours |
+| `plan_job` | Exécute le formulaire une fois, plus tard, en tant que l'utilisateur : ce que fait **Exécuter plus tard (une seule fois)** sur le formulaire. | `allowPlannedJobs` |
+| `create_schedule` | Crée une planification, récurrente (`cron`) ou unique (`run_at`), comme sur la page **Planifications**. | `allowScheduledJobs` |
+| `list_schedules` | Les planifications que l'utilisateur peut voir : toutes avec `allowScheduledJobs`, sinon les exécutions qu'il a planifiées. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `get_schedule` | Une planification, avec ses variables supplémentaires (celles qui ressemblent à des secrets étant masquées) et la sortie de sa dernière exécution. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `delete_schedule` | Annule une exécution planifiée ou supprime une planification que l'utilisateur peut voir. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `list_stored_jobs` | Les [jobs enregistrés](../jobs/stored-jobs.html) que l'utilisateur peut voir, sans leurs valeurs. | `allowStoredJobs` |
+| `get_stored_job` | Un job enregistré avec ses valeurs, par `id`, ou par `form` et `name` parmi ceux de l'utilisateur. | `allowStoredJobs` |
+| `store_job` | Enregistre les valeurs d'un formulaire sous un nom, comme le fait **Enregistrer** sur le formulaire. | `allowStoredJobs` |
+| `delete_stored_job` | Supprime un job enregistré que l'utilisateur peut voir. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` et `plan_job` acceptent `verbose: true` pour exécuter le job en mode verbeux, ce qui nécessite l'option de rôle
+`allowVerboseMode`. Avec [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do), les outils qui lancent, planifient ou
+modifient (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` et `delete_stored_job`)
+ne sont pas proposés.
+
+Il n'existe aucun outil pour exécuter une expression, une requête, un playbook ou des extravars arbitraires. Les expressions
+et les requêtes ne s'exécutent jamais que telles que le formulaire les définit.
+
+L'[assistant de chat](../chat) utilise aussi ces outils, avec un bouton **Lancer** à la place de `launch_job`.
+
+---
+
+## Remplir un formulaire
+
+Appelez `resolve_field` avec le nom du formulaire et les valeurs dont vous disposez, puis à nouveau après chaque réponse. Il parcourt
+les champs dans l'ordre de leurs dépendances et indique pour chacun :
+
+- `status` : `resolved`, `waiting` (avec `waitingFor`), `hidden`, ou `error` (le champ revient à sa valeur par défaut) ;
+- `value`, `default` et, pour les champs à choix, `options` (au plus `maxOptions`, 200 par défaut) ;
+- `needsInput` : un champ obligatoire sans valeur, ou un choix encore sur `__auto__` ;
+- `validationErrors` : les règles que la valeur enfreint, sous la forme `[{type, description}]`, avec le message du navigateur.
+
+Pour l'ensemble du formulaire, `missing` et `invalid` listent ce qui reste à corriger ; `launch_job` le refuse tant que `complete` ne vaut pas true.
+
+La validation est le code même du navigateur, partagé avec la [validation au lancement](../launch-validation). Les champs masqués ne sont pas
+validés, et un champ facultatif vide est valide.
+
+---
+
+## Planifications et exécutions planifiées
+
+`plan_job` accepte les mêmes `form`, `values` et `expectedPayloadHash` que `launch_job`, avec un `name` pour l'exécution et `run_at`, une
+heure ISO 8601 avec son décalage ou `Z` (`2026-10-15T22:00:00+02:00`) ; une heure sans fuseau est refusée. Les valeurs sont résolues
+et validées immédiatement, et vérifiées à nouveau au déclenchement de l'exécution, comme pour une [exécution planifiée](../jobs/schedules.html#planned-runs) dans le
+navigateur. La réponse donne l'heure d'exécution en UTC et selon l'horloge de l'application.
+
+`create_schedule` accepte un `form`, un `name`, soit `cron` (cinq champs, comme `0 22 * * 1-5`) soit `run_at`, et les
+`extraVars` que reçoit le job. Une telle planification s'exécute en tant que `Schedule Service`, sans la validation du formulaire ; pour exécuter un formulaire une fois en tant
+que l'utilisateur, utilisez `plan_job`. Les noms de planification sont uniques.
+
+---
+
+## Jobs enregistrés
+
+Un job enregistré est l'ensemble des valeurs d'un formulaire enregistré sous un nom ; les outils travaillent sur les mêmes jobs enregistrés que le navigateur.
+
+`list_stored_jobs` liste les jobs enregistrés de l'utilisateur, ou ceux de tout le monde pour un utilisateur avec `showSettings`, avec leur nom, leur description,
+leur formulaire, leur création et leur expiration. Un job marqué `usable` (appartenant à l'utilisateur, d'un formulaire qu'il peut lancer) peut être passé comme `storedJob`
+(`{ "id": 7 }`, ou `{ "name": "..." }` parmi ceux de l'utilisateur pour ce formulaire) à `resolve_field`, `launch_job` ou `plan_job` : ses
+valeurs servent de point de départ et `values` s'y superposent. Les champs mot de passe ne sont pas enregistrés, fournissez-les donc dans `values`.
+`launch_job` et `plan_job` à partir d'un job enregistré ont besoin du `expectedPayloadHash` que `resolve_field` a renvoyé pour lui, et
+`resolve_field` refuse `storedJob` combiné à `subform`.
+
+`store_job` accepte le `form`, un `name` unique parmi les jobs enregistrés de l'utilisateur pour ce formulaire, les `values`, et éventuellement une
+`description` et un `expires_at` (ISO 8601 avec son décalage ou `Z`). Sa réponse indique quels champs mot de passe ont été laissés de côté.
+
+---
+
+## Transmettre des valeurs
+
+Passez `field` pour ne résoudre que ce champ et ce dont il dépend. Pour une ligne de liste ou une étape d'assistant, passez `subform` (et
+éventuellement `parent`, les valeurs du formulaire parent).
+
+Envoyez les valeurs telles que le navigateur les détient. Un champ à choix accepte aussi un enregistrement partiel ou sa valeur `valueColumn`
+(`"vol1"`), et un tableau quand il est `multiple`. Les champs calculés ignorent les valeurs envoyées, sauf s'ils sont `editable`.
+
+---
+
+## Approuver le contenu exact
+
+Quand le formulaire est complet, `resolve_field` renvoie aussi ce que `launch_job` va soumettre :
+
+- `modeledExtravars` : les extravars après application de `model`, `valueColumn` et `output`,
+  avec les champs mot de passe masqués ;
+- `credentials` : les identifiants AnsibleForms qu'utilisera le job (des noms, pas des secrets) ;
+- `payloadHash` : un hash SHA-256 du nom du formulaire, des vraies extravars et des identifiants.
+
+Montrez `modeledExtravars` à l'opérateur, et passez le `payloadHash` qu'il a approuvé à
+`launch_job` comme `expectedPayloadHash`. Le lancement résout à nouveau le formulaire et est refusé
+quand le contenu diffère, par exemple parce qu'une requête répond désormais autrement.
+`ansibleforms_user`, `__jobid__` et `__verbose__` sont ajoutés au lancement et ne font pas partie du hash.
+
+`launch_job` ne vérifie que le contenu. Une modification du formulaire qui laisse le contenu identique ne fait pas refuser le lancement.
+Chaque réponse de `resolve_field` porte aussi un `formFingerprint`, un hash SHA-256 de la définition du formulaire : pour refuser un
+lancement après toute modification du formulaire, comparez-le vous-même avant d'appeler `launch_job`, comme le fait le bouton
+**Lancer** de l'assistant de chat.
+
+---
+
+## Relancer avec des changements
+
+`relaunch_job` accepte un `id` de job et des `values` : seulement les champs à changer, en valeurs brutes.
+`values` se superpose aux valeurs avec lesquelles le job a été lancé à l'origine, et le résultat est
+résolu et validé exactement comme par `launch_job`, lignes de liste comprises, puis lancé comme un
+nouveau job par vous (`ansibleforms_user`, c'est vous, pas l'auteur d'origine). Les fichiers téléversés
+du job d'origine sont réutilisés.
+
+Sans `values`, c'est une relance **telle que le job s'est exécuté** : ses extravars stockées sont rejouées sur
+le serveur, mots de passe compris (l'aperçu les masque). Si le formulaire est soumis à la validation au lancement
+`enforce`, la relance passe toutefois par la même vérification qu'une relance avec
+changements.
+
+**Les mots de passe ne sont jamais stockés avec les valeurs des champs**, une relance qui passe par la
+vérification est donc refusée quand le formulaire affiche un champ mot de passe, au niveau supérieur ou dans une ligne de liste
+(`unsupported`, avec les `passwordFields`). Un champ mot de passe masqué par ses dépendances ne
+bloque pas la relance. Voir [Validation au lancement](../launch-validation).
+
+Appelez-le d'abord avec `preview: true` : il renvoie `modeledExtravars` (mots de passe masqués),
+`credentials` et un `payloadHash` sans lancer. Faites-les confirmer par l'utilisateur, puis appelez-le
+à nouveau avec `expectedPayloadHash`. Les mêmes permissions que pour une relance dans le navigateur
+s'appliquent : le formulaire doit autoriser la relance et vos rôles ont besoin de l'option `allowJobRelaunch`. Un
+job sans données de formulaire stockées (lancé avant que la relance n'existe) et un formulaire assistant ne peuvent pas être
+relancés avec des changements.
+
+L'API REST propose la même chose via `POST /api/v2/job/{id}/relaunch` avec le corps
+`{ "values": { ... } }` ; sans corps, elle rejoue le job tel qu'il s'est exécuté.
+
+---
+
+## Erreurs
+
+Un appel refusé est une erreur d'outil dont le contenu structuré porte un `code` et les détails :
+
+| Code | Quand |
+|---|---|
+| `form_incomplete` | `launch_job` ou `relaunch_job` sur un formulaire incomplet, avec `missing`, `invalid`, `waiting`, `validationErrors` et `rowErrors` |
+| `payload_mismatch` | le contenu diffère de `expectedPayloadHash`, avec les deux hashs |
+| `access_denied` | les rôles de l'utilisateur n'accordent pas le formulaire, le job, la planification ou le job enregistré, ou le mode verbeux, ou le serveur est en lecture seule |
+| `not_found` | aucun formulaire, sous-formulaire ou job de ce nom |
+| `unsupported` | un formulaire assistant, un sous-formulaire seul, un champ fichier, ou un `relaunch_job` qui nécessiterait un champ mot de passe affiché |
+| `no_form_data` | `relaunch_job` avec changements pour un job qui n'a stocké aucune valeur de formulaire, comme un job lancé par une planification ; relancez-le plutôt sans changements |
+| `invalid_request` | une requête que le serveur refuse comme mal formée |
+| `internal_error` | tout le reste |
diff --git a/i18n/fr/_introduction/concepts.md b/i18n/fr/_introduction/concepts.md
new file mode 100644
index 0000000..2b2fa58
--- /dev/null
+++ b/i18n/fr/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Concepts
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Concepts
+{: .no_toc }
+
+Les termes utilisés dans cette documentation, chacun avec un lien vers sa page
+{: .fs-6 .fw-300 }
+
+---
+
+## Glossaire
+
+Les termes utilisés dans cette documentation :
+
+| Terme | Signification |
+|---|---|
+| **[Formulaire](forms/)** | Une définition YAML qui recueille des saisies et exécute un playbook, un modèle ou un workflow |
+| **[Champ de formulaire](formfields/)** | Une saisie d'un formulaire, comme `text`, `enum` ou `checkbox` ; sa valeur devient une extravar |
+| **[Catégorie](config/categories.html)** | Un groupe dans l'arborescence des formulaires affichée sur la page Formulaires, défini dans `config.yaml` |
+| **[Rôle](config/roles.html)** | Un ensemble d'utilisateurs et de groupes ; un formulaire liste les rôles qui peuvent le voir et l'exécuter, `default` pour tout le monde |
+| **[Expression](expressions/)** | Du JavaScript qui calcule la valeur d'un champ, dans le navigateur (`runLocal: true`) ou sur le serveur |
+| **[Extravars](formfields/)** | Les variables envoyées au playbook ou au modèle, construites à partir des valeurs des champs |
+| **[Identifiant](expressions/credentials.html)** | Un accès enregistré, chiffré avec `ENCRYPTION_SECRET` : un utilisateur et un mot de passe (plus hôte, port, base de données), ou depuis la 7.3.0 l'adresse et les secrets d'un annuaire LDAP, d'un fournisseur SSO, d'un runner ou d'un HashiCorp Vault |
+| **[Coffre de secrets](secret-stores/)** | Une connexion à HashiCorp Vault ou CyberArk qui fournit l'utilisateur et le mot de passe d'un identifiant |
+| **[Job](gui/forms-and-jobs.html)** | Une exécution d'un formulaire, avec son statut, ses extravars et sa sortie, conservée dans l'historique des jobs |
+| **[Runner](runners.html)** | L'endroit où un job s'exécute, ajouté sous **Connexions > Runners** : `rte` pour les playbooks, `awx` (AWX, ou la variante `aap` ou `ascender`), `semaphore`, `rundeck` ou `jenkins` pour les modèles et les jobs. Un formulaire en choisit un avec `runner:`, ou s'exécute sur le runner par défaut `rte` (playbooks) ou `awx` (modèles) |
+| **[RTE](rte/)** | Un environnement d'exécution (runtime environment) : le serveur AnsibleForms démarré avec `AF_ROLE=rte` dans son propre conteneur, à côté de python et d'ansible, qui exécute les playbooks d'un runner de type `rte` |
+| **[Point d'approbation](forms/approval.html)** | Une pause dans un job jusqu'à ce qu'un utilisateur ayant un rôle d'approbation l'approuve ou le rejette |
+| **[Workflow](workflows/)** | Un graphe de playbooks, d'approbations et d'autres workflows liés en cas de succès, en cas d'échec ou toujours, dans la syntaxe d'AWX |
+| **[Formulaire multi-étapes](forms/multistep.html)** | Obsolète depuis la 7 : un formulaire qui exécute plusieurs playbooks ou modèles à la suite ; un workflow le remplace |
+| **[Canal de notification](notification-channels.html)** | Un serveur de messagerie, un webhook Slack ou Teams, un chat Telegram ou un webhook vers lequel partent les notifications et les demandes d'approbation |
+| **[Concepteur](designer/)** | L'éditeur dans le navigateur pour les formulaires, les playbooks, les inventaires et les workflows, qu'une seule personne utilise à la fois |
+| **[Sous-formulaire](forms/subform.html)** | Un ensemble réutilisable de champs qui décrit les lignes d'un champ `list` ou l'objet d'un champ `yaml` |
+| **[config.yaml](config/)** | Le fichier qui contient les catégories, les rôles et les constantes ; les formulaires sont dans leurs propres fichiers |
+| **[Seed de configuration](seed/)** | Un fichier YAML (`CONFIG_SEED_PATH`) qui déclare les objets d'administration, comme les runners et les identifiants |
+| **[Dossier persistant](customization/paths.html)** | Le dossier qui contient les fichiers qu'AnsibleForms doit conserver entre les redémarrages et les mises à niveau |
diff --git a/i18n/fr/_introduction/gui/administration.md b/i18n/fr/_introduction/gui/administration.md
new file mode 100644
index 0000000..ed46a98
--- /dev/null
+++ b/i18n/fr/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Administration
+parent: Visite de l'interface
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Administration
+{: .no_toc }
+
+Le menu Paramètres : le système, son apparence, les accès, les connexions et les journaux
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le menu Paramètres
+
+**Paramètres** dans l'en-tête ouvre les pages d'administration, regroupées dans le menu de gauche sous **Système**, **Apparence**,
+**Accès**, **Connexions** et **Journaux**. Chaque entrée n'apparaît qu'à un utilisateur qui a l'option de rôle dont sa page a besoin :
+`allowBackupOps` pour **Sauvegardes**, `showLogs` pour **Journal du serveur**, et `showSettings` pour toutes les autres pages.
+Depuis la 7.3.0, trois options en ouvrent une partie sans le reste :
+
+| Option de rôle | Ouvre |
+|---|---|
+| `showAppearanceSettings` | Les pages **Apparence** |
+| `showConnectionsSettings` | Les pages **Connexions**, sauf **Syslog** ; les dépôts, les coffres de secrets et les identifiants protégés restent modifiables par un admin seulement |
+| `showAuditLog` | Le **Journal d'audit** |
+
+Voir [Rôles](../config/roles.html#role-options) pour les options de rôle.
+
+---
+
+## Listes et pages d'enregistrement
+
+Depuis la 7.3.0, les listes des paramètres et les pages d'enregistrement partagent une même mise en page, avec leurs contrôles sur une ligne à part sous le titre :
+
+| Élément | Fonctionnement |
+|---|---|
+| Champ de recherche | En premier sur cette ligne dans chaque page de paramètres et chaque page d'enregistrement. Un mot filtre tous les onglets à la fois : les champs, lignes ou entrées qui correspondent s'affichent sous le nom de leur onglet |
+| Taille de page | Un tableau affiche autant de lignes que l'écran en contient tant qu'aucune taille de page n'est choisie : 10, 20, 50 ou 100 |
+| Colonnes | Chaque colonne nommée se trie, et une cellule vide affiche `–` |
+| Cases à cocher | Les lignes n'en ont que là où l'on peut faire quelque chose avec les lignes cochées, et le menu de ligne (⋮) propose la même action |
+| Menu de ligne | Des libellés courts, comme **Modifier** et **Supprimer**. Une liste avec une colonne **Activé** la met en premier, et propose **Activer** ou **Désactiver** dans chaque menu de ligne, selon le cas |
+
+Les listes avec une colonne **Activé** sont les fournisseurs SSO, les annuaires LDAP, les runners, les planifications, les canaux
+de notification, les serveurs syslog, les annonces, les étiquettes et les versions de l'avertissement.
+
+---
+
+## Système
+
+L'instance elle-même : ses paramètres, son état de santé et ses sauvegardes.
+
+| Page | À quoi elle sert |
+|---|---|
+| **Général** | Les variables d'environnement, en onglets de Configuration à Journalisation. Voir [Variables d'environnement](../customization/). |
+| **Statut** | L'état de santé de l'instance et des systèmes dont elle dépend, dans les onglets Vérifications et Informations. Voir [Supervision](../production/monitoring.html). |
+| **Sauvegardes** | Faire, restaurer et supprimer des sauvegardes de la base de données, de config.yaml et des formulaires. Voir [Sauvegardes](../production/backups.html). |
+
+![Paramètres > Général, l'onglet Configuration](../assets/screenshots/settings.jpg)
+
+### Sauvegardes
+
+La liste des sauvegardes, nocturnes et manuelles : **Ajouter une sauvegarde** en fait une tout de suite, et le menu d'une ligne propose **Afficher la sauvegarde**, **Restaurer** et **Supprimer**.
+
+![Paramètres > Sauvegardes](../assets/screenshots/backups.jpg)
+
+### Restaurer
+
+**Restaurer** montre le contenu de la sauvegarde, puis la restaure ; **Créer une nouvelle sauvegarde avant la restauration (recommandé)** est coché par défaut.
+
+![Restaurer une sauvegarde](../assets/screenshots/restore.jpg)
+
+---
+
+## Apparence
+
+L'aspect de l'instance pour tout le monde, et les messages qu'elle affiche.
+
+| Page | À quoi elle sert |
+|---|---|
+| **Valeurs par défaut** | Le thème, la langue, l'affichage des formulaires, le fuseau horaire et le format de date des utilisateurs qui n'en ont choisi aucun. Voir [Valeurs par défaut](../appearance/defaults.html). |
+| **Nom** | Le nom dans l'onglet du navigateur et sur la page de connexion. Voir [Nom](../appearance/name.html). |
+| **Logo** | Votre propre logo dans l'en-tête. Voir [Logo](../appearance/logo.html). |
+| **Icône** | Votre propre icône dans l'onglet du navigateur. Voir [Icône](../appearance/icon.html). |
+| **Liens** | Le lien du Concepteur, et vos propres liens et menus dans l'en-tête. Voir [Liens](../appearance/links.html). |
+| **Étiquettes** | Des étiquettes à côté du logo, comme PRODUCTION et EU. Voir [Étiquettes](../appearance/labels.html). |
+| **Annonces** | Des messages sous l'en-tête, chacun de son début à sa fin. Voir [Annonces](../announcements.html). |
+
+---
+
+## Accès
+
+Qui peut se connecter, et ce qu'il peut faire une fois connecté.
+
+| Page | À quoi elle sert |
+|---|---|
+| **Avertissement** | Des conditions que chaque utilisateur accepte une fois, et qui a accepté quelle version. Voir [Avertissement](../disclaimer.html). |
+| **Utilisateurs** | Les utilisateurs locaux, et ceux de LDAP et de l'authentification unique. Voir [Utilisateurs et groupes](../users-and-groups.html). |
+| **Groupes** | Les groupes locaux, et ceux de LDAP et de l'authentification unique. Voir [Utilisateurs et groupes](../users-and-groups/local-group.html). |
+| **Rôles** | Les rôles de config.yaml : qui les a et ce qu'ils permettent. Voir [Rôles](../config/roles.html). |
+| **LDAP** | La connexion avec un annuaire LDAP ou Active Directory. Voir [LDAP](../authentication/ldap.html). |
+| **SSO** | L'authentification unique avec des fournisseurs Entra ID ou OpenID Connect. Voir [Authentification](../authentication/). |
+
+![Accès > LDAP, l'annuaire principal](../assets/screenshots/ldap.jpg)
+
+---
+
+## Connexions
+
+Les systèmes qu'AnsibleForms contacte, et ce avec quoi il s'y connecte.
+
+| Page | À quoi elle sert |
+|---|---|
+| **Dépôts** | Les dépôts git d'où viennent les formulaires et les playbooks. Voir [Dépôts git](../repositories/). |
+| **Identifiants** | Les comptes et les secrets qu'utilisent les formulaires, les playbooks et les connexions. Voir [Identifiants](../credentials.html). |
+| **Coffres de secrets** | HashiCorp Vault et CyberArk, où les identifiants peuvent être lus. Voir [Coffres de secrets](../secret-stores/). |
+| **Runners** | Là où les jobs s'exécutent : des conteneurs RTE pour les playbooks, et AWX et consorts pour les modèles. Voir [Runners](../runners.html). |
+| **SSH** | La paire de clés avec laquelle l'application se connecte à git, et les hôtes connus. Voir [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Notifications** | Serveurs SMTP, Slack, Microsoft Teams, Telegram et webhooks. Voir [Canaux de notification](../notification-channels.html). |
+| **Assistant de chat** | Le fournisseur d'IA de l'assistant de chat. Voir [Assistant de chat](../chat/). |
+| **MCP** | Le serveur MCP pour les agents d'IA. Voir [MCP](../mcp/). |
+| **Syslog** | Des serveurs syslog qui reçoivent le journal du serveur, le journal d'audit, ou les deux. Voir [Syslog](../production/logs.html#syslog). |
+
+![Connexions > Identifiants, l'onglet Connexion d'un identifiant](../assets/screenshots/credentials.jpg)
+
+---
+
+## Journaux
+
+Ce qui s'est passé sur l'instance.
+
+| Page | À quoi elle sert |
+|---|---|
+| **Journal d'audit** | Qui a modifié quoi, et si c'était autorisé, filtré par utilisateur, action et résultat. Voir [Piste d'audit](../production/logs.html#audit-trail). |
+| **Journal du serveur** | Le journal propre du serveur, pour le dépannage. Voir [Journaux](../production/logs.html). |
+
+### Journal du serveur
+
+Les dernières lignes du journal, les plus récentes en bas, suivies au fur et à mesure de leur écriture. Le champ de recherche les filtre (une expression
+régulière), **Effacer** vide l'affichage, pas le journal, et **Télécharger** enregistre le journal complet.
+
+![Journaux > Journal du serveur](../assets/screenshots/logs.jpg)
+
+---
+
+## Documentation API
+
+**Documentation API** dans le menu d'aide (le point d'interrogation dans l'en-tête) mène à l'interface Swagger de l'API REST sur `/api/v2/docs`.
+Voir [API](../api/).
+
+![Interface Swagger](../assets/screenshots/swagger.jpg)
diff --git a/i18n/fr/_introduction/gui/designer-and-git.md b/i18n/fr/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..cb34500
--- /dev/null
+++ b/i18n/fr/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Concepteur et git
+parent: Visite de l'interface
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Concepteur et git
+{: .no_toc }
+
+Modifier des formulaires et les garder dans git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Concepteur intégré
+
+Modifiez les formulaires, les catégories, les constantes, les fichiers de variables, les playbooks, les inventaires et les workflows, chacun en YAML, avec des champs (Visuel)
+et en aperçu. Les pages du [Concepteur](../designer/) décrivent chaque section.
+
+![Concepteur intégré](../assets/screenshots/designer.jpg)
+
+---
+
+## Dépôts git
+
+Intégrez des dépôts Git pour mettre vos formulaires et vos playbooks sous contrôle de version.
+
+![Dépôts git](../assets/screenshots/git.jpg)
+
+---
+
+## Éditeur de dépôt git
+
+Modifiez et configurez les paramètres d'intégration des dépôts Git.
+
+![Éditeur de dépôt git](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/fr/_introduction/gui/forms-and-jobs.md b/i18n/fr/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..51c70d8
--- /dev/null
+++ b/i18n/fr/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formulaires et jobs
+parent: Visite de l'interface
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formulaires et jobs
+{: .no_toc }
+
+La connexion, le tableau de bord, remplir un formulaire et suivre ses jobs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Connexion
+
+La page d'authentification des utilisateurs, avec la prise en charge de l'authentification locale, LDAP, Entra ID et OIDC.
+
+![Connexion](../assets/screenshots/login.jpg)
+
+---
+
+## Le tableau de bord
+
+Le tableau de bord principal affiche tous les formulaires disponibles, rangés par catégorie.
+
+![Tableau de bord](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Un formulaire
+
+Un exemple de formulaire avec des sources de données externes et des champs dynamiques.
+
+![Exemple de formulaire](../assets/screenshots/form.jpg)
+
+---
+
+## Aperçu JSON du formulaire
+
+Prévisualisez le contenu JSON et les variables supplémentaires transmis à Ansible avant de lancer le job.
+
+![Aperçu JSON du formulaire](../assets/screenshots/form-json.jpg)
+
+---
+
+## Job en cours
+
+L'exécution en temps réel d'un playbook Ansible, avec la sortie en direct.
+
+![Job en cours](../assets/screenshots/run.jpg)
+
+---
+
+## Sortie du job
+
+La sortie complète d'un playbook Ansible exécuté.
+
+![Sortie du job](../assets/screenshots/job-output.jpg)
+
+---
+
+## Journal des jobs
+
+Tous les jobs avec leur statut et leurs horaires, filtrés par statut depuis le menu de gauche.
+
+![Journal des jobs](../assets/screenshots/job-log.jpg)
+
+---
+
+## Multi-étapes
+
+Un job multi-étapes, avec la sortie de chaque étape sous le job principal. Les formulaires multi-étapes sont obsolètes depuis la 7 : un
+[workflow](../workflows/) enchaîne à la place playbooks, modèles et approbations.
+
+![Formulaire multi-étapes](../assets/screenshots/multistep.jpg)
+
+---
+
+## Planifications
+
+Planifiez l'exécution de formulaires à des heures ou à des intervalles précis. Les [exemples cron](../faq.html#which-cron-expressions-can-i-use) listent les
+expressions courantes et expliquent dans quel fuseau horaire une planification s'exécute.
+
+![Planifications](../assets/screenshots/schedules.jpg)
diff --git a/i18n/fr/_introduction/gui/index.md b/i18n/fr/_introduction/gui/index.md
new file mode 100644
index 0000000..3bbdb44
--- /dev/null
+++ b/i18n/fr/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Visite de l'interface
+nav_order: 3
+has_children: true
+has_toc: false
+description: Captures d'écran et visite de l'interface graphique
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Visite de l'interface
+{: .no_toc }
+
+Une visite en images de l'interface web d'AnsibleForms, du tableau de bord aux fonctions d'administration avancées.
+{: .fs-6 .fw-300 }
+
+---
+
+Pour chaque utilisateur et chaque administrateur : les écrans de l'interface web, regroupés selon ce que vous en faites.
+
+---
+
+## Dans cette section
+
+Chaque groupe d'écrans a sa propre page :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Formulaires et jobs](forms-and-jobs.html) | La connexion, le tableau de bord, remplir un formulaire et suivre ses jobs |
+| [Concepteur et git](designer-and-git.html) | Modifier des formulaires et les garder dans git |
+| [Administration](administration.html) | Le menu Paramètres : le système, son apparence, les accès, les connexions et les journaux |
+| [Paramètres personnels](personal-settings.html) | Votre profil et le thème sombre |
diff --git a/i18n/fr/_introduction/gui/personal-settings.md b/i18n/fr/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..3c88beb
--- /dev/null
+++ b/i18n/fr/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Paramètres personnels
+parent: Visite de l'interface
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Paramètres personnels
+{: .no_toc }
+
+Votre profil et le thème sombre
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Profil utilisateur
+
+Votre compte, vos préférences, votre mot de passe, vos permissions et vos jetons d'API.
+
+Voir [Votre profil](../profile).
+
+![Profil utilisateur](../assets/screenshots/profile.jpg)
+
+---
+
+## Mode sombre
+
+AnsibleForms propose un mode sombre pour moins fatiguer les yeux.
+
+![Mode sombre](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/fr/_introduction/how-it-works.md b/i18n/fr/_introduction/how-it-works.md
new file mode 100644
index 0000000..8c78234
--- /dev/null
+++ b/i18n/fr/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Comment ça marche
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Comment ça marche
+{: .no_toc }
+
+Les éléments d'une installation, ce qui se passe lors d'un lancement, et où les données sont conservées
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Architecture
+
+AnsibleForms est un serveur Node.js qui sert l'application web et une API REST, adossé à une base de données MySQL. Il lit les formulaires
+depuis des fichiers YAML et n'exécute rien lui-même : il confie chaque job à un [runner](runners.html). Un playbook part vers l'un de vos conteneurs RTE
+(runtime environment, environnement d'exécution), qui exécute `ansible-playbook`, et un modèle ou un job part vers AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins :
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Architecture d'AnsibleForms</title>
+<desc id="afd-desc">Le navigateur et un client MCP optionnel communiquent avec le serveur AnsibleForms. Le serveur stocke ses données dans MySQL et dans le dossier persistant, et se connecte aux sources de données, aux coffres de secrets, aux dépôts git, aux fournisseurs de connexion, aux canaux de notification, aux serveurs syslog et à un fournisseur de modèles optionnel. Ses runners confient chaque playbook à l'un d'un ou plusieurs conteneurs RTE, chacun via un WebSocket, qui exécutent ansible-playbook et renvoient la sortie au serveur, et chaque modèle ou job à AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Navigateur</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">formulaires, concepteur,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">jobs, chat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">Client MCP</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">optionnel</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">Serveur AnsibleForms</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Application web, API REST</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formulaires, expressions</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflows, planifications</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">Serveur MCP (optionnel)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runners</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">confient chaque job à son runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Sources de données</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">bases, API REST, fichiers</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Coffres de secrets</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Dépôts git</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">formulaires, playbooks, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Authentification</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Canaux de notification</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">mail, Slack, Teams, webhooks</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Serveurs syslog</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">le journal, la piste d'audit</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Fournisseur de modèles</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">optionnel, assistant de chat</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Dossier persistant</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, formulaires, playbooks</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">jobs, utilisateurs,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">identifiants</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">Conteneurs RTE</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">lancent ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbooks,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">modèles, jobs</text>
+</svg>
+</div>
+
+Chaque composant du schéma a son propre rôle :
+
+| Composant | Rôle |
+|---|---|
+| **Navigateur** | L'application web Vue : les formulaires, le [Concepteur](gui/designer-and-git.html), l'historique des jobs et les paramètres |
+| **Serveur AnsibleForms** | Évalue les formulaires, enregistre les jobs, exécute les workflows et les planifications, confie chaque job à son runner et le suit, et sert l'[API REST](api/) |
+| **Runners** | Là où les jobs s'exécutent, ajoutés sous **Connexions > Runners** : un formulaire en nomme un avec `runner: <name>`, ou utilise le runner par défaut de son type (voir [Runners](runners.html)) |
+| **Conteneurs RTE** | Un ou plusieurs conteneurs d'environnement d'exécution, le même serveur démarré avec `AF_ROLE=rte` : chacun exécute `ansible-playbook` pour les [formulaires ansible](forms/ansible.html), avec les bibliothèques python et les collections de son image, et renvoie la sortie et le statut final au serveur via un WebSocket, sans identifiants de base de données (voir [Comment le RTE s'exécute](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Les runners des modèles et des jobs : les [formulaires AWX](forms/awx.html) lancent un modèle de job ou de workflow, les formulaires [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) et [Jenkins](forms/jenkins.html) lancent l'un de leurs jobs, et le serveur suit sa sortie |
+| **MySQL / MariaDB** | Contient les jobs et leur sortie, les utilisateurs, les identifiants et les connexions ; seul le serveur la lit et l'écrit |
+| **Dossier persistant** | Contient `config.yaml`, les fichiers de formulaires, les playbooks, les journaux et les sauvegardes |
+| **Sources de données** | Alimentent les champs : [requêtes de base de données](formfields/enum.html), [API REST](expressions/rest-apis.html), fichiers et [autres fonctions](expressions/remote.html) |
+| **Coffres de secrets** | Fournissent l'utilisateur et le mot de passe d'un identifiant au moment de son utilisation, voir [Coffres de secrets](secret-stores/) |
+| **Dépôts git** | Gardent les formulaires, les playbooks et `config.yaml` sous contrôle de version |
+| **Fournisseurs de connexion** | Connectent les utilisateurs : [LDAP, Entra ID et OIDC](authentication/), en plus des utilisateurs locaux |
+| **Canaux de notification** | Transportent les [notifications](forms/notifications.html) et les demandes d'approbation : [mail, Slack, Microsoft Teams, Telegram ou un webhook](notification-channels.html) |
+| **Serveurs syslog** | Reçoivent le journal et la piste d'audit au fur et à mesure de leur écriture, voir [Syslog](production/logs.html#syslog) |
+| **Client MCP, chat** | Optionnels, tous deux désactivés par défaut : le [serveur MCP](mcp/) et l'[assistant de chat](chat/), qui a besoin d'un fournisseur de modèles |
+
+Par défaut, un seul conteneur fait tourner ensemble le serveur, l'application web et le travail en arrière-plan, à côté d'un RTE. Pour plusieurs nœuds d'application derrière un
+répartiteur de charge, un worker qui s'occupe du travail en arrière-plan, et davantage de RTE, voir [Mise à l'échelle](production/scaling.html).
+
+### Technologies utilisées
+
+Le serveur et l'interface web reposent sur ces composants :
+
+| Élément | Technologie |
+|---|---|
+| **Serveur** | Node.js et Express |
+| **Base de données** | MySQL ou MariaDB |
+| **Interface web** | Vue 3, avec Bootstrap 5 et Font Awesome |
+
+---
+
+## Ce qui se passe quand vous lancez un formulaire
+
+Un lancement passe par les mêmes étapes, qu'il vienne du navigateur ou de l'[API REST](api/jobs.html) :
+
+1. **Chargement** : le serveur n'envoie que les formulaires que les [rôles](config/roles.html) de l'utilisateur autorisent, et évalue les expressions côté serveur
+2. **Envoi** : le navigateur transforme les valeurs des champs en extravars et les poste sur `POST /api/v2/job`
+3. **Vérification** : le serveur recharge le formulaire pour les rôles de l'utilisateur et, avec la [validation au lancement](launch-validation/) activée, vérifie les valeurs
+4. **Enregistrement** : le job est stocké avec le statut `running`, et son id est ajouté aux extravars sous `__jobid__`
+5. **Approbation** : un formulaire avec un point d'[`approval`](forms/approval.html) attend qu'un approbateur accepte le job
+6. **Identifiants** : pour un playbook, l'application (jamais le RTE) lit les identifiants du formulaire dans la base de données ou dans un [coffre de secrets](secret-stores/)
+7. **Exécution** : le job part vers son runner, celui que le formulaire nomme avec `runner:` ou celui par défaut de son type. Pour un playbook, l'application envoie le job à son
+   RTE via le WebSocket du RTE, avec ses identifiants scellés pour lui, et le RTE exécute `ansible-playbook` (voir [Comment le RTE s'exécute](rte/#how-the-rte-runs)),
+   et AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins exécute un modèle ou un job. Un [workflow](workflows/) exécute ses nœuds, chacun comme
+   un job à part sur son propre runner
+8. **Suivi** : le serveur enregistre la sortie dans la base de données au fur et à mesure qu'elle arrive, envoyée par le RTE via son socket pour un playbook, ou lue depuis les
+   autres runners. La page du formulaire relit le job toutes les deux secondes, et la page Jobs le suit en direct à mesure que le serveur
+   annonce chaque changement
+9. **Fin** : le job reçoit son statut final, et ses [`notifications`](forms/notifications.html) partent par mail et vers ses
+   [canaux de notification](notification-channels.html) quand le formulaire les demande
+
+---
+
+## Où les choses sont stockées
+
+AnsibleForms conserve son état à deux endroits : la base de données MySQL et le dossier persistant. Sauvegardez les deux.
+
+### Dans la base de données
+{: .no_toc }
+
+La base de données, `AnsibleForms`, est créée au premier démarrage (sauf si `ALLOW_SCHEMA_CREATION` vaut `0`) et contient :
+
+* les jobs, leurs extravars et leur sortie, les planifications et les jobs enregistrés
+* les utilisateurs locaux, les groupes et les jetons d'API
+* les identifiants, chiffrés avec `ENCRYPTION_SECRET`, et les connexions aux coffres de secrets
+* les runners, les canaux de notification (mail compris), les serveurs syslog, et les paramètres LDAP, SSO, des dépôts et de l'assistant de chat
+* le journal d'audit
+
+### Dans le dossier persistant
+{: .no_toc }
+
+C'est `/app/dist/persistent` dans l'image et `server/persistent` depuis les sources ; chaque chemin a sa propre [variable](customization/paths.html) :
+
+| Chemin par défaut | Variable | Contenu |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | Les catégories, les rôles et les constantes |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | Les fichiers de formulaires, `.yaml` ou `.yml`, dans des sous-dossiers si vous le souhaitez |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | Les playbooks des formulaires `ansible`, et leur répertoire de travail |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Les clones des dépôts git |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | Les copies que le Concepteur fait avant d'enregistrer |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | Les sauvegardes de la base de données |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | Les fichiers téléversés via les champs `file` |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` et `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | Le certificat et la clé, quand `HTTPS` vaut `1` |
+| `.env` | | Les variables d'environnement enregistrées depuis les pages de paramètres (sauf si `ALLOW_ENV_EDIT` vaut `0`) |
+
+La clé SSH générée se trouve dans [`HOME_PATH`](customization/paths.html#env_HOME_PATH), hors du dossier persistant par défaut.
diff --git a/i18n/fr/_introduction/prerequisites.md b/i18n/fr/_introduction/prerequisites.md
new file mode 100644
index 0000000..7883fc2
--- /dev/null
+++ b/i18n/fr/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Prérequis
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Prérequis
+{: .no_toc }
+
+Ce qu'il vous faut avant d'installer AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Environnement d'exécution
+
+AnsibleForms tourne dans un conteneur, sous forme de services systemd sur le serveur lui-même ou, pour ceux qui le construisent eux-mêmes, comme une application Node.js :
+
+| Installation | Il vous faut |
+|---|---|
+| [Installateur](installation/installer.html) | Linux sur amd64 ou arm64, `curl` ou `wget` et `sha256sum`, et ce dont a besoin le moteur sur lequel il installe (voir plus bas) |
+| [Natif](installation/native.html) | Root, systemd et un Linux pris en charge (Ubuntu, Debian, RHEL et ses recompilations, SUSE) ; l'installateur installe le reste |
+| [Docker](installation/docker.html) | Docker ou Podman, et votre propre serveur MySQL |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose ou podman-compose ; le projet démarre aussi MySQL |
+| [Kubernetes](installation/kubernetes.html) | Un cluster, Helm 3 et une StorageClass (ou des PersistentVolumes créés à l'avance) |
+| [Depuis les sources](installation/from-source.html) | Node.js 26 (24 au minimum) avec npm, Git, et Ansible pour le processus RTE qui exécute les playbooks |
+
+L'image de l'application, `ghcr.io/ansibleforms/ansibleforms`, contient Node.js et les outils que le serveur appelle (git, ssh, le client mariadb et
+ytt), mais ni Python ni Ansible. Les playbooks s'exécutent sur un RTE (runtime environment), un second conteneur basé sur
+`ghcr.io/ansibleforms/ansibleforms-rte-full`, ou sur une image que vous construisez à partir de `ansibleforms-rte-core` (voir [Mise à l'échelle](rte/)).
+Les formulaires qui ne font que lancer des modèles sur AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins n'ont besoin d'aucun RTE.
+
+---
+
+## Base de données
+
+AnsibleForms stocke ses jobs, ses utilisateurs, ses identifiants et ses connexions dans MySQL 8 ou ultérieur, ou dans MariaDB.
+
+Au premier démarrage, il crée lui-même le schéma `AnsibleForms`. Donnez-lui un utilisateur de base de données dédié, avec des droits sur ce seul schéma,
+pas root :
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+C'est tout ce dont il a besoin : il crée et met à jour le schéma, fait ses sauvegardes et, avec plusieurs workers, termine la session d'un worker mort.
+La page **Statut** et le journal avertissent quand l'utilisateur a des droits sur toutes les bases de données. Les nœuds d'application et les workers se connectent avec cet
+utilisateur. Un RTE en mode socket (sortant ou entrant, voir [Modes](rte/modes.html)) ne détient aucun identifiant de base de données : seul un RTE en mode
+base de données, obsolète depuis la 7.3.0, s'y connecte aussi. Pour créer le schéma vous-même, mettez [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) à `0`.
+Le projet Docker Compose et le chart Helm (qui utilise `mysql:8.4`) démarrent une base de données pour vous.
+
+---
+
+## Dimensionnement
+
+Il n'y a pas d'exigences mesurées : la charge dépend surtout du nombre de jobs qui tournent en même temps et de la quantité de sortie qu'ils écrivent.
+Les ressources par défaut du chart Helm sont un point de départ raisonnable pour une petite équipe :
+
+| Composant | Requests | Limits | Volume |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB de mémoire | 4 CPU, 4 GiB de mémoire | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB de mémoire | 2 CPU, 2 GiB de mémoire | 10 GiB |
+
+Le conteneur de l'application n'exécute aucun playbook. Chaque playbook est un processus `ansible-playbook`, avec ses forks, sur un RTE : dimensionnez le CPU et
+la mémoire de chaque RTE pour les playbooks qu'il exécute à la fois, au plus [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (`10` par défaut), et ajoutez
+des RTE pour en exécuter davantage. Les jobs qui tournent sur AWX, AAP, Ascender ou les autres runners de modèles coûtent peu à AnsibleForms.
+
+Par défaut, la sortie des jobs est conservée indéfiniment dans la base de données. Définissez [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+sur une instance chargée pour éviter que la base de données ne grossisse sans limite.
+
+---
+
+## Réseau
+
+L'application et chaque RTE écoutent sur leur propre port, et ouvrent des connexions sortantes vers les systèmes qu'utilisent vos formulaires et vos paramètres.
+
+### Entrant
+{: .no_toc }
+
+Le serveur écoute sur le port `8000` ([`PORT`](customization/server.html#env_PORT)), en HTTP ou, avec
+[`HTTPS`](customization/server.html#env_HTTPS) à `1`, en HTTPS. Le projet Docker Compose le publie sur le port 443,
+et le chart Helm l'expose via un service ou un ingress. Un RTE écoute aussi sur son propre `PORT`, mais seule l'application l'appelle :
+gardez-le hors du réseau public. Un RTE sortant n'a besoin d'aucun port entrant : c'est lui qui appelle l'application sur le port de celle-ci.
+
+### Sortant
+{: .no_toc }
+
+Ouvrez les connexions d'AnsibleForms vers les systèmes que vous utilisez :
+
+| Destination | Utilisé pour |
+|---|---|
+| MySQL / MariaDB | La base de données d'AnsibleForms (`DB_HOST`, `DB_PORT`, `3306` par défaut) |
+| Le RTE | Appeler un RTE entrant à l'adresse de son runner via un WebSocket, ou appeler un RTE en mode base de données à son [`RTE_URL`](customization/server.html#env_RTE_URL), qui se connecte alors lui-même à MySQL ; un RTE sortant appelle l'application à la place (voir [Modes](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Lancer et suivre des modèles et des jobs sur les [runners](runners.html), via leur API HTTP(S) |
+| Les hôtes gérés | Les playbooks s'y connectent depuis le RTE, par exemple en SSH ou en WinRM |
+| LDAP, Entra ID, OIDC | La connexion avec des comptes d'annuaire ou d'authentification unique |
+| Serveurs Git | Cloner et mettre à jour les dépôts, en HTTPS ou en SSH |
+| API REST et bases de données | Les sources de données des expressions et des requêtes de vos formulaires |
+| HashiCorp Vault, CyberArk | Lire des identifiants depuis un [coffre de secrets](secret-stores/) |
+| Serveurs de messagerie, Slack, Teams, Telegram, webhooks | Les notifications de jobs et les demandes d'approbation, via les [canaux de notification](notification-channels.html) |
+| Fournisseur de modèles | L'[assistant de chat](chat/), seulement quand il est activé |
+
+Pour limiter les hôtes que les fonctions REST des expressions peuvent appeler, voir
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) et
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Navigateur
+
+L'application web est conçue pour les navigateurs récents : Chrome ou Edge 111, Firefox 114, Safari 16.4 ou plus récent.
+Les navigateurs plus anciens ne sont pas pris en charge.
+
+---
+
+## Mise à l'échelle
+
+Par défaut, un seul conteneur AnsibleForms fait tourner ensemble l'application web et le travail en arrière-plan, à côté d'un RTE.
+
+Pour servir plus d'utilisateurs, faites tourner plusieurs nœuds d'application derrière un répartiteur de charge (`AF_ROLE=app`) à côté d'un worker (`AF_ROLE=worker`), qui exécute
+les planifications, les sauvegardes et le reste du travail en arrière-plan ; un seul worker travaille à la fois, et un second attend pour prendre le relais. Ils partagent
+la base de données, le dossier persistant, `ACCESS_TOKEN_SECRET` et `ENCRYPTION_SECRET`. Voir [Mise à l'échelle](production/scaling.html). Ajoutez des
+RTE pour exécuter plus de playbooks à la fois : voir [Plusieurs RTE](rte/several.html).
diff --git a/i18n/fr/_introduction/what-is-ansibleforms.md b/i18n/fr/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..473d6a9
--- /dev/null
+++ b/i18n/fr/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Qu'est-ce qu'AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Qu'est-ce qu'AnsibleForms
+{: .no_toc }
+
+Des formulaires en libre-service devant Ansible et AWX, et quand vous en avez besoin
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ce qu'il fait
+
+AnsibleForms place un formulaire web devant un playbook, un workflow, ou un modèle ou un job sur AWX, AAP, Ascender, Semaphore, Rundeck
+ou Jenkins, pour que chacun puisse lancer de l'automatisation sans passer par la ligne de commande.
+
+Un formulaire recueille les saisies, les vérifie, les met en forme en extravars et lance le job. Les données d'un formulaire peuvent venir de bases de données,
+d'API REST, de fichiers et d'autres champs, et chaque lancement est enregistré dans l'historique des jobs avec sa sortie.
+
+---
+
+## Usages courants
+
+Les équipes utilisent AnsibleForms pour confier l'automatisation de routine aux personnes qui la demandent :
+
+* **Demandes en libre-service** : une machine virtuelle, un volume de stockage, un partage ou un compte utilisateur, rempli par le demandeur
+* **Opérations encadrées** : des actions avec des points d'approbation, pour qu'une deuxième personne valide avant que le job ne s'exécute
+* **Choix pilotés par les données** : des listes déroulantes alimentées par une CMDB, une base de données ou une API REST, en cascade d'un champ au suivant
+* **Jobs récurrents** : des formulaires exécutés plus tard ou selon une planification cron, avec les mêmes saisies validées à chaque fois
+* **Automatisation pour les outils et les agents** : l'API REST, le serveur MCP et l'assistant de chat lancent les mêmes formulaires
+
+---
+
+## AnsibleForms ou les surveys d'AWX ?
+
+AWX, AAP et Ascender ont leurs propres surveys. Le bon choix dépend de ce dont ont besoin les personnes qui lancent les jobs.
+
+Un **survey** suffit quand :
+
+* les questions sont fixes : du texte, des nombres, des mots de passe et des choix dans une liste statique
+* les utilisateurs travaillent déjà dans AWX, AAP ou Ascender, et ses permissions leur conviennent
+* vous ne voulez pas faire tourner et maintenir une application et une base de données de plus
+
+**AnsibleForms** est utile quand :
+
+* les choix viennent d'ailleurs : une base de données, une API REST, un fichier ou un autre champ (listes déroulantes en cascade)
+* les saisies ont besoin de validation, de structure (listes, objets imbriqués) ou de valeurs calculées avant d'arriver au playbook
+* les jobs ont besoin de points d'approbation, de planification, ou d'un workflow qui enchaîne playbooks, modèles et approbations depuis un seul formulaire
+* les utilisateurs ne doivent pas voir AWX du tout, ou vous exécutez aussi des playbooks sans AWX
+
+AnsibleForms lance les modèles d'AWX, AAP et Ascender, les deux fonctionnent donc ensemble : les formulaires recueillent et mettent en forme les saisies, et
+AWX continue d'exécuter les jobs.
+
+---
+
+## Pour aller plus loin
+
+Le reste de cette section explique les rouages avant l'installation :
+
+| Page | Ce qu'elle couvre |
+|---|---|
+| [Comment ça marche](how-it-works.html) | L'architecture, les étapes d'un lancement, et où les données sont conservées |
+| [Visite de l'interface](gui/) | Des captures de chaque écran, de la connexion aux pages d'administration |
+| [Concepts](concepts.html) | Les termes utilisés dans cette documentation |
+| [Prérequis](prerequisites.html) | Ce qu'il vous faut avant d'installer |
diff --git a/i18n/fr/_reference/faq.md b/i18n/fr/_reference/faq.md
new file mode 100644
index 0000000..278804c
--- /dev/null
+++ b/i18n/fr/_reference/faq.md
@@ -0,0 +1,1279 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Questions fréquentes
+{: .no_toc }
+
+Questions et réponses courantes sur AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Premiers pas
+
+### Topologie de déploiement : un conteneur ou plusieurs nœuds
+
+Par défaut, un conteneur AnsibleForms fait tourner l'application web et le travail en arrière-plan dans un seul processus, à côté d'un conteneur RTE qui
+exécute les playbooks. Lancez-le avec une politique de redémarrage (par exemple `restart: unless-stopped` dans Docker), et sauvegardez à la fois la base de données et
+le volume persistant.
+
+Pour faire tourner plusieurs réplicas derrière un répartiteur de charge, séparez le processus avec `AF_ROLE` :
+
+- les nœuds `app` servent l'interface web et l'API : faites-en tourner autant que vous voulez, chacun avec le même `ACCESS_TOKEN_SECRET`
+- un `worker` s'occupe du travail en arrière-plan : le schéma et ses mises à niveau, le seed de configuration, les planifications, la sauvegarde nocturne, les synchronisations
+  des dépôts et les nettoyages. Un seul worker travaille à la fois, en détenant un verrou de base de données ; un second attend et prend le relais quand le premier s'arrête
+- les conteneurs `rte` exécutent les playbooks : faites-en tourner davantage pour exécuter plus de playbooks à la fois
+
+Les nœuds d'application et le worker partagent la base de données, le volume persistant et `ENCRYPTION_SECRET`. Un RTE en mode socket (sortant ou
+entrant, voir [Modes](rte/modes.html)) n'a besoin ni de la base de données ni d'`ENCRYPTION_SECRET`. L'assistant de chat a besoin de sessions persistantes (sticky sessions), et
+chaque nœud garde son propre journal. Voir [Mise à l'échelle](production/scaling.html) et la configuration
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Gestion des formulaires sur plusieurs dépôts
+
+Les formulaires de chaque dépôt Git qui a **Utiliser pour les formulaires ?** activé sont fusionnés automatiquement ; en cas de noms de formulaires en double, le premier
+l'emporte et un avertissement est journalisé. Ne gardez `config.yaml` que dans un seul dépôt. Voir [Dépôts git](repositories/).
+
+### À propos des dépôts
+
+AnsibleForms clone et met à jour les dépôts Git sous le chemin des dépôts (`REPO_PATH`), gérés sous **Paramètres > Dépôts**.
+Des interrupteurs sur chaque dépôt définissent ce qu'il contient : configuration, formulaires, playbooks ou fichiers de variables. Voir [Dépôts git](repositories/).
+
+### Validation VS Code des fichiers de formulaires
+
+Ajoutez un en-tête de schéma à vos fichiers YAML de formulaires pour obtenir la validation en direct et l'autocomplétion dans VS Code.
+
+Installez l'[extension YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) et ajoutez ce commentaire comme **première ligne** de chaque fichier de formulaire :
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Cela fonctionne aussi bien pour les fichiers à un seul formulaire (un dict YAML) que pour les fichiers à plusieurs formulaires (une liste YAML) :
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code signale les propriétés inconnues, les champs obligatoires manquants et les types incorrects pendant la saisie.
+
+---
+
+## Gestion des jobs
+
+### Relance d'un job avec des données préremplies
+
+Le bouton de relance ouvre le formulaire prérempli avec les valeurs du job précédent ; les champs mot de passe ne sont jamais stockés.
+Il nécessite l'option de rôle `allowJobRelaunch`, et un formulaire peut le désactiver avec `allowRelaunch: false`. Voir [Relancer un job](jobs/actions.html#relaunch-a-job).
+
+### Fichier journal du job
+
+Suivez la progression via un fichier journal propre au job (v6.1.2).
+
+AnsibleForms peut afficher un **fichier journal propre au job** à côté de la sortie Ansible. Cela permet de suivre la progression de modules personnalisés de longue durée qui, sinon, ne donneraient aucun retour visible pendant l'exécution.
+
+{: .note }
+> Cette fonctionnalité ne marche que pour les playbooks qui s'exécutent sur un RTE. Les modèles et les jobs sur AWX, AAP, Ascender, Semaphore, Rundeck ou
+> Jenkins n'ont pas de fichier journal.
+
+**Fonctionnement :**
+- Pendant l'exécution d'un job, le RTE surveille un fichier journal à un chemin connu dans le dossier du playbook
+- Toutes les deux secondes, quand le fichier a changé, le RTE copie son contenu dans le job, et une dernière fois quand le playbook se termine
+- Le fichier journal s'affiche dans une section **Fichier journal** de la sortie du job, numérotée comme les lignes de la sortie : l'horodatage et le niveau d'une ligne (ERROR, WARNING, INFO, DEBUG) sont lus et colorés comme ceux de la sortie, et les couleurs ANSI sont prises en charge
+
+**Convention de chemin du fichier journal :**
+
+Le fichier journal doit être écrit à ce chemin :
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms transmet `__jobid__` automatiquement**, vous pouvez donc construire le chemin dans votre playbook sans aucune configuration supplémentaire :
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Transmettez cette variable à tout rôle ou module personnalisé qui doit écrire sa progression dans le fichier.
+
+**Responsabilités du développeur du playbook ou du module :**
+- **Créer** le fichier journal (et son répertoire `.joblogs/`) au début de l'opération
+- **Écrire** des messages de progression parlants au fil de l'opération
+
+Le RTE supprime le fichier une fois que le playbook se termine et que le dernier contenu est stocké sur le job.
+
+**Les couleurs ANSI sont prises en charge.**  
+Les codes d'échappement ANSI standard (par exemple `\033[92m` pour le vert et `\033[91m` pour le rouge) de vos messages de journal s'affichent en couleur dans l'interface, si bien que les états de succès, d'avertissement et d'erreur se distinguent d'un coup d'œil.
+
+**Cas d'usage typique :**  
+Un module Ansible personnalisé en Python qui effectue une longue suite d'appels API ou d'opérations sur des données (par exemple un workflow de reprise SnapMirror) peut ajouter une ligne par étape au fichier journal. Un opérateur qui suit le job dans AnsibleForms voit alors la progression en direct dans la section Fichier journal à mesure que la page du job suit le job.
+
+### Jobid
+
+Transmettre l'ID du job courant.
+
+AnsibleForms envoie automatiquement l'ID du job courant dans les extravars sous `__jobid__` ; aucune configuration n'est nécessaire.
+
+### Userinfo
+
+Transmettre l'utilisateur courant.
+
+AnsibleForms envoie automatiquement les informations de l'utilisateur dans les extravars sous `ansibleforms_user` ; aucune configuration n'est nécessaire.
+
+Vous pouvez choisir la quantité d'informations envoyées. `EXTRAVARS_USER_FIELDS` accepte une liste de clés de premier niveau séparées par des virgules
+(`username,email,type`), ou `none` pour ne rien envoyer ; un formulaire peut la remplacer par sa propre propriété `userExtravars`.
+Par défaut, c'est l'objet entier, comme avant. Le `__user__` côté formulaire décrit plus bas vient du jeton de connexion et n'est jamais concerné.
+
+### Userinfo dans le formulaire
+
+Accéder aux informations de l'utilisateur courant dans le formulaire (v4.0.2).
+
+Le champ `__user__` est ajouté automatiquement au formulaire et peut être référencé dans les expressions :
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Champs de formulaire
+
+### Listes déroulantes en cascade
+
+Créer des listes déroulantes en cascade.
+
+Les champs `enum` (listes déroulantes) peuvent contenir des placeholders dans leur propriété `query` ou `expression`, au format `$(another_field)` ou `$(another_field[0].name)`.  
+Dès que le champ référencé change, le champ qui le référence est réévalué, ce qui donne des listes déroulantes dynamiques en cascade.  
+L'application web cliente réévalue les champs toutes les 100 ms ; avec les processeurs actuels et le moteur Chromium, l'expérience est fluide.
+
+{: .note }
+> Une référence à un autre champ enum renvoie les valeurs sélectionnées, **pas** la liste déroulante complète. Utilisez la propriété `placeholderColumn` ou la notation pointée comme `$(city.name)`.  
+> **Nouveau en v4.0.20** : mettre placeholderColumn à "*" renvoie l'enregistrement entier au lieu d'une seule colonne.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Placeholders de champ
+
+Référencer la valeur d'un autre champ.
+
+Les placeholders sont des références à d'autres champs du formulaire.  
+Un placeholder a toujours le format `$(reference)`, et les expressions comme les requêtes peuvent contenir des placeholders.  
+Un placeholder qui pointe vers un champ simple (text, number, password) contient la valeur de ce champ.  
+Un placeholder qui pointe vers un champ enum basé sur des objets doit utiliser soit la propriété `placeholderColumn`, soit la notation pointée comme `$(city.name)`.  
+Un placeholder qui pointe vers un champ expression renvoie l'objet complet, ou vous pouvez utiliser une référence avancée, de type JavaScript, comme `$(myarray[0].name)`.
+
+{: .important }
+> Le placeholder est remplacé **avant** l'évaluation de l'expression. Si vous attendez une chaîne comme résultat, vous devez l'entourer de guillemets.  
+> **Nouveau en v4.0.20** : mettre placeholderColumn à "*" renvoie l'enregistrement entier au lieu d'une seule colonne.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Masquer un champ
+
+Masquer un champ.
+
+Masquez un champ avec la propriété de champ `hide`, ou affichez-le et masquez-le dynamiquement avec les propriétés de champ `dependencies` et `dependencyFn`.
+
+### Regrouper des champs
+
+Regrouper des champs dans un bloc.
+
+Utilisez la propriété de champ `group`. Les champs qui ont le même nom de groupe sont regroupés dans un bloc.
+
+### Validation d'un champ
+
+Valider un champ.
+
+Utilisez les propriétés de validation des champs, comme `regex`, `minValue` et `notIn`.
+
+### Valeur par défaut d'un enum
+
+Valeur par défaut d'un enum.
+
+La propriété de champ `default` définit une valeur par défaut, et sur les champs `enum` vous pouvez utiliser des valeurs comme `__auto__` pour sélectionner automatiquement le premier élément.
+
+Pour une valeur par défaut dynamique basée sur une expression, placez l'élément par défaut en tête de liste, comme dans l'exemple suivant.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Valeur par défaut par expression
+
+Valeur par défaut par expression.
+
+Pour les champs text, number ou date, la propriété `default` définit une valeur par défaut statique.
+
+Pour rendre la valeur par défaut dynamique, à partir d'une expression, utilisez l'une de ces deux propriétés :
+* `editable` : utilisez la propriété editable pour rendre un champ expression modifiable
+* `evalDefault` : utilisez la propriété evalDefault pour évaluer la valeur par défaut comme une expression
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Assistant et workflows
+
+### Quelle est la différence entre un assistant et un workflow ?
+
+Un **assistant** (wizard) et un **workflow** fonctionnent tous deux par étapes, mais ils agissent à des niveaux différents et peuvent être combinés.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Niveau** | Exécution | Formulaire / interface |
+| **Ce qu'il découpe** | Le job en nœuds qui s'exécutent l'un après l'autre, ou côte à côte | La saisie d'un formulaire en plusieurs pages |
+| **Résultat** | 1 job de workflow, avec un job par nœud (chacun avec son propre playbook ou modèle) | 1 job s'exécute à la fin |
+| **`type` du formulaire** | Doit être `workflow` | Fonctionne avec tous les types de formulaires sauf `subform` |
+| **Défini par** | Un [fichier de workflow](workflows/file.html) du concepteur (`workflow:`) | Une liste de références à des [sous-formulaires](forms/subform.html) (`wizard:`) |
+| **À utiliser quand** | « Fais A, puis B, puis C comme jobs séparés » | « Mon formulaire a trop de champs pour une seule page » |
+
+**À retenir :** un workflow concerne *ce qui s'exécute et dans quel ordre* ; `wizard` concerne *la façon dont l'utilisateur remplit le formulaire*.
+
+{: .note }
+> Le type de formulaire `multistep`, avec ses `steps`, assurait la partie exécution avant la 7. Il est obsolète depuis la 7 et supprimé en
+> 8 : un workflow fait tout ce que fait un multistep, voir [Formulaires multi-étapes](forms/multistep.html).
+
+#### Workflow seul
+{: .no_toc }
+
+Un formulaire `type: workflow` exécute l'un des workflows du concepteur. L'utilisateur remplit une seule page de champs et appuie sur Soumettre,
+et le workflow exécute ses nœuds, chacun avec les valeurs du formulaire comme variables supplémentaires :
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Assistant seul
+{: .no_toc }
+
+Un bloc `wizard:` sur un formulaire répartit la saisie sur plusieurs pages. Un **seul** job s'exécute à la fin : les extravars fusionnées de toutes les pages sont envoyées à un seul playbook, modèle ou workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Une page de relecture en lecture seule est ajoutée automatiquement comme dernière page de l'assistant ; vous ne la déclarez pas dans le YAML.
+
+#### Combinés (un assistant au-dessus d'un workflow)
+{: .no_toc }
+
+Un assistant peut se superposer à un formulaire workflow. L'utilisateur remplit les pages de l'assistant et appuie sur Soumettre, et **ensuite** le
+workflow démarre. En faisant correspondre le `defaultModel` d'une étape de l'assistant avec l'[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys)
+d'un nœud, vous pouvez diriger **une page de l'assistant vers un nœud** :
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+Et le workflow `provision-host`, dans un fichier de workflow du concepteur :
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` est une recherche à un seul niveau, utilisez donc un nom plat dans `defaultModel` (par exemple `defaultModel: basics`, et non `defaultModel: input.basics`) quand vous voulez qu'ils correspondent.
+
+Voir la [page Assistant](forms/wizard.html) pour la référence complète des propriétés.
+
+### Comment afficher ou sauter des étapes de l'assistant sous condition ?
+
+Utilisez `when:` pour **masquer** entièrement une étape, ou `optional: true` pour permettre à l'utilisateur de **sauter** une étape visible. Les deux sont indépendants et ne devraient généralement pas être combinés.
+
+#### `when:` : visibilité conditionnelle
+{: .no_toc }
+
+L'étape est masquée quand l'expression donne une valeur fausse. L'utilisateur ne la voit jamais, et ses valeurs ne sont pas recueillies. L'expression peut lire les étapes précédentes via `__parent__.<stepname>.<field>` :
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Seule la page qui correspond au `kind` choisi est affichée. Les étapes qui suivent une étape masquée sont renumérotées automatiquement.
+
+#### `optional: true` : permettre de sauter une étape visible
+{: .no_toc }
+
+L'étape est **toujours affichée** dans la barre des étapes, mais l'utilisateur peut appuyer sur **Suivant** sans la remplir, et **Soumettre** est permis même si la page n'a jamais été visitée ni complétée :
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+L'utilisateur peut ouvrir la page Advanced, la laisser vide, appuyer sur Suivant et passer directement à la page de relecture.
+
+{: .note }
+> `when:` contrôle la *visibilité* ; `optional:` contrôle *si la page doit être complétée*. Ne les combinez pas : pour faire disparaître une page, utilisez `when:` ; pour la garder visible mais facultative, utilisez `optional:`.
+
+### Comment référencer les valeurs d'une étape précédente de l'assistant ?
+
+Utilisez `$(__parent__.<stepname>.<field>)` dans n'importe quel champ d'une étape ultérieure.
+
+Le `name` d'une étape de l'assistant (par défaut, le nom de son `subform`) est l'espace de noms sous lequel ses valeurs sont exposées aux étapes suivantes :
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+C'est le même mécanisme `__parent__` qu'utilisent les sous-formulaires `list` et `yaml` ; voir [Comment accéder aux données du formulaire parent dans un sous-formulaire ?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Sécurité et identifiants
+
+### Identifiants
+
+Transmettre des identifiants.
+
+Les identifiants peuvent être transmis de plusieurs façons :
+* avec la propriété de champ `asCredential`  
+* avec la propriété de formulaire `credentials` (paires clé-valeur)
+* avec une extravar appelée `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Récupérer un mot de passe admin perdu
+
+Si vous avez perdu le mot de passe du compte local `admin` et qu'aucun autre utilisateur admin n'est disponible, utilisez l'option de récupération `REINIT_ADMIN`. **Ce n'est pas un contournement de l'authentification à l'exécution** : elle force seulement une réinitialisation unique du compte admin local au démarrage, après quoi l'authentification normale s'applique.
+
+**Fonctionnement**
+
+Quand `REINIT_ADMIN=1` est défini au démarrage, AnsibleForms :
+
+1. S'assure que le groupe `admins` existe (en le créant s'il manque).
+2. Cherche l'utilisateur admin local (nom d'utilisateur par défaut `admin`, remplacé par `ADMIN_USERNAME`).
+3. S'il existe, réinitialise son mot de passe à la valeur de `ADMIN_PASSWORD` et le rattache au groupe `admins`.
+4. S'il n'existe pas, le crée (comme sur une nouvelle installation).
+5. Journalise l'action de façon bien visible dans les journaux.
+
+**Étapes**
+
+1. Arrêtez AnsibleForms.
+2. Définissez les variables d'environnement (utilisez un mot de passe robuste) :
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   Dans Docker Compose, ajoutez-les au bloc `environment:` du service AnsibleForms.
+3. Démarrez AnsibleForms et guettez dans les journaux une ligne comme :
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Connectez-vous avec `admin` / `YourNewStrongPasswordHere`.
+5. **Supprimez `REINIT_ADMIN` (ou remettez-le à `0`)** et redémarrez, pour que les redémarrages suivants ne réinitialisent plus le mot de passe admin.
+
+**Remarques**
+
+- Si vous étiez bloqué parce que LDAP était la seule méthode de connexion configurée et qu'elle a échoué, le compte local `admin` récupéré utilise toujours l'authentification par la base de données locale, ce qui suffit pour se connecter et corriger LDAP.
+- L'ancienne variable d'environnement `ENABLE_BYPASS` a été supprimée. Elle permettait de se connecter en admin avec n'importe quel mot de passe et était dangereuse à laisser activée. `REINIT_ADMIN` ne fait que réinitialiser le mot de passe ; l'authentification normale s'applique ensuite.
+- `REINIT_ADMIN` n'invalide pas les sessions ni les jetons existants ; seuls le hash du mot de passe et l'appartenance au groupe changent.
+
+### Restreindre les destinations des helpers REST (listes d'autorisation et de refus)
+
+Les helpers `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` et `fn.fnRestJwtSecure` peuvent être appelés depuis les propriétés `expression` des formulaires pour récupérer des données en HTTP. Par défaut, les auteurs d'expressions peuvent viser **n'importe quelle** URL que l'hôte d'AnsibleForms peut joindre, ce que vous voudrez peut-être limiter sur un réseau sensible.
+
+Deux variables d'environnement fournissent une liste d'autorisation et une liste de refus :
+
+| Variable | Comportement |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Noms d'hôtes ou CIDR séparés par des virgules. Quand elle est définie, **seules** ces cibles sont autorisées. |
+| `REST_DENIED_HOSTS` | Noms d'hôtes ou CIDR séparés par des virgules. Toujours bloqués. Prioritaire sur la liste d'autorisation. |
+
+Les noms d'hôtes sont comparés à l'hôte de l'URL sans tenir compte de la casse. Les CIDR sont comparés à chaque IP vers laquelle l'hôte se résout, si bien que `10.0.0.0/8` bloque tout nom DNS qui se résout dans la plage privée.
+
+**Exemples :**
+
+La première ligne n'autorise que deux hôtes ; la seconde bloque des cibles précises :
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Cette protection ne couvre que le processus Node.js d'AnsibleForms.** Une fois qu'un playbook s'exécute, Ansible lui-même peut joindre n'importe quoi depuis l'hôte, hors du contrôle d'AnsibleForms. Utilisez ces listes pour empêcher les auteurs de formulaires de transformer les expressions en proxy vers des services de métadonnées ou des interfaces internes ; ne comptez pas sur elles comme pare-feu réseau.
+
+Depuis la 7.3.0, les helpers REST vérifient le certificat TLS de l'endpoint, comme toutes les autres connexions, et abandonnent après
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (`60` par défaut). Faites confiance à une CA privée avec
+`NODE_EXTRA_CA_CERTS`, ou mettez [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) à `1` uniquement pour des endpoints avec un
+certificat auto-signé.
+
+### Intégration HashiCorp Vault
+
+Les identifiants peuvent lire leur utilisateur et leur mot de passe dans HashiCorp Vault, configuré comme
+**coffre de secrets**. Voir [Coffres de secrets](secret-stores). Les variables d'environnement `VAULT_*`
+des versions précédentes sont importées une fois comme le coffre `vault` au premier démarrage en 7.x.
+
+Pour des secrets utilisés seulement dans un playbook, vous pouvez aussi utiliser le plugin de lookup `community.hashi_vault`,
+qui lit directement dans Vault sans passer par AnsibleForms.
+
+---
+
+## Intégration
+
+### Interroger AWX/Tower/AAP
+
+Interroger des informations dans AWX ou Ansible Automation Platform.
+
+Pour remplir des listes déroulantes avec des données d'AWX ou de Tower, utilisez `fn.fnRestBasic` ou `fn.fnRestJwtSecure`. Depuis la 7.3.0, ces helpers vérifient
+le certificat de l'adresse AWX : avec un certificat auto-signé, faites confiance à sa CA avec `NODE_EXTRA_CA_CERTS`, ou mettez
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) à `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Personnalisation
+
+### Personnalisation
+
+Personnaliser AnsibleForms.
+
+AnsibleForms est une application web. Quand vous la faites tourner nativement dans Node.js, vous pouvez remplacer ou modifier ses fichiers.  
+L'approche recommandée reste toutefois de la faire tourner comme image Docker et d'ajouter des montages de volumes ou de fichiers. Les projets Docker Compose montent déjà des répertoires pour rendre persistants la base de données, les playbooks, les journaux, les certificats et les clés SSH, et vous pouvez ajouter d'autres montages. Un logo personnalisé se téléverse sur la page de paramètres **Logo**.  
+Le fichier `custom.js` contient vos propres fonctions JavaScript à utiliser dans les expressions. Les fonctions intégrées utilisent le préfixe `fn.` (par exemple fn.fnRestBasic) ; les fonctions personnalisées utilisent le préfixe `fnc.`.  
+De la même façon, vous pouvez ajouter vos propres définitions jq dans le fichier `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### Activer YTT
+
+Activer ytt.
+
+Pour utiliser ytt, définissez `USE_YTT=1`.  
+Pour plus d'informations sur ytt, voir https://carvel.dev/ytt/.
+
+{: .important }  
+> Cette fonctionnalité n'a pas été testée en profondeur, et aucun retour n'a été reçu depuis son ajout comme amélioration.  
+> Avec ytt, vous devez désactiver le concepteur : le concepteur convertit les fichiers YAML en JSON intermédiaire et perd la syntaxe ytt (qui se compose de commentaires YAML).
+
+Un répertoire `lib` doit exister dans le répertoire racine ; il est inclus automatiquement dans l'appel à ytt.
+Des données peuvent être fournies globalement en définissant des variables d'environnement préfixées :  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Vous pouvez aussi fournir des fichiers de données de bibliothèque :
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**La bibliothèque `demo` doit exister dans le contexte ytt (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+Les données chargées peuvent ensuite être utilisées :
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Contrôle d'accès
+
+### Comment restreindre ce que les utilisateurs peuvent faire (options de rôle) ?
+
+Au-delà de la restriction des formulaires qu'un rôle peut voir, les `options` d'un rôle activent ou désactivent des fonctions de l'interface pour ses membres.
+Voir [Options de rôle](config/roles.html#role-options) pour chaque option, sa valeur par défaut et la façon dont les options se combinent entre rôles.
+
+### Comment mettre en place une logique RBAC personnalisée dans mes playbooks ou formulaires ?
+
+L'identité de l'utilisateur est disponible côté frontend comme côté backend à chaque exécution.
+
+À chaque soumission de formulaire, AnsibleForms injecte automatiquement l'identité complète de l'utilisateur courant dans les extravars envoyées à Ansible :
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+Votre playbook ou tout module Ansible personnalisé peut donc utiliser `ansibleforms_user` directement pour des décisions fines, par exemple pour n'autoriser que certains groupes à modifier l'inventaire de production, ou pour écrire une piste d'audit avec le nom d'utilisateur de l'auteur de la soumission.
+
+Dans le **frontend**, le même objet est disponible via le champ spécial `__user__` :
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Schémas courants :**
+
+L'identité de l'utilisateur permet des schémas comme les suivants :
+
+- **Croiser avec un fichier de configuration RBAC ou une base de données** : chargez un fichier YAML ou JSON (avec `fn.fnReadYamlFile` ou une expression) qui associe des groupes à des ressources autorisées, puis filtrez sur `$(__user__.groups)`
+- **Piste d'audit** : passez `ansibleforms_user.username` comme variable supplémentaire pour enregistrer qui a déclenché le job
+- **Valeurs de champ dynamiques** : affichez un autre ensemble de choix enum, préremplissez des champs ou masquez des sections selon les groupes ou les rôles de l'utilisateur
+- **Autorisation côté playbook** : vérifiez que `ansibleforms_user.groups` contient un groupe requis avant que le playbook continue, comme contrôle de défense en profondeur indépendant de la liste `roles` du formulaire
+
+{: .note }
+> L'objet ci-dessus est ce qui est envoyé par défaut. Si l'instance définit `EXTRAVARS_USER_FIELDS`,
+> ou si le formulaire définit `userExtravars`, seules les clés qui y sont nommées sont envoyées, si bien qu'un playbook qui
+> vérifie `ansibleforms_user.groups` a besoin que `groups` en fasse partie. Le champ frontend
+> `__user__` vient du jeton de connexion et n'est jamais réduit par aucun de ces deux paramètres.
+
+---
+
+## Planification des jobs
+
+### Comment planifier l'exécution automatique d'un formulaire ?
+
+Ouvrez la liste déroulante à côté de **Soumettre** et choisissez **Planifier (récurrent)** ou **Exécuter plus tard (une seule fois)** ; ils nécessitent les options de rôle
+`allowScheduledJobs` (niveau admin) et `allowPlannedJobs`. Voir [Planifications](jobs/schedules.html).
+
+### Quelles expressions cron puis-je utiliser ?
+
+Une planification récurrente accepte une expression cron standard à 5 champs (minute, heure, jour du mois, mois, jour de la semaine).
+
+| Expression | S'exécute |
+|---|---|
+| `*/15 * * * *` | Toutes les 15 minutes |
+| `0 * * * *` | Toutes les heures, à l'heure pile |
+| `0 */6 * * *` | Toutes les 6 heures, à 00:00, 06:00, 12:00 et 18:00 |
+| `0 2 * * *` | Tous les jours à 02:00 |
+| `30 7 * * 1-5` | Du lundi au vendredi à 07:30 |
+| `0 8 * * MON` | Tous les lundis à 08:00 (les noms de jours et de mois sont acceptés) |
+| `0 0 1 * *` | À minuit le premier jour de chaque mois |
+| `0 22 L * *` | À 22:00 le dernier jour de chaque mois |
+| `0 6 * * 1#1` | À 06:00 le premier lundi de chaque mois |
+| `*/30 * * * * *` | Toutes les 30 secondes (un sixième champ facultatif placé devant correspond aux secondes) |
+
+Quand le jour du mois et le jour de la semaine sont tous deux définis, la planification s'exécute dès que l'un des deux correspond : `0 0 13 * 5` s'exécute le
+13 et tous les vendredis. Le serveur refuse une expression qu'il ne peut pas exécuter, ou qui ne peut jamais se produire (`0 0 30 2 *`).
+
+Sur la page **Planifications**, l'éditeur cron décrit l'expression et prévisualise ses prochaines exécutions. Il n'accepte pas les alias
+comme `@daily`, le joker `?` ni le modificateur `W` (jour ouvré le plus proche), tenez-vous-en donc aux formes du tableau.
+
+{: .note }
+> **Fuseau horaire** Les planifications cron s'exécutent dans le fuseau horaire du serveur, défini avec [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (`UTC` par défaut), et non dans celui de votre profil ou de votre navigateur. `0 2 * * *` avec `LOG_TZ=Europe/Madrid` s'exécute à 02:00
+> heure de Madrid toute l'année, en suivant l'heure d'été. L'éditeur cron prévisualise les prochaines exécutions dans ce même fuseau. Les planifications de
+> pull des dépôts utilisent le même fuseau.
+
+---
+
+## Enregistrer et charger des données de formulaire
+
+### Comment enregistrer et recharger des données de formulaire sans exécuter de job ?
+
+Choisissez **Enregistrer** dans la liste déroulante à côté de **Soumettre** pour enregistrer les valeurs des champs, puis **Charger depuis le stockage** pour les restaurer plus tard.
+Les champs mot de passe ne sont jamais enregistrés. Il faut l'option de rôle `allowStoredJobs`. Voir [Jobs enregistrés](jobs/stored-jobs.html).
+
+---
+
+## Formulaires imbriqués et champs structurés
+
+### Comment recueillir des données structurées ou répétées dans un formulaire ?
+
+Utilisez des champs `list` et `yaml` avec des sous-formulaires (6.2.0+).
+
+Pour recueillir des données structurées complexes, comme une liste de serveurs, un ensemble d'interfaces réseau ou un seul objet imbriqué, utilisez le type de champ `list` ou `yaml` avec un `subform`.
+
+Un **sous-formulaire** est un fragment de formulaire réutilisable (défini avec `type: subform`) qui n'est jamais affiché comme tuile à part. Il n'existe que pour être référencé par des champs d'autres formulaires. Voir la [documentation des sous-formulaires](forms/subform.html) pour la référence complète.
+
+**Recueillir une liste de lignes structurées : le champ `list` :**
+
+Un champ `list` ouvre le sous-formulaire référencé une fois par ligne :
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+L'extravar `servers` envoyée à Ansible est un tableau d'objets : `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Modifier un seul objet structuré : le champ `yaml` :**
+
+Le champ `yaml` a trois modes :
+
+| Mode | Comment | Comportement |
+|---|---|---|
+| **Éditeur** | par défaut | Affiche un éditeur YAML complet avec coloration syntaxique dans lequel l'utilisateur peut taper directement |
+| **Lecture seule** | `readonly: true` | Affiche la valeur YAML sous forme de texte formaté en lecture seule, sans modification |
+| **Sous-formulaire** | `subform: MySubform` | Masque l'éditeur brut ; ouvre le sous-formulaire comme éditeur détaillé au clic |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Téléversement et téléchargement : champs `list` et `yaml` :**
+
+Les deux types de champs prennent en charge le transfert de fichiers côté client via deux propriétés facultatives :
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> Le champ `list` et le type de formulaire `subform` ont remplacé le champ `table` et `tableFields`, supprimés en 7.0.0.
+
+### Comment accéder aux données du formulaire parent dans un sous-formulaire ?
+
+Référencez les valeurs des champs parents depuis un sous-formulaire via `__parent__` (v6.3.0+).
+
+Quand un sous-formulaire s'ouvre, que ce soit depuis un champ **`list`** (l'éditeur de chaque ligne) ou un champ **`yaml`** en mode sous-formulaire, AnsibleForms injecte automatiquement dans le sous-formulaire un champ spécial en lecture seule appelé `__parent__`. Il contient un instantané de **toutes les valeurs des champs du formulaire parent au moment de l'ouverture du sous-formulaire**, constantes et variables comprises.
+
+Cela permet aux champs du sous-formulaire d'utiliser des expressions qui référencent les données du parent sans aucune configuration supplémentaire.
+
+#### Que contient `__parent__` ?
+{: .no_toc }
+
+`__parent__` est un objet simple dont les clés sont les noms des champs du formulaire parent :
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` n'est **pas envoyé à Ansible** ; comme `__user__`, il est retiré des extravars. C'est uniquement un auxiliaire frontend pour les expressions dans les sous-formulaires.
+
+#### Accéder aux valeurs du parent dans les expressions d'un sous-formulaire
+{: .no_toc }
+
+Référencez les valeurs du parent avec la syntaxe d'expression standard `$(...)` :
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Sous-formulaires imbriqués
+{: .no_toc }
+
+`__parent__` désigne toujours le formulaire **parent immédiat**. Si vous imbriquez une `list` dans un sous-formulaire lui-même ouvert depuis un formulaire parent, le `__parent__` du sous-formulaire intérieur contient les données du sous-formulaire intermédiaire. Pour atteindre les niveaux supérieurs, enchaînez les références comme `$(__parent__.__parent__.someField)` si le sous-formulaire intermédiaire propage aussi son propre `__parent__`.
+
+### Comment migrer de `table` / `tableFields` vers `list` / `subform` ?
+
+Le champ `table` et la propriété `tableFields` ont été rendus obsolètes en 6.2.0 et supprimés en 7.0.0, et un formulaire qui les utilise encore échoue à la validation. Pour migrer :
+
+1. Extrayez les colonnes de `tableFields` dans un nouveau formulaire `type: subform` avec des `formfields` ordinaires
+2. Remplacez le champ `table` par un champ `list` qui référence le sous-formulaire via `subform: MySubformName`
+
+**Avant :**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Après :**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### Migrer `from` de `tableFields` vers des expressions `__parent__`
+{: .no_toc }
+
+La propriété `from` des colonnes enum de `tableFields` remplissait les choix de la liste déroulante à partir d'un autre champ du formulaire parent. Dans un `subform`, elle est remplacée par une `expression` qui lit la même valeur via `__parent__`.
+
+**Avant : `tableFields` avec `from` :**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Après : sous-formulaire avec une expression `__parent__` :**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` renvoie la **valeur actuelle** de ce champ, si bien que si ce champ est lui-même un champ expression dynamique, le sous-formulaire voit toujours le dernier résultat évalué du parent.
+
diff --git a/i18n/fr/_reference/getting-help.md b/i18n/fr/_reference/getting-help.md
new file mode 100644
index 0000000..ecff70f
--- /dev/null
+++ b/i18n/fr/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Obtenir de l'aide
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Obtenir de l'aide
+{: .no_toc }
+
+Où poser une question, signaler un bug ou un problème de sécurité, et proposer une amélioration
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avant de demander
+
+La plupart des réponses sont déjà écrites ; un rapide coup d'œil évite souvent un aller-retour :
+
+1. Cherchez sur ce site avec le champ de recherche en haut de chaque page.
+2. Cherchez le message d'erreur exact dans [Dépannage](troubleshooting.html), et parcourez la [FAQ](faq.html).
+3. Consultez le journal du serveur (**Paramètres**, puis **Journal du serveur**) et la page **Statut**, qui signalent la plupart des problèmes de configuration.
+4. Consultez le [Changelog](changelog.html) : le problème est peut-être déjà corrigé dans une version plus récente.
+
+---
+
+## Où aller
+
+Chaque type de demande a son propre endroit, tous sur GitHub :
+
+| Vous voulez | Allez sur |
+|---|---|
+| Poser une question ou partager une idée | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Signaler un bug | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Proposer une fonctionnalité | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Signaler un problème de sécurité | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), en privé |
+| Corriger ou améliorer cette documentation | **Modifier cette page sur GitHub** en bas de n'importe quelle page, ou une [issue sur le site web](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Signaler un bug
+
+Un signalement reproductible est corrigé le plus vite. Le modèle de rapport de bug demande ceci :
+
+* **Version** : affichée sous **À propos** dans le menu d'aide (**?**) de la barre supérieure
+* **Déploiement** : Docker, Docker Compose, Kubernetes, l'installateur (et son moteur), une installation native ou depuis les sources
+* **Étapes pour reproduire** : ce que vous avez fait, ce que vous attendiez, et ce qui s'est passé à la place
+* **Éléments de preuve** : les lignes pertinentes du journal du serveur, et une capture d'écran quand le problème est visible
+
+Pour un problème avec un formulaire, joignez une définition de formulaire minimale qui le montre. Retirez les mots de passe, les jetons, les noms d'hôtes et toute
+autre donnée privée des journaux et des formulaires avant de les publier : les issues et les discussions sont publiques.
+
+---
+
+## Signaler un problème de sécurité
+
+**N'ouvrez jamais d'issue publique pour cela :** utilisez [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), que seuls les mainteneurs voient.
+
+La [politique de sécurité](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) liste les versions prises en charge et
+ce qui se passe après votre signalement.
diff --git a/i18n/fr/_reference/troubleshooting.md b/i18n/fr/_reference/troubleshooting.md
new file mode 100644
index 0000000..2cbec6c
--- /dev/null
+++ b/i18n/fr/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Dépannage
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Dépannage
+{: .no_toc }
+
+Messages d'erreur et symptômes, pourquoi ils se produisent et comment les corriger
+{: .fs-6 .fw-300 }
+
+---
+
+Chaque problème ci-dessous porte comme titre le message ou le symptôme que vous voyez, suivi de la cause et de la correction. Les messages sont cités
+exactement comme AnsibleForms les écrit ; `<name>` représente une valeur qui change selon le cas. La plupart arrivent dans le journal du
+serveur, que vous pouvez lire sous [Journal du serveur](gui/administration.html#server-log) ou avec `docker logs`.
+
+**Base de données et démarrage**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Configuration et formulaires**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [La configuration de base a une section forms](#the-base-config-has-a-forms-section)
+* [Un formulaire manque dans le tableau de bord](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Connexion**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [L'authentification Azure AD ou OIDC échoue](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Déconnecté après un redémarrage ou au bout d'une journée](#logged-out-after-a-restart-or-after-a-day)
+* [Formulaires et jobs vides après une authentification unique (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Jobs**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Un job affiche le statut abandoned](#a-job-shows-the-status-abandoned)
+* [Un RTE ne se connecte pas](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Dépôts git et sauvegardes**
+
+* [Le clonage ou le pull d'un dépôt échoue](#a-repository-clone-or-pull-failed)
+* [Le dépôt de formulaires n'est pas encore cloné](#the-forms-repository-is-not-cloned-yet)
+* [Une sauvegarde échoue](#a-backup-failed)
+
+La [FAQ](faq.html) traite en détail deux problèmes liés : un
+[mot de passe admin perdu](faq.html#recovering-a-lost-admin-password) et
+[la restriction des destinations des helpers REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms ne démarre pas, et le journal répète ces lignes toutes les 5 secondes :
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Pourquoi cela se produit**
+
+Au démarrage, AnsibleForms attend que la base de données réponde à une requête, et continue d'attendre tant qu'elle ne répond pas.
+Le `<reason>` est le message propre du pilote de base de données : une connexion refusée ou expirée désigne l'hôte ou le port,
+un message d'accès refusé le nom d'utilisateur ou le mot de passe.
+
+**Comment le corriger**
+
+Vérifiez [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) et [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Depuis l'intérieur d'un conteneur, `localhost` est le conteneur lui-même, pas l'hôte qui fait tourner MySQL. Assurez-vous que MySQL écoute
+sur une adresse réseau et que l'utilisateur peut se connecter depuis l'hôte d'AnsibleForms. AnsibleForms continue de lui-même dès
+que la base de données répond ; aucun redémarrage n'est nécessaire.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+Le navigateur ouvre une page de base de données au lieu de la page de connexion, et le journal affiche :
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Pourquoi cela se produit**
+
+Le schéma `AnsibleForms` est absent ou incomplet. Une base de données *vide* est provisionnée automatiquement au démarrage, sauf si
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) vaut `0`. Si cela échoue, par exemple parce que
+l'utilisateur de base de données n'a pas le droit de créer un schéma, le journal indique `Failed to create the schema automatically : <reason>`. Un schéma
+qui existe mais auquel il manque des tables (`Table '<name>' is not present`) n'est jamais recréé automatiquement, car créer le
+schéma supprime d'abord toutes les tables. La page de base de données indique alors *It appears that you have an unuseable schema*.
+
+**Comment le corriger**
+
+Sur une nouvelle installation, donnez à l'utilisateur de base de données le droit de créer le schéma `AnsibleForms` et redémarrez, ou appuyez sur
+**Créer** sur la page de base de données. Sur un schéma présent en partie, restaurez une sauvegarde ou supprimez le schéma `AnsibleForms`
+incomplet pour qu'AnsibleForms puisse le recréer. Le journal liste les tables et les patchs qui ont échoué.
+
+---
+
+## Schema creation is disabled
+
+La création du schéma, depuis la page de base de données ou avec `POST /api/v2/schema`, échoue avec :
+
+```
+Schema creation is disabled
+```
+
+**Pourquoi cela se produit**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) vaut `0`, ce qui désactive à la fois la création
+automatique au démarrage et l'endpoint. Sur une base de données qui a déjà des utilisateurs, l'endpoint refuse aussi les appelants qui ne sont pas
+connectés en tant qu'administrateur, avec `Schema creation requires an authenticated administrator`.
+
+**Comment le corriger**
+
+Créez le schéma une fois avec `ALLOW_SCHEMA_CREATION=1` (c'est la valeur par défaut), ou restaurez-le depuis une sauvegarde, puis remettez la
+variable à `0`. Sur une base de données déjà provisionnée, connectez-vous en tant qu'administrateur avant de recréer le schéma, et n'oubliez pas
+que cela supprime et recrée toutes les tables.
+
+---
+
+## Config seed failed, refusing to start
+
+Le conteneur se termine juste après le démarrage, et sa sortie se termine par :
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Pourquoi cela se produit**
+
+Le fichier de [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) n'a pas pu être appliqué : par exemple, ce n'est pas du YAML
+valide ou il enfreint le schéma du seed ; `<reason>` dit ce qui n'a pas fonctionné. AnsibleForms refuse de démarrer plutôt que de
+tourner avec la moitié de ses objets déclarés. La raison est aussi écrite sur la sortie d'erreur standard, `docker logs` et `kubectl logs` l'affichent donc.
+
+**Comment le corriger**
+
+Corrigez ce que nomme `<reason>` et redémarrez. Voir [Rechargement et démarrage](seed/reloading.html) pour la façon dont le seed est
+appliqué, et [Exemple](seed/example.html) pour un fichier valide.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Chaque démarrage écrit cet avertissement dans le journal :
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Ou le worker refuse de démarrer avec :
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Pourquoi cela se produit**
+
+Les secrets stockés sont chiffrés avec [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET) : depuis la 7.3.0, ils se trouvent dans
+les identifiants (les mots de passe et les jetons des annuaires LDAP, des fournisseurs SSO, des runners et des coffres de secrets, entre autres), à côté des adresses
+des webhooks Slack et Teams. Sans lui, une clé publique dans le code source est utilisée. Depuis la 7.3.0, un démarrage avec un nouvel
+`ENCRYPTION_SECRET` rechiffre chaque secret stocké avec lui, en une seule transaction : depuis la clé par défaut quand il est défini pour la première
+fois, ou depuis [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) quand il change. Quand les
+secrets stockés n'ont été chiffrés avec aucune des deux, rien n'est modifié et AnsibleForms ne démarre pas.
+
+**Comment le corriger**
+
+Définissez `ENCRYPTION_SECRET`, et gardez-le avec vos autres secrets : les sauvegardes ne le contiennent jamais. Le démarrage suivant écrit
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Pour le changer plus tard, mettez la nouvelle valeur dans
+`ENCRYPTION_SECRET` et l'ancienne dans `ENCRYPTION_SECRET_PREVIOUS` le temps d'un démarrage, puis supprimez `ENCRYPTION_SECRET_PREVIOUS`. Quand le
+worker refuse de démarrer, mettez dans `ENCRYPTION_SECRET_PREVIOUS` la clé avec laquelle les secrets ont été chiffrés, ou remettez l'ancienne valeur.
+
+---
+
+## Could not load the forms
+
+Le tableau de bord n'affiche aucun formulaire et indique :
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Pourquoi cela se produit**
+
+La configuration de base (`config.yaml`) n'a pas pu être lue ou n'est pas valide. Le `<reason>` dit pourquoi :
+
+| Raison | Cause |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Une erreur de syntaxe YAML |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Un fichier vide, ou qui ne contient que des commentaires |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | Le même rôle est défini deux fois |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` est absent et son dossier n'est pas accessible en écriture |
+| `There is no forms directory nor could there be one created from template.` | Le dossier des formulaires est absent et ne peut pas être créé |
+| Toute autre ligne | La configuration enfreint le schéma, par exemple un rôle sans `groups` |
+
+**Comment le corriger**
+
+Corrigez le fichier nommé par [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH), ou le `config.yaml` du
+dépôt utilisé pour la configuration. Quand des fichiers manquent, faites pointer [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) et
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) vers un emplacement persistant et accessible en écriture. Voir
+[config.yaml](config/) pour la structure.
+
+---
+
+## La configuration de base a une section forms
+
+Après une mise à niveau depuis la 6.x, le tableau de bord est vide, et le panneau des avertissements affiche :
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Pourquoi cela se produit**
+
+Depuis la 7.0.0, chaque formulaire se trouve dans son propre fichier dans le dossier des formulaires. Les formulaires encore listés dans `config.yaml` sont
+ignorés.
+
+**Comment le corriger**
+
+Déplacez chaque formulaire dans son propre fichier dans [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Voir
+[Passer à la 7.x](upgrade-7.html).
+
+---
+
+## Un formulaire manque dans le tableau de bord
+
+Un fichier de formulaire existe, mais un utilisateur ne voit pas le formulaire dans le tableau de bord.
+
+**Pourquoi cela se produit**
+
+Un utilisateur ne voit un formulaire que si l'un des `roles` du formulaire fait partie des rôles de l'utilisateur ; les admins voient tous les formulaires. Chaque utilisateur a
+le rôle `default`, un formulaire avec `roles: [default]` est donc visible par tous. Les rôles d'un utilisateur viennent des groupes et des utilisateurs
+listés sous `roles` dans `config.yaml`. Un formulaire sans `categories` apparaît sous **Default**, il est donc absent des
+autres catégories, tout en restant listé sous **Tous les formulaires**. Enfin, un formulaire qui échoue à la validation est ignoré. Le
+tableau de bord affiche alors un bouton **Cette configuration contient Avertissements ou erreurs**, qui ouvre des messages comme :
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Comment le corriger**
+
+Ouvrez le panneau des avertissements et corrigez ce qu'il liste. Vérifiez les rôles de l'utilisateur sous
+[Permissions](profile/permissions.html) dans le profil, ainsi que les `roles` et les `categories` du formulaire. Voir
+[Rôles](config/roles.html) et [Catégories](config/categories.html). Quand deux fichiers définissent le même nom de formulaire,
+le premier chargé l'emporte.
+
+---
+
+## Could not save the forms
+
+L'enregistrement dans le concepteur échoue avec :
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Pourquoi cela se produit**
+
+Le concepteur valide chaque formulaire selon le schéma avant d'écrire quoi que ce soit. Chaque ligne de `<messages>` nomme le
+formulaire et le champ qui enfreignent une règle. Les options supprimées en 7.0.0 ont leur propre message, par exemple
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Comment le corriger**
+
+Corrigez les champs que nomment les messages. Pour les options supprimées en 7.0.0, suivez [Passer à la 7.x](upgrade-7.html).
+Pour valider les fichiers de formulaires avant qu'ils n'arrivent dans AnsibleForms, voir
+[Validation VS Code des fichiers de formulaires](faq.html#vs-code-validation-for-form-files) dans la FAQ.
+
+---
+
+## The editor is read-only
+
+Le concepteur affiche **Verrouillé** avec le nom d'un autre utilisateur, et l'enregistrement échoue avec :
+
+```
+The editor is read-only
+```
+
+**Pourquoi cela se produit**
+
+Une seule personne à la fois peut modifier les formulaires. Le verrou est pris quand quelqu'un démarre le concepteur, et il reste jusqu'à ce
+qu'il l'arrête, même s'il a fermé le navigateur sans l'arrêter. L'API refuse un enregistrement de toute autre personne avec
+`Designer is locked by <username>`.
+
+**Comment le corriger**
+
+Demandez à `<username>` d'arrêter le concepteur. Si ce n'est pas possible, utilisez **Forcer le déverrouillage** dans le concepteur. Celui qui détient le
+verrou perd les modifications qu'il n'a pas enregistrées.
+
+---
+
+## Abuse attempt of eval function
+
+Un champ d'expression affiche une erreur, et le journal contient une ligne comme :
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Pourquoi cela se produit**
+
+Les expressions côté serveur sont vérifiées avant leur exécution. Elles ne peuvent appeler que des fonctions `fn.` et `fnc.` ; les instructions multiples,
+les lignes multiples, les template literals, `process.env` et des mots comme `require` ou `constructor` sont refusés. Le message
+indique quelle règle a été enfreinte. Avec [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) à
+`off`, chaque expression serveur échoue avec
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Comment le corriger**
+
+Réécrivez l'expression sous forme d'un seul appel `fn.` ou d'une opération simple, ou exécutez-la dans le navigateur avec `runLocal: true`. Voir
+[Expressions](expressions/) et [Expressions locales](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Un champ qui appelle une API REST reste vide, et le journal affiche :
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Pourquoi cela se produit**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) est défini, et l'hôte de l'URL n'y figure pas.
+Un hôte qui correspond à [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) est refusé avec
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, et un hôte qui ne se résout pas avec `cannot resolve <host>`.
+
+**Comment le corriger**
+
+Ajoutez le nom d'hôte, ou un CIDR qui couvre ses adresses, à `REST_ALLOWED_HOSTS`, ou retirez de `REST_DENIED_HOSTS` l'entrée qui le bloque.
+Voir [Restreindre les destinations des helpers REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+La page de connexion refuse un nom d'utilisateur et un mot de passe avec :
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Pourquoi cela se produit**
+
+La page de connexion donne la même réponse pour chaque échec, pour ne pas révéler si un utilisateur existe. AnsibleForms
+essaie d'abord les utilisateurs locaux, puis LDAP : avec plusieurs annuaires, un nom d'utilisateur est cherché dans leur ordre sous **Accès > LDAP**,
+sauf s'il nomme un annuaire (`corp\jane`) ou l'un de ses domaines de connexion (`jane@corp.example`). La vraie raison va dans le journal. Les échecs
+LDAP sont journalisés sous la forme `Error connecting to ldap: <reason>`, avec des raisons comme `Wrong binding credentials` ou
+`Unable to verify the certificate` ; les codes Active Directory sont traduits en `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` ou `Password expired`.
+
+**Comment le corriger**
+
+Lisez la raison dans le journal. Pour la raison complète de chaque échec de connexion, mettez
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) à `debug`, qui journalise `Ldap authentication failed: <reason>`.
+Si le mot de passe de l'admin local est perdu, voir [Récupérer un mot de passe admin perdu](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Le test d'un annuaire LDAP sous **Accès > LDAP** échoue avec l'un de ces messages :
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Pourquoi cela se produit**
+
+L'utilisateur de bind ou son mot de passe est erroné, le serveur ou le port est injoignable, ou, avec TLS, le certificat du serveur ne peut pas être
+vérifié avec le bundle CA. Depuis la 7.3.0, ces éléments se trouvent sur l'identifiant ldap de l'annuaire, sous **Connexions > Identifiants**. Un utilisateur de test qui n'existe pas
+compte quand même comme un test réussi, car la connexion et le bind ont fonctionné.
+
+**Comment le corriger**
+
+Ouvrez l'identifiant que nomme l'annuaire (l'annuaire par défaut est `main`) sous **Connexions > Identifiants**, et corrigez le DN de bind
+et son mot de passe, les serveurs et le port (généralement 389, ou 636 pour LDAPS). Pour les problèmes TLS, collez le bundle CA qui a signé le
+certificat du serveur LDAP ; ignorer la vérification du certificat n'est pas fait pour la production. Voir [LDAP](authentication/ldap.html).
+
+---
+
+## L'authentification Azure AD ou OIDC échoue
+
+Une connexion par authentification unique revient à la page de connexion avec :
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Pourquoi cela se produit**
+
+Le fournisseur d'identité a renvoyé l'utilisateur, mais AnsibleForms n'a pas pu terminer la connexion. Les raisons courantes sont
+`azuread login is not enabled` ou `oidc login is not enabled` (le fournisseur est désactivé), et `jwt expired`, car
+le relais depuis le fournisseur n'est valable que 5 minutes. Une erreur pendant le callback du fournisseur est aussi affichée
+sur la page de connexion, et journalisée.
+
+**Comment le corriger**
+
+Activez le fournisseur sous **Accès > SSO**, et enregistrez l'URL de callback dans le fournisseur d'identité exactement telle
+qu'AnsibleForms l'utilise : `https://<your host>/api/v2/auth/entraid/callback` pour Entra ID (depuis la 7.3.0 ; `azureadoauth2` fonctionne toujours), ou
+`https://<your host>/api/v2/auth/oidc/callback` pour OIDC. Une URL de callback avec `/api/v1/`, d'avant la 7 ou d'avant la
+6.1.5, doit être mise à jour : la page de connexion se recharge alors sans connecter l'utilisateur et sans erreur. Réessayez la connexion après
+un relais expiré.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Un utilisateur avec un mot de passe valide ne peut pas se connecter, et reçoit :
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Pourquoi cela se produit**
+
+L'un des rôles de l'utilisateur met l'option de rôle `allowLogin` à `false`. Le journal indique
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Comment le corriger**
+
+Retirez `allowLogin: false` du rôle, ou sortez l'utilisateur de ce rôle. Voir [Rôles](config/roles.html).
+
+---
+
+## Déconnecté après un redémarrage ou au bout d'une journée
+
+Chaque utilisateur est renvoyé vers la page de connexion après un redémarrage d'AnsibleForms, ou après une journée d'utilisation.
+
+**Pourquoi cela se produit**
+
+Quand [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) n'est pas défini, chaque démarrage génère une
+nouvelle clé de signature, et journalise
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Les jetons d'avant le
+redémarrage ne sont alors plus acceptés. Indépendamment de cela, une session prend fin quand son jeton de rafraîchissement expire
+(`Refresh token is expired`), après
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), 24 heures par défaut.
+
+**Comment le corriger**
+
+Mettez `ACCESS_TOKEN_SECRET` à une valeur fixe et secrète. Augmentez `ACCESS_TOKEN_REFRESH_EXPIRATION` si une journée est trop courte. Pour
+un accès API de longue durée, utilisez un [jeton d'API](profile/api-token.html).
+
+---
+
+## Formulaires et jobs vides après une authentification unique (HTTP 431)
+
+Un utilisateur se connecte avec Entra ID ou OIDC sans erreur, mais les pages des formulaires et des jobs restent vides. L'onglet réseau
+du navigateur montre que les appels API ont reçu cette réponse :
+
+```
+431 Request Header Fields Too Large
+```
+
+Le journal du serveur n'affiche rien pour ces appels, et le même utilisateur peut très bien fonctionner avec un compte LDAP ou local.
+
+**Pourquoi cela se produit**
+
+Avant la 7.1.0, le jeton de connexion contenait tous les groupes de l'utilisateur, et les groupes Entra ID y figuraient deux fois, par object id
+et par nom. Le navigateur envoie ce jeton dans l'en-tête `Authorization` de chaque requête, si bien qu'un utilisateur membre d'une centaine
+de groupes ou plus se retrouve avec un en-tête de bien plus de 16 KB. Node.js refuse les en-têtes de requête de plus de 16 KB avec un 431,
+avant que la requête n'atteigne AnsibleForms, c'est pourquoi rien n'est journalisé. Un reverse proxy placé devant peut refuser la
+requête encore plus tôt : Nginx autorise 8 KB par champ d'en-tête par défaut
+(`large_client_header_buffers 4 8k`), et répond alors 400.
+
+**Comment le corriger**
+
+Passez à la 7.1.0 ou ultérieure : le jeton de connexion ne contient plus les groupes, sa taille ne dépend donc plus du nombre de
+groupes d'un utilisateur, et l'interface le signale quand une requête est refusée avec un 431 au lieu d'afficher des pages vides.
+En attendant de pouvoir mettre à niveau, au choix :
+
+* définissez un **Filtre de groupe** sur le fournisseur sous **Accès > SSO**, une expression régulière qui ne garde que les groupes qu'utilisent vos
+  rôles, voir [Entra ID](authentication/entra-id.html) ou [OIDC](authentication/oidc.html) ; l'utilisateur se reconnecte
+  pour obtenir un jeton plus petit
+* ou augmentez la limite de Node.js avec la variable d'environnement `NODE_OPTIONS=--max-http-header-size=65536`, et
+  redémarrez AnsibleForms
+
+Depuis la 7.1.0, [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) définit la même limite, 16384
+octets par défaut et lue au démarrage, pour d'autres en-têtes volumineux, comme de gros cookies posés par une passerelle d'authentification unique
+placée devant. Augmentez aussi les limites d'en-têtes du proxy, voir [Taille des en-têtes de requête](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Un job Ansible se termine en échec, et la dernière ligne de sa sortie est :
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Pourquoi cela se produit**
+
+`ansible-playbook` s'est terminé avec un code non nul. Les lignes au-dessus contiennent l'erreur propre d'Ansible : le playbook est
+introuvable, un hôte était injoignable, une tâche a échoué, ou l'inventaire est erroné. Le playbook est cherché dans le dépôt
+qui a **Utiliser pour les playbooks ?** activé, ou dans [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) ; la ligne de journal
+`Running from directory : <path>` montre le dossier utilisé.
+
+**Comment le corriger**
+
+Lisez la sortie du job au-dessus de la dernière ligne. Quand le playbook est introuvable, comparez le `playbook` du formulaire avec le
+dossier de `Running from directory`. Voir [Formulaires ansible](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Un job Ansible se termine en échec avec :
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Pourquoi cela se produit**
+
+Le processus `ansible-playbook` sur le RTE a été arrêté par un signal, et personne n'a interrompu le job. Depuis la 7.0.0, la taille de la
+sortie ne provoque plus cela : au-delà de [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (50 MB par flux
+par défaut), le reste de la sortie n'est pas stocké, le job affiche
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+et le playbook va jusqu'au bout. La cause habituelle est désormais la mémoire : le conteneur RTE a atteint sa limite de mémoire et le
+noyau a tué le playbook, par exemple avec beaucoup de forks ou de gros facts.
+
+**Comment le corriger**
+
+Surveillez la mémoire du conteneur RTE pendant l'exécution du playbook (`docker stats`, `kubectl top pod`) et augmentez sa limite, ou réduisez
+la consommation mémoire du playbook (moins de `forks`, pas de collecte de facts inutile). Quand vous ne voyez que l'avertissement `PROCESS_MAX_BUFFER` et
+avez besoin de toute la sortie, augmentez `PROCESS_MAX_BUFFER` dans l'environnement du conteneur RTE ; c'est le RTE qui le lit, pas l'application.
+---
+
+## Failed to launch awx template
+
+Un job AWX se termine en échec, avec une sortie qui commence par :
+
+```
+failed to launch awx template <name>
+```
+
+**Pourquoi cela se produit**
+
+La ligne suivante donne la raison. `Request failed with status code 401` signifie que le jeton ou le nom d'utilisateur et le mot de passe de
+l'identifiant du runner AWX sont refusés. `could not find job template <name>` signifie qu'aucun modèle de job ni aucun modèle de workflow
+ne porte exactement ce nom, ou que l'utilisateur de la connexion ne peut pas le voir. Une erreur de certificat, comme
+`unable to verify the first certificate`, signifie que le certificat d'AWX n'est pas approuvé.
+
+**Comment le corriger**
+
+Utilisez **Tester la connexion** sur le runner (**Connexions > Runners**), qui répond `Runner connection is OK` quand tout fonctionne. Depuis la
+7.3.0, le jeton ou l'utilisateur et le mot de passe, l'adresse et le **Bundle CA** se trouvent sur l'identifiant du runner, sous
+**Connexions > Identifiants** : renouvelez-y le jeton ou le mot de passe, et pour les erreurs de certificat collez la CA dans son **Bundle CA**.
+Vérifiez le nom et les permissions du modèle. Saisissez l'adresse sans `/api/v2` : AnsibleForms ajoute
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX) lui-même.
+Voir [Formulaires AWX](forms/awx.html).
+
+---
+
+## Un job affiche le statut abandoned
+
+Un job qui tournait est maintenant marqué `abandoned`, et le journal d'un nœud ou d'un RTE affiche l'un de ces messages :
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Un RTE en mode base de données, obsolète, journalise les siens :
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Pourquoi cela se produit**
+
+Un job appartient au conteneur qui l'exécute ou le suit : un playbook à son RTE, tout autre job (un job AWX, les étapes d'un formulaire
+multi-étapes) au nœud d'application qui l'a démarré. Quand ce conteneur redémarre, il termine ses propres jobs inachevés. Quand il disparaît, un pod
+remplacé par exemple, le worker termine ses jobs dès qu'il ne répond plus depuis deux minutes. Un RTE en mode socket qui revient sans
+un job qu'il exécutait, un nouveau conteneur sans son spool par exemple, voit ce job se terminer comme abandonné. Un RTE qui s'arrête attend d'abord
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) pour ses playbooks. Toutes les heures, les jobs qui tournent depuis plus
+d'une journée sont aussi marqués comme abandonnés.
+
+Depuis la 7.3.0, un job sur AWX, AAP ou Ascender continue sur son runner : juste après qu'un redémarrage l'a abandonné, un nœud le suit à nouveau,
+s'il a démarré dans les dernières 24 heures, et il se termine avec ce qui s'est réellement passé là-bas. Le journal indique alors `Following <n> abandoned job(s) again on their runner`.
+
+**Comment le corriger**
+
+Relancez un job de playbook. Redémarrez ou mettez à niveau les RTE et les nœuds d'application quand aucun job ne tourne, et laissez assez de temps à un RTE qui s'arrête
+(voir [Mise à l'échelle](rte/run.html)). Vérifiez si le playbook s'est vraiment terminé sur les hôtes gérés avant de
+relancer, car il a pu s'exécuter en partie.
+
+---
+
+## Un RTE ne se connecte pas
+
+**Tester la connexion** sur un runner RTE (**Connexions > Runners**) échoue avec :
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Pourquoi cela se produit**
+
+Un RTE en mode socket communique avec l'application via un WebSocket : en sortant, il appelle l'application ; en entrant, c'est l'application qui l'appelle (voir
+[Modes](rte/modes.html)). Les journaux de l'application et du RTE disent pourquoi le socket n'est pas ouvert :
+
+| Message | Où | Ce que cela signifie |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | Le RTE (entrant) | Le jeton de l'identifiant RTE du runner n'est pas le `RTE_TOKEN` du RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | L'application (entrant) | La même chose, vue depuis l'application |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | L'application, et le RTE refusé (`401`) | Le RTE s'authentifie avec un autre jeton que celui que l'application garde pour son runner |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | Le RTE (sortant) | Il a demandé à rejoindre et attend une approbation |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | Le RTE (entrant, avec `APP_URL`) | La même chose, pour un RTE entrant |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | L'application, et le RTE refusé (`409`) | Le seed de configuration déclare le runner sans `rte_mode`, donc en mode base de données, et c'est le seed qui décide de son mode. Un RTE entrant reçoit `rte_mode: inbound` et `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | Le RTE | Un RTE entrant qui s'inscrit lui-même a besoin de l'adresse à laquelle l'application l'appelle |
+| `Runner '<name>': dialing <address>: <reason>` | L'application, au niveau `debug` | L'application ne parvient pas à ouvrir le socket, par exemple parce que le certificat du RTE n'est pas celui épinglé pour son runner |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | Le RTE | Il tourne en mode base de données, et n'ouvre aucun socket |
+
+**Comment le corriger**
+
+* **Un jeton refusé** : donnez au RTE le jeton de l'identifiant RTE de son runner (**Connexions > Identifiants**), ou l'inverse
+* **En attente d'approbation** : approuvez-le sous **Connexions > Runners**, après avoir vérifié que l'empreinte qui y est affichée est celle de son
+  journal (voir [Approuver un RTE](runners/registration.html#approving-an-rte))
+* **Géré par le seed de configuration en mode base de données** : définissez `rte_mode` sur le runner dans le seed, avec un identifiant RTE (en entrant, son
+  adresse), puis redémarrez le RTE
+* **Entrant sans `RTE_URL`** : mettez dans `RTE_URL` l'adresse par laquelle l'application atteint le RTE, ou omettez `APP_URL` et déclarez le
+  runner dans le seed ou sous **Connexions > Runners**
+* **Un certificat qui n'est pas celui épinglé** : un RTE entrant en HTTPS envoie son certificat quand il s'inscrit, et l'application ne l'appelle
+  qu'avec celui-là. Après un nouveau certificat, le RTE le renvoie quand il s'inscrit ; quand le bundle CA de l'identifiant a été défini
+  à la main, l'application le garde et journalise
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **L'avertissement [DEPRECATED]** : définissez `RTE_MODE` sur le RTE, retirez `DB_*` de son environnement, et passez son runner dans ce mode (voir
+  [Modes](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Avec la validation au lancement sur `enforce`, un lancement est refusé avec `422` et :
+
+```
+The form data is not valid
+```
+
+**Pourquoi cela se produit**
+
+Le serveur a vérifié les valeurs des champs selon les règles du formulaire et a trouvé des champs manquants ou invalides ; la réponse les liste
+sous `details`. Un lancement sans `rawFormData` est refusé aussi. Un formulaire qui ne peut pas encore être vérifié, comme un assistant (wizard),
+est refusé avec `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Comment le corriger**
+
+Corrigez les champs que nomment les détails, ou les règles du formulaire si elles sont trop strictes. Passez d'abord par `log` : il journalise
+`Launch validation would refuse form '<name>' ...` sans rien refuser. Voir
+[Ce que fait enforce](launch-validation/log-and-enforce.html#what-enforce-does) et
+[Le déployer](launch-validation/rolling-it-out.html).
+
+---
+
+## Le clonage ou le pull d'un dépôt échoue
+
+Un dépôt affiche un statut en échec, et sa sortie contient l'erreur de git, ou le journal affiche
+`Background clone of '<name>' failed : <reason>`.
+
+**Pourquoi cela se produit**
+
+Git n'a pas pu joindre le dépôt distant ou s'y authentifier. Pour les URL SSH (`git@host:path`), le dépôt distant doit accepter la clé
+publique d'AnsibleForms ; pour HTTPS, le nom d'utilisateur et le jeton doivent être valides. Un pull est aussi refusé quand la copie de travail a
+des modifications, avec
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Comment le corriger**
+
+Pour SSH, copiez la clé publique depuis l'onglet **Clé** de **Connexions > SSH** et ajoutez-la comme clé de déploiement, ou à un utilisateur qui a
+accès au dépôt. AnsibleForms ajoute l'hôte distant aux hôtes connus lors d'un clonage ; pour les autres hôtes, utilisez l'onglet
+**Hôtes connus** de la même page. Pour
+HTTPS, renouvelez le jeton. Voir [Dépôts git](gui/designer-and-git.html#git-repositories) et
+[À propos des dépôts](faq.html#about-repositories).
+
+---
+
+## Le dépôt de formulaires n'est pas encore cloné
+
+L'enregistrement des formulaires dans le concepteur échoue avec :
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Pourquoi cela se produit**
+
+Un dépôt qui a **Utiliser pour les formulaires ?** activé n'a pas encore de copie de travail, parce que le clonage n'a pas été lancé ou a échoué.
+
+**Comment le corriger**
+
+Clonez le dépôt depuis les paramètres des dépôts. Si le clonage échoue, voir
+[Le clonage ou le pull d'un dépôt échoue](#a-repository-clone-or-pull-failed).
+
+---
+
+## Une sauvegarde échoue
+
+Une sauvegarde échoue, et rien n'est ajouté à la liste des sauvegardes. La raison est l'une de celles-ci :
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Pourquoi cela se produit**
+
+La commande de dump, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), n'est pas installée, n'a pas réussi à se
+connecter, ou a produit un fichier vide. Une grosse base de données peut aussi prendre plus de temps que
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), une heure par défaut.
+Une sauvegarde échouée ne laisse aucun dossier derrière elle ; le journal indique `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Comment le corriger**
+
+Installez les outils client MySQL ou MariaDB, ou mettez dans `MYSQLDUMP_COMMAND` (et `MYSQL_COMMAND` pour les restaurations) une commande
+qui fonctionne sur cet hôte et avec la version de votre serveur. Augmentez `BACKUP_COMMAND_TIMEOUT_SECONDS` pour une grosse base de données.
+Voir [Sauvegardes](gui/administration.html#backups).
diff --git a/i18n/fr/_security_assessment/security-assessment/advisories.md b/i18n/fr/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..9bd0bd7
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Avis de sécurité
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Avis de sécurité
+{: .no_toc }
+
+Chaque vulnérabilité publiée, sa gravité et son correctif
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avis publiés
+
+Lus depuis l'[onglet Security du dépôt](https://github.com/ansibleforms/ansibleforms/security/advisories) à chaque build de ce site :
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Avis</th>
+      <th>Gravité</th>
+      <th>Faiblesse</th>
+      <th>Concernées</th>
+      <th>Corrigé dans</th>
+      <th>Publié</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Aucun avis n'a été publié.
+{% endif %}
+
+Chaque avis sur GitHub donne les détails : l'impact, les conditions, le vecteur CVSS et le correctif.
+
+---
+
+## Ce que cela signifie pour votre version
+
+Un avis nomme les versions qu'il concerne et la première version corrigée. Le correctif est livré dans les versions prises en charge,
+[7.x et 6.5.x](development.html#supported-versions), et les versions plus anciennes ne sont pas corrigées : la mise à niveau est le correctif.
+
+Comparez la version d'une instance (**A propos** dans le menu d'aide, ou `GET /api/v2/version`) avec **Concernées**.
+
+---
+
+## Être informé des nouveaux avis
+
+GitHub prévient les observateurs du dépôt quand un avis est publié :
+
+* Sur [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), choisissez **Watch > Custom > Security alerts**.
+* Le [journal des modifications](../changelog.html) liste chaque correctif de sécurité sous la version qui le livre.
diff --git a/i18n/fr/_security_assessment/security-assessment/development.md b/i18n/fr/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..3d1edd3
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Développement sécurisé
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Développement sécurisé
+{: .no_toc }
+
+Comment les modifications sont vérifiées et publiées, et ce qui est pris en charge
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le code source
+
+AnsibleForms est open source : tout ce qui figure sur cette page peut donc être vérifié dans le dépôt lui-même :
+
+* Le code, son historique et ses pipelines de build sont publics sur [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* La [licence](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) est la GPL-3.0.
+* Le [journal des modifications](../changelog.html) liste chaque modification de chaque version, correctifs de sécurité compris.
+
+---
+
+## Comment une modification est fusionnée
+
+Chaque modification arrive sur `main` par une pull request, selon un ruleset que personne ne peut contourner :
+
+| Règle | Ce qu'elle signifie |
+|---|---|
+| Pull request obligatoire | Rien n'est poussé directement sur `main` |
+| Vérifications obligatoires | La pull request n'est fusionnée que lorsque toutes les vérifications ci-dessous passent |
+| Pas de force push, pas de suppression | L'historique de `main` ne peut être ni réécrit ni supprimé |
+| Historique linéaire | Chaque pull request devient un seul commit : chaque modification peut ainsi être tracée et annulée isolément |
+
+Les vérifications qu'une pull request doit passer :
+
+| Vérification | Ce qu'elle fait |
+|---|---|
+| Client, Server | Les tests unitaires de l'interface web et du serveur |
+| CodeQL | L'analyse statique de GitHub sur le code JavaScript et TypeScript, à la recherche d'injections, de cross-site scripting et d'autres faiblesses |
+| Public schema is up to date | Le schéma de base de données attendu par le code correspond à celui qu'il livre |
+| Title, Branch | La pull request suit les règles de nommage, pour que le journal des modifications reste exact |
+
+Deux autres s'exécutent sur chaque pull request et en rendent compte :
+
+* **Database** teste le serveur sur MySQL et MariaDB, et **Browser** pilote l'interface dans un navigateur.
+* **Dependency review** bloque une nouvelle dépendance présentant une vulnérabilité connue de gravité élevée ou critique.
+
+---
+
+## Analyse du code et dépendances
+
+Le code et ce dont il dépend sont de nouveau vérifiés après la fusion :
+
+* **CodeQL** analyse aussi chaque push sur `main` et sur les branches de release, ainsi que toute la base de code chaque semaine :
+  une nouvelle règle CodeQL vérifie alors aussi le code fusionné avant elle.
+* **Dependabot** ouvre une pull request pour chaque nouvelle version d'une dépendance : les paquets npm du serveur et de
+  l'interface, les paquets Python de l'environnement d'exécution et les GitHub Actions des pipelines chaque semaine, et
+  les images de base des conteneurs chaque jour.
+* Les images de base sont épinglées par digest (`node:26-trixie-slim@sha256:...`) : un build utilise donc exactement l'image relue.
+  Dependabot met à jour le digest quand l'image est reconstruite en amont.
+
+---
+
+## Versions et images
+
+Une version est construite et publiée uniquement par GitHub Actions, jamais depuis la machine d'un développeur :
+
+* Une version est créée à partir de `main` (ou de `release/6.x`), avec un journal des modifications construit à partir de ses pull requests.
+* Les images sont construites par le [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  et poussées vers le GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, avec les images de l'environnement d'exécution
+  à côté. Le workflow et ses journaux sont publics : chacun peut voir ce qui est entré dans une image.
+* Les images de l'application et de l'environnement d'exécution s'exécutent avec l'utilisateur non privilégié `node` (uid 1000), jamais en root.
+
+---
+
+## Versions prises en charge
+
+Les correctifs de sécurité sont intégrés à la version la plus récente de chaque branche prise en charge :
+
+| Version | Reçoit des correctifs de sécurité |
+|---|---|
+| 7.x | Oui |
+| 6.5.x | Oui |
+| Antérieure à 6.5 | Non : la mise à niveau est le correctif |
+
+Le [guide de mise à niveau](../upgrading/) couvre le passage à une version plus récente, et [Passer à la v7](../upgrade-7.html) celui depuis la 6.5.
diff --git a/i18n/fr/_security_assessment/security-assessment/faq.md b/i18n/fr/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..8735351
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: FAQ de l'évaluation
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# FAQ de l'évaluation
+{: .no_toc }
+
+Des réponses courtes aux questions les plus fréquentes des questionnaires de sécurité
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Données et hébergement
+
+Où se trouvent les données, et qui peut y accéder :
+
+| Question | Réponse |
+|---|---|
+| Où nos données sont-elles stockées ? | Dans la base de données MySQL ou MariaDB que vous exploitez, et dans le dossier persistant de votre instance. AnsibleForms est auto-hébergé, sans service cloud derrière. |
+| Envoie-t-il des données à ses auteurs ? | Non. Il n'y a ni télémétrie, ni remontée d'usage, ni vérification de mises à jour. |
+| À quoi se connecte-t-il ? | Uniquement aux systèmes qu'un administrateur configure : voir [Connexions sortantes](measures.html#outbound-connections). |
+| Utilise-t-il l'IA ou envoie-t-il des données à un fournisseur de modèles ? | Uniquement avec l'[assistant de chat](../chat/) activé, qui est désactivé par défaut. Il envoie alors les définitions de formulaire et les valeurs en cours de saisie au fournisseur que vous configurez. |
+| Peut-il fonctionner sans accès à internet ? | Oui. L'application n'a pas besoin d'accès à internet ; les playbooks ont besoin de ce que leurs tâches atteignent. |
+
+---
+
+## Chiffrement
+
+Ce qui est chiffré, et avec quelles clés :
+
+| Question | Réponse |
+|---|---|
+| Les données sont-elles chiffrées en transit ? | Avec [HTTPS](../security/https.html), servi par l'application ou par votre reverse proxy, et `wss://` entre l'application et ses environnements d'exécution. |
+| Les données sont-elles chiffrées au repos ? | Chaque secret stocké est chiffré par l'application en AES-256. Les jobs et leur sortie sont stockés tels quels : utilisez le chiffrement au repos propre à la base de données. Voir [Secrets stockés](measures.html#stored-secrets). |
+| Qui détient les clés ? | Vous : le [`ENCRYPTION_SECRET`](../security/secrets.html) est défini par vous, tenu à l'écart des sauvegardes, et peut faire l'objet d'une rotation. |
+| Les secrets peuvent-ils rester dans notre coffre ? | Oui : [HashiCorp Vault et CyberArk](../secret-stores/) sont lus quand un job en a besoin. |
+
+---
+
+## Accès et traçabilité
+
+Qui peut se connecter, ce qu'il peut faire, et ce qui est enregistré :
+
+| Question | Réponse |
+|---|---|
+| Prend-il en charge l'authentification unique ? | Oui : LDAP / Active Directory, OpenID Connect et Entra ID. Voir [Authentification](../authentication/). |
+| Prend-il en charge l'authentification multifacteur ? | Via l'authentification unique : la MFA de votre fournisseur d'identité s'applique. Les comptes locaux n'en ont pas en propre. |
+| Comment les autorisations sont-elles gérées ? | Avec des rôles associés à des groupes, vérifiés par le serveur à chaque requête. Voir [Autorisations](measures.html#permissions). |
+| Y a-t-il un journal d'audit ? | Oui : chaque modification et chaque tentative refusée, conservées 365 jours par défaut et transférables vers syslog. Voir [Piste d'audit](measures.html#audit-trail). |
+| Y a-t-il un mot de passe par défaut ? | Le premier compte admin a un mot de passe par défaut public, qui doit être changé à la première connexion. Voir [Le compte admin](../security/hardening.html#the-admin-account). |
+
+---
+
+## Vulnérabilités et mises à jour
+
+Comment les problèmes sont trouvés, corrigés et annoncés :
+
+| Question | Réponse |
+|---|---|
+| Des vulnérabilités ont-elles été trouvées ? | Oui. Chacune de celles publiées est listée dans [Avis de sécurité](advisories.html), avec la version qui l'a corrigée. |
+| Comment en signaler une ? | En privé, via GitHub : voir [Signaler une vulnérabilité](reporting.html). |
+| Comment le code est-il vérifié ? | Analyse statique CodeQL et revue des dépendances sur chaque pull request, tests automatisés et mises à jour Dependabot. Voir [Développement sécurisé](development.html). |
+| Quelles versions reçoivent des correctifs de sécurité ? | 7.x et 6.5.x. Voir [Versions prises en charge](development.html#supported-versions). |
+| Comment apprendre la publication d'un nouvel avis ? | Suivez les alertes de sécurité du dépôt sur GitHub. Voir [Être informé des nouveaux avis](advisories.html#being-told-of-new-advisories). |
+| A-t-il fait l'objet d'un test d'intrusion ? | Aucun rapport de test d'intrusion tiers n'est publié. Le code est public : votre propre équipe ou votre testeur peut donc l'évaluer, et les découvertes sont signalées comme indiqué ci-dessus. |
+
+---
+
+## Images et chaîne d'approvisionnement
+
+D'où viennent les images, et comment les vérifier :
+
+| Question | Réponse |
+|---|---|
+| Où les images sont-elles publiées ? | Sur le GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, construites par des workflows GitHub Actions publics. Voir [Versions et images](development.html#releases-and-images). |
+| Les conteneurs s'exécutent-ils en root ? | Non : avec l'utilisateur non privilégié `node`. |
+| Les images sont-elles signées ? | Pas encore. Récupérez-les par digest (`@sha256:...`) pour être sûr d'exécuter l'image que vous avez examinée. |
+| Y a-t-il un SBOM ? | Aucun n'est encore publié avec les images. Un scanner comme Trivy ou Syft en construit un à partir de l'image. |
+| Les images sont-elles analysées à la recherche de vulnérabilités ? | Pas dans le pipeline de release. Leurs images de base sont épinglées par digest et maintenues à jour par Dependabot ; analysez les images dans votre propre registre pour appliquer votre propre politique. |
+| Sous quelle licence est-il distribué ? | GPL-3.0, open source, sans garantie. |
diff --git a/i18n/fr/_security_assessment/security-assessment/index.md b/i18n/fr/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..fb1c16f
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Vue d'ensemble
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Évaluation de la sécurité
+{: .no_toc }
+
+Pour les revues de sécurité : mesures, développement et avis
+{: .fs-6 .fw-300 }
+
+---
+
+## En bref
+
+AnsibleForms exécute des playbooks et détient leurs identifiants : il fait donc partie de votre chaîne de confiance :
+
+* Il est **auto-hébergé** : il tourne sur votre infrastructure, garde ses données dans votre base de données et n'envoie rien à ses auteurs.
+* Il est **open source** (GPL-3.0) : le code, ses pipelines et chaque avis sont publics.
+* Chaque secret stocké est **chiffré**, chaque modification **auditée**, et les **rôles** sont vérifiés à chaque requête.
+* Les vulnérabilités sont **signalées en privé**, corrigées dans chaque version prise en charge, et **publiées**.
+
+---
+
+## Dans cette section
+
+Les pages répondent aux questions d'une revue de sécurité, de la conception à la liste des CVE :
+
+| Page | Contenu |
+|---|---|
+| [Mesures de sécurité](measures.html) | Connexion, autorisations, secrets stockés, piste d'audit, navigateur, serveur, connexions et conteneurs |
+| [Développement sécurisé](development.html) | Comment une modification est relue et testée, analyse du code et des dépendances, construction des images, versions prises en charge |
+| [Signaler une vulnérabilité](reporting.html) | Comment signaler un problème en privé, et ce qui se passe ensuite |
+| [Avis de sécurité](advisories.html) | Chaque vulnérabilité publiée, avec sa CVE, sa gravité et la version corrigée |
+| [FAQ de l'évaluation](faq.html) | Des réponses courtes aux questions les plus fréquentes des questionnaires de sécurité |
+
+Pour sécuriser une instance plutôt que l'évaluer, voir [Sécurité](../security/) dans le guide de l'administrateur.
diff --git a/i18n/fr/_security_assessment/security-assessment/measures.md b/i18n/fr/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..822afaf
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Mesures de sécurité
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Mesures de sécurité
+{: .no_toc }
+
+Comment la connexion, les autorisations, les secrets et les connexions sont protégés
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Où il s'exécute
+
+AnsibleForms est auto-hébergé, sur votre infrastructure, avec ses données dans une base de données que vous exploitez.
+
+* Il n'y a ni service cloud AnsibleForms ni serveur de licences, et aucune télémétrie ni vérification de mises à jour.
+* L'interface est servie par l'application elle-même et ne charge rien depuis un autre site.
+* L'application ne se connecte qu'aux systèmes qu'un administrateur configure, listés dans [Connexions sortantes](#outbound-connections).
+
+Les composants et ce que chacun contient :
+
+| Composant | Ce qu'il fait | Ce qu'il contient |
+|---|---|---|
+| Application | L'interface web, l'API REST, le planificateur | Aucune donnée propre : tout est dans la base de données |
+| MySQL ou MariaDB | La base de données de l'application | Les utilisateurs, les groupes, les identifiants (chiffrés), les jobs avec leurs extravars et leur sortie, le journal d'audit |
+| Environnement d'exécution (RTE) | Exécute les playbooks, dans son propre conteneur | Les fichiers des jobs qu'il exécute, et les secrets d'un job uniquement pendant l'exécution de ce job |
+| Dossier persistant | La configuration, les formulaires, les playbooks et les fichiers envoyés | Les fichiers qu'utilisent les formulaires et les playbooks |
+
+Voir [Fonctionnement](../how-it-works.html) pour la vue d'ensemble, et [RTE](../rte/) pour l'environnement d'exécution.
+
+---
+
+## Connexion
+
+Chaque page et chaque appel d'API qui lit ou modifie des données exige un utilisateur connecté. Les quelques points de terminaison ouverts sans connexion servent
+la connexion elle-même, la version, le nom et le logo de l'instance, la documentation de l'API, et la mise en place de la base de données lors d'un premier démarrage,
+que [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` ferme :
+
+| Méthode | Fonctionnement |
+|---|---|
+| Comptes locaux | Mots de passe hachés avec bcrypt, une [longueur minimale](../security/hardening.html#sign-in-limits-and-passwords), et le mot de passe admin par défaut, public, doit être changé à la première connexion |
+| LDAP / Active Directory | L'annuaire vérifie le mot de passe, et ses groupes sont associés à des rôles. Voir [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Authentification unique via votre fournisseur d'identité, qui apporte aussi sa propre authentification multifacteur. Voir [Authentification](../authentication/) |
+
+* Les échecs de connexion [verrouillent le compte](../security/hardening.html#sign-in-limits-and-passwords), et la connexion est limitée en débit.
+* Une connexion renvoie un jeton d'accès signé valable 30 minutes et un jeton de rafraîchissement valable 24 heures.
+* Les jetons peuvent prendre fin avant leur expiration : la déconnexion, un changement de mot de passe, un utilisateur bloqué et un jeton d'API révoqué y mettent fin sur
+  tous les nœuds à la fois, voir [Jetons](../security/secrets.html#tokens).
+* AnsibleForms n'a pas d'authentification multifacteur propre : utilisez l'authentification unique là où elle est exigée.
+
+---
+
+## Autorisations
+
+Ce qu'un utilisateur peut faire découle des rôles de ses groupes, vérifiés par le serveur à chaque requête :
+
+* Les rôles sont définis dans [config.yaml](../config/roles.html) : quels formulaires un utilisateur voit, et de quelles options il dispose,
+  comme le concepteur, les pages de paramètres ou les jobs des autres utilisateurs.
+* Le serveur vérifie chaque lancement au regard des règles du formulaire (ses champs, leurs valeurs et l'accès de l'utilisateur), y compris
+  les lancements via l'API REST, voir [Validation au lancement](../launch-validation/).
+* Le rôle admin exécute n'importe quel playbook, par conception. Les autres rôles n'obtiennent que ce qui leur est accordé : un utilisateur qui a plusieurs rôles n'obtient une
+  option que si aucun de ces rôles ne la refuse ; un seul rôle restrictif suffit donc à la retenir.
+
+---
+
+## Secrets stockés
+
+Les mots de passe, jetons et clés sont chiffrés avant d'être écrits dans la base de données :
+
+* Chaque secret stocké (identifiants, mot de passe de bind LDAP, jetons des runners, secrets client de l'authentification unique, adresses de
+  webhook et clés d'API) est chiffré en AES-256 avec un vecteur d'initialisation aléatoire par valeur, sous le
+  [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) que vous définissez.
+* Aucun appel d'API ni aucune page de paramètres n'affiche un secret stocké, et les sauvegardes omettent les secrets maîtres.
+* Les secrets peuvent rester dans votre coffre : [HashiCorp Vault et CyberArk](../secret-stores/) sont lus quand un job en a besoin.
+* Les secrets d'un job parviennent à l'environnement d'exécution scellés en AES-256-GCM, sous une clé dérivée de son jeton.
+* Les extravars dont le nom ressemble à un secret sont masquées dans la vue du job, et les champs mot de passe le sont toujours, voir [Données des jobs](../security/hardening.html#job-data).
+
+Le reste de la base de données (les jobs, leurs extravars et leur sortie) est stocké tel quel : protégez-le avec le chiffrement au repos
+et le contrôle d'accès propres à la base de données, voir [La base de données](../security/hardening.html#the-database).
+
+---
+
+## Piste d'audit
+
+Chaque modification, et chaque tentative refusée, est enregistrée :
+
+* Chaque création, modification et suppression, via l'interface ou l'API, est écrite dans le journal d'audit avec l'utilisateur, son
+  adresse, l'action, l'objet et le résultat. Les refus et les connexions sont aussi enregistrés, y compris les échecs.
+* Les valeurs qui ressemblent à des secrets sont masquées avant d'être écrites.
+* Le journal est conservé 365 jours par défaut, et peut être copié vers syslog via UDP, TCP ou TLS.
+
+---
+
+## Dans le navigateur
+
+L'interface est protégée contre le code injecté dans une page :
+
+* Une [Content-Security-Policy](../security/hardening.html#the-content-security-policy) n'autorise que les scripts et les frames de l'application elle-même.
+* Chaque réponse porte des en-têtes de protection : nosniff, protection contre l'intégration en frame, et HSTS en HTTPS.
+* Le HTML des formulaires, des textes d'aide et des réponses du chat est assaini, et la sortie des jobs est échappée.
+
+---
+
+## Sur le serveur
+
+Le code qui traite les saisies des utilisateurs évite les injections classiques :
+
+* Les requêtes de base de données passent leurs valeurs en paramètres, jamais sous forme de texte collé dans la requête.
+* Les commandes, git compris, s'exécutent à partir d'une liste d'arguments, jamais d'un shell : les caractères du shell n'ont donc aucun effet.
+* Les expressions serveur passent par un [filtre d'expressions](../security/hardening.html#expressions-and-outbound-calls), et leurs appels REST par un filtre d'hôtes.
+* Le [serveur MCP](../mcp/), l'[assistant de chat](../chat/) et le point de terminaison des métriques sont désactivés jusqu'à ce que vous les activiez.
+
+---
+
+## Connexions
+
+Le trafic vers et depuis AnsibleForms peut être chiffré de bout en bout :
+
+* L'application sert elle-même le [HTTPS](../security/https.html), ou se place derrière votre reverse proxy.
+* Un environnement d'exécution communique avec l'application via un WebSocket, `wss://` avec une adresse HTTPS, et l'application
+  épingle le certificat d'un environnement entrant, voir [Modes du RTE](../rte/modes.html).
+* LDAP, l'authentification unique, les runners, git, les coffres de secrets et les appels REST des expressions vérifient le certificat du
+  serveur qu'ils atteignent, sauf si un administrateur désactive la vérification pour un serveur au certificat auto-signé.
+
+### Connexions sortantes
+
+AnsibleForms ne se connecte qu'à ce qu'un administrateur configure :
+
+| Connexion | Quand |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (connexion Microsoft et Graph) | Quand cette méthode de connexion est configurée |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Quand un formulaire s'exécute sur ce runner |
+| Serveurs git | Quand un dépôt est configuré |
+| Serveur de messagerie, Slack, Teams, Telegram, webhooks | Quand un canal de notification est configuré |
+| HashiCorp Vault, CyberArk | Quand un coffre de secrets est configuré |
+| Un fournisseur de modèles (Anthropic, OpenAI et d'autres) | Uniquement avec l'[assistant de chat](../chat/) activé, qui est désactivé par défaut |
+| Les hôtes et API nommés dans les formulaires | Quand les expressions d'un formulaire ou un playbook les appellent |
+| Serveurs syslog | Quand le transfert de l'audit ou des journaux est configuré |
+
+---
+
+## Les conteneurs
+
+Les images sont construites pour s'exécuter avec le moins de privilèges possible :
+
+* L'application et l'environnement d'exécution s'exécutent avec l'utilisateur non privilégié `node`, pas en root.
+* Elles sont construites sur des images Debian slim épinglées par digest, voir [Développement sécurisé](development.html#code-analysis-and-dependencies).
+* L'application écoute sur un seul port, 8000.
+
+Pour les étapes qui sécurisent une nouvelle instance, suivez [Durcissement](../security/hardening.html).
diff --git a/i18n/fr/_security_assessment/security-assessment/reporting.md b/i18n/fr/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..38bd5b0
--- /dev/null
+++ b/i18n/fr/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Signaler une vulnérabilité
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Signaler une vulnérabilité
+{: .no_toc }
+
+Comment signaler un problème de sécurité en privé, et ce qui se passe ensuite
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le signaler en privé
+
+AnsibleForms détient des identifiants et des jetons de coffre : ne signalez donc jamais un problème de sécurité dans une issue publique :
+
+1. Ouvrez **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)** : un avis privé que seuls les mainteneurs voient.
+2. Si cette page ne vous est pas accessible, ouvrez une issue normale qui dit seulement que vous avez un signalement de sécurité et demande
+   un canal privé : pas de détails, pas de reproduction, pas de numéros de version. Un mainteneur ouvre un avis privé et
+   vous y invite.
+
+La politique complète est le [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) du dépôt.
+
+---
+
+## Ce qu'il faut inclure
+
+Plus un signalement fournit d'éléments, plus vite le problème est corrigé :
+
+* Ce qu'un attaquant y gagne : les données d'un autre utilisateur, un playbook qu'il n'a pas le droit d'exécuter, l'hôte, ou des droits admin.
+* La version, et la façon dont elle est déployée : Docker, Kubernetes, ou installation native.
+* Une reproduction, ou la requête qui le déclenche.
+* S'il faut un utilisateur connecté, et avec quelles [options de rôle](../config/roles.html).
+
+---
+
+## Ce qui se passe ensuite
+
+Un signalement passe par le même avis privé, du premier message à la publication :
+
+| Étape | Ce que vous obtenez |
+|---|---|
+| Accusé de réception | La confirmation que le signalement est arrivé, et s'il se reproduit |
+| Accepté | Un correctif dans la prochaine version de chaque [version prise en charge](development.html#supported-versions), et un avis publié qui vous mentionne, sauf si vous préférez ne pas être nommé |
+| Refusé | Le raisonnement, en général que le comportement exige une autorisation que l'auteur du signalement avait déjà |
+
+Une fois le correctif publié, l'avis est publié et apparaît dans [Avis de sécurité](advisories.html).
+
+---
+
+## Périmètre
+
+La politique trace la limite là où le modèle de rôles la trace :
+
+| Dans le périmètre | Hors périmètre |
+|---|---|
+| Tout ce qu'un utilisateur connecté peut atteindre au-delà de ce que son rôle lui accorde | Les découvertes qui supposent que le compte admin est déjà compromis : un admin qui exécute n'importe quel playbook, c'est le produit |
+| Tout ce qui est accessible sans connexion | Les rapports de scanner sans impact démontré |
+| Des identifiants stockés qui deviennent lisibles, ou écrits dans un journal | |
+| Une injection dans le shell, la base de données ou le navigateur | |
diff --git a/i18n/fr/_use/designer/index.md b/i18n/fr/_use/designer/index.md
new file mode 100644
index 0000000..9465acd
--- /dev/null
+++ b/i18n/fr/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Concepteur
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Concepteur
+{: .no_toc }
+
+Modifier des formulaires, des playbooks, des inventaires et des workflows dans le navigateur
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour les auteurs de formulaires : les sections du concepteur, et ce que montre chacun de leurs onglets.
+
+Le concepteur nécessite l'[option de rôle](../config/roles.html#role-options) `showDesigner`. Il modifie un élément à la fois, un
+formulaire, un playbook ou un fichier de workflow, avec ses sections dans le menu de gauche. Chaque type de fichier nécessite aussi sa propre option, toutes
+activées par défaut : `allowPlaybookDesign` pour les **Playbooks**, `allowWorkflowDesign` pour les **Workflows**,
+`allowInventoryDesign` pour les **Inventaires** et `allowVarsFileDesign` pour les **Fichiers de variables**. Sans elle, sa section est
+en lecture seule et le serveur refuse d'enregistrer, créer, supprimer ou pousser ses fichiers ; les formulaires et les workflows peuvent toujours les choisir. Les sections
+**Formulaires**, **Catégories** et **Constantes** nécessitent de la même façon `allowFormDesign` : sans elle, elles sont en lecture seule, et le serveur
+refuse de les enregistrer, de les tirer ou de les pousser. Une seule personne modifie à la fois : voir [Le verrou du concepteur](lock.html).
+
+---
+
+## Ses sections
+
+Chaque section modifie un type de fichier, conservé localement ou dans un [dépôt](../repositories/) :
+
+| Section | Ce qu'elle modifie |
+|---|---|
+| **Formulaires** | Les fichiers de formulaires |
+| **Catégories** | Les catégories de `config.yaml` |
+| **Constantes** | Les constantes de `config.yaml` |
+| **Fichiers de variables** | Les fichiers de variables que chargent les formulaires |
+| **Playbooks** | Les playbooks qu'exécutent les formulaires et les workflows |
+| **Inventaires** | Les inventaires : `inventory.yaml`, `group_vars` et `host_vars` |
+| **Workflows** | Les fichiers de [workflow](../workflows/) |
+
+Les sections qui ont des fichiers les listent dans un explorateur de fichiers et ouvrent le premier ; une section qui n'a pas encore de fichiers l'indique. La
+section **Formulaires** et chaque section de fichiers ont un bouton **Nouveau fichier** en tête de leur barre d'outils : dans les Inventaires il crée un nouvel
+inventaire, dans les Workflows un nouveau workflow vide. La loupe de l'explorateur ouvre une zone qui filtre ses fichiers par nom.
+
+La zone de recherche de la ligne de titre trouve un texte dans le YAML ouvert : elle marque chaque endroit où il apparaît. Elle fonctionne dans
+l'onglet **YAML**, une fois que le verrou du concepteur est à vous.
+
+---
+
+## Ses onglets
+
+Chaque section a les trois mêmes onglets, tous sur le même YAML : une modification dans l'un apparaît dans les autres, et **Enregistrer** l'enregistre.
+
+- **YAML** est le fichier tel qu'il est écrit.
+- **Visuel** le modifie avec des champs. Seules les clés touchées par une modification changent : les commentaires et le reste restent tels qu'ils sont écrits.
+- **Aperçu** montre ce qu'il fait, et ne modifie rien.
+
+Ce que montrent les onglets Visuel et Aperçu, section par section :
+
+| Section | Visuel | Aperçu |
+|---|---|---|
+| **Formulaires** | Les réglages du formulaire et ses champs, avec des listes des playbooks, inventaires et workflows du concepteur | Le formulaire tel qu'il est maintenant, modifications non enregistrées comprises ; sa soumission n'exécute rien |
+| **Catégories** | Les catégories sous forme de tableau, modifiable | Le menu de la page Formulaires, construit à partir d'elles |
+| **Constantes** | Les constantes sous forme d'arborescence, modifiable (une clé se déplace avec les touches fléchées) | Chaque constante avec sa référence, `$(NAME)`, à copier, et les formulaires qui l'utilisent |
+| **Fichiers de variables** | Les variables, modifiables | Chaque variable avec sa référence dans un playbook, {% raw %}`{{ name }}`{% endraw %}, à copier, et les formulaires qui chargent le fichier |
+| **Playbooks** | Les plays : le nom, les hosts, **Become**, **Collecter les facts** et les rôles de chaque play, et ses tâches, chacune avec son module et ses arguments | Le plan du playbook : ses plays, avec leurs hosts, rôles et tâches, et les playbooks qu'il importe |
+| **Inventaires** | Les groupes, leurs groupes enfants, leurs hôtes, et les variables que chacun définit | L'inventaire sous forme d'arbre, avec ses `group_vars` et `host_vars` |
+| **Workflows** | Le graphe du workflow, pour le [modifier](../workflows/designer.html) | Une [exécution à blanc](../workflows/designer.html#trying-it-out) : cliquez sur un nœud pour le faire échouer |
+
+Quand le YAML ne peut pas être lu, les onglets Visuel et Aperçu en indiquent la raison, avec **Voir en YAML** pour ouvrir le YAML à la ligne concernée.
diff --git a/i18n/fr/_use/designer/lock.md b/i18n/fr/_use/designer/lock.md
new file mode 100644
index 0000000..91bdce1
--- /dev/null
+++ b/i18n/fr/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: Le verrou du concepteur
+parent: Concepteur
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# Le verrou du concepteur
+{: .no_toc }
+
+Une seule personne modifie à la fois
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Prendre le verrou
+
+Le concepteur est désactivé tant que vous ne l'activez pas, avec l'interrupteur en haut à droite du concepteur. L'activer prend le
+verrou : dès lors, vous êtes le seul à pouvoir enregistrer, jusqu'à ce que vous le désactiviez de nouveau.
+
+Sans le verrou, le concepteur affiche **Le designer n'est pas actif**, et rien ne peut être modifié.
+
+Les enregistrements ne se chevauchent jamais : depuis la 7.3.0, pendant qu'un enregistrement, un push ou un chargement est en cours, un second **Enregistrer** (un double clic, ou Ctrl+S maintenu) est
+ignoré : il ne peut donc pas écrire une seconde sauvegarde ou un second commit en concurrence avec le premier.
+
+---
+
+## Quand quelqu'un d'autre l'a
+
+Pendant qu'un autre utilisateur détient le verrou, le concepteur affiche **Le designer est utilisé par** cet utilisateur, et rien d'autre : ni sections,
+ni fichiers.
+
+L'interrupteur apparaît activé mais grisé, avec **Verrouillé par** et le nom de l'utilisateur à côté. Vous pouvez prendre le verrou dès qu'il
+désactive le concepteur. Chaque concepteur ouvert le voit aussitôt quand le verrou est pris ou libéré, sans rechargement.
+
+Quand deux utilisateurs activent le concepteur au même moment, l'un d'eux obtient le verrou. Depuis la 7.3.0, l'autre voit qui le détient
+et chaque éditeur reste en lecture seule : rien ne peut être saisi qui ne pourrait pas être enregistré.
+
+---
+
+## Libérer le verrou de quelqu'un
+
+Un admin peut libérer un verrou détenu par quelqu'un d'autre, par exemple quand cette personne est rentrée chez elle en laissant le concepteur ouvert.
+
+**Libérer**, à côté de **Verrouillé par**, n'apparaît que pour les admins. Une confirmation est demandée d'abord : les modifications non enregistrées de l'utilisateur sont perdues.
+
+Depuis la 7.3.0, l'utilisateur dont le verrou a été libéré en est informé, ainsi que de l'auteur : **Votre verrou du concepteur a été libéré par** le nom de l'admin,
+avec **Les modifications non enregistrées ne peuvent plus être enregistrées.** Son concepteur ne reprend pas le verrou de lui-même ; il le réactive
+quand il veut continuer.
+
+---
+
+## Un verrou oublié
+
+Un verrou que personne n'utilise se libère tout seul : personne n'attend ainsi un concepteur que personne n'a ouvert.
+
+Le concepteur ouvert du détenteur signale sans cesse au serveur qu'il est toujours là. Quand le serveur n'a plus de nouvelles depuis
+5 minutes, parce que le navigateur a été fermé, que l'ordinateur s'est éteint ou que le réseau a disparu, le verrou est de nouveau libre. Quand
+le détenteur revient au concepteur, celui-ci reprend le verrou si personne d'autre ne l'a pris. La libération par un admin est l'exception : le
+verrou n'est pas repris après elle.
diff --git a/i18n/fr/_use/jobs/actions.md b/i18n/fr/_use/jobs/actions.md
new file mode 100644
index 0000000..6d7c0c0
--- /dev/null
+++ b/i18n/fr/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Actions sur les jobs
+parent: Jobs
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Actions sur les jobs
+{: .no_toc }
+
+Lancer, arrêter, relancer, approuver ou rejeter, et supprimer un job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lancer un job
+
+Chaque job part d'un formulaire. Ouvrez-le depuis la page **Formulaires**, remplissez les champs et cliquez sur **Soumettre** :
+
+1. Le formulaire est validé dans le navigateur, et les valeurs des champs sont envoyées au serveur.
+2. Le serveur crée le job et renvoie son numéro ; les actions [`onSubmit`](../forms/job-status-action.html) du formulaire s'exécutent.
+3. La sortie du job apparaît sous le formulaire et se rafraîchit toutes les deux secondes jusqu'à la fin du job.
+
+Le job apparaît aussi sur la page **Jobs**, où vous pouvez le suivre plus tard.
+
+### Qui peut lancer un formulaire
+
+Un formulaire est listé, et peut être lancé, pour les utilisateurs qui ont l'un des [rôles](../config/roles.html) de sa liste `roles`.
+Le rôle `default`, que tout utilisateur possède, rend un formulaire accessible à tous ceux qui peuvent se connecter.
+
+### Avant de soumettre
+
+La barre au-dessus des champs propose quelques outils, chacun affiché uniquement si votre rôle le permet :
+
+| Bouton | Ce qu'il fait | Option de rôle |
+|---|---|---|
+| **Afficher les variables supplémentaires** | Affiche un aperçu des extravars que recevra le job, au fur et à mesure que vous remplissez les champs | `showExtraVars` |
+| **Verbeux** | Exécute le job en mode verbeux | `allowVerboseMode` |
+| **Charger depuis le stockage** | Remplit les champs à partir d'un [job enregistré](stored-jobs.html) | `allowStoredJobs` |
+| **Recharger ce formulaire** | Recharge le formulaire, avec ses valeurs par défaut | aucune |
+
+### Choix au moment du lancement
+
+Un formulaire peut laisser ses utilisateurs choisir certaines options Ansible au lancement, en déclarant un champ avec un nom réservé. La
+valeur du champ remplace alors le réglage propre au formulaire :
+
+| Nom du champ | Remplace | Type de champ habituel |
+|---|---|---|
+| `__check__` | Le mode check, une exécution à blanc qui ne change rien | `checkbox` |
+| `__diff__` | Le mode diff, qui montre ce qui changerait | `checkbox` |
+| `__limit__` | Les hôtes sur lesquels le playbook s'exécute | `text` ou `enum` |
+| `__tags__` | Les tags à exécuter | `text` ou `enum` |
+| `__inventory__` | L'inventaire | `enum` |
+| `__playbook__`, `__template__` | Le playbook, ou le template AWX / AAP | `enum` |
+
+Par exemple, un formulaire qui propose une exécution à blanc et une limite d'hôtes :
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+Le serveur n'accepte ces noms que d'un formulaire qui les déclare comme champs : un lancement depuis l'API ne peut donc pas les ajouter de
+lui-même. Les propriétés qu'ils remplacent sont décrites dans [Formulaires Ansible](../forms/ansible.html) et [Formulaires AWX](../forms/awx.html).
+
+### Ce qui peut empêcher un lancement
+
+Un lancement ne devient pas toujours immédiatement un job en cours :
+
+* **Champs invalides** : le formulaire n'est pas soumis, et chaque champ qui échoue à sa validation en indique la raison.
+* **Validation au lancement** : avec la [validation au lancement](../launch-validation/) réglée sur `enforce`, le serveur vérifie de nouveau les valeurs
+  et refuse un lancement qui enfreint les règles du formulaire.
+* **Approbation** : un formulaire avec un [point d'approbation](../forms/approval.html) crée le job, qui attend ensuite au statut
+  `approve` ; voir [Approuver ou rejeter un job](#approve-or-reject-a-job).
+
+Quand le job se termine, les [notifications](../forms/notifications.html) du formulaire envoient leurs mails et leurs messages sur les canaux, et ses actions
+sur statut de job s'exécutent.
+
+### Autres façons de démarrer un job
+
+Un formulaire peut aussi démarrer un job sans que personne ne clique sur **Soumettre** :
+
+| Démarré par | Comment | Page |
+|---|---|---|
+| Une exécution ultérieure ou une planification cron | **Exécuter plus tard (une seule fois)** ou **Planifier (récurrent)** à côté de **Soumettre** | [Planifications](schedules.html) |
+| Un script ou un pipeline | `POST /api/v2/job` avec un jeton d'API | [Jobs de l'API REST](../api/jobs.html) |
+| Un agent IA | L'outil `launch_job` du serveur MCP | [Outils MCP](../mcp/tools.html) |
+| Une conversation | L'assistant de chat remplit le formulaire et le lance | [Assistant de chat](../chat/) |
+| Un job précédent | **Relancer**, ci-dessous | [Relancer un job](#relaunch-a-job) |
+
+---
+
+## Arrêter un job
+
+**Arrêter** dans le menu de la ligne (⋮) de la liste, ou **Arrêter le job** sur la page du job, arrête un job au statut `running`. Après votre confirmation,
+AnsibleForms marque le job pour l'arrêt :
+
+* **`ansible`** : le RTE arrête le processus du playbook (avec tous ses workers), et le job se termine en `aborted` avec
+  `... was aborted by the operator`. Un job qui attend encore un RTE libre est arrêté avant de démarrer.
+* **Un job de template** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins) : AnsibleForms demande au runner d'annuler ou d'arrêter
+  le job, et le job se termine en `aborted`. Quand le runner refuse, la sortie affiche `Abort request denied`, suivi de
+  `reverting abort request`, et le job continue de s'exécuter. Un build Jenkins encore en file d'attente en est retiré.
+* **`workflow`** : les jobs des nœuds en cours sont arrêtés et plus rien ne démarre (voir
+  [Exécuter un workflow](../workflows/running.html#abort)).
+* **`multistep`** : les étapes qui n'ont pas encore démarré sont ignorées (`skipping: [Abort is requested]`), et le job principal
+  se termine en `aborted`. Une étape déjà en cours est un job à part entière : ouvrez-la et arrêtez-la pour l'arrêter elle aussi.
+
+Vous pouvez arrêter vos propres jobs ; un admin, ou depuis la 7.3.0 un utilisateur dont le rôle définit `manageAllJobs`, peut arrêter n'importe quel job. `showAllJobLogs` permet à un
+utilisateur de voir les jobs des autres utilisateurs, pas de les arrêter.
+
+---
+
+## Relancer un job
+
+**Relancer** dans le menu de la ligne (⋮) de la liste, ou **Relancer le job** sur la page du job, démarre un nouveau job à partir d'un job terminé. C'est proposé sur tout
+job qui n'est ni `running` ni en attente d'approbation, aux utilisateurs dont le rôle définit l'option de rôle `allowJobRelaunch`.
+
+La boîte de dialogue propose :
+
+* **Relancer** : exécute de nouveau le job avec les valeurs avec lesquelles il s'est exécuté, comme nouveau job à votre nom.
+* **Mode verbeux** : relance en mode verbeux ; affiché avec l'option de rôle `allowVerboseMode`.
+* **Modifier les valeurs avant de relancer**, puis **Modifier et relancer** : ouvre le formulaire pré-rempli avec les valeurs du job, pour que vous
+  puissiez les changer avant de soumettre.
+
+Une relance exige aussi que le formulaire l'autorise (`allowRelaunch`, true par défaut) et que le job soit **le vôtre**, sauf
+si vous êtes admin ou, depuis la 7.3.0, disposez de `manageAllJobs` ; `showAllJobLogs`, qui permettait de relancer n'importe quel job jusqu'à la 7.2, ne le permet plus. La façon dont une relance est vérifiée au regard des règles du formulaire, et pourquoi un formulaire avec un
+champ mot de passe peut la refuser, est décrite dans [Relancer](../launch-validation/relaunching.html).
+
+### Relancer avec des données pré-remplies
+
+**Modifier et relancer** ouvre le formulaire avec le paramètre d'URL `prefillJobId`, que vous pouvez aussi utiliser dans un lien à vous :
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+Le formulaire charge les valeurs de champ stockées avec le job `61` et affiche `Formulaire prérempli avec les données de la tâche précédente #61`.
+Le soumettre démarre un nouveau job, vérifié comme tout autre lancement. Le pré-remplissage suit les mêmes règles qu'une relance :
+
+* **Les champs mot de passe ne sont jamais stockés**, ils ne sont donc jamais pré-remplis : saisissez-les de nouveau. Les constantes ne sont pas stockées non plus.
+* L'option de rôle `allowJobRelaunch` est requise, et le job doit être le vôtre (ou vous êtes admin ou disposez de `manageAllJobs`).
+* Un formulaire avec `allowRelaunch: false` ne peut être ni relancé ni pré-rempli :
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Un job antérieur au stockage des valeurs de champ ne peut pas être pré-rempli, et le formulaire affiche plutôt une erreur :
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Approuver ou rejeter un job
+
+Un job avec un [point d'approbation](../forms/approval.html) s'arrête au statut `approve` et attend. Il est listé sur la page Jobs de
+ses approbateurs, les utilisateurs qui ont l'un des rôles de l'approbation, pour qu'ils puissent le trouver ; depuis la 7.3.0, les autres utilisateurs ne le voient plus.
+
+**Examiner l'approbation** est proposé aux admins et aux utilisateurs qui ont l'un des rôles de l'approbation : un clic sur la ligne du job,
+**Examiner l'approbation** dans le menu de la ligne, ou le bouton **Examiner l'approbation** sur la page du job. La boîte de dialogue affiche le
+message de l'approbation, avec les valeurs du job insérées (ou une ligne générique s'il n'y en a pas), ainsi que le formulaire, l'id du job, qui l'a lancé et
+quand, avec un lien vers le job ; **Rejeter** et **Approuver** y répondent :
+
+* **Approuver** : le job continue et son statut repasse à `running`.
+* **Rejeter** : le job se termine en `rejected`, et sa sortie enregistre `rejected by <username>`.
+
+Un job en attente d'approbation ne peut être ni relancé ni supprimé depuis la page Jobs ; approuvez-le ou rejetez-le d'abord.
+
+Depuis la 7.3.0, l'utilisateur qui a lancé un job ne peut pas l'approuver : une deuxième personne l'examine donc toujours, mais il peut toujours le rejeter pour
+le retirer. Un admin peut toujours approuver, y compris ses propres jobs. Un formulaire dont le point d'approbation définit
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) permet aussi à celui qui l'a lancé d'approuver son propre job.
+
+---
+
+## Supprimer un job
+
+**Supprimer** dans le menu de la ligne (⋮) de la liste, ou **Supprimer le job** sur la page du job, supprime un job avec sa sortie après votre confirmation.
+Supprimer un job multistep supprime aussi ses étapes. Pour supprimer plusieurs jobs à la fois, cochez-les dans la première colonne de la liste et
+cliquez sur **Supprimer (n)** au-dessus.
+
+Vous pouvez supprimer vos propres jobs. Les admins et, depuis la 7.3.0, les utilisateurs disposant de l'option de rôle `manageAllJobs` peuvent supprimer n'importe quel job ; `showAllJobLogs`
+ne le permet plus. Un rôle qui définit `allowJobDeletion: false` ne supprime aucun job, pas même les siens : l'historique des jobs reste ainsi complet. Sur la page du
+job, le bouton est masqué pendant que le job est en cours ou en cours d'arrêt (sauf pour les admins et `manageAllJobs`) et pendant qu'il attend une approbation ; dans la liste, l'entrée
+du menu et la case à cocher sont grisées pour un job que vous ne pouvez pas supprimer.
diff --git a/i18n/fr/_use/jobs/cleanup.md b/i18n/fr/_use/jobs/cleanup.md
new file mode 100644
index 0000000..e5dc6c4
--- /dev/null
+++ b/i18n/fr/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Nettoyage
+parent: Jobs
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Nettoyage
+{: .no_toc }
+
+Les jobs interrompus par un redémarrage, et la durée de conservation des jobs terminés
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jobs abandonnés
+
+Un job en cours est suivi par le processus AnsibleForms qui l'a démarré. Quand ce suivi s'arrête, le job est marqué
+`abandoned` :
+
+* **Au démarrage**, les jobs que ce processus suivait avant de redémarrer, et les jobs d'avant la 7 qu'aucun processus
+  ne suit, sont marqués abandonnés s'ils sont encore `running` ou en cours d'arrêt ; le journal affiche `Abandoned <n> jobs`. Un job qui
+  s'exécute sur un RTE n'est pas touché : il continue sans le processus qui l'a démarré.
+* **Chaque minute**, les jobs suivis par un autre processus AnsibleForms (ou un RTE) qui a cessé de répondre depuis 2 minutes sont
+  marqués abandonnés ; le journal affiche `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Chaque heure**, les jobs démarrés il y a plus d'un jour, toujours `running` et qui n'ont écrit aucune sortie depuis un jour sont marqués abandonnés.
+  Un job qui s'exécute sur un RTE est laissé tranquille ici aussi : le RTE nettoie ses propres jobs quand il redémarre.
+
+Depuis la 7.3.0, un job de template sur AWX, AAP ou Ascender abandonné à cause d'un redémarrage ou d'un nœud arrêté est repris, s'il a démarré
+dans les dernières 24 heures : un processus AnsibleForms le prend en charge, le suit de nouveau sur le runner, et le job se termine avec ce qui
+s'y est réellement passé. Les jobs sur les autres runners, les playbooks, les workflows et les jobs multistep restent abandonnés.
+
+Un playbook abandonné peut s'être exécuté en partie. Vérifiez les hôtes gérés avant de le relancer ; voir
+[Un job affiche le statut abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Conservation des jobs
+
+Les jobs sont conservés jusqu'à leur suppression, sauf si l'administrateur définit une durée de conservation.
+
+Avec [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) défini, une tâche nocturne (à 2 h 30) supprime
+les jobs terminés, avec leur sortie et leurs étapes, qui se sont terminés il y a plus de ce nombre de jours. Elle ne supprime que les jobs au
+statut `success`, `failed`, `warning`, `aborted`, `rejected` ou `abandoned` : les jobs en cours et les jobs en attente
+d'approbation sont conservés quel que soit leur âge. La valeur par défaut, `0`, conserve tous les jobs.
diff --git a/i18n/fr/_use/jobs/following.md b/i18n/fr/_use/jobs/following.md
new file mode 100644
index 0000000..7ff4adf
--- /dev/null
+++ b/i18n/fr/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Suivre un job
+parent: Jobs
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Suivre un job
+{: .no_toc }
+
+Sortie en direct, extravars, filtres et téléchargements
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Suivre un job
+
+Cliquer sur un job ouvre sa page : le formulaire du job comme titre, ses actions dans l'en-tête et sa sortie en dessous.
+
+![La sortie d'un job](../assets/screenshots/job-output.jpg)
+
+Depuis la 7.3.0, la page est composée de cartes, et chacune se replie sous son en-tête :
+
+| Carte | Ce qu'elle affiche |
+|---|---|
+| **Résumé** | Le nom, le statut et le type du job dans son en-tête, et ses informations en dessous dans une grille de trois colonnes (deux, puis une, sur une page étroite) |
+| **Workflow** | Pour un job de workflow, y compris un job de workflow AWX ou AAP, son graphe et son nombre de nœuds (voir [Le graphe du workflow](#the-workflow-graph)) |
+| **Sortie** | La sortie du job et sa barre d'outils |
+
+Un job exécuté sur AWX, AAP, Ascender, Jenkins, Semaphore ou Rundeck y affiche son numéro sous forme de lien vers sa page dans cet outil, ouvert
+dans un nouvel onglet. Le lien est conservé sur le job : il fonctionne donc toujours si le runner est renommé ou supprimé plus tard.
+
+La page se met à jour en direct : le serveur envoie un événement chaque fois qu'un job est lancé, change de statut, écrit de la sortie ou est
+supprimé, et la page relit le job, si bien que la sortie s'allonge au fur et à mesure que le job l'écrit. La liste des jobs se met à jour de la même façon.
+**Actualiser** recharge le job à la main.
+
+Tant que vous êtes à la fin de la sortie, la page la suit vers le bas à mesure que de nouvelles lignes arrivent. Remontez pour lire une ligne précédente
+et la page reste où vous êtes : **Aller aux dernières** apparaît alors en bas de la sortie, et devient **Nouvelles lignes** dès que
+d'autres sont arrivées. Cliquez dessus, ou redescendez jusqu'à la fin, pour suivre de nouveau les nouvelles lignes. La sortie sur la page du formulaire, après
+**Soumettre**, et le [journal du serveur](../production/logs.html) suivent leurs nouvelles lignes de la même façon.
+
+La barre d'outils de la sortie contient :
+
+| Bouton | Ce qu'il fait |
+|---|---|
+| **Afficher les variables supplémentaires** | Affiche les extravars avec lesquelles le job s'est exécuté dans un panneau au-dessus de la sortie, avec un sélecteur **JSON** / **YAML** et **Copier** |
+| **Afficher les artefacts** | Affiche les artefacts du job dans le même panneau (voir ci-dessous) |
+| **Afficher les paramètres** | Remplace **Afficher les variables supplémentaires** pour un job Jenkins : les valeurs avec lesquelles il s'est exécuté, ses paramètres de build |
+| **Afficher la payload** | Remplace **Afficher les variables supplémentaires** pour un job Rundeck : la payload qui lui a été envoyée |
+| **Hôtes et tâches** | Affiche les hôtes et les tâches d'un playbook au-dessus de sa sortie (voir [Hôtes et tâches](#hosts-and-tasks)) |
+| **Actualiser** | Recharge la sortie |
+| **Appliquer le filtre** | Masque les tâches dont le nom correspond au filtre de sortie ; **Supprimer le filtre** les affiche de nouveau |
+| **Copier la sortie** | Copie la sortie en texte brut, avec ou sans le filtre appliqué |
+| **Télécharger la sortie** | Télécharge la sortie sous le nom `ansibleforms-job-<id>.txt` |
+
+**Afficher les artefacts** est proposé pour tout job qui n'est pas un job de template, comme un playbook sur le RTE ou un workflow (vide quand
+ses playbooks n'ont rassemblé aucun artefact avec `set_stats`), et pour un job de template exécuté sur AWX, AAP ou Ascender. Les jobs Semaphore, Rundeck
+et Jenkins n'ont pas d'artefacts : il n'est donc jamais proposé pour eux.
+
+À gauche de la barre d'outils, le bouton **Tout réduire** replie chaque section de la sortie (chaque play et chaque tâche) et devient
+**Tout développer**, qui les déplie de nouveau.
+
+**Afficher les variables supplémentaires** nécessite l'option de rôle `showExtravars` et **Afficher les artefacts** l'option de rôle `showArtifacts` (voir
+les [options de rôle](../config/roles.html#role-options)). Les valeurs des champs mot de passe et des clés qui correspondent à
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) sont masquées.
+
+Le filtre est défini par [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), `\[low\]` par
+défaut. Mettez `[low]` dans le nom d'une tâche bavarde, et **Appliquer le filtre** masque cette tâche et ses lignes.
+
+La page d'un job multistep affiche chaque étape sous le job principal, l'une sous l'autre, chacune sous une barre de titre comme
+**Étape 1 · Prepare the server (id du job 98)** avec son statut. Cliquez sur un titre (ou appuyez sur Entrée ou Espace dessus) pour replier cette sortie,
+et de nouveau pour la déplier. Les workflows AWX/AAP affichent aussi le statut de leurs nœuds.
+
+Les jobs de [workflow](../workflows/running.html#the-job) conservent la sortie de chaque nœud dans la leur, sous une bannière `WORKFLOW NODE` par
+nœud ; ils dessinent leur graphe en direct, et un clic sur un nœud ouvre sa sortie.
+
+---
+
+## Trouver un texte dans la sortie
+
+Depuis la 7.3.0, la page du job a une zone de recherche, **Chercher dans la sortie**, sur sa ligne de titre, à gauche des actions du job.
+
+Chaque endroit où le texte apparaît dans la sortie est mis en évidence, quelle que soit la casse, et la page se place sur le premier. **Entrée** passe au
+suivant, affiché plus fortement, et la barre d'outils indique lequel sur combien (**2 sur 4**), ou **Introuvable**. La recherche déplie d'abord la sortie et
+ses sections, et pendant l'exécution du job les nouvelles lignes sont aussi parcourues, sans déplacer la page.
+
+---
+
+## Se déplacer dans une longue sortie
+
+Depuis la 7.3.0, une longue sortie, sur la page du job et sous un formulaire après **Soumettre**, offre ces moyens de s'y déplacer :
+
+| Contrôle | Ce qu'il fait |
+|---|---|
+| En-têtes fixes | L'en-tête d'une section (un nœud de workflow, le playbook du job, l'étape d'un job multistep) reste en haut pendant que ses lignes défilent |
+| **2 en échec** | Compte les tâches en échec, sans les échecs qu'Ansible devait ignorer ; chaque clic passe à la suivante, dépliée et mise en évidence. Sans tâche en échec, **1 erreur** compte plutôt les lignes d'erreur |
+| Numéros de ligne | Chaque numéro de ligne renvoie vers sa ligne, comme `#L45` dans l'adresse : ouvrir cette adresse fait défiler jusqu'à la ligne et la met en évidence |
+| Boutons haut et bas | Affichés en bas à droite dès que la page a défilé, pour revenir en haut ou aller à la fin |
+| **En cours** et **Arrêter** | Pendant l'exécution du job, la barre de la page du formulaire reste en bas de la fenêtre, et **Arrêter** y arrête le job immédiatement |
+
+---
+
+## Résultats des tâches
+
+Depuis la 7.3.0, la ligne de résultat d'un hôte dans la sortie d'un playbook ouvre ce résultat dans une boîte de dialogue **Résultat de la tâche**, comme le fait AWX.
+
+La ligne, le corps du résultat qui la suit (`=> { ... }`) et l'erreur affichée avant un résultat en échec sont mis en évidence comme un seul bloc au survol, et un
+clic ouvre la boîte de dialogue. Cela fonctionne sur la page du job et sous un formulaire après **Soumettre**, pour un playbook exécuté sur un RTE 7.3.0 ou
+plus récent, car le résultat provient des mêmes événements que [Hôtes et tâches](#hosts-and-tasks). La boîte de dialogue a ces onglets :
+
+| Onglet | Ce qu'il affiche |
+|---|---|
+| **Détails** | Le statut, l'hôte, le play, la tâche, le module, l'élément de boucle, l'heure de début, la durée, le code de retour et le message |
+| **JSON** et **YAML** | Le résultat complet du module, coloré et avec des lignes numérotées |
+| **Sortie standard** et **Erreur standard** | Le `stdout` et le `stderr` du résultat, quand il en a |
+
+Le résultat complet, et avec lui les onglets **JSON**, **YAML** et de sortie, n'est stocké que lorsque le job s'exécute en mode verbeux, puisque la sortie
+l'affiche alors aussi ; sinon, la boîte de dialogue n'affiche que les détails. Même en mode verbeux, les arguments du module (`invocation`) sont
+omis, les valeurs des clés qui ressemblent à un secret sont masquées, et un résultat est tronqué dès qu'il dépasse 64 Ko de JSON.
+
+---
+
+## Le graphe du workflow
+
+Depuis la 7.3.0, le graphe d'un workflow en cours glisse pour garder le nœud en cours en vue.
+
+Faites défiler le graphe ailleurs et il reste là où vous l'avez mis, avec un bouton **Suivre le nœud en cours** pour le suivre de nouveau. Survoler un nœud
+affiche sa carte avec le nom complet et met en avant le nœud et ses liens, le reste du graphe étant estompé. Le graphe a des boutons **Ajuster à
+l'écran** et **Plein écran**, et sous un formulaire après **Soumettre**, un clic sur un nœud ouvre sa sortie comme sur la page du job.
+
+---
+
+## Hôtes et tâches
+
+Depuis la 7.3.0, un job de playbook exécuté sur un RTE 7.3.0 ou plus récent enregistre ses événements structurés à côté de sa sortie texte : chaque play, chaque tâche
+et chaque résultat d'hôte, ainsi que le récapitulatif. **Hôtes et tâches**, dans la barre d'outils de la sortie, les affiche dans un panneau au-dessus de la sortie, sur la page du job et
+sous un formulaire après **Soumettre**. Il est proposé dès que le job a des événements, et le panneau est relu toutes les quelques secondes pendant l'exécution du job :
+
+| Vue | Ce qu'elle affiche |
+|---|---|
+| **Grille** | Le récapitulatif par hôte (ok, changed, failed, unreachable, skipped, rescued, ignored), puis une grille des hôtes par tâche : chaque cellule est colorée selon le résultat de l'hôte pour cette tâche, avec son message et sa durée au survol, ou *non exécutée* |
+| **Chronologie** | Chaque tâche sous forme de barre, aussi longue que le temps pris par son hôte le plus lent, avec sa durée en secondes et le total |
+
+La sortie texte reste telle quelle. Les événements sont écrits par le plugin de callback `af_events` propre au RTE : le playbook n'a donc besoin d'aucune modification.
diff --git a/i18n/fr/_use/jobs/index.md b/i18n/fr/_use/jobs/index.md
new file mode 100644
index 0000000..76f48ed
--- /dev/null
+++ b/i18n/fr/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Jobs
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Jobs
+{: .no_toc }
+
+Suivre, arrêter, relancer, approuver et supprimer les jobs que lancent vos formulaires
+{: .fs-6 .fw-300 }
+
+---
+
+Pour tous ceux qui lancent des formulaires : ce qu'est un job, où le trouver, et qui peut le voir.
+
+---
+
+## Qu'est-ce qu'un job
+
+Un job est une exécution d'un formulaire : AnsibleForms l'enregistre avec son statut, ses extravars et sa sortie dès que le formulaire est soumis.
+
+Chaque job conserve :
+
+* le **formulaire** qu'il a exécuté et l'**utilisateur** qui l'a lancé (avec le type d'utilisateur, comme `local` ou `ldap`) ;
+* son **type de job** et son **statut**, ainsi que son **heure de début** et son **heure de fin** ;
+* sa **sortie**, les extravars et les identifiants avec lesquels il s'est exécuté, et les valeurs de champ saisies dans le formulaire.
+
+Un formulaire multistep crée un job pour le formulaire et un job par étape. Les étapes sont liées au job principal et listées sous lui.
+
+Les mêmes jobs peuvent être lancés, suivis et gérés via l'[API REST](../api/jobs.html).
+
+---
+
+## La page Jobs
+
+Le lien **Jobs** de l'en-tête ouvre la liste de tous les jobs, du plus récent au plus ancien (`/jobs/all`). La page et son lien sont affichés aux utilisateurs
+dont le rôle définit l'[option de rôle](../config/roles.html#role-options) `showJobs`.
+
+![La liste des jobs](../assets/screenshots/job-log.jpg)
+
+Le menu de gauche classe les jobs dans le temps, avec le nombre de jobs de chaque entrée ; une entrée de statut filtre la liste sur ce statut :
+
+| Section | Entrée du menu | Affiche |
+|---|---|---|
+| **Passé** | **Réussi** | Les jobs au statut `success` |
+| | **Échoué** | Les jobs au statut `failed` |
+| | **Annulé** | Les jobs au statut `aborted` |
+| | **Rejeté** | Les jobs au statut `rejected` |
+| | **Abandonné** | Les jobs au statut `abandoned` |
+| **Présent** | **En cours** | Les jobs au statut `running` |
+| | **En attente d'approbation** | Les jobs au statut `approve` ; le compteur passe à l'orange quand un job attend |
+| **Futur** | **Planifiés** | La page [Planifications](schedules.html) (option de rôle `allowScheduledJobs`) |
+| | **Enregistrés** | La page [Jobs enregistrés](stored-jobs.html) (option de rôle `allowStoredJobs`) |
+
+Le menu n'a pas d'entrée pour tous les jobs : le lien **Jobs** de l'en-tête les affiche tous, jobs `warning` compris.
+
+Au-dessus du tableau, sur la ligne de titre :
+
+* la **zone de recherche** garde les jobs dont les colonnes affichées contiennent le texte (sans tenir compte de la casse), ou dont l'une des étapes l'a comme id
+  ou comme cible ;
+* **Supprimer** (avec le nombre de jobs cochés) supprime ensemble les jobs cochés dans la première colonne ;
+* **Colonnes** affiche ou masque les colonnes `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` et `user` ;
+  la durée d'un job en cours s'incrémente ;
+* **Actualiser** recharge la liste.
+
+La liste charge les jobs les plus récents, autant que l'indique le réglage [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)
+(**Paramètres > Système > Général**, onglet **Jobs**, `1000` par défaut) ; ses pages, sa recherche et ses filtres portent sur ces jobs.
+
+Chaque colonne peut être triée et a son propre champ de filtre. Un job multistep a une flèche juste avant son `form` qui déplie
+ses étapes ; un clic sur le reste d'une ligne ouvre le job.
+
+La cloche de l'en-tête compte les jobs qui attendent votre approbation et ouvre la liste sur **En attente d'approbation**. Pour les utilisateurs qui peuvent voir
+les runners, elle compte aussi les [runners en attente d'approbation](../runners/registration.html#approving-an-rte), des RTE qui ont demandé à rejoindre l'instance,
+et ouvre **Connexions > Runners** quand seuls des runners attendent. Quand les deux attendent, elle ouvre un menu, **Jobs en attente d'approbation** et
+**Runners en attente d'approbation**, chacun avec son compteur.
+
+---
+
+## Qui voit quels jobs
+
+Les jobs qu'un utilisateur voit dépendent de ses rôles :
+
+| Utilisateur | Voit |
+|---|---|
+| Admin (rôle `admin`) | Tous les jobs |
+| Option de rôle `showAllJobLogs` | Tous les jobs |
+| Option de rôle `manageAllJobs` (depuis la 7.3.0) | Tous les jobs, et peut les arrêter, les supprimer et les relancer |
+| Tout autre utilisateur | Ses propres jobs, et les jobs en attente d'une approbation qui nomme l'un de ses rôles |
+
+Jusqu'à la 7.2, tout utilisateur pouvait ouvrir n'importe quel job en attente d'approbation, extravars et sortie comprises ; depuis la 7.3.0, seuls son propriétaire et ses
+approbateurs le peuvent. Voir un job ne donne pas droit à toutes les actions sur lui : arrêter, supprimer et relancer le job d'un autre utilisateur demande d'être admin ou
+d'avoir `manageAllJobs`, et `showAllJobLogs` ne fait qu'afficher les jobs. Supprimer demande aussi `allowJobDeletion`, et relancer `allowJobRelaunch`.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Contenu |
+|---|---|
+| [Statuts et types](statuses.html) | Chaque statut qu'un job peut avoir, et les types de job |
+| [Suivre un job](following.html) | Sortie en direct, extravars, filtres et téléchargements |
+| [Actions sur les jobs](actions.html) | Lancer, arrêter, relancer, approuver ou rejeter, et supprimer un job |
+| [Planifications](schedules.html) | Exécuter un formulaire plus tard ou selon une planification cron, et gérer toutes les planifications |
+| [Jobs enregistrés](stored-jobs.html) | Conserver les données d'un formulaire pour les recharger plus tard |
+| [Nettoyage](cleanup.html) | Les jobs interrompus par un redémarrage, et la durée de conservation des jobs terminés |
diff --git a/i18n/fr/_use/jobs/schedules.md b/i18n/fr/_use/jobs/schedules.md
new file mode 100644
index 0000000..75e1efd
--- /dev/null
+++ b/i18n/fr/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Planifications
+parent: Jobs
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Planifications
+{: .no_toc }
+
+Exécuter un formulaire plus tard ou selon une planification cron, et gérer toutes les planifications
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les actions du formulaire
+
+Un formulaire peut faire plus que s'exécuter immédiatement : la liste déroulante à côté de son bouton **Soumettre** contient trois autres actions.
+
+| Action | Ce qu'elle fait | Option de rôle |
+|---|---|---|
+| **Planifier (récurrent)** | Crée une planification qui exécute le formulaire selon une expression cron | `allowScheduledJobs` |
+| **Exécuter plus tard (une seule fois)** | Crée une planification qui exécute le formulaire une fois, à la date et à l'heure que vous choisissez | `allowPlannedJobs` |
+| **Enregistrer** | Enregistre les valeurs des champs, pour les recharger plus tard dans le formulaire | `allowStoredJobs` |
+
+Une action dont l'option de rôle est désactivée n'est pas affichée. Le formulaire est validé avant chacune d'elles, comme pour **Soumettre**. Les deux
+actions de planification créent une entrée sur la page **Planifications** ; **Enregistrer** crée une entrée sur la page **Jobs enregistrés**. La
+barre latérale de la page [Jobs](./) les ouvre sous **Futur**, en tant que **Planifiés** et **Enregistrés**. Les options de rôle sont décrites
+dans [Options de rôle](../config/roles.html#role-options).
+
+{: .warning }
+> Considérez `allowScheduledJobs` comme une option de niveau admin. Ses planifications n'appartiennent pas à l'utilisateur qui les a créées : chaque utilisateur
+> disposant de l'option voit et peut modifier toutes les planifications. Une telle planification s'exécute aussi avec les droits admin, pour n'importe quel formulaire, quel que soit
+> l'accès propre de son créateur. Ne l'accordez qu'aux rôles auxquels vous feriez confiance comme admins.
+
+{: .note }
+> **Exécuter plus tard (une seule fois)** ne nécessite que `allowPlannedJobs`. Pour un utilisateur sans `allowScheduledJobs`, elle planifie une exécution **en tant que cet
+> utilisateur** : le serveur vérifie que l'utilisateur peut exécuter le formulaire, et le job s'exécute en son nom, lui appartient, le moment venu
+> (voir [Exécutions planifiées](#planned-runs)).
+
+---
+
+## Planifier un formulaire
+
+Remplissez le formulaire, puis ouvrez la liste déroulante à côté de **Soumettre** et choisissez l'une des actions de planification.
+
+- **Planifier (récurrent)** ouvre **Créer une planification** : saisissez un **Nom** et une **Expression Cron** (la valeur par défaut, `0 0 * * *`,
+  s'exécute chaque jour à minuit), puis sélectionnez **Créer une planification**.
+- **Exécuter plus tard (une seule fois)** ouvre **Exécuter plus tard** : saisissez un **Nom** et choisissez la date et l'heure **Exécuter à**, puis sélectionnez
+  **Planifier le job**.
+
+Le nom doit être unique parmi toutes les planifications. La planification conserve le nom du formulaire et une copie des extravars que le formulaire a produites
+à ce moment-là, écrites en YAML ; chaque exécution utilise cette copie : modifiez-la donc sur la page **Planifications** pour changer ce que reçoit le job.
+
+![Planifications](../assets/screenshots/schedules.jpg)
+
+---
+
+## La page Planifications
+
+La page **Planifications** liste toutes les planifications, avec leur colonne **Activé** depuis la 7.3.0, et nécessite `allowScheduledJobs`. Le menu de chaque ligne propose :
+
+| Action | Ce qu'elle fait |
+|---|---|
+| **Modifier** | Change le nom, le type, l'expression cron ou l'heure d'exécution, le formulaire et les extra vars |
+| **Exécuter maintenant** | Exécute la planification maintenant, sans attendre son expression cron ou son heure d'exécution |
+| **Activer** ou **Désactiver** | Active ou désactive la planification, selon le cas, comme l'indique sa colonne **Activé** (depuis la 7.3.0) |
+| **Supprimer** | Supprime la planification ; elle cesse immédiatement de s'exécuter |
+| **Dernière sortie** | Sur la page de la planification, ce qu'a rapporté la dernière exécution, comme le numéro du job qu'elle a démarré |
+
+Une planification peut aussi être créée ici de zéro. Choisissez le **Formulaire**, puis cochez **Exécution unique** et définissez
+**Exécuter à**, ou laissez la case décochée et définissez une **Planification**. **Variables supplémentaires** est du YAML sans formulaire pour le remplir : ajoutez donc vous-même les
+valeurs dont le playbook a besoin, sous forme de dictionnaire (paires clé: valeur).
+
+Le champ **Planification** est un éditeur cron : il décrit l'expression en mots, propose des préréglages et affiche un aperçu des prochaines
+exécutions. Le serveur refuse une expression qu'il ne peut pas exécuter, ou qui ne peut jamais se produire.
+
+Depuis la 7.3.0, chaque planification a un interrupteur **Activé**, pour la mettre en pause sans la supprimer. Une planification désactivée reste sur la page
+avec ses réglages, mais ne s'exécute pas d'elle-même : une planification récurrente saute ses déclenchements cron, et une planification unique attend au-delà de son
+**Exécuter à** jusqu'à ce qu'elle soit réactivée. **Exécuter maintenant** l'exécute toujours à la demande. Une nouvelle planification est activée, et les planifications
+qui existaient avant la 7.3.0 sont activées après la mise à niveau.
+
+---
+
+## Expressions cron et fuseau horaire
+
+Une planification récurrente prend une expression cron standard à 5 champs : minute, heure, jour du mois, mois et jour de la semaine.
+
+| Expression | S'exécute |
+|---|---|
+| `*/15 * * * *` | Toutes les 15 minutes |
+| `0 2 * * *` | Chaque jour à 02:00 |
+| `30 7 * * 1-5` | Du lundi au vendredi à 07:30 |
+| `0 0 1 * *` | À minuit le premier jour de chaque mois |
+
+D'autres exemples, et les fonctionnalités cron que l'éditeur n'accepte pas, se trouvent dans la FAQ sous
+[Quelles expressions cron puis-je utiliser ?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Les planifications cron s'exécutent dans le fuseau horaire du serveur, défini avec [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (par défaut `UTC`),
+> et non dans le fuseau horaire de votre profil ou de votre navigateur. L'éditeur cron affiche l'aperçu des prochaines exécutions dans ce même fuseau.
+
+---
+
+## Comment une planification s'exécute
+
+Quand une planification arrive à échéance, elle est mise en file d'attente, et le serveur démarre les planifications en attente une par une, en vérifiant la file toutes les 10 secondes.
+
+- Les planifications **récurrentes** sautent un déclenchement tant que l'exécution précédente est encore en attente ou en cours : les exécutions ne se chevauchent jamais.
+- Les planifications **uniques** s'exécutent dans la minute qui suit **Exécuter à**, puis sont supprimées, y compris quand elles sont démarrées avec **Exécuter maintenant**.
+- Le **Statut** est `success` quand le job a été démarré et `failed` quand il n'a pas pu l'être. Un `success` indique seulement que le job a été
+  lancé : ouvrez le job pour voir comment il s'est terminé.
+
+Une planification créée avec `allowScheduledJobs` s'exécute en tant qu'utilisateur intégré `Schedule Service` (type `schedule`) avec le
+rôle `admin`. Elle peut exécuter n'importe quel formulaire, quel que soit l'accès de la personne qui a créé la planification, et `ansibleforms_user` dans
+ses extravars décrit cet utilisateur. Une [exécution planifiée](#planned-runs) s'exécute plutôt en tant qu'utilisateur qui l'a planifiée.
+
+Le job reçoit aussi un objet `schedule` (avec son `id`, son `name` et son `form`), pour qu'un playbook sache qu'une planification l'a démarré :
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Exécutions planifiées
+
+**Exécuter plus tard (une seule fois)** par un utilisateur sans `allowScheduledJobs` crée une exécution planifiée : une planification unique liée à cet utilisateur.
+
+- **Lors de la planification**, le serveur vérifie que l'utilisateur peut exécuter le formulaire (ses `roles`), et le mode verbeux nécessite
+  `allowVerboseMode`. Une exécution planifiée est toujours unique ; une expression cron est refusée.
+- **Avec la validation au lancement `enforce`**, les valeurs des champs sont vérifiées lors de la planification : une exécution qui serait refusée est
+  refusée pendant que l'utilisateur est encore là.
+- **Lors de l'exécution**, le job s'exécute en tant que cet utilisateur, lui appartient, et passe par les mêmes vérifications qu'un lancement depuis le navigateur : les
+  rôles du formulaire tels qu'ils sont alors, les extravars réservées retirées, et la validation au lancement. `ansibleforms_user` le décrit.
+
+Celui qui planifie ne voit pas la page **Planifications**, qui nécessite `allowScheduledJobs` ; le job apparaît dans son propre historique de jobs.
+
+---
+
+## Quand le formulaire change
+
+Une planification fait référence à son formulaire par son nom et l'exécute tel qu'il est défini au moment de chaque exécution.
+
+- **Le formulaire est modifié** : l'exécution suivante utilise la nouvelle définition (playbook, template, inventaire) avec les extravars stockées dans
+  la planification. Le formulaire n'est pas rendu, donc aucun champ n'est recalculé ; modifiez les extra vars de la planification pour qu'elles correspondent.
+- **Le formulaire est renommé ou supprimé** : l'exécution échoue, le **Statut** devient `failed` et la **Dernière sortie** indique
+  `Failed to launch : No such form '<name>'`. Modifiez la planification et choisissez le bon formulaire, ou supprimez-la.
+
+---
+
+## Les jobs planifiés dans l'historique des jobs
+
+Chaque exécution d'une planification crée un job ordinaire, listé sur la page [Jobs](./) avec `Schedule Service` comme utilisateur ou,
+pour une exécution planifiée, avec l'utilisateur qui l'a planifiée.
+
+Un job `Schedule Service` n'appartient pas à la personne qui a créé la planification : il n'est donc visible que des admins et des
+utilisateurs disposant de `showAllJobLogs` ; le job d'une exécution planifiée est aussi visible de son utilisateur. La **Dernière sortie** de la planification nomme le job qu'elle a démarré, pour que vous puissiez le retrouver dans la liste.
diff --git a/i18n/fr/_use/jobs/statuses.md b/i18n/fr/_use/jobs/statuses.md
new file mode 100644
index 0000000..b6e2cd7
--- /dev/null
+++ b/i18n/fr/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Statuts et types
+parent: Jobs
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Statuts et types
+{: .no_toc }
+
+Chaque statut qu'un job peut avoir, et les types de job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Statuts des jobs
+
+AnsibleForms attribue les statuts suivants à un job. La liste affiche chaque statut sous forme de pastille colorée :
+
+| Statut | Signification | Ce que vous pouvez faire |
+|---|---|---|
+| `running` | Le job est en cours, ou un job approuvé a repris | Suivre sa sortie, l'arrêter |
+| `approve` | Le job attend à un [point d'approbation](../forms/approval.html) avant de s'exécuter (ou avant qu'une étape d'un multistep s'exécute) | L'approuver ou le rejeter, si l'un de vos rôles est approbateur |
+| `success` | Le playbook, le template ou chacune des étapes s'est terminé sans erreur | Voir la sortie, relancer, supprimer |
+| `failed` | Le job s'est terminé par une erreur, ou le lancement lui-même a échoué | Voir la sortie pour en comprendre la raison, relancer, supprimer |
+| `warning` | Un multistep s'est terminé, mais une étape définie avec `continue` a échoué | Voir la sortie, relancer, supprimer |
+| `aborted` | Le job a été arrêté depuis AnsibleForms, ou le job AWX / AAP a été annulé | Voir la sortie, relancer, supprimer |
+| `rejected` | Un approbateur a rejeté le job ; il ne s'est jamais exécuté | Voir la sortie, relancer, supprimer |
+| `abandoned` | AnsibleForms a cessé de suivre le job (voir [Jobs abandonnés](cleanup.html#abandoned-jobs)) | Vérifier les hôtes gérés, relancer, supprimer |
+
+`running` est bleu, `success` vert et s'affiche **Réussi**, et `failed` rouge. `approve` est orange et s'affiche **En attente d'approbation** :
+un job qui attend une personne se distingue ainsi des jobs arrêtés ; `warning`, `aborted` et `rejected` sont ambre. `abandoned` est
+gris : personne ne l'a arrêté, ce qui l'exécutait a disparu.
+
+---
+
+## Types de job
+
+Le type de job suit le `type` du formulaire qui a démarré le job, tel que la liste et la page du job l'affichent :
+
+| Type affiché | Ce qui s'exécute |
+|---|---|
+| `ansible` | Un playbook Ansible, exécuté sur un RTE |
+| `awx`, `aap`, `ascender` | Un job template ou un workflow template sur AWX, AAP ou Ascender |
+| `semaphore` | Un template sur Semaphore UI |
+| `rundeck`, `jenkins` | Un job sur Rundeck ou Jenkins |
+| `workflow` | Un [workflow](../workflows/), dont les nœuds playbook s'exécutent comme des jobs à part entière sous lui |
+| `multistep` | Obsolète, utilisez `workflow` : une suite d'étapes, chacune enregistrée comme un job à part entière sous le job principal |
+
+Un job de template est stocké comme un job `awx` (dans l'API REST aussi) et affiché avec le type de runner sur lequel il s'est exécuté, quel que soit
+le nom que le formulaire lui donne : un formulaire de type `awx` qui s'exécute sur un runner AAP affiche `aap`.
+
+Voir [Formulaires Ansible](../forms/ansible.html), [Formulaires AWX](../forms/awx.html), [Formulaires workflow](../forms/workflow.html) et
+[Formulaires multistep](../forms/multistep.html) pour le côté formulaire.
diff --git a/i18n/fr/_use/jobs/stored-jobs.md b/i18n/fr/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..a26ffb5
--- /dev/null
+++ b/i18n/fr/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Jobs enregistrés
+parent: Jobs
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Jobs enregistrés
+{: .no_toc }
+
+Conserver les données d'un formulaire pour les recharger plus tard
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jobs enregistrés
+
+Les jobs enregistrés conservent les valeurs d'un formulaire pour que vous puissiez les recharger, au lieu de remplir les mêmes champs à chaque fois.
+
+Pour enregistrer, remplissez le formulaire, ouvrez la liste déroulante à côté de **Soumettre** et choisissez **Enregistrer**. Dans **Enregistrer les données du formulaire**, saisissez un
+**Nom**, une **Description** facultative et une date **Expire le (optionnel)**, puis enregistrez. Les champs mot de passe et constantes ne sont
+jamais enregistrés. Un sous-formulaire a la même action **Enregistrer** à côté de son bouton **Enregistrer**, et conserve des valeurs inachevées sans
+les valider.
+
+Pour charger, sélectionnez **Charger depuis le stockage** en haut du formulaire. **Charger le formulaire enregistré** liste vos jobs enregistrés pour ce formulaire, avec
+leurs dates de création et d'expiration ; sélectionnez-en un pour remplir le formulaire avec ses valeurs. Rien ne s'exécute tant que vous ne soumettez pas.
+
+Les jobs enregistrés sont conservés dans la base de données d'AnsibleForms (table `stored_jobs`), avec le nom du formulaire, votre utilisateur sous la forme
+`<type>/<username>` (par exemple `local/admin`) et les valeurs en JSON. Un nom doit être unique par utilisateur et par formulaire ; enregistrer
+un second job portant le même nom échoue avec « Un formulaire enregistré portant ce nom existe déjà ».
+
+---
+
+## Gérer les jobs enregistrés
+
+La page **Jobs enregistrés** liste les jobs enregistrés avec leur formulaire, leur utilisateur et leurs dates de création et d'expiration, et nécessite `allowStoredJobs`.
+
+- **Modifier** ouvre la page propre au job enregistré : ses **Détails** (nom, formulaire, expiration) et ses **Valeurs**, les valeurs de champ
+  enregistrées en YAML, qui peuvent y être modifiées et enregistrées.
+- **Ouvrir dans le formulaire** ouvre son formulaire avec les valeurs enregistrées remplies ; rien ne s'exécute tant que vous ne soumettez pas.
+- **Supprimer** le supprime. Vous pouvez supprimer vos propres jobs enregistrés ; les utilisateurs disposant de `showSettings` peuvent supprimer n'importe lequel.
+- Les jobs enregistrés dont la date **Expire le** est passée sont supprimés automatiquement chaque jour à 04:00 (dans `LOG_TZ`).
diff --git a/i18n/fr/_use/profile/account.md b/i18n/fr/_use/profile/account.md
new file mode 100644
index 0000000..a345213
--- /dev/null
+++ b/i18n/fr/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Compte
+parent: Votre profil
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Compte
+{: .no_toc }
+
+Avec quel compte vous êtes connecté
+{: .fs-6 .fw-300 }
+
+---
+
+La vue Compte montre avec quel compte vous êtes connecté et ce qui détermine votre accès :
+
+- **Nom d'utilisateur** et **Type de connexion** : un compte local, LDAP, Microsoft Entra ID ou OpenID Connect.
+- **Groupes** : les groupes fournis avec votre connexion, comme `local/admins` ou `ldap/Domain Admins`.
+- **Rôles** : les rôles de `config.yaml` qui correspondent à ces groupes et à votre utilisateur. Ils déterminent
+  quels formulaires vous voyez et de quelles options vous disposez.
diff --git a/i18n/fr/_use/profile/api-token.md b/i18n/fr/_use/profile/api-token.md
new file mode 100644
index 0000000..5d70d6a
--- /dev/null
+++ b/i18n/fr/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Jeton d'API
+parent: Votre profil
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# Jeton d'API
+{: .no_toc }
+
+Créer un jeton pour les scripts et les agents IA
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Qui peut en créer un
+
+Un jeton de longue durée permet à des scripts d'appeler l'API sans votre mot de passe. Depuis la 7.3.0, il nécessite l'option de rôle `allowApiTokens` :
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Jusqu'à la 7.2.0, l'option était seulement `extendedTokenExpiration`. Un rôle d'avant la 7.3.0 qui ne définit que cette option reçoit
+`allowApiTokens`, et garde donc ses jetons ; avec les deux, on peut aussi créer un jeton qui n'expire jamais. Voir [Options de rôle](../config/roles.html#role-options).
+
+---
+
+## Créer un jeton
+
+**Nouveau jeton**, sur la ligne de titre de **Profil > Jetons d'API**, ouvre un assistant en trois étapes :
+
+1. **Détails** : un nom, pour reconnaître le jeton dans la liste, et sa durée de validité. Les choix sont 30, 90, 180
+   ou 365 jours jusqu'à [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 par défaut), ce
+   maximum lui-même, et **N'expire jamais** avec `extendedTokenExpiration`. Choisissez la durée la plus courte dont votre script a besoin.
+2. **Confirmer** : un compte local ou LDAP saisit son mot de passe, qui n'est pas stocké dans le jeton. Un compte Microsoft Entra ID ou
+   OIDC n'a pas de mot de passe ici : son jeton est créé à partir de sa session, qui doit s'être connectée au plus 10 minutes
+   auparavant ; le fournisseur peut donc vous demander de vous reconnecter d'abord.
+3. **Copier** : le jeton, affiché **une seule fois**. Copiez-le avec **Copier** et gardez-le aussi précieusement qu'un mot de passe.
+
+Envoyez le jeton dans l'en-tête `Authorization` de chaque appel d'API :
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Un jeton d'API ne peut pas en créer un autre. Le jeton d'un compte SSO porte les rôles de sa dernière connexion : un changement de groupe chez le
+fournisseur d'identité ne l'atteint que lorsque vous vous reconnectez et créez un nouveau jeton.
+
+---
+
+## Vos jetons
+
+Les jetons que vous avez créés sont listés avec leur nom et la date de création, d'expiration et de dernière utilisation de chacun ; **Révoquer** dans le menu d'une ligne en met un hors service.
+Un admin les voit et les révoque aussi sur votre page sous **Paramètres > Utilisateurs**. Un jeton prend fin à son expiration, ou plus tôt :
+
+- **une révocation**, depuis la liste ;
+- **une déconnexion avec le jeton** (`POST /api/v2/auth/logout` avec le jeton dans l'en-tête `Authorization`), qui y met fin avec
+  la session dans laquelle il a été créé ;
+- **un changement de mot de passe**, qui met fin à tous les jetons et sessions de votre compte créés avant lui, ainsi qu'un blocage de votre compte.
+
+Un jeton qui n'expire jamais prend fin lui aussi dans ces cas. Un script peut aussi demander lui-même un jeton via l'API de connexion et
+son paramètre `expiryDays` (`POST /api/v2/auth/login?expiryDays=90`, ou `expiryDays=never`) ; un `expiryDays` plus long est ramené
+à `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/fr/_use/profile/index.md b/i18n/fr/_use/profile/index.md
new file mode 100644
index 0000000..e61bba3
--- /dev/null
+++ b/i18n/fr/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: Votre profil
+nav_order: 4
+description: Votre compte, vos préférences, votre mot de passe, vos autorisations et vos tokens d'API
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# Votre profil
+{: .no_toc }
+
+Votre compte, vos préférences, votre mot de passe, vos autorisations et vos jetons d'API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pour chaque utilisateur : votre propre compte, vos préférences, votre mot de passe, vos autorisations et vos jetons d'API.
+
+Ouvrez votre profil depuis l'avatar en haut à droite : **Profil**.
+
+---
+
+## Ouvrir une vue
+
+Le menu de gauche liste les vues du profil par ordre alphabétique. Chaque vue a sa propre adresse,
+pour que vous puissiez y faire un lien direct :
+
+| Vue | Adresse |
+|---|---|
+| Compte | `/profile/account` |
+| Jetons d'API | `/profile/token` |
+| Mot de passe | `/profile/password` |
+| Autorisations | `/profile/permissions` |
+| Préférences | `/profile/preferences` |
+
+`/profile` seul ouvre la première vue du menu. Les vues que vos rôles n'autorisent pas sont masquées ; leur adresse ouvre plutôt la première
+vue. **Jetons d'API** n'est affiché que lorsque l'un de vos rôles a l'option de rôle `allowApiTokens`.
+
+---
+
+## Dans cette section
+
+Chaque sujet est décrit sur sa propre page :
+
+| Page | Contenu |
+|---|---|
+| [Compte](account.html) | Avec quel compte vous êtes connecté |
+| [Préférences](preferences.html) | Langue, thème, fuseau horaire, format de date et notifications de bureau |
+| [Mot de passe](password.html) | Changer le mot de passe d'un compte local |
+| [Autorisations](permissions.html) | Ce que vos rôles vous permettent de faire |
+| [Jetons d'API](api-token.html) | Créer un jeton pour les scripts et les agents IA |
diff --git a/i18n/fr/_use/profile/password.md b/i18n/fr/_use/profile/password.md
new file mode 100644
index 0000000..537567d
--- /dev/null
+++ b/i18n/fr/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Mot de passe
+parent: Votre profil
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Mot de passe
+{: .no_toc }
+
+Changer le mot de passe d'un compte local
+{: .fs-6 .fw-300 }
+
+---
+
+Saisissez votre mot de passe actuel et deux fois le nouveau, puis cliquez sur **Changer le mot de passe**.
+
+Les comptes LDAP, Entra ID et OpenID Connect changent plutôt leur mot de passe auprès de ce fournisseur.
diff --git a/i18n/fr/_use/profile/permissions.md b/i18n/fr/_use/profile/permissions.md
new file mode 100644
index 0000000..6479147
--- /dev/null
+++ b/i18n/fr/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Autorisations
+parent: Votre profil
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Autorisations
+{: .no_toc }
+
+Ce que vos rôles vous permettent de faire
+{: .fs-6 .fw-300 }
+
+---
+
+Les options de rôle sont regroupées en onglets, chacun avec le nombre de ses options dont vous disposez, comme `5/8` :
+
+| Onglet | Options concernant |
+|---|---|
+| **Accès et intégrations** | La connexion, l'assistant de chat, le serveur MCP, les envois de fichiers et les jetons d'API |
+| **Concepteur** | L'ouverture du concepteur, et la modification des formulaires, playbooks, workflows, inventaires et fichiers de variables |
+| **Jobs** | La consultation des jobs et de leurs extravars ou artefacts, la relance, la suppression, la planification et l'enregistrement de jobs |
+| **Paramètres** | Les pages de paramètres, les journaux, le journal d'audit et les sauvegardes |
+| **Autres** | Une option définie à la main dans un rôle et qui ne figure dans aucun autre onglet ; toujours le dernier onglet |
+
+Les autres onglets sont classés par ordre alphabétique. Chaque onglet est un tableau avec les colonnes **Paramètre** (l'option), **Description**
+(ce qu'elle fait) et **Votre accès** : **Autorisé** ou **Non autorisé**. Une option qui s'applique à cause d'une autre l'indique
+sous sa description : **Inclus dans** une option dont vous disposez l'active, et **Nécessite** une option qui vous manque la laisse désactivée.
+
+Les options proviennent des `options` de vos rôles dans `config.yaml` ; la page [Rôles](../config/roles.html) explique comment
+elles se combinent.
diff --git a/i18n/fr/_use/profile/preferences.md b/i18n/fr/_use/profile/preferences.md
new file mode 100644
index 0000000..645d207
--- /dev/null
+++ b/i18n/fr/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Préférences
+parent: Votre profil
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Préférences
+{: .no_toc }
+
+Langue, thème, fuseau horaire, format de date et notifications de bureau
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Les préférences
+
+La vue Préférences change l'apparence d'AnsibleForms pour vous. Chaque choix est stocké dans le navigateur
+où vous le faites : un autre navigateur ou un autre ordinateur repart donc des valeurs par défaut.
+
+| Paramètre | Choix | Aussi modifiable depuis |
+|---|---|---|
+| Langue | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (japonais), 简体中文 (chinois simplifié) | le drapeau dans l'en-tête |
+| Thème | Suivre le navigateur, Clair, Sombre, ou Couleur (un en-tête dans la couleur de votre choix) | l'icône du soleil dans l'en-tête |
+| Affichage des formulaires | Tuiles ou Liste | le bouton de la page Formulaires |
+| Fuseau horaire | UTC, le fuseau de ce navigateur, ou n'importe quel fuseau par son nom | uniquement ici |
+| Format de date | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY` | uniquement ici |
+| Notifications de bureau | Activées ou désactivées | uniquement ici |
+
+Depuis la 7.3.0, la vue est organisée en onglets, chacun à sa propre adresse (`/profile/preferences/<tab>`) : **Apparence** (langue, thème et affichage
+des formulaires), **Date et heure** (fuseau horaire et format de date) et **Notifications**. La zone de recherche au-dessus liste les paramètres correspondants
+sous le nom de leur onglet. Un choix reste un brouillon jusqu'à **Enregistrer**, et quitter la vue avec une modification non enregistrée demande d'abord confirmation.
+
+**Suivre le navigateur** passe en clair ou en sombre comme le navigateur, et change avec lui. C'est le thème par défaut depuis la 7.3.0, sauf si votre
+administrateur en choisit un autre. Survoler une couleur du thème **Couleur**, ici ou dans le menu des thèmes de l'en-tête, donne un aperçu de l'application dans cette
+couleur, et le thème précédent revient quand le pointeur quitte la palette ; rien ne change avant un clic.
+
+---
+
+## Notifications de bureau
+
+Depuis la 7.3.0, l'onglet **Notifications** active les notifications de bureau dans ce navigateur, pour les utilisateurs dont le rôle définit `showJobs`.
+
+Le navigateur demande son autorisation la première fois. Quand il bloque les notifications pour le site, l'interrupteur reste désactivé et indique comment
+les autoriser, et un site en simple `http` ne peut pas du tout en afficher. Une fois activées, une notification arrive :
+
+| Quand | Elle indique | Un clic dessus |
+|---|---|---|
+| Un job que vous avez lancé se termine | Le formulaire et son résultat, comme *Patch Linux servers: Réussi*, avec le numéro et la durée du job | Ramène l'onglet au premier plan sur ce job |
+| Un job attend votre approbation | Le formulaire, le numéro du job et qui l'a lancé, avec les boutons **Approuver** et **Rejeter** | Ouvre les jobs en attente d'approbation |
+
+Les boutons **Approuver** et **Rejeter** s'affichent dans Chrome et Edge ; Firefox et Safari affichent la notification sans eux, tout comme un
+site avec un certificat auto-signé, car les boutons nécessitent un service worker. Les notifications n'arrivent que lorsqu'un onglet AnsibleForms est ouvert,
+même en arrière-plan : rien n'est envoyé une fois tous les onglets fermés. Chacune ne s'affiche qu'une fois, quel que soit le nombre d'onglets ouverts, et les étapes d'un
+job multistep et le job que vous êtes en train de regarder restent silencieux.
+
+---
+
+## Fuseau horaire
+
+Les dates et heures dans tout AnsibleForms sont affichées dans le fuseau horaire que vous sélectionnez. Cela inclut les heures de début
+et de fin des jobs, le journal d'audit, la page de statut, les sauvegardes, les jobs enregistrés, et l'expiration d'un jeton
+d'API. Changer de fuseau horaire met à jour chaque page immédiatement, sans rechargement.
+
+Tant que vous n'en choisissez pas, c'est le fuseau horaire défini par votre administrateur pour tout le monde qui s'applique (**Paramètres > Apparence > Valeurs par défaut**, voir
+[Apparence](../appearance.html)), **UTC** sauf modification. **Ce navigateur** suit le fuseau horaire de votre ordinateur, et la
+liste contient tous les fuseaux par leur nom, comme `Europe/Madrid`. La carte affiche l'heure actuelle dans le fuseau et le format sélectionnés.
+
+---
+
+## Format de date
+
+Le format de date définit comment se lit la partie date de chaque date, chaque choix étant affiché avec la date du jour : `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY`. Tant que vous n'en choisissez pas, le format de date par défaut de votre administrateur
+s'applique, `YYYY-MM-DD` sauf modification. Comme les autres choix, il est conservé dans ce navigateur.
+
+---
+
+## Ce qui garde les heures du serveur
+
+Deux exceptions gardent les heures propres au serveur :
+
+- **Le journal du serveur et la sortie des jobs** sont du texte qui contient les heures que le serveur y a écrites.
+- **Les heures que vous saisissez**, comme le moment où un job planifié doit s'exécuter, et les planifications cron, fonctionnent comme
+  avant.
diff --git a/i18n/fr/_use/repositories/adding.md b/i18n/fr/_use/repositories/adding.md
new file mode 100644
index 0000000..873bf65
--- /dev/null
+++ b/i18n/fr/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Ajouter un dépôt
+parent: Dépôts git
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Ajouter un dépôt
+{: .no_toc }
+
+La page Dépôts, chaque champ d'un dépôt, et la déclaration d'un dépôt dans le config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La page Dépôts
+
+Les dépôts se gèrent dans **Paramètres > Connexions > Dépôts**, qui nécessite l'[option de rôle](../config/roles.html#role-options) `showSettings` ou, depuis la 7.3.0,
+`showConnectionsSettings`. Certaines modifications sont réservées à un admin, voir [ci-dessous](#who-may-change-a-repository).
+
+![Dépôts](../assets/screenshots/git.jpg)
+
+La liste affiche le **Nom**, la **Description**, la **Branche**, le **Head** (le hash court du commit extrait), **Pull** et
+**Push**. L'onglet **Détails** d'un dépôt affiche les mêmes badges Pull et Push au-dessus de son head :
+
+| Colonne | Ce qu'elle indique |
+|---|---|
+| **Pull** | Le dernier clonage, pull ou réinitialisation : **En cours** pendant que git travaille, puis **Réussi** ou **Échoué** ; un tiret avant le premier |
+| **Push** | **Échoué** quand le dernier push a échoué ; **Modifications en attente** quand des modifications enregistrées ici, par le concepteur, ne sont pas encore poussées vers le dépôt distant ; **Réussi** quand rien n'attend ; un tiret avant le premier push |
+
+**Réussi** dans la colonne Push signifie seulement que rien n'attend d'être poussé : le dépôt distant peut encore contenir des commits plus récents qu'un
+pull rapatrie. Le menu de chaque ligne contient ces actions :
+
+| Action | Ce qu'elle fait |
+|---|---|
+| **Modifier** | Modifier les champs ci-dessous |
+| **Pull** | Cloner le dépôt, ou faire un pull quand l'arbre de travail existe déjà |
+| **Push** | Committer et pousser l'arbre de travail ; uniquement sur les dépôts utilisés pour les formulaires, la configuration, les playbooks, les workflows ou les inventaires, et activé seulement tant qu'il y a des modifications non encore poussées |
+| **Réinitialiser** | Supprimer l'arbre de travail et le cloner de nouveau, ce qui abandonne les modifications locales |
+| **Modifier les identifiants** | Ouvrir l'onglet **Identifiants** du dépôt, pour choisir l'identifiant qu'utilise git |
+| **Afficher la sortie du dernier pull** | Afficher la sortie de git pour le dernier clonage, pull ou réinitialisation, avec le mot de passe masqué |
+| **Afficher la sortie du dernier push** | Afficher la sortie de git pour le dernier push, avec le mot de passe masqué |
+| **Supprimer** | Supprimer l'enregistrement et son arbre de travail sous `REPO_PATH` ; réservé à un admin |
+
+**Tout puller**, au-dessus de la liste, fait un pull de tous les dépôts à la fois.
+
+Une seule opération git s'exécute à la fois sur un dépôt. Une deuxième est refusée avec
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Ajouter un dépôt
+
+Cliquez sur **Ajouter un dépôt** : un assistant demande les champs en quatre étapes (**Dépôt**, **Identifiants**, **Utilisation**, **Planification
+du pull**), et AnsibleForms lance le clonage en arrière-plan dès que vous enregistrez.
+
+![Modifier un dépôt](../assets/screenshots/git-edit.jpg)
+
+| Champ | Obligatoire | Signification |
+|---|---|---|
+| **Nom** | oui | Le nom du dossier sous `REPO_PATH` ; lettres, chiffres, tiret, tiret bas et point |
+| **Branche** | oui | La branche à cloner, à puller et à pousser, par exemple `main` ; obligatoire depuis la 7.3.0. Seul un dépôt du config seed peut l'omettre, pour cloner la branche par défaut du dépôt distant |
+| **Identifiant** | non | Un identifiant de [Connexions > Identifiants](../credentials.html) avec l'utilisateur et le mot de passe ou le jeton qu'utilise git ; **Ajouter un identifiant** en crée un |
+| **URI** | oui | Le dépôt distant, `https://...` ou SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Activer le pull planifié** | non | Faire un pull du dépôt selon une planification |
+| **Planification du pull** | non | Quand faire le pull, sous forme d'expression cron ; affiché une fois le pull planifié activé |
+| **Description** | oui | Une description libre |
+| **Utiliser pour la configuration ?** ... **Utiliser pour les inventaires ?** | non | Ce que contient le dépôt, voir [ci-dessus](./#what-a-repository-is-for) |
+| **Pull au démarrage de l'application** | non | Cloner le dépôt, ou en faire un pull, à chaque démarrage d'AnsibleForms |
+
+Renommer un dépôt déplace son arbre de travail vers le nouveau dossier, ainsi que sa planification de pull. Un dépôt d'avant
+la 7 qui a encore son propre utilisateur l'indique dans son onglet **Identifiants** : choisissez un identifiant pour le remplacer.
+
+---
+
+## Qui peut modifier un dépôt
+
+Le contenu d'un dépôt devient ce qu'AnsibleForms charge et exécute : depuis la 7.3.0, un utilisateur sans le rôle `admin` ne peut donc plus :
+
+- ajouter ou supprimer un dépôt ;
+- changer son **URI** ou sa **Branche** ;
+- activer ou désactiver l'un de ses interrupteurs **Utiliser pour**.
+
+Il peut toujours changer sa description, sa planification de pull et son identifiant, et faire un pull, un push ou une réinitialisation. Un identifiant qu'utilise un runner,
+une connexion ou une méthode de connexion ne peut pas être choisi par lui ; le refus le nomme, et ne dit rien de ce qu'il contient.
+
+---
+
+## Déclarer des dépôts dans le config seed
+
+Les dépôts peuvent aussi être déclarés dans le [config seed](../seed/), pour qu'une nouvelle instance les clone à son premier démarrage.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+Les champs sont ceux de la page, `credential` (un identifiant du seed ou de l'application), `rebase_on_start` (**Pull au démarrage de
+l'application**) et `cron` (la planification du pull) compris ; `user` et `password` sont toujours acceptés à la place d'un identifiant. Un
+dépôt issu du seed est en lecture seule dans l'interface, et il est cloné de nouveau au démarrage quand son arbre de travail est absent ; voir
+[Objets gérés](../seed/managed-objects.html).
diff --git a/i18n/fr/_use/repositories/authentication.md b/i18n/fr/_use/repositories/authentication.md
new file mode 100644
index 0000000..ecdc236
--- /dev/null
+++ b/i18n/fr/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Authentification
+parent: Dépôts git
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Authentification
+{: .no_toc }
+
+HTTPS avec un jeton, SSH avec la clé générée, et commandes git personnalisées
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Authentification
+
+La façon dont AnsibleForms s'authentifie dépend de la forme de l'**URI**.
+
+### HTTPS avec un jeton
+
+Pour un dépôt distant HTTPS privé, choisissez un **Identifiant** dont l'utilisateur est l'utilisateur git et dont le mot de passe est un jeton d'accès personnel
+(ou le mot de passe).
+
+Depuis la 7.3.0, git se connecte via `GIT_ASKPASS` : l'utilisateur et le jeton sont transmis à chaque commande git qui communique avec le serveur, jamais dans
+l'URL ; ils ne sont donc pas conservés dans le `.git/config` du clone, et un jeton modifié est utilisé au pull ou au push suivant. Le jeton a besoin
+d'un accès en lecture pour le pull, et en écriture pour le push. Un dépôt distant public n'a besoin d'aucun identifiant.
+
+Jusqu'à la 7.2.0, les deux étaient insérés dans l'URL, sous la forme `https://<user>:<token>@git.example.com/team/forms.git`. Un clone créé à cette époque conserve
+cette URL jusqu'à son prochain pull ou push, qui rétablit son remote sur l'**URI** propre au dépôt.
+
+### SSH avec la clé générée
+
+Pour un dépôt distant SSH, AnsibleForms s'authentifie avec sa propre paire de clés, qu'il génère au premier démarrage.
+
+1. Ouvrez **Paramètres > Connexions > SSH**, dans son onglet **Clé**, et copiez la **Clé publique**.
+2. Ajoutez-la sur le serveur git, comme clé de déploiement du dépôt (avec un accès en écriture si vous faites des push), ou à un utilisateur qui a accès.
+3. Ajoutez le dépôt avec une **URI** SSH, par exemple `git@git.example.com:team/forms.git`, et ne choisissez aucun identifiant.
+
+La paire de clés se trouve dans `.ssh/id_rsa` sous [`HOME_PATH`](../customization/paths.html#env_HOME_PATH) : gardez donc ce dossier sur
+un stockage persistant, sinon la clé change quand le conteneur est recréé.
+
+Lors du clonage avec une URI `user@host:path`, AnsibleForms exécute d'abord `ssh-keyscan` sur l'hôte et ajoute sa clé aux
+hôtes connus. Pour les autres dépôts distants, ajoutez l'hôte dans l'onglet **Hôtes connus** de **Paramètres > Connexions > SSH** avant le
+premier clonage.
+
+### Commandes git personnalisées
+
+Les commandes de clonage, de pull et de push peuvent être remplacées, par exemple pour ajouter des options git, avec trois réglages.
+
+| Réglage | Valeur par défaut | Ce qu'AnsibleForms ajoute |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, l'URI et le nom |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+Depuis la 7.3.0, ces commandes s'exécutent sans shell : les guillemets fonctionnent, mais un opérateur de shell comme `;`, `|`, `&&` ou `>` est refusé.
diff --git a/i18n/fr/_use/repositories/designer.md b/i18n/fr/_use/repositories/designer.md
new file mode 100644
index 0000000..62b7f53
--- /dev/null
+++ b/i18n/fr/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Concepteur et push
+parent: Dépôts git
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Concepteur et push
+{: .no_toc }
+
+Modifier des formulaires dans le concepteur et les pousser vers le dépôt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Modifier et pousser depuis le concepteur
+
+Avec un dépôt utilisé pour les formulaires, le concepteur modifie les fichiers de son arbre de travail et les pousse vers le dépôt distant.
+
+| Bouton | Ce qu'il fait |
+|---|---|
+| **Enregistrer (local)** | Écrit les formulaires et `config.yaml` dans les arbres de travail, sans commit |
+| **Enregistrer (dépôt)** | Committe et pousse les modifications enregistrées ; activé dès qu'il y a des modifications non poussées |
+| **Charger (dépôt)** | Fait un pull des dépôts de formulaires et recharge le concepteur, après confirmation si des modifications ne sont pas enregistrées |
+
+Les formulaires restent dans leur dépôt ; les nouveaux attendent, déjà utilisables, dans [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) jusqu'à ce que vous les poussiez.
+Un formulaire enregistré dans un sous-dossier garde son chemin relatif : `team/deploy.yaml` est poussé vers `team/deploy.yaml` sous le dossier des formulaires
+du dépôt. Un nouveau formulaire dont le chemin existe déjà là-bas n'est pas écrasé ; il reste en préparation : renommez-le donc.
+Avec plusieurs dépôts de formulaires, **Enregistrer (dépôt)** et **Charger (dépôt)** demandent lequel, par défaut celui de `config.yaml`.
+
+Un push indexe toutes les modifications, les committe en tant que `AnsibleForms` avec le message `Forms sync by <user>`, puis fait un fetch, un rebase sur
+le dépôt distant et un push, en réessayant jusqu'à cinq fois. Un conflit de rebase est abandonné et les fichiers en conflit sont listés ;
+corrigez-les dans le dépôt distant, ou utilisez **Réinitialiser** sur la page Dépôts. **Push** sur la page Dépôts fait la même chose.
+
+Quand un unique dépôt de formulaires est cloné vide, AnsibleForms copie le `config.yaml` local et les formulaires dans son arbre
+de travail, pour qu'un push (**Enregistrer (dépôt)**, ou **Push** sur la page Dépôts) les publie. Pour en savoir plus sur le concepteur, voir [Concepteur et git](../gui/designer-and-git.html).
diff --git a/i18n/fr/_use/repositories/index.md b/i18n/fr/_use/repositories/index.md
new file mode 100644
index 0000000..a3ab04f
--- /dev/null
+++ b/i18n/fr/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Dépôts git
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Dépôts git
+{: .no_toc }
+
+Conserver les formulaires, les fichiers de variables, la configuration et les playbooks dans git
+{: .fs-6 .fw-300 }
+
+---
+
+Pour les admins qui conservent formulaires, configuration et playbooks dans git : ce qu'un dépôt peut contenir et quelle source l'emporte.
+
+---
+
+## À quoi sert un dépôt
+
+Un dépôt est un dépôt git distant qu'AnsibleForms clone et tient à jour, et chacun a des interrupteurs qui indiquent ce qu'il contient :
+
+| Interrupteur | Ce qu'AnsibleForms y lit | Dossier dans le dépôt |
+|---|---|---|
+| **Utiliser pour la configuration ?** | `config.yaml` avec les catégories, les rôles et les constantes | la racine |
+| **Utiliser pour les formulaires ?** | Les fichiers de formulaires, que le concepteur y enregistre aussi, et leurs fichiers de variables | `forms`, ou la racine ; fichiers de variables dans `vars` |
+| **Utiliser pour les playbooks ?** | Les playbooks Ansible qu'exécutent les jobs | `playbooks`, ou la racine |
+| **Utiliser pour les workflows ?** | Les fichiers de [workflow](../workflows/), que le concepteur y enregistre aussi | n'importe quel dossier |
+| **Utiliser pour les inventaires ?** | Un inventaire, nommé d'après le dépôt, qu'un formulaire désigne avec `inventory:` | la racine : `inventory.yaml`, `group_vars`, `host_vars` |
+
+Sans le sous-dossier, la racine du dépôt est utilisée. Un seul dépôt peut tout contenir ; si vous les séparez, seuls **Utiliser pour les
+formulaires**, **Utiliser pour les workflows** et **Utiliser pour les inventaires** peuvent être activés sur plusieurs : les autres interrupteurs prennent le premier dépôt
+et journalisent un avertissement.
+
+Chaque dépôt est cloné dans un sous-dossier qui porte son nom, sous [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Un seul dépôt pour tout
+
+Un seul dépôt peut contenir les formulaires, les fichiers de variables, la configuration et les playbooks, avec les interrupteurs activés et un sous-dossier par type.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Un dépôt par usage
+
+Des dépôts séparés permettent aux équipes de posséder leur partie, avec un interrupteur chacun et les fichiers directement à la racine.
+
+| Dépôt | Interrupteur | Contenu à la racine |
+|---|---|---|
+| `af-config` | **Utiliser pour la configuration ?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Utiliser pour les formulaires ?** | Les fichiers de formulaires de chaque équipe, fusionnés en une seule liste |
+| `af-playbooks` | **Utiliser pour les playbooks ?** | Les playbooks et les rôles |
+
+Seuls les formulaires peuvent venir de plusieurs dépôts ; la configuration et les playbooks viennent chacun d'un seul. Les fichiers de variables viennent du dossier `vars`
+du premier dépôt de formulaires qui en a un.
+
+---
+
+## Comment les dépôts se combinent avec les dossiers locaux
+
+Le contenu d'un dépôt remplace le dossier local correspondant ; ce tableau résume d'où chaque type de fichier est lu.
+
+| Contenu | Lu depuis, la première correspondance l'emporte |
+|---|---|
+| Configuration | 1. la base de données, quand la configuration y est conservée ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. le `config.yaml` du dépôt **Utiliser pour la configuration** <br> 3. le `config.yaml` d'un dépôt **Utiliser pour les formulaires**, quand aucun dépôt n'est utilisé pour la configuration <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formulaires | Chaque dépôt **Utiliser pour les formulaires** plus `FORMS_STAGING_PATH` ; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) uniquement s'il n'y en a aucun |
+| Playbooks | Le dépôt **Utiliser pour les playbooks**, sinon [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Fichiers de variables | Le dossier `vars` du premier dépôt **Utiliser pour les formulaires** qui en a un, sinon [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflows | Chaque dépôt **Utiliser pour les workflows** plus [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), ensemble |
+
+Les formulaires de plusieurs dépôts sont fusionnés en une seule liste. Quand deux d'entre eux contiennent un formulaire portant le même nom, le premier
+chargé est conservé et l'avertissement `skipping duplicate form <name>` est journalisé : gardez donc des noms de formulaire uniques entre les dépôts.
+
+---
+
+## Dépannage
+
+La plupart des problèmes apparaissent dans la colonne **Pull** et dans **Afficher la sortie du dernier pull** (ou **Afficher la sortie du dernier push**), qui contiennent le
+message d'erreur de git lui-même.
+
+- [Le clonage ou le pull d'un dépôt a échoué](../troubleshooting.html#a-repository-clone-or-pull-failed) : authentification, hôtes
+  connus et modifications locales.
+- [Le dépôt de formulaires n'est pas encore cloné](../troubleshooting.html#the-forms-repository-is-not-cloned-yet) : le concepteur
+  ne peut pas enregistrer avant le premier clonage.
+- Un dépôt bloqué en `running` est remis à `failed` : après un redémarrage, au démarrage suivant ; en moins d'une minute dès que le nœud
+  qui exécute son opération git cesse de répondre pendant 2 minutes ; et dans tous les cas après 2 heures. Relancez **Pull**.
+
+---
+
+## Dans cette section
+
+Chaque sujet a sa propre page :
+
+| Page | Contenu |
+|---|---|
+| [Ajouter un dépôt](adding.html) | La page Dépôts, chaque champ d'un dépôt, et la déclaration d'un dépôt dans le config seed |
+| [Authentification](authentication.html) | HTTPS avec un jeton, SSH avec la clé générée, et commandes git personnalisées |
+| [Récupérer les modifications](pulling.html) | Pulls planifiés, manuels et via l'API, et modifications locales |
+| [Concepteur et push](designer.html) | Modifier des formulaires dans le concepteur et les pousser vers le dépôt |
diff --git a/i18n/fr/_use/repositories/pulling.md b/i18n/fr/_use/repositories/pulling.md
new file mode 100644
index 0000000..fb8db40
--- /dev/null
+++ b/i18n/fr/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Récupérer les modifications
+parent: Dépôts git
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Récupérer les modifications
+{: .no_toc }
+
+Pulls planifiés, manuels et via l'API, et modifications locales
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Récupérer les modifications
+
+Un pull d'un dépôt se fait selon sa planification, au démarrage, depuis la page ou via l'API ; il n'existe pas de point de terminaison webhook.
+
+| Déclencheur | Comment |
+|---|---|
+| Planification | **Activer le pull planifié** et une **Planification du pull**, par exemple `0 * * * *` pour toutes les heures |
+| Démarrage | **Pull au démarrage de l'application** clone le dépôt, ou fait un pull s'il est déjà cloné |
+| Page des paramètres | **Pull** dans le menu de la ligne, ou **Tout puller** au-dessus de la liste |
+| Concepteur | **Charger (dépôt)**, qui fait un pull des dépôts de formulaires et recharge le concepteur ; prendre le verrou du concepteur fait aussi d'abord un pull de tous les dépôts de formulaires |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` ou `showConnectionsSettings`) ou `POST /api/v2/forms-repos/pull/<name>` (voir ci-dessous) |
+
+### Pull depuis un pipeline ou un webhook
+
+AnsibleForms n'a pas de récepteur de webhook dédié, mais un job de CI ou un webhook de serveur git peut appeler le point de terminaison de pull.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Créez le jeton comme décrit dans [Jetons d'API](../profile/api-token.html), pour un utilisateur dont le rôle a `showSettings` ou
+`showConnectionsSettings`. `/api/v2/forms-repos/pull/<name>` nécessite plutôt `showDesigner` et `allowFormDesign`, avec le concepteur
+activé ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` renvoie le
+`head`, le `status` et l'`output`, pour qu'un pipeline puisse vérifier quel commit l'instance exécute après un pull.
+
+### Modifications locales
+
+Un pull n'écrase jamais un travail qui n'est pas encore poussé : un pull planifié vérifie donc l'arbre de travail avant de s'exécuter.
+
+Un pull planifié est ignoré tant que l'arbre de travail a des modifications non commitées ou des commits non poussés, et tant qu'un concepteur
+détient le verrou du concepteur. Un pull manuel d'un arbre de travail avec des modifications en conflit échoue avec :
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Poussez les modifications, ou abandonnez-les avec **Réinitialiser** dans le menu de la ligne, ce qui supprime l'arbre de travail et le clone de nouveau.
diff --git a/i18n/fr/index.md b/i18n/fr/index.md
new file mode 100644
index 0000000..441e5a5
--- /dev/null
+++ b/i18n/fr/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Accueil
+nav_order: 1
+description: "AnsibleForms : créez des formulaires dynamiques pilotés par les données pour l'automatisation avec Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Des formulaires en libre-service pour <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible est un puissant outil d'automatisation, mais il reste une application en ligne de commande, et il manque à AWX/AAP/Ascender
+      des formulaires qui recueillent des données de plusieurs sources. AnsibleForms vous permet de créer des formulaires dynamiques, alimentés par des données, de générer des extravars
+      et de les envoyer à Ansible, AWX/AAP/Ascender, Semaphore, Rundeck ou Jenkins pour y exécuter des templates.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">Installer AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">Créer votre premier formulaire</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="Le tableau de bord d'AnsibleForms">
+  </div>
+</div>
+
+## Fonctionnalités
+
+Ce qu'AnsibleForms apporte à votre installation Ansible, et ce qu'un seul formulaire peut faire :
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Application</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Plateformes d'automatisation</strong><span>Des playbooks sur des RTE, des templates sur Ascender, Semaphore et d'autres</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Contrôle d'accès</strong><span>Rôles et options de rôle, avec des connexions locales, LDAP, Entra ID et OIDC</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Planification</strong><span>Exécuter un formulaire plus tard, ou selon une planification cron</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Historique des jobs</strong><span>Suivre, arrêter et relancer des jobs</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Identifiants et secrets</strong><span>Stocker des identifiants, ou les lire depuis Vault ou CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dépôts git</strong><span>Conserver formulaires, playbooks et configuration dans Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Concepteur</strong><span>Modifier les formulaires en YAML, avec validation</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP et chat</strong><span>Lancer des formulaires depuis des scripts, des agents IA ou un chat</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formulaires</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Listes déroulantes en cascade</strong><span>Des listes déroulantes qui réagissent aux autres champs</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Expressions et sources de données</strong><span>Remplir des champs depuis des bases de données, des API REST, des fichiers et du JavaScript</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dépendances entre champs</strong><span>Afficher ou masquer des champs selon d'autres champs</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validation</strong><span>Min, max, regex et plus, avec vérification facultative sur le serveur</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflows et assistants</strong><span>Enchaîner playbooks et approbations, ou répartir la saisie sur plusieurs pages</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Champs structurés</strong><span>Des listes et des objets reposant sur des sous-formulaires réutilisables</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Points d'approbation</strong><span>Mettre un job en pause jusqu'à ce que quelqu'un l'approuve</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Notifications</strong><span>Mail, Slack, Teams, Telegram ou un webhook sur les événements des jobs</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Besoin d'aide ?
+
+Les questions, les bugs et les signalements de sécurité ont chacun leur place :
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Dépannage</strong>
+    <span>Rechercher un message d'erreur et la façon de le corriger</span>
+    <span class="af-card-more">Dépannage &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Poser une question</strong>
+    <span>Interroger la communauté et les mainteneurs</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Signaler un bug</strong>
+    <span>Ouvrir une issue avec les étapes pour le reproduire</span>
+    <span class="af-card-more">Nouvelle issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Obtenir de l'aide</strong>
+    <span>Ce qu'il faut inclure, et comment signaler un problème de sécurité</span>
+    <span class="af-card-more">Obtenir de l'aide &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/it.yml b/i18n/it.yml
new file mode 100644
index 0000000..b1109e3
--- /dev/null
+++ b/i18n/it.yml
@@ -0,0 +1,42 @@
+# The Italian docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: it
+docs_language: "it"
+
+title: "Documentazione di AnsibleForms"
+description: "Documentazione tecnica di AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Tutti i diritti riservati."
+
+# "Edit this page on GitHub" opens the Italian page's source
+gh_edit_link_text: "Modifica questa pagina su GitHub"
+gh_edit_source: i18n/it
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Introduzione"
+    get_started:
+      name: "Primi passi"
+    configure:
+      name: "Configurare"
+    build_forms:
+      name: "Creare moduli"
+    use:
+      name: "Guida utente"
+    integrate:
+      name: "Integrare"
+    security_assessment:
+      name: "Sicurezza"
+    reference:
+      name: "Riferimento"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (ultima)"
+    url: "/it/"
+  - name: "6"
+    title: "6.x (in inglese)"
+    url: "/v6/"
diff --git a/i18n/it/_build_forms/expressions/credentials.md b/i18n/it/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..d347e0c
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Credenziali
+parent: Espressioni
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Credenziali
+{: .no_toc }
+
+Leggere una credenziale salvata in un'espressione
+{: .fs-6 .fw-300 }
+
+---
+
+Leggi una credenziale salvata per nome o tramite espressione regolare, con un'alternativa di riserva:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Prima si prova il nome esatto. Se nessuna credenziale ha quel nome, il nome viene usato come espressione regolare, e poi si prova l'alternativa.
+
+#### Limitato dal ruolo
+
+Quando uno dei ruoli dell'utente elenca `credentials` in `config.yaml`, `fn.fnCredentials` restituisce solo una credenziale consentita
+da un ruolo del genere: i pattern del ruolo vengono confrontati con il nome della credenziale trovata (per nome, espressione regolare o alternativa),
+e qualsiasi altra viene rifiutata. I ruoli senza l'elenco non la limitano, e un amministratore non è mai limitato.
+
+#### Credenziali da un archivio di segreti
+
+Una credenziale che indica un [archivio di segreti](../secret-stores) ottiene `user` e `password`
+da quell'archivio al momento dell'esecuzione. `fn.fnCredentials('myapp')` continua a funzionare senza modifiche.
+
+Un segreto si può leggere anche senza una riga di credenziale, ovunque sia accettato un nome di credenziale
+(compresi `fnRestBasic`, `fnRestJwtSecure` e le sostituzioni negli header di `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+Le chiavi del segreto vengono mappate come descritto in [Nomi delle chiavi](../secret-stores#key-names).
+Un segreto con un'altra struttura viene rimodellato con un'espressione `jq` come terzo argomento:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/it/_build_forms/expressions/index.md b/i18n/it/_build_forms/expressions/index.md
new file mode 100644
index 0000000..e7c73b5
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Espressioni
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Espressioni
+{: .no_toc }
+
+Calcolare i valori dei campi con JavaScript, nel browser o sul server
+{: .fs-6 .fw-300 }
+
+---
+
+Per chi scrive i moduli: compila i campi in modo dinamico con JavaScript, calcolati nel browser o recuperati sul server.
+
+L'attributo `expression` di un campo del modulo ti permette di creare moduli dinamici con espressioni JavaScript.
+
+---
+
+## Introduzione
+
+L'attributo `expression` è disponibile su diversi tipi di campo:
+- campo `enum`: per popolare dinamicamente le opzioni del menu a tendina
+- campo `expression`: per recuperare o generare qualsiasi tipo di dato
+- campo `html`: per costruirne il contenuto HTML
+- campi `yaml` e `list`: per riempirne i dati
+
+Le espressioni JavaScript vengono valutate **lato server** (predefinito) oppure **lato client**, in base alla proprietà `runLocal` del campo.
+Un campo `html`, e i tipi di campo `local`, `local_out` e `credential`, eseguono sempre la loro espressione nel browser, qualunque cosa dica
+`runLocal`.
+
+- **Lato server** (`runLocal: false`, il valore predefinito): funzioni predefinite che recuperano dati da API, file e database.
+- **Lato client** (`runLocal: true`): il codice sfrutta l'intero motore JavaScript nella sandbox del browser per calcoli, trasformazioni e manipolazioni.
+
+---
+
+## Considerazioni sulla sicurezza
+
+Poiché le espressioni vengono valutate con la funzione JavaScript `eval`, l'iniezione di codice è un rischio potenziale:
+
+- **Le espressioni lato server** passano prima da un sanitizzatore: ogni chiamata deve essere una funzione `fn.` o `fnc.`, e vengono rifiutati le righe multiple,
+  `;`, i template literal, `process.env` e i modi per uscire da `eval` (`import`, `require`, `constructor`, ...).
+- **Le espressioni lato client** vengono valutate nella sandbox del browser e si possono considerare sicure.
+
+Quanto è severo il sanitizzatore dipende da
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER):
+
+| Valore | Espressioni lato server |
+|---|---|
+| `strict` (predefinito) | chiamate `fn.` e `fnc.`, e metodi sul loro risultato, come `fn.fnTime().format('YYYY')` |
+| `paranoid` | solo chiamate dirette `fn.` e `fnc.`, nessun metodo sul loro risultato |
+| `off` | ogni espressione lato server viene rifiutata; funzionano solo le espressioni `runLocal` |
+| `legacy` | le regole della 6.2.1, che permettevano a qualsiasi utente autenticato di eseguire codice sul server; solo per un aggiornamento, e solo nell'ambiente reale (non dalla pagina delle impostazioni) |
+
+Un valore vuoto o sconosciuto equivale a `strict`. Una modifica vale dalla prossima espressione, senza riavvio.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina dedicata:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Segnaposto](placeholders.html) | Fare riferimento a un altro campo, a una costante o all'utente con `$(...)` |
+| [Espressioni locali](local.html) | JavaScript eseguito nella sandbox del browser |
+| [Espressioni remote](remote.html) | Funzioni lato server per date, reti, file, SSH e nomi numerati |
+| [API REST](rest-apis.html) | Chiamare API REST con autenticazione basic, a token o personalizzata |
+| [Credenziali](credentials.html) | Leggere una credenziale salvata |
+| [Ordinamento](sorting.html) | Ordinare array con un oggetto di ordinamento |
+| [Query jq](jq.html) | Rimodellare i dati con jq |
diff --git a/i18n/it/_build_forms/expressions/jq.md b/i18n/it/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..7b4c06a
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Query jq
+parent: Espressioni
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# Query jq
+{: .no_toc }
+
+Rimodellare i dati con jq, comprese le funzioni integrate
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Eseguire una JSON Query (jq) su un oggetto
+
+Rimodella un oggetto, per esempio il valore di un altro campo, con un'espressione jq:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+Dalla 7.3.0 un filtro jq gira al massimo per [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (30 per impostazione predefinita)
+prima di essere fermato, e il suo output è limitato a 64 MB. Questo vale per `fn.fnJq` e per l'espressione jq delle funzioni di query REST, su file,
+su credenziali e su database.
+
+---
+
+## Funzioni jq integrate
+
+Tutte le funzioni che recuperano dati accettano una JSON query (jq), un linguaggio per manipolare oggetti e array di dati.  
+Quando manipoli i dati, potresti dover convertire i byte in KB, MB o GB, o arrotondare i numeri.  
+Per questo AnsibleForms include alcune funzioni jq personalizzate:
+
+- **fn2KB**: da byte a KB
+- **fn2MB**: da byte a MB
+- **fn2GB**: da byte a GB
+- **fnRound0**: arrotonda a 0 decimali
+- **fnRound1**: arrotonda a 1 decimale
+- **fnRound2**: arrotonda a 2 decimali
+- **fnRound**: arrotonda a 2 decimali
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/it/_build_forms/expressions/local.md b/i18n/it/_build_forms/expressions/local.md
new file mode 100644
index 0000000..2a26cdf
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Espressioni locali
+parent: Espressioni
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Espressioni locali
+{: .no_toc }
+
+JavaScript eseguito nella sandbox del browser
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Gli esempi seguenti girano con la proprietà del campo `runLocal: true`.  
+Vengono eseguiti nella sandbox del browser e possono sfruttare l'intero motore JavaScript.
+
+{: .note }
+> **Suggerimento**: usa il tipo `local` come alias di `type: expression, runLocal: true, hide: true, output: false`  
+> **Suggerimento**: usa il tipo `local_out` come alias di `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Convenzioni di nomenclatura
+
+Usa le manipolazioni di stringhe per applicare le convenzioni di nomenclatura.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Calcoli
+
+Usa la matematica per fare calcoli.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Conversioni
+
+Converti i byte in gigabyte.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Convertire un array di oggetti in una tabella HTML
+
+Trasforma un array di oggetti, per esempio da un altro campo, in una tabella HTML per un campo `html`:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Ottenere un nome con numerazione incrementale
+
+Con la numerazione automatica, potresti dover trovare il nome successivo in un array di stringhe numerate.  
+Questa funzione è disponibile anche come espressione lato server (con il prefisso `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Quando il primo argomento non è un array, la funzione locale restituisce il valore predefinito. La funzione server `fn.fnGetNumberedName`
+invece fallisce con un errore.
+
+---
+
+## Manipolazione di array di oggetti
+
+Gli array di oggetti spesso vanno filtrati, modificati e ordinati.  
+AnsibleForms include un helper personalizzato che mantiene questo codice conciso.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Manipolazione di array di oggetti con JavaScript puro
+
+Tutti i metodi standard degli array JavaScript restano disponibili per filtrare e modificare i dati, come `map`, `forEach`, `find`, `filter` e `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/it/_build_forms/expressions/placeholders.md b/i18n/it/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..2df5af9
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Segnaposto
+parent: Espressioni
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Segnaposto
+{: .no_toc }
+
+Fare riferimento a un altro campo, a una costante o all'utente corrente con `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Che cos'è un segnaposto
+
+Un segnaposto è un riferimento scritto come `$(reference)`. Viene sostituito da un valore prima che il testo che lo contiene venga usato.
+
+I segnaposto funzionano in `expression`, `query` e `default` di un campo (valutato con `evalDefault`), e in `label`,
+`help` e `placeholder`. Un campo che contiene un segnaposto dipende dal campo che nomina: attende finché quel campo ha un
+valore, e viene valutato di nuovo ogni volta che quel valore cambia. È così che si costruiscono i menu a tendina a cascata.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## A cosa può fare riferimento un segnaposto
+
+Un segnaposto nomina un campo del modulo, oppure uno di questi, che ogni modulo ha:
+
+| Riferimento | Cosa contiene |
+|---|---|
+| `$(field)` | il valore di un altro campo del modulo |
+| `$(name)`, una costante | una [costante](../config/constants.html) di `config.yaml`, o un valore dai `varsFiles` del modulo |
+| `$(__user__)` | l'utente che ha effettuato l'accesso: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | in un [sottomodulo](../forms/subform.html) (una riga di lista, un passo di wizard), un valore del modulo padre |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Accedere a una parte del valore
+
+La notazione a punti e a indici legge una parte di un valore, purché il percorso contenga solo lettere, cifre, `_`, `-`, `.` e `[n]`:
+
+| Segnaposto | Su | Restituisce |
+|---|---|---|
+| `$(field)` | un campo di testo, numero o password | il valore |
+| `$(field)` | un enum di record | la `placeholderColumn` del record selezionato, altrimenti la sua prima colonna |
+| `$(field.col)` | un enum di record | quella colonna del record selezionato |
+| `$(field)` | un enum con `multiple: true` | la colonna scelta di ogni record selezionato, come array |
+| `$(field)` | un'espressione, una lista o una costante | l'intero valore (una lista restituisce le sue righe) |
+| `$(field.a.b)`, `$(f[0].x)` | un'espressione, una lista o una costante | quella parte dell'oggetto o dell'array |
+
+Impostando `placeholderColumn: "*"` su un enum, `$(field)` restituisce l'intero record selezionato invece di una colonna.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Come viene inserito il valore
+
+Il modo in cui un valore viene scritto nel testo dipende da dove si trova il segnaposto.
+
+| Dove | Esempio | Diventa |
+|---|---|---|
+| un'espressione, fuori dagli apici | `$(count) + 1` | un letterale JavaScript: un numero resta un numero, un testo diventa una stringa tra apici, un oggetto o un array un letterale |
+| un'espressione, l'intera stringa tra apici | `fn.fnLs('$(dir)')` | lo stesso letterale, apici compresi, così un valore che contiene un apice non può uscirne |
+| un'espressione, dentro una stringa più lunga | `'$(dir)/vars'` | il testo, con l'escape per quella stringa |
+| una query, un'etichetta, un testo di aiuto | `where city='$(city)'` | il testo |
+
+Un campo i cui segnaposto non possono ancora essere risolti tutti non viene valutato; con `ignoreIncomplete: true` un valore mancante viene
+invece scritto come `undefined`.
+
+### Backtick e `${` in un valore
+
+Dalla 7.3.0 il valore di un campo non può essere eseguito come codice quando il server lo scrive in un'espressione (espressioni remote, validazione
+all'avvio, MCP e chat). Un backtick o `${` nel valore viene scritto come escape unicode (`\u0060`, `\u0024{`), così resta
+testo anche dentro un template literal. Le espressioni lato server rifiutano del tutto i template literal; per quelli usa `runLocal`.
+
+Un'espressione `runLocal` valutata nel browser inserisce il valore come indicato nella tabella sopra, senza quell'escape, quindi lì non mettere
+un segnaposto dentro un template literal.
+
+---
+
+## Vedi anche
+
+Pagine correlate e voci delle FAQ:
+
+- [Espressioni locali](local.html) e [Espressioni remote](remote.html): dove si usa la maggior parte dei segnaposto
+- [FAQ: Menu a tendina a cascata](../faq.html#cascaded-dropdowns) e [Segnaposto dei campi](../faq.html#field-placeholders): altri esempi
+- [FAQ: Come accedo ai dati del modulo padre dentro un sottomodulo?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/it/_build_forms/expressions/remote.md b/i18n/it/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..cfa9c08
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Espressioni remote
+parent: Espressioni
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Espressioni remote
+{: .no_toc }
+
+Funzioni lato server per date, reti, file, SSH e nomi numerati
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Gli esempi seguenti girano con la proprietà del campo `runLocal: false` (predefinita).  
+Vengono valutati lato server.
+
+Poiché valutare codice sul server è un rischio per la sicurezza, l'espressione viene sanitizzata e limitata alle funzioni fornite
+con AnsibleForms e alle [funzioni che aggiungi tu](#your-own-functions).  
+Le espressioni lato server servono a recuperare informazioni da sorgenti di dati come file, API REST e comandi SSH.
+
+{: .important }
+Le funzioni lato server integrate hanno il prefisso `fn.` (per esempio `fn.fnRestBasic`), le tue il prefisso `fnc.`.
+
+---
+
+## Manipolare data e ora
+
+Lavora con date e orari tramite [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## Ottenere informazioni CIDR da un IP
+
+Ottieni la subnet di un indirizzo IP e di una netmask, e verifica quali indirizzi ne fanno parte:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## Ottenere l'output SSH
+
+Esegui un comando su un host remoto via SSH e usane l'output:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Elencare i file di una directory
+
+Elenca i file di una directory sul server AnsibleForms, facoltativamente in modo ricorsivo e filtrato:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Analizzare una pagina HTML
+
+Scarica una pagina HTML ed estrai le parti che corrispondono a un'espressione regolare:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+La pagina viene scaricata rispettando [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) e
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), come le funzioni REST. A differenza di queste, ignora
+`REST_IGNORE_CERTS` e `REST_TIMEOUT_SECONDS`: verifica sempre il certificato e attende al massimo 30 secondi.
+
+---
+
+## Ottenere informazioni DNS
+
+Risolvi un record DNS di un dominio:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Leggere un file JSON
+
+Leggi un file JSON sul server, facoltativamente filtrato con jq:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Leggere un file YAML
+
+Leggi un file YAML sul server, facoltativamente filtrato con jq:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Ottenere un nome con numerazione incrementale
+
+In un array di stringhe con numeri incrementali (server001, server002, ...), potresti dover trovare il prossimo nome disponibile.  
+Questa funzione è disponibile anche come espressione locale (senza il prefisso `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Sul server, `fn.fnGetNumberedName` fallisce con un errore quando il primo argomento non è un array. L'espressione locale
+(senza `fn.`) restituisce invece il valore predefinito.
+
+---
+
+## Le tue funzioni
+
+Aggiungi funzioni JavaScript tue in `custom.js`, e chiamale in un'espressione lato server con il prefisso `fnc.`.
+
+Il file esporta un oggetto di funzioni. Quello incluso nell'immagine contiene due esempi:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+Allo stesso modo, `jq.custom.definitions` contiene definizioni jq tue. Vengono anteposte a ogni query jq eseguita dal
+server, così le [query jq](jq.html) di ogni funzione possono usarle.
+
+In un container, monta entrambi i file sopra quelli dell'immagine e riavvia; vengono letti all'avvio del server:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Una funzione personalizzata gira dentro il processo del server, con i suoi permessi, ogni volta che un'espressione la chiama. Il
+> [sanitizzatore](index.html#security-concerns) verifica che l'espressione chiami solo funzioni `fn.` e `fnc.`; cosa una
+> funzione fa con i suoi argomenti dipende da te.
diff --git a/i18n/it/_build_forms/expressions/rest-apis.md b/i18n/it/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..0c9e517
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: API REST
+parent: Espressioni
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# API REST
+{: .no_toc }
+
+Chiamare API REST con autenticazione basic, a token o personalizzata
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## API REST con autenticazione basic
+
+Chiama un'API REST con l'utente e la password di una credenziale salvata:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## API REST con autenticazione a token
+
+Chiama un'API REST con un bearer token scritto nell'espressione:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST con autenticazione a token protetta
+
+Chiama un'API REST con un bearer token preso da una credenziale salvata, così non compare mai nel modulo:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST con header personalizzati
+
+Chiama un'API REST con header tuoi, per qualsiasi altro tipo di autenticazione:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certificati e timeout
+
+Dalla 7.3.0 ogni funzione helper REST (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) verifica il certificato
+TLS dell'endpoint e smette di attendere dopo un tempo prestabilito:
+
+| Impostazione | Cosa cambia |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` salta la verifica del certificato. Fino alla 7.2.0 non veniva mai verificato; lascialo a `0` e affidati invece a una CA privata con `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Quanto attende una chiamata per una risposta, 60 secondi per impostazione predefinita; un endpoint che non risponde mai fa allora fallire il campo invece di tenerlo bloccato |
+
+Dalla 7.3.0 un campo il cui endpoint ha un certificato autofirmato fallisce con un errore di certificato finché non si imposta una delle due.
+[Chiamate REST e jq](../customization/security.html#rest-calls-and-jq) le descrive entrambe, e spiega come considerare attendibile una CA privata per tutte le chiamate REST in una volta.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) non è un helper REST: ignora entrambe le impostazioni, verifica sempre il
+certificato e attende al massimo 30 secondi.
diff --git a/i18n/it/_build_forms/expressions/sorting.md b/i18n/it/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..5af2764
--- /dev/null
+++ b/i18n/it/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Ordinamento
+parent: Espressioni
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Ordinamento
+{: .no_toc }
+
+Ordinare array con un oggetto di ordinamento
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ordinare un array
+
+Ordina un array proveniente da un'espressione, da un'API REST o da un database con un oggetto di ordinamento:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## L'oggetto di ordinamento
+
+Le funzioni REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) accettano questo oggetto di ordinamento
+come argomento. Per qualsiasi altro risultato, come `fn.fnJq` o la lettura di un file, racchiudilo in `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/it/_build_forms/formfields/checkbox.md b/i18n/it/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..b5f0635
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Campi del modulo
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Campo Checkbox
+{: .no_toc }
+
+Un valore vero o falso, per attivare un'opzione o impostare un flag
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `checkbox`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `checkbox`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/datetime.md b/i18n/it/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..b528d4a
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Campi del modulo
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Campo Datetime
+{: .no_toc }
+
+Un selettore di data, ora, settimana, mese o anno
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `datetime`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `datetime`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/enum.md b/i18n/it/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..2eaa34a
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Campi del modulo
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Campo Enum
+{: .no_toc }
+
+Un menu a tendina con ricerca, per scelte singole o multiple
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `enum`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `enum`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/expression.md b/i18n/it/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..545c456
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Campi del modulo
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Campo Expression
+{: .no_toc }
+
+Un valore calcolato da JavaScript, nel browser o sul server
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `expression`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `expression`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/file.md b/i18n/it/_build_forms/formfields/file.md
new file mode 100644
index 0000000..90eb772
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Campi del modulo
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Campo File
+{: .no_toc }
+
+Caricare file, come file di configurazione o certificati
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `file`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `file`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/html.md b/i18n/it/_build_forms/formfields/html.md
new file mode 100644
index 0000000..02d2243
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Campi del modulo
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Campo Html
+{: .no_toc }
+
+Contenuto HTML ricco all'interno di un modulo
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `html`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `html`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/index.md b/i18n/it/_build_forms/formfields/index.md
new file mode 100644
index 0000000..ab4e0b3
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Campi del modulo
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Campi del modulo
+{: .no_toc }
+
+I controlli di input di un modulo
+{: .fs-6 .fw-300 }
+
+---
+
+Per chi scrive i moduli: i tipi di campo che un modulo può contenere, e le proprietà supportate da ciascuno.
+
+I campi del modulo definiscono i controlli di input di un modulo. Ogni tipo di campo ha proprietà e comportamento propri per raccogliere un determinato tipo di dato.
+
+Scegli il tipo di campo adatto ai dati da raccogliere, dal semplice testo alle liste strutturate.
+
+---
+
+## Proprietà comuni
+
+Tutti i campi del modulo condividono due proprietà fondamentali:
+
+- **name** (string, obbligatorio): l'identificatore univoco del campo
+- **type** (string, obbligatorio): il tipo di campo, che determina quale delle pagine seguenti descrive le proprietà disponibili
+
+Ogni tipo di campo aggiunge proprietà specifiche della sua funzione. Seleziona un tipo di campo nella barra di navigazione laterale o nella tabella qui sotto per aprire il riferimento completo delle sue proprietà:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Tipo di campo</th>
+      <th>Descrizione</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/it/_build_forms/formfields/list.md b/i18n/it/_build_forms/formfields/list.md
new file mode 100644
index 0000000..c297a8f
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Campi del modulo
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Campo List
+{: .no_toc }
+
+Una tabella di righe, ognuna modificata in un sottomodulo
+{: .fs-6 .fw-300 }
+
+---
+
+Un campo list mostra una tabella di righe, ognuna creata e modificata in un pannello dedicato di **sottomodulo** (uno schema di drilldown). Sostituisce il campo `table`, rimosso nella 7.0.0.
+
+---
+
+## Caratteristiche principali
+
+Il campo list offre le seguenti funzionalità:
+
+- Ogni riga viene modificata in un sottomodulo a schermo intero, che dà accesso a tutti i tipi di campo, comprese le liste annidate.
+- Il sottomodulo è un modulo a sé, di tipo `subform`, e può essere **riutilizzato in più campi list** di moduli diversi (ad es. un unico sottomodulo `Address` condiviso da clienti, fornitori, ordini…).
+- Le proprietà marker (`insertMarker`, `updateMarker`, `deleteMarker`) supportano schemi di playbook idempotenti.
+- Con `allowDelete: false`, le righe preesistenti sono protette; si possono eliminare solo le righe aggiunte nella sessione corrente (quelle con l'`insertMarker`).
+- La proprietà `columns` stabilisce quali campi del sottomodulo compaiono come colonne nella tabella riepilogativa.
+- L'output è sempre un array di oggetti. `model`, `output`, `outputObject` e `valueColumn` dichiarati sui campi del sottomodulo vengono rispettati quando si generano le extravars.
+
+---
+
+## Dichiarazione del sottomodulo
+
+Un sottomodulo è un modulo a sé con `type: subform`, in un file della cartella dei moduli come qualsiasi altro modulo. Accetta lo stesso array `fields` di qualsiasi altro modulo, ma non compare mai nell'elenco a riquadri dei moduli e non viene mai inviato direttamente.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `list`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Esempi</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Esempi
+
+### Sottomodulo di indirizzo condiviso
+
+Un unico sottomodulo `Address` riutilizzato da due campi list dello stesso modulo:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Tracciamento con marker (attento all'idempotenza)
+
+Le righe precaricate sono protette, e i marker indicano al playbook quali righe sono nuove, modificate o rimosse:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Precompilare le righe
+
+Una lista può essere precompilata da tre sorgenti. In ogni caso, le righe risultanti devono essere oggetti le cui chiavi corrispondono ai nomi dei campi del sottomodulo a cui si fa riferimento.
+
+#### `default` statico
+
+Righe scritte nel modulo stesso:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Da un'API REST (`expression`)
+
+Righe caricate da un'API REST tramite un'espressione lato server:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Da una query su database (`dbConfig` + `query`)
+
+Righe caricate da una query su database:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Da un'espressione locale (`runLocal`)
+
+Righe calcolate nel browser da un'espressione locale:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Liste annidate
+
+Un sottomodulo può contenere un proprio campo list, per avere una lista dentro ogni riga:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Accedere ai dati del modulo padre tramite `__parent__`
+
+Quando si apre l'editor di una riga del sottomodulo, AnsibleForms inserisce una variabile `__parent__` nel sottomodulo. Contiene un'istantanea di **tutti i valori dei campi del modulo padre**, comprese costanti e variabili.
+
+Fai riferimento a essa con la sintassi standard delle espressioni `$(...)` nelle definizioni dei campi del sottomodulo:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` è un helper **solo frontend**. Viene rimosso dalle extravars di Ansible e non viene mai inviato al playbook.
+
diff --git a/i18n/it/_build_forms/formfields/number.md b/i18n/it/_build_forms/formfields/number.md
new file mode 100644
index 0000000..1bfb9ba
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Campi del modulo
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Campo Number
+{: .no_toc }
+
+Un valore intero o decimale, come una porta o una quantità
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `number`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `number`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/password.md b/i18n/it/_build_forms/formfields/password.md
new file mode 100644
index 0000000..1664a62
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Campi del modulo
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Campo Password
+{: .no_toc }
+
+Un valore mascherato, per password, segreti e token
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `password`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `password`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/radio.md b/i18n/it/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..2132edb
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Campi del modulo
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Campo Radio
+{: .no_toc }
+
+Una scelta tra un insieme di opzioni che si escludono a vicenda
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `radio`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `radio`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/text.md b/i18n/it/_build_forms/formfields/text.md
new file mode 100644
index 0000000..1d91e45
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Campi del modulo
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Campo Text
+{: .no_toc }
+
+Una singola riga di testo, come un nome o un nome host
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `text`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `text`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/textarea.md b/i18n/it/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..0f0b857
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Campi del modulo
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Campo Textarea
+{: .no_toc }
+
+Testo su più righe, come una descrizione o un frammento di configurazione
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `textarea`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `textarea`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/it/_build_forms/formfields/yaml.md b/i18n/it/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..94a777b
--- /dev/null
+++ b/i18n/it/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Campi del modulo
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Campo YAML
+{: .no_toc }
+
+Dati strutturati in un editor YAML, con convalida e importazione da file
+{: .fs-6 .fw-300 }
+
+---
+
+## Proprietà
+
+Le proprietà disponibili per un campo `yaml`, raggruppate per scopo:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valore:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di campi `yaml`, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione del campo, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Accedere ai dati del modulo padre tramite `__parent__`
+
+Quando un campo `yaml` usa la modalità `subform`, AnsibleForms inserisce una variabile `__parent__` nel sottomodulo. Contiene un'istantanea di **tutti i valori dei campi del modulo padre** al momento dell'apertura dell'editor, comprese costanti e variabili.
+
+Fai riferimento a essa con la sintassi standard delle espressioni `$(...)` nelle definizioni dei campi del sottomodulo:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` è un helper **solo frontend**. Viene rimosso dalle extravars di Ansible e non viene mai inviato al playbook.
diff --git a/i18n/it/_build_forms/forms/ansible.md b/i18n/it/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..964cdce
--- /dev/null
+++ b/i18n/it/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Moduli Ansible
+parent: Moduli
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Moduli Ansible
+{: .no_toc }
+
+Moduli che eseguono un playbook Ansible locale
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: ansible`, in aggiunta alle [proprietà comuni dei moduli](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/approval.md b/i18n/it/_build_forms/forms/approval.md
new file mode 100644
index 0000000..5925a4e
--- /dev/null
+++ b/i18n/it/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Punti di approvazione
+parent: Moduli
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Punti di approvazione
+{: .no_toc }
+
+Mettere in pausa un job finché qualcuno non lo approva
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Come funziona
+
+Un punto di approvazione mette in pausa il job nel suo punto del modulo finché un approvatore non risponde:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Approvare il proprio job
+
+Dalla 7.3.0 l'utente che ha avviato un job non può approvarlo, nemmeno con uno dei ruoli dell'approvazione, quindi serve una seconda persona; un amministratore può sempre approvare, anche i propri job.
+Chi l'ha avviato può comunque rifiutare (ritirare) il proprio job. Imposta `allowSelf: true` quando può anche approvarlo, per esempio in un modulo di test:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Attributi
+
+Gli attributi di un punto di approvazione:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di punti di approvazione, in YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/awx.md b/i18n/it/_build_forms/forms/awx.md
new file mode 100644
index 0000000..29982cf
--- /dev/null
+++ b/i18n/it/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Moduli AWX
+parent: Moduli
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# Moduli AWX
+{: .no_toc }
+
+Moduli che avviano un modello di job di AWX, AAP o Ascender
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: awx`, in aggiunta alle [proprietà comuni dei moduli](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/common.md b/i18n/it/_build_forms/forms/common.md
new file mode 100644
index 0000000..a22dfba
--- /dev/null
+++ b/i18n/it/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Proprietà comuni
+parent: Moduli
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Proprietà comuni dei moduli
+{: .no_toc }
+
+Proprietà condivise da tutti i tipi di modulo
+{: .fs-6 .fw-300 }
+
+---
+
+Queste proprietà valgono per **tutti i tipi di modulo**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (deprecato) e `subform`.
+
+Tutte le altre proprietà sono specifiche del tipo e sono documentate nella pagina del rispettivo tipo di modulo.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Proprietà
+
+Le proprietà condivise da tutti i tipi di modulo:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/it/_build_forms/forms/index.md b/i18n/it/_build_forms/forms/index.md
new file mode 100644
index 0000000..11eeeb2
--- /dev/null
+++ b/i18n/it/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Moduli
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Moduli
+{: .no_toc }
+
+Definire i moduli che i tuoi utenti compilano
+{: .fs-6 .fw-300 }
+
+---
+
+Per chi scrive i moduli: come si scrivono i moduli in YAML, da dove vengono caricati, e le proprietà di ogni tipo di modulo.
+
+I moduli sono il cuore di AnsibleForms. Ogni modulo è un'interfaccia web che raccoglie l'input dell'utente e, con quei dati, esegue un
+playbook Ansible, un template di AWX, AAP o Ascender, un template di Semaphore, un job Rundeck o Jenkins, oppure un
+[workflow](../workflows/).
+
+I moduli sono definiti in file YAML nella cartella dei moduli. Ogni file YAML contiene un solo modulo o una lista di moduli, e si possono usare sottocartelle per organizzarli.
+
+**VIDEO**: [Crea il tuo primo modulo](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Capire la struttura di un modulo
+
+Ogni modulo di AnsibleForms si configura con un insieme di proprietà. **[Proprietà comuni](common.html)** elenca le proprietà valide per tutti i tipi di modulo; le pagine specifiche di ciascun tipo descrivono quelle aggiuntive.
+
+---
+
+## Come vengono caricati i moduli
+
+AnsibleForms carica i moduli dalle seguenti posizioni:
+
+1. **DAI REPOSITORY** : tutti i repository con l'interruttore "Usare per moduli?" attivo (sono supportati più repository)
+   - I moduli di tutti i repository abilitati vengono uniti automaticamente.
+   - In ogni repository si cerca prima una sottocartella `forms/`.
+   - Se la sottocartella `forms/` non esiste, si usa la radice del repository.
+   - I moduli creati nel designer e non ancora inviati con push restano in una cartella di staging
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) e vengono caricati insieme a loro.
+
+2. **DALLA CARTELLA LOCALE** : la cartella locale `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), quando nessun repository ha "Usare per moduli?" attivo
+
+{: .warning }
+> **Nota:** quando "Usare per moduli?" è attivo su più repository, tutti i loro moduli vengono uniti. I nomi dei moduli devono essere univoci tra i repository per evitare conflitti.
+
+---
+
+## Dove gira un modulo
+
+Il tipo di un modulo decide il tipo di [runner](../runners.html) su cui gira il suo job: un RTE per `ansible`, un runner AWX per `awx`,
+`aap` e `ascender`, e un runner del tipo corrispondente per `semaphore`, `rundeck` e `jenkins`.
+
+- `runner: <name>` sul modulo sceglie per nome un runner di quel tipo; senza, il job gira sul runner predefinito del tipo.
+- Un runner disattivato in **Connessioni > Runner** fa fallire il job, che il modulo lo nomini o che sia quello predefinito. Il job
+  non ripiega mai su un altro runner.
+- Quando uno dei ruoli dell'utente elenca `runners` in `config.yaml`, il job può girare solo su un runner elencato da un ruolo del genere, altrimenti viene
+  rifiutato. I ruoli senza l'elenco non lo limitano, e un amministratore non è mai limitato.
+
+---
+
+## In questa sezione
+
+Le pagine seguenti descrivono in dettaglio le proprietà dei moduli:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Proprietà comuni](common.html) | Proprietà valide per tutti i tipi di modulo (`name`, `description`, `help`, `type`, `fields`) |
+| [Moduli Ansible](ansible.html) | Proprietà specifiche di `type: ansible` |
+| [Moduli AWX](awx.html) | Proprietà specifiche di `type: awx` |
+| [Moduli Semaphore](semaphore.html) | Proprietà specifiche di `type: semaphore`, che esegue un template di Semaphore |
+| [Moduli Rundeck](rundeck.html) | Proprietà specifiche di `type: rundeck`, che esegue un job Rundeck |
+| [Moduli Jenkins](jenkins.html) | Proprietà specifiche di `type: jenkins`, che esegue la build di un job Jenkins |
+| [Moduli multistep](multistep.html) | Proprietà specifiche di `type: multistep`, deprecato a favore di `workflow` |
+| [Moduli workflow](workflow.html) | Proprietà specifiche di `type: workflow`, che esegue un [workflow](../workflows/) |
+| [Wizard](wizard.html) | Suddividere l'input di un modulo su più pagine (funziona sopra qualsiasi tipo di modulo eseguibile) |
+| [Sottomodulo](subform.html) | I sottomoduli usano solo le proprietà comuni |
+| [Punti di approvazione](approval.html) | Mettere in pausa un job finché non viene approvato (`approval`) |
+| [Notifiche](notifications.html) | Inviare email e messaggi sui canali in base allo stato o agli eventi del job (`notifications`) |
+| [Azioni sullo stato del job](job-status-action.html) | Agire sul modulo quando un job cambia stato (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/it/_build_forms/forms/jenkins.md b/i18n/it/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..56984b1
--- /dev/null
+++ b/i18n/it/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Moduli Jenkins
+parent: Moduli
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Moduli Jenkins
+{: .no_toc }
+
+Moduli che eseguono la build di un job Jenkins
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: jenkins`, in aggiunta alle [proprietà comuni dei moduli](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/job-status-action.md b/i18n/it/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..ae98516
--- /dev/null
+++ b/i18n/it/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Azioni sullo stato del job
+parent: Moduli
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Azioni sullo stato del job
+{: .no_toc }
+
+Agire sul modulo quando il suo job viene inviato, riesce, fallisce o termina
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Sono disponibili i seguenti hook:
+
+- `onSubmit`: scatta quando il modulo viene inviato
+- `onSuccess`: scatta quando il job termina con successo
+- `onFailure`: scatta quando il job fallisce
+- `onFinish`: scatta quando il job termina, qualunque sia il suo stato
+- `onAbort`: scatta quando il job viene interrotto
+
+---
+
+## Attributi
+
+Gli attributi di un'azione sullo stato del job:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di azioni sullo stato del job, in YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/multistep.md b/i18n/it/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..d5a73f4
--- /dev/null
+++ b/i18n/it/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Moduli multistep
+parent: Moduli
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Moduli multistep
+{: .no_toc }
+
+Eseguire più playbook o template in sequenza da un solo modulo
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` è deprecato dalla 7 e rimosso nella 8: usa invece un [workflow](workflow.html). Un workflow fa tutto ciò che fa
+> un multistep, con condizioni, valori propri per ogni nodo, nodi di approvazione e rami che girano in parallelo.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà a livello di modulo
+
+Un modulo multistep definisce i suoi passi in una sola proprietà a livello di modulo:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / obbligatorio</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Oltre a `steps`, un modulo multistep accetta queste proprietà a livello di modulo, documentate nella pagina [Moduli Ansible](ansible.html):
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (obbligatoria){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Proprietà dei passi
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Disponibile solo con i tipi:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Aggiunto</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Esempi
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Esempio
+
+Un modulo multistep esegue più job in sequenza, e ogni passo avvia il proprio playbook o template AWX. Tutti i passi condividono i campi del modulo: per impostazione predefinita ogni passo riceve tutte le extravars, e la `key` di un passo lo limita a quella parte.
+
+### Creare e configurare un server
+
+Ogni passo riceve la propria parte delle extravars: un passo AWX crea il server, un passo Ansible ne configura la rete, e un passo finale invia sempre un report:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/it/_build_forms/forms/notifications.md b/i18n/it/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..9b363c8
--- /dev/null
+++ b/i18n/it/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Notifiche
+parent: Moduli
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Notifiche
+{: .no_toc }
+
+Inviare un'email o un messaggio su un canale quando un job termina o gli succede qualcosa
+{: .fs-6 .fw-300 }
+
+---
+
+Le `notifications` di un modulo indicano chi viene informato dei suoi job, e quando:
+
+- **Chi**: `recipients`, indirizzi email, e `channels`, i nomi dei
+  [canali di notifica](../notification-channels.html) (mail, Slack, Microsoft Teams, Telegram, un webhook). È obbligatorio
+  almeno uno dei due.
+- **Quando**: `onStatus`, quando un job termina (`success`, `failed`, `aborted`, `warning` o `any`), e `onEvent`, quando
+  succede qualcosa a un job (`launch`, `relaunch`, `delete`, `approve`, `reject` o `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Attributi
+
+Gli attributi dell'oggetto `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Esempi
+
+Esempi di notifiche, in YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}La definizione, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/rundeck.md b/i18n/it/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..86d1458
--- /dev/null
+++ b/i18n/it/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Moduli Rundeck
+parent: Moduli
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Moduli Rundeck
+{: .no_toc }
+
+Moduli che eseguono un job Rundeck
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: rundeck`, in aggiunta alle [proprietà comuni dei moduli](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/semaphore.md b/i18n/it/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..e971d9c
--- /dev/null
+++ b/i18n/it/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Moduli Semaphore
+parent: Moduli
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Moduli Semaphore
+{: .no_toc }
+
+Moduli che eseguono un template di Semaphore UI
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: semaphore`, in aggiunta alle [proprietà comuni dei moduli](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/forms/subform.md b/i18n/it/_build_forms/forms/subform.md
new file mode 100644
index 0000000..ffb2f9c
--- /dev/null
+++ b/i18n/it/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Sottomodulo
+parent: Moduli
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Sottomodulo
+{: .no_toc }
+
+Un frammento di modulo riutilizzabile per campi list, campi yaml e pagine di wizard
+{: .fs-6 .fw-300 }
+
+---
+
+Un sottomodulo è un frammento di modulo riutilizzabile. Non compare nella vista a riquadri e non può essere inviato direttamente. Viene invece richiamato da:
+
+- Un campo [`list`](../formfields/list.html): apre il sottomodulo come editor di drilldown per ogni riga
+- Un campo [`yaml`](../formfields/yaml.html) con la proprietà `subform`: apre il sottomodulo come editor di drilldown per un singolo oggetto
+- Un passo di [`wizard`](wizard.html): mostra il sottomodulo come una pagina del wizard
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+I sottomoduli **non hanno proprietà specifiche del tipo**. Usano solo le [proprietà comuni dei moduli](common.html): `name`, `description`, `help`, `type` e `fields`.
+
+Quando un sottomodulo fa da pagina di un wizard, `description` e `help` forniscono i valori predefiniti per `title` e `help` del passo. Può anche impostare `showHelp` per espandere quell'aiuto al caricamento della pagina.
+
+Le proprietà di esecuzione (`playbook`, `template`, `roles`, `inventory`, ecc.) non si applicano ai sottomoduli, perché un sottomodulo non viene mai inviato direttamente.
+
diff --git a/i18n/it/_build_forms/forms/wizard.md b/i18n/it/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..34b3134
--- /dev/null
+++ b/i18n/it/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Wizard
+parent: Moduli
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Wizard
+{: .no_toc }
+
+Suddividere l'input di un modulo su più pagine con Indietro e Avanti
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Che cos'è un wizard?
+
+Un **wizard** trasforma un singolo modulo in una sequenza di pagine. Ogni pagina viene generata da un [`subform`](subform.html) e l'utente si sposta con i pulsanti **Indietro** e **Avanti**. La convalida avviene pagina per pagina: l'utente non può andare avanti finché il passo corrente non è valido, a meno che il passo non sia contrassegnato come `optional`.
+
+Alla fine di ogni wizard viene aggiunta automaticamente una **pagina di riepilogo** in sola lettura. Elenca ogni passo con i valori raccolti, così l'utente può confermarli prima dell'invio. La pagina di riepilogo **non** si dichiara in YAML; il suo titolo viene preso dalla lingua attiva.
+
+All'invio, i **valori raccolti in tutti i passi vengono uniti in un unico payload di extravars** e inviati al playbook, template o workflow sottostante, esattamente come se l'utente avesse compilato un unico grande modulo.
+
+Un modulo con un `wizard` non ha bisogno di `fields` propri, ma non può impostare `enableForChat`, e un `subform` non può avere a sua volta un `wizard`. La [validazione all'avvio](../launch-validation/rolling-it-out.html#wizard-forms) controlla l'avvio di un wizard passo per passo.
+
+{: .note }
+> Per capire in cosa un `wizard` si differenzia da un workflow, e come si combinano, vedi la voce delle FAQ [Qual è la differenza tra un wizard e un workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Proprietà a livello di modulo
+
+Un wizard si attiva con una sola proprietà a livello di modulo:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">added in version {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Esempi:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà dei passi del wizard
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / univoco</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Aggiunto</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Esempi
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Combinare un wizard con un workflow
+
+Un wizard si può sovrapporre a un modulo [workflow](workflow.html). Quando il `defaultModel` di ogni passo del wizard corrisponde alla [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) del nodo di workflow corrispondente, ogni playbook o template riceve solo i valori della propria pagina del wizard.
+
+Le FAQ contengono un esempio completo e la struttura delle extravars unite: [Qual è la differenza tra un wizard e un workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (sezione *Combinati (wizard sopra un workflow)*).
+
+Un wizard su un modulo [`multistep`](multistep.html), deprecato, funziona allo stesso modo, con la [`key`](multistep.html#step_key) del passo al posto di `extra_vars_key`.
+
+---
+
+## Vedi anche
+
+Pagine correlate e voci delle FAQ:
+
+- [Sottomodulo](subform.html): le pagine del wizard vengono generate dai sottomoduli
+- [Moduli workflow](workflow.html): l'equivalente del wizard a livello di esecuzione
+- [`__parent__` nei sottomoduli](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): come fare riferimento ai passi precedenti del wizard da un passo successivo
diff --git a/i18n/it/_build_forms/forms/workflow.md b/i18n/it/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..48fedc0
--- /dev/null
+++ b/i18n/it/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Moduli workflow
+parent: Moduli
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Moduli workflow
+{: .no_toc }
+
+Moduli che eseguono uno dei workflow del designer
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Proprietà
+
+Proprietà specifiche di `type: workflow`, in aggiunta alle [proprietà comuni dei moduli](common.html). La sezione
+[Workflow](../workflows/) descrive i file di workflow veri e propri.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attributo</th>
+      <th>Commenti</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obbligatorio</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">aggiunto nella versione {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Scelte:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinito)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinito:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Esempi:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/it/_build_forms/launch-validation/file-uploads.md b/i18n/it/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..2b288e4
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Caricamento di file
+parent: Validazione all'avvio
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Caricamento di file
+{: .no_toc }
+
+Come vengono validati i campi file
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un campo file non si fida mai di ciò che la richiesta di avvio dice su un file. La validazione all'avvio controlla il file stesso, sul
+disco del server.
+
+---
+
+## Come un file caricato arriva a un job
+
+Un file viene caricato prima che il modulo venga avviato, in due passi:
+
+1. Il browser carica il file con `POST /api/v2/job/upload`. Il server lo salva in `UPLOAD_PATH`.
+2. La richiesta di avvio descrive quel caricamento nella sua parte `files`.
+
+La validazione all'avvio confronta poi la descrizione con il disco:
+
+* Il file deve esistere dentro `UPLOAD_PATH`.
+* Percorso e dimensione vengono letti dal disco, mai dalla richiesta.
+
+---
+
+## Cosa viene accettato
+
+Un campo file riceve un valore solo da un caricamento verificato. Tutto il resto viene scartato:
+
+* Un percorso che il chiamante scrive in `rawFormData` o `extravars` viene ignorato.
+* Un campo file obbligatorio senza un caricamento reale viene segnalato come `missing`.
+
+---
+
+## Regole dei file
+
+Le regole di un campo file vengono controllate sul caricamento reale, con le dimensioni in byte:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` e `maxSize` confrontano la dimensione reale del file, e `regex` il suo nome. Indipendentemente da qualsiasi modulo,
+`UPLOAD_MAX_GB` limita la dimensione di un singolo caricamento (10 GB per impostazione predefinita).
diff --git a/i18n/it/_build_forms/launch-validation/index.md b/i18n/it/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..8127416
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Validazione all'avvio
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Validazione all'avvio
+{: .no_toc }
+
+Controllare sul server ogni avvio di un modulo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per amministratori e autori di moduli: fai controllare al server ogni avvio, le sue regole e le sue extravars, chiunque lo invii.
+
+Il controllo vale indipendentemente da chi o cosa avvia il modulo: il browser, uno script che chiama la REST API,
+o un agente IA attraverso il server MCP.
+
+---
+
+## Perché esiste
+
+Le regole di un modulo (`required`, `regex`, `minValue`, `sameAs`, ...) sono sempre state controllate
+nel browser. Il browser poi invia due cose a `POST /api/v2/job`:
+
+- `rawFormData`: i valori dei campi così come li ha compilati l'utente;
+- `extravars`: ciò che riceve il playbook, costruito nel browser a partire da quei valori.
+
+Senza la validazione all'avvio, il server si fida di entrambi. Chiunque abbia un token valido può chiamare quell'endpoint
+direttamente e inviare qualsiasi extravars, senza che venga applicata alcuna regex, campo obbligatorio o regola
+di lista. Per un modulo usato solo nel browser può essere accettabile; per un
+modulo che altri sistemi avviano via REST, significa che le regole del modulo non vengono applicate affatto.
+
+Inoltre il server non ha modo di distinguere una richiesta del browser da una inviata da uno
+script: entrambe usano lo stesso endpoint, lo stesso token e lo stesso body, e gli utenti possono modificare
+qualsiasi richiesta inviata dal proprio browser. Ci si può fidare di un controllo solo se avviene sul server, e la
+validazione all'avvio è proprio quel controllo.
+
+---
+
+## Le tre vie d'ingresso
+
+Il modo in cui un avvio viene validato dipende da come arriva e dalla modalità di validazione all'avvio:
+
+| Avviato da | Validato | Extravars con cui gira il job |
+|---|---|---|
+| **Server MCP** (agente IA) | sempre, sul server | sempre costruite dal server |
+| **Browser** o **REST API**, validazione all'avvio `off` | solo nel browser | quelle inviate dal browser (o dal chiamante) |
+| **Browser** o **REST API**, validazione all'avvio `log` | sul server, i rifiuti vengono solo registrati nel log | quelle inviate; le differenze vengono registrate nel log |
+| **Browser** o **REST API**, validazione all'avvio `enforce` | sul server, rifiutato se non valido | **costruite dal server** |
+
+Il browser, il server MCP e la validazione all'avvio usano lo stesso codice per le regole (il
+motore dei moduli condiviso): le stesse regole, nello stesso ordine, con gli stessi messaggi. Un errore che il
+browser mostra viene rifiutato dal server con lo stesso testo.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina dedicata:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Attivarla](switching-it-on.html) | Per l'intera istanza, o per un solo modulo |
+| [Log ed enforce](log-and-enforce.html) | Cosa fa ogni modalità con un avvio che viola le regole |
+| [Righe delle liste](list-rows-and-subforms.html) | Come vengono validate le righe dei campi list |
+| [Caricamento di file](file-uploads.html) | Come vengono validati i campi file |
+| [Password](passwords.html) | Come vengono validati i campi password e tenuti fuori dalle API |
+| [Rilancio](relaunching.html) | Come viene validato un job rilanciato |
+| [Messa in produzione](rolling-it-out.html) | Portare un'istanza in enforce, e le limitazioni note |
diff --git a/i18n/it/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/it/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..0c5817e
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Righe delle liste
+parent: Validazione all'avvio
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Righe delle liste
+{: .no_toc }
+
+Come vengono validate le righe dei campi list
+{: .fs-6 .fw-300 }
+
+---
+
+Un campo `list` contiene righe; ogni riga è un'istanza del suo sottomodulo, compilata tramite l'editor
+di riga. Un campo `yaml` con un `subform` è una riga di questo tipo. Il server le tratta nello stesso modo
+dell'editor di riga del browser: ogni riga viene risolta tramite il suo sottomodulo, con i valori del modulo
+come `__parent__`, le sue regole controllate e i suoi campi calcolati valutati. Le liste annidate funzionano
+allo stesso modo: nella lista di una riga, `$(__parent__.__parent__.x)` raggiunge il modulo.
+
+Le righe vengono controllate così:
+
+- **Una riga che l'utente ha aggiunto o modificato** nell'editor viene risolta e validata.
+- **Una riga che nessuno ha toccato**, prodotta dal default, dall'espressione o dalla query della lista stessa
+  (come le voci esistenti di una lista di ACL), passa **esattamente com'è arrivata**, come nel
+  browser: non viene rivalidata e non le viene aggiunto nulla. Una voce esistente che viola una regola
+  scritta in seguito non blocca l'avvio.
+- **Una riga marcata come eliminata** (il `deleteMarker` della lista) viene mantenuta così com'è e non viene validata.
+
+Per distinguere queste righe senza fidarsi della richiesta, il server esegue di nuovo la sorgente
+della lista (il suo default, altrimenti la sua espressione o query) durante la validazione all'avvio. Una riga
+che non è passata dall'editor passa invariata **solo se è una delle righe prodotte da quella
+sorgente**. Qualsiasi altra riga, come una inventata da un chiamante REST, viene risolta e
+validata come una riga modificata. Una riga qualsiasi quindi non può aggirare i controlli, mentre
+le righe non toccate del browser continuano a passare invariate.
+
+Un utente del browser se ne accorge in un solo caso: i dati della sorgente sono cambiati tra l'apertura del
+modulo e il suo avvio (nel frattempo una voce è stata modificata o rimossa), **e** quella riga
+viola una regola del suo sottomodulo. A quel punto la riga non conta più come una delle righe della sorgente, quindi
+viene validata, e l'avvio viene rifiutato indicando la riga, per esempio
+`acls[2].user_or_group (regex)`.
+
+Le righe che falliscono compaiono in `rowErrors` con il loro `index` (un campo `yaml` non ne ha) e nel log come
+`disks[1].size (maxValue)`.
+
+Un avvio può contenere al massimo **500 righe** su tutti i livelli di annidamento, perché ogni riga esegue le query del suo sottomodulo.
+
+---
+
+## Marker delle righe
+
+I marker che una lista imposta sulle sue righe (`insertMarker`, `updateMarker` e `deleteMarker`; senza
+`insertMarker`, le nuove righe ricevono `__inserted__` quando la lista imposta `allowDelete: false`, un `deleteMarker` o un `updateMarker`)
+arrivano al playbook su ogni riga che ne porta uno. Una riga rimossa viene inviata con il suo marker di
+eliminazione, così il playbook può rimuoverla. Prima della 6.4.1 una riga di lista portava un marker solo quando il suo
+sottomodulo lo dichiarava come campo (nascosto).
diff --git a/i18n/it/_build_forms/launch-validation/log-and-enforce.md b/i18n/it/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..7404279
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Log ed enforce
+parent: Validazione all'avvio
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Log ed enforce
+{: .no_toc }
+
+Cosa fa ogni modalità con un avvio che viola le regole
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Cosa fa `log`
+
+Ogni avvio viene controllato, ma per l'utente non cambia nulla. Nel log viene scritto un avviso quando:
+
+- l'avvio **verrebbe rifiutato**, con il motivo (solo nomi dei campi e tipi di regola, mai
+  valori):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- le extravars inviate dal client **differiscono** da quelle costruite dal server, con le
+  chiavi di primo livello che differiscono:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Prima tieni `log` attivo per un po' su un'istanza reale. Mostra quali moduli verrebbero rifiutati e
+quali calcolano valori diversi sul server, prima che qualcuno ne subisca le conseguenze.
+
+---
+
+## Cosa fa `enforce`
+
+Con `enforce`, un avvio non valido viene rifiutato, e uno valido gira con le extravars costruite
+dal server.
+
+### Un avvio che viola le regole viene rifiutato
+
+`POST /api/v2/job` risponde `422` con i campi che falliscono:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing`: campi obbligatori senza valore;
+- `invalid`: campi che violano una regola, scelte che non sono tra le opzioni, e campi list
+  con una riga che fallisce;
+- `waiting`: campi che non è stato possibile valutare (un campo di cui hanno bisogno non ha mai ricevuto un valore);
+- `validationErrors`: per ogni campo, ogni regola che fallisce con il messaggio mostrato dal browser;
+- `rowErrors`: per ogni campo list, le righe che falliscono (vedi [Righe delle liste](list-rows-and-subforms.html));
+- `uploads`: campi file il cui caricamento non è stato possibile verificare.
+
+Viene rifiutato anche un avvio **senza `rawFormData`**: i suoi valori non si possono controllare.
+
+### Un avvio valido gira con le extravars del server
+
+Il job non gira con le extravars inviate dal client. Il server le costruisce dai valori
+controllati, usando lo stesso codice del browser, ed esegue quelle. Un chiamante che invia `rawFormData`
+validi insieme a `extravars` diverse riceve le extravars che corrispondono ai valori, non
+quelle che ha inviato.
+
+Della richiesta, il server mantiene `__verbose__` (solo per gli utenti autorizzati alla modalità verbose). Le
+chiavi riservate (`__playbook__`, `__inventory__`, ...) vengono dal modulo, come sempre, e
+`ansibleforms_user` è l'utente che avvia.
+
+### Ciò che l'utente ha visto non è sempre ciò che gira
+
+Costruire le extravars significa valutare di nuovo il modulo: ogni espressione e query gira
+un'altra volta sul server, un momento dopo che il browser l'ha eseguita, come l'utente che avvia. Un valore
+che dipende da **quando** o **dove** viene valutato può differire, e in quel caso si usa
+il valore del server:
+
+| Cosa | Perché può differire | Quanto |
+|---|---|---|
+| `fn.fnTime()`, un timestamp, un nome costruito dall'ora | valutato di nuovo, qualche secondo dopo | conta solo a cavallo di un secondo o di una data. `fnTime` gira già sul server anche nel flusso del browser, con lo stesso fuso orario (il `TZ` del container) |
+| una query, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, la lettura di un file | i dati esterni sono cambiati nel frattempo | solo quando sono cambiati |
+| un'espressione `runLocal` che usa `new Date()`, `toLocaleString`, `Intl` | il browser usa fuso orario e impostazioni locali dell'utente, il server i propri | solo espressioni di questo tipo |
+
+Lo stesso vale per la **validazione**: una regola che legge un campo del genere (`notIn` sul risultato di una
+query, `validIf` su un flag calcolato) viene controllata sul valore del server. I moduli le cui
+extravars differiscono compaiono negli avvisi di `log` descritti sopra; esaminali prima di passare a enforce.
diff --git a/i18n/it/_build_forms/launch-validation/passwords.md b/i18n/it/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..022ddb8
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Password
+parent: Validazione all'avvio
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Password
+{: .no_toc }
+
+Come vengono validati, salvati e tenuti fuori dalle API i campi password
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un campo password viene validato come qualsiasi altro campo. Il suo valore, però, resta sul server e non viene mai restituito
+a un client.
+
+---
+
+## Dove viene conservata una password
+
+Il server salva la password con il job, nelle sue extravars:
+
+* Un'**approvazione** può così proseguire il job con la password inserita dall'utente.
+* Un **rilancio così com'era stato eseguito** può riutilizzarla, quando la validazione all'avvio non è `enforce`.
+
+La password salvata viene usata solo sul server.
+
+---
+
+## Cosa restituiscono le API
+
+Nessuna API restituisce mai una password:
+
+* Un job letto tramite la REST API o il `get_job` del server MCP maschera ogni campo `password` del suo modulo, anche dentro
+  le righe delle liste e i sottomoduli YAML.
+* `MASK_EXTRAVARS_REGEX` (predefinito `password|secret|token`) maschera anche ogni extravar il cui nome corrisponde, per
+  i segreti che non sono campi password.
+
+---
+
+## Cosa riceve un rilancio
+
+Per precompilare un rilancio, il browser riceve i dati grezzi del modulo del job. Quei dati non contengono mai una password, nemmeno dentro
+le righe delle liste o i sottomoduli YAML, quindi l'utente inserisce di nuovo la password.
+
+Un campo password nascosto dalle dipendenze del modulo non serve, e non va inserito di nuovo.
diff --git a/i18n/it/_build_forms/launch-validation/relaunching.md b/i18n/it/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..2a3cd94
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Rilancio
+parent: Validazione all'avvio
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Rilancio
+{: .no_toc }
+
+Come viene validato un job rilanciato
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un job si può rilanciare in due modi. Il modo in cui il rilancio viene controllato dipende da quale dei due, e dalla modalità di
+validazione all'avvio.
+
+---
+
+## Due tipi di rilancio
+
+I due tipi differiscono per il fatto che il chiamante invii o meno nuovi valori:
+
+* **Così com'era stato eseguito**: il pulsante Rilancia, `POST /api/v2/job/{id}/relaunch` senza body, oppure `relaunch_job` senza
+  `values`.
+* **Con modifiche**: le stesse chiamate con nuovi valori, sovrapposti ai valori dei campi salvati del job:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Come viene controllato ciascuno
+
+La modalità di validazione all'avvio decide se un rilancio viene riprodotto o controllato di nuovo:
+
+| Rilancio | `off` / `log` | `enforce` |
+|---|---|---|
+| **Così com'era stato eseguito** | riproduce le extravars salvate del job, password comprese | il controllo completo, dai valori dei campi salvati |
+| **Con modifiche** | il controllo completo, sui valori salvati con le modifiche sovrapposte | il controllo completo, allo stesso modo |
+
+Un'eccezione con `enforce`: un job avviato da una pianificazione di livello admin non ha valori di campo propri, quindi rilanciarlo così com'era
+riproduce le extravars salvate della pianificazione, per un amministratore o per un utente con l'opzione di ruolo `allowScheduledJobs`.
+
+Un rilancio controllato (vedi [Log ed enforce](log-and-enforce.html)) avvia un nuovo job a nome del chiamante.
+
+---
+
+## Campi password
+
+I valori dei campi salvati non contengono password, quindi un rilancio controllato non ne ha per un **campo password visibile**:
+
+* Il rilancio viene rifiutato come `unsupported`, con i `passwordFields` che mancano.
+* Avvia di nuovo il modulo e inserisci la password.
+* Un campo password che le dipendenze del modulo **nascondono** non serve e non blocca il rilancio.
+
+Con `enforce`, questo vale anche per il pulsante Rilancia.
+
+---
+
+## Chi può rilanciare
+
+Entrambi i tipi di rilancio richiedono:
+
+* che il modulo consenta il rilancio (`allowRelaunch`, true per impostazione predefinita);
+* l'opzione di ruolo `allowJobRelaunch`;
+* che l'utente sia **il proprietario del job**, un amministratore, o un utente con l'opzione di ruolo `manageAllJobs`.
+
+Vedere tutti i job (`showAllJobLogs`) non basta per rilanciare il job di un altro utente. Gli approvatori possono vedere un job che attende la loro
+approvazione, ma neanche loro possono rilanciarlo.
diff --git a/i18n/it/_build_forms/launch-validation/rolling-it-out.md b/i18n/it/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..d60a136
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Messa in produzione
+parent: Validazione all'avvio
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Messa in produzione
+{: .no_toc }
+
+Portare un'istanza in enforce, e le limitazioni note
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Messa in produzione
+
+`enforce` è il valore predefinito. Su un'istanza con script o altri sistemi che avviano moduli via
+REST, arrivaci per gradi, osservando il log prima di rifiutare qualcosa:
+
+1. Imposta `LAUNCH_VALIDATION=log` per l'intera istanza (prima di aggiornare, in caso di aggiornamento).
+2. Lavora in questa modalità per un po' ed esamina il log: gli avvisi `would refuse` indicano avvii
+   che violano le regole; gli avvisi `extravars differ` indicano moduli che calcolano qualcosa
+   in modo diverso sul server (un timestamp, dati esterni). Decidi per ogni modulo se la cosa
+   conta.
+3. Passa quei moduli a `launchValidation: enforce`. I chiamanti che inviavano valori non validi o
+   extravars inventate ora ricevono un `422` con il motivo.
+4. Quando ogni modulo si comporta come previsto, rimuovi `LAUNCH_VALIDATION` (o impostalo a `enforce`) per l'intera istanza.
+
+---
+
+## Limitazioni
+
+La validazione all'avvio non copre ancora tutto:
+
+- I **moduli wizard** non si possono rilanciare con modifiche, e un job wizard avviato prima della 7.0
+  non si può rilanciare con `enforce` (non salvava i valori dei suoi passi). Il server MCP
+  non può avviare moduli wizard.
+- La **risoluzione dei segnaposto** nel browser usa ancora una propria copia del codice del server; in
+  rari casi limite (`__undefined__`, apici dentro le espressioni) i due potrebbero risolvere un
+  segnaposto in modo diverso. `log` rivela queste differenze.
+- Le espressioni **`runLocal`** girano nel motore JavaScript del browser nel browser e in una
+  sandbox sul server; lo stesso codice produce lo stesso risultato, tranne quando dipende dal
+  fuso orario o dalle impostazioni locali del browser.
+
+---
+
+## Moduli wizard
+
+Un [wizard](../forms/wizard.html) viene controllato passo per passo: il browser invia i valori di
+ogni passo, e il server controlla ogni passo che l'utente invierebbe rispetto al suo sottomodulo.
+
+- Un passo viene escluso quando è `optional` e l'utente l'ha saltato, oppure quando il suo `when` è falso.
+- Un passo legge i passi precedenti tramite `$(__parent__.<step>.<field>)`, con i loro valori controllati.
+- Gli errori indicano il passo e il campo, come `<step>.<field>`.
+- Con `enforce`, le extravars vengono costruite sul server, ogni passo sotto il suo `defaultModel`.
+- I campi file non sono supportati in un wizard.
diff --git a/i18n/it/_build_forms/launch-validation/switching-it-on.md b/i18n/it/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..ff17512
--- /dev/null
+++ b/i18n/it/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Attivarla
+parent: Validazione all'avvio
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Attivarla
+{: .no_toc }
+
+Per l'intera istanza, o per un solo modulo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La validazione all'avvio ha due impostazioni. **Vale la più severa delle due.**
+
+---
+
+## Per l'intera istanza: `LAUNCH_VALIDATION`
+
+La variabile d'ambiente [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) vale per ogni modulo:
+
+- `off`: nessun controllo lato server; il job gira con le extravars inviate dal browser o dal chiamante.
+- `log`: ogni avvio viene controllato; ciò che verrebbe rifiutato viene scritto nel log come
+  avviso, e l'avvio gira comunque come prima.
+- `enforce` (predefinito): un avvio non valido viene rifiutato, e uno valido gira con le extravars costruite
+  dal server.
+
+Anche un valore vuoto o sconosciuto equivale a `enforce`. Le modifiche hanno effetto senza riavvio.
+
+{: .warning }
+> **L'aggiornamento cambia il comportamento.** Un'istanza che non imposta `LAUNCH_VALIDATION` applica enforce
+> a ogni avvio dopo l'aggiornamento. Gli script che chiamano `POST /api/v2/job` senza `rawFormData`,
+> o con valori che violano le regole di un modulo, vengono rifiutati con un `422`. Imposta
+> `LAUNCH_VALIDATION=log` prima di aggiornare per vedere cosa verrebbe rifiutato, oppure `off` per mantenere il
+> vecchio comportamento (vedi [Messa in produzione](rolling-it-out.html)).
+
+---
+
+## Per un solo modulo: `launchValidation`
+
+Un modulo può impostare il proprio livello:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Usa questa impostazione su un'istanza che gira in `off` o `log`, per un modulo che sai che verrà
+avviato via REST: quel modulo è in enforce, mentre il resto dell'istanza no. Si può impostare anche nel designer, nelle
+impostazioni del modulo.
+
+**Un modulo può essere reso più severo dell'istanza, mai più permissivo.** Con `LAUNCH_VALIDATION`
+su `enforce`, il `launchValidation: off` di un modulo non ha effetto: un modulo non può scavalcare
+la decisione di un operatore.
+
+La usano anche i moduli wizard: l'avvio di un wizard viene controllato passo per passo, ogni passo rispetto al proprio
+sottomodulo (vedi [Moduli wizard](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/it/_build_forms/workflows/designer.md b/i18n/it/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..5d4cb84
--- /dev/null
+++ b/i18n/it/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Modifica nel designer
+parent: Workflow
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Modifica nel designer
+{: .no_toc }
+
+Disegnare un workflow, e provarlo senza eseguire nulla
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La sezione Workflow
+
+**Designer > Workflow** elenca i file di workflow in un esploratore dei file, con le schede YAML, Visuale e Anteprima di ogni
+sezione del [designer](../designer/).
+
+- **Il pulsante `+`** nella barra degli strumenti crea un file di workflow, con un workflow vuoto da cui partire.
+- **YAML** mostra il file così com'è scritto. I commenti e l'ordine delle chiavi vengono mantenuti anche dalle altre schede.
+- **Visuale** disegna ogni workflow del file come un grafo, con il nome e la descrizione sopra. Un file con due workflow
+  li mostra entrambi, uno sotto l'altro.
+- **Anteprima** è una prova a vuoto del workflow: vedi [Provarlo](#trying-it-out).
+
+I problemi sono elencati sopra il grafo, ognuno con un link che apre lo YAML alla sua riga: un collegamento a un nodo che non
+esiste, un ciclo, un playbook, inventario, credenziale, runner o repository che il designer non conosce.
+
+---
+
+## Il grafo
+
+Il grafo si legge da sinistra a destra, da **START** agli ultimi nodi. Ogni nodo mostra il suo identificatore e, sotto, cosa
+esegue; i collegamenti sono colorati in base a ciò che li fa scattare, come dice la legenda dentro il grafo: in caso di successo, in caso di errore,
+sempre.
+
+- **Fai clic su START** per aggiungere un primo nodo: un nodo senza genitore, che gira appena parte il workflow.
+- **Fai clic su un nodo** per modificarlo.
+- **Fai clic su un collegamento** per cambiare ciò che lo fa scattare, o per rimuoverlo.
+
+---
+
+## Aggiungere un nodo
+
+Un nuovo nodo si aggiunge con un wizard: **Nuovo nodo in caso di successo**, **Nuovo nodo in caso di errore** o **Nuovo nodo sempre** su un nodo
+esistente, oppure START per il primo.
+
+1. **Cosa esegue**: l'identificatore del nodo, **Esegue** (che tipo di nodo è e, per un nodo playbook, dove gira)
+   e cosa esegue: un playbook o un template o job, un workflow, il nome e il timeout di un'approvazione, o un repository. Vedi
+   [Dove gira un nodo](#where-a-node-runs).
+2. **Come viene eseguito**: le impostazioni di esecuzione: l'inventario, le credenziali, il limite, i tag, la verbosità,
+   la modalità check e diff, la condizione (**Gira quando**) e **Valori da** (vedi [il file di workflow](file.html#run-settings)).
+3. **Dove va**: il nodo dopo il quale gira, e in quale caso.
+
+**Crea** aggiunge il nodo allo YAML.
+
+---
+
+## Dove gira un nodo
+
+**Esegue** dice cosa esegue un nodo e dove, in un unico elenco: **Playbook sull'RTE**, **Template su AWX**, **Template su
+Semaphore**, **Job su Rundeck**, **Job su Jenkins**, poi **Workflow**, **Approvazione** e **Pull di repository**.
+
+| Esegue | Il campo sotto | Runner |
+|---|---|---|
+| **Playbook sull'RTE** | **Playbook**: un playbook del designer | **L'RTE predefinito**, oppure un runner RTE per nome |
+| **Template su AWX** (AAP e Ascender compresi) | **Template**: il nome del template, digitato | i runner AWX, ognuno con la sua variante |
+| **Template su Semaphore** | **Template**: il nome del template, digitato | i runner Semaphore |
+| **Job su Rundeck** o **Job su Jenkins** | **Job**: il nome del job, digitato | i runner Rundeck o Jenkins |
+
+- **Playbook sull'RTE** è sempre proposto; gli altri solo quando l'istanza ha un [runner](../runners.html) di quel tipo.
+- **Runner** elenca solo i runner di quel tipo, con quello predefinito contrassegnato e preselezionato (o il primo per nome).
+- Scegliere un altro posto azzera ciò che il nodo esegue, che va quindi scelto di nuovo.
+- Un nodo il cui runner non è noto al designer mostra **Template o job su** quel runner.
+
+Il file di workflow non cambia: un nodo del genere è un nodo `job_template` con un `runner:` (vedi
+[il file di workflow](file.html#run-settings)).
+
+---
+
+## Modificare un nodo
+
+Facendo clic su un nodo si apre la sua finestra di dialogo, con quattro schede:
+
+| Scheda | Cosa contiene |
+|---|---|
+| **Cosa esegue** | L'identificatore, **Esegue**, cosa esegue e, per un nodo playbook, il runner |
+| **Come viene eseguito** | Le impostazioni di esecuzione; le credenziali si scelgono da un elenco, ognuna aggiunta con `+` |
+| **Esegue dopo** | I collegamenti verso il nodo, e **Tutti i genitori devono convergere** |
+| **Esegue dopo di sé** | I collegamenti in uscita, con **Collega a un nodo esistente:** e **Collega a un nuovo nodo:** |
+
+**Mostra in YAML** apre lo YAML sul nodo, e **Rimuovi nodo** lo rimuove insieme ai suoi collegamenti. Ogni modifica viene scritta subito
+nello YAML; **Salva** salva il file.
+
+---
+
+## Provarlo
+
+La scheda **Anteprima** fa scorrere il workflow senza avviare nulla, secondo le regole di AWX.
+
+Ogni nodo parte come riuscito. Fai clic su un nodo per farlo fallire, e fai di nuovo clic per farlo riuscire; il grafo mostra allora
+quali nodi verrebbero eseguiti, quali no, e se il workflow fallirebbe. **Ripristina** fa riuscire di nuovo tutti i nodi.
diff --git a/i18n/it/_build_forms/workflows/file.md b/i18n/it/_build_forms/workflows/file.md
new file mode 100644
index 0000000..75fddd7
--- /dev/null
+++ b/i18n/it/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Il file di workflow
+parent: Workflow
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# Il file di workflow
+{: .no_toc }
+
+La sintassi dei workflow, i tipi di nodo e le impostazioni di esecuzione di ogni nodo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dove si trovano i file di workflow
+
+I file di workflow sono file YAML nella cartella locale dei workflow e in ogni repository usato per i workflow.
+
+- **La cartella locale** è [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), per impostazione predefinita `workflows` sotto la
+  cartella persistente.
+- **Un repository** con **Usare per i workflow?** attivo viene letto per intero, quindi i suoi file di workflow possono stare in qualsiasi cartella. Il
+  designer li salva di nuovo nel repository, e **Push** li invia al remoto.
+
+Viene letto ogni file YAML che contiene `workflow_job_templates`, fino a sei livelli di cartelle, e un file può contenere più
+workflow. Un modulo indica un workflow con il suo `name`, quindi mantieni i nomi univoci: quando due workflow hanno lo stesso nome, un job che
+lo esegue fallisce e chiede di rinominarne uno.
+
+---
+
+## La sintassi
+
+Un file di workflow si scrive con la sintassi di un'esportazione di AWX, con i nodi sotto `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+Viene letta anche la struttura della collection `awx.awx`: `workflow_nodes` direttamente sotto il workflow, e nomi scritti come
+semplici stringhe (`inventory: staging`) invece che come mappe (`inventory: {name: staging}`).
+
+### Il workflow
+
+Una voce di workflow ha alcune chiavi proprie, accanto ai suoi nodi:
+
+| Chiave | Cos'è |
+|---|---|
+| `name` | Il nome del workflow, quello indicato da `workflow:` in un modulo |
+| `description` | A cosa serve, mostrato nel designer |
+| `extra_vars` | Variabili che ogni nodo riceve; i valori del modulo prevalgono su di esse |
+| `related.workflow_nodes` | I nodi |
+
+### Un nodo
+
+Ogni nodo ha un identificatore, ciò che esegue e i suoi collegamenti:
+
+| Chiave | Cos'è |
+|---|---|
+| `identifier` | L'id del nodo: lettere, cifre, punti, trattini, due punti e trattini bassi, univoco nel workflow |
+| `unified_job_template.type` | Cosa esegue il nodo: vedi [tipi di nodo](#node-types) |
+| `unified_job_template.name` | Il playbook, workflow, approvazione o repository che esegue |
+| `related.success_nodes` | I nodi che girano quando questo riesce |
+| `related.failure_nodes` | I nodi che girano quando questo fallisce |
+| `related.always_nodes` | I nodi che girano quando questo è terminato, in ogni caso |
+| `all_parents_must_converge` | `true`: il nodo attende che scattino tutti i collegamenti verso di esso, non uno solo |
+
+I collegamenti devono andare in avanti: un workflow i cui collegamenti formano un ciclo non gira.
+
+---
+
+## Tipi di nodo
+
+Un nodo esegue una di quattro cose, con i nomi che usa AWX:
+
+| Tipo | Cosa esegue il nodo |
+|---|---|
+| `job_template` | Uno dei playbook del designer, come job a sé sull'RTE; oppure, con `runner:`, il template o job di quel runner |
+| `workflow_job_template` | Un altro workflow, come job di workflow figlio; i workflow si annidano fino a cinque livelli |
+| `workflow_approval_template` | Un'approvazione: il job di workflow attende finché qualcuno la approva o la rifiuta |
+| `project` | Un pull del repository indicato (l'aggiornamento di progetto di AWX) |
+
+Il `unified_job_template.timeout` di un nodo di approvazione è in secondi. Quando scade senza risposta, il nodo fallisce; `0` o nessun
+timeout attende una risposta per tutto il tempo necessario. Un'approvazione rifiutata fa fallire il nodo, e il workflow prosegue lungo i suoi
+collegamenti.
+
+---
+
+## Impostazioni di esecuzione
+
+Un nodo `job_template` accetta le impostazioni di un nodo AWX, sul nodo stesso:
+
+| Chiave | Cosa fa |
+|---|---|
+| `inventory` | L'inventario su cui gira il playbook, per nome, come `inventory:` in un modulo |
+| `related.credentials` | Le credenziali: ognuna arriva al playbook con il proprio nome, e la prima di tipo *SSH* è anche il login con cui si connette ansible. Una di tipo vault apre solo i vault |
+| `limit` | Gira solo su questi host (`--limit`) |
+| `job_tags` | Esegue solo i task con questi tag (`--tags`) |
+| `skip_tags` | Salta i task con questi tag (`--skip-tags`) |
+| `verbosity` | Da `0` a `5`: il numero di `-v` |
+| `diff_mode` | `true`: mostra le modifiche (`--diff`) |
+| `job_type` | `check`: una prova a vuoto (`--check`); `run` o niente: un'esecuzione reale |
+| `extra_data` | Variabili che riceve questo nodo, sotto le `extra_vars` del workflow e i valori del modulo |
+
+Il job del nodo riceve i valori del modulo come extra vars. I valori del modulo prevalgono sulle `extra_vars` del workflow, che prevalgono
+sull'`extra_data` del nodo, come fanno in AWX le risposte di un survey.
+
+---
+
+## Le chiavi proprie di AnsibleForms
+
+Tre chiavi di un nodo sono proprie di AnsibleForms, e AWX le ignora, così un workflow può fare ciò che fa un modulo multistep:
+
+| Chiave | Cosa fa |
+|---|---|
+| `runner` | Su un nodo `job_template`, esegue il template o job di quel runner invece di un playbook del designer: AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins. Un runner RTE esegue lì il playbook del nodo. Un workflow può mescolarli. |
+| `if_extra_var` | Il nodo gira solo quando questa extra var è `true`, come l'`ifExtraVar` di un passo multistep. Se non è soddisfatta, il nodo viene saltato, e ciò che lo segue gira come dopo un successo. Non su un nodo di approvazione, che gira sempre. |
+| `extra_vars_key` | Il nodo riceve solo questa chiave delle extra vars, con l'utente copiato dentro, come la `key` di un passo multistep |
+
+Su un runner di template, `unified_job_template.name` è il template o job da eseguire, e `limit`, `job_tags`, modalità check
+e modalità diff del nodo vengono passati come li passerebbe un modulo del tipo di quel runner. Una `verbosity` sopra `0` attiva il
+`verbose` del modulo, e `skip_tags` non viene passato. Solo un runner AWX (AWX, AAP o Ascender) riceve l'inventario del nodo, e le
+credenziali come sue credenziali AWX; Semaphore, Rundeck e Jenkins ricevono le credenziali come le `credentials` di un modulo.
diff --git a/i18n/it/_build_forms/workflows/index.md b/i18n/it/_build_forms/workflows/index.md
new file mode 100644
index 0000000..e91fd4f
--- /dev/null
+++ b/i18n/it/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflow
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflow
+{: .no_toc }
+
+Concatenare playbook, approvazioni e altri workflow, come fa AWX
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per chi scrive i moduli: che cos'è un workflow, come girano i suoi nodi, e dove approfondire.
+
+Un workflow è un grafo di nodi. Ogni nodo esegue qualcosa: uno dei playbook del designer, un altro workflow, un'approvazione,
+o un pull di repository. I collegamenti tra i nodi dicono cosa viene eseguito dopo, in caso di successo, in caso di errore o sempre. Un modulo di
+[tipo `workflow`](../forms/workflow.html) lo avvia, e la pagina dei job lo disegna in diretta mentre gira.
+
+I workflow seguono la sintassi e le regole di AWX, quindi un workflow esportato da AWX si legge allo stesso modo in AnsibleForms. Girano
+sull'RTE, senza AWX: un nodo playbook è un job a sé, con l'inventario, le credenziali, il limite e i tag del nodo.
+
+---
+
+## Come gira un workflow
+
+I nodi girano secondo le regole di AWX, e i rami che non dipendono l'uno dall'altro girano in parallelo.
+
+- **Un nodo senza genitore parte subito**, quando parte il workflow.
+- **Un collegamento scatta quando il suo nodo è terminato**: un collegamento *in caso di successo* dopo un successo, uno *in caso di errore* dopo un errore,
+  uno *sempre* dopo l'uno o l'altro. Un nodo annullato non fa scattare nessuno dei suoi collegamenti.
+- **Un nodo parte appena scatta uno dei collegamenti verso di esso.** Con **Tutti i genitori devono convergere** attivo, attende finché ogni collegamento
+  verso di esso è scattato.
+- **Un nodo che non può più partire viene contrassegnato come *non viene eseguito***, e lo stesso vale per i nodi che solo lui poteva far partire.
+- **Il workflow fallisce quando un nodo è fallito e nulla gestisce l'errore**: quel nodo non ha né un collegamento *in caso di errore* né uno *sempre*.
+  Un errore gestito da un collegamento non fa fallire il workflow.
+
+Un nodo con una condizione (`if_extra_var`) non soddisfatta viene saltato. Ciò che lo segue gira come dopo un successo. Un nodo
+di approvazione non accetta condizioni: attende sempre una risposta.
+
+---
+
+## Passare dati tra i nodi
+
+Ciò che il playbook di un nodo raccoglie con `set_stats` arriva ai nodi successivi come extra vars, nello stesso modo in cui AWX passa gli
+artifact di un job. Un nodo riceve i dati da ogni genitore il cui collegamento verso di esso è scattato, uniti nell'ordine in cui i genitori sono
+scritti, e passa avanti ciò che ha ricevuto più i dati del proprio job, con i propri che prevalgono su una chiave impostata da entrambi.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Un nodo successivo legge poi {% raw %}`{{ version }}` e `{{ build_id }}`{% endraw %} come qualsiasi altra extra var.
+
+Le extra vars di un nodo provengono da quattro fonti. Una di queste, `extra_data`, sono le variabili proprie del nodo: il nome che usa AWX,
+impostate sul nodo nel [file di workflow](file.html#run-settings). Quando due fonti impostano la stessa chiave, l'ordine di precedenza è
+quello di AWX, dalla più bassa:
+
+| Fonte | Prevale su |
+|---|---|
+| le variabili proprie del nodo (`extra_data`) | niente |
+| i dati passati con `set_stats` | l'`extra_data` del nodo |
+| le `extra_vars` del workflow | i dati passati |
+| i valori del modulo | tutto |
+
+- Vengono passati solo i dati a livello di playbook: `set_stats` con `per_host: false`, il suo valore predefinito.
+- Un nodo di approvazione, un nodo saltato e un nodo di progetto passano avanti ciò che hanno ricevuto.
+- L'output di un nodo termina con le chiavi che ha passato, solo per nome, perché i loro valori possono essere segreti.
+- Il job del nodo conserva i suoi dati come artefatti (**Mostra artefatti** nella sua pagina), e il job di workflow conserva i dati di tutti i suoi
+  nodi, così anche un workflow annidato li passa ai nodi successivi.
+- Un nodo che gira su un runner AWX passa avanti allo stesso modo gli artifact del suo job AWX.
+---
+
+## In questa sezione
+
+Le pagine seguenti descrivono i workflow in dettaglio:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Il file di workflow](file.html) | La sintassi del file, i tipi di nodo e le impostazioni di esecuzione di ogni nodo |
+| [Modifica nel designer](designer.html) | La sezione Workflow del designer: il grafo, le finestre di dialogo di nodi e collegamenti e la prova a vuoto |
+| [Eseguire un workflow](running.html) | Il modulo che lo avvia, la pagina del job, gli output dei nodi, le approvazioni e l'interruzione |
diff --git a/i18n/it/_build_forms/workflows/running.md b/i18n/it/_build_forms/workflows/running.md
new file mode 100644
index 0000000..018cdc4
--- /dev/null
+++ b/i18n/it/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Eseguire un workflow
+parent: Workflow
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Eseguire un workflow
+{: .no_toc }
+
+Avviare un workflow da un modulo, e seguirlo nella pagina dei job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Il modulo
+
+Un modulo di [tipo `workflow`](../forms/workflow.html) avvia un workflow, indicato con `workflow:` come si fa con un playbook: con
+il suo **file** nella cartella dei workflow, con le sottocartelle (`team/deploy-app.yml`), oppure con il **nome** del workflow dentro
+il file (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+I campi del modulo arrivano a ogni nodo come extra vars, e lo stesso vale per le sue [`credentials`](../forms/workflow.html#workflow_credentials), con i nomi
+che il modulo dà loro, come quelle di un modulo multistep arrivano ai suoi passi:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+Le credenziali proprie di un nodo, impostate nel file di workflow, arrivano al suo playbook con il proprio nome e prevalgono su un nome usato da entrambi. Nella scheda Visuale di un modulo nel designer, **Workflow** è un elenco dei
+file di workflow del designer.
+
+Un nome di file da solo viene trovato anche in una sottocartella, quando un solo file ha quel nome. Due workflow con lo stesso nome bloccano un modulo che
+lo indica per nome, e il designer avvisa quando salvi il secondo: rinominane uno, oppure indica il suo file. Un workflow che non si riesce a
+trovare termina il job come fallito, con il motivo nel suo output.
+
+---
+
+## Il job
+
+Un job di workflow gira sul server AnsibleForms, e ogni nodo playbook gira come job a sé, figlio del job di
+workflow come i passi di un modulo multistep: un playbook del designer sull'RTE, oppure, per un nodo con un `runner:`, il
+template o job di quel runner su AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins (vedi [Dove gira un nodo](designer.html#where-a-node-runs)).
+
+La pagina del job disegna il workflow, in diretta: ogni nodo colorato in base al suo stato, i collegamenti scattati, e i nodi che non
+verranno eseguiti. I dati in alto indicano il workflow al posto di un playbook.
+
+- **Fai clic su un nodo** terminato per aprirne l'output in una finestra di dialogo.
+- **L'output** contiene l'output di ogni nodo sotto un'intestazione `WORKFLOW NODE [identifier] (status)`, nell'ordine in cui i nodi
+  sono terminati.
+- **Mostra variabili extra** e **Mostra artefatti**, sull'intestazione di ogni nodo nell'output e nella finestra di dialogo aperta dal grafo,
+  mostrano le extravars e gli artefatti propri di quel nodo (`{}` quando non ne ha), come JSON o YAML, con un pulsante Copia.
+
+Le extravars di un nodo contengono ciò che i nodi precedenti gli hanno passato, e i suoi artefatti ciò che il suo playbook ha raccolto con
+`set_stats`. I due pulsanti seguono le [opzioni di ruolo](../config/roles.html#role-options) `showExtravars` e
+`showArtifacts`. Gli stessi dati si ottengono da `GET /api/v2/job/{id}/node/{nodeId}`, per chiunque possa vedere il job.
+
+Il job fallisce quando un nodo è fallito e nulla ha gestito l'errore, secondo la regola di AWX; altrimenti riesce.
+
+---
+
+## Approvazioni
+
+Un nodo di approvazione trattiene il job di workflow finché qualcuno non risponde.
+
+Quando il workflow raggiunge un nodo di approvazione, lo stato del job diventa **In attesa di approvazione**: compare nella campanella e nella
+pagina del job, come un [punto di approvazione](../forms/approval.html) di un modulo. Il nome del nodo è il titolo dell'approvazione e la sua descrizione
+il messaggio; il resto viene dall'`approval` del modulo:
+
+- i suoi `roles` decidono chi può approvarla o rifiutarla, e `allowSelf` se chi l'ha avviato può anche approvarla;
+- le sue `notifications` e i suoi `channels` ricevono la richiesta.
+
+Un modulo workflow senza `approval` trattiene comunque il job su un nodo di approvazione, ma in quel caso solo un amministratore può approvarlo.
+
+- **Approvata**: il nodo riesce e il workflow prosegue lungo i suoi collegamenti *in caso di successo*.
+- **Rifiutata**: il nodo fallisce e il workflow prosegue lungo i suoi collegamenti *in caso di errore*.
+- **Scaduta**: dopo il timeout del nodo senza risposta, anche in questo caso il nodo fallisce.
+
+---
+
+## Interruzione
+
+**Interrompi** su un job di workflow in esecuzione lo ferma: i job dei nodi in esecuzione vengono interrotti, non parte più nulla, e un'approvazione
+in attesa viene annullata. Si può interrompere anche un job di workflow in attesa di un'approvazione.
diff --git a/i18n/it/_configure/announcements.md b/i18n/it/_configure/announcements.md
new file mode 100644
index 0000000..7312e2d
--- /dev/null
+++ b/i18n/it/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Annunci
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Annunci
+{: .no_toc }
+
+Messaggi sotto l'intestazione per tutti, come una finestra di manutenzione, ciascuno dal suo inizio alla sua fine
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: avvisa tutti gli utenti di una finestra di manutenzione o di un incidente, in **Impostazioni > Aspetto > Annunci**.
+
+La pagina richiede l'opzione di ruolo `showSettings` o `showAppearanceSettings`. Dalla 7.3.0 è un'unica lista, e ogni annuncio
+ha la sua pagina e il suo interruttore Abilitato.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Generale](announcements/general.html) | L'interruttore Abilitato di ogni annuncio, che ha sostituito l'interruttore unico per tutti |
+| [Lista](announcements/list.html) | Gli annunci non ancora terminati, le loro colonne e la pagina di un annuncio |
+| [Aggiungerne uno](announcements/adding-one.html) | La procedura guidata in due passaggi: il messaggio, poi quando compare |
+
+
+---
+
+## Dove compaiono
+
+Gli annunci compaiono come una riga sotto l'intestazione di ogni pagina, per ogni utente che ha effettuato l'accesso, ciascuno nel colore del suo tipo.
+
+Più annunci abilitati possono comparire insieme, il più recente per primo. La pagina di accesso e un modulo incorporato in un altro sito non ne mostrano nessuno.
+
+Ognuno ha un pulsante di chiusura. Un annuncio chiuso resta chiuso in quella scheda del browser finché la scheda non viene chiusa, o
+finché non cambiano il suo messaggio o la sua data di fine. Un annuncio salvato raggiunge subito tutti i browser aperti; uno che
+arriva alla sua data di inizio o di fine compare o scompare lì entro un minuto.
diff --git a/i18n/it/_configure/announcements/adding-one.md b/i18n/it/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..6dc43e0
--- /dev/null
+++ b/i18n/it/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Aggiungerne uno
+parent: Annunci
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Aggiungerne uno
+{: .no_toc }
+
+La procedura guidata in due passaggi: il messaggio, poi quando compare
+{: .fs-6 .fw-300 }
+
+**Aggiungi annuncio** apre una procedura guidata in due passaggi. **Messaggio** chiede cosa dice:
+
+| Campo | Significato |
+|---|---|
+| **Messaggio** | Il testo, al massimo 500 caratteri. Obbligatorio. |
+| **Tipo** | Il suo colore e la sua icona: blu per Info (il predefinito), ambra per Avviso, rosso per Pericolo |
+
+**Quando** chiede quando compare:
+
+| Campo | Significato |
+|---|---|
+| **Data di inizio** | Compare da questo momento. Lasciala vuota per mostrarlo subito. |
+| **Data di fine** | In questo momento scompare e viene eliminato. Lasciala vuota per tenerlo finché non lo elimini. |
+
+La data di fine deve essere successiva alla data di inizio e trovarsi nel futuro.
diff --git a/i18n/it/_configure/announcements/general.md b/i18n/it/_configure/announcements/general.md
new file mode 100644
index 0000000..db3c625
--- /dev/null
+++ b/i18n/it/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Generale
+parent: Annunci
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Generale
+{: .no_toc }
+
+L'interruttore Abilitato di ogni annuncio, che ha sostituito l'interruttore unico per tutti
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Attivare o disattivare un annuncio
+
+Dalla 7.3.0 ogni annuncio si attiva o si disattiva da solo, con il suo interruttore **Abilitato**.
+
+Un nuovo annuncio è abilitato. **Disabilita** nel menu della sua riga, o l'interruttore **Abilitato** nella sua pagina, lo nasconde sotto l'intestazione e lo lascia
+nella lista, e **Abilita** lo mostra di nuovo dalla sua data di inizio fino alla sua data di fine. L'interruttore viene salvato subito.
+
+---
+
+## L'interruttore Mostra annunci della 7.2
+
+Fino alla 7.2, una scheda **Generale** aveva un interruttore **Mostra annunci** che li attivava o disattivava tutti insieme.
+
+Dalla 7.3.0 quell'interruttore non c'è più. Se era disattivato, l'aggiornamento disabilita ogni annuncio, così nessuno inizia a comparire: abilita di nuovo quelli che vuoi.
diff --git a/i18n/it/_configure/announcements/list.md b/i18n/it/_configure/announcements/list.md
new file mode 100644
index 0000000..e0abb2c
--- /dev/null
+++ b/i18n/it/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Lista
+parent: Annunci
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Lista
+{: .no_toc }
+
+Gli annunci non ancora terminati, le loro colonne e la pagina di un annuncio
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La lista
+
+**Impostazioni > Aspetto > Annunci** elenca ogni annuncio non ancora terminato, con queste colonne:
+
+| Colonna | Significato |
+|---|---|
+| **Abilitato** | Se compare sotto l'intestazione dal suo inizio alla sua fine (dalla 7.3.0) |
+| **Messaggio** | Il testo sotto l'intestazione |
+| **Tipo** | Info, Avviso o Pericolo |
+| **Data di inizio** | Quando inizia a comparire; `–` quando compare subito |
+| **Data di fine** | Quando termina; `–` quando compare finché non viene eliminato |
+| **Creato da** | Chi l'ha aggiunto |
+
+Un clic su una riga, o **Modifica** nel menu della riga, apre la pagina dell'annuncio. Il menu ha anche **Abilita** o **Disabilita**, ed **Elimina**.
+
+Una volta passata la sua data di fine, un annuncio viene eliminato: la lista conserva solo quelli in arrivo e quelli che stanno comparendo.
+
+---
+
+## La pagina di un annuncio
+
+Dalla 7.3.0 ogni annuncio si apre in una pagina propria, in `/settings/announcements/<id>`, con una sola scheda, **Dettagli**.
+
+Contiene il messaggio, il tipo, le date di inizio e di fine e l'interruttore **Abilitato**, che viene salvato subito; gli altri campi si salvano
+con **Salva**, ed **Elimina** rimuove l'annuncio. Il titolo della pagina lo identifica con i primi caratteri del suo messaggio.
diff --git a/i18n/it/_configure/appearance.md b/i18n/it/_configure/appearance.md
new file mode 100644
index 0000000..ed21d4c
--- /dev/null
+++ b/i18n/it/_configure/appearance.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Aspetto
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Aspetto
+{: .no_toc }
+
+I valori predefiniti, il nome, il logo, l'icona del browser, i collegamenti dell'intestazione e le etichette accanto al logo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: dai all'istanza il tuo aspetto, in **Impostazioni > Aspetto**, con l'opzione di ruolo `showSettings`.
+Anche la sola opzione di ruolo `showAppearanceSettings` apre queste pagine, annunci compresi, senza il resto delle impostazioni.
+
+Le pagine di questo gruppo sono **Valori predefiniti**, **Nome**, **Logo**, **Icona**, **Collegamenti**, **Etichette** e **Annunci**;
+gli annunci hanno una pagina tutta loro, [Annunci](announcements.html). Un valore predefinito, un nome, un collegamento o un'etichetta salvati
+compaiono subito in tutti i browser aperti.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Valori predefiniti](appearance/defaults.html) | Il tema, la lingua, il fuso orario e il formato data per gli utenti che non ne hanno scelto nessuno |
+| [Nome](appearance/name.html) | Il nome dell'applicazione nella scheda del browser e nella pagina di accesso |
+| [Logo](appearance/logo.html) | Il tuo logo nell'intestazione |
+| [Icona](appearance/icon.html) | La tua icona nella scheda del browser e nei segnalibri |
+| [Collegamenti](appearance/links.html) | I collegamenti dell'intestazione, integrati e tuoi |
+| [Etichette](appearance/labels.html) | Etichette accanto al logo che dicono di quale istanza si tratta; un'unica etichetta Ambiente fino alla 7.2 |
diff --git a/i18n/it/_configure/appearance/defaults.md b/i18n/it/_configure/appearance/defaults.md
new file mode 100644
index 0000000..1a838b8
--- /dev/null
+++ b/i18n/it/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Valori predefiniti
+parent: Aspetto
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Valori predefiniti
+{: .no_toc }
+
+Il tema, la lingua, il fuso orario e il formato data per gli utenti che non ne hanno scelto nessuno
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## I valori predefiniti
+
+**Valori predefiniti** imposta l'aspetto dell'app per un utente che non ha fatto una scelta propria nelle sue
+[preferenze](../profile/preferences.html); la scelta dell'utente prevale sempre:
+
+| Campo | Scelte | Senza una scelta |
+|---|---|---|
+| **Tema predefinito** | Segui il browser, Chiaro, Scuro o Colore, con uno di 12 colori per Colore | Segui il browser (Chiaro fino alla 7.2) |
+| **Lingua predefinita** | Le lingue dell'app, salvata in [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Inglese |
+| **Vista dei moduli predefinita** | Riquadri o Elenco, per la pagina dei moduli | Riquadri |
+| **Fuso orario predefinito** | UTC, il browser di ogni utente o qualsiasi fuso per nome | UTC |
+| **Formato data predefinito** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY`, mostrati con la data di oggi | `YYYY-MM-DD` |
+
+La lingua è una variabile d'ambiente e si applica senza riavvio. Con
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) impostata a `0` la pagina la mostra in sola lettura.
+
+Dalla 7.3.0 la pagina è divisa nelle due schede delle preferenze del profilo, **Aspetto** (tema, lingua e vista dei moduli) e **Data e
+ora** (fuso orario e formato data, con un'anteprima dell'ora attuale), e la sua casella di ricerca elenca le corrispondenze sotto il nome di ogni scheda.
+
+---
+
+## Seguire il browser
+
+Dalla 7.3.0 **Segui il browser** mostra a ogni utente il tema chiaro o scuro richiesto dal suo browser, e cambia insieme a lui.
+
+È il valore predefinito quando non si sceglie nessun tema predefinito, quindi una nuova installazione segue il browser. Passando il puntatore su uno dei colori di
+**Colore** si vede un'anteprima dell'app in quel colore; il tema che avevi ritorna quando il puntatore si sposta, e nulla viene salvato fino a **Salva**.
diff --git a/i18n/it/_configure/appearance/icon.md b/i18n/it/_configure/appearance/icon.md
new file mode 100644
index 0000000..94707cc
--- /dev/null
+++ b/i18n/it/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Icona
+parent: Aspetto
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Icona
+{: .no_toc }
+
+La tua icona nella scheda del browser e nei segnalibri
+{: .fs-6 .fw-300 }
+
+**Icona** sostituisce l'icona di AnsibleForms nella scheda del browser e nei segnalibri:
+
+| Regola | Valore |
+|---|---|
+| Tipi | PNG, ICO, SVG, WEBP, GIF e JPEG |
+| File più grande | 256 KB |
+| Risultato migliore | Un'immagine quadrata di almeno 64 × 64 px, oppure un SVG |
+
+Scegli un file in **Nuova icona** e fai clic su **Carica**; **Rimuovi l'icona personalizzata** ripristina l'icona predefinita.
diff --git a/i18n/it/_configure/appearance/labels.md b/i18n/it/_configure/appearance/labels.md
new file mode 100644
index 0000000..774046e
--- /dev/null
+++ b/i18n/it/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Etichette
+parent: Aspetto
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Etichette
+{: .no_toc }
+
+Etichette accanto al logo che dicono di quale istanza si tratta
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La lista
+
+Dalla 7.3.0 **Impostazioni > Aspetto > Etichette** contiene più etichette accanto al logo dell'intestazione, come PRODUCTION ed EU:
+
+| Colonna | Significato |
+|---|---|
+| **Abilitato** | Se l'etichetta compare accanto al logo e nella pagina di accesso |
+| **Etichetta** | Il suo testo, mostrato come la pillola colorata che compare nell'intestazione |
+
+Le righe seguono l'ordine dell'intestazione. Un clic su una riga, o **Modifica** nel menu della riga, apre la pagina dell'etichetta; il menu della riga ha anche
+**Abilita** o **Disabilita**, a seconda del caso, **Sposta su** e **Sposta giù** per cambiare l'ordine, ed **Elimina**.
+
+L'intestazione e la pagina di accesso mostrano le etichette abilitate nel loro ordine. Oltre la terza, un **+N** grigio raccoglie le altre nel suo tooltip,
+e un telefono mostra la prima etichetta e il **+N**. Un'etichetta salvata compare subito in tutti i browser aperti.
+
+---
+
+## Aggiungere un'etichetta
+
+**Aggiungi etichetta** apre una finestra di dialogo con i due campi dell'etichetta, entrambi obbligatori:
+
+| Campo | Significato |
+|---|---|
+| **Etichetta** | Il testo dell'etichetta, come PRODUCTION |
+| **Colore** | Blu, verde, ambra, arancione, rosso o grigio, come campioni rotondi; rosso all'inizio |
+
+Un'anteprima mostra l'intestazione con tutte le etichette abilitate e quella nuova mentre la scrivi. Una nuova etichetta è abilitata e viene dopo
+le altre. La sua pagina ha una sola scheda, **Dettagli**, con gli stessi campi, l'interruttore **Abilitato**, che viene salvato subito, e l'anteprima.
+
+---
+
+## L'etichetta di ambiente della 7.2
+
+Fino alla 7.2, **Impostazioni > Aspetto > Ambiente** impostava un'unica etichetta accanto al logo.
+
+Con una sola etichetta, PRODUCTION EU e PRODUCTION US diventano entrambe PRODUCTION quando più istanze sono aperte una accanto all'altra. Dalla 7.3.0
+l'aggiornamento rende quell'etichetta la prima della lista, con il suo testo, il suo colore e il fatto che comparisse o no, e il vecchio indirizzo
+**Ambiente** apre la lista.
+
+---
+
+## Le etichette nel config seed
+
+Dalla 7.3.0 il [config seed](../seed/) dichiara le etichette nella sua sezione `labels`, ognuna con il suo testo e, se vuoi, il suo colore:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` è uno tra `blue`, `green`, `amber`, `orange`, `red` o `grey`, e `position` le ordina, dalla più bassa. Un'etichetta dichiarata
+nel seed è in sola lettura nella sua pagina, come ogni [oggetto gestito](../seed/managed-objects.html).
diff --git a/i18n/it/_configure/appearance/links.md b/i18n/it/_configure/appearance/links.md
new file mode 100644
index 0000000..c034f01
--- /dev/null
+++ b/i18n/it/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Collegamenti
+parent: Aspetto
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Collegamenti
+{: .no_toc }
+
+I collegamenti dell'intestazione, integrati e tuoi
+{: .fs-6 .fw-300 }
+
+**Collegamenti** imposta i collegamenti dell'intestazione, per ogni utente che ha effettuato l'accesso, in due schede.
+
+**Integrati** ha l'interruttore **Designer**, salvato in [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) e applicato
+senza riavvio. Se è disattivato, il designer sparisce per tutti: il suo collegamento, la sua pagina e la sua API.
+
+**Personalizzati** contiene i tuoi collegamenti, come una wiki, un runbook o un portale di supporto. **Aggiungi collegamento** aggiunge una riga con questi campi:
+
+| Campo | Significato |
+|---|---|
+| **Icona** | L'icona prima dell'etichetta, scelta da un elenco |
+| **Etichetta** | Il testo del collegamento |
+| **Indirizzo** | Un sito (`https://…`) o una pagina dell'app (`/forms/all`) |
+| **Nuova scheda** | Apre il collegamento in una nuova scheda del browser |
+
+I pulsanti di una riga la spostano: **→** mette il collegamento dentro quello sopra, che allora si apre come menu nell'intestazione,
+**←** lo riporta fuori nell'intestazione, e le frecce su e giù lo spostano (un menu insieme ai collegamenti che contiene).
+Un menu non ha bisogno di un indirizzo proprio.
+
+L'intestazione contiene al massimo 5 dei tuoi collegamenti dopo quelli integrati, e al massimo 10 dentro ogni menu.
diff --git a/i18n/it/_configure/appearance/logo.md b/i18n/it/_configure/appearance/logo.md
new file mode 100644
index 0000000..f25083f
--- /dev/null
+++ b/i18n/it/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logo
+parent: Aspetto
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logo
+{: .no_toc }
+
+Il tuo logo nell'intestazione
+{: .fs-6 .fw-300 }
+
+**Logo** sostituisce il logo di AnsibleForms nell'intestazione con la tua immagine, mostrata in ogni tema:
+
+| Regola | Valore |
+|---|---|
+| Tipi | PNG, JPEG, WEBP, GIF e SVG |
+| File più grande | 900 KB |
+| Dimensione nell'intestazione | Al massimo 200 × 33 px, mantenendo le proporzioni |
+
+Scegli un file in **Nuovo logo** per vederne l'anteprima, poi fai clic su **Carica**. **Logo attuale** mostra il logo in uso e la dimensione
+con cui lo mostra l'intestazione. **Rimuovi logo personalizzato** ripristina il logo predefinito, che segue il tema.
diff --git a/i18n/it/_configure/appearance/name.md b/i18n/it/_configure/appearance/name.md
new file mode 100644
index 0000000..9f48db0
--- /dev/null
+++ b/i18n/it/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Nome
+parent: Aspetto
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Nome
+{: .no_toc }
+
+Il nome dell'applicazione nella scheda del browser e nella pagina di accesso
+{: .fs-6 .fw-300 }
+
+**Nome** contiene il **Nome dell'applicazione**, mostrato nella scheda del browser e nella pagina di accesso. Se è vuoto, la scheda del browser mostra
+`AnsibleForms` e la pagina di accesso non mostra alcun nome.
diff --git a/i18n/it/_configure/authentication/entra-id.md b/i18n/it/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..ed0a075
--- /dev/null
+++ b/i18n/it/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Autenticazione
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Single sign-on con Microsoft Entra ID (Azure AD), con i ruoli ricavati dai gruppi Entra ID dell'utente
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Come funziona
+
+Con un provider Entra ID abilitato, la pagina di accesso mostra un pulsante Entra ID sotto **Accedi**. Un accesso procede così:
+
+1. Il pulsante manda il browser a `/api/v2/auth/entraid`, che lo reindirizza a Microsoft.
+2. L'utente accede da Microsoft, che lo reindirizza di nuovo all'**URI di reindirizzamento** con un codice di autorizzazione. Il server
+   scambia quel codice con Microsoft per l'ID token e un access token per Microsoft Graph.
+3. Il server legge i gruppi dell'utente da Microsoft Graph (`/v1.0/me/transitiveMemberOf`), quindi contano anche i gruppi annidati.
+4. I gruppi vengono filtrati con il **Filtro gruppi** sul loro nome visualizzato, e ogni gruppo tenuto viene salvato due volte,
+   come `azuread/<object id>` e come `azuread/<display name>`.
+
+Il nome utente è la claim `upn` del token, es. `jdoe@example.com`, oppure la claim `preferred_username` quando il token
+non ha `upn`; per un account aziendale entrambe contengono lo stesso valore.
+
+---
+
+## Registrare l'applicazione
+
+AnsibleForms ha bisogno di una registrazione dell'app nell'Entra admin center, in **App registrations > New registration**:
+
+1. Dalle un nome, scegli **Accounts in this organizational directory only** come tipi di account supportati, e aggiungi un
+   URI di reindirizzamento di tipo **Web**: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. In **Certificates & secrets**, crea un client secret e copiane il valore; viene mostrato una sola volta.
+3. In **API permissions**, aggiungi i permessi **delegated** di Microsoft Graph `User.Read` e `GroupMember.Read.All`,
+   e concedi per essi il consenso dell'amministratore.
+4. Nella pagina **Overview**, annota l'**Application (client) ID** e il **Directory (tenant) ID**.
+
+L'URI di reindirizzamento è l'indirizzo con cui gli utenti raggiungono AnsibleForms, seguito da `/api/v2/auth/entraid/callback`.
+Con [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms`, diventa
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Deve corrispondere esattamente all'**URI di reindirizzamento** della
+credenziale del provider.
+
+Fino alla 7.2.0 il percorso era `/api/v2/auth/azureadoauth2/callback`. Funziona ancora dalla 7.3.0, quindi una registrazione esistente
+non va modificata; una credenziale con l'**URI di reindirizzamento** vuoto usa il nuovo percorso, quindi in quel caso aggiungilo alla registrazione.
+
+AnsibleForms legge i gruppi da Graph e non usa una claim dei gruppi nel token, quindi non serve configurare nessuna claim di gruppo
+nella registrazione.
+
+---
+
+## Aggiungere il provider
+
+Aggiungi il provider in **Accesso > SSO**: una procedura guidata chiede i suoi campi in quattro passaggi, con **Microsoft Entra ID** nel passaggio **Tipo**:
+
+| Passaggio | Campo | Significato |
+|---|---|---|
+| Dettagli | Nome, Descrizione | Un nome unico per il provider, e una descrizione facoltativa |
+| Tipo | Provider | **Microsoft Entra ID**; si imposta quando viene creato, e resta |
+| Credenziali | Credenziale | Una credenziale **Microsoft Entra ID** di [Connessioni > Credenziali](../credentials.html), vedi sotto |
+| Gruppi | Filtro gruppi | Espressione regolare; si tengono solo i gruppi il cui nome visualizzato corrisponde. Vuoto tiene tutti i gruppi |
+
+La credenziale contiene la registrazione dell'app, quindi solo un admin può aggiungerla o modificarla:
+
+| Campo | Significato |
+|---|---|
+| Tenant ID | Obbligatorio. Il Directory (tenant) ID, un GUID, o uno dei domini del tenant. Solo gli utenti di quel tenant possono accedere |
+| Client ID | L'Application (client) ID |
+| Client secret | Il valore del client secret, salvato cifrato o letto da un [archivio di segreti](../secret-stores/) |
+| URI di reindirizzamento | Come registrato, es. `https://af.example.com/api/v2/auth/entraid/callback`. Vuoto: l'URL dell'app e il percorso di callback |
+
+Una credenziale con il tenant ID vuoto viene rifiutata al salvataggio. Gli endpoint multi-tenant `common`, `organizations`
+e `consumers` vengono rifiutati quando si salva il provider che indica la credenziale, perché permetterebbero di accedere agli utenti di qualsiasi
+tenant Microsoft. All'accesso, il server verifica anche che il token provenga dal tenant configurato. Un provider
+salvato in passato senza tenant ID non fa accedere nessuno: finché il tenant ID non viene compilato, il server registra
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Fino alla 7.2.0 il tenant, il client ID, il secret e l'URL di reindirizzamento erano campi del provider. L'aggiornamento alla 7.3.0 li sposta in una
+credenziale chiamata `<provider>-sso`, vedi [Indirizzi nelle credenziali](../credentials/types.html#addresses-in-credentials).
+Scegli una credenziale per ogni nuovo provider: il server accetta ancora un provider con un proprio client ID e secret di
+prima della 7.3.0, che accede con quelli finché non si sceglie una credenziale.
+
+Si abilita un solo provider Entra ID alla volta, quello con cui accede il pulsante Entra ID. **Abilita** nel menu di riga di un altro,
+o il suo interruttore **Abilitato**, disattiva gli altri del suo tipo; la colonna **Abilitato** della lista mostra quale è in uso. Un provider
+può anche saltare la pagina di accesso, vedi [Attivare il single sign-on](./#switching-single-sign-on). Il salvataggio lo applica subito, senza riavvio.
+
+---
+
+## Corrispondenza con i ruoli
+
+In config.yaml, un gruppo Entra ID è `entraid/<object id>` o `entraid/<display name>`, e un utente è `entraid/<upn>`.
+L'object id è unico nel tenant, quindi è la scelta più sicura; un nome visualizzato è più facile da leggere:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Fino alla 7.2.0 il prefisso era `azuread/`. In un ruolo corrisponde ancora agli stessi membri dalla 7.3.0 e verrà rimosso nella 8.0; l'editor
+dei ruoli scrive `entraid/`. Solo i ruoli accettano `entraid/`: i gruppi dell'utente sono salvati come `azuread/<object id>` e
+`azuread/<display name>`, e la pagina del profilo e la extravar `ansibleforms_user` li mostrano così. Un **Filtro gruppi** come `^AF-` tiene solo i gruppi usati dai tuoi ruoli; vedi [Ruoli](../config/roles.html). Dalla 7.1.0
+il token di accesso non contiene più i gruppi, quindi la sua dimensione non cresce più con essi. Il filtro conta ancora per
+gli utenti con molti gruppi: a ogni accesso si confrontano meno gruppi con i ruoli, e il
+[record della directory](../users-and-groups/directory.html) dell'utente elenca solo i gruppi che contano. Prima della 7.1.0,
+un utente con cento gruppi o più ne ha bisogno per vedere qualsiasi modulo, vedi
+[Moduli e job vuoti dopo un single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Endpoint di Microsoft Graph
+
+Il server fa accedere gli utenti su `https://login.microsoftonline.com` e chiama Microsoft Graph su `https://graph.microsoft.com` per impostazione predefinita:
+
+| Variabile | Cosa cambia |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | L'authority di accesso, per un cloud nazionale come `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | L'endpoint Graph da cui si leggono i gruppi, come `https://graph.microsoft.us` |
+
+Entrambe accettano un URI di base senza slash finale, e sono nuove nella 7.3.0. `AZURE_AUTHORITY_URI` e `AZURE_GRAPH_URI` vengono ancora lette
+quando quelle non sono impostate, con un avviso nel log, e verranno rimosse nella 8.0. Il server deve raggiungere Graph: un accesso non riesce quando i gruppi non si possono leggere.
+
+---
+
+## Limitazioni
+
+Gli utenti Entra ID accedono con Microsoft, quindi alcune cose funzionano in modo diverso rispetto agli account locali e LDAP:
+
+- Non hanno una password in AnsibleForms, quindi non possono cambiarla lì; un [token API](../profile/api-token.html) viene creato dalla loro sessione.
+- I nomi visualizzati non sono unici in Entra ID: due gruppi con lo stesso nome corrispondono allo stesso ruolo. Indica il gruppo con il suo
+  object id nel ruolo, `entraid/<object id>`, per corrispondere solo a quel gruppo.
diff --git a/i18n/it/_configure/authentication/index.md b/i18n/it/_configure/authentication/index.md
new file mode 100644
index 0000000..6108d8b
--- /dev/null
+++ b/i18n/it/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Autenticazione
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Autenticazione
+{: .no_toc }
+
+Scegli come accedono gli utenti, e come il loro account e i loro gruppi portano ai ruoli
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Metodi di accesso
+
+AnsibleForms supporta quattro metodi di accesso, e più di uno può essere attivo allo stesso tempo:
+
+| Metodo | Quando usarlo | Pagina |
+|---|---|---|
+| Account locali | L'admin integrato, gli account di servizio, i team piccoli, o una riserva quando la directory non è disponibile. | [Account locali](local.html) |
+| LDAP | Utenti e gruppi stanno in Active Directory, OpenLDAP o un'altra directory LDAP. | [LDAP](ldap.html) |
+| Entra ID | Gli utenti accedono con il loro account Microsoft 365 / Entra ID (single sign-on). | [Entra ID](entra-id.html) |
+| OIDC | Single sign-on tramite un altro provider OpenID Connect, come Keycloak. | [OIDC](oidc.html) |
+
+Gli account locali e LDAP si configurano in **Accesso > Utenti**, **Gruppi** e **LDAP**; Entra ID e OIDC in
+**Accesso > SSO**.
+
+---
+
+## Come un accesso sceglie il metodo
+
+La pagina di accesso ha un modulo con nome utente e password, più un pulsante per ogni provider di single sign-on abilitato:
+
+- **Nome utente e password** vengono verificati prima sugli utenti locali. Solo quando nessun utente locale ha quel nome, e LDAP
+  è abilitato, si prova la directory. Un utente locale con la password sbagliata viene rifiutato senza interpellare LDAP.
+- **I pulsanti Entra ID e OpenID** compaiono sotto **Accedi** quando un provider di quel tipo è abilitato. Mandano il browser
+  al provider e poi indietro; nessuna password arriva ad AnsibleForms.
+
+Si possono abilitare un solo provider Entra ID e un solo provider OIDC alla volta: abilitarne uno disattiva gli altri del suo tipo.
+Un accesso con nome utente e password non riuscito mostra sempre lo stesso messaggio generico; il motivo è nel log del server e nel log di audit.
+
+---
+
+## Attivare il single sign-on
+
+Dalla 7.3.0 ogni provider in **Accesso > SSO** ha due interruttori propri, che si applicano senza riavvio:
+
+| Interruttore | Effetto |
+|---|---|
+| **Abilitato** | Mostra il pulsante del provider nella pagina di accesso e ne accetta l'accesso. Attivarlo disattiva gli altri provider del suo tipo. |
+| **Salta la pagina di accesso** | Gli utenti vanno direttamente a questo provider, senza la pagina di accesso, finché il provider è abilitato. Attivarlo per un provider lo disattiva per gli altri; è in grigio su un provider disattivato. |
+
+Il modulo con nome utente e password resta raggiungibile in `/login?local`, per l'admin locale o quando il provider non funziona,
+e viene mostrato dopo la disconnessione e quando un accesso single sign-on torna con un errore.
+
+Le variabili `ENABLE_SSO` e `SSO_AUTO_LOGIN` sono rimosse nella 7.3.0. Il primo avvio della 7.3.0 le legge una volta, e
+registra un avviso a ogni avvio finché sono ancora impostate, quindi toglile dall'ambiente dopo l'aggiornamento:
+
+| Variabile prima della 7.3.0 | Cosa fa l'aggiornamento |
+|---|---|
+| `ENABLE_SSO=0` | Disattiva tutti i provider: i provider restano configurati, senza pulsante nella pagina di accesso |
+| `SSO_AUTO_LOGIN=1` | Attiva **Salta la pagina di accesso** per il provider abilitato, quando ne è abilitato esattamente uno e `ENABLE_SSO` non è `0` |
+
+---
+
+## Dall'utente ai ruoli
+
+Ogni accesso produce un utente con un **tipo** (`local`, `ldap`, `azuread` o `oidc`), un nome utente e un elenco di gruppi.
+Ogni gruppo riceve il prefisso del suo tipo, così un gruppo Entra ID viene salvato e mostrato come `azuread/...`:
+
+| Metodo di accesso | Nome utente | Gruppi |
+|---|---|---|
+| Locale | il nome utente locale | `local/<group>`, uno per ogni gruppo locale dell'utente |
+| LDAP, directory `main` | il valore dell'attributo Username | `ldap/<cn>`, il CN di ogni gruppo restituito dalla directory |
+| LDAP, un'altra directory | `<directory>/<username>` | `ldap/<directory>/<cn>`, vedi [Più directory](ldap.html#several-directories) |
+| Entra ID | la claim `upn`, o `preferred_username` quando il token non ha `upn` | `azuread/<object id>` e `azuread/<display name>` di ogni gruppo, letti da Microsoft Graph |
+| OIDC | la claim `preferred_username` | `oidc/<name>`, dalla claim `groups` dell'ID token |
+
+I [ruoli](../config/roles.html) in config.yaml confrontano poi questi valori: un ruolo si applica quando uno dei suoi `groups` è uno
+dei gruppi dell'utente, o quando i suoi `users` contengono `<type>/<username>`. Ogni utente riceve anche il ruolo `default`. Dalla 7.3.0 un
+ruolo indica un membro Entra ID come `entraid/<group>` o `entraid/<upn>`, che corrisponde al valore `azuread/` salvato; `azuread/`
+in un ruolo funziona ancora e verrà rimosso nella 8.0. Il profilo e le extravars del job continuano a mostrare `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+La pagina del **profilo** di un utente elenca il tipo di accesso, i gruppi e i ruoli, ed è il modo più rapido per verificare una corrispondenza.
+L'opzione di ruolo `allowLogin` può rifiutare l'accesso degli utenti che non corrispondono a nessun ruolo: impostala a `false` su `default` e a
+`true` sui ruoli che possono accedere.
diff --git a/i18n/it/_configure/authentication/ldap.md b/i18n/it/_configure/authentication/ldap.md
new file mode 100644
index 0000000..c332b50
--- /dev/null
+++ b/i18n/it/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Autenticazione
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Fai accedere gli utenti della directory con la loro password, e assegna loro i ruoli tramite i loro gruppi della directory
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Come funziona
+
+AnsibleForms si connette alla directory con un account di bind, cerca l'utente e poi esegue il bind come quell'utente per verificare
+la password:
+
+1. L'utente accede con nome utente e password. Quando nessun utente **locale** ha quel nome, si prova LDAP.
+2. AnsibleForms esegue il bind con l'account di bind della credenziale della directory, e cerca in **Base di ricerca** una voce il cui
+   **Attributo nome utente** è uguale al nome utente.
+3. Esegue il bind come la voce trovata, con la password digitata.
+4. I gruppi vengono letti dalla voce (o da una ricerca di gruppi), filtrati, e ricevono il prefisso `ldap/`.
+
+Un nome utente in forma UPN (`jdoe@example.com`) che non trova nessun utente viene riprovato una volta con la parte prima della `@`, così gli utenti
+possono accedere con l'una o l'altra forma anche quando l'Attributo nome utente contiene il nome breve. Una password sbagliata non viene mai riprovata.
+
+Un unico insieme di impostazioni serve Active Directory, OpenLDAP e altri; dalla 7.3.0 possono esserci [più directory](#several-directories).
+
+---
+
+## Impostazioni
+
+Dalla 7.3.0 le impostazioni sono per directory. **Accesso > LDAP** elenca le directory, nell'ordine in cui si cerca un nome utente semplice:
+
+![Accesso > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menu di riga | Cosa fa |
+|---|---|
+| Modifica | Apre la pagina della directory |
+| Testa connessione | Prova un accesso con un nome utente e una password di test, vedi [Testare la connessione](#testing-the-connection) |
+| Attiva, Disattiva | Attiva o disattiva la directory; `main` viene disattivata invece che eliminata |
+| Sposta su, Sposta giù | Cambia la sua posizione nell'ordine di ricerca |
+| Elimina | Rimuove la directory; mostrato ma disabilitato su `main` |
+
+Aggiungere una directory chiede i suoi campi in quattro passaggi, le schede della sua pagina. **Dettagli** contiene **Abilitato**, il **Nome** e una **Descrizione**:
+
+| Scheda | Impostazione | Significato |
+|---|---|---|
+| Credenziali | Credenziale | Obbligatoria. Una credenziale `ldap` di [Connessioni > Credenziali](../credentials.html), che contiene la connessione, vedi sotto |
+| Utenti | Base di ricerca | DN da cui parte la ricerca degli utenti, es. `OU=Users,DC=example,DC=com`. Si cerca anche nei sottoalberi |
+| Utenti | Attributo nome utente | Attributo confrontato con il nome di accesso: `sAMAccountName` in AD (il predefinito), `uid` in OpenLDAP |
+| Utenti | Attributo mail | Attributo che contiene l'indirizzo email, di solito `mail` |
+| Utenti | Domini di accesso | Domini i cui accessi `user@domain` vanno direttamente a questa directory, vedi [Più directory](#several-directories) |
+| Gruppi | Attributo gruppi | Attributo della voce utente che contiene i gruppi (`memberOf`, il predefinito), oppure `groups` con una ricerca di gruppi |
+| Gruppi | Base ricerca gruppi | DN da cui parte la ricerca dei gruppi |
+| Gruppi | Classe gruppo | objectClass dei gruppi, es. `group`, `groupOfNames` o `posixGroup` |
+| Gruppi | Attributo membro gruppo | Attributo di un gruppo che elenca i suoi membri, es. `member`, `uniqueMember` o `memberUid`; predefinito `member` |
+| Gruppi | Attributo utente membro gruppo | Attributo dell'utente contenuto in quei valori di membro, es. `dn` o `uid`; predefinito `dn` |
+| Gruppi | Filtro gruppi | Espressione regolare; si tengono solo i gruppi il cui nome corrisponde. Vuoto tiene tutti i gruppi |
+
+I valori predefiniti degli ultimi tre campi dei gruppi si applicano solo quando si usa la ricerca di gruppi, vedi la sezione successiva.
+
+La credenziale `ldap` contiene come si raggiunge la directory e con quale identità la si interroga:
+
+| Campo | Significato |
+|---|---|
+| Server | Uno per campo, come `host`, `host:port` o `ldaps://host:port`, provati in questo ordine: quando uno non è raggiungibile, si passa al successivo |
+| Porta | `389` per LDAP semplice, `636` per LDAPS |
+| Abilita TLS | Connessione con LDAPS (`ldaps://`). StartTLS sulla porta 389 non è supportato |
+| Ignora certificati | Salta la validazione del certificato del server. Mostrato solo con **Abilita TLS** |
+| Certificato | Il certificato client che AnsibleForms presenta ai server, in PEM, quando i certificati vengono verificati |
+| Bundle CA | Il o i certificati CA che hanno firmato il certificato del server, in PEM, quando i certificati vengono verificati |
+| Bind user DN | Il DN dell'account di servizio che interroga la directory |
+| Password bind user | La sua password, salvata cifrata o letta da un [archivio di segreti](../secret-stores/) |
+
+Solo un admin può aggiungere o modificare una credenziale `ldap`, vedi [Chi può modificare una credenziale](../credentials.html#who-may-change-a-credential).
+Fino alla 7.2.0 i server, il TLS e l'account di bind erano campi delle impostazioni LDAP. L'aggiornamento alla 7.3.0 li sposta in una credenziale,
+vedi [Indirizzi nelle credenziali](../credentials/types.html#addresses-in-credentials):
+
+| La directory prima dell'aggiornamento | Dove vanno i suoi server |
+|---|---|
+| Un bind DN e una password propri, nessuna credenziale | Una nuova credenziale `ldap` chiamata `<directory>-ldap`, come `main-ldap` |
+| Una credenziale senza server | In quella credenziale |
+| Una credenziale che contiene già altri server | Una copia della credenziale chiamata `<credential>-<directory>`, che la directory poi indica |
+
+Un nome già in uso riceve `-2`, `-3` e così via. Una directory del config seed resta com'è: è del seed.
+
+---
+
+## Gruppi
+
+I gruppi arrivano da uno di due posti, e l'**Attributo gruppi** decide quale si usa:
+
+- **Un attributo della voce utente**, di solito `memberOf`. È la configurazione comune per Active Directory, e per
+  OpenLDAP con l'overlay `memberof`.
+- **Una ricerca di gruppi**, per le directory senza `memberOf`. Viene eseguita solo quando **Base ricerca gruppi** e **Classe gruppo**
+  sono entrambi impostati: AnsibleForms cerca allora i gruppi di quella classe il cui **Attributo membro gruppo** contiene
+  l'**Attributo utente membro gruppo** dell'utente, e salva il risultato nell'attributo `groups`. Imposta **Attributo gruppi** a `groups`
+  per usarla.
+
+{: .note }
+> Con **Attributo gruppi** `memberOf`, una ricerca di gruppi configurata viene eseguita ma il suo risultato non si usa per i ruoli.
+
+Ogni gruppo è un DN, e AnsibleForms tiene il suo primo CN: `CN=AF-Admins,OU=Groups,DC=example,DC=com` diventa `AF-Admins`.
+Il **Filtro gruppi** si applica poi a quel nome, e i gruppi rimasti ricevono il prefisso `ldap/`: `ldap/AF-Admins`.
+
+Nelle directory grandi il filtro mantiene piccoli i token e i job; un'espressione regolare non valida tiene tutti i gruppi e viene registrata nel log.
+
+---
+
+## Corrispondenza con i ruoli
+
+In config.yaml, un gruppo LDAP è `ldap/<group CN>` e un utente LDAP è `ldap/<username>`, entrambi sensibili a maiuscole e minuscole:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+Il nome utente è il valore dell'**Attributo nome utente** come lo restituisce la directory, non come l'ha digitato l'utente.
+Vedi [Ruoli](../config/roles.html) per le opzioni dei ruoli.
+
+---
+
+## Più directory
+
+Dalla 7.3.0 possono esserci più directory, ognuna con i suoi server, utenti e gruppi. I loro nomi distinguono i loro membri:
+
+| Directory | Nome utente | Gruppi | In un ruolo |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Qualsiasi altra, come `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Un utente indica la directory all'accesso come `corp\jdoe` o `corp/jdoe`, oppure accede con un indirizzo di un dominio che la directory
+possiede. Un nome utente semplice si prova in ogni directory abilitata, nel loro ordine, e così anche un nome come `other\jdoe` quando nessuna
+directory si chiama `other`: allora si cerca così come è stato digitato.
+
+Decide la prima directory che conosce l'utente: una password sbagliata lì è la risposta, e la directory successiva non viene
+provata, perché potrebbe contenere qualcun altro con quel nome. Una directory non raggiungibile viene saltata.
+
+La directory chiamata `default` fino alla 7.2.0 si chiama `main` dalla 7.3.0: l'aggiornamento la rinomina, e una nuova installazione parte
+con `main`. I suoi membri mantengono i loro nomi brevi, quindi i ruoli che li indicano non vanno modificati. La directory `main` non si può
+rinominare, e il nome di una directory contiene solo lettere, cifre, `-` e `_`.
+
+---
+
+## Testare la connessione
+
+**Testa connessione** chiede un nome utente e una password di test, e prova un accesso con le impostazioni sullo schermo, salvate o no.
+Se riesce mostra la voce della directory dell'utente, che ti dice i nomi esatti degli attributi e i DN dei gruppi da usare.
+
+Un utente di test che non esiste segnala comunque un successo: la connessione e l'account di bind funzionano, solo l'utente non
+viene trovato. Errori tipici:
+
+| Messaggio | Causa |
+|---|---|
+| `Bad server or port (connection failed)` | Il nome host non si risolve o la porta non è raggiungibile. |
+| `Wrong binding credentials` | Il bind DN o la password della credenziale della directory sono sbagliati. |
+| `Unable to verify the certificate` | Il certificato del server non è firmato dal Bundle CA della credenziale. |
+| `Certificate is not valid` | Il Certificato o il Bundle CA della credenziale non contengono un certificato PEM valido. |
+
+---
+
+## Esempio con Active Directory
+
+Questo esempio si connette a due domain controller via LDAPS e tiene solo i gruppi il cui nome inizia con `AF-`:
+
+| Impostazione | Valore |
+|---|---|
+| Credenziale > Server | `dc01.example.com`, poi `dc02.example.com` |
+| Credenziale > Porta | `636` |
+| Credenziale > Abilita TLS | attivo |
+| Credenziale > Ignora certificati | disattivo, con un certificato client e la catena CA della CA aziendale |
+| Credenziale > Bind user DN | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Base di ricerca | `OU=Users,DC=example,DC=com` |
+| Attributo mail | `mail` |
+| Attributo nome utente | `sAMAccountName` |
+| Attributo gruppi | `memberOf` |
+| Filtro gruppi | `^AF-` |
+
+I membri di `CN=AF-Operators,…` corrispondono ai ruoli con `ldap/AF-Operators`, e accedono come `jdoe` o `jdoe@example.com`.
+
+---
+
+## Esempio con OpenLDAP
+
+Questo esempio usa una ricerca di gruppi sulle voci `groupOfNames`, quindi funziona senza l'overlay `memberof`:
+
+| Impostazione | Valore |
+|---|---|
+| Credenziale > Server | `ldap.example.com` |
+| Credenziale > Porta | `636` |
+| Credenziale > Abilita TLS | attivo |
+| Credenziale > Bind user DN | `cn=readonly,dc=example,dc=com` |
+| Base di ricerca | `ou=people,dc=example,dc=com` |
+| Attributo mail | `mail` |
+| Attributo nome utente | `uid` |
+| Attributo gruppi | `groups` |
+| Base ricerca gruppi | `ou=groups,dc=example,dc=com` |
+| Classe gruppo | `groupOfNames` |
+| Attributo membro gruppo | `member` |
+| Attributo utente membro gruppo | `dn` |
+
+Un utente elencato in `cn=af-admins,ou=groups,dc=example,dc=com` riceve il gruppo `ldap/af-admins`. Per i gruppi `posixGroup`,
+usa **Attributo membro gruppo** `memberUid` e **Attributo utente membro gruppo** `uid`.
+
+Con l'overlay `memberof`, lascia vuoti i campi della ricerca di gruppi e imposta **Attributo gruppi** a `memberOf`.
+
+---
+
+## Errori comuni
+
+La maggior parte dei problemi LDAP si riduce a uno di questi:
+
+- **Un utente locale con lo stesso nome.** Gli utenti locali si verificano per primi, quindi alla directory non si chiede mai di quel nome.
+- **Nessun gruppo, o quelli sbagliati.** L'Attributo gruppi deve esistere (`groups` con una ricerca di gruppi); `memberOf` ignora l'annidamento.
+- **Nomi di gruppo che non corrispondono.** Usa `ldap/<CN>` con le stesse maiuscole e minuscole, e verifica che il Filtro gruppi tenga il gruppo.
+- **DN di gruppo che non iniziano con un CN.** Come nome del gruppo si usa solo il primo valore `CN=`, quindi ogni DN di gruppo
+  deve iniziare con `CN=` (o `cn=`).
+- **Certificati.** Il TLS richiede entrambi i campi dei certificati della credenziale e un nome di server corrispondente; Ignora certificati è solo per i test.
+- **Impostazioni che non si possono salvare.** Quando una directory viene dal [config seed](../seed/managed-objects.html), la sua pagina
+  è in sola lettura: modifica invece il file del seed.
+
+Un accesso non riuscito mostra un messaggio generico. Il motivo viene registrato dal server e conservato nel log di audit, e per Active
+Directory viene tradotto dal codice della directory, es. `Wrong password`, `Account locked` o `Password expired`.
diff --git a/i18n/it/_configure/authentication/local.md b/i18n/it/_configure/authentication/local.md
new file mode 100644
index 0000000..69e92a9
--- /dev/null
+++ b/i18n/it/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Account locali
+parent: Autenticazione
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Account locali
+{: .no_toc }
+
+L'admin integrato, e gli utenti e i gruppi salvati nel database di AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'admin integrato
+
+Ogni avvio crea il gruppo locale `admins` e l'utente admin se mancano; tre variabili controllano l'admin:
+
+| Variabile | Predefinito | Significato |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Nome utente dell'admin, creato nel gruppo `admins` quando nessun utente ha quel nome. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Password assegnata all'admin quando viene creato (o reimpostato). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` reimposta la password dell'admin a `ADMIN_PASSWORD` e lo rimette in `admins`. |
+
+`ADMIN_PASSWORD` si usa solo quando l'utente viene creato o reimpostato: cambiarla dopo non ha alcun effetto da sola.
+
+Un utente locale che accede con la password predefinita pubblica `AnsibleForms!123` può solo cambiarla. Il browser apre una
+pagina di cambio password che non si può chiudere, e il server risponde a ogni altra richiesta con `403` (codice
+`password_change_required`) finché la password non viene cambiata. La nuova password deve essere diversa da quella predefinita; dopo il
+cambio, l'utente accede di nuovo con quella. Imposta `ADMIN_PASSWORD` con un tuo valore prima del primo avvio per saltare questo passaggio.
+
+Cambiare `ADMIN_USERNAME` dopo il primo avvio crea un secondo utente admin con quel nome; quello vecchio resta.
+
+{: .warning }
+> `REINIT_ADMIN=1` reimposta la password a **ogni** avvio finché è impostata. Usala per recuperare una password dell'admin persa,
+> poi rimuovila e riavvia.
+
+---
+
+## Utenti e gruppi
+
+Gli utenti e i gruppi locali si gestiscono in **Accesso > Utenti** e **Accesso > Gruppi**. Un utente ha questi campi:
+
+| Campo | Significato |
+|---|---|
+| Nome utente | Il nome di accesso. Deve essere unico. |
+| Descrizione | Facoltativa. |
+| Password | Salvata come hash. Cambiala in seguito con l'azione **Cambia password**. |
+| Email | Facoltativa. |
+| Gruppo | Il primo gruppo locale dell'utente. Aggiungine altri nella scheda **Gruppi** della pagina dell'utente. |
+
+Gli utenti locali cambiano la propria password nel loro profilo; gli altri utenti lo fanno nella loro directory o nel loro identity provider.
+
+Un utente può appartenere a più gruppi, e riceve i ruoli di tutti. La scheda **Gruppi** della pagina di un utente aggiunge e
+rimuove gruppi, e lo stesso fa la scheda **Utenti** della pagina di un gruppo. Un utente conserva almeno un gruppo: l'ultimo non si può
+rimuovere.
+
+Un gruppo che ha ancora utenti non si può eliminare: rimuovi prima i suoi utenti. Il gruppo `admins` non si può mai eliminare né
+rinominare, e l'utente `admin` non si può mai eliminare.
+
+---
+
+## Consentire l'accesso
+
+La scheda **Dettagli** della pagina di un utente ha un interruttore **Consenti accesso**, offerto anche come **Blocca accesso** e **Consenti
+accesso** nel menu di riga della lista degli utenti. Esiste allo stesso modo per gli utenti locali e per gli utenti LDAP e SSO:
+
+- **Attivo**: l'utente accede come al solito.
+- **Disattivo**: le sessioni dell'utente terminano subito e ogni accesso viene rifiutato, finché un admin non lo riattiva. La pagina
+  chiede prima una conferma.
+
+L'interruttore non si può disattivare per l'utente `admin`, la via per rientrare, né può farlo un admin per il proprio account. La pagina di
+un utente LDAP o SSO ha anche **Termina sessioni**, che disconnette l'utente ovunque senza bloccarlo.
+
+---
+
+## Corrispondenza con i ruoli
+
+I ruoli indicano i gruppi locali come `local/<group>` e gli utenti come `local/<user>`; per impostazione predefinita `admins` riceve `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Tieni `local/admins` nel ruolo `admin`, così l'admin integrato può sempre accedere, anche quando la directory o
+l'identity provider non sono disponibili. Quando config.yaml non si riesce a caricare affatto, i membri di `local/admins` ricevono comunque il
+ruolo `admin`, così puoi accedere e correggerlo. Vedi [Ruoli](../config/roles.html) per le opzioni dei ruoli.
+
+---
+
+## Account locali e LDAP
+
+Un accesso con nome utente e password verifica gli utenti locali prima di LDAP. Quando un utente locale ha lo stesso nome di un utente
+della directory, vince sempre l'account locale e la password della directory non funziona per quel nome. Dai agli account locali nomi
+che non possano entrare in conflitto con gli account della directory, per esempio con un prefisso `svc-`.
diff --git a/i18n/it/_configure/authentication/oidc.md b/i18n/it/_configure/authentication/oidc.md
new file mode 100644
index 0000000..e251b16
--- /dev/null
+++ b/i18n/it/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Autenticazione
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Single sign-on con un provider OpenID Connect come Keycloak, con i ruoli ricavati da una claim dei gruppi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Come funziona
+
+Con un provider OIDC abilitato, la pagina di accesso mostra un pulsante OpenID sotto **Accedi**. Un accesso procede così:
+
+1. Il pulsante manda il browser a `/api/v2/auth/oidc`, che lo reindirizza al provider (flusso authorization code
+   con PKCE).
+2. L'utente accede presso il provider, che lo reindirizza di nuovo all'**URI di reindirizzamento**.
+3. Il server scambia il codice con i token e legge le claim dell'ID token.
+4. Il nome utente è la claim `preferred_username`, e ogni valore della claim `groups` che supera il
+   **Filtro gruppi** diventa un gruppo `oidc/<value>`.
+
+AnsibleForms richiede gli scope `openid profile email`; gli scope non sono configurabili. Disconnettersi da AnsibleForms
+manda anche il browser all'endpoint di fine sessione del provider, quando il provider ne pubblica uno.
+
+{: .note }
+> OIDC è stato testato con Keycloak. Gli altri provider funzionano quando soddisfano i requisiti qui sotto.
+
+---
+
+## Requisiti del provider
+
+Il provider deve offrire la discovery di OpenID Connect, e un client confidenziale per AnsibleForms:
+
+- **Discovery**: AnsibleForms legge `<issuer>/.well-known/openid-configuration`, quindi l'issuer deve essere raggiungibile dal
+  server di AnsibleForms, via HTTPS.
+- **Un client confidenziale** con il flusso authorization code, un client ID e un client secret.
+- **L'URI di reindirizzamento** `https://af.example.com/api/v2/auth/oidc/callback`, cioè l'indirizzo con cui gli utenti raggiungono
+  AnsibleForms seguito da `/api/v2/auth/oidc/callback`. Con [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms`, diventa `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Una claim `groups` nell'ID token**, che contiene un elenco di nomi di gruppo. Senza di essa, l'utente non riceve gruppi OIDC.
+- **Una claim `preferred_username`**, che diventa il nome utente.
+
+---
+
+## Esempio con Keycloak
+
+Questo esempio usa un realm `example` su `https://keycloak.example.com`; l'issuer è quindi
+`https://keycloak.example.com/realms/example`. In quel realm:
+
+1. In **Clients**, crea un client OpenID Connect con client ID `ansibleforms`. Attiva **Client authentication**,
+   lascia **Standard flow**, e imposta **Valid redirect URIs** a `https://af.example.com/api/v2/auth/oidc/callback`.
+2. Nella scheda **Credentials** del client, copia il **Client secret**.
+3. Nella scheda **Client scopes**, apri `ansibleforms-dedicated` e aggiungi un mapper **By configuration > Group Membership**,
+   con **Token Claim Name** `groups`, **Full group path** disattivato e **Add to ID token** attivato.
+
+Con **Full group path** attivato, la claim contiene percorsi come `/af-admins`, e il ruolo deve allora usare `oidc//af-admins`.
+
+---
+
+## Aggiungere il provider
+
+Aggiungi il provider in **Accesso > SSO**: una procedura guidata chiede i suoi campi in quattro passaggi, con **Open ID** nel passaggio **Tipo**:
+
+| Passaggio | Campo | Significato |
+|---|---|---|
+| Dettagli | Nome, Descrizione | Un nome unico per il provider, e una descrizione facoltativa |
+| Tipo | Provider | **Open ID**; si imposta quando viene creato, e resta |
+| Credenziali | Credenziale | Una credenziale **Open ID** di [Connessioni > Credenziali](../credentials.html), vedi sotto |
+| Gruppi | Filtro gruppi | Espressione regolare; si tengono solo i valori della claim `groups` che corrispondono. Vuoto tiene tutti i gruppi |
+
+La credenziale contiene il client, quindi solo un admin può aggiungerla o modificarla:
+
+| Campo | Significato |
+|---|---|
+| Issuer | Obbligatorio. L'URL dell'issuer, es. `https://keycloak.example.com/realms/example` |
+| Client ID | Il client ID presso il provider, es. `ansibleforms` |
+| Client secret | Il client secret, salvato cifrato o letto da un [archivio di segreti](../secret-stores/) |
+| URI di reindirizzamento | Come registrato, es. `https://af.example.com/api/v2/auth/oidc/callback`. Vuoto: l'URL dell'app e il percorso di callback |
+
+Fino alla 7.2.0 l'issuer, il client ID, il secret e l'URL di reindirizzamento erano campi del provider. L'aggiornamento alla 7.3.0 li sposta in una
+credenziale chiamata `<provider>-sso`, vedi [Indirizzi nelle credenziali](../credentials/types.html#addresses-in-credentials).
+Scegli una credenziale per ogni nuovo provider: il server accetta ancora un provider con un proprio client ID e secret di
+prima della 7.3.0, che accede con quelli finché non si sceglie una credenziale.
+
+Si abilita un solo provider OIDC alla volta, quello con cui accede il pulsante OpenID. **Abilita** nel menu di riga di un altro,
+o il suo interruttore **Abilitato**, disattiva gli altri del suo tipo; la colonna **Abilitato** della lista mostra quale è in uso.
+Un provider può anche saltare la pagina di accesso, vedi [Attivare il single sign-on](./#switching-single-sign-on).
+
+Salvare il provider lo applica immediatamente. Quando l'issuer non è raggiungibile, il server registra
+`Failed to initialize OIDC strategy` e gli accessi OIDC non riescono finché il provider non viene salvato di nuovo o il server non si riavvia.
+
+---
+
+## Corrispondenza con i ruoli
+
+In config.yaml, un gruppo OIDC è `oidc/<group>` e un utente è `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+I valori si confrontano esattamente, maiuscole e minuscole comprese. Vedi [Ruoli](../config/roles.html) per le opzioni dei ruoli.
+
+---
+
+## Limitazioni
+
+Gli utenti OIDC accedono presso il provider, quindi alcune cose funzionano in modo diverso rispetto agli account locali e LDAP:
+
+- Non hanno una password in AnsibleForms, quindi non possono cambiarla lì; dalla 7.2.0 un [token API](../profile/api-token.html)
+  viene creato dalla loro sessione.
+- Mantieni corta la claim `groups`: invia solo i gruppi che contano per AnsibleForms, per esempio con uno scope client
+  dedicato o una struttura di gruppi presso il provider, oppure filtrali con il **Filtro gruppi**. Dalla 7.1.0 il token
+  di accesso di AnsibleForms non contiene più i gruppi; prima, un utente con cento gruppi o più poteva non vedere nessun modulo, vedi
+  [Moduli e job vuoti dopo un single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/it/_configure/config/categories.md b/i18n/it/_configure/config/categories.md
new file mode 100644
index 0000000..24521f3
--- /dev/null
+++ b/i18n/it/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Categorie
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Categorie
+{: .no_toc }
+
+Raggruppa i moduli nella dashboard.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'attributo categories
+
+La lista `categories` di primo livello di config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Oggetto Category
+
+Ogni voce della lista `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/it/_configure/config/constants.md b/i18n/it/_configure/config/constants.md
new file mode 100644
index 0000000..53ab1ff
--- /dev/null
+++ b/i18n/it/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Costanti
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Costanti
+{: .no_toc }
+
+Oggetti liberi che ogni modulo può riutilizzare.
+{: .fs-6 .fw-300 }
+
+---
+
+## L'attributo constants
+
+L'oggetto `constants` di primo livello di config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/it/_configure/config/index.md b/i18n/it/_configure/config/index.md
new file mode 100644
index 0000000..fd8d94e
--- /dev/null
+++ b/i18n/it/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Categorie, ruoli e costanti per tutti i moduli
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori: il file config.yaml che contiene le categorie, i ruoli e le costanti condivisi da tutti i moduli.
+
+AnsibleForms usa un file config.yaml per configurare categorie, ruoli e costanti. Se non viene fornito nessun file, ne viene generato uno con una configurazione minima. La configurazione si può anche importare nel database, il che rende superfluo un file config.yaml.
+
+---
+
+## Panoramica
+
+Il file config.yaml contiene la configurazione delle categorie, dei ruoli e delle costanti usati da AnsibleForms.
+
+**VIDEO**: [Crea il tuo primo modulo](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+Il seguente config.yaml minimo serve da punto di partenza. Contiene solo la categoria obbligatoria `Default` e i ruoli obbligatori `admin` e `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Priorità di caricamento della configurazione
+
+AnsibleForms carica il file config.yaml nel seguente ordine (vince la prima corrispondenza):
+
+1. **DAL DATABASE** : la configurazione importata nel database, solo quando `ENABLE_CONFIG_IN_DATABASE=1`, oppure quando quella
+   variabile non è impostata e l'origine della configurazione salvata nel database è `database` (una copia vuota ripiega sul file)
+2. **DA UN REPOSITORY (use_for_config)** : il repository con l'interruttore "usa per la configurazione" attivo (novità della 6.1.0)
+3. **DA UN REPOSITORY (use_for_forms)** : il repository con l'interruttore "usa per i moduli" attivo (ripiego per compatibilità con le versioni precedenti)
+4. **DA UN FILE LOCALE** : il file locale `config.yaml` (variabile d'ambiente CONFIG_PATH)
+
+{: .warning }
+> **Nota:** attiva "usa per la configurazione" su un solo repository. Se ce l'hanno attivo più repository, viene registrato un avviso e si usa il primo.
+
+---
+
+## In questa sezione
+
+Il file ha tre attributi di primo livello, e ognuno ha una pagina propria:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Categorie](categories.html) | Raggruppa i moduli nella dashboard in un albero di categorie con icone |
+| [Ruoli](roles.html) | Associa utenti e gruppi ai ruoli, e stabilisci cosa può fare ogni ruolo |
+| [Costanti](constants.html) | Oggetti liberi che ogni modulo può riutilizzare |
diff --git a/i18n/it/_configure/config/roles.md b/i18n/it/_configure/config/roles.md
new file mode 100644
index 0000000..ac0c438
--- /dev/null
+++ b/i18n/it/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Ruoli
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Ruoli
+{: .no_toc }
+
+Associa utenti e gruppi ai ruoli, e stabilisci cosa può fare ogni ruolo.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'attributo roles
+
+La lista `roles` di primo livello di config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## Il ruolo default
+
+Ogni utente che ha effettuato l'accesso ha il ruolo `default`, quindi un modulo con `roles: [default]` è aperto a chiunque possa accedere. Non
+esiste un accesso anonimo: nessuno riceve questo ruolo senza accedere.
+
+Il ruolo non contiene gruppi né utenti, perché si applica già a tutti. Le sue `options` sono i valori predefiniti di tutti, come
+descritto in [Opzioni dei ruoli](#role-options) più sotto. `config.yaml` deve avere un ruolo `admin` e un ruolo `default`, e la
+pagina dei ruoli li mostra entrambi come **Obbligatorio**.
+
+`default` si chiamava `public` prima della 7.0.0, e il vecchio nome continua a funzionare:
+
+- **In un modulo**, `roles: [public]` corrisponde ancora a ogni utente, quindi i moduli nei tuoi repository non vanno modificati.
+- **In `config.yaml`**, un ruolo chiamato `public` viene rinominato `default` nel file quando la configurazione viene caricata. Cambia solo il
+  nome, prima si fa un backup della configurazione, e una configurazione tenuta in un repository ha poi una modifica da fare push.
+- **In un template ytt**, il template non viene riscritto: viene rinominata la configurazione che produce, e un avviso nel log ti chiede
+  di rinominare il ruolo anche nel template. La versione 8 rifiuta lì un ruolo `public`.
+
+Una configurazione con sia un ruolo `default` sia un ruolo `public` viene rifiutata, perché sono lo stesso ruolo.
+
+---
+
+## Oggetto Role
+
+Ogni voce della lista `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Opzioni dei ruoli
+
+Le `options` di un ruolo attivano o disattivano funzionalità per i suoi membri. Dalla 7.3.0 la pagina del ruolo le mostra in quattro gruppi,
+ogni opzione con una (i) che dice cosa concede, lo stesso testo mostrato dalla vista **Permessi** del profilo:
+
+| Opzione | Permette all'utente di | Predefinito |
+|---|---|---|
+| **Impostazioni** | | |
+| `showSettings` | Vedere e modificare ogni pagina delle impostazioni; il log del server e i backup hanno opzioni proprie | Solo admin |
+| `showAppearanceSettings` | Modificare le impostazioni dell'aspetto, senza le altre impostazioni (dalla 7.3.0) | Disattivato |
+| `showConnectionsSettings` | Gestire le impostazioni delle connessioni (credenziali, runner e altro), senza le altre impostazioni (dalla 7.3.0) | Disattivato |
+| `showLogs` | Vedere il log del server | Solo admin |
+| `showAuditLog` | Vedere il log di audit, senza le altre impostazioni (dalla 7.3.0) | Solo admin |
+| `allowBackupOps` | Fare il backup del database e ripristinarlo | Solo admin |
+| **Designer** | | |
+| `showDesigner` | Vedere e usare il designer | Solo admin |
+| `allowFormDesign` | Modificare la configurazione dei moduli nel designer: categorie, costanti e moduli. Senza, sola lettura (dalla 7.3.0) | Attivo |
+| `allowPlaybookDesign` | Modificare i playbook nel designer: salvarli, crearli, rimuoverli e farne push. Senza, sola lettura | Attivo |
+| `allowWorkflowDesign` | Modificare i workflow nel designer: salvarli, crearli, rimuoverli e farne push. Senza, sola lettura | Attivo |
+| `allowInventoryDesign` | Modificare gli inventari nel designer: salvarli, crearli, rimuoverli e farne push. Senza, sola lettura | Attivo |
+| `allowVarsFileDesign` | Modificare i file di variabili nel designer: salvarli, crearli, rimuoverli e farne push. Senza, sola lettura | Attivo |
+| **Job** | | |
+| `showJobs` | Vedere la pagina dei job | Attivo |
+| `showAllJobLogs` | Vedere i job di tutti gli utenti, non solo i propri | Solo admin |
+| `manageAllJobs` | Interrompere, eliminare e rilanciare i job di tutti gli utenti; eliminare e rilanciare richiedono anche le due opzioni qui sotto (dalla 7.3.0) | Solo admin |
+| `showExtravars` | Vedere le extravars di un modulo e di un job | Attivo |
+| `showDebugButtons` | Vedere i pulsanti di debug in un modulo | Attivo |
+| `showArtifacts` | Vedere gli artifact di un job: ciò che restituisce un job AWX, o ciò che un playbook ha raccolto con `set_stats` | Attivo |
+| `allowVerboseMode` | Eseguire i job in modalità verbose | Attivo |
+| `allowJobRelaunch` | Rilanciare un job con i dati del modulo di un'esecuzione precedente | Solo admin |
+| `allowJobDeletion` | Eliminare i job: i propri, o quelli di tutti gli utenti con `manageAllJobs`. Senza, la cronologia dei job resta intera (dalla 7.3.0) | Attivo |
+| `allowScheduledJobs` | Creare e gestire pianificazioni ricorrenti e una tantum, nella pagina **Pianificazioni** (vedi l'avviso qui sotto) | Solo admin |
+| `allowPlannedJobs` | Pianificare un job da eseguire una volta a un'ora stabilita (**Esegui più tardi**) | Attivo |
+| `allowStoredJobs` | Salvare i dati di un modulo e caricarli di nuovo in seguito | Attivo |
+| **Accesso e integrazioni** | | |
+| `allowLogin` | Accedere ad AnsibleForms | Attivo |
+| `allowChat` | Usare l'[assistente chat](../chat/), quando è abilitato | Attivo |
+| `allowMcp` | Usare il [server MCP](../mcp/) da un agente IA, quando è abilitato | L'`allowChat` del ruolo |
+| `allowFileUploads` | Caricare file tramite i campi file di un modulo (dalla 7.3.0) | Attivo |
+| `allowApiTokens` | Creare [token API](../profile/api-token.html) per gli script, fino alla durata massima consentita dall'istanza (dalla 7.3.0) | Disattivato |
+| `extendedTokenExpiration` | Creare anche token API che non scadono mai; richiede `allowApiTokens` | Disattivato |
+
+Alcune opzioni ne includono altre, e la pagina del ruolo mostra quelle incluse attive e in grigio:
+
+- **`showSettings`** concede anche `showAppearanceSettings`, `showConnectionsSettings` e `showAuditLog`.
+- **`manageAllJobs`** concede anche `showAllJobLogs`, perché agire sui job di tutti gli utenti significa vederli.
+- **Le opzioni di design** contano solo con `showDesigner`, e `extendedTokenExpiration` solo con `allowApiTokens`.
+
+Fino alla 7.2.0, `showAllJobLogs` permetteva anche a un utente di interrompere ed eliminare i job che mostrava; dalla 7.3.0 serve `manageAllJobs`.
+Un ruolo di prima della 7.3.0 con `extendedTokenExpiration` e senza `allowApiTokens` riceve `allowApiTokens`, così mantiene i suoi token.
+
+**Solo admin** significa attivo per gli utenti che hanno il ruolo `admin`, e disattivo per tutti gli altri. Quando un utente corrisponde a più ruoli,
+le opzioni si combinano così:
+
+- **Tra i ruoli dell'utente**, un'opzione è attiva solo quando tutti i ruoli che la impostano sono d'accordo: vince un `false` esplicito.
+- **Il ruolo `default`** completa le opzioni che nessuno degli altri ruoli dell'utente imposta, quindi può contenere i valori predefiniti per tutti.
+- **Le opzioni non impostate da nessuna parte** prendono il valore predefinito della tabella.
+
+`showExtraVars`, con la V maiuscola, è accettata come grafia alternativa di `showExtravars`; quando una delle due grafie è `false`,
+l'opzione è disattivata.
+
+{: .warning }
+> Considera `allowScheduledJobs` un'opzione di livello admin. Le pianificazioni non appartengono all'utente che le ha create: ogni utente con
+> l'opzione vede e può modificare tutte le pianificazioni. Una pianificazione inoltre viene eseguita con diritti di admin, per qualsiasi modulo, qualunque sia
+> l'accesso di chi l'ha creata. Concedila solo ai ruoli di cui ti fideresti come admin.
+
+{: .warning }
+> `allowLogin: false` sul ruolo `default` blocca fuori ogni utente i cui altri ruoli non impostano `allowLogin: true`, compresi
+> gli admin. Riconcedila ai ruoli che devono accedere prima di salvare.
diff --git a/i18n/it/_configure/credentials.md b/i18n/it/_configure/credentials.md
new file mode 100644
index 0000000..118f994
--- /dev/null
+++ b/i18n/it/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Credenziali
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Credenziali
+{: .no_toc }
+
+Salva gli accessi con cui si connettono moduli, repository, archivi di segreti e canali di notifica
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: aggiungi gli utenti, le password e i token con cui si connette AnsibleForms, conservati cifrati o letti da un archivio di segreti.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Tipi di credenziale](credentials/types.html) | Cosa contiene ogni tipo, e dove si può scegliere |
+| [La pagina delle credenziali](credentials/list.html) | La lista delle credenziali, e la finestra di dialogo che ne aggiunge una |
+| [La pagina di una credenziale](credentials/credential-page.html) | Le schede di una credenziale, e cosa la usa |
+
+---
+
+## Come funziona
+
+Una **credenziale** è un accesso con un nome, aggiunto in **Connessioni > Credenziali**. I moduli e gli altri oggetti di amministrazione
+la indicano con il suo nome, così la password stessa non compare mai in un modulo. Il suo utente e la sua password sono conservati nel
+database di AnsibleForms, cifrati con `ENCRYPTION_SECRET`, oppure letti da un [archivio di segreti](secret-stores/) ogni volta che
+la credenziale viene usata.
+
+---
+
+## Chi può modificare una credenziale
+
+Dalla 7.3.0 una credenziale da cui dipende una connessione o un accesso può essere aggiunta, modificata o eliminata solo da un admin:
+
+| Credenziali | Perché |
+|---|---|
+| Tipi di connessione: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` e `cyberark` | Un runner o un archivio di segreti ne prende l'indirizzo e il segreto |
+| Tipi di accesso: `oidc`, `entraid` e `ldap` | Un provider SSO o una directory LDAP fa accedere gli utenti con essa |
+| Qualsiasi credenziale indicata da un runner | Il runner accede con essa, e anche una modifica del runner stesso richiede un admin |
+
+Gli altri utenti con accesso alle credenziali le vedono in sola lettura. Un utente che potesse puntare una credenziale del genere verso un altro
+server riceverebbe ogni segreto inviato tramite essa, ed è per questo che la regola segue quella dei runner. Altre tre regole
+tengono questi utenti lontani dai segreti che altrimenti non potrebbero leggere:
+
+- **Indicare una credenziale protetta**: solo un admin può indicare una di queste credenziali altrove, per esempio in un repository,
+  in un canale di notifica o nelle impostazioni dell'assistente chat. Una credenziale che legge la sua password da un archivio di segreti è
+  protetta allo stesso modo, qualunque sia il suo tipo.
+- **Scegliere un archivio di segreti**: solo un admin può puntare una credenziale verso un [archivio di segreti](secret-stores/), o cambiare
+  l'archivio o il riferimento che legge; un altro utente può comunque rimandarli invariati, o svuotarli tutti.
+- **Spostare una credenziale**: quando un altro utente cambia dove accede una credenziale (il suo host, la porta, l'issuer, il tenant o
+  l'indirizzo del server) senza digitare di nuovo la password, la password salvata viene cancellata, e così il riferimento all'archivio
+  di segreti che legge, in modo che il vecchio segreto non vada mai alla nuova destinazione.
+
+---
+
+## Credenziali in uso
+
+Una credenziale ancora indicata da dei record non si può eliminare né rinominare, perché questi resterebbero a puntare verso il nulla.
+Il rifiuto indica quanti record la usano; la scheda **Usato da** della [sua pagina](credentials/credential-page.html) li elenca.
+Puntali prima verso un'altra credenziale, poi eliminala o rinominala.
diff --git a/i18n/it/_configure/credentials/credential-page.md b/i18n/it/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..c22ca61
--- /dev/null
+++ b/i18n/it/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "La pagina di una credenziale"
+parent: Credenziali
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# La pagina di una credenziale
+{: .no_toc }
+
+Le schede di una credenziale, e cosa la usa
+{: .fs-6 .fw-300 }
+
+La pagina di una credenziale mostra i passaggi della sua finestra di dialogo come schede, più cosa la usa:
+
+| Scheda | Cosa contiene |
+|---|---|
+| Dettagli | Nome e descrizione. |
+| Tipo | A cosa serve la credenziale. |
+| Accesso | Ogni campo del suo tipo, come nel passaggio **Accesso** della finestra di dialogo: l'utente, la password, e dove accede (host e porta, il database, il server mail, i server della directory, il tenant o l'issuer, l'indirizzo del server e il suo TLS). Per una credenziale CyberArk, l'AppID, il certificato client e la chiave. |
+| Archivio | Database o Archivio di segreti, e l'archivio e il riferimento. Non per CyberArk né per HashiCorp Vault. |
+| Usato da | Tutto ciò che indica questa credenziale: archivi di segreti, canali di notifica, repository, directory LDAP, provider SSO, runner, l'assistente chat, i moduli e i workflow del designer. Una riga lo apre. |
+
+La password si digita nella scheda **Accesso**, e una volta salvata non viene più mostrata: se la lasci vuota, resta quella salvata. Per una credenziale
+CyberArk, lascia vuota la chiave client per mantenere quella salvata. In alto a destra ci sono **Testa connessione** (solo credenziali database),
+**Elimina** e **Salva**.
+
+Dalla 7.3.0, **Elimina** e un nuovo nome vengono rifiutati finché **Usato da** elenca qualcosa, vedi [Credenziali in uso](../credentials.html#credentials-in-use).
+
+Una credenziale dichiarata nel [config seed](../seed/) è in sola lettura in questa pagina: modificala invece nel file del seed.
diff --git a/i18n/it/_configure/credentials/list.md b/i18n/it/_configure/credentials/list.md
new file mode 100644
index 0000000..ba607d3
--- /dev/null
+++ b/i18n/it/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: La pagina delle credenziali
+parent: Credenziali
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# La pagina delle credenziali
+{: .no_toc }
+
+La lista delle credenziali, e la finestra di dialogo che ne aggiunge una
+{: .fs-6 .fw-300 }
+
+La pagina in **Connessioni > Credenziali** elenca ogni credenziale con il suo **Nome**, **Tipo**, **Descrizione** e **Usato da**, il
+numero di record, moduli e workflow che la indicano (vedi [Credenziali in uso](../credentials.html#credentials-in-use)).
+
+**Aggiungi credenziale** apre una finestra di dialogo a passaggi:
+
+| Passaggio | Campi |
+|---|---|
+| Credenziale | Nome e descrizione, entrambi obbligatori. |
+| Tipo | Uno di 18 tipi, vedi sotto. |
+| Accesso | Con cosa accede il tipo e dove, vedi sotto. |
+| Archivio | Dove sono conservati l'utente e la password: **Database** (cifrati nel database di AnsibleForms) o **Archivio di segreti**, con l'archivio e il **Riferimento** al suo interno. Non per CyberArk né per HashiCorp Vault, con cui accede un archivio di segreti. |
+
+Il passaggio **Tipo** elenca i tipi per nome: AAP, API, Ascender, AWX, CyberArk, Database, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH, e Utente e password (vedi [Tipi di credenziale](types.html)).
+
+Il passaggio **Accesso** contiene ogni campo del tipo, indirizzo compreso; non c'è un passaggio separato per la connessione:
+
+| Tipi | Campi del passaggio Accesso |
+|---|---|
+| Tutti i tipi tranne CyberArk | La password, o ciò che ne fa le veci: la password di bind di LDAP, il client secret di Entra ID e Open ID, il token di HashiCorp Vault, il token RTE, il token API di Semaphore, Rundeck e Jenkins, un token o una password per AWX, AAP e Ascender |
+| Tutti i tipi tranne HashiCorp Vault, RTE, Semaphore e Rundeck | L'utente: l'AppID di CyberArk, il bind DN di LDAP, il client ID di Entra ID e Open ID, facoltativo per AWX, AAP e Ascender |
+| SSH, Database | **Host** e **Porta**; per un database anche il **Tipo database** e il **Database** |
+| SMTP | **Server mail** (obbligatorio), la sua **Porta** e **Usa TLS** |
+| LDAP | I **Server** della directory (obbligatori), la sua **Porta** e **Abilita TLS**; con TLS, **Ignora certificati**, il **Bundle CA** e un **Certificato client** |
+| Microsoft Entra ID | **Tenant ID** (obbligatorio) e **URI di reindirizzamento** |
+| Open ID | **Issuer** (obbligatorio) e **URI di reindirizzamento** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Server**, l'indirizzo a cui accede, obbligatorio, con **Salta la verifica del certificato** e il **Bundle CA** |
+| CyberArk | **Certificato client** e **Chiave client** |
+
+Una riga apre la pagina della credenziale. Il suo menu offre **Modifica**, **Testa connessione** (solo credenziali database) ed **Elimina**. La
+password si cambia nella pagina della credenziale, nella sua scheda **Accesso**.
diff --git a/i18n/it/_configure/credentials/types.md b/i18n/it/_configure/credentials/types.md
new file mode 100644
index 0000000..0c63ebb
--- /dev/null
+++ b/i18n/it/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Tipi di credenziale
+parent: Credenziali
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Tipi di credenziale
+{: .no_toc }
+
+Cosa contiene ogni tipo, e dove si può scegliere
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## I tipi
+
+Il tipo dice a cosa serve una credenziale. Decide quali campi chiede la finestra di dialogo, e dove si può scegliere:
+
+| Tipo | Cosa contiene | Usato da |
+|---|---|---|
+| Utente e password | Un utente e una password per qualsiasi accesso: una API REST con basic auth, un servizio e altro. Il predefinito | Playbook, tramite le `credentials` di un modulo o un campo credenziale; [espressioni REST](../expressions/credentials.html) |
+| SSH | Un utente e una password per SSH verso un server, con il suo host e la sua porta | Playbook, tramite le `credentials` di un modulo, `ansibleCredentials` o un campo credenziale, e l'accesso di un nodo di workflow |
+| Git | Un utente e una password o un token per repository git | [Repository](../repositories/authentication.html) |
+| API | Un utente e una password o un token per una API REST | [Espressioni REST](../expressions/credentials.html), il token di un bot Telegram, il bearer token di un webhook, la chiave API dell'assistente chat |
+| Database | Un accesso a un database, con il suo tipo, host, porta e nome del database | Query dei moduli (`dbConfig`) e `fnCredentials`; si può testare |
+| CyberArk | L'indirizzo del CyberArk Central Credential Provider (CCP) e il suo TLS, e l'AppID, il certificato client e la chiave con cui accede un archivio CyberArk | Un archivio di segreti [CyberArk](../secret-stores/cyberark.html) |
+| SMTP | Un server mail, la sua porta e il TLS, e il suo accesso (nessuno per un relay) | Un [canale di notifica](../notification-channels.html) mail |
+| LDAP | I server di una directory, la porta, il TLS e i certificati, e il suo bind DN e la password | Una [directory LDAP](../authentication/ldap.html) |
+| Microsoft Entra ID | La registrazione dell'app di un provider: il tenant ID, il client ID, il client secret e l'URI di reindirizzamento | Un [provider Entra ID](../authentication/entra-id.html) |
+| Open ID | Il client di un provider: l'issuer, il client ID, il client secret e l'URI di reindirizzamento | Un [provider OIDC](../authentication/oidc.html) |
+| RTE | Il token (`RTE_TOKEN`) e l'indirizzo di un RTE | Un [runner](../runners.html) RTE |
+| AWX, AAP, Ascender | Il token o l'accesso, e l'indirizzo, di quella piattaforma | Un runner di quel tipo |
+| Semaphore, Rundeck | Il token API e l'indirizzo di quel prodotto | Un runner di quel tipo |
+| Jenkins | Un utente, il suo token API e l'indirizzo di un Jenkins | Un runner Jenkins |
+| HashiCorp Vault | Il token e l'indirizzo con cui accede un archivio Vault | Un archivio di segreti [HashiCorp Vault](../secret-stores/hashicorp-vault.html) |
+
+Una credenziale database può essere di tipo MySQL, MSSQL, PostgreSQL, Oracle o MongoDB.
+
+Nell'API e nel [config seed](../seed/), i tipi sono `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` e `vault`. L'aggiornamento dalla 6
+assegna a ogni credenziale il tipo `userpass`, o `database` a una credenziale di database: un modulo la usa come nella 6. Cambiala in SSH per un
+accesso con cui si connette il playbook di un nodo di workflow, o in API per una API REST.
+
+---
+
+## Indirizzi nelle credenziali
+
+Dalla 7.3.0 un accesso che funziona su un server porta con sé quel server, così il record che lo usa indica solo la credenziale:
+
+| Record | Cosa è passato nella sua credenziale |
+|---|---|
+| Una directory LDAP | I suoi server, la porta, il TLS, i certificati e l'account di bind, in una credenziale `ldap` chiamata `<directory>-ldap` |
+| Un provider SSO | Il suo client ID e secret, il tenant o l'issuer, e l'URI di reindirizzamento, in una credenziale `entraid` o `oidc` chiamata `<provider>-sso` |
+| Un runner | Il suo indirizzo e il TLS, e il suo token o accesso, in una credenziale del suo tipo, `<runner>-token` o `<runner>-login` |
+| Un archivio di segreti | Il suo indirizzo e il TLS, e il suo token (`<store>-token`) o l'AppID e il certificato CyberArk (`<store>-appid`) |
+| Un canale mail | Il suo server, la porta e il TLS, nella sua credenziale `smtp`, o in una nuova chiamata `<channel>-smtp` |
+
+L'aggiornamento alla 7.3.0 fa questi spostamenti una sola volta. Un record che indicava già una credenziale la mantiene, e ne riceve una copia quando
+un altro record usava lo stesso accesso con un altro server. I record dichiarati nel [config seed](../seed/) restano come li ha il seed.
+Le credenziali delle connessioni e degli accessi possono essere modificate solo da un admin, vedi [Chi può modificare una credenziale](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/it/_configure/customization/configuration.md b/i18n/it/_configure/customization/configuration.md
new file mode 100644
index 0000000..78880de
--- /dev/null
+++ b/i18n/it/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Configurazione
+parent: Variabili d'ambiente
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Configurazione
+{: .no_toc }
+
+Il config seed, dove si conserva la configurazione, git e ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per decidere da dove arriva la configurazione: un config seed, il database, git o template ytt.
+
+---
+
+## Esempio
+
+Applica un config seed montato, controllalo ogni cinque minuti, e tieni `config.yaml` nel database. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Un seed non valido impedisce l'avvio del server. Vedi [Config seed](../seed/) per il formato del file.
+
+---
+
+## Da dove si legge config.yaml
+
+Le categorie, i ruoli e le costanti arrivano da `config.yaml` su disco o dalla sua copia nel database, scelti in questo ordine:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), quando è impostata, nell'ambiente o nella scheda
+   **Configurazione** della pagina delle impostazioni: `1` legge il database, `0` legge il file.
+2. Altrimenti, l'origine della configurazione salvata nel database (`file` o `database`), che le istanze configurate
+   prima della 6.3.0 sceglievano nella pagina delle impostazioni.
+3. Altrimenti, il file: il `config.yaml` del repository con **Usare per configurazione** attivo, altrimenti di un repository con
+   **Usare per moduli** attivo, altrimenti quello in [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Una `ENABLE_CONFIG_IN_DATABASE` impostata esplicitamente vince sempre, anche `0` su un `database` salvato. Viene letta ogni volta che
+la configurazione si carica, quindi una modifica si applica senza riavvio. La pagina **Stato** mostra l'origine in uso nella sua scheda **Informazioni**.
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/it/_configure/customization/features.md b/i18n/it/_configure/customization/features.md
new file mode 100644
index 0000000..ae481d0
--- /dev/null
+++ b/i18n/it/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Funzionalità
+parent: Variabili d'ambiente
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Funzionalità
+{: .no_toc }
+
+Il designer, MCP, la chat, la validazione all'avvio, la lista dei job, le metriche, l'API AWX e il log delle query
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per attivare o disattivare le parti facoltative dell'applicazione.
+
+---
+
+## Esempio
+
+Esponi il server MCP per gli agenti IA e applica le regole di validazione dei moduli a ogni avvio. Nel `.env` del progetto compose:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` ed `ENABLE_CHAT` si applicano senza riavvio: vengono lette a ogni richiesta, quindi puoi attivarle nella
+pagina delle impostazioni. Finché una è disattivata, il suo endpoint (`/api/v2/mcp` o `/api/v2/chat`) risponde `404`.
+
+Usa prima `LAUNCH_VALIDATION=log` per un po': registra ciò che `enforce` rifiuterebbe, senza rifiutarlo. Vedi [MCP](../mcp/)
+e [Registrare e applicare](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/it/_configure/customization/index.md b/i18n/it/_configure/customization/index.md
new file mode 100644
index 0000000..12a1d17
--- /dev/null
+++ b/i18n/it/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Variabili d'ambiente
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Variabili d'ambiente
+{: .no_toc }
+
+Configura AnsibleForms con le variabili d'ambiente
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori che installano AnsibleForms: le variabili d'ambiente che il server legge, raggruppate per argomento.
+
+AnsibleForms si regola con le variabili d'ambiente, che giri con Docker Compose, su Kubernetes o dai sorgenti.
+
+---
+
+## Da dove arrivano i valori
+
+Il server legge ogni variabile dalla prima di queste fonti che la imposta, quindi un valore più in alto nella lista vince sempre:
+
+1. **L'ambiente del processo**: `environment:` ed `env_file:` in docker-compose (il `.env` del progetto viene passato così),
+   `env` ed `envFrom` su Kubernetes, o la shell che avvia `node`.
+2. **`persistent/.env`**, il file che scrivono le pagine delle impostazioni (`data/.env` nel progetto docker-compose, un altro percorso con
+   `MANAGED_ENV_PATH`). Viene letto a ogni avvio, anche in produzione, e non sovrascrive mai una variabile già impostata.
+3. **`server/.env.<NODE_ENV>`**, per esempio `.env.development`. Viene letto solo quando `NODE_ENV` non è `production` (o con
+   `FORCE_DOTENV=1`), in pratica quando si esegue [dai sorgenti](../installation/from-source.html) in modalità sviluppo.
+4. **Il valore predefinito integrato**, mostrato nelle tabelle di ogni gruppo.
+
+Le pagine delle impostazioni, in **Impostazioni > Generale**, mostrano il valore in vigore e salvano le modifiche in `persistent/.env`. Molte variabili
+si applicano appena salvate; le altre vengono salvate ma richiedono un riavvio, e la pagina le elenca dopo il salvataggio. Una variabile impostata
+nell'ambiente del processo non si può modificare lì: la pagina la mostra come *Impostata nell'ambiente, non modificabile qui.*
+Alcune variabili, come `ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET`, non si possono mai modificare dalla pagina.
+
+Le variabili che legge un RTE, come `AF_ROLE`, `RTE_MODE`, `APP_URL` o `RTE_MAX_JOBS`, non compaiono affatto nelle pagine delle impostazioni:
+l'app non le usa, quindi impostale nell'ambiente in cui gira l'RTE. Le variabili `RTE_*` che legge l'app stessa,
+`RTE_QUEUE_MINUTES` e `RTE_FILES_MAX_MB`, sono l'eccezione e restano nelle pagine. Quattro variabili dell'RTE, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` e `RTE_DRAIN_SECONDS`, si possono invece impostare per singolo RTE nella sua pagina del runner, dove un valore vince sulla
+variabile (vedi [Le impostazioni di un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Con [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` le pagine mostrano solo i valori e il salvataggio viene rifiutato. Usala
+quando l'ambiente è dichiarato in un manifest, come descritto in [Modifica e audit](../seed/environment-and-audit.html).
+
+Il [config seed](../seed/) non imposta nessuna variabile d'ambiente. Dichiara oggetti che vengono salvati nel database, e i
+riferimenti `${ENV_VAR}` al suo interno vengono risolti dall'ambiente del server in esecuzione.
+
+Alcune variabili si leggono solo dall'ambiente e non sono nelle tabelle: `MANAGED_ENV_PATH` e `FORCE_DOTENV`, descritte
+sopra, e le variabili di proxy di sistema `HTTPS_PROXY` e `NO_PROXY` (lette anche in minuscolo). Un RTE in uscita contatta l'app tramite
+`HTTPS_PROXY`, e un RTE in entrata invia tramite esso la sua chiamata di registrazione, a meno che l'host dell'app non sia in `NO_PROXY` (nomi host,
+suffissi `.domain`, o `*` per ogni host).
+
+Le variabili contrassegnate con <span class="af-badge af-badge-secret">Segreto</span> contengono una password, un token o una chiave: tienile fuori dal controllo
+di versione, per esempio in un Secret di Kubernetes o in un file `.env` di cui non si fa commit.
+
+---
+
+## In questa sezione
+
+Le variabili sono raggruppate per argomento, con una pagina per gruppo:
+
+| Pagina | Cosa tratta |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Altre variabili
+
+Le seguenti variabili non sono ancora assegnate a un gruppo:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/it/_configure/customization/logging.md b/i18n/it/_configure/customization/logging.md
new file mode 100644
index 0000000..82bba41
--- /dev/null
+++ b/i18n/it/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Registrazione
+parent: Variabili d'ambiente
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Registrazione
+{: .no_toc }
+
+Livelli di log, file, syslog e colori della console
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per regolare quanto si registra, dove vanno i file di log, o per mostrare gli orari nel tuo fuso orario.
+
+---
+
+## Esempio
+
+Registra di più nei file che nella console, e mostra gli orari dei log e dei job nell'ora di Amsterdam.
+Nel `.env` del progetto compose:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+I server syslog non si configurano più qui: aggiungili in **Impostazioni > Connessioni > Syslog**, vedi [Log](../production/logs.html#syslog).
+Le variabili `LOG_SYSLOG_*` qui sotto sono deprecate dalla 7. Il primo avvio che trova `LOG_SYSLOG_HOST` impostata le importa
+una volta come server syslog `syslog`, che riceve il log del server, e da quel momento le ignora.
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/it/_configure/customization/paths.md b/i18n/it/_configure/customization/paths.md
new file mode 100644
index 0000000..4af6579
--- /dev/null
+++ b/i18n/it/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Percorsi
+parent: Variabili d'ambiente
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Percorsi
+{: .no_toc }
+
+Dove si trovano la configurazione, i moduli, i playbook, i caricamenti e i backup
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per tenere una parte dei dati su un altro volume, per esempio i backup e i caricamenti su uno storage più grande o più economico.
+
+---
+
+## Esempio
+
+Backup e file caricati su un volume separato, il resto dei dati nella solita cartella persistente. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Un nuovo percorso vale solo per i nuovi file: ciò che è già nella vecchia cartella non viene spostato, quindi copialo tu.
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/it/_configure/customization/retention.md b/i18n/it/_configure/customization/retention.md
new file mode 100644
index 0000000..a4f6887
--- /dev/null
+++ b/i18n/it/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Backup e conservazione
+parent: Variabili d'ambiente
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Backup e conservazione
+{: .no_toc }
+
+I comandi di backup, e per quanto tempo si conservano i backup, i job e i record di audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per controllare quanta cronologia conserva il database, e quanti backup restano su disco.
+
+---
+
+## Esempio
+
+Conserva i job terminati per 90 giorni e la traccia di audit per due anni. Nel `.env` del progetto compose:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Un'attività giornaliera rimuove i job terminati più vecchi di così alle 2:30 e le voci di audit alle 3:30. Un job in esecuzione, o uno in attesa di
+approvazione, non viene mai rimosso. Entrambe le variabili si applicano senza riavvio quando vengono modificate nella pagina delle impostazioni.
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/it/_configure/customization/security.md b/i18n/it/_configure/customization/security.md
new file mode 100644
index 0000000..a0ca401
--- /dev/null
+++ b/i18n/it/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Variabili di sicurezza
+parent: Variabili d'ambiente
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Variabili di sicurezza
+{: .no_toc }
+
+Token, cifratura, host REST in uscita, mascheramento e le vecchie impostazioni VAULT_*
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale per impostare i tuoi segreti per i token e la cifratura, e per limitare cosa possono chiamare e mostrare i moduli.
+
+---
+
+## Esempio
+
+I tuoi segreti, chiamate REST limitate a una sola API e a una rete interna, e una chiave mascherata in più. Nel `.env` del progetto compose:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Imposta `ENCRYPTION_SECRET` prima di salvare la prima credenziale. Dalla 7.3.0, impostarla o cambiarla ricifra ogni segreto
+salvato al successivo avvio, con `ENCRYPTION_SECRET_PREVIOUS` che indica la vecchia chiave quando era una tua, vedi
+[Cambiare il segreto di cifratura](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## Chiamate REST e jq
+
+Dalla 7.3.0 le funzioni helper REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) verificano il
+certificato dell'endpoint che chiamano, come ogni altra connessione; fino alla 7.2.0 non lo facevano mai. Si applicano loro tre impostazioni:
+
+| Variabile | Predefinito | Effetto |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` salta la verifica del certificato: solo per endpoint con un certificato autofirmato |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Quanto attende una risposta una chiamata REST prima di fallire per timeout |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Quanto può girare un filtro jq prima di essere fermato; l'output di jq è inoltre limitato a 64 MB |
+
+Tutte e tre hanno effetto al salvataggio, senza riavvio. Per un endpoint il cui certificato è firmato da una CA privata, lascia attiva la verifica
+e fornisci invece quella CA a Node.js: imposta `NODE_EXTRA_CA_CERTS` su un file PEM che la contiene nell'ambiente dell'app, poi riavvia l'app.
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/it/_configure/customization/server.md b/i18n/it/_configure/customization/server.md
new file mode 100644
index 0000000..0e68fd2
--- /dev/null
+++ b/i18n/it/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Server e database
+parent: Variabili d'ambiente
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Server e database
+{: .no_toc }
+
+Il server web, la connessione MySQL, l'account admin, e cosa esegue ogni processo (AF_ROLE e le variabili RTE_*)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Modificale quando l'applicazione gira dietro un reverse proxy, su un'altra porta, o con un database esterno al progetto compose.
+
+---
+
+## Esempio
+
+Dietro un reverse proxy che termina il TLS, sotto `/ansibleforms`, con un MySQL esterno. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Queste sostituiscono le righe `DB_*` e `PORT` che il file compose ha già lì, e che vincono sugli stessi nomi in `.env`. Rimuovi
+il servizio `mysqldb` e il `depends_on` che lo attende, e mappa la porta 8000 in `ports`. Il lato del proxy è descritto nella pagina
+[Reverse proxy](../production/reverse-proxy.html).
+
+---
+
+## Variabili
+
+Ogni variabile di questo gruppo, con il suo tipo, il valore predefinito e la descrizione:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/it/_configure/disclaimer.md b/i18n/it/_configure/disclaimer.md
new file mode 100644
index 0000000..25405f6
--- /dev/null
+++ b/i18n/it/_configure/disclaimer.md
@@ -0,0 +1,55 @@
+---
+layout: default
+title: Disclaimer
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Disclaimer
+{: .no_toc }
+
+Condizioni che ogni utente accetta una volta prima di usare l'app, registrate con chi ha accettato quale versione e quando
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: chiedi a ogni utente di accettare delle condizioni d'uso, in **Impostazioni > Accesso > Disclaimer**, con l'opzione di ruolo `showSettings`.
+
+Dalla 7.3.0 la pagina elenca ogni versione del disclaimer, e ogni versione si apre in una pagina propria con le sue accettazioni.
+Fino alla 7.2, la pagina aveva invece tre schede (**Generale**, **Versioni** e **Accettazioni**); l'aggiornamento conserva ogni versione.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Generale](disclaimer/general.html) | La lista delle versioni, come aggiungerne una, e come abilitare quella che gli utenti accettano |
+| [Versioni](disclaimer/versions.html) | La pagina di una versione, e come cambiarne il testo come correzione o di nuovo per tutti |
+| [Accettazioni](disclaimer/acceptances.html) | Chi ha accettato quale versione, e come chiederlo di nuovo a utenti scelti |
+
+
+---
+
+## Cosa vedono gli utenti
+
+Con una versione abilitata, ogni utente che accede la riceve in una finestra di dialogo prima di qualsiasi altra cosa, admin compresi:
+
+1. Leggono il suo titolo e il suo testo.
+2. Spuntano la casella, poi fanno clic su **Accetta**. **Rifiuta**, in rosso, invece li disconnette.
+
+Dalla 7.3.0 la pagina dietro la finestra di dialogo resta sfocata finché non rispondono.
+
+Un utente accetta ogni versione una sola volta: non gli viene richiesto al successivo accesso, ma solo quando arriva una nuova versione, quando
+un admin salva un testo modificato con [Chiedi di nuovo a tutti](disclaimer/versions.html#changing-the-text), o quando un admin usa
+[Richiedi di nuovo](disclaimer/acceptances.html#asking-users-again) sulla sua accettazione.
+
+Finché non accettano, l'API risponde a ogni chiamata della loro sessione con lo stato `403` e il codice `disclaimer_required`,
+tranne le chiamate sotto `/api/v2/disclaimer` e `/api/v2/profile`, e gli eventi live che il browser segue.
+A un [token API](profile/api-token.html) non viene mai chiesto, perché uno script non ha nessuno che faccia clic.
diff --git a/i18n/it/_configure/disclaimer/acceptances.md b/i18n/it/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..3a6c87b
--- /dev/null
+++ b/i18n/it/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Accettazioni
+parent: Disclaimer
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Accettazioni
+{: .no_toc }
+
+Chi ha accettato quale versione, e come chiederlo di nuovo a utenti scelti
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Chi ha accettato
+
+Ogni accettazione viene registrata per l'utente e la versione, e la scheda **Accettazioni** della pagina di una versione le elenca, la più recente per prima:
+
+| Colonna | Significato |
+|---|---|
+| **Utente** | Il nome utente |
+| **Accesso** | Come ha effettuato l'accesso: Locale, LDAP, Microsoft Entra ID o OpenID Connect |
+| **Accettato** | Quando |
+| **Indirizzo IP** | Da dove |
+| **Browser** | Il suo browser |
+
+---
+
+## Chiedere di nuovo agli utenti
+
+Dalla 7.3.0 si può chiedere a utenti scelti di accettare di nuovo una versione, senza chiederlo a tutti.
+
+**Richiedi di nuovo** nel menu di una riga, o sulle righe spuntate nella lista, cancella quelle accettazioni dopo una conferma: quegli utenti ricevono di nuovo il
+disclaimer alla loro richiesta successiva, senza dover accedere di nuovo. La lista si può anche esportare, come ogni tabella.
+
+Il [log di audit](../production/logs.html#audit-trail) registra anche ogni accettazione, ogni rifiuto e ogni modifica del disclaimer.
diff --git a/i18n/it/_configure/disclaimer/general.md b/i18n/it/_configure/disclaimer/general.md
new file mode 100644
index 0000000..da07eb4
--- /dev/null
+++ b/i18n/it/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Generale
+parent: Disclaimer
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Generale
+{: .no_toc }
+
+La lista delle versioni, come aggiungerne una, e come abilitare quella che gli utenti accettano
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La lista
+
+Dalla 7.3.0 **Impostazioni > Accesso > Disclaimer** è una lista delle versioni del disclaimer, una per ogni testo così come è stato accettato:
+
+| Colonna | Significato |
+|---|---|
+| **Abilitato** | Se questa è la versione che gli utenti accettano; al massimo una è abilitata |
+| **Versione** | Il suo numero, contato a partire da 1 |
+| **Titolo** | Il titolo della sua finestra di dialogo |
+| **Pubblicata da** | Chi l'ha aggiunta |
+| **Pubblicata** | Quando |
+| **Accettazioni** | Quanti utenti l'hanno accettata |
+
+Un clic su una riga, o **Modifica** nel menu della riga, apre la [pagina della versione](versions.html). Il menu ha anche **Abilita** o **Disabilita**, ed **Elimina**.
+
+---
+
+## Aggiungere una versione
+
+**Aggiungi avviso** apre una finestra di dialogo per una nuova versione, con il numero successivo, che non è abilitata finché non la abiliti tu:
+
+| Campo | Significato |
+|---|---|
+| **Titolo** | Il titolo della finestra di dialogo, come Condizioni d'uso |
+| **Testo** | Ciò che gli utenti accettano, al massimo 20000 caratteri. Testo semplice: gli a capo vengono mantenuti. |
+| **Casella** | Ciò che gli utenti spuntano prima di poter accettare, all'inizio "Ho letto e accetto queste condizioni." |
+
+Tutti e tre sono obbligatori. La versione abilitata fino a quel momento resta quella che gli utenti accettano, quindi un nuovo testo si può preparare in anticipo.
+
+---
+
+## Abilitare una versione
+
+**Abilita** nel menu di una riga, o l'interruttore **Abilitato** nella pagina della versione, rende quella versione quella che gli utenti accettano e disattiva
+le altre.
+
+Agli utenti che hanno già accettato quella versione non viene chiesto di nuovo, quindi una versione precedente si può riabilitare senza chiederlo a tutti.
+**Disabilita** sulla versione abilitata disattiva il disclaimer finché non si abilita di nuovo una versione; le versioni e le accettazioni restano.
+Eliminare una versione elimina anche le sue accettazioni, ed eliminare quella abilitata disattiva il disclaimer.
diff --git a/i18n/it/_configure/disclaimer/versions.md b/i18n/it/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..6025c77
--- /dev/null
+++ b/i18n/it/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versioni
+parent: Disclaimer
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versioni
+{: .no_toc }
+
+La pagina di una versione, e come cambiarne il testo come correzione o di nuovo per tutti
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La pagina di una versione
+
+Dalla 7.3.0 ogni versione ha una pagina propria, in `/settings/disclaimer/<version>`, con due schede:
+
+| Scheda | Cosa contiene |
+|---|---|
+| **Dettagli** | Il titolo, il testo e l'etichetta della casella, e l'interruttore **Abilitato**, che viene salvato subito |
+| **Accettazioni** | Chi ha accettato questa versione, vedi [Accettazioni](acceptances.html) |
+
+**Anteprima** mostra la finestra di dialogo come la vedranno gli utenti, ed **Elimina** rimuove la versione con le sue accettazioni. La casella di ricerca sopra le
+schede cerca in entrambe insieme: i campi corrispondenti in **Dettagli** e le righe corrispondenti in **Accettazioni**.
+
+---
+
+## Cambiare il testo
+
+**Salva** su un titolo, un testo o un'etichetta della casella modificati che gli utenti hanno già accettato chiede **Chiedere di nuovo a tutti?**:
+
+| Risposta | Cosa succede |
+|---|---|
+| **Chiedi di nuovo a tutti** | Le accettazioni di questa versione vengono cancellate, e ogni utente la accetta di nuovo alla sua richiesta successiva |
+| **Mantieni come correzione** | Il testo viene riscritto, per esempio per un refuso, e le accettazioni continuano a valere: a nessuno viene chiesto di nuovo |
+
+Una versione che nessuno ha ancora accettato si salva senza chiedere. Per conservare il testo accettato, [aggiungi una nuova versione](general.html#adding-a-version) e abilitala.
diff --git a/i18n/it/_configure/notification-channels.md b/i18n/it/_configure/notification-channels.md
new file mode 100644
index 0000000..ce4c96b
--- /dev/null
+++ b/i18n/it/_configure/notification-channels.md
@@ -0,0 +1,82 @@
+---
+layout: default
+title: Canali di notifica
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Canali di notifica
+{: .no_toc }
+
+Invia richieste di approvazione e notifiche dei job via mail, a Slack, Microsoft Teams, Telegram o a qualsiasi webhook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: aggiungi i server mail e i canali di chat a cui i moduli inviano le loro notifiche e approvazioni.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Mail](notification-channels/mail.html) | I server SMTP, quello predefinito, e il loro accesso |
+| [Slack e Microsoft Teams](notification-channels/slack-and-teams.html) | Un webhook di canale di Slack o Teams |
+| [Telegram](notification-channels/telegram.html) | Un bot che pubblica in una chat Telegram |
+| [Webhook](notification-channels/webhook.html) | Una richiesta JSON a qualsiasi endpoint HTTP |
+| [Usare i canali in un modulo](notification-channels/in-a-form.html) | Indicare i canali nelle notifiche e nelle approvazioni |
+| [Provare un canale](notification-channels/testing.html) | Invia prova, e cosa dimostra |
+
+
+---
+
+## Come funziona
+
+Un **canale di notifica** è un posto dove vanno le notifiche, aggiunto in **Connessioni > Notifiche**. Ogni canale ha
+uno di questi tipi:
+
+| Tipo | Cosa invia |
+|---|---|
+| Mail | Mail tramite un server SMTP: richieste di approvazione e notifiche dei job. |
+| Slack | Un messaggio in un canale Slack, tramite il suo webhook in entrata, con un pulsante per il job. |
+| Microsoft Teams | Una scheda in un canale Teams, tramite un webhook di Workflows, con un pulsante per il job. |
+| Telegram | Un messaggio di un bot in una chat Telegram, con un collegamento al job. |
+| Webhook | Una richiesta JSON a qualsiasi endpoint HTTP, costruita da un template. |
+
+Un modulo indica i suoi canali nelle sue [notifiche](forms/notifications.html) e nella sua [approvazione](forms/approval.html),
+con `channels:`. Una notifica che non si può inviare viene scritta nel log; non fa mai fallire il job né l'approvazione.
+
+---
+
+## La pagina delle notifiche
+
+La pagina in **Connessioni > Notifiche** elenca ogni canale con queste colonne:
+
+| Colonna | Significato |
+|---|---|
+| Abilitato | Se gli vengono inviate notifiche, vedi [Usare i canali in un modulo](notification-channels/in-a-form.html). |
+| Nome | Come lo indicano i moduli in `channels:`. |
+| Tipo | Mail, Slack, Microsoft Teams, Telegram o Webhook. Il canale mail predefinito mostra una pillola **Predefinito** dopo il suo tipo. |
+| Descrizione | A cosa serve il canale. |
+
+**Aggiungi canale di notifica** apre una finestra di dialogo: **Canale** (nome e descrizione), **Tipo**, poi i passaggi del tipo
+scelto. Il tipo si imposta quando il canale viene creato, e resta. Una riga apre la pagina del canale, con gli stessi passaggi come
+schede dopo **Dettagli**, e **Invia prova**, **Elimina** e **Salva** in alto a destra. Il menu della riga offre
+**Modifica**, **Attiva** o **Disattiva** (a seconda del caso), **Imposta come predefinito** (mail), **Invia prova** ed **Elimina**.
+
+La scheda **Dettagli** della pagina di un canale contiene l'interruttore **Abilitato**, che viene salvato subito, e per la mail l'interruttore
+**Predefinito**, che si salva con **Salva**.
+
+Un utente che apre queste pagine con `showConnectionsSettings` ma senza il ruolo admin non può scegliere una credenziale che solo
+un admin può indicare, vedi [Chi può modificare una credenziale](credentials.html#who-may-change-a-credential). Quando un utente del genere cambia
+dove invia un canale (l'url di un webhook o la sua verifica del certificato, l'indirizzo di una Bot API di Telegram), il canale perde la
+credenziale che indicava, a meno che non ne scelga una nella stessa modifica.
+
+Un canale dichiarato nel [config seed](seed/) è in sola lettura in questa pagina, e si può comunque provare.
diff --git a/i18n/it/_configure/notification-channels/in-a-form.md b/i18n/it/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..994ee0d
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Usare i canali in un modulo
+parent: Canali di notifica
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Usare i canali in un modulo
+{: .no_toc }
+
+Indicare i canali nelle notifiche e nelle approvazioni
+{: .fs-6 .fw-300 }
+
+I moduli indicano i canali con il loro nome, in `notifications` per lo stato e gli eventi dei job, e in `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- I canali di chat e webhook ricevono un messaggio breve (il modulo, il job, cosa è successo) con un collegamento al job; per
+  un'approvazione, la pagina del job è dove la si approva o la si rifiuta.
+- Un canale **mail** nella lista invia la solita mail ai `recipients` (gli indirizzi delle `notifications` di un'approvazione) tramite
+  quel server invece di quello predefinito.
+- Un nome che non esiste, o un canale di chat o webhook disattivato, viene saltato e segnalato nel log.
+- Un canale **mail** disattivato non viene saltato: la mail passa invece dal canale mail predefinito, e il
+  log lo segnala.
diff --git a/i18n/it/_configure/notification-channels/mail.md b/i18n/it/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..8dad9b1
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Mail
+parent: Canali di notifica
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Mail
+{: .no_toc }
+
+I server SMTP, quello predefinito, e il loro accesso
+{: .fs-6 .fw-300 }
+
+Un canale mail è un server SMTP. Puoi tenerne più di uno; quello contrassegnato come **Predefinito** è il server con cui l'app invia le sue
+mail quando un modulo non indica nessun canale mail. Il primo canale mail diventa il predefinito, e **Imposta come predefinito** lo sposta.
+
+| Passaggio | Campo | Significato |
+|---|---|---|
+| Credenziali | Credenziale | Obbligatoria. Una credenziale **smtp** di [Connessioni > Credenziali](../credentials.html): il server mail, la sua porta e il TLS, e l'accesso. Per un relay senza accesso, una credenziale smtp senza utente. |
+| Mittente | Mittente mail | L'indirizzo del mittente che vedono i destinatari. |
+
+L'interruttore **Predefinito** nella scheda **Dettagli** della pagina di un canale mail lo rende il predefinito, come fa **Imposta come predefinito**.
+Le impostazioni mail del config seed si usano finché nessun canale mail è il predefinito, o finché quello predefinito è disattivato.
diff --git a/i18n/it/_configure/notification-channels/slack-and-teams.md b/i18n/it/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..714fe53
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack e Microsoft Teams
+parent: Canali di notifica
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack e Microsoft Teams
+{: .no_toc }
+
+Un webhook di canale di Slack o Teams
+{: .fs-6 .fw-300 }
+
+I canali Slack e Teams richiedono solo l'indirizzo del webhook del canale:
+
+| Tipo | Indirizzo del webhook |
+|---|---|
+| Slack | Il webhook in entrata del canale (Slack app > Incoming Webhooks). |
+| Microsoft Teams | Il webhook di Workflows del canale ("post to a channel when a webhook request is received"). |
+
+L'indirizzo è il segreto che permette a chiunque di pubblicare nel canale: viene salvato cifrato e, una volta salvato, non viene più mostrato.
diff --git a/i18n/it/_configure/notification-channels/telegram.md b/i18n/it/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..c23126b
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Canali di notifica
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Un bot che pubblica in una chat Telegram
+{: .fs-6 .fw-300 }
+
+Un canale Telegram è un bot che pubblica in una chat. Il suo passaggio **Credenziali** contiene il **Token del bot**, il suo passaggio **Bot** il resto:
+
+| Campo | Significato |
+|---|---|
+| Token del bot | Una credenziale **api** di [Connessioni > Credenziali](../credentials.html) la cui password è il token del bot ottenuto da BotFather. |
+| Id della chat | La chat, il gruppo o il canale in cui pubblica il bot; un numero negativo per un gruppo o un canale. |
+| Indirizzo della Bot API | Un server Bot API tuo; vuoto per `api.telegram.org`. |
diff --git a/i18n/it/_configure/notification-channels/testing.md b/i18n/it/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..e3b823d
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Provare un canale
+parent: Canali di notifica
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Provare un canale
+{: .no_toc }
+
+Invia prova, e cosa dimostra
+{: .fs-6 .fw-300 }
+
+**Invia prova** invia una notifica di prova tramite il canale così come è salvato, quindi salva prima le tue modifiche. Funziona anche su un canale
+disattivato. Per un canale mail
+la finestra di dialogo chiede l'indirizzo a cui inviarla; gli altri pubblicano nel proprio canale. La finestra di dialogo mostra se ha funzionato,
+e il motivo quando non ha funzionato.
diff --git a/i18n/it/_configure/notification-channels/webhook.md b/i18n/it/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..5706703
--- /dev/null
+++ b/i18n/it/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Canali di notifica
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Una richiesta JSON a qualsiasi endpoint HTTP
+{: .fs-6 .fw-300 }
+
+Un canale webhook invia una richiesta JSON a qualsiasi endpoint HTTP. Il suo passaggio **Endpoint** dice dove e come, e il suo
+passaggio **Credenziali** contiene il **Token bearer**:
+
+| Campo | Significato |
+|---|---|
+| Url | L'indirizzo a cui viene inviata la richiesta. |
+| Metodo | `POST` (predefinito) o `PUT`. |
+| Token bearer | Una credenziale **api** di [Connessioni > Credenziali](../credentials.html) la cui password viene inviata come `Authorization: Bearer <password>`. Vuoto: nessun token. |
+| Verifica il certificato TLS | Attivo per impostazione predefinita; disattivalo solo per un endpoint con un certificato autofirmato. |
+
+{% raw %}
+Il suo passaggio **Contenuto** contiene le **Intestazioni**, intestazioni aggiuntive come oggetto JSON, per esempio `{ "X-Source": "ansibleforms" }`, e il
+**Contenuto**, il template JSON del corpo. Questi segnaposto vengono compilati:
+
+| Segnaposto | Valore |
+|---|---|
+| `{{title}}` | Il titolo della notifica |
+| `{{text}}` | Il suo testo |
+| `{{status}}` | Lo stato del job |
+| `{{event}}` | L'evento del job |
+| `{{jobId}}` | L'id del job |
+| `{{form}}` | Il nome del modulo |
+| `{{user}}` | L'utente che ha avviato il job |
+| `{{link}}` | Il collegamento al job |
+
+Un segnaposto che è un'intera stringa JSON (`"{{text}}"`) viene sostituito dal valore in JSON; dentro una stringa più lunga, il suo
+testo viene sottoposto a escape per JSON. Un segnaposto sconosciuto resta come è scritto. Un contenuto vuoto invia questo template:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/it/_configure/production/backups.md b/i18n/it/_configure/production/backups.md
new file mode 100644
index 0000000..8fe1d79
--- /dev/null
+++ b/i18n/it/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Backup
+parent: In produzione
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Backup
+{: .no_toc }
+
+Backup notturni, cosa contengono, ripristini, e cos'altro conservare
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Backup notturni
+
+AnsibleForms fa il backup di se stesso ogni notte a mezzanotte, nel fuso orario di [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(UTC per impostazione predefinita). Queste impostazioni lo controllano:
+
+| Variabile | Predefinito | Significato |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Dove si scrivono i backup, ognuno in una cartella con data e ora |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Quanti backup notturni si conservano, `0` li conserva tutti |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | Il comando che fa il dump del database |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | Il comando che riapplica un dump durante il ripristino |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Per quanto tempo possono girare il dump e il ripristino |
+
+Gli utenti con l'opzione di ruolo `allowBackupOps` possono anche fare un backup in qualsiasi momento nella pagina **Backup**. La conservazione
+rimuove solo i backup notturni, e contano solo i backup con un dump utilizzabile, così una serie di notti
+fallite non spinge mai fuori l'ultimo backup buono.
+
+Prima che un aggiornamento modifichi il database, il worker fa prima un backup normale, una volta per versione, chiamato *Before the upgrade to
+&lt;version&gt;*. Compare nella pagina **Backup** e la conservazione notturna non lo rimuove mai. Se non riesce (nessuno strumento di dump,
+`BACKUP_PATH` non scrivibile), l'aggiornamento si ferma e dice perché, così l'app non parte mai su un database aggiornato a metà.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` aggiorna senza backup.
+
+I comandi possono essere wrapper come `docker exec <container> mysqldump`, se la loro prima parola esiste in locale. Dalla 7.3.0 girano
+senza shell: le virgolette e `$NAME` dall'ambiente del comando funzionano, ma `;`, `|`, `&&`, `>` e `<` vengono rifiutati.
+
+---
+
+## Diritti sul database
+
+Il dump gira come [`DB_USER`](../customization/server.html#env_DB_USER), e non richiede più diritti di quelli di cui ha bisogno l'applicazione stessa:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Il dump si fa con `--no-tablespaces`, quindi il diritto `PROCESS` a livello di server non serve, e salta le tabelle
+che descrivono i processi in esecuzione (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). Il ripristino lo riapplica con lo stesso utente.
+La pagina **Stato** mostra un avviso nel suo controllo **Utente del database** quando l'utente ha diritti su ogni database, come li ha `root`.
+
+---
+
+## Cosa contiene un backup
+
+Ogni backup è una cartella sotto `BACKUP_PATH`, chiamata con la sua data e ora UTC (`YYYYMMDDHHmmss`), che contiene:
+
+| File | Contenuto |
+|------|---------|
+| `ansibleforms.sql` | Il dump del database `AnsibleForms`: utenti, gruppi, credenziali, job, impostazioni, la traccia di audit |
+| `config.yaml` | Il file in [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | La cartella in [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | Il file di ambiente che scrivono le pagine delle impostazioni, senza `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` e `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | La descrizione del backup |
+
+Un backup il cui dump non riesce viene rimosso di nuovo e registrato come errore. La pagina **Stato** avvisa quando non c'è nessun backup,
+quando il più recente ha più di due giorni, o quando non ha un dump utilizzabile, e verifica che lo strumento di dump esista.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) conserva invece i punti di ripristino del designer (60 giorni per impostazione predefinita).
+
+---
+
+## Ripristinare un backup
+
+Ripristina dalla [pagina **Backup**](../gui/administration.html#restore), con **Crea un nuovo backup prima del ripristino** spuntato. Un ripristino:
+
+* riapplica `ansibleforms.sql`, che sostituisce l'intero database; dalla 7.3.0 un backup di una versione più vecchia viene poi aggiornato
+  di nuovo, come all'avvio di una nuova versione, e una patch che non riesce viene segnalata
+* ricopia `config.yaml`, e sostituisce la cartella `forms/` con quella del backup: dalla 7.3.0 i moduli che non sono nel backup vengono
+  rimossi invece che conservati, i collegamenti e i permessi della cartella restano, e una copia non riuscita riporta la cartella allo stato precedente
+* **non** ripristina `managed.env`, perché descrive l'host da cui proviene il backup. Il pulsante **Ripristina ambiente**
+  lo rimette a richiesta, conserva il file attuale come `.env.bak`, e richiede un riavvio.
+
+Un backup senza un dump utilizzabile viene rifiutato; dopo un ripristino interrotto, correggi la causa e ripristina di nuovo.
+
+Su un nuovo host, imposta lo stesso `ENCRYPTION_SECRET` prima di ripristinare, altrimenti le credenziali salvate non si possono decifrare.
+
+---
+
+## Cos'altro mettere nel backup
+
+Il backup notturno copre il database, la configurazione e i moduli, ma nient'altro della cartella persistente:
+
+* **`ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET`** : mai in un backup, per scelta. Tienili nel tuo gestore di segreti;
+  senza il segreto di cifratura un dump del database è inutile per le credenziali.
+* **i backup stessi** : stanno sullo stesso volume dell'istanza. Copia `BACKUP_PATH` su un altro host.
+* **il resto della cartella persistente** : playbook, caricamenti, file di variabili, repository clonati, certificati e log.
+  Con il progetto docker-compose, fai il backup dell'intera cartella `data/`, che contiene anche la chiave SSH, le funzioni
+  personalizzate e i ruoli e le collection di Ansible.
+
+Il contenuto che arriva da git (repository, moduli in un repository) si può clonare di nuovo, quindi il suo backup conta meno.
diff --git a/i18n/it/_configure/production/index.md b/i18n/it/_configure/production/index.md
new file mode 100644
index 0000000..8a5ba34
--- /dev/null
+++ b/i18n/it/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: In produzione
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# In produzione
+{: .no_toc }
+
+Pubblica, fai il backup e monitora un'istanza da cui dipendono delle persone
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Prima di andare in produzione
+
+I valori predefiniti mettono in funzione un'istanza in fretta, ma molti di essi servono solo per una prima occhiata. AnsibleForms
+registra un avviso `[SECURITY]` all'avvio quando `ENCRYPTION_SECRET` o `ACCESS_TOKEN_SECRET` non sono impostate, e la
+pagina **Stato** riporta i backup, le impostazioni di conservazione e il sanitizer delle espressioni.
+
+---
+
+## Checklist per la produzione
+
+Passa in rassegna questi punti una volta prima che gli utenti dipendano dall'istanza, e di nuovo dopo un aggiornamento importante:
+
+| Punto | Cosa fare | Dettagli |
+|------|------------|---------|
+| Password dell'admin | Cambia la password dell'account admin locale | [Hardening](../security/hardening.html#the-admin-account) |
+| Segreto di cifratura | Imposta [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) prima di salvare qualsiasi credenziale | [Segreti e cifratura](../security/secrets.html#the-two-master-secrets) |
+| Segreto dei token | Imposta [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET), così le sessioni sopravvivono a un riavvio | [Segreti e cifratura](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Termina il TLS con il tuo certificato, non con quello di esempio | [HTTPS](../security/https.html) |
+| Reverse proxy | Pubblica l'istanza dietro un proxy, se vuoi sotto [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse proxy](reverse-proxy.html) |
+| Endpoint dello schema | Imposta [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) a `0` una volta che lo schema esiste | [Hardening](../security/hardening.html#the-database) |
+| Chiamate in uscita | Limita le espressioni REST con [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Hardening](../security/hardening.html#expressions-and-outbound-calls) |
+| Funzionalità facoltative | Lascia MCP e l'assistente chat disattivati se non li usi | [Hardening](../security/hardening.html#optional-features) |
+| Backup | Verifica che il backup notturno funzioni, e copialo fuori dall'host | [Backup](backups.html) |
+| Conservazione | Decidi per quanto tempo conservare i job e le voci di audit | [Log](logs.html#retention) |
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina propria; la messa in sicurezza dell'istanza è trattata in [Sicurezza](../security/):
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Reverse proxy](reverse-proxy.html) | Pubblicare AnsibleForms dietro Nginx, Traefik o Apache, alla radice o sotto un sottopercorso |
+| [Backup](backups.html) | Backup notturni, cosa contengono, ripristini, e cos'altro conservare |
+| [Log](logs.html) | File di log, syslog, la traccia di audit, e la conservazione dei job e delle voci di audit |
+| [Scalabilità](scaling.html) | Più nodi dell'app con un worker; l'RTE ha una sezione propria, [Ambienti di esecuzione](../rte/) |
+| [Monitoraggio](monitoring.html) | Probe di salute, metriche Prometheus e la pagina Stato |
diff --git a/i18n/it/_configure/production/logs.md b/i18n/it/_configure/production/logs.md
new file mode 100644
index 0000000..1ad030c
--- /dev/null
+++ b/i18n/it/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Log
+parent: In produzione
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Log
+{: .no_toc }
+
+File di log, syslog, la traccia di audit, e per quanto tempo si conservano i job e le voci di audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## File di log
+
+AnsibleForms scrive due log a rotazione giornaliera in [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), comprime i giorni precedenti e li conserva per [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+(30 per impostazione predefinita, `0` conserva ogni file; una modifica nella pagina delle impostazioni si applica subito):
+
+* `ansibleforms.<date>.log` : tutto ciò che è a livello [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) o superiore
+* `ansibleforms.errors.<date>.log` : solo gli errori
+
+La console, letta con `docker logs` o `kubectl logs`, ha un proprio livello,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Entrambi sono `notice` per impostazione predefinita, il che va bene per la
+produzione; usa `info` o `debug` solo durante la risoluzione dei problemi, e lascia
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) disattivata. I livelli si possono cambiare nelle
+pagine delle impostazioni senza riavvio, e la pagina **Log del server** mostra il log agli utenti con l'opzione `showLogs`.
+
+---
+
+## Righe JSON
+
+Per un raccoglitore di log come Loki, ELK o Splunk, imposta [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) a `json`. Ogni
+riga, nella console e nei file, è allora un oggetto JSON invece di `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Campo | Contenuto |
+|-------|---------|
+| `time` | L'ora, in ISO 8601 UTC |
+| `level` | Il livello di log |
+| `message` | Il messaggio |
+| `requestId` | La richiesta a cui appartiene la riga, quando è stata scritta mentre se ne serviva una |
+| `role` | Il ruolo del processo, [`AF_ROLE`](scaling.html), o `all` quando non è impostato |
+| `host` | Il nome host della macchina o del container in cui gira il processo |
+
+Ogni richiesta riceve un id: l'intestazione `X-Request-Id` inviata da un reverse proxy, o uno nuovo. Viene restituito nell'intestazione
+`X-Request-Id` della risposta e riportato da ogni riga scritta mentre la richiesta viene servita (come `[req <id>]` nelle righe di testo),
+così una richiesta si può seguire nel log e confrontare con quelle del proxy. Una modifica nella pagina delle impostazioni si applica subito.
+
+---
+
+## Syslog
+
+I server syslog si gestiscono in **Impostazioni > Connessioni > Syslog**, così un server syslog o un SIEM riceve il log man mano che viene scritto.
+Puoi aggiungere più server, e ognuno ha le sue impostazioni:
+
+| Impostazione | Cosa fa |
+|---------|--------------|
+| Abilitato | Solo i server abilitati ricevono qualcosa, così un server si può mettere in pausa senza eliminarlo; anche **Abilita** e **Disabilita** nel suo menu di riga lo commutano |
+| Protocollo | `udp4` (predefinito), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` o `unix-connect` |
+| Host e porta | Il server a cui inviare, porta `514` per impostazione predefinita; un protocollo `unix` richiede invece il percorso di un socket |
+| Riceve | Il log del server, le voci di audit, o entrambi (il predefinito per un nuovo server) |
+| Livello | Il livello più basso del log del server che riceve, `info` per impostazione predefinita; le voci di audit vengono sempre inviate |
+| Tipo | `BSD` (RFC 3164, il predefinito) o `RFC 5424` |
+
+Una modifica si applica su ogni nodo senza riavvio, e la pagina del server ha un pulsante che gli invia un messaggio di prova.
+Un server non raggiungibile non ferma mai l'applicazione: l'errore viene scritto nella console.
+
+Dalla 7.3.0 i server syslog richiedono i diritti completi sulle impostazioni, l'opzione di ruolo [`showSettings`](../config/roles.html#role-options):
+l'accesso alle sole impostazioni delle connessioni non basta, perché un server syslog riceve il log del server e le voci di audit.
+
+Le variabili `LOG_SYSLOG_*` delle versioni precedenti sono deprecate dalla 7. Il primo avvio che trova
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) impostata le importa una volta come server `syslog`,
+che riceve il log del server come prima, e da quel momento le ignora. Rimuovile dall'ambiente dopo quel primo
+avvio, e gestisci il server nella pagina delle impostazioni.
+
+---
+
+## Traccia di audit
+
+La pagina **Registro di audit** (in **Impostazioni > Log**) registra chi ha cambiato cosa, una domanda a cui i file di log non rispondono bene.
+Registra:
+
+* ogni modifica fatta tramite l'API (`POST`, `PUT`, `PATCH`, `DELETE`), compresi i tentativi rifiutati con 401 o 403
+* gli accessi, con il nome utente che è stato provato
+* gli eventi dell'applicazione stessa, come i backup notturni, i backup rimossi, i job eliminati e le applicazioni del config seed
+
+Ogni voce ha la sua ora, l'attore (un utente, o l'applicazione stessa per le sue attività), l'indirizzo IP del client,
+l'azione, il suo obiettivo e il suo esito: `success`, `failure` o `denied`. La pagina filtra per attore, azione ed
+esito, e gli utenti con l'opzione di ruolo `showSettings` possono aprirla.
+
+L'indirizzo IP è quello che vede AnsibleForms, cioè quello del proxy quando gira dietro un proxy. Imposta
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) con il numero o gli indirizzi dei tuoi proxy, e AnsibleForms
+registra invece l'indirizzo del client che il proxy riporta in `X-Forwarded-For`; vedi [Reverse proxy](reverse-proxy.html).
+
+Per tenere la traccia di audit fuori dall'istanza, per un SIEM, aggiungi un server syslog che riceve le voci di audit (vedi
+[Syslog](#syslog)). Ogni voce viene inviata quando avviene, come una riga `audit {...}` con la voce in JSON, qualunque sia il
+livello del server. La copia syslog non viene rimossa dalla conservazione qui sotto, né sostituita da un ripristino del database.
+
+---
+
+## Conservazione
+
+Due attività giornaliere con un'impostazione evitano che il database cresca senza limiti:
+
+| Variabile | Predefinito | Esecuzione | Rimuove |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Le voci di audit più vecchie di così |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (conserva tutto) | 2:30 | I job terminati più vecchi di così, con il loro output |
+
+`0` conserva tutto per entrambe. Altre due attività giornaliere non hanno un'impostazione: alle 3:00 vengono rimossi i refresh token salvati più vecchi di 30 giorni e
+le revoche di token scadute, e alle 4:00 i [job salvati](../jobs/stored-jobs.html) la cui scadenza è passata.
+Gli orari sono nel fuso orario di [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), e le esegue il worker.
+
+L'output dei job è di solito la tabella che cresce più in fretta: la pagina **Stato** ne riporta la dimensione
+e avvisa quando supera 1 GB senza una conservazione impostata. I job in esecuzione e quelli in attesa di approvazione non vengono mai rimossi.
+Scegli una conservazione dei job adatta ai tuoi requisiti di audit, e conserva la traccia di audit almeno altrettanto a lungo.
diff --git a/i18n/it/_configure/production/monitoring.md b/i18n/it/_configure/production/monitoring.md
new file mode 100644
index 0000000..b7ed9b4
--- /dev/null
+++ b/i18n/it/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Monitoraggio
+parent: In produzione
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Monitoraggio
+{: .no_toc }
+
+Probe di salute per un load balancer o Kubernetes, metriche Prometheus, e la pagina Stato
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Probe di salute
+
+Due endpoint dicono a un load balancer, a un healthcheck di container o a Kubernetes se un processo può ricevere traffico.
+Nessuno dei due richiede un accesso, e nessuno dei due restituisce nulla sulla configurazione:
+
+| Endpoint | Risponde | Usalo per |
+|----------|---------|------------|
+| `/api/v2/live` | `200` con `{"status":"live"}` finché il processo gira | Una liveness probe: riavvia il processo quando smette di rispondere |
+| `/api/v2/ready` | `200` con `{"status":"ready"}`, o `503` con `{"status":"not ready","reason":"..."}` | Una readiness probe: invia traffico solo ai processi pronti |
+
+Un processo è pronto quando valgono tutte queste condizioni:
+
+* non si sta arrestando (`stopping`)
+* il database risponde (`database unreachable`)
+* lo schema esiste (`schema not provisioned`) ed è completo, con ogni tabella, colonna e indice di questa versione
+  (`schema not upgraded`); quest'ultimo controllo resta in cache per 30 secondi, così una probe ogni pochi secondi resta economica
+
+Sotto un [`BASE_URL`](../customization/server.html#env_BASE_URL) i percorsi iniziano con esso, per esempio
+`/ansibleforms/api/v2/ready`. Un ambiente di esecuzione (RTE) risponde alle stesse probe su `/live` e `/ready`, senza il
+controllo di completezza dello schema; non è pronto mentre smaltisce i suoi job all'arresto, così non gli viene inviato nessun nuovo job. Un RTE in uscita
+inoltre non è pronto (`not connected to the app`) finché il suo socket verso l'app non è aperto.
+Un processo avviato con `AF_ROLE=worker` non ha interfaccia web: risponde solo a `/api/v2/version` e `/health` per l'healthcheck
+del suo container. Vedi [Scalabilità](scaling.html) per i ruoli.
+
+---
+
+## Metriche Prometheus
+
+Imposta [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) con una stringa casuale lunga per esporre le metriche Prometheus.
+Un processo che serve l'applicazione web risponde su `/api/v2/metrics`, un RTE su `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Senza `METRICS_TOKEN` gli endpoint rispondono `404`, come se non esistessero, e una richiesta senza l'intestazione
+`Authorization: Bearer <token>` corretta riceve `401`. Ogni processo riporta i propri valori, quindi raccoglili da ciascuno:
+
+| Metrica | Cosa misura |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | Il processo: CPU, memoria, ritardo dell'event loop, garbage collection |
+| `af_http_requests_total{route,method,status}` | Le richieste servite |
+| `af_http_request_duration_seconds{route}` | Quanto tempo hanno richiesto |
+| `af_jobs{status}` | I job in esecuzione (`running`) o in attesa di approvazione (`approve`) in questo momento |
+| `af_jobs_ended_24h{status}` | I job terminati nelle ultime 24 ore, per stato |
+| `af_nodes{role,alive}` | I processi registrati nel database, per ruolo, vivi o no |
+| `af_login_failures_total`, `af_login_lockouts_total` | Accessi non riusciti e blocchi di account |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Su un RTE: i playbook che esegue ora, e quanti ne può eseguire insieme |
+| `af_rte_socket_connected` | Su un RTE in modalità socket: `1` finché il suo socket verso l'app è aperto, `0` quando non lo è |
+
+I valori dei job e dei nodi si leggono dal database a ogni raccolta. Quando il database non risponde vengono lasciati
+fuori, e la raccolta riesce comunque con le altre metriche.
+
+---
+
+## La pagina Stato
+
+La pagina **Stato**, in **Impostazioni > Sistema**, mostra agli utenti con l'opzione di ruolo `showSettings` come sta l'istanza.
+Si limita a leggere, quindi aggiornarla non invia mai mail né lancia job. Ha due schede, e il numero di problemi compare sull'etichetta della scheda **Controlli**.
+
+### Controlli
+
+Ogni controllo è verde (sano), ambra (richiede attenzione) o rosso (un problema), con i suoi dettagli quando si espande la riga:
+
+| Controllo | Cosa guarda |
+|-------|------------------|
+| Connessione al database | Il database risponde |
+| Utente del database | Ambra quando l'utente ha diritti su ogni database, come `root`, invece che solo su `AnsibleForms.*` |
+| Schema del database | Ogni tabella, colonna e indice di questa versione esiste, e quale patch non è riuscita quando non è così |
+| Pianificatore | Un worker esegue le attività di sistema, e nessuna di esse ha smesso di essere pianificata |
+| Nodi | I processi nel database, ambra quando eseguono versioni diverse |
+| Job | I job in esecuzione e quelli in attesa di approvazione, ambra quando un job gira da più di 24 ore |
+| Strumenti di backup | Il comando di dump di [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) esiste, e la sua versione |
+| Ultimo backup | Ambra quando non ce n'è nessuno o il più recente ha più di due giorni, rosso quando non ha un dump utilizzabile |
+| Blocco del designer | Chi detiene il blocco del designer, ambra quando è detenuto da più di 8 ore |
+| Repository | Rosso quando un repository non è riuscito o non ha un working tree su disco |
+| Seed di configurazione | Il file del [config seed](../seed/) è leggibile e si analizza, e il suo ultimo ricaricamento ha funzionato |
+| Archivi di segreti | Ogni archivio di segreti risponde, ambra quando il token di un HashiCorp Vault scade presto |
+| Runner | Ogni runner risponde, ambra quando non ce n'è nessuno o non c'è un RTE predefinito |
+| Espressioni server | Ambra quando [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) è `legacy` |
+| Segreti | Ambra quando `ENCRYPTION_SECRET` è il valore predefinito pubblico o `ACCESS_TOKEN_SECRET` non è impostato |
+| LDAP | Il server LDAP è raggiungibile e il suo certificato TLS è valido, senza accedervi |
+| Archiviazione job | La dimensione delle tabelle dei job, ambra oltre 1 GB quando non è impostata nessuna conservazione dei job |
+| Cartelle scrivibili | Ogni cartella configurata è scrivibile |
+| Spazio su disco | Il disco che contiene i backup, ambra dall'85% di uso e rosso dal 95% |
+
+### Informazioni
+
+Dati sull'istanza senza un verdetto, le prime cose che chiede una conversazione di supporto: la versione di
+AnsibleForms, l'URL di base, la versione e l'host del database, l'origine della configurazione, il config seed, le impostazioni
+di conservazione, i metodi di autenticazione, il server del [canale mail](../notification-channels.html) attivo, il livello
+e il percorso del log, l'uptime, il fuso orario, la versione di Node.js e la piattaforma.
+
+La pagina legge `/api/v2/health`, che richiede un utente che ha effettuato l'accesso con `showSettings`. Per un sistema di monitoraggio, usa invece le
+probe e le metriche descritte sopra.
diff --git a/i18n/it/_configure/production/reverse-proxy.md b/i18n/it/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..2421264
--- /dev/null
+++ b/i18n/it/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse proxy
+parent: In produzione
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse proxy
+{: .no_toc }
+
+Pubblica AnsibleForms dietro Nginx, Traefik o Apache, alla radice o sotto un sottopercorso
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quando usarne uno
+
+AnsibleForms serve l'interfaccia, l'API REST e Swagger su una sola porta; un reverse proxy davanti ti permette di:
+
+* servirlo sulla porta 443 con un certificato gestito dai tuoi strumenti esistenti (ACME, una CA aziendale)
+* condividere un nome host con altre applicazioni, pubblicando AnsibleForms sotto un sottopercorso
+* tenere la porta dell'applicazione e il database fuori dalla rete pubblica
+
+Un proxy è facoltativo: l'applicazione può servire HTTPS da sola, vedi [HTTPS](../security/https.html).
+
+---
+
+## Le impostazioni che contano
+
+Solo poche impostazioni influiscono sul comportamento di AnsibleForms dietro un proxy:
+
+| Impostazione | Dietro un proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | La porta verso cui inoltra il proxy, `8000` per impostazione predefinita. Il progetto docker-compose la imposta a `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` quando il proxy termina il TLS e raggiunge l'applicazione su una rete privata, `1` per cifrare anche quel tratto. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | Il sottopercorso, per esempio `/ansibleforms`. Lascialo a `/` quando l'applicazione ha un nome host proprio. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Quali proxy possono riportare l'indirizzo del client in `X-Forwarded-For`, di solito `1`. Vedi [Indirizzi dei client](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | La richiesta JSON più grande che l'applicazione accetta, 50 MB per impostazione predefinita. Il proxy deve consentire almeno questo. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | Il file più grande che accetta un campo di caricamento di un modulo, 10 GB per impostazione predefinita. Anche il proxy deve consentirlo, altrimenti i caricamenti falliscono lì. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | L'insieme più grande di intestazioni di richiesta che l'applicazione accetta, 16 KB per impostazione predefinita, dalla 7.1.0. Vedi [Dimensione delle intestazioni della richiesta](#request-header-size). |
+| **URL radice pubblica** | In **Sistema > Generale**, nella scheda **Server**: l'indirizzo che raggiungono gli utenti, sottopercorso compreso. Costruisce i collegamenti nelle mail di notifica, nei messaggi dei canali e nelle richieste di approvazione. |
+
+Per Entra ID o OIDC, registra l'indirizzo pubblico come URI di reindirizzamento, con il sottopercorso di `BASE_URL` se impostato.
+
+---
+
+## Servire sotto un sottopercorso
+
+`BASE_URL` monta l'intera applicazione sotto il sottopercorso; il proxy deve inoltrare il percorso **invariato**.
+Con `BASE_URL=/ansibleforms`:
+
+* l'interfaccia, `/api/v2/...` e l'interfaccia Swagger sono tutte servite sotto `/ansibleforms/`
+* il `<base href>` dell'interfaccia viene riscritto all'avvio, così le risorse e le chiamate API si risolvono sotto il sottopercorso
+* una richiesta per `/` o per `/ansibleforms` (senza slash finale) viene reindirizzata a `/ansibleforms/`
+
+Mantieni il prefisso: niente `StripPrefix` in Traefik, nessun URI su `proxy_pass` in Nginx, perché l'applicazione se lo aspetta.
+
+La pagina **Stato** mostra l'URL di base in vigore.
+
+---
+
+## Timeout, caricamenti e output in tempo reale
+
+La pagina dei job e i contatori dei job vengono a sapere delle modifiche tramite un unico flusso di lunga durata di server-sent events,
+[`/api/v2/events`](../api/events.html), tenuto aperto per ogni browser. Il flusso invia intestazioni che disattivano il buffering del proxy
+(`X-Accel-Buffering: no`) e una riga di keep-alive ogni 15 secondi, così il solito timeout di lettura di 60 secondi lo tiene aperto;
+quando un proxy lo chiude comunque, il browser si riconnette da solo. L'output sotto un modulo, subito dopo un avvio, viene invece
+letto ogni due secondi. L'avvio di un job ritorna non appena il job viene creato, così un playbook lungo non tiene
+aperta una richiesta.
+
+Le richieste che possono durare a lungo sono:
+
+* **backup e ripristino** dalla pagina **Backup**, che attendono la fine del comando di dump o di ripristino, fino a
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (3600 per impostazione predefinita)
+* **caricamenti grandi** tramite un campo file, che trasmettono l'intero file in una sola richiesta
+* **messaggi della chat**, quando l'[assistente chat](../chat/) è abilitato, che attendono la risposta del provider del modello
+
+I proxy spesso vanno in timeout dopo 60 secondi e limitano il corpo delle richieste (Nginx accetta 1 MB per impostazione predefinita). Aumenta entrambi per
+le route di AnsibleForms, come negli esempi qui sotto.
+
+---
+
+## WebSocket dei runner
+
+Dalla 7.3.0 un [Runner in uscita](../rte/modes.html#outbound) contatta l'applicazione e tiene aperto un WebSocket su
+`<BASE_URL>/api/v2/rte/socket`. Il proxy deve far passare l'upgrade, altrimenti il Runner non si connette mai e continua a riprovare:
+
+| Proxy | Di cosa ha bisogno il WebSocket |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` e le intestazioni `Upgrade` e `Connection`, che Nginx non inoltra per impostazione predefinita |
+| Traefik | Niente: i WebSocket passano così come sono |
+| Apache | `upgrade=websocket` sulla riga `ProxyPass` (2.4.47 e successive), o `mod_proxy_wstunnel` prima di quella versione |
+
+Entrambi i lati inviano un ping ogni 20 secondi, così il solito timeout di lettura di 60 secondi tiene aperto un socket inattivo.
+
+---
+
+## Dimensione delle intestazioni della richiesta
+
+Ogni richiesta porta il token di accesso nella sua intestazione `Authorization`, accanto ai cookie e alle intestazioni aggiunte dal proxy.
+Sia il proxy sia l'applicazione limitano la dimensione delle intestazioni della richiesta, e rifiutano una richiesta oltre il limite prima che
+AnsibleForms la veda, quindi nulla arriva al log del server. I valori predefiniti:
+
+| Componente | Limite | Predefinito | Rifiutata con |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), tutte le intestazioni insieme | 16384 byte | 431 |
+| Nginx | `large_client_header_buffers`, per campo di intestazione | `4 8k`: 8 KB per campo | 400 |
+| Traefik | `http.maxHeaderBytes` dell'entry point, tutte le intestazioni insieme | 1 MB | 431 |
+| HAProxy | `tune.bufsize` nella sezione `global`, l'intero blocco di intestazioni, meno la riserva `tune.maxrewrite` (1024 byte) | 16384 byte: 15360 byte di intestazioni | 400 |
+| Apache | `LimitRequestFieldSize`, per campo di intestazione | 8190 byte | 400 |
+
+Fino alla 7.0.3 il token di accesso conteneva ogni gruppo di un utente single sign-on, e poteva superare questi limiti, vedi
+[Moduli e job vuoti dopo un single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Dalla 7.1.0 il token resta piccolo, e i valori predefiniti bastano. Quando qualcos'altro rende grandi le intestazioni, come
+i cookie di altre applicazioni sullo stesso dominio o un gateway single sign-on davanti, aumenta i limiti insieme:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536`, o prima della 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; entrambe vengono
+  lette all'avvio, quindi riavvia l'applicazione dopo una modifica
+* Nginx: `large_client_header_buffers 4 32k;` nel blocco `http` o `server`
+* HAProxy: `tune.bufsize 65536` nella sezione `global`; ogni flusso riceve un buffer di quella dimensione, quindi HAProxy consiglia
+  di ridurre il `maxconn` globale dello stesso fattore, e HTTP/2 richiede almeno il valore predefinito 16384
+* Apache: `LimitRequestFieldSize 32768` nella configurazione del server o nel virtual host
+
+---
+
+## Indirizzi dei client
+
+Dietro un proxy ogni connessione arriva dal proxy. Senza [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY),
+la traccia di audit registra l'indirizzo del proxy per ogni azione, e i
+[limiti di accesso](../security/hardening.html#sign-in-limits-and-passwords) per indirizzo contano tutti i client come un solo indirizzo.
+`TRUST_PROXY` dice a quali proxy l'applicazione può credere quando riportano il client in `X-Forwarded-For`:
+
+| Valore | Indirizzo del client |
+|-------|----------------|
+| `0` (predefinito) | L'indirizzo della connessione. `X-Forwarded-For` viene ignorata; vuoto, `false`, `off` e `no` significano lo stesso. |
+| Un numero, es. `1` | Si fida di quel numero di proxy davanti all'applicazione: `1` per un solo reverse proxy, `2` per un load balancer davanti a un ingress. |
+| Una lista, es. `10.0.0.5,172.16.0.0/12` | Si fida dei proxy a questi indirizzi e intervalli CIDR. Sono accettati anche i preset `loopback`, `linklocal` e `uniquelocal`. |
+| `true` | Si fida di ogni salto: si usa l'indirizzo più a sinistra di `X-Forwarded-For`. |
+
+L'applicazione percorre `X-Forwarded-For` da destra, salta i proxy fidati, e prende il primo indirizzo che non è
+uno di loro. Usa il numero esatto di proxy, o i loro indirizzi:
+
+* `X-Forwarded-For` è una normale intestazione di richiesta che qualsiasi client può inviare. Un numero troppo alto, o `true`, permette a un
+  client di scegliere l'indirizzo che registra la traccia di audit. `true` è sicuro solo quando l'applicazione è raggiungibile soltanto
+  tramite il proxy, e il server registra un avviso `[SECURITY]` all'avvio quando è impostato.
+* Il proxy deve aggiungere l'indirizzo da cui ha ricevuto la connessione, come fanno gli esempi qui sotto
+  (`$proxy_add_x_forwarded_for` in Nginx; Traefik e Apache `mod_proxy` lo aggiungono per impostazione predefinita).
+* Un valore non valido viene rifiutato nella pagina delle impostazioni; impostato nell'ambiente, viene registrato come errore all'avvio e
+  non ci si fida di nessun proxy. Una modifica salvata nella pagina delle impostazioni si applica senza riavvio.
+
+---
+
+## Esempi
+
+Ogni esempio pubblica AnsibleForms su `https://forms.example.com/ansibleforms/`, con il TLS terminato dal proxy e
+l'applicazione in esecuzione con `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` e `TRUST_PROXY=1`:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` non indica nessun URI, quindi Nginx inoltra il percorso così come è arrivato, prefisso compreso. Il blocco `map` va nel
+contesto `http` (un file sotto `conf.d/` viene incluso lì), e fa passare l'upgrade WebSocket dei Runner:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Senza un sottopercorso, usa `location /` e lascia `BASE_URL` non impostato.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Label sul servizio `app` del progetto docker-compose, con Traefik sulla stessa rete Docker. Il servizio
+non pubblica nessuna porta propria, Traefik lo raggiunge sulla rete:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Non c'è nessun middleware `StripPrefix`, di proposito. Traefik imposta da solo le intestazioni `X-Forwarded-*` e non limita
+la dimensione del corpo, ma controlla i `respondingTimeouts` dell'entry point quando i backup o i caricamenti durano più del suo
+timeout di lettura. Senza un sottopercorso, tieni solo la parte `Host(...)` della regola.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Richiede `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl`, e Apache 2.4.47 o successivo per l'`upgrade=websocket` dei Runner.
+Entrambi i lati di `ProxyPass` portano il prefisso:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Senza un sottopercorso, inoltra `/` a `http://10.0.0.20:8000/` e lascia `BASE_URL` non impostato.
+
+</div>
+</div>
+
+Per mantenere cifrato il tratto tra il proxy e l'applicazione, esegui l'applicazione con `HTTPS=1`, punta il proxy a
+`https://`, e dai all'applicazione un certificato di cui il proxy si fida, vedi [HTTPS](../security/https.html).
diff --git a/i18n/it/_configure/production/scaling.md b/i18n/it/_configure/production/scaling.md
new file mode 100644
index 0000000..4793e93
--- /dev/null
+++ b/i18n/it/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Scalabilità
+parent: In produzione
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Scalabilità
+{: .no_toc }
+
+AnsibleForms suddiviso su più nodi dell'app e un worker, accanto a uno o più RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ruoli
+
+Ogni container di AnsibleForms esegue lo stesso codice server, e [`AF_ROLE`](../customization/server.html#env_AF_ROLE) decide cosa fa:
+
+| `AF_ROLE` | Immagine | Esegue | Quanti |
+|---|---|---|---|
+| `all` (non impostato) | `ansibleforms` | L'app web e il worker in un solo processo: il predefinito | 1 |
+| `app` | `ansibleforms` | L'interfaccia web e l'API | Quanti ne vuoi, dietro un load balancer |
+| `worker` | `ansibleforms` | Il lavoro in background: lo schema del database e i suoi aggiornamenti, il config seed, le pianificazioni, il backup notturno, le sincronizzazioni dei repository e le pulizie | Uno al lavoro; gli altri attendono e subentrano |
+| `rte` | `ansibleforms-rte-full` (o `-rte-core`, `-rte-base`) | I playbook | Quanti ne vuoi |
+
+L'installazione più piccola è un container senza `AF_ROLE` accanto a un RTE: è ciò che eseguono il [progetto Docker Compose](../installation/docker-compose.html)
+e il [chart Helm](../installation/kubernetes.html). Qualsiasi altro valore di `AF_ROLE` ferma il processo all'avvio.
+
+---
+
+## L'RTE
+
+L'RTE, l'ambiente di esecuzione che esegue i playbook, ha una sezione propria: [Ambienti di esecuzione](../rte/). Tratta come un RTE
+esegue un job, [le sue immagini](../rte/images.html), [come eseguirne uno](../rte/run.html), [più RTE](../rte/several.html) come runner o
+repliche, e [un RTE in un altro datacenter](../rte/another-datacenter.html).
+
+---
+
+## Più nodi dell'app
+
+Per servire più utenti, o per sopravvivere alla perdita di un nodo, suddividi l'app in nodi `app` dietro un load balancer e un `worker`.
+
+### Cosa condividono i nodi
+{: .no_toc }
+
+I nodi si coordinano tra loro tramite il database e un volume condiviso:
+
+* **Il database** : i job, il blocco del worker, il blocco del designer, la lista dei nodi, i lease dei runner (quale nodo dell'app detiene il
+  socket di ogni RTE) e gli avvisi di modifica che mantengono aggiornate le cache di ogni nodo. Una credenziale, un runner o una pianificazione modificati
+  su un nodo sono in vigore su tutti entro 5 secondi
+* **Il volume persistente** (`/app/dist/persistent`) : moduli, la configurazione, repository, caricamenti, backup e il `.env` gestito.
+  Ogni nodo dell'app e il worker montano lo stesso, in lettura e scrittura
+* **La cartella ssh** (`/home/node/.ssh`) : la chiave e i known hosts per git su ssh; il worker crea la chiave al suo primo avvio
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : lo stesso su ogni nodo dell'app, altrimenti un token firmato
+  da un nodo viene rifiutato dal successivo. Un nodo dell'app si rifiuta di partire senza
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : lo stesso su ogni nodo dell'app e worker, altrimenti una
+  credenziale salvata da uno non può essere letta da un altro. Un RTE in modalità socket non lo legge mai; ne ha bisogno solo un RTE deprecato in modalità database
+  che si registra da solo
+
+Dai anche a ogni container lo stesso utente del database: un worker in attesa può terminare la sessione di uno morto solo quando è la propria.
+
+### Il blocco del worker
+{: .no_toc }
+
+Lavora un solo worker alla volta. Detiene il lock del database `ansibleforms_worker`; quando si ferma, il database rilascia il lock e un
+worker in attesa lo prende entro 10 secondi. Quando l'host del worker muore senza salutare, il database potrebbe tenere il lock per ore,
+quindi un worker in attesa termina quella sessione quando nessun worker ha scritto un heartbeat da due minuti, e subentra.
+
+Un worker che perde il lock a favore di un altro si ferma, e il suo container si riavvia come quello in attesa. Anche un worker il cui avvio non riesce si
+ferma, così non detiene mai il lock senza fare nulla. Galera e la group replication non condividono il lock tra i nodi del database: punta ogni
+worker allo stesso nodo del database.
+
+### Job e nodi
+{: .no_toc }
+
+Ogni container si chiama `<role>-<hostname>-<port>`, senza niente da impostare, e la pagina **Stato** li elenca tutti con il loro ruolo
+e la versione, quale è il worker, e un avviso quando eseguono versioni diverse.
+
+Un job in esecuzione su un RTE appartiene a quell'RTE, e prosegue quando il nodo dell'app che lo ha avviato se ne va. Qualsiasi altro job (un job template
+su AWX o un altro runner, un job di workflow, o i passaggi di un modulo multistep deprecato) appartiene al nodo dell'app che lo ha avviato. Un container che si riavvia termina i propri job non finiti, e il
+worker termina i job di un container che ha smesso di rispondere da due minuti, come un pod sostituito.
+
+Un `SIGHUP` inviato a qualsiasi nodo riapplica il [config seed](../seed/): un nodo dell'app chiede al worker di farlo.
+
+### Aggiornamento
+{: .no_toc }
+
+Aggiorna **prima il worker**, poi i nodi dell'app. Il worker applica le patch allo schema, e un nodo dell'app della nuova versione attende finché lo
+schema non è aggiornato e registra cosa sta aspettando. I nodi dell'app aggiornati per primi restano non pronti finché il worker non li segue, mentre quelli vecchi continuano
+a servire. Gli RTE possono seguire in qualsiasi momento, purché parlino lo stesso contratto.
+
+### Limiti
+{: .no_toc }
+
+Alcune cose restano legate a un solo nodo:
+
+* **L'assistente chat** tiene le sue conversazioni nella memoria di un nodo dell'app: usa le sticky session sul load balancer (nginx
+  `ip_hash`), o un solo nodo dell'app
+* **I log** restano in ogni container. Imposta [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) fuori dal volume condiviso, perché più
+  processi che ruotano lo stesso file perdono righe. Il visualizzatore dei log mostra il log del nodo che risponde, quindi raccogli i log in modo centralizzato
+* **Le impostazioni** modificate nelle pagine delle impostazioni vengono scritte nel `.env` gestito sul volume condiviso e si applicano su ogni nodo; quelle
+  che richiedono un riavvio lo richiedono su ogni nodo
+
+---
+
+## Esempio di architettura
+
+Il repository dell'app ha un punto di partenza completo in [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Servizio | Immagine | Ruolo |
+|---|---|---|
+| `db` | `mariadb:11` | Il database, con un utente che ha diritti solo sullo schema `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, dietro il load balancer |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: il secondo attende e subentra |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Esegue i playbook con `RTE_MODE=inbound` e `RTE_FILES=local`: l'app lo contatta |
+| `lb` | `nginx:stable` | Termina l'HTTPS sulla porta 8443 e distribuisce i browser sui nodi dell'app con `ip_hash` |
+
+Il runner `rte` dell'RTE e la credenziale con cui accede (il suo indirizzo `http://rte:8000` e `RTE_TOKEN`) sono dichiarati nel
+[config seed](../seed/) `seed.yaml`, che il worker applica a ogni avvio; l'RTE non imposta nessun `RTE_URL` e non è pubblicato sull'host.
+
+I nodi dell'app e i worker condividono un solo `.env`, con l'utente del database, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` dietro il load balancer e un `LOG_PATH` fuori dal volume condiviso. L'RTE non ha `env_file`: riceve
+solo `RTE_TOKEN` da `compose.yaml`, quindi non contiene nessuna password del database. I nodi dell'app, i worker e l'RTE montano gli stessi
+volumi persistent e ssh:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/it/_configure/rte/another-datacenter.md b/i18n/it/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..22a6d72
--- /dev/null
+++ b/i18n/it/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Un altro datacenter
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Un RTE in un altro datacenter
+{: .no_toc }
+
+Da un host vuoto in un secondo datacenter a un RTE in uscita che esegue il suo primo playbook
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Per gli amministratori: quando gli host gestiti di un secondo datacenter vanno raggiunti da un RTE in quel datacenter, non dal primo.
+
+{: .note }
+> **La strada facile.** L'[installer](../installation/installer.html#a-runner) esegue ogni passaggio qui sotto sull'host dell'RTE con un solo comando:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, con `--join afj_...` per farlo approvare subito.
+> Questo runbook fa lo stesso a mano, con Docker o Podman, così puoi vedere e adattare ogni parte.
+
+---
+
+## Cosa ottieni alla fine
+
+L'app, il suo worker e il suo database restano dove sono, nel datacenter 1. Il datacenter 2 riceve un host che esegue un container RTE in
+modalità in uscita ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), vedi [Modalità](modes.html#outbound)): contatta l'app su
+HTTPS e tiene aperto un WebSocket, si unisce come runner proprio, ed esegue i playbook dei moduli che lo indicano sugli host gestiti
+del datacenter 2.
+
+| Dove | Cosa gira lì | Parla con |
+|---|---|---|
+| Datacenter 1 | I nodi dell'app, il worker, il database (come oggi) | Niente di nuovo: riceve il socket dell'RTE sul suo solito indirizzo HTTPS |
+| Datacenter 2, l'host dell'RTE | Docker o Podman, e il container RTE | L'app in `APP_URL` su HTTPS, e gli host gestiti del datacenter 2 |
+
+L'RTE non contiene credenziali del database né `ENCRYPTION_SECRET`, solo un token proprio. Nulla si connette a lui, quindi non ha bisogno di porte
+aperte, di un nome DNS né di un certificato. L'app invia i playbook e gli inventari con ogni job (`RTE_FILES=transfer`, il
+predefinito), quindi l'RTE non ha bisogno di una loro copia né di un disco condiviso.
+
+Ogni comando qui sotto si esegue in un terminale sull'host dell'RTE, come utente con `sudo`, salvo dove indicato diversamente. Richiede circa 20 minuti,
+la maggior parte passati ad attendere l'immagine.
+
+---
+
+## 0. Prima di iniziare
+
+Raccogli queste informazioni:
+
+| Cosa | Da dove arriva |
+|---|---|
+| L'indirizzo dell'app | `APP_URL`: l'indirizzo che le persone aprono in un browser, come `https://forms.example.com`, con il suo percorso di base se ne ha uno |
+| Il certificato dell'app | Firmato da una CA pubblica, da una CA privata (ti serve il suo certificato, passaggio 6), o autofirmato |
+| Un proxy | L'`HTTPS_PROXY` che questo datacenter usa per raggiungere il datacenter 1, se c'è |
+| Il nome dell'RTE | Il nome del suo runner in **Connessioni > Runner**, che i moduli indicano con `runner:`, come `rte-dc2`: lettere, cifre e `_ . : @ -` |
+| Un join token | Facoltativo: un [join token](../runners/registration.html#join-tokens) (`afj_...`) approva subito l'RTE. Senza, lo approva un admin (passaggio 8) |
+| La chiave ssh | La chiave privata che i playbook usano per raggiungere gli host gestiti, o il diritto di crearne una |
+
+L'app deve eseguire la 7.3.0 o successiva. Per creare un join token per questo solo RTE, un admin chiama l'API una volta (vedi
+[Join token](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Preparare l'host
+
+L'RTE è un container, quindi l'host ha bisogno di un motore dei container e di nient'altro: Node.js, python e ansible sono nell'immagine.
+
+| Requisito | Perché |
+|---|---|
+| Linux su **x86_64** (amd64) | Le immagini RTE sono pubblicate solo per amd64 |
+| 2 CPU e 4 GB di memoria, o di più | Un RTE esegue fino a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbook insieme (10), ognuno con i suoi fork: dimensionalo per quelli |
+| 20 GB di disco libero | L'immagine `-rte-full` occupa circa 3,3 GB, più un'immagine durante gli aggiornamenti, i file dei job che l'app invia e i file temporanei dei job |
+| Docker, o Podman con podman-compose | Per scaricare ed eseguire l'immagine |
+| L'ora impostata via NTP | Gli orari dei job vengono confrontati con quelli dell'app |
+
+**Docker**, su Ubuntu o Debian (altre distribuzioni: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, su RHEL, Rocky o Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Con Podman, scrivi `podman` al posto di `docker` e `podman-compose` al posto di `docker compose` in ogni comando qui sotto.
+
+---
+
+## 2. Rete e firewall
+
+L'RTE apre da solo ogni connessione. Nulla lo raggiunge dall'esterno:
+
+| Da | A | Porta | Perché |
+|---|---|---|---|
+| L'host dell'RTE | L'app, in `APP_URL` (tramite `HTTPS_PROXY` se impostato) | La porta dell'app, `443` dietro la maggior parte dei proxy | Il socket su cui passano i job, i loro file e il loro output |
+| L'host dell'RTE | Gli host gestiti del datacenter 2 | ssh (`22`), WinRM, le loro API | I playbook girano da qui |
+| L'host dell'RTE | `ghcr.io` | `443` | Per scaricare l'immagine, a meno che non arrivi dal tuo registry o da un file (passaggio 4) |
+
+Non aprire nessuna porta in entrata per l'RTE. La sua `PORT` (`8000`) serve solo `/live`, `/ready` e `/metrics`, per le probe su questo host.
+
+L'RTE contatta `APP_URL` con aggiunto `/api/v2/rte/socket`, come WebSocket. Un reverse proxy davanti all'app deve far passare l'upgrade
+per quel percorso (vedi [WebSocket dei runner](../production/reverse-proxy.html#runner-websockets)). Verifica da qui che l'app risponda:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Cartelle
+
+Tutto sta sotto `/opt/af-rte`. L'RTE gira come utente `node` (uid 1000), quindi i suoi dati appartengono a quell'uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Cartella | Nel container | Contiene |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | Lo spool (`rte-spool`: l'output e la fine di ogni job finché l'app non li ha salvati), i file dei job inviati dall'app (`rte-files`), una CA privata, le librerie python che installa un playbook |
+| `data/ssh/` | `/home/node/.ssh` | La chiave ssh e il `known_hosts` dei playbook |
+| `data/ansible/` | `/etc/ansible/...` | Un `ansible.cfg`, ruoli e collection tuoi, montati invece che integrati nell'immagine |
+
+Tieni `data/` sull'host: un RTE riavviato invia ancora ciò che l'app non aveva salvato, e conserva la sua cache dei file dei job.
+
+**Chiave ssh.** Copia la chiave che i playbook usano nel datacenter 1, o creane una per questo datacenter e dai la sua metà pubblica agli host gestiti:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Poi assegna tutto all'uid 1000, con la chiave leggibile solo dal suo proprietario:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. L'immagine
+
+Scegline una delle due.
+
+### Opzione A: l'immagine ufficiale
+{: .no_toc }
+
+Le immagini pubblicate sono nel GitHub Container Registry, pubbliche, senza bisogno di accesso (vedi [Immagini](images.html) per i tre livelli).
+Prendi lo stesso livello del datacenter 1. `:7` segue l'ultima versione 7, come fa il `:7` dell'app:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Un host senza accesso a internet riceve l'immagine da uno che ce l'ha:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Oppure caricala una volta nel tuo registry (`docker tag` e `docker push`), e usa quel nome nei passaggi successivi.
+
+### Opzione B: la tua immagine
+{: .no_toc }
+
+Quando i playbook del datacenter 2 hanno bisogno di collection o librerie python che mancano all'immagine ufficiale (quelle VMware per il vCenter
+di questo datacenter, per esempio), parti da `ansibleforms-rte-core`:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Ricostruiscila a ogni nuova versione dell'app (vedi [Costruire il tuo RTE](images.html#build-your-own-rte)). Con più host RTE, costruiscila
+una volta e caricala nel tuo registry. Offline, usa `docker save` e `docker load` sull'immagine costruita come nell'opzione A.
+
+---
+
+## 5. Impostazioni
+
+Un nuovo [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) proprio, di almeno 16 caratteri. È la password di questo RTE: l'app
+lo conserva nella credenziale RTE del runner, e sigilla con esso i segreti di ogni job.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variabile | Significato |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: l'RTE contatta l'app. Senza, l'RTE parte nella modalità database deprecata |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'indirizzo dell'app, `http://` o `https://`, con il suo percorso di base se c'è |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Il nome del suo runner. Se non è impostata: il suo id di nodo, `rte-<hostname>-<port>`, che cambia con il container |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Il suo token, di almeno 16 caratteri. Conservalo: d'ora in poi il runner accede con esso |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Facoltativa: un join token, usato solo finché il suo runner non esiste ancora o attende l'approvazione |
+
+Aggiungi queste quando la rete ne ha bisogno:
+
+| Variabile | Quando |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | L'RTE raggiunge l'app tramite un proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Un host elencato in `NO_PROXY` (separati da virgole, `.example.com` per un dominio) viene contattato direttamente |
+| `NODE_EXTRA_CA_CERTS` | Il certificato dell'app proviene da una CA privata: metti il certificato della CA in `/opt/af-rte/data/certificates/ca.pem` e imposta `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` accetta qualsiasi certificato dell'app, compreso uno autofirmato. Solo all'interno di una rete fidata: preferisci `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predefinito) riceve i playbook e gli inventari con ogni job. Lascialo così, a meno che non li monti tu sull'RTE (`local`) |
+
+Le altre impostazioni che legge un RTE sono in [Eseguire un RTE](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` e
+`RTE_DRAIN_SECONDS` si possono impostare anche in seguito nella sua pagina del runner, che vince sulla variabile (vedi
+[Le impostazioni di un RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Avviarlo
+
+Un file compose tiene l'intera definizione in un solo posto, accanto alle impostazioni. Metti l'immagine del passaggio 4 in `image:`:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker lo riavvia dopo un reboot (`unless-stopped`). Podman non ha un demone che lo faccia: abilita `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`), o esegui il container come servizio systemd con un file Quadlet. Su un host con SELinux
+in modalità enforcing, aggiungi `:Z` a ogni volume (`./data:/app/dist/persistent:Z`).
+
+Senza compose, lo stesso container con un solo comando:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Verificarlo sull'host
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+Il log mostra l'RTE che parte, contatta l'app e si connette:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Senza un join token, un'altra riga dice che è in attesa:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Annota l'impronta.
+
+`/ready` risponde `503` con `not connected to the app` finché il socket non è aperto. L'healthcheck dice solo che il processo è in ascolto.
+
+---
+
+## 8. Approvarlo
+
+Senza un join token, l'RTE ha chiesto di unirsi: **Connessioni > Runner** mostra un avviso arancione sopra la lista,
+**1 Runner attende l'approvazione**. Aprilo, verifica che l'**Impronta** sia quella del log dell'RTE e che **Modalità** dica
+In uscita, poi fai clic su **Approva** (vedi [Approvare un RTE](../runners/registration.html#approving-an-rte)). Solo un admin approva. Una richiesta
+che nessuno gestisce entro 24 ore viene rimossa, e l'RTE chiede di nuovo la prossima volta che contatta l'app.
+
+Con un join token, il runner viene approvato subito e la sua descrizione indica il join token. In entrambi i casi l'app conserva il token dell'RTE
+in una nuova credenziale RTE, `rte-dc2-rte`, e da quel momento l'RTE accede con il proprio `RTE_TOKEN`: `RTE_JOIN_TOKEN` non viene più
+usato, e puoi rimuoverlo da `rte.env`.
+
+---
+
+## 9. Verificarlo in AnsibleForms
+
+1. **Connessioni > Runner** elenca il runner `rte-dc2`, tipo RTE. Attiva **Colonne > Connessione** per vedere **Connesso** nella lista
+2. Aprilo. La sua scheda **RTE** mostra **Modalità** In uscita e il badge **Connessione** **Connesso**; al passaggio del puntatore indica il nodo dell'app che
+   detiene il socket, la versione dell'RTE e quanti dei suoi job sono in esecuzione
+3. Fai clic su **Testa connessione**: dice **Runner connection is OK**. Non chiama nulla: legge quale nodo dell'app detiene il socket dell'RTE
+   (`runner_leases`) e verifica il contratto che l'RTE ha parlato quando si è connesso
+4. Dagli una descrizione, come *Datacenter 2*
+5. Lascia **Predefinito** sul runner del datacenter 1, a meno che ogni modulo di playbook senza `runner:` non debba girare nel datacenter 2
+
+La pagina **Stato** elenca il nuovo RTE con la sua versione, accanto agli altri.
+
+---
+
+## 10. Un primo job
+
+Prova l'intero percorso con un playbook che non cambia nulla. Nei playbook dell'app (la sua cartella dei playbook o il suo repository, come nel
+datacenter 1), aggiungi `ping-dc2.yaml`:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Poi aggiungi nel designer un modulo che indica il nuovo runner:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Avvialo. L'app invia la cartella dei playbook e l'inventario con il job, e l'RTE li conserva in base al loro hash, così una cartella invariata
+non viene mai inviata due volte. L'output inizia con `Running on RTE rte-dc2 (outbound)`, mostra `pong` per ogni host, e il job
+termina con successo. Una cartella più grande di [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 per impostazione predefinita) non viene
+inviata: il job fallisce e lo segnala.
+
+---
+
+## 11. Mandargli i moduli
+
+Un modulo gira sull'RTE che indica, quindi aggiungi la stessa riga a ogni modulo per il datacenter 2:
+
+```yaml
+runner: rte-dc2
+```
+
+Vedi [Runner](../runners.html) per il runner predefinito e gli altri tipi di runner.
+
+---
+
+## Quando qualcosa non funziona
+
+L'RTE scrive in `docker logs` da `notice` in su. Una connessione che fallisce prima che il socket si apra (un nome DNS, una porta rifiutata, un
+certificato) compare solo come `RTE: dialing the app again in <n> seconds`, a livello `info`: imposta
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) in `rte.env` e riavvialo per vedere
+`RTE: socket to wss://...: <the error>`.
+
+| Cosa vedi | Dove | Cosa fare |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `RTE_TOKEN` manca o è troppo corto in `rte.env` |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Imposta `APP_URL` in `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` deve iniziare con `https://` (o `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | Manca `RTE_MODE=outbound` in `rte.env` |
+| Nessuna riga `connected to the app`, `/ready` resta `503` | `docker logs`, `/ready` | La rete del passaggio 2: fai `curl` all'app da questo host, il proxy (`HTTPS_PROXY`, `NO_PROXY`), il certificato dell'app (`NODE_EXTRA_CA_CERTS`, passaggio 5). Imposta `LOG_CONSOLE_LEVEL=debug` per vedere l'errore |
+| `the app refused the socket (404)` o un altro stato diverso da 401, 403 e 409 | `docker logs` | Un reverse proxy non fa passare il WebSocket su `/api/v2/rte/socket`, o ad `APP_URL` manca il percorso di base dell'app |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Esiste un runner `rte-dc2` con un altro token. Dai all'RTE quel token (la password della credenziale del runner), o elimina il runner così che chieda di unirsi |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Crea un nuovo join token, o rimuovi `RTE_JOIN_TOKEN` e approva l'RTE (passaggio 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | L'RTE è stato reinstallato con un nuovo token: usa il token della credenziale del suo runner, o fallo cambiare a un admin |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Segue un rifiuto. Correggine la causa, poi `docker restart af_rte_dc2` invece di aspettare |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Approvalo (passaggio 8). È connesso, ma fino ad allora non riceve job |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | L'app e l'RTE eseguono versioni con un altro [contratto](images.html#the-contract): aggiorna l'RTE alla versione dell'app (vedi Aggiornarlo) |
+| **Non connesso**, o **Testa connessione** dice *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | L'app | Nessun nodo dell'app detiene il suo socket: l'RTE è fermo, o non riesce a raggiungere l'app. Leggi i suoi `docker logs` |
+| Un job attende, poi fallisce con *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | L'output del job | L'RTE non era connesso mentre il job attendeva |
+| `Permission denied` sulla chiave ssh | L'output del job | I file di `data/` devono appartenere all'uid 1000 (passaggio 3) |
+| `UNREACHABLE` per gli host gestiti | L'output del job | ssh da questo host: la chiave, `known_hosts`, e il firewall verso gli host |
+
+Sul lato dell'app, un RTE rifiutato compare nel log dell'app come `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Aggiornarlo
+
+Quando l'app passa a una nuova versione, seguila anche su questo host. Un RTE con lo stesso contratto continua a funzionare nel frattempo; quando una versione
+cambia il contratto, le sue note di rilascio lo dicono (vedi [Il contratto](images.html#the-contract)). Con `:7` in `compose.yml`, o nel
+`FROM` del tuo Dockerfile:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Aggiornalo quando non c'è nessun playbook in esecuzione su di esso: un arresto attende `RTE_DRAIN_SECONDS` (25) per i playbook in esecuzione, e quelli ancora in esecuzione
+terminano allora come abbandonati. Ciò che hanno stampato prima dell'arresto viene conservato nello spool e inviato quando l'RTE torna. Offline, esegui `docker load`
+della nuova immagine (passaggio 4) prima di `docker compose up -d`.
+
+---
+
+## Tornare indietro
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+Il socket si chiude, e il runner mostra subito **Non connesso**: nessun nodo dell'app detiene più il suo socket (`runner_leases`). Un host
+che se ne va senza chiuderlo mostra **Non connesso** entro circa un minuto, quando il nodo dell'app non sente più nulla sul socket. Il
+runner resta: un runner che si è unito tramite un socket non viene mai rimosso da solo. Eliminalo in **Connessioni > Runner**, e la sua
+credenziale `rte-dc2-rte` in **Connessioni > Credenziali**. Rimuovi prima la riga `runner:` dai moduli che lo indicavano: fino ad
+allora i loro job attendono l'RTE, fino a `RTE_QUEUE_MINUTES`, e falliscono.
+
+---
+
+## Più capacità nel datacenter 2
+
+Ripeti i passaggi da 1 a 9 su altri host del datacenter 2, ognuno con il proprio `RTE_NAME` e `RTE_TOKEN`, come `rte-dc2-b`: ognuno si unisce come
+runner proprio e riceve fino a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbook. Un modulo ne sceglie uno con
+`runner:`. Due RTE con lo stesso `RTE_NAME` non si dividono il lavoro: il secondo prende il socket al primo (vedi
+[Più RTE](several.html#several-rtes)).
+
+---
+
+## Un RTE in modalità database
+
+Prima della 7.3.0 questo runbook configurava un RTE in modalità database: conteneva le credenziali del database (`DB_*`, `ENCRYPTION_SECRET`), si connetteva
+al database del datacenter 1 sulla porta `3306`, e l'app lo chiamava sulla sua porta `8000`. Quella modalità è deprecata dalla 7.3.0 e
+verrà rimossa nella 8.0.0. Per passare un RTE del genere alla modalità in uscita senza un nuovo runner, imposta su di esso `RTE_MODE=outbound`, `APP_URL` e `RTE_NAME` (il nome del
+suo runner), mantieni il suo `RTE_TOKEN`, e rimuovi `DB_*`, `ENCRYPTION_SECRET` e `RTE_REGISTER`: vedi
+[Database (deprecata)](modes.html#database-deprecated). Poi chiudi la porta `8000` e la porta del database di cui non ha più bisogno.
diff --git a/i18n/it/_configure/rte/images.md b/i18n/it/_configure/rte/images.md
new file mode 100644
index 0000000..3dba4f0
--- /dev/null
+++ b/i18n/it/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Immagini
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# Immagini RTE
+{: .no_toc }
+
+Le tre immagini RTE pubblicate, e un RTE tuo con le collection e le librerie usate dai tuoi playbook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le immagini RTE
+
+L'RTE è pubblicato in tre livelli, ognuno costruito su quello precedente, con gli stessi tag dell'app (vedi [Tag delle immagini](../installation/#image-tags)):
+
+| Immagine | Cosa contiene | Quando usarla |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js e il server di AnsibleForms, git, ssh e sshpass. Niente python e niente ansible, quindi da sola non esegue nessun playbook | Per costruire un RTE con le tue versioni di python e ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base, più python 3.14, ansible-core e alcune librerie comuni (`jmespath`, `netaddr`, `requests`, `paramiko`). Nessuna collection | Per costruire un RTE più piccolo con solo le collection e le librerie usate dai tuoi playbook |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Il core, più il pacchetto `ansible` sullo stesso ansible-core, e ciò che aveva l'immagine di AnsibleForms 6.5: le collection NetApp, AWS e community, `pandas`, `pyvmomi`, `boto3`, il client mariadb, ytt e alcuni strumenti di sistema | **Il predefinito.** Eseguila così com'è: i playbook della 6.5 trovano ciò che usavano |
+
+Come l'immagine dell'app, ogni livello gira come utente `node` (uid 1000), e anche i playbook girano come quell'utente.
+
+---
+
+## Costruire il tuo RTE
+
+Parti da `ansibleforms-rte-core` e aggiungi le collection e le librerie python usate dai tuoi playbook. Questo esempio NetApp è uno dei
+Dockerfile in [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+L'ambiente python e la cartella delle collection appartengono a `node`, quindi queste installazioni non richiedono root. Un livello che installa pacchetti
+di sistema passa a `USER root` per farlo e torna a `USER node` alla fine. Per portare il tuo python e il tuo ansible, parti da
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` nella stessa cartella).
+
+Tieni l'immagine allineata alla versione dell'app: `:7` segue il `:7` dell'app. Collection e ruoli si possono anche montare invece di integrarli nell'immagine, in
+`/etc/ansible/collections` e `/etc/ansible/roles`. Così non serve ricostruire a ogni modifica, ma ciò che gira dipende da quel volume;
+le librerie python vanno sempre nell'immagine. Integrare tutto è riproducibile e parte in fretta, ed è quindi la strada per la produzione.
+
+---
+
+## Il contratto
+
+Ciò che l'app e un RTE devono condividere è il loro contratto, un numero che entrambi riportano. Un RTE di una versione più vecchia continua a funzionare con un'app
+più recente finché entrambi parlano lo stesso contratto; quando una versione lo cambia, le sue note di rilascio dicono che gli RTE vanno aggiornati. Ogni modalità
+ha il suo:
+
+| Modalità | Contratto | In caso di discrepanza |
+|---|---|---|
+| In uscita, In entrata | 3, novità della 7.3.0 | L'app chiude il socket dell'RTE con il codice `4409` e registra *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Un RTE in uscita registra *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Un job inviato con un altro contratto viene rifiutato |
+| Database (deprecata) | 2, dalla 7.0.0 | L'RTE rifiuta i job dell'app |
+
+**Testa connessione** sul runner dice quale contratto parla l'RTE e quale richiede l'app (vedi
+[Testa connessione](../runners/runner-page.html#test-connection)), e la riga **Runner** della pagina **Stato** esegue lo stesso controllo.
diff --git a/i18n/it/_configure/rte/index.md b/i18n/it/_configure/rte/index.md
new file mode 100644
index 0000000..4a67a8f
--- /dev/null
+++ b/i18n/it/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Ambienti di esecuzione (RTE)
+{: .no_toc }
+
+Cos'è un RTE, come esegue un playbook, e cosa può toccare
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: capisci l'RTE prima di eseguirne uno, dimensionarlo o spostarlo in un'altra rete.
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Immagini](images.html) | Le tre immagini RTE, e come costruire la tua con le collection usate dai tuoi playbook |
+| [Modalità](modes.html) | In uscita, in entrata o database: chi apre la connessione, lo spool, i file del job |
+| [Eseguire un RTE](run.html) | Le impostazioni di ogni modalità, e un esempio `docker run` di ciascuna |
+| [Più RTE](several.html) | Capacità, repliche dietro un solo indirizzo, e cosa succede quando un RTE si ferma o muore |
+| [Un altro datacenter](another-datacenter.html) | Un runbook: aggiungere un RTE in un secondo datacenter, da un host vuoto al suo primo job |
+
+---
+
+## Cos'è un RTE
+
+AnsibleForms 7 non esegue nessun playbook nel container dell'app. Il job di un modulo `ansible` viene affidato a un [runner](../runners.html) di tipo
+`rte`, un ambiente di esecuzione: il server di AnsibleForms avviato con `AF_ROLE=rte`, accanto a python e ansible, senza interfaccia
+web. Parla con l'app tramite un unico WebSocket e non contiene credenziali del database
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` o `inbound`, vedi [Modalità](modes.html)): l'app gli invia il job,
+l'RTE esegue `ansible-playbook`, e l'app salva l'output e lo stato finale che le rimanda, dove il browser li legge.
+
+L'app risolve le credenziali del job e le consegna all'RTE sigillate solo per quell'RTE e quel job. L'RTE non legge mai la
+tabella delle credenziali né un archivio di segreti, e un playbook non eredita le variabili d'ambiente di AnsibleForms
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` e le altre): passa un valore del genere come extravar o come credenziale. L'RTE dalla 7.0 alla 7.2,
+che leggeva e scriveva da solo nel database, gira ancora nella 7.x come modalità database deprecata (vedi [Modalità database](#database-mode-deprecated)).
+
+---
+
+## Come gira l'RTE
+
+L'RTE è un container che esegui tu, accanto all'app o in un'altra rete: AnsibleForms non ne crea mai uno. Qui si vede
+dove gira, cosa condivide con l'app, e cosa succede al suo interno dal momento in cui si avvia un modulo fino a quando il processo del playbook
+non c'è più:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Come l'RTE esegue un playbook</title>
+<desc id="afr-desc">Su un host di container o in un cluster Kubernetes, entrambi gestiti dall'operatore, il container dell'app e uno o più container RTE mantengono ciascuno un WebSocket tra loro, aperto dall'app (in entrata) o dall'RTE (in uscita). Solo l'app parla con il database. 1: il browser avvia un modulo sull'app. 2: l'app salva il job nel database, sceglie il runner e sigilla per esso i segreti del job. 3: l'app invia il job tramite il socket. 4: l'RTE lo prende in carico e ottiene i file del job, dalla sua cache o dall'app. 5: l'RTE avvia ansible-playbook come processo figlio, uno per job, fino a RTE_MAX_JOBS. 6: il playbook raggiunge gli host gestiti. 7: l'RTE scrive l'output, gli eventi e la fine nel suo spool e li invia tramite il socket; l'app li salva nel database e ne conferma la ricezione. 8: il browser segue il job tramite l'app. Il volume dell'app è montato nell'RTE solo con RTE_FILES=local.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Host di container o cluster Kubernetes</text>
+<text class="afr-s" x="181" y="61">gestito da te; un RTE in uscita può stare in un'altra rete</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Browser</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">moduli, pagina job</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">Container app</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">web, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runner</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">sigillano i segreti</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">Hub RTE</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">salva e conferma</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">Container RTE</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="477" y="160" text-anchor="middle">File del job</text>
+<text class="afr-s" x="477" y="174" text-anchor="middle">in cache per hash</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">fino a RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">fino alla conferma</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">un</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Host gestiti</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volume dell'app</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbook, inventari</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">solo RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">solo dell'app</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="548" cy="142" r="9"/><text class="afr-nt" x="548" y="146" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+Il diagramma mostra un socket per RTE, qualunque sia il lato che lo ha aperto: l'app contatta un RTE in entrata, un RTE in uscita contatta l'app (vedi
+[Modalità](modes.html)). Una volta aperto, gli stessi messaggi viaggiano in entrambe le direzioni, e solo l'app legge e scrive nel database.
+
+**Chi lo avvia.** Un RTE è un container di lunga durata, avviato da ciò che esegue i tuoi altri container. Attende i job e continua a
+girare tra un job e l'altro:
+
+| Come esegui AnsibleForms | Chi avvia l'RTE |
+|---|---|
+| `docker run` o `podman run` | Tu, con un comando come quello di [Eseguire un RTE](run.html), su qualsiasi host che raggiunge l'app, o che l'app raggiunge |
+| [Docker Compose](../installation/docker-compose.html) | Il servizio `rte` di `docker-compose.yml`, accanto ad `app` e `mysqldb`. Il suo config seed lo dichiara come runner predefinito `rte`, in entrata, su `http://rte:8000` |
+| [Chart Helm](../installation/kubernetes.html) | Kubernetes, come secondo container chiamato `rte` nel pod dell'app (`containers.rte`). L'app lo contatta su `127.0.0.1`, in entrata, e il seed del chart lo dichiara come runner predefinito |
+| [L'installer](../installation/installer.html) | Docker Compose o il chart Helm come sopra, o un servizio systemd [senza container](../installation/native.html); un Runner proprio, che chiede di unirsi e attende l'approvazione di un admin |
+
+Il motore dei container è tuo: Docker o Podman sull'host, o il runtime dei container del tuo cluster Kubernetes, installato e mantenuto
+aggiornato da te. AnsibleForms non parla mai con esso. Né l'app né l'RTE chiamano Docker o Podman, ne montano il socket o avviano un
+container: l'app parla solo con l'RTE tramite il suo socket.
+
+**Cosa c'è dentro.** Un solo container, con ciò che serve per eseguire un playbook e nient'altro:
+
+* **Il server** : lo stesso server Node.js dell'app, avviato con `AF_ROLE=rte` (impostato nell'immagine) sotto `tini`
+* **Cosa è escluso** : l'interfaccia web, l'accesso, il pianificatore, il worker e ogni modulo del database, che questo ruolo non carica
+* **Su cosa è in ascolto** : la sua `PORT` (`8000`): `/live` e `/ready` per le probe e `/metrics` per Prometheus, e in entrata il socket
+  che l'app contatta, `/rte/v1/socket`. Un RTE in uscita non accetta connessioni dall'app
+* **Python e ansible** : portati dal livello dell'immagine che scegli (vedi [Le immagini RTE](images.html))
+* **L'utente** : il server e ogni playbook girano come `node` (uid 1000), mai come root
+
+**Cosa condivide con l'app.** Il suo token, e con `RTE_FILES=local` i file dell'app. Con `RTE_FILES=transfer`, il predefinito, i
+playbook e gli inventari arrivano con ogni job, e l'RTE non ha bisogno di un disco condiviso:
+
+| Condiviso con l'app | Cosa ne fa l'RTE |
+|---|---|
+| `RTE_TOKEN` | Lo presenta quando contatta l'app (in uscita), o lo verifica quando l'app lo contatta (in entrata). L'app conserva lo stesso valore nella credenziale RTE del runner, e i segreti del job vengono sigillati con esso |
+| Il volume persistente, `/app/dist/persistent`, solo con `RTE_FILES=local` | La cartella dei playbook ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)), o il repository dei playbook che il worker ha clonato sotto [`REPO_PATH`](../customization/paths.html#env_REPO_PATH), gli inventari ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) e i repository degli inventari) e i caricamenti. L'RTE scrive i file delle extravars del job nella cartella del playbook, quindi montala in lettura e scrittura |
+| La cartella ssh, `/home/node/.ssh` | La chiave privata e il `known_hosts` usati dalle connessioni ssh del playbook: monta quella dell'app, gestita nelle sue pagine delle impostazioni, o dai all'RTE una propria |
+
+L'RTE non clona nulla: un repository gli arriva nei file di un job, o sul volume che condivide con l'app. Collection, ruoli e
+`ansible.cfg` arrivano dall'immagine, dalle cartelle `/etc/ansible/collections`, `/etc/ansible/roles` e `/etc/ansible/ansible.cfg` quando
+le monti lì (il progetto Docker Compose lo fa), o da un `ansible.cfg` accanto ai playbook.
+
+**La vita di un job.** I numeri qui sotto sono quelli del diagramma, per un modulo di playbook avviato dal browser o dall'API:
+
+1. **Avvio** : l'app verifica il modulo e i suoi valori, costruisce le extravars e salva il job con stato `running`. Un modulo con
+   un'[approvazione](../forms/approval.html) si ferma qui finché un approvatore non lo accetta, e prima di allora non raggiunge nessun RTE
+2. **Scelta del runner** : l'app prende l'RTE che il modulo indica con `runner: <name>`, altrimenti il runner predefinito di tipo RTE, e ne salva
+   il nome sul job. Risolve le credenziali del job dal database o da un [archivio di segreti](../secret-stores/), il suo accesso ansible e la sua
+   password vault, e le sigilla con AES-256-GCM con una chiave derivata dal token di quel runner e dall'id del job
+3. **Consegna** : il nodo dell'app che detiene il socket dell'RTE gli invia il job: le extravars, le opzioni del modulo, i segreti sigillati e
+   gli hash dei file del job. Qualsiasi nodo dell'app può avviare il job; quello che detiene il socket lo invia entro due secondi. Un RTE pieno,
+   o non connesso, fa attendere il job, fino a [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Presa in carico** : l'RTE risponde `claimed`, o `refused` quando è pieno, si sta fermando, non riesce ad aprire i segreti, o il job arriva con un altro
+   [contratto](images.html#the-contract) rispetto al suo. Con `RTE_FILES=transfer` prende i playbook e gli inventari dalla sua
+   cache in base al loro hash, chiede all'app un hash che non ha, e li estrae in una cartella propria del job
+5. **Partenza** : nella cartella del playbook (più il `playbookSubPath` del modulo, che deve esistere) scrive due file: `extravars_<id>.json`
+   con i valori del modulo e le credenziali, e uno nascosto con l'accesso ansible. Poi avvia `ansible-playbook` come proprio processo
+   figlio, senza shell, in un gruppo di processi proprio, con `-e @` quei file, un `-i` per inventario, e i tag, il limit, il check,
+   il diff e la verbosità del modulo. La password vault entra da stdin, mai in un file o sulla riga di comando, e il processo gira come
+   `node` con un ambiente filtrato (vedi sotto)
+6. **Esecuzione** : il playbook si connette agli host gestiti dal container RTE, via ssh con la chiave e il `known_hosts` di
+   `/home/node/.ssh`, con `sshpass` per un accesso con password, o tramite le API che chiamano i suoi moduli. È l'RTE, non l'app, che deve raggiungerli
+7. **Output e fine** : l'RTE raggruppa stdout e stderr ogni mezzo secondo o 64 KB, con le credenziali mascherate, e numera ogni
+   gruppo. Scrive ogni elemento nello spool del job sul suo disco prima di inviarlo: l'output, gli eventi, il log del job di
+   `.joblogs/job_log_<id>.log` (ogni 2 secondi), l'inizio e la fine con lo stato finale (`success`, `failed` o `aborted`). L'app
+   salva ogni elemento una sola volta e ne conferma la ricezione, e l'RTE elimina lo spool una volta salvata la fine. Oltre
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) byte su un flusso (50 MB per impostazione predefinita) non invia altro, e
+   il playbook continua. L'app invia poi le [notifiche](../forms/notifications.html) del modulo
+8. **Seguire** : il browser non parla mai con l'RTE: la pagina del modulo rilegge il job tramite l'app ogni 2 secondi, e la pagina Job
+   lo segue in tempo reale man mano che l'app salva ogni elemento
+
+**Un socket caduto.** Il playbook continua. L'RTE ricontatta l'app (in uscita), o un nodo dell'app lo ricontatta (in entrata), e reinvia ciò
+di cui l'app non aveva confermato la ricezione: l'app salta ciò che ha già salvato, quindi nessuna riga va persa o viene salvata due volte. Questo vale finché il socket
+torna entro due minuti: l'app scrive l'heartbeat dell'RTE solo finché il suo socket è aperto, e una volta che quell'heartbeat ha due minuti
+il worker termina i job in esecuzione dell'RTE come abbandonati, anche se i loro playbook stanno ancora girando. Tieni lo spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) su un volume, così un RTE riavviato invia ancora ciò che aveva conservato. Un
+playbook che era in esecuzione quando il suo RTE si è riavviato non può continuare: l'app termina il suo job come abbandonato quando l'RTE torna senza di esso.
+
+**Interruzione.** Un'interruzione imposta il flag di interruzione del job, e il nodo dell'app che detiene il socket dell'RTE invia `cancel` entro due secondi. L'RTE
+invia `SIGTERM` al gruppo di processi del playbook, così `ansible-playbook` e ogni fork che ha avviato si fermano insieme, e il job termina
+`aborted`. Un cancel che arriva prima del suo job viene conservato per un minuto, e il job parte allora già interrotto.
+
+**Pulizia.** Appena il processo termina, qualunque sia l'esito, l'RTE rimuove entrambi i file delle extravars (un modulo con `keepExtravars`
+conserva quello visibile, mai quello nascosto), il file degli artifact in `/tmp`, il file di log del job e la cartella dei file propria del job. La
+fine viene salvata una sola volta: un secondo scrittore, come l'app che fa fallire un job che l'RTE ha già terminato, non cambia nulla.
+
+**Un processo per job, non un container per job.** AWX e AAP avviano un nuovo pod o container da un'immagine di execution environment per
+ogni job. AnsibleForms non avvia nulla: il container RTE è già in esecuzione, e ogni job è un processo figlio al suo interno. Un job parte
+senza scaricare un'immagine né pianificare un pod, e AnsibleForms non ha bisogno di diritti sul tuo motore dei container o sul tuo cluster. In cambio, i
+playbook che girano su un RTE ne condividono CPU, memoria, `/tmp`, cartella home e python: dai al container risorse sufficienti per
+`RTE_MAX_JOBS` playbook con i loro fork. Per cambiare ciò che un playbook può usare, cambia l'immagine, non il job.
+
+---
+
+## Il confine di sicurezza
+
+L'RTE esegue codice scritto dagli autori dei moduli, quindi è costruito per contenere il meno possibile:
+
+* **Solo il suo token** : l'RTE non contiene credenziali del database né `ENCRYPTION_SECRET`. Non accetta chiamate se non il socket dell'app, con
+  il suo token, e non ha utenti, accesso né pagine web. Tramite il socket può solo eseguire i job che l'app gli invia, riferire su di essi e
+  chiederne i file: non può creare un job, leggere un altro job o distribuire credenziali
+* **Segreti sigillati** : per eseguire un job, l'RTE non legge mai la tabella delle credenziali né un archivio di segreti. Riceve i segreti dei job che
+  esegue, sigillati solo per il suo token e quell'id di job, così un pacchetto destinato a un altro RTE o a un altro job non si apre, e un byte modificato
+  viene rifiutato
+* **Una connessione verificata** : in uscita, l'RTE verifica il certificato dell'app. In entrata su HTTPS, l'app fissa il certificato proprio dell'RTE
+  quando si unisce, e lo contatta solo quando presenta quello (vedi [Modalità](modes.html#inbound)). Un RTE in entrata su HTTP semplice va
+  su una rete privata, come quella del progetto Docker Compose
+* **Nessun ambiente ereditato** : `ansible-playbook` riceve l'ambiente dell'RTE senza nessuna delle variabili che AnsibleForms legge per sé
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, le `MYSQL_*` e le altre), quindi
+  `lookup('env', ...)` non può raggiungerle. Ciò che imposti per i playbook (`PATH`, proxy, `ANSIBLE_*`) passa così com'è
+* **Nessun template dagli utenti** : {% raw %}un valore di un modulo che contiene `{{`, `{%` o `{#` arriva al playbook come stringa unsafe{% endraw %}
+  che ansible non elabora mai come template, a meno che il modulo non imposti `allowJinjaInExtravars`, e nessuna shell esegue mai la riga di comando
+* **Non root** : l'RTE e i suoi playbook girano come `node` (uid 1000), quindi un playbook può fare ciò che può quell'utente nel container, come
+  leggere i suoi file e la chiave ssh, e niente di più
+
+Tratta il suo container, la sua immagine e il suo ambiente con la stessa cura di quelli dell'app.
+
+---
+
+## Modalità database (deprecata)
+
+L'RTE dalla 7.0 alla 7.2, senza `RTE_MODE`, gira per tutta la 7.x e verrà rimosso nella 8.0.0. Differisce dai passaggi qui sopra in quattro modi:
+
+* **Contiene il database** : le sue impostazioni `DB_*`, e `ENCRYPTION_SECRET` quando si registra da solo
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **La consegna è una chiamata HTTP** : l'app chiama `POST <address>/rte/v1/jobs` con il token e i segreti sigillati, e l'RTE prende in carico
+  il job scrivendo il suo nome su di esso nel database (passaggi 3 e 4)
+* **Scrive l'output da solo** : nel database, a gruppi, senza spool (passaggio 7). Un'interruzione lo raggiunge tramite il flag di interruzione del job,
+  che legge ogni 2 secondi, e una chiamata `/cancel`
+* **Legge i file dal volume dell'app** : ha bisogno dello stesso disco dell'app, come con `RTE_FILES=local`
+
+La sua pagina del runner non ha nessuna delle [impostazioni RTE](../runners/runner-page.html#an-rtes-settings): legge le sue variabili. Per passarlo a una
+modalità socket, vedi [Modalità](modes.html#database-deprecated).
diff --git a/i18n/it/_configure/rte/modes.md b/i18n/it/_configure/rte/modes.md
new file mode 100644
index 0000000..b0e2bca
--- /dev/null
+++ b/i18n/it/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modalità
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Come un RTE comunica con l'app
+{: .no_toc }
+
+In uscita, in entrata o database: chi apre la connessione, e cosa vi passa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: dalla 7.3.0 un RTE comunica con l'app tramite un unico WebSocket e non contiene credenziali del database. Scegli la modalità
+adatta alla rete tra di loro: chi può aprire una connessione verso chi, e attraverso quali proxy e firewall passa.
+
+---
+
+## Le tre modalità
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) sull'RTE dice come raggiunge l'app; il suo runner ha la stessa **Modalità**:
+
+| Modalità | Chi apre la connessione | Cosa contiene l'RTE | Per |
+|---|---|---|---|
+| `outbound` | L'RTE contatta l'app in [`APP_URL`](../customization/server.html#env_APP_URL) e tiene aperto un WebSocket | Il suo `RTE_TOKEN`, nessuna credenziale del database | Una DMZ, un NAT, o una zona che non ammette connessioni in entrata: nulla raggiunge l'RTE dall'esterno |
+| `inbound` | L'app contatta l'RTE all'indirizzo del suo runner e tiene aperto un WebSocket | Il suo `RTE_TOKEN`, nessuna credenziale del database | Una rete in cui il lato centrale apre ogni connessione, un progetto compose, un pod |
+| `database` (deprecata) | L'app chiama l'API dell'RTE via HTTP, e l'RTE legge e scrive da solo nel database dell'app | Le credenziali del database (`DB_*`) ed `ENCRYPTION_SECRET` | Il comportamento dalla 7.0 alla 7.2, rimosso nella 8.0.0 |
+
+Un RTE senza `RTE_MODE` gira in modalità database per tutta la 7.x, e registra un avviso `[DEPRECATED] This RTE runs in database mode` al
+suo avvio. Un runner aggiunto prima della 7.3.0 ha la modalità **Database (deprecato)**; impostala sulla modalità in cui gira il suo RTE quando lo migri.
+
+---
+
+## In uscita
+
+L'RTE apre la connessione, quindi funziona da una rete che non accetta alcuna connessione in entrata:
+
+* **Il socket** : l'RTE contatta `APP_URL` con aggiunto `/api/v2/rte/socket`, su `wss://` (`ws://` per un indirizzo `http://`), con il suo
+  `RTE_TOKEN` e il nome del suo runner, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Ricontatta quando il socket cade
+* **La prima volta** : chiede di unirsi, e il suo runner attende l'approvazione di un admin in **Connessioni > Runner**, connesso
+  ma senza job (vedi [Chiedere di unirsi](../runners/registration.html#asking-to-join)). Un join token,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), lo approva subito. Da quel momento accede con il proprio token
+* **La rete** : solo dalla zona dell'RTE verso l'app, sulla porta dell'app, attraverso un proxy quando `HTTPS_PROXY` lo indica. Un reverse
+  proxy davanti all'app deve far passare il WebSocket su quel percorso (vedi [WebSocket dei runner](../production/reverse-proxy.html#runner-websockets))
+* **Il certificato** : il certificato dell'app viene verificato. Indica una CA privata con `NODE_EXTRA_CA_CERTS`, o, solo all'interno di una rete
+  fidata, disattiva la verifica con [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **Il runner** : non ha bisogno di un indirizzo, quindi la sua credenziale RTE contiene solo il token
+* **Pronto** : `/ready` risponde `503` finché il socket verso l'app non è aperto
+
+Con più nodi dell'app dietro un load balancer, il nodo che l'RTE raggiunge detiene il suo socket. Qualsiasi nodo può avviare un job: il nodo che detiene
+il socket lo invia all'RTE, entro due secondi quando il job è stato avviato su un altro nodo.
+
+---
+
+## In entrata
+
+L'RTE è in ascolto sulla sua `PORT`, e l'app lo contatta all'indirizzo del suo runner, con aggiunto `/rte/v1/socket` e il token dell'RTE. Con
+più nodi dell'app, uno alla volta detiene il socket di ogni runner in entrata; quando quel nodo si ferma, un altro subentra e lo ricontatta.
+
+L'app ha bisogno del runner dell'RTE prima di poterlo contattare: tipo RTE, modalità **In entrata**, e una credenziale RTE con l'indirizzo dell'RTE e il suo
+`RTE_TOKEN`. Ci arriva in uno di due modi:
+
+| Come | Cosa impostare |
+|---|---|
+| L'RTE chiede di unirsi | `APP_URL` e [`RTE_URL`](../customization/server.html#env_RTE_URL) (l'indirizzo che l'app contatta). L'RTE fa una sola chiamata, `POST /api/v2/rte/register`, e il suo runner attende l'approvazione di un admin: l'app lo contatta una volta approvato (vedi [Chiedere di unirsi](../runners/registration.html#asking-to-join)). Con `RTE_JOIN_TOKEN` viene approvato subito. Un RTE in entrata con `APP_URL` ma senza `RTE_URL` si rifiuta di partire |
+| Aggiungi tu il runner | Nessun `APP_URL`: aggiungi il runner in **Connessioni > Runner**, o nel [config seed](../seed/), come in [Eseguire un RTE](run.html#start-it) |
+
+Il progetto Docker Compose, il chart Helm e il controller dell'installer eseguono il proprio RTE in questo modo, in entrata, dichiarato dal seed.
+
+**Su HTTPS.** Con [`HTTPS=1`](../customization/server.html#env_HTTPS) l'RTE serve il suo socket su TLS, con la chiave e il certificato
+di [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) e [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(`key.pem` e `cert.pem` nella sua cartella `certificates` per impostazione predefinita). Un RTE con un `RTE_URL` `https://` invia quel certificato quando
+chiede di unirsi, e l'app lo fissa: contatta l'RTE solo quando presenta lo stesso certificato, quindi uno autofirmato funziona senza una CA.
+L'RTE registra l'impronta del certificato al suo avvio (le prime 8 cifre esadecimali dello SHA-256 dei suoi byte DER, come `abcd-ef12`),
+e la finestra di approvazione mostra quella ricevuta dall'app: verifica che coincidano prima di approvarlo.
+L'[installer](../installation/installer.html#a-runner) configura i suoi Runner in entrata in questo modo, con un certificato del loro indirizzo.
+
+---
+
+## Database (deprecata)
+
+L'RTE dalla 7.0 alla 7.2: l'app chiama la sua API via HTTP, e l'RTE prende in carico il job nel database, vi scrive l'output e mantiene aggiornata la
+propria riga di runner, con [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Modalità database](./#database-mode-deprecated)
+spiega in cosa differiscono i suoi passaggi. Funziona ancora nella 7.x, con un avviso a ogni avvio, e verrà rimossa nella 8.0.0.
+
+Per passare un RTE del genere a una modalità socket, mantieni il suo runner e il suo token:
+
+1. Un runner del [config seed](../seed/): imposta prima `rte_mode: outbound` o `rte_mode: inbound` per esso nel seed (in entrata: con
+   l'indirizzo che l'app contatta nell'`url` della sua credenziale). L'RTE non può spostare da solo un runner del seed
+2. Sull'RTE, imposta `RTE_MODE=outbound` con `APP_URL`, o `RTE_MODE=inbound` (con `APP_URL` e `RTE_URL` per fare la sua unica
+   chiamata di registrazione), e imposta [`RTE_NAME`](../customization/server.html#env_RTE_NAME) con il nome che ha il suo runner in
+   **Connessioni > Runner**. Mantieni il suo `RTE_TOKEN`
+3. Rimuovi `DB_*` ed `ENCRYPTION_SECRET` dal suo ambiente, e `RTE_REGISTER`, che legge solo la modalità database, poi riavvialo
+
+Quando l'RTE aggiornato accede con il nome del runner e il token proprio del runner, l'app sposta subito quel runner nella modalità dell'RTE,
+senza approvazione, e registra *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. Il runner non è più una riga registrata dal suo RTE, quindi il worker non lo rimuove mai quando il vecchio container smette di rispondere. Un
+runner del config seed ancora in modalità database viene invece rifiutato, con *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. Non usare un join token per questo: un join
+token viene rifiutato per un runner già approvato. Un RTE in entrata senza `APP_URL` non fa alcuna chiamata: imposta invece la **Modalità** del suo runner su
+**In entrata** in **Connessioni > Runner**, e l'app lo contatta. L'[installer](../installation/installer.html#a-72-runner)
+aggiorna un Runner della 7.2 in questo modo.
+
+---
+
+## Cosa passa sul socket
+
+In entrambe le modalità socket, l'app invia all'RTE ogni job con tutto ciò che l'RTE leggeva prima nel database, e salva ciò che torna indietro,
+l'output, gli eventi, il log del job e la fine, esattamente una volta. L'app invia anche le notifiche di fine.
+
+**Lo spool.** Ogni gruppo di output, gruppo di eventi, log, inizio e fine viene numerato e scritto nel file di spool del job
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) prima di essere inviato, e conservato finché l'app non dice di averlo salvato.
+Dopo una riconnessione, allo stesso nodo dell'app o a un altro, l'RTE reinvia ciò che non è stato confermato, e l'app salta ciò che ha già
+salvato: nulla va perso, e nulla viene salvato due volte. Tieni lo spool su un volume, così un RTE che si riavvia invia ancora ciò che non aveva
+consegnato. Un playbook che era in esecuzione quando l'RTE si è riavviato non può continuare: il suo job termina come abbandonato.
+
+**Capacità.** L'RTE esegue fino a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbook insieme, o il valore impostato
+nella sua [pagina del runner](../runners/runner-page.html#an-rtes-settings), e dice all'app ogni 20 secondi quanti ne girano. Un job per un RTE
+pieno attende, come descritto in [Più RTE](several.html#several-jobs-on-one-rte).
+
+**I file del job.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES), o l'impostazione **File dei job** della sua pagina del runner, dice
+da dove l'RTE prende i playbook e gli inventari:
+
+| `RTE_FILES` | Da dove arrivano i file |
+|---|---|
+| `transfer` (predefinito) | L'app invia la cartella dei playbook e gli inventari con il job, ognuno impacchettato e identificato da un hash del suo contenuto. L'RTE li conserva impacchettati sotto [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), gli ultimi usati fino a [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (1024 MB per impostazione predefinita), e chiede solo un hash che non ha: una cartella invariata non viene mai inviata due volte. L'RTE non ha bisogno di un disco condiviso né dell'accesso ai repository |
+| `local` | L'RTE gira dalle proprie cartelle, come un RTE in modalità database: monta su di esso i playbook ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) e i repository ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) |
+
+Con `transfer`, ogni job estrae i suoi file in una cartella privata propria, rimossa quando il job termina: nessun job vede ciò che un altro ha
+scritto, e nessun file di inventario o di extravars resta estratto sul disco dell'RTE. Gli RTE possono condividere un `RTE_CACHE_PATH`; ognuno tiene i suoi job in
+una cartella propria, e la cartella di un RTE che si è fermato (ucciso durante un job, o ricreato con un altro hostname) viene rimossa dagli altri
+dopo 10 minuti. Una cartella più grande di [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 per impostazione predefinita, letta
+dall'app, applicata senza riavvio) non viene inviata: il job fallisce e dice di montare invece la cartella sull'RTE. La cartella ssh non viene mai inviata: l'RTE tiene la propria
+chiave privata e il `known_hosts` in `/home/node/.ssh`.
+
+**Host e task.** Dalla 7.3.0, un RTE in qualsiasi modalità registra gli eventi strutturati di un playbook accanto al suo output testuale: ogni play, task e
+risultato per host, e il riepilogo, scritti dal suo plugin di callback `af_events`. La pagina del job li mostra in **Host e task** (vedi
+[Seguire un job](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Rete
+
+Cosa aprire tra l'app, l'RTE e gli host gestiti, per modalità:
+
+| Modalità | Da | A | Porta |
+|---|---|---|---|
+| In uscita | L'RTE | L'app, in `APP_URL` | La porta dell'app (`443` dietro la maggior parte dei proxy) |
+| In entrata | I nodi dell'app | L'RTE, all'indirizzo del suo runner | La `PORT` dell'RTE (`8000`) |
+| Database (deprecata) | L'RTE, e i nodi dell'app e il worker | Il database, e l'RTE | `3306`, e la `PORT` dell'RTE |
+| Ogni modalità | L'RTE | Gli host gestiti | ssh (`22`), WinRM, le loro API |
+
+In una modalità socket l'RTE non si connette mai al database. La sua API risponde solo al socket e alle probe: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/it/_configure/rte/run.md b/i18n/it/_configure/rte/run.md
new file mode 100644
index 0000000..a93213b
--- /dev/null
+++ b/i18n/it/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Eseguire un RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Eseguire un RTE
+{: .no_toc }
+
+Le impostazioni di ogni modalità, e come avviare un RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Impostazioni
+
+Ciò di cui ha bisogno un RTE dipende dalla sua modalità (vedi [Modalità](modes.html)). Ogni RTE legge queste:
+
+| Variabile | Significato |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Dalla 7.3.0: `outbound` (contatta l'app), `inbound` (l'app lo contatta) o `database` (deprecata, la predefinita per tutta la 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Il token tra l'app e l'RTE, di almeno 16 caratteri; l'RTE si rifiuta di partire senza |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quanti playbook esegue insieme, `10` per impostazione predefinita (`0` non imposta alcun limite). Un job per un RTE pieno attende finché un playbook non termina |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | All'arresto, quanto attende i suoi playbook in esecuzione, `25` per impostazione predefinita; quelli ancora in esecuzione terminano allora come abbandonati |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Letta dai nodi dell'app e dal worker, non dall'RTE: quanto attende un job per un RTE pieno o in arresto, `60` per impostazione predefinita |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | La cartella dei playbook e il limite dell'output: le legge l'RTE, quindi impostale nel suo ambiente |
+| `LISTEN_HOST` | Dalla 7.3.0: l'indirizzo su cui si mettono in ascolto i suoi listener, ogni interfaccia per impostazione predefinita; `127.0.0.1` quando nulla lo contatta dall'esterno (un RTE in uscita) |
+
+Un RTE in una modalità socket, `outbound` o `inbound`, legge anche queste, e nessuna `DB_*` né `ENCRYPTION_SECRET`:
+
+| Variabile | Significato |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | L'indirizzo dell'app come lo aprono le persone, come `https://forms.example.com`. In uscita: l'indirizzo che contatta. In entrata: l'indirizzo della sua unica chiamata di registrazione |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (predefinito): il certificato dell'app deve essere valido. `0` accetta qualsiasi certificato, solo all'interno di una rete fidata |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Il nome del suo runner, che i moduli indicano con `runner:`. Se non è impostata: il suo id di nodo, `rte-<hostname>-<port>`, che cambia con il container: impostala in produzione |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Facoltativa, solo la prima volta: un join token, creato tramite l'API, che approva subito il suo runner invece di attendere un admin (vedi [Join token](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | In entrata, quando chiede di unirsi: l'indirizzo che l'app contatta, come `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predefinito): l'app invia i playbook e gli inventari con il job. `local`: gira dalle proprie cartelle montate |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Dove l'output, gli eventi e la fine di ogni job attendono che l'app li abbia salvati, `<persistent>/rte-spool` per impostazione predefinita: tienilo su un volume |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Con `transfer`: dove si conservano le cartelle inviate dall'app, `<persistent>/rte-files` per impostazione predefinita |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Con `transfer`: quanto spazio possono occupare quelle cartelle, `1024` per impostazione predefinita; quelle usate meno di recente se ne vanno per prime, e `0` non ne conserva nessuna |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Letta dall'app, non dall'RTE: la cartella più grande che invia con `transfer`, `512` per impostazione predefinita |
+
+Su un RTE in una modalità socket, `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` e `RTE_CACHE_MB` si possono anche impostare nella sua pagina del runner,
+nella scheda RTE: un valore lì vince sulla variabile, che allora compila solo un campo lasciato vuoto (vedi
+[Le impostazioni di un RTE](../runners/runner-page.html#an-rtes-settings)). Un valore fuori intervallo viene riportato al suo limite, e l'RTE lo segnala
+all'avvio.
+
+Un RTE in modalità database (deprecata) legge invece le impostazioni del database, e si registra da solo:
+
+| Variabile | Significato |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Gli stessi valori dell'app: l'RTE legge i suoi job dal database e vi scrive il loro output |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | L'indirizzo su cui l'app chiama l'RTE, come `http://rte:8000`. Il runner prende il nome del suo host (`rte`), così i moduli possono usare `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Deprecata nella 7.3.0, insieme alla modalità database: un RTE in modalità socket si unisce invece con un join token. `1` (predefinito): l'RTE si aggiunge da solo in **Connessioni > Runner** al suo avvio, e il primo diventa il runner predefinito. `0`: aggiungilo tu lì, o nel [config seed](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Lo stesso valore dell'app, necessario solo per registrarsi da solo (il token del runner viene salvato cifrato); lascialo fuori con `RTE_REGISTER=0` |
+
+In modalità database, senza `RTE_URL` l'RTE registra il suo indirizzo IP e la sua porta con il nome `rte-<hostname>-<port>`, che cambiano quando
+il container viene ricreato: imposta `RTE_URL` in produzione. Il worker rimuove un runner che l'RTE ha registrato da solo 10 minuti dopo
+l'ultimo heartbeat dell'RTE.
+
+---
+
+## Avviarlo
+
+L'RTE esegue i playbook, quindi ha bisogno della sua cartella ssh, con la chiave privata e il `known_hosts` usati dai playbook, e di una cartella
+persistente per il suo spool e i file che l'app invia. Scegli la modalità:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">In uscita</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">In entrata</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Database (deprecato)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Avvia l'RTE su qualsiasi host che raggiunge l'app, con il suo token e il nome che riceve il suo runner:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Contatta l'app e chiede di unirsi: **Connessioni > Runner** mostra il runner `rte-dmz` in attesa di approvazione, e il suo log mostra
+l'impronta del suo token. Verifica che la sua revisione mostri la stessa impronta, poi fai clic su **Approva** (vedi
+[Approvare un RTE](../runners/registration.html#approving-an-rte)): da quel momento riceve job, accedendo con il proprio `RTE_TOKEN`.
+Per un avvio non presidiato, aggiungi `-e RTE_JOIN_TOKEN=<a join token, afj_...>`, che lo approva subito. Nulla deve raggiungere questo
+host: non pubblicare nessuna porta. Sulla sua `PORT` sono in ascolto solo `/live`, `/ready` e `/metrics`, per le probe.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Avvia l'RTE dove l'app lo raggiunge. Questo gira accanto all'app ed esegue i playbook dalle sue cartelle (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Poi dai all'app il suo runner: nel [config seed](../seed/), una credenziale RTE e un runner in entrata che accede con essa:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Oppure aggiungi gli stessi due a mano: la credenziale in **Connessioni > Credenziali**, tipo RTE, e il runner in
+**Connessioni > Runner**, tipo RTE, modalità **In entrata**, con quella credenziale. Per lasciare invece che l'RTE chieda di unirsi, avvialo con
+`APP_URL` e `RTE_URL`, e approvalo in **Connessioni > Runner** (vedi [In entrata](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Deprecata dalla 7.3.0 e rimossa nella 8.0.0. L'RTE esegue i playbook dal proprio disco, quindi monta su di esso anche il volume persistente dell'app
+(playbook, repository, caricamenti) e la sua cartella ssh. Un esempio Docker, con l'app raggiungibile come `ansibleforms` sulla
+stessa rete:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Tieni un RTE in entrata fuori dalla rete pubblica: il suo socket risponde a chiunque abbia il token. `docker stop` attende solo 10 secondi prima
+di uccidere un container, quindi dai all'RTE un timeout di arresto più lungo (`--stop-timeout`, o `stop_grace_period` in compose) o abbassa
+`RTE_DRAIN_SECONDS`. Kubernetes attende 30 secondi per impostazione predefinita.
+
+L'[installer](../installation/installer.html) configura un RTE in uscita o in entrata su un server proprio, con Docker, Podman o
+[senza container](../installation/native.html), e stampa l'impronta con cui approvarlo. Per eseguire a mano un RTE in un altro datacenter,
+segui [Un altro datacenter](another-datacenter.html).
diff --git a/i18n/it/_configure/rte/several.md b/i18n/it/_configure/rte/several.md
new file mode 100644
index 0000000..d3c4d62
--- /dev/null
+++ b/i18n/it/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Più RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Più RTE
+{: .no_toc }
+
+Quanti playbook esegue un RTE, altri RTE come runner o repliche, e cosa succede quando uno si ferma o muore
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Più job su un RTE
+
+Un RTE esegue fino a [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbook in parallelo, 10 per
+impostazione predefinita (`0` non imposta alcun limite). Un job per un RTE pieno non viene preso in carico. In una modalità socket l'app non lo invia finché l'ultimo
+rapporto di salute dell'RTE non mostra uno slot libero, e un RTE pieno o in arresto risponde `refused` perché occupato; in modalità database l'RTE risponde
+`503`. In entrambi i casi l'app scrive `Waiting for a free slot on RTE <name>` una volta nell'output e ripropone il job ogni 10 secondi,
+per al massimo [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) (60 per impostazione predefinita). Poi il job fallisce con
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Un job interrotto mentre attende termina `aborted` senza mai
+raggiungere l'RTE.
+
+---
+
+## Più RTE
+
+L'app non distribuisce da sola i job sui runner: ogni job va a un solo runner, quello che il modulo indica o il
+predefinito. Più container RTE aiutano in due modi:
+
+* **Come runner propri** : ogni RTE ha il suo `RTE_NAME` e si unisce come runner proprio: chiede di unirsi e un admin
+  lo approva, oppure presenta un join token (vedi [Registrazione](../runners/registration.html)). Un modulo ne sceglie uno con `runner: <name>`,
+  per esempio un RTE con le collection VMware, o uno in un'altra zona di rete; gli altri girano sull'RTE predefinito
+* **Come repliche dietro un solo indirizzo** (solo modalità database) : più container RTE con lo stesso `RTE_URL` e lo stesso `RTE_TOKEN`,
+  come i pod dietro un Service di Kubernetes, condividono un runner, e l'indirizzo distribuisce le chiamate tra di loro. Una replica piena risponde
+  `503`, e il tentativo successivo può finire su un'altra. L'app segue un job tramite il database, quindi non importa quale replica
+  risponda alle sue chiamate di stato
+
+In una modalità socket (vedi [Modalità](modes.html)) un runner tiene un socket verso un RTE, e un secondo RTE che accede con lo stesso
+`RTE_NAME` prende il socket al primo. Dai a ogni RTE un nome e un runner propri, e lascia che i moduli scelgano tra di loro con
+`runner:`.
+
+Ogni RTE in modalità database scrive un heartbeat nel database ogni 10 secondi, e uno che si registra da solo controlla la sua riga di runner ogni
+30 secondi. Per un RTE in una modalità socket, il nodo dell'app che detiene il suo socket scrive l'heartbeat per lui ogni 20 secondi, finché il
+socket è aperto. La pagina **Stato** elenca ogni RTE con la sua versione. Il worker rimuove un runner che un RTE in modalità database ha registrato
+da solo quando quell'RTE non scrive un heartbeat da 10 minuti, e quando il runner predefinito è una riga del genere il cui RTE si è fermato, il successivo RTE
+che controlla prende il ruolo di predefinito. Un runner del config seed, aggiunto a mano o unito tramite un socket non viene mai rimosso in quel modo.
+
+---
+
+## Quando un RTE si ferma o muore
+
+**Quando un RTE si ferma.** Con `SIGTERM` (`docker stop`, un rolling update, uno scale down) l'RTE smette di accettare job: `/ready` risponde `503`,
+e un nuovo job viene rifiutato perché occupato (`503` in modalità database), quindi l'app attende, oppure in modalità database l'indirizzo lo manda a un'altra
+replica. I playbook in esecuzione hanno [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) per finire, 25 per impostazione predefinita,
+poi l'RTE esce.
+
+**Quando un RTE muore.** Un container ucciso (memoria esaurita, un nodo perso, la fine del timeout di arresto) si porta via i suoi playbook: niente
+li sposta su un altro RTE, e niente li riesegue. I loro job vengono terminati come `abandoned`, dall'RTE stesso o dall'app quando
+torna con lo stesso id, che un container riavviato mantiene (`rte-<hostname>-<port>`), o dal worker, quando l'heartbeat dell'RTE
+ha due minuti. Verifica sugli host gestiti cosa ha fatto il playbook prima di avviarlo di nuovo.
+
+**Mentre un RTE è giù.** In una modalità socket un nuovo job per lui attende il suo socket, fino a `RTE_QUEUE_MINUTES` più un minuto, poi
+fallisce con *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+In modalità database fallisce subito con *the RTE at ... is unreachable*, a meno che un'altra replica non risponda al suo indirizzo.
diff --git a/i18n/it/_configure/runners.md b/i18n/it/_configure/runners.md
new file mode 100644
index 0000000..1b85f09
--- /dev/null
+++ b/i18n/it/_configure/runners.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Runner
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runner
+{: .no_toc }
+
+Dove girano i job: container di ambienti di esecuzione per i playbook, e AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins per i template
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: aggiungi i runner su cui girano i tuoi job, scegli il predefinito di ogni tipo, approva gli RTE che chiedono di unirsi, provali.
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [La pagina dei runner](runners/list.html) | La lista dei runner, come aggiungerne uno, attivarlo o disattivarlo, e il predefinito di ogni tipo |
+| [Tipi di runner](runners/types.html) | I prodotti che un runner può essere, il loro indirizzo e il loro accesso |
+| [Registrazione](runners/registration.html) | Come un RTE chiede di unirsi e viene approvato, i join token per le installazioni non presidiate, e la modalità database |
+| [La pagina di un runner](runners/runner-page.html) | Le schede di un runner, la modalità e la connessione di un RTE, e Testa connessione |
+| [Chi gestisce i runner](runners/permissions.html) | Chi può aggiungere, modificare e provare i runner |
+
+
+---
+
+## Come funziona
+
+Dalla versione 7 l'app non esegue nulla da sola: ogni job gira su un **runner**, aggiunto in **Connessioni > Runner**.
+Il tipo di un modulo decide di quale tipo di runner ha bisogno:
+
+| Tipo di modulo | Gira su un runner di tipo | Cosa gira |
+|---|---|---|
+| `ansible` | RTE | Un playbook, in un container di ambiente di esecuzione |
+| `awx`, `aap`, `ascender` | AWX (le varianti AWX, AAP e Ascender) | Un job template o un workflow template |
+| `semaphore` | Semaphore | Un template di Semaphore UI |
+| `rundeck` | Rundeck | Un job di Rundeck |
+| `jenkins` | Jenkins | Un job di Jenkins |
+
+Un modulo `workflow` o `subform` non ha un runner proprio: ogni nodo di un [workflow](workflows/) sceglie il suo. Un nodo
+con un `runner:` gira su quel runner (un RTE, o un template o un job su AWX, Semaphore, Rundeck o Jenkins), ogni altro
+sull'RTE predefinito, quindi i nodi di uno stesso job possono girare su runner diversi. Il modulo `multistep`, deprecato dalla 7 e
+sostituito dai workflow, funziona allo stesso modo: ognuno dei suoi passaggi gira sul runner richiesto dal proprio tipo.
+
+Un modulo sceglie il suo runner in uno di due modi:
+
+- **Per nome**: `runner: <name>` sul modulo, su un nodo di workflow, o su un passaggio di un multistep deprecato (anche nelle
+  impostazioni del modulo nel designer). Il runner deve essere del tipo richiesto dal modulo, altrimenti il job fallisce. Il vecchio `awx: <name>`
+  funziona ancora, registra un avviso di deprecazione, e sparirà nella 8.
+- **Come predefinito**: un modulo che non indica nessun runner gira sul runner predefinito del suo tipo. Senza, il job fallisce
+  con un messaggio che dice quale tipo di runner aggiungere.
+
+Un runner disattivato in **Connessioni > Runner** non riceve nessun job, né per nome né come predefinito: il job fallisce e dice di attivarlo
+o di indicare un altro runner (vedi [Predefinito e Abilitato](runners/list.html#default-and-enabled)).
diff --git a/i18n/it/_configure/runners/list.md b/i18n/it/_configure/runners/list.md
new file mode 100644
index 0000000..e0b094f
--- /dev/null
+++ b/i18n/it/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: La pagina dei runner
+parent: Runner
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# La pagina dei runner
+{: .no_toc }
+
+La lista dei runner, come aggiungerne uno, attivarlo o disattivarlo, e il predefinito di ogni tipo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La lista
+
+La pagina in **Connessioni > Runner** elenca ogni runner con queste colonne:
+
+| Colonna | Significato |
+|---|---|
+| Abilitato | Se riceve job. Un runner disattivato non riceve nessun job, nemmeno come predefinito del suo tipo. |
+| Nome | Come lo indicano i moduli, con `runner: <name>`. |
+| Tipo | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck o Jenkins. Il runner predefinito del suo tipo ha una pillola **Predefinito** dopo di esso. |
+| Descrizione | A cosa serve. |
+
+**Colonne** ne aggiunge altre due, disattivate per impostazione predefinita: **Modalità**, la modalità di un RTE (In uscita, In entrata o Database (deprecato), vedi
+[Modalità](../rte/modes.html)), e **Connessione**, se un nodo dell'app detiene un socket verso un RTE in una modalità socket: **Connesso** o
+**Non connesso**.
+
+Dalla 7.3.0 i runner in attesa di approvazione non sono nella lista ma in un avviso sopra di essa, vedi [Approvare un RTE](registration.html#approving-an-rte).
+**Aggiungi runner** apre una finestra di dialogo a passaggi: **Runner** (nome e descrizione), **Tipo** e **Credenziali**, con un passaggio **Modalità** dopo
+**Tipo** per un RTE (In uscita, il predefinito per uno nuovo, In entrata o Database (deprecato)): quattro passaggi per un RTE, tre per gli
+altri. Nel passaggio **Tipo** ogni prodotto ha un suggerimento: quello dell'RTE ne dà il nome completo, *Ambiente di esecuzione*. Una riga apre la pagina
+del runner, e il suo menu offre:
+
+| Azione | Cosa fa |
+|---|---|
+| Modifica | Apre la sua pagina |
+| Testa connessione | Verifica che risponda e accetti la sua credenziale, vedi [Testa connessione](runner-page.html#test-connection) |
+| Attiva, Disattiva | Lo attiva o lo disattiva, a seconda di com'è |
+| Modifica credenziali | Apre la scheda Credenziali della sua pagina |
+| Elimina | Lo rimuove |
+
+---
+
+## Predefinito e Abilitato
+
+Il predefinito di ogni tipo è dove girano i moduli di quel tipo quando non indicano nessun runner:
+
+| Predefinito per | Dove girano questi moduli quando non indicano nessun runner |
+|---|---|
+| Form playbook | I moduli `ansible`, su un RTE |
+| Form AWX, AAP e Ascender | I moduli `awx`, `aap` e `ascender`, su un runner AWX |
+| Form Semaphore | I moduli `semaphore` |
+| Form Rundeck | I moduli `rundeck` |
+| Form Jenkins | I moduli `jenkins` |
+
+Il primo runner di un tipo diventa il suo predefinito, quindi un solo runner per tipo non richiede passaggi aggiuntivi. Per rendere predefinito un altro runner,
+attiva l'interruttore **Predefinito** nella sua pagina (vedi [La pagina di un runner](runner-page.html)).
+
+Un runner disattivato resta nella lista con le sue impostazioni, ma nessun job va a lui, nemmeno come predefinito del suo tipo. Un job per lui fallisce con
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Attivalo o disattivalo con **Attiva** o **Disattiva** nel menu della sua riga, o con l'interruttore **Abilitato** nella sua pagina. Un nuovo runner è attivo, e i
+runner che esistevano prima della 7.3.0 sono attivi dopo l'aggiornamento. Il [config seed](../seed/example.html) può disattivarne uno con
+`enabled: false`.
diff --git a/i18n/it/_configure/runners/permissions.md b/i18n/it/_configure/runners/permissions.md
new file mode 100644
index 0000000..91ab4de
--- /dev/null
+++ b/i18n/it/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Chi gestisce i runner
+parent: Runner
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Chi gestisce i runner
+{: .no_toc }
+
+Chi può aggiungere, modificare e provare i runner
+{: .fs-6 .fw-300 }
+
+Un runner riceve le credenziali di ogni job che esegue, quindi solo il ruolo **admin** aggiunge, modifica, attiva o disattiva ed elimina i runner,
+e approva o rifiuta un RTE che ha chiesto di unirsi. Gli utenti con accesso alle impostazioni li vedono e possono provarli, ma non possono modificarli.
+
+Un runner dichiarato nel [config seed](../seed/) è in sola lettura in questa pagina: modificalo invece nel file del seed.
diff --git a/i18n/it/_configure/runners/registration.md b/i18n/it/_configure/runners/registration.md
new file mode 100644
index 0000000..9ae151b
--- /dev/null
+++ b/i18n/it/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Registrazione
+parent: Runner
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Registrazione
+{: .no_toc }
+
+Come un RTE chiede di unirsi e viene approvato, i join token per le installazioni non presidiate, e la modalità database
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Chiedere di unirsi
+
+Dalla 7.3.0, un RTE in una modalità socket (`outbound` o `inbound`) che l'app non conosce ancora chiede di unirsi, e un admin lo approva.
+Si presenta con il proprio `RTE_TOKEN` e il suo `RTE_NAME`: un RTE in uscita quando contatta l'app la prima volta, uno in entrata nella sua unica
+chiamata di registrazione. Senza un join token, l'app allora:
+
+1. Salva l'`RTE_TOKEN` dell'RTE in una nuova credenziale di tipo RTE chiamata `<name>-rte` (con un numero aggiunto quando quel nome è già in uso), e
+   per un RTE in entrata il suo indirizzo, `RTE_URL`
+2. Aggiunge un runner chiamato come `RTE_NAME`, tipo RTE, nella modalità dell'RTE, che accede con quella credenziale, contrassegnato come **In attesa di approvazione**
+   e disattivato. La sua descrizione indica l'host da cui ha fatto la richiesta
+
+Un RTE in uscita resta connesso mentre attende, ma non riceve job. L'app non contatta uno in entrata finché non è approvato. Entrambi registrano
+che attendono l'approvazione di un admin in **Connessioni > Runner**, con l'impronta del loro token.
+
+Un RTE in entrata con un `RTE_URL` `https://` invia anche il suo certificato quando chiede di unirsi, e l'app lo fissa: da quel momento
+l'app contatta quell'RTE solo quando presenta lo stesso certificato, quindi uno autofirmato funziona senza una CA (vedi [In entrata](../rte/modes.html#inbound)).
+
+Al massimo 20 RTE possono attendere l'approvazione contemporaneamente: gli altri vengono rifiutati finché alcuni non vengono approvati o rifiutati. Una richiesta che nessuno gestisce entro
+24 ore viene rimossa dal worker, con la sua credenziale.
+
+Un RTE che porta il nome di un runner che l'app conosce già, ma con un altro token, viene rifiutato e non chiede di unirsi. Dagli il token di quel runner,
+o elimina il runner così che chieda di unirsi. Un [join token](#join-tokens) aiuta solo finché quel runner attende ancora l'approvazione.
+
+---
+
+## Approvare un RTE
+
+I runner in attesa di approvazione lasciano la lista di **Connessioni > Runner** per un avviso arancione sopra di essa, come
+**2 Runner attendono l'approvazione**, con una riga per runner: il suo nome, host, indirizzo IP, modalità, indirizzo e impronta.
+La campanella dell'intestazione li conta, per gli utenti che possono vedere i runner (vedi [la campanella](../jobs/#the-jobs-page)).
+
+Un clic sull'avviso apre la finestra **Esamina approvazione** per ogni runner a turno; un clic su un nome apre solo quello.
+La sua pagina mostra gli stessi dati in un riquadro giallo, **Questo RTE ha chiesto di unirsi**. Verifica che sia uno che hai avviato tu prima di approvarlo:
+
+| Campo | Cosa mostra |
+|---|---|
+| Impronta | Le prime 8 cifre esadecimali dello SHA-256 del suo `RTE_TOKEN`, come `abcd-ef12`. L'RTE la registra al suo avvio, e l'[installer](../installation/installer.html#a-runner) la stampa alla fine. Deve essere la stessa |
+| Impronta del certificato | Nella finestra di dialogo, per un RTE in entrata su HTTPS: le prime 8 cifre esadecimali dello SHA-256 del certificato che l'app fissa (i suoi byte DER), come `abcd-ef12`. L'RTE la registra al suo avvio e l'[installer](../installation/installer.html#a-runner) la stampa alla fine. Deve essere la stessa |
+| Host | L'host su cui gira |
+| Indirizzo IP | L'indirizzo da cui ha chiamato l'app |
+| Modalità | In uscita o In entrata |
+| URI | L'indirizzo di un RTE in entrata, dove l'app lo contatta |
+| Versione | La sua versione |
+| Richiesto il | Quando ha chiesto di unirsi |
+
+**Approva** e **Rifiuta**, nella finestra di dialogo o nel riquadro della sua pagina, decidono:
+
+| Azione | Cosa succede |
+|---|---|
+| Approva | Il runner viene abilitato e riceve job da quel momento. Diventa il predefinito del suo tipo quando non ce n'è uno |
+| Rifiuta | Il runner viene rimosso con la sua credenziale, e il suo socket viene chiuso. L'RTE può chiedere di nuovo di unirsi; allora attende di nuovo l'approvazione |
+
+Solo un admin approva o rifiuta un RTE.
+
+---
+
+## Join token
+
+Un join token approva subito un RTE, per le installazioni non presidiate: un RTE avviato con
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), o un Runner installato con il `--join` dell'installer, lo presenta una volta
+e il suo runner viene aggiunto abilitato, senza attendere. I join token non hanno una pagina nell'interfaccia: un admin li crea tramite
+l'[API REST](../api/), sotto `/api/v2/runner`:
+
+| Chiamata | Cosa fa |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Crea un join token. Il corpo contiene il suo `name`, e facoltativamente `expiresInHours` (nessuno: non scade mai) e `maxUses` (nessuno: qualsiasi numero di RTE) |
+| `GET /api/v2/runner/jointoken` | Elenca i join token, dal più recente, con i loro utilizzi e se sono ancora utilizzabili; mai i token stessi |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Lo revoca: non aggiunge più nessun runner, e resta nella lista |
+| `DELETE /api/v2/runner/jointoken/<id>` | Lo elimina |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+La risposta contiene il token, che inizia con `afj_`, solo questa volta: viene salvato solo il suo SHA-256. Un RTE che lo presenta riceve la stessa
+credenziale e lo stesso runner di uno che [chiede di unirsi](#asking-to-join), abilitato, e la sua descrizione indica il join token. Da quel momento
+l'RTE accede con il proprio token, quindi il join token può scadere o essere revocato senza effetti su di esso. Revocare o eliminare un join token
+lascia i runner che ha aggiunto.
+
+Un join token non dà mai un nuovo token a un runner approvato. Quando esiste già un runner RTE con quel nome:
+
+| Il runner | Cosa succede |
+|---|---|
+| Attende l'approvazione | Riceve il nuovo token nella sua credenziale, e attende ancora l'approvazione di un admin |
+| È approvato | Rifiutato con `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. Il join token non viene consumato |
+| Viene dal [config seed](../seed/) | Rifiutato: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Un RTE reinstallato con un nuovo token accede quindi con il token della credenziale del suo runner, oppure un admin cambia quel token
+in **Connessioni > Credenziali**, o elimina il runner così che l'RTE si unisca come nuovo.
+
+---
+
+## Registrazione in modalità database
+
+Un RTE in modalità database, deprecata dalla 7.3.0, si registra da solo per impostazione predefinita, al suo `RTE_URL` o altrimenti al proprio indirizzo e porta. Il
+worker rimuove un runner del genere quando il suo RTE non scrive un heartbeat da 10 minuti. Un runner aggiunto a mano, dal config seed o da un
+RTE in una modalità socket non viene mai rimosso in quel modo.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), che attiva o disattiva questa registrazione, è deprecata nella 7.3.0 insieme alla
+modalità database: un RTE in una modalità socket chiede di unirsi, o si unisce con un join token. Per gestire tu questi runner nel frattempo, avvia
+l'RTE con `RTE_REGISTER=0` e aggiungilo qui con tipo RTE, modalità **Database (deprecato)**, e una credenziale RTE con il suo indirizzo e lo
+stesso token. Per passarlo a una modalità socket, vedi [Modalità](../rte/modes.html#database-deprecated).
diff --git a/i18n/it/_configure/runners/runner-page.md b/i18n/it/_configure/runners/runner-page.md
new file mode 100644
index 0000000..db4b230
--- /dev/null
+++ b/i18n/it/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "La pagina di un runner"
+parent: Runner
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# La pagina di un runner
+{: .no_toc }
+
+Le schede di un runner, la modalità, la connessione e le impostazioni di un RTE, e Testa connessione
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Schede
+
+La pagina di un runner mostra i passaggi della sua finestra di dialogo come schede, più ciò che gira su di esso:
+
+| Scheda | Cosa contiene |
+|---|---|
+| Dettagli | Il nome e la descrizione, l'interruttore **Predefinito** e l'interruttore **Abilitato**, uguali per ogni tipo di runner |
+| Tipo | Il prodotto, come nella finestra di dialogo. Per un RTE anche la sua **Modalità**: **Database (deprecato)**, **In entrata** o **In uscita**, l'`RTE_MODE` con cui gira il suo RTE (vedi [Modalità](../rte/modes.html)) |
+| RTE | Solo per un RTE: la sua **Modalità** a parole e, in una modalità socket, la sua **Connessione** e le sue impostazioni (vedi [Le impostazioni di un RTE](#an-rtes-settings)) |
+| Credenziali | La **Credenziale** con cui accede, una credenziale di Connessioni > Credenziali del tipo del runner, che contiene il suo token o accesso e l'indirizzo del suo server. Quella di un RTE contiene il suo `RTE_TOKEN`, e l'indirizzo dell'RTE a meno che non sia in uscita. **Progetto** per Semaphore, Rundeck e Jenkins |
+| Moduli | I moduli che girano su di esso, e come: **Lo nomina** o **Come runner predefinito**. Una riga apre il modulo |
+| Job | Gli ultimi 100 job che sono girati su di esso, con il loro stato, inizio, fine e durata. Una riga apre il job |
+
+Ogni scheda ha il suo indirizzo, come `/settings/runners/<id>/rte`, così un collegamento o un segnalibro la apre. Un runner senza quella scheda si apre su
+Dettagli.
+
+I due interruttori della scheda Dettagli vengono salvati subito. **Predefinito** rende il runner il predefinito del suo tipo; si disattiva rendendo
+predefinito un altro runner. **Abilitato** attiva o disattiva il runner: se è disattivato, nessun job va a lui, nemmeno come predefinito del suo tipo (vedi
+[Predefinito e Abilitato](list.html#default-and-enabled)).
+
+Un RTE che ha chiesto di unirsi si apre con un riquadro giallo, **Questo RTE ha chiesto di unirsi**, con la sua impronta e ciò che ha detto di sé, e
+**Approva** e **Rifiuta** (vedi [Approvare un RTE](registration.html#approving-an-rte)). Un runner del [config seed](../seed/) lo indica
+in cima alla sua pagina, ed è in sola lettura.
+
+---
+
+## Le impostazioni di un RTE
+
+La scheda RTE gestisce un RTE dall'app, senza modificarne l'ambiente sulla macchina su cui gira.
+
+**Connessione.** Un RTE in una modalità socket mostra un badge: **Connesso** o **Non connesso**. Al passaggio del puntatore, **Connesso** mostra il nodo dell'app
+che detiene il suo socket, la versione dell'RTE, e quanti dei suoi job sono in esecuzione. **Non connesso** significa che nessun nodo dell'app detiene un socket verso di esso:
+verifica che l'RTE sia in esecuzione, il suo indirizzo o `APP_URL`, e il suo token.
+
+**Impostazioni.** Un RTE in modalità in uscita o in entrata ha quattro impostazioni, ognuna vuota per impostazione predefinita:
+
+| Impostazione | Equivale a | Cosa fa |
+|---|---|---|
+| Job simultanei max | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quanti playbook esegue insieme, `10` per impostazione predefinita; `0` non imposta alcun limite |
+| Cache dei file | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Quanto dei file dei job inviati dall'app conserva, in MB, `1024` per impostazione predefinita; `0` non ne conserva nessuno |
+| Attesa allo stop | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Quanto attende un RTE in arresto i suoi playbook in esecuzione, `25` secondi per impostazione predefinita |
+| File dei job | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Trasferimento**: l'app invia i file di un job con il job. **Locale**: gira dalle proprie cartelle montate |
+
+**Quale valore vince.** Un valore nella pagina vince sulla stessa variabile impostata sull'RTE. Un campo lasciato vuoto usa la variabile propria dell'RTE,
+altrimenti il valore predefinito. Sotto ogni campo la pagina dice quale: **Sostituisce RTE_MAX_JOBS impostata sull'RTE (3)**, o **Vuoto: l'RTE usa la propria
+RTE_MAX_JOBS, 3**; il segnaposto mostra il valore che rappresenta un campo vuoto.
+
+**Come arrivano all'RTE.** Le impostazioni vengono salvate con il runner nel database dell'app. L'app le invia tramite il socket dell'RTE
+quando si connette e ogni volta che vengono salvate, e l'RTE le applica subito: una cache più piccola viene ridotta, un nuovo limite conta dal
+job successivo. L'RTE le tiene solo in memoria e non scrive nessun file: dopo un riavvio le riceve di nuovo quando si connette, prima del suo primo job.
+
+Un RTE in modalità database (deprecata) non ha un socket: legge queste impostazioni dalle proprie variabili, e la scheda lo dice.
+
+---
+
+## Testa connessione
+
+I pulsanti in alto a destra agiscono sul runner così come è salvato.
+
+Accanto a **Salva** ci sono **Testa connessione** ed **Elimina**, e nella scheda Credenziali **Aggiungi credenziale**, che crea una credenziale del
+tipo del runner e la sceglie. Un token o una password, una volta salvati, non vengono più mostrati: cambiali sulla credenziale.
+
+**Testa connessione** verifica che il runner risponda e accetti il suo token o accesso, e lo dice in un messaggio: **Runner connection is
+OK**, o perché non è riuscito. Non esegue nessun job. Per un RTE verifica anche il contratto che parla l'RTE (vedi
+[Il contratto](../rte/images.html#the-contract)):
+
+| RTE | Cosa legge il test | Quando fallisce |
+|---|---|---|
+| In uscita o In entrata | Chi detiene il suo socket, come lo registra ogni nodo dell'app, e ciò che l'RTE ha detto quando si è connesso. Non chiama nulla | Nessun nodo dell'app detiene un socket verso di esso: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, o per uno in entrata, *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Oppure l'RTE parla un contratto diverso da 3 |
+| Database (deprecato) | Il `/rte/v1/health` dell'RTE, chiamato con il suo token | L'RTE non risponde al suo indirizzo, rifiuta il token, o parla un contratto diverso da 2 |
+
+Il badge **Connessione** della scheda RTE mostra lo stesso stato del socket senza un test.
diff --git a/i18n/it/_configure/runners/types.md b/i18n/it/_configure/runners/types.md
new file mode 100644
index 0000000..a4d79ff
--- /dev/null
+++ b/i18n/it/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Tipi di runner
+parent: Runner
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Tipi di runner
+{: .no_toc }
+
+I prodotti che un runner può essere, il loro indirizzo e il loro accesso
+{: .fs-6 .fw-300 }
+
+Il passaggio **Tipo** offre una scelta per prodotto, ognuna con un suggerimento; quello dell'RTE ne scrive il nome per esteso, *Ambiente di esecuzione*. AAP e
+Ascender sono salvati come runner di tipo `awx` con una variante (`aap` o `ascender`), che è anche ciò che usa il config seed:
+
+| Tipo | Esempio di URI | Progetto | Autenticazione |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | Il `RTE_TOKEN` dell'RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Un token API, o un utente e una password |
+| Ascender | `https://ascender.example.com/api/v2` | | Un token API, o un utente e una password |
+| AWX | `https://awx.example.com/api/v2` | | Un token API, o un utente e una password |
+| Jenkins | `https://jenkins.example.com` | La cartella in cui si trovano i job (facoltativa) | Un utente e il token API di quell'utente |
+| Rundeck | `https://rundeck.example.com` | Il nome del progetto | Il token API di un utente |
+| Semaphore | `https://semaphore.example.com` | L'id del progetto, il numero in `/project/<id>` | Il token API di un utente |
+
+Un indirizzo AWX, AAP o Ascender porta il suo percorso API: `/api/v2`, o `/api/controller/v2` per AAP 2.5 e successive.
+Un RTE è l'immagine di AnsibleForms avviata con `AF_ROLE=rte`; come eseguirne uno è descritto in
+[Ambienti di esecuzione](../rte/).
diff --git a/i18n/it/_configure/secret-stores/cyberark.md b/i18n/it/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..3fdd25b
--- /dev/null
+++ b/i18n/it/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Archivi di segreti
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Leggi le credenziali dal CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Sperimentale.** Non ancora testato su un'installazione CyberArk reale; segnala ciò che riscontri.
+
+Il CCP è l'interfaccia REST dell'Application Access Manager di CyberArk.
+
+---
+
+## Campi dell'archivio
+
+Oltre ai [campi che ha ogni archivio](./#adding-a-store), un archivio CyberArk ha questi campi:
+
+| Campo | Significato |
+|---|---|
+| Credenziale | Una credenziale **CyberArk** di [Connessioni > Credenziali](../credentials.html): l'URL di base del CCP, es. `https://ccp.example.com` (viene aggiunto `/AIMWebService/api/Accounts`), le sue impostazioni TLS, il suo AppID (l'applicazione definita per AnsibleForms in CyberArk), e un certificato client e una chiave in PEM, solo quando l'AppID li richiede. |
+
+---
+
+## Riferimento al segreto
+
+Il riferimento al segreto identifica l'account come coppie chiave-valore separate da `;`:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Chiavi ammesse: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` passa il resto del riferimento come query CCP nativa, con `QueryFormat=Exact`
+  a meno che tu non lo imposti diversamente.
+- Un `AppID` nel riferimento viene ignorato: si usa sempre l'AppID dell'archivio.
+- La password dell'account (`Content`) diventa la password; `UserName`, `Address`, `Port` e
+  `Database` compilano utente, host, porta e nome del database.
+
+---
+
+## Opzioni aggiuntive
+
+Le opzioni aggiuntive dell'archivio si impostano come oggetto JSON:
+
+| Chiave | Significato |
+|---|---|
+| `reason` | Inviato come `Reason` quando il riferimento non ne ha uno, per l'audit di CyberArk. |
+| `check_ref` | Un riferimento che **Testa connessione** legge davvero. Senza, il test verifica solo che il CCP risponda e accetti l'AppID. |
+| `timeout_ms` | Timeout della richiesta, predefinito 10000. |
+
+Per esempio, per inviare un motivo e far leggere a **Testa connessione** un account di prova:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/it/_configure/secret-stores/hashicorp-vault.md b/i18n/it/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..c8ea700
--- /dev/null
+++ b/i18n/it/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Archivi di segreti
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Leggi le credenziali da HashiCorp Vault, da KV v1 o v2 o da un motore di segreti dinamici
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Campi dell'archivio
+
+Oltre ai [campi che ha ogni archivio](./#adding-a-store), un archivio HashiCorp Vault ha questi campi:
+
+| Campo | Significato |
+|---|---|
+| Credenziale | Una credenziale **HashiCorp Vault** di [Connessioni > Credenziali](../credentials.html): l'indirizzo del Vault, le sue impostazioni TLS, e il token come password, con accesso in lettura ai percorsi usati dalle tue credenziali. **Aggiungi credenziale** ne crea una di quel tipo. AnsibleForms non rinnova il token. |
+| Namespace | Il namespace di Vault Enterprise, inviato come `X-Vault-Namespace`. Mostrato quando **Vault Enterprise** è attivato, nel passaggio **Tipo**. |
+| Versione KV | `2` (predefinito) o `1`. |
+| Mount predefinito | Usato per un riferimento senza slash, es. `myapp` diventa `secret/data/myapp`. |
+
+Il riferimento al segreto è il percorso, es. `secret/myapp/prod`. Per KV v2 il segmento `/data/`
+viene inserito quando lo ometti.
+
+---
+
+## Credenziali dinamiche per database
+
+Un riferimento della forma `<mount>/creds/<role>`, es. `database/creds/readonly`, legge da un
+motore di segreti dinamici come il motore database di Vault. Vault crea allora un nuovo account
+di database per ogni lettura, valido per la durata del lease.
+
+- Un account viene riutilizzato per l'80% del suo lease, non per il tempo di cache; con cache `0`, ogni query ne legge uno nuovo.
+- Vault restituisce solo un utente e una password: metti il resto della connessione nella riga della credenziale.
+- Il lease non viene mai revocato in anticipo; l'account scade quando Vault termina il lease.
diff --git a/i18n/it/_configure/secret-stores/index.md b/i18n/it/_configure/secret-stores/index.md
new file mode 100644
index 0000000..45b6725
--- /dev/null
+++ b/i18n/it/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Archivi di segreti
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Archivi di segreti
+{: .no_toc }
+
+Leggi le credenziali da un gestore di segreti invece di salvarle in AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: collega un gestore di segreti, e lascia che le credenziali ne leggano l'utente e la password.
+
+---
+
+## Come funziona
+
+Un **archivio di segreti** è una connessione a un gestore di segreti, aggiunta in
+**Connessioni > Archivi di segreti**. Una **credenziale** può allora indicare un archivio e un punto al suo interno
+(il *riferimento al segreto*). Quando un modulo, un playbook o un'espressione usa quella credenziale:
+
+- **utente** e **password** vengono letti dall'archivio, ogni volta (entro il tempo di cache dell'archivio);
+- **host**, **porta** e **database** restano quelli della riga della credenziale. Quando la riga lascia
+  vuoto uno di essi e il segreto lo contiene, si usa il valore del segreto.
+
+I moduli continuano a indicare la credenziale per nome, quindi spostare una password in un archivio non cambia
+nulla nei tuoi moduli.
+
+| Tipo di archivio | Stato |
+|---|---|
+| HashiCorp Vault (KV v1 e v2, autenticazione con token) | disponibile |
+| Credenziali dinamiche di HashiCorp Vault (`<mount>/creds/<role>`) | sperimentale |
+| CyberArk Central Credential Provider (CCP) | sperimentale |
+
+---
+
+## Aggiungere un archivio
+
+Dalla 7.3.0 solo un admin può aggiungere, modificare o eliminare un archivio, perché il suo token o la sua chiave vengono inviati al suo indirizzo. Ogni archivio ha questi campi:
+
+| Campo | Significato |
+|---|---|
+| Nome | Come le credenziali indicano l'archivio. |
+| Tipo | Il gestore di segreti. |
+| Credenziale | Come e dove accede l'archivio: una credenziale di [Connessioni > Credenziali](../credentials.html), nel passaggio **Credenziali**, di tipo **HashiCorp Vault** (il suo token e il suo indirizzo) o **CyberArk**. Contiene l'URL di base, es. `https://vault.example.com:8200`, e le impostazioni TLS: salta la verifica del certificato, o un Bundle CA in PEM per una CA privata. Non può leggere a sua volta da un archivio di segreti. |
+| Cache (secondi) | Per quanto tempo un segreto letto viene riutilizzato. `0` lo legge a ogni utilizzo. Predefinito 60. |
+| Opzioni aggiuntive (JSON) | Opzioni specifiche del tipo, come oggetto JSON. |
+
+Fino alla 7.2.0 l'indirizzo, il token e le impostazioni TLS erano campi dell'archivio. L'aggiornamento alla 7.3.0 li sposta nella sua
+credenziale, chiamata `<store>-token` (o `<store>-appid` per CyberArk), vedi [Indirizzi nelle credenziali](../credentials/types.html#addresses-in-credentials).
+
+**Testa connessione** verifica l'accesso senza leggere un segreto. La pagina **Stato** verifica ogni archivio, e avvisa 7 giorni
+prima che scada un token Vault.
+
+Ogni gestore di segreti ha una pagina propria:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 e v2 con autenticazione con token, e credenziali dinamiche per database |
+| [CyberArk](cyberark.html) | Il Central Credential Provider (CCP) dell'Application Access Manager di CyberArk |
+
+---
+
+## Usare un archivio
+
+### In una credenziale
+
+In **Connessioni > Credenziali**, nel passaggio **Archivio** della credenziale, scegli **Archivio di segreti**, poi scegli
+l'**Archivio di segreti** e compila il **Riferimento**. L'utente e la password vengono allora letti dall'archivio, non digitati.
+
+### In linea, senza una riga di credenziale
+
+Ovunque sia accettato il nome di una credenziale, puoi invece indicare direttamente un archivio (`fnCredentials`, `fnRestBasic`,
+le `credentials:` di un modulo, il `dbConfig` di una query).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Senza una riga di credenziale, un segreto di database richiede almeno un `db_type` e un host, per esempio:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Senza `db_type`, il segreto è una credenziale semplice (utente, password e qualsiasi altra chiave), e una query su di esso presume `mysql`.
+
+### Nomi delle chiavi
+
+Un segreto viene associato a una credenziale con questi alias. Le altre chiavi vengono passate così come sono.
+
+| Campo della credenziale | Chiavi accettate nel segreto |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | stesso nome (solo segreti in linea) |
+
+Per una riga di credenziale, host, porta e nome del database del segreto si usano solo dove la
+riga li lascia vuoti.
+
+Un segreto con una struttura diversa si può rimodellare con un'espressione `jq`, passata come terzo argomento di
+`fnCredentials`:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## Nel config seed
+
+Gli archivi si possono dichiarare anche nel config seed, come gli altri oggetti di amministrazione:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+L'archivio accede con la sua credenziale: una `vault` contiene l'indirizzo del Vault in `url` e il token come password, una `cyberark`
+l'AppID e l'indirizzo del CCP. Senza una credenziale, si usano l'`url` e il `token` propri dell'archivio.
+Per i dettagli, vedi [Config seed](../seed).
+
+---
+
+## Aggiornare dalle variabili VAULT_*
+
+Prima della 7 l'unico archivio era un HashiCorp Vault configurato con le variabili d'ambiente
+`VAULT_*`, e una credenziale vi puntava con **Vault path**.
+
+- **Le variabili vengono importate una volta** come archivio chiamato `vault`; rimuovile dopo.
+- **Le credenziali con un `vault_path`** ora usano quell'archivio; `vault_path` sparirà nella 8.
diff --git a/i18n/it/_configure/security/hardening.md b/i18n/it/_configure/security/hardening.md
new file mode 100644
index 0000000..e168a8b
--- /dev/null
+++ b/i18n/it/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Hardening
+parent: Sicurezza
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Hardening
+{: .no_toc }
+
+L'account admin, i limiti di accesso, il database, le espressioni, i dati dei job, la policy del browser, le funzionalità facoltative e le opzioni dei ruoli
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## L'account admin
+
+L'account admin locale viene creato al primo avvio da [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+e [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), il cui valore predefinito è `AnsibleForms!123`.
+
+* Un accesso con la password predefinita pubblica `AnsibleForms!123` deve prima cambiarla: fino ad allora il server risponde
+  a ogni richiesta tranne il cambio password con `403` (codice `password_change_required`), e il browser mostra una
+  pagina di cambio password che non si può chiudere. La nuova password non può essere di nuovo quella predefinita.
+* `ADMIN_PASSWORD` viene letta solo quando l'account viene creato la prima volta: imposta un tuo valore prima del primo avvio.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` reimposta la password a `ADMIN_PASSWORD` a ogni
+  avvio. Usala solo per recuperare una password persa, poi rimuovila e riavvia.
+* Imposta prima i due segreti principali: vedi [Segreti e cifratura](secrets.html).
+* Una volta che l'accesso LDAP o SSO funziona, tieni l'admin locale solo per le emergenze, con una password lunga conservata nel tuo vault.
+
+---
+
+## Limiti di accesso e password
+
+I tentativi di indovinare le password vengono rallentati da tre limiti. I fallimenti si contano nel database, quindi ogni nodo dell'app vede gli
+stessi tentativi, e ogni limite si applica senza riavvio:
+
+| Variabile | Predefinito | Cosa fa |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Dopo questo numero di accessi non riusciti, un account locale o LDAP viene bloccato per `LOGIN_LOCKOUT_MINUTES`. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Un indirizzo con questo numero di accessi non riusciti entro `LOGIN_LOCKOUT_MINUTES` viene trattenuto finché quella finestra non termina: un indirizzo che prova molti account. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Per quanto tempo un account resta bloccato, e la finestra in cui si contano i fallimenti. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Richieste al minuto da un indirizzo, per nodo dell'app, su accesso, disconnessione, rinnovo del token e callback di single sign-on. |
+
+Un account bloccato o un indirizzo trattenuto riceve `429` con un'intestazione `Retry-After`, prima che si verifichi qualsiasi password e
+che l'account esista o no; oltre `AUTH_RATE_LIMIT` la risposta è ugualmente `429`. Un accesso riuscito azzera il
+conteggio dell'account, e lo stesso fa un admin che imposta la password dell'utente. `0` disattiva un limite; `LOGIN_LOCKOUT_MINUTES=0`
+disattiva sia il blocco sia il limite per indirizzo.
+
+`LOGIN_MAX_FAILURES_PER_IP` e `AUTH_RATE_LIMIT` contano per indirizzo del client: dietro un reverse proxy, imposta `TRUST_PROXY`
+così che l'indirizzo sia quello del client e non quello del proxy, vedi [Indirizzi dei client](../production/reverse-proxy.html#client-addresses).
+
+Una password locale impostata tramite l'applicazione, per un nuovo utente, da un admin o dagli utenti che cambiano la propria, deve avere
+almeno [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) caratteri (`8` per impostazione predefinita,
+`0` non verifica la lunghezza). Non può essere il nome utente né la password predefinita pubblica. `ADMIN_PASSWORD` non viene verificata.
+
+---
+
+## Il database
+
+AnsibleForms conserva ogni credenziale e ogni job nel suo database MySQL, quindi tieni quel database fuori dalla rete:
+
+* Il progetto docker-compose pubblica MySQL sull'host (`MYSQLDB_LOCAL_PORT`, `3306`) e viene fornito con la password di root
+  `AnsibleForms!123`. Rimuovi quella mappatura di porta, o legala a `127.0.0.1`, e cambia la password.
+* Connettiti con un account dedicato invece di `root`, impostato in [`DB_USER`](../customization/server.html#env_DB_USER) e
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Ha bisogno di diritti solo sullo schema `AnsibleForms`:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Questo copre la creazione dello schema (`CREATE DATABASE` compreso), le patch agli aggiornamenti, e i
+  [backup](../production/backups.html) e i ripristini, che girano con lo stesso utente: il dump si fa con
+  `--no-tablespaces`, quindi non serve nessun diritto a livello di server come `PROCESS`. Sostituisci `%` con l'indirizzo
+  dell'applicazione dove puoi. Un utente con diritti su ogni database, come li ha `root`, trasforma una falla nell'applicazione in
+  una falla nell'intero server di database: la pagina **Stato** lo segnala nel suo controllo **Utente del database**, e il log
+  a ogni avvio.
+* Imposta [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) a `0` una volta che lo schema esiste.
+  Creare lo schema elimina prima ogni tabella; con `0` né il bootstrap all'avvio né l'endpoint `/api/v2/schema`
+  possono eseguirla.
+
+---
+
+## Espressioni e chiamate in uscita
+
+Le espressioni server girano sul server per qualsiasi utente che ha effettuato l'accesso, quindi il sanitizer e i filtri in uscita contano:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` o `paranoid`, mai `legacy`, che permette agli utenti di eseguire codice sul server.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : gli host che le espressioni REST non possono raggiungere, es. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : quando è impostata, le espressioni REST possono raggiungere
+  solo questi host e intervalli. La lista dei negati vince su di essa.
+
+Entrambe le liste coprono solo le funzioni helper REST di AnsibleForms stesso; i playbook girano al di fuori di esse e non vengono filtrati.
+
+Dalla 7.3.0 le funzioni helper REST verificano il certificato dell'endpoint, come fa ogni altra connessione.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` disattiva la verifica: usala solo per
+endpoint con un certificato autofirmato.
+
+---
+
+## Dati dei job
+
+Le extravars e l'output dei job vengono salvati nel database e mostrati a chiunque possa vedere il job:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : le extravars la cui chiave corrisponde vengono
+  mostrate come `********`. Il valore predefinito è `password|secret|token`; i campi password sono sempre mascherati. Estendila con
+  i nomi usati dai tuoi moduli, per esempio `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : riduce l'oggetto `ansibleforms_user`
+  inviato con ogni job, che altrimenti contiene tutte le appartenenze ai gruppi dell'utente.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) nasconde solo i task rumorosi; nascondi i segreti con `no_log`.
+
+---
+
+## La Content-Security-Policy
+
+L'interfaccia viene servita con un'intestazione Content-Security-Policy, che limita ciò che una pagina può caricare ed eseguire nel browser:
+
+* Gli script arrivano solo dall'applicazione stessa, quindi uno script iniettato in una pagina non viene eseguito.
+* Nessun altro sito può mostrare l'interfaccia in un frame.
+* Permette ciò di cui l'applicazione ha bisogno: le espressioni locali dei moduli valutate nel browser (`'unsafe-eval'`), gli stili
+  inline, le immagini da qualsiasi URL (immagini dei moduli e delle categorie), e i worker dell'editor di codice.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) è `1` per impostazione predefinita e dovrebbe
+restare così. Con `0` la policy viene inviata come `Content-Security-Policy-Report-Only`: la console del browser elenca ciò che
+bloccherebbe, e nulla viene bloccato. Usa `0` solo per una configurazione che non può ancora funzionare con la policy, come un reverse proxy
+che inietta uno script proprio. Una modifica nella pagina delle impostazioni si applica senza riavvio.
+
+---
+
+## Le pagine delle impostazioni e il designer
+
+Gli amministratori possono modificare gran parte della configurazione dal browser. Restringilo dove la configurazione sta altrove:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : impostazioni in sola lettura, per un [ambiente gestito](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : rimuove il designer integrato quando i moduli
+  sono mantenuti in git.
+
+---
+
+## Funzionalità facoltative
+
+Queste funzionalità sono disattivate per impostazione predefinita. Attivale solo quando le usi; una modifica nella pagina delle impostazioni si applica senza riavvio:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : espone il [server MCP](../mcp/) su `/api/v2/mcp`,
+  così i client MCP possono avviare moduli con il token di un utente.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : l'[assistente chat](../chat/). Le definizioni dei moduli
+  e i valori in compilazione vengono inviati al provider del modello configurato.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) funziona al contrario: è `enforce`
+per impostazione predefinita, quindi il server rifiuta un avvio i cui valori violano le regole del modulo, compresi gli avvii tramite l'API REST.
+Lasciala così: `log` registra solo ciò che verrebbe rifiutato e `off` non verifica nulla, vedi [Validazione all'avvio](../launch-validation/).
+
+---
+
+## Opzioni dei ruoli
+
+Alcune opzioni di ruolo in [config.yaml](../config/roles.html) concedono più di quanto suggerisca il loro nome. Concedile con attenzione:
+
+| Opzione | Perché conta |
+|--------|----------------|
+| `allowScheduledJobs` | Un utente che ce l'ha vede e può modificare ogni pianificazione, e una pianificazione gira con diritti di admin, per qualsiasi modulo. Considerala di livello admin. |
+| `allowBackupOps` | Comprende il **ripristino**, che sostituisce l'intero database. |
+| `showSettings` | Apre le pagine di amministrazione. Senza il ruolo admin, non può modificare gli account e i gruppi indicati dal ruolo admin, vedi [Utenti e gruppi](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Mostra il log del server, che può contenere nomi host, nomi utente e dettagli degli errori. |
+| `showConnectionsSettings` | Apre le pagine delle connessioni: credenziali, runner, canali di notifica e altro. Aggiungere, modificare ed eliminare runner e archivi di segreti resta compito di un admin, e così le credenziali delle connessioni e degli accessi. Di un repository, aggiungerlo o eliminarlo e cambiarne l'indirizzo, il branch o i flag `use_for_*` resta compito di un admin. |
+| `showAllJobLogs` | Mostra i job di tutti gli utenti, non solo quelli dell'utente stesso. |
+| `manageAllJobs` | Interrompe, elimina e rilancia i job di tutti gli utenti. |
+| `allowApiTokens` | Permette all'utente di creare token API che durano fino a [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 per impostazione predefinita). Disconnettersi con un token o revocarlo lo termina, e un cambio di password termina tutti i token dell'utente, vedi [Token](secrets.html#tokens). |
+| `extendedTokenExpiration` | Con `allowApiTokens`, permette anche all'utente di creare token API che non scadono mai. |
+| `allowFileUploads` | Permette all'utente di caricare file tramite i campi file di un modulo. Attiva per ogni utente a meno che un ruolo non la disattivi. |
+| `allowChat`, `allowMcp` | Permettono all'utente di usare l'assistente chat e il server MCP, quando sono attivati. `allowChat` è attiva per ogni utente a meno che un ruolo non la disattivi, e `allowMcp` segue `allowChat` a meno che un ruolo non la imposti. |
+
+Un utente senza il ruolo `admin` non riceve nessuna delle opzioni di livello admin qui sopra a meno che un ruolo non gliele conceda. Quando il ruolo `admin`
+non imposta nessuna opzione, i suoi utenti ricevono `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` e `allowScheduledJobs`. `allowApiTokens` ed
+`extendedTokenExpiration` restano disattivate anche per il ruolo `admin`: impostale sui ruoli che ne hanno bisogno.
+
+Quando più ruoli di un utente impostano la stessa opzione, vince `false`. Le opzioni del ruolo `default` completano solo le opzioni
+che nessuno dei ruoli propri dell'utente imposta; non prevalgono mai su di essi.
diff --git a/i18n/it/_configure/security/https.md b/i18n/it/_configure/security/https.md
new file mode 100644
index 0000000..49cc44b
--- /dev/null
+++ b/i18n/it/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Sicurezza
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+Servi HTTPS dall'applicazione stessa, e sostituisci il certificato di esempio
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dove termina il TLS
+
+Il TLS può terminare in uno di tre posti, e solo il primo riguarda le impostazioni di questa pagina:
+
+* **in AnsibleForms**, con `HTTPS=1` : HTTPS su [`PORT`](../customization/server.html#env_PORT) con i file qui sotto, come fa docker-compose sulla 443.
+* **in un reverse proxy**, con `HTTPS=0` dietro di esso : vedi [Reverse proxy](../production/reverse-proxy.html).
+* **in un ingress Kubernetes** : vedi la scheda Ingress di [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) e il README del chart.
+
+Puoi combinare il primo con gli altri due per cifrare anche il tratto tra il proxy e l'applicazione.
+
+---
+
+## Le impostazioni
+
+Tre variabili controllano HTTPS nell'applicazione:
+
+| Variabile | Predefinito | Significato |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` serve HTTPS, `0` HTTP semplice |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | La chiave privata, PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | Il certificato del server, PEM |
+
+Nell'immagine del container la cartella persistente è `/app/dist/persistent`, quindi i file predefiniti sono
+`/app/dist/persistent/certificates/key.pem` e `cert.pem`. Con il progetto docker-compose questo corrisponde a `data/certificates/`
+sull'host.
+
+---
+
+## Il certificato di esempio
+
+Quando `HTTPS=1` e uno dei due file manca all'avvio, AnsibleForms registra `httpsKey or httpsCert not found, copying from
+templates` e copia una chiave e un certificato di esempio dall'immagine ai percorsi configurati. Se quella copia non riesce,
+l'applicazione si ferma.
+
+Quel certificato è autofirmato per `CN=ansibleforms`, ed è **lo stesso su ogni installazione**: la sua chiave privata
+è inclusa nell'immagine pubblica. Va bene per una prima occhiata, ma i browser lo segnalano e chiunque può decifrare il traffico
+protetto da esso. Sostituiscilo prima che l'istanza contenga credenziali reali.
+
+---
+
+## Sostituire il certificato
+
+Usa un certificato emesso per il nome host che digitano gli utenti, dalla tua CA o da un client ACME, in formato PEM.
+Il file del certificato può contenere l'intera catena: prima il certificato del server, poi gli intermedi.
+
+1. Copia i file nella cartella persistente, o in qualsiasi posto in cui l'applicazione possa leggerli:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Se si trovano altrove, imposta `HTTPS_KEY` e `HTTPS_CERT` con i loro percorsi **all'interno del container**.
+
+3. Riavvia l'applicazione, che legge entrambi i file all'avvio.
+
+Per un rapido certificato autofirmato tuo (un'istanza di test, o il tratto dietro un proxy), `openssl` ne crea uno:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Rinnovare senza riavvio
+
+Cambiare `HTTPS_KEY` o `HTTPS_CERT` nelle pagine delle impostazioni ricarica la chiave e il certificato nel server in esecuzione.
+Le nuove connessioni ricevono il nuovo certificato, quelle aperte mantengono il vecchio. Se i nuovi file non si possono leggere o non formano una
+coppia valida, il certificato attuale resta al suo posto e viene registrato un avviso.
+
+Questo funziona solo quando le pagine delle impostazioni possono scrivere l'ambiente ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+è `1`) e la variabile non è impostata nell'ambiente reale. Quando un rinnovo sostituisce i file negli stessi
+percorsi, riavvia l'applicazione.
diff --git a/i18n/it/_configure/security/index.md b/i18n/it/_configure/security/index.md
new file mode 100644
index 0000000..f35a365
--- /dev/null
+++ b/i18n/it/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Sicurezza
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Sicurezza
+{: .no_toc }
+
+Metti in sicurezza un'istanza: l'account admin, i suoi segreti, HTTPS e cosa possono fare gli utenti e i moduli
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori che preparano un'istanza per la produzione, e per le revisioni di sicurezza di un'istanza esistente.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina propria:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Hardening](hardening.html) | L'account admin, i limiti di accesso, il database, le espressioni, i dati dei job, la policy del browser, le funzionalità facoltative e le opzioni dei ruoli |
+| [HTTPS](https.html) | Dove termina il TLS, servire HTTPS dall'applicazione, e sostituire il certificato di esempio |
+| [Segreti e cifratura](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, e la durata dei token |
+
+Pagine correlate: [Autenticazione](../authentication/) per i metodi di accesso, [Validazione all'avvio](../launch-validation/) per
+i controlli lato server di ogni avvio, e le [Variabili di sicurezza](../customization/security.html).
diff --git a/i18n/it/_configure/security/secrets.md b/i18n/it/_configure/security/secrets.md
new file mode 100644
index 0000000..3b99021
--- /dev/null
+++ b/i18n/it/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Segreti e cifratura
+parent: Sicurezza
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Segreti e cifratura
+{: .no_toc }
+
+I due segreti principali, cosa proteggono, e quanto durano le sessioni e i token
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## I due segreti principali
+
+Due segreti proteggono tutto il resto. Impostali entrambi prima che l'istanza contenga dati reali, conservali fuori dall'istanza,
+e non cambiarli mai alla leggera:
+
+| Segreto | Cosa protegge | Se non è impostato | Se viene perso o cambiato |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Ogni password e token salvati nel database: credenziali, la password di bind LDAP, i token dei runner, i client secret SSO, gli indirizzi dei webhook di Slack e Teams, la chiave API della chat | Si usa una chiave predefinita, pubblica nel codice sorgente | Perso: ogni segreto salvato va reinserito. Cambiato: dalla 7.3.0 ogni segreto salvato viene ricifrato, vedi [sotto](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | La firma degli access token e dei refresh token, compresi i [token API](../profile/api-token.html) di lunga durata | A ogni avvio viene generato un segreto casuale, quindi ogni riavvio disconnette tutti | Ogni sessione e ogni token API diventano non validi |
+
+Entrambi vengono segnalati con un avviso `[SECURITY]` all'avvio finché mancano. Le pagine delle impostazioni si rifiutano di modificarli,
+l'API non li restituisce mai, e i backup li escludono di proposito, quindi un `ENCRYPTION_SECRET` perso non si può recuperare
+da nessuna parte: conservane una copia nel tuo gestore di segreti. Il segreto di cifratura si usa come chiave di 32 caratteri; un valore più corto o
+più lungo viene completato o troncato.
+
+Cambiare `ACCESS_TOKEN_SECRET` termina subito ogni sessione e ogni token API. Per terminare i token di un solo utente o di una sola
+sessione, usa le revoche descritte in [Token](#tokens).
+
+---
+
+## Cambiare il segreto di cifratura
+
+Dalla 7.3.0, impostare o cambiare `ENCRYPTION_SECRET` non fa più perdere i segreti salvati. Al successivo avvio il worker ricifra
+ognuno di essi con la nuova chiave, in un'unica transazione del database, prima che qualsiasi altra cosa scriva un segreto:
+
+| Situazione | Cosa impostare |
+|---|---|
+| L'istanza girava senza `ENCRYPTION_SECRET`, sulla chiave predefinita pubblica | Solo `ENCRYPTION_SECRET`: i segreti vengono ricifrati a partire dalla chiave predefinita |
+| L'istanza girava con una chiave tua | `ENCRYPTION_SECRET` con la nuova chiave e [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) con quella vecchia, per quell'unico avvio |
+
+Quando i segreti salvati erano cifrati con una chiave che non è nessuna delle due, non si cambia nulla e l'app si rifiuta di partire finché
+`ENCRYPTION_SECRET_PREVIOUS` non indica quella chiave. Rimuovi `ENCRYPTION_SECRET_PREVIOUS` una volta che l'avvio li ha ricifrati, e imposta il
+nuovo `ENCRYPTION_SECRET` su ogni nodo dell'app, sul worker e su ogni RTE in modalità database che si registra da solo. Quella
+registrazione automatica (`RTE_REGISTER`) è deprecata nella 7.3.0: un RTE che si unisce con un join token (`RTE_JOIN_TOKEN`) in modalità
+socket non ha bisogno di `ENCRYPTION_SECRET`, vedi [Modalità RTE](../rte/modes.html).
+
+---
+
+## Token
+
+Un accesso restituisce un access token di breve durata e un refresh token più lungo, che il browser usa per ottenere una nuova coppia:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : `30m` per impostazione predefinita. Più breve
+  limita l'uso di un token intercettato.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : `24h` per
+  impostazione predefinita. È il tempo per cui un browser inattivo resta connesso.
+* L'opzione di ruolo `allowApiTokens` permette a un utente di richiedere un token API valido per un certo numero di giorni, ed
+  `extendedTokenExpiration` ne aggiunge uno che non scade mai. Concedile solo ai ruoli che hanno bisogno di accesso API dagli script.
+  Nella [pagina del profilo](../profile/api-token.html) un token si crea da una sessione del browser che ha effettuato l'accesso al massimo 10 minuti
+  prima, e mai da un altro token API. Un token che non scade mai dura 50 anni, e gli eventi qui sotto lo terminano comunque.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : `90` per impostazione predefinita. La durata massima di un
+  token API: una richiesta più lunga viene ridotta a questo valore.
+
+Un token è un JWT firmato, ma il server tiene anche una lista di token revocati, condivisa da tutti i nodi dell'app, così un token
+può terminare prima di scadere:
+
+| Evento | Cosa termina |
+|-------|-----------|
+| Disconnettersi | Ogni token di quell'accesso: l'access token, il suo refresh token, e un token API quando la disconnessione lo usa |
+| Un cambio di password, da parte dell'utente o di un admin | Ogni token dell'utente emesso prima del cambio, token API compresi, su ogni dispositivo |
+| L'interruttore **Consenti accesso** di un utente disattivato (utente locale, LDAP o SSO), o un utente locale eliminato | Ogni token dell'utente |
+| **Termina sessioni** nella pagina di un utente LDAP o SSO | Ogni token dell'utente; può accedere di nuovo a meno che non sia bloccato |
+| **Revoca** su un token API, nella pagina del profilo o nella scheda **Token API** dell'utente | Quel solo token API, subito |
+
+Uno script termina il proprio token API disconnettendosi con esso: `POST /api/v2/auth/logout` con il token nell'intestazione
+`Authorization`.
diff --git a/i18n/it/_configure/seed/environment-and-audit.md b/i18n/it/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..0224bd8
--- /dev/null
+++ b/i18n/it/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Modifica e audit
+parent: Config seed
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Modifica e audit
+{: .no_toc }
+
+Bloccare le pagine delle impostazioni, e cosa registra il log di audit
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Disattivare la modifica dell'ambiente
+
+`ALLOW_ENV_EDIT=0` rende le pagine delle impostazioni in sola lettura. Ogni variabile viene comunque mostrata con
+il valore in vigore e il motivo per cui non si può modificare, e l'endpoint di salvataggio risponde con
+403.
+
+Usala ogni volta che l'ambiente è dichiarato altrove. Altrimenti la pagina delle impostazioni scrive
+`persistent/.env`, che su un volume effimero va perso senza avviso al riavvio successivo, e su
+uno durevole si allontana dal manifest che dovrebbe fare fede.
+
+{: .note }
+> I backup includono `persistent/.env` come `managed.env`, così una ricostruzione recupera le impostazioni del database e
+> dei percorsi. **`ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET` vengono rimossi**:
+> il dump accanto contiene ogni credenziale salvata come testo cifrato AES, e scrivere la chiave che
+> lo decifra nella stessa cartella renderebbe sufficiente una copia del backup per leggerle tutte. Imposta
+> invece quei due sull'host di destinazione; un commento nel file lo indica.
+>
+> Ciò che resta può comunque contenere credenziali (`DB_PASSWORD`, `METRICS_TOKEN`, un vecchio `VAULT_TOKEN`), quindi il file viene
+> scritto con permessi `0600`. Ripristinarlo è un passaggio separato e volontario invece che parte di un ripristino normale,
+> perché l'host del database e i percorsi che contiene descrivono la macchina da cui proviene il backup. La
+> finestra di ripristino elenca il file e offre un proprio pulsante *Ripristina ambiente*
+> (`POST /api/v2/backup/:folder/restore-env`), che conserva il file precedente come `.env.bak`.
+
+---
+
+## Cosa viene registrato
+
+Ogni applicazione che cambia qualcosa scrive una voce `seed.apply` nel log di audit, indicando
+gli oggetti creati, aggiornati, rilasciati ed eliminati. I valori non vengono mai registrati, perché la maggior parte
+di essi sono segreti. Un'applicazione senza effetti non scrive nulla, il che mantiene significativa la traccia. Un
+controllo periodico che trova il file invariato è un'applicazione senza effetti, così la traccia non guadagna una riga ogni minuto.
+
+Un'applicazione richiesta tramite l'endpoint viene registrata di proposito due volte, e le due righe
+registrano cose diverse: `config-seed.apply.create` è **chi** l'ha chiesta, `seed.apply` è
+**cosa** ha cambiato.
+
+La pagina Stato riporta il seed due volte: un **controllo** che il file sia ancora leggibile e si analizzi,
+e che l'ultimo ricaricamento sia riuscito, e una riga di **informazioni** che dice quanti record
+possiede attualmente. Il controllo è l'unico posto che segnala quando il file su disco e la configurazione
+in vigore sono divergenti, perché un ricaricamento non riuscito lascia l'istanza in esecuzione.
diff --git a/i18n/it/_configure/seed/example.md b/i18n/it/_configure/seed/example.md
new file mode 100644
index 0000000..edc1686
--- /dev/null
+++ b/i18n/it/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Esempio
+parent: Config seed
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Esempio
+{: .no_toc }
+
+Un file di seed completo, sezione per sezione
+{: .fs-6 .fw-300 }
+
+---
+
+Il seguente file di seed dichiara ogni sezione tranne `oauth2` e la deprecata `awx`; i segreti arrivano da variabili
+d'ambiente come `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` è uno tra:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : qualsiasi altro endpoint compatibile con OpenAI
+
+Come `ldap`, la sezione `chat` è una riga singola, quindi ogni campo è obbligatorio tranne quelli
+facoltativi; un campo facoltativo omesso resta invariato.
+
+L'assistente chat richiede anche `ENABLE_CHAT=1`; vedi la pagina [Assistente chat](../chat).
+
+Dalla 7.3.0 un runner accede con una credenziale del suo tipo, che contiene l'indirizzo del suo server in `url`. Un runner con un proprio `token`,
+o `username` e `password`, funziona ancora: il seed registra un avviso e li trasforma in una credenziale del genere, che prende il nome del runner. Un
+runner che indica una credenziale `api` o `userpass` funziona ancora anch'esso, con un avviso: dai invece a quella credenziale il tipo del runner.
+Entrambi sono deprecati dalla 7.3.0 e verranno rimossi nella 8.0.0. Un runner RTE senza `rte_mode` è in modalità database, deprecata (vedi
+[Modalità](../rte/modes.html)). Un runner con `enabled: false` non riceve nessun job, nemmeno come predefinito del suo tipo (vedi
+[Predefinito e Abilitato](../runners/list.html#default-and-enabled)); senza `enabled`, il seed lo lascia com'è.
+
+Un elemento runner accetta queste chiavi oltre a `name`, `type`, `description`, `credential`, `is_default` ed `enabled`:
+
+| Chiave | Cosa imposta |
+|---|---|
+| `rte_mode` | La modalità di un RTE: `outbound`, `inbound` o `database` (deprecata, la predefinita) |
+| `rte_max_jobs` | I **Job simultanei max** di un RTE in modalità socket, da `0` a `10000` (`0`: nessun limite) |
+| `rte_cache_mb` | La sua **Cache dei file** in MB, da `0` a `1048576` (`0` non ne conserva nessuno) |
+| `rte_files` | I suoi **File dei job**: `transfer` o `local` |
+| `rte_drain_seconds` | La sua **Attesa allo stop** in secondi, da `0` a `86400` |
+| `flavour` | Un runner `awx` che è un AAP o un Ascender: `aap` o `ascender`; nessuno per AWX |
+| `project` | L'id del progetto di un runner Semaphore, il nome del progetto di un runner Rundeck, la cartella di un runner Jenkins |
+| `uri`, `ignore_certs`, `ca_bundle` | L'indirizzo e il TLS propri del runner, di prima della 7.3.0: usati solo finché la sua credenziale non contiene un `url` |
+
+Le quattro impostazioni `rte_*` sono quelle della scheda RTE della pagina del runner (vedi [Le impostazioni di un RTE](../runners/runner-page.html#an-rtes-settings)):
+vincono sulle stesse variabili impostate sull'RTE, e un RTE in modalità database le ignora. Un valore fuori dal suo intervallo fa fallire la
+validazione del seed.
+
+Un RTE in modalità database può registrarsi da solo prima che il seed venga applicato. Un runner RTE del seed il cui `uri` è l'indirizzo con cui un RTE del genere
+si è registrato **adotta** quella riga: prende il nome e i campi dichiarati, e il worker non lo rimuove più quando l'RTE smette di
+rispondere, invece di avere un secondo runner per lo stesso RTE.
diff --git a/i18n/it/_configure/seed/index.md b/i18n/it/_configure/seed/index.md
new file mode 100644
index 0000000..664dfce
--- /dev/null
+++ b/i18n/it/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Config seed
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Config seed
+{: .no_toc }
+
+Dichiara gli oggetti di amministrazione in un file
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori che fanno provisioning da git: dichiara gli oggetti di amministrazione in un file, così un'istanza si può ricostruire su un database vuoto.
+
+---
+
+## Cosa copre
+
+Imposta `CONFIG_SEED_PATH` su un file YAML, e AnsibleForms lo applica all'avvio. Il file
+dichiara oggetti che prima esistevano solo nel database:
+
+| Sezione                 | Cosa dichiara                                                       |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Dove girano i job: RTE, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Archivi di segreti (HashiCorp Vault, ...)                           |
+| `credentials`           | Credenziali                                                         |
+| `oauth2`                | Provider SSO: Entra ID e OIDC                                       |
+| `repositories`          | Repository git                                                      |
+| `syslog_servers`        | I server syslog che ricevono il log del server e le voci di audit   |
+| `notification_channels` | Server mail, Slack, Teams, Telegram e webhook per le notifiche      |
+| `labels`                | Le etichette accanto al logo dell'intestazione, dalla 7.3.0          |
+| `ldap`                  | La configurazione LDAP                                              |
+| `settings`              | L'URL pubblico, e le impostazioni mail usate quando nessun canale mail è attivo |
+| `chat`                  | Il provider del modello dell'assistente chat                        |
+| `awx`                   | Deprecata dalla 7, rimossa nella 8: usa `runners` con `type: awx`   |
+
+Un seed scritto prima della 7 continua a funzionare: ogni elemento della sua sezione `awx` viene applicato come runner di tipo `awx`, e il log
+avvisa a ogni applicazione. Sposta quegli elementi sotto `runners` con `type: awx` prima di aggiornare alla 8.
+
+Il seed **non** è la stessa cosa di `config.yaml`, che contiene le categorie, i ruoli e le costanti
+e ha il proprio `CONFIG_PATH`. I due sono tenuti separati di proposito: il
+repository che *contiene* `config.yaml` è uno degli oggetti che il seed dichiara, quindi il seed
+non può stare al suo interno.
+
+Utenti e gruppi sono esclusi: arrivano da LDAP o SSO, e il primo admin da `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina propria:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Esempio](example.html) | Un file di seed completo, sezione per sezione |
+| [Oggetti gestiti](managed-objects.html) | Come il seed possiede gli oggetti che elenca, e come tiene fuori i segreti |
+| [Ricaricamento e avvio](reloading.html) | Modificare il file senza riavvio, e cosa succede all'avvio |
+| [Kubernetes](kubernetes.html) | Fare il provisioning di AnsibleForms da una ConfigMap e da dei Secret |
+| [Modifica e audit](environment-and-audit.html) | Bloccare le pagine delle impostazioni, e cosa registra il log di audit |
diff --git a/i18n/it/_configure/seed/kubernetes.md b/i18n/it/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..f34df0c
--- /dev/null
+++ b/i18n/it/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Config seed
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+Fare il provisioning di AnsibleForms da una ConfigMap e da dei Secret
+{: .fs-6 .fw-300 }
+
+---
+
+Monta il seed da una `ConfigMap` e i suoi segreti da un `Secret`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Un solo pod, con `AF_ROLE` non impostato.** Questo pod esegue l'app web e il worker in un solo processo. Le pianificazioni, il backup
+> notturno e il resto del lavoro in background girano solo nel processo che detiene il lock del worker nel database, il blocco
+> del designer è una tabella del database, e i playbook girano su un RTE, non in questo pod. Mantieni comunque `replicas: 1` con la strategia
+> `Recreate`: in un aggiornamento il nuovo pod attende che il worker applichi le patch allo schema, e il vecchio pod detiene il
+> lock del worker finché non si ferma. Per eseguire più nodi web, suddividili in nodi `AF_ROLE=app` e un worker, come
+> descrive [Scalabilità](../production/scaling.html).
+
+`ENCRYPTION_SECRET` deve essere impostato prima di inserire qualsiasi credenziale. Una volta che le credenziali arrivano
+dal seed, il database è di fatto una cache, quindi ruotarlo significa riapplicare il
+seed invece di reinserire tutto a mano.
+
+Le due probe non richiedono accesso. Sotto un [`BASE_URL`](../customization/server.html#env_BASE_URL) i loro percorsi iniziano con esso, e
+[Monitoraggio](../production/monitoring.html) descrive cosa verifica ciascuna.
diff --git a/i18n/it/_configure/seed/managed-objects.md b/i18n/it/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..c3cc22d
--- /dev/null
+++ b/i18n/it/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Oggetti gestiti
+parent: Config seed
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Oggetti gestiti
+{: .no_toc }
+
+Come il seed possiede gli oggetti che elenca, e come tiene fuori i segreti
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le sezioni a riga singola sono tutto o niente
+
+`ldap`, `settings` e `chat` sono ciascuna una **riga singola**, quindi il seed deve dichiararne tutti i campi; le altre sezioni sono liste.
+
+Un seed che omette un campo si rifiuta di partire e lo indica:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Dichiara esplicitamente un valore vuoto con `""` o `false`. Alcuni campi sono facoltativi, e uno omesso resta invariato:
+
+| Sezione | Campi facoltativi |
+|---|---|
+| `ldap` | `description`, `credential` (una credenziale con cui fare il bind) e `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` ed `extra_headers` |
+| `settings` | Nessuno |
+
+`settings` copre solo i campi mail e l'URL; tutte le altre impostazioni restano modificabili.
+
+---
+
+## Il file non contiene segreti
+
+Ogni `${VARIABLE}` viene sostituita con quella variabile d'ambiente (su Kubernetes, da un `Secret`), così il file può stare in Git.
+
+Una variabile non impostata è un **errore fatale**, così un segnaposto non può mai finire salvato come password.
+
+Le credenziali possono anche usare un [archivio di segreti](../secret-stores) (`secret_store`, `secret_ref`); `vault_path` sparirà nella 8.
+
+---
+
+## Oggetti gestiti
+
+Un oggetto che viene dal seed è contrassegnato come **gestito**:
+
+- Viene imposto a **ogni** avvio, così il file resta la fonte autorevole.
+- È in sola lettura: l'API risponde **403**, l'interfaccia disabilita Modifica ed Elimina, e la sua pagina dice che viene dal file
+  del config seed ed è in sola lettura.
+- Solo il seed può impostare o togliere il contrassegno.
+
+Gli oggetti creati a mano non vengono **mai toccati**, a meno che il seed non dichiari lo stesso nome. Quel record viene allora **adottato**:
+i campi dichiarati vengono imposti e diventa in sola lettura. L'adozione viene registrata come avviso e nella traccia di audit.
+
+Applicare il seed è idempotente: i record che corrispondono già vengono lasciati stare, quindi un riavvio di norma riporta `0 updated`.
+
+Un repository dichiarato il cui working tree manca viene **clonato di nuovo** a ogni avvio, così un primo clone non riuscito viene
+ritentato. La riga *Repository* della pagina Stato mostra qualsiasi repository senza working tree.
+
+### Rimuovere un oggetto
+
+Rimuovere un oggetto dal file lo **rilascia**: il record resta e torna modificabile. Eliminare un'intera sezione
+fa lo stesso.
+
+Aggiungi `prune: true` a una sezione a lista per **eliminare** i record gestiti che il file non dichiara più:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` non elimina mai un record creato a mano.
+
+### Disattivare il seed
+
+Togliere `CONFIG_SEED_PATH` **non** rilascia nulla: il seed non viene più applicato, e i record che gestiva restano gestiti
+e in sola lettura. Per modificarli di nuovo, rilasciali prima: punta `CONFIG_SEED_PATH` a un file senza di essi (un file vuoto non dichiara
+nulla e rilascia ogni record), lascia che si applichi a un avvio o a un ricaricamento, poi togli la variabile. I record rilasciati restano come
+sono, e diventano modificabili.
diff --git a/i18n/it/_configure/seed/reloading.md b/i18n/it/_configure/seed/reloading.md
new file mode 100644
index 0000000..de3b379
--- /dev/null
+++ b/i18n/it/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Ricaricamento e avvio
+parent: Config seed
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Ricaricamento e avvio
+{: .no_toc }
+
+Modificare il file senza riavvio, e cosa succede all'avvio
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Modificare il file senza riavviare
+
+Il seed viene riletto ogni `CONFIG_SEED_RELOAD_SECONDS` (60 per impostazione predefinita, `0` lo disattiva)
+e riapplicato quando il suo contenuto è cambiato. Una modifica di cui si fa commit in git raggiunge quindi
+automaticamente un'istanza in esecuzione: su Kubernetes, una `ConfigMap` viene rimontata nel pod entro
+circa un minuto, e il controllo successivo la rileva. Non c'è nessun rollout né riavvio, e nessun
+hook deve chiamare nulla.
+
+Per un file invariato, il controllo calcola un hash e si ferma, quindi non riscrive mai una riga che ha
+già applicato.
+
+Per applicare subito il file invece di attendere il controllo successivo, usa uno di questi:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Entrambi **forzano** un'applicazione anche quando il file non è cambiato. Un'applicazione forzata reimpone un
+record gestito che è stato modificato direttamente nel database, e riclona un repository dichiarato
+il cui working tree manca.
+
+{: .note }
+> Un ricaricamento non è **mai fatale**, a differenza dell'applicazione all'avvio. Un'istanza che sta già
+> servendo mantiene la sua configurazione attuale, il motivo viene registrato, e la riga *Seed di configurazione*
+> nella pagina Stato diventa rossa e lo indica. Un errore di battitura inviato a git non deve poter mettere
+> fuori servizio un'istanza in esecuzione senza alcun intervento di un operatore.
+>
+> Lo stesso contenuto errato inoltre non viene ritentato a ogni controllo; altrimenti una sola modifica sbagliata
+> scriverebbe lo stesso errore nel log all'infinito. Correggi il file, o chiama l'endpoint per ritentare
+> subito.
+
+---
+
+## Un seed errato si rifiuta di partire
+
+Un file illeggibile, uno YAML non valido, un campo sconosciuto, un nome duplicato o una
+`${VARIABLE}` non risolta fanno **uscire** il server invece di farlo partire. Questo vale solo per il percorso di **avvio**:
+vedi la nota qui sopra per cosa fa lo stesso file a un'istanza già in funzione.
+
+È voluto. Continuare con la configurazione precedente lascerebbe un'istanza il cui
+comportamento non corrisponde più al manifest che dovrebbe descriverla, senza che nulla
+segnali la discrepanza. Il motivo viene scritto sullo standard error oltre che nel file di log, così
+`kubectl logs` e `docker logs` lo mostrano.
+
+La validazione è rigorosa: i campi sconosciuti vengono rifiutati invece che ignorati, e l'errore indica
+la chiave incriminata:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Un database vuoto si configura da solo
+
+Con `ALLOW_SCHEMA_CREATION` attiva (il predefinito), un database che non contiene **nessuna tabella
+di AnsibleForms** riceve il suo schema all'avvio. Un nuovo deployment parte quindi
+senza che nessuno debba chiamare a mano l'endpoint `/schema`.
+
+La condizione è rigorosa di proposito: creare lo schema **elimina prima ogni tabella**, quindi
+viene eseguita solo su un database completamente vuoto. Un database a cui manca
+una colonna, o che ha tabelle ma nessun account utente, *non* è vuoto e non viene toccato;
+quei casi li gestiscono le patch dello schema.
diff --git a/i18n/it/_configure/users-and-groups.md b/i18n/it/_configure/users-and-groups.md
new file mode 100644
index 0000000..57d3f5c
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups.md
@@ -0,0 +1,60 @@
+---
+layout: default
+title: Utenti e gruppi
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Utenti e gruppi
+{: .no_toc }
+
+Gli utenti e i gruppi locali, quelli LDAP e single sign-on accanto a loro, e come bloccare un accesso
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: gestisci chi può accedere in **Impostazioni > Accesso > Utenti** e **Gruppi**, con l'opzione di ruolo `showSettings`.
+
+L'admin integrato, l'ordine di accesso e la corrispondenza con i ruoli degli account locali sono in [Account locali](authentication/local.html).
+
+---
+
+## In questa sezione
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Un utente locale](users-and-groups/local-user.html) | Aggiungere un utente locale, e le schede della sua pagina |
+| [Più gruppi](users-and-groups/several-groups.html) | Un utente locale in più gruppi, e i loro ruoli |
+| [Un gruppo locale](users-and-groups/local-group.html) | La pagina di un gruppo locale e le sue schede |
+| [Utenti e gruppi della directory](users-and-groups/directory.html) | Utenti e gruppi LDAP, Entra ID e OIDC, come visti l'ultima volta |
+| [Bloccare un accesso](users-and-groups/blocking-a-sign-in.html) | Consenti accesso: bloccare un utente senza eliminare nulla |
+
+
+---
+
+## Le liste
+
+Le liste **Utenti** e **Gruppi** mostrano gli utenti e i gruppi locali e, accanto a loro, quelli LDAP e single sign-on.
+
+Un utente o un gruppo di LDAP, Entra ID o OIDC compare nella lista una volta che ha effettuato l'accesso (o è stato visto in un accesso), o una volta che un ruolo lo indica.
+La colonna **Origine** dice da dove arriva ciascuno: Locale, LDAP, Microsoft Entra ID o OIDC. Dalla 7.3.0 la lista **Utenti** ha anche
+una colonna **Ultimo accesso**, che dice quando ogni utente ha effettuato l'ultimo accesso.
+
+Una riga apre la pagina del suo utente o gruppo. **Aggiungi utente** e **Aggiungi gruppo** ne creano uno locale.
+
+---
+
+## Account che concedono l'admin
+
+Il ruolo admin in config.yaml indica gruppi e utenti locali, quindi solo un admin può modificare gli account e i gruppi che indica.
+
+Un utente con `showSettings` ma senza il ruolo admin non può modificare, bloccare, cambiare di gruppo, impostare la password di o eliminare un
+account locale indicato dal ruolo admin (direttamente o tramite uno dei suoi gruppi). Né può creare, rinominare o eliminare un gruppo
+indicato dal ruolo admin, o metterci un utente. Lo stesso vale per un utente LDAP o SSO che corrisponde al ruolo admin: bloccarlo,
+terminarne le sessioni, dimenticarlo e revocarne i token API spetta a un admin. Il server risponde a una richiesta del genere con `403`.
diff --git a/i18n/it/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/it/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..f79c4f9
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Bloccare un accesso
+parent: Utenti e gruppi
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Bloccare un accesso
+{: .no_toc }
+
+Consenti accesso: bloccare un utente senza eliminare nulla
+{: .fs-6 .fw-300 }
+
+L'interruttore **Consenti accesso** blocca un utente, locale o di una directory, senza eliminare nulla.
+
+Se lo disattivi, dopo una conferma, le sessioni dell'utente terminano subito e ogni accesso viene rifiutato finché non lo riattivi.
+La lista degli utenti ha **Blocca accesso** e **Consenti accesso** nel menu di ogni riga per fare lo stesso.
+
+Non puoi bloccare l'utente `admin`, né il tuo stesso accesso.
diff --git a/i18n/it/_configure/users-and-groups/directory.md b/i18n/it/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..383175f
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Utenti e gruppi della directory
+parent: Utenti e gruppi
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Utenti e gruppi della directory
+{: .no_toc }
+
+Utenti e gruppi LDAP, Entra ID e OIDC, come visti l'ultima volta
+{: .fs-6 .fw-300 }
+
+Un utente LDAP, Entra ID o OIDC ha la sua pagina in `/settings/users/<source>/<name>`, con `ldap`, `azuread` o `oidc`
+come origine, come `/settings/users/ldap/jdoe`. Mostra ciò che è stato registrato all'ultimo accesso dell'utente, in sola lettura,
+perché è la directory o l'identity provider a stabilire chi è l'utente e quali sono i suoi gruppi.
+
+Le sue schede sono quelle di un utente locale. **Dettagli** ha l'interruttore **Consenti accesso**, il nome utente, l'origine, il nome,
+l'email, quando l'utente è stato visto per la prima volta e il suo ultimo accesso. **Gruppi** elenca i gruppi dell'ultimo accesso.
+**Token API** elenca i token API dell'utente, e **Revoca** ne termina uno subito.
+
+In alto a destra, **Termina sessioni** disconnette subito l'utente ovunque. **Dimentica** rimuove il record, che torna
+al suo accesso successivo; i suoi job, job salvati e pianificazioni restano. Un utente bloccato non si può dimenticare, perché
+lo farebbe rientrare: il server risponde `409`, quindi consentine prima l'accesso.
+
+I gruppi di questo record sono anche i gruppi con cui lavora la sessione dell'utente, letti in tempo reale. Dimenticare un utente che ha
+effettuato l'accesso lo lascia senza gruppi, e senza i ruoli che quei gruppi concedono, finché non accede di nuovo.
+
+Un gruppo della directory ha la sua pagina in `/settings/groups/<source>/<name>`, in sola lettura, con le schede **Dettagli**,
+**Utenti** (gli utenti visti in esso al loro ultimo accesso), **Ruoli** e **Moduli**.
diff --git a/i18n/it/_configure/users-and-groups/local-group.md b/i18n/it/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..f5a8806
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Un gruppo locale
+parent: Utenti e gruppi
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Un gruppo locale
+{: .no_toc }
+
+La pagina di un gruppo locale e le sue schede
+{: .fs-6 .fw-300 }
+
+La pagina di un gruppo, `/settings/groups/<id>`, ha queste schede:
+
+| Scheda | Cosa mostra |
+|---|---|
+| **Dettagli** | Il nome e la descrizione |
+| **Utenti** | Gli utenti del gruppo; **Aggiungi utente** ne aggiunge uno, il menu di una riga o le caselle di spunta ne rimuovono uno |
+| **Ruoli** | I ruoli che indicano il gruppo |
+| **Moduli** | I moduli che quei ruoli aprono |
+
+Un gruppo con utenti non si può eliminare: rimuovi prima i suoi utenti. Il gruppo `admins` non si può mai eliminare né rinominare.
diff --git a/i18n/it/_configure/users-and-groups/local-user.md b/i18n/it/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..1c41690
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Un utente locale
+parent: Utenti e gruppi
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Un utente locale
+{: .no_toc }
+
+Aggiungere un utente locale, e le schede della sua pagina
+{: .fs-6 .fw-300 }
+
+**Aggiungi utente** apre una procedura guidata in tre passaggi: **Utente** (nome utente, descrizione, email), **Password** e **Gruppo**.
+
+La pagina di un utente, `/settings/users/<id>`, ha queste schede:
+
+| Scheda | Cosa mostra |
+|---|---|
+| **Dettagli** | L'interruttore **Consenti accesso**, il nome utente, la descrizione, l'email e, dalla 7.3.0, l'**Ultimo accesso** |
+| **Gruppi** | I gruppi a cui appartiene l'utente |
+| **Ruoli** | I ruoli che ha l'utente, e cosa concede ciascuno: **Direttamente**, **Tramite** un gruppo, o **Tutti** |
+| **Moduli** | I moduli che quei ruoli aprono |
+| **Job** | I job avviati dall'utente, dal più recente |
+| **Job salvati** | I valori dei moduli che l'utente ha salvato per eseguirli di nuovo |
+| **Pianificazioni** | I job che l'utente ha pianificato con Esegui più tardi |
+| **Attività** | Cosa ha registrato il log di audit sulle azioni dell'utente |
+| **Token API** | I token API dell'utente, con quando ognuno è stato creato, quando scade e quando è stato usato l'ultima volta; **Revoca** ne termina uno subito |
+
+Dalla 7.3.0 gli accessi di un utente locale vengono registrati, come già quelli di un utente LDAP o SSO: **Ultimo accesso** mostra il più recente, e
+la lista degli utenti ha una colonna **Ultimo accesso** ordinabile per ogni origine, così un account che nessuno usa salta all'occhio. Un accesso rifiutato non viene
+registrato, e un utente locale che non ha effettuato l'accesso dall'aggiornamento mostra `–`.
+
+**Cambia password** ed **Elimina** sono in alto a destra. L'utente `admin` non si può mai eliminare né rinominare.
diff --git a/i18n/it/_configure/users-and-groups/several-groups.md b/i18n/it/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..3f57f03
--- /dev/null
+++ b/i18n/it/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Più gruppi
+parent: Utenti e gruppi
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Più gruppi
+{: .no_toc }
+
+Un utente locale in più gruppi, e i loro ruoli
+{: .fs-6 .fw-300 }
+
+Un utente locale può appartenere a più gruppi, e riceve i ruoli di ciascuno di essi: i ruoli indicano un gruppo come `local/<group>`.
+
+Nella scheda **Gruppi**, **Aggiungi gruppo** aggiunge l'utente a un altro gruppo, e il menu di una riga o le caselle di spunta ne rimuovono uno.
+Un utente conserva almeno un gruppo. La lista degli utenti ha **Aggiungi a un gruppo** nel menu di ogni riga per fare lo stesso.
diff --git a/i18n/it/_get_started/first-form.md b/i18n/it/_get_started/first-form.md
new file mode 100644
index 0000000..c4f4333
--- /dev/null
+++ b/i18n/it/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: Il tuo primo modulo
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# Il tuo primo modulo
+{: .no_toc }
+
+Scrivi un playbook, crea un modulo per esso nel Designer, avvialo e ritrova il job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Questo tutorial parte da un'installazione nuova, vedi [Installazione](installation/). Richiede circa quindici minuti.
+
+---
+
+## 1. Accedi
+
+Apri AnsibleForms in un browser e accedi come amministratore.
+
+L'account predefinito è `admin` / `AnsibleForms!123` (o i tuoi valori [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)); si apre la pagina **Moduli**:
+
+![La pagina Moduli, con moduli di esempio](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Scrivi il playbook
+
+Un modulo `ansible` esegue un playbook dalla cartella dei playbook, quindi il playbook viene prima. Salva questo come `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+Il playbook legge quattro variabili. Il modulo che crei subito dopo le invia come extravars, una per campo.
+
+Metti il file nella cartella `playbooks` della cartella persistente
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); crea la cartella se non esiste ancora:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Dai sorgenti</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+La cartella che hai montato su `/app/dist/persistent`, `/srv/apps/ansibleforms/persistent` nell'esempio di installazione:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+La cartella `data/playbooks` del progetto docker-compose:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+Il volume persistente, montato su `/app/dist/persistent` nel pod di AnsibleForms. Trova il nome del pod, poi copia il file al suo interno:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+La cartella `persistent/playbooks` del server, `/srv/apps/ansibleforms/server` nell'esempio di installazione:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Quando un repository git ha **Usare per playbook?** attivato, i playbook vengono eseguiti da quel repository:
+> fai il commit di `hello.yaml` lì. Vedi [Designer e git](gui/designer-and-git.html).
+
+---
+
+## 3. Crea il modulo
+
+I moduli sono file YAML nella cartella dei moduli. Il Designer li modifica nel browser e li controlla prima di salvarli.
+
+1. Fai clic su **Designer** nel menu in alto, poi su **Moduli** nel menu a sinistra.
+2. Fai clic sull'interruttore in alto a destra (**Avvia designer**). Blocca la configurazione in modo che nessun altro la modifichi
+   nello stesso momento, e poi mostra **Bloccato da me**.
+3. Fai clic su **Nuovo file**, il primo pulsante della barra degli strumenti, e inserisci il nome file `hello-world.yaml`. Il Designer vi aggiunge un modulo
+   chiamato `New Form`.
+4. Sostituisci lo YAML nell'editor con questo modulo:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Fai clic su **Valida** (il segno di spunta), poi su **Salva**. Il salvataggio scrive `hello-world.yaml` nella cartella dei moduli.
+6. Fai di nuovo clic sull'interruttore per rilasciare il blocco.
+
+![Il Designer, durante la modifica di un modulo](assets/screenshots/designer.jpg)
+
+Il modulo usa quattro tipi di campo:
+
+| Campo | Tipo | Cosa fa |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Una casella di testo obbligatoria |
+| `target_env` | [`enum`](formfields/enum.html) | Un menu a tendina con un elenco fisso di `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Un menu a tendina riempito da un'[espressione](expressions/local.html) locale; `__auto__` seleziona il primo elemento |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Una casella di controllo, inviata come `true` o `false` |
+
+`vm_size` mostra entrambe le colonne, `size` e `cpus`, e invia `size`, la prima; `valueColumn` ne sceglie un'altra.
+
+`roles: [default]` permette a ogni utente che ha effettuato l'accesso di eseguire il modulo, e `categories: [Default]` lo mette nella categoria definita dal
+`config.yaml` predefinito.
+
+{: .note }
+> Puoi anche copiare `hello-world.yaml` in [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) e [validarlo in VS Code](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Avvialo
+
+Apri il modulo dalla pagina **Moduli**: fai clic su **Moduli** nel menu in alto e scegli **Hello world** nella categoria **Default**.
+
+Inserisci il tuo nome e cambia gli altri campi se vuoi. Fai clic su **Mostra variabili extra** per vedere cosa riceverà il playbook,
+poi fai clic su **Invia**:
+
+![Un modulo](assets/screenshots/form.jpg)
+
+---
+
+## 5. Segui l'output
+
+Il job parte subito, e il suo output compare sotto il modulo mentre viene eseguito, terminando con una barra **Completato**:
+
+![L'output di un job](assets/screenshots/run.jpg)
+
+Il task di debug stampa i tuoi valori, per esempio `Hello Alice: a small machine in development (dry run: True)`.
+
+L'avviso sul localhost implicito è normale senza un inventario; un modulo reale imposta [`inventory`](forms/ansible.html).
+
+---
+
+## 6. Ritrovalo nella cronologia dei job
+
+Ogni avvio viene conservato come job. Fai clic su **Job** nel menu in alto: il nuovo job è in cima a **Tutti i job**.
+
+Fai clic sul job per rivederne l'output, e su **Mostra variabili extra** per vedere cosa è stato inviato. Le icone davanti a ogni job
+lo rilanciano o lo eliminano:
+
+![La cronologia dei job](assets/screenshots/job-output.jpg)
+
+---
+
+## Prossimi passi
+
+Amplia questo modulo con le pagine di riferimento:
+
+* **[Moduli](forms/)** : ogni proprietà di un modulo, template sui runner, moduli workflow, punti di approvazione e notifiche
+* **[Campi del modulo](formfields/)** : tutti i tipi di campo, con validazione, dipendenze e layout
+* **[Espressioni](expressions/)** : riempi i campi da API REST, database e file
+* **[Ruoli](config/roles.html)** e **[categorie](config/categories.html)** in `config.yaml` : decidi chi vede quale modulo
+* **[Come funziona](how-it-works.html)** : cosa succede dietro un avvio, e dove viene salvato tutto
diff --git a/i18n/it/_get_started/installation/docker-compose.md b/i18n/it/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..c601b67
--- /dev/null
+++ b/i18n/it/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Installazione
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Installa AnsibleForms, il suo RTE e MySQL insieme con docker-compose o podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Il [progetto docker-compose](https://github.com/ansibleforms/docker) esegue tre container: MySQL, l'app AnsibleForms e l'RTE
+(ambiente di runtime) che esegue i playbook. Contiene le loro impostazioni, moduli e playbook di esempio, quindi l'unico altro requisito è
+Docker o Podman con il suo strumento compose.
+
+L'[installer](installer.html) scarica questo progetto, ne compila impostazioni e segreti e lo avvia con un solo comando. Questa pagina
+lo prepara a mano.
+
+---
+
+## Prerequisiti
+
+Prima di iniziare ti servono:
+
+* **Macchina Linux** : qualsiasi distribuzione, con CPU e memoria modeste
+* **Accesso a GitHub** : per scaricare o clonare il progetto docker-compose da GitHub
+* **Docker o Podman** : un motore di container, installato più sotto
+* **Uno strumento compose** : Docker Compose o podman-compose, per avviare i tre container da pochi file di configurazione
+
+**VIDEO**: [Come installare AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Scegli dove installare
+
+Crea una cartella per il progetto; gli esempi usano `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Clona il progetto docker-compose
+
+Installa Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Poi clona il progetto docker-compose in quella cartella:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Imposta i permessi corretti
+
+L'app e l'RTE girano come utente `node` (uid 1000), quindi assegna a quell'utente la cartella `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Se arrivi dalla 6, il cui container girava come root, esegui lo stesso `chown` una volta prima di avviare la 7. MySQL si riprende la propria cartella quando parte.
+
+---
+
+## Installa un motore di container
+
+Installa Docker o Podman, ognuno con il suo strumento compose:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Installa Docker Engine con il plugin Compose dal repository di Docker
+(vedi i [manuali di installazione di Docker](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Poi fai in modo che i nomi si risolvano dentro i container, e avvia Docker come servizio:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman non richiede un servizio. Installalo insieme a podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Personalizza
+
+Controlla le variabili nei file `.env` e `docker-compose.yml`, e cambia ogni password: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` e `RTE_TOKEN`. [Scopri di più sulle variabili d'ambiente](../customization)
+
+L'app si connette a MySQL come `ansibleforms` (`MYSQLDB_USER`), con tutti i diritti sullo schema `AnsibleForms` e nessuno
+altrove; root serve solo a MySQL stesso. MySQL crea quell'utente solo al primo avvio: un'installazione che finora si connetteva come root
+lo crea una volta, come mostra il [README](https://github.com/ansibleforms/docker#database) del progetto.
+
+L'RTE non è pubblicato sull'host. Dalla 7.3.0 l'app lo contatta su `http://rte:8000` con `RTE_TOKEN` e tiene aperto un WebSocket
+(`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)): l'RTE non riceve impostazioni del database né il `.env`, solo il suo token e alcune
+impostazioni proprie in `docker-compose.yml`. Il config seed `data/seed.yaml` dichiara una credenziale RTE con il token e quell'indirizzo,
+e il runner predefinito `rte`, in modalità inbound, che accede con essa. L'RTE esegue i playbook dalla stessa cartella `data`
+(`RTE_FILES=local`). Quando i tuoi playbook hanno bisogno di altre collection o librerie Python, crea un tuo RTE
+e fai puntare il servizio `rte` a esso (vedi [Crea il tuo RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Avvia il progetto docker-compose
+
+Avvia i tre container in background. L'app aspetta che MySQL sia healthy, poi contatta l'RTE:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Prova l'applicazione
+
+Una volta avviati i container, apri AnsibleForms in un browser:
+
+* Apri `https://your_ip` (porta 443, vedi `WEBAPP_LOCAL_PORT` nel file .env)
+* Accedi come `admin` con la `ADMIN_PASSWORD` del file `.env`; finché è ancora quella predefinita `AnsibleForms!123`, scegli una nuova password
+* Controlla in **Connessioni > Runner** che l'RTE sia elencato come `rte`, il runner predefinito, e che la sua pagina mostri la sua
+  **Connessione** come **Connesso**
+* Prossimi passi:
+  * Crea moduli aggiungendo file YAML alla cartella data/forms/ o usando il designer integrato
+  * Aggiungi i tuoi playbook alla cartella data/playbooks/
+  * Aggiungi una connessione LDAP
+  * Aggiungi utenti e gruppi
+  * Aggiungi runner per i moduli template: AWX, AAP o Ascender, Semaphore, Rundeck o Jenkins
+  * Aggiungi credenziali per connessioni esterne, come altri server MySQL o API REST, o da passare ai playbook Ansible
+  * Collega repository Git e scegli se i tuoi moduli e/o playbook si sincronizzano con un repository
+
+---
+
+## Struttura dei file
+
+Il progetto docker-compose ha la seguente struttura di cartelle:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/it/_get_started/installation/docker.md b/i18n/it/_get_started/installation/docker.md
new file mode 100644
index 0000000..2a27a71
--- /dev/null
+++ b/i18n/it/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Installazione
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Esegui le immagini dell'app e dell'RTE di AnsibleForms con Docker o Podman, accanto a un tuo server MySQL
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Puoi eseguire AnsibleForms con Docker o Podman come due container, l'app e l'RTE che esegue i playbook, collegati a un database MySQL.
+
+---
+
+## Prerequisiti
+
+Prima di iniziare ti servono:
+
+* **Docker o Podman** : uno dei due installato e in esecuzione
+* **MySQL** : installato e in esecuzione
+
+---
+
+## Installa MySQL
+
+Installa MySQL 8+, o MariaDB, su un server Linux raggiungibile dal container:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu include MySQL 8:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian include MariaDB al posto di MySQL, supportato anch'esso da AnsibleForms:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 e successivi, e le sue ricompilazioni, includono MySQL 8 in AppStream:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms si connette al database tramite la rete, come `DB_USER` con `DB_PASSWORD`. Dagli un utente tutto suo, con diritti solo
+sullo schema `AnsibleForms`, non root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+È tutto ciò che serve ad AnsibleForms: con questo crea e aggiorna il suo schema e fa i suoi backup. La pagina **Stato** e il log
+avvisano quando l'utente ha diritti su tutti i database. Su Ubuntu e Debian il server ascolta solo su localhost: imposta `bind-address` nella sua
+configurazione in modo che i container possano raggiungerlo.
+
+---
+
+## Prepara le cartelle
+
+AnsibleForms 7 gira in due container: l'app, e l'RTE (ambiente di runtime) che esegue i playbook. Entrambi montano una cartella per
+il tuo `config.yaml`, moduli, playbook, log e certificati, e una cartella per la chiave SSH. Le immagini girano come utente `node` (uid 1000),
+quindi assegna a quell'utente entrambe le cartelle:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Metti le impostazioni dell'app in un file di ambiente: la connessione al database,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) prima di salvare qualsiasi credenziale, il token che l'app e
+l'RTE condividono ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), almeno 16 caratteri) e il config seed che dichiara l'RTE:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+L'RTE riceve un file tutto suo, senza le impostazioni del database: dalla 7.3.0 l'app lo contatta e tiene aperto un WebSocket
+(`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)), ed esegue i playbook dalle stesse cartelle (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+Il [config seed](../seed/) dichiara una credenziale RTE con l'indirizzo dell'RTE e il suo token, e il runner predefinito `rte` che accede
+con essa:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Avvia i container
+
+Esegui le immagini pubblicate sul GitHub Container Registry (vedi [Tag delle immagini](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) per l'app e
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) per l'RTE.
+
+Il seed aggiunge l'RTE in **Connessioni > Runner** come runner `rte`, quello predefinito, così i moduli playbook vengono eseguiti su di esso senza altra
+configurazione. L'app crea lo schema al primo avvio, e contatta l'RTE quando entrambi sono in esecuzione (un `config.yaml` di esempio si trova nel
+[progetto docker-compose](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Una volta avviati, entrambi i container compaiono nell'elenco:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman accetta le stesse opzioni e non richiede un servizio:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Una volta avviati, entrambi i container compaiono nell'elenco:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+L'app ascolta sulla porta `8000`, in HTTP a meno che tu non imposti `HTTPS=1`. L'RTE non è pubblicato sull'host: solo l'app lo contatta, dentro
+la rete. `--stop-timeout 30` dà all'RTE il tempo di lasciar terminare i playbook in esecuzione durante uno stop (vedi
+[Eseguire un RTE](../rte/run.html) per le impostazioni dell'RTE e per creare un tuo RTE).
+
+---
+
+## Prova l'applicazione
+
+Una volta avviati i container, apri AnsibleForms in un browser:
+
+* Apri `http://your_ip:8000` (o HTTPS, se hai impostato `HTTPS=1`)
+* Accedi come `admin` / `AnsibleForms!123` (o con la password che hai impostato con `ADMIN_PASSWORD`), e scegli una nuova password
+* Controlla in **Connessioni > Runner** che l'RTE sia elencato come `rte`, il runner predefinito, e che la sua pagina mostri la sua
+  **Connessione** come **Connesso**
+* Prossimi passi:
+  * Crea moduli aggiungendo file YAML alla cartella `forms` o usando il designer integrato
+  * Aggiungi i tuoi playbook alla cartella `playbooks` della cartella persistente montata
+  * Aggiungi una connessione LDAP
+  * Aggiungi utenti e gruppi
+  * Aggiungi runner per i moduli template: AWX, AAP o Ascender, Semaphore, Rundeck o Jenkins
+  * Aggiungi credenziali per connessioni esterne, come altri server MySQL o API REST, o da passare ai playbook Ansible
diff --git a/i18n/it/_get_started/installation/from-source.md b/i18n/it/_get_started/installation/from-source.md
new file mode 100644
index 0000000..7b7b5eb
--- /dev/null
+++ b/i18n/it/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Dai sorgenti
+parent: Installazione
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Dai sorgenti
+{: .no_toc }
+
+Compila AnsibleForms dai sorgenti ed eseguilo con Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Come è organizzato il codice
+
+Il repository contiene due applicazioni Node.js, e una build le unisce in una sola:
+
+* **client** : l'interfaccia web, scritta in Vue 3 e compilata in file statici con Vite
+* **server** : l'API, scritta in Express. Passa i job ai runner, si connette al database e serve il client compilato.
+  Avviato con `AF_ROLE=rte`, lo stesso server è l'RTE (ambiente di runtime) che esegue i playbook
+
+Viene compilato solo il client; il suo output va nella cartella `views` del server, come nell'[immagine Docker](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Prerequisiti
+
+Compilare ed eseguire dai sorgenti richiede buone competenze Linux e qualche conoscenza di Node.js. Installi ogni componente tu stesso. Per
+eseguire AnsibleForms senza container e senza compilarlo, l'[installazione nativa](native.html) dell'installer fa tutto questo al posto tuo:
+
+* **Node.js 26** (la versione in `.nvmrc`; almeno la 24), con npm
+* **Git**, per ottenere il codice e sincronizzare i repository
+* **Client OpenSSH**, per git via SSH, e **sshpass**, per i playbook che si connettono con una password SSH
+* **Client MariaDB** (`mariadb`, `mariadb-dump`), per backup e ripristini, anche con un server MySQL
+* **MySQL 8+ o MariaDB**, raggiungibile dal server
+* **Ansible**, per il processo RTE che esegue i playbook (`ansible-playbook` nel suo path). Il processo dell'app non ha bisogno
+  né di Ansible né di Python, e con soli moduli template (AWX, AAP, Ascender e gli altri runner) non ti serve affatto un RTE
+
+Installali per la tua distribuzione:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 arriva dal repository NodeSource, gli altri strumenti da Ubuntu stesso:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 arriva dal repository NodeSource, gli altri strumenti da Debian stesso:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js arriva da NodeSource e `sshpass` da EPEL (su RHEL stesso, abilita EPEL come documenta Red Hat):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Controlla `node --version` (26) e `ansible-playbook --version`; per il database e il suo utente, vedi [Installa MySQL](docker.html#install-mysql).
+
+---
+
+## Ottieni il codice
+
+Clona il repository in una cartella a tua scelta, di proprietà dell'utente che eseguirà l'applicazione. Gli esempi usano `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Compila
+
+Compila in tre passi, dalla cartella del repository. Prima compila il client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Poi installa le dipendenze del server:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Infine copia il client compilato nella cartella `views` del server:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Configura
+
+Il server legge le sue impostazioni dalle variabili d'ambiente e, in produzione, anche da `server/persistent/.env`, il file
+in cui scrivono le pagine delle impostazioni.
+
+Parti dal file di esempio nella radice del repository e imposta almeno la connessione MySQL (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Tutte le variabili sono descritte in [Variabili d'ambiente](../customization). Tutto il resto viene salvato per impostazione predefinita in `server/persistent`:
+`config.yaml`, la cartella `forms` e i certificati autofirmati vengono creati lì al primo avvio, insieme ai log.
+Metti i tuoi playbook in `server/persistent/playbooks`, oppure fai puntare `ANSIBLE_PATH` altrove nell'ambiente dell'RTE, che la legge.
+
+---
+
+## Esegui
+
+Esegui AnsibleForms in produzione, o in modalità sviluppo per lavorare sul codice stesso:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Produzione</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Sviluppo</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Avvia il server in modalità produzione dalla cartella `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Un'applicazione avviata dalla riga di comando si ferma quando ti disconnetti. [PM2](https://pm2.keymetrics.io/) la tiene in esecuzione in
+background, la riavvia dopo un crash e la avvia di nuovo al boot:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+I playbook vengono eseguiti su un RTE: avvia lo stesso server una seconda volta con `AF_ROLE=rte`, su una porta tutta sua. L'app lo contatta e tiene
+aperto un WebSocket (`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)), ed esso esegue i playbook dalle stesse cartelle
+(`RTE_FILES=local`). Legge anche `persistent/.env`, ma non usa nessuna delle sue impostazioni del database. Aggiungi a `persistent/.env` il token che l'app e l'RTE condividono,
+di almeno 16 caratteri, e il config seed che dichiara l'RTE:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+Il [config seed](../seed/) dichiara una credenziale RTE con l'indirizzo dell'RTE e il suo token, e il runner predefinito `rte` che accede
+con essa:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Senza un seed, aggiungili in **Connessioni > Credenziali** (una credenziale RTE con quell'indirizzo e il token) e
+**Connessioni > Runner** (tipo RTE, **Modalità** **In entrata**). Poi avvia l'RTE, solo su `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+Le impostazioni dell'RTE sono descritte nella pagina [Eseguire un RTE](../rte/run.html). Controlla che PM2 elenchi entrambi i processi:
+
+```bash
+pm2 status
+```
+
+Entrambi sono `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Per lavorare sul codice stesso, avvia tutto dalla radice del repository con live reload: il server sulla porta 3001, un RTE sulla porta 8010
+e il client su `https://localhost:8443`. In questa modalità, il server e l'RTE leggono invece `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+L'RTE (`npm run dev:rte`) ha bisogno di `ansible-playbook` nel path, e si aggiunge come runner in modalità database, deprecata, solo per
+lo sviluppo; `npm run dev:local` avvia il client e il server senza di esso. La [guida per contribuire](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) descrive i test e i controlli da eseguire.
+
+</div>
+</div>
+
+---
+
+## Primo avvio
+
+Apri il server in un browser (con il `.env` di esempio, `https://your_ip:8443`). Su un database vuoto, lo schema viene creato al
+primo avvio.
+
+Le credenziali di amministratore predefinite sono:
+
+* nome utente : `admin`
+* password : `AnsibleForms!123`
diff --git a/i18n/it/_get_started/installation/index.md b/i18n/it/_get_started/installation/index.md
new file mode 100644
index 0000000..03b9853
--- /dev/null
+++ b/i18n/it/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Installazione
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Installazione
+{: .no_toc }
+
+Scegli un metodo di installazione per AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori che preparano una nuova istanza: scegli un metodo di installazione, poi segui la sua pagina.
+
+---
+
+## In questa sezione
+
+AnsibleForms supporta diversi metodi di installazione, ognuno descritto nella propria pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Installer](installer.html) | Un solo comando che installa un controller o un Runner su Docker, Podman, Kubernetes o in modo nativo, e poi lo aggiorna e ne fa il backup |
+| [Nativa](native.html) | L'installazione dell'installer senza container: Node.js, MariaDB e Ansible sul server, AnsibleForms come servizi systemd |
+| [Docker](docker.html) | Installa MySQL ed esegui l'immagine Docker precompilata con le variabili d'ambiente necessarie |
+| [Docker Compose](docker-compose.html) | Scarica il [progetto docker-compose](https://github.com/ansibleforms/docker) e usa docker-compose per avviare sia MySQL sia AnsibleForms |
+| [Dai sorgenti](from-source.html) | Installa a mano tutte le dipendenze, poi compila e avvia il codice |
+| [Kubernetes](kubernetes.html) | Installa il chart Helm e usa Kubernetes per avviare AnsibleForms e il suo database MySQL |
+
+{: .note }
+> **Consiglio** L'installer, dalla 7.3.0, è il modo più rapido per avere un'istanza funzionante: prepara il progetto Docker Compose su
+> Docker o Podman, o uno degli altri metodi, a partire da poche domande. Le immagini Docker includono tutte le dipendenze.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Per portare un'installazione esistente a una versione più recente, vedi [Aggiornamento](../upgrading/).
+
+Ogni metodo esegue un RTE accanto all'app, il container (o servizio) che esegue i playbook. Per aggiungerne un altro, su un altro host o in un altro
+datacenter, installa un Runner con l'[installer](installer.html#a-runner): si collega ad AnsibleForms tramite un unico WebSocket (in uscita, vedi
+[Modalità](../rte/modes.html)) e non contiene credenziali del database. Vedi anche [Ambienti di runtime](../rte/) e il relativo runbook
+[Un RTE in un altro datacenter](../rte/another-datacenter.html).
+
+---
+
+## Tag delle immagini
+
+L'immagine è pubblicata come `ghcr.io/ansibleforms/ansibleforms` sul GitHub Container Registry, che appartiene al
+progetto e non limita i pull anonimi. Ogni versione dalla 7.0.0 in poi è pubblicata solo lì, e ci sono anche
+le versioni 6.x.
+
+Dalla 7, i playbook vengono eseguiti su un RTE, pubblicato in tre livelli accanto all'app (vedi [Le immagini RTE](../rte/images.html)):
+
+| Immagine | Cos'è |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | L'applicazione web e l'API, senza python né ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | L'RTE senza python né ansible: la base per il tuo |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | La base con python, ansible-core e alcune librerie: quella a cui aggiungere le tue collection |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | La core con il pacchetto `ansible`, le sue collection e librerie: l'RTE predefinito |
+
+Le quattro immagini sono compilate nella stessa esecuzione e hanno gli stessi tag, quindi il tag di un RTE corrisponde sempre a quello dell'app.
+
+Il vecchio repository su Docker Hub, `ansibleguy/ansibleforms`, non viene più aggiornato. Conserva le versioni
+esistenti ma non riceve nuove versioni di nessuna delle due linee. Se fai il pull da lì, passa
+a `ghcr.io/ansibleforms/ansibleforms` con lo stesso tag per continuare a ricevere aggiornamenti.
+
+Su ogni immagine sono disponibili i seguenti tag; le immagini RTE partono dalla 7.0.0, quindi non hanno tag 6.x:
+
+| Tag | Punta a |
+|---|---|
+| `latest` | l'ultima versione della major più recente |
+| `7`, `6` | l'ultima versione di quella major |
+| `7.0`, `6.5` | l'ultima versione di quella minor |
+| `7.0.0`, `6.5.5` | esattamente quella versione |
+| `latest-rc` | l'ultima release candidate, o l'ultima versione quando è più recente; ogni candidate ha anche il suo tag |
+
+`latest` va solo avanti: una patch per una major più vecchia (per esempio una 6.5.x pubblicata
+dopo la 7.0.0) sposta `6` e `6.5`, ma mai `latest`.
+
+Per restare su una major, usa il suo numero (`6`) invece di `latest`.
diff --git a/i18n/it/_get_started/installation/installer.md b/i18n/it/_get_started/installation/installer.md
new file mode 100644
index 0000000..7b25e0e
--- /dev/null
+++ b/i18n/it/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Installer
+parent: Installazione
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# L'installer
+{: .no_toc }
+
+Installa, aggiorna e gestisci AnsibleForms su un server Linux, con un solo comando
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori: il modo più rapido per avere un'istanza funzionante, o un Runner per un AnsibleForms installato altrove. Dalla 7.3.0.
+
+---
+
+## Cosa installa
+
+L'installer fa alcune domande in una procedura guidata a schermo intero, mostra ogni risposta da rivedere, e solo allora modifica il server.
+Installa uno di due ruoli, su uno di quattro motori:
+
+| Ruolo | Cos'è |
+|---|---|
+| Controller | L'applicazione completa: l'interfaccia web, il suo database e il suo Runner. Sceglilo per una prima installazione |
+| Runner | Un RTE che esegue i playbook di un AnsibleForms installato altrove, per esempio in un'altra rete, in una DMZ o in un altro datacenter. Parla con AnsibleForms tramite un unico WebSocket e non contiene credenziali del database |
+
+I motori su cui li installa:
+
+| Motore | Come gira |
+|---|---|
+| Docker | Il [progetto Docker Compose](docker-compose.html), su Docker Engine con il suo plugin compose. I container si riavviano insieme a Docker |
+| Podman | Lo stesso progetto su Podman, rootless o come root, con podman-compose. Una unit systemd avvia i container al boot |
+| Kubernetes | Il [chart Helm](kubernetes.html), sul cluster raggiunto da `kubectl`. Un controller viene servito dietro un ingress; un Runner usa la modalità runner del chart |
+| Direttamente su questo server | Nessun container: Node.js, MariaDB e Ansible sul server, e AnsibleForms come servizi systemd. Vedi [Installazione nativa](native.html) |
+
+Dopo l'installazione, lo stesso programma aggiorna l'installazione, ne fa il backup, ne mostra lo stato e la rimuove. Prende anche in carico un
+AnsibleForms che non ha installato lui, come uno preparato a mano dal progetto Docker Compose (vedi [Un'installazione esistente](#an-existing-installation)).
+
+---
+
+## Eseguilo
+
+Lo script di installazione scarica l'installer per questo server e lo avvia:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Le varianti abituali: come root, per installare Docker o Podman, per installare direttamente sul server o sotto `/opt`; con un comando o
+dei flag (vedi [Flag](#flags)); e l'installer di una versione precisa invece dell'ultima:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+Lo script:
+
+1. Controlla che il server esegua Linux su amd64 o arm64, e trova `curl` o `wget` e `sha256sum`
+2. Scarica `ansibleforms-installer_linux_<arch>` dall'ultima release di
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases), o dalla release indicata da `AF_INSTALLER_VERSION`
+3. Lo verifica con il `checksums.txt` della release, e non usa nessun download il cui checksum sia diverso
+4. Lo conserva come `ansibleforms-installer`, in `/usr/local/bin` per root e altrimenti in `~/.local/bin`, per gli aggiornamenti e i backup successivi.
+   Tramite sudo, eseguilo con il percorso completo: il `secure_path` di sudo, come sui sistemi Red Hat, spesso non include `/usr/local/bin`
+5. Lo avvia con i flag indicati, leggendo la tastiera dal terminale anche se lo script è arrivato tramite una pipe
+
+Senza un terminale, come in un job di CI, l'installer gira senza interazione (vedi [Senza interazione](#unattended)).
+
+---
+
+## La procedura guidata
+
+La procedura guidata fa una domanda alla volta, con i passi elencati a sinistra. **Esc** torna al passo precedente, mantenendo la sua risposta:
+
+| Passo | Cosa chiede |
+|---|---|
+| Lingua | La lingua dell'installer, per impostazione predefinita quella del locale di questo server: catalano, tedesco, inglese, spagnolo, francese, italiano, giapponese, olandese, polacco, portoghese o cinese. Viene chiesta per prima, prima che l'installer dica qualcosa su un'installazione che ha trovato |
+| Novità | Cosa c'è di nuovo nella versione che installa, con prima le modifiche incompatibili, le rimozioni e le deprecazioni |
+| Ruolo | Controller o Runner |
+| Motore | Docker, Podman, Kubernetes, o direttamente su questo server |
+| Cartella | La cartella di installazione, e il nome dell'istanza |
+| Join, App, Modalità | Solo un Runner: vedi [Un Runner](#a-runner). Non la modalità su Kubernetes |
+| Rete | La porta dell'interfaccia web, o del Runner. Non su Kubernetes |
+| HTTPS | Come i browser si collegano a un controller |
+| Admin | La password del primo admin, digitata due volte |
+| Cluster, Ingress, Storage | Solo Kubernetes: il namespace e la release, l'ingress (un controller), la classe di storage |
+| Riepilogo | Ogni risposta: **Installa**, o **Modifica risposte** |
+
+**Motore.** L'elenco mostra ciò che questo server ha. Un motore che manca viene proposto come *Docker (non installato: lo installa l'installer)*
+o lo stesso per Podman: una volta confermato, l'installer installa Docker con lo script di Docker stesso (`get.docker.com`, plugin compose
+incluso) o Podman con podman-compose dai pacchetti della distribuzione. Questo richiede root. Kubernetes viene proposto quando `kubectl` e
+`helm` sono installati e raggiungono un cluster. *Direttamente su questo server* richiede root e un Linux supportato, e dice il perché quando è disattivato.
+
+**Cartella.** I valori predefiniti:
+
+| | Controller | Runner |
+|---|---|---|
+| Cartella, come root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Cartella, come altro utente | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Nome dell'istanza, Docker o Podman | `af` | `runner` |
+| Nome dell'istanza, nativa | `ansibleforms` | `ansibleforms-runner` |
+
+Con Docker o Podman, la cartella contiene il file compose e il suo `.env` con i segreti, e tutti i dati: database, moduli, playbook
+e log. Deve essere vuota. Il nome dell'istanza, lettere minuscole, cifre e `-`, fa da prefisso ai container (`af_app`, `af_db`, `af_rte`), così più
+istanze possono condividere un server. Il nome dell'istanza di un Runner è anche il nome del suo runner in **Connessioni > Runner** (`RTE_NAME`).
+
+**Rete.** L'interfaccia web di un controller ascolta su `443`, o sulla prima porta libera successiva. **HTTPS** propone poi:
+
+| Scelta | Cosa fa |
+|---|---|
+| HTTPS con un certificato autofirmato creato per questo server | Un certificato per i nomi di questo server, valido dieci anni. I browser ti chiedono di accettarlo una volta |
+| HTTPS con il mio certificato e la mia chiave | Il tuo certificato e la tua chiave, in formato PEM, dalla tua CA o da Let's Encrypt |
+| HTTP, con HTTPS gestito da un reverse proxy davanti | HTTP semplice sulla porta, per nginx, Traefik o un load balancer che gestisce l'HTTPS |
+
+**Admin.** La password dell'utente `admin`, digitata due volte perché un errore di battitura non ti chiuda fuori. Se la lasci vuota, l'installer ne genera
+una robusta.
+
+**La fine.** L'installer genera la password del database e i segreti, avvia AnsibleForms e aspetta che risponda. Poi
+mostra l'indirizzo da aprire, l'utente e la password, e la cartella. I Runner installati per esso chiedono di unirsi, e un admin li approva
+in **Connessioni > Runner** (vedi [Un Runner](#a-runner)).
+
+---
+
+## Un Runner
+
+Un Runner è un RTE per un AnsibleForms che gira altrove, alla versione 7.3.0 o successiva. Non contiene credenziali del database: accede
+con un token tutto suo, che AnsibleForms conserva in una credenziale RTE (vedi [Modalità](../rte/modes.html)). Dopo la cartella, la procedura guidata
+chiede altre tre cose:
+
+| Passo | Cosa chiede |
+|---|---|
+| App | L'indirizzo dell'AnsibleForms per cui lavora questo Runner, quello che le persone aprono in un browser |
+| Modalità | **In uscita: il Runner si collega ad AnsibleForms** (il predefinito), o **In entrata: AnsibleForms si collega al Runner** |
+| Rete | La porta del Runner, `8000` per impostazione predefinita. In uscita, su di essa ascoltano solo i controlli di salute, raggiungibili solo da questo server. In entrata, anche l'indirizzo di questo server così come lo raggiunge AnsibleForms |
+
+`--role runner` salta la domanda sul ruolo, quindi questo comando, eseguito sul server del Runner, parte con le domande di un Runner:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+L'installer si collega poi ad AnsibleForms. Un certificato autofirmato, o di una CA privata, chiede **Considerare attendibile questo certificato?**:
+sì imposta [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) sul Runner. Legge la versione su cui gira AnsibleForms,
+rifiuta una versione precedente alla 7.3.0, e installa il Runner con quella stessa versione, qualunque versione installerebbe l'installer.
+
+Scegli in uscita per una DMZ, un NAT, o una zona che non consente connessioni in ingresso: solo traffico da questo server verso AnsibleForms, sulla sua
+porta. Scegli in entrata per le reti in cui è il lato centrale ad aprire ogni connessione.
+
+Il riepilogo mostra **Registrazione: chiede approvazione**, o **da solo, con un token di adesione** quando `--join` ne ha fornito uno. Alla fine l'installer
+mostra il nome del Runner, la sua modalità, l'app e, in entrata, il suo indirizzo, poi dice di aver chiesto di unirsi ad AnsibleForms: approvalo in
+**Connessioni > Runner**, dopo aver controllato che l'impronta mostrata lì sia quella che stampa:
+
+```
+Fingerprint: abcd-ef12
+```
+
+L'impronta sono le prime 8 cifre esadecimali dello SHA-256 del token del Runner, `RTE_TOKEN`, che è conservato nel file `.env`
+della cartella (`rte.env` per un'[installazione nativa](native.html)). Vedi [Approvare un RTE](../runners/registration.html#approving-an-rte). Con `--join`, il Runner viene approvato subito:
+si è registrato da solo, e risulta connesso in **Connessioni > Runner**.
+
+Un Runner in entrata serve il suo socket in HTTPS. L'installer crea un certificato autofirmato per l'indirizzo su cui AnsibleForms
+lo raggiunge, valido dieci anni, nella `data/certificates` della cartella, e imposta `RTE_URL` su `https://<address>:<port>`.
+Il Runner invia il certificato quando chiede di unirsi, e AnsibleForms lo fissa (pinning): contatta quel Runner solo quando presenta
+quello stesso certificato, quindi non serve nessuna CA. L'installer stampa l'impronta del certificato sotto quella del token:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+Sono le prime 8 cifre esadecimali dello SHA-256 dei byte DER del certificato, come `xxxx-xxxx`. Prima di approvare il Runner,
+controlla che la finestra di approvazione mostri la stessa impronta del certificato. Anche un Runner registrato con `--join` la stampa.
+
+Su Kubernetes, un Runner è la modalità runner del chart Helm, e sempre in uscita: la procedura guidata non chiede né la modalità né la rete, perché niente
+lo raggiunge dall'esterno (vedi [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Per un controller su Kubernetes, l'installer installa il [chart Helm](kubernetes.html) sul cluster raggiunto da `kubectl`:
+
+| Domanda | Predefinito |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nome della release Helm | `ansibleforms` |
+| Hostname servito dall'ingress | Nessuno: obbligatorio, per esempio `ansibleforms.example.com` |
+| Classe di ingress | Una di quelle del cluster, `nginx` per impostazione predefinita |
+| Servirlo in HTTPS (con il certificato dell'ingress)? | Sì |
+| Classe di storage per i volumi | Quella predefinita del cluster |
+
+La password dell'admin si trova nel Secret `<release>-secrets` di quel namespace, sotto la chiave `ADMIN_PASSWORD`. L'installer conserva i
+valori del chart in un file accanto al suo file di stato, `<release>-values.yaml`, e lo riapplica negli aggiornamenti; `--values` aggiunge un tuo file. Il chart di una release viene pubblicato poco dopo di essa.
+
+Per un Runner, l'installer installa lo stesso chart nella sua [modalità runner](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): un RTE
+da solo, senza app, senza database e senza ingress, che contatta AnsibleForms (in uscita). Dopo l'indirizzo dell'app, la procedura guidata chiede:
+
+| Domanda | Predefinito |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nome della release Helm | `ansibleforms-runner`, che è anche il nome del suo runner in **Connessioni > Runner** |
+| Classe di storage per i volumi | Quella predefinita del cluster |
+
+L'installer crea il token del Runner e imposta l'indirizzo dell'app, il nome del runner e, quando consideri attendibile il certificato dell'app,
+`runner.appTlsVerify: false`. Con `--join`, il token di adesione approva subito il Runner; senza, il Runner chiede di unirsi, e
+l'installer stampa la sua impronta da controllare prima di approvarlo in **Connessioni > Runner**.
+
+---
+
+## Comandi
+
+L'installer accetta un comando, prima o dopo i suoi flag. Senza comando, installa:
+
+| Comando | Cosa fa |
+|---|---|
+| `install` | Installa AnsibleForms, come controller o come Runner (il predefinito). Su un server che ha già un'installazione, la sua o una che trova, propone di aggiornarla |
+| `upgrade` | Aggiorna a una versione più recente, mostrando prima le sue note di rilascio (vedi [Aggiornamento](#upgrade)) |
+| `status` | Mostra l'installazione (il suo ruolo, motore e versione) e i suoi container, pod o servizi, e se risponde. Poi elenca ogni altro AnsibleForms che trova sul server |
+| `backup` | Fa subito il backup del database, in `installer-backups` nella cartella di installazione (su Kubernetes, `backups` accanto al file di stato dell'installer). Un Runner non contiene dati di cui fare il backup |
+| `release-notes` | Mostra le note di rilascio di una versione, `--version` o quella di questo installer, con prima le modifiche incompatibili |
+| `uninstall` | Rimuove l'installazione, e con `--purge` i suoi dati |
+| `version` | Stampa la versione dell'installer |
+
+L'installer ricorda l'installazione in `/etc/ansibleforms/installer.json` per root, o in `~/.config/ansibleforms/installer.json`
+per un altro utente, così i comandi dopo `install` non hanno bisogno di flag e trovano l'installazione da soli. Quella cartella non contiene binari,
+ed esiste solo dopo che l'installer ha installato un AnsibleForms o ne ha preso in carico uno:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` chiede **Eliminare anche i suoi dati (database, moduli, playbook, log)?**. Per eliminarli, digita il nome dell'istanza (la release Helm
+su Kubernetes); altrimenti rimuove i container, i pod o i servizi e conserva i dati.
+
+---
+
+## Flag
+
+Ogni flag risponde a una domanda, che la procedura guidata poi salta. `ansibleforms-installer --help` li elenca:
+
+| Flag | A cosa risponde |
+|---|---|
+| `--lang <code>` | La lingua: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` o `zh` |
+| `--version <version>` | La versione di AnsibleForms da installare o a cui aggiornare; per impostazione predefinita quella di questo installer |
+| `--role <role>` | `controller` o `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` o `native` |
+| `--runtime <runtime>` | `docker` o `podman` (compose) |
+| `--install-runtime` | Installa Docker o Podman se mancano, senza chiedere |
+| `--dir <folder>` | La cartella di installazione (compose) |
+| `--name <name>` | Il nome dell'istanza, prefisso dei suoi container (compose, `af` per impostazione predefinita) |
+| `--port <port>` | La porta sull'host: l'interfaccia web per un controller, l'RTE per un Runner |
+| `--tls <choice>` | `self`, `own` o `off` (un controller compose) |
+| `--cert <file>`, `--key <file>` | I file del certificato e della chiave, con `--tls own` |
+| `--admin-password <password>` | La password del primo admin; generata per impostazione predefinita |
+| `--join <token>` | Un token di adesione (`afj_...`), creato tramite l'API, che approva subito il Runner (un Runner, senza interazione; vedi [Token di adesione](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | L'indirizzo dell'app, per esempio `https://forms.example.com` (un Runner) |
+| `--runner-mode <mode>` | `outbound` (l'RTE contatta l'app) o `inbound` (l'app contatta l'RTE) (un Runner) |
+| `--host <address>` | L'indirizzo di questo server, che l'app contatta (un Runner in entrata) |
+| `--namespace <namespace>` | Il namespace Kubernetes, `ansibleforms` per impostazione predefinita |
+| `--release <release>` | La release Helm, `ansibleforms` per impostazione predefinita |
+| `--hostname <name>` | L'hostname dell'ingress (kubernetes) |
+| `--ingress-class <class>` | La classe di ingress (kubernetes) |
+| `--storage-class <class>` | La classe di storage (kubernetes) |
+| `--values <file>` | Un file di valori Helm aggiuntivo (kubernetes) |
+| `--purge` | Con `uninstall`: elimina anche i dati |
+| `--source <folder>` | Una copia locale del repository [ansibleforms/docker](https://github.com/ansibleforms/docker) da cui installare (air-gapped) |
+| `--bundle <file>` | Un bundle di release, `ansibleforms-<version>-linux-<arch>.tar.gz`, da cui installare in modo nativo (vedi [Installazione nativa](native.html#air-gapped)) |
+| `--yes` | Risponde a ogni domanda con il suo valore predefinito (senza interazione) |
+| `--verbose` | Mostra ogni comando che esegue |
+
+---
+
+## Senza interazione
+
+Con `--yes`, o senza un terminale, l'installer non chiede nulla: i flag rispondono alle loro domande e i valori predefiniti al resto. Salta
+la lingua, le note di rilascio, la password dell'admin (generata, a meno che `--admin-password` non ne fornisca una) e il riepilogo, e stampa
+invece il link alle note di rilascio. Installa un Docker o un Podman mancante solo con `--install-runtime` o `--yes`, e un Runner
+ha bisogno di `--app-url`. Senza `--join`, il Runner chiede di unirsi e aspetta l'approvazione di un admin; con esso, viene approvato subito.
+
+Un controller su Docker, che installa Docker se manca:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Un Runner in entrata su Podman, che l'app contatta su `rte-dmz.example.com:8000`:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Un'installazione esistente
+
+L'installer ricorda cosa ha installato in `installer.json`. Senza quel file, `install`, `upgrade` e `status` cercano prima un
+AnsibleForms già presente sul server, chiunque l'abbia installato:
+
+| Trovato | Come viene trovato | Preso in carico quando |
+|---|---|---|
+| Docker o Podman | Container dell'immagine dell'app o dell'RTE, raggruppati per progetto compose | La cartella contiene il file compose e il `.env` del repository [ansibleforms/docker](https://github.com/ansibleforms/docker): i servizi `mysqldb`, `app` e `rte`, nei container `<name>_db`, `<name>_app` e `<name>_rte` |
+| Un Runner 7.2 | Un RTE da solo nel suo progetto compose, con i `DB_*` dell'app e senza `RTE_MODE` (modalità database) | Il suo file compose è leggibile. Il suo aggiornamento lo porta a una modalità socket (vedi [Un Runner 7.2](#a-72-runner)) |
+| Kubernetes | Release Helm del chart `ansibleforms`, e Deployment e StatefulSet delle sue immagini | È una release del chart: i suoi valori attuali diventano il suo file di valori |
+| Nativa | Servizi systemd che eseguono AnsibleForms con Node.js | Seguono la struttura dell'installer: `releases/`, `current`, `app.env` e `rte.env` (vedi [Installazione nativa](native.html#the-folder)) |
+| Nessun motore | L'app o un RTE che risponde su una porta abituale: 443, 3000, 3001, 8000, 8001, 8010 o 8443 | Mai: gira dai sorgenti o a mano. L'installer si limita a segnalarlo |
+
+Contano solo le immagini dell'app e dell'RTE: un container MySQL con un nome che richiama AnsibleForms non è un'installazione. L'installer elenca ciò che
+ha trovato, una riga ciascuno, con il motivo e cosa fare a mano per uno che non può prendere in carico: il suo file compose non è quello del repository,
+il suo database è fuori dal suo progetto compose, gira su Kubernetes senza il chart Helm, è gestito da Argo CD (aggiornalo lì,
+cambiando la versione del chart dell'Application), o la sua versione non si può leggere.
+
+Per un'installazione che può prendere in carico, `install` propone tre scelte:
+
+| Scelta | Cosa fa |
+|---|---|
+| Prendi in carico e aggiorna | Mostra cosa ricorderà, poi scrive `installer.json` una volta che confermi, e prosegue con l'[aggiornamento](#upgrade) |
+| Installa comunque un nuovo AnsibleForms accanto | Una seconda installazione, con la sua cartella, le sue porte e il suo database, dopo una conferma apposita |
+| Interrompi | Non viene modificato nulla |
+
+Per un'installazione che esegue già la versione che l'installer installerebbe, la prima scelta è invece **Prendi in carico**: l'installer
+ricorda dove si trova e come gira, per i suoi backup, lo stato e i prossimi aggiornamenti, e per ora non viene modificato nulla.
+
+`upgrade` propone lo stesso senza la seconda scelta, e si ferma quando non c'è nulla da prendere in carico. Senza interazione, `install` si ferma con un messaggio,
+e `upgrade --yes` prende in carico un'installazione solo quando ne trova esattamente una che può prendere in carico. I valori attuali di una release Kubernetes vengono
+salvati accanto a `installer.json`, e gli aggiornamenti li riapplicano con il chart della nuova versione.
+
+---
+
+## Aggiornamento
+
+`ansibleforms-installer upgrade` porta l'installazione a una versione più recente della stessa major. Elenca le versioni più recenti,
+a partire dall'ultima (senza interazione, prende l'ultima), e mostra le note di rilascio di ogni versione che supera, con prima le modifiche incompatibili
+e le rimozioni. Quando contengono modifiche incompatibili, ti chiede di confermare di averle lette; senza interazione, prosegue solo con `--yes`.
+
+L'installer fa il backup del database prima di modificare qualsiasi cosa. Quando la nuova versione non risponde, propone di tornare indietro: la versione
+precedente ritorna, e il suo database viene ripristinato da quel backup. Non fa downgrade, e non attraversa una major: segui
+la [guida all'aggiornamento](../upgrade-7.html) per questo, per esempio dalla 6.x alla 7.x, con cosa fare sulla 6.5 prima di aggiornare.
+
+Su Docker o Podman, l'aggiornamento di un controller porta anche i suoi file in linea con la nuova versione del repository docker:
+
+| File | Cosa fa l'aggiornamento |
+|---|---|
+| `docker-compose.yml` | Sostituito da quello della nuova versione, dopo averne salvato una copia in `installer-backups` |
+| `.env` | Ogni riga esistente viene mantenuta, e vengono aggiunte le chiavi di cui la nuova versione ha bisogno, con i segreti creati come li crea un'installazione nuova. Prima ne viene salvata una copia |
+| `data/seed.yaml` | Sostituito quando è un seed fornito dal repository docker, non modificato. Uno modificato a mano viene mantenuto, e quello nuovo viene salvato accanto |
+| `data/` | I nuovi file portati dalla versione, come un nuovo playbook, vengono aggiunti. Ogni file esistente viene mantenuto |
+
+Un'impostazione del database mancante (`MYSQLDB_USER` o una password) non si può inventare per un database che esiste, quindi l'aggiornamento allora si ferma prima
+di qualsiasi modifica. Un rollback rimette il file compose, il `.env` e il seed com'erano.
+
+Un Runner esegue la stessa versione del suo AnsibleForms: aggiorna prima AnsibleForms, poi i suoi Runner. L'aggiornamento di un Runner riscrive il suo
+file compose per la nuova immagine RTE e mantiene il suo `.env` e i suoi dati così come sono.
+
+---
+
+## Un Runner 7.2
+
+Un Runner della 7.2 gira in modalità database, deprecata dalla 7.3.0: il suo RTE contiene le impostazioni del database di AnsibleForms. L'installer lo
+trova (vedi [Un'installazione esistente](#an-existing-installation)), e il suo aggiornamento lo porta a una modalità socket con lo stesso runner:
+
+1. Legge il nome del runner (`RTE_NAME`) e il token (`RTE_TOKEN`) dal vecchio container RTE. Quando l'RTE non si è registrato da solo
+   (`RTE_REGISTER=0`), digiti il nome che il suo runner ha in **Connessioni > Runner**
+2. Chiede l'indirizzo dell'app e la modalità, **in uscita** per impostazione predefinita o in entrata, e in entrata la porta e l'indirizzo di questo server
+3. Mostra il piano, poi fa il backup del vecchio file compose e del `.env` in `installer-backups`
+4. Scrive la struttura Runner dell'installer senza le impostazioni `DB_*`. Mantiene `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` e `METRICS_TOKEN`, che un RTE in modalità socket legge ancora
+5. Avvia il nuovo RTE accanto al vecchio. Il nuovo RTE accede con il token del runner stesso, e AnsibleForms sposta da sé il runner alla
+   nuova modalità, **senza approvazione**: i suoi job e i moduli che lo nominano restano invariati
+6. Una volta che il nuovo RTE è connesso, il vecchio container viene fermato e rimosso
+
+Un Runner in entrata serve HTTPS con un certificato fissato, come uno nuovo (vedi [Un Runner](#a-runner)), e l'installer stampa l'impronta del suo
+certificato. Quando il vecchio RTE occupa la porta che serve al nuovo, viene fermato prima, quindi il Runner resta offline finché il
+nuovo non si connette. Il nuovo RTE di un Runner in uscita prende una porta libera su `127.0.0.1` e gira accanto al vecchio senza interruzioni.
+
+Quando l'installer non riesce a leggere un token dal vecchio RTE, scegli tu come accede il nuovo RTE:
+
+| Scelta | Cosa segue |
+|---|---|
+| Scrivere il token del runner | La password della credenziale RTE del runner in **Connessioni > Credenziali**. Il runner mantiene il suo nome e i suoi job |
+| Unirsi come nuovo runner con un token di adesione | Un [token di adesione](../runners/registration.html#join-tokens) aggiunge un nuovo runner con un altro nome. Ritira a mano il vecchio runner |
+
+Quando il nuovo RTE non si connette, l'installer propone di rimettere i vecchi file e riavviare il vecchio container; se AnsibleForms
+aveva già spostato il runner, riporta la sua modalità a database in **Connessioni > Runner**. Una volta che il nuovo RTE è connesso, non si
+torna indietro: i vecchi file restano in `installer-backups`.
+
+Quando AnsibleForms non conosce nessun runner con quel nome, il nuovo RTE chiede invece di unirsi e aspetta un'approvazione. Rifiuta quella richiesta in
+**Connessioni > Runner**, poi esegui di nuovo l'aggiornamento con il nome che il runner ha lì.
+
+---
+
+## Versioni
+
+La versione dell'installer segue quella dell'app: ogni release di AnsibleForms arriva con un installer della stessa versione, pubblicato insieme ad essa, e
+quell'installer installa quella versione per impostazione predefinita. `--version` ne installa un'altra. Ogni release nella
+[pagina Releases dell'installer](https://github.com/ansibleforms/installer/releases) ha i binari per Linux su amd64 e arm64, con i loro
+checksum.
diff --git a/i18n/it/_get_started/installation/kubernetes.md b/i18n/it/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..acf4954
--- /dev/null
+++ b/i18n/it/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Installazione
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Installa AnsibleForms e il suo database MySQL con il chart Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Il chart Helm distribuisce AnsibleForms con MySQL e l'RTE che esegue i playbook (vedi il [riferimento dei valori](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+Anche l'[installer](installer.html) installa il chart, a partire da poche domande, e aggiorna una release che non ha installato lui. Lo stesso
+chart installa anche un Runner da solo, per un AnsibleForms che gira altrove (vedi [Un Runner su Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Prerequisiti
+
+Prima di iniziare ti servono:
+
+* **Cluster Kubernetes** : con `kubectl` configurato per raggiungerlo
+* **Helm 3** : per installare e aggiornare il chart
+* **Storage** : una StorageClass per il provisioning dinamico, o dei PersistentVolume creati in anticipo
+* **Ingress controller** : solo se vuoi esporre AnsibleForms tramite un ingress
+
+---
+
+## 1. Ottieni i valori del chart
+
+Scarica i valori predefiniti del chart in un tuo file, dal repository del chart o dal registry OCI:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Repository del chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">Registry OCI</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Nessun repository da aggiungere: il chart viene scaricato dal GitHub Container Registry.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Configura lo storage
+
+Sia AnsibleForms sia MySQL salvano i loro dati su un volume persistente. Imposta la StorageClass e la dimensione di ciascuno:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Un `className` vuoto usa la StorageClass predefinita del cluster. La modalità di accesso predefinita è `ReadWriteMany`, che molte classi
+di storage non offrono; `ReadWriteOnce` va bene con una sola replica. Per i PersistentVolume creati in anticipo, vedi il
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart.
+
+---
+
+## 3. Imposta le credenziali
+
+AnsibleForms ha bisogno di un account admin, di una password del database e di un `ENCRYPTION_SECRET`, la chiave che cifra le credenziali
+salvate in AnsibleForms. Per cambiare quella chiave in seguito, imposta [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+su quella vecchia per un avvio: ogni segreto salvato viene allora cifrato di nuovo con la nuova chiave. Forniscile in uno di tre modi:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">Nel file dei valori</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Generate dal chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Secret esistente</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Impostale in `my_values.yaml`. Il chart le salva in un Secret chiamato `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Lascia che il chart generi quello che non fornisci, alla prima installazione. In seguito mantiene gli stessi valori a ogni
+aggiornamento:
+
+```bash
+--set secrets.generate=true
+```
+
+Questo non funziona con Argo CD o Flux, che fanno il render del chart senza accesso al cluster. Il Secret generato
+sopravvive a `helm uninstall`; fanne un backup, perché `ENCRYPTION_SECRET` non si può recuperare.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Fai puntare il chart a un Secret che gestisci tu, per esempio con External Secrets, Sealed Secrets o SOPS. Il chart
+allora non ne crea nessuno:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+Il Secret deve contenere `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` e `ADMIN_PASSWORD`.
+
+</div>
+</div>
+
+---
+
+## 4. Scegli l'immagine RTE
+
+AnsibleForms 7 non esegue da sé nessun playbook: lo fa l'RTE (ambiente di runtime). Il chart lo esegue come secondo container nel
+pod del server, sullo stesso volume, e lo registra come runner predefinito `rte`, così i moduli playbook funzionano senza alcuna configurazione. Dalla 7.3.0
+l'app lo contatta su `127.0.0.1` e tiene aperto un WebSocket (`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)): l'RTE non riceve
+impostazioni del database né chiave di cifratura. Il config seed del chart dichiara una credenziale RTE con il token e quell'indirizzo, e
+il runner, in modalità inbound, che accede con essa.
+
+L'immagine predefinita, `ghcr.io/ansibleforms/ansibleforms-rte-full`, contiene ansible con le sue collection e le librerie Python che aveva l'immagine 6.5.
+Per averne di più, o di meno, crea la tua su uno dei tre livelli RTE (`ansibleforms-rte-base`, `-rte-core` o `-rte-full`, vedi
+[Le immagini RTE](../rte/images.html)) e fai puntare il chart a essa:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+Il token tra l'app e l'RTE, e la chiave che firma le sessioni, vengono generati alla prima installazione nel
+Secret `<release>-keys` e mantenuti a ogni aggiornamento. Con un tuo config seed, aggiungici quella credenziale e quel runner: le note che Helm stampa dopo l'installazione mostrano come
+(vedi il [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart).
+
+---
+
+## 5. Installa il chart
+
+Installa il chart nel suo namespace con i tuoi valori:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Con il registry OCI, usa `oci://ghcr.io/ansibleforms/charts/ansibleforms` come chart. In tutto ciò che gira senza interazione,
+fissa la versione del chart con `--version`, così una nuova release non viene mai installata da sola.
+
+---
+
+## 6. Controlla l'installazione
+
+Il chart include un test che controlla sia il server web sia la connessione al database:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+Il test termina con `OK` quando AnsibleForms risponde e il suo database accetta connessioni.
+
+---
+
+## 7. Apri AnsibleForms
+
+Come raggiungi AnsibleForms dipende da come è esposto il server:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Con il servizio `ClusterIP` predefinito e senza ingress, nulla è esposto fuori dal cluster. Inoltra una porta locale per
+dare un'occhiata:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Poi apri `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Imposta `services.server.type: LoadBalancer` (eventualmente con un indirizzo fisso in `services.server.loadbalancer.ip`),
+poi aspetta che il servizio ottenga il suo indirizzo:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Abilita l'ingress e imposta il nome host che porta al tuo ingress controller:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+Il [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart tratta il TLS dietro un ingress, compresa l'impostazione del backend necessaria per l'HTTPS sul
+server.
+
+</div>
+</div>
+
+---
+
+## 8. Accedi
+
+Accedi come utente admin, `admin` per impostazione predefinita. Per leggere la password dal Secret:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Con `secrets.existingSecret`, leggila invece dal tuo Secret.
+
+---
+
+## Un Runner su Kubernetes
+
+Con `runner.enabled`, il chart installa solo un RTE: un Runner per un AnsibleForms installato altrove, in un altro namespace, in un altro
+cluster o su una VM. Contatta l'app e tiene aperto un WebSocket (`RTE_MODE=outbound`, vedi [Modalità](../rte/modes.html)), quindi non ha bisogno
+di database, chiave di cifratura né porta in ingresso. Non crea app, MySQL, Service né Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Valore | Cosa fa |
+|---|---|
+| `runner.enabled` | Installa solo il Runner: niente app, niente MySQL, niente Service, niente Ingress |
+| `runner.appUrl` | L'indirizzo dell'app come lo aprono le persone, con il suo `BASE_URL` se presente. Obbligatorio |
+| `runner.name` | Il nome di runner con cui si unisce (`RTE_NAME`). Vuoto: il nome della release |
+| `runner.joinToken` | Un [token di adesione](../runners/registration.html#join-tokens) creato nell'app, letto al primo avvio per approvare subito il Runner |
+| `runner.appTlsVerify` | `false` accetta il certificato autofirmato dell'app (`APP_TLS_VERIFY=0`), solo all'interno di una rete fidata |
+
+Senza un token di adesione, il Runner chiede di unirsi e aspetta che un admin lo approvi in **Connessioni > Runner**. Una volta approvato,
+accede con il suo `RTE_TOKEN`, conservato nel Secret `<release>-keys`: conserva quel Secret insieme alla release. Anche
+l'[installer](installer.html#kubernetes) installa questa modalità runner, quando scegli il ruolo Runner e Kubernetes.
+
+---
+
+## Prossimi passi
+
+Il [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart tratta il resto della configurazione:
+
+* **Il tuo database** : imposta `mysql.enabled: false` e fai puntare AnsibleForms a un server MySQL esistente
+* **Moduli da ConfigMap** : fornisci `config.yaml` e i file dei moduli tramite ConfigMap
+* **HTTPS dietro un ingress**, risorse, posizionamento sui nodi e registry privati
+* **L'RTE** : il suo token, una tua immagine RTE, o nessun RTE
+
+Per passare a una release più recente, vedi [Aggiornamento su Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/it/_get_started/installation/native.md b/i18n/it/_get_started/installation/native.md
new file mode 100644
index 0000000..d7f0ba6
--- /dev/null
+++ b/i18n/it/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Nativa
+parent: Installazione
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Installazione nativa
+{: .no_toc }
+
+AnsibleForms direttamente sul server, senza container, come servizi systemd preparati dall'installer
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori di server in cui i container non sono consentiti: l'[installer](installer.html) installa tutto ciò che serve ad AnsibleForms
+sul server stesso, poi lo aggiorna e lo rimuove. Installa AnsibleForms 7.3.0 o successivo.
+
+---
+
+## Cosa richiede
+
+Scegli **Direttamente su questo server, senza container** al passo **Motore** dell'installer, o passa `--mode native`. Richiede:
+
+* **Root** : esegui l'installer con `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : i servizi girano come unit systemd
+* **Un Linux supportato** : Ubuntu, Debian, RHEL e le sue ricompilazioni come Rocky Linux e AlmaLinux, SUSE Linux Enterprise o openSUSE
+* **amd64 o arm64**
+* **Accesso a Internet** : ai repository della distribuzione, a GitHub, a nodejs.org e agli indici dei pacchetti Python e Ansible (vedi
+  [Air-gapped](#air-gapped) per ciò che sostituisce un bundle di release)
+
+Su un server che non soddisfa questi requisiti, il motore compare come *Direttamente su questo server (richiede root: eseguilo con sudo)* o
+*Direttamente su questo server (non supportato su questo Linux)*. Entrambi i ruoli si installano in questo modo: un controller e un [Runner](installer.html#a-runner).
+
+---
+
+## Cosa installa
+
+L'installer installa questi pacchetti della distribuzione, per entrambi i ruoli:
+
+| Pacchetto | Perché |
+|---|---|
+| `git` | I repository |
+| Il client ssh | Le connessioni dei playbook |
+| Il client MariaDB | I backup dell'app: `app.env` imposta [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) e [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) sul client trovato, `mariadb-dump` e `mariadb` o i più vecchi `mysqldump` e `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | I download |
+| `libatomic` | Node.js si collega a essa, e i server minimali non la hanno |
+| `sshpass` | I playbook che accedono con una password ssh. Su RHEL e le sue ricompilazioni arriva da EPEL, che l'installer prova ad abilitare con `epel-release`; quando non si può installare, l'installazione prosegue e lo segnala |
+| Il server MariaDB | Solo un controller: il suo database |
+
+Poi, nella cartella di installazione, con ogni download verificato con il suo checksum pubblicato:
+
+* **AnsibleForms** : il bundle di release `ansibleforms-<version>-linux-<arch>.tar.gz` dalla release GitHub dell'app, l'app compilata per
+  Node.js. Una versione senza bundle dice *Senza container serve AnsibleForms 7.3.0 o successivo.*
+* **Node.js** : l'ultima release della major indicata dal bundle, da nodejs.org
+* **Python e Ansible** : uv, poi con esso il Python delle immagini RTE e un ambiente virtuale con Ansible e le librerie
+  dell'immagine RTE full, poi le sue collection Ansible (vedi [Le immagini RTE](../rte/images.html)). Richiede qualche minuto
+* **I file iniziali** : i moduli, i playbook e le impostazioni della cartella `data` del [progetto docker-compose](https://github.com/ansibleforms/docker),
+  come li riceve una nuova installazione Docker Compose. Un Runner mantiene solo la sua configurazione Ansible e le impostazioni ssh e git
+
+Per un controller crea poi lo schema `AnsibleForms` in MariaDB, e un utente del database con il nome dell'istanza, con tutti i diritti su quello
+schema e nessuno altrove, che accede solo da questo server.
+
+---
+
+## La cartella
+
+Tutto si trova nella cartella di installazione, per impostazione predefinita `/opt/ansibleforms` (o `/opt/ansibleforms-runner` per un Runner):
+
+| Percorso | Cosa contiene |
+|---|---|
+| `releases/<version>/` | Una release: il bundle, il suo link a Node.js, il suo ambiente virtuale Python e le sue collection |
+| `current` | Il link alla release in esecuzione; un aggiornamento lo sposta, e così un rollback |
+| `runtime/` | Node.js, uv e Python, condivisi dalle release |
+| `data/` | Ciò che i container montano come `/app/dist/persistent`: moduli, playbook, `config.yaml`, il config seed, certificati e log |
+| `home/` | La home dell'utente di sistema: `.ssh` e `.gitconfig`, collegati a `data/ssh` e `data/git` |
+| `app.env`, `rte.env` | Le impostazioni e i segreti dei servizi, leggibili solo da root e dall'utente di sistema. Quello dell'RTE non contiene impostazioni del database |
+| `installer-backups/` | I backup del database fatti dall'installer, prima di un aggiornamento o con `backup` |
+
+Le release e i runtime appartengono a root, quindi i servizi non possono modificare il proprio codice; `data/` e `home/` appartengono all'utente di sistema.
+I file del database sono conservati da MariaDB, fuori dalla cartella.
+
+---
+
+## I servizi
+
+Un controller esegue due servizi systemd, un Runner uno. Ognuno gira come un utente di sistema con il nome dell'istanza (`ansibleforms` per impostazione predefinita),
+da `current/server`, con il suo file di impostazioni:
+
+| Servizio | Cosa esegue | Impostazioni |
+|---|---|---|
+| `<name>` | L'app: l'interfaccia web, l'API e il worker. Solo un controller | `app.env` |
+| `<name>-rte` | L'RTE che esegue i playbook | `rte.env` |
+
+L'RTE di un controller è `inbound` su una porta tutta sua su `127.0.0.1` (`8001`, o la prima libera successiva, con
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), esegue i playbook dalle cartelle dell'app (`RTE_FILES=local`),
+ed è dichiarato dal config seed `data/seed.yaml` come runner predefinito.
+
+L'RTE di un Runner riceve la modalità, `APP_URL`, `RTE_NAME` e, con `--join`, il token di adesione, e riceve i playbook con ogni job (vedi
+[Modalità](../rte/modes.html)). Uno in uscita non riceve chiamate dall'app, quindi ascolta solo su `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Uno in entrata serve HTTPS con un certificato autofirmato del proprio indirizzo in `data/certificates`, che AnsibleForms fissa.
+Senza un token di adesione chiede di unirsi, e un admin lo approva in **Connessioni > Runner**.
+
+Si avviano al boot e si riavviano dopo un errore. Gestiscili e leggi i loro log con gli strumenti di systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+L'app può ascoltare su una porta sotto la 1024, come `443`, senza root. L'RTE mantiene il diritto di usare `sudo`, che serve ai playbook con
+`become` su questo server, così un playbook può gestire il server su cui gira l'RTE.
+
+---
+
+## Aggiornamento e rollback
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` aggiorna un'installazione nativa come fa con le altre (vedi [Aggiornamento](installer.html#upgrade)), in
+questo ordine:
+
+1. Mette in posizione la nuova release accanto a quella in esecuzione: il suo bundle, Node.js, Python, Ansible e le collection. I servizi
+   in esecuzione non vengono ancora toccati
+2. Aggiunge i nuovi file iniziali portati dalla release, mantenendo ogni file esistente
+3. Fa il backup del database (un controller) in `installer-backups/`, con una copia di `app.env` e `rte.env`
+4. Ferma i servizi, fa puntare `current` alla nuova release, e li riavvia
+5. Aspetta che l'app risponda con la nuova versione (un Runner: che il suo RTE torni ad ascoltare)
+
+Quando la nuova versione non risponde, l'installer propone di tornare indietro: `current` punta di nuovo alla release precedente, il
+database viene ripristinato dal backup, e i servizi si avviano. Vengono conservate solo la release in esecuzione e quella precedente.
+
+I servizi nativi con la struttura dell'installer senza un `installer.json` accanto, per esempio dopo che è stato eliminato, vengono trovati da `install`
+e `upgrade`, che propongono di prenderli in carico (vedi [Un'installazione esistente](installer.html#an-existing-installation)).
+
+---
+
+## Disinstallazione
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` ferma e rimuove i servizi. Mantiene la cartella e il database, a meno che tu non scelga di eliminare
+i dati (o passi `--purge`) e digiti il nome dell'istanza per confermare. In quel caso elimina anche il database e il suo utente (un controller),
+cancella la cartella e rimuove l'utente di sistema.
+
+I pacchetti restano installati, MariaDB compreso: altri software potrebbero usarli.
+
+---
+
+## Air-gapped
+
+`--bundle` installa da un bundle di release che hai copiato sul server, invece di scaricarlo da GitHub. Prendi il file per la sua
+architettura, `ansibleforms-<version>-linux-amd64.tar.gz` o `-arm64`, dalle [Releases](https://github.com/ansibleforms/ansibleforms/releases) dell'app:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` fa lo stesso per i file iniziali, da una copia locale del repository [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python con i suoi pacchetti e le collection Ansible vengono comunque scaricati durante l'installazione.
diff --git a/i18n/it/_get_started/upgrade-7.md b/i18n/it/_get_started/upgrade-7.md
new file mode 100644
index 0000000..b6912c4
--- /dev/null
+++ b/i18n/it/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Aggiornare alla v7
+parent: Aggiornamento
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Aggiornare alla v7
+{: .no_toc }
+
+Cosa cambiare quando sei ancora sulla 6.5, e cosa cambia quando passi alla versione 7
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+La versione 7 elimina tutto ciò che la 6.x aveva deprecato; correggilo prima sulla 6.5, dove funzionano sia il vecchio sia il nuovo, poi aggiorna.
+
+---
+
+## Prima di aggiornare (sulla 6.5)
+
+### I moduli stanno nei loro file
+
+I moduli stanno solo nella cartella dei moduli (`FORMS_FOLDER_PATH`) o in un repository di moduli; `config.yaml` conserva categorie, ruoli e costanti.
+
+- **Un file `forms.yaml`:** rinominalo in `config.yaml`. Sulla 6.5 la pagina delle impostazioni ha un pulsante
+  **Convert forms.yaml to config.yaml** per questo.
+- **Una sezione `forms:` nella configurazione di base:** la versione 7 la rifiuta. Sposta ogni modulo nel suo file, per esempio
+  trascinandolo su un file nel designer della 6.5.
+- **Variabili d'ambiente:**
+
+  | Rimossa | Usa invece |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` e `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### Il campo `table`
+
+La versione 7 rifiuta i campi `table`, e con loro se ne vanno le loro proprietà (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`): usa un campo `list` con un `subform`, e trasforma il `from` di ogni colonna in un'espressione
+su `__parent__` (vedi le [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Proprietà rinominate
+
+Ogni proprietà rimossa ha un sostituto diretto:
+
+| Rimossa | Usa invece |
+|---|---|
+| `disableRelaunch: true` (modulo) | `allowRelaunch: false` |
+| `noOutput: true` (campo) | `output: false` |
+| `enableLogin` (opzione del ruolo) | `allowLogin` |
+
+### Datasource e schemi di dati
+
+Le importazioni dei datasource e le loro pagine di amministrazione sono state rimosse, così come la
+collection Galaxy di AnsibleForms, i cui moduli servivano solo a esse.
+
+- Le importazioni pianificate si fermano e le tabelle dei datasource vengono eliminate: annota prima ciò che ti serve.
+- Gli schemi di dati riempiti da un'importazione sono database a sé e restano. Un modulo che
+  li interroga tramite una credenziale continua a funzionare.
+- Per mantenere aggiornati quei dati, esegui l'importazione come un tuo playbook, per esempio da una
+  pianificazione.
+
+### API v1
+
+`/api/v1/*` è stata rimossa; usa `/api/v2/*` (documentazione interattiva su `/api/v2/docs`). Le chiamate
+che gli script usano di solito sono:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+La v2 risponde con codici di stato HTTP (`400`, `403`, `404`, `422`) e un corpo JSON semplice, non con l'involucro
+`{ status, message, data }` della v1.
+
+**Anche i callback del single sign-on.** Un URL di reindirizzamento con `/api/v1/` non risponde più: l'accesso torna
+alla pagina di login senza accedere. Cambialo in `/api/v2/` in due punti, sul provider SSO in
+AnsibleForms e nell'identity provider (gli URI di reindirizzamento della registrazione dell'app Entra ID, gli URI di reindirizzamento validi
+del client OIDC):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback`, o `/api/v2/auth/entraid/callback` dalla 7.3.0
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Cosa cambia nella 7
+
+La versione 7 cambia il modo in cui vengono eseguiti i playbook e rende più restrittive diverse impostazioni predefinite. Controlla ogni punto qui sotto quando passi dalla 6.5.
+
+### I playbook girano su un RTE
+
+La versione 7 non esegue più `ansible-playbook` nel container di AnsibleForms. I playbook girano su un ambiente di runtime (RTE),
+un container a sé, e l'immagine dell'app non contiene più né ansible né python. Avvia un RTE accanto all'app, dall'immagine
+`ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Dalla 7.3.0 l'app contatta l'RTE e tiene aperto un WebSocket (vedi
+[Modalità](rte/modes.html)): l'RTE non riceve impostazioni del database né `ENCRYPTION_SECRET`. Le sue impostazioni:
+
+| Impostazione | Valore |
+|---|---|
+| `AF_ROLE` | `rte`. Le immagini RTE la impostano già. |
+| `RTE_MODE` | `inbound`: l'app contatta l'RTE. Un Runner in un'altra rete usa `outbound` (vedi [Modalità](rte/modes.html)). |
+| `RTE_TOKEN` | Un token di almeno 16 caratteri. L'app accede con esso al socket dell'RTE, e l'RTE si rifiuta di partire senza. |
+| `RTE_FILES` | `local` quando l'RTE monta la stessa cartella persistente dell'app, come quando le sta accanto. |
+
+Poi sposta i mount di ansible dal container dell'app all'RTE:
+
+- `ansible.cfg` in `/etc/ansible/ansible.cfg`, i tuoi ruoli in `/etc/ansible/roles` e le tue collection in
+  `/etc/ansible/collections`.
+- Monta anche sull'RTE la stessa cartella persistente dell'app, così trova i playbook e i repository.
+
+Poi dichiara l'RTE come runner, nel [config seed](seed/) come fa il progetto Docker Compose, o in **Connessioni → Runner**:
+una credenziale RTE con l'indirizzo dell'RTE (per esempio `http://rte:8000`) e lo stesso token, e un runner di tipo RTE, in modalità inbound,
+che la nomina:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Il seed legge `RTE_TOKEN` dall'ambiente dell'app. Vedi [Runner](runners.html) e [Ambienti di runtime](rte/).
+
+{: .warning }
+> **Lo stesso contratto per l'app e l'RTE** L'app risolve le credenziali di un job e le passa all'RTE sigillate per
+> quell'RTE (contratto RTE 2, novità della 7.0.0). Un RTE con un altro contratto rifiuta i job dell'app: esegui l'immagine RTE della stessa
+> release dell'app, e aggiornali insieme. Le release 7 successive continuano a funzionare con un RTE 7 più vecchio finché il contratto
+> resta lo stesso (vedi [Scalabilità](../rte/images.html#build-your-own-rte)).
+
+
+### Cosa contiene l'immagine RTE
+
+L'RTE è disponibile in tre livelli, ognuno costruito sul precedente. Scegli quello adatto ai tuoi playbook:
+
+| Immagine | Contenuto |
+|---|---|
+| `ansibleforms-rte-full` | Quella predefinita. Ansible 14 con ansible-core 2.21, e le collection e le librerie python che aveva l'immagine 6.5. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core e alcune librerie comuni, senza collection. Aggiungi le tue in un'immagine costruita su di essa. |
+| `ansibleforms-rte-base` | Solo il server, senza python né ansible, per costruire un RTE con le tue versioni. |
+
+Passare dalla 6.5 (ansible 12 con ansible-core 2.19) cambia anche queste cose per i tuoi playbook:
+
+- **ansible-core 2.21:** leggi le [guide al porting](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  per la 2.20 e la 2.21.
+- **Python 3.14:** i livelli RTE girano su python 3.14.
+- **Niente più `boto`:** la vecchia libreria `boto` 2 non c'è più. La collection `amazon.aws` usa `boto3`, che è inclusa.
+
+Due variabili d'ambiente ora appartengono all'RTE e non sono più lette dall'app, quindi impostale nel container dell'RTE:
+
+| Variabile | Cambiamento |
+|---|---|
+| `ANSIBLE_PATH` | La cartella dei playbook, sull'RTE. |
+| `PROCESS_MAX_BUFFER` | Ora 50 MB per impostazione predefinita. Oltre questo limite, l'output del job non viene più salvato (il job lo segnala), ma il playbook prosegue invece di essere fermato. |
+
+
+### I container girano come uid 1000
+
+Le immagini dell'app e dell'RTE girano come utente `node` (uid 1000) invece che come root, e la loro cartella home è `/home/node`:
+
+- **Assegna i volumi all'uid 1000, una volta.** Per i volumi persistente e ssh, esegui
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v`; per una cartella dell'host, `sudo chown -R 1000:1000 <folder>`.
+  Su Kubernetes, imposta `fsGroup: 1000`.
+- **Monta la cartella ssh su `/home/node/.ssh`**, non su `/root/.ssh`. Se hai impostato
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) su `/root`, rimuovilo o impostalo su `/home/node`.
+- **La tua immagine RTE** costruita su un livello RTE passa a `USER root` per le sue installazioni e torna a `USER node` alla fine.
+
+
+### La validazione all'avvio è attiva
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) ora vale per impostazione predefinita `enforce` (6.5: `off`). Ogni
+avvio, dal browser o da `POST /api/v2/job`, viene controllato rispetto alle regole del modulo, e il job usa le extravars e
+le credenziali che il server costruisce dai valori controllati.
+
+- **I client REST devono inviare `rawFormData`**, i valori grezzi dei campi come li invia il browser. Un avvio con solo
+  `extravars` viene rifiutato, perché i suoi valori non si possono controllare.
+- **Per vedere prima cosa verrebbe rifiutato**, imposta `LAUNCH_VALIDATION=log` e leggi gli avvisi nel log. `off` ripristina il
+  comportamento della 6.5.
+
+Vedi [Validazione all'avvio](launch-validation/) per i dettagli.
+
+
+### I playbook non vedono più le impostazioni dell'app
+
+Un playbook non eredita più le variabili d'ambiente che AnsibleForms legge per sé: `ENCRYPTION_SECRET`, le impostazioni `DB_*`,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, le impostazioni `VAULT_*`, ogni altra variabile documentata e ogni variabile `MYSQL_*`.
+Il resto dell'ambiente dell'RTE, come `PATH`, i proxy, le impostazioni `ANSIBLE_*` e le credenziali cloud, viene passato come prima.
+
+Un playbook che leggeva una di queste con `lookup('env', ...)` deve ottenere il valore in un altro modo: passalo come extravar o come
+credenziale, o impostalo sull'RTE con un altro nome.
+
+### Solo il ruolo admin gestisce runner e admin
+
+Un utente con accesso alle impostazioni non ha più il pieno controllo su chi è admin e su dove vanno le credenziali:
+
+- **Runner:** solo il ruolo admin aggiunge, modifica o elimina un runner, perché un runner riceve le credenziali dei job
+  che esegue. Gli utenti con accesso alle impostazioni possono ancora vedere e provare i runner.
+- **Account e gruppi admin:** solo il ruolo admin concede i diritti di admin. Senza di esso, un utente non può mettere un account in un gruppo nominato
+  dal ruolo admin, né modificare, reimpostare o eliminare un account admin o un gruppo del genere.
+- **Ruoli:** un designer senza il ruolo admin non può modificare i ruoli. Un salvataggio o un ripristino i cui ruoli sono diversi viene rifiutato.
+
+Dai il ruolo admin a chi gestisce runner, admin e ruoli.
+
+### La password predefinita va cambiata
+
+Un utente che accede con la password predefinita pubblica `AnsibleForms!123` deve prima cambiarla. Fino ad allora, ogni altra chiamata
+API risponde `403` con il codice `password_change_required`, e il browser mostra la pagina di cambio password.
+
+Accedi una volta e scegli una nuova password, o imposta [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) prima del
+primo avvio. Gli script che accedono con la password predefinita devono usarne un'altra.
+
+### I token terminano al logout e al cambio password
+
+Un logout ora termina i token di quella sessione, e un cambio password termina tutte le sessioni di quell'utente, quindi accedi di nuovo dopo
+aver cambiato una password.
+
+Un token API richiesto con `?expiryDays=` dura al massimo [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) giorni
+(90 per impostazione predefinita). Gli script che usano token API di lunga durata devono richiederne uno nuovo prima che scada.
+
+### Entra ID ha bisogno del tuo tenant
+
+L'accesso con Entra ID (Azure AD) ora usa OpenID Connect solo verso il tuo tenant, e un utente di un altro tenant non può
+accedere. Un provider senza ID tenant, o con `common`, `organizations` o `consumers`, viene rifiutato.
+
+- **Imposta l'ID tenant** sul provider SSO: il Directory (tenant) ID, un GUID, o il dominio del tenant.
+- **Concedi i permessi Graph:** il login chiede `openid profile email User.Read GroupMember.Read.All`. Dai alla registrazione
+  dell'app i permessi delegati di Microsoft Graph `User.Read` e `GroupMember.Read.All`, con consenso dell'amministratore.
+- **Preferisci gli ID dei gruppi nei ruoli:** indica un gruppo come `azuread/<object id>` (`entraid/<object id>` dalla 7.3.0) invece che con il suo nome visualizzato.
+
+Vedi [Entra ID](authentication/entra-id.html) per la configurazione.
+
+### Le password hanno una lunghezza minima
+
+Una password locale impostata tramite l'applicazione ha bisogno di almeno
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) caratteri (8 per impostazione predefinita), e non può essere il nome utente né la
+password predefinita. `PASSWORD_MIN_LENGTH=0` disattiva il controllo della lunghezza. Le password esistenti continuano a funzionare.
+
+### Esegui i container con una restart policy
+
+Un'eccezione non gestita ora termina il processo, registrata a livello `crit`, invece di lasciarlo in esecuzione in uno stato sconosciuto. Esegui
+i container con una restart policy, come `--restart unless-stopped` con Docker (il progetto docker-compose la imposta).
+Kubernetes riavvia i pod da sé.
+
+### Connessioni AWX e il link home
+
+Altre due cose spariscono nella 7, senza nulla da fare sulla 6.5:
+
+- **Connessioni AWX e AAP:** la tabella `awx`, `/api/v2/awx` e la pagina A.A.P. non ci sono più. L'aggiornamento sposta ogni connessione AWX o
+  AAP in **Connessioni → Runner**, come runner di tipo `awx`, e i moduli con `awx:` continuano a funzionare.
+- **`NAV_HOME_LABEL` e `NAV_HOME_ICON`:** non vengono più letti. Il primo link dell'intestazione è sempre Moduli.
+
+### Deprecato nella 7, rimosso nella 8
+
+Questi funzionano ancora nella 7, ma ognuno registra un avviso quando viene usato. Passa al sostituto prima della versione 8:
+
+| Deprecato | Usa invece |
+|---|---|
+| Variabili d'ambiente `VAULT_*` | Un archivio di segreti chiamato `vault` (**Connessioni → Archivi di segreti**). Il primo avvio della 7 importa le variabili una volta come quell'archivio, poi le ignora. |
+| Variabili d'ambiente `LOG_SYSLOG_*` | Un server syslog (**Connessioni → Syslog**). Quando `LOG_SYSLOG_HOST` è impostata, il primo avvio della 7 le importa una volta come il server `syslog`, che riceve il log del server come prima, poi le ignora. Per inviare anche le voci di audit, impostalo per ricevere entrambi. |
+| `vault_path` su una credenziale (API, config seed) | `secret_store` e `secret_ref`. Vedi [Archivi di segreti](secret-stores/). |
+| Il ruolo `public` in `config.yaml` | Il ruolo `default`. Il file viene rinominato quando la configurazione si carica; rinomina a mano un template ytt. `public` nei `roles:` di un modulo continua a corrispondere. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` su un modulo o un passo | `approval`. `hasApproval` non ha effetto. |
+| `awx: <name>` su un modulo | `runner: <name>`. Una connessione AWX è un runner di tipo `awx`. |
+| `type: multistep` su un modulo, con i suoi `steps` | `type: workflow`, con nodi che nominano un `runner`. Vedi [Moduli workflow](forms/workflow.html). |
+| La sezione `awx:` del config seed | Elementi `runners:` con `type: awx` |
+| `LOCK_PATH` | Niente: non viene più letto, il blocco del designer è conservato nel database. |
+| Un RTE in modalità database, dalla 7.3.0: `RTE_MODE=database` o nessun `RTE_MODE`, con i `DB_*` del database e `ENCRYPTION_SECRET` sull'RTE | `RTE_MODE=outbound` o `RTE_MODE=inbound`, senza `DB_*`. L'RTE si unisce una volta con un token di adesione (`RTE_JOIN_TOKEN`), oppure il suo runner viene impostato su quella modalità in **Connessioni → Runner** o nel config seed (`rte_mode`). Vedi [Modalità](rte/modes.html). |
+| `RTE_REGISTER`, dalla 7.3.0 (solo modalità database) | Un token di adesione (`RTE_JOIN_TOKEN`): l'RTE si aggiunge come runner che accede con una credenziale RTE. |
+| Una credenziale `api` o `userpass` su un runner del config seed, dalla 7.3.0 | Una credenziale del tipo del runner (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` o `jenkins`), con il suo server in `url`. |
+| Un runner del config seed con un proprio `token`, o `username` e `password`, dalla 7.3.0 | Una credenziale del tipo del runner nella sezione `credentials`, con il suo server in `url`, che il runner nomina con `credential:`. Nel frattempo il seed ne crea una con il nome del runner. |
+
+`ENABLE_SSO` e `SSO_AUTO_LOGIN` non vengono più letti dalla 7.3.0. Il primo avvio della 7.3 li trasferisce una volta: `ENABLE_SSO=0` disattiva
+ogni provider SSO, e `SSO_AUTO_LOGIN=1` spunta **Salta la pagina di accesso** sull'unico provider abilitato. Poi vengono ignorati: ogni avvio
+registra un avviso finché sono impostati, e ogni provider ha **Abilitato** e **Salta la pagina di accesso** in **Accesso → SSO**.
+
+---
+
+## Tag delle immagini
+
+`latest` passa alla 7 con la 7.0.0. Per restare sulla 6, usa il tag `6` (o `6.5`) invece di `latest`.
+Tutti i tag sono elencati in [Tag delle immagini](installation/#image-tags).
+
+---
+
+## Tornare indietro
+
+Fai un backup prima di aggiornare (**Impostazioni → Backup**). La 6.5 gira su un database aggiornato alla 7, ma solo
+il backup ripristina le definizioni dei datasource eliminate.
diff --git a/i18n/it/_get_started/upgrading/docker-compose.md b/i18n/it/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..4acee02
--- /dev/null
+++ b/i18n/it/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Aggiornamento
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Aggiorna un'installazione fatta con il progetto docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Il progetto docker-compose esegue tre container: MySQL (`mysqldb`), AnsibleForms (`app`) e l'RTE che esegue i
+playbook (`rte`). AnsibleForms e l'RTE usano il tag dell'immagine `7`, che punta sempre all'ultima release 7.x. Un
+aggiornamento scarica di nuovo le immagini e ricrea i container la cui immagine è cambiata. Tutto ciò che deve persistere è salvato
+nella cartella `data` e viene conservato.
+
+---
+
+## Prima di aggiornare
+
+Prepara l'aggiornamento in modo da poter tornare indietro se qualcosa va storto:
+
+* **Fai un backup** in **Impostazioni → Backup**. La nuova release aggiorna lo schema del database al suo primo avvio.
+* **Leggi il [changelog](../changelog)** delle release tra la tua versione e quella nuova.
+* **Passi a una nuova major?** Segui prima [Aggiornare alla v7](../upgrade-7.html).
+* **Arrivi dalla 6.5?** Il progetto 6.x, sul suo branch `v6`, non ha il container `rte`. Aggiorna la tua copia del progetto al
+  suo branch `main`, mantenendo le tue impostazioni del `.env` e la tua cartella `data`, così che `docker-compose.yml` abbia il servizio
+  `rte`. Quel file compose imposta `CONFIG_SEED_PATH`, e una cartella `data` della 6.x non ha `seed.yaml`: copia `data/seed.yaml` dal
+  repository, e aggiungi `RTE_TOKEN` (almeno 16 caratteri) al tuo `.env`, come lo ha il `.env` del repository. Senza di essi
+  l'app si rifiuta di partire. Le immagini 7 girano come uid 1000 invece che come root: assegna una volta a quell'utente la cartella `data`, lasciando i file
+  di MySQL a MySQL, con `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  La cartella `data/ssh` ora è montata su `/home/node/.ssh` invece che su `/root/.ssh`.
+* **Arrivi dalla 7.2?** Aggiorna insieme `docker-compose.yml` e `data/seed.yaml`: vedi prima [Dalla 7.2 alla 7.3](#from-72-to-73).
+
+---
+
+## Dalla 7.2 alla 7.3
+
+Fino alla 7.2.0 il servizio `rte` riceveva le impostazioni del database e il suo runner, dichiarato in `data/seed.yaml`, girava in modalità database,
+deprecata nella 7.3.0 e rimossa nella 8.0.0. Dalla 7.3.0 l'app contatta l'RTE su `http://rte:8000` e tiene aperto un WebSocket
+(`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)), e l'RTE non contiene impostazioni del database. Prendi entrambi i file dal branch
+`main` del repository, mantenendo il tuo `.env`:
+
+| File | Cosa cambia |
+|---|---|
+| `docker-compose.yml` | Il servizio `rte` non legge più `.env`: riceve `RTE_MODE=inbound`, `RTE_TOKEN` e `RTE_FILES=local`, e nessun `DB_*` |
+| `data/seed.yaml` | Una credenziale RTE `rte`, con `url: http://rte:8000` e `password: ${RTE_TOKEN}`, e il runner `rte` con `rte_mode: inbound` e `credential: rte` |
+
+Cambiali entrambi. Con solo il nuovo file compose, il seed mantiene il runner `rte` in modalità database: l'app chiama l'RTE come uno della 7.2,
+a cui il nuovo RTE non risponde, e nessun playbook viene eseguito. Un seed che hai modificato tu ha bisogno della stessa credenziale e dello stesso `rte_mode`.
+
+Un runner creato dal seed resta gestito, in sola lettura in **Connessioni → Runner**, anche dopo che hai rimosso `CONFIG_SEED_PATH`: solo un
+seed applicato rilascia un runner che non dichiara più. Quindi mantieni il seed e imposta lì `rte_mode`, invece di rimuovere
+`CONFIG_SEED_PATH` per modificare il runner a mano.
+
+L'[installer](../installation/installer.html#upgrade) lo fa da solo: il suo aggiornamento sostituisce `docker-compose.yml`, e `data/seed.yaml`
+quando è uno fornito dal repository, non modificato. Uno modificato a mano viene mantenuto, e quello nuovo viene salvato accanto.
+
+---
+
+## 1. Scarica le nuove immagini
+
+Scarica le immagini più recenti dei tag in `docker-compose.yml`:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Ricrea i container
+
+Avvia di nuovo il progetto; i container la cui immagine è cambiata vengono ricreati:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Controlla l'aggiornamento
+
+Segui il log di AnsibleForms mentre si avvia. Il primo avvio di una nuova release aggiorna lo schema del database, e l'RTE
+si avvia quando AnsibleForms è healthy:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+In AnsibleForms, **Aiuto → Informazioni** mostra la versione in esecuzione, e **Impostazioni → Stato** mostra lo stato di salute del
+database, dello schema e degli altri sistemi da cui dipende AnsibleForms.
+
+---
+
+## Tornare indietro
+
+Per tornare alla release che eseguivi prima, la versione che **Aiuto → Informazioni** mostrava prima dell'aggiornamento, fissa il suo tag esatto in
+`docker-compose.yml` sia sull'immagine di AnsibleForms sia su quella dell'RTE, al posto di `7`, ed esegui di nuovo il passo 2. Se quella release
+non si avvia sul database aggiornato, ripristina il backup che hai fatto in **Impostazioni → Backup**. Rimetti i tag su
+`7` per ricevere di nuovo gli aggiornamenti.
+
+**VIDEO**: [Come aggiornare AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/it/_get_started/upgrading/docker.md b/i18n/it/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..0d7d3dc
--- /dev/null
+++ b/i18n/it/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Aggiornamento
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Aggiorna un container standalone, senza docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un'installazione standalone si aggiorna sostituendo i suoi container: scarica le nuove immagini, rimuovi i vecchi container e
+avviane di nuovi con gli stessi comandi `run`. Dalla versione 7 sono due: AnsibleForms e l'RTE che esegue i
+playbook, sempre sulla stessa release. I tuoi file sono salvati nella cartella montata `/app/dist/persistent` e i tuoi dati in
+MySQL, quindi entrambi vengono conservati.
+
+---
+
+## Prima di aggiornare
+
+Prepara l'aggiornamento in modo da poter tornare indietro se qualcosa va storto:
+
+* **Fai un backup** in **Impostazioni → Backup**. La nuova release aggiorna lo schema del database al suo primo avvio.
+* **Leggi il [changelog](../changelog)** delle release tra la tua versione e quella nuova.
+* **Passi a una nuova major?** Segui prima [Aggiornare alla v7](../upgrade-7.html).
+* **Arrivi dalla 6.5?** Le immagini 7 girano come uid 1000 invece che come root: assegna una volta a quell'utente le cartelle che monti, per
+  esempio `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Arrivi dalla 7.2?** L'RTE riceve un file tutto suo e l'app lo contatta: vedi prima [Dalla 7.2 alla 7.3](#from-72-to-73).
+
+---
+
+## Dalla 7.2 alla 7.3
+
+Fino alla 7.2.0 l'RTE leggeva il file di ambiente dell'app, con le impostazioni del database, e si aggiungeva come runner da `RTE_URL`. Quella
+è la modalità database, deprecata nella 7.3.0 e rimossa nella 8.0.0. Dalla 7.3.0 l'app contatta l'RTE e tiene aperto un WebSocket
+(`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)), e l'RTE non contiene impostazioni del database. Una volta, prima del passo 2:
+
+1. Crea `/srv/apps/ansibleforms/rte.env` come fa l'[installazione](../installation/docker.html#prepare-the-folders), con
+   `RTE_MODE=inbound`, lo stesso `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` e `HTTPS=0`. Niente `DB_*`, niente `ENCRYPTION_SECRET`, niente `RTE_URL`
+2. Dichiara il runner in quella modalità. O aggiungi il [config seed](../seed/) dell'installazione, `persistent/seed.yaml` con la credenziale RTE
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) e il runner `rte` (`rte_mode: inbound`), e aggiungi
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` al file di ambiente dell'app. Oppure, senza seed, apri il runner in
+   **Connessioni → Runner**, imposta la sua **Modalità** su **In entrata**, e scegli una credenziale RTE che contenga `http://rte:8000` e il token
+
+Con il seed, anche il file di ambiente dell'app contiene `RTE_TOKEN`, lo stesso token, perché il seed lo legge da lì.
+
+---
+
+## 1. Scarica le nuove immagini
+
+Scarica le immagini più recenti di AnsibleForms e dell'RTE del tag che esegui:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Sostituisci i container
+
+Rimuovi i vecchi container e avviane di nuovi con i comandi `run` dell'[installazione](../installation/docker.html). L'app
+legge la connessione al database dal suo file di ambiente, con l'utente del database di AnsibleForms (non root). L'RTE legge il suo
+`rte.env`, senza le impostazioni del database, e l'app lo contatta tramite una rete condivisa da entrambi i container:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Se arrivi dalla 6.5, non c'è ancora nessun container RTE: i comandi `stop` e `rm` trovano solo l'app. Crea la rete condivisa
+una volta con `docker network create ansibleforms` (o `podman network create ansibleforms`). Come fa
+l'[installazione](../installation/docker.html#prepare-the-folders), metti la connessione al database, `ENCRYPTION_SECRET`, un `RTE_TOKEN`
+di almeno 16 caratteri e `CONFIG_SEED_PATH` nel file di ambiente dell'app, e crea `rte.env` e il config seed. Usa le tue
+cartelle dove la tua installazione 6.5 ne montava altre. Il seed aggiunge l'RTE in **Connessioni → Runner** come runner predefinito `rte`;
+vedi [Aggiornare alla v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Controlla l'aggiornamento
+
+Segui il log di AnsibleForms mentre si avvia. Il primo avvio di una nuova release aggiorna lo schema del database:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+L'RTE scrive un log tutto suo, che `docker logs rte` mostra. In AnsibleForms, **Aiuto → Informazioni** mostra la versione in esecuzione, e **Impostazioni → Stato** mostra lo stato di salute del
+database, dello schema e degli altri sistemi da cui dipende AnsibleForms.
+
+---
+
+## Tornare indietro
+
+Per tornare alla release che eseguivi prima, la versione che **Aiuto → Informazioni** mostrava prima dell'aggiornamento, esegui di nuovo il passo 2 con
+il suo tag esatto al posto di `7`, sia sull'immagine di AnsibleForms sia su quella dell'RTE. Se quella release non si avvia sul database
+aggiornato, ripristina il backup che hai fatto in **Impostazioni → Backup**.
diff --git a/i18n/it/_get_started/upgrading/from-source.md b/i18n/it/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..544860e
--- /dev/null
+++ b/i18n/it/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Dai sorgenti
+parent: Aggiornamento
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Dai sorgenti
+{: .no_toc }
+
+Aggiorna un'installazione compilata dai sorgenti
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un'installazione compilata dai sorgenti si aggiorna facendo il checkout della nuova release, ricompilandola e riavviando
+l'applicazione. Le tue impostazioni, moduli, playbook, certificati e log sono salvati in `server/persistent`, che Git e la
+build non modificano.
+
+---
+
+## Prima di aggiornare
+
+Prepara l'aggiornamento in modo da poter tornare indietro se qualcosa va storto:
+
+* **Fai un backup** in **Impostazioni → Backup**. La nuova release aggiorna lo schema del database al suo primo avvio.
+* **Leggi il [changelog](../changelog)** delle release tra la tua versione e quella nuova.
+* **Passi a una nuova major?** Segui prima [Aggiornare alla v7](../upgrade-7.html).
+* **Controlla la versione di Node.js** richiesta dalla nuova release, nel changelog.
+
+---
+
+## 1. Ottieni la nuova release
+
+Scarica i tag delle release e fai il checkout della release che vuoi. I tag delle release riportano il numero di versione, e `git tag` li
+elenca; il branch `main` può contenere modifiche non ancora rilasciate:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Ricompila
+
+Ricompila con gli stessi tre passi dell'installazione. Prima ricompila il client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Poi aggiorna le dipendenze del server:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Infine copia di nuovo il client ricompilato nella cartella `views` del server:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Confronta `.env.example`, nella radice del repository, con il tuo `persistent/.env` per riprendere le eventuali impostazioni che la release aggiunge.
+
+---
+
+## 3. Riavvia
+
+Riavvia l'applicazione e il suo RTE per caricare il nuovo codice. Lo schema del database viene aggiornato al primo avvio:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Se arrivi dalla 7.2, l'RTE girava in modalità database, con le impostazioni del database e `RTE_URL`, deprecata nella 7.3.0 e rimossa nella 8.0.0.
+Avvialo di nuovo in modalità inbound, e dichiara il suo runner con una credenziale RTE nel seed o in **Connessioni → Runner**, come mostra
+l'[installazione](../installation/from-source.html#run): `pm2 delete ansibleforms-rte`, poi il suo comando `pm2 start`.
+
+Se esegui l'applicazione senza PM2, ferma `npm run start` e avvialo di nuovo.
+
+---
+
+## 4. Controlla l'aggiornamento
+
+Segui il log dell'applicazione mentre si avvia:
+
+```bash
+pm2 logs ansibleforms
+```
+
+In AnsibleForms, **Aiuto → Informazioni** mostra la versione in esecuzione, e **Impostazioni → Stato** mostra lo stato di salute del
+database, dello schema e degli altri sistemi da cui dipende AnsibleForms.
+
+---
+
+## Tornare indietro
+
+Per tornare alla release che eseguivi prima, la versione che **Aiuto → Informazioni** mostrava prima dell'aggiornamento, fai il checkout del suo tag con
+`git checkout <version>`, poi ricompila e riavvia come nei passi 2 e 3. Se quella release non si avvia sul database aggiornato, ripristina il backup che hai fatto in
+**Impostazioni → Backup**.
diff --git a/i18n/it/_get_started/upgrading/index.md b/i18n/it/_get_started/upgrading/index.md
new file mode 100644
index 0000000..2870d44
--- /dev/null
+++ b/i18n/it/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Aggiornamento
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Aggiornamento
+{: .no_toc }
+
+Porta AnsibleForms a una release più recente
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori di un'istanza in esecuzione: passa a una release più recente, con il metodo con cui l'hai installata.
+
+---
+
+## In questa sezione
+
+La procedura di aggiornamento dipende da come hai installato AnsibleForms. Ogni metodo è descritto nella propria pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Aggiornare alla v7](../upgrade-7.html) | Cosa cambiare quando sei ancora sulla 6.5, prima di passare alla 7 |
+| [Con l'installer](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, per un'installazione fatta dall'installer: backup, note di rilascio e rollback |
+| [Docker](docker.html) | Scarica la nuova immagine e ricrea il container con le stesse impostazioni |
+| [Docker Compose](docker-compose.html) | Scarica la nuova immagine e riavvia il progetto docker-compose |
+| [Dai sorgenti](from-source.html) | Scarica il nuovo codice, ricompilalo e riavvia l'applicazione |
+| [Kubernetes](kubernetes.html) | Aggiorna il repository del chart ed esegui `helm upgrade` con i tuoi valori |
+
+{: .note }
+> **Prima il backup** Fai un backup prima di aggiornare (**Impostazioni → Backup**). Lo schema del database viene aggiornato al primo
+> avvio della nuova release, quindi il backup è il tuo punto di ritorno se qualcosa va storto. Dalla 7.3.0 anche il worker ne fa
+> uno da sé prima di aggiornare da una release più vecchia, con il nome della release, a meno che
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) non sia `0`.
+
+La release che ricevi dipende dal tag dell'immagine che esegui: `latest` segue la major più recente, mentre un tag come `7`
+resta su quella major. Tutti i tag sono elencati in [Tag delle immagini](../installation/#image-tags).
diff --git a/i18n/it/_get_started/upgrading/kubernetes.md b/i18n/it/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..723f926
--- /dev/null
+++ b/i18n/it/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Aggiornamento
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Aggiorna un'installazione fatta con il chart Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ogni versione del chart distribuisce una release di AnsibleForms. Un aggiornamento installa una versione più recente del chart con i tuoi valori esistenti;
+i dati sui volumi persistenti vengono conservati. Un aggiornamento che non cambia nulla lascia intatti i pod.
+
+---
+
+## Prima di aggiornare
+
+Prepara l'aggiornamento in modo da poter tornare indietro se qualcosa va storto:
+
+* **Fai un backup** in **Impostazioni → Backup**. La nuova release aggiorna lo schema del database al suo primo avvio.
+* **Leggi il [changelog](../changelog)** delle release tra la tua versione e quella nuova.
+* **Passi a una nuova major?** Segui prima [Aggiornare alla v7](../upgrade-7.html).
+* **Leggi il [changelog](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) del chart** per le modifiche ai valori.
+* **Con credenziali generate** (`secrets.generate`), fai il backup del Secret `<release>-secrets`: `ENCRYPTION_SECRET` non si può recuperare.
+* **Arrivi dalla 7.2?** L'RTE nel pod del server cambia modalità: vedi [Dalla 7.2 alla 7.3](#from-72-to-73).
+
+---
+
+## Dalla 7.2 alla 7.3
+
+Il chart 7.3.0 porta l'RTE accanto all'app fuori dalla modalità database, deprecata nella 7.3.0 e rimossa nella 8.0.0. L'app lo contatta su
+`127.0.0.1` e tiene aperto un WebSocket (`RTE_MODE=inbound`, vedi [Modalità](../rte/modes.html)):
+
+* Il container RTE non riceve più `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` né `RTE_URL`, e prende i file del job dal
+  volume condiviso (`RTE_FILES=local`)
+* Il config seed del chart dichiara una credenziale RTE con il token e l'indirizzo, e il runner, `rte_mode: inbound`, che accede
+  con essa. Con il seed del chart, non c'è nulla da fare
+* Con `containers.rte.seedRunner: false`, o con un tuo config seed (`CONFIG_SEED_PATH`), l'RTE non si aggiunge più come runner.
+  Dichiaralo tu, nel tuo seed o in **Connessioni → Runner**: una credenziale RTE con `http://127.0.0.1:<port>` e il token,
+  e un runner di tipo RTE con `rte_mode: inbound` che la nomina. Le note che Helm stampa dopo l'aggiornamento mostrano come
+
+Dalla 7.3.0 il chart installa anche un Runner da solo, con `runner.enabled` (vedi
+[Un Runner su Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Trova la nuova versione del chart
+
+Aggiorna il repository del chart ed elenca le versioni del chart disponibili:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Aggiorna la release
+
+Esegui lo stesso comando `helm upgrade` dell'installazione, con il tuo file dei valori e la nuova versione del chart:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Con il registry OCI, usa `oci://ghcr.io/ansibleforms/charts/ansibleforms` come chart.
+
+---
+
+## 3. Controlla l'aggiornamento
+
+Aspetta i nuovi pod, poi esegui il test del chart, che controlla sia il server web sia la connessione al database:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+In AnsibleForms, **Aiuto → Informazioni** mostra la versione in esecuzione, e **Impostazioni → Stato** mostra lo stato di salute del
+database, dello schema e degli altri sistemi da cui dipende AnsibleForms.
+
+---
+
+## Tornare indietro
+
+Helm conserva la cronologia della release. Per tornare alla revisione precedente:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Se non si avvia sul database aggiornato, ripristina il tuo backup (vedi il [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) del chart).
diff --git a/i18n/it/_integrate/api/authentication.md b/i18n/it/_integrate/api/authentication.md
new file mode 100644
index 0000000..ceda4d4
--- /dev/null
+++ b/i18n/it/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Autenticazione
+parent: API REST
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Autenticazione
+{: .no_toc }
+
+Accedi, rinnova il token, o usa un token di lunga durata
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ogni chiamata ha bisogno di un access token nell'header `Authorization`. Un token si ottiene accedendo, e si mantiene valido con
+il refresh token.
+
+---
+
+## Accedi
+
+Accedi con l'autenticazione basic, con il nome e la password dell'utente:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+La risposta contiene due token, l'access token e il refresh token:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Chiama l'API
+
+Invia l'access token come bearer token con ogni chiamata:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Rinnova il token
+
+L'access token scade (`ACCESS_TOKEN_EXPIRATION`, 30 minuti per impostazione predefinita). Ottienine uno nuovo con il refresh token,
+senza la password:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+La risposta contiene una nuova coppia, nella stessa forma del login. Un refresh token funziona una volta sola: conserva quello nuovo per il rinnovo successivo.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Token di lunga durata
+
+Uno script che gira senza interazione può usare un token che dura di più. Dalla 7.3.0 richiede l'opzione di ruolo `allowApiTokens`:
+
+* Creane uno in [Profilo > Token API](../profile/api-token.html).
+* Oppure accedi con il parametro di query `expiryDays`, per un token valido quel numero di giorni:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` viene letto solo dall'URL, mai dal body. Per un utente i cui ruoli non hanno `allowApiTokens`, viene ignorato,
+e il login restituisce un token con la durata abituale. `expiryDays=never` richiede anche `extendedTokenExpiration`. Aggiungi il parametro di query `name`
+(`?expiryDays=90&name=nightly-backup`) per dare un nome al token nell'elenco dei token dell'utente.
+
+Un token di lunga durata dura al massimo [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) giorni, 90 per
+impostazione predefinita: un `expiryDays` più lungo viene ridotto a questo valore, a meno che non sia `never`. Rinnovarlo restituisce un token normale, quindi accedi di nuovo quando scade.
+
+### Token dell'utente che ha effettuato l'accesso
+
+La vista **Token API** del profilo usa questi endpoint, che funzionano per qualsiasi account, SSO compreso, perché non richiedono password:
+
+| Chiamata | Cosa fa |
+|---|---|
+| `GET /api/v2/profile/tokens` | Elenca i tuoi token API, con il loro `sid`, `name`, creazione, scadenza e ultimo uso |
+| `POST /api/v2/profile/tokens` | Crea un token dalla tua sessione; il body contiene `expiryDays` (un numero, o `never`) e un `name` facoltativo |
+| `DELETE /api/v2/profile/tokens/{sid}` | Revoca uno dei tuoi token |
+
+`POST` risponde `403` quando viene chiamato con un token API (un token non può crearne un altro), senza `allowApiTokens`, o quando la
+sessione ha effettuato l'accesso più di 10 minuti fa (codice `sign_in_again`): prima accedi di nuovo. Una durata superiore al massimo risponde `400`.
+
+---
+
+## Quando un token termina prima
+
+Un token, di lunga durata o no, smette di funzionare prima della scadenza quando succede una di queste cose:
+
+* **Un logout della sua sessione**: `POST /api/v2/auth/logout` con il token termina i token di quel login, e solo quelli. Un
+  logout nel browser non termina il token di uno script.
+* **Un cambio password**: l'utente cambia la sua password, o un admin la imposta. Ogni token emesso prima viene rifiutato.
+* **L'utente viene rimosso o bloccato**: eliminare un utente locale, o bloccare un utente, termina tutti i suoi token. Un admin può anche
+  terminare le sessioni di un utente LDAP o SSO.
+
+Un token rifiutato risponde `401`. Accedi di nuovo, con la nuova password se è cambiata.
+
+---
+
+## Script che accedono a ogni esecuzione
+
+Gli endpoint di login e dei token sono protetti contro i flood e i tentativi di indovinare le password, quindi uno script che accede ogni volta che gira
+dovrebbe conoscere questi limiti:
+
+| Limite | Predefinito | Cosa succede |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 richieste al minuto da un indirizzo | Login, logout, rinnovo, gli endpoint SSO, `PUT /api/v2/profile` (cambio password) e `POST` o `DELETE /api/v2/profile/tokens` rispondono `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 login falliti di fila | L'account viene bloccato per [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), ogni login risponde `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 login falliti da un indirizzo | Ogni login da quell'indirizzo risponde `429` finché la finestra non termina |
+
+Un `429` porta un header `Retry-After` con i secondi da attendere: fermati e aspetta, non riprovare subito. Un account bloccato
+rifiuta anche la password giusta finché il blocco non termina, quindi uno script con una password sbagliata blocca il suo utente per tutti.
+Una password attuale sbagliata durante un cambio password (`PUT /api/v2/profile`) conta anch'essa come login fallito, e un account bloccato
+non può cambiare la sua password. Un login riuscito azzera il conteggio dell'account, e lo stesso fa un admin che imposta la password.
+
+Per stare lontano da questi limiti, accedi una volta e riusa il token, o usa un token di lunga durata, invece di accedere per
+ogni chiamata. Dietro un reverse proxy, imposta [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) così il server vede
+l'indirizzo del client, altrimenti tutti i client contano come uno solo.
diff --git a/i18n/it/_integrate/api/events.md b/i18n/it/_integrate/api/events.md
new file mode 100644
index 0000000..c8f5b4f
--- /dev/null
+++ b/i18n/it/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Eventi in tempo reale
+parent: API REST
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Eventi in tempo reale
+{: .no_toc }
+
+Sapere quando cambiano job e impostazioni, invece di interrogare a intervalli
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Il server comunica ai suoi client cosa cambia, nel momento in cui cambia. Anche uno script può mettersi in ascolto, invece di leggere un job ogni pochi secondi.
+
+---
+
+## Lo stream
+
+`GET /api/v2/events` è uno stream di [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+che resta aperto. Qualsiasi utente che ha effettuato l'accesso può aprirlo, con il solito bearer token:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Quando qualcosa cambia, invia un evento `changed` con il nome di ciò che è cambiato:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Nomi degli eventi
+
+Un evento porta solo un nome, mai dati, quindi non rivela nulla che l'utente non possa vedere. Vengono inviati questi nomi:
+
+| Nome | Cosa è cambiato |
+|---|---|
+| `jobs` | Un job: avviato, il suo stato o il suo output, eliminato |
+| `appearance` | Le impostazioni mostrate dall'intestazione: il tema, il nome, un annuncio, una variabile d'ambiente |
+| `designer` | Un blocco del designer, preso o rilasciato |
+| `runners` | Un runner (dalla 7.3.0): un RTE si è connesso o disconnesso, ha chiesto di unirsi, è stato approvato o rifiutato, o ha cambiato modalità o impostazioni |
+
+Quando ricevi un nome, rileggi ciò che mostri tramite la normale API (per esempio `GET /api/v2/job/42`), con i tuoi
+permessi. Un nome molto frequente viene inviato al massimo una volta al secondo.
+
+---
+
+## Tenerlo aperto
+
+Lo stream è fatto per sopravvivere a proxy e load balancer, e un client si riconnette da solo:
+
+* Alla connessione, il server invia un evento `hello`, e chiede al client di attendere 3 secondi prima di riconnettersi.
+* Ogni 15 secondi invia una riga di commento (`: ping`), così una connessione inattiva non viene chiusa. Ignora le righe che iniziano con `:`.
+* Gli eventi di ogni nodo dell'app raggiungono ogni stream, qualunque sia il nodo a cui è connesso il client.
+* Dopo una riconnessione, rileggi ciò che mostri: un evento inviato mentre lo stream era interrotto non viene inviato di nuovo.
+
+---
+
+## Salute e metriche
+
+Le sonde di liveness e readiness (`/api/v2/live`, `/api/v2/ready`) e le metriche Prometheus (`/api/v2/metrics`) sono
+pensate per gli strumenti di monitoraggio più che per script che agiscono come un utente. Vedi [Monitoraggio](../production/monitoring.html).
diff --git a/i18n/it/_integrate/api/index.md b/i18n/it/_integrate/api/index.md
new file mode 100644
index 0000000..541bdbc
--- /dev/null
+++ b/i18n/it/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: API REST
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# API REST
+{: .no_toc }
+
+Avvia moduli e gestisci AnsibleForms dagli script
+{: .fs-6 .fw-300 }
+
+---
+
+Per sviluppatori e automation engineer: avvia moduli e gestisci AnsibleForms dagli script.
+
+Tutto ciò che fa l'interfaccia web passa dall'API REST, quindi script e altri strumenti possono fare lo stesso.
+
+---
+
+## Panoramica
+
+L'API è servita sotto `/api/v2` sul server di AnsibleForms:
+
+* **Riferimento completo** : queste pagine trattano ciò che gli script usano di più. Ogni endpoint è descritto, e si può provare, nella
+  pagina Swagger integrata del server, `https://<your server>/api/v2/docs`.
+* **Permessi** : una chiamata viene eseguita come l'utente di cui porta il token, con i ruoli di quell'utente, come nel browser.
+* **Validazione all'avvio** : i job avviati tramite l'API possono essere controllati come gli avvii dal browser
+  (vedi [Validazione all'avvio](../launch-validation/)).
+* **Limiti di frequenza** : sono limitati solo gli endpoint di login, logout, rinnovo del token e single sign-on, il cambio password
+  (`PUT /api/v2/profile`) e gli endpoint dei token API (`POST` e `DELETE /api/v2/profile/tokens`) (vedi
+  [Autenticazione](authentication.html)). Le altre chiamate non hanno limiti di frequenza (l'[assistente chat](../chat/) ha limiti
+  propri), quindi uno script dovrebbe regolare da sé il proprio ritmo, per esempio quando segue un job.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha la sua pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Autenticazione](authentication.html) | Accedi, rinnova il token, o usa un token di lunga durata |
+| [Job](jobs.html) | Avvia un modulo, segui il job, interrompilo, rilancialo o approvalo |
+| [Risposte ed errori](responses.html) | La forma di una risposta, e i codici di stato |
+| [Eventi in tempo reale](events.html) | Sapere quando cambiano job e impostazioni, invece di interrogare a intervalli |
diff --git a/i18n/it/_integrate/api/jobs.md b/i18n/it/_integrate/api/jobs.md
new file mode 100644
index 0000000..8bc6904
--- /dev/null
+++ b/i18n/it/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Job
+parent: API REST
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Job
+{: .no_toc }
+
+Avvia un modulo, segui il job, interrompilo, rilancialo o approvalo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Un job è un'esecuzione di un modulo. Avvialo con il nome e i valori del modulo, poi seguilo tramite il suo ID.
+
+---
+
+## Avvia un modulo
+
+Invia il nome del modulo e i suoi valori a `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+La richiesta accetta queste proprietà:
+
+| Proprietà | Significato |
+|---|---|
+| `formName` | Il nome del modulo da avviare. Obbligatoria. |
+| `extravars` | Le variabili extra per il job. `payload` è accettato come altro nome. |
+| `rawFormData` | I valori dei campi del modulo, come li tiene il browser. La [validazione all'avvio](../launch-validation/) controlla questi, e costruisce da essi le extravars. |
+| `credentials` | Credenziali da passare al job, per nome. |
+| `files` | Gli upload dei campi file del modulo (vedi [Upload di file](../launch-validation/file-uploads.html)). |
+
+La risposta contiene l'ID del nuovo job:
+
+```json
+{ "id": 42 }
+```
+
+Per eseguire il job in modalità verbose, aggiungi `"__verbose__": true` alle extravars. Richiede l'opzione di ruolo `allowVerboseMode`,
+altrimenti l'avvio risponde `403`.
+
+---
+
+## Carica un file
+
+Un modulo con un campo file ha bisogno che prima venga caricato il file. Invialo come parte multipart `file` a `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+La risposta descrive l'upload salvato:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Passalo invariato nei `files` dell'avvio, sotto il nome del campo file: `"files": { "firmware": { ... } }`. Il server
+lo verifica sul proprio disco (vedi [Upload di file](../launch-validation/file-uploads.html)).
+
+---
+
+## Segui il job
+
+Leggi il job tramite il suo ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+Il job contiene il suo `status`, le sue `extravars` (anche come `payload`, lo stesso oggetto), i suoi `subjobs` e il suo `output`. L'output
+è HTML con i colori della pagina del job; aggiungi `?text=true` per il testo semplice, adatto a uno script o a un log:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+Il suo `status` è `running` mentre è in esecuzione, e `approve` mentre attende un'approvazione. Un job termina con uno di questi:
+
+| Stato | Significato |
+|---|---|
+| `success` | Il job è terminato senza errori |
+| `failed` | Il job è fallito |
+| `warning` | Un job multistep è terminato, ma un passo con `continue` impostato è fallito lungo il percorso |
+| `aborted` | Il job è stato interrotto |
+| `rejected` | L'approvazione è stata rifiutata, quindi ciò che la attendeva non è stato eseguito |
+| `abandoned` | Il processo che seguiva il job si è fermato (un riavvio, un container sostituito) e il job è stato abbandonato |
+
+Un job in esecuzione su un runner quando è stato abbandonato può comunque terminare con il suo esito reale, se quel runner lo porta a termine.
+
+---
+
+## Trova i job
+
+`GET /api/v2/job` elenca prima i job più recenti, come `{ "count": ..., "records": [ ... ] }`. Questi parametri di query lo restringono:
+
+| Parametro | Significato |
+|---|---|
+| `records` | Quanti job, al massimo. Il valore predefinito è [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), e 5000 il massimo a meno che `JOBS_LIST_SIZE` non sia più alto. |
+| `user`, `user_type` | Solo i job di questo utente. `user_type` è `local` se omesso (`ldap`, `azuread`, `oidc` per gli altri). |
+| `runner` | Solo i job eseguiti su questo runner |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Un utente vede i propri job e i job che attendono un'approvazione che uno dei suoi ruoli può dare. Un admin, o un ruolo con l'opzione
+`showAllJobLogs` o `manageAllJobs`, vede tutti i job. Un record contiene il riepilogo del job (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); leggi
+il job stesso per le sue extravars e il suo output.
+
+`GET /api/v2/job/approvals` risponde con un numero: quanti job attendono un'approvazione che l'utente può dare.
+
+---
+
+## Altro su un job
+
+Questi endpoint leggono altre informazioni su un job:
+
+| Chiamata | Cosa restituisce |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | I valori dei campi con cui il job è stato avviato, come li conteneva il modulo. Valgono gli stessi permessi di un rilancio: un tuo job (o qualsiasi job per un admin o un ruolo con `manageAllJobs`), un modulo che consente il rilancio, e l'opzione di ruolo `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Gli eventi strutturati di un job playbook (dalla 7.3.0, per un playbook su un RTE 7.3.0 o successivo): ogni play, task, risultato per host e il recap, con il loro `order`, `type`, `play`, `task`, `host`, `duration` e `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Uno di questi eventi con il suo `result` completo, come lo mostra la finestra **Risultato del task**; `400` quando `order` non è un numero intero, `404` quando il job non ha un evento del genere |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Un nodo di un job workflow: `{ "node", "job", "extravars", "artifacts" }`, dove `job` è l'ID del job del nodo, o `null` quando il nodo non è stato eseguito. |
+
+---
+
+## Altre azioni
+
+Questi endpoint agiscono su un job esistente:
+
+| Chiamata | Azione |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Interrompe un job in esecuzione |
+| `POST /api/v2/job/{id}/relaunch` | Rilancia un job, così come è stato eseguito o con modifiche (vedi [Rilancio](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Approva un job che attende approvazione; un tuo job risponde `403`, a meno che la sua approvazione non imposti `allowSelf: true` o tu sia un admin |
+| `POST /api/v2/job/{id}/reject` | Rifiuta un job che attende approvazione |
+| `GET /api/v2/job/{id}/download` | Scarica l'output del job |
+| `DELETE /api/v2/job/{id}` | Elimina un job |
+
+Interruzione, approvazione, rifiuto ed eliminazione rispondono con un messaggio, e un rilancio anche con l'ID del nuovo job:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Aggiungi `?verbose=true` a un rilancio per eseguire il nuovo job in modalità verbose, con l'opzione di ruolo `allowVerboseMode`. Un job che
+è nello stato sbagliato per l'azione, per esempio l'interruzione di un job già terminato, risponde `409`.
diff --git a/i18n/it/_integrate/api/responses.md b/i18n/it/_integrate/api/responses.md
new file mode 100644
index 0000000..ddcb796
--- /dev/null
+++ b/i18n/it/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Risposte ed errori
+parent: API REST
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Risposte ed errori
+{: .no_toc }
+
+La forma di una risposta, e i codici di stato
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Le risposte sono JSON semplice, e il codice di stato HTTP dice se una chiamata è riuscita.
+
+---
+
+## Risposte
+
+Una chiamata riuscita restituisce l'oggetto stesso, o un elenco con la sua dimensione:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Un errore restituisce un messaggio, e i dettagli quando ce ne sono:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Codici di stato
+
+Il codice di stato dice cosa è andato storto:
+
+| Codice | Significato |
+|---|---|
+| `200` | La chiamata è riuscita |
+| `400` | La richiesta è malformata, per esempio un rinnovo del token senza refresh token, o un upload senza file |
+| `401` | Il token manca, è sbagliato o è scaduto: accedi o rinnovalo |
+| `403` | I ruoli dell'utente non consentono la chiamata (compreso approvare un proprio job, a meno che la sua approvazione non imposti `allowSelf: true` o tu sia un admin), o l'account deve prima fare qualcosa (vedi sotto) |
+| `404` | L'oggetto non esiste |
+| `409` | La richiesta è incompleta (un avvio senza dati), o l'oggetto non è in uno stato che consente l'azione |
+| `422` | La [validazione all'avvio](../launch-validation/) ha rifiutato i valori del modulo; `details` elenca il perché |
+| `429` | Troppe richieste agli endpoint di login e dei token, o troppi login falliti (vedi [Autenticazione](authentication.html)) |
+| `500` | Il server ha avuto un errore; il log del server riporta il motivo |
+
+Per un job, un `409` significa che è nello stato sbagliato per l'azione: interrompere un job che non è in esecuzione (o di cui è già stata chiesta l'interruzione),
+rilanciare un job ancora in esecuzione, o approvare o rifiutare un job che non attende più un'approvazione.
+
+---
+
+## Un 403 con un codice
+
+Alcune risposte `403` portano un `code`, per qualcosa che l'utente deve fare nel browser prima che qualsiasi altra chiamata funzioni:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Codice | Cosa fare |
+|---|---|
+| `password_change_required` | L'utente ha effettuato l'accesso con la password predefinita pubblica: prima cambiala nel profilo |
+| `disclaimer_required` | Il disclaimer è attivo e l'utente non ne ha ancora accettato la versione attuale: accettalo nel browser |
+
+Un token API di lunga durata (vedi [Autenticazione](authentication.html#long-lived-tokens)) non viene mai bloccato dal disclaimer.
diff --git a/i18n/it/_integrate/chat/index.md b/i18n/it/_integrate/chat/index.md
new file mode 100644
index 0000000..565ad33
--- /dev/null
+++ b/i18n/it/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Assistente chat
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Assistente chat
+{: .no_toc }
+
+Compila e avvia moduli tramite una conversazione
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per gli amministratori che lo attivano, e per gli utenti che chattano con esso: compila e avvia moduli tramite una conversazione.
+
+Un pulsante di chat su ogni pagina apre un
+assistente che trova il modulo giusto, chiede le informazioni mancanti, propone come pulsanti le scelte
+del modulo stesso, e mostra un riepilogo con un pulsante **Avvia**. Un job parte solo quando l'utente fa clic su di esso.
+
+---
+
+## Come funziona
+
+L'assistente comunica con il modello di IA tramite il server, che risponde alle richieste del modello usando lo stesso motore dei moduli del browser:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Le chiamate al modello partono dal server**, mai dal browser, quindi la chiave API resta sul server
+  (vedi [Fornitori](providers.html)).
+- **Il modello non può avviare nulla.** Prepara un riepilogo monouso; Avvia lo ricontrolla prima di eseguirlo.
+- **È l'utente a scegliere i target.** Le scelte e i nomi obbligatori vengono dall'utente, mai dal modello.
+- **Scrivere "sì" o "avvia" non fa nulla.** Solo il pulsante avvia un job.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha la sua pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Attivarlo](switching-it-on.html) | Abilita l'assistente e offri dei moduli al suo interno |
+| [Fornitori](providers.html) | Il modello linguistico dietro l'assistente, e i proxy |
+| [Privacy e limiti](privacy-and-limits.html) | Cosa esce dalla rete, e i limiti per utente |
+| [Rilancio e audit](relaunching-and-audit.html) | Il rilancio dalla chat, la traccia di audit e le limitazioni |
diff --git a/i18n/it/_integrate/chat/privacy-and-limits.md b/i18n/it/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..0e18741
--- /dev/null
+++ b/i18n/it/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Privacy e limiti
+parent: Assistente chat
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Privacy e limiti
+{: .no_toc }
+
+Cosa esce dalla rete, e i limiti per utente
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Cosa esce dalla rete
+
+Per i moduli che partecipano, al fornitore viene inviato quanto segue:
+
+- i nomi e le descrizioni dei moduli, le etichette dei campi, i testi di aiuto, le scelte e i valori che si stanno
+  compilando;
+- la conversazione.
+
+Quanto segue non viene mai inviato al fornitore, alla pagina né al log:
+
+- le password (l'utente le inserisce nel browser), le credenziali salvate e la chiave API;
+- l'output di un job, e le sue extravars salvate (l'assistente legge solo lo stato di un job, e solo
+  quando **Lascia che l'assistente segua i suoi job** è attivo nelle impostazioni).
+
+Tutto ciò che si trova sotto una chiave che sembra un segreto (`password`, `secret`, `token`, `api_key`, ...)
+viene mascherato prima che il modello o la pagina lo vedano.
+
+Per tenere i dati dei moduli in casa, usa un tuo tenant (Azure OpenAI) o un modello locale (Ollama), non un'API pubblica.
+
+---
+
+## Limiti
+
+I seguenti limiti si impostano nella pagina delle impostazioni:
+
+- **Messaggi per conversazione** (20) - dopodiché l'utente deve iniziare una nuova conversazione.
+- **Cicli di strumenti per messaggio** (6) - quante volte il modello può chiamare uno strumento prima di rispondere.
+- **Timeout** (60 s) - per ogni chiamata al fornitore.
+
+I seguenti limiti sono fissi: un messaggio alla volta per conversazione, al massimo 4000 caratteri per messaggio, 60 messaggi per
+utente all'ora, e 5 conversazioni per utente. Una conversazione viene scartata dopo 2 ore senza messaggi.
+
+Una scheda di riepilogo con un pulsante **Avvia** si può usare una volta, e scade dopo 15 minuti: Avvia risponde allora che il
+riepilogo è scaduto, e l'utente chiede all'assistente un riepilogo nuovo. Conversazioni e riepiloghi sono tenuti in memoria, quindi dopo
+un riavvio l'utente deve iniziare una nuova conversazione.
diff --git a/i18n/it/_integrate/chat/providers.md b/i18n/it/_integrate/chat/providers.md
new file mode 100644
index 0000000..d7b88f5
--- /dev/null
+++ b/i18n/it/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Fornitori
+parent: Assistente chat
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Fornitori
+{: .no_toc }
+
+Il modello linguistico dietro l'assistente, e i proxy
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Seleziona il fornitore nella pagina delle impostazioni. Questo compila l'URL di base, l'autenticazione e
+la versione API, che restano tutti modificabili. I campi vuoti ricadono sui valori predefiniti del fornitore.
+
+| Fornitore | Protocollo | URL di base (predefinito) | Chiave inviata come |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | obbligatorio: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, versione API `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | nessuna |
+| **Altro compatibile OpenAI** (LiteLLM, un gateway, vLLM, LM Studio, ...) | OpenAI | obbligatorio, di solito termina con `/v1` | Bearer |
+
+L'ID del modello è quello usato dal fornitore o dal proxy (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). L'assistente richiede un modello che supporti il **tool calling**; il supporto varia tra
+i piccoli modelli locali.
+
+Per i server locali e i proxy che non richiedono una chiave, basta un URL di base; non viene inviato nessun header di autorizzazione.
+
+---
+
+## La chiave API
+
+La chiave proviene da una credenziale, quindi viene salvata e ruotata come ogni altro segreto:
+
+* Crea una credenziale di tipo **api** in **Impostazioni > Connessioni > Credenziali** (vedi [Credenziali](../credentials.html)),
+  con la chiave come password. Può anche leggere la chiave da un [archivio di segreti](../secret-stores/).
+* Sceglila nel campo **Credenziale** delle impostazioni della chat. La chiave viene letta per ogni messaggio, quindi una
+  password cambiata si applica dal messaggio successivo.
+
+Una chiave salvata nella pagina delle impostazioni prima che esistessero le credenziali continua a funzionare finché non viene scelta nessuna credenziale. Il
+[config seed](../seed/) imposta la chiave stessa, come `api_key`.
+
+---
+
+## Per un proxy
+
+Un proxy o un gateway davanti al modello può aver bisogno di queste impostazioni:
+
+- **Autenticazione** - come viene inviata la chiave: `Authorization: Bearer`, `api-key`, `x-api-key`,
+  o nessuna. Vuoto usa il predefinito del fornitore.
+- **Versione API** - l'header `anthropic-version`, o `?api-version=` nell'URL per i compatibili OpenAI (Azure).
+- **Utente** - inviato con ogni chiamata come `user` (compatibili OpenAI) o `metadata.user_id`
+  (Anthropic). Alcuni proxy lo richiedono. Vuoto non invia nulla.
+- **Ignora errori del certificato** - non sicuro; fai invece considerare attendibile la CA del proxy con `NODE_EXTRA_CA_CERTS`.
+- **Header aggiuntivi** - un oggetto JSON, es. `{"X-Org": "ops"}`. Valori di testo su una riga, al massimo 20;
+  gli header della chiave e del contenuto non possono essere sostituiti.
+
+---
+
+## In un container, dietro un proxy
+
+La chat usa semplice HTTPS in uscita dal container del server AnsibleForms. Dietro un
+proxy di uscita aziendale, imposta `HTTPS_PROXY` **e** `NODE_USE_ENV_PROXY=1`; senza il secondo,
+il client HTTP integrato di Node ignora `HTTPS_PROXY`. Un fornitore con un certificato di una
+CA interna richiede che Node consideri attendibile quella CA (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Con `NODE_USE_ENV_PROXY=1`, un modello o un proxy dentro la rete deve essere elencato in
+`NO_PROXY`, altrimenti la chiamata va al proxy di uscita, che non può raggiungerlo.
+
+Un test di connessione fallito indica l'host e il motivo (DNS, connessione rifiutata o certificato non attendibile).
diff --git a/i18n/it/_integrate/chat/relaunching-and-audit.md b/i18n/it/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..75dfb39
--- /dev/null
+++ b/i18n/it/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Rilancio e audit
+parent: Assistente chat
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Rilancio e audit
+{: .no_toc }
+
+Il rilancio dalla chat, la traccia di audit e le limitazioni
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rilancio
+
+Una richiesta come "Esegui di nuovo il job 1234" (l'utente deve digitare l'ID del job) mostra un'anteprima di un rilancio
+con le stesse regole di `relaunch_job` del server MCP, compresa la regola sulle password della
+[validazione all'avvio](../launch-validation), e mostra un riepilogo **Riavvia**; il pulsante
+lo avvia una volta. "Esegui di nuovo il job 1234 con il server web02" cambia solo quel campo.
+
+---
+
+## Audit
+
+Ogni avvio dalla chat viene registrato come **chat.launch** con l'utente, il job, il modulo,
+il fornitore e l'hash del payload del riepilogo che è stato approvato. Le modifiche alle impostazioni della chat vengono
+registrate come qualsiasi altra modifica alle impostazioni.
+
+---
+
+## Limitazioni
+
+L'assistente chat non fa ancora tutto ciò che fa un browser:
+
+- I **moduli wizard** non possono partecipare (`enableForChat` viene rifiutato su di essi), e nemmeno
+  i campi che l'assistente non compila: password e upload di file.
+- Le risposte arrivano in un unico blocco; lo streaming non è ancora supportato.
+- Il modello può fraintendere una richiesta. La scheda di riepilogo mostra esattamente cosa verrà inviato;
+  controllala prima di fare clic su **Avvia**.
diff --git a/i18n/it/_integrate/chat/switching-it-on.md b/i18n/it/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..f48eb39
--- /dev/null
+++ b/i18n/it/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Attivarlo
+parent: Assistente chat
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Attivarlo
+{: .no_toc }
+
+Abilita l'assistente e offri dei moduli al suo interno
+{: .fs-6 .fw-300 }
+
+---
+
+L'assistente richiede tutte e quattro le condizioni seguenti:
+
+1. **`ENABLE_CHAT=1`** - la variabile d'ambiente. Modificata nella pagina delle impostazioni, si applica subito, senza riavvio; finché
+   è disattivata, gli endpoint della chat rispondono `404`. Vedi [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Un fornitore del modello** - Impostazioni -> Connessioni -> **Assistente chat** (o il [config seed](../seed) su Kubernetes).
+3. **Moduli che partecipano** - `enableForChat: true` su ogni modulo; l'assistente ignora tutti gli altri.
+4. **Utenti che possono usarlo** - l'opzione di ruolo `allowChat` (predefinito: true). Imposta
+   `allowChat: false` su un ruolo per escluderne i membri.
+
+Il pulsante della chat compare per un utente quando tutte e quattro le condizioni sono soddisfatte.
diff --git a/i18n/it/_integrate/mcp/index.md b/i18n/it/_integrate/mcp/index.md
new file mode 100644
index 0000000..522026c
--- /dev/null
+++ b/i18n/it/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Server MCP
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# Server MCP
+{: .no_toc }
+
+Lascia che gli agenti di IA usino i tuoi moduli tramite il Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per amministratori e integratori: lascia che i client MCP elenchino, compilino e avviino moduli come l'utente di cui hanno il token.
+
+AnsibleForms può servire un
+server [Model Context Protocol](https://modelcontextprotocol.io), così che un client MCP, come
+un backend di chat o un assistente dell'IDE, possa elencare i moduli che un utente può usare, determinarne i campi,
+avviare job e seguirne l'avanzamento.
+
+---
+
+## Cos'è, e cosa non è
+
+Il server MCP è un'interfaccia tecnica allo stesso flusso dei moduli usato dal browser. Gira
+**come l'utente di cui riceve il token**: gli stessi ruoli dei moduli, la stessa visibilità dei job, gli
+stessi controlli sulle extravars riservate di un invio dal browser.
+
+Non aggiunge nessuna politica di IA propria. Se un agente debba chiedere conferma prima di un avvio,
+quali moduli possa usare, o quante richieste possa fare, spetta al client MCP. Lo
+strumento di avvio è contrassegnato come distruttivo, quindi un client ben fatto chiede prima conferma,
+ma il server non lo impone.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha la sua pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Configurazione](setup.html) | Attiva il server e autentica il client |
+| [Strumenti](tools.html) | Gli strumenti che un agente usa per compilare, approvare e rilanciare moduli |
+| [Limitazioni](limitations.html) | Le espressioni eseguite sul server, e ciò che il server MCP non fa |
diff --git a/i18n/it/_integrate/mcp/limitations.md b/i18n/it/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..a39d19c
--- /dev/null
+++ b/i18n/it/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Limitazioni
+parent: Server MCP
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Limitazioni
+{: .no_toc }
+
+Le espressioni eseguite sul server, e ciò che il server MCP non fa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Espressioni runLocal
+
+Le espressioni `runLocal`, i campi `local` / `credential` / `html` e i valori predefiniti `evalDefault` vengono
+valutati sul server, in un contesto V8 separato: niente `process`, `require`, rete né
+timer, nessuna compilazione di stringhe in codice, un limite di tempo di 2 secondi, e solo le funzioni
+helper offerte dal browser (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Questo protegge da espressioni difettose o fuori controllo. Non è una sandbox per codice ostile,
+e non ha bisogno di esserlo: il codice viene dalla definizione del modulo, mai dal chiamante
+MCP, e ogni valore inviato da un chiamante viene sostituito come letterale JavaScript.
+
+Un'espressione che usa un'API del browser (`window`, `document`, `fetch`) non può girare qui e
+restituisce `status: error`.
+
+Le espressioni lato server (senza `runLocal`) passano per le stesse regole di
+[`EXPRESSION_SANITIZER`](../customization) usate per il browser.
+
+---
+
+## Limitazioni
+
+Alcuni moduli e campi non si possono ancora usare tramite il server MCP:
+
+- I **moduli wizard** non si possono ancora avviare. I loro passi si possono risolvere con `subform`.
+- I **campi file** non si possono compilare; un modulo il cui campo file ha un valore viene rifiutato.
+- **Righe di lista** (e un campo `yaml` con un subform, che è una riga del genere): ogni riga che
+  invii, tranne una che porta il `deleteMarker` della lista, viene risolta tramite il suo subform con
+  i valori del modulo come `__parent__` e poi validata. Questo vale anche per le liste annidate, dove
+  `__parent__.__parent__` raggiunge il modulo. Invia righe semplici, cioè i valori grezzi dei campi
+  del subform. Le righe che falliscono sono elencate per campo lista in `rowErrors`
+  (`vms[1].disks[0].size (missing)` nel messaggio). Sono accettate al massimo 500 righe per chiamata,
+  su tutti i livelli.
+- Un enum lasciato su `__auto__` non viene mai compilato con la sua prima opzione; il chiamante deve scegliere.
+- Ogni richiesta MCP crea una voce nel registro di audit (azione "Richiesta MCP (agente IA)"); il
+  job stesso viene registrato sotto l'utente, come per qualsiasi altro avvio.
diff --git a/i18n/it/_integrate/mcp/setup.md b/i18n/it/_integrate/mcp/setup.md
new file mode 100644
index 0000000..14f1f5a
--- /dev/null
+++ b/i18n/it/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Configurazione
+parent: Server MCP
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Configurazione
+{: .no_toc }
+
+Attiva il server e autentica il client
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Abilitarlo
+
+Imposta [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) su `1`, o attivalo in **Impostazioni > Connessioni > MCP**
+(vedi [La pagina MCP](#the-mcp-page)). Modificato nella pagina delle impostazioni, l'interruttore si applica subito, senza riavvio. Finché è
+disattivato, l'endpoint risponde `404`. L'endpoint è:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Usa Streamable HTTP stateless con risposte JSON semplici, quindi `GET` e `DELETE` restituiscono 405.
+
+---
+
+## Limitare cosa possono fare gli agenti
+
+Altri due interruttori restringono il server MCP per tutti i client. Come `ENABLE_MCP`, si applicano senza riavvio:
+
+| Variabile | Con `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | Il server non offre nessuno degli strumenti che avviano, pianificano o modificano (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), e li rifiuta. Gli agenti possono elencare, leggere e compilare moduli, leggere pianificazioni e job salvati, e seguire i job, ma non avviano né modificano nulla: un modo sicuro per provare un agente. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Gli agenti vedono solo i moduli che impostano `enableForChat: true`, lo stesso elenco dell'[assistente chat](../chat/). Qualsiasi altro modulo, e qualsiasi suo job, risponde come non trovato. |
+
+Entrambi sono disattivati per impostazione predefinita: gli agenti vedono ogni modulo consentito dai ruoli dell'utente, e possono avviarlo.
+
+---
+
+## La pagina MCP
+
+**Impostazioni > Connessioni > MCP** contiene le impostazioni del server MCP in due schede.
+
+- **Generale** ha i tre interruttori, `ENABLE_MCP`, `MCP_READ_ONLY` e `MCP_CHAT_FORMS_ONLY`, salvati con **Salva**. Gli altri due
+  si possono modificare solo mentre il server MCP è attivo.
+- **Configurazione del client** mostra l'**Endpoint**, con un pulsante per copiarlo, e una configurazione pronta per **Claude Code**
+  (`.mcp.json`, o un comando `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, che chiede
+  il token al primo avvio del server) e **Codex** (`~/.codex/config.toml`, con il token nella variabile d'ambiente
+  `ANSIBLEFORMS_TOKEN`). Ognuna ha il suo pulsante di copia; sostituisci `<your-token>` con un tuo token, creato
+  con il link **Crea un token**.
+
+L'endpoint è costruito dall'URL dell'app (**Impostazioni > URL**) quando è impostato, altrimenti dall'indirizzo del browser.
+
+---
+
+## Autenticazione
+
+Ogni richiesta ha bisogno di un access token di AnsibleForms:
+
+```
+Authorization: Bearer <token>
+```
+
+Ottienine uno nel modo abituale (`POST /api/v2/auth/login`, o i flussi OIDC / Entra ID) e
+rinnovalo con `POST /api/v2/token`. Non c'è di proposito **nessuno strumento di login**: una password passata come
+argomento di uno strumento finirebbe nel contesto del modello linguistico e nella sua cronologia di chat.
+
+Anche i ruoli dell'utente devono consentire il server MCP, tramite l'[opzione di ruolo](../config/roles.html) `allowMcp`. Quando nessun ruolo
+dell'utente la imposta, segue `allowChat`, che è attiva per impostazione predefinita. Un utente a cui è negato riceve `403` su ogni richiesta.
+
+- **Un backend di chat** fa accedere l'utente da sé, conserva il refresh token e passa l'access
+  token a ogni chiamata MCP.
+- **Un client IDE** ha bisogno di un token che duri abbastanza da poter essere configurato una sola volta. Con un ruolo
+  che ha l'opzione `allowApiTokens`, creane uno in
+  [Profilo > Token API](../profile/api-token.html), o accedi con `?expiryDays=<n>` nell'URL
+  di login per un token valido quel numero di giorni.
+
+Per collegare un agente di programmazione con un token del genere:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Aggiungi il server con il token come header:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Aggiungi il server a `~/.codex/config.toml`, con il token letto da una variabile d'ambiente:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Poi imposta la variabile prima di avviare Codex:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/it/_integrate/mcp/tools.md b/i18n/it/_integrate/mcp/tools.md
new file mode 100644
index 0000000..4e6ca81
--- /dev/null
+++ b/i18n/it/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Strumenti
+parent: Server MCP
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Strumenti
+{: .no_toc }
+
+Gli strumenti che un agente usa per compilare, approvare e rilanciare moduli
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Il server MCP offre fino a 15 strumenti. Sei sono offerti a ogni utente; gli altri seguono le opzioni di ruolo dell'utente, quindi a un utente
+senza un'opzione i relativi strumenti non vengono proprio offerti:
+
+| Strumento | Cosa fa | Offerto con |
+|---|---|---|
+| `list_forms` | I moduli che l'utente può usare: nome, descrizione, categorie, e `enableForChat` (se l'assistente chat lo offre). | sempre |
+| `get_form` | La definizione completa di un modulo. Ogni campo porta anche `dynamic` (valutato da un'espressione o da una query) e `dependsOn` (i campi che legge). | sempre |
+| `resolve_field` | Valuta il modulo per i valori compilati finora. Vedi sotto. | sempre |
+| `launch_job` | Avvia il modulo con i valori dati, esattamente come farebbe un invio dal browser. Restituisce l'id del job. | sempre |
+| `relaunch_job` | Avvia di nuovo un job con alcuni campi modificati. Vedi sotto. | sempre |
+| `get_job` | Stato e output di un job (`tail` limita l'output alle ultime righe). | sempre |
+| `plan_job` | Esegue il modulo una volta, più tardi, come l'utente: ciò che fa **Esegui più tardi (una volta)** sul modulo. | `allowPlannedJobs` |
+| `create_schedule` | Crea una pianificazione, ricorrente (`cron`) o singola (`run_at`), come nella pagina **Pianificazioni**. | `allowScheduledJobs` |
+| `list_schedules` | Le pianificazioni che l'utente può vedere: tutte con `allowScheduledJobs`, altrimenti le esecuzioni che ha pianificato. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `get_schedule` | Una pianificazione, con le sue extra vars (quelle che sembrano segreti mascherate) e l'output della sua ultima esecuzione. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `delete_schedule` | Annulla un'esecuzione pianificata o elimina una pianificazione che l'utente può vedere. | `allowPlannedJobs` o `allowScheduledJobs` |
+| `list_stored_jobs` | I [job salvati](../jobs/stored-jobs.html) che l'utente può vedere, senza i loro valori. | `allowStoredJobs` |
+| `get_stored_job` | Un job salvato con i suoi valori, per `id`, o per `form` e `name` tra quelli dell'utente. | `allowStoredJobs` |
+| `store_job` | Salva i valori di un modulo con un nome, come fa **Salva** sul modulo. | `allowStoredJobs` |
+| `delete_stored_job` | Elimina un job salvato che l'utente può vedere. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` e `plan_job` accettano `verbose: true` per eseguire il job in modalità verbose, che richiede
+l'opzione di ruolo `allowVerboseMode`. Con [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) gli strumenti che avviano, pianificano o
+modificano (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` e `delete_stored_job`)
+non vengono offerti.
+
+Non c'è nessuno strumento per eseguire un'espressione, una query, un playbook o delle extravars arbitrari. Espressioni
+e query girano sempre e solo come le definisce il modulo.
+
+Anche l'[assistente chat](../chat) usa questi strumenti, con un pulsante **Avvia** al posto di `launch_job`.
+
+---
+
+## Compilare un modulo
+
+Chiama `resolve_field` con il nome del modulo e i valori che hai finora, e di nuovo dopo ogni risposta. Percorre
+i campi in ordine di dipendenza e riporta per ciascuno:
+
+- `status`: `resolved`, `waiting` (con `waitingFor`), `hidden`, o `error` (il campo ricade sul suo valore predefinito);
+- `value`, `default` e, per i campi a scelta, `options` (al massimo `maxOptions`, predefinito 200);
+- `needsInput`: un campo obbligatorio senza valore, o una scelta ancora su `__auto__`;
+- `validationErrors`: le regole che il valore viola, come `[{type, description}]`, con il messaggio del browser.
+
+Per l'intero modulo, `missing` e `invalid` elencano ciò che resta da correggere; `launch_job` lo rifiuta finché `complete` non è true.
+
+La validazione è il codice stesso del browser, condiviso con la [validazione all'avvio](../launch-validation). I campi nascosti non vengono
+validati, e un campo facoltativo vuoto è valido.
+
+---
+
+## Pianificazioni ed esecuzioni pianificate
+
+`plan_job` accetta gli stessi `form`, `values` e `expectedPayloadHash` di `launch_job`, con un `name` per l'esecuzione e `run_at`, un
+orario ISO 8601 con il suo offset o `Z` (`2026-10-15T22:00:00+02:00`); un orario senza fuso viene rifiutato. I valori vengono risolti
+e validati subito, e controllati di nuovo quando l'esecuzione parte, come per un'[esecuzione pianificata](../jobs/schedules.html#planned-runs) nel
+browser. La risposta indica l'orario dell'esecuzione in UTC e sull'orologio dell'app.
+
+`create_schedule` accetta un `form`, un `name`, o `cron` (cinque campi, come `0 22 * * 1-5`) o `run_at`, e le
+`extraVars` che riceve il job. Una pianificazione del genere gira come `Schedule Service`, senza la validazione del modulo; per eseguire un modulo una volta come
+l'utente, usa `plan_job`. I nomi delle pianificazioni sono univoci.
+
+---
+
+## Job salvati
+
+Un job salvato sono i valori di un modulo salvati con un nome; gli strumenti lavorano sugli stessi job salvati del browser.
+
+`list_stored_jobs` elenca i job salvati dell'utente, o quelli di tutti per un utente con `showSettings`, con il loro nome, descrizione,
+modulo, creazione e scadenza. Uno contrassegnato come `usable` (dell'utente stesso, di un modulo che può avviare) si può passare come `storedJob`
+(`{ "id": 7 }`, o `{ "name": "..." }` tra quelli dell'utente per quel modulo) a `resolve_field`, `launch_job` o `plan_job`: i suoi
+valori sono il punto di partenza e `values` vi si sovrappongono. I campi password non vengono salvati, quindi forniscili in `values`.
+`launch_job` e `plan_job` da un job salvato richiedono l'`expectedPayloadHash` che `resolve_field` ha restituito per esso, e
+`resolve_field` rifiuta `storedJob` insieme a `subform`.
+
+`store_job` accetta il `form`, un `name` univoco tra i job salvati dell'utente per quel modulo, i `values`, e facoltativamente una
+`description` e `expires_at` (ISO 8601 con il suo offset o `Z`). La sua risposta dice quali campi password sono stati esclusi.
+
+---
+
+## Passare i valori
+
+Passa `field` per risolvere solo quel campo e ciò da cui dipende. Per una riga di lista o un passo di un wizard, passa `subform` (e
+facoltativamente `parent`, i valori del modulo padre).
+
+Invia i valori come li tiene il browser. Un campo a scelta accetta anche un record parziale o il suo valore `valueColumn`
+(`"vol1"`), e un array quando è `multiple`. I campi calcolati ignorano i valori inviati a meno che non siano `editable`.
+
+---
+
+## Approvare il payload esatto
+
+Quando il modulo è completo, `resolve_field` restituisce anche ciò che `launch_job` invierà:
+
+- `modeledExtravars`: le extravars dopo l'applicazione di `model`, `valueColumn` e `output`,
+  con i campi password mascherati;
+- `credentials`: le credenziali di AnsibleForms che il job userà (nomi, non segreti);
+- `payloadHash`: un hash SHA-256 del nome del modulo, delle extravars reali e delle credenziali.
+
+Mostra `modeledExtravars` all'operatore, e passa il `payloadHash` che ha approvato a
+`launch_job` come `expectedPayloadHash`. L'avvio risolve di nuovo il modulo e viene rifiutato
+quando il payload è diverso, per esempio perché una query ora risponde in modo diverso.
+`ansibleforms_user`, `__jobid__` e `__verbose__` vengono aggiunti all'avvio e non fanno parte dell'hash.
+
+`launch_job` controlla solo il payload. Una modifica del modulo che lascia il payload uguale non fa rifiutare l'avvio.
+Ogni risposta di `resolve_field` porta anche un `formFingerprint`, un hash SHA-256 della definizione del modulo: per rifiutare un
+avvio dopo qualsiasi modifica del modulo, confrontalo tu prima di chiamare `launch_job`, come fa il pulsante
+**Avvia** dell'assistente chat.
+
+---
+
+## Rilanciare con modifiche
+
+`relaunch_job` accetta un `id` di job e `values`: solo i campi da modificare, come valori grezzi.
+`values` si sovrappone ai valori con cui il job era stato avviato in origine, e il risultato viene
+risolto e validato esattamente come da `launch_job`, righe di lista comprese, poi avviato come
+nuovo job da te (`ansibleforms_user` sei tu, non chi lo aveva inviato in origine). Gli upload di file
+del job originale vengono riutilizzati.
+
+Senza `values`, è un rilancio **così come il job è stato eseguito**: le sue extravars salvate vengono riprodotte sul
+server, password comprese (l'anteprima le maschera). Se però il modulo è sotto la validazione all'avvio
+`enforce`, il rilancio passa per lo stesso controllo di un rilancio con
+modifiche.
+
+**Le password non vengono mai salvate con i valori dei campi**, quindi un rilancio che passa per il
+controllo viene rifiutato quando il modulo mostra un campo password, al livello principale o in una riga di lista
+(`unsupported`, con i `passwordFields`). Un campo password nascosto dalle sue dipendenze non
+blocca il rilancio. Vedi [Validazione all'avvio](../launch-validation).
+
+Chiamalo prima con `preview: true`: restituisce `modeledExtravars` (password mascherate),
+`credentials` e un `payloadHash` senza avviare nulla. Confermali con l'utente, poi chiamalo
+di nuovo con `expectedPayloadHash`. Valgono gli stessi permessi di un rilancio nel browser:
+il modulo deve consentire il rilancio e i tuoi ruoli devono avere l'opzione `allowJobRelaunch`. Un
+job senza dati del modulo salvati (avviato prima che esistesse il rilancio) e un modulo wizard non si possono
+rilanciare con modifiche.
+
+L'API REST offre lo stesso tramite `POST /api/v2/job/{id}/relaunch` con il body
+`{ "values": { ... } }`; senza body, riproduce il job così come è stato eseguito.
+
+---
+
+## Errori
+
+Una chiamata rifiutata è un errore dello strumento il cui contenuto strutturato porta un `code` e i dettagli:
+
+| Codice | Quando |
+|---|---|
+| `form_incomplete` | `launch_job` o `relaunch_job` su un modulo non completo, con `missing`, `invalid`, `waiting`, `validationErrors` e `rowErrors` |
+| `payload_mismatch` | il payload è diverso da `expectedPayloadHash`, con entrambi gli hash |
+| `access_denied` | i ruoli dell'utente non concedono il modulo, il job, la pianificazione o il job salvato, o la modalità verbose, o il server è in sola lettura |
+| `not_found` | nessun modulo, subform o job del genere |
+| `unsupported` | un modulo wizard, un subform da solo, un campo file, o un `relaunch_job` che richiederebbe un campo password visibile |
+| `no_form_data` | `relaunch_job` con modifiche per un job che non ha salvato valori del modulo, come uno avviato da una pianificazione; rilancialo invece senza modifiche |
+| `invalid_request` | una richiesta che il server rifiuta perché malformata |
+| `internal_error` | qualsiasi altra cosa |
diff --git a/i18n/it/_introduction/concepts.md b/i18n/it/_introduction/concepts.md
new file mode 100644
index 0000000..d3b5fe4
--- /dev/null
+++ b/i18n/it/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Concetti
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Concetti
+{: .no_toc }
+
+I termini usati in questa documentazione, ognuno collegato alla sua pagina
+{: .fs-6 .fw-300 }
+
+---
+
+## Glossario
+
+I termini usati in questa documentazione:
+
+| Termine | Significato |
+|---|---|
+| **[Modulo](forms/)** | Una definizione YAML che raccoglie input ed esegue un playbook, un template o un workflow |
+| **[Campo del modulo](formfields/)** | Un input di un modulo, come `text`, `enum` o `checkbox`; il suo valore diventa un'extravar |
+| **[Categoria](config/categories.html)** | Un gruppo nell'albero dei moduli mostrato nella pagina Moduli, definito in `config.yaml` |
+| **[Ruolo](config/roles.html)** | Un insieme di utenti e gruppi; un modulo elenca i ruoli che possono vederlo ed eseguirlo, `default` per tutti |
+| **[Espressione](expressions/)** | JavaScript che calcola il valore di un campo, nel browser (`runLocal: true`) o sul server |
+| **[Extravars](formfields/)** | Le variabili inviate al playbook o al template, costruite dai valori dei campi |
+| **[Credenziale](expressions/credentials.html)** | Un login salvato, cifrato con `ENCRYPTION_SECRET`: un utente e una password (e host, porta, database), o dalla 7.3.0 l'indirizzo e i segreti di una directory LDAP, di un provider SSO, di un runner o di un HashiCorp Vault |
+| **[Archivio di segreti](secret-stores/)** | Una connessione a HashiCorp Vault o CyberArk che fornisce l'utente e la password di una credenziale |
+| **[Job](gui/forms-and-jobs.html)** | Un'esecuzione di un modulo, con il suo stato, le extravars e l'output, conservata nella cronologia dei job |
+| **[Runner](runners.html)** | Dove gira un job, aggiunto in **Connessioni > Runner**: `rte` per i playbook, `awx` (AWX, o la variante `aap` o `ascender`), `semaphore`, `rundeck` o `jenkins` per template e job. Un modulo ne sceglie uno con `runner:`, o gira sul runner predefinito `rte` (playbook) o `awx` (template) |
+| **[RTE](rte/)** | Un ambiente di runtime: il server AnsibleForms avviato con `AF_ROLE=rte` nel suo container, accanto a python e ansible, che esegue i playbook di un runner di tipo `rte` |
+| **[Punto di approvazione](forms/approval.html)** | Una pausa in un job finché un utente con un ruolo di approvazione non lo approva o lo rifiuta |
+| **[Workflow](workflows/)** | Un grafo di playbook, approvazioni e altri workflow collegati in caso di successo, di fallimento o sempre, con la sintassi di AWX |
+| **[Modulo multistep](forms/multistep.html)** | Deprecato dalla 7: un modulo che esegue più playbook o template in sequenza; lo sostituisce un workflow |
+| **[Canale di notifica](notification-channels.html)** | Un server di posta, un webhook di Slack o Teams, una chat Telegram o un webhook a cui vanno le notifiche e le richieste di approvazione |
+| **[Designer](designer/)** | L'editor nel browser per moduli, playbook, inventari e workflow, usato da una persona alla volta |
+| **[Subform](forms/subform.html)** | Un insieme riutilizzabile di campi che descrive le righe di un campo `list` o l'oggetto di un campo `yaml` |
+| **[config.yaml](config/)** | Il file con le categorie, i ruoli e le costanti; i moduli stanno nei loro file |
+| **[Config seed](seed/)** | Un file YAML (`CONFIG_SEED_PATH`) che dichiara gli oggetti di amministrazione, come runner e credenziali |
+| **[Cartella persistente](customization/paths.html)** | La cartella che contiene i file che AnsibleForms deve conservare tra riavvii e aggiornamenti |
diff --git a/i18n/it/_introduction/gui/administration.md b/i18n/it/_introduction/gui/administration.md
new file mode 100644
index 0000000..b00f80d
--- /dev/null
+++ b/i18n/it/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Amministrazione
+parent: Tour dell'interfaccia
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Amministrazione
+{: .no_toc }
+
+Il menu Impostazioni: il sistema, il suo aspetto, l'accesso, le connessioni e i log
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Il menu Impostazioni
+
+**Impostazioni** nell'intestazione apre le pagine di amministrazione, raggruppate nel menu a sinistra sotto **Sistema**, **Aspetto**,
+**Accesso**, **Connessioni** e **Log**. Ogni voce compare solo a un utente con l'opzione di ruolo che la sua pagina richiede:
+`allowBackupOps` per **Backup**, `showLogs` per **Log del server**, e `showSettings` per ogni altra pagina.
+Dalla 7.3.0 tre opzioni ne aprono una parte senza il resto:
+
+| Opzione di ruolo | Apre |
+|---|---|
+| `showAppearanceSettings` | Le pagine di **Aspetto** |
+| `showConnectionsSettings` | Le pagine di **Connessioni**, tranne **Syslog**; repository, archivi di segreti e credenziali protette restano modificabili solo da un admin |
+| `showAuditLog` | Il **Registro di audit** |
+
+Vedi [Ruoli](../config/roles.html#role-options) per le opzioni di ruolo.
+
+---
+
+## Elenchi e pagine dei record
+
+Dalla 7.3.0 gli elenchi delle impostazioni e le pagine dei record condividono un unico layout, con i loro controlli su una riga a sé sotto il titolo:
+
+| Parte | Come funziona |
+|---|---|
+| Casella di ricerca | La prima di quella riga in ogni pagina delle impostazioni e pagina di record. Una parola restringe tutte le schede insieme: i campi, le righe o le linee corrispondenti compaiono sotto il nome della loro scheda |
+| Righe per pagina | Una tabella mostra tante righe quante ne entrano nello schermo finché non si sceglie un numero di righe per pagina: 10, 20, 50 o 100 |
+| Colonne | Ogni colonna con un nome si può ordinare, e una cella vuota mostra `–` |
+| Caselle di controllo | Le righe le hanno solo dove si può fare qualcosa con le righe spuntate, e il menu della riga (⋮) offre la stessa azione |
+| Menu della riga | Etichette brevi, come **Modifica** ed **Elimina**. Un elenco con una colonna **Abilitato** la mette per prima, e offre **Attiva** o **Disattiva** nel menu di ogni riga, a seconda dei casi |
+
+Gli elenchi con una colonna **Abilitato** sono i provider SSO, le directory LDAP, i runner, le pianificazioni, i canali di
+notifica, i server syslog, gli annunci, le etichette e le versioni del disclaimer.
+
+---
+
+## Sistema
+
+L'istanza stessa: le sue impostazioni, il suo stato di salute e i suoi backup.
+
+| Pagina | A cosa serve |
+|---|---|
+| **Generale** | Le variabili d'ambiente, in schede da Configurazione a Registrazione. Vedi [Variabili d'ambiente](../customization/). |
+| **Stato** | Lo stato di salute dell'istanza e dei sistemi da cui dipende, nelle schede Controlli e Informazioni. Vedi [Monitoraggio](../production/monitoring.html). |
+| **Backup** | Crea, ripristina ed elimina i backup del database, di config.yaml e dei moduli. Vedi [Backup](../production/backups.html). |
+
+![Impostazioni > Generale, la scheda Configurazione](../assets/screenshots/settings.jpg)
+
+### Backup
+
+L'elenco dei backup, notturni e manuali: **Aggiungi backup** ne crea uno subito, e il menu di una riga ha **Mostra backup**, **Ripristina** ed **Elimina**.
+
+![Impostazioni > Backup](../assets/screenshots/backups.jpg)
+
+### Ripristino
+
+**Ripristina** mostra cosa contiene il backup, poi lo ripristina; **Crea un nuovo backup prima del ripristino (consigliato)** è spuntato per impostazione predefinita.
+
+![Ripristino di un backup](../assets/screenshots/restore.jpg)
+
+---
+
+## Aspetto
+
+Come appare l'istanza per tutti, e i messaggi che mostra.
+
+| Pagina | A cosa serve |
+|---|---|
+| **Valori predefiniti** | Il tema, la lingua, la vista dei moduli, il fuso orario e il formato della data degli utenti che non ne hanno scelto nessuno. Vedi [Valori predefiniti](../appearance/defaults.html). |
+| **Nome** | Il nome nella scheda del browser e nella pagina di accesso. Vedi [Nome](../appearance/name.html). |
+| **Logo** | Il tuo logo nell'intestazione. Vedi [Logo](../appearance/logo.html). |
+| **Icona** | La tua icona nella scheda del browser. Vedi [Icona](../appearance/icon.html). |
+| **Collegamenti** | Il link al Designer, e i tuoi link e menu nell'intestazione. Vedi [Collegamenti](../appearance/links.html). |
+| **Etichette** | Etichette accanto al logo, come PRODUCTION ed EU. Vedi [Etichette](../appearance/labels.html). |
+| **Annunci** | Messaggi sotto l'intestazione, ognuno dal suo inizio alla sua fine. Vedi [Annunci](../announcements.html). |
+
+---
+
+## Accesso
+
+Chi può accedere, e cosa può fare una volta entrato.
+
+| Pagina | A cosa serve |
+|---|---|
+| **Disclaimer** | Termini che ogni utente accetta una volta, e chi ha accettato quale versione. Vedi [Disclaimer](../disclaimer.html). |
+| **Utenti** | Gli utenti locali, e quelli LDAP e single sign-on. Vedi [Utenti e gruppi](../users-and-groups.html). |
+| **Gruppi** | I gruppi locali, e quelli LDAP e single sign-on. Vedi [Utenti e gruppi](../users-and-groups/local-group.html). |
+| **Ruoli** | I ruoli di config.yaml: chi li ha e cosa consentono. Vedi [Ruoli](../config/roles.html). |
+| **LDAP** | Accesso con una directory LDAP o Active Directory. Vedi [LDAP](../authentication/ldap.html). |
+| **SSO** | Single sign-on con provider Entra ID o OpenID Connect. Vedi [Autenticazione](../authentication/). |
+
+![Accesso > LDAP, la directory principale](../assets/screenshots/ldap.jpg)
+
+---
+
+## Connessioni
+
+I sistemi che AnsibleForms raggiunge, e con cosa vi accede.
+
+| Pagina | A cosa serve |
+|---|---|
+| **Repository** | I repository git da cui provengono i moduli e i playbook. Vedi [Repository Git](../repositories/). |
+| **Credenziali** | Gli account e i segreti usati da moduli, playbook e connessioni. Vedi [Credenziali](../credentials.html). |
+| **Archivi di segreti** | HashiCorp Vault e CyberArk, da cui si possono leggere le credenziali. Vedi [Archivi di segreti](../secret-stores/). |
+| **Runner** | Dove girano i job: container RTE per i playbook, e AWX e simili per i template. Vedi [Runner](../runners.html). |
+| **SSH** | La coppia di chiavi con cui l'app si collega a git, e gli host conosciuti. Vedi [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Notifiche** | Server SMTP, Slack, Microsoft Teams, Telegram e webhook. Vedi [Canali di notifica](../notification-channels.html). |
+| **Assistente chat** | Il fornitore di IA dell'assistente chat. Vedi [Assistente chat](../chat/). |
+| **MCP** | Il server MCP per gli agenti di IA. Vedi [MCP](../mcp/). |
+| **Syslog** | Server syslog che ricevono il log del server, il registro di audit, o entrambi. Vedi [Syslog](../production/logs.html#syslog). |
+
+![Connessioni > Credenziali, la scheda Connessione di una credenziale](../assets/screenshots/credentials.jpg)
+
+---
+
+## Log
+
+Cosa è successo sull'istanza.
+
+| Pagina | A cosa serve |
+|---|---|
+| **Registro di audit** | Chi ha cambiato cosa, e se era consentito, filtrato per utente, azione ed esito. Vedi [Traccia di audit](../production/logs.html#audit-trail). |
+| **Log del server** | Il log del server stesso, per la risoluzione dei problemi. Vedi [Log](../production/logs.html). |
+
+### Log del server
+
+Le ultime righe del log, le più recenti in fondo, seguite man mano che vengono scritte. La casella di ricerca le filtra (un'espressione
+regolare), **Cancella** svuota la vista, non il log, e **Scarica** salva l'intero log.
+
+![Log > Log del server](../assets/screenshots/logs.jpg)
+
+---
+
+## Documentazione API
+
+**Documentazione API** nel menu di aiuto (il punto interrogativo nell'intestazione) porta alla Swagger UI dell'API REST su `/api/v2/docs`.
+Vedi [API](../api/).
+
+![Interfaccia Swagger](../assets/screenshots/swagger.jpg)
diff --git a/i18n/it/_introduction/gui/designer-and-git.md b/i18n/it/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..8c6326c
--- /dev/null
+++ b/i18n/it/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Designer e git
+parent: Tour dell'interfaccia
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Designer e git
+{: .no_toc }
+
+Modificare i moduli e tenerli in git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Designer integrato
+
+Modifica moduli, categorie, costanti, file di variabili, playbook, inventari e workflow, ognuno come YAML, con i campi (Visual)
+e come anteprima. Le pagine del [Designer](../designer/) descrivono ogni sezione.
+
+![Designer integrato](../assets/screenshots/designer.jpg)
+
+---
+
+## Repository Git
+
+Integra i repository Git per mettere i tuoi moduli e playbook sotto controllo di versione.
+
+![Repository Git](../assets/screenshots/git.jpg)
+
+---
+
+## Editor dei repository Git
+
+Modifica e configura le impostazioni di integrazione dei repository Git.
+
+![Editor dei repository Git](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/it/_introduction/gui/forms-and-jobs.md b/i18n/it/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..2b8cdde
--- /dev/null
+++ b/i18n/it/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Moduli e job
+parent: Tour dell'interfaccia
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Moduli e job
+{: .no_toc }
+
+L'accesso, la dashboard, la compilazione di un modulo e il monitoraggio dei suoi job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Accesso
+
+La pagina di autenticazione degli utenti, con supporto per l'autenticazione locale, LDAP, Entra ID e OIDC.
+
+![Accesso](../assets/screenshots/login.jpg)
+
+---
+
+## La dashboard
+
+La dashboard principale mostra tutti i moduli disponibili organizzati per categoria.
+
+![Dashboard](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Un modulo
+
+Un esempio di modulo con origini dati esterne e campi dinamici.
+
+![Esempio di modulo](../assets/screenshots/form.jpg)
+
+---
+
+## Anteprima JSON del modulo
+
+Visualizza in anteprima il payload JSON e le variabili extra passate ad Ansible prima di eseguire il job.
+
+![Anteprima JSON del modulo](../assets/screenshots/form-json.jpg)
+
+---
+
+## Job in esecuzione
+
+Esecuzione in tempo reale di un playbook Ansible con output dal vivo.
+
+![Job in esecuzione](../assets/screenshots/run.jpg)
+
+---
+
+## Output del job
+
+L'output completo di un playbook Ansible eseguito.
+
+![Output del job](../assets/screenshots/job-output.jpg)
+
+---
+
+## Log dei job
+
+Tutti i job con il loro stato e i loro orari, filtrati per stato dal menu a sinistra.
+
+![Log dei job](../assets/screenshots/job-log.jpg)
+
+---
+
+## Multistep
+
+Un job multistep, con l'output di ogni passo sotto il job principale. I moduli multistep sono deprecati dalla 7: un
+[workflow](../workflows/) concatena invece playbook, template e approvazioni.
+
+![Modulo multistep](../assets/screenshots/multistep.jpg)
+
+---
+
+## Pianificazioni
+
+Pianifica l'esecuzione dei moduli a orari o intervalli precisi. Gli [esempi di cron](../faq.html#which-cron-expressions-can-i-use) elencano espressioni
+comuni, e spiegano in quale fuso orario gira una pianificazione.
+
+![Pianificazioni](../assets/screenshots/schedules.jpg)
diff --git a/i18n/it/_introduction/gui/index.md b/i18n/it/_introduction/gui/index.md
new file mode 100644
index 0000000..7bd2b29
--- /dev/null
+++ b/i18n/it/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Tour dell'interfaccia
+nav_order: 3
+has_children: true
+has_toc: false
+description: Screenshot e panoramica dell'interfaccia grafica
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Tour dell'interfaccia
+{: .no_toc }
+
+Un tour visivo dell'interfaccia web di AnsibleForms, dalla dashboard alle funzioni di amministrazione avanzate.
+{: .fs-6 .fw-300 }
+
+---
+
+Per ogni utente e amministratore: le schermate dell'interfaccia web, raggruppate in base a ciò che ci fai.
+
+---
+
+## In questa sezione
+
+Ogni gruppo di schermate ha la sua pagina:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Moduli e job](forms-and-jobs.html) | L'accesso, la dashboard, la compilazione di un modulo e il monitoraggio dei suoi job |
+| [Designer e git](designer-and-git.html) | Modificare i moduli e tenerli in git |
+| [Amministrazione](administration.html) | Il menu Impostazioni: il sistema, il suo aspetto, l'accesso, le connessioni e i log |
+| [Impostazioni personali](personal-settings.html) | Il tuo profilo e il tema scuro |
diff --git a/i18n/it/_introduction/gui/personal-settings.md b/i18n/it/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..0056cc5
--- /dev/null
+++ b/i18n/it/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Impostazioni personali
+parent: Tour dell'interfaccia
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Impostazioni personali
+{: .no_toc }
+
+Il tuo profilo e il tema scuro
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Profilo utente
+
+Il tuo account, preferenze, password, permessi e token API.
+
+Vedi [Il tuo profilo](../profile).
+
+![Profilo utente](../assets/screenshots/profile.jpg)
+
+---
+
+## Modalità scura
+
+AnsibleForms supporta la modalità scura per affaticare meno la vista.
+
+![Modalità scura](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/it/_introduction/how-it-works.md b/i18n/it/_introduction/how-it-works.md
new file mode 100644
index 0000000..13a52cc
--- /dev/null
+++ b/i18n/it/_introduction/how-it-works.md
@@ -0,0 +1,209 @@
+---
+layout: default
+title: Come funziona
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Come funziona
+{: .no_toc }
+
+Le parti di un'installazione, cosa succede a un avvio, e dove vengono conservati i dati
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Architettura
+
+AnsibleForms è un server Node.js che serve l'applicazione web e un'API REST, appoggiandosi a un database MySQL. Legge i moduli
+da file YAML e non esegue nulla da sé: passa ogni job a un [runner](runners.html). Un playbook va a uno dei tuoi container RTE
+(ambiente di runtime), che esegue `ansible-playbook`, e un template o un job va ad AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Architettura di AnsibleForms</title>
+<desc id="afd-desc">Il browser e un client MCP facoltativo comunicano con il server di AnsibleForms. Il server salva i suoi dati in MySQL e nella cartella persistente, e si collega a origini dati, archivi di segreti, repository git, provider di accesso, canali di notifica, server syslog e un fornitore di modelli facoltativo. I suoi runner passano ogni playbook a uno di uno o più container RTE, ciascuno tramite un WebSocket, che eseguono ansible-playbook e rimandano l'output al server, e ogni template o job ad AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="99" text-anchor="middle">Browser</text>
+<text class="afd-s" x="105" y="118" text-anchor="middle">moduli, designer, job, chat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">Client MCP</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">facoltativo</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">Server di AnsibleForms</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">App web e API REST</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Moduli, espressioni</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflow, pianificazioni</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">Server MCP (facoltativo)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runner</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">passano ogni job al suo runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Origini dati</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">database, API REST, file</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Archivi di segreti</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Repository git</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">moduli, playbook, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Provider di accesso</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Canali di notifica</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">mail, Slack, Teams, webhook</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Server syslog</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">il log, la traccia di audit</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Fornitore di modelli</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">facoltativo, assistente chat</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Cartella persistente</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, moduli, playbook</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">job, utenti,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">credenziali</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">Container RTE</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">eseguono ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbook,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">template, job</text>
+</svg>
+</div>
+I componenti del diagramma hanno ognuno un ruolo proprio:
+
+| Componente | Ruolo |
+|---|---|
+| **Browser** | L'applicazione web Vue: i moduli, il [Designer](gui/designer-and-git.html), la cronologia dei job e le impostazioni |
+| **Server di AnsibleForms** | Valuta i moduli, registra i job, esegue i workflow e le pianificazioni, passa ogni job al suo runner e lo segue, e serve l'[API REST](api/) |
+| **Runner** | Dove girano i job, aggiunti in **Connessioni > Runner**: un modulo ne nomina uno con `runner: <name>`, o usa il runner predefinito del suo tipo (vedi [Runner](runners.html)) |
+| **Container RTE** | Uno o più container dell'ambiente di runtime, lo stesso server avviato con `AF_ROLE=rte`: ognuno esegue `ansible-playbook` per i [moduli ansible](forms/ansible.html), con le librerie python e le collection della sua immagine, e rimanda l'output e lo stato finale al server tramite un WebSocket, senza credenziali del database (vedi [Come gira l'RTE](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runner per template e job: i [moduli AWX](forms/awx.html) avviano un job template o un workflow template, i moduli [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) e [Jenkins](forms/jenkins.html) avviano uno dei loro job, e il server ne segue l'output |
+| **MySQL / MariaDB** | Contiene i job e il loro output, gli utenti, le credenziali e le connessioni; solo il server lo legge e lo scrive |
+| **Cartella persistente** | Contiene `config.yaml`, i file dei moduli, i playbook, i log e i backup |
+| **Origini dati** | Riempiono i campi: [query su database](formfields/enum.html), [API REST](expressions/rest-apis.html), file e [altre funzioni](expressions/remote.html) |
+| **Archivi di segreti** | Forniscono l'utente e la password di una credenziale al momento dell'uso, vedi [Archivi di segreti](secret-stores/) |
+| **Repository git** | Tengono i moduli, i playbook e `config.yaml` sotto controllo di versione |
+| **Provider di accesso** | Fanno accedere gli utenti: [LDAP, Entra ID e OIDC](authentication/), accanto agli utenti locali |
+| **Canali di notifica** | Portano le [notifiche](forms/notifications.html) e le richieste di approvazione: [mail, Slack, Microsoft Teams, Telegram o un webhook](notification-channels.html) |
+| **Server syslog** | Ricevono il log e la traccia di audit man mano che vengono scritti, vedi [Syslog](production/logs.html#syslog) |
+| **Client MCP, chat** | Facoltativi, entrambi disattivati per impostazione predefinita: il [server MCP](mcp/) e l'[assistente chat](chat/), che ha bisogno di un fornitore di modelli |
+
+Per impostazione predefinita un solo container esegue insieme il server, l'app web e il lavoro in background, accanto a un RTE. Per più nodi dell'app dietro un
+load balancer, un worker che esegue il lavoro in background, e più RTE, vedi [Scalabilità](production/scaling.html).
+
+### Costruito con
+
+Il server e l'interfaccia web sono costruiti su questi componenti:
+
+| Parte | Tecnologia |
+|---|---|
+| **Server** | Node.js ed Express |
+| **Database** | MySQL o MariaDB |
+| **Interfaccia web** | Vue 3, con Bootstrap 5 e Font Awesome |
+
+---
+
+## Cosa succede quando avvii un modulo
+
+Un avvio passa per gli stessi passi sia che arrivi dal browser sia dall'[API REST](api/jobs.html):
+
+1. **Caricamento** : il server invia solo i moduli consentiti dai [ruoli](config/roles.html) dell'utente, e valuta le espressioni lato server
+2. **Invio** : il browser trasforma i valori dei campi in extravars e le invia a `POST /api/v2/job`
+3. **Controllo** : il server ricarica il modulo per i ruoli dell'utente e, con la [validazione all'avvio](launch-validation/) attiva, controlla i valori
+4. **Registrazione** : il job viene salvato con stato `running`, e il suo id viene aggiunto alle extravars come `__jobid__`
+5. **Approvazione** : un modulo con un punto di [`approval`](forms/approval.html) aspetta finché un approvatore non accetta il job
+6. **Credenziali** : per un playbook, l'app (mai l'RTE) legge le credenziali del modulo dal database o da un [archivio di segreti](secret-stores/)
+7. **Esecuzione** : il job va al suo runner, quello che il modulo nomina con `runner:` o il predefinito del suo tipo. Per un playbook, l'app invia il job al suo
+   RTE tramite il WebSocket dell'RTE, con le credenziali sigillate per esso, e l'RTE esegue `ansible-playbook` (vedi [Come gira l'RTE](rte/#how-the-rte-runs)),
+   e AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins esegue un template o un job. Un [workflow](workflows/) esegue i suoi nodi, ognuno come
+   job a sé sul proprio runner
+8. **Monitoraggio** : il server salva l'output nel database man mano che arriva, inviato dall'RTE tramite il suo socket per un playbook, o letto dagli
+   altri runner. La pagina del modulo rilegge il job ogni due secondi, e la pagina Job lo segue in tempo reale man mano che il server
+   annuncia ogni cambiamento
+9. **Fine** : il job riceve il suo stato finale, e le sue [`notifications`](forms/notifications.html) partono via mail e verso i suoi
+   [canali di notifica](notification-channels.html) quando il modulo le richiede
+
+---
+
+## Dove vengono conservate le cose
+
+AnsibleForms conserva il suo stato in due posti: il database MySQL e la cartella persistente. Fai il backup di entrambi.
+
+### Nel database
+{: .no_toc }
+
+Il database, `AnsibleForms`, viene creato al primo avvio (a meno che `ALLOW_SCHEMA_CREATION` non sia `0`) e contiene:
+
+* i job, le loro extravars e il loro output, le pianificazioni e i job salvati
+* gli utenti locali, i gruppi e i token API
+* le credenziali, cifrate con `ENCRYPTION_SECRET`, e le connessioni agli archivi di segreti
+* i runner, i canali di notifica (mail compresa), i server syslog, e le impostazioni di LDAP, SSO, repository e assistente chat
+* il registro di audit
+
+### Nella cartella persistente
+{: .no_toc }
+
+È `/app/dist/persistent` nell'immagine e `server/persistent` dai sorgenti; ogni percorso ha la sua [variabile](customization/paths.html):
+
+| Percorso predefinito | Variabile | Contenuto |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | Le categorie, i ruoli e le costanti |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | I file dei moduli, `.yaml` o `.yml`, in sottocartelle se vuoi |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | I playbook dei moduli `ansible`, e la loro directory di lavoro |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | I cloni dei repository git |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | Le copie che il Designer fa prima di salvare |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | I backup del database |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | I file caricati tramite i campi `file` |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` e `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | Il certificato e la chiave, quando `HTTPS` è `1` |
+| `.env` | | Le variabili d'ambiente salvate dalle pagine delle impostazioni (a meno che `ALLOW_ENV_EDIT` non sia `0`) |
+
+La chiave SSH generata si trova in [`HOME_PATH`](customization/paths.html#env_HOME_PATH), per impostazione predefinita fuori dalla cartella persistente.
diff --git a/i18n/it/_introduction/prerequisites.md b/i18n/it/_introduction/prerequisites.md
new file mode 100644
index 0000000..5c5dfd5
--- /dev/null
+++ b/i18n/it/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Prerequisiti
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Prerequisiti
+{: .no_toc }
+
+Cosa ti serve prima di installare AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Runtime
+
+AnsibleForms gira come container, come servizi systemd sul server stesso o, per chi lo compila da sé, come applicazione Node.js:
+
+| Installazione | Ti serve |
+|---|---|
+| [Installer](installation/installer.html) | Linux su amd64 o arm64, `curl` o `wget` e `sha256sum`, e i requisiti del motore su cui installa (sotto) |
+| [Nativa](installation/native.html) | Root, systemd e un Linux supportato (Ubuntu, Debian, RHEL e le sue ricompilazioni, SUSE); l'installer installa il resto |
+| [Docker](installation/docker.html) | Docker o Podman, e un tuo server MySQL |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose o podman-compose; il progetto avvia anche MySQL |
+| [Kubernetes](installation/kubernetes.html) | Un cluster, Helm 3 e una StorageClass (o dei PersistentVolume creati in anticipo) |
+| [Dai sorgenti](installation/from-source.html) | Node.js 26 (almeno la 24) con npm, Git, e Ansible per il processo RTE che esegue i playbook |
+
+L'immagine dell'app, `ghcr.io/ansibleforms/ansibleforms`, contiene Node.js e gli strumenti che il server chiama (git, ssh, il client mariadb e
+ytt), ma né Python né Ansible. I playbook girano su un RTE (ambiente di runtime), un secondo container da
+`ghcr.io/ansibleforms/ansibleforms-rte-full`, o da un'immagine che costruisci su `ansibleforms-rte-core` (vedi [Scalabilità](rte/)).
+I moduli che avviano solo template su AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins non hanno bisogno di un RTE.
+
+---
+
+## Database
+
+AnsibleForms salva i suoi job, utenti, credenziali e connessioni in MySQL 8 o successivo, o in MariaDB.
+
+Al primo avvio crea da sé lo schema `AnsibleForms`. Dagli un utente del database tutto suo, con diritti solo su quello schema,
+non root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+È tutto ciò che gli serve: crea e aggiorna lo schema, fa i suoi backup e, con più worker, termina la sessione di uno morto.
+La pagina **Stato** e il log avvisano quando l'utente ha diritti su tutti i database. I nodi dell'app e i worker si connettono con questo
+utente. Un RTE in modalità socket (in uscita o in entrata, vedi [Modalità](rte/modes.html)) non contiene credenziali del database: solo uno in modalità
+database, deprecata dalla 7.3.0, si connette anch'esso. Per creare lo schema tu stesso, imposta [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) su `0`.
+Il progetto Docker Compose e il chart Helm (che usa `mysql:8.4`) avviano un database per te.
+
+---
+
+## Dimensionamento
+
+Non ci sono requisiti misurati: il carico dipende soprattutto da quanti job girano nello stesso momento e da quanto output scrivono.
+Le risorse predefinite del chart Helm sono un punto di partenza ragionevole per un piccolo team:
+
+| Componente | Richieste | Limiti | Volume |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB di memoria | 4 CPU, 4 GiB di memoria | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB di memoria | 2 CPU, 2 GiB di memoria | 10 GiB |
+
+Il container dell'app non esegue nessun playbook. Ogni playbook è un processo `ansible-playbook`, con i suoi fork, su un RTE: dimensiona CPU e
+memoria di ogni RTE per i playbook che esegue contemporaneamente, al massimo [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (`10` per impostazione predefinita), ed esegui più
+RTE per eseguirne di più. I job che girano su AWX, AAP, Ascender o sugli altri runner di template costano poco ad AnsibleForms.
+
+Per impostazione predefinita l'output dei job resta nel database per sempre. Imposta [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+su un'istanza molto usata per evitare che il database cresca senza limiti.
+
+---
+
+## Rete
+
+L'app e ogni RTE ascoltano su una porta propria, e aprono connessioni in uscita verso i sistemi che usano i tuoi moduli e le tue impostazioni.
+
+### In ingresso
+{: .no_toc }
+
+Il server ascolta sulla porta `8000` ([`PORT`](customization/server.html#env_PORT)), in HTTP o, con
+[`HTTPS`](customization/server.html#env_HTTPS) impostato su `1`, in HTTPS. Il progetto Docker Compose la pubblica sulla porta 443,
+e il chart Helm la espone tramite un servizio o un ingress. Anche un RTE ascolta sulla sua `PORT`, ma solo l'app lo chiama:
+tienilo fuori dalla rete pubblica. Un RTE in uscita non ha bisogno di nessuna porta in ingresso: contatta l'app sulla porta dell'app.
+
+### In uscita
+{: .no_toc }
+
+Apri le connessioni da AnsibleForms verso i sistemi che usi:
+
+| Destinazione | Usata per |
+|---|---|
+| MySQL / MariaDB | Il database di AnsibleForms (`DB_HOST`, `DB_PORT`, predefinita `3306`) |
+| L'RTE | Contattare un RTE in entrata all'indirizzo del suo runner tramite un WebSocket, o chiamarne uno in modalità database al suo [`RTE_URL`](customization/server.html#env_RTE_URL), che poi si connette lui stesso a MySQL; un RTE in uscita invece contatta l'app (vedi [Modalità](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Avviare e seguire template e job sui [runner](runners.html), tramite la loro API HTTP(S) |
+| Gli host gestiti | I playbook vi si collegano dall'RTE, per esempio via SSH o WinRM |
+| LDAP, Entra ID, OIDC | L'accesso con account di directory o single sign-on |
+| Server Git | Clonare e aggiornare i repository, via HTTPS o SSH |
+| API REST e database | Le origini dati delle espressioni e delle query nei tuoi moduli |
+| HashiCorp Vault, CyberArk | Leggere credenziali da un [archivio di segreti](secret-stores/) |
+| Server di posta, Slack, Teams, Telegram, webhook | Notifiche dei job e richieste di approvazione, tramite i [canali di notifica](notification-channels.html) |
+| Fornitore di modelli | L'[assistente chat](chat/), solo quando è attivo |
+
+Per limitare quali host possono chiamare le funzioni REST delle espressioni, vedi
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) e
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Browser
+
+L'applicazione web è fatta per i browser attuali: Chrome o Edge 111, Firefox 114, Safari 16.4 o più recenti.
+I browser più vecchi non sono supportati.
+
+---
+
+## Scalabilità
+
+Per impostazione predefinita un solo container di AnsibleForms esegue insieme l'app web e il lavoro in background, accanto a un RTE.
+
+Per servire più utenti, esegui più nodi dell'app dietro un load balancer (`AF_ROLE=app`) accanto a un worker (`AF_ROLE=worker`), che esegue le
+pianificazioni, i backup e l'altro lavoro in background; lavora un solo worker alla volta, e un secondo aspetta di subentrare. Condividono
+il database, la cartella persistente, `ACCESS_TOKEN_SECRET` e `ENCRYPTION_SECRET`. Vedi [Scalabilità](production/scaling.html). Esegui più
+RTE per eseguire più playbook contemporaneamente: vedi [Più RTE](rte/several.html).
diff --git a/i18n/it/_introduction/what-is-ansibleforms.md b/i18n/it/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..762ee77
--- /dev/null
+++ b/i18n/it/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Cos'è AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Cos'è AnsibleForms
+{: .no_toc }
+
+Moduli self-service davanti ad Ansible e AWX, e quando ti servono
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Cosa fa
+
+AnsibleForms mette un modulo web davanti a un playbook, a un workflow, o a un template o un job su AWX, AAP, Ascender, Semaphore, Rundeck
+o Jenkins, così le persone possono eseguire automazioni senza la riga di comando.
+
+Un modulo raccoglie l'input, lo controlla, lo trasforma in extravars e avvia il job. I dati di un modulo possono provenire da database,
+API REST, file e altri campi, e ogni avvio viene registrato nella cronologia dei job con il suo output.
+
+---
+
+## Usi tipici
+
+I team usano AnsibleForms per affidare l'automazione di routine alle persone che la richiedono:
+
+* **Richieste self-service** : una macchina virtuale, un volume di storage, una condivisione o un account utente, compilati da chi li richiede
+* **Operazioni protette** : azioni con punti di approvazione, così una seconda persona dà il via libera prima che il job parta
+* **Scelte guidate dai dati** : menu a tendina riempiti da una CMDB, un database o un'API REST, a cascata da un campo all'altro
+* **Job ricorrenti** : moduli eseguiti più tardi o secondo una pianificazione cron, ogni volta con lo stesso input validato
+* **Automazione per strumenti e agenti** : l'API REST, il server MCP e l'assistente chat avviano gli stessi moduli
+
+---
+
+## AnsibleForms o i survey di AWX?
+
+AWX, AAP e Ascender hanno i loro survey. Quale sia adatto dipende da ciò di cui hanno bisogno le persone che avviano i job.
+
+Un **survey** basta quando:
+
+* le domande sono fisse: testo, numeri, password e scelte da un elenco statico
+* gli utenti lavorano già in AWX, AAP o Ascender, e i suoi permessi vanno bene per loro
+* non vuoi eseguire e mantenere un'altra applicazione e un altro database
+
+**AnsibleForms** aiuta quando:
+
+* le scelte vengono da altrove: un database, un'API REST, un file, o un altro campo (menu a tendina a cascata)
+* l'input ha bisogno di validazione, struttura (liste, oggetti annidati) o valori calcolati prima di arrivare al playbook
+* i job hanno bisogno di punti di approvazione, pianificazione, o di un workflow che concateni playbook, template e approvazioni da un solo modulo
+* gli utenti non dovrebbero vedere affatto AWX, o esegui anche playbook senza AWX
+
+AnsibleForms avvia template di AWX, AAP e Ascender, quindi i due lavorano insieme: i moduli raccolgono e modellano l'input, e
+AWX continua a eseguire i job.
+
+---
+
+## Dove andare dopo
+
+Il resto di questa sezione spiega le parti in gioco prima dell'installazione:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Come funziona](how-it-works.html) | L'architettura, i passi di un avvio, e dove vengono conservati i dati |
+| [Tour dell'interfaccia](gui/) | Screenshot di ogni schermata, dall'accesso alle pagine di amministrazione |
+| [Concetti](concepts.html) | I termini usati in questa documentazione |
+| [Prerequisiti](prerequisites.html) | Cosa ti serve prima di installare |
diff --git a/i18n/it/_reference/faq.md b/i18n/it/_reference/faq.md
new file mode 100644
index 0000000..582f78b
--- /dev/null
+++ b/i18n/it/_reference/faq.md
@@ -0,0 +1,1278 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Domande frequenti
+{: .no_toc }
+
+Domande e risposte comuni su AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Primi passi
+
+### Topologia della distribuzione: un container o più nodi
+
+Per impostazione predefinita, un container di AnsibleForms esegue l'applicazione web e il lavoro in background in un unico processo, accanto a un container RTE che
+esegue i playbook. Eseguilo con una restart policy (per esempio `restart: unless-stopped` in Docker), e fai il backup sia del database sia
+del volume persistente.
+
+Per eseguire più repliche dietro un load balancer, dividi il processo con `AF_ROLE`:
+
+- i nodi `app` servono l'interfaccia web e l'API: eseguine quanti vuoi, ognuno con lo stesso `ACCESS_TOKEN_SECRET`
+- un `worker` esegue il lavoro in background: lo schema e i suoi aggiornamenti, il config seed, le pianificazioni, il backup notturno, le sincronizzazioni
+  dei repository e le pulizie. Lavora un solo worker alla volta, tenendo un lock sul database; un secondo aspetta e subentra quando il primo si ferma
+- i container `rte` eseguono i playbook: eseguine di più per eseguire più playbook contemporaneamente
+
+I nodi dell'app e il worker condividono il database, il volume persistente e `ENCRYPTION_SECRET`. Un RTE in modalità socket (in uscita o
+in entrata, vedi [Modalità](rte/modes.html)) non ha bisogno né del database né di `ENCRYPTION_SECRET`. L'assistente chat ha bisogno di sessioni sticky, e
+ogni nodo tiene il proprio log. Vedi [Scalabilità](production/scaling.html) e la configurazione
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Gestione dei moduli su più repository
+
+I moduli di ogni repository Git con **Usare per moduli?** attivo vengono uniti automaticamente; in caso di nomi di modulo duplicati vince il primo
+e viene registrato un avviso. Tieni `config.yaml` in un solo repository. Vedi [Repository Git](repositories/).
+
+### Sui repository
+
+AnsibleForms clona e aggiorna i repository Git nel percorso dei repository (`REPO_PATH`), gestiti in **Impostazioni > Repository**.
+Gli interruttori su ogni repository stabiliscono cosa contiene: configurazione, moduli, playbook o file di variabili. Vedi [Repository Git](repositories/).
+
+### Validazione in VS Code dei file dei moduli
+
+Aggiungi un'intestazione di schema ai file YAML dei tuoi moduli per avere validazione in tempo reale e completamento automatico in VS Code.
+
+Installa l'[estensione YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) e aggiungi questo commento come **prima riga** di qualsiasi file di modulo:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Funziona sia per i file con un solo modulo (un dizionario YAML) sia per quelli con più moduli (una lista YAML):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code evidenzia le proprietà sconosciute, i campi obbligatori mancanti e i tipi sbagliati mentre scrivi.
+
+---
+
+## Gestione dei job
+
+### Rilanciare un job con i dati precompilati
+
+Il pulsante di rilancio apre il modulo precompilato con i valori del job precedente; i campi password non vengono mai salvati.
+Richiede l'opzione di ruolo `allowJobRelaunch`, e un modulo può disattivarlo con `allowRelaunch: false`. Vedi [Rilanciare un job](jobs/actions.html#relaunch-a-job).
+
+### File di log del job
+
+Segui l'avanzamento tramite un file di log specifico del job (v6.1.2).
+
+AnsibleForms può mostrare un **file di log specifico del job** accanto all'output di Ansible. Questo ti permette di seguire l'avanzamento di moduli personalizzati di lunga durata che altrimenti non darebbero nessun riscontro visibile durante l'esecuzione.
+
+{: .note }
+> Questa funzione funziona solo per i playbook eseguiti su un RTE. I template e i job su AWX, AAP, Ascender, Semaphore, Rundeck o
+> Jenkins non hanno file di log.
+
+**Come funziona:**
+- Durante l'esecuzione di un job, l'RTE tiene d'occhio un file di log in un percorso noto dentro la cartella del playbook
+- Ogni due secondi, quando il file è cambiato, l'RTE ne copia il contenuto nel job, e un'ultima volta quando il playbook termina
+- Il file di log viene mostrato in una sezione **Log file** dell'output del job, numerato come le righe dell'output : il timestamp e il livello di una riga di log (ERROR, WARNING, INFO, DEBUG) vengono letti e colorati come quelli dell'output, e i colori ANSI sono supportati
+
+**Convenzione per il percorso del file di log:**
+
+Il file di log deve essere scritto in questo percorso:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms passa `__jobid__` automaticamente**, quindi puoi comporre il percorso nel tuo playbook senza nessuna configurazione aggiuntiva:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Passa questa variabile a qualsiasi ruolo o modulo personalizzato che debba scrivere l'avanzamento nel file.
+
+**Responsabilità di chi sviluppa il playbook / il modulo:**
+- **Creare** il file di log (e la sua directory `.joblogs/`) all'inizio dell'operazione
+- **Scrivere** messaggi di avanzamento significativi man mano che l'operazione procede
+
+L'RTE elimina il file quando il playbook termina e l'ultimo contenuto è stato salvato nel job.
+
+**La codifica a colori ANSI è supportata.**  
+I codici di escape ANSI standard (per esempio `\033[92m` per il verde e `\033[91m` per il rosso) nei tuoi messaggi di log vengono resi come colori nell'interfaccia, così gli stati di successo, avviso ed errore si distinguono a colpo d'occhio.
+
+**Caso d'uso tipico:**  
+Un modulo Ansible personalizzato in Python che esegue una lunga sequenza di chiamate API o operazioni sui dati (per esempio un workflow di DR con SnapMirror) può aggiungere una riga per ogni passo al file di log. Un operatore che guarda il job in AnsibleForms vede allora l'avanzamento in tempo reale nella sezione Log file, mentre la pagina del job segue il job.
+
+### Jobid
+
+Passa l'ID del job corrente.
+
+AnsibleForms invia automaticamente l'ID del job corrente nelle extravars come `__jobid__`; non serve nessuna configurazione.
+
+### Informazioni sull'utente
+
+Passa l'utente corrente.
+
+AnsibleForms invia automaticamente le informazioni sull'utente nelle extravars come `ansibleforms_user`; non serve nessuna configurazione.
+
+Puoi scegliere quanta parte inviarne. `EXTRAVARS_USER_FIELDS` accetta un elenco separato da virgole di chiavi di primo livello
+(`username,email,type`), o `none` per non inviare nulla; un modulo può sovrascriverlo con la propria proprietà `userExtravars`.
+Il valore predefinito è l'intero oggetto, come prima. Il `__user__` lato modulo descritto sotto viene dal token di accesso e non ne è mai influenzato.
+
+### Informazioni sull'utente nel modulo
+
+Accedi alle informazioni sull'utente corrente nel modulo (v4.0.2).
+
+Il campo `__user__` viene aggiunto automaticamente al modulo e si può usare nelle espressioni:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Campi del modulo
+
+### Menu a tendina a cascata
+
+Crea menu a tendina a cascata.
+
+I campi `enum` (menu a tendina) possono contenere placeholder nella loro proprietà `query` o `expression`, nel formato `$(another_field)` o `$(another_field[0].name)`.  
+Non appena il campo referenziato cambia, il campo che lo referenzia viene rivalutato, il che produce menu a tendina dinamici e a cascata.  
+L'applicazione web client rivaluta i campi ogni 100 ms; con i processori attuali e il motore Chromium, l'esperienza risulta fluida.
+
+{: .note }
+> Un riferimento a un altro campo enum restituisce i valori selezionati, **non** l'intero elenco del menu a tendina. Usa la proprietà `placeholderColumn` o la notazione a punti come `$(city.name)`.  
+> **Novità della v4.0.20**: impostare placeholderColumn su "*" restituisce l'intero record invece di una singola colonna.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Placeholder dei campi
+
+Fai riferimento al valore di un altro campo.
+
+I placeholder sono riferimenti ad altri campi del modulo.  
+Un placeholder ha sempre il formato `$(reference)`, e sia le espressioni sia le query possono contenere placeholder.  
+Un placeholder che punta a un campo semplice (text, number, password) contiene il valore di quel campo.  
+Un placeholder che punta a un campo enum basato su oggetti deve usare o la proprietà `placeholderColumn` o la notazione a punti come `$(city.name)`.  
+Un placeholder che punta a un campo expression restituisce l'intero oggetto, oppure puoi usare un riferimento avanzato, simile a JavaScript, come `$(myarray[0].name)`.
+
+{: .important }
+> Il placeholder viene sostituito **prima** che l'espressione venga valutata. Se ti aspetti che il risultato sia una stringa, devi racchiuderlo tra virgolette.  
+> **Novità della v4.0.20**: impostare placeholderColumn su "*" restituisce l'intero record invece di una singola colonna.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Nascondere un campo
+
+Nascondi un campo.
+
+Nascondi un campo con la proprietà di campo `hide`, o mostralo e nascondilo dinamicamente con le proprietà di campo `dependencies` e `dependencyFn`.
+
+### Raggruppare i campi
+
+Raggruppa i campi in un blocco.
+
+Usa la proprietà di campo `group`. I campi con lo stesso nome di gruppo vengono raggruppati in un blocco.
+
+### Validazione dei campi
+
+Valida un campo.
+
+Usa le proprietà di validazione dei campi, come `regex`, `minValue` e `notIn`.
+
+### Valore predefinito su un enum
+
+Valore predefinito di un enum.
+
+La proprietà di campo `default` imposta un valore predefinito, e sui campi `enum` puoi usare valori come `__auto__` per selezionare automaticamente il primo elemento.
+
+Per un valore predefinito dinamico basato su un'espressione, sposta l'elemento predefinito in cima all'elenco, come nell'esempio seguente.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Valore predefinito da un'espressione
+
+Valore predefinito da un'espressione.
+
+Per i campi text, number o date, la proprietà `default` imposta un valore predefinito statico.
+
+Per rendere il valore predefinito dinamico, basato su un'espressione, usa una di due proprietà:
+* `editable`: usa la proprietà editable per rendere modificabile un campo expression
+* `evalDefault`: usa la proprietà evalDefault per valutare il valore predefinito come un'espressione
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Wizard e workflow
+
+### Qual è la differenza tra un wizard e un workflow?
+
+Un **wizard** e un **workflow** sono entrambi divisi in passi, ma operano su livelli diversi e si possono combinare.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Livello** | Esecuzione | Modulo / interfaccia |
+| **Cosa divide** | Il job in nodi che girano uno dopo l'altro, o in parallelo | L'input di un modulo in più pagine |
+| **Risultato** | 1 job workflow, con un job per nodo (ognuno con il proprio playbook o template) | 1 job eseguito alla fine |
+| **`type` del modulo** | Deve essere `workflow` | Funziona con ogni tipo di modulo tranne `subform` |
+| **Definito da** | Un [file di workflow](workflows/file.html) del designer (`workflow:`) | Un elenco di riferimenti a [subform](forms/subform.html) (`wizard:`) |
+| **Usalo quando** | "Fai A, poi B, poi C come job separati" | "Il mio modulo ha troppi campi per una sola pagina" |
+
+**Il punto chiave:** un workflow riguarda *cosa viene eseguito e in quale ordine*; `wizard` riguarda *come l'utente compila il modulo*.
+
+{: .note }
+> Il tipo di modulo `multistep`, con i suoi `steps`, si occupava della parte di esecuzione prima della 7. È deprecato dalla 7 e rimosso nella
+> 8: un workflow fa tutto ciò che fa un multistep, vedi [Moduli multistep](forms/multistep.html).
+
+#### Solo workflow
+{: .no_toc }
+
+Un modulo `type: workflow` esegue uno dei workflow del designer. L'utente compila un'unica pagina di campi e preme Invia,
+e il workflow esegue i suoi nodi, ognuno con i valori del modulo come extra vars:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Solo wizard
+{: .no_toc }
+
+Un blocco `wizard:` su un modulo distribuisce la raccolta dell'input su più pagine. Alla fine viene eseguito **un solo** job: le extravars unite di tutte le pagine vengono inviate a un unico playbook, template o workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Una pagina di riepilogo in sola lettura viene aggiunta automaticamente come ultima pagina del wizard; non la dichiari nello YAML.
+
+#### Combinati (wizard sopra un workflow)
+{: .no_toc }
+
+Un wizard si può sovrapporre a un modulo workflow. L'utente compila le pagine del wizard e preme Invia, e **poi** parte il
+workflow. Facendo corrispondere il `defaultModel` di un passo del wizard con l'[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys)
+di un nodo, puoi indirizzare **una pagina del wizard a un nodo**:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+E il workflow `provision-host`, in un file di workflow del designer:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` è una ricerca su un solo livello, quindi usa un nome piatto in `defaultModel` (per esempio `defaultModel: basics`, non `defaultModel: input.basics`) quando vuoi che corrispondano.
+
+Vedi la [pagina Wizard](forms/wizard.html) per il riferimento completo delle proprietà.
+
+### Come mostro o salto i passi del wizard in base a una condizione?
+
+Usa `when:` per **nascondere** completamente un passo, o `optional: true` per permettere all'utente di **saltare** un passo visibile. Le due cose sono indipendenti e in genere non vanno combinate.
+
+#### `when:`: visibilità condizionale
+{: .no_toc }
+
+Il passo è nascosto quando l'espressione restituisce un valore falsy. L'utente non lo vede mai, e i suoi valori non vengono raccolti. L'espressione può leggere i passi precedenti tramite `__parent__.<stepname>.<field>`:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Viene mostrata solo la pagina corrispondente al `kind` scelto. I passi dopo uno nascosto vengono rinumerati automaticamente.
+
+#### `optional: true`: permettere di saltare un passo visibile
+{: .no_toc }
+
+Il passo è **sempre mostrato** nella barra dei passi, ma l'utente può premere **Avanti** senza compilarlo, e **Invia** è consentito anche se la pagina non è mai stata visitata o completata:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+L'utente può aprire la pagina Advanced, lasciarla vuota, premere Avanti e passare direttamente alla pagina di riepilogo.
+
+{: .note }
+> `when:` controlla la *visibilità*; `optional:` controlla *se la pagina deve essere completata*. Non combinarli: per far sparire una pagina, usa `when:`; per tenerla visibile ma saltabile, usa `optional:`.
+
+### Come faccio riferimento ai valori di un passo precedente del wizard?
+
+Usa `$(__parent__.<stepname>.<field>)` dentro qualsiasi campo di un passo successivo.
+
+Il `name` di un passo del wizard (per impostazione predefinita il nome del suo `subform`) è lo spazio dei nomi sotto cui i suoi valori vengono esposti ai passi successivi:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+È lo stesso meccanismo `__parent__` usato dai subform di `list` e `yaml`; vedi [Come accedo ai dati del modulo padre dentro un subform?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Sicurezza e credenziali
+
+### Credenziali
+
+Passa le credenziali.
+
+Le credenziali si possono passare in diversi modi:
+* usando la proprietà di campo `asCredential`  
+* usando la proprietà di modulo `credentials` (coppie chiave-valore)
+* usando un'extravar chiamata `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Recuperare una password di admin persa
+
+Se hai perso la password dell'account locale `admin` e non è disponibile nessun altro utente admin, usa l'opzione di recupero `REINIT_ADMIN`. **Non è un modo per aggirare l'autenticazione durante l'esecuzione**: forza solo un reset una tantum dell'account admin locale all'avvio, dopodiché l'autenticazione procede normalmente.
+
+**Come funziona**
+
+Quando `REINIT_ADMIN=1` è impostato all'avvio, AnsibleForms:
+
+1. Si assicura che il gruppo `admins` esista (creandolo se manca).
+2. Cerca l'utente admin locale (nome utente predefinito `admin`, sovrascritto da `ADMIN_USERNAME`).
+3. Se esiste, reimposta la sua password al valore di `ADMIN_PASSWORD` e lo ricollega al gruppo `admins`.
+4. Se non esiste, lo crea (come in un'installazione nuova).
+5. Registra l'azione in modo ben visibile nei log.
+
+**Passi**
+
+1. Ferma AnsibleForms.
+2. Imposta le variabili d'ambiente (usa una password robusta):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   In Docker Compose, aggiungile al blocco `environment:` del servizio AnsibleForms.
+3. Avvia AnsibleForms e cerca nei log una riga come:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Accedi con `admin` / `YourNewStrongPasswordHere`.
+5. **Rimuovi `REINIT_ADMIN` (o rimettilo a `0`)** e riavvia, così che i riavvii futuri non reimpostino di nuovo la password dell'admin.
+
+**Note**
+
+- Se sei rimasto chiuso fuori perché LDAP era l'unico metodo di accesso configurato ed è andato in errore, l'account locale `admin` recuperato ricade sempre sull'autenticazione con il database locale, che basta per accedere e sistemare LDAP.
+- La vecchia variabile d'ambiente `ENABLE_BYPASS` è stata rimossa. Permetteva di accedere come admin con qualsiasi password e non era sicuro lasciarla attiva. `REINIT_ADMIN` reimposta solo la password; dopo si applica la normale autenticazione.
+- `REINIT_ADMIN` non invalida le sessioni e i token esistenti; cambiano solo l'hash della password e l'appartenenza al gruppo.
+
+### Limitare le destinazioni degli helper REST (liste di consentiti e negati)
+
+Gli helper `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` e `fn.fnRestJwtSecure` si possono chiamare dalle proprietà `expression` dei moduli per recuperare dati via HTTP. Per impostazione predefinita, chi scrive le espressioni può puntare a **qualsiasi** URL raggiungibile dall'host di AnsibleForms, cosa che su una rete sensibile potresti voler limitare.
+
+Due variabili d'ambiente forniscono una lista di consentiti e una di negati:
+
+| Variabile | Comportamento |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Nomi host o CIDR separati da virgole. Quando è impostata, sono consentite **solo** queste destinazioni. |
+| `REST_DENIED_HOSTS` | Nomi host o CIDR separati da virgole. Sempre bloccati. Ha la precedenza sulla lista dei consentiti. |
+
+I nomi host vengono confrontati con l'host dell'URL senza distinzione tra maiuscole e minuscole. I CIDR vengono confrontati con ogni IP in cui si risolve l'host, quindi `10.0.0.0/8` blocca qualsiasi nome DNS che si risolva nell'intervallo privato.
+
+**Esempi:**
+
+La prima riga consente solo due host; la seconda blocca destinazioni specifiche:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Questa protezione tutela solo il processo Node.js di AnsibleForms.** Una volta che un playbook gira, Ansible stesso può raggiungere qualsiasi cosa dall'host, fuori dal controllo di AnsibleForms. Usa queste liste per impedire a chi scrive i moduli di trasformare le espressioni in un proxy verso servizi di metadati o interfacce interne; non affidarti a esse come a un firewall di rete.
+
+Dalla 7.3.0 gli helper REST controllano il certificato TLS dell'endpoint, come fa ogni altra connessione, e rinunciano dopo
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (`60` per impostazione predefinita). Fai considerare attendibile una CA privata con
+`NODE_EXTRA_CA_CERTS`, o imposta [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) su `1` solo per endpoint con un
+certificato autofirmato.
+
+### Integrazione con HashiCorp Vault
+
+Le credenziali possono leggere il loro utente e la loro password da HashiCorp Vault, configurato come
+**archivio di segreti**. Vedi [Archivi di segreti](secret-stores). Le variabili d'ambiente `VAULT_*`
+delle versioni precedenti vengono importate una volta come archivio `vault` al primo avvio della 7.x.
+
+Per i segreti usati solo dentro un playbook, puoi anche usare il plugin di lookup `community.hashi_vault`,
+che legge direttamente da Vault e scavalca AnsibleForms.
+
+---
+
+## Integrazione
+
+### Interrogare AWX/Tower/AAP
+
+Interroga informazioni da AWX o da Ansible Automation Platform.
+
+Per riempire i menu a tendina con dati da AWX o Tower, usa `fn.fnRestBasic` o `fn.fnRestJwtSecure`. Dalla 7.3.0 questi helper controllano
+il certificato dell'indirizzo di AWX: con uno autofirmato, fai considerare attendibile la sua CA con `NODE_EXTRA_CA_CERTS`, o imposta
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) su `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Personalizzazione
+
+### Personalizzazione
+
+Personalizza AnsibleForms.
+
+AnsibleForms è un'applicazione web. Quando la esegui in modo nativo in Node.js, puoi sostituirne o modificarne i file.  
+L'approccio consigliato, però, è eseguirla come immagine Docker e aggiungere mappature di volumi o file. I progetti Docker Compose mappano già delle directory per rendere persistenti il database, i playbook, i log, i certificati e le chiavi SSH, e puoi aggiungere altre mappature. Un logo personalizzato si carica nella pagina delle impostazioni **Logo**.  
+Il file `custom.js` contiene le tue funzioni JavaScript da usare nelle espressioni. Le funzioni integrate usano il prefisso `fn.` (per esempio fn.fnRestBasic); le funzioni personalizzate usano il prefisso `fnc.`.  
+Allo stesso modo, puoi aggiungere le tue definizioni jq nel file `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### Attivare YTT
+
+Attiva ytt.
+
+Per usare ytt, imposta `USE_YTT=1`.  
+Per maggiori informazioni su ytt, vedi https://carvel.dev/ytt/.
+
+{: .important }  
+> Questa funzione non è stata testata a fondo, e non è arrivato nessun riscontro da quando è stata aggiunta come miglioramento.  
+> Quando usi ytt, devi disattivare il designer: il designer converte i file YAML in JSON intermedio e scarta la sintassi di ytt (che consiste di commenti YAML).
+
+Nella directory radice deve esistere una directory `lib`; viene inclusa automaticamente nella chiamata a ytt.
+I dati si possono fornire globalmente impostando variabili d'ambiente con un prefisso:  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+In alternativa, fornisci file di dati della libreria:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**La libreria `demo` deve esistere nel contesto di ytt (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+I dati caricati si possono poi usare:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Controllo degli accessi
+
+### Come limito ciò che gli utenti possono fare (opzioni di ruolo)?
+
+Oltre a limitare quali moduli un ruolo può vedere, le `options` di un ruolo attivano o disattivano funzioni dell'interfaccia per i suoi membri.
+Vedi [Opzioni di ruolo](config/roles.html#role-options) per ogni opzione, il suo valore predefinito e come si combinano le opzioni tra i ruoli.
+
+### Come implemento una logica RBAC personalizzata nei miei playbook o moduli?
+
+L'identità dell'utente è disponibile sia nel frontend sia nel backend a ogni esecuzione.
+
+A ogni invio di un modulo, AnsibleForms inserisce automaticamente l'identità completa dell'utente corrente nelle extravars inviate ad Ansible:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+Il tuo playbook o qualsiasi modulo Ansible personalizzato può quindi usare `ansibleforms_user` direttamente per decisioni granulari, per esempio per consentire solo a certi gruppi di modificare l'inventario di produzione, o per scrivere una traccia di audit con il nome utente di chi ha inviato il modulo.
+
+Nel **frontend**, lo stesso oggetto è disponibile tramite il campo speciale `__user__`:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Schemi tipici:**
+
+L'identità dell'utente consente schemi come i seguenti:
+
+- **Incrociare un file di configurazione RBAC o un database**: carica un file YAML o JSON (con `fn.fnReadYamlFile` o un'espressione) che associa i gruppi alle risorse consentite, poi filtra su `$(__user__.groups)`
+- **Traccia di audit**: passa `ansibleforms_user.username` come variabile extra per registrare chi ha avviato il job
+- **Valori dinamici dei campi**: mostra un insieme diverso di scelte enum, precompila campi o nascondi sezioni in base ai gruppi o ai ruoli dell'utente
+- **Autorizzazione lato playbook**: verifica che `ansibleforms_user.groups` contenga un gruppo richiesto prima che il playbook prosegua, come controllo di difesa in profondità indipendente dall'elenco `roles` del modulo
+
+{: .note }
+> L'oggetto qui sopra è ciò che viene inviato per impostazione predefinita. Se l'istanza imposta `EXTRAVARS_USER_FIELDS`,
+> o il modulo imposta `userExtravars`, vengono inviate solo le chiavi indicate lì, quindi un playbook che
+> verifica `ansibleforms_user.groups` richiede che `groups` sia una di esse. Il campo `__user__`
+> del frontend viene dal token di accesso e non viene mai ridotto da nessuna delle due impostazioni.
+
+---
+
+## Pianificazione dei job
+
+### Come pianifico l'esecuzione automatica di un modulo?
+
+Apri il menu a tendina accanto a **Invia** e scegli **Pianifica (ricorrente)** o **Esegui più tardi (una volta)**; richiedono le opzioni di ruolo
+`allowScheduledJobs` (a livello admin) e `allowPlannedJobs`. Vedi [Pianificazioni](jobs/schedules.html).
+
+### Quali espressioni cron posso usare?
+
+Una pianificazione ricorrente accetta un'espressione cron standard a 5 campi (minuto, ora, giorno del mese, mese, giorno della settimana).
+
+| Espressione | Esegue |
+|---|---|
+| `*/15 * * * *` | Ogni 15 minuti |
+| `0 * * * *` | Ogni ora, allo scoccare dell'ora |
+| `0 */6 * * *` | Ogni 6 ore, alle 00:00, 06:00, 12:00 e 18:00 |
+| `0 2 * * *` | Ogni giorno alle 02:00 |
+| `30 7 * * 1-5` | Dal lunedì al venerdì alle 07:30 |
+| `0 8 * * MON` | Ogni lunedì alle 08:00 (i nomi dei giorni e dei mesi sono accettati) |
+| `0 0 1 * *` | A mezzanotte del primo giorno di ogni mese |
+| `0 22 L * *` | Alle 22:00 dell'ultimo giorno di ogni mese |
+| `0 6 * * 1#1` | Alle 06:00 del primo lunedì di ogni mese |
+| `*/30 * * * * *` | Ogni 30 secondi (un sesto campo facoltativo in testa indica i secondi) |
+
+Quando sono impostati sia il giorno del mese sia il giorno della settimana, la pianificazione viene eseguita quando corrisponde uno dei due: `0 0 13 * 5` gira
+il 13 e ogni venerdì. Il server rifiuta un'espressione che non può eseguire, o una che non può mai verificarsi (`0 0 30 2 *`).
+
+Nella pagina **Pianificazioni**, l'editor cron descrive l'espressione e mostra in anteprima le sue prossime esecuzioni. Non accetta abbreviazioni
+come `@daily`, il carattere jolly `?` né il modificatore `W` (giorno feriale più vicino), quindi attieniti alle forme della tabella.
+
+{: .note }
+> **Fuso orario** Le pianificazioni cron girano nel fuso orario del server, impostato con [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (predefinito `UTC`), non nel fuso orario del tuo profilo o del tuo browser. `0 2 * * *` con `LOG_TZ=Europe/Madrid` gira alle 02:00
+> ora di Madrid tutto l'anno, seguendo l'ora legale. L'editor cron mostra in anteprima le prossime esecuzioni in quello stesso fuso. Le pianificazioni
+> di pull dei repository usano lo stesso fuso.
+
+---
+
+## Salvare e caricare i dati dei moduli
+
+### Come salvo e ricarico i dati di un modulo senza eseguire un job?
+
+Seleziona **Salva** nel menu a tendina accanto a **Invia** per salvare i valori dei campi, poi **Carica da archivio** per ripristinarli in seguito.
+I campi password non vengono mai salvati. Richiede l'opzione di ruolo `allowStoredJobs`. Vedi [Job salvati](jobs/stored-jobs.html).
+
+---
+
+## Moduli annidati e campi strutturati
+
+### Come raccolgo dati strutturati o ripetuti in un modulo?
+
+Usa i campi `list` e `yaml` con dei subform (6.2.0+).
+
+Per raccogliere dati strutturati complessi, come un elenco di server, un insieme di interfacce di rete o un singolo oggetto annidato, usa il tipo di campo `list` o `yaml` insieme a un `subform`.
+
+Un **subform** è un frammento di modulo riutilizzabile (definito con `type: subform`) che non viene mai mostrato come riquadro a sé. Esiste solo per essere referenziato dai campi di altri moduli. Vedi la [documentazione dei subform](forms/subform.html) per il riferimento completo.
+
+**Raccogliere un elenco di righe strutturate: campo `list`:**
+
+Un campo `list` apre il subform referenziato una volta per riga:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+L'extravar `servers` inviata ad Ansible è un array di oggetti: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Modificare un singolo oggetto strutturato: campo `yaml`:**
+
+Il campo `yaml` ha tre modalità:
+
+| Modalità | Come | Comportamento |
+|---|---|---|
+| **Editor** | predefinita | Mostra un editor YAML completo con evidenziazione della sintassi in cui l'utente può scrivere direttamente |
+| **Sola lettura** | `readonly: true` | Mostra il valore YAML come testo formattato in sola lettura, senza modifica |
+| **Subform** | `subform: MySubform` | Nasconde l'editor grezzo; al clic apre il subform come editor di dettaglio |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Upload e download: campi `list` e `yaml`:**
+
+Entrambi i tipi di campo supportano il trasferimento di file lato client tramite due proprietà facoltative:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> Il campo `list` e il tipo di modulo `subform` hanno sostituito il campo `table` e `tableFields`, rimossi nella 7.0.0.
+
+### Come accedo ai dati del modulo padre dentro un subform?
+
+Fai riferimento ai valori dei campi del padre dall'interno di un subform tramite `__parent__` (v6.3.0+).
+
+Quando si apre un subform, sia da un campo **`list`** (l'editor di ogni riga) sia da un campo **`yaml`** in modalità subform, AnsibleForms inserisce automaticamente nel subform un campo speciale in sola lettura chiamato `__parent__`. Contiene un'istantanea di **ogni valore di campo del modulo padre nel momento in cui il subform è stato aperto**, comprese costanti e variabili.
+
+Questo permette ai campi del subform di usare espressioni che fanno riferimento ai dati del padre senza nessuna configurazione aggiuntiva.
+
+#### Cosa c'è in `__parent__`?
+{: .no_toc }
+
+`__parent__` è un oggetto semplice le cui chiavi sono i nomi dei campi del modulo padre:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` **non viene inviato ad Ansible**; come `__user__`, viene tolto dalle extravars. È solo un aiuto lato frontend per le espressioni dentro i subform.
+
+#### Accedere ai valori del padre nelle espressioni di un subform
+{: .no_toc }
+
+Fai riferimento ai valori del padre con la sintassi standard delle espressioni `$(...)`:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Subform annidati
+{: .no_toc }
+
+`__parent__` si riferisce sempre al modulo **padre diretto**. Se annidi un `list` dentro un subform che a sua volta viene aperto da un modulo padre, il `__parent__` del subform interno contiene i dati del subform intermedio. Per raggiungere livelli più lontani, concatena riferimenti come `$(__parent__.__parent__.someField)` se anche il subform intermedio propaga il proprio `__parent__`.
+
+### Come migro da `table` / `tableFields` a `list` / `subform`?
+
+Il campo `table` e la proprietà `tableFields` sono stati deprecati nella 6.2.0 e rimossi nella 7.0.0, e un modulo che li usa ancora non supera la validazione. Per migrare:
+
+1. Estrai le colonne da `tableFields` in un nuovo modulo `type: subform` con normali `formfields`
+2. Sostituisci il campo `table` con un campo `list` che fa riferimento al subform tramite `subform: MySubformName`
+
+**Prima:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Dopo:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### Migrare `from` di `tableFields` a espressioni con `__parent__`
+{: .no_toc }
+
+La proprietà `from` delle colonne enum di `tableFields` riempiva le scelte del menu a tendina da un altro campo del modulo padre. In un `subform`, viene sostituita da un'`expression` che legge lo stesso valore tramite `__parent__`.
+
+**Prima: `tableFields` con `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Dopo: subform con un'espressione `__parent__`:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` restituisce il **valore attuale** di quel campo, quindi se quel campo è a sua volta un campo expression dinamico, il subform vede sempre l'ultimo risultato valutato dal padre.
diff --git a/i18n/it/_reference/getting-help.md b/i18n/it/_reference/getting-help.md
new file mode 100644
index 0000000..b6078da
--- /dev/null
+++ b/i18n/it/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Ottenere aiuto
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Ottenere aiuto
+{: .no_toc }
+
+Dove fare una domanda, segnalare un bug o un problema di sicurezza, e proporre un miglioramento
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Prima di chiedere
+
+La maggior parte delle risposte è già scritta da qualche parte; una rapida occhiata spesso evita un giro di domande e risposte:
+
+1. Cerca in questo sito con la casella di ricerca in cima a ogni pagina.
+2. Cerca il messaggio di errore esatto in [Risoluzione dei problemi](troubleshooting.html), e dai un'occhiata alle [FAQ](faq.html).
+3. Controlla il log del server (**Impostazioni**, poi **Log del server**) e la pagina **Stato**, che segnalano la maggior parte dei problemi di configurazione.
+4. Controlla il [Changelog](changelog.html): il problema potrebbe essere già risolto in una release più recente.
+
+---
+
+## Dove andare
+
+Ogni tipo di richiesta ha il suo posto, tutti su GitHub:
+
+| Vuoi | Vai a |
+|---|---|
+| Fare una domanda o condividere un'idea | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Segnalare un bug | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Proporre una funzionalità | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Segnalare un problema di sicurezza | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), in privato |
+| Correggere o migliorare questa documentazione | **Edit this page on GitHub** in fondo a qualsiasi pagina, o una [issue sul sito](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Segnalare un bug
+
+Una segnalazione riproducibile viene risolta più in fretta. Il template per i bug chiede quanto segue:
+
+* **Versione** : mostrata sotto **Informazioni** nel menu di aiuto (**?**) della barra in alto
+* **Distribuzione** : Docker, Docker Compose, Kubernetes, l'installer (e il suo motore), un'installazione nativa o dai sorgenti
+* **Passi per riprodurre** : cosa hai fatto, cosa ti aspettavi, e cosa è successo invece
+* **Prove** : le righe rilevanti del log del server, e uno screenshot quando il problema è visibile
+
+Per un problema con un modulo, includi una definizione minima del modulo che lo mostri. Togli password, token, nomi host e qualsiasi
+altro dato privato da log e moduli prima di pubblicarli: issue e discussioni sono pubbliche.
+
+---
+
+## Segnalare un problema di sicurezza
+
+**Non aprire mai una issue pubblica per questo:** usa [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), che vedono solo i maintainer.
+
+La [politica di sicurezza](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) elenca le versioni supportate e
+cosa succede dopo la segnalazione.
diff --git a/i18n/it/_reference/troubleshooting.md b/i18n/it/_reference/troubleshooting.md
new file mode 100644
index 0000000..16c60db
--- /dev/null
+++ b/i18n/it/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Risoluzione dei problemi
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Risoluzione dei problemi
+{: .no_toc }
+
+Messaggi di errore e sintomi, perché si verificano e come risolverli
+{: .fs-6 .fw-300 }
+
+---
+
+Ogni problema qui sotto ha come titolo il messaggio o il sintomo che vedi, seguito dalla causa e dalla soluzione. I messaggi sono citati
+esattamente come li scrive AnsibleForms; `<name>` indica un valore che cambia caso per caso. La maggior parte finisce nel log del
+server, che puoi leggere in [Log del server](gui/administration.html#server-log) o con `docker logs`.
+
+**Database e avvio**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Configurazione e moduli**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [La configurazione di base ha una sezione forms](#the-base-config-has-a-forms-section)
+* [Un modulo manca dalla dashboard](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Accesso**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [L'autenticazione Azure AD o OIDC non riesce](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Disconnessi dopo un riavvio o dopo un giorno](#logged-out-after-a-restart-or-after-a-day)
+* [Moduli e job vuoti dopo un single sign-on (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Job**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Un job mostra lo stato abandoned](#a-job-shows-the-status-abandoned)
+* [Un RTE non si connette](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Repository git e backup**
+
+* [Il clone o il pull di un repository non riesce](#a-repository-clone-or-pull-failed)
+* [Il repository dei moduli non è ancora clonato](#the-forms-repository-is-not-cloned-yet)
+* [Un backup non riesce](#a-backup-failed)
+
+Le [FAQ](faq.html) trattano a fondo due problemi collegati: una
+[password di admin persa](faq.html#recovering-a-lost-admin-password) e
+[la restrizione delle destinazioni degli helper REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms non si avvia, e il log ripete queste righe ogni 5 secondi:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Perché succede**
+
+All'avvio, AnsibleForms aspetta che il database risponda a una query, e continua ad aspettare finché non risponde.
+Il `<reason>` è il messaggio del driver del database: una connessione rifiutata o scaduta indica l'host o la porta,
+un messaggio di accesso negato il nome utente o la password.
+
+**Come risolverlo**
+
+Controlla [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) e [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Dentro un container, `localhost` è il container stesso, non l'host che esegue MySQL. Assicurati che MySQL ascolti
+su un indirizzo di rete e che l'utente possa connettersi dall'host di AnsibleForms. AnsibleForms prosegue da solo non appena
+il database risponde; non serve riavviare.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+Il browser apre una pagina del database invece della pagina di accesso, e il log mostra:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Perché succede**
+
+Lo schema `AnsibleForms` manca o è incompleto. Un database *vuoto* viene preparato automaticamente all'avvio, a meno che
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) non sia `0`. Se questo non riesce, per esempio perché
+l'utente del database non può creare uno schema, il log dice `Failed to create the schema automatically : <reason>`. Uno schema
+che esiste ma a cui mancano delle tabelle (`Table '<name>' is not present`) non viene mai ricreato automaticamente, perché creare lo
+schema elimina prima tutte le tabelle. La pagina del database dice allora *It appears that you have an unuseable schema*.
+
+**Come risolverlo**
+
+Su un'installazione nuova, dai all'utente del database il diritto di creare lo schema `AnsibleForms` e riavvia, oppure premi
+**Crea** nella pagina del database. Con uno schema presente solo in parte, ripristina un backup o rimuovi lo schema `AnsibleForms`
+incompleto così che AnsibleForms possa crearlo di nuovo. Il log elenca quali tabelle e patch non sono riuscite.
+
+---
+
+## Schema creation is disabled
+
+La creazione dello schema, dalla pagina del database o con `POST /api/v2/schema`, non riesce con:
+
+```
+Schema creation is disabled
+```
+
+**Perché succede**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) è `0`, il che disattiva sia la creazione
+automatica all'avvio sia l'endpoint. Su un database che ha già degli utenti, l'endpoint rifiuta anche i chiamanti che non hanno
+effettuato l'accesso come amministratore, con `Schema creation requires an authenticated administrator`.
+
+**Come risolverlo**
+
+Crea lo schema una volta con `ALLOW_SCHEMA_CREATION=1` (è il valore predefinito), o ripristinalo da un backup, e poi rimetti la
+variabile a `0`. Su un database già preparato, accedi come amministratore prima di ricreare lo schema, e ricorda
+che elimina e ricrea tutte le tabelle.
+
+---
+
+## Config seed failed, refusing to start
+
+Il container esce subito dopo l'avvio, e il suo output termina con:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Perché succede**
+
+Il file in [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) non è stato applicato: per esempio non è YAML
+valido o viola lo schema del seed; `<reason>` dice cosa è andato storto. AnsibleForms si rifiuta di avviarsi piuttosto che
+girare con metà dei suoi oggetti dichiarati. Il motivo viene scritto anche sullo standard error, quindi `docker logs` e `kubectl logs` lo mostrano.
+
+**Come risolverlo**
+
+Correggi ciò che indica `<reason>` e avvia di nuovo. Vedi [Ricaricamento e avvio](seed/reloading.html) per come viene applicato
+il seed, ed [Esempio](seed/example.html) per un file valido.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Ogni avvio registra questo avviso:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Oppure il worker si rifiuta di avviarsi con:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Perché succede**
+
+I segreti salvati sono cifrati con [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET): dalla 7.3.0 stanno nelle
+credenziali (le password e i token di directory LDAP, provider SSO, runner e archivi di segreti, tra gli altri), accanto agli indirizzi
+dei webhook di Slack e Teams. Senza di essa, viene usata una chiave che è pubblica nel codice sorgente. Dalla 7.3.0, un avvio con un nuovo
+`ENCRYPTION_SECRET` cifra di nuovo con esso ogni segreto salvato, in un'unica transazione: dalla chiave predefinita quando viene impostato per la prima
+volta, o da [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) quando cambia. Quando i
+segreti salvati non sono stati cifrati con nessuna delle due, non viene modificato nulla e AnsibleForms non si avvia.
+
+**Come risolverlo**
+
+Imposta `ENCRYPTION_SECRET`, e conservalo con gli altri tuoi segreti: i backup non lo contengono mai. L'avvio successivo registra
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Per cambiarlo in seguito, imposta il nuovo valore in
+`ENCRYPTION_SECRET` e quello vecchio in `ENCRYPTION_SECRET_PREVIOUS` per un avvio, poi rimuovi `ENCRYPTION_SECRET_PREVIOUS`. Quando il
+worker si rifiuta di avviarsi, imposta `ENCRYPTION_SECRET_PREVIOUS` sulla chiave con cui sono stati cifrati i segreti, o rimetti il vecchio valore.
+
+---
+
+## Could not load the forms
+
+La dashboard non mostra nessun modulo e segnala:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Perché succede**
+
+La configurazione di base (`config.yaml`) non si è potuta leggere o non è valida. Il `<reason>` dice quale dei due:
+
+| Motivo | Causa |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Un errore di sintassi YAML |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Un file vuoto, o con solo commenti |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | Lo stesso ruolo è definito due volte |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` manca e la sua cartella non è scrivibile |
+| `There is no forms directory nor could there be one created from template.` | La cartella dei moduli manca e non si può creare |
+| Qualsiasi altra riga | La configurazione viola lo schema, per esempio un ruolo senza `groups` |
+
+**Come risolverlo**
+
+Correggi il file indicato da [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH), o il `config.yaml` nel
+repository usato per la configurazione. Quando mancano dei file, fai puntare [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) e
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) a una posizione scrivibile e persistente. Vedi
+[config.yaml](config/) per la struttura.
+
+---
+
+## La configurazione di base ha una sezione forms
+
+Dopo un aggiornamento dalla 6.x la dashboard è vuota, e il pannello degli avvisi mostra:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Perché succede**
+
+Dalla 7.0.0, ogni modulo sta nel suo file nella cartella dei moduli. I moduli ancora elencati in `config.yaml` vengono
+ignorati.
+
+**Come risolverlo**
+
+Sposta ogni modulo nel suo file in [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Vedi
+[Aggiornare alla 7.x](upgrade-7.html).
+
+---
+
+## Un modulo manca dalla dashboard
+
+Un file di modulo esiste, ma un utente non vede il modulo nella dashboard.
+
+**Perché succede**
+
+Un utente vede un modulo solo quando uno dei `roles` del modulo è uno dei ruoli dell'utente; gli admin vedono tutti i moduli. Ogni utente ha
+il ruolo `default`, quindi un modulo con `roles: [default]` è visibile a tutti. I ruoli di un utente vengono dai gruppi e dagli utenti
+elencati sotto `roles` in `config.yaml`. Un modulo senza `categories` compare sotto **Default**, quindi manca dalle
+altre categorie, pur essendo elencato sotto **Tutti i moduli**. Infine, un modulo che non supera la validazione viene saltato. La
+dashboard mostra allora un pulsante **Questa configurazione ha Avvisi o errori**, che apre messaggi come:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Come risolverlo**
+
+Apri il pannello degli avvisi e correggi ciò che elenca. Controlla i ruoli dell'utente in
+[Permessi](profile/permissions.html) nel profilo, e i `roles` e le `categories` del modulo. Vedi
+[Ruoli](config/roles.html) e [Categorie](config/categories.html). Quando due file definiscono lo stesso nome di modulo,
+vince il primo caricato.
+
+---
+
+## Could not save the forms
+
+Il salvataggio nel designer non riesce con:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Perché succede**
+
+Il designer valida ogni modulo rispetto allo schema prima di scrivere qualsiasi cosa. Ogni riga di `<messages>` indica il
+modulo e il campo che violano una regola. Le opzioni rimosse nella 7.0.0 hanno un messaggio apposito, per esempio
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Come risolverlo**
+
+Correggi i campi indicati dai messaggi. Per le opzioni rimosse dalla 7.0.0, segui [Aggiornare alla 7.x](upgrade-7.html).
+Per validare i file dei moduli prima che arrivino ad AnsibleForms, vedi
+[Validazione in VS Code dei file dei moduli](faq.html#vs-code-validation-for-form-files) nelle FAQ.
+
+---
+
+## The editor is read-only
+
+Il designer mostra **Bloccato** con il nome di un altro utente, e il salvataggio non riesce con:
+
+```
+The editor is read-only
+```
+
+**Perché succede**
+
+Solo una persona alla volta può modificare i moduli. Il blocco viene preso quando qualcuno avvia il designer, e resta finché
+non lo ferma, anche se ha chiuso il browser senza fermarlo. L'API rifiuta un salvataggio da chiunque altro con
+`Designer is locked by <username>`.
+
+**Come risolverlo**
+
+Chiedi a `<username>` di fermare il designer. Se non è possibile, usa **Force Unlock** nel designer. Chi detiene il
+blocco perde le modifiche che non ha salvato.
+
+---
+
+## Abuse attempt of eval function
+
+Un campo con un'espressione mostra un errore, e il log ha una riga come:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Perché succede**
+
+Le espressioni lato server vengono controllate prima di essere eseguite. Possono chiamare solo funzioni `fn.` e `fnc.`; istruzioni multiple,
+righe multiple, template literal, `process.env` e parole come `require` o `constructor` vengono rifiutate. Il messaggio
+dice quale regola è stata violata. Con [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) impostato su
+`off`, ogni espressione lato server fallisce con
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Come risolverlo**
+
+Riscrivi l'espressione come una singola chiamata `fn.` o un'operazione semplice, o eseguila nel browser con `runLocal: true`. Vedi
+[Espressioni](expressions/) ed [Espressioni locali](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Un campo che chiama un'API REST resta vuoto, e il log mostra:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Perché succede**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) è impostata, e l'host dell'URL non vi è compreso.
+Un host che corrisponde a [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) viene rifiutato con
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, e un host che non si risolve con `cannot resolve <host>`.
+
+**Come risolverlo**
+
+Aggiungi il nome host, o un CIDR che copra i suoi indirizzi, a `REST_ALLOWED_HOSTS`, o rimuovi da `REST_DENIED_HOSTS` la voce che lo blocca.
+Vedi [Limitare le destinazioni degli helper REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+La pagina di accesso rifiuta un nome utente e una password con:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Perché succede**
+
+La pagina di accesso dà la stessa risposta per ogni errore, così da non rivelare se un utente esiste. AnsibleForms
+prova prima gli utenti locali e poi LDAP: con più directory, un nome utente viene cercato nel loro ordine in **Accesso > LDAP**,
+a meno che non indichi una directory (`corp\jane`) o uno dei suoi domini di accesso (`jane@corp.example`). Il motivo reale va nel log. Gli errori
+LDAP vengono registrati come `Error connecting to ldap: <reason>`, con motivi come `Wrong binding credentials` o
+`Unable to verify the certificate`; i codici di Active Directory vengono tradotti in `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` o `Password expired`.
+
+**Come risolverlo**
+
+Leggi il motivo nel log. Per il motivo completo di ogni accesso fallito, imposta
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) su `debug`, che registra `Ldap authentication failed: <reason>`.
+Se la password dell'admin locale è persa, vedi [Recuperare una password di admin persa](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Il test di una directory LDAP in **Accesso > LDAP** non riesce con uno di questi:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Perché succede**
+
+L'utente di bind o la sua password sono sbagliati, il server o la porta non sono raggiungibili, o, con TLS, il certificato del server non si può
+verificare con il bundle della CA. Dalla 7.3.0 questi stanno nella credenziale ldap della directory, in **Connessioni > Credenziali**. Un utente di test che non esiste
+conta comunque come test riuscito, perché la connessione e il bind hanno funzionato.
+
+**Come risolverlo**
+
+Apri la credenziale indicata dalla directory (la directory predefinita è `main`) in **Connessioni > Credenziali**, e correggi il bind
+DN e la sua password, i server e la porta (di solito 389, o 636 per LDAPS). Per i problemi TLS, incolla il bundle della CA che ha firmato il
+certificato del server LDAP; saltare il controllo del certificato non è adatto alla produzione. Vedi [LDAP](authentication/ldap.html).
+
+---
+
+## L'autenticazione Azure AD o OIDC non riesce
+
+Un accesso single sign-on torna alla pagina di accesso con:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Perché succede**
+
+L'identity provider ha rimandato indietro l'utente, ma AnsibleForms non è riuscito a completare l'accesso. Motivi comuni sono
+`azuread login is not enabled` o `oidc login is not enabled` (il provider è disattivato), e `jwt expired`, perché
+il passaggio dal provider è valido solo 5 minuti. Anche un errore durante il callback dal provider viene mostrato
+nella pagina di accesso, e registrato.
+
+**Come risolverlo**
+
+Abilita il provider in **Accesso > SSO**, e registra l'URL di callback nell'identity provider esattamente come
+lo usa AnsibleForms: `https://<your host>/api/v2/auth/entraid/callback` per Entra ID (dalla 7.3.0; `azureadoauth2` funziona ancora), o
+`https://<your host>/api/v2/auth/oidc/callback` per OIDC. Un URL di callback con `/api/v1/`, di prima della 7 o prima della
+6.1.5, va aggiornato: la pagina di accesso allora si ricarica senza accedere e senza errori. Riprova l'accesso dopo
+un passaggio scaduto.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Un utente con una password valida non riesce ad accedere, e riceve:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Perché succede**
+
+Uno dei ruoli dell'utente imposta l'opzione di ruolo `allowLogin` su `false`. Il log dice
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Come risolverlo**
+
+Rimuovi `allowLogin: false` dal ruolo, o togli l'utente da quel ruolo. Vedi [Ruoli](config/roles.html).
+
+---
+
+## Disconnessi dopo un riavvio o dopo un giorno
+
+Ogni utente viene rimandato alla pagina di accesso dopo che AnsibleForms si riavvia, o dopo un giorno di uso.
+
+**Perché succede**
+
+Quando [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) non è impostato, ogni avvio genera una
+nuova chiave di firma, e registra
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+I token di prima del
+riavvio non vengono più accettati. Indipendentemente da questo, una sessione termina quando il suo refresh token scade
+(`Refresh token is expired`), dopo
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), 24 ore per impostazione predefinita.
+
+**Come risolverlo**
+
+Imposta `ACCESS_TOKEN_SECRET` su un valore fisso e segreto. Aumenta `ACCESS_TOKEN_REFRESH_EXPIRATION` se un giorno è troppo poco. Per
+un accesso all'API di lunga durata, usa un [token API](profile/api-token.html).
+
+---
+
+## Moduli e job vuoti dopo un single sign-on (HTTP 431)
+
+Un utente accede con Entra ID o OIDC senza errori, ma le pagine dei moduli e dei job restano vuote. La scheda rete
+del browser mostra le chiamate API con la risposta:
+
+```
+431 Request Header Fields Too Large
+```
+
+Il log del server non mostra nulla per queste chiamate, e lo stesso utente può lavorare senza problemi con un account LDAP o locale.
+
+**Perché succede**
+
+Prima della 7.1.0, il token di accesso conteneva ogni gruppo dell'utente, e i gruppi di Entra ID vi comparivano due volte, per object id
+e per nome. Il browser invia quel token nell'header `Authorization` di ogni richiesta, quindi un utente in un centinaio di
+gruppi o più si ritrova con un header di ben oltre 16 KB. Node.js rifiuta gli header di richiesta più grandi di 16 KB con un 431,
+prima che la richiesta raggiunga AnsibleForms, ed è per questo che non viene registrato nulla. Un reverse proxy davanti può rifiutare la
+richiesta anche prima: Nginx consente per impostazione predefinita 8 KB per campo di header
+(`large_client_header_buffers 4 8k`), e risponde invece 400.
+
+**Come risolverlo**
+
+Aggiorna alla 7.1.0 o successiva: il token di accesso non contiene più i gruppi, quindi la sua dimensione non dipende più da quanti
+gruppi ha un utente, e l'interfaccia lo segnala quando una richiesta viene rifiutata con 431 invece di mostrare pagine vuote.
+Finché non puoi aggiornare, puoi:
+
+* impostare un **Filtro gruppi** sul provider in **Accesso > SSO**, un'espressione regolare che mantiene solo i gruppi usati dai tuoi
+  ruoli, vedi [Entra ID](authentication/entra-id.html) o [OIDC](authentication/oidc.html); l'utente accede di nuovo
+  per ottenere un token più piccolo
+* oppure alzare il limite di Node.js con la variabile d'ambiente `NODE_OPTIONS=--max-http-header-size=65536`, e
+  riavviare AnsibleForms
+
+Dalla 7.1.0, [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) imposta lo stesso limite, 16384
+byte per impostazione predefinita e letto all'avvio, per altri header grandi, come i cookie voluminosi impostati da un gateway di single sign-on
+davanti. Alza anche i limiti degli header del proxy, vedi [Dimensione degli header di richiesta](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Un job Ansible termina come fallito, e l'ultima riga del suo output è:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Perché succede**
+
+`ansible-playbook` è uscito con un codice diverso da zero. Le righe sopra contengono l'errore di Ansible stesso: il playbook non è stato
+trovato, un host non era raggiungibile, un task è fallito, o l'inventario è sbagliato. Il playbook viene cercato nel repository
+con **Usare per playbook?** attivo, o in [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); la riga di log
+`Running from directory : <path>` mostra la cartella usata.
+
+**Come risolverlo**
+
+Leggi l'output del job sopra l'ultima riga. Quando il playbook non viene trovato, confronta il `playbook` del modulo con la
+cartella in `Running from directory`. Vedi [Moduli Ansible](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Un job Ansible termina come fallito con:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Perché succede**
+
+Il processo `ansible-playbook` sull'RTE è stato terminato da un segnale, e nessuno ha interrotto il job. Dalla 7.0.0 la dimensione
+dell'output non causa più questo: oltre [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (50 MB per stream
+per impostazione predefinita) il resto dell'output non viene salvato, il job mostra
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+e il playbook arriva fino alla fine. La causa abituale ora è la memoria: il container RTE ha raggiunto il suo limite di memoria e il
+kernel ha ucciso il playbook, per esempio con molti fork o facts di grandi dimensioni.
+
+**Come risolverlo**
+
+Controlla la memoria del container RTE mentre il playbook gira (`docker stats`, `kubectl top pod`) e alzane il limite, o riduci
+l'uso di memoria del playbook (meno `forks`, niente raccolta di facts inutile). Quando vedi solo l'avviso di `PROCESS_MAX_BUFFER` e
+ti serve l'intero output, alza `PROCESS_MAX_BUFFER` nell'ambiente del container RTE; viene letta dall'RTE, non dall'app.
+---
+
+## Failed to launch awx template
+
+Un job AWX termina come fallito, con un output che inizia con:
+
+```
+failed to launch awx template <name>
+```
+
+**Perché succede**
+
+La riga successiva dà il motivo. `Request failed with status code 401` significa che il token o il nome utente e la password nella
+credenziale del runner AWX vengono rifiutati. `could not find job template <name>` significa che né un job template né un workflow job template
+ha esattamente quel nome, o che l'utente della connessione non può vederlo. Un errore di certificato, come
+`unable to verify the first certificate`, significa che il certificato di AWX non è considerato attendibile.
+
+**Come risolverlo**
+
+Usa **Testa connessione** sul runner (**Connessioni > Runner**), che risponde `Runner connection is OK` quando funziona. Dalla
+7.3.0 il token o l'utente e la password, l'indirizzo e il **Bundle CA** stanno nella credenziale del runner, in
+**Connessioni > Credenziali**: rinnova lì il token o la password, e per gli errori di certificato incolla la CA nel suo **Bundle CA**.
+Controlla il nome e i permessi del template. Inserisci l'indirizzo senza `/api/v2`: AnsibleForms aggiunge da sé
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX).
+Vedi [Moduli AWX](forms/awx.html).
+
+---
+
+## Un job mostra lo stato abandoned
+
+Un job che era in esecuzione ora è contrassegnato come `abandoned`, e il log di un nodo o di un RTE mostra uno di questi:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Un RTE in modalità database, deprecata, registra i suoi:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Perché succede**
+
+Un job appartiene al container che lo esegue o lo segue: un playbook al suo RTE, qualsiasi altro job (un job AWX, i passi di un modulo
+multistep) al nodo dell'app che l'ha avviato. Quando quel container si riavvia, termina i propri job non finiti. Quando scompare, per esempio un pod
+sostituito, il worker termina i suoi job dopo che non ha risposto per due minuti. Un RTE in modalità socket che torna senza
+un job che stava eseguendo, per esempio un nuovo container senza il suo spool, fa terminare quel job come abandoned. Un RTE che si ferma aspetta
+prima [`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) per i suoi playbook. Ogni ora, anche i job in esecuzione da più
+di un giorno vengono contrassegnati come abandoned.
+
+Dalla 7.3.0 un job su AWX, AAP o Ascender prosegue sul suo runner: subito dopo che un riavvio lo abbandona, un nodo torna a seguirlo,
+se è partito nelle ultime 24 ore, e termina con ciò che è successo davvero lì. Il log dice allora `Following <n> abandoned job(s) again on their runner`.
+
+**Come risolverlo**
+
+Rilancia un job playbook. Riavvia o aggiorna RTE e nodi dell'app mentre nessun job è in esecuzione, e dai a un RTE che si ferma abbastanza tempo
+(vedi [Scalabilità](rte/run.html)). Controlla se il playbook è davvero terminato sugli host gestiti prima di
+rilanciarlo, perché potrebbe essere stato eseguito solo in parte.
+
+---
+
+## Un RTE non si connette
+
+**Testa connessione** su un runner RTE (**Connessioni > Runner**) non riesce con:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Perché succede**
+
+Un RTE in modalità socket parla con l'app tramite un WebSocket: in uscita contatta l'app, in entrata è l'app a contattarlo (vedi
+[Modalità](rte/modes.html)). I log dell'app e dell'RTE dicono perché il socket non è aperto:
+
+| Messaggio | Dove | Cosa significa |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | L'RTE (in entrata) | Il token della credenziale RTE del runner non è l'`RTE_TOKEN` dell'RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | L'app (in entrata) | Lo stesso, visto dall'app |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | L'app, e l'RTE che viene rifiutato (`401`) | L'RTE accede con un token diverso da quello che l'app conserva per il suo runner |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | L'RTE (in uscita) | Ha chiesto di unirsi e aspetta un'approvazione |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | L'RTE (in entrata, con `APP_URL`) | Lo stesso, per un RTE in entrata |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | L'app, e l'RTE che viene rifiutato (`409`) | Il config seed dichiara il runner senza `rte_mode`, quindi in modalità database, ed è il seed a decidere la sua modalità. Un RTE in entrata riceve `rte_mode: inbound` e `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | L'RTE | Un RTE in entrata che si registra da solo ha bisogno dell'indirizzo su cui l'app lo contatta |
+| `Runner '<name>': dialing <address>: <reason>` | L'app, a livello `debug` | L'app non riesce ad aprire il socket, per esempio perché il certificato dell'RTE non è quello fissato per il suo runner |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | L'RTE | Gira in modalità database, e non apre affatto un socket |
+
+**Come risolverlo**
+
+* **Un token rifiutato** : dai all'RTE il token della credenziale RTE del suo runner (**Connessioni > Credenziali**), o viceversa
+* **In attesa di approvazione** : approvalo in **Connessioni > Runner**, dopo aver controllato che l'impronta mostrata lì sia quella nel suo
+  log (vedi [Approvare un RTE](runners/registration.html#approving-an-rte))
+* **Gestito dal config seed in modalità database** : imposta `rte_mode` sul runner nel seed, con una credenziale RTE (per l'entrata, il suo
+  indirizzo), poi riavvia l'RTE
+* **In entrata senza `RTE_URL`** : imposta `RTE_URL` sull'indirizzo su cui l'app raggiunge l'RTE, oppure ometti `APP_URL` e dichiara il
+  runner nel seed o in **Connessioni > Runner**
+* **Un certificato che non è quello fissato** : un RTE in entrata su HTTPS invia il suo certificato quando si registra, e l'app lo contatta
+  solo con quello. Dopo un nuovo certificato, l'RTE lo invia di nuovo quando si registra; quando il bundle CA della credenziale è stato impostato
+  a mano, l'app lo mantiene e registra
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **L'avviso [DEPRECATED]** : imposta `RTE_MODE` sull'RTE, rimuovi `DB_*` dal suo ambiente, e imposta il suo runner su quella modalità (vedi
+  [Modalità](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Con la validazione all'avvio su `enforce`, un avvio viene rifiutato con `422` e:
+
+```
+The form data is not valid
+```
+
+**Perché succede**
+
+Il server ha controllato i valori dei campi rispetto alle regole del modulo e ha trovato campi mancanti o non validi; la risposta li elenca
+sotto `details`. Anche un avvio senza `rawFormData` viene rifiutato. Un modulo che non si può ancora controllare, come un wizard,
+viene rifiutato con `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Come risolverlo**
+
+Correggi i campi indicati dai dettagli, o le regole del modulo se sono troppo rigide. Esegui prima in modalità `log`: registra
+`Launch validation would refuse form '<name>' ...` senza rifiutare nulla. Vedi
+[Cosa fa enforce](launch-validation/log-and-enforce.html#what-enforce-does) e
+[Introdurla gradualmente](launch-validation/rolling-it-out.html).
+
+---
+
+## Il clone o il pull di un repository non riesce
+
+Un repository mostra uno stato di errore, e il suo output contiene l'errore di git, oppure il log mostra
+`Background clone of '<name>' failed : <reason>`.
+
+**Perché succede**
+
+Git non è riuscito a raggiungere il remoto o ad autenticarsi presso di esso. Per gli URL SSH (`git@host:path`), il remoto deve accettare la chiave
+pubblica di AnsibleForms; per HTTPS, il nome utente e il token devono essere validi. Un pull viene rifiutato anche quando l'albero di lavoro ha
+modifiche, con
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Come risolverlo**
+
+Per SSH, copia la chiave pubblica dalla scheda **Chiave** di **Connessioni > SSH** e aggiungila come deploy key, o a un utente con
+accesso al repository. AnsibleForms aggiunge l'host remoto agli host conosciuti durante un clone; per altri host, usa la
+scheda **Host conosciuti** della stessa pagina. Per
+HTTPS, rinnova il token. Vedi [Repository Git](gui/designer-and-git.html#git-repositories) e
+[Sui repository](faq.html#about-repositories).
+
+---
+
+## Il repository dei moduli non è ancora clonato
+
+Il salvataggio dei moduli nel designer non riesce con:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Perché succede**
+
+Un repository con **Usare per moduli?** attivo non ha ancora un albero di lavoro, perché il clone non è stato eseguito o non è riuscito.
+
+**Come risolverlo**
+
+Clona il repository dalle impostazioni dei repository. Se il clone non riesce, vedi
+[Il clone o il pull di un repository non riesce](#a-repository-clone-or-pull-failed).
+
+---
+
+## Un backup non riesce
+
+Un backup non riesce, e non viene aggiunto nulla all'elenco dei backup. Il motivo è uno di questi:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Perché succede**
+
+Il comando di dump, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), non è installato, non è riuscito a
+connettersi, o ha prodotto un file vuoto. Un database grande può anche richiedere più di
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), un'ora per impostazione predefinita.
+Un backup fallito non lascia nessuna cartella; il log dice `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Come risolverlo**
+
+Installa gli strumenti client di MySQL o MariaDB, o imposta `MYSQLDUMP_COMMAND` (e `MYSQL_COMMAND` per i ripristini) su un comando
+che funzioni su questo host e con la versione del tuo server. Alza `BACKUP_COMMAND_TIMEOUT_SECONDS` per un database grande.
+Vedi [Backup](gui/administration.html#backups).
diff --git a/i18n/it/_security_assessment/security-assessment/advisories.md b/i18n/it/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..b6ad32d
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Advisory di sicurezza
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Advisory di sicurezza
+{: .no_toc }
+
+Ogni vulnerabilità pubblicata, la sua gravità e la sua correzione
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Advisory pubblicati
+
+Letti dalla [scheda Security del repository](https://github.com/ansibleforms/ansibleforms/security/advisories) a ogni build di questo sito:
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Advisory</th>
+      <th>Gravità</th>
+      <th>Debolezza</th>
+      <th>Interessate</th>
+      <th>Corretta in</th>
+      <th>Pubblicato</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Non è stato pubblicato alcun advisory.
+{% endif %}
+
+Ogni advisory su GitHub fornisce i dettagli: l'impatto, le condizioni, il vettore CVSS e la correzione.
+
+---
+
+## Cosa significa per la tua versione
+
+Un advisory indica le versioni interessate e la prima versione corretta. La correzione viene distribuita nelle release supportate,
+[7.x e 6.5.x](development.html#supported-versions), e le release più vecchie non ricevono patch: la correzione è aggiornare.
+
+Confronta la versione di un'istanza (**Informazioni** nel menu di aiuto, oppure `GET /api/v2/version`) con **Interessate**.
+
+---
+
+## Essere avvisati dei nuovi advisory
+
+GitHub avvisa chi segue il repository quando viene pubblicato un advisory:
+
+* Su [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), scegli **Watch > Custom > Security alerts**.
+* Il [changelog](../changelog.html) elenca ogni correzione di sicurezza sotto la release che la contiene.
diff --git a/i18n/it/_security_assessment/security-assessment/development.md b/i18n/it/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..dbea6fb
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Sviluppo sicuro
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Sviluppo sicuro
+{: .no_toc }
+
+Come le modifiche vengono controllate e rilasciate, e cosa è supportato
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Il codice sorgente
+
+AnsibleForms è open source, quindi tutto ciò che c'è in questa pagina si può verificare nel repository stesso:
+
+* Il codice, la sua storia e le sue pipeline di build sono pubblici su [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* La [licenza](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) è GPL-3.0.
+* Il [changelog](../changelog.html) elenca ogni modifica di ogni release, correzioni di sicurezza comprese.
+
+---
+
+## Come viene integrata una modifica
+
+Ogni modifica arriva su `main` tramite una pull request, sotto un ruleset che nessuno può aggirare:
+
+| Regola | Cosa significa |
+|---|---|
+| Pull request obbligatoria | Nulla viene inviato direttamente su `main` |
+| Controlli obbligatori | La pull request viene integrata solo quando passano tutti i controlli qui sotto |
+| Niente force push, niente eliminazione | La storia di `main` non può essere riscritta né rimossa |
+| Storia lineare | Ogni pull request diventa un solo commit, così ogni modifica si può tracciare e annullare singolarmente |
+
+I controlli che una pull request deve superare:
+
+| Controllo | Cosa fa |
+|---|---|
+| Client, Server | I test unitari dell'interfaccia web e del server |
+| CodeQL | L'analisi statica di GitHub del codice JavaScript e TypeScript, per injection, cross-site scripting e altre debolezze |
+| Public schema is up to date | Lo schema di database che il codice si aspetta corrisponde a quello che distribuisce |
+| Title, Branch | La pull request rispetta le regole di denominazione, così il changelog resta accurato |
+
+Altri due girano su ogni pull request e ne riportano l'esito:
+
+* **Database** testa il server su MySQL e MariaDB, e **Browser** pilota l'interfaccia in un browser.
+* **Dependency review** blocca una nuova dipendenza con una vulnerabilità nota di gravità alta o critica.
+
+---
+
+## Analisi del codice e dipendenze
+
+Il codice e ciò da cui dipende vengono controllati di nuovo dopo l'integrazione:
+
+* **CodeQL** analizza anche ogni push su `main` e sui branch di release, e l'intero codice ogni settimana:
+  così una nuova regola di CodeQL controlla anche il codice integrato prima di essa.
+* **Dependabot** apre una pull request per ogni nuova versione di una dipendenza: i pacchetti npm del server e
+  dell'interfaccia, i pacchetti Python dell'ambiente di esecuzione e le GitHub Actions delle pipeline ogni settimana, e
+  le immagini base dei container ogni giorno.
+* Le immagini base sono fissate per digest (`node:26-trixie-slim@sha256:...`), così una build usa esattamente l'immagine revisionata.
+  Dependabot aggiorna il digest quando l'immagine viene ricostruita a monte.
+
+---
+
+## Release e immagini
+
+Una release viene costruita e pubblicata solo da GitHub Actions, mai dal computer di uno sviluppatore:
+
+* Una release viene creata da `main` (o da `release/6.x`), con un changelog costruito dalle sue pull request.
+* Le immagini vengono costruite dal [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  e inviate al GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, con accanto le immagini dell'ambiente
+  di esecuzione. Il workflow e i suoi log sono pubblici, così chiunque può vedere cosa è entrato in un'immagine.
+* Le immagini dell'applicazione e dell'ambiente di esecuzione girano con l'utente non privilegiato `node` (uid 1000), mai come root.
+
+---
+
+## Versioni supportate
+
+Le correzioni di sicurezza vanno nella release più recente di ogni linea supportata:
+
+| Versione | Riceve correzioni di sicurezza |
+|---|---|
+| 7.x | Sì |
+| 6.5.x | Sì |
+| Precedenti alla 6.5 | No: la correzione è aggiornare |
+
+La [guida all'aggiornamento](../upgrading/) spiega come passare a una release più recente, e [Aggiornare alla v7](../upgrade-7.html) il passaggio dalla 6.5.
diff --git a/i18n/it/_security_assessment/security-assessment/faq.md b/i18n/it/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..24af7a4
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: FAQ sulla valutazione
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# FAQ sulla valutazione
+{: .no_toc }
+
+Risposte brevi alle domande più frequenti dei questionari di sicurezza
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dati e hosting
+
+Dove si trovano i dati, e chi può raggiungerli:
+
+| Domanda | Risposta |
+|---|---|
+| Dove vengono conservati i nostri dati? | Nel database MySQL o MariaDB che gestisci tu, e nella cartella persistente della tua istanza. AnsibleForms è self-hosted, senza alcun servizio cloud alle spalle. |
+| Invia dati a chi lo sviluppa? | No. Non c'è telemetria, nessuna raccolta di dati d'uso e nessun controllo degli aggiornamenti. |
+| A cosa si connette? | Solo ai sistemi configurati da un amministratore: vedi [Connessioni in uscita](measures.html#outbound-connections). |
+| Usa l'IA o invia dati a un fornitore di modelli? | Solo con l'[assistente chat](../chat/) attivo, che per impostazione predefinita è disattivato. In quel caso invia le definizioni dei moduli e i valori in compilazione al fornitore che configuri. |
+| Può funzionare senza accesso a Internet? | Sì. L'applicazione non ha bisogno di accesso a Internet; i playbook hanno bisogno di ciò che raggiungono i loro task. |
+
+---
+
+## Cifratura
+
+Cosa viene cifrato, e con quali chiavi:
+
+| Domanda | Risposta |
+|---|---|
+| I dati sono cifrati in transito? | Con [HTTPS](../security/https.html), servito dall'applicazione o dal tuo reverse proxy, e con `wss://` tra l'applicazione e i suoi ambienti di esecuzione. |
+| I dati sono cifrati a riposo? | Ogni segreto salvato viene cifrato dall'applicazione con AES-256. I job e il loro output vengono salvati così come sono: usa la cifratura a riposo del database stesso. Vedi [Segreti salvati](measures.html#stored-secrets). |
+| Chi detiene le chiavi? | Tu: l'[`ENCRYPTION_SECRET`](../security/secrets.html) lo imposti tu, resta fuori dai backup, e si può ruotare. |
+| I segreti possono restare nel nostro vault? | Sì: [HashiCorp Vault e CyberArk](../secret-stores/) vengono letti quando un job ne ha bisogno. |
+
+---
+
+## Accesso e responsabilità
+
+Chi può accedere, cosa può fare, e cosa viene registrato:
+
+| Domanda | Risposta |
+|---|---|
+| Supporta il single sign-on? | Sì: LDAP / Active Directory, OpenID Connect ed Entra ID. Vedi [Autenticazione](../authentication/). |
+| Supporta l'autenticazione a più fattori? | Tramite il single sign-on: vale l'MFA del tuo provider di identità. Gli account locali non ne hanno una propria. |
+| Come vengono gestiti i permessi? | Con ruoli associati a gruppi, controllati dal server a ogni richiesta. Vedi [Permessi](measures.html#permissions). |
+| C'è un registro di audit? | Sì: ogni modifica e ogni tentativo rifiutato, conservati per 365 giorni per impostazione predefinita e inoltrabili a syslog. Vedi [Traccia di audit](measures.html#audit-trail). |
+| C'è una password predefinita? | Il primo account admin ha una password predefinita pubblica, che va cambiata al primo accesso. Vedi [L'account admin](../security/hardening.html#the-admin-account). |
+
+---
+
+## Vulnerabilità e aggiornamenti
+
+Come i problemi vengono trovati, corretti e annunciati:
+
+| Domanda | Risposta |
+|---|---|
+| Sono state trovate vulnerabilità? | Sì. Ognuna di quelle pubblicate è elencata in [Advisory di sicurezza](advisories.html), con la versione che l'ha corretta. |
+| Come ne segnaliamo una? | In privato, tramite GitHub: vedi [Segnalare una vulnerabilità](reporting.html). |
+| Come viene controllato il codice? | Analisi statica con CodeQL e revisione delle dipendenze su ogni pull request, test automatici, e aggiornamenti con Dependabot. Vedi [Sviluppo sicuro](development.html). |
+| Quali versioni ricevono correzioni di sicurezza? | 7.x e 6.5.x. Vedi [Versioni supportate](development.html#supported-versions). |
+| Come veniamo a sapere di un nuovo advisory? | Segui gli avvisi di sicurezza del repository su GitHub. Vedi [Essere avvisati dei nuovi advisory](advisories.html#being-told-of-new-advisories). |
+| È stato sottoposto a penetration test? | Non è pubblicato alcun report di penetration test di terze parti. Il codice è pubblico, quindi il tuo team o il tuo tester può valutarlo, e i risultati si segnalano come descritto sopra. |
+
+---
+
+## Immagini e supply chain
+
+Da dove vengono le immagini, e come verificarle:
+
+| Domanda | Risposta |
+|---|---|
+| Dove vengono pubblicate le immagini? | Sul GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, costruite da workflow pubblici di GitHub Actions. Vedi [Release e immagini](development.html#releases-and-images). |
+| I container girano come root? | No: con l'utente non privilegiato `node`. |
+| Le immagini sono firmate? | Non ancora. Scaricale per digest (`@sha256:...`) per essere sicuro di eseguire l'immagine che hai revisionato. |
+| C'è uno SBOM? | Non ne viene ancora pubblicato uno con le immagini. Uno scanner come Trivy o Syft ne costruisce uno a partire dall'immagine. |
+| Le immagini vengono analizzate per le vulnerabilità? | Non nella pipeline di release. Le loro immagini base sono fissate per digest e mantenute aggiornate da Dependabot; analizza le immagini nel tuo registry per applicare la tua policy. |
+| Con quale licenza è distribuito? | GPL-3.0, open source, senza garanzia. |
diff --git a/i18n/it/_security_assessment/security-assessment/index.md b/i18n/it/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..4ec4802
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Panoramica
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Valutazione della sicurezza
+{: .no_toc }
+
+Per le revisioni di sicurezza: misure, sviluppo e advisory
+{: .fs-6 .fw-300 }
+
+---
+
+## In breve
+
+AnsibleForms esegue playbook e ne custodisce le credenziali, quindi fa parte della tua catena di fiducia:
+
+* È **self-hosted**: gira sulla tua infrastruttura, conserva i suoi dati nel tuo database, e non invia nulla a chi lo sviluppa.
+* È **open source** (GPL-3.0): il codice, le sue pipeline e ogni advisory sono pubblici.
+* Ogni segreto salvato è **cifrato**, ogni modifica **registrata nell'audit**, e i **ruoli** vengono controllati a ogni richiesta.
+* Le vulnerabilità vengono **segnalate in privato**, corrette in ogni release supportata, e **pubblicate**.
+
+---
+
+## In questa sezione
+
+Le pagine rispondono alle domande di una revisione di sicurezza, dalla progettazione all'elenco delle CVE:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Misure di sicurezza](measures.html) | Accesso, permessi, segreti salvati, la traccia di audit, il browser, il server, le connessioni e i container |
+| [Sviluppo sicuro](development.html) | Come una modifica viene revisionata e testata, l'analisi del codice e delle dipendenze, come vengono costruite le immagini, le versioni supportate |
+| [Segnalare una vulnerabilità](reporting.html) | Come segnalare un problema in privato, e cosa succede dopo |
+| [Advisory di sicurezza](advisories.html) | Ogni vulnerabilità pubblicata, con la sua CVE, la gravità e la versione corretta |
+| [FAQ sulla valutazione](faq.html) | Risposte brevi alle domande più frequenti dei questionari di sicurezza |
+
+Per mettere in sicurezza un'istanza invece di valutarla, vedi [Sicurezza](../security/) nella guida per l'amministratore.
diff --git a/i18n/it/_security_assessment/security-assessment/measures.md b/i18n/it/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..cb0fb36
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Misure di sicurezza
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Misure di sicurezza
+{: .no_toc }
+
+Come sono protetti accesso, permessi, segreti e connessioni
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dove gira
+
+AnsibleForms è self-hosted, sulla tua infrastruttura, con i suoi dati in un database che gestisci tu.
+
+* Non esiste un servizio cloud di AnsibleForms né un server di licenze, e non c'è telemetria né controllo degli aggiornamenti.
+* L'interfaccia viene servita dall'applicazione stessa e non carica nulla da altri siti.
+* L'applicazione si connette solo ai sistemi configurati da un amministratore, elencati in [Connessioni in uscita](#outbound-connections).
+
+Le componenti e cosa contiene ciascuna:
+
+| Componente | Cosa fa | Cosa contiene |
+|---|---|---|
+| Applicazione | L'interfaccia web, la REST API, lo scheduler | Nessun dato proprio: è tutto nel database |
+| MySQL o MariaDB | Il database dell'applicazione | Utenti, gruppi, credenziali (cifrate), job con le loro extravars e il loro output, il registro di audit |
+| Ambiente di esecuzione (RTE) | Esegue i playbook, nel proprio container | I file dei job che esegue, e i segreti di un job solo mentre quel job gira |
+| Cartella persistente | La configurazione, i moduli, i playbook e i file caricati | I file usati dai moduli e dai playbook |
+
+Vedi [Come funziona](../how-it-works.html) per il quadro completo, e [RTE](../rte/) per l'ambiente di esecuzione.
+
+---
+
+## Accesso
+
+Ogni pagina e chiamata API che legge o modifica dati richiede un utente autenticato. I pochi endpoint aperti senza autenticazione servono
+l'accesso stesso, la versione, il nome e il logo dell'istanza, la documentazione delle API, e la configurazione del database al primo avvio,
+che [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` chiude:
+
+| Metodo | Come funziona |
+|---|---|
+| Account locali | Password con hash bcrypt, una [lunghezza minima](../security/hardening.html#sign-in-limits-and-passwords), e la password admin predefinita pubblica va cambiata al primo accesso |
+| LDAP / Active Directory | La directory verifica la password, e i suoi gruppi vengono associati ai ruoli. Vedi [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Single sign-on tramite il tuo provider di identità, che porta con sé anche la propria autenticazione a più fattori. Vedi [Autenticazione](../authentication/) |
+
+* Gli accessi falliti [bloccano l'account](../security/hardening.html#sign-in-limits-and-passwords), e l'accesso ha un limite di frequenza.
+* Un accesso restituisce un access token firmato valido 30 minuti e un refresh token valido 24 ore.
+* I token si possono terminare prima della scadenza: l'uscita, un cambio di password, un utente bloccato e un token API revocato li terminano
+  su tutti i nodi contemporaneamente, vedi [Token](../security/secrets.html#tokens).
+* AnsibleForms non ha un'autenticazione a più fattori propria: usa il single sign-on dove è richiesta.
+
+---
+
+## Permessi
+
+Ciò che un utente può fare deriva dai ruoli dei suoi gruppi, controllati dal server a ogni richiesta:
+
+* I ruoli si definiscono in [config.yaml](../config/roles.html): quali moduli vede un utente, e quali opzioni ha,
+  come il designer, le pagine delle impostazioni o i job degli altri utenti.
+* Il server controlla ogni avvio rispetto alle regole del modulo (i suoi campi, i loro valori e l'accesso dell'utente), compresi
+  gli avvii tramite la REST API, vedi [Validazione all'avvio](../launch-validation/).
+* Il ruolo admin esegue qualsiasi playbook per progettazione. Gli altri ruoli ottengono solo ciò che viene concesso: un utente con più ruoli ottiene un'opzione
+  solo quando nessuno di quei ruoli la rifiuta, quindi basta un ruolo restrittivo per negarla.
+
+---
+
+## Segreti salvati
+
+Password, token e chiavi vengono cifrati prima di essere scritti nel database:
+
+* Ogni segreto salvato, credenziali, la password di bind LDAP, i token dei runner, i client secret del single sign-on, gli indirizzi
+  dei webhook e le chiavi API, viene cifrato con AES-256 e un vettore di inizializzazione casuale per ogni valore, con
+  l'[`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) che imposti tu.
+* Nessuna chiamata API o pagina delle impostazioni mostra un segreto salvato, e i backup omettono i segreti principali.
+* I segreti possono restare nel tuo vault: [HashiCorp Vault e CyberArk](../secret-stores/) vengono letti quando un job ne ha bisogno.
+* I segreti di un job arrivano all'ambiente di esecuzione sigillati con AES-256-GCM, con una chiave derivata dal suo token.
+* Le extravars il cui nome sembra quello di un segreto vengono mascherate nella vista del job, e i campi password lo sono sempre, vedi [Dati dei job](../security/hardening.html#job-data).
+
+Il resto del database, i job, le loro extravars e il loro output, viene salvato così com'è: proteggilo con la cifratura a riposo
+e il controllo degli accessi del database stesso, vedi [Il database](../security/hardening.html#the-database).
+
+---
+
+## Traccia di audit
+
+Ogni modifica, e ogni tentativo rifiutato, viene registrato:
+
+* Ogni creazione, modifica ed eliminazione, tramite l'interfaccia o l'API, viene scritta nel registro di audit con l'utente, il suo
+  indirizzo, l'azione, l'oggetto e l'esito. Vengono registrati anche i rifiuti e gli accessi, compresi quelli falliti.
+* I valori che sembrano segreti vengono oscurati prima di essere scritti.
+* Il registro viene conservato per 365 giorni per impostazione predefinita, e può essere copiato su syslog via UDP, TCP o TLS.
+
+---
+
+## Nel browser
+
+L'interfaccia è protetta contro il codice iniettato in una pagina:
+
+* Una [Content-Security-Policy](../security/hardening.html#the-content-security-policy) consente solo gli script e i frame dell'applicazione stessa.
+* Ogni risposta porta header di protezione: nosniff, protezione dai frame, e HSTS su HTTPS.
+* L'HTML dei moduli, dei testi di aiuto e delle risposte della chat viene sanitizzato, e l'output dei job viene sottoposto a escape.
+
+---
+
+## Sul server
+
+Il codice che gestisce l'input degli utenti evita le classiche injection:
+
+* Le query al database passano i loro valori come parametri, mai come testo incollato nella query.
+* I comandi, git compreso, girano da un elenco di argomenti, mai da una shell, quindi i caratteri della shell non hanno effetto.
+* Le espressioni lato server passano da un [sanitizzatore delle espressioni](../security/hardening.html#expressions-and-outbound-calls), e le loro chiamate REST da un filtro degli host.
+* Il [server MCP](../mcp/), l'[assistente chat](../chat/) e l'endpoint delle metriche sono disattivati finché non li attivi.
+
+---
+
+## Connessioni
+
+Il traffico da e verso AnsibleForms può essere cifrato da un capo all'altro:
+
+* L'applicazione serve [HTTPS](../security/https.html) direttamente, oppure sta dietro il tuo reverse proxy.
+* Un ambiente di esecuzione comunica con l'applicazione tramite un WebSocket, `wss://` con un indirizzo HTTPS, e l'applicazione
+  fissa il certificato di uno in ingresso, vedi [Modalità dell'RTE](../rte/modes.html).
+* LDAP, il single sign-on, i runner, git, gli archivi di segreti e le chiamate REST delle espressioni verificano il certificato del
+  server che raggiungono, a meno che un amministratore non disattivi la verifica per un server con un certificato autofirmato.
+
+### Connessioni in uscita
+
+AnsibleForms si connette solo a ciò che configura un amministratore:
+
+| Connessione | Quando |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (login Microsoft e Graph) | Quando quel metodo di accesso è configurato |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Quando un modulo gira su quel runner |
+| Server Git | Quando è configurato un repository |
+| Server di posta, Slack, Teams, Telegram, webhook | Quando è configurato un canale di notifica |
+| HashiCorp Vault, CyberArk | Quando è configurato un archivio di segreti |
+| Un fornitore di modelli (Anthropic, OpenAI e altri) | Solo con l'[assistente chat](../chat/) attivo, che per impostazione predefinita è disattivato |
+| Host e API indicati nei moduli | Quando le espressioni di un modulo o un playbook li chiamano |
+| Server syslog | Quando è configurato l'inoltro dell'audit o dei log |
+
+---
+
+## I container
+
+Le immagini sono costruite per girare con il minimo dei privilegi possibile:
+
+* L'applicazione e l'ambiente di esecuzione girano con l'utente non privilegiato `node`, non come root.
+* Sono costruite su immagini Debian slim fissate per digest, vedi [Sviluppo sicuro](development.html#code-analysis-and-dependencies).
+* L'applicazione resta in ascolto su una sola porta, la 8000.
+
+Per i passi che mettono in sicurezza una nuova istanza, segui [Hardening](../security/hardening.html).
diff --git a/i18n/it/_security_assessment/security-assessment/reporting.md b/i18n/it/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..5cae454
--- /dev/null
+++ b/i18n/it/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Segnalare una vulnerabilità
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Segnalare una vulnerabilità
+{: .no_toc }
+
+Come segnalare in privato un problema di sicurezza, e cosa succede dopo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Segnalalo in privato
+
+AnsibleForms custodisce credenziali e token di vault, quindi non segnalare mai un problema di sicurezza in una issue pubblica:
+
+1. Apri **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: un advisory privato visibile solo ai maintainer.
+2. Se quella pagina non è disponibile per te, apri una normale issue che dica soltanto che hai una segnalazione di sicurezza e chieda
+   un canale privato: nessun dettaglio, nessun modo per riprodurlo, nessun numero di versione. Un maintainer apre un advisory privato e
+   ti invita.
+
+La policy completa è il [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) del repository.
+
+---
+
+## Cosa includere
+
+Più di queste informazioni contiene una segnalazione, più velocemente viene corretta:
+
+* Cosa ottiene un attaccante: i dati di un altro utente, un playbook che non potrebbe eseguire, l'host, o diritti di amministratore.
+* La versione, e come è distribuita: Docker, Kubernetes, o installata in modo nativo.
+* Un modo per riprodurlo, o la richiesta che lo innesca.
+* Se richiede un utente autenticato, e con quali [opzioni di ruolo](../config/roles.html).
+
+---
+
+## Cosa succede dopo
+
+Una segnalazione passa per lo stesso advisory privato dal primo messaggio alla pubblicazione:
+
+| Passo | Cosa ricevi |
+|---|---|
+| Presa in carico | La conferma che la segnalazione è arrivata, e se si riesce a riprodurla |
+| Accettata | Una correzione nella prossima release di ogni [versione supportata](development.html#supported-versions), e un advisory pubblicato che ti cita, a meno che tu preferisca non essere nominato |
+| Respinta | La motivazione, di solito che il comportamento richiede un permesso che chi l'ha segnalato aveva già |
+
+Una volta rilasciata la correzione, l'advisory viene pubblicato e compare in [Advisory di sicurezza](advisories.html).
+
+---
+
+## Ambito
+
+La policy traccia il confine dove lo traccia il modello dei ruoli:
+
+| Nell'ambito | Fuori ambito |
+|---|---|
+| Qualsiasi cosa un utente autenticato possa raggiungere oltre ciò che gli concede il suo ruolo | Risultati che richiedono che l'account admin sia già compromesso: un admin che esegue qualsiasi playbook è il prodotto stesso |
+| Qualsiasi cosa raggiungibile senza accedere | Report di scanner senza un impatto dimostrato |
+| Credenziali salvate che diventano leggibili, o scritte in un log | |
+| Injection nella shell, nel database o nel browser | |
diff --git a/i18n/it/_use/designer/index.md b/i18n/it/_use/designer/index.md
new file mode 100644
index 0000000..b8e0c99
--- /dev/null
+++ b/i18n/it/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Designer
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Designer
+{: .no_toc }
+
+Modificare moduli, playbook, inventari e workflow nel browser
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per chi scrive i moduli: le sezioni del designer, e cosa mostra ciascuna delle loro schede.
+
+Il designer richiede l'[opzione di ruolo](../config/roles.html#role-options) `showDesigner`. Modifica un elemento alla volta, un
+modulo, un playbook o un file di workflow, con le sue sezioni nel menu a sinistra. Ogni tipo di file richiede anche una propria opzione, tutte
+attive per impostazione predefinita: `allowPlaybookDesign` per i **Playbook**, `allowWorkflowDesign` per i **Workflow**,
+`allowInventoryDesign` per gli **Inventari** e `allowVarsFileDesign` per i **File di variabili**. Senza, la sua sezione è
+in sola lettura e il server rifiuta di salvare, creare, rimuovere o inviare con push i suoi file; moduli e workflow possono comunque sceglierli. I
+**Moduli**, le **Categorie** e le **Costanti** richiedono allo stesso modo `allowFormDesign`: senza, sono in sola lettura, e il server
+rifiuta di salvarli, di farne il pull o il push. Modifica una sola persona alla volta: vedi [Il blocco del designer](lock.html).
+
+---
+
+## Le sue sezioni
+
+Ogni sezione modifica un tipo di file, conservato in locale o in un [repository](../repositories/):
+
+| Sezione | Cosa modifica |
+|---|---|
+| **Moduli** | I file dei moduli |
+| **Categorie** | Le categorie di `config.yaml` |
+| **Costanti** | Le costanti di `config.yaml` |
+| **File di variabili** | I file di variabili caricati dai moduli |
+| **Playbook** | I playbook eseguiti da moduli e workflow |
+| **Inventari** | Gli inventari: `inventory.yaml`, `group_vars` e `host_vars` |
+| **Workflow** | I file di [workflow](../workflows/) |
+
+Le sezioni con file li elencano in un esploratore dei file e aprono il primo; una sezione che non ha ancora file lo dice. La
+sezione **Moduli** e ogni sezione di file hanno un pulsante **Nuovo file** per primo nella barra degli strumenti: negli Inventari crea un nuovo
+inventario, nei Workflow un nuovo workflow vuoto. La lente d'ingrandimento dell'esploratore apre una casella che filtra i suoi file per nome.
+
+La casella di ricerca sulla riga del titolo trova un testo nello YAML aperto: evidenzia ogni punto in cui compare. Funziona nella
+scheda **YAML**, una volta che il blocco del designer è tuo.
+
+---
+
+## Le sue schede
+
+Ogni sezione ha le stesse tre schede, tutte sullo stesso YAML: una modifica in una si vede nelle altre, e **Salva** la salva.
+
+- **YAML** è il file così com'è scritto.
+- **Visuale** lo modifica con dei campi. Cambiano solo le chiavi toccate da una modifica, così i commenti e il resto restano come sono scritti.
+- **Anteprima** mostra cosa fa, e non modifica nulla.
+
+Cosa mostrano le schede Visuale e Anteprima, sezione per sezione:
+
+| Sezione | Visuale | Anteprima |
+|---|---|---|
+| **Moduli** | Le impostazioni del modulo e i suoi campi, con elenchi dei playbook, inventari e workflow del designer | Il modulo com'è ora, modifiche non salvate comprese; il suo invio non esegue nulla |
+| **Categorie** | Le categorie come tabella, modificabile | Il menu della pagina Moduli, costruito a partire da esse |
+| **Costanti** | Le costanti come struttura ad albero, modificabile (una chiave si sposta con i tasti freccia) | Ogni costante con il suo riferimento, `$(NAME)`, da copiare, e i moduli che la usano |
+| **File di variabili** | Le variabili, modificabili | Ogni variabile con il suo riferimento in un playbook, {% raw %}`{{ name }}`{% endraw %}, da copiare, e i moduli che caricano il file |
+| **Playbook** | I play: per ogni play il nome, gli host, **Become**, **Raccogli facts** e i ruoli, e i suoi task, ognuno con il suo modulo e i suoi argomenti | La struttura del playbook: i suoi play, con host, ruoli e task, e i playbook che importa |
+| **Inventari** | I gruppi, i loro gruppi figli, i loro host, e le variabili impostate da ciascuno | L'inventario come albero, con i suoi `group_vars` e `host_vars` |
+| **Workflow** | Il grafo del workflow, per [modificarlo](../workflows/designer.html) | Una [prova a vuoto](../workflows/designer.html#trying-it-out): fai clic su un nodo per farlo fallire |
+
+Quando lo YAML non si riesce a leggere, le schede Visuale e Anteprima dicono perché, con **Mostra in YAML** per aprire lo YAML alla riga.
diff --git a/i18n/it/_use/designer/lock.md b/i18n/it/_use/designer/lock.md
new file mode 100644
index 0000000..b31419b
--- /dev/null
+++ b/i18n/it/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: Il blocco del designer
+parent: Designer
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# Il blocco del designer
+{: .no_toc }
+
+Modifica una sola persona alla volta
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Prendere il blocco
+
+Il designer è disattivato finché non lo attivi, con l'interruttore in alto a destra del designer. Attivarlo prende il
+blocco: da quel momento sei l'unico che può salvare, finché non lo disattivi di nuovo.
+
+Senza il blocco il designer mostra **Il designer non è attivo**, e non si può modificare nulla.
+
+I salvataggi non si sovrappongono mai: dalla 7.3.0, mentre è in corso un salvataggio, un push o un caricamento, un secondo **Salva** (un doppio clic, o Ctrl+S tenuto premuto) viene
+ignorato, così non può scrivere un secondo backup o un secondo commit in concorrenza con il primo.
+
+---
+
+## Quando ce l'ha qualcun altro
+
+Mentre un altro utente detiene il blocco, il designer mostra **Il designer è in uso da** quell'utente, e nient'altro: nessuna sezione,
+nessun file.
+
+L'interruttore appare attivo ma in grigio, con accanto **Bloccato da** e il nome dell'utente. Puoi prendere il blocco quando quell'utente
+disattiva il designer. Ogni designer aperto se ne accorge subito quando il blocco viene preso o liberato, senza ricaricare.
+
+Quando due utenti attivano il designer nello stesso momento, uno dei due ottiene il blocco. Dalla 7.3.0 l'altro vede chi lo detiene
+e ogni editor resta in sola lettura, così non si può digitare nulla che poi non si potrebbe salvare.
+
+---
+
+## Rilasciare il blocco di qualcuno
+
+Un amministratore può liberare un blocco detenuto da qualcun altro, per esempio quando è andato a casa lasciando il designer aperto.
+
+**Rilascia**, accanto a **Bloccato da**, compare solo agli amministratori. Chiede prima conferma: le modifiche non salvate dell'utente vanno perse.
+
+Dalla 7.3.0 l'utente il cui blocco è stato rilasciato viene avvisato, e gli viene detto da chi: **Il tuo blocco del designer è stato rilasciato da** e il nome dell'amministratore,
+con **Le modifiche non salvate non possono più essere salvate.** Il suo designer non riprende il blocco da solo; lo riattiva
+quando vuole continuare.
+
+---
+
+## Un blocco dimenticato
+
+Un blocco che nessuno usa si libera da solo, così nessuno resta in attesa di un designer che nessuno ha aperto.
+
+Il designer aperto di chi detiene il blocco continua a comunicare al server che è ancora lì. Quando il server non ne ha notizie da
+5 minuti, perché il browser è stato chiuso, il computer spento o la rete è caduta, il blocco torna libero. Quando
+chi lo deteneva torna al designer, riprende il blocco se nessun altro l'ha preso. Il rilascio da parte di un amministratore è l'eccezione: dopo di esso il
+blocco non viene ripreso.
diff --git a/i18n/it/_use/jobs/actions.md b/i18n/it/_use/jobs/actions.md
new file mode 100644
index 0000000..7c76343
--- /dev/null
+++ b/i18n/it/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Azioni sui job
+parent: Job
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Azioni sui job
+{: .no_toc }
+
+Avviare, interrompere, rilanciare, approvare o rifiutare, ed eliminare un job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avviare un job
+
+Ogni job parte da un modulo. Aprilo dalla pagina **Moduli**, compila i campi e premi **Invia**:
+
+1. Il modulo viene validato nel browser, e i valori dei campi vengono inviati al server.
+2. Il server crea il job e ne restituisce il numero; vengono eseguite le azioni [`onSubmit`](../forms/job-status-action.html) del modulo.
+3. L'output del job compare sotto il modulo e si aggiorna ogni due secondi finché il job non termina.
+
+Il job compare anche nella pagina **Job**, dove puoi seguirlo in seguito.
+
+### Chi può avviare un modulo
+
+Un modulo è elencato, e si può avviare, per gli utenti che hanno uno dei [ruoli](../config/roles.html) della sua lista `roles`.
+Il ruolo `default`, che ogni utente ha, rende un modulo disponibile a chiunque possa accedere.
+
+### Prima di inviare
+
+La barra sopra i campi offre alcuni strumenti, ognuno visibile solo quando il tuo ruolo lo consente:
+
+| Pulsante | Cosa fa | Opzione di ruolo |
+|---|---|---|
+| **Mostra variabili extra** | Mostra in anteprima le extravars che il job riceverà, mentre compili i campi | `showExtraVars` |
+| **verbose** | Esegue il job in modalità verbose | `allowVerboseMode` |
+| **Carica da archivio** | Compila i campi da un [job salvato](stored-jobs.html) | `allowStoredJobs` |
+| **Ricarica questo modulo** | Carica di nuovo il modulo, con i suoi valori predefiniti | nessuna |
+
+### Scelte al momento dell'avvio
+
+Un modulo può permettere ai suoi utenti di scegliere alcune opzioni di Ansible quando lo avviano, dichiarando un campo con un nome riservato. Il
+valore del campo prevale allora sull'impostazione del modulo stesso:
+
+| Nome del campo | Prevale su | Tipo di campo tipico |
+|---|---|---|
+| `__check__` | La modalità check, una prova a vuoto che non modifica nulla | `checkbox` |
+| `__diff__` | La modalità diff, che mostra cosa cambierebbe | `checkbox` |
+| `__limit__` | Gli host su cui gira il playbook | `text` o `enum` |
+| `__tags__` | I tag da eseguire | `text` o `enum` |
+| `__inventory__` | L'inventario | `enum` |
+| `__playbook__`, `__template__` | Il playbook, o il template AWX / AAP | `enum` |
+
+Per esempio, un modulo che offre una prova a vuoto e un limite sugli host:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+Il server accetta questi nomi solo da un modulo che li dichiara come campi, quindi un avvio dall'API non può aggiungerli
+da solo. Le proprietà su cui prevalgono sono descritte in [Moduli Ansible](../forms/ansible.html) e [Moduli AWX](../forms/awx.html).
+
+### Cosa può bloccare un avvio
+
+Un avvio non diventa sempre subito un job in esecuzione:
+
+* **Campi non validi** : il modulo non viene inviato, e ogni campo che non supera la validazione mostra il motivo.
+* **Validazione all'avvio** : con la [validazione all'avvio](../launch-validation/) impostata su `enforce`, il server controlla di nuovo i valori
+  e rifiuta un avvio che viola le regole del modulo.
+* **Approvazione** : un modulo con un [punto di approvazione](../forms/approval.html) crea il job, che poi resta in attesa con stato
+  `approve`; vedi [Approvare o rifiutare un job](#approve-or-reject-a-job).
+
+Quando il job termina, le [notifiche](../forms/notifications.html) del modulo inviano le loro email e i messaggi sui canali, e vengono eseguite le sue azioni
+sullo stato del job.
+
+### Altri modi per avviare un job
+
+Un modulo può avviare un job anche senza che una persona prema **Invia**:
+
+| Avviato da | Come | Pagina |
+|---|---|---|
+| Esecuzione posticipata o pianificazione cron | **Esegui più tardi (una volta)** o **Pianifica (ricorrente)** accanto a **Invia** | [Pianificazioni](schedules.html) |
+| Uno script o una pipeline | `POST /api/v2/job` con un token API | [Job nella REST API](../api/jobs.html) |
+| Un agente IA | Lo strumento `launch_job` del server MCP | [Strumenti MCP](../mcp/tools.html) |
+| Una conversazione | L'assistente chat compila il modulo e lo avvia | [Assistente chat](../chat/) |
+| Un job precedente | **Rilancia**, più sotto | [Rilanciare un job](#relaunch-a-job) |
+
+---
+
+## Interrompere un job
+
+**Interrompi** nel menu della riga (⋮) dell'elenco, o **Interrompi job** nella pagina del job, ferma un job con stato `running`. Dopo la conferma,
+AnsibleForms contrassegna il job per l'interruzione:
+
+* **`ansible`**: l'RTE ferma il processo del playbook (con tutti i suoi worker), e il job termina come `aborted` con
+  `... was aborted by the operator`. Un job ancora in attesa di un RTE libero viene interrotto prima di partire.
+* **Un job di template** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): AnsibleForms chiede al runner di annullare o fermare
+  il job, e il job termina come `aborted`. Quando il runner rifiuta, l'output mostra `Abort request denied`, seguito da
+  `reverting abort request`, e il job continua a girare. Una build Jenkins ancora in coda viene tolta dalla coda.
+* **`workflow`**: i job dei nodi in esecuzione vengono interrotti e non parte più nulla (vedi
+  [Eseguire un workflow](../workflows/running.html#abort)).
+* **`multistep`**: i passi non ancora partiti vengono saltati (`skipping: [Abort is requested]`), e il job principale
+  termina come `aborted`. Un passo già in esecuzione è un job a sé: aprilo e interrompilo per fermare anche quello.
+
+Puoi interrompere i tuoi job; un amministratore, o dalla 7.3.0 un utente il cui ruolo imposta `manageAllJobs`, può interrompere qualsiasi job. `showAllJobLogs` permette a un
+utente di vedere i job degli altri utenti, non di interromperli.
+
+---
+
+## Rilanciare un job
+
+**Rilancia** nel menu della riga (⋮) dell'elenco, o **Rilancia job** nella pagina del job, avvia un nuovo job a partire da uno terminato. È proposto su qualsiasi
+job che non sia né `running` né in attesa di approvazione, agli utenti il cui ruolo imposta l'opzione di ruolo `allowJobRelaunch`.
+
+La finestra di dialogo offre:
+
+* **Rilancia**: esegue di nuovo il job con i valori con cui era girato, come nuovo job a tuo nome.
+* **Modalità verbosa**: rilancia in modalità verbose; compare con l'opzione di ruolo `allowVerboseMode`.
+* **Modifica i valori prima di rilanciare**, poi **Modifica e rilancia**: apre il modulo precompilato con i valori del job, così puoi
+  modificarli prima di inviarlo.
+
+Un rilancio richiede inoltre che il modulo lo consenta (`allowRelaunch`, true per impostazione predefinita) e che il job sia **tuo**, a meno che
+tu non sia un amministratore o, dalla 7.3.0, abbia `manageAllJobs`; `showAllJobLogs`, che fino alla 7.2 permetteva di rilanciare qualsiasi job, ora non lo fa più. Come un rilancio viene controllato rispetto alle regole del modulo, e perché un modulo con un
+campo password può rifiutarlo, è descritto in [Rilancio](../launch-validation/relaunching.html).
+
+### Rilanciare con dati precompilati
+
+**Modifica e rilancia** apre il modulo con il parametro URL `prefillJobId`, che puoi usare anche in un tuo link:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+Il modulo carica i valori dei campi salvati con il job `61` e mostra `Modulo precompilato con i dati del job precedente #61`.
+Inviarlo avvia un nuovo job, controllato come qualsiasi altro avvio. La precompilazione segue le stesse regole di un rilancio:
+
+* **I campi password non vengono mai salvati**, quindi non vengono mai precompilati: inseriscili di nuovo. Nemmeno le costanti vengono salvate.
+* Serve l'opzione di ruolo `allowJobRelaunch`, e il job deve essere tuo (oppure sei un amministratore o hai `manageAllJobs`).
+* Un modulo con `allowRelaunch: false` non può essere rilanciato né precompilato:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Un job precedente al salvataggio dei valori dei campi non può essere precompilato, e il modulo mostra invece un errore:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Approvare o rifiutare un job
+
+Un job con un [punto di approvazione](../forms/approval.html) si ferma con stato `approve` e resta in attesa. È elencato nella pagina Job dei
+suoi approvatori, gli utenti con uno dei ruoli dell'approvazione, così possono trovarlo; dalla 7.3.0 gli altri utenti non lo vedono più.
+
+**Esamina approvazione** è proposto agli amministratori e agli utenti che hanno uno dei ruoli dell'approvazione: un clic sulla riga del job,
+**Esamina approvazione** nel menu della riga, o il pulsante **Esamina approvazione** nella pagina del job. La finestra di dialogo mostra il
+messaggio dell'approvazione, con i valori del job inseriti (o una riga generica se non ce n'è uno), e il modulo, l'id del job, chi l'ha avviato e
+quando, con un link al job; **Rifiuta** e **Approva** rispondono:
+
+* **Approva**: il job prosegue e il suo stato torna a `running`.
+* **Rifiuta**: il job termina come `rejected`, e il suo output registra `rejected by <username>`.
+
+Un job in attesa di approvazione non si può rilanciare né eliminare dalla pagina Job; prima approvalo o rifiutalo.
+
+Dalla 7.3.0 l'utente che ha avviato un job non può approvarlo, così lo esamina sempre una seconda persona, anche se può comunque rifiutarlo per
+ritirarlo. Un amministratore può sempre approvare, compresi i propri job. Un modulo il cui punto di approvazione imposta
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) permette anche a chi l'ha avviato di approvare il proprio job.
+
+---
+
+## Eliminare un job
+
+**Elimina** nel menu della riga (⋮) dell'elenco, o **Elimina job** nella pagina del job, elimina un job con il suo output dopo la conferma.
+Eliminare un job multistep elimina anche i suoi passi. Per eliminare più job insieme, selezionali nella prima colonna dell'elenco e
+fai clic su **Elimina (n)** sopra di essa.
+
+Puoi eliminare i tuoi job. Gli amministratori e, dalla 7.3.0, gli utenti con l'opzione di ruolo `manageAllJobs` possono eliminare qualsiasi job; `showAllJobLogs`
+non lo permette più. Un ruolo che imposta `allowJobDeletion: false` non elimina alcun job, nemmeno i propri, così lo storico dei job resta completo. Nella pagina del
+job il pulsante è nascosto mentre il job è in esecuzione o in interruzione (tranne per gli amministratori e `manageAllJobs`) e mentre attende l'approvazione; nell'elenco, la
+voce del menu e la casella di selezione sono in grigio per un job che non puoi eliminare.
diff --git a/i18n/it/_use/jobs/cleanup.md b/i18n/it/_use/jobs/cleanup.md
new file mode 100644
index 0000000..dc1ff4c
--- /dev/null
+++ b/i18n/it/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Pulizia
+parent: Job
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Pulizia
+{: .no_toc }
+
+I job interrotti da un riavvio, e per quanto tempo vengono conservati i job terminati
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Job abbandonati
+
+Un job in esecuzione viene seguito dal processo AnsibleForms che l'ha avviato. Quando questo monitoraggio si interrompe, il job viene contrassegnato
+come `abandoned`:
+
+* **All'avvio**, i job che questo processo seguiva prima di riavviarsi, e i job precedenti alla 7 che nessun processo
+  segue, vengono contrassegnati come abbandonati se sono ancora `running` o in interruzione; il log mostra `Abandoned <n> jobs`. Un job che
+  gira su un RTE non viene toccato: prosegue senza il processo che l'ha avviato.
+* **Ogni minuto**, i job seguiti da un altro processo AnsibleForms (o RTE) che ha smesso di rispondere da 2 minuti vengono
+  contrassegnati come abbandonati; il log mostra `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Ogni ora**, i job partiti più di un giorno fa, ancora `running` e che non hanno scritto output per un giorno vengono contrassegnati come abbandonati.
+  Anche qui un job che gira su un RTE viene lasciato stare: l'RTE ripulisce i propri job quando si riavvia.
+
+Dalla 7.3.0 un job di template su AWX, AAP o Ascender abbandonato a causa di un riavvio o di un nodo fermo viene ripreso, se è partito
+nelle ultime 24 ore: un processo AnsibleForms lo prende in carico, lo segue di nuovo sul runner, e il job termina con ciò che
+è davvero successo lì. I job sugli altri runner, i playbook, i workflow e i job multistep restano abbandonati.
+
+Un playbook abbandonato potrebbe essere girato in parte. Controlla gli host gestiti prima di rilanciarlo; vedi
+[Un job mostra lo stato abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Conservazione dei job
+
+I job vengono conservati finché non vengono eliminati, a meno che l'amministratore non imposti un periodo di conservazione.
+
+Con [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) impostato, un'attività notturna (alle 2:30) elimina
+i job terminati, con il loro output e i loro passi, che sono finiti da più di quel numero di giorni. Rimuove solo i job con
+stato `success`, `failed`, `warning`, `aborted`, `rejected` o `abandoned`, quindi i job in esecuzione e quelli in attesa di
+approvazione vengono conservati per quanto vecchi siano. Il valore predefinito, `0`, conserva ogni job.
diff --git a/i18n/it/_use/jobs/following.md b/i18n/it/_use/jobs/following.md
new file mode 100644
index 0000000..b6b9d59
--- /dev/null
+++ b/i18n/it/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Seguire un job
+parent: Job
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Seguire un job
+{: .no_toc }
+
+Output in diretta, extravars, filtri e download
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Seguire un job
+
+Facendo clic su un job si apre la sua pagina: il modulo del job come titolo, le sue azioni nell'intestazione e il suo output sotto.
+
+![L'output di un job](../assets/screenshots/job-output.jpg)
+
+Dalla 7.3.0 la pagina è fatta di schede, e ognuna si richiude sotto la propria intestazione:
+
+| Scheda | Cosa mostra |
+|---|---|
+| **Riepilogo** | Il nome, lo stato e il tipo del job come intestazione, e sotto i suoi dati in una griglia di tre colonne (due, poi una, su una pagina stretta) |
+| **Workflow** | Per un job di workflow, anche un job di workflow AWX o AAP, il suo grafo e il numero dei suoi nodi (vedi [Il grafo del workflow](#the-workflow-graph)) |
+| **Output** | L'output del job e la sua barra degli strumenti |
+
+Un job girato su AWX, AAP, Ascender, Jenkins, Semaphore o Rundeck mostra lì il suo numero come link alla sua pagina in quello strumento, aperta
+in una nuova scheda. Il link resta salvato sul job, quindi funziona ancora quando il runner viene rinominato o rimosso in seguito.
+
+La pagina si aggiorna in diretta: il server invia un evento ogni volta che un job viene avviato, cambia stato, scrive output o viene
+eliminato, e la pagina rilegge il job, così l'output cresce man mano che il job lo scrive. L'elenco dei job si aggiorna allo stesso modo.
+**Aggiorna** ricarica il job a mano.
+
+Mentre sei alla fine dell'output, la pagina lo segue verso il basso man mano che arrivano nuove righe. Scorri verso l'alto per leggere una riga precedente
+e la pagina resta dove sei: compare allora **Vai alle ultime** sopra la parte bassa dell'output, che diventa **Nuove righe** quando ne
+sono arrivate altre. Fai clic, o scorri di nuovo fino alla fine, per seguire di nuovo le nuove righe. L'output nella pagina del modulo, dopo
+**Invia**, e il [log del server](../production/logs.html) seguono le loro nuove righe allo stesso modo.
+
+La barra degli strumenti dell'output contiene:
+
+| Pulsante | Cosa fa |
+|---|---|
+| **Mostra variabili extra** | Mostra le extravars con cui è girato il job in un pannello sopra l'output, con un selettore **JSON** / **YAML** e **Copia** |
+| **Mostra artefatti** | Mostra gli artefatti del job nello stesso pannello (vedi sotto) |
+| **Mostra i parametri** | Prende il posto di **Mostra variabili extra** per un job Jenkins: i valori con cui è girato, i suoi parametri di build |
+| **Mostra payload** | Prende il posto di **Mostra variabili extra** per un job Rundeck: il payload che gli è stato inviato |
+| **Host e task** | Mostra gli host e i task di un playbook sopra il suo output (vedi [Host e task](#hosts-and-tasks)) |
+| **Aggiorna** | Ricarica l'output |
+| **Applica filtro** | Nasconde i task il cui nome corrisponde al filtro dell'output; **Rimuovi filtro** li mostra di nuovo |
+| **Copia l'output** | Copia l'output come testo semplice, con o senza il filtro applicato |
+| **Scarica l'output** | Scarica l'output come `ansibleforms-job-<id>.txt` |
+
+**Mostra artefatti** è proposto per ogni job che non sia un job di template, come un playbook sull'RTE o un workflow (vuoto quando
+i suoi playbook non hanno raccolto artefatti con `set_stats`), e per un job di template girato su AWX, AAP o Ascender. I job Semaphore, Rundeck
+e Jenkins non hanno artefatti, quindi per loro non viene mai proposto.
+
+A sinistra della barra degli strumenti, il pulsante **Comprimi tutto** richiude ogni sezione dell'output (ogni play e task) e diventa
+**Espandi tutto**, che le riapre.
+
+**Mostra variabili extra** richiede l'opzione di ruolo `showExtravars` e **Mostra artefatti** l'opzione di ruolo `showArtifacts` (vedi
+[opzioni di ruolo](../config/roles.html#role-options)). I valori dei campi password e delle chiavi che corrispondono a
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) vengono mascherati.
+
+Il filtro si imposta con [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), `\[low\]` per
+impostazione predefinita. Metti `[low]` nel nome di un task rumoroso, e **Applica filtro** nasconde quel task e le sue righe.
+
+La pagina di un job multistep mostra ogni passo sotto il job principale, uno sotto l'altro, ognuno sotto una barra del titolo come
+**Passo 1 · Prepare the server (id job 98)** con il suo stato. Fai clic su un titolo (o premi Invio o Spazio su di esso) per richiudere quell'output,
+e di nuovo per riaprirlo. Anche i workflow AWX/AAP mostrano lo stato dei loro nodi.
+
+I job di [workflow](../workflows/running.html#the-job) conservano l'output di ogni nodo nel proprio, sotto un'intestazione `WORKFLOW NODE` per
+ogni nodo; disegnano il loro grafo, in diretta, e un clic su un nodo ne apre l'output.
+
+---
+
+## Cercare un testo nell'output
+
+Dalla 7.3.0 la pagina del job ha una casella di ricerca, **Cerca nell'output**, sulla riga del titolo, a sinistra delle azioni del job.
+
+Ogni punto dell'output in cui compare il testo viene evidenziato, a prescindere da maiuscole e minuscole, e la pagina si sposta sul primo. **Invio** va
+al successivo, evidenziato più forte, e la barra degli strumenti indica quale su quanti (**2 di 4**), oppure **Non trovato**. La ricerca prima riapre l'output e
+le sue sezioni, e mentre il job gira vengono cercate anche le nuove righe, senza spostare la pagina.
+
+---
+
+## Muoversi in un output lungo
+
+Dalla 7.3.0 un output lungo, nella pagina del job e sotto un modulo dopo **Invia**, offre questi modi per percorrerlo:
+
+| Controllo | Cosa fa |
+|---|---|
+| Intestazioni fisse | L'intestazione di una sezione (un nodo di workflow, il playbook del job, un passo di un job multistep) resta in alto mentre le sue righe scorrono |
+| **2 falliti** | Conta i task falliti, escludendo gli errori che ad Ansible è stato detto di ignorare; ogni clic va al successivo, riaperto ed evidenziato. Senza task falliti, **1 errore** conta invece le righe di errore |
+| Numeri di riga | Ogni numero di riga è un link alla sua riga, come `#L45` nell'indirizzo: aprire quell'indirizzo scorre fino alla riga e la evidenzia |
+| Pulsanti su e giù | Compaiono in basso a destra quando la pagina è stata fatta scorrere, per tornare in cima o andare alla fine |
+| **In esecuzione** e **Interrompi** | Mentre il job gira, la barra della pagina del modulo resta fissa in fondo alla finestra, e **Interrompi** lì ferma subito il job |
+
+---
+
+## Risultati dei task
+
+Dalla 7.3.0 la riga del risultato di un host nell'output di un playbook apre quel risultato in una finestra di dialogo **Risultato del task**, come fa AWX.
+
+La riga, il corpo del risultato che la segue (`=> { ... }`) e l'errore stampato prima di un risultato fallito si evidenziano come un unico blocco al passaggio del mouse, e un
+clic apre la finestra di dialogo. Funziona nella pagina del job e sotto un modulo dopo **Invia**, per un playbook girato su un RTE 7.3.0 o
+successivo, perché il risultato viene dagli stessi eventi di [Host e task](#hosts-and-tasks). La finestra di dialogo ha queste schede:
+
+| Scheda | Cosa mostra |
+|---|---|
+| **Dettagli** | Lo stato, l'host, il play, il task, il modulo, l'elemento del ciclo, l'ora di avvio, la durata, il codice di uscita e il messaggio |
+| **JSON** e **YAML** | L'intero risultato del modulo, colorato e con le righe numerate |
+| **Output standard** ed **Errore standard** | Lo `stdout` e lo `stderr` del risultato, quando ci sono |
+
+L'intero risultato, e con esso le schede **JSON**, **YAML** e di output, viene salvato solo quando il job gira in modalità verbose, perché allora anche l'output
+lo mostra; altrimenti la finestra di dialogo mostra solo i dettagli. Anche in modalità verbose gli argomenti del modulo (`invocation`) vengono
+esclusi, i valori delle chiavi che sembrano segreti vengono mascherati, e un risultato viene troncato quando supera i 64 KB di JSON.
+
+---
+
+## Il grafo del workflow
+
+Dalla 7.3.0 il grafo di un workflow in esecuzione scorre per tenere in vista il nodo in esecuzione.
+
+Se sposti il grafo, resta dove l'hai messo, con un pulsante **Segui il nodo in esecuzione** per seguirlo di nuovo. Passando il mouse su un nodo
+compare la sua scheda con il nome completo e il nodo e i suoi collegamenti vengono messi in risalto, con il resto del grafo sfumato. Il grafo ha i pulsanti **Adatta allo
+schermo** e **Schermo intero**, e sotto un modulo dopo **Invia** un clic su un nodo ne apre l'output come nella pagina del job.
+
+---
+
+## Host e task
+
+Dalla 7.3.0, un job di playbook girato su un RTE 7.3.0 o successivo registra i suoi eventi strutturati accanto all'output testuale: ogni play, task
+e risultato per host, e il riepilogo finale. **Host e task**, nella barra degli strumenti dell'output, li mostra in un pannello sopra l'output, nella pagina del job e
+sotto un modulo dopo **Invia**. Viene proposto quando il job ha degli eventi, e il pannello viene riletto ogni pochi secondi mentre il job gira:
+
+| Vista | Cosa mostra |
+|---|---|
+| **Griglia** | Il riepilogo per host (ok, modificati, falliti, irraggiungibili, saltati, recuperati, ignorati), poi una griglia di host per task: ogni cella è colorata in base al risultato dell'host per quel task, con il messaggio e il tempo al passaggio del mouse, oppure *non eseguito* |
+| **Cronologia** | Ogni task come una barra, lunga quanto il tempo impiegato dall'host più lento, con il suo tempo in secondi e il totale |
+
+L'output testuale resta così com'è. Gli eventi vengono scritti dal plugin di callback `af_events` dell'RTE stesso, quindi il playbook non richiede modifiche.
diff --git a/i18n/it/_use/jobs/index.md b/i18n/it/_use/jobs/index.md
new file mode 100644
index 0000000..75700c4
--- /dev/null
+++ b/i18n/it/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Job
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Job
+{: .no_toc }
+
+Seguire, interrompere, rilanciare, approvare ed eliminare i job avviati dai tuoi moduli
+{: .fs-6 .fw-300 }
+
+---
+
+Per chiunque avvii moduli: che cos'è un job, dove trovarlo, e chi può vederlo.
+
+---
+
+## Che cos'è un job
+
+Un job è un'esecuzione di un modulo: AnsibleForms lo registra con il suo stato, le extravars e l'output non appena il modulo viene inviato.
+
+Ogni job conserva:
+
+* il **modulo** che ha eseguito e l'**utente** che l'ha avviato (con il tipo di utente, come `local` o `ldap`);
+* il suo **tipo di job** e il suo **stato**, e l'**ora di inizio** e l'**ora di fine**;
+* il suo **output**, le extravars e le credenziali con cui è girato, e i valori dei campi inseriti nel modulo.
+
+Un modulo multistep crea un job per il modulo e un job per ogni passo. I passi sono collegati al job principale ed elencati sotto di esso.
+
+Gli stessi job si possono avviare, seguire e gestire tramite la [REST API](../api/jobs.html).
+
+---
+
+## La pagina Job
+
+Il link **Job** nell'intestazione apre l'elenco di tutti i job, dal più recente (`/jobs/all`). La pagina e il suo link sono visibili agli utenti
+il cui ruolo imposta l'[opzione di ruolo](../config/roles.html#role-options) `showJobs`.
+
+![L'elenco dei job](../assets/screenshots/job-log.jpg)
+
+Il menu a sinistra ordina i job nel tempo, con il numero di job in ogni voce; una voce di stato filtra l'elenco su quello stato:
+
+| Sezione | Voce del menu | Mostra |
+|---|---|---|
+| **Passato** | **Riuscito** | I job con stato `success` |
+| | **Fallito** | I job con stato `failed` |
+| | **Interrotto** | I job con stato `aborted` |
+| | **Rifiutato** | I job con stato `rejected` |
+| | **Abbandonato** | I job con stato `abandoned` |
+| **Presente** | **In esecuzione** | I job con stato `running` |
+| | **In attesa di approvazione** | I job con stato `approve`; il contatore diventa arancione quando uno è in attesa |
+| **Futuro** | **Pianificati** | La pagina [Pianificazioni](schedules.html) (opzione di ruolo `allowScheduledJobs`) |
+| | **Salvati** | La pagina [Job salvati](stored-jobs.html) (opzione di ruolo `allowStoredJobs`) |
+
+Il menu non ha una voce per tutti i job: il link **Job** dell'intestazione li mostra tutti, compresi i job `warning`.
+
+Sopra la tabella, sulla riga del titolo:
+
+* la **casella di ricerca** mantiene i job le cui colonne visibili contengono il testo (senza distinzione tra maiuscole e minuscole), o uno dei cui passi lo ha come id
+  o come destinazione;
+* **Elimina** (con il numero di job selezionati) elimina insieme i job selezionati nella prima colonna;
+* **Colonne** mostra o nasconde le colonne `id`, `modulo`, `tipo job`, `stato`, `ora di inizio`, `ora di fine`, `durata` e `utente`;
+  la durata di un job in esecuzione aumenta in tempo reale;
+* **Aggiorna** ricarica l'elenco.
+
+L'elenco carica i job più recenti, tanti quanti ne indica l'impostazione [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)
+(**Impostazioni > Sistema > Generale**, scheda **Job**, `1000` per impostazione predefinita); le sue pagine, la ricerca e i filtri coprono quei job.
+
+Ogni colonna si può ordinare e ha un proprio campo di filtro. Un job multistep ha una freccia subito prima del suo `modulo` che espande
+i suoi passi; un clic sul resto di una riga apre il job.
+
+La campanella nell'intestazione conta i job in attesa della tua approvazione e apre l'elenco su **In attesa di approvazione**. Per gli utenti che possono vedere
+i runner, conta anche i [runner in attesa di approvazione](../runners/registration.html#approving-an-rte), gli RTE che hanno chiesto di unirsi,
+e apre **Connessioni > Runner** quando sono in attesa solo dei runner. Se sono in attesa entrambi, apre un menu, **Job in attesa di approvazione** e
+**Runner in attesa di approvazione**, ognuno con il suo contatore.
+
+---
+
+## Chi vede quali job
+
+I job che un utente vede dipendono dai suoi ruoli:
+
+| Utente | Vede |
+|---|---|
+| Admin (ruolo `admin`) | Tutti i job |
+| Opzione di ruolo `showAllJobLogs` | Tutti i job |
+| Opzione di ruolo `manageAllJobs` (dalla 7.3.0) | Tutti i job, e può interromperli, eliminarli e rilanciarli |
+| Qualsiasi altro utente | I propri job, e i job in attesa di un'approvazione che nomina uno dei suoi ruoli |
+
+Fino alla 7.2, ogni utente poteva aprire qualsiasi job in attesa di approvazione, extravars e output compresi; dalla 7.3.0 possono farlo solo il suo proprietario e i suoi
+approvatori. Vedere un job non concede tutte le azioni su di esso: interrompere, eliminare e rilanciare il job di un altro utente richiede un amministratore o
+`manageAllJobs`, e `showAllJobLogs` mostra soltanto i job. Per eliminare serve anche `allowJobDeletion` e per rilanciare `allowJobRelaunch`.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina dedicata:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Stati e tipi](statuses.html) | Tutti gli stati che un job può avere, e i tipi di job |
+| [Seguire un job](following.html) | Output in diretta, extravars, filtri e download |
+| [Azioni sui job](actions.html) | Avviare, interrompere, rilanciare, approvare o rifiutare, ed eliminare un job |
+| [Pianificazioni](schedules.html) | Eseguire un modulo più tardi o secondo una pianificazione cron, e gestire tutte le pianificazioni |
+| [Job salvati](stored-jobs.html) | Conservare i dati di un modulo per ricaricarli più tardi |
+| [Pulizia](cleanup.html) | I job interrotti da un riavvio, e per quanto tempo vengono conservati i job terminati |
diff --git a/i18n/it/_use/jobs/schedules.md b/i18n/it/_use/jobs/schedules.md
new file mode 100644
index 0000000..7fb837b
--- /dev/null
+++ b/i18n/it/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Pianificazioni
+parent: Job
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Pianificazioni
+{: .no_toc }
+
+Eseguire un modulo più tardi o secondo una pianificazione cron, e gestire tutte le pianificazioni
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le azioni del modulo
+
+Un modulo può fare di più che girare subito: il menu a tendina accanto al pulsante **Invia** contiene altre tre azioni.
+
+| Azione | Cosa fa | Opzione di ruolo |
+|---|---|---|
+| **Pianifica (ricorrente)** | Crea una pianificazione che esegue il modulo secondo un'espressione cron | `allowScheduledJobs` |
+| **Esegui più tardi (una volta)** | Crea una pianificazione che esegue il modulo una sola volta, alla data e all'ora che scegli | `allowPlannedJobs` |
+| **Salva** | Salva i valori dei campi, per ricaricarli nel modulo più tardi | `allowStoredJobs` |
+
+Un'azione la cui opzione di ruolo è disattivata non viene mostrata. Il modulo viene validato prima di ognuna di esse, come per **Invia**. Entrambe
+le azioni di pianificazione creano una voce nella pagina **Pianificazioni**; **Salva** crea una voce nella pagina **Job salvati**. La
+barra laterale della pagina [Job](./) le apre sotto **Futuro**, come **Pianificati** e **Salvati**. Le opzioni di ruolo sono descritte
+in [Opzioni di ruolo](../config/roles.html#role-options).
+
+{: .warning }
+> Considera `allowScheduledJobs` un'opzione di livello admin. Le sue pianificazioni non appartengono all'utente che le ha create: ogni utente
+> con l'opzione vede e può modificare tutte le pianificazioni. Una pianificazione del genere gira inoltre con diritti di admin, per qualsiasi modulo, qualunque sia
+> l'accesso di chi l'ha creata. Concedila solo a ruoli di cui ti fideresti come amministratori.
+
+{: .note }
+> **Esegui più tardi (una volta)** richiede solo `allowPlannedJobs`. Per un utente senza `allowScheduledJobs`, pianifica un'esecuzione **come quell'
+> utente**: il server verifica che l'utente possa eseguire il modulo, e il job gira come lui, di sua proprietà, quando arriva il momento
+> (vedi [Esecuzioni programmate](#planned-runs)).
+
+---
+
+## Pianificare un modulo
+
+Compila il modulo, poi apri il menu a tendina accanto a **Invia** e scegli una delle azioni di pianificazione.
+
+- **Pianifica (ricorrente)** apre **Crea pianificazione**: inserisci un **Nome** e un'**Espressione Cron** (il valore predefinito, `0 0 * * *`,
+  gira ogni giorno a mezzanotte), poi seleziona **Crea pianificazione**.
+- **Esegui più tardi (una volta)** apre **Esegui più tardi**: inserisci un **Nome** e scegli la data e l'ora in **Esegui alle**, poi seleziona
+  **Pianifica job**.
+
+Il nome deve essere univoco tra tutte le pianificazioni. La pianificazione conserva il nome del modulo e una copia delle extravars prodotte dal modulo
+in quel momento, scritte in YAML; ogni esecuzione usa quella copia, quindi modificala nella pagina **Pianificazioni** per cambiare ciò che riceve il job.
+
+![Pianificazioni](../assets/screenshots/schedules.jpg)
+
+---
+
+## La pagina Pianificazioni
+
+La pagina **Pianificazioni** elenca tutte le pianificazioni, con la colonna **Abilitato** dalla 7.3.0, e richiede `allowScheduledJobs`. Il menu di ogni riga offre:
+
+| Azione | Cosa fa |
+|---|---|
+| **Modifica** | Cambia il nome, il tipo, l'espressione cron o l'ora di esecuzione, il modulo e le variabili extra |
+| **Esegui ora** | Esegue subito la pianificazione, senza attendere la sua espressione cron o l'ora di esecuzione |
+| **Attiva** o **Disattiva** | Attiva o disattiva la pianificazione, a seconda del caso, come mostra la sua colonna **Abilitato** (dalla 7.3.0) |
+| **Elimina** | Rimuove la pianificazione; smette subito di girare |
+| **Ultimo output** | Nella pagina della pianificazione, ciò che ha riportato l'ultima esecuzione, come il numero del job che ha avviato |
+
+Qui si può anche creare una pianificazione da zero. Scegli il **Modulo**, poi spunta **Esecuzione una tantum** e imposta
+**Esegui alle**, oppure lascialo vuoto e imposta una **Pianificazione** cron. **Variabili extra** è YAML senza un modulo che lo compili, quindi aggiungi tu i
+valori di cui il playbook ha bisogno, come dizionario (coppie chiave: valore).
+
+Il campo **Pianificazione** è un editor cron: descrive l'espressione a parole, offre preimpostazioni e mostra in anteprima le prossime
+esecuzioni. Il server rifiuta un'espressione che non può eseguire, o una che non può mai verificarsi.
+
+Dalla 7.3.0 ogni pianificazione ha un interruttore **Abilitato**, per metterla in pausa senza eliminarla. Una pianificazione disattivata resta nella pagina
+con le sue impostazioni, ma non gira da sola: una ricorrente salta i suoi scatti cron, e una una tantum attende oltre il suo
+**Esegui alle** finché non viene riattivata. **Esegui ora** la esegue comunque su richiesta. Una nuova pianificazione è attiva, e le pianificazioni
+esistenti prima della 7.3.0 sono attive dopo l'aggiornamento.
+
+---
+
+## Espressioni cron e fuso orario
+
+Una pianificazione ricorrente accetta un'espressione cron standard a 5 campi: minuto, ora, giorno del mese, mese e giorno della settimana.
+
+| Espressione | Gira |
+|---|---|
+| `*/15 * * * *` | Ogni 15 minuti |
+| `0 2 * * *` | Ogni giorno alle 02:00 |
+| `30 7 * * 1-5` | Dal lunedì al venerdì alle 07:30 |
+| `0 0 1 * *` | A mezzanotte del primo giorno di ogni mese |
+
+Altri esempi, e le funzionalità cron che l'editor non accetta, sono nelle FAQ alla voce
+[Quali espressioni cron posso usare?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Le pianificazioni cron girano nel fuso orario del server, impostato con [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (predefinito `UTC`),
+> non nel fuso orario del tuo profilo o del tuo browser. L'editor cron mostra in anteprima le prossime esecuzioni in quello stesso fuso.
+
+---
+
+## Come gira una pianificazione
+
+Quando una pianificazione è dovuta, viene messa in coda, e il server avvia le pianificazioni in coda una alla volta, controllando la coda ogni 10 secondi.
+
+- Le pianificazioni **ricorrenti** saltano uno scatto mentre l'esecuzione precedente è ancora in coda o in esecuzione, così le esecuzioni non si sovrappongono mai.
+- Le pianificazioni **una tantum** girano entro un minuto da **Esegui alle**, poi vengono eliminate, anche quando vengono avviate con **Esegui ora**.
+- **Stato** è `success` quando il job è stato avviato e `failed` quando non è stato possibile. Un `success` dice solo che il job è stato
+  avviato: apri il job per vedere come è finito.
+
+Una pianificazione creata con `allowScheduledJobs` gira come l'utente integrato `Schedule Service` (tipo `schedule`) con il
+ruolo `admin`. Può eseguire qualsiasi modulo, qualunque sia l'accesso della persona che ha creato la pianificazione, e `ansibleforms_user` nelle
+sue extravars descrive quell'utente. Un'[esecuzione programmata](#planned-runs) gira invece come l'utente che l'ha programmata.
+
+Il job riceve anche un oggetto `schedule` (con `id`, `name` e `form`), così un playbook sa che l'ha avviato una pianificazione:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Esecuzioni programmate
+
+**Esegui più tardi (una volta)** da parte di un utente senza `allowScheduledJobs` crea un'esecuzione programmata: una pianificazione una tantum legata a quell'utente.
+
+- **Quando viene programmata**, il server verifica che l'utente possa eseguire il modulo (i suoi `roles`), e la modalità verbose richiede
+  `allowVerboseMode`. Un'esecuzione programmata è sempre una tantum; un'espressione cron viene rifiutata.
+- **Con la validazione all'avvio in `enforce`**, i valori dei campi vengono controllati quando viene programmata, così un'esecuzione che verrebbe rifiutata viene
+  rifiutata mentre l'utente è ancora davanti allo schermo.
+- **Quando gira**, il job gira come quell'utente, di sua proprietà, con gli stessi controlli di un avvio dal browser: i
+  ruoli del modulo come sono in quel momento, le extravars riservate rimosse, e la validazione all'avvio. `ansibleforms_user` descrive l'utente.
+
+Chi programma non vede la pagina **Pianificazioni**, che richiede `allowScheduledJobs`; il job compare nel suo storico dei job.
+
+---
+
+## Quando il modulo cambia
+
+Una pianificazione fa riferimento al suo modulo per nome e lo esegue così com'è definito al momento di ogni esecuzione.
+
+- **Il modulo viene modificato**: l'esecuzione successiva usa la nuova definizione (playbook, template, inventario) con le extravars salvate nella
+  pianificazione. Il modulo non viene visualizzato, quindi nessun campo viene ricalcolato; modifica le variabili extra della pianificazione di conseguenza.
+- **Il modulo viene rinominato o rimosso**: l'esecuzione fallisce, **Stato** diventa `failed` e **Ultimo output** riporta
+  `Failed to launch : No such form '<name>'`. Modifica la pianificazione e scegli il modulo giusto, oppure eliminala.
+
+---
+
+## I job pianificati nello storico dei job
+
+Ogni esecuzione di una pianificazione crea un job normale, elencato nella pagina [Job](./) con `Schedule Service` come utente, oppure,
+per un'esecuzione programmata, con l'utente che l'ha programmata.
+
+Un job di `Schedule Service` non appartiene alla persona che ha creato la pianificazione, quindi è visibile solo agli amministratori e agli
+utenti con `showAllJobLogs`; il job di un'esecuzione programmata è visibile anche al suo utente. L'**Ultimo output** della pianificazione indica il job che ha avviato, così puoi trovarlo nell'elenco.
diff --git a/i18n/it/_use/jobs/statuses.md b/i18n/it/_use/jobs/statuses.md
new file mode 100644
index 0000000..79db6bd
--- /dev/null
+++ b/i18n/it/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Stati e tipi
+parent: Job
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Stati e tipi
+{: .no_toc }
+
+Tutti gli stati che un job può avere, e i tipi di job
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Stati dei job
+
+AnsibleForms imposta su un job gli stati seguenti. L'elenco mostra ogni stato come un'etichetta colorata:
+
+| Stato | Significato | Cosa puoi fare |
+|---|---|---|
+| `running` | Il job è in esecuzione, oppure un job approvato è ripartito | Seguirne l'output, interromperlo |
+| `approve` | Il job attende a un [punto di approvazione](../forms/approval.html) prima di girare (o prima che giri un passo di un multistep) | Approvarlo o rifiutarlo, se uno dei tuoi ruoli è approvatore |
+| `success` | Il playbook, il template o ogni passo è terminato senza errori | Vedere l'output, rilanciarlo, eliminarlo |
+| `failed` | Il job è terminato con un errore, oppure è fallito l'avvio stesso | Vedere l'output per capire perché, rilanciarlo, eliminarlo |
+| `warning` | Un multistep è terminato, ma un passo con `continue` impostato è fallito | Vedere l'output, rilanciarlo, eliminarlo |
+| `aborted` | Il job è stato interrotto da AnsibleForms, oppure il job AWX / AAP è stato annullato | Vedere l'output, rilanciarlo, eliminarlo |
+| `rejected` | Un approvatore ha rifiutato il job; non è mai stato eseguito | Vedere l'output, rilanciarlo, eliminarlo |
+| `abandoned` | AnsibleForms ha smesso di seguire il job (vedi [Job abbandonati](cleanup.html#abandoned-jobs)) | Controllare gli host gestiti, rilanciarlo, eliminarlo |
+
+`running` è blu, `success` verde e si legge **Riuscito**, e `failed` rosso. `approve` è arancione e si legge **In attesa di approvazione**,
+così un job che attende una persona si distingue da quelli fermi; `warning`, `aborted` e `rejected` sono ambra. `abandoned` è
+grigio: nessuno l'ha fermato, ciò che lo eseguiva non c'è più.
+
+---
+
+## Tipi di job
+
+Il tipo di job segue il `type` del modulo che ha avviato il job, come lo mostrano l'elenco e la pagina del job:
+
+| Tipo mostrato | Cosa gira |
+|---|---|
+| `ansible` | Un playbook Ansible, eseguito su un RTE |
+| `awx`, `aap`, `ascender` | Un modello di job o di workflow su AWX, AAP o Ascender |
+| `semaphore` | Un template su Semaphore UI |
+| `rundeck`, `jenkins` | Un job su Rundeck o Jenkins |
+| `workflow` | Un [workflow](../workflows/), i cui nodi playbook girano come job a sé sotto di esso |
+| `multistep` | Deprecato, usa `workflow`: una sequenza di passi, ognuno registrato come job a sé sotto il job principale |
+
+Un job di template viene salvato come job `awx` (anche nella REST API) e mostrato con il tipo di runner su cui è girato, qualunque nome gli
+desse il modulo: un modulo di tipo `awx` che gira su un runner AAP mostra `aap`.
+
+Vedi [Moduli Ansible](../forms/ansible.html), [Moduli AWX](../forms/awx.html), [Moduli workflow](../forms/workflow.html) e
+[Moduli multistep](../forms/multistep.html) per la parte relativa ai moduli.
diff --git a/i18n/it/_use/jobs/stored-jobs.md b/i18n/it/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..cce20a9
--- /dev/null
+++ b/i18n/it/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Job salvati
+parent: Job
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Job salvati
+{: .no_toc }
+
+Conservare i dati di un modulo per ricaricarli più tardi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Job salvati
+
+I job salvati conservano i valori di un modulo così puoi ricaricarli, invece di compilare ogni volta gli stessi campi.
+
+Per salvare, compila il modulo, apri il menu a tendina accanto a **Invia** e scegli **Salva**. In **Salva dati modulo**, inserisci un
+**Nome**, una **Descrizione** facoltativa e una data in **Scade il (opzionale)**, poi salva. I campi password e costante non vengono
+mai salvati. Un sottomodulo ha la stessa azione **Salva** accanto al suo pulsante **Salva**, e conserva i valori non completati senza
+validarli.
+
+Per caricare, seleziona **Carica da archivio** in cima al modulo. **Carica modulo salvato** elenca i tuoi job salvati per quel modulo, con
+le date di creazione e di scadenza; selezionane uno per compilare il modulo con i suoi valori. Non gira nulla finché non invii.
+
+I job salvati vengono conservati nel database di AnsibleForms (tabella `stored_jobs`), con il nome del modulo, il tuo utente come
+`<type>/<username>` (per esempio `local/admin`) e i valori in JSON. Un nome deve essere univoco per utente e modulo; salvarne
+un secondo con lo stesso nome fallisce con "A saved form with this name already exists".
+
+---
+
+## Gestire i job salvati
+
+La pagina **Job salvati** elenca i job salvati con il loro modulo, utente, data di creazione e di scadenza, e richiede `allowStoredJobs`.
+
+- **Modifica** apre la pagina del job salvato: i suoi **Dettagli** (nome, modulo, scadenza) e i suoi **Valori**, i valori dei
+  campi salvati in YAML, che lì si possono modificare e salvare.
+- **Apri nel modulo** apre il suo modulo con i valori salvati già compilati; non gira nulla finché non invii.
+- **Elimina** lo rimuove. Puoi eliminare i tuoi job salvati; gli utenti con `showSettings` possono eliminarne qualsiasi.
+- I job salvati con una data **Scade il** nel passato vengono eliminati automaticamente ogni giorno alle 04:00 (in `LOG_TZ`).
diff --git a/i18n/it/_use/profile/account.md b/i18n/it/_use/profile/account.md
new file mode 100644
index 0000000..55e8417
--- /dev/null
+++ b/i18n/it/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Account
+parent: Il tuo profilo
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Account
+{: .no_toc }
+
+Con quale utente hai effettuato l'accesso
+{: .fs-6 .fw-300 }
+
+---
+
+La vista Account mostra con quale utente hai effettuato l'accesso e cosa determina il tuo accesso:
+
+- **Nome utente** e **Tipo di accesso**: un account locale, LDAP, Microsoft Entra ID o OpenID Connect.
+- **Gruppi**: i gruppi che arrivano con il tuo accesso, come `local/admins` o `ldap/Domain Admins`.
+- **Ruoli**: i ruoli di `config.yaml` che corrispondono a quei gruppi e al tuo utente. Determinano
+  quali moduli vedi e quali opzioni hai.
diff --git a/i18n/it/_use/profile/api-token.md b/i18n/it/_use/profile/api-token.md
new file mode 100644
index 0000000..ca174f2
--- /dev/null
+++ b/i18n/it/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Token API
+parent: Il tuo profilo
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# Token API
+{: .no_toc }
+
+Creare un token per script e agenti IA
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Chi può crearne uno
+
+Un token di lunga durata permette agli script di chiamare l'API senza la tua password. Dalla 7.3.0 richiede l'opzione di ruolo `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Fino alla 7.2.0 l'opzione era solo `extendedTokenExpiration`. A un ruolo precedente alla 7.3.0 che imposta solo quell'opzione viene dato
+`allowApiTokens`, così mantiene i suoi token; con entrambe, si può creare anche un token che non scade mai. Vedi [Opzioni di ruolo](../config/roles.html#role-options).
+
+---
+
+## Creare un token
+
+**Nuovo token**, sulla riga del titolo di **Profilo > Token API**, apre un wizard in tre passi:
+
+1. **Dettagli**: un nome, per riconoscere il token nell'elenco, e per quanto tempo resta valido. Le scelte sono 30, 90, 180
+   o 365 giorni fino a [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 per impostazione predefinita), quel
+   massimo stesso, e **Non scade mai** con `extendedTokenExpiration`. Scegli il periodo più breve di cui il tuo script ha bisogno.
+2. **Conferma**: un account locale o LDAP inserisce la propria password, che non viene salvata nel token. Un account Microsoft Entra ID o
+   OIDC qui non ha una password: il suo token viene creato dalla sua sessione, che deve aver effettuato l'accesso al massimo 10 minuti
+   prima, quindi il provider potrebbe chiederti prima di accedere di nuovo.
+3. **Copia**: il token, mostrato **una sola volta**. Copialo con **Copia** e custodiscilo con la stessa cura di una password.
+
+Invia il token nell'header `Authorization` di ogni chiamata API:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Un token API non può crearne un altro. Il token di un account SSO porta con sé i ruoli del suo ultimo accesso: una modifica dei gruppi presso il
+provider di identità lo raggiunge solo quando accedi di nuovo e crei un nuovo token.
+
+---
+
+## I tuoi token
+
+I token che hai creato sono elencati con il loro nome e con quando ognuno è stato creato, quando scade e quando è stato usato l'ultima volta; **Revoca** nel menu di una riga ne termina uno.
+Un amministratore li vede e li revoca anche nella tua pagina in **Impostazioni > Utenti**. Un token termina alla scadenza, o prima:
+
+- **con una revoca**, dall'elenco;
+- **con un logout fatto con il token** (`POST /api/v2/auth/logout` con il token nell'header `Authorization`), che lo termina insieme
+  alla sessione in cui è stato creato;
+- **con un cambio di password**, che termina ogni token e sessione del tuo account creati prima di esso, e con il blocco del tuo account.
+
+Anche un token che non scade mai termina in questi casi. Uno script può anche richiedere da sé un token tramite l'API di login e
+il suo parametro `expiryDays` (`POST /api/v2/auth/login?expiryDays=90`, oppure `expiryDays=never`); un `expiryDays` più lungo viene ridotto
+a `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/it/_use/profile/index.md b/i18n/it/_use/profile/index.md
new file mode 100644
index 0000000..2da0267
--- /dev/null
+++ b/i18n/it/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: Il tuo profilo
+nav_order: 4
+description: Il tuo account, preferenze, password, permessi e token API
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# Il tuo profilo
+{: .no_toc }
+
+Il tuo account, preferenze, password, permessi e token API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Per ogni utente: il tuo account, le preferenze, la password, i permessi e i token API.
+
+Apri il tuo profilo dall'avatar in alto a destra: **Profilo**.
+
+---
+
+## Aprire una vista
+
+Il menu a sinistra elenca le viste del profilo in ordine alfabetico. Ogni vista ha un proprio indirizzo,
+così puoi collegarti direttamente a essa:
+
+| Vista | Indirizzo |
+|---|---|
+| Account | `/profile/account` |
+| Token API | `/profile/token` |
+| Password | `/profile/password` |
+| Permessi | `/profile/permissions` |
+| Preferenze | `/profile/preferences` |
+
+`/profile` da solo apre la prima vista del menu. Le viste che i tuoi ruoli non consentono sono nascoste; il loro indirizzo apre invece la prima
+vista. **Token API** viene mostrata solo quando uno dei tuoi ruoli ha l'opzione di ruolo `allowApiTokens`.
+
+---
+
+## In questa sezione
+
+Ogni argomento è descritto in una pagina dedicata:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Account](account.html) | Con quale utente hai effettuato l'accesso |
+| [Preferenze](preferences.html) | Lingua, tema, fuso orario, formato data e notifiche desktop |
+| [Password](password.html) | Cambiare la password di un account locale |
+| [Permessi](permissions.html) | Cosa ti permettono di fare i tuoi ruoli |
+| [Token API](api-token.html) | Creare un token per script e agenti IA |
diff --git a/i18n/it/_use/profile/password.md b/i18n/it/_use/profile/password.md
new file mode 100644
index 0000000..d1d89c6
--- /dev/null
+++ b/i18n/it/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Password
+parent: Il tuo profilo
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Password
+{: .no_toc }
+
+Cambiare la password di un account locale
+{: .fs-6 .fw-300 }
+
+---
+
+Inserisci la password attuale e quella nuova due volte, poi fai clic su **Cambia password**.
+
+Gli account LDAP, Entra ID e OpenID Connect cambiano invece la password presso quel provider.
diff --git a/i18n/it/_use/profile/permissions.md b/i18n/it/_use/profile/permissions.md
new file mode 100644
index 0000000..ce77054
--- /dev/null
+++ b/i18n/it/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Permessi
+parent: Il tuo profilo
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Permessi
+{: .no_toc }
+
+Cosa ti permettono di fare i tuoi ruoli
+{: .fs-6 .fw-300 }
+
+---
+
+Le opzioni di ruolo sono raggruppate in schede, ognuna con il numero di opzioni che hai, come `5/8`:
+
+| Scheda | Opzioni relative a |
+|---|---|
+| **Accesso e integrazioni** | L'accesso, l'assistente chat, il server MCP, il caricamento di file e i token API |
+| **Designer** | Aprire il designer, e modificare moduli, playbook, workflow, inventari e file di variabili |
+| **Job** | Vedere i job e le loro extravars o artefatti, rilanciare, eliminare, pianificare e salvare job |
+| **Impostazioni** | Le pagine delle impostazioni, i log, il registro di audit e i backup |
+| **Altro** | Un'opzione impostata a mano in un ruolo che non rientra in nessun'altra scheda; sempre l'ultima scheda |
+
+Le altre schede sono in ordine alfabetico. Ogni scheda è una tabella con le colonne **Impostazione** (l'opzione), **Descrizione**
+(cosa fa) e **Il tuo accesso**: **Consentito** o **Non consentito**. Un'opzione che vale a causa di un'altra lo dice
+sotto la sua descrizione: **Incluso in** un'opzione che hai la attiva, e **Richiede** un'opzione che non hai la tiene disattivata.
+
+Le opzioni vengono dalle `options` dei tuoi ruoli in `config.yaml`; la pagina [Ruoli](../config/roles.html) spiega come
+si combinano.
diff --git a/i18n/it/_use/profile/preferences.md b/i18n/it/_use/profile/preferences.md
new file mode 100644
index 0000000..53f132a
--- /dev/null
+++ b/i18n/it/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Preferenze
+parent: Il tuo profilo
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Preferenze
+{: .no_toc }
+
+Lingua, tema, fuso orario, formato data e notifiche desktop
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Le preferenze
+
+La vista Preferenze cambia l'aspetto di AnsibleForms per te. Ogni scelta viene salvata nel browser
+in cui la fai, quindi un altro browser o computer parte dai valori predefiniti.
+
+| Impostazione | Scelte | Si imposta anche da |
+|---|---|---|
+| Lingua | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (giapponese), 简体中文 (cinese semplificato) | la bandiera nell'intestazione |
+| Tema | Segui il browser, Chiaro, Scuro, o Colore (un'intestazione nel colore che scegli) | l'icona del sole nell'intestazione |
+| Vista dei form | Riquadri o Lista | il pulsante nella pagina Moduli |
+| Fuso orario | UTC, il fuso di questo browser, o qualsiasi fuso per nome | solo qui |
+| Formato data | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY` | solo qui |
+| Notifiche desktop | Attive o disattive | solo qui |
+
+Dalla 7.3.0 la vista è suddivisa in schede, ognuna con il proprio indirizzo (`/profile/preferences/<tab>`): **Aspetto** (lingua, tema e vista
+dei form), **Data e ora** (fuso orario e formato data) e **Notifiche**. La casella di ricerca sopra di esse elenca le impostazioni che corrispondono
+sotto il nome della loro scheda. Una scelta resta una bozza finché non premi **Salva**, e uscire dalla vista con una modifica non salvata chiede prima conferma.
+
+**Segui il browser** passa a chiaro o scuro come fa il browser, e cambia insieme a esso. È il tema predefinito dalla 7.3.0, a meno che il tuo
+amministratore non ne scelga un altro. Passando il mouse su un colore del tema **Colore**, qui o nel menu del tema dell'intestazione, si vede un'anteprima dell'app in quel
+colore, e il tema precedente torna quando il puntatore lascia la tavolozza; non cambia nulla finché non fai clic.
+
+---
+
+## Notifiche desktop
+
+Dalla 7.3.0 la scheda **Notifiche** attiva le notifiche desktop in questo browser, per gli utenti il cui ruolo imposta `showJobs`.
+
+Il browser chiede il permesso la prima volta. Quando blocca le notifiche per il sito, l'interruttore resta disattivato e spiega come
+consentirle, e un sito in semplice `http` non può mostrarle affatto. Una volta attive, arriva una notifica:
+
+| Quando | Cosa dice | Un clic su di essa |
+|---|---|---|
+| Un job che hai avviato termina | Il modulo e il suo esito, come *Patch Linux servers: Riuscito*, con il numero del job e la durata | Porta in primo piano la scheda su quel job |
+| Un job attende la tua approvazione | Il modulo, il numero del job e chi l'ha avviato, con i pulsanti **Approva** e **Rifiuta** | Apre i job in attesa di approvazione |
+
+I pulsanti **Approva** e **Rifiuta** compaiono in Chrome ed Edge; Firefox e Safari mostrano la notifica senza di essi, e lo stesso fa un
+sito con un certificato autofirmato, perché i pulsanti richiedono un service worker. Le notifiche arrivano solo mentre è aperta una scheda di AnsibleForms,
+anche in background: non viene inviato nulla una volta chiuse tutte le schede. Ognuna compare una sola volta, per quante schede siano aperte, e i passi di un
+job multistep e il job che stai guardando non generano notifiche.
+
+---
+
+## Fuso orario
+
+Date e orari in tutto AnsibleForms vengono mostrati nel fuso orario che selezioni. Questo comprende le ore di inizio
+e fine dei job, il registro di audit, la pagina di stato, i backup, i job salvati, e la scadenza di un token
+API. Cambiare il fuso orario aggiorna subito ogni pagina, senza ricaricare.
+
+Finché non ne scegli uno, vale il fuso orario impostato dal tuo amministratore per tutti (**Impostazioni > Aspetto > Valori predefiniti**, vedi
+[Aspetto](../appearance.html)), **UTC** se non è stato cambiato. **Questo browser** segue il fuso orario del tuo computer, e
+l'elenco contiene ogni fuso per nome, come `Europe/Madrid`. La scheda mostra l'ora corrente nel fuso e nel formato selezionati.
+
+---
+
+## Formato data
+
+Il formato data stabilisce come si legge la parte data di ogni data, con ogni scelta mostrata con la data di oggi: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` o `DD.MM.YYYY`. Finché non ne scegli uno, vale il formato data predefinito del tuo amministratore,
+`YYYY-MM-DD` se non è stato cambiato. Come le altre scelte, viene conservato in questo browser.
+
+---
+
+## Cosa mantiene gli orari del server
+
+Due eccezioni mantengono gli orari propri del server:
+
+- **Il log del server e l'output dei job** sono testo che contiene gli orari che il server vi ha scritto.
+- **Gli orari che inserisci**, come quando deve girare un job programmato, e le pianificazioni cron, funzionano come
+  prima.
diff --git a/i18n/it/_use/repositories/adding.md b/i18n/it/_use/repositories/adding.md
new file mode 100644
index 0000000..8ccb2b6
--- /dev/null
+++ b/i18n/it/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Aggiungere un repository
+parent: Repository Git
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Aggiungere un repository
+{: .no_toc }
+
+La pagina Repository, ogni campo di un repository, e come dichiararne uno nel config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## La pagina Repository
+
+I repository si gestiscono in **Impostazioni > Connessioni > Repository**, che richiede l'[opzione di ruolo](../config/roles.html#role-options) `showSettings` o, dalla 7.3.0,
+`showConnectionsSettings`. Alcune modifiche sono riservate a un amministratore, vedi [sotto](#who-may-change-a-repository).
+
+![Repository](../assets/screenshots/git.jpg)
+
+L'elenco mostra **Nome**, **Descrizione**, **Branch**, **Head** (l'hash breve del commit su cui è fatto il checkout), **Pull** e
+**Push**. La scheda **Dettagli** di un repository mostra gli stessi badge Pull e Push sopra il suo head:
+
+| Colonna | Cosa dice |
+|---|---|
+| **Pull** | L'ultimo clone, pull o reset: **In esecuzione** mentre git lavora, poi **Riuscito** o **Fallito**; un trattino prima del primo |
+| **Push** | **Fallito** quando l'ultimo push non è riuscito; **Modifiche in sospeso** quando le modifiche salvate qui, dal designer, non sono ancora state inviate al remoto; **Riuscito** quando non c'è nulla in attesa; un trattino prima del primo push |
+
+**Riuscito** nella colonna Push significa solo che non c'è nulla in attesa di push: il remoto potrebbe comunque contenere commit più recenti che un
+pull porta dentro. Il menu di ogni riga contiene queste azioni:
+
+| Azione | Cosa fa |
+|---|---|
+| **Modifica** | Cambia i campi qui sotto |
+| **Pull** | Clona il repository, o ne fa il pull quando la copia di lavoro esiste già |
+| **Push** | Fa il commit e il push della copia di lavoro; solo sui repository usati per moduli, configurazione, playbook, workflow o inventari, e attivo solo finché ci sono modifiche non ancora inviate |
+| **Reimposta** | Elimina la copia di lavoro e la clona di nuovo, scartando le modifiche locali |
+| **Modifica credenziali** | Apre la scheda **Credenziali** del repository, per scegliere la credenziale che usa git |
+| **Mostra output dell'ultimo pull** | Mostra l'output di git dell'ultimo clone, pull o reset, con la password mascherata |
+| **Mostra output dell'ultimo push** | Mostra l'output di git dell'ultimo push, con la password mascherata |
+| **Elimina** | Rimuove il record e la sua copia di lavoro sotto `REPO_PATH`; riservato a un amministratore |
+
+**Pull di tutti**, sopra l'elenco, fa il pull di tutti i repository in una volta.
+
+Su un repository gira una sola operazione git alla volta. Una seconda viene rifiutata con
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Aggiungere un repository
+
+Fai clic su **Aggiungi repository**: un wizard chiede i campi in quattro passi (**Repository**, **Credenziali**, **Utilizzo**, **Pianificazione
+del pull**), e AnsibleForms avvia il clone in background appena salvi.
+
+![Modifica repository](../assets/screenshots/git-edit.jpg)
+
+| Campo | Obbligatorio | Significato |
+|---|---|---|
+| **Nome** | sì | Il nome della cartella sotto `REPO_PATH`; lettere, cifre, trattino, trattino basso e punto |
+| **Branch** | sì | Il branch da clonare, da cui fare il pull e su cui fare il push, per esempio `main`; obbligatorio dalla 7.3.0. Solo un repository del config seed può ometterlo, per clonare il branch predefinito del remoto |
+| **Credenziale** | no | Una credenziale di [Connessioni > Credenziali](../credentials.html) con l'utente e la password o il token che usa git; **Aggiungi credenziale** ne crea una |
+| **URI** | sì | Il remoto, `https://...` o SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Attiva il pull pianificato** | no | Fa il pull del repository secondo una pianificazione |
+| **Pianificazione del pull** | no | Quando fare il pull, come espressione cron; compare quando il pull pianificato è attivo |
+| **Descrizione** | sì | Una descrizione a testo libero |
+| **Usare per configurazione?** ... **Usare per gli inventari?** | no | Cosa contiene il repository, vedi [sopra](./#what-a-repository-is-for) |
+| **Pull all'avvio dell'app** | no | Clona il repository, o ne fa il pull, ogni volta che AnsibleForms si avvia |
+
+Rinominare un repository sposta la sua copia di lavoro nella nuova cartella e sposta con essa la sua pianificazione del pull. Un repository di
+prima della 7 che ha ancora un proprio utente lo segnala nella sua scheda **Credenziali**: scegli una credenziale per sostituirlo.
+
+---
+
+## Chi può modificare un repository
+
+Il contenuto di un repository diventa ciò che AnsibleForms carica ed esegue, quindi dalla 7.3.0 un utente senza il ruolo `admin` non può più:
+
+- aggiungere o eliminare un repository;
+- cambiarne l'**URI** o il **Branch**;
+- attivare o disattivare uno qualsiasi dei suoi flag **Usare per**.
+
+Può comunque cambiarne la descrizione, la pianificazione del pull e la credenziale, e farne il pull, il push o il reset. Una credenziale usata da un runner,
+una connessione o un metodo di accesso non può essere scelta da lui; il rifiuto la nomina, e non dice nulla di ciò che contiene.
+
+---
+
+## Dichiarare repository nel config seed
+
+I repository si possono dichiarare anche nel [config seed](../seed/), così una nuova istanza li clona al primo avvio.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+I campi sono quelli della pagina, compresi `credential` (una credenziale del seed o dell'app), `rebase_on_start` (**Pull all'avvio
+dell'app**) e `cron` (la pianificazione del pull); `user` e `password` sono ancora accettati al posto di una credenziale. Un
+repository del seed è in sola lettura nell'interfaccia, e viene clonato di nuovo all'avvio quando manca la sua copia di lavoro; vedi
+[Oggetti gestiti](../seed/managed-objects.html).
diff --git a/i18n/it/_use/repositories/authentication.md b/i18n/it/_use/repositories/authentication.md
new file mode 100644
index 0000000..bc9bc66
--- /dev/null
+++ b/i18n/it/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Autenticazione
+parent: Repository Git
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Autenticazione
+{: .no_toc }
+
+HTTPS con un token, SSH con la chiave generata, e comandi git personalizzati
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Autenticazione
+
+Il modo in cui AnsibleForms si autentica dipende dalla forma dell'**URI**.
+
+### HTTPS con un token
+
+Per un remoto HTTPS privato, scegli una **Credenziale** il cui utente è l'utente git e la cui password è un personal access token
+(o la password).
+
+Dalla 7.3.0 git accede tramite `GIT_ASKPASS`: l'utente e il token vengono passati a ogni comando git che parla con il server, mai inseriti
+nell'URL, quindi non restano nel `.git/config` del clone e un token cambiato viene usato al pull o push successivo. Il token richiede
+accesso in lettura per il pull, e in scrittura per il push. Un remoto pubblico non richiede alcuna credenziale.
+
+Fino alla 7.2.0 entrambi venivano inseriti nell'URL, come `https://<user>:<token>@git.example.com/team/forms.git`. Un clone fatto allora mantiene
+quell'URL fino al suo pull o push successivo, che riporta il suo remoto all'**URI** del repository stesso.
+
+### SSH con la chiave generata
+
+Per un remoto SSH, AnsibleForms si autentica con una propria coppia di chiavi, che genera al primo avvio.
+
+1. Apri **Impostazioni > Connessioni > SSH**, nella scheda **Chiave**, e copia la **Chiave pubblica**.
+2. Aggiungila sul server git, come deploy key del repository (con accesso in scrittura se fai push), oppure a un utente che ha accesso.
+3. Aggiungi il repository con un **URI** SSH, per esempio `git@git.example.com:team/forms.git`, e non scegliere alcuna credenziale.
+
+La coppia di chiavi si trova in `.ssh/id_rsa` sotto [`HOME_PATH`](../customization/paths.html#env_HOME_PATH), quindi tieni quella cartella su
+uno storage persistente, altrimenti la chiave cambia quando il container viene ricreato.
+
+Su un clone con un URI `user@host:path`, AnsibleForms esegue prima `ssh-keyscan` sull'host e aggiunge la sua chiave agli
+host conosciuti. Per gli altri remoti, aggiungi l'host nella scheda **Host conosciuti** di **Impostazioni > Connessioni > SSH** prima del
+primo clone.
+
+### Comandi git personalizzati
+
+I comandi di clone, pull e push si possono sostituire, per esempio per aggiungere opzioni git, con tre impostazioni.
+
+| Impostazione | Predefinito | Cosa aggiunge AnsibleForms |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, l'URI e il nome |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+Dalla 7.3.0 questi comandi girano senza shell: gli apici funzionano, ma un operatore di shell come `;`, `|`, `&&` o `>` viene rifiutato.
diff --git a/i18n/it/_use/repositories/designer.md b/i18n/it/_use/repositories/designer.md
new file mode 100644
index 0000000..c82b55d
--- /dev/null
+++ b/i18n/it/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Designer e push
+parent: Repository Git
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Designer e push
+{: .no_toc }
+
+Modificare i moduli nel designer e inviarli al repository con push
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Modificare e fare il push dal designer
+
+Con un repository usato per i moduli, il designer modifica i file nella sua copia di lavoro e li invia di nuovo al remoto con push.
+
+| Pulsante | Cosa fa |
+|---|---|
+| **Salva (locale)** | Scrive i moduli e `config.yaml` nelle copie di lavoro, senza fare commit |
+| **Salva (repository)** | Fa il commit e il push delle modifiche salvate; attivo quando ci sono modifiche non ancora inviate |
+| **Carica (repository)** | Fa il pull dei repository dei moduli e ricarica il designer, dopo una conferma se ci sono modifiche non salvate |
+
+I moduli restano nel loro repository; quelli nuovi attendono, già utilizzabili, in [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) finché non fai il push.
+Un modulo salvato in una sottocartella mantiene il suo percorso relativo: `team/deploy.yaml` viene inviato in `team/deploy.yaml` sotto la cartella dei moduli
+del repository. Un nuovo modulo il cui percorso esiste già lì non viene sovrascritto; resta nello staging, quindi rinominalo.
+Con più repository di moduli, **Salva (repository)** e **Carica (repository)** chiedono quale, proponendo per primo quello con `config.yaml`.
+
+Un push mette in stage tutte le modifiche, ne fa il commit come `AnsibleForms` con il messaggio `Forms sync by <user>`, poi fa il fetch, il rebase sul
+remoto e il push, riprovando fino a cinque volte. Un conflitto di rebase viene annullato e i file in conflitto vengono elencati;
+correggili nel remoto, oppure usa **Reimposta** nella pagina Repository. **Push** nella pagina Repository fa la stessa cosa.
+
+Quando un unico repository di moduli viene clonato vuoto, AnsibleForms copia il `config.yaml` locale e i moduli nella sua copia
+di lavoro, così un push (**Salva (repository)**, o **Push** nella pagina Repository) li pubblica. Altro sul designer si trova in [Designer e git](../gui/designer-and-git.html).
diff --git a/i18n/it/_use/repositories/index.md b/i18n/it/_use/repositories/index.md
new file mode 100644
index 0000000..d0ff81f
--- /dev/null
+++ b/i18n/it/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Repository Git
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Repository Git
+{: .no_toc }
+
+Tenere moduli, file di variabili, configurazione e playbook in git
+{: .fs-6 .fw-300 }
+
+---
+
+Per gli amministratori che tengono moduli, configurazione e playbook in git: cosa può contenere un repository e quale sorgente prevale.
+
+---
+
+## A cosa serve un repository
+
+Un repository è un remote git che AnsibleForms clona e mantiene aggiornato, e ognuno ha degli interruttori che dicono cosa contiene:
+
+| Interruttore | Cosa ne legge AnsibleForms | Cartella nel repository |
+|---|---|---|
+| **Usare per configurazione?** | `config.yaml` con le categorie, i ruoli e le costanti | la radice |
+| **Usare per moduli?** | I file dei moduli, che il designer vi salva anche di nuovo, e i loro file di variabili | `forms`, o la radice; i file di variabili in `vars` |
+| **Usare per playbook?** | I playbook Ansible eseguiti dai job | `playbooks`, o la radice |
+| **Usare per i workflow?** | I file di [workflow](../workflows/), che il designer vi salva anche di nuovo | qualsiasi cartella |
+| **Usare per gli inventari?** | Un inventario, con il nome del repository, che un modulo indica con `inventory:` | la radice: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Senza la sottocartella, si usa la radice del repository. Un solo repository può contenere tutto; se li separi, solo **Usare per
+moduli**, **Usare per i workflow** e **Usare per gli inventari** possono essere attivi su più repository: gli altri interruttori prendono il primo repository
+e registrano un avviso nel log.
+
+Ogni repository viene clonato in una sottocartella con il suo nome, sotto [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Un repository per tutto
+
+Un unico repository può contenere moduli, file di variabili, configurazione e playbook, con gli interruttori attivi e una sottocartella per ogni tipo.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Un repository per ogni scopo
+
+Repository separati permettono ai team di gestire la propria parte, con un interruttore ciascuno e i file direttamente nella radice.
+
+| Repository | Interruttore | Contenuto nella radice |
+|---|---|---|
+| `af-config` | **Usare per configurazione?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Usare per moduli?** | I file dei moduli di ogni team, uniti in un unico elenco |
+| `af-playbooks` | **Usare per playbook?** | I playbook e i ruoli |
+
+Solo i moduli possono provenire da più repository; configurazione e playbook provengono ciascuno da uno solo. I file di variabili provengono dalla cartella `vars`
+del primo repository di moduli che ne ha una.
+
+---
+
+## Come si combinano i repository con le cartelle locali
+
+Il contenuto dei repository sostituisce la cartella locale corrispondente; questa tabella riassume da dove viene letto ogni tipo di file.
+
+| Contenuto | Letto da, vince la prima corrispondenza |
+|---|---|
+| Configurazione | 1. il database, quando la configurazione è conservata lì ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. `config.yaml` del repository **Usare per configurazione** <br> 3. `config.yaml` di un repository **Usare per moduli**, quando nessun repository è usato per la configurazione <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Moduli | Ogni repository **Usare per moduli** più `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) solo quando non ce n'è nessuno |
+| Playbook | Il repository **Usare per playbook**, altrimenti [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| File di variabili | La cartella `vars` del primo repository **Usare per moduli** che ne ha una, altrimenti [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflow | Ogni repository **Usare per i workflow** più [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), insieme |
+
+I moduli di più repository vengono uniti in un unico elenco. Quando due di essi contengono un modulo con lo stesso nome, viene mantenuto il primo
+caricato e viene registrato l'avviso `skipping duplicate form <name>`, quindi mantieni i nomi dei moduli univoci tra i repository.
+
+---
+
+## Risoluzione dei problemi
+
+La maggior parte dei problemi si vede nella colonna **Pull** e in **Mostra output dell'ultimo pull** (o **Mostra output dell'ultimo push**), che contengono il messaggio
+di errore di git stesso.
+
+- [Il clone o il pull di un repository non è riuscito](../troubleshooting.html#a-repository-clone-or-pull-failed): autenticazione, host
+  conosciuti e modifiche locali.
+- [Il repository dei moduli non è ancora stato clonato](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): il designer
+  non può salvare prima del primo clone.
+- Un repository bloccato in `running` viene riportato a `failed`: dopo un riavvio, all'avvio successivo; entro un minuto quando il nodo
+  che esegue la sua operazione git smette di rispondere per 2 minuti; e in ogni caso dopo 2 ore. Esegui di nuovo **Pull**.
+
+---
+
+## In questa sezione
+
+Ogni argomento ha una pagina dedicata:
+
+| Pagina | Cosa tratta |
+|---|---|
+| [Aggiungere un repository](adding.html) | La pagina Repository, ogni campo di un repository, e come dichiararne uno nel config seed |
+| [Autenticazione](authentication.html) | HTTPS con un token, SSH con la chiave generata, e comandi git personalizzati |
+| [Fare il pull delle modifiche](pulling.html) | Pull pianificati, manuali e via API, e modifiche locali |
+| [Designer e push](designer.html) | Modificare i moduli nel designer e inviarli al repository con push |
diff --git a/i18n/it/_use/repositories/pulling.md b/i18n/it/_use/repositories/pulling.md
new file mode 100644
index 0000000..f7c650c
--- /dev/null
+++ b/i18n/it/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Fare il pull delle modifiche
+parent: Repository Git
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Fare il pull delle modifiche
+{: .no_toc }
+
+Pull pianificati, manuali e via API, e modifiche locali
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fare il pull delle modifiche
+
+Il pull di un repository avviene secondo la sua pianificazione, all'avvio, dalla pagina, o tramite l'API; non esiste un endpoint per i webhook.
+
+| Attivazione | Come |
+|---|---|
+| Pianificazione | **Attiva il pull pianificato** e una **Pianificazione del pull**, per esempio `0 * * * *` per ogni ora |
+| Avvio | **Pull all'avvio dell'app** clona il repository, o ne fa il pull se è già clonato |
+| Pagina delle impostazioni | **Pull** nel menu della riga, o **Pull di tutti** sopra l'elenco |
+| Designer | **Carica (repository)**, che fa il pull dei repository dei moduli e ricarica il designer; anche prendere il blocco del designer fa prima il pull di ogni repository di moduli |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` o `showConnectionsSettings`) oppure `POST /api/v2/forms-repos/pull/<name>` (vedi sotto) |
+
+### Pull da una pipeline o da un webhook
+
+AnsibleForms non ha un ricevitore di webhook dedicato, ma un job di CI o un webhook del server git può chiamare l'endpoint di pull.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Crea il token come descritto in [Token API](../profile/api-token.html), per un utente il cui ruolo ha `showSettings` o
+`showConnectionsSettings`. `/api/v2/forms-repos/pull/<name>` richiede invece `showDesigner` e `allowFormDesign`, con il designer
+attivo ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` restituisce
+`head`, `status` e `output`, così una pipeline può verificare quale commit esegue l'istanza dopo un pull.
+
+### Modifiche locali
+
+Un pull non sovrascrive mai il lavoro non ancora inviato con push, quindi un pull pianificato controlla la copia di lavoro prima di girare.
+
+Un pull pianificato viene saltato finché la copia di lavoro ha modifiche non committate o commit non inviati, e finché un designer
+detiene il blocco del designer. Un pull manuale di una copia di lavoro con modifiche in conflitto fallisce con:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Invia le modifiche con push, oppure scartale con **Reimposta** nel menu della riga, che elimina la copia di lavoro e la clona di nuovo.
diff --git a/i18n/it/index.md b/i18n/it/index.md
new file mode 100644
index 0000000..6679fdb
--- /dev/null
+++ b/i18n/it/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Home
+nav_order: 1
+description: "AnsibleForms: crea moduli dinamici basati sui dati per l'automazione con Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Moduli self-service per <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible è un potente strumento di automazione, ma resta un'applicazione a riga di comando, e ad AWX/AAP/Ascender mancano
+      moduli che raccolgano dati da più sorgenti. AnsibleForms ti permette di costruire moduli dinamici basati sui dati, generare extravars
+      e inviarle ad Ansible, AWX/AAP/Ascender, Semaphore, Rundeck o Jenkins per eseguire lì i template.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">Installa AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">Crea il tuo primo modulo</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="La dashboard di AnsibleForms">
+  </div>
+</div>
+
+## Funzionalità
+
+Cosa porta AnsibleForms al tuo ambiente Ansible, e cosa può fare un singolo modulo:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Applicazione</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Piattaforme di automazione</strong><span>Playbook sugli RTE, template su Ascender, Semaphore e altro</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Controllo degli accessi</strong><span>Ruoli e opzioni di ruolo, con accesso locale, LDAP, Entra ID e OIDC</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Pianificazione</strong><span>Esegui un modulo più tardi, o secondo una pianificazione cron</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Storico dei job</strong><span>Segui, interrompi e rilancia i job</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Credenziali e segreti</strong><span>Salva le credenziali, o leggile da Vault o CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Repository Git</strong><span>Tieni moduli, playbook e configurazione in Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Designer</strong><span>Modifica i moduli in YAML, con validazione</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP e chat</strong><span>Avvia moduli da script, agenti IA o una chat</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Moduli</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Menu a tendina a cascata</strong><span>Menu a tendina che reagiscono ad altri campi</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Espressioni e sorgenti di dati</strong><span>Compila i campi da database, API REST, file e JavaScript</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dipendenze tra campi</strong><span>Mostra o nascondi campi in base ad altri campi</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validazione</strong><span>Min, max, regex e altro, facoltativamente controllati sul server</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflow e moduli wizard</strong><span>Concatena playbook e approvazioni, o suddividi l'input su più pagine</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Campi strutturati</strong><span>Liste e oggetti basati su sottomoduli riutilizzabili</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Punti di approvazione</strong><span>Metti in pausa un job finché qualcuno non lo approva</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Notifiche</strong><span>Mail, Slack, Teams, Telegram o un webhook sugli eventi dei job</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Serve aiuto?
+
+Domande, bug e segnalazioni di sicurezza hanno ciascuno il proprio posto:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Risoluzione dei problemi</strong>
+    <span>Cerca un messaggio di errore e come risolverlo</span>
+    <span class="af-card-more">Risoluzione dei problemi &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Fai una domanda</strong>
+    <span>Chiedi alla community e ai maintainer</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Segnala un bug</strong>
+    <span>Apri una issue con i passi per riprodurlo</span>
+    <span class="af-card-more">Nuova issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Ottenere aiuto</strong>
+    <span>Cosa includere, e come segnalare un problema di sicurezza</span>
+    <span class="af-card-more">Ottenere aiuto &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/ja.yml b/i18n/ja.yml
new file mode 100644
index 0000000..182d167
--- /dev/null
+++ b/i18n/ja.yml
@@ -0,0 +1,46 @@
+# The Japanese docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: ja
+docs_language: "ja"
+
+title: "AnsibleForms ドキュメント"
+description: "AnsibleForms の技術ドキュメント"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. All rights reserved."
+
+# "Edit this page on GitHub" opens the Japanese page's source
+gh_edit_link_text: "GitHub でこのページを編集"
+gh_edit_source: i18n/ja
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "はじめに"
+    get_started:
+      name: "クイックスタート"
+    configure:
+      name: "設定"
+    build_forms:
+      name: "フォームの作成"
+    use:
+      name: "ユーザーガイド"
+    integrate:
+      name: "連携"
+    security_assessment:
+      name: "セキュリティ"
+    reference:
+      name: "リファレンス"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (最新)"
+    url: "/ja/"
+  - name: "6"
+    title: "6.x (英語)"
+    url: "/v6/"
+
+# Search : full-width punctuation separates words too (the CJK pairing is in _includes/lunr/custom-index.js)
+search:
+  tokenizer_separator: /[\s/、。，．：；！？「」『』（）【】・]+/
diff --git a/i18n/ja/_build_forms/expressions/credentials.md b/i18n/ja/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..eab8aa5
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: 認証情報
+parent: 式
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# 認証情報
+{: .no_toc }
+
+式の中で保存された認証情報を読み取る
+{: .fs-6 .fw-300 }
+
+---
+
+保存された認証情報を、名前または正規表現で、フォールバック付きで読み取ります。
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+まず完全一致の名前が試されます。その名前の認証情報がない場合は、名前が正規表現として使われ、その後フォールバックが試されます。
+
+#### ロールによる制限
+
+ユーザーのロールのいずれかが `config.yaml` で `credentials` を列挙している場合、 `fn.fnCredentials` は、そのようなロールが許可する認証情報だけを
+返します。ロールのパターンは、(名前、正規表現、フォールバックのいずれかで) 見つかった認証情報の名前と照合され、
+それ以外は拒否されます。このリストを持たないロールは制限せず、管理者が制限されることはありません。
+
+#### シークレットストアの認証情報
+
+[シークレットストア](../secret-stores) を指定した認証情報は、実行時にそのストアから `user` と `password` を
+取得します。 `fn.fnCredentials('myapp')` はそのまま動作します。
+
+認証情報の名前を受け付ける場所であればどこでも ( `fnRestBasic`、 `fnRestJwtSecure`、 `fnRestAdvanced` のヘッダー置換を含む)、
+認証情報の行がなくてもシークレットを読み取れます。
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+シークレットのキーは、 [キー名](../secret-stores#key-names) で説明しているとおりに対応付けられます。
+形式の異なるシークレットは、3 番目の引数に `jq` 式を指定して整形します。
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/ja/_build_forms/expressions/index.md b/i18n/ja/_build_forms/expressions/index.md
new file mode 100644
index 0000000..fa73b9b
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: 式
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# 式
+{: .no_toc }
+
+ブラウザーまたはサーバーで、JavaScript を使ってフィールドの値を計算する
+{: .fs-6 .fw-300 }
+
+---
+
+フォーム作成者向け: ブラウザーで計算したり、サーバーで取得したりした値を JavaScript でフィールドに動的に入れる方法を説明します。
+
+フォームフィールドの `expression` 属性を使うと、JavaScript の式で動的なフォームを作成できます。
+
+---
+
+## はじめに
+
+`expression` 属性は、複数のフィールドの種類で使用できます。
+- `enum` フィールド: ドロップダウンの選択肢を動的に設定する
+- `expression` フィールド: あらゆる形式のデータを取得または生成する
+- `html` フィールド: HTML コンテンツを作成する
+- `yaml` フィールドと `list` フィールド: データを入れる
+
+JavaScript の式は、フィールドのプロパティ `runLocal` の設定に応じて、 **サーバー側** (既定) または **クライアント側** で評価されます。
+`html` フィールドと、フィールドの種類 `local`、 `local_out`、 `credential` は、 `runLocal` の設定にかかわらず、
+常にブラウザーで式を実行します。
+
+- **サーバー側** ( `runLocal: false`、既定): API、ファイル、データベースからデータを取得する定義済みの関数です。
+- **クライアント側** ( `runLocal: true` ): ブラウザーのサンドボックス内の完全な JavaScript エンジンを使って、計算、変換、操作を行うコードです。
+
+---
+
+## セキュリティ上の懸念
+
+式は JavaScript の `eval` 関数で評価されるため、コードインジェクションが懸念されます。
+
+- **サーバー側の式** は、まずサニタイザーを通ります。すべての呼び出しは `fn.` または `fnc.` の関数である必要があり、複数行、
+  `;`、テンプレートリテラル、 `process.env`、 `eval` から抜け出す手段 ( `import`、 `require`、 `constructor` など) は拒否されます。
+- **クライアント側の式** はブラウザーのサンドボックスで評価されるため、安全とみなせます。
+
+サニタイザーの厳しさは
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) で決まります。
+
+| 値 | サーバー側の式 |
+|---|---|
+| `strict` (既定) | `fn.` と `fnc.` の呼び出しと、 `fn.fnTime().format('YYYY')` のようなその結果に対するメソッド |
+| `paranoid` | `fn.` と `fnc.` の直接の呼び出しだけ。結果に対するメソッドは不可 |
+| `off` | サーバー側の式はすべて拒否されます。 `runLocal` の式だけが動作します |
+| `legacy` | 6.2.1 のルール。認証済みのユーザーなら誰でもサーバー上でコードを実行できます。アップグレード時専用で、実際の環境変数でのみ設定できます (設定ページからは不可) |
+
+空の値や不明な値は `strict` とみなされます。変更は再起動なしで、次の式から適用されます。
+
+---
+
+## このセクションの内容
+
+各トピックはそれぞれのページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [プレースホルダー](placeholders.html) | `$(...)` でほかのフィールド、定数、ユーザーを参照する |
+| [ローカル式](local.html) | ブラウザーのサンドボックスで実行される JavaScript |
+| [リモート式](remote.html) | 日付、ネットワーク、ファイル、SSH、連番の名前のためのサーバー側の関数 |
+| [REST API](rest-apis.html) | Basic、トークン、カスタム認証で REST API を呼び出す |
+| [認証情報](credentials.html) | 保存された認証情報を読み取る |
+| [並べ替え](sorting.html) | 並べ替えオブジェクトで配列を並べ替える |
+| [jq クエリ](jq.html) | jq でデータを整形する |
diff --git a/i18n/ja/_build_forms/expressions/jq.md b/i18n/ja/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..d8f3f44
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: jq クエリ
+parent: 式
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# jq クエリ
+{: .no_toc }
+
+組み込み関数を含め、jq でデータを整形する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## オブジェクトに JSON クエリ (jq) を実行する
+
+オブジェクト (たとえばほかのフィールドの値) を jq 式で整形します。
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+7.3.0 以降、jq フィルターは最大 [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (既定は 30) 秒実行されると
+停止され、出力は 64 MB までに制限されます。これは `fn.fnJq` と、REST、ファイル、認証情報、データベースクエリの各関数の
+jq 式に適用されます。
+
+---
+
+## 組み込みの jq 関数
+
+データを取得する関数はすべて、データオブジェクトや配列を操作するための言語である JSON クエリ (jq) を受け付けます。  
+データを操作するときには、バイトを KB、MB、GB に変換したり、数値を丸めたりする必要がある場合があります。  
+そのために、AnsibleForms にはいくつかのカスタム jq 関数が用意されています。
+
+- **fn2KB**: バイトを KB に変換
+- **fn2MB**: バイトを MB に変換
+- **fn2GB**: バイトを GB に変換
+- **fnRound0**: 小数点以下 0 桁に丸める
+- **fnRound1**: 小数点以下 1 桁に丸める
+- **fnRound2**: 小数点以下 2 桁に丸める
+- **fnRound**: 小数点以下 2 桁に丸める
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/ja/_build_forms/expressions/local.md b/i18n/ja/_build_forms/expressions/local.md
new file mode 100644
index 0000000..70cb5dd
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: ローカル式
+parent: 式
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# ローカル式
+{: .no_toc }
+
+ブラウザーのサンドボックスで実行される JavaScript
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+次の例は、フィールドのプロパティ `runLocal: true` で実行されます。  
+ブラウザーのサンドボックスで実行され、完全な JavaScript エンジンを利用できます。
+
+{: .note }
+> **ヒント**: 種類 `local` は `type: expression, runLocal: true, hide: true, output: false` の別名として使えます  
+> **ヒント**: 種類 `local_out` は `type: expression, runLocal: true, hide: true` の別名として使えます  
+
+---
+
+## 命名規則
+
+文字列操作を使って命名規則を適用します。
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## 計算
+
+数学関数を使って計算します。
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## 変換
+
+バイトをギガバイトに変換します。
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## オブジェクトの配列を HTML の表に変換する
+
+オブジェクトの配列 (たとえばほかのフィールドの値) を、 `html` フィールド用の HTML の表に変換します。
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## 連番付きの名前を取得する
+
+自動採番では、番号付きの文字列の配列から次の名前を求める必要がある場合があります。  
+この関数は、サーバー側の式としても ( `fn.` を付けて) 使用できます。
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+最初の引数が配列でない場合、ローカルの関数は既定値を返します。サーバーの関数 `fn.fnGetNumberedName` の場合は、
+代わりにエラーで失敗します。
+
+---
+
+## オブジェクトの配列の操作
+
+オブジェクトの配列は、絞り込み、変更、並べ替えが必要になることがよくあります。  
+AnsibleForms には、このコードを簡潔に保つためのカスタムヘルパーがあります。
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## 素の JavaScript によるオブジェクトの配列の操作
+
+`map`、 `forEach`、 `find`、 `filter`、 `reduce` など、JavaScript の標準の配列メソッドはすべて、データの絞り込みや変更に引き続き使用できます。
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/ja/_build_forms/expressions/placeholders.md b/i18n/ja/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..ee6b0fa
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: プレースホルダー
+parent: 式
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# プレースホルダー
+{: .no_toc }
+
+`$(...)` でほかのフィールド、定数、現在のユーザーを参照する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## プレースホルダーとは
+
+プレースホルダーは `$(reference)` の形式で書く参照です。それを含むテキストが使われる前に、値に置き換えられます。
+
+プレースホルダーは、フィールドの `expression`、 `query`、 `default` ( `evalDefault` で評価される場合) と、 `label`、
+`help`、 `placeholder` で使えます。プレースホルダーを含むフィールドは、そこで指定したフィールドに依存します。そのフィールドに
+値が入るまで待ち、その値が変わるたびに再評価されます。連動するドロップダウンはこのしくみで作ります。
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## プレースホルダーで参照できるもの
+
+プレースホルダーは、フォームのフィールド、またはすべてのフォームにある次のいずれかを指定します。
+
+| 参照 | 内容 |
+|---|---|
+| `$(field)` | フォームのほかのフィールドの値 |
+| `$(name)`、定数 | `config.yaml` の [定数](../config/constants.html)、またはフォームの `varsFiles` の値 |
+| `$(__user__)` | サインインしているユーザー: `username`、 `type`、 `groups`、 `roles` |
+| `$(__parent__.field)` | [サブフォーム](../forms/subform.html) (list の行、ウィザードのステップ) で、親フォームの値 |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## 値の一部を参照する
+
+パスが英字、数字、 `_`、 `-`、 `.`、 `[n]` だけで構成されていれば、ドット記法とインデックス記法で値の一部を読み取れます。
+
+| プレースホルダー | 対象 | 得られるもの |
+|---|---|---|
+| `$(field)` | text、number、password フィールド | 値 |
+| `$(field)` | レコードの enum | 選択したレコードの `placeholderColumn`、それがなければ最初の列 |
+| `$(field.col)` | レコードの enum | 選択したレコードのその列 |
+| `$(field)` | `multiple: true` の enum | 選択したすべてのレコードの選択された列を配列で |
+| `$(field)` | expression、list、定数 | 値全体 (list の場合はその行) |
+| `$(field.a.b)`、 `$(f[0].x)` | expression、list、定数 | オブジェクトまたは配列のその部分 |
+
+enum に `placeholderColumn: "*"` を設定すると、 `$(field)` は 1 つの列ではなく、選択したレコード全体を返します。
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## 値の埋め込み方
+
+値がテキストにどのように埋め込まれるかは、プレースホルダーの位置によって決まります。
+
+| 位置 | 例 | 結果 |
+|---|---|---|
+| 式の中、引用符の外 | `$(count) + 1` | JavaScript のリテラル。数値は数値のまま、テキストは引用符付きの文字列、オブジェクトや配列はリテラルになります |
+| 式の中、引用符で囲まれた文字列全体 | `fn.fnLs('$(dir)')` | 引用符を含めて同じリテラルになるため、引用符を含む値でも文字列から抜け出せません |
+| 式の中、より長い文字列の内部 | `'$(dir)/vars'` | その文字列用にエスケープされたテキスト |
+| クエリ、ラベル、ヘルプテキスト | `where city='$(city)'` | テキスト |
+
+プレースホルダーをまだすべて解決できないフィールドは評価されません。 `ignoreIncomplete: true` の場合は、代わりに不足している値が
+`undefined` として埋め込まれます。
+
+### 値に含まれるバッククォートと `${`
+
+7.3.0 以降、サーバーがフィールドの値を式に埋め込むとき (リモート式、起動時の検証、MCP、チャット)、その値がコードとして実行されることはありません。
+値に含まれるバッククォートや `${` は Unicode エスケープ ( `\u0060`、 `\u0024{` ) として書き込まれるため、
+テンプレートリテラルの中でもテキストのままです。サーバー側の式はテンプレートリテラル自体を拒否します。テンプレートリテラルには `runLocal` を使ってください。
+
+ブラウザーで評価される `runLocal` の式は、このエスケープを行わずに上の表のとおりに値を埋め込みます。そのため、そこでは
+テンプレートリテラルの中にプレースホルダーを置かないでください。
+
+---
+
+## 関連項目
+
+関連するページと FAQ の項目:
+
+- [ローカル式](local.html) と [リモート式](remote.html): ほとんどのプレースホルダーが使われる場所
+- [FAQ: 連動するドロップダウン](../faq.html#cascaded-dropdowns) と [フィールドのプレースホルダー](../faq.html#field-placeholders): その他の例
+- [FAQ: サブフォームの中で親フォームのデータにアクセスするには?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/ja/_build_forms/expressions/remote.md b/i18n/ja/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..160bce4
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: リモート式
+parent: 式
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# リモート式
+{: .no_toc }
+
+日付、ネットワーク、ファイル、SSH、連番の名前のためのサーバー側の関数
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+次の例は、フィールドのプロパティ `runLocal: false` (既定) で実行されます。  
+サーバー側で評価されます。
+
+サーバーでコードを評価することはセキュリティ上のリスクになるため、式はサニタイズされ、AnsibleForms に付属する関数と
+[自分で追加した関数](#your-own-functions) に制限されます。  
+サーバー側の式は、ファイル、REST API、SSH コマンドなどのデータソースから情報を取得するためのものです。
+
+{: .important }
+サーバー側の組み込み関数には `fn.` が付き (たとえば `fn.fnRestBasic` )、自分で追加した関数には `fnc.` が付きます。
+
+---
+
+## 日付と時刻を操作する
+
+[Day.js](https://day.js.org) で日付と時刻を扱います。
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## IP から CIDR の情報を取得する
+
+IP アドレスとネットマスクからサブネットを求め、どのアドレスがそこに属するかをチェックします。
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## SSH の出力を取得する
+
+SSH でリモートホスト上のコマンドを実行し、その出力を使います。
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## ディレクトリ内のファイルを一覧表示する
+
+AnsibleForms サーバー上のディレクトリのファイルを一覧表示します。必要に応じて再帰的に、絞り込んで表示できます。
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## HTML ページを解析する
+
+HTML ページを取得し、正規表現に一致する部分を抽出します。
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+ページは REST 関数と同じく、 [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) と
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) の制約のもとで取得されます。REST 関数とは異なり、
+`REST_IGNORE_CERTS` と `REST_TIMEOUT_SECONDS` は無視され、常に証明書をチェックし、最大 30 秒待ちます。
+
+---
+
+## DNS の情報を取得する
+
+ドメインの DNS レコードを解決します。
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## JSON ファイルを読み取る
+
+サーバー上の JSON ファイルを読み取ります。必要に応じて jq で絞り込めます。
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## YAML ファイルを読み取る
+
+サーバー上の YAML ファイルを読み取ります。必要に応じて jq で絞り込めます。
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## 連番付きの名前を取得する
+
+連番付きの文字列 (server001、server002 など) の配列から、次に使える名前を求める必要がある場合があります。  
+この関数は、ローカル式としても ( `fn.` を付けずに) 使用できます。
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+サーバーでは、最初の引数が配列でない場合、 `fn.fnGetNumberedName` はエラーで失敗します。ローカル式
+( `fn.` なし) の場合は、代わりに既定値を返します。
+
+---
+
+## 独自の関数
+
+独自の JavaScript 関数を `custom.js` に追加し、サーバーの式で `fnc.` を付けて呼び出します。
+
+このファイルは関数のオブジェクトをエクスポートします。イメージに同梱されているファイルには、2 つの例が含まれています。
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+同じように、 `jq.custom.definitions` には独自の jq の定義を置きます。これらはサーバーが実行するすべての jq クエリの先頭に
+追加されるため、どの関数の [jq クエリ](jq.html) からも使えます。
+
+コンテナーでは、両方のファイルをイメージ内のファイルの上にマップして再起動します。これらはサーバーの起動時に読み込まれます。
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> カスタム関数は、式から呼び出されるたびに、サーバープロセスの中でその権限で実行されます。
+> [サニタイザー](index.html#security-concerns) は、式が `fn.` と `fnc.` の関数だけを呼び出していることをチェックしますが、
+> 関数が引数をどう扱うかはお客様次第です。
diff --git a/i18n/ja/_build_forms/expressions/rest-apis.md b/i18n/ja/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..74c212c
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: REST API
+parent: 式
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# REST API
+{: .no_toc }
+
+Basic、トークン、カスタム認証で REST API を呼び出す
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Basic 認証による REST API
+
+保存された認証情報のユーザーとパスワードで REST API を呼び出します。
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## トークン認証による REST API
+
+式に記述した Bearer トークンで REST API を呼び出します。
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## 保護されたトークン認証による REST API
+
+保存された認証情報から取得した Bearer トークンで REST API を呼び出します。トークンがフォームに現れることはありません。
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## カスタムヘッダーによる REST API
+
+その他の種類の認証のために、独自のヘッダーで REST API を呼び出します。
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## 証明書とタイムアウト
+
+7.3.0 以降、すべての REST ヘルパー関数 ( `fnRestBasic`、 `fnRestAdvanced`、 `fnRestJwt`、 `fnRestJwtSecure` ) は、エンドポイントの TLS
+証明書をチェックし、一定時間が過ぎると待機をやめます。
+
+| 設定 | 変更される内容 |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` で証明書のチェックをスキップします。7.2.0 までは一度もチェックされていませんでした。 `0` のままにして、代わりに `NODE_EXTRA_CA_CERTS` でプライベート CA を信頼させてください |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | 呼び出しが応答を待つ時間。既定は 60 秒です。応答しないエンドポイントは、フィールドを止めたままにせず、フィールドを失敗させます |
+
+7.3.0 以降、エンドポイントが自己署名証明書を使うフィールドは、どちらかの設定を行うまで証明書エラーで失敗します。
+[REST 呼び出しと jq](../customization/security.html#rest-calls-and-jq) では、両方の設定と、すべての REST 呼び出しでまとめてプライベート CA を信頼させる方法を説明しています。
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) は REST ヘルパーではありません。両方の設定を無視し、常に
+証明書をチェックし、最大 30 秒待ちます。
diff --git a/i18n/ja/_build_forms/expressions/sorting.md b/i18n/ja/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..30ba9de
--- /dev/null
+++ b/i18n/ja/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: 並べ替え
+parent: 式
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# 並べ替え
+{: .no_toc }
+
+並べ替えオブジェクトで配列を並べ替える
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 配列を並べ替える
+
+式、REST API、データベースから得た配列を、並べ替えオブジェクトで並べ替えます。
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## 並べ替えオブジェクト
+
+REST 関数 ( `fn.fnRestBasic`、 `fn.fnRestAdvanced`、 `fn.fnRestJwt`、 `fn.fnRestJwtSecure` ) は、この並べ替えオブジェクトを
+引数として受け取ります。 `fn.fnJq` やファイルの読み取りなど、それ以外の結果は `fn.fnSort` で囲んでください。
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/ja/_build_forms/formfields/checkbox.md b/i18n/ja/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..aff11cf
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: フォームフィールド
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Checkbox フィールド
+{: .no_toc }
+
+オプションの有効化やフラグの設定に使う true または false の値です
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`checkbox` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`checkbox` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/datetime.md b/i18n/ja/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..0eec2cf
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: フォームフィールド
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Datetime フィールド
+{: .no_toc }
+
+日付、時刻、週、月、年を選択するピッカーです
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`datetime` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`datetime` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/enum.md b/i18n/ja/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..d638dcc
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: フォームフィールド
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Enum フィールド
+{: .no_toc }
+
+検索付きのドロップダウンで、単一選択にも複数選択にも使えます
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`enum` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`enum` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/expression.md b/i18n/ja/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..8da9ee5
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: フォームフィールド
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Expression フィールド
+{: .no_toc }
+
+ブラウザーまたはサーバー上の JavaScript で計算される値です
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`expression` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`expression` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/file.md b/i18n/ja/_build_forms/formfields/file.md
new file mode 100644
index 0000000..fbf3bd5
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: フォームフィールド
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# File フィールド
+{: .no_toc }
+
+設定ファイルや証明書などのファイルをアップロードします
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`file` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`file` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/html.md b/i18n/ja/_build_forms/formfields/html.md
new file mode 100644
index 0000000..a5b73f2
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: フォームフィールド
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Html フィールド
+{: .no_toc }
+
+フォーム内に表示するリッチな HTML コンテンツです
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`html` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`html` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/index.md b/i18n/ja/_build_forms/formfields/index.md
new file mode 100644
index 0000000..ca698f4
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: フォームフィールド
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# フォームフィールド
+{: .no_toc }
+
+フォームの入力コントロール
+{: .fs-6 .fw-300 }
+
+---
+
+フォーム作成者向け: フォームに配置できるフィールドの種類と、それぞれがサポートするプロパティを説明します。
+
+フォームフィールドは、フォームの入力コントロールを定義します。フィールドの種類ごとに、特定の種類のデータを収集するための独自のプロパティと動作があります。
+
+単純なテキストから構造化されたリストまで、収集したいデータに合ったフィールドの種類を選んでください。
+
+---
+
+## 共通プロパティ
+
+すべてのフォームフィールドには、次の 2 つの基本プロパティがあります。
+
+- **name** (string、必須): フィールドの一意な識別子
+- **type** (string、必須): フィールドの種類。使用できるプロパティを説明するページは、この値で決まります
+
+各フィールドの種類には、その機能に固有のプロパティが追加されます。ナビゲーションのサイドバーまたは下の表でフィールドの種類を選ぶと、プロパティの完全なリファレンスが開きます。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">フィールドの種類</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/ja/_build_forms/formfields/list.md b/i18n/ja/_build_forms/formfields/list.md
new file mode 100644
index 0000000..9c9f336
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: フォームフィールド
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# List フィールド
+{: .no_toc }
+
+行ごとにサブフォームで編集する、行の表です
+{: .fs-6 .fw-300 }
+
+---
+
+list フィールドは行の表を表示し、各行は専用の **サブフォーム** ペインで作成、編集します (ドリルダウン方式)。7.0.0 で削除された `table` フィールドに代わるものです。
+
+---
+
+## 主な機能
+
+list フィールドには次の機能があります。
+
+- 各行は全画面のサブフォームで編集するため、ネストしたリストを含むすべてのフィールドの種類を使用できます。
+- サブフォームは `subform` 型の独立したフォームであり、別々のフォームにある **複数の list フィールドで再利用** できます (たとえば、顧客、仕入先、注文などで 1 つの `Address` サブフォームを共有できます)。
+- マーカープロパティ (`insertMarker`、`updateMarker`、`deleteMarker`) により、冪等な playbook のパターンを実現できます。
+- `allowDelete: false` の場合、既存の行は保護されます。削除できるのは、現在のセッションで追加された行 ( `insertMarker` が付いた行) だけです。
+- `columns` プロパティで、サブフォームのどのフィールドを一覧表の列として表示するかを指定します。
+- 出力は常にオブジェクトの配列です。サブフォームのフィールドで宣言した `model`、`output`、`outputObject`、`valueColumn` は、extravars の生成時に反映されます。
+
+---
+
+## サブフォームの宣言
+
+サブフォームは `type: subform` を持つ独立したフォームで、ほかのフォームと同じようにフォームフォルダー内のファイルに置きます。ほかのフォームと同じ `fields` 配列を受け付けますが、フォームのタイル一覧には表示されず、直接送信されることもありません。
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## プロパティ
+
+`list` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>例</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## 例
+
+### 共有の住所サブフォーム
+
+同じフォームの 2 つの list フィールドで、1 つの `Address` サブフォームを再利用します。
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### マーカーによる追跡 (冪等性に対応)
+
+事前に読み込まれた行は保護され、どの行が新規、変更、削除なのかをマーカーで playbook に伝えます。
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### 行を事前に入力する
+
+list には 3 種類のソースから事前に値を入れられます。いずれの場合も、結果の行は、参照先サブフォームのフィールド名と一致するキーを持つオブジェクトである必要があります。
+
+#### 静的な `default`
+
+フォーム自体に記述した行です。
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### REST API から (`expression`)
+
+サーバー側の式で REST API から読み込んだ行です。
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### データベースクエリから (`dbConfig` + `query`)
+
+データベースクエリで読み込んだ行です。
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### ローカル式から (`runLocal`)
+
+ローカル式によってブラウザーで計算した行です。
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### ネストしたリスト
+
+サブフォーム自体に list フィールドを持たせて、各行の中にリストを入れられます。
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### `__parent__` で親フォームのデータを参照する
+
+サブフォームの行エディターが開くと、AnsibleForms はサブフォームに `__parent__` 変数を注入します。この変数には **親フォームのすべてのフィールド値** のスナップショットが入っており、定数や vars も含まれます。
+
+サブフォームのフィールド定義では、標準の `$(...)` 式の構文でこの変数を参照します。
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` は **フロントエンド専用** のヘルパーです。Ansible の extravars からは取り除かれ、playbook に送られることはありません。
+
diff --git a/i18n/ja/_build_forms/formfields/number.md b/i18n/ja/_build_forms/formfields/number.md
new file mode 100644
index 0000000..f2ba40e
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: フォームフィールド
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Number フィールド
+{: .no_toc }
+
+ポート番号や数量などの整数または小数の値です
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`number` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`number` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/password.md b/i18n/ja/_build_forms/formfields/password.md
new file mode 100644
index 0000000..d2bbfd8
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: フォームフィールド
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Password フィールド
+{: .no_toc }
+
+パスワード、シークレット、トークン用のマスクされた値です
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`password` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`password` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/radio.md b/i18n/ja/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..8db5ce3
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: フォームフィールド
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Radio フィールド
+{: .no_toc }
+
+互いに排他的な選択肢から 1 つを選びます
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`radio` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`radio` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/text.md b/i18n/ja/_build_forms/formfields/text.md
new file mode 100644
index 0000000..88faf8b
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: フォームフィールド
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Text フィールド
+{: .no_toc }
+
+名前やホスト名など、1 行のテキストです
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`text` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`text` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/textarea.md b/i18n/ja/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..b6e4114
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: フォームフィールド
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Textarea フィールド
+{: .no_toc }
+
+説明や設定の断片など、複数行のテキストです
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`textarea` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`textarea` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/ja/_build_forms/formfields/yaml.md b/i18n/ja/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..17ad66c
--- /dev/null
+++ b/i18n/ja/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: フォームフィールド
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# YAML フィールド
+{: .no_toc }
+
+検証とファイルインポートに対応した YAML エディターで扱う構造化データです
+{: .fs-6 .fw-300 }
+
+---
+
+## プロパティ
+
+`yaml` フィールドで使用できるプロパティを、用途別にまとめています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>値:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+`yaml` フィールドの YAML での例です。
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML でのフィールド定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## `__parent__` で親フォームのデータを参照する
+
+`yaml` フィールドが `subform` モードを使う場合、AnsibleForms はサブフォームに `__parent__` 変数を注入します。この変数には、エディターを開いた時点での **親フォームのすべてのフィールド値** のスナップショットが入っており、定数や vars も含まれます。
+
+サブフォームのフィールド定義では、標準の `$(...)` 式の構文でこの変数を参照します。
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` は **フロントエンド専用** のヘルパーです。Ansible の extravars からは取り除かれ、playbook に送られることはありません。
diff --git a/i18n/ja/_build_forms/forms/ansible.md b/i18n/ja/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..7cbfcd3
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Ansible フォーム
+parent: フォーム
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Ansible フォーム
+{: .no_toc }
+
+ローカルの Ansible playbook を実行するフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: ansible` に固有のプロパティです。
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/approval.md b/i18n/ja/_build_forms/forms/approval.md
new file mode 100644
index 0000000..a3d9227
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: 承認ポイント
+parent: フォーム
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# 承認ポイント
+{: .no_toc }
+
+誰かが承認するまでジョブを一時停止する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## しくみ
+
+承認ポイントは、承認者が応答するまで、フォーム内のその位置でジョブを一時停止します。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## 自分のジョブを承認する
+
+7.3.0 以降、ジョブを起動したユーザーは、承認のロールのいずれかを持っていてもそのジョブを承認できないため、2 人目の確認が必要になります。管理者は、自分のジョブも含めて常に承認できます。
+起動したユーザーは、自分のジョブを却下 (取り下げ) することはできます。起動したユーザーにも承認を許可する場合は、テスト用のフォームなどで `allowSelf: true` を設定します。
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## 属性
+
+承認ポイントの属性:
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{var.version}} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+承認ポイントの YAML での例です。
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML での定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/awx.md b/i18n/ja/_build_forms/forms/awx.md
new file mode 100644
index 0000000..8f39366
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: AWX フォーム
+parent: フォーム
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# AWX フォーム
+{: .no_toc }
+
+AWX、AAP、Ascender のジョブテンプレートを起動するフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: awx` に固有のプロパティです。
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/common.md b/i18n/ja/_build_forms/forms/common.md
new file mode 100644
index 0000000..6b8c116
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: 共通プロパティ
+parent: フォーム
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# フォームの共通プロパティ
+{: .no_toc }
+
+すべてのフォームの種類に共通するプロパティ
+{: .fs-6 .fw-300 }
+
+---
+
+これらのプロパティは **すべてのフォームの種類** に適用されます: `ansible`、 `awx`、 `aap`、 `ascender`、 `semaphore`、 `rundeck`、 `jenkins`、
+`workflow`、 `multistep` (非推奨)、 `subform` です。
+
+それ以外のプロパティは種類ごとに固有のもので、それぞれのフォームの種類のページで説明しています。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## プロパティ
+
+すべてのフォームの種類に共通するプロパティ:
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/ja/_build_forms/forms/index.md b/i18n/ja/_build_forms/forms/index.md
new file mode 100644
index 0000000..6b6289a
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: フォーム
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# フォーム
+{: .no_toc }
+
+ユーザーが入力するフォームを定義する
+{: .fs-6 .fw-300 }
+
+---
+
+フォーム作成者向け: フォームを YAML で書く方法、フォームの読み込み元、各フォームの種類のプロパティを説明します。
+
+フォームは AnsibleForms の中核です。各フォームはユーザーの入力を収集する Web インターフェイスで、そのデータを使って
+Ansible の playbook、AWX、AAP、Ascender のテンプレート、Semaphore のテンプレート、Rundeck や Jenkins のジョブ、または
+[ワークフロー](../workflows/) を実行します。
+
+フォームは、フォームフォルダー内の YAML ファイルで定義します。各 YAML ファイルには 1 つのフォームまたはフォームのリストを含め、サブフォルダーを使って整理できます。
+
+**動画**: [最初のフォームを作成する](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## フォームの構造を理解する
+
+AnsibleForms のフォームはすべて、一連のプロパティで構成されます。 **[共通プロパティ](common.html)** には、すべてのフォームの種類に適用されるプロパティが一覧表示されており、種類ごとのページではそれ以外のプロパティを説明しています。
+
+---
+
+## フォームの読み込み方
+
+AnsibleForms は次の場所からフォームを読み込みます。
+
+1. **リポジトリから** : 「フォームに使用」スイッチが有効なすべてのリポジトリ (複数のリポジトリに対応)
+   - 有効なすべてのリポジトリのフォームは自動的にまとめられます。
+   - 各リポジトリでは、まず `forms/` サブフォルダーがあるかどうかを確認します。
+   - `forms/` サブフォルダーがない場合は、リポジトリのルートが使われます。
+   - デザイナーで作成してまだプッシュしていないフォームは、ステージングフォルダー
+     ( [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) ) に置かれ、一緒に読み込まれます。
+
+2. **ローカルフォルダーから** : ローカルの `forms/` フォルダー
+   ( [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) )。「フォームに使用」が有効なリポジトリがない場合
+
+{: .warning }
+> **注:** 複数のリポジトリで「フォームに使用」を有効にすると、それらのフォームはすべてまとめられます。競合を避けるため、フォーム名はリポジトリ間で一意にする必要があります。
+
+---
+
+## フォームの実行場所
+
+フォームの種類によって、ジョブが実行される [ランナー](../runners.html) の種類が決まります。 `ansible` は RTE、 `awx`、
+`aap`、 `ascender` は AWX ランナー、 `semaphore`、 `rundeck`、 `jenkins` はそれぞれ同じ種類のランナーです。
+
+- フォームの `runner: <name>` で、その種類のランナーを名前で選びます。指定がない場合、ジョブはその種類のデフォルトのランナーで実行されます。
+- **接続 > ランナー** で無効にされたランナーでは、フォームで指定した場合でもデフォルトの場合でも、ジョブは失敗します。ジョブが
+  別のランナーにフォールバックすることはありません。
+- ユーザーのロールのいずれかが `config.yaml` で `runners` を列挙している場合、ジョブはそのようなロールが列挙したランナーでしか実行できず、それ以外は
+  拒否されます。このリストを持たないロールは制限せず、管理者が制限されることはありません。
+
+---
+
+## このセクションの内容
+
+次のページでフォームのプロパティを詳しく説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [共通プロパティ](common.html) | すべてのフォームの種類に適用されるプロパティ ( `name`、 `description`、 `help`、 `type`、 `fields` ) |
+| [Ansible フォーム](ansible.html) | `type: ansible` に固有のプロパティ |
+| [AWX フォーム](awx.html) | `type: awx` に固有のプロパティ |
+| [Semaphore フォーム](semaphore.html) | Semaphore のテンプレートを実行する `type: semaphore` に固有のプロパティ |
+| [Rundeck フォーム](rundeck.html) | Rundeck のジョブを実行する `type: rundeck` に固有のプロパティ |
+| [Jenkins フォーム](jenkins.html) | Jenkins のジョブをビルドする `type: jenkins` に固有のプロパティ |
+| [マルチステップフォーム](multistep.html) | `type: multistep` に固有のプロパティ。非推奨で、 `workflow` に置き換えられています |
+| [ワークフローフォーム](workflow.html) | [ワークフロー](../workflows/) を実行する `type: workflow` に固有のプロパティ |
+| [ウィザード](wizard.html) | フォームの入力を複数のページに分ける (実行可能などのフォームの種類にも重ねて使えます) |
+| [サブフォーム](subform.html) | サブフォームは共通プロパティだけを使います |
+| [承認ポイント](approval.html) | 承認されるまでジョブを一時停止する ( `approval` ) |
+| [通知](notifications.html) | ジョブのステータスやイベントに応じてメールやチャネルのメッセージを送信する ( `notifications` ) |
+| [ジョブステータスアクション](job-status-action.html) | ジョブのステータスが変わったときにフォームに対して処理を行う ( `onSubmit`、 `onSuccess` など) |
diff --git a/i18n/ja/_build_forms/forms/jenkins.md b/i18n/ja/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..d53935c
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Jenkins フォーム
+parent: フォーム
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Jenkins フォーム
+{: .no_toc }
+
+Jenkins のジョブをビルドするフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: jenkins` に固有のプロパティです。
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/job-status-action.md b/i18n/ja/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..0cd466e
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: ジョブステータスアクション
+parent: フォーム
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# ジョブステータスアクション
+{: .no_toc }
+
+ジョブが送信、成功、失敗、終了したときにフォームに対して処理を行う
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+次のフックを使用できます。
+
+- `onSubmit`: フォームが送信されたときに実行されます
+- `onSuccess`: ジョブが正常に完了したときに実行されます
+- `onFailure`: ジョブが失敗したときに実行されます
+- `onFinish`: ステータスにかかわらず、ジョブが終了したときに実行されます
+- `onAbort`: ジョブが中止されたときに実行されます
+
+---
+
+## 属性
+
+ジョブステータスアクションの属性:
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{var.version}} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+ジョブステータスアクションの YAML での例です。
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML での定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/multistep.md b/i18n/ja/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..93de51b
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: マルチステップフォーム
+parent: フォーム
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# マルチステップフォーム
+{: .no_toc }
+
+1 つのフォームから複数の playbook やテンプレートを順に実行する
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` はバージョン 7 から非推奨で、8 で削除されます。代わりに [ワークフロー](workflow.html) を使ってください。ワークフローは、
+> マルチステップでできることをすべて行え、さらに条件、ノードごとの独自の値、承認ノード、並行して実行される分岐も使えます。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## フォームレベルのプロパティ
+
+マルチステップフォームは、1 つのフォームレベルのプロパティでステップを定義します。
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / 必須</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+`steps` のほかに、マルチステップフォームは次のフォームレベルのプロパティを受け付けます。これらは [Ansible フォーム](ansible.html) のページで説明しています。
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (必須){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## ステップのプロパティ
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{var.version}} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">次の種類でのみ使用可能:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">追加</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        例
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+マルチステップフォームは複数のジョブを順に実行し、各ステップが独自の playbook または AWX テンプレートを起動します。すべてのステップはフォームのフィールドを共有します。既定では各ステップが extravars 全体を受け取り、ステップの `key` を指定するとその部分だけに限定されます。
+
+### サーバーを作成して設定する
+
+各ステップは extravars のそれぞれの部分を受け取ります。AWX のステップがサーバーを作成し、Ansible のステップがそのネットワークを設定し、最後のステップが常にレポートを送信します。
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/ja/_build_forms/forms/notifications.md b/i18n/ja/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..59d6680
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: 通知
+parent: フォーム
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# 通知
+{: .no_toc }
+
+ジョブが終了したとき、またはジョブに何かが起きたときに、メールやチャネルのメッセージを送信する
+{: .fs-6 .fw-300 }
+
+---
+
+フォームの `notifications` では、ジョブについて誰に、いつ知らせるかを指定します。
+
+- **誰に**: メールアドレスの `recipients` と、
+  [通知チャネル](../notification-channels.html) (メール、Slack、Microsoft Teams、Telegram、Webhook) の名前の `channels` です。2 つのうち
+  少なくとも一方が必要です。
+- **いつ**: ジョブが終了したとき ( `success`、 `failed`、 `aborted`、 `warning`、 `any` ) の `onStatus` と、ジョブに
+  何かが起きたとき ( `launch`、 `relaunch`、 `delete`、 `approve`、 `reject`、 `any` ) の `onEvent` です。
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## 属性
+
+`notifications` オブジェクトの属性:
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{var.version}} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 例
+
+通知の YAML での例です。
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}YAML での定義です。{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/rundeck.md b/i18n/ja/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..ed749fe
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Rundeck フォーム
+parent: フォーム
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Rundeck フォーム
+{: .no_toc }
+
+Rundeck のジョブを実行するフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: rundeck` に固有のプロパティです。
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/semaphore.md b/i18n/ja/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..f85fe66
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Semaphore フォーム
+parent: フォーム
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Semaphore フォーム
+{: .no_toc }
+
+Semaphore UI のテンプレートを実行するフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: semaphore` に固有のプロパティです。
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/forms/subform.md b/i18n/ja/_build_forms/forms/subform.md
new file mode 100644
index 0000000..70e0af2
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: サブフォーム
+parent: フォーム
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# サブフォーム
+{: .no_toc }
+
+list フィールド、yaml フィールド、ウィザードのページで使う、再利用可能なフォームの断片
+{: .fs-6 .fw-300 }
+
+---
+
+サブフォームは、再利用可能なフォームの断片です。タイル表示には表示されず、直接送信することもできません。代わりに、次のものから参照されます。
+
+- [`list`](../formfields/list.html) フィールド: 各行のドリルダウンエディターとしてサブフォームを開きます
+- `subform` プロパティを持つ [`yaml`](../formfields/yaml.html) フィールド: 1 つのオブジェクトのドリルダウンエディターとしてサブフォームを開きます
+- [`wizard`](wizard.html) のステップ: サブフォームをウィザードの 1 ページとして表示します
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+サブフォームには **種類に固有のプロパティはありません**。 [フォームの共通プロパティ](common.html) である `name`、 `description`、 `help`、 `type`、 `fields` だけを使います。
+
+サブフォームをウィザードのページとして使う場合、その `description` と `help` がステップの `title` と `help` の既定値になります。 `showHelp` を設定して、ページの読み込み時にそのヘルプを展開することもできます。
+
+実行に関するプロパティ ( `playbook`、 `template`、 `roles`、 `inventory` など) は、サブフォームには適用されません。サブフォームが直接送信されることはないためです。
+
diff --git a/i18n/ja/_build_forms/forms/wizard.md b/i18n/ja/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..533fe95
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: ウィザード
+parent: フォーム
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# ウィザード
+{: .no_toc }
+
+フォームの入力を、戻るボタンと次へボタンで移動する複数のページに分ける
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## ウィザードとは
+
+**ウィザード** は、1 つのフォームを一連のページに変えます。各ページは [`subform`](subform.html) から表示され、ユーザーは **戻る** ボタンと **次へ** ボタンで移動します。検証はページごとに行われ、ステップに `optional` が付いていない限り、現在のステップが有効になるまで先に進めません。
+
+すべてのウィザードの最後には、読み取り専用の **確認ページ** が自動的に追加されます。各ステップと収集した値が一覧表示されるため、ユーザーは送信前に内容を確認できます。確認ページは YAML では宣言 **しません**。タイトルは現在のロケールから取得されます。
+
+送信すると、 **すべてのステップで収集した値が 1 つの extravars のペイロードにまとめられ**、ユーザーが 1 つの大きなフォームに入力した場合とまったく同じように、基になる playbook、テンプレート、ワークフローに送信されます。
+
+`wizard` を持つフォームには独自の `fields` は不要ですが、 `enableForChat` は設定できません。また、 `subform` 自体が `wizard` を持つことはできません。 [起動時の検証](../launch-validation/rolling-it-out.html#wizard-forms) は、ウィザードの起動をステップごとにチェックします。
+
+{: .note }
+> `wizard` とワークフローの違いと、両者の組み合わせ方については、FAQ の項目 [ウィザードとワークフローの違いは何ですか?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) を参照してください。
+
+---
+
+## フォームレベルのプロパティ
+
+ウィザードは、1 つのフォームレベルのプロパティで有効にします。
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">バージョン {{ wizard_prop.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**例:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## ウィザードのステップのプロパティ
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必須</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 一意</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{var.version}} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">追加</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        例
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## ウィザードとワークフローを組み合わせる
+
+ウィザードは [ワークフロー](workflow.html) フォームの上に重ねられます。ウィザードの各ステップの `defaultModel` が、対応するワークフローノードの [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) と一致する場合、各 playbook やテンプレートは、それぞれのウィザードのページの値だけを受け取ります。
+
+FAQ には、具体的な例と、まとめられた extravars の構成が記載されています: [ウィザードとワークフローの違いは何ですか?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow)（*組み合わせ（ワークフローの上にウィザード）* のセクション）。
+
+非推奨の [`multistep`](multistep.html) フォーム上のウィザードも同じように動作し、 `extra_vars_key` の代わりにステップの [`key`](multistep.html#step_key) を使います。
+
+---
+
+## 関連項目
+
+関連するページと FAQ の項目:
+
+- [サブフォーム](subform.html): ウィザードのページはサブフォームから表示されます
+- [ワークフローフォーム](workflow.html): 実行層でウィザードに対応するもの
+- [サブフォームでの `__parent__`](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): 後のステップから前のウィザードのステップを参照する方法
diff --git a/i18n/ja/_build_forms/forms/workflow.md b/i18n/ja/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..69cb5f2
--- /dev/null
+++ b/i18n/ja/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: ワークフローフォーム
+parent: フォーム
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# ワークフローフォーム
+{: .no_toc }
+
+デザイナーのワークフローを実行するフォーム
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## プロパティ
+
+[フォームの共通プロパティ](common.html) に加えて、 `type: workflow` に固有のプロパティです。ワークフローファイル自体については
+[ワークフロー](../workflows/) のセクションで説明しています。
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>説明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必須</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">バージョン {{ var.version }} で追加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>選択肢:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (既定)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>既定値:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>例:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/ja/_build_forms/launch-validation/file-uploads.md b/i18n/ja/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..e8424a6
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: ファイルのアップロード
+parent: 起動時の検証
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# ファイルのアップロード
+{: .no_toc }
+
+file フィールドがどのように検証されるか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+file フィールドは、起動リクエストがファイルについて述べている内容を決して信頼しません。起動時の検証は、サーバーのディスク上の
+ファイル自体をチェックします。
+
+---
+
+## アップロードがジョブに届くまで
+
+ファイルは、フォームが起動される前に、2 つのステップでアップロードされます。
+
+1. ブラウザーが `POST /api/v2/job/upload` でファイルをアップロードします。サーバーはそれを `UPLOAD_PATH` に保存します。
+2. 起動リクエストの `files` 部分で、そのアップロードについて記述します。
+
+その後、起動時の検証がその記述をディスクと照合します。
+
+* ファイルは `UPLOAD_PATH` の中に存在する必要があります。
+* パスとサイズは、リクエストからではなく、常にディスクから読み取られます。
+
+---
+
+## 受け付けられるもの
+
+file フィールドが値を得るのは、検証済みのアップロードからだけです。それ以外はすべて破棄されます。
+
+* 呼び出し元が `rawFormData` や `extravars` に書き込んだパスは無視されます。
+* 実際のアップロードがない必須の file フィールドは、 `missing` として報告されます。
+
+---
+
+## ファイルのルール
+
+file フィールドのルールは、実際のアップロードに対してチェックされ、サイズはバイト単位です。
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` と `maxSize` はファイルの実際のサイズを、 `regex` はファイル名を比較します。フォームとは関係なく、
+`UPLOAD_MAX_GB` で 1 回のアップロードのサイズの上限 (既定は 10 GB) が決まります。
diff --git a/i18n/ja/_build_forms/launch-validation/index.md b/i18n/ja/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..995aaf6
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: 起動時の検証
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# 起動時の検証
+{: .no_toc }
+
+フォームのすべての起動をサーバーでチェックする
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者とフォーム作成者向け: 誰が送信したかにかかわらず、すべての起動について、そのルールと extravars をサーバーにチェックさせます。
+
+このチェックは、誰が、または何がフォームを起動したかにかかわらず適用されます。ブラウザー、REST API を呼び出すスクリプト、
+MCP サーバーを通じた AI エージェントのいずれでもです。
+
+---
+
+## 存在する理由
+
+フォームのルール ( `required`、 `regex`、 `minValue`、 `sameAs` など) は、これまでずっと
+ブラウザーでチェックされてきました。その後、ブラウザーは `POST /api/v2/job` に 2 つのものを送信します。
+
+- `rawFormData`: ユーザーが入力したとおりのフィールドの値
+- `extravars`: playbook が受け取るもの。ブラウザーでそれらの値から作成されます
+
+起動時の検証がない場合、サーバーはこの両方を信頼します。有効なトークンを持っていれば誰でもその
+エンドポイントを直接呼び出し、regex、必須フィールド、リストのルールを一切適用されずに、任意の extravars を
+送信できます。ブラウザーでしか使われないフォームであれば、それでも許容できるかもしれません。しかし、
+ほかのシステムが REST で起動するフォームでは、フォームのルールがまったく適用されないことになります。
+
+また、サーバーには、ブラウザーからのリクエストとスクリプトから送信されたリクエストを区別する方法がありません。
+どちらも同じエンドポイント、同じトークン、同じ本文を使い、ユーザーは自分のブラウザーが送信するリクエストを
+何でも変更できます。信頼できるチェックはサーバー上のものだけであり、起動時の検証がそのチェックです。
+
+---
+
+## 3 つの経路
+
+起動がどのように検証されるかは、起動がどの経路で届くかと、起動時の検証のモードによって決まります。
+
+| 起動元 | 検証 | ジョブが使う extravars |
+|---|---|---|
+| **MCP サーバー** (AI エージェント) | 常にサーバーで検証 | 常にサーバーが作成 |
+| **ブラウザー** または **REST API**、起動時の検証 `off` | ブラウザーでのみ検証 | ブラウザー (または呼び出し元) が送信したもの |
+| **ブラウザー** または **REST API**、起動時の検証 `log` | サーバーで検証、拒否はログに記録するだけ | 送信されたもの。差異はログに記録 |
+| **ブラウザー** または **REST API**、起動時の検証 `enforce` | サーバーで検証、無効な場合は拒否 | **サーバーが作成** |
+
+ブラウザー、MCP サーバー、起動時の検証は、ルールに同じコード (共有のフォームエンジン) を使います。
+同じルールを同じ順序で、同じメッセージとともに適用します。ブラウザーが表示するエラーは、サーバーでも同じテキストで拒否されます。
+
+---
+
+## このセクションの内容
+
+各トピックはそれぞれのページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [有効にする](switching-it-on.html) | インスタンス全体、または 1 つのフォームに対して |
+| [log と enforce](log-and-enforce.html) | ルールに反する起動を各モードがどう扱うか |
+| [リストの行](list-rows-and-subforms.html) | list フィールドの行がどのように検証されるか |
+| [ファイルのアップロード](file-uploads.html) | file フィールドがどのように検証されるか |
+| [パスワード](passwords.html) | password フィールドがどのように検証され、API から除外されるか |
+| [再起動](relaunching.html) | 再起動したジョブがどのように検証されるか |
+| [展開する](rolling-it-out.html) | インスタンスを enforce に移行する方法と、既知の制限 |
diff --git a/i18n/ja/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/ja/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..428b1a7
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: リストの行
+parent: 起動時の検証
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# リストの行
+{: .no_toc }
+
+list フィールドの行がどのように検証されるか
+{: .fs-6 .fw-300 }
+
+---
+
+`list` フィールドは行を保持し、各行はそのサブフォームのインスタンスで、行エディターで入力します。 `subform` を持つ
+`yaml` フィールドも、そうした行の 1 つです。サーバーはこれらを、ブラウザーの行エディターと同じように扱います。各行はサブフォームを通じて解決され、
+フォームの値が `__parent__` となり、ルールがチェックされ、計算フィールドが評価されます。ネストしたリストも同じように
+動作します。行自体のリストでは、 `$(__parent__.__parent__.x)` でフォームに到達できます。
+
+行は次のようにチェックされます。
+
+- **ユーザーがエディターで追加または編集した行** は、解決され、検証されます。
+- **誰も触れていない行** (リスト自体の既定値、式、クエリによって生成された行。たとえば ACL リストの既存のエントリ) は、
+  ブラウザーと同じように **受け取ったとおりのまま** 通過します。再検証されず、何も追加されません。後から書かれたルールに反する既存のエントリがあっても、
+  起動は止まりません。
+- **削除済みとしてマークされた行** (リストの `deleteMarker` ) は、そのまま保持され、検証されません。
+
+リクエストを信頼せずにこれらの行を区別するため、サーバーは起動時の検証の中で、リスト自体のソース (既定値、それがなければ式またはクエリ) を
+再度実行します。エディターを経由していない行が変更なしで通過するのは、 **そのソースが生成する行のいずれかである場合だけ** です。
+それ以外の行 (REST の呼び出し元が作り出した行など) は、編集された行と同じように解決され、検証されます。
+そのため、単なる行がチェックを回避することはできず、一方でブラウザーの触れられていない行は引き続き変更なしで通過します。
+
+ブラウザーのユーザーがこれに気づくのは、1 つのケースだけです。フォームを開いてから起動するまでの間にソースのデータが変わり
+(その間にエントリが変更または削除された)、 **かつ** その行がサブフォームのルールに反する場合です。その行はもうソースの行とはみなされないため、
+検証され、起動はその行の名前とともに拒否されます。たとえば
+`acls[2].user_or_group (regex)` です。
+
+失敗した行は、 `rowErrors` に `index` とともに表示され ( `yaml` フィールドには index はありません)、ログには
+`disks[1].size (maxValue)` のように表示されます。
+
+各行がサブフォームのクエリを実行するため、1 回の起動に含められる行は、すべてのネストレベルを合わせて最大 **500 行** です。
+
+---
+
+## 行のマーカー
+
+リストが行に設定するマーカー ( `insertMarker`、 `updateMarker`、 `deleteMarker`。 `insertMarker` がない場合、
+リストが `allowDelete: false`、 `deleteMarker`、 `updateMarker` のいずれかを設定していれば、新しい行には `__inserted__` が付きます) は、
+マーカーを持つすべての行で playbook に届きます。削除された行は削除マーカー付きで送信されるため、
+playbook はその行を削除できます。6.4.1 より前は、リストの行がマーカーを持つのは、サブフォームがそれを (非表示の) フィールドとして
+宣言している場合だけでした。
diff --git a/i18n/ja/_build_forms/launch-validation/log-and-enforce.md b/i18n/ja/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..101498d
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,106 @@
+---
+layout: default
+title: log と enforce
+parent: 起動時の検証
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# log と enforce
+{: .no_toc }
+
+ルールに反する起動を各モードがどう扱うか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## `log` の動作
+
+すべての起動がチェックされますが、ユーザーにとっては何も変わりません。次の場合に警告がログに書き込まれます。
+
+- 起動が **拒否されるはず** の場合。理由 (フィールド名とルールの種類だけで、値は含まれません) とともに
+  記録されます。
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- クライアントが送信した extravars が、サーバーが作成するものと **異なる** 場合。異なる
+  最上位のキーとともに記録されます。
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+まず実際のインスタンスでしばらく `log` を実行してください。誰かに影響が出る前に、どのフォームが拒否されるか、
+どのフォームがサーバーで異なる値を計算するかがわかります。
+
+---
+
+## `enforce` の動作
+
+`enforce` では、無効な起動は拒否され、有効な起動はサーバーが作成した extravars で
+実行されます。
+
+### ルールに反する起動は拒否される
+
+`POST /api/v2/job` は、失敗したフィールドとともに `422` を返します。
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing`: 値のない必須フィールド
+- `invalid`: ルールに反するフィールド、選択肢のいずれでもない選択、失敗した行を持つ list
+  フィールド
+- `waiting`: 評価できなかったフィールド (必要とするフィールドに値が設定されなかった)
+- `validationErrors`: フィールドごとの、失敗したすべてのルールと、ブラウザーが表示するメッセージ
+- `rowErrors`: list フィールドごとの、失敗した行 ( [リストの行](list-rows-and-subforms.html) を参照)
+- `uploads`: アップロードを検証できなかった file フィールド
+
+**`rawFormData` のない** 起動も拒否されます。その値をチェックできないためです。
+
+### 有効な起動はサーバーの extravars で実行される
+
+ジョブは、クライアントが送信した extravars では実行されません。サーバーは、ブラウザーと同じコードを使って、チェック済みの
+値から extravars を作成し、それで実行します。有効な `rawFormData` と異なる `extravars` を一緒に送信した呼び出し元は、
+送信したものではなく、値に一致する extravars を受け取ります。
+
+リクエストからサーバーが保持するのは `__verbose__` (詳細モードの使用を許可されたユーザーのみ) です。
+予約済みのキー ( `__playbook__`、 `__inventory__` など) は、これまでどおりフォームから取得され、
+`ansibleforms_user` は起動したユーザーです。
+
+### ユーザーが見たものがそのまま実行されるとは限らない
+
+extravars を作成するということは、フォームを再度評価するということです。すべての式とクエリが、ブラウザーでの実行から少し後に、
+起動したユーザーとしてサーバー上でもう一度実行されます。 **いつ** または **どこで** 評価されるかに依存する値は
+異なることがあり、その場合はサーバーの値が使われます。
+
+| 対象 | 異なる理由 | 影響の大きさ |
+|---|---|---|
+| `fn.fnTime()`、タイムスタンプ、時刻から作られた名前 | 数秒後に再度評価される | 秒や日付の境界でのみ問題になります。 `fnTime` はブラウザーでの流れでもすでにサーバーで、同じタイムゾーン (コンテナーの `TZ` ) で実行されています |
+| クエリ、 `fnRestAdvanced`、 `fnSsh`、 `fnDnsResolve`、ファイルの読み取り | その間に外部のデータが変わった | 変わった場合のみ |
+| `new Date()`、 `toLocaleString`、 `Intl` を使う `runLocal` 式 | ブラウザーはユーザーのタイムゾーンとロケールを、サーバーは自身のものを使う | そのような式のみ |
+
+**検証** にも同じことが当てはまります。そのようなフィールドを読み取るルール (クエリの結果に対する `notIn`、
+計算されたフラグに対する `validIf` ) は、サーバーの値に照らしてチェックされます。extravars が異なるフォームは、
+上記の `log` の警告に表示されます。強制する前に確認してください。
diff --git a/i18n/ja/_build_forms/launch-validation/passwords.md b/i18n/ja/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..d1ecfd9
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: パスワード
+parent: 起動時の検証
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# パスワード
+{: .no_toc }
+
+password フィールドがどのように検証、保存され、API から除外されるか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+password フィールドは、ほかのフィールドと同じように検証されます。ただし、その値はサーバーに保持され、クライアントに返されることは
+ありません。
+
+---
+
+## パスワードの保存場所
+
+サーバーは、パスワードをジョブとともに、その extravars に保存します。
+
+* これにより、 **承認** の後、ユーザーが入力したパスワードでジョブを続行できます。
+* 起動時の検証が `enforce` でない場合、 **実行時のままの再起動** でパスワードを再利用できます。
+
+保存されたパスワードは、サーバー上でだけ使われます。
+
+---
+
+## API が返すもの
+
+パスワードを返す API はありません。
+
+* REST API または MCP サーバーの `get_job` で読み取ったジョブでは、フォームのすべての `password` フィールドがマスクされます。
+  list の行や YAML のサブフォームの中も同様です。
+* `MASK_EXTRAVARS_REGEX` (既定は `password|secret|token` ) は、名前が一致するすべての extravar もマスクします。
+  password フィールドではないシークレットのためです。
+
+---
+
+## 再起動で受け取るもの
+
+再起動の事前入力のために、ブラウザーはジョブの生のフォームデータを受け取ります。このデータには、list の行や YAML のサブフォームの中も含めて、
+パスワードは一切含まれないため、ユーザーはパスワードをもう一度入力します。
+
+フォームの依存関係によって非表示になっている password フィールドは不要で、もう一度入力する必要はありません。
diff --git a/i18n/ja/_build_forms/launch-validation/relaunching.md b/i18n/ja/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..c94925d
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: 再起動
+parent: 起動時の検証
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# 再起動
+{: .no_toc }
+
+再起動したジョブがどのように検証されるか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+ジョブを再起動する方法は 2 つあります。再起動がどのようにチェックされるかは、どちらの方法かと、起動時の検証の
+モードによって決まります。
+
+---
+
+## 2 種類の再起動
+
+2 つの違いは、呼び出し元が新しい値を送信するかどうかです。
+
+* **実行時のまま**: 再起動ボタン、本文なしの `POST /api/v2/job/{id}/relaunch`、または
+  `values` なしの `relaunch_job` です。
+* **変更あり**: 同じ呼び出しに新しい値を付けたもので、ジョブに保存されたフィールドの値の上に重ねられます。
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## それぞれのチェック方法
+
+再起動を再生するか、再度チェックするかは、起動時の検証のモードで決まります。
+
+| 再起動 | `off` / `log` | `enforce` |
+|---|---|---|
+| **実行時のまま** | ジョブに保存された extravars をパスワードも含めて再生します | 保存されたフィールドの値から完全にチェックします |
+| **変更あり** | 保存された値に変更を重ねたものを完全にチェックします | 同じように完全にチェックします |
+
+`enforce` での例外が 1 つあります。管理者レベルのスケジュールで起動されたジョブには独自のフィールドの値がないため、それを実行時のまま再起動すると、
+管理者または `allowScheduledJobs` ロールオプションを持つユーザーの場合、スケジュールに保存された extravars が再生されます。
+
+チェックされた再起動 ( [log と enforce](log-and-enforce.html) を参照) は、呼び出し元の名前で新しいジョブを開始します。
+
+---
+
+## password フィールド
+
+保存されたフィールドの値にはパスワードが含まれないため、チェックされた再起動では、 **表示されている password フィールド** の値がありません。
+
+* 再起動は `unsupported` として拒否され、不足している `passwordFields` が示されます。
+* フォームを再度起動して、パスワードを入力してください。
+* フォームの依存関係によって **非表示** になっている password フィールドは不要で、再起動を妨げません。
+
+`enforce` では、これは再起動ボタンにも当てはまります。
+
+---
+
+## 再起動できるユーザー
+
+どちらの再起動にも、次の条件が必要です。
+
+* フォームが再起動を許可していること ( `allowRelaunch`、既定は true )
+* `allowJobRelaunch` ロールオプション
+* ユーザーが **ジョブの所有者**、管理者、または `manageAllJobs` ロールオプションを持つユーザーであること
+
+すべてのジョブを表示できる ( `showAllJobLogs` ) だけでは、ほかのユーザーのジョブを再起動できません。承認者は自分の承認を待っているジョブを
+表示できますが、それを再起動することもできません。
diff --git a/i18n/ja/_build_forms/launch-validation/rolling-it-out.md b/i18n/ja/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..dab68e0
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: 展開する
+parent: 起動時の検証
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# 展開する
+{: .no_toc }
+
+インスタンスを enforce に移行する方法と、既知の制限
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 展開する
+
+`enforce` が既定です。スクリプトやほかのシステムが REST でフォームを起動するインスタンスでは、何かを拒否する前に
+ログを見ながら、段階的に移行してください。
+
+1. インスタンス全体に `LAUNCH_VALIDATION=log` を設定します (アップグレードの場合は、アップグレードの前に)。
+2. しばらくこのモードで運用し、ログを確認します。 `would refuse` の警告は、ルールに反する起動を
+   示します。 `extravars differ` の警告は、サーバー上で異なる計算をするフォーム (タイムスタンプ、外部のデータ) を
+   示します。それが問題になるかどうかを、フォームごとに判断してください。
+3. それらのフォームを `launchValidation: enforce` に切り替えます。無効な値や作り出した extravars を送信していた呼び出し元は、
+   理由とともに `422` を受け取るようになります。
+4. すべてのフォームが期待どおりに動作したら、インスタンス全体の `LAUNCH_VALIDATION` を削除します (または `enforce` に設定します)。
+
+---
+
+## 制限
+
+起動時の検証は、まだすべてを網羅しているわけではありません。
+
+- **ウィザードフォーム** は変更ありで再起動できません。また、7.0 より前に起動されたウィザードのジョブは、
+  `enforce` では再起動できません (ステップの値を保存していなかったため)。MCP サーバーは
+  ウィザードフォームを起動できません。
+- ブラウザーでの **プレースホルダーの解決** は、サーバーのコードの独自のコピーを使っています。
+  まれなエッジケース ( `__undefined__`、式内の引用符) では、両者がプレースホルダーを異なる方法で解決する可能性があります。
+  `log` でそのような差異がわかります。
+- **`runLocal`** の式は、ブラウザーではブラウザーの JavaScript エンジンで、サーバーでは
+  サンドボックスで実行されます。同じコードは同じ結果を生みますが、ブラウザーのタイムゾーンやロケールに依存する部分は例外です。
+
+---
+
+## ウィザードフォーム
+
+[ウィザード](../forms/wizard.html) はステップごとにチェックされます。ブラウザーは各ステップの値を送信し、
+サーバーは、ユーザーが送信するはずのすべてのステップを、それぞれのサブフォームに照らしてチェックします。
+
+- `optional` でユーザーがスキップしたステップ、または `when` が false のステップは除外されます。
+- ステップは、チェック済みの値を持つ前のステップを `$(__parent__.<step>.<field>)` で読み取ります。
+- エラーには、 `<step>.<field>` のようにステップとフィールドが示されます。
+- `enforce` では、extravars はサーバーで作成され、各ステップはその `defaultModel` の下に置かれます。
+- ウィザードでは file フィールドはサポートされていません。
diff --git a/i18n/ja/_build_forms/launch-validation/switching-it-on.md b/i18n/ja/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..d39022f
--- /dev/null
+++ b/i18n/ja/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: 有効にする
+parent: 起動時の検証
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# 有効にする
+{: .no_toc }
+
+インスタンス全体、または 1 つのフォームに対して
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+起動時の検証には 2 つの設定があります。 **2 つのうち、より厳しい方が適用されます。**
+
+---
+
+## インスタンス全体: `LAUNCH_VALIDATION`
+
+環境変数 [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) は、すべてのフォームに適用されます。
+
+- `off`: サーバー側でのチェックは行われません。ジョブは、ブラウザーまたは呼び出し元が送信した extravars で実行されます。
+- `log`: すべての起動がチェックされます。拒否されるはずのものは警告としてログに
+  書き込まれますが、起動はこれまでどおり実行されます。
+- `enforce` (既定): 無効な起動は拒否され、有効な起動はサーバーが作成した extravars で
+  実行されます。
+
+空の値や不明な値も `enforce` とみなされます。変更は再起動なしで反映されます。
+
+{: .warning }
+> **アップグレードで動作が変わります。** `LAUNCH_VALIDATION` を設定していないインスタンスでは、アップグレード後、
+> すべての起動が強制的に検証されます。 `rawFormData` なしで、またはフォームのルールに反する値で `POST /api/v2/job` を呼び出すスクリプトは、
+> `422` で拒否されます。何が拒否されるかを確認するには、アップグレード前に
+> `LAUNCH_VALIDATION=log` を設定してください。以前の動作を維持するには `off` を設定します ( [展開する](rolling-it-out.html) を参照)。
+
+---
+
+## 1 つのフォーム: `launchValidation`
+
+フォームは独自のレベルを設定できます。
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+この設定は、 `off` または `log` で運用しているインスタンスで、REST で起動されることがわかっているフォームに使います。
+そのフォームは強制的に検証され、インスタンスのそれ以外の部分はそうなりません。デザイナーのフォーム設定でも
+設定できます。
+
+**フォームはインスタンスより厳しくできますが、緩くはできません。** `LAUNCH_VALIDATION` が
+`enforce` の場合、フォームの `launchValidation: off` は効果がありません。フォームが運用者の判断を
+上書きすることはできません。
+
+ウィザードフォームもこの設定を使います。ウィザードの起動はステップごとにチェックされ、各ステップはそれ自身の
+サブフォームに照らしてチェックされます ( [ウィザードフォーム](rolling-it-out.html#wizard-forms) を参照)。
diff --git a/i18n/ja/_build_forms/workflows/designer.md b/i18n/ja/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..4989d95
--- /dev/null
+++ b/i18n/ja/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: デザイナーでの編集
+parent: ワークフロー
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# デザイナーでの編集
+{: .no_toc }
+
+ワークフローを描き、何も実行せずに試す
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ワークフローセクション
+
+**デザイナー > ワークフロー** では、ワークフローファイルがファイルエクスプローラーに一覧表示され、どの [デザイナー](../designer/) セクションにもある
+YAML、ビジュアル、プレビューのタブがあります。
+
+- ツールバーの **`+` ボタン** で、空のワークフローを含むワークフローファイルを作成します。
+- **YAML** は、書かれているとおりのファイルを表示します。コメントとキーの順序は、ほかのタブでも保持されます。
+- **ビジュアル** は、ファイル内の各ワークフローをグラフとして描き、その上に名前と説明を表示します。2 つのワークフローを含むファイルでは、
+  両方が上下に並んで表示されます。
+- **プレビュー** はワークフローのドライランです。 [試してみる](#trying-it-out) を参照してください。
+
+問題はグラフの上に一覧表示され、それぞれにその行の YAML を開くリンクがあります。存在しないノードへのリンク、ループ、デザイナーが
+認識していない playbook、インベントリ、認証情報、ランナー、リポジトリなどです。
+
+---
+
+## グラフ
+
+グラフは左から右へ、 **START** から最後のノードへと読みます。各ノードには識別子と、その下に実行するものが表示されます。
+リンクは、グラフ内の凡例のとおり、発火の条件によって色分けされています: 成功時、失敗時、
+常に。
+
+- **START をクリック** すると、最初のノードを追加します。親のないノードで、ワークフローの開始と同時に実行されます。
+- **ノードをクリック** すると、そのノードを編集します。
+- **リンクをクリック** すると、発火の条件を変更したり、リンクを削除したりできます。
+
+---
+
+## ノードを追加する
+
+新しいノードはウィザードで追加します。既存のノードで **成功時に新しいノード**、 **失敗時に新しいノード**、 **常に新しいノード** のいずれかを選ぶか、
+最初のノードの場合は START を使います。
+
+1. **実行するもの**: ノードの識別子、 **実行するもの** (ノードの種類と、playbook ノードの場合は実行場所)、
+   および実行する対象です。playbook、テンプレートまたはジョブ、ワークフロー、承認の名前とタイムアウト、またはリポジトリです。
+   [ノードの実行場所](#where-a-node-runs) を参照してください。
+2. **実行のしかた**: 実行設定です。インベントリ、認証情報、制限、タグ、詳細度、
+   チェックモードと差分モード、条件 ( **実行条件** )、 **値の取得元** です ( [ワークフローファイル](file.html#run-settings) を参照)。
+3. **つなぎ先**: このノードがどのノードの後に、どの条件で実行されるかです。
+
+**作成** で、ノードを YAML に追加します。
+
+---
+
+## ノードの実行場所
+
+**実行するもの** では、ノードが何をどこで実行するかを 1 つのリストで指定します: **RTE の playbook**、 **AWX のテンプレート**、 **Semaphore の
+テンプレート**、 **Rundeck のジョブ**、 **Jenkins のジョブ**、続いて **ワークフロー**、 **承認**、 **リポジトリの pull** です。
+
+| 実行するもの | その下のフィールド | ランナー |
+|---|---|---|
+| **RTE の playbook** | **Playbook**: デザイナーの playbook | **デフォルトの RTE**、または名前で指定した RTE ランナー |
+| **AWX のテンプレート** (AAP と Ascender を含む) | **テンプレート**: 入力したテンプレートの名前 | AWX ランナー (それぞれの種類付き) |
+| **Semaphore のテンプレート** | **テンプレート**: 入力したテンプレートの名前 | Semaphore ランナー |
+| **Rundeck のジョブ** または **Jenkins のジョブ** | **ジョブ**: 入力したジョブの名前 | Rundeck または Jenkins のランナー |
+
+- **RTE の playbook** は常に選択できます。それ以外は、インスタンスにその種類の [ランナー](../runners.html) がある場合にだけ選択できます。
+- **ランナー** にはその種類のランナーだけが一覧表示され、デフォルトのランナーに印が付いてあらかじめ選択されます (ない場合は名前順で最初のもの)。
+- 別の実行場所を選ぶと、ノードが実行するものはクリアされるため、選び直します。
+- デザイナーがランナーを認識していないノードには、 **{runner} のテンプレートまたはジョブ** と表示されます。
+
+ワークフローファイルは変わりません。そのようなノードは、 `runner:` を持つ `job_template` ノードです (
+[ワークフローファイル](file.html#run-settings) を参照)。
+
+---
+
+## ノードを編集する
+
+ノードをクリックすると、4 つのタブを持つダイアログが開きます。
+
+| タブ | 内容 |
+|---|---|
+| **実行するもの** | 識別子、 **実行するもの**、実行する対象、playbook ノードの場合はランナー |
+| **実行のしかた** | 実行設定。認証情報はリストから選び、それぞれ `+` で追加します |
+| **次の後に実行** | ノードに入るリンクと、 **すべての親の収束が必要** |
+| **次に実行** | ノードから出るリンク。 **既存のノードにリンク:** と **新しいノードにリンク:** があります |
+
+**YAML で表示** でそのノードの YAML を開き、 **ノードを削除** でノードをリンクとともに削除します。変更はすべてすぐに
+YAML に書き込まれます。 **保存** でファイルを保存します。
+
+---
+
+## 試してみる
+
+**プレビュー** タブでは、何も起動せずに、AWX のルールに従ってワークフローを最後まで再生します。
+
+すべてのノードは成功の状態から始まります。ノードをクリックすると失敗させ、もう一度クリックすると成功に戻します。グラフには、
+どのノードが実行され、どのノードが実行されないか、ワークフローが失敗するかどうかが表示されます。 **リセット** で、すべてのノードを再び成功に戻します。
diff --git a/i18n/ja/_build_forms/workflows/file.md b/i18n/ja/_build_forms/workflows/file.md
new file mode 100644
index 0000000..22b978a
--- /dev/null
+++ b/i18n/ja/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: ワークフローファイル
+parent: ワークフロー
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# ワークフローファイル
+{: .no_toc }
+
+ワークフローの構文、ノードの種類、各ノードの実行設定
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ワークフローファイルの置き場所
+
+ワークフローファイルは、ローカルのワークフローフォルダーと、ワークフローに使用するすべてのリポジトリにある YAML ファイルです。
+
+- **ローカルフォルダー** は [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH) で、既定では永続フォルダー配下の
+  `workflows` です。
+- **ワークフローに使用しますか?** がオンの **リポジトリ** は全体が読み込まれるため、ワークフローファイルはどのフォルダーに置いてもかまいません。
+  デザイナーはファイルをリポジトリに保存し、 **プッシュ** でリモートに送信します。
+
+`workflow_job_templates` を含む YAML ファイルは、6 階層の深さまですべて読み込まれ、1 つのファイルに複数の
+ワークフローを含めることができます。フォームはワークフローを `name` で指定するため、名前は一意にしてください。2 つのワークフローが同じ名前を持つ場合、
+それを実行するジョブは失敗し、どちらかの名前を変更するよう表示されます。
+
+---
+
+## 構文
+
+ワークフローファイルは AWX のエクスポートの構文で記述し、ノードは `related.workflow_nodes` の下に置きます。
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+`awx.awx` コレクションの形式も読み込めます。ワークフローの直下に `workflow_nodes` を置き、名前をマップ ( `inventory: {name: staging}` ) ではなく
+単純な文字列 ( `inventory: staging` ) で記述する形式です。
+
+### ワークフロー
+
+ワークフローの項目には、ノードとは別に、いくつかの独自のキーがあります。
+
+| キー | 内容 |
+|---|---|
+| `name` | ワークフローの名前。フォームの `workflow:` で指定します |
+| `description` | ワークフローの用途。デザイナーに表示されます |
+| `extra_vars` | すべてのノードが受け取る変数。フォームの値が優先されます |
+| `related.workflow_nodes` | ノード |
+
+### ノード
+
+各ノードには、識別子、実行するもの、リンクがあります。
+
+| キー | 内容 |
+|---|---|
+| `identifier` | ノードの ID。英字、数字、ドット、ハイフン、コロン、アンダースコアが使え、ワークフロー内で一意です |
+| `unified_job_template.type` | ノードが実行するもの。 [ノードの種類](#node-types) を参照してください |
+| `unified_job_template.name` | 実行する playbook、ワークフロー、承認、リポジトリ |
+| `related.success_nodes` | このノードが成功したときに実行されるノード |
+| `related.failure_nodes` | このノードが失敗したときに実行されるノード |
+| `related.always_nodes` | このノードが終了したときに、結果にかかわらず実行されるノード |
+| `all_parents_must_converge` | `true`: ノードは、1 つだけでなく、そこに入るすべてのリンクが発火するのを待ちます |
+
+リンクは先に進む方向でなければなりません。リンクがループするワークフローは実行されません。
+
+---
+
+## ノードの種類
+
+ノードは次の 4 種類のいずれかを実行します。名前は AWX での呼び名と同じです。
+
+| 種類 | ノードが実行するもの |
+|---|---|
+| `job_template` | デザイナーの playbook の 1 つを、RTE 上の個別のジョブとして実行します。 `runner:` がある場合は、そのランナーのテンプレートまたはジョブです |
+| `workflow_job_template` | 別のワークフローを、子のワークフロージョブとして実行します。ワークフローは 5 階層までネストできます |
+| `workflow_approval_template` | 承認です。誰かが承認または却下するまで、ワークフロージョブは待機します |
+| `project` | 指定したリポジトリのプルです (AWX のプロジェクトの更新) |
+
+承認ノードの `unified_job_template.timeout` は秒単位です。応答がないままその時間が過ぎると、ノードは失敗します。 `0` またはタイムアウトなしの場合は、
+どれだけ時間がかかっても応答を待ちます。承認が却下されるとノードは失敗し、ワークフローはそのリンクに沿って
+続行します。
+
+---
+
+## 実行設定
+
+`job_template` ノードは、AWX のノードと同じ設定をノード自体に持ちます。
+
+| キー | 内容 |
+|---|---|
+| `inventory` | playbook を実行する対象のインベントリ。フォームの `inventory:` と同じく名前で指定します |
+| `related.credentials` | 認証情報。それぞれ独自の名前で playbook に渡され、最初の *SSH* の認証情報は ansible が接続に使うログインにもなります。Vault の認証情報は Vault を開くだけです |
+| `limit` | これらのホストでのみ実行します ( `--limit` ) |
+| `job_tags` | これらのタグを持つタスクだけを実行します ( `--tags` ) |
+| `skip_tags` | これらのタグを持つタスクをスキップします ( `--skip-tags` ) |
+| `verbosity` | `0` から `5`: `-v` の数 |
+| `diff_mode` | `true`: 変更内容を表示します ( `--diff` ) |
+| `job_type` | `check`: ドライラン ( `--check` )。 `run` または指定なし: 実際の実行 |
+| `extra_data` | このノードが受け取る変数。ワークフローの `extra_vars` とフォームの値より優先度は低くなります |
+
+ノードのジョブは、フォームの値を extra vars として受け取ります。AWX のサーベイの回答と同じように、フォームの値はワークフローの `extra_vars` より優先され、
+ワークフローの `extra_vars` はノードの `extra_data` より優先されます。
+
+---
+
+## AnsibleForms 独自のキー
+
+ノードの 3 つのキーは AnsibleForms 独自のもので、AWX はこれらを無視します。これにより、ワークフローでマルチステップフォームと同じことができます。
+
+| キー | 内容 |
+|---|---|
+| `runner` | `job_template` ノードで、デザイナーの playbook の代わりに、そのランナーのテンプレートまたはジョブを実行します: AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins。RTE ランナーの場合は、ノードの playbook をそこで実行します。1 つのワークフローでこれらを混在させられます。 |
+| `if_extra_var` | マルチステップのステップの `ifExtraVar` と同じく、この extra var が `true` の場合にだけノードを実行します。満たされない場合、ノードはスキップされ、その後に続くものは成功の後と同じように実行されます。常に実行される承認ノードには使えません。 |
+| `extra_vars_key` | マルチステップのステップの `key` と同じく、ノードは extra vars のこのキーだけを、ユーザー情報をコピーした状態で受け取ります |
+
+テンプレートのランナーでは、 `unified_job_template.name` が実行するテンプレートまたはジョブで、ノードの `limit`、 `job_tags`、チェック
+モード、差分モードは、そのランナーの種類のフォームと同じように渡されます。 `verbosity` が `0` より大きい場合はフォームの
+`verbose` がオンになり、 `skip_tags` は渡されません。ノードのインベントリを受け取るのは AWX ランナー (AWX、AAP、Ascender) だけで、
+認証情報も AWX の認証情報として受け取ります。Semaphore、Rundeck、Jenkins は、認証情報をフォームの `credentials` として受け取ります。
diff --git a/i18n/ja/_build_forms/workflows/index.md b/i18n/ja/_build_forms/workflows/index.md
new file mode 100644
index 0000000..c0346d7
--- /dev/null
+++ b/i18n/ja/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: ワークフロー
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# ワークフロー
+{: .no_toc }
+
+AWX と同じように、playbook、承認、ほかのワークフローをつなげる
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+フォーム作成者向け: ワークフローとは何か、そのノードがどのように実行されるか、次に読むべきページを説明します。
+
+ワークフローはノードのグラフです。各ノードは何かを実行します。デザイナーの playbook、別のワークフロー、承認、
+またはリポジトリのプルです。ノード間のリンクは、成功時、失敗時、または常に、次に何を実行するかを示します。
+[`workflow` タイプ](../forms/workflow.html) のフォームがワークフローを起動し、ジョブページでは実行中のワークフローがリアルタイムで描画されます。
+
+ワークフローは AWX の構文と AWX のルールに従うため、AWX からエクスポートしたワークフローは AnsibleForms でも同じように読めます。ワークフローは
+AWX を使わずに RTE で実行されます。playbook ノードは、ノードのインベントリ、認証情報、制限、タグを持つ個別のジョブです。
+
+---
+
+## ワークフローの実行のしくみ
+
+ノードは AWX のルールに従って実行され、互いに依存しない分岐は並行して実行されます。
+
+- **親のないノードは、ワークフローの開始と同時に開始します。**
+- **リンクは、そのノードが終了したときに発火します**: *成功時* のリンクは成功の後、 *失敗時* のリンクは失敗の後、
+  *常に* のリンクはどちらの後にも発火します。キャンセルされたノードは、どのリンクも発火させません。
+- **ノードは、そこに入るリンクのいずれか 1 つが発火するとすぐに開始します。** **すべての親の収束が必要** をオンにすると、そこに入る
+  すべてのリンクが発火するまで待ちます。
+- **開始できなくなったノードは *実行しない* としてマークされ**、そのノードからしか開始できないノードも同様にマークされます。
+- **ノードが失敗し、それを処理するものがない場合、ワークフローは失敗します**: そのノードに *失敗時* のリンクも *常に* のリンクもない場合です。
+  リンクで処理される失敗では、ワークフローは失敗しません。
+
+条件 ( `if_extra_var` ) が満たされないノードはスキップされます。その後に続くものは、成功の後と同じように実行されます。承認
+ノードは条件を取りません。常に応答を待ちます。
+
+---
+
+## ノード間でデータを渡す
+
+ノードの playbook が `set_stats` で収集したものは、AWX がジョブのアーティファクトを引き渡すのと同じように、後続のノードに extra vars として
+届きます。ノードは、そこへのリンクが発火したすべての親からデータを受け取り、親が記述された順にマージします。そして、受け取ったものに
+自身のジョブのデータを加えて引き渡します。両方が同じキーを設定した場合は、自身のデータが優先されます。
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+後続のノードは、ほかの extra var と同じように {% raw %}`{{ version }}` と `{{ build_id }}`{% endraw %} を読み取れます。
+
+ノードの extra vars は 4 か所から来ます。そのうちの 1 つ `extra_data` はノード自身の変数です。これは AWX での呼び名で、
+[ワークフローファイル](file.html#run-settings) でノードに設定します。2 つのソースが同じキーを設定した場合、優先順位は
+AWX と同じで、低いものから順に次のとおりです。
+
+| ソース | 優先される対象 |
+|---|---|
+| ノード自身の変数 ( `extra_data` ) | なし |
+| `set_stats` で引き渡されたデータ | ノードの `extra_data` |
+| ワークフローの `extra_vars` | 引き渡されたデータ |
+| フォームの値 | すべて |
+
+- 引き渡されるのは playbook 全体のデータだけです。つまり `per_host: false` (既定値) の `set_stats` です。
+- 承認ノード、スキップされたノード、プロジェクトノードは、受け取ったものをそのまま引き渡します。
+- ノードの出力の最後には、引き渡したキーが名前だけで表示されます。値はシークレットの可能性があるためです。
+- ノードのジョブはそのデータをアーティファクトとして保持し (そのページの **Artifacts を表示** )、ワークフロージョブはすべての
+  ノードのデータを保持します。そのため、ネストしたワークフローも、後続のノードにデータを引き渡します。
+- AWX ランナーで実行されるノードも、同じように AWX ジョブのアーティファクトを引き渡します。
+---
+
+## このセクションの内容
+
+次のページでワークフローを詳しく説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [ワークフローファイル](file.html) | ファイルの構文、ノードの種類、各ノードの実行設定 |
+| [デザイナーでの編集](designer.html) | デザイナーのワークフローセクション: グラフ、ノードとリンクのダイアログ、ドライラン |
+| [ワークフローの実行](running.html) | ワークフローを起動するフォーム、ジョブページ、ノードの出力、承認、中止 |
diff --git a/i18n/ja/_build_forms/workflows/running.md b/i18n/ja/_build_forms/workflows/running.md
new file mode 100644
index 0000000..feeb7c4
--- /dev/null
+++ b/i18n/ja/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: ワークフローの実行
+parent: ワークフロー
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# ワークフローの実行
+{: .no_toc }
+
+フォームからワークフローを起動し、ジョブページで追跡する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## フォーム
+
+[`workflow` タイプ](../forms/workflow.html) のフォームはワークフローを起動します。ワークフローは playbook と同じように `workflow:` で指定します。
+ワークフローフォルダー内の **ファイル** をサブフォルダーを含めて指定する ( `team/deploy-app.yml` ) か、ファイル内のワークフローの **名前**
+( `deploy-app` ) で指定します。
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+マルチステップフォームの値がステップに届くのと同じように、フォームのフィールドは extra vars としてすべてのノードに届きます。フォームの [`credentials`](../forms/workflow.html#workflow_credentials) も、
+フォームで付けた名前ですべてのノードに届きます。
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+ワークフローファイルで設定したノード自身の認証情報は、独自の名前で playbook に届き、名前が重なった場合はこちらが優先されます。フォームのデザイナーのビジュアルタブでは、 **ワークフロー** に
+デザイナーのワークフローファイルが一覧表示されます。
+
+ファイル名だけを指定した場合も、そのファイル名を持つファイルが 1 つだけであれば、サブフォルダー内で見つかります。同じ名前のワークフローが 2 つあると、
+名前で指定しているフォームは停止し、2 つ目を保存するときにデザイナーが警告します。どちらかの名前を変更するか、ファイルで指定してください。
+ワークフローが見つからない場合、ジョブは失敗で終了し、その理由が出力に表示されます。
+
+---
+
+## ジョブ
+
+ワークフロージョブは AnsibleForms のサーバー上で実行され、playbook の各ノードは、マルチステップフォームのステップと同じように、ワークフロージョブの子である
+個別のジョブとして実行されます。RTE 上のデザイナーの playbook、または `runner:` のあるノードの場合は、AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins 上の
+そのランナーのテンプレートまたはジョブです ( [ノードの実行場所](designer.html#where-a-node-runs) を参照)。
+
+ジョブのページには、ワークフローがリアルタイムで描画されます。各ノードはステータスで色分けされ、発火したリンクと、実行されない
+ノードが表示されます。上部の情報には、playbook の代わりにワークフローの名前が表示されます。
+
+- 終了した **ノードをクリック** すると、その出力がダイアログで開きます。
+- **出力** には、すべてのノードの出力が、ノードが終了した順に `WORKFLOW NODE [identifier] (status)` の見出しの下に
+  表示されます。
+- 出力内の各ノードのヘッダーと、グラフから開いたダイアログにある **Extravars を表示** と **Artifacts を表示** で、
+  そのノード自身の extravars とアーティファクト (ない場合は `{}` ) を JSON または YAML で、コピーボタン付きで表示します。
+
+ノードの extravars には、それより前のノードが引き渡したものが入っており、アーティファクトには、その playbook が
+`set_stats` で収集したものが入っています。2 つのボタンは [ロールオプション](../config/roles.html#role-options) の `showExtravars` と
+`showArtifacts` に従います。同じデータは、ジョブを見られるユーザーであれば `GET /api/v2/job/{id}/node/{nodeId}` からも取得できます。
+
+AWX のルールに従い、ノードが失敗し、それを処理するものがなかった場合、ジョブは失敗します。それ以外の場合は成功します。
+
+---
+
+## 承認
+
+承認ノードは、誰かが応答するまでワークフロージョブを止めておきます。
+
+ワークフローが承認ノードに到達すると、ジョブのステータスは **承認待ち** になります。フォームの [承認ポイント](../forms/approval.html) と同じように、
+ベルとジョブのページに表示されます。ノードの名前が承認のタイトルに、説明が
+メッセージになります。それ以外はフォームの `approval` から取得します。
+
+- `roles` で、誰が承認または却下できるかを決め、 `allowSelf` で、起動したユーザーも承認できるかを決めます。
+- `notifications` と `channels` に依頼が送信されます。
+
+`approval` のないワークフローフォームでも承認ノードでジョブは止まりますが、その場合は管理者しか承認できません。
+
+- **承認された** 場合、ノードは成功し、ワークフローは *成功時* のリンクに沿って続行します。
+- **却下された** 場合、ノードは失敗し、ワークフローは *失敗時* のリンクに沿って続行します。
+- **タイムアウトした** 場合 (応答がないままノードのタイムアウトが過ぎた場合)、ノードはやはり失敗します。
+
+---
+
+## 中止
+
+実行中のワークフロージョブで **中止** を使うと、ワークフローが停止します。実行中のノードのジョブは中止され、それ以降は何も開始されず、
+待機中の承認はキャンセルされます。承認を待っているワークフロージョブも中止できます。
diff --git a/i18n/ja/_configure/announcements.md b/i18n/ja/_configure/announcements.md
new file mode 100644
index 0000000..8358bad
--- /dev/null
+++ b/i18n/ja/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: お知らせ
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# お知らせ
+{: .no_toc }
+
+メンテナンス予定など、全員に向けてヘッダーの下に表示するメッセージです。それぞれ開始日から終了日まで表示されます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。メンテナンス予定や障害をすべてのユーザーに知らせるには、 **設定 > 外観 > お知らせ** を使います。
+
+このページを使うには、ロールオプション `showSettings` または `showAppearanceSettings` が必要です。7.3.0 からは一つのリストになり、各お知らせに
+専用のページと「有効」スイッチがあります。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [全般](announcements/general.html) | すべてのお知らせをまとめて切り替えるスイッチに代わった、お知らせごとの「有効」スイッチ |
+| [リスト](announcements/list.html) | 終了していないお知らせ、その列、お知らせのページ |
+| [追加する](announcements/adding-one.html) | 2 ステップのウィザード：メッセージ、そして表示する期間 |
+
+
+---
+
+## 表示される場所
+
+お知らせは、サインインしているすべてのユーザーに対し、すべてのページのヘッダーの下に 1 行で、種類ごとの色で表示されます。
+
+有効なお知らせが複数あるときは同時に表示され、新しいものが先に並びます。サインインページと、別のサイトに埋め込まれたフォームには表示されません。
+
+各お知らせには閉じるボタンがあります。閉じたお知らせは、そのブラウザーのタブを閉じるまで、または
+メッセージか終了日が変わるまで閉じたままです。保存したお知らせは、開いているすべてのブラウザーにすぐに届きます。開始日または終了日に
+達したお知らせは、1 分以内にそこで表示または非表示になります。
diff --git a/i18n/ja/_configure/announcements/adding-one.md b/i18n/ja/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..0c6efb8
--- /dev/null
+++ b/i18n/ja/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: 追加する
+parent: お知らせ
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# 追加する
+{: .no_toc }
+
+2 ステップのウィザード：メッセージ、そして表示する期間
+{: .fs-6 .fw-300 }
+
+**お知らせを追加** を押すと、2 ステップのウィザードが開きます。 **メッセージ** では内容を入力します。
+
+| フィールド | 意味 |
+|---|---|
+| **メッセージ** | 本文。最大 500 文字です。必須です。 |
+| **種類** | 色とアイコン。情報は青（既定）、警告は黄、危険は赤です |
+
+**期間** では表示する期間を指定します。
+
+| フィールド | 意味 |
+|---|---|
+| **開始日** | この時点から表示します。空欄にするとすぐに表示します。 |
+| **終了日** | この時点で非表示になり、削除されます。空欄にすると削除するまで残ります。 |
+
+終了日は開始日より後で、かつ未来の日時でなければなりません。
diff --git a/i18n/ja/_configure/announcements/general.md b/i18n/ja/_configure/announcements/general.md
new file mode 100644
index 0000000..323eb7f
--- /dev/null
+++ b/i18n/ja/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: 全般
+parent: お知らせ
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# 全般
+{: .no_toc }
+
+すべてのお知らせをまとめて切り替えるスイッチに代わった、お知らせごとの「有効」スイッチ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## お知らせのオン／オフ
+
+7.3.0 からは、各お知らせをそれぞれの **有効** スイッチで個別にオン／オフします。
+
+新しいお知らせは有効になっています。行メニューの **無効にする** 、またはお知らせのページの **有効** スイッチを使うと、ヘッダーの下には表示されなくなり、
+リストには残ります。 **有効にする** を押すと、開始日から終了日まで再び表示されます。スイッチはすぐに保存されます。
+
+---
+
+## 7.2 の「お知らせを表示」スイッチ
+
+7.2 までは、 **全般** タブに **お知らせを表示** スイッチがあり、すべてのお知らせをまとめてオン／オフしていました。
+
+7.3.0 からこのスイッチはなくなりました。オフになっていた場合、アップグレード時にすべてのお知らせが無効になり、どれも表示され始めません。表示したいものを改めて有効にしてください。
diff --git a/i18n/ja/_configure/announcements/list.md b/i18n/ja/_configure/announcements/list.md
new file mode 100644
index 0000000..9786184
--- /dev/null
+++ b/i18n/ja/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: リスト
+parent: お知らせ
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# リスト
+{: .no_toc }
+
+終了していないお知らせ、その列、お知らせのページ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## リスト
+
+**設定 > 外観 > お知らせ** には、終了していないすべてのお知らせが次の列とともに表示されます。
+
+| 列 | 意味 |
+|---|---|
+| **有効** | 開始日から終了日までヘッダーの下に表示するかどうか（7.3.0 から） |
+| **メッセージ** | ヘッダーの下に表示される本文 |
+| **種類** | 情報、警告、危険のいずれか |
+| **開始日** | 表示が始まる日時。すぐに表示する場合は `–` |
+| **終了日** | 表示が終わる日時。削除するまで表示する場合は `–` |
+| **作成者** | 追加した人 |
+
+行をクリックするか、行メニューの **編集** を選ぶと、お知らせのページが開きます。メニューには **有効にする** または **無効にする** と、 **削除** もあります。
+
+終了日を過ぎたお知らせは削除されます。リストに残るのは、これから表示されるものと表示中のものだけです。
+
+---
+
+## お知らせのページ
+
+7.3.0 からは、各お知らせが `/settings/announcements/<id>` の専用ページで開き、タブは **詳細** の一つだけです。
+
+ページには、メッセージ、種類、開始日と終了日、そして **有効** スイッチがあります。スイッチはすぐに保存され、それ以外のフィールドは
+**保存** で保存されます。 **削除** を押すとお知らせが削除されます。ページのタイトルには、メッセージの先頭の数文字が表示されます。
diff --git a/i18n/ja/_configure/appearance.md b/i18n/ja/_configure/appearance.md
new file mode 100644
index 0000000..f6af354
--- /dev/null
+++ b/i18n/ja/_configure/appearance.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 外観
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# 外観
+{: .no_toc }
+
+既定値、名前、ロゴ、ブラウザーのアイコン、ヘッダーのリンク、ロゴの横のラベル
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。 **設定 > 外観** で、ロールオプション `showSettings` を使ってインスタンスの見た目を自社に合わせます。
+ロールオプション `showAppearanceSettings` だけでも、ほかの設定は開かずに、お知らせを含むこれらのページを開けます。
+
+このグループのページは **既定値** 、 **名前** 、 **ロゴ** 、 **アイコン** 、 **リンク** 、 **ラベル** 、 **お知らせ** です。
+お知らせには専用のページ [お知らせ](announcements.html) があります。保存した既定値、名前、リンク、ラベルは、
+開いているすべてのブラウザーにすぐに反映されます。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [既定値](appearance/defaults.html) | 何も選んでいないユーザー向けのテーマ、言語、タイムゾーン、日付形式 |
+| [名前](appearance/name.html) | ブラウザーのタブとサインインページに表示されるアプリケーション名 |
+| [ロゴ](appearance/logo.html) | ヘッダーに表示する独自のロゴ |
+| [アイコン](appearance/icon.html) | ブラウザーのタブとブックマークに表示する独自のアイコン |
+| [リンク](appearance/links.html) | ヘッダーのリンク（組み込みと独自のもの） |
+| [ラベル](appearance/labels.html) | どのインスタンスかを示す、ロゴの横のラベル。7.2 までは環境ラベルが一つだけ |
+
diff --git a/i18n/ja/_configure/appearance/defaults.md b/i18n/ja/_configure/appearance/defaults.md
new file mode 100644
index 0000000..5aa1537
--- /dev/null
+++ b/i18n/ja/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: 既定値
+parent: 外観
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# 既定値
+{: .no_toc }
+
+何も選んでいないユーザー向けのテーマ、言語、タイムゾーン、日付形式
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 既定値
+
+**既定値** では、[個人設定](../profile/preferences.html) で自分の選択をしていないユーザーに対するアプリの見た目を設定します。
+ユーザー自身の選択が常に優先されます。
+
+| フィールド | 選択肢 | 選択がない場合 |
+|---|---|---|
+| **既定のテーマ** | ブラウザーに合わせる、ライト、ダーク、色（色の場合は 12 色から一つ） | ブラウザーに合わせる（7.2 まではライト） |
+| **既定の言語** | アプリの言語。 [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) に保存されます | 英語 |
+| **既定のフォーム表示** | フォームページの表示。タイルまたはリスト | タイル |
+| **既定のタイムゾーン** | UTC、各ユーザーのブラウザー、または名前で指定する任意のタイムゾーン | UTC |
+| **既定の日付形式** | `YYYY-MM-DD` 、 `DD/MM/YYYY` 、 `MM/DD/YYYY` 、 `DD.MM.YYYY` 。今日の日付で表示されます | `YYYY-MM-DD` |
+
+言語は環境変数で、再起動なしで反映されます。
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) を `0` にすると、ページでは読み取り専用で表示されます。
+
+7.3.0 からは、このページはプロフィールの個人設定と同じ二つのタブ、 **外観** （テーマ、言語、フォーム表示）と **日付と時刻**
+（タイムゾーンと日付形式。現在時刻のプレビュー付き）に分かれており、検索ボックスは一致した項目を各タブ名の下に表示します。
+
+---
+
+## ブラウザーに合わせる
+
+7.3.0 からは、 **ブラウザーに合わせる** を選ぶと、各ユーザーのブラウザーが求めるライトまたはダークのテーマが表示され、ブラウザーの設定に合わせて切り替わります。
+
+既定のテーマを選んでいない場合はこれが既定になるため、新しいインストールはブラウザーに合わせます。 **色** の色の一つにポインターを重ねると、
+その色でアプリをプレビューできます。ポインターを離すと元のテーマに戻り、 **保存** するまで何も保存されません。
diff --git a/i18n/ja/_configure/appearance/icon.md b/i18n/ja/_configure/appearance/icon.md
new file mode 100644
index 0000000..b523049
--- /dev/null
+++ b/i18n/ja/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: アイコン
+parent: 外観
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# アイコン
+{: .no_toc }
+
+ブラウザーのタブとブックマークに表示する独自のアイコン
+{: .fs-6 .fw-300 }
+
+**アイコン** では、ブラウザーのタブとブックマークに表示される AnsibleForms のアイコンを置き換えます。
+
+| ルール | 値 |
+|---|---|
+| 形式 | PNG、ICO、SVG、WEBP、GIF、JPEG |
+| 最大ファイルサイズ | 256 KB |
+| 最適な結果 | 64 × 64 px 以上の正方形の画像、または SVG |
+
+**新しいアイコン** でファイルを選び、 **アップロード** をクリックします。 **カスタムアイコンを削除** を押すと既定のアイコンに戻ります。
diff --git a/i18n/ja/_configure/appearance/labels.md b/i18n/ja/_configure/appearance/labels.md
new file mode 100644
index 0000000..cabe282
--- /dev/null
+++ b/i18n/ja/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: ラベル
+parent: 外観
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# ラベル
+{: .no_toc }
+
+どのインスタンスかを示す、ロゴの横のラベル
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## リスト
+
+7.3.0 からは、 **設定 > 外観 > ラベル** で、PRODUCTION や EU のような複数のラベルをヘッダーのロゴの横に置けます。
+
+| 列 | 意味 |
+|---|---|
+| **有効** | ロゴの横とサインインページにラベルを表示するかどうか |
+| **ラベル** | テキスト。ヘッダーに色付きのピルとして表示されます |
+
+行はヘッダーでの順に並びます。行をクリックするか、行メニューの **編集** を選ぶとラベルのページが開きます。行メニューには、
+状態に応じて **有効にする** または **無効にする** 、順序を変える **上へ移動** と **下へ移動** 、そして **削除** もあります。
+
+ヘッダーとサインインページには、有効なラベルがその順に表示されます。4 つ目以降はグレーの **+N** にまとめられ、ツールチップに表示されます。
+スマートフォンでは最初のラベルと **+N** が表示されます。保存したラベルは、開いているすべてのブラウザーにすぐに反映されます。
+
+---
+
+## ラベルの追加
+
+**ラベルを追加** を押すと、ラベルの二つのフィールドを持つダイアログが開きます。どちらも必須です。
+
+| フィールド | 意味 |
+|---|---|
+| **ラベル** | ラベルのテキスト。例：PRODUCTION |
+| **色** | 青、緑、琥珀、オレンジ、赤、グレーのいずれか。丸い色見本で選びます。最初は赤です |
+
+プレビューには、有効なすべてのラベルと、入力中の新しいラベルを含むヘッダーが表示されます。新しいラベルは有効になり、ほかのラベルの後ろに
+並びます。ラベルのページにはタブが **詳細** の一つだけあり、同じフィールド、すぐに保存される **有効** スイッチ、プレビューがあります。
+
+---
+
+## 7.2 の環境ラベル
+
+7.2 までは、 **設定 > 外観 > 環境** でロゴの横にラベルを一つだけ設定していました。
+
+ラベルが一つだけだと、複数のインスタンスを並べて開いたときに PRODUCTION EU と PRODUCTION US がどちらも PRODUCTION と表示されます。7.3.0 からは、
+アップグレード時にそのラベルがテキスト、色、表示の有無とともにリストの先頭になり、以前の **環境** の
+アドレスを開くとリストが表示されます。
+
+---
+
+## 構成シードのラベル
+
+7.3.0 からは、[構成シード](../seed/) の `labels` セクションでラベルを宣言できます。それぞれテキストと、必要に応じて色を指定します。
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` は `blue` 、 `green` 、 `amber` 、 `orange` 、 `red` 、 `grey` のいずれかで、 `position` は順序を決め、小さい順に並びます。シードで宣言した
+ラベルは、ほかのすべての [管理対象オブジェクト](../seed/managed-objects.html) と同じく、そのページでは読み取り専用です。
diff --git a/i18n/ja/_configure/appearance/links.md b/i18n/ja/_configure/appearance/links.md
new file mode 100644
index 0000000..04fcb17
--- /dev/null
+++ b/i18n/ja/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: リンク
+parent: 外観
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# リンク
+{: .no_toc }
+
+ヘッダーのリンク（組み込みと独自のもの）
+{: .fs-6 .fw-300 }
+
+**リンク** では、サインインしているすべてのユーザーに対するヘッダーのリンクを、二つのタブで設定します。
+
+**組み込み** には **デザイナー** スイッチがあります。 [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) に保存され、
+再起動なしで反映されます。オフにすると、デザイナーは全員に対してなくなります。リンクも、ページも、API もです。
+
+**カスタム** には、Wiki、Runbook、サポートポータルなどの独自のリンクを置きます。 **リンクを追加** を押すと、次のフィールドを持つ行が追加されます。
+
+| フィールド | 意味 |
+|---|---|
+| **アイコン** | ラベルの前に表示するアイコン。リストから選びます |
+| **ラベル** | リンクのテキスト |
+| **アドレス** | サイト（ `https://…` ）またはアプリのページ（ `/forms/all` ） |
+| **新しいタブ** | リンクをブラウザーの新しいタブで開きます |
+
+行のボタンで行を移動します。 **→** はリンクを上のリンクの中に入れ、上のリンクはヘッダーでメニューとして開くようになります。
+**←** はリンクをヘッダーに戻し、上下の矢印はリンク（中にリンクを持つメニューならメニューごと）を移動します。
+メニュー自体にはアドレスは不要です。
+
+ヘッダーには、組み込みのリンクの後に独自のリンクを最大 5 個、各メニューの中には最大 10 個まで置けます。
diff --git a/i18n/ja/_configure/appearance/logo.md b/i18n/ja/_configure/appearance/logo.md
new file mode 100644
index 0000000..b391c98
--- /dev/null
+++ b/i18n/ja/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: ロゴ
+parent: 外観
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# ロゴ
+{: .no_toc }
+
+ヘッダーに表示する独自のロゴ
+{: .fs-6 .fw-300 }
+
+**ロゴ** では、ヘッダーの AnsibleForms のロゴを独自の画像に置き換えます。画像はすべてのテーマで表示されます。
+
+| ルール | 値 |
+|---|---|
+| 形式 | PNG、JPEG、WEBP、GIF、SVG |
+| 最大ファイルサイズ | 900 KB |
+| ヘッダーでのサイズ | 最大 200 × 33 px。縦横比は維持されます |
+
+**新しいロゴ** でファイルを選ぶとプレビューが表示されるので、 **アップロード** をクリックします。 **現在のロゴ** には、使用中のロゴと
+ヘッダーでの表示サイズが表示されます。 **カスタムロゴを削除** を押すと、テーマに合わせて変わる既定のロゴに戻ります。
diff --git a/i18n/ja/_configure/appearance/name.md b/i18n/ja/_configure/appearance/name.md
new file mode 100644
index 0000000..38bbbb0
--- /dev/null
+++ b/i18n/ja/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: 名前
+parent: 外観
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# 名前
+{: .no_toc }
+
+ブラウザーのタブとサインインページに表示されるアプリケーション名
+{: .fs-6 .fw-300 }
+
+**名前** には、ブラウザーのタブとサインインページに表示される **アプリケーション名** を設定します。空の場合、ブラウザーのタブには
+`AnsibleForms` と表示され、サインインページには名前が表示されません。
diff --git a/i18n/ja/_configure/authentication/entra-id.md b/i18n/ja/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..d28750c
--- /dev/null
+++ b/i18n/ja/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: 認証
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Microsoft Entra ID（Azure AD）によるシングルサインオン。ロールはユーザーの Entra ID グループから決まります
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 仕組み
+
+Entra ID プロバイダーが有効な場合、ログインページの **サインイン** の下に Entra ID のボタンが表示されます。ログインは次のように進みます。
+
+1. ボタンを押すとブラウザーは `/api/v2/auth/entraid` に送られ、そこから Microsoft にリダイレクトされます。
+2. ユーザーが Microsoft でサインインすると、認可コードとともに **リダイレクト URL** に戻されます。サーバーは
+   そのコードを Microsoft と交換して、ID トークンと Microsoft Graph 用のアクセストークンを受け取ります。
+3. サーバーは Microsoft Graph（ `/v1.0/me/transitiveMemberOf` ）からユーザーのグループを読み込むので、入れ子のグループも含まれます。
+4. グループは表示名に対して **グループフィルター** で絞り込まれ、残った各グループは
+   `azuread/<object id>` と `azuread/<display name>` の 2 通りで保存されます。
+
+ユーザー名はトークンの `upn` クレームで、たとえば `jdoe@example.com` です。トークンに `upn` がない場合は `preferred_username` クレームが
+使われます。職場のアカウントではどちらも同じ値です。
+
+---
+
+## アプリケーションの登録
+
+AnsibleForms には、Entra 管理センターの **App registrations > New registration** で作成するアプリの登録が必要です。
+
+1. 名前を付け、サポートされるアカウントの種類として **Accounts in this organizational directory only** を選び、種類 **Web** の
+   リダイレクト URI `https://af.example.com/api/v2/auth/entraid/callback` を追加します。
+2. **Certificates & secrets** でクライアントシークレットを作成し、その値をコピーします。値は一度しか表示されません。
+3. **API permissions** で、Microsoft Graph の **委任された** アクセス許可 `User.Read` と `GroupMember.Read.All` を追加し、
+   管理者の同意を与えます。
+4. **Overview** ページで、 **Application (client) ID** と **Directory (tenant) ID** を控えます。
+
+リダイレクト URI は、ユーザーが AnsibleForms にアクセスするアドレスの後に `/api/v2/auth/entraid/callback` を付けたものです。
+[`BASE_URL`](../customization/server.html#env_BASE_URL) が `/forms` の場合は
+`https://af.example.com/forms/api/v2/auth/entraid/callback` になります。プロバイダーの認証情報の **リダイレクト URI** と
+完全に一致する必要があります。
+
+7.2.0 までのパスは `/api/v2/auth/azureadoauth2/callback` でした。7.3.0 からもこのパスは使えるので、既存の登録を変更する必要は
+ありません。 **リダイレクト URI** が空の認証情報は新しいパスを使うので、その場合は新しいパスを登録に追加してください。
+
+AnsibleForms はグループを Graph から読み込み、トークンのグループクレームは使わないので、登録でグループクレームを
+設定する必要はありません。
+
+---
+
+## プロバイダーの追加
+
+**アクセス > SSO** でプロバイダーを追加します。ウィザードが 4 つのステップでフィールドを尋ね、 **種類** のステップでは **Microsoft Entra ID** を選びます。
+
+| ステップ | フィールド | 意味 |
+|---|---|---|
+| 詳細 | 名前、説明 | プロバイダーの一意の名前と、任意の説明 |
+| 種類 | プロバイダー | **Microsoft Entra ID** 。作成時に設定し、変更できません |
+| 認証情報 | 認証情報 | [接続 > 認証情報](../credentials.html) の **Microsoft Entra ID** 認証情報。下記を参照 |
+| グループ | グループフィルター | 正規表現。表示名が一致するグループだけが残ります。空の場合はすべてのグループが残ります |
+
+認証情報はアプリの登録を保持するので、追加、変更できるのは管理者だけです。
+
+| フィールド | 意味 |
+|---|---|
+| テナント ID | 必須。Directory (tenant) ID（GUID）、またはテナントのドメインの一つ。そのテナントのユーザーだけがサインインできます |
+| クライアント ID | Application (client) ID |
+| クライアントシークレット | クライアントシークレットの値。暗号化して保存するか、 [シークレットストア](../secret-stores/) から読み込みます |
+| リダイレクト URI | 登録したとおりの値。例： `https://af.example.com/api/v2/auth/entraid/callback` 。空の場合はアプリの URL とコールバックのパス |
+
+テナント ID が空の認証情報は、保存時に拒否されます。マルチテナントのエンドポイント `common` 、 `organizations` 、
+`consumers` は、その認証情報を指定したプロバイダーの保存時に拒否されます。任意の Microsoft テナントのユーザーがサインインできてしまうためです。サインイン時には、
+トークンが設定されたテナントから来ていることもサーバーが確認します。以前にテナント ID なしで保存されたプロバイダーでは
+誰もサインインできません。テナント ID を入力するまで、サーバーは
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)` をログに記録します。
+
+7.2.0 までは、テナント、クライアント ID、シークレット、リダイレクト URL はプロバイダーのフィールドでした。7.3.0 へのアップグレードでこれらは
+`<provider>-sso` という名前の認証情報に移されます。 [認証情報内のアドレス](../credentials/types.html#addresses-in-credentials) を参照してください。
+新しいプロバイダーには必ず認証情報を選んでください。サーバーは 7.3.0 より前の、独自のクライアント ID とシークレットを持つプロバイダーも
+引き続き受け付け、認証情報が選ばれるまではそれらでサインインします。
+
+同時に有効にできる Entra ID プロバイダーは一つだけで、Entra ID のボタンはそのプロバイダーでサインインします。別のプロバイダーの行メニューの **有効にする** 、
+またはその **有効** スイッチを使うと、同じ種類のほかのプロバイダーはオフになります。リストの **有効** 列で、どれが使われているかがわかります。プロバイダーは
+ログインページをスキップすることもできます。 [シングルサインオンの切り替え](./#switching-single-sign-on) を参照してください。保存するとすぐに、再起動なしで反映されます。
+
+---
+
+## ロールへの対応付け
+
+config.yaml では、Entra ID のグループは `entraid/<object id>` または `entraid/<display name>` 、ユーザーは `entraid/<upn>` と書きます。
+オブジェクト ID はテナント内で一意なので、より安全な選択です。表示名のほうが読みやすくはあります。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+7.2.0 までのプレフィックスは `azuread/` でした。7.3.0 からもロールでは同じメンバーに一致しますが、8.0 で削除されます。
+ロールエディターは `entraid/` と書き込みます。 `entraid/` を受け付けるのはロールだけです。ユーザーのグループは `azuread/<object id>` と
+`azuread/<display name>` として保存され、プロフィールページと extravar `ansibleforms_user` にもそのように表示されます。 `^AF-` のような **グループフィルター** を使うと、ロールで使うグループだけが残ります。 [ロール](../config/roles.html) を参照してください。7.1.0 からは
+サインイントークンにグループが含まれなくなったため、グループが増えてもトークンのサイズは大きくなりません。それでも、多くのグループに
+所属するユーザーにはフィルターが重要です。サインインのたびにロールと照合されるグループが少なくなり、ユーザーの
+[ディレクトリレコード](../users-and-groups/directory.html) には意味のあるグループだけが表示されます。7.1.0 より前は、
+100 以上のグループに所属するユーザーがフォームを表示するにはフィルターが必要です。
+[シングルサインオン後にフォームとジョブが空になる](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431) を参照してください。
+
+---
+
+## Microsoft Graph のエンドポイント
+
+サーバーは既定で `https://login.microsoftonline.com` でユーザーをサインインさせ、 `https://graph.microsoft.com` の Microsoft Graph を呼び出します。
+
+| 変数 | 変わるもの |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | サインインの機関。 `https://login.microsoftonline.us` のような国内クラウド向け |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | グループを読み込む Graph のエンドポイント。例： `https://graph.microsoft.us` |
+
+どちらも末尾にスラッシュのないベース URI を指定し、7.3.0 で追加されました。これらが設定されていない場合は `AZURE_AUTHORITY_URI` と `AZURE_GRAPH_URI` が
+ログに警告を出しつつ引き続き読み込まれますが、8.0 で削除されます。サーバーは Graph に到達できる必要があります。グループを読み込めないとログインは失敗します。
+
+---
+
+## 制限事項
+
+Entra ID のユーザーは Microsoft でサインインするため、ローカルアカウントや LDAP アカウントとはいくつかの点で動作が異なります。
+
+- AnsibleForms にはパスワードがないので、そこでパスワードを変更することはできません。 [API トークン](../profile/api-token.html) はセッションから作成されます。
+- Entra ID では表示名は一意ではありません。同じ名前の二つのグループは同じロールに対応付けられます。そのグループだけに一致させるには、
+  ロールでオブジェクト ID を使って `entraid/<object id>` と指定してください。
diff --git a/i18n/ja/_configure/authentication/index.md b/i18n/ja/_configure/authentication/index.md
new file mode 100644
index 0000000..96a1b66
--- /dev/null
+++ b/i18n/ja/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: 認証
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# 認証
+{: .no_toc }
+
+ユーザーのサインイン方法と、アカウントやグループからロールが決まる仕組みを選びます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ログイン方法
+
+AnsibleForms は 4 つのログイン方法に対応しており、複数を同時に有効にできます。
+
+| 方法 | 使う場面 | ページ |
+|---|---|---|
+| ローカルアカウント | 組み込みの管理者、サービスアカウント、小規模なチーム、またはディレクトリが停止したときの予備。 | [ローカルアカウント](local.html) |
+| LDAP | ユーザーとグループが Active Directory、OpenLDAP、またはその他の LDAP ディレクトリにある場合。 | [LDAP](ldap.html) |
+| Entra ID | ユーザーが Microsoft 365 / Entra ID のアカウントでサインインする場合（シングルサインオン）。 | [Entra ID](entra-id.html) |
+| OIDC | Keycloak など、別の OpenID Connect プロバイダーを使ったシングルサインオン。 | [OIDC](oidc.html) |
+
+ローカルアカウントと LDAP は **アクセス > ユーザー** 、 **グループ** 、 **LDAP** で、Entra ID と OIDC は
+**アクセス > SSO** で設定します。
+
+---
+
+## ログイン方法の決まり方
+
+ログインページには、ユーザー名とパスワードのフォームと、有効なシングルサインオンプロバイダーごとのボタンがあります。
+
+- **ユーザー名とパスワード** は、まずローカルユーザーと照合されます。その名前のローカルユーザーがなく、LDAP
+  が有効な場合にだけディレクトリが試されます。パスワードを間違えたローカルユーザーは、LDAP に問い合わせることなく拒否されます。
+- **Entra ID と OpenID のボタン** は、そのプロバイダーが有効なときに **サインイン** の下に表示されます。ブラウザーをプロバイダーに
+  送り、戻ってきます。パスワードが AnsibleForms に届くことはありません。
+
+同時に有効にできる Entra ID プロバイダーと OIDC プロバイダーはそれぞれ一つだけです。一つを有効にすると、同じ種類のほかのプロバイダーはオフになります。
+ユーザー名とパスワードによるログインが失敗したときは、常に同じ汎用メッセージが表示されます。理由はサーバーログと監査ログに記録されます。
+
+---
+
+## シングルサインオンの切り替え
+
+7.3.0 からは、 **アクセス > SSO** の各プロバイダーに専用のスイッチが二つあり、再起動なしで反映されます。
+
+| スイッチ | 効果 |
+|---|---|
+| **有効** | ログインページにプロバイダーのボタンを表示し、そのサインインを受け付けます。オンにすると、同じ種類のほかのプロバイダーはオフになります。 |
+| **ログインページをスキップ** | プロバイダーが有効な間、ユーザーはログインページを経由せずにこのプロバイダーへ直接移動します。一つのプロバイダーでオンにすると、ほかのプロバイダーではオフになります。オフになっているプロバイダーではグレー表示になります。 |
+
+ユーザー名とパスワードのフォームは、ローカル管理者用やプロバイダーに障害が起きたときのために `/login?local` で引き続き開けます。
+また、サインアウトした後と、シングルサインオンのログインがエラーで戻ってきたときにも表示されます。
+
+変数 `ENABLE_SSO` と `SSO_AUTO_LOGIN` は 7.3.0 で削除されました。7.3.0 の初回起動時に一度だけ読み込まれ、
+設定が残っている間は起動のたびに警告がログに出るので、アップグレード後は環境から削除してください。
+
+| 7.3.0 より前の変数 | アップグレードで行われること |
+|---|---|
+| `ENABLE_SSO=0` | すべてのプロバイダーをオフにします。プロバイダーの設定は残り、ログインページにボタンは表示されません |
+| `SSO_AUTO_LOGIN=1` | 有効なプロバイダーがちょうど一つで、 `ENABLE_SSO` が `0` でない場合、そのプロバイダーの **ログインページをスキップ** をオンにします |
+
+---
+
+## ユーザーからロールへ
+
+ログインのたびに、 **種類** （ `local` 、 `ldap` 、 `azuread` 、 `oidc` ）、ユーザー名、グループのリストを持つユーザーができます。
+各グループには種類のプレフィックスが付くため、Entra ID のグループは `azuread/...` として保存、表示されます。
+
+| ログイン方法 | ユーザー名 | グループ |
+|---|---|---|
+| ローカル | ローカルのユーザー名 | `local/<group>` 。ユーザーのローカルグループごとに一つ |
+| LDAP、 `main` ディレクトリ | Username Attribute の値 | `ldap/<cn>` 。ディレクトリが返す各グループの CN |
+| LDAP、別のディレクトリ | `<directory>/<username>` | `ldap/<directory>/<cn>` 。 [複数のディレクトリ](ldap.html#several-directories) を参照 |
+| Entra ID | `upn` クレーム。トークンに `upn` がない場合は `preferred_username` | Microsoft Graph から読み込んだ各グループの `azuread/<object id>` と `azuread/<display name>` |
+| OIDC | `preferred_username` クレーム | ID トークンの `groups` クレームから得た `oidc/<name>` |
+
+その後、config.yaml の [ロール](../config/roles.html) がこれらの値と照合されます。ロールの `groups` のいずれかがユーザーのグループの
+一つである場合、またはロールの `users` に `<type>/<username>` が含まれる場合に、そのロールが適用されます。すべてのユーザーには `default` ロールも付与されます。7.3.0 からは、
+ロールで Entra ID のメンバーを `entraid/<group>` または `entraid/<upn>` と指定でき、保存されている `azuread/` の値と一致します。ロールでの `azuread/`
+も引き続き使えますが、8.0 で削除されます。プロフィールとジョブの extravars には引き続き `azuread/` と表示されます。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+ユーザーの **プロフィール** ページには、ログインの種類、グループ、ロールが表示されるので、対応付けを確認するにはこれが一番の近道です。
+ロールオプション `allowLogin` を使うと、どのロールにも一致しないユーザーのログインを拒否できます。 `default` では `false` に、
+サインインを許可するロールでは `true` に設定します。
diff --git a/i18n/ja/_configure/authentication/ldap.md b/i18n/ja/_configure/authentication/ldap.md
new file mode 100644
index 0000000..e3f1216
--- /dev/null
+++ b/i18n/ja/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: 認証
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+ディレクトリのユーザーが自分のパスワードでサインインし、ディレクトリのグループを通じてロールを得られるようにします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 仕組み
+
+AnsibleForms はバインドアカウントでディレクトリに接続してユーザーを検索し、そのユーザーとしてバインドしてパスワードを
+確認します。
+
+1. ユーザーがユーザー名とパスワードでサインインします。その名前の **ローカル** ユーザーがいない場合に LDAP が試されます。
+2. AnsibleForms はディレクトリの認証情報にあるバインドアカウントでバインドし、 **検索ベース** の中で **ユーザー名属性** が
+   ユーザー名と等しいエントリを検索します。
+3. 見つかったエントリとして、入力されたパスワードでバインドします。
+4. グループをエントリから（またはグループ検索で）読み込み、フィルターをかけ、 `ldap/` のプレフィックスを付けます。
+
+UPN 形式のユーザー名（ `jdoe@example.com` ）でユーザーが見つからない場合は、 `@` より前の部分で一度だけ再試行されます。そのため、ユーザー名属性が
+短い名前を保持していても、ユーザーはどちらの形式でもサインインできます。パスワードが間違っている場合は再試行されません。
+
+一つの設定で Active Directory、OpenLDAP などに対応します。7.3.0 からは [複数のディレクトリ](#several-directories) を持てます。
+
+---
+
+## 設定
+
+7.3.0 からは、設定はディレクトリごとです。 **アクセス > LDAP** には、ドメインのないユーザー名を検索する順にディレクトリが並びます。
+
+![アクセス > LDAP](../assets/screenshots/ldap.jpg)
+
+| 行メニュー | 動作 |
+|---|---|
+| 編集 | ディレクトリのページを開きます |
+| 接続テスト | テスト用のユーザー名とパスワードでログインを試します。 [接続のテスト](#testing-the-connection) を参照 |
+| 有効にする、無効にする | ディレクトリをオン／オフにします。 `main` は削除せずにオフにします |
+| 上へ移動、下へ移動 | 検索順での位置を変えます |
+| 削除 | ディレクトリを削除します。 `main` では表示されますが無効です |
+
+ディレクトリを追加すると、そのページのタブにあたる 4 つのステップでフィールドを入力します。 **詳細** には **有効** 、 **名前** 、 **説明** があります。
+
+| タブ | 設定 | 意味 |
+|---|---|---|
+| 認証情報 | 認証情報 | 必須。 [接続 > 認証情報](../credentials.html) の `ldap` 認証情報で、接続先を保持します。下記を参照 |
+| ユーザー | 検索ベース | ユーザー検索を始める DN。例： `OU=Users,DC=example,DC=com` 。サブツリーも検索されます |
+| ユーザー | ユーザー名属性 | ログイン名と照合する属性。AD では `sAMAccountName` （既定）、OpenLDAP では `uid` |
+| ユーザー | メール属性 | メールアドレスを保持する属性。通常は `mail` |
+| ユーザー | サインインドメイン | `user@domain` 形式のサインインをこのディレクトリに直接送るドメイン。 [複数のディレクトリ](#several-directories) を参照 |
+| グループ | グループ属性 | グループを保持するユーザーエントリの属性（ `memberOf` 、既定）。グループ検索を使う場合は `groups` |
+| グループ | グループ検索ベース | グループ検索を始める DN |
+| グループ | グループクラス | グループの objectClass。例： `group` 、 `groupOfNames` 、 `posixGroup` |
+| グループ | グループメンバー属性 | メンバーを列挙するグループの属性。例： `member` 、 `uniqueMember` 、 `memberUid` 。既定は `member` |
+| グループ | グループメンバーのユーザー属性 | メンバーの値が保持しているユーザーの属性。例： `dn` 、 `uid` 。既定は `dn` |
+| グループ | グループフィルター | 正規表現。名前が一致するグループだけが残ります。空の場合はすべてのグループが残ります |
+
+最後の三つのグループフィールドの既定値は、グループ検索を使う場合にだけ適用されます。次のセクションを参照してください。
+
+`ldap` 認証情報は、ディレクトリへの接続方法と、どのアカウントで検索するかを保持します。
+
+| フィールド | 意味 |
+|---|---|
+| サーバー | フィールドごとに一つ。 `host` 、 `host:port` 、 `ldaps://host:port` の形式で、この順に試されます。一つに接続できなければ次が試されます |
+| ポート | 通常の LDAP は `389` 、LDAPS は `636` |
+| TLS を有効にする | LDAPS（ `ldaps://` ）で接続します。ポート 389 での StartTLS には対応していません |
+| 証明書を無視 | サーバー証明書の検証を省略します。 **TLS を有効にする** がオンのときだけ表示されます |
+| 証明書 | 証明書を検証する場合に、AnsibleForms がサーバーに提示するクライアント証明書（PEM） |
+| CA バンドル | 証明書を検証する場合に、サーバー証明書に署名した CA 証明書（PEM） |
+| バインドユーザー DN | ディレクトリを検索するサービスアカウントの DN |
+| バインドユーザーのパスワード | そのパスワード。暗号化して保存するか、 [シークレットストア](../secret-stores/) から読み込みます |
+
+`ldap` 認証情報を追加、変更できるのは管理者だけです。 [認証情報を変更できるユーザー](../credentials.html#who-may-change-a-credential) を参照してください。
+7.2.0 までは、サーバー、TLS、バインドアカウントは LDAP 設定のフィールドでした。7.3.0 へのアップグレードでこれらは認証情報に移されます。
+[認証情報内のアドレス](../credentials/types.html#addresses-in-credentials) を参照してください。
+
+| アップグレード前のディレクトリ | サーバーの移動先 |
+|---|---|
+| 独自のバインド DN とパスワードがあり、認証情報がない | `main-ldap` のような `<directory>-ldap` という名前の新しい `ldap` 認証情報 |
+| サーバーのない認証情報がある | その認証情報 |
+| すでに別のサーバーを保持する認証情報がある | `<credential>-<directory>` という名前の認証情報のコピー。ディレクトリはそのコピーを指すようになります |
+
+名前が使われている場合は `-2` 、 `-3` と続きます。構成シードのディレクトリはそのまま残ります。シードが管理しているためです。
+
+---
+
+## グループ
+
+グループは二つの場所のいずれかから取得され、 **グループ属性** がどちらを使うかを決めます。
+
+- **ユーザーエントリの属性** 。通常は `memberOf` です。Active Directory や、 `memberof` オーバーレイを使う
+  OpenLDAP で一般的な構成です。
+- **グループ検索** 。 `memberOf` のないディレクトリ向けです。 **グループ検索ベース** と **グループクラス** の両方が
+  設定されている場合にだけ実行されます。AnsibleForms は、 **グループメンバー属性** にユーザーの **グループメンバーのユーザー属性** を
+  含む、そのクラスのグループを検索し、結果を属性 `groups` に保存します。これを使うには **グループ属性** を `groups`
+  に設定します。
+
+{: .note }
+> **グループ属性** が `memberOf` の場合、設定されたグループ検索は実行されますが、その結果はロールに使われません。
+
+各グループは DN で、AnsibleForms は最初の CN を残します。 `CN=AF-Admins,OU=Groups,DC=example,DC=com` は `AF-Admins` になります。
+その名前に **グループフィルター** が適用され、残ったグループに `ldap/` のプレフィックスが付きます： `ldap/AF-Admins` 。
+
+大きなディレクトリでは、フィルターによってトークンとジョブを小さく保てます。無効な正規表現の場合はすべてのグループが残り、ログに記録されます。
+
+---
+
+## ロールへの対応付け
+
+config.yaml では、LDAP グループは `ldap/<group CN>` 、LDAP ユーザーは `ldap/<username>` と書きます。どちらも大文字と小文字が区別されます。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+ユーザー名は、ユーザーが入力したものではなく、ディレクトリが返す **ユーザー名属性** の値です。
+ロールオプションについては [ロール](../config/roles.html) を参照してください。
+
+---
+
+## 複数のディレクトリ
+
+7.3.0 からは、それぞれ独自のサーバー、ユーザー、グループを持つ複数のディレクトリを使えます。メンバーはディレクトリの名前で区別されます。
+
+| ディレクトリ | ユーザー名 | グループ | ロールでの指定 |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe` 、 `ldap/AF-Admins` |
+| `corp` などそのほか | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe` 、 `ldap/corp/AF-Admins` |
+
+ユーザーはサインイン時に `corp\jdoe` または `corp/jdoe` とディレクトリを指定するか、ディレクトリが持つドメインのアドレスで
+サインインします。ドメインのないユーザー名は、有効なすべてのディレクトリで順に試されます。 `other` という名前のディレクトリがない場合の
+`other\jdoe` のような名前も同様で、入力されたとおりに検索されます。
+
+ユーザーを知っている最初のディレクトリが判定します。そこでパスワードが間違っていればそれが答えとなり、次のディレクトリは
+試されません。同じ名前の別人がいる可能性があるためです。接続できないディレクトリはスキップされます。
+
+7.2.0 まで `default` という名前だったディレクトリは、7.3.0 から `main` という名前になります。アップグレードで名前が変わり、新しいインストールは
+`main` から始まります。メンバーは短い名前のままなので、メンバーを指定しているロールを変更する必要はありません。 `main` ディレクトリは
+名前を変更できず、ディレクトリ名に使えるのは英字、数字、 `-` 、 `_` だけです。
+
+---
+
+## 接続のテスト
+
+**接続テスト** では、テスト用のユーザー名とパスワードを入力し、保存の有無にかかわらず画面上の設定でログインを試します。
+成功すると、ユーザーのディレクトリエントリが表示され、使うべき正確な属性名とグループの DN がわかります。
+
+存在しないテストユーザーでも成功と報告されます。接続とバインドアカウントは機能しており、ユーザーが見つからないだけです。
+よくあるエラー：
+
+| メッセージ | 原因 |
+|---|---|
+| `Bad server or port (connection failed)` | ホスト名を解決できないか、ポートに到達できません。 |
+| `Wrong binding credentials` | ディレクトリの認証情報のバインド DN またはパスワードが間違っています。 |
+| `Unable to verify the certificate` | サーバー証明書が認証情報の CA バンドルで署名されていません。 |
+| `Certificate is not valid` | 認証情報の証明書または CA バンドルに、有効な PEM 証明書が含まれていません。 |
+
+---
+
+## Active Directory の例
+
+この例では、LDAPS で二つのドメインコントローラーに接続し、名前が `AF-` で始まるグループだけを残します。
+
+| 設定 | 値 |
+|---|---|
+| 認証情報 > サーバー | `dc01.example.com` 、次に `dc02.example.com` |
+| 認証情報 > ポート | `636` |
+| 認証情報 > TLS を有効にする | オン |
+| 認証情報 > 証明書を無視 | オフ。クライアント証明書と企業 CA の CA チェーンを設定 |
+| 認証情報 > バインドユーザー DN | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| 検索ベース | `OU=Users,DC=example,DC=com` |
+| メール属性 | `mail` |
+| ユーザー名属性 | `sAMAccountName` |
+| グループ属性 | `memberOf` |
+| グループフィルター | `^AF-` |
+
+`CN=AF-Operators,…` のメンバーは `ldap/AF-Operators` を持つロールに一致し、 `jdoe` または `jdoe@example.com` としてサインインします。
+
+---
+
+## OpenLDAP の例
+
+この例では `groupOfNames` エントリに対するグループ検索を使うため、 `memberof` オーバーレイがなくても動作します。
+
+| 設定 | 値 |
+|---|---|
+| 認証情報 > サーバー | `ldap.example.com` |
+| 認証情報 > ポート | `636` |
+| 認証情報 > TLS を有効にする | オン |
+| 認証情報 > バインドユーザー DN | `cn=readonly,dc=example,dc=com` |
+| 検索ベース | `ou=people,dc=example,dc=com` |
+| メール属性 | `mail` |
+| ユーザー名属性 | `uid` |
+| グループ属性 | `groups` |
+| グループ検索ベース | `ou=groups,dc=example,dc=com` |
+| グループクラス | `groupOfNames` |
+| グループメンバー属性 | `member` |
+| グループメンバーのユーザー属性 | `dn` |
+
+`cn=af-admins,ou=groups,dc=example,dc=com` に含まれるユーザーには、グループ `ldap/af-admins` が付与されます。 `posixGroup` のグループでは、
+**グループメンバー属性** に `memberUid` 、 **グループメンバーのユーザー属性** に `uid` を使います。
+
+`memberof` オーバーレイを使う場合は、グループ検索のフィールドを空にし、 **グループ属性** を `memberOf` に設定します。
+
+---
+
+## よくある落とし穴
+
+LDAP の問題のほとんどは、次のいずれかに行き着きます。
+
+- **同じ名前のローカルユーザー。** ローカルユーザーが先に確認されるため、その名前ではディレクトリに問い合わせが行きません。
+- **グループがない、または違うグループになる。** グループ属性が存在する必要があります（グループ検索では `groups` ）。 `memberOf` は入れ子のグループを扱いません。
+- **グループ名が一致しない。** 大文字と小文字を合わせて `ldap/<CN>` を使い、グループフィルターがそのグループを残すか確認してください。
+- **CN で始まらないグループ DN。** グループ名として使われるのは最初の `CN=` の値だけなので、すべてのグループ DN は
+  `CN=` （または `cn=` ）で始まる必要があります。
+- **証明書。** TLS には認証情報の二つの証明書フィールドと、一致するサーバー名が必要です。証明書を無視はテスト専用です。
+- **保存できない設定。** ディレクトリが [構成シード](../seed/managed-objects.html) から来ている場合、そのページは
+  読み取り専用です。代わりにシードファイルを変更してください。
+
+ログインに失敗すると汎用メッセージが表示されます。理由はサーバーがログに記録し、監査ログにも残ります。Active
+Directory の場合は、ディレクトリのコードから `Wrong password` 、 `Account locked` 、 `Password expired` などに変換されます。
diff --git a/i18n/ja/_configure/authentication/local.md b/i18n/ja/_configure/authentication/local.md
new file mode 100644
index 0000000..67283c7
--- /dev/null
+++ b/i18n/ja/_configure/authentication/local.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: ローカルアカウント
+parent: 認証
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# ローカルアカウント
+{: .no_toc }
+
+組み込みの管理者と、AnsibleForms のデータベースに保存されるユーザーとグループ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 組み込みの管理者
+
+起動のたびに、ローカルの `admins` グループと管理者ユーザーがなければ作成されます。管理者は三つの変数で制御します。
+
+| 変数 | 既定値 | 意味 |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | 管理者のユーザー名。その名前のユーザーがいない場合に `admins` グループに作成されます。 |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | 管理者の作成時（またはリセット時）に設定されるパスワード。 |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` にすると管理者のパスワードを `ADMIN_PASSWORD` にリセットし、 `admins` に戻します。 |
+
+`ADMIN_PASSWORD` が使われるのは、ユーザーの作成時とリセット時だけです。後から変更しても、それだけでは何も起きません。
+
+公開されている既定のパスワード `AnsibleForms!123` でサインインしたローカルユーザーは、パスワードの変更しかできません。ブラウザーには
+閉じられないパスワード変更ページが開き、パスワードが変更されるまで、サーバーはほかのすべてのリクエストに `403` （コード
+`password_change_required` ）を返します。新しいパスワードは既定のものと異なる必要があり、変更後は
+新しいパスワードでもう一度サインインします。この手順を省くには、初回起動の前に `ADMIN_PASSWORD` を独自の値に設定してください。
+
+初回起動後に `ADMIN_USERNAME` を変更すると、その名前で 2 人目の管理者ユーザーが作成されます。元のユーザーは残ります。
+
+{: .warning }
+> `REINIT_ADMIN=1` は、設定されている間 **起動のたびに** パスワードをリセットします。紛失した管理者パスワードの回復に使い、
+> その後は削除して再起動してください。
+
+---
+
+## ユーザーとグループ
+
+ローカルのユーザーとグループは **アクセス > ユーザー** と **アクセス > グループ** で管理します。ユーザーには次のフィールドがあります。
+
+| フィールド | 意味 |
+|---|---|
+| ユーザー名 | ログイン名。一意である必要があります。 |
+| 説明 | 任意。 |
+| パスワード | ハッシュとして保存されます。後から **パスワードを変更** 操作で変更します。 |
+| メールアドレス | 任意。 |
+| グループ | ユーザーの最初のローカルグループ。ほかのグループはユーザーのページの **グループ** タブで追加します。 |
+
+ローカルユーザーは自分のパスワードをプロフィールで変更します。ほかのユーザーは、それぞれのディレクトリまたは ID プロバイダーで変更します。
+
+ユーザーは複数のグループに所属でき、そのすべてのグループのロールが付与されます。ユーザーのページの **グループ** タブでグループを追加、
+削除でき、グループのページの **ユーザー** タブでも同様です。ユーザーには少なくとも一つのグループが残ります。最後のグループは
+削除できません。
+
+ユーザーが残っているグループは削除できません。先にユーザーを外してください。 `admins` グループは削除も名前の変更もできず、
+ユーザー `admin` は削除できません。
+
+---
+
+## サインインの許可
+
+ユーザーのページの **詳細** タブには **サインインを許可** スイッチがあり、ユーザーリストの行メニューにも **サインインをブロック** と **サインインを
+許可** として用意されています。ローカルユーザーにも、LDAP や SSO のユーザーにも使えます。
+
+- **オン**：ユーザーは通常どおりサインインします。
+- **オフ**：ユーザーのセッションはすぐに終了し、管理者が再びオンにするまで、すべてのサインインが拒否されます。ページでは
+  先に確認を求められます。
+
+戻るための手段であるユーザー `admin` ではスイッチをオフにできず、管理者が自分自身のアカウントをオフにすることもできません。LDAP または SSO のユーザーの
+ページには **セッションを終了** もあり、ブロックせずにすべての場所からユーザーをサインアウトさせます。
+
+---
+
+## ロールへの対応付け
+
+ロールでは、ローカルグループを `local/<group>` 、ユーザーを `local/<user>` と指定します。既定では `admins` に `admin` が付与されます。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+組み込みの管理者がディレクトリや ID プロバイダーを使えないときでも必ずサインインできるよう、 `admin` ロールには `local/admins` を残しておいてください。
+config.yaml がまったく読み込めない場合でも、 `local/admins` のメンバーには `admin` ロールが付与されるので、サインインして修正できます。ロールオプションについては [ロール](../config/roles.html) を参照してください。
+
+---
+
+## ローカルアカウントと LDAP
+
+ユーザー名とパスワードによるログインでは、LDAP より先にローカルユーザーが確認されます。ローカルユーザーがディレクトリのユーザーと同じ名前の場合、
+常にローカルアカウントが優先され、その名前ではディレクトリのパスワードは使えません。ローカルアカウントには、
+ディレクトリのアカウントと重ならない名前を付けてください。たとえば `svc-` のプレフィックスを付けます。
diff --git a/i18n/ja/_configure/authentication/oidc.md b/i18n/ja/_configure/authentication/oidc.md
new file mode 100644
index 0000000..60c3ac3
--- /dev/null
+++ b/i18n/ja/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: 認証
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Keycloak などの OpenID Connect プロバイダーによるシングルサインオン。ロールはグループクレームから決まります
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 仕組み
+
+OIDC プロバイダーが有効な場合、ログインページの **サインイン** の下に OpenID のボタンが表示されます。ログインは次のように進みます。
+
+1. ボタンを押すとブラウザーは `/api/v2/auth/oidc` に送られ、そこからプロバイダーにリダイレクトされます（PKCE を使った
+   認可コードフロー）。
+2. ユーザーがプロバイダーでサインインすると、 **リダイレクト URL** に戻されます。
+3. サーバーはコードをトークンと交換し、ID トークンのクレームを読み込みます。
+4. ユーザー名は `preferred_username` クレームで、 `groups` クレームの値のうち **グループフィルター** を
+   通過したものがそれぞれ `oidc/<value>` グループになります。
+
+AnsibleForms はスコープ `openid profile email` を要求します。スコープは設定できません。AnsibleForms からサインアウトすると、
+プロバイダーが公開している場合は、ブラウザーがプロバイダーのセッション終了エンドポイントにも送られます。
+
+{: .note }
+> OIDC は Keycloak でテストされています。ほかのプロバイダーも、以下の要件を満たせば動作します。
+
+---
+
+## プロバイダーの要件
+
+プロバイダーは OpenID Connect ディスカバリーと、AnsibleForms 用のコンフィデンシャルクライアントを提供する必要があります。
+
+- **ディスカバリー** ：AnsibleForms は `<issuer>/.well-known/openid-configuration` を読み込むので、発行者には
+  AnsibleForms サーバーから HTTPS で到達できる必要があります。
+- 認可コードフロー、クライアント ID、クライアントシークレットを持つ **コンフィデンシャルクライアント** 。
+- **リダイレクト URI** `https://af.example.com/api/v2/auth/oidc/callback` 。つまり、ユーザーが AnsibleForms にアクセスするアドレスの
+  後に `/api/v2/auth/oidc/callback` を付けたものです。 [`BASE_URL`](../customization/server.html#env_BASE_URL) が
+  `/forms` の場合は `https://af.example.com/forms/api/v2/auth/oidc/callback` になります。
+- グループ名のリストを保持する **ID トークンの `groups` クレーム** 。これがないと、ユーザーには OIDC グループが付与されません。
+- ユーザー名になる **`preferred_username` クレーム** 。
+
+---
+
+## Keycloak の例
+
+この例では、 `https://keycloak.example.com` 上のレルム `example` を使います。発行者は
+`https://keycloak.example.com/realms/example` になります。そのレルムで次の操作を行います。
+
+1. **Clients** で、クライアント ID `ansibleforms` の OpenID Connect クライアントを作成します。 **Client authentication** をオンにし、
+   **Standard flow** はそのままにして、 **Valid redirect URIs** を `https://af.example.com/api/v2/auth/oidc/callback` に設定します。
+2. クライアントの **Credentials** タブで **Client secret** をコピーします。
+3. **Client scopes** タブで `ansibleforms-dedicated` を開き、 **By configuration > Group Membership** のマッパーを追加します。
+   **Token Claim Name** は `groups` 、 **Full group path** はオフ、 **Add to ID token** はオンにします。
+
+**Full group path** がオンの場合、クレームには `/af-admins` のようなパスが入るので、ロールでは `oidc//af-admins` と指定する必要があります。
+
+---
+
+## プロバイダーの追加
+
+**アクセス > SSO** でプロバイダーを追加します。ウィザードが 4 つのステップでフィールドを尋ね、 **種類** のステップでは **Open ID** を選びます。
+
+| ステップ | フィールド | 意味 |
+|---|---|---|
+| 詳細 | 名前、説明 | プロバイダーの一意の名前と、任意の説明 |
+| 種類 | プロバイダー | **Open ID** 。作成時に設定し、変更できません |
+| 認証情報 | 認証情報 | [接続 > 認証情報](../credentials.html) の **Open ID** 認証情報。下記を参照 |
+| グループ | グループフィルター | 正規表現。 `groups` クレームの値のうち一致するものだけが残ります。空の場合はすべてのグループが残ります |
+
+認証情報はクライアントを保持するので、追加、変更できるのは管理者だけです。
+
+| フィールド | 意味 |
+|---|---|
+| 発行者 (Issuer) | 必須。発行者の URL。例： `https://keycloak.example.com/realms/example` |
+| クライアント ID | プロバイダーでのクライアント ID。例： `ansibleforms` |
+| クライアントシークレット | クライアントシークレット。暗号化して保存するか、 [シークレットストア](../secret-stores/) から読み込みます |
+| リダイレクト URI | 登録したとおりの値。例： `https://af.example.com/api/v2/auth/oidc/callback` 。空の場合はアプリの URL とコールバックのパス |
+
+7.2.0 までは、発行者、クライアント ID、シークレット、リダイレクト URL はプロバイダーのフィールドでした。7.3.0 へのアップグレードでこれらは
+`<provider>-sso` という名前の認証情報に移されます。 [認証情報内のアドレス](../credentials/types.html#addresses-in-credentials) を参照してください。
+新しいプロバイダーには必ず認証情報を選んでください。サーバーは 7.3.0 より前の、独自のクライアント ID とシークレットを持つプロバイダーも
+引き続き受け付け、認証情報が選ばれるまではそれらでサインインします。
+
+同時に有効にできる OIDC プロバイダーは一つだけで、OpenID のボタンはそのプロバイダーでサインインします。別のプロバイダーの行メニューの **有効にする** 、
+またはその **有効** スイッチを使うと、同じ種類のほかのプロバイダーはオフになります。リストの **有効** 列で、どれが使われているかがわかります。
+プロバイダーはログインページをスキップすることもできます。 [シングルサインオンの切り替え](./#switching-single-sign-on) を参照してください。
+
+プロバイダーを保存するとすぐに反映されます。発行者に到達できない場合、サーバーは
+`Failed to initialize OIDC strategy` をログに記録し、プロバイダーを再度保存するかサーバーを再起動するまで OIDC ログインは失敗します。
+
+---
+
+## ロールへの対応付け
+
+config.yaml では、OIDC のグループは `oidc/<group>` 、ユーザーは `oidc/<preferred_username>` と書きます。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+値は大文字と小文字も含めて完全一致で照合されます。ロールオプションについては [ロール](../config/roles.html) を参照してください。
+
+---
+
+## 制限事項
+
+OIDC のユーザーはプロバイダーでサインインするため、ローカルアカウントや LDAP アカウントとはいくつかの点で動作が異なります。
+
+- AnsibleForms にはパスワードがないので、そこでパスワードを変更することはできません。7.2.0 からは [API トークン](../profile/api-token.html)
+  がセッションから作成されます。
+- `groups` クレームは短く保ってください。プロバイダー側で専用のクライアントスコープやグループ構成を使うなどして AnsibleForms に関係のあるグループだけを送るか、
+  **グループフィルター** で絞り込みます。7.1.0 からは AnsibleForms のサインイン
+  トークンにグループが含まれなくなりました。それ以前は、100 以上のグループに所属するユーザーはフォームを表示できないことがありました。
+  [シングルサインオン後にフォームとジョブが空になる](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431) を参照してください。
diff --git a/i18n/ja/_configure/config/categories.md b/i18n/ja/_configure/config/categories.md
new file mode 100644
index 0000000..c3eb917
--- /dev/null
+++ b/i18n/ja/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: カテゴリ
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# カテゴリ
+{: .no_toc }
+
+ダッシュボードのフォームをまとめます。
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## categories 属性
+
+config.yaml の最上位の `categories` リスト：
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Category オブジェクト
+
+`categories` リストの各エントリ：
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/ja/_configure/config/constants.md b/i18n/ja/_configure/config/constants.md
new file mode 100644
index 0000000..c656291
--- /dev/null
+++ b/i18n/ja/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: 定数
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# 定数
+{: .no_toc }
+
+すべてのフォームで再利用できる自由なオブジェクト。
+{: .fs-6 .fw-300 }
+
+---
+
+## constants 属性
+
+config.yaml の最上位の `constants` オブジェクト：
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/ja/_configure/config/index.md b/i18n/ja/_configure/config/index.md
new file mode 100644
index 0000000..6c33cd9
--- /dev/null
+++ b/i18n/ja/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+すべてのフォームに共通のカテゴリ、ロール、定数
+{: .fs-6 .fw-300 }
+
+---
+
+管理者向けです。すべてのフォームで共有するカテゴリ、ロール、定数を保持する config.yaml ファイルについて説明します。
+
+AnsibleForms は config.yaml ファイルを使ってカテゴリ、ロール、定数を設定します。ファイルが用意されていない場合は、最小限の設定でファイルが生成されます。設定をデータベースにインポートすることもでき、その場合 config.yaml ファイルは不要になります。
+
+---
+
+## 概要
+
+config.yaml ファイルには、AnsibleForms が使うカテゴリ、ロール、定数の設定が含まれます。
+
+**動画** ： [最初のフォームを作成する](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+次の最小限の config.yaml を出発点にできます。必須の `Default` カテゴリと、必須の `admin` ロールと `default` ロールだけが含まれています。
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## 設定の読み込みの優先順位
+
+AnsibleForms は次の順に config.yaml ファイルを読み込みます（最初に一致したものが使われます）。
+
+1. **データベースから** ：データベースにインポートした設定。 `ENABLE_CONFIG_IN_DATABASE=1` の場合、またはこの
+   変数が未設定で、データベースに保存された設定の取得元が `database` の場合に限ります（コピーが空ならファイルにフォールバックします）
+2. **リポジトリから（use_for_config）** ：「設定に使用しますか?」スイッチが有効なリポジトリ（6.1.0 で追加）
+3. **リポジトリから（use_for_forms）** ：「フォームに使用しますか?」スイッチが有効なリポジトリ（後方互換性のためのフォールバック）
+4. **ローカルファイルから** ：ローカルの `config.yaml` ファイル（環境変数 CONFIG_PATH）
+
+{: .warning }
+> **注意：** 「設定に使用しますか?」は一つのリポジトリだけで有効にしてください。複数で有効になっている場合は警告がログに記録され、最初のものが使われます。
+
+---
+
+## このセクションの内容
+
+ファイルには三つの最上位の属性があり、それぞれに専用のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [カテゴリ](categories.html) | ダッシュボードのフォームを、アイコン付きのカテゴリのツリーにまとめます |
+| [ロール](roles.html) | ユーザーとグループをロールに対応付け、各ロールにできることを設定します |
+| [定数](constants.html) | すべてのフォームで再利用できる自由なオブジェクト |
diff --git a/i18n/ja/_configure/config/roles.md b/i18n/ja/_configure/config/roles.md
new file mode 100644
index 0000000..d15aae7
--- /dev/null
+++ b/i18n/ja/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: ロール
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# ロール
+{: .no_toc }
+
+ユーザーとグループをロールに対応付け、各ロールにできることを設定します。
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## roles 属性
+
+config.yaml の最上位の `roles` リスト：
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## default ロール
+
+サインインしたすべてのユーザーは `default` ロールを持つので、 `roles: [default]` のフォームはサインインできる全員に公開されます。
+匿名アクセスはありません。サインインせずにこのロールを得ることはできません。
+
+このロールはすでに全員に適用されるため、グループもユーザーも持ちません。その `options` は全員の既定値になります。詳しくは
+下の [ロールオプション](#role-options) を参照してください。 `config.yaml` には `admin` ロールと `default` ロールが必要で、
+ロールのページでは両方とも **必須** と表示されます。
+
+`default` は 7.0.0 より前は `public` と呼ばれていましたが、古い名前も引き続き使えます。
+
+- **フォームでは** 、 `roles: [public]` は引き続きすべてのユーザーに一致するので、リポジトリのフォームを変更する必要はありません。
+- **`config.yaml` では** 、 `public` という名前のロールは、設定の読み込み時にファイル内で `default` に名前が変わります。変わるのは
+  名前だけで、先に設定のバックアップが取られます。リポジトリで管理している設定では、プッシュすべき変更が発生します。
+- **ytt テンプレートでは** 、テンプレートは書き換えられません。生成される設定の名前が変わり、ログの警告で
+  テンプレート内のロール名も変更するよう求められます。バージョン 8 では、そこでの `public` ロールは拒否されます。
+
+`default` ロールと `public` ロールの両方を持つ設定は、同じロールであるため拒否されます。
+
+---
+
+## Role オブジェクト
+
+`roles` リストの各エントリ：
+
+{% include config_object.html name="Role" %}
+
+---
+
+## ロールオプション
+
+ロールの `options` は、そのメンバーに対して機能をオン／オフにします。7.3.0 からは、ロールのページで四つのグループに分けて表示され、
+各オプションには、何ができるようになるかを説明する (i) があります。プロフィールの **権限** ビューと同じテキストです。
+
+| オプション | ユーザーにできること | 既定値 |
+|---|---|---|
+| **設定** | | |
+| `showSettings` | すべての設定ページの表示と変更。サーバーログとバックアップには専用のオプションがあります | 管理者のみ |
+| `showAppearanceSettings` | ほかの設定なしで、外観の設定を変更（7.3.0 から） | オフ |
+| `showConnectionsSettings` | ほかの設定なしで、接続の設定（認証情報、ランナーなど）を管理（7.3.0 から） | オフ |
+| `showLogs` | サーバーログの表示 | 管理者のみ |
+| `showAuditLog` | ほかの設定なしで、監査ログを表示（7.3.0 から） | 管理者のみ |
+| `allowBackupOps` | データベースのバックアップとリストア | 管理者のみ |
+| **デザイナー** | | |
+| `showDesigner` | デザイナーの表示と使用 | 管理者のみ |
+| `allowFormDesign` | デザイナーでフォームの設定（カテゴリ、定数、フォーム）を編集。ない場合は読み取り専用（7.3.0 から） | オン |
+| `allowPlaybookDesign` | デザイナーでプレイブックを編集（保存、作成、削除、プッシュ）。ない場合は読み取り専用 | オン |
+| `allowWorkflowDesign` | デザイナーでワークフローを編集（保存、作成、削除、プッシュ）。ない場合は読み取り専用 | オン |
+| `allowInventoryDesign` | デザイナーでインベントリを編集（保存、作成、削除、プッシュ）。ない場合は読み取り専用 | オン |
+| `allowVarsFileDesign` | デザイナーで変数ファイルを編集（保存、作成、削除、プッシュ）。ない場合は読み取り専用 | オン |
+| **ジョブ** | | |
+| `showJobs` | ジョブページの表示 | オン |
+| `showAllJobLogs` | 自分のジョブだけでなく、すべてのユーザーのジョブを表示 | 管理者のみ |
+| `manageAllJobs` | すべてのユーザーのジョブの中止、削除、再実行。削除と再実行には下の二つのオプションも必要です（7.3.0 から） | 管理者のみ |
+| `showExtravars` | フォームとジョブの extravars を表示 | オン |
+| `showDebugButtons` | フォームのデバッグボタンを表示 | オン |
+| `showArtifacts` | ジョブのアーティファクト（AWX ジョブが返すもの、またはプレイブックが `set_stats` で集めたもの）を表示 | オン |
+| `allowVerboseMode` | 詳細モードでジョブを実行 | オン |
+| `allowJobRelaunch` | 以前の実行のフォームデータでジョブを再実行 | 管理者のみ |
+| `allowJobDeletion` | ジョブの削除。自分のジョブ、または `manageAllJobs` があればすべてのユーザーのジョブ。ない場合はジョブ履歴がすべて残ります（7.3.0 から） | オン |
+| `allowScheduledJobs` | **スケジュール** ページで、繰り返しと一回限りのスケジュールを作成、管理（下の警告を参照） | 管理者のみ |
+| `allowPlannedJobs` | 決まった時刻に一度だけ実行するようジョブを計画（ **後で実行** ） | オン |
+| `allowStoredJobs` | フォームのデータを保存し、後で再び読み込む | オン |
+| **アクセスと連携** | | |
+| `allowLogin` | AnsibleForms にサインイン | オン |
+| `allowChat` | 有効な場合に [チャットアシスタント](../chat/) を使用 | オン |
+| `allowMcp` | 有効な場合に AI エージェントから [MCP サーバー](../mcp/) を使用 | ロールの `allowChat` |
+| `allowFileUploads` | フォームのファイルフィールドからファイルをアップロード（7.3.0 から） | オン |
+| `allowApiTokens` | インスタンスが許す最長の有効期間まで、スクリプト用の [API トークン](../profile/api-token.html) を作成（7.3.0 から） | オフ |
+| `extendedTokenExpiration` | 期限切れにならない API トークンも作成。 `allowApiTokens` が必要です | オフ |
+
+ほかのオプションを含むオプションもあり、ロールのページでは含まれるオプションがオンかつグレー表示になります。
+
+- **`showSettings`** は `showAppearanceSettings` 、 `showConnectionsSettings` 、 `showAuditLog` も与えます。
+- **`manageAllJobs`** は `showAllJobLogs` も与えます。すべてのユーザーのジョブを操作するには、それらを見る必要があるためです。
+- **デザインのオプション** は `showDesigner` がある場合にだけ意味を持ち、 `extendedTokenExpiration` は `allowApiTokens` がある場合だけです。
+
+7.2.0 までは、 `showAllJobLogs` で表示されるジョブの中止と削除もできました。7.3.0 からは `manageAllJobs` が必要です。
+7.3.0 より前の、 `extendedTokenExpiration` があって `allowApiTokens` がないロールには `allowApiTokens` が付与されるので、トークンはそのまま使えます。
+
+**管理者のみ** は、 `admin` ロールを持つユーザーにはオン、それ以外の全員にはオフという意味です。ユーザーが複数のロールに一致する場合、
+オプションは次のように組み合わされます。
+
+- **ユーザーのロールの間では** 、オプションを設定しているすべてのロールが同意している場合にだけオンになります。明示的な `false` が優先されます。
+- **`default` ロール** は、ユーザーのほかのロールがどれも設定していないオプションを補うので、全員の既定値を持たせることができます。
+- **どこにも設定されていないオプション** は、表の既定値になります。
+
+V が大文字の `showExtraVars` も `showExtravars` の別の綴りとして受け付けられます。どちらかの綴りが `false` の場合、
+オプションはオフになります。
+
+{: .warning }
+> `allowScheduledJobs` は管理者レベルのオプションとして扱ってください。スケジュールは作成したユーザーの所有物ではなく、このオプションを持つ
+> すべてのユーザーがすべてのスケジュールを表示、変更できます。また、スケジュールは作成者自身のアクセス権にかかわらず、どのフォームでも管理者権限で実行されます。
+> 管理者として信頼できるロールにだけ付与してください。
+
+{: .warning }
+> `default` ロールで `allowLogin: false` にすると、ほかのロールで `allowLogin: true` を設定していないすべてのユーザーが、管理者も含めて
+> 締め出されます。保存する前に、サインインが必要なロールで改めて許可してください。
diff --git a/i18n/ja/_configure/credentials.md b/i18n/ja/_configure/credentials.md
new file mode 100644
index 0000000..e93b50b
--- /dev/null
+++ b/i18n/ja/_configure/credentials.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: 認証情報
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# 認証情報
+{: .no_toc }
+
+フォーム、リポジトリ、シークレットストア、通知チャネルが接続に使うログインを保存します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。AnsibleForms が接続に使うユーザー、パスワード、トークンを追加します。これらは暗号化して保存するか、シークレットストアから読み込みます。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [認証情報の種類](credentials/types.html) | 各種類が保持するものと、選択できる場所 |
+| [認証情報ページ](credentials/list.html) | 認証情報のリストと、認証情報を追加するダイアログ |
+| [認証情報のページ](credentials/credential-page.html) | 認証情報のタブと、それを使っているもの |
+
+---
+
+## 仕組み
+
+**認証情報** は名前の付いたログインで、 **接続 > 認証情報** で追加します。フォームやほかの管理オブジェクトは
+名前で認証情報を参照するので、パスワード自体がフォームに現れることはありません。ユーザーとパスワードは、
+`ENCRYPTION_SECRET` で暗号化して AnsibleForms のデータベースに保存するか、認証情報が使われるたびに [シークレットストア](secret-stores/) から
+読み込みます。
+
+---
+
+## 認証情報を変更できるユーザー
+
+7.3.0 からは、接続やサインインが依存している認証情報の追加、変更、削除は管理者だけが行えます。
+
+| 認証情報 | 理由 |
+|---|---|
+| 接続の種類： `rte` 、 `awx` 、 `aap` 、 `ascender` 、 `semaphore` 、 `rundeck` 、 `jenkins` 、 `vault` 、 `cyberark` | ランナーやシークレットストアが、アドレスとシークレットをそこから取得します |
+| サインインの種類： `oidc` 、 `entraid` 、 `ldap` | SSO プロバイダーや LDAP ディレクトリが、それを使ってユーザーをサインインさせます |
+| ランナーが指定しているすべての認証情報 | ランナーはそれを使ってサインインし、ランナー自体の変更にも管理者が必要です |
+
+認証情報にアクセスできるほかのユーザーには、これらは読み取り専用で表示されます。こうした認証情報を別のサーバーに向けられるユーザーは、
+それを通じて送られるすべてのシークレットを受け取れてしまいます。そのため、このルールはランナーのルールに合わせています。さらに次の三つのルールで、
+本来は読めないシークレットにそうしたユーザーが近づけないようにしています。
+
+- **保護された認証情報の指定** ：リポジトリ、通知チャネル、チャットアシスタントの設定など、ほかの場所でこれらの認証情報を
+  指定できるのは管理者だけです。パスワードをシークレットストアから読み込む認証情報も、種類にかかわらず同じように保護されます。
+- **シークレットストアの選択** ：認証情報を [シークレットストア](secret-stores/) に向けたり、読み込むストアや参照を変更したりできるのは
+  管理者だけです。ほかのユーザーも、それらを変更せずにそのまま送り返すか、すべてを空にすることはできます。
+- **認証情報の移動** ：ほかのユーザーが、パスワードを入力し直さずに認証情報のログイン先（ホスト、ポート、発行者、テナント、
+  サーバーのアドレス）を変更すると、保存されているパスワードは消去され、読み込むシークレットストアの参照も消去されます。
+  これにより、古いシークレットが新しい接続先に送られることはありません。
+
+---
+
+## 使用中の認証情報
+
+レコードが指定している認証情報は、削除も名前の変更もできません。そうしたレコードが何も指さない状態になってしまうためです。
+拒否されたときは、その認証情報を使っているレコードの数が示されます。 [認証情報のページ](credentials/credential-page.html) の **使用元** タブに一覧が表示されます。
+先にそれらを別の認証情報に向けてから、削除または名前の変更を行ってください。
diff --git a/i18n/ja/_configure/credentials/credential-page.md b/i18n/ja/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..71cc0a8
--- /dev/null
+++ b/i18n/ja/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: 認証情報のページ
+parent: 認証情報
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# 認証情報のページ
+{: .no_toc }
+
+認証情報のタブと、それを使っているもの
+{: .fs-6 .fw-300 }
+
+認証情報のページには、ダイアログのステップがタブとして表示され、さらにそれを使っているものも表示されます。
+
+| タブ | 内容 |
+|---|---|
+| 詳細 | 名前と説明。 |
+| 種類 | 認証情報の用途。 |
+| ログイン | ダイアログの **ログイン** ステップと同じく、その種類のすべてのフィールド。ユーザー、パスワード、ログイン先（ホストとポート、データベース、メールサーバー、ディレクトリのサーバー、テナントまたは発行者、サーバーのアドレスとその TLS）。CyberArk 認証情報の場合は AppID、クライアント証明書、キー。 |
+| 保存先 | データベースまたはシークレットストアと、ストアおよび参照。CyberArk と HashiCorp Vault にはありません。 |
+| 使用元 | この認証情報を指定しているすべてのもの。シークレットストア、通知チャネル、リポジトリ、LDAP ディレクトリ、SSO プロバイダー、ランナー、チャットアシスタント、フォーム、デザイナーのワークフロー。行をクリックすると開きます。 |
+
+パスワードは **ログイン** タブで入力し、一度保存すると二度と表示されません。空のままにすると、保存されているものが残ります。CyberArk
+認証情報では、保存されているクライアントキーを残すにはクライアントキーを空のままにします。右上には **接続テスト** （データベースの認証情報のみ）、
+**削除** 、 **保存** があります。
+
+7.3.0 からは、 **使用元** に何かが表示されている間は **削除** と新しい名前は拒否されます。 [使用中の認証情報](../credentials.html#credentials-in-use) を参照してください。
+
+[構成シード](../seed/) で宣言された認証情報は、このページでは読み取り専用です。代わりにシードファイルで変更してください。
diff --git a/i18n/ja/_configure/credentials/list.md b/i18n/ja/_configure/credentials/list.md
new file mode 100644
index 0000000..b45396e
--- /dev/null
+++ b/i18n/ja/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 認証情報ページ
+parent: 認証情報
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# 認証情報ページ
+{: .no_toc }
+
+認証情報のリストと、認証情報を追加するダイアログ
+{: .fs-6 .fw-300 }
+
+**接続 > 認証情報** のページには、すべての認証情報が **名前** 、 **種類** 、 **説明** 、 **使用元** とともに表示されます。使用元は、
+その認証情報を指定しているレコード、フォーム、ワークフローの数です（ [使用中の認証情報](../credentials.html#credentials-in-use) を参照）。
+
+**認証情報を追加** を押すと、ステップ形式のダイアログが開きます。
+
+| ステップ | フィールド |
+|---|---|
+| 認証情報 | 名前と説明。どちらも必須です。 |
+| 種類 | 18 種類のいずれか。下記を参照。 |
+| ログイン | その種類が何を使ってどこにログインするか。下記を参照。 |
+| 保存先 | ユーザーとパスワードの保存場所。 **データベース** （AnsibleForms のデータベースに暗号化して保存）または **シークレットストア** で、後者の場合はストアとその中の **参照** を指定します。シークレットストアのログインに使う CyberArk と HashiCorp Vault にはありません。 |
+
+**種類** ステップには、種類が名前で表示されます。AAP、API、Ascender、AWX、CyberArk、データベース、Git、HashiCorp Vault、Jenkins、LDAP、
+Microsoft Entra ID、Open ID、RTE、Rundeck、Semaphore、SMTP、SSH、ユーザーとパスワードです（ [認証情報の種類](types.html) を参照）。
+
+**ログイン** ステップには、アドレスを含め、その種類のすべてのフィールドがあります。接続用の別のステップはありません。
+
+| 種類 | ログインステップのフィールド |
+|---|---|
+| CyberArk 以外のすべての種類 | パスワード、またはその代わりになるもの。LDAP のバインドパスワード、Entra ID と Open ID のクライアントシークレット、HashiCorp Vault のトークン、RTE トークン、Semaphore、Rundeck、Jenkins の API トークン、AWX、AAP、Ascender のトークンまたはパスワード |
+| HashiCorp Vault、RTE、Semaphore、Rundeck 以外のすべての種類 | ユーザー。CyberArk の AppID、LDAP のバインド DN、Entra ID と Open ID のクライアント ID。AWX、AAP、Ascender では任意 |
+| SSH、データベース | **ホスト** と **ポート** 。データベースの場合は **データベースの種類** と **データベース** も |
+| SMTP | **メールサーバー** （必須）、その **ポート** と **TLS を使用** |
+| LDAP | ディレクトリの **サーバー** （必須）、その **ポート** と **TLS を有効にする** 。TLS の場合は **証明書を無視** 、 **CA バンドル** 、 **クライアント証明書** |
+| Microsoft Entra ID | **テナント ID** （必須）と **リダイレクト URI** |
+| Open ID | **発行者 (Issuer)** （必須）と **リダイレクト URI** |
+| HashiCorp Vault、CyberArk、RTE、AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins | ログイン先のアドレスである **サーバー** （必須）と、 **証明書の検証をスキップ** 、 **CA バンドル** |
+| CyberArk | **クライアント証明書** と **クライアントキー** |
+
+行をクリックすると、その認証情報のページが開きます。行メニューには **編集** 、 **接続テスト** （データベースの認証情報のみ）、 **削除** があります。
+パスワードは認証情報のページの **ログイン** タブで変更します。
diff --git a/i18n/ja/_configure/credentials/types.md b/i18n/ja/_configure/credentials/types.md
new file mode 100644
index 0000000..a1e5f2d
--- /dev/null
+++ b/i18n/ja/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: 認証情報の種類
+parent: 認証情報
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# 認証情報の種類
+{: .no_toc }
+
+各種類が保持するものと、選択できる場所
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 種類
+
+種類は、認証情報の用途を示します。ダイアログが尋ねるフィールドと、その認証情報を選択できる場所は種類によって決まります。
+
+| 種類 | 保持するもの | 使用するもの |
+|---|---|---|
+| ユーザーとパスワード | 任意のログイン用のユーザーとパスワード。ベーシック認証の REST API、サービスなど。既定の種類です | フォームの `credentials` または認証情報フィールドを通じたプレイブック、 [REST 式](../expressions/credentials.html) |
+| SSH | サーバーへの SSH 用のユーザーとパスワード、およびそのホストとポート | フォームの `credentials` 、 `ansibleCredentials` 、または認証情報フィールドを通じたプレイブック、ワークフローノードのログイン |
+| Git | git リポジトリ用のユーザーとパスワードまたはトークン | [リポジトリ](../repositories/authentication.html) |
+| API | REST API 用のユーザーとパスワードまたはトークン | [REST 式](../expressions/credentials.html) 、Telegram ボットのトークン、Webhook のベアラートークン、チャットアシスタントの API キー |
+| データベース | データベースのログイン。種類、ホスト、ポート、データベース名を含みます | フォームのクエリ（ `dbConfig` ）と `fnCredentials` 。テストできます |
+| CyberArk | CyberArk Central Credential Provider（CCP）のアドレスとその TLS、CyberArk ストアがログインに使う AppID、クライアント証明書、キー | [CyberArk](../secret-stores/cyberark.html) シークレットストア |
+| SMTP | メールサーバー、そのポートと TLS、ログイン（リレーの場合はなし） | メールの [通知チャネル](../notification-channels.html) |
+| LDAP | ディレクトリのサーバー、ポート、TLS、証明書、バインド DN とパスワード | [LDAP ディレクトリ](../authentication/ldap.html) |
+| Microsoft Entra ID | プロバイダーのアプリの登録。テナント ID、クライアント ID、クライアントシークレット、リダイレクト URI | [Entra ID プロバイダー](../authentication/entra-id.html) |
+| Open ID | プロバイダーのクライアント。発行者、クライアント ID、クライアントシークレット、リダイレクト URI | [OIDC プロバイダー](../authentication/oidc.html) |
+| RTE | RTE のトークン（ `RTE_TOKEN` ）とアドレス | RTE の [ランナー](../runners.html) |
+| AWX、AAP、Ascender | そのプラットフォームのトークンまたはログインと、アドレス | その種類のランナー |
+| Semaphore、Rundeck | その製品の API トークンとアドレス | その種類のランナー |
+| Jenkins | Jenkins のユーザー、その API トークンとアドレス | Jenkins ランナー |
+| HashiCorp Vault | Vault ストアがログインに使うトークンとアドレス | [HashiCorp Vault](../secret-stores/hashicorp-vault.html) シークレットストア |
+
+データベースの認証情報の種類には、MySQL、MSSQL、PostgreSQL、Oracle、MongoDB があります。
+
+API と [構成シード](../seed/) では、種類は `userpass` 、 `ssh` 、 `git` 、 `api` 、 `database` 、 `cyberark` 、 `smtp` 、
+`ldap` 、 `entraid` 、 `oidc` 、 `rte` 、 `awx` 、 `aap` 、 `ascender` 、 `semaphore` 、 `rundeck` 、 `jenkins` 、 `vault` です。バージョン 6 からの
+アップグレードでは、すべての認証情報に種類 `userpass` 、データベースのものには `database` が付与されます。フォームでは 6 と同じように使われます。ワークフローノードの
+プレイブックが接続に使うログインは SSH に、REST API 用のものは API に変更してください。
+
+---
+
+## 認証情報内のアドレス
+
+7.3.0 からは、一つのサーバーで使うログインはそのサーバーを持つので、それを使うレコードは認証情報を指定するだけで済みます。
+
+| レコード | 認証情報に移されたもの |
+|---|---|
+| LDAP ディレクトリ | サーバー、ポート、TLS、証明書、バインドアカウント。 `<directory>-ldap` という名前の `ldap` 認証情報へ |
+| SSO プロバイダー | クライアント ID とシークレット、テナントまたは発行者、リダイレクト URI。 `<provider>-sso` という名前の `entraid` または `oidc` 認証情報へ |
+| ランナー | アドレスと TLS、トークンまたはログイン。その種類の認証情報 `<runner>-token` または `<runner>-login` へ |
+| シークレットストア | アドレスと TLS、トークン（ `<store>-token` ）、または CyberArk の AppID と証明書（ `<store>-appid` ） |
+| メールチャネル | サーバー、ポート、TLS。その `smtp` 認証情報、または `<channel>-smtp` という名前の新しい認証情報へ |
+
+7.3.0 へのアップグレードで、これらの移動が一度だけ行われます。すでに認証情報を指定していたレコードはそれを使い続けますが、
+別のレコードが同じログインを別のサーバーで使っていた場合は、そのコピーが作られます。 [構成シード](../seed/) で宣言されたレコードは、シードの内容のまま残ります。
+接続とサインインの認証情報を変更できるのは管理者だけです。 [認証情報を変更できるユーザー](../credentials.html#who-may-change-a-credential) を参照してください。
diff --git a/i18n/ja/_configure/customization/configuration.md b/i18n/ja/_configure/customization/configuration.md
new file mode 100644
index 0000000..435e72c
--- /dev/null
+++ b/i18n/ja/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: 設定
+parent: 環境変数
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# 設定
+{: .no_toc }
+
+構成シード、設定の保存場所、git と ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+設定の取得元（構成シード、データベース、git、ytt テンプレート）を決めるには、これらを変更します。
+
+---
+
+## 例
+
+マウントした構成シードを適用して 5 分ごとに確認し、 `config.yaml` をデータベースに保持します。 `docker-compose.yml` では次のようにします。
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+シードが無効な場合、サーバーは起動しません。ファイル形式については [構成シード](../seed/) を参照してください。
+
+---
+
+## config.yaml の読み込み元
+
+カテゴリ、ロール、定数は、ディスク上の `config.yaml` またはデータベース内のそのコピーから取得され、次の順で決まります。
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE) が環境または設定ページの **設定** タブで
+   設定されている場合はそれに従います。 `1` はデータベースを、 `0` はファイルを読み込みます。
+2. そうでない場合は、データベースに保存されている設定の取得元（ `file` または `database` ）。6.3.0 より前に構築したインスタンスが
+   設定ページで選んだものです。
+3. そうでない場合はファイルです。 **設定に使用しますか?** が有効なリポジトリの `config.yaml` 、なければ
+   **フォームに使用しますか?** が有効なリポジトリのもの、それもなければ [`CONFIG_PATH`](paths.html#env_CONFIG_PATH) にあるものです。
+
+明示的に設定された `ENABLE_CONFIG_IN_DATABASE` は常に優先され、保存されている `database` よりも `0` が優先されます。設定を
+読み込むたびに読まれるので、変更は再起動なしで反映されます。 **ステータス** ページの **情報** タブに、使われている取得元が表示されます。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/ja/_configure/customization/features.md b/i18n/ja/_configure/customization/features.md
new file mode 100644
index 0000000..742fb33
--- /dev/null
+++ b/i18n/ja/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 機能
+parent: 環境変数
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# 機能
+{: .no_toc }
+
+デザイナー、MCP、チャット、起動時の検証、ジョブリスト、メトリクス、AWX API、クエリのログ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+アプリケーションの任意の機能をオン／オフにするには、これらを変更します。
+
+---
+
+## 例
+
+AI エージェント向けに MCP サーバーを提供し、起動のたびにフォームの検証ルールを強制します。compose プロジェクトの `.env` では次のようにします。
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` と `ENABLE_CHAT` は再起動なしで反映されます。リクエストのたびに読み込まれるので、設定ページで
+切り替えられます。オフの間は、そのエンドポイント（ `/api/v2/mcp` または `/api/v2/chat` ）は `404` を返します。
+
+まずはしばらく `LAUNCH_VALIDATION=log` で運用してください。 `enforce` で拒否されるものを、拒否せずにログに記録します。 [MCP](../mcp/)
+と [ログと強制](../launch-validation/log-and-enforce.html) を参照してください。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/ja/_configure/customization/index.md b/i18n/ja/_configure/customization/index.md
new file mode 100644
index 0000000..20c7151
--- /dev/null
+++ b/i18n/ja/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: 環境変数
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# 環境変数
+{: .no_toc }
+
+環境変数で AnsibleForms を設定します
+{: .fs-6 .fw-300 }
+
+---
+
+AnsibleForms をデプロイする管理者向けです。サーバーが読み込む環境変数を、トピックごとにまとめて説明します。
+
+AnsibleForms は、Docker Compose、Kubernetes、ソースのいずれで実行する場合も、環境変数で調整します。
+
+---
+
+## 値の取得元
+
+サーバーは各変数を、次の取得元のうちその変数を設定している最初のものから読み込みます。そのため、リストの上にある値が常に優先されます。
+
+1. **プロセスの環境** ：docker-compose の `environment:` と `env_file:` （プロジェクトの `.env` はこの方法で渡されます）、
+   Kubernetes の `env` と `envFrom` 、または `node` を起動するシェル。
+2. **`persistent/.env`** 。設定ページが書き込むファイルです（docker-compose プロジェクトでは `data/.env` 、
+   `MANAGED_ENV_PATH` で別のパスにもできます）。本番環境でも起動のたびに読み込まれ、すでに設定されている変数を上書きすることはありません。
+3. **`server/.env.<NODE_ENV>`** 。たとえば `.env.development` です。 `NODE_ENV` が `production` でない場合（または
+   `FORCE_DOTENV=1` の場合）にだけ読み込まれます。実際には、開発モードで [ソースから](../installation/from-source.html) 実行する場合です。
+4. **組み込みの既定値** 。各グループの表に記載されています。
+
+**設定 > 全般** の設定ページには現在有効な値が表示され、変更は `persistent/.env` に保存されます。多くの変数は
+保存するとすぐに反映されます。ほかの変数は保存されますが再起動が必要で、保存後にページに一覧が表示されます。プロセスの環境で
+設定された変数はそこでは変更できず、ページには *環境で設定されているため、ここでは変更できません。* と表示されます。
+`ENCRYPTION_SECRET` や `ACCESS_TOKEN_SECRET` など、ページから決して変更できない変数もいくつかあります。
+
+`AF_ROLE` 、 `RTE_MODE` 、 `APP_URL` 、 `RTE_MAX_JOBS` など、RTE が読み込む変数は設定ページにはまったくありません。
+アプリはそれらを使わないので、RTE を実行する環境で設定してください。アプリ自身が読み込む `RTE_*` 変数、
+`RTE_QUEUE_MINUTES` と `RTE_FILES_MAX_MB` は例外で、ページに残っています。RTE の四つの変数 `RTE_MAX_JOBS` 、
+`RTE_CACHE_MB` 、 `RTE_FILES` 、 `RTE_DRAIN_SECONDS` は、代わりに RTE ごとにランナーのページで設定することもでき、そこでの値が
+変数より優先されます（ [RTE の設定](../runners/runner-page.html#an-rtes-settings) を参照）。
+
+[`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` の場合、ページには値が表示されるだけで、保存は拒否されます。
+[編集と監査](../seed/environment-and-audit.html) で説明しているように、環境をマニフェストで宣言している場合に使います。
+
+[構成シード](../seed/) は環境変数を設定しません。データベースに保存されるオブジェクトを宣言し、その中の
+`${ENV_VAR}` 参照は実行中のサーバーの環境から解決されます。
+
+環境からだけ読み込まれ、表には載っていない変数もいくつかあります。上で説明した `MANAGED_ENV_PATH` と `FORCE_DOTENV` 、
+そしてシステムのプロキシ変数 `HTTPS_PROXY` と `NO_PROXY` （小文字も読み込まれます）です。アウトバウンドの RTE は `HTTPS_PROXY` を
+経由してアプリに接続し、インバウンドの RTE は登録の呼び出しをそれ経由で送ります。ただし、アプリのホストが `NO_PROXY` （ホスト名、
+`.domain` サフィックス、またはすべてのホストを表す `*` ）に含まれる場合は除きます。
+
+<span class="af-badge af-badge-secret">シークレット</span> の付いた変数は、パスワード、トークン、キーを保持します。Kubernetes の Secret や
+コミットしない `.env` ファイルなどに置き、バージョン管理に含めないでください。
+
+---
+
+## このセクションの内容
+
+変数はトピックごとにグループ化され、グループごとに一つのページがあります。
+
+| ページ | 内容 |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## その他の変数
+
+次の変数は、まだどのグループにも割り当てられていません。
+
+{{ other }}
+{% endif %}
diff --git a/i18n/ja/_configure/customization/logging.md b/i18n/ja/_configure/customization/logging.md
new file mode 100644
index 0000000..7072de3
--- /dev/null
+++ b/i18n/ja/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: ログ
+parent: 環境変数
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# ログ
+{: .no_toc }
+
+ログレベル、ファイル、syslog、コンソールの色
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+ログに記録する量やログファイルの保存先を調整したり、タイムスタンプを独自のタイムゾーンで表示したりするには、これらを変更します。
+
+---
+
+## 例
+
+コンソールよりファイルに多くのログを記録し、ログとジョブのタイムスタンプをアムステルダム時間で表示します。
+compose プロジェクトの `.env` では次のようにします。
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Syslog サーバーはここでは設定しなくなりました。 **設定 > 接続 > Syslog** で追加してください。 [ログ](../production/logs.html#syslog) を参照してください。
+下の `LOG_SYSLOG_*` 変数はバージョン 7 から非推奨です。 `LOG_SYSLOG_HOST` が設定されていることを検出した最初の起動で、それらは一度だけ
+サーバーログを受け取る syslog サーバー `syslog` としてインポートされ、以降は無視されます。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/ja/_configure/customization/paths.md b/i18n/ja/_configure/customization/paths.md
new file mode 100644
index 0000000..128f0ec
--- /dev/null
+++ b/i18n/ja/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: パス
+parent: 環境変数
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# パス
+{: .no_toc }
+
+設定、フォーム、プレイブック、アップロード、バックアップの保存場所
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+データの一部を別のボリュームに置くには、これらを変更します。たとえば、バックアップとアップロードを大容量または安価なストレージに置く場合です。
+
+---
+
+## 例
+
+バックアップとアップロードしたファイルを別のボリュームに置き、残りのデータは通常の永続フォルダーに置きます。 `docker-compose.yml` では次のようにします。
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+新しいパスは新しいファイルにだけ適用されます。古いフォルダーにすでにあるものは移動されないので、自分でコピーしてください。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/ja/_configure/customization/retention.md b/i18n/ja/_configure/customization/retention.md
new file mode 100644
index 0000000..de0b74b
--- /dev/null
+++ b/i18n/ja/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: バックアップと保持期間
+parent: 環境変数
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# バックアップと保持期間
+{: .no_toc }
+
+バックアップのコマンドと、バックアップ、ジョブ、監査レコードの保持期間
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+データベースに残す履歴の量と、ディスクに残すバックアップの数を制御するには、これらを変更します。
+
+---
+
+## 例
+
+終了したジョブを 90 日間、監査証跡を 2 年間保持します。compose プロジェクトの `.env` では次のようにします。
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+毎日のタスクが、午前 2 時 30 分にこれより古い終了済みのジョブを、午前 3 時 30 分に監査エントリを削除します。実行中のジョブや
+承認待ちのジョブは削除されません。どちらの変数も、設定ページで変更すると再起動なしで反映されます。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/ja/_configure/customization/security.md b/i18n/ja/_configure/customization/security.md
new file mode 100644
index 0000000..2444e08
--- /dev/null
+++ b/i18n/ja/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: セキュリティの変数
+parent: 環境変数
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# セキュリティの変数
+{: .no_toc }
+
+トークン、暗号化、外部への REST ホスト、マスキング、古い VAULT_* 設定
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+独自のトークンと暗号化のシークレットを設定し、フォームが呼び出せるものと表示できるものを制限するには、これらを変更します。
+
+---
+
+## 例
+
+独自のシークレットを使い、REST の呼び出しを一つの API と内部ネットワークに制限し、マスクするキーを一つ追加します。compose プロジェクトの `.env` では次のようにします。
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+`ENCRYPTION_SECRET` は、最初の認証情報を保存する前に設定してください。7.3.0 からは、設定または変更すると、次回の起動時に保存されている
+すべてのシークレットが再暗号化されます。古いキーが独自のものだった場合は `ENCRYPTION_SECRET_PREVIOUS` でそれを指定します。
+[暗号化シークレットの変更](../security/secrets.html#changing-the-encryption-secret) を参照してください。
+
+---
+
+## REST の呼び出しと jq
+
+7.3.0 からは、REST のヘルパー関数（ `fn.fnRestBasic` 、 `fn.fnRestAdvanced` 、 `fn.fnRestJwt` 、 `fn.fnRestJwtSecure` ）は、ほかのすべての接続と同じく、
+呼び出すエンドポイントの証明書を検証します。7.2.0 までは検証していませんでした。これらには三つの設定が適用されます。
+
+| 変数 | 既定値 | 効果 |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` にすると証明書の検証を省略します。自己署名証明書を持つエンドポイント専用です |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | REST の呼び出しがタイムアウトで失敗するまでに応答を待つ時間 |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | jq フィルターが停止されるまでに実行できる時間。jq の出力も 64 MB に制限されます |
+
+三つとも、保存すると再起動なしで反映されます。プライベート CA が署名した証明書を持つエンドポイントでは、検証はオンのままにして、
+代わりにその CA を Node.js に渡してください。アプリの環境で `NODE_EXTRA_CA_CERTS` にその CA を含む PEM ファイルを設定し、アプリを再起動します。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/ja/_configure/customization/server.md b/i18n/ja/_configure/customization/server.md
new file mode 100644
index 0000000..db9e478
--- /dev/null
+++ b/i18n/ja/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: サーバーとデータベース
+parent: 環境変数
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# サーバーとデータベース
+{: .no_toc }
+
+Web サーバー、MySQL の接続、管理者アカウント、各プロセスが実行するもの（AF_ROLE と RTE_* 変数）
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+アプリケーションをリバースプロキシの背後で、別のポートで、または compose プロジェクト外のデータベースに対して実行する場合は、これらを変更します。
+
+---
+
+## 例
+
+TLS を終端するリバースプロキシの背後で、 `/ansibleforms` の下に置き、外部の MySQL を使います。 `docker-compose.yml` では次のようにします。
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+これらは、compose ファイルのその場所にすでにある `DB_*` と `PORT` の行を置き換えます。それらの行は `.env` の同じ名前より優先されます。
+`mysqldb` サービスと、それを待つ `depends_on` を削除し、 `ports` でポート 8000 をマッピングしてください。プロキシ側の設定は
+[リバースプロキシ](../production/reverse-proxy.html) のページで説明しています。
+
+---
+
+## 変数
+
+このグループのすべての変数と、その型、既定値、説明：
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/ja/_configure/disclaimer.md b/i18n/ja/_configure/disclaimer.md
new file mode 100644
index 0000000..3c3d352
--- /dev/null
+++ b/i18n/ja/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: 免責事項
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# 免責事項
+{: .no_toc }
+
+すべてのユーザーがアプリを使う前に一度同意する規約。誰がどの版にいつ同意したかが記録されます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。 **設定 > アクセス > 免責事項** で、ロールオプション `showSettings` を使い、すべてのユーザーに利用規約への同意を求めます。
+
+7.3.0 からは、ページに免責事項のすべての版が表示され、各版はその同意記録とともに専用のページで開きます。
+7.2 までは、代わりに三つのタブ（ **全般** 、 **版** 、 **同意記録** ）がありました。アップグレードしてもすべての版は残ります。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [全般](disclaimer/general.html) | 版のリスト、版の追加、ユーザーが同意する版の有効化 |
+| [版](disclaimer/versions.html) | 版のページと、修正として、または全員に再度求めるための本文の変更 |
+| [同意記録](disclaimer/acceptances.html) | 誰がどの版に同意したか、および選んだユーザーへの再同意の要求 |
+
+
+---
+
+## ユーザーに表示されるもの
+
+版が有効な場合、サインインしたすべてのユーザーには、管理者も含め、何よりも先にダイアログでその版が表示されます。
+
+1. タイトルと本文を読みます。
+2. チェックボックスをオンにし、 **同意する** をクリックします。赤い **同意しない** を押すと、代わりにサインアウトされます。
+
+7.3.0 からは、ユーザーが応答するまでダイアログの背後のページはぼかして表示されます。
+
+ユーザーは各版に一度だけ同意します。次回のサインインでは再度求められず、求められるのは新しい版が出たとき、
+管理者が変更した本文を [全員に再度求める](disclaimer/versions.html#changing-the-text) で保存したとき、または管理者がその同意に対して
+[再同意を求める](disclaimer/acceptances.html#asking-users-again) を使ったときだけです。
+
+同意するまでは、API はそのセッションのすべての呼び出しに、ステータス `403` とコード `disclaimer_required` を返します。
+ただし、 `/api/v2/disclaimer` と `/api/v2/profile` の下の呼び出しと、ブラウザーが受け取るライブイベントは除きます。
+[API トークン](profile/api-token.html) には同意は求められません。スクリプトにはクリックする人がいないためです。
+
diff --git a/i18n/ja/_configure/disclaimer/acceptances.md b/i18n/ja/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..6017b04
--- /dev/null
+++ b/i18n/ja/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 同意記録
+parent: 免責事項
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# 同意記録
+{: .no_toc }
+
+誰がどの版に同意したか、および選んだユーザーへの再同意の要求
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 同意したユーザー
+
+各同意はユーザーと版ごとに記録され、版のページの **同意記録** タブに新しい順で表示されます。
+
+| 列 | 意味 |
+|---|---|
+| **ユーザー** | ユーザー名 |
+| **サインイン** | サインインの方法。ローカル、LDAP、Microsoft Entra ID、OpenID Connect |
+| **同意日時** | 同意した日時 |
+| **IP アドレス** | 同意した場所 |
+| **ブラウザー** | 使用したブラウザー |
+
+---
+
+## ユーザーへの再同意の要求
+
+7.3.0 からは、全員に求めることなく、選んだユーザーに版への再同意を求めることができます。
+
+行メニュー、またはリストでチェックした行の **再同意を求める** を使うと、確認の後でそれらの同意が消去されます。対象のユーザーには、
+サインインし直さなくても、次のリクエストで免責事項が再び表示されます。リストは、ほかのすべての表と同様にエクスポートすることもできます。
+
+[監査ログ](../production/logs.html#audit-trail) にも、各同意、各拒否、免責事項の各変更が記録されます。
diff --git a/i18n/ja/_configure/disclaimer/general.md b/i18n/ja/_configure/disclaimer/general.md
new file mode 100644
index 0000000..b4b9fd1
--- /dev/null
+++ b/i18n/ja/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 全般
+parent: 免責事項
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# 全般
+{: .no_toc }
+
+版のリスト、版の追加、ユーザーが同意する版の有効化
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## リスト
+
+7.3.0 からは、 **設定 > アクセス > 免責事項** は免責事項の版のリストです。同意された本文ごとに一つの版があります。
+
+| 列 | 意味 |
+|---|---|
+| **有効** | ユーザーが同意する版かどうか。有効にできるのは最大一つです |
+| **版** | 版の番号。1 から順に増えます |
+| **タイトル** | ダイアログのタイトル |
+| **公開者** | 追加した人 |
+| **公開日時** | 追加した日時 |
+| **同意記録** | 同意したユーザーの数 |
+
+行をクリックするか、行メニューの **編集** を選ぶと、 [版のページ](versions.html) が開きます。メニューには **有効にする** または **無効にする** と、 **削除** もあります。
+
+---
+
+## 版の追加
+
+**免責事項を追加** を押すと、次の番号を持つ新しい版のダイアログが開きます。新しい版は、有効にするまで有効になりません。
+
+| フィールド | 意味 |
+|---|---|
+| **タイトル** | ダイアログのタイトル。例：利用規約 |
+| **本文** | ユーザーが同意する内容。最大 20000 文字です。プレーンテキストで、改行は保持されます。 |
+| **チェックボックス** | 同意する前にユーザーがチェックする内容。最初は「これらの条件を読み、同意します。」です。 |
+
+三つとも必須です。それまで有効だった版が引き続きユーザーの同意する版になるので、新しい本文を前もって準備できます。
+
+---
+
+## 版の有効化
+
+行メニューの **有効にする** 、または版のページの **有効** スイッチを使うと、その版がユーザーの同意する版になり、
+ほかの版はオフになります。
+
+その版にすでに同意したユーザーには再度求められないので、全員に求めることなく以前の版を再び有効にできます。
+有効な版で **無効にする** を使うと、再び版が有効になるまで免責事項はオフになります。版と同意記録は残ります。
+版を削除するとその同意記録も削除され、有効な版を削除すると免責事項はオフになります。
diff --git a/i18n/ja/_configure/disclaimer/versions.md b/i18n/ja/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..5f3abbc
--- /dev/null
+++ b/i18n/ja/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: 版
+parent: 免責事項
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# 版
+{: .no_toc }
+
+版のページと、修正として、または全員に再度求めるための本文の変更
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 版のページ
+
+7.3.0 からは、各版が `/settings/disclaimer/<version>` に専用のページを持ち、タブは二つあります。
+
+| タブ | 内容 |
+|---|---|
+| **詳細** | タイトル、本文、チェックボックスのラベル、そしてすぐに保存される **有効** スイッチ |
+| **同意記録** | この版に同意したユーザー。 [同意記録](acceptances.html) を参照 |
+
+**プレビュー** では、ユーザーに表示されるとおりにダイアログが表示されます。 **削除** を押すと、版がその同意記録とともに削除されます。タブの上にある
+検索ボックスは両方を同時に検索し、 **詳細** の一致するフィールドと **同意記録** の一致する行を表示します。
+
+---
+
+## 本文の変更
+
+ユーザーがすでに同意したタイトル、本文、チェックボックスのラベルを変更して **保存** すると、 **全員に再度求めますか？** と尋ねられます。
+
+| 回答 | 結果 |
+|---|---|
+| **全員に再度求める** | この版の同意記録が消去され、すべてのユーザーが次のリクエストで再び同意します |
+| **修正として保持** | 誤字の修正などとして本文が書き換えられ、同意記録はそのまま有効です。誰にも再度求められません |
+
+まだ誰も同意していない版は、確認なしで保存されます。同意された本文を残すには、 [新しい版を追加](general.html#adding-a-version) して有効にしてください。
diff --git a/i18n/ja/_configure/notification-channels.md b/i18n/ja/_configure/notification-channels.md
new file mode 100644
index 0000000..319f17b
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: 通知チャネル
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# 通知チャネル
+{: .no_toc }
+
+承認依頼とジョブの通知を、メール、Slack、Microsoft Teams、Telegram、または任意の Webhook に送ります
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。フォームが通知と承認を送るメールサーバーとチャットのチャネルを追加します。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [メール](notification-channels/mail.html) | SMTP サーバー、既定のサーバー、そのログイン |
+| [Slack と Microsoft Teams](notification-channels/slack-and-teams.html) | Slack または Teams のチャネルの Webhook |
+| [Telegram](notification-channels/telegram.html) | Telegram のチャットに投稿するボット |
+| [Webhook](notification-channels/webhook.html) | 任意の HTTP エンドポイントへの JSON リクエスト |
+| [フォームでのチャネルの使用](notification-channels/in-a-form.html) | 通知と承認でのチャネルの指定 |
+| [チャネルのテスト](notification-channels/testing.html) | テスト送信と、それで確認できること |
+
+
+---
+
+## 仕組み
+
+**通知チャネル** は通知の送り先で、 **接続 > 通知** で追加します。各チャネルは次のいずれかの
+種類を持ちます。
+
+| 種類 | 送るもの |
+|---|---|
+| メール | SMTP サーバー経由のメール。承認依頼とジョブの通知。 |
+| Slack | 受信 Webhook を経由した Slack チャネルへのメッセージ。ジョブへのボタン付き。 |
+| Microsoft Teams | Workflows の Webhook を経由した Teams チャネルへのカード。ジョブへのボタン付き。 |
+| Telegram | Telegram のチャットへのボットからのメッセージ。ジョブへのリンク付き。 |
+| Webhook | テンプレートから組み立てた、任意の HTTP エンドポイントへの JSON リクエスト。 |
+
+フォームは、その [通知](forms/notifications.html) と [承認](forms/approval.html) で、
+`channels:` を使ってチャネルを指定します。送信できなかった通知はログに書き込まれ、ジョブや承認が失敗することはありません。
+
+---
+
+## 通知ページ
+
+**接続 > 通知** のページには、すべてのチャネルが次の列とともに表示されます。
+
+| 列 | 意味 |
+|---|---|
+| 有効 | 通知を送信するかどうか。 [フォームでのチャネルの使用](notification-channels/in-a-form.html) を参照。 |
+| 名前 | フォームが `channels:` で参照する名前。 |
+| 種類 | メール、Slack、Microsoft Teams、Telegram、Webhook のいずれか。既定のメールチャネルでは、種類の後に **既定** のピルが表示されます。 |
+| 説明 | チャネルの用途。 |
+
+**通知チャネルを追加** を押すとダイアログが開きます。 **チャネル** （名前と説明）、 **種類** 、そして選んだ種類の
+ステップが続きます。種類はチャネルの作成時に設定され、変更できません。行をクリックするとチャネルのページが開き、 **詳細** の後に
+同じステップがタブとして並び、右上に **テスト送信** 、 **削除** 、 **保存** があります。行メニューには
+**編集** 、 **有効にする** または **無効にする** （状態に応じて）、 **既定にする** （メール）、 **テスト送信** 、 **削除** があります。
+
+チャネルのページの **詳細** タブには、すぐに保存される **有効** スイッチがあり、メールの場合は **保存** で保存される
+**既定** スイッチもあります。
+
+`showConnectionsSettings` を持ち、管理者ロールを持たないユーザーがこれらのページを開いた場合、管理者だけが指定できる
+認証情報は選べません。 [認証情報を変更できるユーザー](credentials.html#who-may-change-a-credential) を参照してください。このようなユーザーが
+チャネルの送信先（Webhook の URL やその証明書の検証、Telegram の Bot API アドレス）を変更すると、同じ変更で認証情報を選ばない限り、
+チャネルは指定していた認証情報を失います。
+
+[構成シード](seed/) で宣言されたチャネルは、このページでは読み取り専用ですが、テストはできます。
+
diff --git a/i18n/ja/_configure/notification-channels/in-a-form.md b/i18n/ja/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..2cc9659
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: フォームでのチャネルの使用
+parent: 通知チャネル
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# フォームでのチャネルの使用
+{: .no_toc }
+
+通知と承認でのチャネルの指定
+{: .fs-6 .fw-300 }
+
+フォームはチャネルを名前で指定します。ジョブのステータスとジョブのイベントには `notifications` で、承認には `approval` で指定します。
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- チャットと Webhook のチャネルには、ジョブへのリンク付きの短いメッセージ（フォーム、ジョブ、起きたこと）が送られます。
+  承認の場合は、ジョブのページで承認または却下します。
+- リストにある **メール** チャネルは、既定のサーバーではなくそのサーバーを使って、 `recipients` （承認の場合は `notifications` のアドレス）に
+  通常のメールを送ります。
+- 存在しない名前や、オフになっているチャットまたは Webhook のチャネルはスキップされ、ログに記録されます。
+- オフになっている **メール** チャネルはスキップされません。代わりに既定のメールチャネルからメールが送られ、
+  その旨がログに記録されます。
diff --git a/i18n/ja/_configure/notification-channels/mail.md b/i18n/ja/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..2c802b7
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: メール
+parent: 通知チャネル
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# メール
+{: .no_toc }
+
+SMTP サーバー、既定のサーバー、そのログイン
+{: .fs-6 .fw-300 }
+
+メールチャネルは SMTP サーバーです。複数持つことができ、 **既定** の印が付いたものが、フォームがメールチャネルを指定していないときに
+アプリがメールの送信に使うサーバーです。最初のメールチャネルが既定になり、 **既定にする** で変更できます。
+
+| ステップ | フィールド | 意味 |
+|---|---|---|
+| 認証情報 | 認証情報 | 必須。 [接続 > 認証情報](../credentials.html) の **smtp** 認証情報で、メールサーバー、そのポートと TLS、ログインを保持します。ログインのないリレーの場合は、ユーザーのない smtp 認証情報を使います。 |
+| 送信者 | 送信元アドレス | 受信者に表示される送信者のアドレス。 |
+
+メールチャネルのページの **詳細** タブにある **既定** スイッチは、 **既定にする** と同じく、そのチャネルを既定にします。
+既定のメールチャネルがない間、または既定のものがオフになっている間は、構成シードのメール設定が使われます。
diff --git a/i18n/ja/_configure/notification-channels/slack-and-teams.md b/i18n/ja/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..667b984
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack と Microsoft Teams
+parent: 通知チャネル
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack と Microsoft Teams
+{: .no_toc }
+
+Slack または Teams のチャネルの Webhook
+{: .fs-6 .fw-300 }
+
+Slack と Teams のチャネルに必要なのは、チャネルの Webhook のアドレスだけです。
+
+| 種類 | Webhook アドレス |
+|---|---|
+| Slack | チャネルの受信 Webhook（Slack app > Incoming Webhooks）。 |
+| Microsoft Teams | チャネルの Workflows の Webhook（「Webhook 要求を受信したらチャネルに投稿する」）。 |
+
+このアドレスは、誰でもチャネルに投稿できるようにするシークレットです。暗号化して保存され、一度保存すると二度と表示されません。
diff --git a/i18n/ja/_configure/notification-channels/telegram.md b/i18n/ja/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..f62b762
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: 通知チャネル
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Telegram のチャットに投稿するボット
+{: .fs-6 .fw-300 }
+
+Telegram チャネルは、チャットに投稿するボットです。 **認証情報** ステップには **ボットトークン** が、 **ボット** ステップにはそれ以外の設定があります。
+
+| フィールド | 意味 |
+|---|---|
+| ボットトークン | [接続 > 認証情報](../credentials.html) の **api** 認証情報で、パスワードが BotFather から得たボットトークンのもの。 |
+| チャット ID | ボットが投稿するチャット、グループ、チャネル。グループやチャネルの場合は負の数です。 |
+| Bot API アドレス | 独自の Bot API サーバー。空の場合は `api.telegram.org` 。 |
diff --git a/i18n/ja/_configure/notification-channels/testing.md b/i18n/ja/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..cd3e6a1
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: チャネルのテスト
+parent: 通知チャネル
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# チャネルのテスト
+{: .no_toc }
+
+テスト送信と、それで確認できること
+{: .fs-6 .fw-300 }
+
+**テスト送信** は、保存されている状態のチャネルでテスト通知を送るので、先に変更を保存してください。オフになっているチャネルでも
+使えます。メールチャネルの場合は
+ダイアログで送信先のアドレスを尋ねられます。ほかのチャネルは自分のチャネルに投稿します。ダイアログには成功したかどうかと、
+失敗した場合はその理由が表示されます。
diff --git a/i18n/ja/_configure/notification-channels/webhook.md b/i18n/ja/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..9382486
--- /dev/null
+++ b/i18n/ja/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: 通知チャネル
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+任意の HTTP エンドポイントへの JSON リクエスト
+{: .fs-6 .fw-300 }
+
+Webhook チャネルは、任意の HTTP エンドポイントに JSON リクエストを送ります。 **エンドポイント** ステップで送信先と方法を指定し、
+**認証情報** ステップには **Bearer トークン** があります。
+
+| フィールド | 意味 |
+|---|---|
+| URL | リクエストの送信先アドレス。 |
+| メソッド | `POST` （既定）または `PUT` 。 |
+| Bearer トークン | [接続 > 認証情報](../credentials.html) の **api** 認証情報で、そのパスワードが `Authorization: Bearer <password>` として送られます。空の場合はトークンなし。 |
+| TLS 証明書を検証 | 既定でオンです。自己署名証明書のエンドポイントの場合にのみオフにします。 |
+
+{% raw %}
+**ペイロード** ステップには、 `{ "X-Source": "ansibleforms" }` のような JSON オブジェクトで指定する追加のヘッダーである **ヘッダー** と、
+本文の JSON テンプレートである **ペイロード** があります。次のプレースホルダーが埋め込まれます。
+
+| プレースホルダー | 値 |
+|---|---|
+| `{{title}}` | 通知のタイトル |
+| `{{text}}` | 通知の本文 |
+| `{{status}}` | ジョブのステータス |
+| `{{event}}` | ジョブのイベント |
+| `{{jobId}}` | ジョブ ID |
+| `{{form}}` | フォーム名 |
+| `{{user}}` | ジョブを開始したユーザー |
+| `{{link}}` | ジョブへのリンク |
+
+JSON の文字列全体であるプレースホルダー（ `"{{text}}"` ）は、値を JSON としたものに置き換えられます。より長い文字列の中では、
+そのテキストは JSON 用にエスケープされます。不明なプレースホルダーは書かれたまま残ります。ペイロードが空の場合は、次のテンプレートが送られます。
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/ja/_configure/production/backups.md b/i18n/ja/_configure/production/backups.md
new file mode 100644
index 0000000..943f8dd
--- /dev/null
+++ b/i18n/ja/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: バックアップ
+parent: 本番環境での運用
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# バックアップ
+{: .no_toc }
+
+夜間バックアップ、その内容、リストア、ほかに保持すべきもの
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 夜間バックアップ
+
+AnsibleForms は毎晩午前 0 時に、 [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) のタイムゾーン（既定は UTC）で
+自分自身をバックアップします。次の設定で制御します。
+
+| 変数 | 既定値 | 意味 |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | バックアップの書き込み先。バックアップごとにタイムスタンプ付きのフォルダーが一つ作られます |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | 保持する夜間バックアップの数。 `0` ですべて保持します |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | データベースをダンプするコマンド |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | リストア時にダンプを再生するコマンド |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | ダンプとリストアを実行できる時間 |
+
+ロールオプション `allowBackupOps` を持つユーザーは、 **バックアップ** ページでいつでもバックアップを取ることもできます。保持期間によって削除されるのは
+夜間バックアップだけで、数に含まれるのは使用可能なダンプを持つバックアップだけです。そのため、何晩も続けて失敗しても、
+最後の正常なバックアップが押し出されることはありません。
+
+アップグレードでデータベースが変更される前に、ワーカーはまず通常のバックアップを、リリースごとに一度、 *Before the upgrade to
+&lt;version&gt;* という名前で取ります。これは **バックアップ** ページに表示され、夜間バックアップの保持期間で削除されることはありません。失敗した場合（ダンプツールがない、
+`BACKUP_PATH` に書き込めないなど）、アップグレードは理由を示して停止するため、アップグレードが中途半端なデータベースでアプリが起動することはありません。
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` にすると、バックアップなしでアップグレードします。
+
+コマンドは、最初の単語がローカルに存在すれば、 `docker exec <container> mysqldump` のようなラッパーでもかまいません。7.3.0 からは
+シェルなしで実行されます。引用符とコマンドの環境の `$NAME` は使えますが、 `;` 、 `|` 、 `&&` 、 `>` 、 `<` は拒否されます。
+
+---
+
+## データベースの権限
+
+ダンプは [`DB_USER`](../customization/server.html#env_DB_USER) として実行され、アプリケーション自体が必要とする以上の権限は不要です。
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+ダンプは `--no-tablespaces` で取られるため、サーバー全体の `PROCESS` 権限は不要です。また、実行中のプロセスを表すテーブル
+（ `nodes` 、 `cache_epochs` 、 `designer_lock` 、 `runner_leases` ）はスキップされます。リストアは同じユーザーで再生されます。
+ユーザーが `root` のようにすべてのデータベースに対する権限を持っている場合、 **ステータス** ページの **データベースユーザー** チェックに警告が表示されます。
+
+---
+
+## バックアップの内容
+
+各バックアップは `BACKUP_PATH` の下のフォルダーで、UTC のタイムスタンプ（ `YYYYMMDDHHmmss` ）にちなんだ名前が付き、次のものを含みます。
+
+| ファイル | 内容 |
+|------|---------|
+| `ansibleforms.sql` | `AnsibleForms` データベースのダンプ。ユーザー、グループ、認証情報、ジョブ、設定、監査証跡 |
+| `config.yaml` | [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) にあるファイル |
+| `forms/` | [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) にあるフォルダー |
+| `managed.env` | 設定ページが書き込む環境ファイル。 `ENCRYPTION_SECRET` 、 `ENCRYPTION_SECRET_PREVIOUS` 、 `ACCESS_TOKEN_SECRET` は含みません |
+| `meta.yaml` | バックアップの説明 |
+
+ダンプに失敗したバックアップは再び削除され、エラーとしてログに記録されます。 **ステータス** ページは、バックアップがないとき、
+最新のものが 2 日より古いとき、または使用可能なダンプがないときに警告し、ダンプツールが存在するかも確認します。
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) は、代わりにデザイナーの復元ポイントを保持します（既定は 60 日）。
+
+---
+
+## バックアップのリストア
+
+[**バックアップ** ページ](../gui/administration.html#restore) から、 **復元する前に新しいバックアップを作成する** をオンにしてリストアします。リストアでは次のことが行われます。
+
+* `ansibleforms.sql` を再生し、データベース全体を置き換えます。7.3.0 からは、古いリリースのバックアップはその後、新しいリリースの
+  起動時と同じように再びアップグレードされ、失敗したパッチは報告されます
+* `config.yaml` を書き戻し、 `forms/` フォルダーをバックアップのものに置き換えます。7.3.0 からは、バックアップにないフォームは
+  残さずに削除され、フォルダーのリンクとモードは維持され、コピーに失敗するとフォルダーはロールバックされます
+* `managed.env` は **リストアしません** 。バックアップ元のホストを表すものだからです。 **環境を復元**
+  ボタンを押すと要求に応じて戻し、現在のファイルを `.env.bak` として残します。再起動が必要です。
+
+使用可能なダンプのないバックアップは拒否されます。リストアが中断された場合は、原因を修正してから再度リストアしてください。
+
+新しいホストでは、リストアの前に同じ `ENCRYPTION_SECRET` を設定してください。そうしないと、保存されている認証情報を復号できません。
+
+---
+
+## ほかにバックアップすべきもの
+
+夜間バックアップはデータベース、設定、フォームを対象とし、永続フォルダーのそれ以外のものは含みません。
+
+* **`ENCRYPTION_SECRET` と `ACCESS_TOKEN_SECRET`** ：設計上、バックアップには決して含まれません。シークレットマネージャーに保管してください。
+  暗号化シークレットがなければ、データベースのダンプは認証情報の役に立ちません。
+* **バックアップ自体** ：インスタンスと同じボリュームにあります。 `BACKUP_PATH` を別のホストにコピーしてください。
+* **永続フォルダーの残り** ：プレイブック、アップロード、変数ファイル、クローンしたリポジトリ、証明書、ログ。
+  docker-compose プロジェクトでは、 `data/` フォルダー全体をバックアップしてください。ここには SSH キー、カスタム
+  関数、Ansible のロールとコレクションも含まれます。
+
+git から来るコンテンツ（リポジトリ、リポジトリ内のフォーム）は再びクローンできるので、そのバックアップの重要性は低くなります。
diff --git a/i18n/ja/_configure/production/index.md b/i18n/ja/_configure/production/index.md
new file mode 100644
index 0000000..4ab56c7
--- /dev/null
+++ b/i18n/ja/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: 本番環境での運用
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# 本番環境での運用
+{: .no_toc }
+
+利用者が頼りにするインスタンスを公開し、バックアップし、監視します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 本番稼働の前に
+
+既定値を使えばインスタンスをすぐに動かせますが、その中には最初に試すためだけのものもいくつかあります。AnsibleForms は
+`ENCRYPTION_SECRET` または `ACCESS_TOKEN_SECRET` が設定されていないと起動時に `[SECURITY]` の警告をログに記録し、
+**ステータス** ページではバックアップ、保持期間の設定、式のサニタイザーについて報告します。
+
+---
+
+## 本番環境のチェックリスト
+
+利用者がインスタンスを頼りにする前に一度、そしてメジャーアップグレードの後にもう一度、次の項目を確認してください。
+
+| 項目 | やること | 詳細 |
+|------|------------|---------|
+| 管理者パスワード | ローカル管理者アカウントのパスワードを変更します | [強化](../security/hardening.html#the-admin-account) |
+| 暗号化シークレット | 認証情報を保存する前に [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) を設定します | [シークレットと暗号化](../security/secrets.html#the-two-master-secrets) |
+| トークンシークレット | 再起動してもセッションが維持されるよう、 [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) を設定します | [シークレットと暗号化](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | サンプルの証明書ではなく、独自の証明書で TLS を終端します | [HTTPS](../security/https.html) |
+| リバースプロキシ | インスタンスをプロキシの背後で公開します。必要に応じて [`BASE_URL`](../customization/server.html#env_BASE_URL) の下に置きます | [リバースプロキシ](reverse-proxy.html) |
+| スキーマのエンドポイント | スキーマができたら [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) を `0` に設定します | [強化](../security/hardening.html#the-database) |
+| 外部への呼び出し | [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) で REST 式を制限します | [強化](../security/hardening.html#expressions-and-outbound-calls) |
+| 任意の機能 | 使わないなら MCP とチャットアシスタントはオフのままにします | [強化](../security/hardening.html#optional-features) |
+| バックアップ | 夜間バックアップが動作することを確認し、ホストの外にコピーします | [バックアップ](backups.html) |
+| 保持期間 | ジョブと監査エントリを保持する期間を決めます | [ログ](logs.html#retention) |
+
+---
+
+## このセクションの内容
+
+トピックごとに専用のページがあります。インスタンスの保護については [セキュリティ](../security/) で扱います。
+
+| ページ | 内容 |
+|---|---|
+| [リバースプロキシ](reverse-proxy.html) | Nginx、Traefik、Apache の背後で、ルートまたはサブパスの下に AnsibleForms を公開します |
+| [バックアップ](backups.html) | 夜間バックアップ、その内容、リストア、ほかに保持すべきもの |
+| [ログ](logs.html) | ログファイル、syslog、監査証跡、ジョブと監査エントリの保持期間 |
+| [スケーリング](scaling.html) | ワーカーを伴う複数のアプリノード。RTE には専用のセクション [ランタイム環境](../rte/) があります |
+| [監視](monitoring.html) | ヘルスプローブ、Prometheus メトリクス、ステータスページ |
diff --git a/i18n/ja/_configure/production/logs.md b/i18n/ja/_configure/production/logs.md
new file mode 100644
index 0000000..59999a8
--- /dev/null
+++ b/i18n/ja/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: ログ
+parent: 本番環境での運用
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# ログ
+{: .no_toc }
+
+ログファイル、syslog、監査証跡、ジョブと監査エントリの保持期間
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ログファイル
+
+AnsibleForms は、日ごとにローテーションする二つのログを [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+（ `%PERSISTENT_FOLDER%/logs` ）に書き込み、古い日のものを圧縮して [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+の間保持します（既定は 30。 `0` ですべてのファイルを保持します。設定ページでの変更はすぐに反映されます）。
+
+* `ansibleforms.<date>.log` ： [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) 以上のすべて
+* `ansibleforms.errors.<date>.log` ：エラーのみ
+
+`docker logs` や `kubectl logs` で読むコンソールには、独自のレベル
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) があります。どちらも既定は `notice` で、
+本番環境にはこれが適切です。 `info` や `debug` はトラブルシューティング中にだけ使い、
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) はオフのままにしてください。レベルは
+設定ページで再起動なしで変更でき、 **サーバーログ** ページでは、オプション `showLogs` を持つユーザーにログが表示されます。
+
+---
+
+## JSON 行
+
+Loki、ELK、Splunk などのログコレクター向けには、 [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) を `json` に設定します。すると、
+コンソールでもファイルでも、各行が `<time> <level>: <message>` ではなく一つの JSON オブジェクトになります。
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| フィールド | 内容 |
+|-------|---------|
+| `time` | 時刻。ISO 8601 の UTC |
+| `level` | ログレベル |
+| `message` | メッセージ |
+| `requestId` | リクエストの処理中に書かれた行の場合、その行が属するリクエスト |
+| `role` | プロセスのロール [`AF_ROLE`](scaling.html) 。設定されていない場合は `all` |
+| `host` | プロセスが動作するマシンまたはコンテナーのホスト名 |
+
+各リクエストには ID が付きます。リバースプロキシが送った `X-Request-Id` ヘッダー、または新しい ID です。これはレスポンスの
+`X-Request-Id` ヘッダーで返され、リクエストの処理中に書かれたすべての行に含まれます（テキストの行では `[req <id>]` として）。
+そのため、リクエストをログの中で追跡し、プロキシのログと突き合わせることができます。設定ページでの変更はすぐに反映されます。
+
+---
+
+## Syslog
+
+Syslog サーバーは **設定 > 接続 > Syslog** で管理し、syslog サーバーや SIEM がログを書き込まれたとおりに受け取れるようにします。
+複数のサーバーを追加でき、それぞれに独自の設定があります。
+
+| 設定 | 動作 |
+|---------|--------------|
+| 有効 | 有効なサーバーだけが何かを受け取るので、削除せずにサーバーを一時停止できます。行メニューの **有効にする** と **無効にする** でも切り替えられます |
+| プロトコル | `udp4` （既定）、 `udp6` 、 `tcp4` 、 `tcp6` 、 `tls4` 、 `tls6` 、 `unix` 、 `unix-connect` |
+| ホストとポート | 送信先のサーバー。ポートは既定で `514` 。 `unix` のプロトコルでは代わりにソケットのパスを指定します |
+| 受信内容 | サーバーログ、監査エントリ、またはその両方（新しいサーバーの既定） |
+| レベル | 受け取るサーバーログの最低レベル。既定は `info` 。監査エントリは常に送信されます |
+| 種類 | `BSD` （RFC 3164、既定）または `RFC 5424` |
+
+変更は再起動なしですべてのノードに反映され、サーバーのページにはテストメッセージを送るボタンがあります。
+到達できないサーバーがあってもアプリケーションが止まることはありません。エラーはコンソールに書き込まれます。
+
+7.3.0 からは、syslog サーバーには設定の完全な権限、つまりロールオプション [`showSettings`](../config/roles.html#role-options) が必要です。
+syslog サーバーはサーバーログと監査エントリを受け取るため、接続の設定へのアクセスだけでは足りません。
+
+以前のバージョンの `LOG_SYSLOG_*` 変数は、バージョン 7 から非推奨です。 [`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) が
+設定されていることを検出した最初の起動で、それらは一度だけサーバー `syslog` としてインポートされ、
+以前と同じくサーバーログを受け取ります。以降は無視されます。その最初の起動の後で環境から削除し、
+サーバーは設定ページで管理してください。
+
+---
+
+## 監査証跡
+
+**監査ログ** ページ（ **設定 > ログ** の下）には、誰が何を変更したかが記録されます。これはログファイルでは答えにくいことです。
+記録されるのは次のものです。
+
+* API を通じて行われたすべての変更（ `POST` 、 `PUT` 、 `PATCH` 、 `DELETE` ）。401 または 403 で拒否された試行も含みます
+* サインイン。試されたユーザー名も記録されます
+* 夜間バックアップ、削除されたバックアップ、整理されたジョブ、構成シードの適用など、アプリケーション自体のイベント
+
+各エントリには、時刻、実行者（ユーザー、またはアプリケーション自身のタスクの場合はアプリケーション）、クライアントの IP アドレス、
+操作、その対象、そして結果（ `success` 、 `failure` 、 `denied` ）があります。ページでは実行者、操作、結果で
+絞り込むことができ、ロールオプション `showSettings` を持つユーザーが開けます。
+
+IP アドレスは AnsibleForms から見えるもので、プロキシの背後で動作している場合はプロキシのアドレスになります。
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) にプロキシの数またはアドレスを設定すると、AnsibleForms は
+代わりにプロキシが `X-Forwarded-For` で報告するクライアントのアドレスを記録します。 [リバースプロキシ](reverse-proxy.html) を参照してください。
+
+監査証跡を SIEM 向けなどにインスタンスの外に保持するには、監査エントリを受け取る syslog サーバーを追加します（
+[Syslog](#syslog) を参照）。各エントリは発生したときに、サーバーのレベルにかかわらず、エントリを JSON にした `audit {...}` という
+1 行として送られます。syslog 側のコピーは、下の保持期間で削除されることも、データベースのリストアで置き換えられることもありません。
+
+---
+
+## 保持期間
+
+設定を持つ二つの毎日のタスクが、データベースが際限なく大きくなるのを防ぎます。
+
+| 変数 | 既定値 | 実行時刻 | 削除するもの |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | これより古い監査エントリ |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` （すべて保持） | 2:30 | これより古い終了済みのジョブとその出力 |
+
+どちらも `0` ですべてを保持します。設定のない毎日のタスクがさらに二つあります。3:00 には 30 日より古い保存済みのリフレッシュトークンと
+期限切れのトークン失効情報が削除され、4:00 には有効期限を過ぎた [保存済みジョブ](../jobs/stored-jobs.html) が削除されます。
+時刻は [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) のタイムゾーンで、ワーカーがこれらを実行します。
+
+通常、最も速く大きくなるテーブルはジョブの出力です。 **ステータス** ページはそのサイズを報告し、
+保持期間が設定されないまま 1 GB を超えると警告します。実行中のジョブと承認待ちのジョブは削除されません。
+監査の要件に合ったジョブの保持期間を決め、監査証跡は少なくともそれと同じ期間保持してください。
diff --git a/i18n/ja/_configure/production/monitoring.md b/i18n/ja/_configure/production/monitoring.md
new file mode 100644
index 0000000..0be864b
--- /dev/null
+++ b/i18n/ja/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: 監視
+parent: 本番環境での運用
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# 監視
+{: .no_toc }
+
+ロードバランサーや Kubernetes 向けのヘルスプローブ、Prometheus メトリクス、ステータスページ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ヘルスプローブ
+
+二つのエンドポイントが、ロードバランサー、コンテナーのヘルスチェック、Kubernetes に、プロセスがトラフィックを受け付けられるかどうかを伝えます。
+どちらもログインは不要で、構成に関する情報は何も返しません。
+
+| エンドポイント | 応答 | 用途 |
+|----------|---------|------------|
+| `/api/v2/live` | プロセスが動作している限り `{"status":"live"}` とともに `200` | Liveness プローブ。応答しなくなったらプロセスを再起動します |
+| `/api/v2/ready` | `{"status":"ready"}` とともに `200` 、または `{"status":"not ready","reason":"..."}` とともに `503` | Readiness プローブ。準備ができたプロセスにだけトラフィックを送ります |
+
+次のすべてが成り立つとき、プロセスは準備ができています。
+
+* シャットダウン中でない（ `stopping` ）
+* データベースが応答する（ `database unreachable` ）
+* スキーマが存在し（ `schema not provisioned` ）、このバージョンのすべてのテーブル、列、インデックスがそろっている
+  （ `schema not upgraded` ）。この最後のチェックは 30 秒間キャッシュされるので、数秒ごとのプローブでも負荷はわずかです
+
+[`BASE_URL`](../customization/server.html#env_BASE_URL) の下では、パスはその値で始まります。たとえば
+`/ansibleforms/api/v2/ready` です。ランタイム環境（RTE）は同じプローブに `/live` と `/ready` で応答しますが、
+スキーマがそろっているかのチェックはありません。シャットダウン時にジョブを処理し終えるまでの間は準備ができていない状態になるので、新しいジョブは送られません。アウトバウンドの RTE
+も、アプリへのソケットが開くまでは準備ができていません（ `not connected to the app` ）。
+`AF_ROLE=worker` で起動したプロセスには Web インターフェースがなく、コンテナーのヘルスチェック用に `/api/v2/version` と `/health` にだけ応答します。
+ロールについては [スケーリング](scaling.html) を参照してください。
+
+---
+
+## Prometheus メトリクス
+
+Prometheus メトリクスを提供するには、 [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) に長いランダムな文字列を設定します。
+Web アプリケーションを提供するプロセスは `/api/v2/metrics` で、RTE は `/metrics` で応答します。
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+`METRICS_TOKEN` がない場合、エンドポイントは存在しないかのように `404` を返し、正しい
+`Authorization: Bearer <token>` ヘッダーのないリクエストには `401` が返ります。各プロセスは自分の値を報告するので、それぞれをスクレイプしてください。
+
+| メトリクス | 測定するもの |
+|--------|------------------|
+| `af_process_*` 、 `af_nodejs_*` | プロセス。CPU、メモリ、イベントループの遅延、ガベージコレクション |
+| `af_http_requests_total{route,method,status}` | 処理したリクエスト |
+| `af_http_request_duration_seconds{route}` | それらにかかった時間 |
+| `af_jobs{status}` | 現在実行中（ `running` ）または承認待ち（ `approve` ）のジョブ |
+| `af_jobs_ended_24h{status}` | 過去 24 時間に終了したジョブ。ステータス別 |
+| `af_nodes{role,alive}` | データベースに登録されたプロセス。ロール別、稼働中かどうか |
+| `af_login_failures_total` 、 `af_login_lockouts_total` | 失敗したサインインとアカウントのロックアウト |
+| `af_rte_running_jobs` 、 `af_rte_max_jobs` | RTE の場合：現在実行中のプレイブックと、同時に実行できる数 |
+| `af_rte_socket_connected` | ソケットモードの RTE の場合：アプリへのソケットが開いている間は `1` 、開いていないときは `0` |
+
+ジョブとノードの値は、スクレイプのたびにデータベースから読み込まれます。データベースが応答しない場合はそれらが省かれ、
+ほかのメトリクスでスクレイプは成功します。
+
+---
+
+## ステータスページ
+
+**設定 > システム** の **ステータス** ページは、ロールオプション `showSettings` を持つユーザーにインスタンスの状態を表示します。
+読み取るだけなので、更新してもメールが送られたりジョブが起動されたりすることはありません。タブは二つあり、問題の数が **チェック** タブのラベルに表示されます。
+
+### チェック
+
+各チェックは緑（正常）、黄（要確認）、赤（問題あり）のいずれかで、行を展開すると詳細が表示されます。
+
+| チェック | 確認するもの |
+|-------|------------------|
+| データベース接続 | データベースが応答するか |
+| データベースユーザー | ユーザーが `AnsibleForms.*` だけでなく、 `root` のようにすべてのデータベースに対する権限を持っていると黄 |
+| データベーススキーマ | このバージョンのすべてのテーブル、列、インデックスが存在するか。存在しない場合はどのパッチが失敗したか |
+| スケジューラー | ワーカーがシステムタスクを実行しており、どれもスケジュールが止まっていないか |
+| ノード | データベース上のプロセス。異なるバージョンが動作していると黄 |
+| ジョブ | 実行中のジョブと承認待ちのジョブ。24 時間を超えて実行されているジョブがあると黄 |
+| バックアップツール | [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) のダンプコマンドが存在するか、そのバージョン |
+| 最終バックアップ | バックアップがないか最新のものが 2 日より古いと黄、使用可能なダンプがないと赤 |
+| デザイナーのロック | デザイナーのロックを持っている人。8 時間を超えて保持されていると黄 |
+| リポジトリ | リポジトリが失敗しているか、ディスク上に作業ツリーがないと赤 |
+| Config seed | [構成シード](../seed/) ファイルが読み取れて解析でき、最後の再読み込みが成功したか |
+| シークレットストア | すべてのシークレットストアが応答するか。HashiCorp Vault のトークンがまもなく期限切れになると黄 |
+| ランナー | すべてのランナーが応答するか。ランナーがないか既定の RTE がないと黄 |
+| サーバー式 | [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) が `legacy` だと黄 |
+| シークレット | `ENCRYPTION_SECRET` が公開されている既定値であるか、 `ACCESS_TOKEN_SECRET` が設定されていないと黄 |
+| LDAP | サインインせずに、LDAP サーバーに到達でき、その TLS 証明書が有効か |
+| ジョブストレージ | ジョブのテーブルのサイズ。ジョブの保持期間が設定されておらず 1 GB を超えると黄 |
+| 書き込み可能なフォルダー | 設定されたすべてのフォルダーに書き込めるか |
+| ディスク容量 | バックアップを保持するディスク。使用率 85% から黄、95% から赤 |
+
+### 情報
+
+判定のない、インスタンスに関する事実です。サポートとのやり取りで最初に求められるものです。AnsibleForms の
+バージョン、ベース URL、データベースのバージョンとホスト、設定のソース、構成シード、保持期間の
+設定、認証方法、有効な [メールチャネル](../notification-channels.html) のサーバー、ログの
+レベルとパス、稼働時間、タイムゾーン、Node.js のバージョン、プラットフォーム。
+
+ページは `/api/v2/health` を読み込みます。これには `showSettings` を持つサインイン済みのユーザーが必要です。監視システムには、
+代わりに上のプローブとメトリクスを使ってください。
diff --git a/i18n/ja/_configure/production/reverse-proxy.md b/i18n/ja/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..7282b2c
--- /dev/null
+++ b/i18n/ja/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: リバースプロキシ
+parent: 本番環境での運用
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# リバースプロキシ
+{: .no_toc }
+
+Nginx、Traefik、Apache の背後で、ルートまたはサブパスの下に AnsibleForms を公開します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 使う場面
+
+AnsibleForms はインターフェース、REST API、Swagger を一つのポートで提供します。その前にリバースプロキシを置くと、次のことができます。
+
+* 既存のツール（ACME、社内 CA）で管理する証明書を使って、ポート 443 で提供する
+* AnsibleForms をサブパスの下で公開して、一つのホスト名をほかのアプリケーションと共有する
+* アプリケーションのポートとデータベースを公開ネットワークから切り離す
+
+プロキシは必須ではありません。アプリケーション自身で HTTPS を提供することもできます。 [HTTPS](../security/https.html) を参照してください。
+
+---
+
+## 重要な設定
+
+プロキシの背後での AnsibleForms の動作に影響する設定は、ごくわずかです。
+
+| 設定 | プロキシの背後では |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | プロキシの転送先ポート。既定は `8000` です。docker-compose プロジェクトでは `443` に設定されています。 |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | プロキシが TLS を終端し、プライベートネットワーク経由でアプリケーションに接続する場合は `0` 、その区間も暗号化する場合は `1` 。 |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | サブパス。たとえば `/ansibleforms` 。アプリケーションが独自のホスト名を持つ場合は `/` のままにします。 |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | `X-Forwarded-For` でクライアントのアドレスを報告できるプロキシ。通常は `1` 。 [クライアントのアドレス](#client-addresses) を参照。 |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | アプリケーションが受け付ける最大の JSON リクエスト。既定は 50 MB です。プロキシは少なくともこれを許可する必要があります。 |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | フォームのアップロードフィールドが受け付ける最大のファイル。既定は 10 GB です。プロキシもこれを許可する必要があり、そうでないとそこでアップロードが失敗します。 |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | アプリケーションが受け付けるリクエストヘッダー全体の最大サイズ。既定は 16 KB で、7.1.0 からです。 [リクエストヘッダーのサイズ](#request-header-size) を参照。 |
+| **公開ルート URL** | **システム > 全般** の **サーバー** タブにあります。ユーザーがアクセスするアドレスで、サブパスも含みます。通知メール、チャネルのメッセージ、承認依頼のリンクの組み立てに使われます。 |
+
+Entra ID または OIDC では、公開アドレスをリダイレクト URI として登録します。 `BASE_URL` のサブパスを設定している場合はそれも含めます。
+
+---
+
+## サブパスの下での提供
+
+`BASE_URL` はアプリケーション全体をサブパスの下にマウントします。プロキシはパスを **変更せずに** 転送する必要があります。
+`BASE_URL=/ansibleforms` の場合：
+
+* インターフェース、 `/api/v2/...` 、Swagger インターフェースはすべて `/ansibleforms/` の下で提供されます
+* インターフェースの `<base href>` は起動時に書き換えられるので、アセットと API の呼び出しはサブパスの下で解決されます
+* `/` または `/ansibleforms` （末尾のスラッシュなし）へのリクエストは `/ansibleforms/` にリダイレクトされます
+
+プレフィックスは残してください。アプリケーションはそれを前提としているので、Traefik では `StripPrefix` を使わず、Nginx では `proxy_pass` に URI を付けません。
+
+**ステータス** ページには、現在有効なベース URL が表示されます。
+
+---
+
+## タイムアウト、アップロード、ライブ出力
+
+ジョブページとジョブのカウンターは、ブラウザーごとに開いたままになる一本の長寿命の server-sent events ストリーム
+[`/api/v2/events`](../api/events.html) で変更を知ります。このストリームはプロキシのバッファリングを無効にするヘッダー
+（ `X-Accel-Buffering: no` ）と、15 秒ごとのキープアライブ行を送るので、一般的な 60 秒の読み取りタイムアウトでも開いたままになります。
+それでもプロキシが閉じた場合は、ブラウザーが自動的に再接続します。起動直後にフォームの下に表示される出力は、
+代わりに 2 秒ごとに読み込まれます。ジョブの起動はジョブが作成されるとすぐに戻るので、長いプレイブックでも
+リクエストが開いたままになることはありません。
+
+時間がかかることがあるリクエストは次のとおりです。
+
+* **バックアップ** ページからの **バックアップとリストア** 。ダンプまたはリストアのコマンドが終わるまで、最大
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) （既定は 3600）待ちます
+* ファイルフィールドを通じた **大きなアップロード** 。ファイル全体を一つのリクエストでストリーミングします
+* [チャットアシスタント](../chat/) が有効な場合の **チャットメッセージ** 。モデルプロバイダーの応答を待ちます
+
+プロキシは 60 秒でタイムアウトし、リクエストの本文に上限を設けることがよくあります（Nginx の既定は 1 MB）。下の例のように、
+AnsibleForms のルートでは両方を引き上げてください。
+
+---
+
+## ランナーの WebSocket
+
+7.3.0 からは、 [アウトバウンドのランナー](../rte/modes.html#outbound) がアプリケーションに接続し、
+`<BASE_URL>/api/v2/rte/socket` で WebSocket を一つ開いたままにします。プロキシはアップグレードを通す必要があり、そうでないとランナーは接続できず、接続を試し続けます。
+
+| プロキシ | WebSocket に必要なもの |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` と、Nginx が既定では転送しない `Upgrade` ヘッダーと `Connection` ヘッダー |
+| Traefik | 何も不要。WebSocket はそのまま通過します |
+| Apache | `ProxyPass` 行の `upgrade=websocket` （2.4.47 以降）、それより前は `mod_proxy_wstunnel` |
+
+両端が 20 秒ごとに ping を送るので、一般的な 60 秒の読み取りタイムアウトでもアイドル状態のソケットは開いたままになります。
+
+---
+
+## リクエストヘッダーのサイズ
+
+すべてのリクエストは、Cookie やプロキシが追加するヘッダーと並んで、 `Authorization` ヘッダーにサインイントークンを含みます。
+プロキシとアプリケーションの両方がリクエストヘッダーのサイズに上限を設けており、上限を超えるリクエストは
+AnsibleForms に届く前に拒否されるため、サーバーログには何も残りません。既定値は次のとおりです。
+
+| コンポーネント | 上限 | 既定値 | 拒否時の応答 |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) 、すべてのヘッダーの合計 | 16384 バイト | 431 |
+| Nginx | `large_client_header_buffers` 、ヘッダーフィールドごと | `4 8k` ：フィールドごとに 8 KB | 400 |
+| Traefik | エントリポイントの `http.maxHeaderBytes` 、すべてのヘッダーの合計 | 1 MB | 431 |
+| HAProxy | `global` セクションの `tune.bufsize` 、ヘッダーブロック全体から `tune.maxrewrite` の予約分（1024 バイト）を引いたもの | 16384 バイト：ヘッダーは 15360 バイト | 400 |
+| Apache | `LimitRequestFieldSize` 、ヘッダーフィールドごと | 8190 バイト | 400 |
+
+7.0.3 までは、サインイントークンにシングルサインオンユーザーのすべてのグループが含まれており、これらの上限を超えることがありました。
+[シングルサインオン後にフォームとジョブが空になる](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431) を参照してください。
+7.1.0 からはトークンは小さいままなので、既定値で十分です。同じドメインのほかのアプリケーションの Cookie や、前段のシングルサインオンゲートウェイなど、
+ほかの理由でヘッダーが大きくなる場合は、上限をまとめて引き上げてください。
+
+* AnsibleForms： `MAX_HTTP_HEADER_SIZE=65536` 、7.1.0 より前は `NODE_OPTIONS=--max-http-header-size=65536` 。どちらも
+  起動時に読み込まれるので、変更後はアプリケーションを再起動してください
+* Nginx： `http` または `server` ブロックに `large_client_header_buffers 4 32k;`
+* HAProxy： `global` セクションに `tune.bufsize 65536` 。すべてのストリームがそのサイズのバッファーを持つため、HAProxy は
+  グローバルの `maxconn` を同じ比率で下げるよう勧めています。HTTP/2 には少なくとも既定の 16384 が必要です
+* Apache：サーバー設定またはバーチャルホストに `LimitRequestFieldSize 32768`
+
+---
+
+## クライアントのアドレス
+
+プロキシの背後では、すべての接続がプロキシから来ます。 [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) がないと、
+監査証跡にはすべての操作でプロキシのアドレスが記録され、アドレスごとの
+[サインインの制限](../security/hardening.html#sign-in-limits-and-passwords) ではすべてのクライアントが一つのアドレスとして数えられます。
+`TRUST_PROXY` は、 `X-Forwarded-For` でクライアントを報告するとき、アプリケーションがどのプロキシを信頼してよいかを指定します。
+
+| 値 | クライアントのアドレス |
+|-------|----------------|
+| `0` （既定） | 接続のアドレス。 `X-Forwarded-For` は無視されます。空、 `false` 、 `off` 、 `no` も同じ意味です。 |
+| 数値。例： `1` | アプリケーションの前にあるその数のプロキシを信頼します。リバースプロキシが一つなら `1` 、イングレスの前にロードバランサーがあれば `2` 。 |
+| リスト。例： `10.0.0.5,172.16.0.0/12` | これらのアドレスと CIDR 範囲にあるプロキシを信頼します。プリセット `loopback` 、 `linklocal` 、 `uniquelocal` も使えます。 |
+| `true` | すべてのホップを信頼します。 `X-Forwarded-For` の左端のアドレスが使われます。 |
+
+アプリケーションは `X-Forwarded-For` を右から辿り、信頼するプロキシを飛ばして、それ以外の最初のアドレスを
+採用します。プロキシの正確な数、またはそのアドレスを使ってください。
+
+* `X-Forwarded-For` は、どのクライアントでも送れるただのリクエストヘッダーです。数値が大きすぎる場合や `true` の場合、
+  監査証跡に記録されるアドレスをクライアントが選べてしまいます。 `true` が安全なのは、アプリケーションにプロキシ経由でしか
+  到達できない場合だけで、これを設定するとサーバーは起動時に `[SECURITY]` の警告をログに記録します。
+* プロキシは、接続を受けたアドレスを追加する必要があります。下の例ではそうしています
+  （Nginx では `$proxy_add_x_forwarded_for` 。Traefik と Apache の `mod_proxy` は既定で追加します）。
+* 無効な値は設定ページで拒否されます。環境で設定した場合は起動時にエラーとしてログに記録され、
+  どのプロキシも信頼されません。設定ページで保存した変更は再起動なしで反映されます。
+
+---
+
+## 例
+
+各例では、AnsibleForms を `https://forms.example.com/ansibleforms/` で公開し、TLS はプロキシで終端し、
+アプリケーションは `HTTPS=0` 、 `PORT=8000` 、 `BASE_URL=/ansibleforms` 、 `TRUST_PROXY=1` で実行します。
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` には URI を付けないので、Nginx はパスを受け取ったまま、プレフィックスも含めて転送します。 `map` ブロックは
+`http` コンテキストに置き（ `conf.d/` の下のファイルはそこにインクルードされます）、ランナーの WebSocket アップグレードを通します。
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+サブパスを使わない場合は、 `location /` を使い、 `BASE_URL` は未設定のままにします。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+docker-compose プロジェクトの `app` サービスに付けるラベルで、Traefik は同じ Docker ネットワーク上にあります。サービスは
+独自のポートを公開せず、Traefik はネットワーク経由でそこに到達します。
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+`StripPrefix` ミドルウェアは意図的に使っていません。Traefik は `X-Forwarded-*` ヘッダーを自分で設定し、本文のサイズに上限を
+設けませんが、バックアップやアップロードがエントリポイントの読み取りタイムアウトより長くかかる場合は、その `respondingTimeouts` を確認してください。
+サブパスを使わない場合は、ルールの `Host(...)` の部分だけを残します。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+`mod_proxy` 、 `mod_proxy_http` 、 `mod_headers` 、 `mod_ssl` と、ランナーの `upgrade=websocket` のために Apache 2.4.47 以降が必要です。
+`ProxyPass` の両側にプレフィックスを付けます。
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+サブパスを使わない場合は、 `/` を `http://10.0.0.20:8000/` にプロキシし、 `BASE_URL` は未設定のままにします。
+
+</div>
+</div>
+
+プロキシとアプリケーションの間の区間も暗号化するには、アプリケーションを `HTTPS=1` で実行し、プロキシを
+`https://` に向け、プロキシが信頼する証明書をアプリケーションに与えます。 [HTTPS](../security/https.html) を参照してください。
diff --git a/i18n/ja/_configure/production/scaling.md b/i18n/ja/_configure/production/scaling.md
new file mode 100644
index 0000000..cad79b5
--- /dev/null
+++ b/i18n/ja/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: スケーリング
+parent: 本番環境での運用
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# スケーリング
+{: .no_toc }
+
+複数のアプリノードとワーカーに分割した AnsibleForms と、一つ以上の RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ロール
+
+すべての AnsibleForms コンテナーは同じサーバーコードを実行し、 [`AF_ROLE`](../customization/server.html#env_AF_ROLE) が何をするかを決めます。
+
+| `AF_ROLE` | イメージ | 実行するもの | 数 |
+|---|---|---|---|
+| `all` （未設定） | `ansibleforms` | Web アプリとワーカーを一つのプロセスで。既定です | 1 |
+| `app` | `ansibleforms` | Web インターフェースと API | ロードバランサーの背後にいくつでも |
+| `worker` | `ansibleforms` | バックグラウンドの処理。データベーススキーマとそのアップグレード、構成シード、スケジュール、夜間バックアップ、リポジトリの同期、クリーンアップ | 稼働するのは一つ。ほかは待機して引き継ぎます |
+| `rte` | `ansibleforms-rte-full` （または `-rte-core` 、 `-rte-base` ） | プレイブック | いくつでも |
+
+最小のインストールは、 `AF_ROLE` のないコンテナー一つと RTE 一つです。 [Docker Compose プロジェクト](../installation/docker-compose.html)
+と [Helm チャート](../installation/kubernetes.html) はこの構成で動作します。 `AF_ROLE` にそれ以外の値を指定すると、プロセスは起動時に停止します。
+
+---
+
+## RTE
+
+プレイブックを実行するランタイム環境である RTE には、専用のセクション [ランタイム環境](../rte/) があります。そこでは、RTE が
+ジョブを実行する仕組み、 [そのイメージ](../rte/images.html) 、 [実行方法](../rte/run.html) 、ランナーまたはレプリカとしての [複数の RTE](../rte/several.html) 、
+そして [別のデータセンターの RTE](../rte/another-datacenter.html) を扱います。
+
+---
+
+## 複数のアプリノード
+
+より多くのユーザーに対応したり、ノードを一つ失っても稼働を続けたりするには、アプリをロードバランサーの背後の `app` ノードと `worker` に分割します。
+
+### ノードが共有するもの
+{: .no_toc }
+
+ノードはデータベースと共有ボリュームを通じて互いに整合を取ります。
+
+* **データベース** ：ジョブ、ワーカーのロック、デザイナーのロック、ノードのリスト、ランナーのリース（各 RTE のソケットを
+  どのアプリノードが持っているか）、そして各ノードのキャッシュを最新に保つ変更通知。一つのノードで編集した認証情報、ランナー、スケジュールは、
+  5 秒以内にすべてのノードで有効になります
+* **永続ボリューム** （ `/app/dist/persistent` ）：フォーム、設定、リポジトリ、アップロード、バックアップ、管理対象の `.env` 。
+  すべてのアプリノードとワーカーが同じものを読み書き可能でマウントします
+* **ssh フォルダー** （ `/home/node/.ssh` ）：ssh 経由の git に使うキーと既知のホスト。ワーカーが最初の起動時にキーを作成します
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** ：すべてのアプリノードで同じにします。そうしないと、一つのノードが署名した
+  トークンが次のノードで拒否されます。アプリノードはこれがないと起動しません
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** ：すべてのアプリノードとワーカーで同じにします。そうしないと、一つのノードが
+  保存した認証情報を別のノードで読めません。ソケットモードの RTE はこれを読みません。必要なのは、自分自身を登録する非推奨のデータベースモードの RTE
+  だけです
+
+すべてのコンテナーに同じデータベースユーザーも与えてください。待機中のワーカーが停止したワーカーのセッションを終了できるのは、それが自分と同じユーザーの場合だけです。
+
+### ワーカーのロック
+{: .no_toc }
+
+同時に稼働するワーカーは一つだけです。稼働中のワーカーはデータベースのロック `ansibleforms_worker` を保持します。停止するとデータベースがロックを解放し、
+待機中のワーカーが 10 秒以内にそれを取得します。ワーカーのホストが別れを告げずに停止すると、データベースは何時間もロックを保持し続けることがあるため、
+2 分間どのワーカーもハートビートを書き込まなければ、待機中のワーカーがそのセッションを終了して引き継ぎます。
+
+別のワーカーにロックを奪われたワーカーは停止し、そのコンテナーは待機側として再起動します。起動に失敗したワーカーも停止するので、
+何もせずにロックを保持し続けることはありません。Galera とグループレプリケーションは、データベースノード間でロックを共有しません。すべての
+ワーカーを同じデータベースノードに向けてください。
+
+### ジョブとノード
+{: .no_toc }
+
+各コンテナーは、何も設定しなくても自分に `<role>-<hostname>-<port>` という名前を付けます。 **ステータス** ページにはそのすべてがロールと
+バージョン、どれがワーカーかとともに表示され、異なるバージョンが動作している場合は警告が出ます。
+
+RTE で実行中のジョブはその RTE に属し、それを開始したアプリノードがなくなっても続行します。それ以外のジョブ（AWX やほかのランナーの
+テンプレートジョブ、ワークフロージョブ、非推奨のマルチステップフォームのステップ）は、それを開始したアプリノードに属します。再起動したコンテナーは
+自分の未完了のジョブを終了し、置き換えられた Pod のように 2 分間応答しなくなったコンテナーのジョブはワーカーが終了します。
+
+どのノードに `SIGHUP` を送っても、 [構成シード](../seed/) が再適用されます。アプリノードはワーカーにそれを依頼します。
+
+### アップグレード
+{: .no_toc }
+
+**先にワーカー** をアップグレードし、その後でアプリノードをアップグレードします。ワーカーがスキーマにパッチを当て、新しいバージョンのアプリノードは
+スキーマにパッチが当たるまで待機し、何を待っているかをログに記録します。先にアップグレードしたアプリノードはワーカーが追いつくまで準備ができていない状態のままで、
+その間は古いノードが処理を続けます。RTE は、同じ契約で通信できる限り、いつ追従してもかまいません。
+
+### 制限
+{: .no_toc }
+
+一つのノードにとどまるものもいくつかあります。
+
+* **チャットアシスタント** は、会話を一つのアプリノードのメモリに保持します。ロードバランサーでスティッキーセッションを使う（nginx の
+  `ip_hash` ）か、アプリノードを一つにしてください
+* **ログ** は各コンテナーにとどまります。複数のプロセスが一つのファイルをローテーションすると行が失われるため、 [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) は
+  共有ボリュームの外に設定してください。ログビューアーは応答したノードのログを表示するので、ログは一元的に収集してください
+* 設定ページで変更した **設定** は共有ボリューム上の管理対象の `.env` に書き込まれ、すべてのノードに反映されます。再起動が必要な設定は、
+  すべてのノードで再起動が必要です
+
+---
+
+## 構成例
+
+アプリのリポジトリには、 [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale) に完全な出発点があります。
+
+| サービス | イメージ | ロール |
+|---|---|---|
+| `db` | `mariadb:11` | データベース。 `AnsibleForms` スキーマにだけ権限を持つユーザー付き |
+| `app1` 、 `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app` 。ロードバランサーの背後 |
+| `worker1` 、 `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker` 。二つ目は待機して引き継ぎます |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | `RTE_MODE=inbound` と `RTE_FILES=local` でプレイブックを実行します。アプリがそこに接続します |
+| `lb` | `nginx:stable` | ポート 8443 で HTTPS を終端し、 `ip_hash` でブラウザーをアプリノードに振り分けます |
+
+RTE のランナー `rte` と、それがサインインに使う認証情報（アドレス `http://rte:8000` と `RTE_TOKEN` ）は、ワーカーが起動のたびに適用する
+[構成シード](../seed/) `seed.yaml` で宣言されています。RTE は `RTE_URL` を設定せず、ホストには公開されません。
+
+アプリノードとワーカーは一つの `.env` を共有し、そこにはデータベースユーザー、 `ENCRYPTION_SECRET` 、 `ACCESS_TOKEN_SECRET` 、 `RTE_TOKEN` 、
+`CONFIG_SEED_PATH` 、ロードバランサーの背後なので `HTTPS=0` 、そして共有ボリュームの外の `LOG_PATH` があります。RTE には `env_file` がなく、
+`compose.yaml` から `RTE_TOKEN` だけを受け取るので、データベースのパスワードは保持しません。アプリノード、ワーカー、RTE は同じ
+永続ボリュームと ssh ボリュームをマウントします。
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/ja/_configure/rte/another-datacenter.md b/i18n/ja/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..58a5e9c
--- /dev/null
+++ b/i18n/ja/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: 別のデータセンター
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# 別のデータセンターの RTE
+{: .no_toc }
+
+2 つ目のデータセンターの何もないホストから、最初のプレイブックを実行するアウトバウンドの RTE まで
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+管理者向けです。2 つ目のデータセンターの管理対象ホストに、1 つ目のデータセンターからではなく、そのデータセンターの RTE から接続したい場合に使います。
+
+{: .note }
+> **簡単な方法。** [インストーラー](../installation/installer.html#a-runner) は、以下のすべての手順を RTE のホスト上で一つのコマンドで行います。
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner` です。すぐに承認させるには `--join afj_...` を付けます。
+> この手順書は同じことを Docker または Podman を使って手動で行うので、各部分を確認して調整できます。
+
+---
+
+## 最終的な構成
+
+アプリ、そのワーカー、データベースは、データセンター 1 のそのままの場所に残ります。データセンター 2 には、アウトバウンドモード
+（ [`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE) 。 [モード](modes.html#outbound) を参照）の RTE コンテナーを一つ実行するホストを置きます。RTE は HTTPS で
+アプリに接続して WebSocket を一本開いたままにし、独自のランナーとして参加し、それを指定するフォームのプレイブックをデータセンター 2 の管理対象
+ホストに対して実行します。
+
+| 場所 | そこで動作するもの | 通信先 |
+|---|---|---|
+| データセンター 1 | アプリノード、ワーカー、データベース（現状のまま） | 新しいものはありません。いつもの HTTPS のアドレスで RTE のソケットを受けます |
+| データセンター 2 の RTE ホスト | Docker または Podman と、RTE のコンテナー | HTTPS で `APP_URL` のアプリ、およびデータセンター 2 の管理対象ホスト |
+
+RTE はデータベースの認証情報も `ENCRYPTION_SECRET` も持たず、自分のトークンだけを持ちます。RTE に接続してくるものはないので、開いた
+ポートも、DNS 名も、証明書も不要です。アプリはプレイブックとインベントリを各ジョブとともに送るので（ `RTE_FILES=transfer` 、
+既定）、RTE にそのコピーも共有ディスクも不要です。
+
+特に記載がない限り、以下のコマンドはすべて RTE のホスト上のターミナルで、 `sudo` を使えるユーザーとして実行します。所要時間は約 20 分で、
+その大半はイメージの取得待ちです。
+
+---
+
+## 0. 始める前に
+
+次のものを集めてください。
+
+| もの | 入手先 |
+|---|---|
+| アプリのアドレス | `APP_URL` ：利用者がブラウザーで開くアドレス。例： `https://forms.example.com` 。ベースパスがあればそれも含めます |
+| アプリの証明書 | 公的な CA、プライベート CA（その証明書が必要です。手順 6）、または自己署名の証明書 |
+| プロキシ | このデータセンターがデータセンター 1 に到達するのに使う `HTTPS_PROXY` （ある場合） |
+| RTE の名前 | **接続 > ランナー** でのランナーの名前で、フォームは `runner:` でこれを指定します。例： `rte-dc2` 。英字、数字、 `_ . : @ -` |
+| 参加トークン | 任意： [参加トークン](../runners/registration.html#join-tokens) （ `afj_...` ）があれば RTE はすぐに承認されます。ない場合は管理者が承認します（手順 8） |
+| ssh キー | プレイブックが管理対象ホストへの接続に使う秘密鍵、またはそれを作成する権限 |
+
+アプリは 7.3.0 以降である必要があります。この RTE 専用の参加トークンを作るには、管理者が API を一度呼び出します（
+[参加トークン](../runners/registration.html#join-tokens) を参照）。
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. ホストの準備
+
+RTE はコンテナーなので、ホストに必要なのはコンテナーエンジンだけです。Node.js、python、ansible はイメージに含まれています。
+
+| 必要なもの | 理由 |
+|---|---|
+| **x86_64** （amd64）の Linux | RTE イメージは amd64 向けにしか公開されていません |
+| 2 CPU と 4 GB 以上のメモリ | 一つの RTE は最大 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 個（10）のプレイブックを同時に、それぞれのフォークとともに実行します。それに合わせてサイズを決めてください |
+| 20 GB の空きディスク | `-rte-full` イメージは約 3.3 GB で、さらに更新時のイメージ、アプリが送るジョブのファイル、ジョブの一時ファイルが加わります |
+| Docker、または podman-compose を伴う Podman | イメージを取得して実行するため |
+| NTP で合わせた時刻 | ジョブの時刻はアプリの時刻と比較されます |
+
+**Docker** 、Ubuntu または Debian の場合（ほかのディストリビューション： [docs.docker.com/engine/install](https://docs.docker.com/engine/install/) ）：
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman** 、RHEL、Rocky、Alma Linux の場合：
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Podman では、以下のすべてのコマンドで `docker` を `podman` に、 `docker compose` を `podman-compose` に読み替えてください。
+
+---
+
+## 2. ネットワークとファイアウォール
+
+RTE はすべての接続を自分で開きます。外部から RTE に届くものはありません。
+
+| 送信元 | 宛先 | ポート | 理由 |
+|---|---|---|---|
+| RTE のホスト | `APP_URL` のアプリ（設定されていれば `HTTPS_PROXY` 経由） | アプリのポート。多くのプロキシの背後では `443` | ジョブ、そのファイル、その出力が流れるソケット |
+| RTE のホスト | データセンター 2 の管理対象ホスト | ssh（ `22` ）、WinRM、それらの API | プレイブックはここから実行されます |
+| RTE のホスト | `ghcr.io` | `443` | イメージを取得するため。独自のレジストリやファイルから取得する場合は不要です（手順 4） |
+
+RTE のために着信ポートは開かないでください。その `PORT` （ `8000` ）が提供するのは、このホスト上のプローブ用の `/live` 、 `/ready` 、 `/metrics` だけです。
+
+RTE は、 `APP_URL` に `/api/v2/rte/socket` を付けたアドレスに WebSocket として接続します。アプリの前にあるリバースプロキシは、そのパスで
+アップグレードを通す必要があります（ [ランナーの WebSocket](../production/reverse-proxy.html#runner-websockets) を参照）。ここからアプリが応答することを確認します。
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. フォルダー
+
+すべては `/opt/af-rte` の下に置きます。RTE はユーザー `node` （uid 1000）で動作するので、そのデータはその uid の所有にします。
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| フォルダー | コンテナー内 | 保持するもの |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | スプール（ `rte-spool` ：アプリが保存するまでの各ジョブの出力と終了）、アプリが送ったジョブのファイル（ `rte-files` ）、プライベート CA、プレイブックがインストールする python ライブラリ |
+| `data/ssh/` | `/home/node/.ssh` | プレイブックの ssh キーと `known_hosts` |
+| `data/ansible/` | `/etc/ansible/...` | 組み込む代わりにマウントする、独自の `ansible.cfg` 、ロール、コレクション |
+
+`data/` はホスト上に置いてください。再起動した RTE も、アプリが保存していなかったものを送り、ジョブのファイルのキャッシュを保持します。
+
+**ssh キー。** データセンター 1 でプレイブックが使っているキーをコピーするか、このデータセンター用に作成して、その公開鍵を管理対象ホストに渡します。
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+次に、すべてを uid 1000 に渡し、キーは所有者だけが読めるようにします。
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. イメージ
+
+二つのうち一つを選んでください。
+
+### 選択肢 A：公式イメージ
+{: .no_toc }
+
+公開されているイメージは GitHub Container Registry にあり、公開されていてログインは不要です（三つのレイヤーについては [イメージ](images.html) を参照）。
+データセンター 1 と同じレイヤーを使ってください。 `:7` は、アプリの `:7` と同じく最新の 7 系リリースに追従します。
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+インターネットにアクセスできないホストは、アクセスできるホストからイメージを入手します。
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+または、一度だけ独自のレジストリにプッシュし（ `docker tag` と `docker push` ）、以降の手順ではその名前を使います。
+
+### 選択肢 B：独自のイメージ
+{: .no_toc }
+
+データセンター 2 のプレイブックが、公式イメージにないコレクションや python ライブラリ（たとえば、このデータセンターの vCenter 用の VMware のもの）を
+必要とする場合は、 `ansibleforms-rte-core` の上に構築します。
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+アプリの新しいリリースのたびにリビルドしてください（ [独自の RTE のビルド](images.html#build-your-own-rte) を参照）。複数の RTE ホストがある場合は、一度ビルドして
+独自のレジストリにプッシュします。オフラインの場合は、選択肢 A と同じようにビルドしたイメージを `docker save` と `docker load` で移します。
+
+---
+
+## 5. 設定
+
+16 文字以上の、新しい独自の [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) を用意します。これがこの RTE のパスワードです。アプリは
+それをランナーの RTE 認証情報に保持し、それで各ジョブのシークレットを封印します。
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| 変数 | 意味 |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound` ：RTE がアプリに接続します。これがないと、RTE は非推奨のデータベースモードで起動します |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | アプリのアドレス。 `http://` または `https://` で、ベースパスがあればそれも含めます |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | ランナーの名前。未設定の場合はノード ID `rte-<hostname>-<port>` で、コンテナーとともに変わります |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | 独自のトークン。16 文字以上。保管しておいてください。以降、ランナーはこれでサインインします |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | 任意：参加トークン。ランナーがまだ存在しないか承認待ちの間だけ使われます |
+
+ネットワークに必要な場合は、次のものを追加します。
+
+| 変数 | 使う場面 |
+|---|---|
+| `HTTPS_PROXY` 、 `NO_PROXY` | RTE がプロキシ経由でアプリに到達する場合： `HTTPS_PROXY=http://proxy.dc2.example.com:3128` 。 `NO_PROXY` に記載したホスト（カンマ区切り。ドメインは `.example.com` ）には直接接続します |
+| `NODE_EXTRA_CA_CERTS` | アプリの証明書がプライベート CA のものである場合：CA の証明書を `/opt/af-rte/data/certificates/ca.pem` に置き、 `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` を設定します |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` は、自己署名のものも含め、アプリのどの証明書も受け入れます。信頼できる一つのネットワークの中でだけ使い、 `NODE_EXTRA_CA_CERTS` を優先してください |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` （既定）はプレイブックとインベントリを各ジョブとともに受け取ります。自分で RTE にマウントする（ `local` ）場合を除き、そのままにします |
+
+RTE が読み込むその他の設定は [RTE の実行](run.html#settings) にあります。 `RTE_MAX_JOBS` 、 `RTE_CACHE_MB` 、 `RTE_FILES` 、
+`RTE_DRAIN_SECONDS` は、後からランナーのページで設定することもでき、そちらが変数より優先されます（
+[RTE の設定](../runners/runner-page.html#an-rtes-settings) を参照）。
+
+---
+
+## 6. 起動
+
+compose ファイルを使うと、定義全体を設定の隣の一か所にまとめられます。 `image:` には手順 4 のイメージを指定します。
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker は再起動後に再び起動します（ `unless-stopped` ）。Podman にはそれを行うデーモンがないので、 `podman-restart.service` を有効にする
+（ `sudo systemctl enable --now podman-restart` ）か、Quadlet ファイルでコンテナーを systemd サービスとして実行してください。SELinux が
+enforcing のホストでは、各ボリュームに `:Z` を追加します（ `./data:/app/dist/persistent:Z` ）。
+
+compose を使わない場合、同じコンテナーを一つのコマンドで起動できます。
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. ホストでの確認
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+ログには、RTE が起動し、アプリに接続し、接続が確立したことが表示されます。
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+参加トークンがない場合は、待機中であることを示す行がもう一つ表示されます。
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)` 。フィンガープリントを控えておいてください。
+
+ソケットが開くまで、 `/ready` は `not connected to the app` とともに `503` を返します。ヘルスチェックが示すのは、プロセスが待ち受けていることだけです。
+
+---
+
+## 8. 承認
+
+参加トークンがない場合、RTE は参加を申請しています。 **接続 > ランナー** では、リストの上にオレンジ色の通知
+**1 件のランナーが承認を待っています** が表示されます。それを開き、 **フィンガープリント** が RTE のログのものと同じで、 **モード** が
+アウトバウンドであることを確認してから、 **承認** します（ [RTE の承認](../runners/registration.html#approving-an-rte) を参照）。承認できるのは管理者だけです。24 時間以内に
+誰も処理しなかった申請は削除され、RTE は次にアプリに接続したときに再び申請します。
+
+参加トークンがある場合、ランナーはすぐに承認され、その説明には参加トークンの名前が入ります。どちらの場合も、アプリは RTE のトークンを
+新しい RTE 認証情報 `rte-dc2-rte` に保持し、以降 RTE は自分の `RTE_TOKEN` でサインインします。 `RTE_JOIN_TOKEN` はもう
+使われないので、 `rte.env` から削除してかまいません。
+
+---
+
+## 9. AnsibleForms での確認
+
+1. **接続 > ランナー** に、種類 RTE のランナー `rte-dc2` が表示されます。 **列 > 接続** をオンにすると、リストに **接続済み** が表示されます
+2. それを開きます。 **RTE** タブには **モード** アウトバウンドと、 **接続** のバッジ **接続済み** が表示されます。ポインターを重ねると、
+   ソケットを持つアプリノード、RTE のリリース、実行中のジョブの数が表示されます
+3. **接続テスト** をクリックすると、 **Runner connection is OK** と表示されます。何も呼び出さず、どのアプリノードが RTE のソケットを持っているか
+   （ `runner_leases` ）を読み、RTE が接続時に使った契約を確認します
+4. *データセンター 2* のような説明を付けます
+5. `runner:` のないすべてのプレイブックフォームをデータセンター 2 で実行したい場合を除き、 **既定** はデータセンター 1 のランナーのままにします
+
+**ステータス** ページには、新しい RTE がほかの RTE と並んでバージョンとともに表示されます。
+
+---
+
+## 10. 最初のジョブ
+
+何も変更しないプレイブックで、経路全体を確かめます。アプリのプレイブック（データセンター 1 と同じく、そのプレイブックのフォルダーまたは
+リポジトリ）に `ping-dc2.yaml` を追加します。
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+次に、デザイナーで新しいランナーを指定するフォームを追加します。
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+起動します。アプリはプレイブックのフォルダーとインベントリをジョブとともに送り、RTE はそれらをハッシュで保持するので、変更されていない
+フォルダーが二度送られることはありません。出力は `Running on RTE rte-dc2 (outbound)` で始まり、すべてのホストで `pong` と表示され、ジョブは
+成功で終わります。 [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) （既定は 512）より大きいフォルダーは
+送られず、ジョブは失敗してその旨を示します。
+
+---
+
+## 11. フォームの送り先にする
+
+フォームは指定した RTE で実行されるので、データセンター 2 向けのすべてのフォームに同じ行を追加します。
+
+```yaml
+runner: rte-dc2
+```
+
+既定のランナーとほかの種類のランナーについては [ランナー](../runners.html) を参照してください。
+
+---
+
+## 失敗したとき
+
+RTE は `notice` 以上を `docker logs` に書き込みます。ソケットが開く前に失敗した接続（DNS 名、拒否されたポート、
+証明書）は、 `info` で `RTE: dialing the app again in <n> seconds` としか表示されません。
+`rte.env` に [`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) を設定して再起動すると、
+`RTE: socket to wss://...: <the error>` が表示されます。
+
+| 表示されるもの | 場所 | 対処 |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `rte.env` に `RTE_TOKEN` がないか、短すぎます |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | `rte.env` に `APP_URL` を設定します |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` は `https://` （または `http://` ）で始めます |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | `rte.env` に `RTE_MODE=outbound` がありません |
+| `connected to the app` の行がなく、 `/ready` が `503` のまま | `docker logs` 、 `/ready` | 手順 2 のネットワーク：このホストからアプリに `curl` し、プロキシ（ `HTTPS_PROXY` 、 `NO_PROXY` ）とアプリの証明書（ `NODE_EXTRA_CA_CERTS` 、手順 5）を確認します。エラーを見るには `LOG_CONSOLE_LEVEL=debug` を設定します |
+| `the app refused the socket (404)` 、または 401、403、409 以外のステータス | `docker logs` | リバースプロキシが `/api/v2/rte/socket` で WebSocket を通していないか、 `APP_URL` にアプリのベースパスがありません |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | 別のトークンを持つランナー `rte-dc2` が存在します。RTE にそのトークン（ランナーの認証情報のパスワード）を与えるか、ランナーを削除して RTE に参加を申請させます |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | 新しい参加トークンを作るか、 `RTE_JOIN_TOKEN` を削除して RTE を承認します（手順 8） |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | RTE が新しいトークンで再インストールされました。ランナーの認証情報のトークンを使うか、管理者に変更してもらいます |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | 拒否の後に表示されます。原因を修正したら、待たずに `docker restart af_rte_dc2` を実行します |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | 承認します（手順 8）。接続はしていますが、それまではジョブを受け取りません |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | アプリと RTE が異なる [契約](images.html#the-contract) のリリースで動作しています。RTE をアプリのリリースに更新します（「更新」を参照） |
+| **未接続** 、または **接続テスト** で *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* と表示される | アプリ | どのアプリノードもそのソケットを持っていません。RTE が停止しているか、アプリに到達できません。その `docker logs` を確認します |
+| ジョブが待機した後、 *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* で失敗する | ジョブの出力 | ジョブが待機している間、RTE が接続していませんでした |
+| ssh キーで `Permission denied` | ジョブの出力 | `data/` のファイルは uid 1000 の所有である必要があります（手順 3） |
+| 管理対象ホストで `UNREACHABLE` | ジョブの出力 | このホストからの ssh：キー、 `known_hosts` 、ホストへのファイアウォール |
+
+アプリ側では、拒否された RTE はアプリのログに `Refused an RTE socket from <address>: <why>` として表示されます。
+
+---
+
+## 更新
+
+アプリが新しいリリースに移ったら、このホストでも追従してください。同じ契約の RTE はその間も動作し続けます。リリースで
+契約が変わる場合は、そのリリースノートに記載されます（ [契約](images.html#the-contract) を参照）。 `compose.yml` 、または Dockerfile の
+`FROM` に `:7` を指定している場合：
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+プレイブックが実行されていないときに更新してください。停止時は実行中のプレイブックを `RTE_DRAIN_SECONDS` （25）待ち、その時点でまだ実行中のものは
+放棄されたものとして終了します。停止前に出力されたものはスプールに保持され、RTE が戻ると送られます。オフラインの場合は、
+`docker compose up -d` の前に新しいイメージを `docker load` します（手順 4）。
+
+---
+
+## ロールバック
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+ソケットが閉じ、ランナーはすぐに **未接続** と表示されます。どのアプリノードもそのソケットを持たなくなるためです（ `runner_leases` ）。ソケットを閉じずに
+いなくなったホストは、アプリノードがソケットから何も受け取らなくなってから約 1 分以内に **未接続** と表示されます。
+ランナーは残ります。ソケットで参加したランナーが自動的に削除されることはありません。 **接続 > ランナー** でランナーを、
+**接続 > 認証情報** でその認証情報 `rte-dc2-rte` を削除してください。先に、それを指定していたフォームから `runner:` の行を削除します。そうしないと、
+それらのジョブは最大 `RTE_QUEUE_MINUTES` の間 RTE を待ち、失敗します。
+
+---
+
+## データセンター 2 の容量の追加
+
+データセンター 2 のほかのホストで手順 1 から 9 を繰り返し、それぞれに `rte-dc2-b` のような独自の `RTE_NAME` と `RTE_TOKEN` を与えます。それぞれが
+独自のランナーとして参加し、最大 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 個のプレイブックを受け取ります。フォームは
+`runner:` でその一つを選びます。同じ `RTE_NAME` を持つ二つの RTE は作業を分担しません。2 つ目が 1 つ目からソケットを引き継ぎます（
+[複数の RTE](several.html#several-rtes) を参照）。
+
+---
+
+## データベースモードの RTE
+
+7.3.0 より前は、この手順書でデータベースモードの RTE を構成していました。データベースの認証情報（ `DB_*` 、 `ENCRYPTION_SECRET` ）を保持し、
+ポート `3306` でデータセンター 1 のデータベースに接続し、アプリはポート `8000` で RTE を呼び出していました。このモードは 7.3.0 から非推奨で、
+8.0.0 で削除されます。新しいランナーを作らずにこうした RTE をアウトバウンドに移すには、 `RTE_MODE=outbound` 、 `APP_URL` 、 `RTE_NAME` （その
+ランナーの名前）を設定し、 `RTE_TOKEN` はそのままにして、 `DB_*` 、 `ENCRYPTION_SECRET` 、 `RTE_REGISTER` を削除します。
+[データベース（非推奨）](modes.html#database-deprecated) を参照してください。その後、不要になったポート `8000` とデータベースのポートを閉じます。
diff --git a/i18n/ja/_configure/rte/images.md b/i18n/ja/_configure/rte/images.md
new file mode 100644
index 0000000..7468c72
--- /dev/null
+++ b/i18n/ja/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: イメージ
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# RTE イメージ
+{: .no_toc }
+
+公開されている三つの RTE イメージと、プレイブックが使うコレクションとライブラリを含む独自の RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## RTE イメージ
+
+RTE は三つのレイヤーで公開されており、それぞれが前のものの上に構築され、タグはアプリと同じです（ [イメージのタグ](../installation/#image-tags) を参照）。
+
+| イメージ | 中身 | 用途 |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js と AnsibleForms サーバー、git、ssh、sshpass。python も ansible もないので、単体ではプレイブックを実行しません | 独自の python と ansible のバージョンで RTE をビルドする場合 |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | base に、python 3.14、ansible-core、いくつかの一般的なライブラリ（ `jmespath` 、 `netaddr` 、 `requests` 、 `paramiko` ）を加えたもの。コレクションはありません | プレイブックが使うコレクションとライブラリだけを含む、より小さな RTE をビルドする場合 |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | core に、同じ ansible-core 上の `ansible` パッケージと、AnsibleForms 6.5 のイメージにあったもの（NetApp、AWS、community のコレクション、 `pandas` 、 `pyvmomi` 、 `boto3` 、mariadb クライアント、ytt、いくつかの OS ツール）を加えたもの | **既定。** そのまま実行します。6.5 のプレイブックは使っていたものを見つけられます |
+
+アプリのイメージと同じく、すべてのレイヤーはユーザー `node` （uid 1000）で動作し、プレイブックもそのユーザーで実行されます。
+
+---
+
+## 独自の RTE のビルド
+
+`ansibleforms-rte-core` の上に構築し、プレイブックが使うコレクションと python ライブラリを追加します。この NetApp の例は、
+[examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte) にある Dockerfile の一つです。
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+python の環境とコレクションのフォルダーは `node` の所有なので、これらのインストールに root は不要です。OS のパッケージをインストールする
+レイヤーでは、そのために `USER root` に切り替え、最後に `USER node` に戻します。独自の python と ansible を使うには、
+`ansibleforms-rte-base` の上に構築します（同じフォルダーの `Dockerfile.own-ansible` ）。
+
+イメージはアプリのリリースに合わせてください。 `:7` はアプリの `:7` に追従します。コレクションとロールは、組み込む代わりに
+`/etc/ansible/collections` と `/etc/ansible/roles` にマウントすることもできます。その場合は変更のたびにリビルドする必要はありませんが、実行されるものはそのボリュームに
+依存します。python ライブラリは常にイメージに含めます。すべてを組み込むと再現性があり起動も速いので、本番環境ではこの方法を使ってください。
+
+---
+
+## 契約
+
+アプリと RTE が共有しなければならないのは契約で、両者が報告する番号です。古いリリースの RTE も、両者が同じ契約で通信する限り、
+新しいアプリと引き続き動作します。リリースで契約が変わる場合は、そのリリースノートに RTE の更新が必要であると記載されます。各モードには
+それぞれの契約があります。
+
+| モード | 契約 | 一致しない場合 |
+|---|---|---|
+| アウトバウンド、インバウンド | 3。7.3.0 で追加 | アプリはコード `4409` で RTE のソケットを閉じ、 *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused* とログに記録します。アウトバウンドの RTE は *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds* とログに記録します。別の契約で送られたジョブは拒否されます |
+| データベース（非推奨） | 2。7.0.0 から | RTE はアプリのジョブを拒否します |
+
+ランナーの **接続テスト** は、RTE がどの契約で通信し、アプリがどの契約を必要としているかを示します（
+[接続テスト](../runners/runner-page.html#test-connection) を参照）。 **ステータス** ページの **ランナー** の行でも同じ確認が行われます。
diff --git a/i18n/ja/_configure/rte/index.md b/i18n/ja/_configure/rte/index.md
new file mode 100644
index 0000000..4bf024b
--- /dev/null
+++ b/i18n/ja/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# ランタイム環境（RTE）
+{: .no_toc }
+
+RTE とは何か、プレイブックをどのように実行するか、何に触れてよいか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。RTE を実行する前、サイズを決める前、別のネットワークに移す前に、RTE を理解しておいてください。
+
+| ページ | 内容 |
+|---|---|
+| [イメージ](images.html) | 三つの RTE イメージと、プレイブックが使うコレクションを含む独自イメージのビルド |
+| [モード](modes.html) | アウトバウンド、インバウンド、データベース：誰が接続を開くか、スプール、ジョブのファイル |
+| [RTE の実行](run.html) | 各モードの設定と、それぞれの `docker run` の例 |
+| [複数の RTE](several.html) | 容量、一つのアドレスの背後のレプリカ、RTE が停止または異常終了したときに起きること |
+| [別のデータセンター](another-datacenter.html) | 手順書：何もないホストから最初のジョブまで、2 つ目のデータセンターに RTE を追加します |
+
+---
+
+## RTE とは
+
+AnsibleForms 7 は、アプリのコンテナーではプレイブックを実行しません。 `ansible` フォームのジョブは、種類が `rte` の
+[ランナー](../runners.html) 、つまりランタイム環境に渡されます。これは `AF_ROLE=rte` で起動した AnsibleForms サーバーで、python と ansible を
+備え、Web インターフェースはありません。アプリとは一本の WebSocket で通信し、データベースの認証情報は持ちません
+（ [`RTE_MODE`](../customization/server.html#env_RTE_MODE) が `outbound` または `inbound` 。 [モード](modes.html) を参照）。アプリがジョブを送り、
+RTE が `ansible-playbook` を実行し、送り返された出力と最終ステータスをアプリが保存し、ブラウザーはそれを読み込みます。
+
+アプリはジョブの認証情報を解決し、その RTE とそのジョブだけが開けるように封をして RTE に渡します。RTE は認証情報のテーブルも
+シークレットストアも読まず、プレイブックは AnsibleForms 自身の環境変数（ `ENCRYPTION_SECRET` 、 `DB_*` 、 `RTE_TOKEN` など）を
+引き継ぎません。そうした値は extravar または認証情報として渡してください。データベースを自分で読み書きしていた 7.0 から 7.2 の RTE は、
+7.x では非推奨のデータベースモードとして引き続き動作します（ [データベースモード](#database-mode-deprecated) を参照）。
+
+---
+
+## RTE の動作
+
+RTE は、アプリの隣または別のネットワークで自分で実行するコンテナーです。AnsibleForms が作成することはありません。ここでは、
+どこで動作するか、アプリと何を共有するか、そしてフォームが起動されてからプレイブックのプロセスがなくなるまでに
+その中で何が起きるかを順に説明します。
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">RTE がプレイブックを実行する仕組み</title>
+<desc id="afr-desc">運用者が管理するコンテナーホストまたは Kubernetes クラスター上で、アプリのコンテナーと一つ以上の RTE コンテナーが、それぞれの間に一本の WebSocket を持ちます。ソケットはアプリ（インバウンド）または RTE（アウトバウンド）が開きます。データベースと通信するのはアプリだけです。1：ブラウザーがアプリでフォームを起動します。2：アプリはジョブをデータベースに保存し、ランナーを選び、そのランナー向けにジョブのシークレットを封印します。3：アプリがソケットでジョブを送ります。4：RTE がジョブを受け取り、ジョブのファイルをキャッシュまたはアプリから取得します。5：RTE が ansible-playbook を子プロセスとして、ジョブごとに一つ、RTE_MAX_JOBS まで起動します。6：プレイブックが管理対象のホストに接続します。7：RTE が出力、イベント、終了をスプールに書き込み、ソケットで送ります。アプリはそれらをデータベースに保存して確認応答します。8：ブラウザーはアプリを通じてジョブを追跡します。アプリのボリュームが RTE にマウントされるのは RTE_FILES=local の場合だけです。</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">コンテナーホストまたは Kubernetes クラスター</text>
+<text class="afr-s" x="181" y="61">管理は利用者。アウトバウンドの RTE は別のネットワークでも可</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">ブラウザー</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">フォーム、ジョブページ</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">アプリのコンテナー</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">Web アプリ、API、ワーカー</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">ランナー</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">シークレットを封印</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">RTE ハブ</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">保存して確認応答</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">RTE コンテナー</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">ジョブのファイル</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">ハッシュでキャッシュ</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">最大 RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">スプール</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">確認応答まで保持</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">一本の</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">管理対象のホスト</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">アプリのボリューム</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">プレイブック、インベントリ</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">RTE_FILES=local のみ</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">アプリ専用</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+図は、どちらの側が開いたかにかかわらず、RTE ごとに一つのソケットを示しています。インバウンドの RTE にはアプリが接続し、アウトバウンドの RTE はアプリに接続します（
+[モード](modes.html) を参照）。開いた後は同じメッセージが双方向に流れ、データベースを読み書きするのはアプリだけです。
+
+**誰が起動するか。** RTE は長時間動作するコンテナーで、ほかのコンテナーを実行しているものが起動します。ジョブを待ち、
+ジョブの合間も動作し続けます。
+
+| AnsibleForms の実行方法 | RTE を起動するもの |
+|---|---|
+| `docker run` または `podman run` | 自分で起動します。 [RTE の実行](run.html) にあるようなコマンドを、アプリに到達できる、またはアプリから到達できる任意のホストで実行します |
+| [Docker Compose](../installation/docker-compose.html) | `docker-compose.yml` の `rte` サービス。 `app` と `mysqldb` の隣にあります。構成シードで、インバウンドの既定のランナー `rte` として `http://rte:8000` に宣言されています |
+| [Helm チャート](../installation/kubernetes.html) | Kubernetes。アプリの Pod 内の `rte` という 2 つ目のコンテナー（ `containers.rte` ）として起動します。アプリは `127.0.0.1` でインバウンドとして接続し、チャートのシードで既定のランナーとして宣言されています |
+| [インストーラー](../installation/installer.html) | 上記の Docker Compose または Helm チャート、あるいは [コンテナーを使わない](../installation/native.html) systemd サービス。独自のランナーで、参加を申請して管理者の承認を待ちます |
+
+コンテナーエンジンは利用者のものです。ホスト上の Docker や Podman、または Kubernetes クラスターのコンテナーランタイムで、インストールと更新は
+利用者が行います。AnsibleForms がそれと通信することはありません。アプリも RTE も Docker や Podman を呼び出さず、そのソケットをマウントせず、
+コンテナーを起動しません。アプリはソケットを通じて RTE と通信するだけです。
+
+**中身。** プレイブックの実行に必要なものだけを備えた、一つのコンテナーです。
+
+* **サーバー** ：アプリと同じ Node.js サーバーで、 `tini` の下で `AF_ROLE=rte` （イメージで設定）で起動します
+* **省かれているもの** ：Web インターフェース、ログイン、スケジューラー、ワーカー、すべてのデータベースモジュール。このロールでは読み込まれません
+* **待ち受けるもの** ：その `PORT` （ `8000` ）。プローブ用の `/live` と `/ready` 、Prometheus 用の `/metrics` 、そしてインバウンドの場合は
+  アプリが接続するソケット `/rte/v1/socket` 。アウトバウンドの RTE はアプリからの接続を受けません
+* **Python と ansible** ：選んだイメージのレイヤーが提供します（ [RTE イメージ](images.html) を参照）
+* **ユーザー** ：サーバーとすべてのプレイブックは `node` （uid 1000）で実行され、root では実行されません
+
+**アプリと共有するもの。** トークンと、 `RTE_FILES=local` の場合はアプリのファイルです。既定の `RTE_FILES=transfer` では、
+プレイブックとインベントリは各ジョブとともに届き、RTE に共有ディスクは不要です。
+
+| アプリと共有するもの | RTE での使い方 |
+|---|---|
+| `RTE_TOKEN` | アプリに接続するとき（アウトバウンド）に提示するか、アプリが接続してきたとき（インバウンド）に確認します。アプリはランナーの RTE 認証情報に同じ値を保持し、ジョブのシークレットはそれで封印されます |
+| 永続ボリューム `/app/dist/persistent` 。 `RTE_FILES=local` の場合のみ | プレイブックのフォルダー（ [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) ）、またはワーカーが [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) の下にクローンしたプレイブックのリポジトリ、インベントリ（ [`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) とインベントリのリポジトリ）、アップロード。RTE はジョブの extravars ファイルをプレイブックのフォルダーに書き込むので、読み書き可能でマウントしてください |
+| ssh フォルダー `/home/node/.ssh` | プレイブックの ssh 接続が使う秘密鍵と `known_hosts` 。設定ページで管理しているアプリのものをマウントするか、RTE に独自のものを与えます |
+
+RTE は何もクローンしません。リポジトリはジョブのファイルとして、またはアプリと共有するボリューム上で RTE に届きます。コレクション、ロール、
+`ansible.cfg` は、イメージから、 `/etc/ansible/collections` 、 `/etc/ansible/roles` 、 `/etc/ansible/ansible.cfg` にマウントした場合はそれらのフォルダーから
+（Docker Compose プロジェクトはそうしています）、またはプレイブックの隣にある `ansible.cfg` から取得されます。
+
+**ジョブのライフサイクル。** 以下の番号は、ブラウザーまたは API から起動したプレイブックフォームについての、図の番号です。
+
+1. **起動** ：アプリはフォームとその値を確認し、extravars を組み立て、ステータス `running` でジョブを保存します。
+   [承認](../forms/approval.html) のあるフォームは、承認者が承認するまでここで止まり、それまでどの RTE にも届きません
+2. **ランナーの選択** ：アプリは、フォームが `runner: <name>` で指定した RTE、なければ種類が RTE の既定のランナーを選び、その
+   名前をジョブに保存します。データベースまたは [シークレットストア](../secret-stores/) からジョブの認証情報、ansible のログイン、
+   vault パスワードを解決し、そのランナーのトークンとジョブ ID から導出したキーで AES-256-GCM により封印します
+3. **引き渡し** ：RTE のソケットを持つアプリノードが、ジョブを RTE に送ります。extravars、フォームのオプション、封印されたシークレット、
+   ジョブのファイルのハッシュです。どのアプリノードでもジョブを起動でき、ソケットを持つノードが 2 秒以内に送ります。RTE が満杯か
+   接続していない場合、ジョブは最大 [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) まで待機します
+4. **受け取り** ：RTE は `claimed` と答えるか、満杯、停止中、シークレットを開けない、またはジョブが自分とは異なる
+   [契約](images.html#the-contract) で届いた場合は `refused` と答えます。 `RTE_FILES=transfer` では、プレイブックとインベントリをハッシュで
+   キャッシュから取り出し、持っていないハッシュはアプリに要求し、ジョブ専用のフォルダーに展開します
+5. **開始** ：プレイブックのフォルダー（存在する必要があるフォームの `playbookSubPath` を加えたもの）に二つのファイルを書き込みます。フォームの値と
+   認証情報を含む `extravars_<id>.json` と、ansible のログインを含む隠しファイルです。その後、 `ansible-playbook` を自分の子プロセスとして、
+   シェルを使わず、独自のプロセスグループで起動します。それらのファイルを `-e @` で、インベントリごとに `-i` を一つ渡し、フォームのタグ、limit、check、
+   diff、詳細度も渡します。vault パスワードは stdin で渡され、ファイルやコマンドラインには決して置かれません。プロセスは
+   フィルターされた環境で `node` として実行されます（下記を参照）
+6. **実行** ：プレイブックは RTE のコンテナーから管理対象のホストに接続します。 `/home/node/.ssh` のキーと `known_hosts` を使った ssh、
+   パスワードログインの場合は `sshpass` 、またはモジュールが呼び出す API 経由です。到達できる必要があるのはアプリではなく RTE です
+7. **出力と終了** ：RTE は stdout と stderr を 0.5 秒ごとまたは 64 KB ごとにまとめ、認証情報をマスクし、各バッチに番号を付けます。
+   送信する前に、各項目をディスク上のジョブのスプールに書き込みます。出力、イベント、
+   `.joblogs/job_log_<id>.log` のジョブログ（2 秒ごと）、開始、そして最終ステータス（ `success` 、 `failed` 、 `aborted` ）を伴う終了です。アプリは
+   各項目を一度だけ保存して確認応答し、終了が保存されると RTE はスプールを破棄します。一つのストリームで
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) バイト（既定は 50 MB）を超えるとそれ以上は送らず、
+   プレイブックは続行します。その後、アプリはフォームの [通知](../forms/notifications.html) を送ります
+8. **追跡** ：ブラウザーが RTE と通信することはありません。フォームのページは 2 秒ごとにアプリを通じてジョブを読み直し、ジョブページは
+   アプリが各項目を保存するたびにライブで追跡します
+
+**ソケットが切断された場合。** プレイブックは続行します。RTE が再接続する（アウトバウンド）か、アプリノードが再び接続し（インバウンド）、
+アプリがまだ確認応答していないものを再送します。アプリはすでに保存したものを飛ばすので、行が失われたり二重に保存されたりすることはありません。これが成り立つのは、
+2 分以内にソケットが戻る場合です。アプリはソケットが開いている間だけ RTE のハートビートを書き込み、そのハートビートが 2 分経過すると、
+プレイブックがまだ動作していても、ワーカーはその RTE の実行中のジョブを放棄されたものとして終了します。再起動した RTE が保持していたものを送れるよう、
+スプール（ [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) ）はボリューム上に置いてください。RTE の再起動時に
+実行中だったプレイブックは続行できません。RTE がそれを持たずに戻ってくると、アプリはそのジョブを放棄されたものとして終了します。
+
+**中止。** 中止するとジョブの中止フラグが設定され、RTE のソケットを持つアプリノードが 2 秒以内に `cancel` を送ります。RTE は
+プレイブックのプロセスグループに `SIGTERM` を送るので、 `ansible-playbook` とそれが起動したすべてのフォークが一緒に停止し、ジョブは
+`aborted` で終了します。ジョブより先に届いた cancel は 1 分間保持され、そのジョブは中止された状態で開始されます。
+
+**後片付け。** プロセスが終了するとすぐに、結果にかかわらず、RTE は二つの extravars ファイル（ `keepExtravars` のあるフォームは
+表示されるほうを残しますが、隠しファイルは決して残しません）、 `/tmp` のアーティファクトファイル、ジョブログのファイル、ジョブ専用のファイルのフォルダーを削除します。
+終了は一度だけ保存されます。RTE がすでに終了したジョブをアプリが失敗にするなど、二度目の書き込みは何も変えません。
+
+**ジョブごとに一つのプロセスであり、ジョブごとに一つのコンテナーではありません。** AWX と AAP は、ジョブごとに実行環境のイメージから新しい Pod またはコンテナーを
+起動します。AnsibleForms は何も起動しません。RTE のコンテナーはすでに動作しており、各ジョブはその中の子プロセスです。ジョブは
+イメージのプルも Pod のスケジューリングもなしに始まり、AnsibleForms にはコンテナーエンジンやクラスターに対する権限は不要です。その代わり、
+一つの RTE で動作するプレイブックは、その CPU、メモリ、 `/tmp` 、ホームフォルダー、python を共有します。フォークを含めた
+`RTE_MAX_JOBS` 個のプレイブックに十分なリソースをコンテナーに与えてください。プレイブックが使えるものを変えるには、ジョブではなくイメージを変更します。
+
+---
+
+## セキュリティの境界
+
+RTE はフォームの作成者が書いたコードを実行するので、保持するものをできるだけ少なくするように作られています。
+
+* **トークンだけ** ：RTE はデータベースの認証情報も `ENCRYPTION_SECRET` も持ちません。トークン付きのアプリのソケット以外からの呼び出しは受けず、
+  ユーザーもログインも Web ページもありません。ソケットを通じてできるのは、アプリが送ったジョブを実行し、それについて報告し、そのファイルを
+  要求することだけです。ジョブを作成したり、別のジョブを読んだり、認証情報を渡したりすることはできません
+* **封印されたシークレット** ：ジョブを実行するために、RTE は認証情報のテーブルもシークレットストアも読みません。実行するジョブのシークレットを、
+  自分のトークンとそのジョブ ID だけで開けるように封印された状態で受け取るので、別の RTE や別のジョブ向けのバンドルは開けず、1 バイトでも変更されたものは
+  拒否されます
+* **検証された接続** ：アウトバウンドでは、RTE がアプリの証明書を検証します。HTTPS のインバウンドでは、アプリは RTE の参加時にその証明書を固定し、
+  その証明書を提示した場合にだけ接続します（ [モード](modes.html#inbound) を参照）。プレーンな HTTP のインバウンドの RTE は、
+  Docker Compose プロジェクトのようなプライベートネットワークに置くものです
+* **環境を引き継がない** ： `ansible-playbook` は、AnsibleForms 自身が読み込むすべての変数（ `ENCRYPTION_SECRET` 、 `DB_PASSWORD` 、 `RTE_TOKEN` 、
+  `VAULT_TOKEN` 、 `ACCESS_TOKEN_SECRET` 、 `MYSQL_*` など）を除いた RTE の環境を受け取るので、
+  `lookup('env', ...)` でもそれらには届きません。プレイブック向けに設定したもの（ `PATH` 、プロキシ、 `ANSIBLE_*` ）はそのまま渡されます
+* **ユーザーからのテンプレートなし** ： {% raw %}`{{` 、 `{%` 、 `{#` を含むフォームの値は、unsafe な文字列としてプレイブックに届き{% endraw %}、
+  フォームが `allowJinjaInExtravars` を設定しない限り ansible がテンプレートとして処理することはありません。また、コマンドラインをシェルが実行することもありません
+* **root ではない** ：RTE とそのプレイブックは `node` （uid 1000）で実行されるので、プレイブックにできるのは、そのファイルや ssh キーを読むなど、
+  コンテナー内でそのユーザーにできることだけです
+
+そのコンテナー、イメージ、環境は、アプリのものと同じように慎重に扱ってください。
+
+---
+
+## データベースモード（非推奨）
+
+`RTE_MODE` のない 7.0 から 7.2 の RTE は 7.x の間ずっと動作し、8.0.0 で削除されます。上の手順とは四つの点で異なります。
+
+* **データベースを持つ** ：その `DB_*` 設定と、自分自身を登録する場合は `ENCRYPTION_SECRET`
+  （ [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) ）
+* **引き渡しが HTTP の呼び出し** ：アプリがトークンと封印されたシークレットを付けて `POST <address>/rte/v1/jobs` を呼び出し、RTE は
+  データベースのジョブに自分の名前を書き込んで受け取ります（手順 3 と 4）
+* **出力を自分で書き込む** ：データベースに、バッチで、スプールなしで書き込みます（手順 7）。中止は、2 秒ごとに読み込むジョブの中止フラグと、
+  `/cancel` の呼び出しで届きます
+* **ファイルをアプリのボリュームから読む** ： `RTE_FILES=local` の場合と同じく、アプリと同じディスクが必要です
+
+そのランナーのページには [RTE の設定](../runners/runner-page.html#an-rtes-settings) は一つもありません。自分の変数を読み込むためです。ソケットモードに
+移すには、 [モード](modes.html#database-deprecated) を参照してください。
diff --git a/i18n/ja/_configure/rte/modes.md b/i18n/ja/_configure/rte/modes.md
new file mode 100644
index 0000000..b6cdf1f
--- /dev/null
+++ b/i18n/ja/_configure/rte/modes.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: モード
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# RTE とアプリの通信方法
+{: .no_toc }
+
+アウトバウンド、インバウンド、データベース：誰が接続を開き、何がそこを流れるか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。7.3.0 からは、RTE は一本の WebSocket でアプリと通信し、データベースの認証情報は持ちません。両者の間のネットワークに
+合ったモードを選んでください。誰が誰に接続を開いてよいか、どのプロキシやファイアウォールを通るかで決まります。
+
+---
+
+## 三つのモード
+
+RTE の [`RTE_MODE`](../customization/server.html#env_RTE_MODE) は、RTE がアプリに到達する方法を示します。そのランナーにも同じ **モード** があります。
+
+| モード | 接続を開く側 | RTE が保持するもの | 用途 |
+|---|---|---|---|
+| `outbound` | RTE が [`APP_URL`](../customization/server.html#env_APP_URL) のアプリに接続し、WebSocket を一本開いたままにします | 自分の `RTE_TOKEN` 。データベースの認証情報はなし | DMZ、NAT、または着信接続を許可しないゾーン。外部から RTE に届くものは何もありません |
+| `inbound` | アプリがランナーのアドレスの RTE に接続し、WebSocket を一本開いたままにします | 自分の `RTE_TOKEN` 。データベースの認証情報はなし | 中央側がすべての接続を開くネットワーク、compose プロジェクト、Pod |
+| `database` （非推奨） | アプリが HTTP で RTE の API を呼び出し、RTE はアプリのデータベースを自分で読み書きします | データベースの認証情報（ `DB_*` ）と `ENCRYPTION_SECRET` | 7.0 から 7.2 の動作。8.0.0 で削除されます |
+
+`RTE_MODE` のない RTE は 7.x の間ずっとデータベースモードで動作し、起動時に `[DEPRECATED] This RTE runs in database mode` の警告を
+ログに記録します。7.3.0 より前に追加したランナーのモードは **データベース (非推奨)** です。移行するときは、その RTE が動作するモードに設定してください。
+
+---
+
+## アウトバウンド
+
+RTE が接続を開くので、着信接続をまったく受け付けないネットワークからでも動作します。
+
+* **ソケット** ：RTE は、 `APP_URL` に `/api/v2/rte/socket` を付けたアドレスに、 `wss://` （ `http://` のアドレスでは `ws://` ）で、
+  自分の `RTE_TOKEN` とランナーの名前 [`RTE_NAME`](../customization/server.html#env_RTE_NAME) を付けて接続します。ソケットが切れると再接続します
+* **初回** ：参加を申請し、そのランナーは **接続 > ランナー** で、接続はしているもののジョブのない状態で管理者の承認を待ちます
+  （ [参加の申請](../runners/registration.html#asking-to-join) を参照）。参加トークン
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) があればすぐに承認されます。以降は自分のトークンでサインインします
+* **ネットワーク** ：RTE のゾーンからアプリへ、アプリのポートでのみ通信します。 `HTTPS_PROXY` の指定があればプロキシを経由します。アプリの前にある
+  リバースプロキシは、そのパスで WebSocket を通す必要があります（ [ランナーの WebSocket](../production/reverse-proxy.html#runner-websockets) を参照）
+* **証明書** ：アプリの証明書が検証されます。プライベート CA は `NODE_EXTRA_CA_CERTS` で指定するか、信頼できる一つのネットワークの中でだけ
+  [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) で検証をオフにします
+* **ランナー** ：アドレスは不要なので、RTE 認証情報はトークンだけを保持します
+* **準備完了** ：アプリへのソケットが開くまで、 `/ready` は `503` を返します
+
+ロードバランサーの背後に複数のアプリノードがある場合、RTE が到達したノードがそのソケットを持ちます。どのノードでもジョブを起動でき、
+ソケットを持つノードが RTE にジョブを送ります。ジョブが別のノードで起動された場合は 2 秒以内に送ります。
+
+---
+
+## インバウンド
+
+RTE は自分の `PORT` で待ち受け、アプリはランナーのアドレスに `/rte/v1/socket` を付け、RTE のトークンを使って接続します。
+複数のアプリノードがある場合、各インバウンドランナーのソケットを持つのは一度に一つのノードです。そのノードが停止すると、別のノードが引き継いで接続し直します。
+
+アプリが RTE に接続するには、先にその RTE のランナーが必要です。種類は RTE、モードは **インバウンド** で、RTE のアドレスとその
+`RTE_TOKEN` を持つ RTE 認証情報を使います。ランナーは次の二つの方法のいずれかで用意されます。
+
+| 方法 | 設定するもの |
+|---|---|
+| RTE が参加を申請する | `APP_URL` と [`RTE_URL`](../customization/server.html#env_RTE_URL) （アプリが接続するアドレス）。RTE は `POST /api/v2/rte/register` を一度だけ呼び出し、そのランナーは管理者の承認を待ちます。承認されるとアプリが接続します（ [参加の申請](../runners/registration.html#asking-to-join) を参照）。 `RTE_JOIN_TOKEN` があればすぐに承認されます。 `APP_URL` があって `RTE_URL` がないインバウンドの RTE は起動を拒否します |
+| 自分でランナーを追加する | `APP_URL` は不要です。 [RTE の実行](run.html#start-it) にあるように、 **接続 > ランナー** または [構成シード](../seed/) でランナーを追加します |
+
+Docker Compose プロジェクト、Helm チャート、インストーラーのコントローラーは、この方法で、シードで宣言したインバウンドの独自の RTE を実行します。
+
+**HTTPS の場合。** [`HTTPS=1`](../customization/server.html#env_HTTPS) では、RTE は [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) と
+[`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) のキーと証明書（既定では `certificates` フォルダーの `key.pem` と `cert.pem` ）を使い、
+TLS でソケットを提供します。 `https://` の `RTE_URL` を持つ RTE は参加を申請するときにその証明書を送り、アプリはそれを固定します。
+同じ証明書を提示した場合にだけ RTE に接続するので、自己署名証明書でも CA なしで動作します。
+RTE は起動時に証明書のフィンガープリント（DER バイトの SHA-256 の先頭 16 進数 8 桁を `abcd-ef12` の形式で）をログに記録し、
+承認ダイアログにはアプリが受け取ったものが表示されます。承認する前に一致していることを確認してください。
+[インストーラー](../installation/installer.html#a-runner) は、自分のアドレスの証明書を使って、この方法でインバウンドのランナーを構成します。
+
+---
+
+## データベース（非推奨）
+
+7.0 から 7.2 の RTE です。アプリが HTTP でその API を呼び出し、RTE はデータベースでジョブを受け取り、そこに出力を書き込み、
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) で自分のランナーの行を最新に保ちます。手順の違いは [データベースモード](./#database-mode-deprecated)
+で説明しています。7.x では起動のたびに警告を出しつつ引き続き動作し、8.0.0 で削除されます。
+
+こうした RTE をソケットモードに移すには、ランナーとトークンはそのままにします。
+
+1. [構成シード](../seed/) のランナーの場合：まずシードでそのランナーに `rte_mode: outbound` または `rte_mode: inbound` を設定します（インバウンドの場合は、
+   認証情報の `url` にアプリが接続するアドレスを指定します）。シードで管理されたランナーは RTE が自分で移すことはできません
+2. RTE で、 `APP_URL` とともに `RTE_MODE=outbound` を、または `RTE_MODE=inbound` （一度だけの登録の呼び出しを行うなら `APP_URL` と `RTE_URL` も）を設定し、
+   [`RTE_NAME`](../customization/server.html#env_RTE_NAME) を **接続 > ランナー** でのランナーの名前に設定します。 `RTE_TOKEN` はそのままにします
+3. 環境から `DB_*` と `ENCRYPTION_SECRET` 、そしてデータベースモードだけが読み込む `RTE_REGISTER` を削除し、再起動します
+
+アップグレードした RTE がランナーの名前とランナー自身のトークンでサインインすると、アプリは承認なしにすぐにそのランナーを RTE のモードに移し、
+*Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token* とログに記録します。ランナーはもはや RTE が登録した行ではないので、古いコンテナーが応答しなくなってもワーカーが削除することはありません。
+データベースモードのままの構成シードのランナーは、代わりに *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE* として拒否されます。これに参加トークンは使わないでください。参加
+トークンは、すでに承認されたランナーでは拒否されます。 `APP_URL` のないインバウンドの RTE は呼び出しを行いません。代わりに **接続 > ランナー** でランナーの **モード** を
+**インバウンド** に設定すると、アプリが接続します。 [インストーラー](../installation/installer.html#a-72-runner) は、
+この方法で 7.2 のランナーをアップグレードします。
+
+---
+
+## ソケットを流れるもの
+
+どちらのソケットモードでも、アプリは RTE がかつてデータベースで読み込んでいたものすべてを付けて各ジョブを送り、戻ってきたもの、
+つまり出力、イベント、ジョブログ、終了を、ちょうど一度だけ保存します。終了の通知もアプリが送ります。
+
+**スプール。** 出力のバッチ、イベントのバッチ、ログ、開始、終了はそれぞれ番号が付けられ、送信前にジョブのスプールファイル
+（ [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) ）に書き込まれ、アプリが保存したと応答するまで保持されます。
+同じアプリノードまたは別のノードに再接続した後、RTE は確認応答されていないものを再送し、アプリはすでに保存したものを
+飛ばします。何も失われず、二重に保存されることもありません。再起動した RTE が届けていなかったものを送れるよう、スプールはボリューム上に置いてください。
+RTE の再起動時に実行中だったプレイブックは続行できず、そのジョブは放棄されたものとして終了します。
+
+**容量。** RTE は最大 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 個、またはその [ランナーのページ](../runners/runner-page.html#an-rtes-settings) で
+設定した数のプレイブックを同時に実行し、実行中の数を 20 秒ごとにアプリに伝えます。満杯の RTE へのジョブは、
+[複数の RTE](several.html#several-jobs-on-one-rte) で説明しているように待機します。
+
+**ジョブのファイル。** [`RTE_FILES`](../customization/server.html#env_RTE_FILES) 、またはランナーのページの **ジョブファイル** 設定は、
+RTE がプレイブックとインベントリをどこから取得するかを示します。
+
+| `RTE_FILES` | ファイルの取得元 |
+|---|---|
+| `transfer` （既定） | アプリがプレイブックのフォルダーとインベントリをジョブとともに送ります。それぞれパックされ、内容のハッシュで名前が付けられます。RTE はそれらをパックしたまま [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) の下に、最近使ったものから [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) （既定は 1024 MB）まで保持し、持っていないハッシュだけを要求します。変更されていないフォルダーが二度送られることはありません。RTE に共有ディスクもリポジトリへのアクセスも不要です |
+| `local` | データベースモードの RTE と同じく、RTE は自分のフォルダーから実行します。プレイブック（ [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) ）とリポジトリ（ [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) ）をマウントしてください |
+
+`transfer` では、各ジョブはファイルを専用のプライベートなフォルダーに展開し、ジョブが終わると削除されます。どのジョブもほかのジョブが書いたものを見ることはなく、
+インベントリや extravars のファイルが RTE のディスクに展開されたまま残ることもありません。RTE は一つの `RTE_CACHE_PATH` を共有できます。それぞれが
+自分のジョブを専用のフォルダーに保持し、停止した RTE（ジョブの途中で強制終了された、または別のホスト名で再作成された）のフォルダーは、10 分後にほかの RTE が削除します。
+[`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) （既定は 512。アプリが読み込み、再起動なしで反映されます）より大きいフォルダーは
+送られません。ジョブは失敗し、代わりに RTE にフォルダーをマウントするよう示します。ssh フォルダーは決して送られません。RTE は自分の
+秘密鍵と `known_hosts` を `/home/node/.ssh` に保持します。
+
+**ホストとタスク。** 7.3.0 からは、どのモードの RTE も、プレイブックの構造化されたイベントをテキスト出力と並べて記録します。各プレイ、タスク、
+ホストの結果、そしてリキャップで、 `af_events` コールバックプラグインが書き込みます。ジョブページでは **ホストとタスク** に表示されます（
+[ジョブの追跡](../jobs/following.html#hosts-and-tasks) を参照）。
+
+---
+
+## ネットワーク
+
+アプリ、RTE、管理対象のホストの間で開くべきもの（モード別）：
+
+| モード | 送信元 | 宛先 | ポート |
+|---|---|---|---|
+| アウトバウンド | RTE | `APP_URL` のアプリ | アプリのポート（多くのプロキシの背後では `443` ） |
+| インバウンド | アプリノード | ランナーのアドレスの RTE | RTE の `PORT` （ `8000` ） |
+| データベース（非推奨） | RTE、およびアプリノードとワーカー | データベース、および RTE | `3306` と RTE の `PORT` |
+| すべてのモード | RTE | 管理対象のホスト | ssh（ `22` ）、WinRM、それらの API |
+
+ソケットモードでは、RTE がデータベースに接続することはありません。その API が応答するのはソケットとプローブ（ `/live` 、 `/ready` 、 `/metrics` ）だけです。
diff --git a/i18n/ja/_configure/rte/run.md b/i18n/ja/_configure/rte/run.md
new file mode 100644
index 0000000..bfce0e1
--- /dev/null
+++ b/i18n/ja/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: RTE の実行
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# RTE の実行
+{: .no_toc }
+
+各モードの設定と、RTE の起動方法
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 設定
+
+RTE に必要なものはモードによって異なります（ [モード](modes.html) を参照）。すべての RTE が次のものを読み込みます。
+
+| 変数 | 意味 |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | 7.3.0 から： `outbound` （アプリに接続する）、 `inbound` （アプリが接続してくる）、 `database` （非推奨。7.x の間の既定） |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | アプリと RTE の間のトークン。16 文字以上。これがないと RTE は起動を拒否します |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | 同時に実行するプレイブックの数。既定は `10` （ `0` で無制限）。満杯の RTE へのジョブは、プレイブックが終わるまで待機します |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | 停止時に実行中のプレイブックを待つ時間。既定は `25` 。その時点でまだ実行中のものは放棄されたものとして終了します |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | RTE ではなく、アプリノードとワーカーが読み込みます。満杯または停止中の RTE をジョブが待つ時間。既定は `60` |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) 、 `PROCESS_MAX_BUFFER` | プレイブックのフォルダーと出力の上限。RTE が読み込むので、RTE の環境で設定してください |
+| `LISTEN_HOST` | 7.3.0 から：リスナーがバインドするアドレス。既定ではすべてのインターフェース。外部から何も接続してこない場合（アウトバウンドの RTE）は `127.0.0.1` |
+
+ソケットモード（ `outbound` または `inbound` ）の RTE は、さらに次のものを読み込み、 `DB_*` と `ENCRYPTION_SECRET` は読み込みません。
+
+| 変数 | 意味 |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | 利用者が開くアプリのアドレス。例： `https://forms.example.com` 。アウトバウンド：接続先のアドレス。インバウンド：一度だけの登録の呼び出し先のアドレス |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` （既定）：アプリの証明書が有効である必要があります。 `0` は何でも受け入れます。信頼できる一つのネットワークの中でだけ使います |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | ランナーの名前で、フォームは `runner:` でこれを指定します。未設定の場合はノード ID `rte-<hostname>-<port>` で、コンテナーとともに変わります。本番環境では設定してください |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | 任意。初回のみ：API で作成する参加トークン。管理者を待たずにすぐにランナーを承認します（ [参加トークン](../runners/registration.html#join-tokens) を参照） |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | インバウンドで参加を申請する場合：アプリが接続するアドレス。例： `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` （既定）：アプリがプレイブックとインベントリをジョブとともに送ります。 `local` ：マウントした自分のフォルダーから実行します |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | 各ジョブの出力、イベント、終了が、アプリが保存するまで待機する場所。既定は `<persistent>/rte-spool` 。ボリューム上に置いてください |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | `transfer` の場合：アプリが送ったフォルダーを保持する場所。既定は `<persistent>/rte-files` |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | `transfer` の場合：それらのフォルダーが使える容量。既定は `1024` 。最も長く使われていないものから削除され、 `0` では何も保持しません |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | RTE ではなくアプリが読み込みます： `transfer` で送る最大のフォルダー。既定は `512` |
+
+ソケットモードの RTE では、 `RTE_MAX_JOBS` 、 `RTE_DRAIN_SECONDS` 、 `RTE_FILES` 、 `RTE_CACHE_MB` をランナーのページの
+RTE タブでも設定できます。そこでの値が変数より優先され、変数は空のままのフィールドを埋めるだけになります（
+[RTE の設定](../runners/runner-page.html#an-rtes-settings) を参照）。範囲外の値は上限または下限に合わせられ、RTE は起動時に
+その旨を伝えます。
+
+データベースモード（非推奨）の RTE は、代わりにデータベースの設定を読み込み、自分自身を登録します。
+
+| 変数 | 意味 |
+|---|---|
+| `DB_HOST` 、 `DB_PORT` 、 `DB_USER` 、 `DB_PASSWORD` | アプリと同じ値。RTE はデータベースからジョブを読み込み、そこに出力を書き込みます |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | アプリが RTE を呼び出すアドレス。例： `http://rte:8000` 。ランナーはホスト名（ `rte` ）にちなんで名前が付くので、フォームでは `runner: rte` を使えます |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | 7.3.0 でデータベースモードとともに非推奨になりました。ソケットモードの RTE は代わりに参加トークンで参加します。 `1` （既定）：RTE は起動時に **接続 > ランナー** に自分自身を追加し、最初のものが既定のランナーになります。 `0` ：そこで、または [構成シード](../seed/) で自分で追加します |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | アプリと同じ値。自分自身を登録する場合にだけ必要です（ランナーのトークンは暗号化して保存されます）。 `RTE_REGISTER=0` では省きます |
+
+データベースモードで `RTE_URL` がない場合、RTE は自分の IP アドレスとポートを `rte-<hostname>-<port>` という名前で登録しますが、これはコンテナーを
+再作成すると変わります。本番環境では `RTE_URL` を設定してください。RTE が自分で登録したランナーは、RTE の最後のハートビートから 10 分後に
+ワーカーが削除します。
+
+---
+
+## 起動
+
+RTE はプレイブックを実行するので、プレイブックが使う秘密鍵と `known_hosts` を含む ssh フォルダーと、スプールとアプリが送るファイルのための
+永続フォルダーが必要です。モードを選んでください。
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">アウトバウンド</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">インバウンド</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">データベース (非推奨)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+アプリに到達できる任意のホストで、独自のトークンとランナーに付ける名前を指定して RTE を起動します。
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+RTE はアプリに接続して参加を申請します。 **接続 > ランナー** にはランナー `rte-dmz` が承認待ちとして表示され、そのログには
+トークンのフィンガープリントが表示されます。確認画面に同じフィンガープリントが表示されていることを確かめてから **承認** します（
+[RTE の承認](../runners/registration.html#approving-an-rte) を参照）。以降は自分の `RTE_TOKEN` でサインインしてジョブを受け取ります。
+無人で起動するには `-e RTE_JOIN_TOKEN=<a join token, afj_...>` を追加すると、すぐに承認されます。このホストに到達する必要のあるものは
+何もないので、ポートは公開しません。その `PORT` で待ち受けるのは、プローブ用の `/live` 、 `/ready` 、 `/metrics` だけです。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+アプリが到達できる場所で RTE を起動します。この例ではアプリの隣で動作し、そのフォルダーからプレイブックを実行します（ `RTE_FILES=local` ）。
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+次に、アプリにランナーを与えます。 [構成シード](../seed/) で、RTE 認証情報と、それを使ってサインインするインバウンドのランナーを宣言します。
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+または、同じ二つを手動で追加します。認証情報は **接続 > 認証情報** で種類 RTE として、ランナーは
+**接続 > ランナー** で種類 RTE、モード **インバウンド** として、その認証情報を指定します。代わりに RTE に参加を申請させるには、
+`APP_URL` と `RTE_URL` を指定して起動し、 **接続 > ランナー** で承認します（ [インバウンド](modes.html#inbound) を参照）。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+7.3.0 から非推奨で、8.0.0 で削除されます。RTE は自分のディスクからプレイブックを実行するので、アプリの永続ボリューム
+（プレイブック、リポジトリ、アップロード）と ssh フォルダーもマウントします。同じネットワーク上でアプリに `ansibleforms` として到達できる
+Docker の例：
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+インバウンドの RTE は公開ネットワークに置かないでください。そのソケットは、トークンを持つどの呼び出し元にも応答します。 `docker stop` はコンテナーを強制終了するまで
+10 秒しか待たないので、RTE にはより長い停止タイムアウト（ `--stop-timeout` 、compose では `stop_grace_period` ）を与えるか、
+`RTE_DRAIN_SECONDS` を下げてください。Kubernetes は既定で 30 秒待ちます。
+
+[インストーラー](../installation/installer.html) は、専用のサーバー上で Docker、Podman、または
+[コンテナーを使わずに](../installation/native.html) アウトバウンドまたはインバウンドの RTE を構成し、承認に使うフィンガープリントを表示します。別のデータセンターで
+RTE を手動で実行するには、 [別のデータセンター](another-datacenter.html) に従ってください。
diff --git a/i18n/ja/_configure/rte/several.md b/i18n/ja/_configure/rte/several.md
new file mode 100644
index 0000000..786dd5e
--- /dev/null
+++ b/i18n/ja/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: 複数の RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# 複数の RTE
+{: .no_toc }
+
+一つの RTE が実行するプレイブックの数、ランナーまたはレプリカとしての RTE の追加、RTE が停止または異常終了したときに起きること
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 一つの RTE での複数のジョブ
+
+一つの RTE は最大 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 個のプレイブックを並べて実行します。既定は 10
+（ `0` で無制限）です。満杯の RTE へのジョブは受け取られません。ソケットモードでは、RTE の最後のヘルスレポートに空きがない間はアプリがジョブを送らず、
+満杯または停止中の RTE は busy として `refused` を返します。データベースモードでは RTE は `503` を返します。
+どちらの場合も、アプリは出力に `Waiting for a free slot on RTE <name>` を一度書き込み、最大 [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+（既定は 60）の間、10 秒ごとにジョブを再提示します。その後、ジョブは
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)* で失敗します。待機中に中止されたジョブは、
+RTE に届くことなく `aborted` で終了します。
+
+---
+
+## 複数の RTE
+
+アプリはジョブを自動でランナーに分散しません。すべてのジョブは一つのランナー、つまりフォームが指定したランナーか
+既定のランナーに送られます。RTE のコンテナーを増やすことは、二つの点で役立ちます。
+
+* **独自のランナーとして** ：各 RTE は独自の `RTE_NAME` を持ち、独自のランナーとして参加します。参加を申請して管理者が
+  承認するか、参加トークンを提示します（ [登録](../runners/registration.html) を参照）。フォームは `runner: <name>` でその一つを選びます。
+  たとえば VMware のコレクションを持つ RTE や、別のネットワークゾーンにある RTE です。それ以外は既定の RTE で実行されます
+* **一つのアドレスの背後のレプリカとして** （データベースモードのみ）：Kubernetes の Service の背後にある Pod のように、同じ `RTE_URL` と同じ `RTE_TOKEN` を持つ
+  複数の RTE コンテナーが一つのランナーを共有し、アドレスが呼び出しをそれらに分散します。満杯のレプリカは
+  `503` を返し、次の試行は別のレプリカに届くことがあります。アプリはデータベースを通じてジョブを追跡するので、ステータスの呼び出しにどのレプリカが
+  応答しても問題ありません
+
+ソケットモード（ [モード](modes.html) を参照）では、一つのランナーは一つの RTE へのソケットを一本持ち、同じ
+`RTE_NAME` でサインインした 2 つ目の RTE は 1 つ目からソケットを引き継ぎます。各 RTE に独自の名前とランナーを与え、フォームが
+`runner:` でそれらの中から選べるようにしてください。
+
+データベースモードの RTE はそれぞれ 10 秒ごとにデータベースにハートビートを書き込み、自分自身を登録する RTE は 30 秒ごとに自分のランナーの行を
+確認します。ソケットモードの RTE では、そのソケットを持つアプリノードが、ソケットが開いている間、20 秒ごとに代わりにハートビートを書き込みます。
+**ステータス** ページには、すべての RTE がバージョンとともに表示されます。データベースモードの RTE が自分で登録したランナーは、
+その RTE が 10 分間ハートビートを書き込まなかった時点でワーカーが削除します。既定のランナーがそうした行で、その RTE が停止していた場合は、
+次に確認した RTE が既定を引き継ぎます。構成シードのランナー、手動で追加したランナー、ソケットで参加したランナーが、この方法で削除されることはありません。
+
+---
+
+## RTE が停止または異常終了したとき
+
+**RTE が停止したとき。** `SIGTERM` （ `docker stop` 、ローリングアップデート、スケールダウン）を受けると、RTE はジョブの受け取りをやめます。 `/ready` は `503` を返し、
+新しいジョブは busy として拒否される（データベースモードでは `503` ）ので、アプリは待機します。データベースモードでは、アドレスが別の
+レプリカにジョブを送ります。実行中のプレイブックには、終わるまでの時間として [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) （既定は 25）が与えられ、
+その後 RTE は終了します。
+
+**RTE が異常終了したとき。** 強制終了されたコンテナー（メモリ不足、ノードの喪失、停止タイムアウトの終了）は、プレイブックを道連れにします。それらを
+別の RTE に移すものも、再実行するものもありません。そのジョブは `abandoned` として終了します。終了させるのは RTE 自身、
+再起動したコンテナーが保持する同じ ID（ `rte-<hostname>-<port>` ）で RTE が戻ってきたときのアプリ、または RTE のハートビートが
+2 分経過した時点でのワーカーです。再び起動する前に、プレイブックが何をしたかを管理対象のホストで確認してください。
+
+**RTE が停止している間。** ソケットモードでは、その RTE への新しいジョブは、最大 `RTE_QUEUE_MINUTES` とさらに 1 分の間ソケットを待ち、その後
+*no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* で失敗します。
+データベースモードでは、別のレプリカがそのアドレスで応答しない限り、すぐに *the RTE at ... is unreachable* で失敗します。
diff --git a/i18n/ja/_configure/runners.md b/i18n/ja/_configure/runners.md
new file mode 100644
index 0000000..3ddb980
--- /dev/null
+++ b/i18n/ja/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: ランナー
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# ランナー
+{: .no_toc }
+
+ジョブの実行場所：プレイブック用のランタイム環境コンテナーと、テンプレート用の AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。ジョブを実行するランナーを追加し、種類ごとの既定を選び、参加を申請した RTE を承認し、テストします。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [ランナーページ](runners/list.html) | ランナーのリスト、追加、オン／オフ、種類ごとの既定 |
+| [ランナーの種類](runners/types.html) | ランナーになれる製品、そのアドレスとログイン |
+| [登録](runners/registration.html) | RTE が参加を申請して承認される仕組み、無人インストール用の参加トークン、データベースモード |
+| [ランナーのページ](runners/runner-page.html) | ランナーのタブ、RTE のモードと接続、接続テスト |
+| [ランナーを管理できるユーザー](runners/permissions.html) | ランナーを追加、変更、テストできるユーザー |
+
+
+---
+
+## 仕組み
+
+バージョン 7 から、アプリ自身は何も実行しません。すべてのジョブは **接続 > ランナー** で追加した **ランナー** で実行されます。
+フォームの種類によって、必要なランナーの種類が決まります。
+
+| フォームの種類 | 実行するランナーの種類 | 実行されるもの |
+|---|---|---|
+| `ansible` | RTE | ランタイム環境のコンテナー内のプレイブック |
+| `awx` 、 `aap` 、 `ascender` | AWX（AWX、AAP、Ascender の各フレーバー） | ジョブテンプレートまたはワークフローテンプレート |
+| `semaphore` | Semaphore | Semaphore UI のテンプレート |
+| `rundeck` | Rundeck | Rundeck のジョブ |
+| `jenkins` | Jenkins | Jenkins のジョブ |
+
+`workflow` または `subform` のフォームには独自のランナーがありません。 [ワークフロー](workflows/) の各ノードがそれぞれ選びます。
+`runner:` のあるノードはそのランナー（RTE、または AWX、Semaphore、Rundeck、Jenkins のテンプレートやジョブ）で、それ以外のノードは
+既定の RTE で実行されるので、一つのジョブのノードが異なるランナーで実行されることもあります。バージョン 7 から非推奨でワークフローに置き換えられた
+`multistep` フォームも同じように動作し、各ステップはその種類が必要とするランナーで実行されます。
+
+フォームは次の二つの方法のいずれかでランナーを選びます。
+
+- **名前で** ：フォーム、ワークフローのノード、または非推奨のマルチステップのステップに `runner: <name>` を指定します（デザイナーの
+  フォーム設定でも指定できます）。ランナーはフォームが必要とする種類でなければならず、そうでないとジョブは失敗します。古い `awx: <name>`
+  も引き続き使えますが、非推奨の警告がログに記録され、8 で削除されます。
+- **既定として** ：ランナーを指定していないフォームは、その種類の既定のランナーで実行されます。既定のランナーがない場合、ジョブは
+  追加すべきランナーの種類を示すメッセージとともに失敗します。
+
+**接続 > ランナー** でオフにしたランナーは、名前でも既定としてもジョブを受け取りません。ジョブは失敗し、有効にするか
+別のランナーを指定するよう示します（ [既定と有効](runners/list.html#default-and-enabled) を参照）。
+
diff --git a/i18n/ja/_configure/runners/list.md b/i18n/ja/_configure/runners/list.md
new file mode 100644
index 0000000..c489bcf
--- /dev/null
+++ b/i18n/ja/_configure/runners/list.md
@@ -0,0 +1,69 @@
+---
+layout: default
+title: ランナーページ
+parent: ランナー
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# ランナーページ
+{: .no_toc }
+
+ランナーのリスト、追加、オン／オフ、種類ごとの既定
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## リスト
+
+**接続 > ランナー** のページには、すべてのランナーが次の列とともに表示されます。
+
+| 列 | 意味 |
+|---|---|
+| 有効 | ジョブを受け取るかどうか。オフのランナーは、その種類の既定であってもジョブを受け取りません。 |
+| 名前 | フォームが `runner: <name>` で参照する名前。 |
+| 種類 | RTE、AWX、Ansible Automation Platform、Ascender、Semaphore UI、Rundeck、Jenkins のいずれか。その種類の既定のランナーには、後ろに **既定** のピルが表示されます。 |
+| 説明 | 用途。 |
+
+**列** では、既定でオフの列を二つ追加できます。 **モード** は RTE のモード（アウトバウンド、インバウンド、データベース (非推奨)。
+[モード](../rte/modes.html) を参照）、 **接続** はソケットモードの RTE へのソケットをアプリノードが持っているかどうかで、 **接続済み** または
+**未接続** です。
+
+7.3.0 からは、承認待ちのランナーはリストではなく、その上の通知に表示されます。 [RTE の承認](registration.html#approving-an-rte) を参照してください。
+**ランナーを追加** を押すと、ステップ形式のダイアログが開きます。 **ランナー** （名前と説明）、 **種類** 、 **認証情報** で、RTE の場合は **種類** の後に
+**モード** のステップ（アウトバウンド（新規の既定）、インバウンド、データベース (非推奨)）があります。RTE では 4 ステップ、ほかの種類では
+3 ステップです。 **種類** のステップでは各製品にヒントがあり、RTE のヒントには正式名称 *実行環境* が示されます。行をクリックするとランナーの
+ページが開き、行メニューには次のものがあります。
+
+| 操作 | 動作 |
+|---|---|
+| 編集 | そのページを開きます |
+| 接続テスト | 応答し、認証情報を受け入れるかを確認します。 [接続テスト](runner-page.html#test-connection) を参照 |
+| 有効にする、無効にする | 現在の状態の逆にオン／オフします |
+| 資格情報を変更 | そのページの認証情報タブを開きます |
+| 削除 | 削除します |
+
+---
+
+## 既定と有効
+
+各種類の既定は、その種類のフォームがランナーを指定していないときに実行される場所です。
+
+| 既定の対象 | ランナーを指定していない場合にこれらのフォームが実行される場所 |
+|---|---|
+| Playbook のフォーム | `ansible` フォーム。RTE で実行 |
+| AWX・AAP・Ascender のフォーム | `awx` 、 `aap` 、 `ascender` フォーム。AWX ランナーで実行 |
+| Semaphore のフォーム | `semaphore` フォーム |
+| Rundeck のフォーム | `rundeck` フォーム |
+| Jenkins のフォーム | `jenkins` フォーム |
+
+ある種類の最初のランナーがその種類の既定になるので、種類ごとにランナーが一つだけなら追加の手順は不要です。別のランナーを既定にするには、
+そのページの **既定** スイッチをオンにします（ [ランナーのページ](runner-page.html) を参照）。
+
+オフにしたランナーは設定とともにリストに残りますが、その種類の既定であってもジョブは送られません。そのランナー向けのジョブは
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;* で失敗します。
+行メニューの **有効にする** または **無効にする** 、あるいはそのページの **有効** スイッチでオン／オフします。新しいランナーはオンで、
+7.3.0 より前からあるランナーもアップグレード後はオンです。 [構成シード](../seed/example.html) では `enabled: false` でオフにできます。
diff --git a/i18n/ja/_configure/runners/permissions.md b/i18n/ja/_configure/runners/permissions.md
new file mode 100644
index 0000000..853b058
--- /dev/null
+++ b/i18n/ja/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: ランナーを管理できるユーザー
+parent: ランナー
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# ランナーを管理できるユーザー
+{: .no_toc }
+
+ランナーを追加、変更、テストできるユーザー
+{: .fs-6 .fw-300 }
+
+ランナーは実行するすべてのジョブの認証情報を受け取るので、ランナーの追加、変更、オン／オフ、削除、そして参加を申請した RTE の承認と拒否は、
+**admin** ロールだけが行えます。設定にアクセスできるユーザーはランナーを表示してテストできますが、変更はできません。
+
+[構成シード](../seed/) で宣言されたランナーは、このページでは読み取り専用です。代わりにシードファイルで変更してください。
diff --git a/i18n/ja/_configure/runners/registration.md b/i18n/ja/_configure/runners/registration.md
new file mode 100644
index 0000000..005db00
--- /dev/null
+++ b/i18n/ja/_configure/runners/registration.md
@@ -0,0 +1,122 @@
+---
+layout: default
+title: 登録
+parent: ランナー
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# 登録
+{: .no_toc }
+
+RTE が参加を申請して承認される仕組み、無人インストール用の参加トークン、データベースモード
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 参加の申請
+
+7.3.0 からは、アプリがまだ知らないソケットモード（ `outbound` または `inbound` ）の RTE は参加を申請し、管理者がそれを承認します。
+RTE は自分の `RTE_TOKEN` と `RTE_NAME` を付けて連絡してきます。アウトバウンドの RTE は最初にアプリに接続したとき、インバウンドの RTE は一度だけの
+登録の呼び出しで連絡します。参加トークンがない場合、アプリは次のことを行います。
+
+1. RTE の `RTE_TOKEN` を、 `<name>-rte` という名前（その名前が使われている場合は番号が付きます）の種類 RTE の新しい認証情報に保存します。
+   インバウンドの RTE の場合はそのアドレス `RTE_URL` も保存します
+2. `RTE_NAME` にちなんだ名前で、種類 RTE、RTE のモードで、その認証情報でサインインするランナーを追加します。ランナーには **承認待ち** の印が付き、
+   オフになっています。その説明には申請元のホストが示されます
+
+アウトバウンドの RTE は待機中も接続を保ちますが、ジョブは受け取りません。インバウンドの RTE には、承認されるまでアプリは接続しません。どちらも、
+**接続 > ランナー** で管理者の承認を待っていることを、トークンのフィンガープリントとともにログに記録します。
+
+`https://` の `RTE_URL` を持つインバウンドの RTE は、参加を申請するときに証明書も送り、アプリはそれを固定します。以降、アプリは
+その RTE が同じ証明書を提示した場合にだけ接続するので、自己署名証明書でも CA なしで動作します（ [インバウンド](../rte/modes.html#inbound) を参照）。
+
+同時に承認を待てる RTE は最大 20 個です。それを超えると、いくつかが承認または拒否されるまで拒否されます。24 時間以内に誰も処理しなかった申請は、
+認証情報とともにワーカーが削除します。
+
+アプリがすでに知っているランナーの名前を持ちながら別のトークンを持つ RTE は拒否され、参加の申請もしません。そのランナーの
+トークンを RTE に与えるか、ランナーを削除して RTE に参加を申請させてください。 [参加トークン](#join-tokens) が役立つのは、そのランナーがまだ承認待ちの間だけです。
+
+---
+
+## RTE の承認
+
+承認待ちのランナーは **接続 > ランナー** のリストから外れ、その上のオレンジ色の通知（たとえば
+**2 件のランナーが承認を待っています** ）に、ランナーごとに名前、ホスト、IP アドレス、モード、アドレス、フィンガープリントの行とともに表示されます。
+ランナーを表示できるユーザーには、ヘッダーのベルにその数が表示されます（ [ベル](../jobs/#the-jobs-page) を参照）。
+
+通知をクリックすると、ランナーごとに順番に **承認を確認** ダイアログが開きます。名前をクリックすると、そのランナーだけが開きます。
+そのページでは、黄色のボックス **この RTE が参加を求めています** に同じ情報が表示されます。承認する前に、自分が起動したものであることを確認してください。
+
+| フィールド | 表示内容 |
+|---|---|
+| フィンガープリント | `RTE_TOKEN` の SHA-256 の先頭 16 進数 8 桁を `abcd-ef12` の形式で表示したもの。RTE は起動時にこれをログに記録し、 [インストーラー](../installation/installer.html#a-runner) は最後に表示します。同じである必要があります |
+| 証明書のフィンガープリント | ダイアログで、HTTPS のインバウンドの RTE の場合：アプリが固定する証明書（その DER バイト）の SHA-256 の先頭 16 進数 8 桁を `abcd-ef12` の形式で表示したもの。RTE は起動時にこれをログに記録し、 [インストーラー](../installation/installer.html#a-runner) は最後に表示します。同じである必要があります |
+| ホスト | RTE が動作しているホスト |
+| IP アドレス | RTE がアプリに連絡してきたアドレス |
+| モード | アウトバウンドまたはインバウンド |
+| URI | インバウンドの RTE のアドレス。アプリはここに接続します |
+| バージョン | RTE のリリース |
+| 申請日時 | 参加を申請した日時 |
+
+ダイアログまたはそのページのボックスにある **承認** と **拒否** で決めます。
+
+| 操作 | 結果 |
+|---|---|
+| 承認 | ランナーが有効になり、今後ジョブを受け取ります。その種類に既定がない場合は既定になります |
+| 拒否 | ランナーが認証情報とともに削除され、そのソケットは閉じられます。RTE は再び参加を申請でき、その場合は再び承認待ちになります |
+
+RTE を承認または拒否できるのは管理者だけです。
+
+---
+
+## 参加トークン
+
+参加トークンは、無人インストールのために RTE をすぐに承認します。 [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) を指定して
+起動した RTE、またはインストーラーの `--join` でインストールしたランナーは、それを一度提示し、そのランナーは待たずに有効な状態で追加されます。
+参加トークンにはインターフェース上のページがありません。管理者が `/api/v2/runner` の下の [REST API](../api/) で作成します。
+
+| 呼び出し | 動作 |
+|---|---|
+| `POST /api/v2/runner/jointoken` | 参加トークンを作成します。本文にはその `name` と、任意で `expiresInHours` （なし：期限切れにならない）と `maxUses` （なし：RTE の数は無制限）を含めます |
+| `GET /api/v2/runner/jointoken` | 参加トークンを新しい順に、使用回数とまだ使えるかどうかとともに一覧表示します。トークン自体は決して表示されません |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | 失効させます。それ以降ランナーを追加しなくなり、リストには残ります |
+| `DELETE /api/v2/runner/jointoken/<id>` | 削除します |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+応答には `afj_` で始まるトークンがこの一度だけ含まれます。保存されるのはその SHA-256 だけです。それを提示した RTE は、
+[参加を申請する](#asking-to-join) RTE と同じ認証情報とランナーを有効な状態で受け取り、その説明には参加トークンの名前が入ります。以降、
+RTE は自分のトークンでサインインするので、参加トークンが期限切れになったり失効したりしても影響はありません。参加トークンを失効または削除しても、
+それが追加したランナーは残ります。
+
+参加トークンが、承認済みのランナーに新しいトークンを与えることはありません。その名前の RTE ランナーがすでに存在する場合：
+
+| ランナー | 結果 |
+|---|---|
+| 承認待ち | 認証情報に新しいトークンが入り、引き続き管理者の承認を待ちます |
+| 承認済み | `409` で拒否されます： *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections* 。参加トークンは消費されません |
+| [構成シード](../seed/) から来ている | 拒否されます： *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+そのため、新しいトークンで再インストールした RTE は、ランナーの認証情報のトークンでサインインするか、管理者が
+**接続 > 認証情報** でそのトークンを変更するか、ランナーを削除して RTE を新規として参加させます。
+
+---
+
+## データベースモードでの登録
+
+7.3.0 から非推奨のデータベースモードの RTE は、既定で自分自身を、その `RTE_URL` 、なければ自分のアドレスとポートで登録します。
+その RTE が 10 分間ハートビートを書き込まなかった時点で、ワーカーはそのランナーを削除します。手動で、構成シードで、またはソケットモードの
+RTE が追加したランナーが、この方法で削除されることはありません。
+
+この登録をオン／オフにする [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) は、7.3.0 でデータベースモードとともに
+非推奨になりました。ソケットモードの RTE は参加を申請するか、参加トークンで参加します。その間こうしたランナーを自分で管理するには、
+`RTE_REGISTER=0` で RTE を起動し、ここで種類 RTE、モード **データベース (非推奨)** 、そのアドレスと同じトークンを持つ RTE 認証情報で
+追加します。ソケットモードに移すには、 [モード](../rte/modes.html#database-deprecated) を参照してください。
diff --git a/i18n/ja/_configure/runners/runner-page.md b/i18n/ja/_configure/runners/runner-page.md
new file mode 100644
index 0000000..f3e0bca
--- /dev/null
+++ b/i18n/ja/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: ランナーのページ
+parent: ランナー
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# ランナーのページ
+{: .no_toc }
+
+ランナーのタブ、RTE のモード、接続、設定、接続テスト
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## タブ
+
+ランナーのページには、ダイアログのステップがタブとして表示され、さらにそこで実行されるものも表示されます。
+
+| タブ | 内容 |
+|---|---|
+| 詳細 | 名前と説明、 **既定** スイッチと **有効** スイッチ。すべての種類のランナーで共通です |
+| 種類 | ダイアログと同じく製品。RTE の場合はその **モード** も： **データベース (非推奨)** 、 **インバウンド** 、 **アウトバウンド** 。その RTE が実行される `RTE_MODE` です（ [モード](../rte/modes.html) を参照） |
+| RTE | RTE のみ：その **モード** の説明と、ソケットモードの場合はその **接続** と設定（ [RTE の設定](#an-rtes-settings) を参照） |
+| 認証情報 | サインインに使う **認証情報** 。接続 > 認証情報 にある、ランナーの種類の認証情報で、トークンまたはログインとサーバーのアドレスを保持します。RTE の認証情報は `RTE_TOKEN` と、アウトバウンドでなければ RTE のアドレスを保持します。Semaphore、Rundeck、Jenkins では **プロジェクト** もあります |
+| フォーム | そこで実行されるフォームとその方法： **指定** または **デフォルトのランナーとして** 。行をクリックするとフォームが開きます |
+| ジョブ | そこで実行された最新 100 件のジョブと、そのステータス、開始、終了、所要時間。行をクリックするとジョブが開きます |
+
+各タブには `/settings/runners/<id>/rte` のような独自のアドレスがあるので、リンクやブックマークで開けます。そのタブのないランナーは
+詳細タブで開きます。
+
+詳細タブの二つのスイッチはすぐに保存されます。 **既定** はランナーをその種類の既定にします。別のランナーを既定にするとオフになります。
+**有効** はランナーをオン／オフにします。オフにすると、その種類の既定であってもジョブは送られません（
+[既定と有効](list.html#default-and-enabled) を参照）。
+
+参加を申請した RTE は、黄色のボックス **この RTE が参加を求めています** とともに開き、そこにはフィンガープリントと RTE が自分について伝えた内容、
+**承認** と **拒否** があります（ [RTE の承認](registration.html#approving-an-rte) を参照）。 [構成シード](../seed/) のランナーでは、ページの上部に
+その旨が表示され、読み取り専用です。
+
+---
+
+## RTE の設定
+
+RTE タブでは、RTE が動作するマシン上の環境を編集せずに、アプリから RTE を管理します。
+
+**接続。** ソケットモードの RTE にはバッジが表示されます： **接続済み** または **未接続** 。ポインターを重ねると、 **接続済み** ではソケットを持つ
+アプリノード、RTE のリリース、実行中のジョブの数が表示されます。 **未接続** は、どのアプリノードもその RTE へのソケットを持っていないことを意味します。
+RTE が動作しているか、そのアドレスまたは `APP_URL` 、そしてトークンを確認してください。
+
+**設定。** アウトバウンドまたはインバウンドモードの RTE には四つの設定があり、どれも既定では空です。
+
+| 設定 | 対応する変数 | 動作 |
+|---|---|---|
+| 最大同時ジョブ数 | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | 同時に実行するプレイブックの数。既定は `10` 。 `0` で無制限 |
+| ジョブファイルのキャッシュ | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | アプリが送ったジョブのファイルを保持する量（MB）。既定は `1024` 。 `0` では何も保持しません |
+| 停止時の待機時間 | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | 停止中の RTE が実行中のプレイブックを待つ時間。既定は `25` 秒 |
+| ジョブファイル | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **転送** ：アプリがジョブのファイルをジョブとともに送ります。 **ローカル** ：マウントした自分のフォルダーから実行します |
+
+**どちらの値が優先されるか。** ページ上の値は、RTE で設定された同じ変数より優先されます。空のままのフィールドは RTE 自身の変数を、
+なければ既定値を使います。各フィールドの下には、どちらかが表示されます： **RTE で設定された RTE_MAX_JOBS (3) を上書きします。** 、または **空欄: RTE は自身の
+RTE_MAX_JOBS (3) を使います。** 。プレースホルダーには、空のフィールドが表す値が表示されます。
+
+**RTE への届き方。** 設定はランナーとともにアプリのデータベースに保存されます。アプリは RTE が接続したときと保存のたびに、
+RTE のソケットでそれらを送り、RTE はすぐに適用します。キャッシュを小さくすると切り詰められ、新しい上限は次の
+ジョブから数えられます。RTE はそれらをメモリにだけ保持し、ファイルには書き込みません。再起動後は、最初のジョブの前、接続時に再び受け取ります。
+
+データベースモード（非推奨）の RTE にはソケットがないので、これらの設定は自分の変数から読み込みます。タブにはその旨が表示されます。
+
+---
+
+## 接続テスト
+
+右上のボタンは、保存されている状態のランナーに対して動作します。
+
+**保存** の隣には **接続テスト** と **削除** があり、認証情報タブには **認証情報を追加** があります。これはランナーの種類の認証情報を作成し、
+それを選択します。トークンやパスワードは、一度保存すると二度と表示されません。変更は認証情報で行ってください。
+
+**接続テスト** は、ランナーが応答し、トークンまたはログインを受け入れるかを確認し、その結果をメッセージで示します： **Runner connection is
+OK** 、または失敗した理由です。ジョブは実行しません。RTE の場合は、RTE が使っている契約も確認します（
+[契約](../rte/images.html#the-contract) を参照）。
+
+| RTE | テストが読み取るもの | 失敗する場合 |
+|---|---|---|
+| アウトバウンドまたはインバウンド | すべてのアプリノードが記録している、誰がそのソケットを持っているか、そして RTE が接続時に伝えた内容。何も呼び出しません | どのアプリノードもその RTE へのソケットを持っていない場合： *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app* 、インバウンドの場合は *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE* 。または RTE が 3 以外の契約で通信している場合 |
+| データベース（非推奨） | トークンを付けて呼び出した RTE の `/rte/v1/health` | RTE がそのアドレスで応答しない、トークンを拒否する、または 2 以外の契約で通信している場合 |
+
+RTE タブの **接続** バッジには、テストしなくても同じソケットの状態が表示されます。
diff --git a/i18n/ja/_configure/runners/types.md b/i18n/ja/_configure/runners/types.md
new file mode 100644
index 0000000..9d7903c
--- /dev/null
+++ b/i18n/ja/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: ランナーの種類
+parent: ランナー
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# ランナーの種類
+{: .no_toc }
+
+ランナーになれる製品、そのアドレスとログイン
+{: .fs-6 .fw-300 }
+
+**種類** のステップには製品ごとに一つの選択肢があり、それぞれにヒントがあります。RTE のヒントには名前が *実行環境* と書かれています。AAP と
+Ascender は、フレーバー（ `aap` または `ascender` ）を持つ種類 `awx` のランナーとして保存されます。構成シードでもこの形式を使います。
+
+| 種類 | Uri の例 | プロジェクト | 認証 |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | RTE の `RTE_TOKEN` |
+| AAP | `https://aap.example.com/api/controller/v2` | | API トークン、またはユーザーとパスワード |
+| Ascender | `https://ascender.example.com/api/v2` | | API トークン、またはユーザーとパスワード |
+| AWX | `https://awx.example.com/api/v2` | | API トークン、またはユーザーとパスワード |
+| Jenkins | `https://jenkins.example.com` | ジョブがあるフォルダー（任意） | ユーザーとその API トークン |
+| Rundeck | `https://rundeck.example.com` | プロジェクト名 | ユーザーの API トークン |
+| Semaphore | `https://semaphore.example.com` | プロジェクト ID。 `/project/<id>` の数字 | ユーザーの API トークン |
+
+AWX、AAP、Ascender のアドレスには API パスを含めます。 `/api/v2` 、AAP 2.5 以降では `/api/controller/v2` です。
+RTE は `AF_ROLE=rte` で起動した AnsibleForms のイメージで、その実行方法は
+[ランタイム環境](../rte/) で説明しています。
diff --git a/i18n/ja/_configure/secret-stores/cyberark.md b/i18n/ja/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..149dd33
--- /dev/null
+++ b/i18n/ja/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: シークレットストア
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+CyberArk Central Credential Provider（CCP）から認証情報を読み込みます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **試験的。** 実際の CyberArk 環境ではまだテストされていません。結果をぜひお知らせください。
+
+CCP は、CyberArk の Application Access Manager の REST インターフェースです。
+
+---
+
+## ストアのフィールド
+
+[すべてのストアにあるフィールド](./#adding-a-store) に加えて、CyberArk ストアには次のフィールドがあります。
+
+| フィールド | 意味 |
+|---|---|
+| 認証情報 | [接続 > 認証情報](../credentials.html) の **CyberArk** 認証情報。CCP のベース URL（例： `https://ccp.example.com` 。 `/AIMWebService/api/Accounts` が付加されます）、その TLS の設定、AppID（CyberArk で AnsibleForms 用に定義したアプリケーション）、そして AppID が必要とする場合に限り PEM のクライアント証明書とキーを保持します。 |
+
+---
+
+## シークレットの参照
+
+シークレットの参照は、アカウントを `;` 区切りのキーと値の組で特定します。
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- 使えるキー： `Safe` 、 `Folder` 、 `Object` 、 `UserName` 、 `Address` 、 `Database` 、 `PolicyID` 、
+  `Reason` 、 `Query` 、 `QueryFormat` 、 `ConnectionTimeout` 、 `FailRequestOnPasswordChange` 。
+- `Query=` は参照の残りをネイティブの CCP クエリとして渡します。ほかの値を設定しない限り、 `QueryFormat=Exact`
+  が使われます。
+- 参照内の `AppID` は無視されます。常にストアの AppID が使われます。
+- アカウントのパスワード（ `Content` ）がパスワードになり、 `UserName` 、 `Address` 、 `Port` 、
+  `Database` がユーザー、ホスト、ポート、データベース名を埋めます。
+
+---
+
+## 追加オプション
+
+ストアの追加オプションは JSON オブジェクトで設定します。
+
+| キー | 意味 |
+|---|---|
+| `reason` | 参照に `Reason` がない場合に、CyberArk の監査用として `Reason` で送られます。 |
+| `check_ref` | **接続テスト** が実際に読み込む参照。これがない場合、テストは CCP が応答して AppID を受け入れることだけを確認します。 |
+| `timeout_ms` | リクエストのタイムアウト。既定は 10000。 |
+
+たとえば、理由を送り、 **接続テスト** でプローブ用のアカウントを読み込ませるには次のようにします。
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/ja/_configure/secret-stores/hashicorp-vault.md b/i18n/ja/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..a8e2005
--- /dev/null
+++ b/i18n/ja/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: シークレットストア
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+HashiCorp Vault の KV v1、v2、または動的シークレットエンジンから認証情報を読み込みます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ストアのフィールド
+
+[すべてのストアにあるフィールド](./#adding-a-store) に加えて、HashiCorp Vault ストアには次のフィールドがあります。
+
+| フィールド | 意味 |
+|---|---|
+| 認証情報 | [接続 > 認証情報](../credentials.html) の **HashiCorp Vault** 認証情報。Vault のアドレス、その TLS の設定、そして認証情報が使うパスへの読み取りアクセスを持つトークンをパスワードとして保持します。 **認証情報を追加** でその種類の認証情報を作成できます。AnsibleForms はトークンを更新しません。 |
+| ネームスペース | Vault Enterprise のネームスペース。 `X-Vault-Namespace` として送られます。 **種類** ステップで **Vault Enterprise** をオンにすると表示されます。 |
+| KV バージョン | `2` （既定）または `1` 。 |
+| 既定のマウント | スラッシュのない参照に使われます。たとえば `myapp` は `secret/data/myapp` になります。 |
+
+シークレットの参照はパスで、たとえば `secret/myapp/prod` です。KV v2 では、 `/data/` の部分を省くと
+自動的に挿入されます。
+
+---
+
+## 動的なデータベースの認証情報
+
+`database/creds/readonly` のような `<mount>/creds/<role>` 形式の参照は、Vault のデータベースエンジンなどの
+動的シークレットエンジンから読み込みます。その場合、Vault は読み込みのたびに、リースの期間有効な新しいデータベース
+アカウントを作成します。
+
+- アカウントは、キャッシュ時間ではなくリースの 80% の間再利用されます。キャッシュが `0` の場合は、クエリのたびに新しいものを読み込みます。
+- Vault が返すのはユーザーとパスワードだけです。接続のそれ以外の情報は認証情報の行に入れてください。
+- リースが早期に失効されることはありません。アカウントは、Vault がリースを終了したときに期限切れになります。
diff --git a/i18n/ja/_configure/secret-stores/index.md b/i18n/ja/_configure/secret-stores/index.md
new file mode 100644
index 0000000..a9df73f
--- /dev/null
+++ b/i18n/ja/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: シークレットストア
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# シークレットストア
+{: .no_toc }
+
+認証情報を AnsibleForms に保存する代わりに、シークレットマネージャーから読み込みます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。シークレットマネージャーに接続し、認証情報がユーザーとパスワードをそこから読み込めるようにします。
+
+---
+
+## 仕組み
+
+**シークレットストア** はシークレットマネージャーへの接続で、
+**接続 > シークレットストア** で追加します。その後、 **認証情報** でストアとその中の場所
+（ *シークレットの参照* ）を指定できます。フォーム、プレイブック、式がその認証情報を使うと、次のようになります。
+
+- **ユーザー** と **パスワード** は、毎回（ストアのキャッシュ時間内であればキャッシュから）ストアから読み込まれます。
+- **ホスト** 、 **ポート** 、 **データベース** は、認証情報の行のものがそのまま使われます。行でそのいずれかが空で、
+  シークレットにその値がある場合は、シークレットの値が使われます。
+
+フォームは引き続き名前で認証情報を参照するので、パスワードをストアに移してもフォームは何も
+変わりません。
+
+| ストアの種類 | 状態 |
+|---|---|
+| HashiCorp Vault（KV v1 と v2、トークン認証） | 利用可能 |
+| HashiCorp Vault の動的認証情報（ `<mount>/creds/<role>` ） | 試験的 |
+| CyberArk Central Credential Provider（CCP） | 試験的 |
+
+---
+
+## ストアの追加
+
+7.3.0 からは、ストアのトークンやキーがそのアドレスに送られるため、ストアの追加、変更、削除は管理者だけが行えます。すべてのストアには次のフィールドがあります。
+
+| フィールド | 意味 |
+|---|---|
+| 名前 | 認証情報がストアを参照する名前。 |
+| 種類 | シークレットマネージャー。 |
+| 認証情報 | ストアがどのように、どこにログインするか。 **認証情報** ステップで指定する、 [接続 > 認証情報](../credentials.html) の種類 **HashiCorp Vault** （トークンとアドレス）または **CyberArk** の認証情報です。ベース URL（例： `https://vault.example.com:8200` ）と TLS の設定（証明書の検証のスキップ、またはプライベート CA 用の PEM の CA バンドル）を保持します。それ自体をシークレットストアから読み込むことはできません。 |
+| キャッシュ (秒) | 読み込んだシークレットを再利用する期間。 `0` では使用のたびに読み込みます。既定は 60 です。 |
+| 追加オプション (JSON) | 種類に固有のオプション。JSON オブジェクトで指定します。 |
+
+7.2.0 までは、アドレス、トークン、TLS の設定はストアのフィールドでした。7.3.0 へのアップグレードでこれらは
+`<store>-token` （CyberArk の場合は `<store>-appid` ）という名前の認証情報に移されます。 [認証情報内のアドレス](../credentials/types.html#addresses-in-credentials) を参照してください。
+
+**接続テスト** は、シークレットを読まずにアクセスを確認します。 **ステータス** ページはすべてのストアを確認し、Vault のトークンが
+期限切れになる 7 日前に警告します。
+
+シークレットマネージャーごとに専用のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | トークン認証による KV v1 と v2、および動的なデータベースの認証情報 |
+| [CyberArk](cyberark.html) | CyberArk の Application Access Manager の Central Credential Provider（CCP） |
+
+---
+
+## ストアの使用
+
+### 認証情報で
+
+**接続 > 認証情報** で、認証情報の **保存先** ステップで **シークレットストア** を選び、
+**シークレットストア** を選択して **参照** を入力します。すると、ユーザーとパスワードは入力したものではなく、ストアから読み込まれます。
+
+### 認証情報の行を使わずに直接
+
+認証情報の名前を受け付ける場所ならどこでも、代わりにストアを直接参照できます（ `fnCredentials` 、 `fnRestBasic` 、
+フォームの `credentials:` 、クエリの `dbConfig` ）。
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+認証情報の行がない場合、データベースのシークレットには少なくとも `db_type` とホストが必要です。たとえば次のとおりです。
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+`db_type` がない場合、シークレットは通常の認証情報（ユーザー、パスワード、その他のキー）として扱われ、それに対するクエリは `mysql` を前提とします。
+
+### キーの名前
+
+シークレットは、次の別名で認証情報に対応付けられます。そのほかのキーはそのまま渡されます。
+
+| 認証情報のフィールド | シークレットで受け付けるキー |
+|---|---|
+| `user` | `user` 、 `username` 、 `login` |
+| `password` | `password` 、 `token` 、 `api_key` 、 `apikey` 、 `secret` |
+| `host` | `host` 、 `address` |
+| `port` | `port` |
+| `db_name` | `db_name` 、 `database` |
+| `db_type` 、 `secure` | 同じ名前（直接参照するシークレットのみ） |
+
+認証情報の行の場合、シークレットのホスト、ポート、データベース名は、行でそれらが空の場合にだけ
+使われます。
+
+構造の異なるシークレットは、 `fnCredentials` の第 3 引数として渡す `jq` 式で
+形を変えられます。
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## 構成シードで
+
+ストアは、ほかの管理オブジェクトと同じく、構成シードで宣言することもできます。
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+ストアはその認証情報でログインします。 `vault` の認証情報は Vault のアドレスを `url` に、トークンをパスワードとして保持し、 `cyberark`
+の認証情報は AppID と CCP のアドレスを保持します。認証情報がない場合は、ストア自身の `url` と `token` が使われます。
+詳しくは [構成シード](../seed) を参照してください。
+
+---
+
+## VAULT_* 変数からのアップグレード
+
+バージョン 7 より前は、ストアは `VAULT_*` 環境変数で設定する HashiCorp Vault だけで、
+認証情報は **Vault パス** でそれを指していました。
+
+- **変数は一度だけ** `vault` という名前のストアとして **インポートされます** 。その後は削除してください。
+- **`vault_path` を持つ認証情報** は、そのストアを使うようになりました。 `vault_path` は 8 で削除されます。
diff --git a/i18n/ja/_configure/security/hardening.md b/i18n/ja/_configure/security/hardening.md
new file mode 100644
index 0000000..a0144c5
--- /dev/null
+++ b/i18n/ja/_configure/security/hardening.md
@@ -0,0 +1,183 @@
+---
+layout: default
+title: 強化
+parent: セキュリティ
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# 強化
+{: .no_toc }
+
+管理者アカウント、サインインの制限、データベース、式、ジョブのデータ、ブラウザーのポリシー、任意の機能、ロールオプション
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 管理者アカウント
+
+ローカルの管理者アカウントは、初回起動時に [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+と [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) から作成されます。後者の既定値は `AnsibleForms!123` です。
+
+* 公開されている既定のパスワード `AnsibleForms!123` でサインインした場合は、まずそれを変更する必要があります。変更するまで、サーバーは
+  パスワードの変更以外のすべてのリクエストに `403` （コード `password_change_required` ）を返し、ブラウザーには閉じられない
+  パスワード変更ページが表示されます。新しいパスワードを再び既定値にすることはできません。
+* `ADMIN_PASSWORD` が読み込まれるのは、アカウントが最初に作成されるときだけです。初回起動の前に独自の値を設定してください。
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` は、起動のたびにパスワードを `ADMIN_PASSWORD` にリセットします。
+  紛失したパスワードの回復にだけ使い、その後は設定を外して再起動してください。
+* 最初に二つのマスターシークレットを設定してください。 [シークレットと暗号化](secrets.html) を参照してください。
+* LDAP または SSO でのサインインが機能したら、ローカル管理者は緊急時専用とし、長いパスワードを保管庫に保存してください。
+
+---
+
+## サインインの制限とパスワード
+
+パスワードの推測は、三つの制限で遅らせられます。失敗はデータベースで数えられるので、すべてのアプリノードが同じ試行を把握し、
+どの制限も再起動なしで反映されます。
+
+| 変数 | 既定値 | 動作 |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | ログインにこの回数失敗すると、ローカルまたは LDAP のアカウントは `LOGIN_LOCKOUT_MINUTES` の間ロックされます。 |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | `LOGIN_LOCKOUT_MINUTES` の間にこの回数ログインに失敗したアドレスは、その期間が終わるまで止められます。一つのアドレスが多くのアカウントを試す場合です。 |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | アカウントがロックされる時間と、失敗を数える期間。 |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | ログイン、サインアウト、トークンの更新、シングルサインオンのコールバックについて、アプリノードごとに一つのアドレスから受け付ける 1 分あたりのリクエスト数。 |
+
+ロックされたアカウントや止められたアドレスには、パスワードを確認する前に、アカウントが存在するかどうかにかかわらず、 `Retry-After` ヘッダー付きの `429` が返されます。
+`AUTH_RATE_LIMIT` を超えた場合も `429` が返されます。ログインに成功するとアカウントのカウントは消去され、管理者がユーザーのパスワードを
+設定した場合も同様です。 `0` で制限をオフにします。 `LOGIN_LOCKOUT_MINUTES=0` では、ロックアウトとアドレスごとの制限の両方がオフになります。
+
+`LOGIN_MAX_FAILURES_PER_IP` と `AUTH_RATE_LIMIT` はクライアントのアドレスごとに数えます。リバースプロキシの背後では、アドレスがプロキシのものではなく
+クライアントのものになるよう `TRUST_PROXY` を設定してください。 [クライアントのアドレス](../production/reverse-proxy.html#client-addresses) を参照してください。
+
+新しいユーザー向けに、管理者が、またはユーザー自身が変更するなど、アプリケーションを通じて設定するローカルのパスワードは、
+少なくとも [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) 文字（既定は `8` 、
+`0` で長さを確認しません）である必要があります。ユーザー名や公開されている既定のパスワードは使えません。 `ADMIN_PASSWORD` は確認されません。
+
+---
+
+## データベース
+
+AnsibleForms はすべての認証情報とジョブを MySQL データベースに保持するので、そのデータベースはネットワークから切り離してください。
+
+* docker-compose プロジェクトは MySQL をホストに公開し（ `MYSQLDB_LOCAL_PORT` 、 `3306` ）、root パスワード `AnsibleForms!123` が
+  設定された状態で提供されます。そのポートマッピングを削除するか `127.0.0.1` にバインドし、パスワードを変更してください。
+* `root` ではなく専用のアカウントで接続し、 [`DB_USER`](../customization/server.html#env_DB_USER) と
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD) に設定してください。必要なのは `AnsibleForms` スキーマに対する権限だけです。
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  これで、スキーマの作成（ `CREATE DATABASE` を含む）、アップグレード時のパッチ、そして同じユーザーで実行される
+  [バックアップ](../production/backups.html) とリストアがまかなえます。ダンプは `--no-tablespaces` で取られるので、
+  `PROCESS` のようなサーバー全体の権限は不要です。可能であれば `%` をアプリケーションのアドレスに置き換えてください。 `root` のように
+  すべてのデータベースに対する権限を持つユーザーを使うと、アプリケーションの穴がデータベースサーバー全体の穴になります。
+  **ステータス** ページはその **データベースユーザー** チェックで、ログは起動のたびに、これについて警告します。
+* スキーマができたら、 [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) を `0` に設定してください。
+  スキーマの作成では最初にすべてのテーブルが削除されます。 `0` にすると、起動時のブートストラップも `/api/v2/schema`
+  エンドポイントもそれを実行できません。
+
+---
+
+## 式と外部への呼び出し
+
+サーバー式はサインインしたどのユーザーに対してもサーバー上で実行されるので、サニタイザーと外部への呼び出しのフィルターが重要です。
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) ： `strict` または `paranoid` 。ユーザーがサーバーのコードを実行できてしまう `legacy` は決して使わないでください。
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) ：REST 式が到達してはならないホスト。例： `169.254.169.254,127.0.0.0/8` 。
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) ：設定すると、REST 式が到達できるのは
+  これらのホストと範囲だけになります。拒否リストのほうが優先されます。
+
+どちらのリストも AnsibleForms 自身の REST ヘルパー関数だけを対象とします。プレイブックはその外で実行され、フィルターされません。
+
+7.3.0 からは、REST ヘルパー関数は、ほかのすべての接続と同じくエンドポイントの証明書を検証します。
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` で検証をオフにします。自己署名証明書を持つ
+エンドポイントにだけ使ってください。
+
+---
+
+## ジョブのデータ
+
+ジョブの extravars と出力はデータベースに保存され、そのジョブを見られる全員に表示されます。
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) ：キーが一致する extravars は
+  `********` と表示されます。既定は `password|secret|token` で、パスワードフィールドは常にマスクされます。フォームで使っている名前で
+  拡張してください。たとえば `password|secret|token|apikey|passphrase` です。
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) ：すべてのジョブとともに送られる `ansibleforms_user`
+  オブジェクトを絞り込みます。これがないと、ユーザーのグループのメンバーシップがすべて含まれます。
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) はうるさいタスクを隠すだけです。シークレットは `no_log` で隠してください。
+
+---
+
+## Content-Security-Policy
+
+インターフェースは Content-Security-Policy ヘッダー付きで提供され、ブラウザーでページが読み込んで実行できるものを制限します。
+
+* スクリプトはアプリケーション自身からのものだけなので、ページに注入されたスクリプトは実行されません。
+* ほかのサイトがインターフェースをフレームで表示することはできません。
+* アプリケーションに必要なものは許可されます。ブラウザーで評価されるフォームのローカル式（ `'unsafe-eval'` ）、インライン
+  スタイル、任意の URL の画像（フォームとカテゴリの画像）、コードエディターのワーカーです。
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) の既定は `1` で、そのままにしておくべきです。
+`0` にすると、ポリシーは `Content-Security-Policy-Report-Only` として送られます。ブラウザーのコンソールにはブロックされるはずのものが表示され、
+何もブロックされません。独自のスクリプトを注入するリバースプロキシなど、まだポリシーとともに動作できない構成にだけ `0` を使ってください。
+設定ページでの変更は再起動なしで反映されます。
+
+---
+
+## 設定ページとデザイナー
+
+管理者は、ブラウザーから設定の多くを変更できます。設定がほかの場所で管理されている場合は、これを絞り込んでください。
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` ： [管理された環境](../seed/environment-and-audit.html) 向けに、設定を読み取り専用にします。
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` ：フォームを git で管理している場合に、組み込みのデザイナーを
+  取り除きます。
+
+---
+
+## 任意の機能
+
+これらの機能は既定でオフです。使う場合にだけオンにしてください。設定ページでの変更は再起動なしで反映されます。
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) ： `/api/v2/mcp` で [MCP サーバー](../mcp/) を提供し、
+  MCP クライアントがユーザーのトークンでフォームを起動できるようにします。
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) ： [チャットアシスタント](../chat/) 。フォームの定義と
+  入力中の値が、設定したモデルプロバイダーに送られます。
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) は逆に、既定で `enforce` です。そのため、REST API を通じた起動も含め、
+値がフォームのルールに反する起動をサーバーは拒否します。
+そのままにしてください。 `log` は拒否されるはずのものをログに記録するだけで、 `off` は何も確認しません。 [起動時の検証](../launch-validation/) を参照してください。
+
+---
+
+## ロールオプション
+
+[config.yaml](../config/roles.html) のロールオプションには、名前から想像される以上の権限を与えるものがあります。慎重に付与してください。
+
+| オプション | 重要な理由 |
+|--------|----------------|
+| `allowScheduledJobs` | これを持つユーザーはすべてのスケジュールを表示、変更でき、スケジュールはどのフォームでも管理者権限で実行されます。管理者レベルとして扱ってください。 |
+| `allowBackupOps` | データベース全体を置き換える **リストア** を含みます。 |
+| `showSettings` | 管理ページを開きます。admin ロールがない場合、admin ロールが指定するアカウントとグループは変更できません。 [ユーザーとグループ](../users-and-groups.html#accounts-that-grant-admin) を参照してください。 |
+| `showLogs` | ホスト名、ユーザー名、エラーの詳細を含むことがあるサーバーログを表示します。 |
+| `showConnectionsSettings` | 接続のページ（認証情報、ランナー、通知チャネルなど）を開きます。ランナーとシークレットストアの追加、変更、削除は管理者のものであり、接続とサインインの認証情報も同様です。リポジトリについては、追加、削除、アドレス、ブランチ、 `use_for_*` フラグの変更は管理者のものです。 |
+| `showAllJobLogs` | ユーザー自身のジョブだけでなく、すべてのユーザーのジョブを表示します。 |
+| `manageAllJobs` | すべてのユーザーのジョブを中止、削除、再実行します。 |
+| `allowApiTokens` | 最大 [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) （既定は 90）有効な API トークンを作成できるようにします。トークンでサインアウトするか失効させると終了し、パスワードを変更するとそのユーザーのすべてのトークンが終了します。 [トークン](secrets.html#tokens) を参照してください。 |
+| `extendedTokenExpiration` | `allowApiTokens` とともに、期限切れにならない API トークンも作成できるようにします。 |
+| `allowFileUploads` | フォームのファイルフィールドからファイルをアップロードできるようにします。ロールでオフにしない限り、すべてのユーザーでオンです。 |
+| `allowChat` 、 `allowMcp` | オンになっている場合に、チャットアシスタントと MCP サーバーを使えるようにします。 `allowChat` はロールでオフにしない限りすべてのユーザーでオンで、 `allowMcp` はロールで設定しない限り `allowChat` に従います。 |
+
+`admin` ロールのないユーザーは、ロールで与えられない限り、上記の管理者レベルのオプションを何も得ません。 `admin` ロールが
+オプションを設定していない場合、そのユーザーには `showSettings` 、 `showDesigner` 、 `showLogs` 、 `showAuditLog` 、 `allowBackupOps` 、
+`allowJobRelaunch` 、 `showAllJobLogs` 、 `manageAllJobs` 、 `allowScheduledJobs` が付与されます。 `allowApiTokens` と
+`extendedTokenExpiration` は `admin` ロールでもオフのままです。必要なロールで設定してください。
+
+ユーザーの複数のロールが同じオプションを設定している場合は、 `false` が優先されます。 `default` ロールのオプションは、ユーザー自身の
+ロールがどれも設定していないオプションを補うだけで、それらを覆すことはありません。
diff --git a/i18n/ja/_configure/security/https.md b/i18n/ja/_configure/security/https.md
new file mode 100644
index 0000000..ce74b0c
--- /dev/null
+++ b/i18n/ja/_configure/security/https.md
@@ -0,0 +1,96 @@
+---
+layout: default
+title: HTTPS
+parent: セキュリティ
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+アプリケーション自身から HTTPS を提供し、サンプル証明書を置き換えます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## TLS を終端する場所
+
+TLS は三つの場所のいずれかで終端でき、このページの設定が関係するのは最初のものだけです。
+
+* **AnsibleForms で** 、 `HTTPS=1` ：下のファイルを使って [`PORT`](../customization/server.html#env_PORT) で HTTPS を提供します。docker-compose が 443 で行っている方法です。
+* **リバースプロキシで** 、その背後では `HTTPS=0` ： [リバースプロキシ](../production/reverse-proxy.html) を参照してください。
+* **Kubernetes のイングレスで** ： [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) の Ingress タブと、チャートの README を参照してください。
+
+最初のものをほかの二つと組み合わせて、プロキシとアプリケーションの間の区間も暗号化できます。
+
+---
+
+## 設定
+
+アプリケーションの HTTPS は三つの変数で制御します。
+
+| 変数 | 既定値 | 意味 |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` で HTTPS を、 `0` でプレーンな HTTP を提供します |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | 秘密鍵（PEM） |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | サーバー証明書（PEM） |
+
+コンテナーイメージでは永続フォルダーは `/app/dist/persistent` なので、既定のファイルは
+`/app/dist/persistent/certificates/key.pem` と `cert.pem` です。docker-compose プロジェクトでは、ホストの `data/certificates/` です。
+
+---
+
+## サンプル証明書
+
+`HTTPS=1` で、起動時にいずれかのファイルがない場合、AnsibleForms は `httpsKey or httpsCert not found, copying from
+templates` とログに記録し、イメージからサンプルのキーと証明書を設定されたパスにコピーします。そのコピーに失敗すると、
+アプリケーションは停止します。
+
+この証明書は `CN=ansibleforms` の自己署名証明書で、 **すべてのインストールで同じ** です。その秘密鍵は公開されているイメージに
+含まれています。最初に試すには問題ありませんが、ブラウザーは警告を表示し、誰でもそれで保護された通信を復号できます。
+インスタンスが実際の認証情報を保持する前に置き換えてください。
+
+---
+
+## 証明書の置き換え
+
+ユーザーが入力するホスト名向けに、自社の CA または ACME クライアントが発行した PEM 形式の証明書を使います。
+証明書ファイルにはフルチェーンを含めることができます。サーバー証明書を先に、その後に中間証明書を置きます。
+
+1. ファイルを永続フォルダー、またはアプリケーションが読めるどこかにコピーします。
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. ほかの場所に置いた場合は、 `HTTPS_KEY` と `HTTPS_CERT` に **コンテナー内の** パスを設定します。
+
+3. アプリケーションを再起動します。両方のファイルは起動時に読み込まれます。
+
+手早く独自の自己署名証明書を作るには（テスト用のインスタンス、またはプロキシの背後の区間向け）、 `openssl` を使います。
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## 再起動なしの更新
+
+設定ページで `HTTPS_KEY` または `HTTPS_CERT` を変更すると、実行中のサーバーでキーと証明書が再読み込みされます。
+新しい接続には新しい証明書が使われ、開いている接続は古いもののままです。新しいファイルを読めないか、有効な組み合わせに
+ならない場合は、現在の証明書がそのまま使われ、警告がログに記録されます。
+
+これが機能するのは、設定ページが環境に書き込める（ [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+が `1` ）場合で、かつ変数が実際の環境で設定されていない場合だけです。更新で同じパスのファイルを置き換える場合は、
+アプリケーションを再起動してください。
diff --git a/i18n/ja/_configure/security/index.md b/i18n/ja/_configure/security/index.md
new file mode 100644
index 0000000..5c6ec54
--- /dev/null
+++ b/i18n/ja/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: セキュリティ
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# セキュリティ
+{: .no_toc }
+
+インスタンスを保護します：管理者アカウント、シークレット、HTTPS、ユーザーとフォームにできること
+{: .fs-6 .fw-300 }
+
+---
+
+インスタンスを本番環境向けに準備する管理者と、既存のインスタンスのセキュリティレビューのためのものです。
+
+---
+
+## このセクションの内容
+
+トピックごとに専用のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [強化](hardening.html) | 管理者アカウント、サインインの制限、データベース、式、ジョブのデータ、ブラウザーのポリシー、任意の機能、ロールオプション |
+| [HTTPS](https.html) | TLS を終端する場所、アプリケーションからの HTTPS の提供、サンプル証明書の置き換え |
+| [シークレットと暗号化](secrets.html) | `ENCRYPTION_SECRET` 、 `ACCESS_TOKEN_SECRET` 、トークンの有効期間 |
+
+関連ページ：サインイン方法については [認証](../authentication/) 、すべての起動をサーバー側で確認する [起動時の検証](../launch-validation/) 、
+そして [セキュリティの変数](../customization/security.html) 。
diff --git a/i18n/ja/_configure/security/secrets.md b/i18n/ja/_configure/security/secrets.md
new file mode 100644
index 0000000..dc25a63
--- /dev/null
+++ b/i18n/ja/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: シークレットと暗号化
+parent: セキュリティ
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# シークレットと暗号化
+{: .no_toc }
+
+二つのマスターシークレット、それが保護するもの、セッションとトークンの有効期間
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 二つのマスターシークレット
+
+二つのシークレットが、それ以外のすべてを保護します。インスタンスが実際のデータを保持する前に両方を設定し、インスタンスの外に保管し、
+軽々しく変更しないでください。
+
+| シークレット | 保護するもの | 設定されていない場合 | 紛失または変更した場合 |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | データベースに保存されるすべてのパスワードとトークン。認証情報、LDAP のバインドパスワード、ランナーのトークン、SSO のクライアントシークレット、Slack と Teams の Webhook アドレス、チャットの API キー | ソースコードで公開されている既定のキーが使われます | 紛失：保存されているすべてのシークレットを再入力する必要があります。変更：7.3.0 からは、保存されているすべてのシークレットが再暗号化されます。 [下記](#changing-the-encryption-secret) を参照 |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | アクセストークンとリフレッシュトークンの署名。有効期間の長い [API トークン](../profile/api-token.html) も含みます | 起動のたびにランダムなシークレットが生成されるため、再起動のたびに全員がサインアウトされます | すべてのセッションとすべての API トークンが無効になります |
+
+どちらも、設定されていない間は起動時に `[SECURITY]` の警告としてログに記録されます。設定ページはそれらの編集を拒否し、
+API は決してそれらを返さず、バックアップは意図的にそれらを除外します。そのため、紛失した `ENCRYPTION_SECRET` はどこからも回復できません。
+シークレットマネージャーにコピーを保管してください。暗号化シークレットは 32 文字のキーとして使われます。短い値や
+長い値は、埋められるか切り詰められます。
+
+`ACCESS_TOKEN_SECRET` を変更すると、すべてのセッションとすべての API トークンがすぐに終了します。一人のユーザーや一つの
+セッションのトークンを終了するには、 [トークン](#tokens) で説明している失効を使ってください。
+
+---
+
+## 暗号化シークレットの変更
+
+7.3.0 からは、 `ENCRYPTION_SECRET` を設定または変更しても、保存されているシークレットは失われなくなりました。次回の起動時に、ワーカーは
+ほかの何かがシークレットを書き込む前に、一つのデータベーストランザクションで、すべてのシークレットを新しいキーで再暗号化します。
+
+| 状況 | 設定するもの |
+|---|---|
+| インスタンスが `ENCRYPTION_SECRET` なしで、公開されている既定のキーで動作していた | `ENCRYPTION_SECRET` だけ。シークレットは既定のキーから再暗号化されます |
+| インスタンスが独自のキーで動作していた | その一回の起動のために、 `ENCRYPTION_SECRET` に新しいキーを、 [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) に古いキーを設定します |
+
+保存されているシークレットがそのどちらでもないキーで暗号化されていた場合は、何も変更されず、 `ENCRYPTION_SECRET_PREVIOUS` がそのキーを
+指定するまでアプリは起動を拒否します。起動で再暗号化されたら `ENCRYPTION_SECRET_PREVIOUS` を削除し、
+新しい `ENCRYPTION_SECRET` をすべてのアプリノード、ワーカー、そして自分自身を登録するデータベースモードのすべての RTE に設定してください。その
+自己登録（ `RTE_REGISTER` ）は 7.3.0 で非推奨になりました。ソケットモードで参加トークン（ `RTE_JOIN_TOKEN` ）を使って参加する RTE には
+`ENCRYPTION_SECRET` は不要です。 [RTE のモード](../rte/modes.html) を参照してください。
+
+---
+
+## トークン
+
+サインインすると、有効期間の短いアクセストークンと、より長いリフレッシュトークンが返され、ブラウザーはそれを使って新しい組を取得します。
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) ：既定は `30m` です。短くすると、
+  傍受されたトークンが使える範囲が限られます。
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) ：既定は `24h` です。
+  操作のないブラウザーがサインインしたままでいられる時間です。
+* ロールオプション `allowApiTokens` を使うと、ユーザーは指定した日数有効な API トークンを要求でき、
+  `extendedTokenExpiration` を加えると期限切れにならないものも要求できます。スクリプトからの API アクセスが必要なロールにだけ付与してください。
+  [プロフィールページ](../profile/api-token.html) では、トークンは 10 分以内にサインインしたブラウザーのセッションから作成され、
+  別の API トークンからは決して作成されません。期限切れにならないトークンの有効期間は 50 年で、下のイベントでは引き続き終了します。
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) ：既定は `90` です。API トークンの最長の
+  有効期間で、それより長い要求はこの値に切り詰められます。
+
+トークンは署名された JWT ですが、サーバーはすべてのアプリノードで共有される失効したトークンのリストも保持しているので、トークンは
+期限切れになる前に終了できます。
+
+| イベント | 終了するもの |
+|-------|-----------|
+| サインアウト | そのサインインのすべてのトークン。アクセストークン、そのリフレッシュトークン、そしてサインアウトに API トークンを使った場合はその API トークン |
+| ユーザー自身または管理者によるパスワードの変更 | 変更前に発行されたユーザーのすべてのトークン。API トークンも含め、すべてのデバイスで |
+| ユーザー（ローカル、LDAP、SSO のユーザー）の **サインインを許可** スイッチをオフにする、またはローカルユーザーを削除する | ユーザーのすべてのトークン |
+| LDAP または SSO のユーザーのページの **セッションを終了** | ユーザーのすべてのトークン。ブロックされていなければ再びサインインできます |
+| プロフィールページまたはユーザーの **API トークン** タブで API トークンの **取り消す** | その API トークン一つが、すぐに |
+
+スクリプトは、自分の API トークンでサインアウトすることでそのトークンを終了します。 `Authorization` ヘッダーにトークンを付けて
+`POST /api/v2/auth/logout` を呼び出します。
diff --git a/i18n/ja/_configure/seed/environment-and-audit.md b/i18n/ja/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..ca0fbae
--- /dev/null
+++ b/i18n/ja/_configure/seed/environment-and-audit.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 編集と監査
+parent: 構成シード
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# 編集と監査
+{: .no_toc }
+
+設定ページのロックと、監査ログに記録されるもの
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 環境の編集をオフにする
+
+`ALLOW_ENV_EDIT=0` にすると、設定ページは読み取り専用になります。各変数は引き続き現在有効な値と、
+変更できない理由とともに表示され、保存のエンドポイントは 403 を
+返します。
+
+環境がほかの場所で宣言されている場合は、常にこれを使ってください。そうしないと、設定ページは
+`persistent/.env` に書き込みます。これは一時的なボリュームでは次回の再起動で黙って失われ、永続的なボリュームでは
+正とされるべきマニフェストからずれていきます。
+
+{: .note }
+> バックアップには `persistent/.env` が `managed.env` として含まれるので、再構築するとデータベースと
+> パスの設定が戻ります。 **`ENCRYPTION_SECRET` と `ACCESS_TOKEN_SECRET` は取り除かれます** 。
+> 隣にあるダンプは保存されているすべての認証情報を AES の暗号文として保持しており、それを復号するキーを
+> 同じフォルダーに書き込むと、バックアップのコピーさえあればすべてを読めてしまうためです。この二つは
+> 代わりに移行先のホストで設定してください。ファイル内のコメントにもそう書かれています。
+>
+> 残ったものにもまだ認証情報（ `DB_PASSWORD` 、 `METRICS_TOKEN` 、古い `VAULT_TOKEN` ）が含まれることがあるので、ファイルは
+> `0600` で書き込まれます。その復元は、通常のリストアの一部ではなく、別途選択する手順です。
+> ファイル内のデータベースホストとパスは、バックアップ元のマシンを表しているためです。
+> リストアのダイアログにはファイルが表示され、専用の *環境を復元* ボタン
+> （ `POST /api/v2/backup/:folder/restore-env` ）があります。これは以前のファイルを `.env.bak` として残します。
+
+---
+
+## 記録されるもの
+
+何かを変更した適用はそれぞれ、作成、更新、解放、整理されたオブジェクトを示す `seed.apply` エントリを一つ
+監査ログに書き込みます。値はその大半がシークレットであるため、決して記録されません。何も変更しない適用は何も書き込まないので、
+証跡は意味のあるものに保たれます。ファイルが変わっていないことを確認したポーリングは何も変更しない適用なので、
+証跡に毎分行が増えることはありません。
+
+エンドポイントで要求された適用は意図的に二度記録され、その二つの行は
+異なることを記録します。 `config-seed.apply.create` は要求した **人** を、 `seed.apply` は
+変更した **内容** を記録します。
+
+ステータスページはシードについて二つのことを報告します。ファイルがまだ読み取れて解析でき、最後の再読み込みが成功したかを確認する **チェック** と、
+現在所有しているレコードの数を示す **情報** の行です。ディスク上のファイルと有効な設定がずれたときに
+それを報告するのはこのチェックだけです。再読み込みに失敗しても、インスタンスは動作し続けるためです。
diff --git a/i18n/ja/_configure/seed/example.md b/i18n/ja/_configure/seed/example.md
new file mode 100644
index 0000000..226593b
--- /dev/null
+++ b/i18n/ja/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: 例
+parent: 構成シード
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# 例
+{: .no_toc }
+
+セクションごとに説明する、完全なシードファイル
+{: .fs-6 .fw-300 }
+
+---
+
+次のシードファイルは、 `oauth2` と非推奨の `awx` 以外のすべてのセクションを宣言しています。シークレットは `${SEED_AWX_TOKEN}` のような
+環境変数から取得します。
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` は次のいずれかです。
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` ：OpenAI 互換のその他のエンドポイント
+
+`ldap` と同じく、 `chat` セクションは単一行なので、任意のものを除くすべてのフィールドが必須です。省略した任意の
+フィールドは変更されません。
+
+チャットアシスタントには `ENABLE_CHAT=1` も必要です。 [チャットアシスタント](../chat) のページを参照してください。
+
+7.3.0 からは、ランナーはその種類の認証情報でサインインし、その認証情報が `url` にサーバーのアドレスを保持します。独自の `token` 、
+または `username` と `password` を持つランナーも引き続き動作します。シードは警告をログに記録し、それらをランナーにちなんだ名前のそうした認証情報に変換します。
+`api` または `userpass` の認証情報を指定しているランナーも、警告付きで引き続き動作します。その認証情報にはランナーの種類を与えてください。
+どちらも 7.3.0 から非推奨で、8.0.0 で削除されます。 `rte_mode` のない RTE ランナーは、非推奨のデータベースモードです（
+[モード](../rte/modes.html) を参照）。 `enabled: false` のランナーは、その種類の既定であってもジョブを受け取りません（
+[既定と有効](../runners/list.html#default-and-enabled) を参照）。 `enabled` がない場合、シードはそのままにします。
+
+ランナーの項目は、 `name` 、 `type` 、 `description` 、 `credential` 、 `is_default` 、 `enabled` のほかに、次のキーを受け付けます。
+
+| キー | 設定するもの |
+|---|---|
+| `rte_mode` | RTE のモード： `outbound` 、 `inbound` 、 `database` （非推奨、既定） |
+| `rte_max_jobs` | ソケットモードの RTE の **最大同時ジョブ数** 。 `0` から `10000` （ `0` ：無制限） |
+| `rte_cache_mb` | その **ジョブファイルのキャッシュ** （MB）。 `0` から `1048576` （ `0` では何も保持しません） |
+| `rte_files` | その **ジョブファイル** ： `transfer` または `local` |
+| `rte_drain_seconds` | その **停止時の待機時間** （秒）。 `0` から `86400` |
+| `flavour` | AAP または Ascender である `awx` ランナー： `aap` または `ascender` 。AWX ではなし |
+| `project` | Semaphore ランナーのプロジェクト ID、Rundeck ランナーのプロジェクト名、Jenkins ランナーのフォルダー |
+| `uri` 、 `ignore_certs` 、 `ca_bundle` | 7.3.0 より前の、ランナー自身のアドレスと TLS。その認証情報が `url` を持たない間だけ使われます |
+
+四つの `rte_*` 設定は、ランナーのページの RTE タブにある設定です（ [RTE の設定](../runners/runner-page.html#an-rtes-settings) を参照）。
+RTE で設定された同じ変数より優先され、データベースモードの RTE はこれらを無視します。範囲外の値はシードの
+検証で失敗します。
+
+データベースモードの RTE は、シードが適用される前に自分自身を登録することがあります。シードで宣言した RTE ランナーの `uri` が、そうした RTE が
+登録したアドレスである場合、そのランナーはその行を **引き継ぎます** 。宣言した名前とフィールドを取り込み、RTE が応答しなくなっても
+ワーカーはそれを削除しなくなります。同じ RTE に対して 2 つ目のランナーが作られることはありません。
diff --git a/i18n/ja/_configure/seed/index.md b/i18n/ja/_configure/seed/index.md
new file mode 100644
index 0000000..35a76ed
--- /dev/null
+++ b/i18n/ja/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: 構成シード
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# 構成シード
+{: .no_toc }
+
+管理オブジェクトをファイルで宣言します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+git から構築する管理者向けです。管理オブジェクトをファイルで宣言し、空のデータベースからインスタンスを再構築できるようにします。
+
+---
+
+## 対象となるもの
+
+`CONFIG_SEED_PATH` に YAML ファイルを設定すると、AnsibleForms は起動時にそれを適用します。このファイルは、
+これまでデータベースにしか存在しなかったオブジェクトを宣言します。
+
+| セクション                 | 宣言するもの                                                    |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | ジョブの実行場所：RTE、AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins |
+| `secret_stores`         | シークレットストア（HashiCorp Vault など）                                |
+| `credentials`           | 認証情報                                                         |
+| `oauth2`                | SSO プロバイダー：Entra ID と OIDC                                    |
+| `repositories`          | Git リポジトリ                                                    |
+| `syslog_servers`        | サーバーログと監査エントリを受け取る syslog サーバー    |
+| `notification_channels` | 通知用のメールサーバー、Slack、Teams、Telegram、Webhook |
+| `labels`                | ヘッダーのロゴの横のラベル（7.3.0 から）                      |
+| `ldap`                  | LDAP の設定                                              |
+| `settings`              | 公開 URL と、有効なメールチャネルがない場合に使われるメール設定 |
+| `chat`                  | チャットアシスタントのモデルプロバイダー                                 |
+| `awx`                   | 7 から非推奨、8 で削除： `type: awx` の `runners` を使ってください    |
+
+バージョン 7 より前に書かれたシードも引き続き動作します。 `awx` セクションの各項目は種類 `awx` のランナーとして適用され、ログには
+適用のたびに警告が出ます。8 にアップグレードする前に、それらの項目を `type: awx` として `runners` の下に移してください。
+
+シードは `config.yaml` と同じでは **ありません** 。 `config.yaml` はカテゴリ、ロール、定数を保持し、
+独自の `CONFIG_PATH` を持ちます。二つは意図的に分けられています。 `config.yaml` を *保持する*
+リポジトリはシードが宣言するオブジェクトの一つなので、シードをその中に置くことは
+できないのです。
+
+ユーザーとグループは対象外です。これらは LDAP または SSO から取得され、最初の管理者は `ADMIN_USERNAME` / `ADMIN_PASSWORD` から作成されます。
+
+---
+
+## このセクションの内容
+
+トピックごとに専用のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [例](example.html) | セクションごとに説明する、完全なシードファイル |
+| [管理対象オブジェクト](managed-objects.html) | シードが一覧にしたオブジェクトをどのように所有し、シークレットをどのように外に置くか |
+| [再読み込みと起動](reloading.html) | 再起動なしでのファイルの変更と、起動時に起きること |
+| [Kubernetes](kubernetes.html) | ConfigMap と Secret から AnsibleForms を構築します |
+| [編集と監査](environment-and-audit.html) | 設定ページのロックと、監査ログに記録されるもの |
diff --git a/i18n/ja/_configure/seed/kubernetes.md b/i18n/ja/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..4a30a36
--- /dev/null
+++ b/i18n/ja/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: 構成シード
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+ConfigMap と Secret から AnsibleForms を構築します
+{: .fs-6 .fw-300 }
+
+---
+
+シードを `ConfigMap` から、そのシークレットを `Secret` からマウントします。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **`AF_ROLE` を設定しない一つの Pod。** この Pod は、Web アプリとワーカーを一つのプロセスで実行します。スケジュール、夜間
+> バックアップ、その他のバックグラウンドの処理は、データベースでワーカーのロックを持つプロセスだけで実行され、デザイナーの
+> ロックはデータベースのテーブルで、プレイブックはこの Pod ではなく RTE で実行されます。それでも `replicas: 1` と `Recreate`
+> 戦略はそのままにしてください。アップグレード時、新しい Pod はワーカーがスキーマにパッチを当てるのを待ち、古い Pod は停止するまで
+> ワーカーのロックを保持します。複数の Web ノードを実行するには、 [スケーリング](../production/scaling.html) で説明しているように、
+> `AF_ROLE=app` のノードとワーカーに分割してください。
+
+`ENCRYPTION_SECRET` は、認証情報を入力する前に設定する必要があります。認証情報がシードから
+来るようになると、データベースは実質的にキャッシュになるので、ローテーションは手作業ですべてを再入力するのではなく、シードを
+再適用することになります。
+
+二つのプローブにはログインは不要です。 [`BASE_URL`](../customization/server.html#env_BASE_URL) の下では、そのパスはその値で始まります。
+それぞれが何を確認するかは [監視](../production/monitoring.html) で説明しています。
diff --git a/i18n/ja/_configure/seed/managed-objects.md b/i18n/ja/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..56ef937
--- /dev/null
+++ b/i18n/ja/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: 管理対象オブジェクト
+parent: 構成シード
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# 管理対象オブジェクト
+{: .no_toc }
+
+シードが一覧にしたオブジェクトをどのように所有し、シークレットをどのように外に置くか
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 単一行のセクションはすべてか無しか
+
+`ldap` 、 `settings` 、 `chat` はそれぞれ **単一行** なので、シードはそのすべてのフィールドを宣言する必要があります。ほかのセクションはリストです。
+
+フィールドを省いたシードは起動を拒否し、そのフィールドの名前を示します。
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+空の値は `""` または `false` で明示的に宣言します。いくつかのフィールドは任意で、省いた場合は変更されません。
+
+| セクション | 任意のフィールド |
+|---|---|
+| `ldap` | `description` 、 `credential` （バインドに使う認証情報）、 `groupfilter` |
+| `chat` | `auth_type` 、 `api_version` 、 `request_user` 、 `ignore_certs` 、 `extra_headers` |
+| `settings` | なし |
+
+`settings` が対象とするのはメールのフィールドと URL だけです。ほかの設定はすべて編集可能なままです。
+
+---
+
+## ファイルはシークレットを持たない
+
+各 `${VARIABLE}` はその環境変数（Kubernetes では `Secret` から）で置き換えられるので、ファイルは Git に置けます。
+
+設定されていない変数は **致命的なエラー** になるので、プレースホルダーがパスワードとして保存されてしまうことは決してありません。
+
+認証情報は [シークレットストア](../secret-stores) （ `secret_store` 、 `secret_ref` ）も使えます。 `vault_path` は 8 で削除されます。
+
+---
+
+## 管理対象オブジェクト
+
+シードから来たオブジェクトには **管理対象** のフラグが付きます。
+
+- **起動のたびに** 適用されるので、ファイルが正であり続けます。
+- 読み取り専用です。API は **403** を返し、インターフェースでは編集と削除が無効になり、そのページには構成
+  シードファイルから来ていて読み取り専用であることが表示されます。
+- フラグを設定または解除できるのはシードだけです。
+
+手動で作成したオブジェクトは、シードが同じ名前を宣言しない限り **決して変更されません** 。宣言した場合、そのレコードは **引き継がれ** 、
+宣言したフィールドが適用されて読み取り専用になります。引き継ぎは警告としてログに記録され、監査証跡にも残ります。
+
+シードの適用はべき等です。すでに一致しているレコードはそのまま残るので、再起動では通常 `0 updated` と報告されます。
+
+作業ツリーがない宣言済みのリポジトリは、起動のたびに **再びクローンされる** ので、最初のクローンが失敗しても
+再試行されます。ステータスページの *リポジトリ* の行には、作業ツリーのないリポジトリが表示されます。
+
+### オブジェクトの削除
+
+ファイルからオブジェクトを削除すると、それは **解放** されます。レコードは残り、再び編集可能になります。セクション全体を削除しても
+同じです。
+
+ファイルがもう宣言していない管理対象のレコードを **削除** するには、リストのセクションに `prune: true` を追加します。
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` が手動で作成したレコードを削除することはありません。
+
+### シードをオフにする
+
+`CONFIG_SEED_PATH` の設定を外しても、何も **解放されません** 。シードが適用されなくなるだけで、シードが管理していたレコードは管理対象のまま
+読み取り専用で残ります。再び編集するには、先にそれらを解放してください。 `CONFIG_SEED_PATH` をそれらを含まないファイルに向け（空のファイルは何も宣言せず、
+すべてのレコードを解放します）、起動時または再読み込みで適用させてから、変数の設定を外します。解放されたレコードはそのまま
+残り、編集可能になります。
diff --git a/i18n/ja/_configure/seed/reloading.md b/i18n/ja/_configure/seed/reloading.md
new file mode 100644
index 0000000..57b418c
--- /dev/null
+++ b/i18n/ja/_configure/seed/reloading.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: 再読み込みと起動
+parent: 構成シード
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# 再読み込みと起動
+{: .no_toc }
+
+再起動なしでのファイルの変更と、起動時に起きること
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 再起動せずにファイルを変更する
+
+シードは `CONFIG_SEED_RELOAD_SECONDS` ごと（既定は 60、 `0` でオフ）に読み直され、
+内容が変わっていれば再適用されます。そのため、git にコミットした変更は実行中のインスタンスに
+自動的に届きます。Kubernetes では、 `ConfigMap` は約 1 分以内に Pod の下に再マウントされ、
+次の確認でそれが取り込まれます。ロールアウトも再起動も不要で、何かを呼び出すフックも
+必要ありません。
+
+変更されていないファイルの場合、ポーリングはハッシュを一つ計算して止まるので、すでに適用した行を
+書き直すことはありません。
+
+次の確認を待たずにすぐファイルを適用するには、次のどちらかを使います。
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+どちらも、ファイルが変わっていなくても適用を **強制** します。強制した適用では、データベースで直接編集された
+管理対象のレコードが再び適用され、作業ツリーがない宣言済みのリポジトリが再びクローンされます。
+
+{: .note }
+> 起動時の適用と違い、再読み込みが **致命的になることはありません** 。すでにサービスを提供しているインスタンスは
+> 現在の設定を保ち、理由がログに記録され、ステータスページの *Config seed* の行が赤くなってその理由を
+> 示します。git にプッシュした誤字のせいで、運用者が何もしないうちに実行中のインスタンスが停止することがあってはなりません。
+>
+> 同じ壊れた内容が確認のたびに再試行されることもありません。そうでなければ、一つの誤った編集で同じエラーが
+> 際限なくログに書き込まれてしまいます。ファイルを修正するか、エンドポイントを呼び出してすぐに再試行してください。
+
+---
+
+## 壊れたシードは起動を拒否する
+
+読み取れないファイル、無効な YAML、不明なフィールド、重複した名前、解決できない
+`${VARIABLE}` があると、サーバーは起動せずに **終了** します。これは **起動時** の経路だけです。
+すでに稼働しているインスタンスに同じファイルが与える影響については、上の注記を参照してください。
+
+これは意図的です。以前の設定のまま続行すると、そのインスタンスの動作は、それを記述するはずのマニフェストと
+一致しなくなり、しかもその不一致を報告するものが何もありません。理由はログファイルだけでなく標準エラーにも書き込まれるので、
+`kubectl logs` と `docker logs` で確認できます。
+
+検証は厳格です。不明なフィールドは無視されずに拒否され、エラーには
+問題のキーが示されます。
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## 空のデータベースは自分で構築される
+
+`ALLOW_SCHEMA_CREATION` がオン（既定）の場合、 **AnsibleForms のテーブルがまったくない** データベースでは、
+起動時にスキーマが作成されます。そのため、新しいデプロイメントは、誰かが手動で `/schema` エンドポイントを
+呼び出さなくても起動します。
+
+この前提条件は意図的に厳格です。スキーマの作成では **最初にすべてのテーブルが削除される** ので、
+完全に空のデータベースに対してしか実行されません。列が一つ欠けているデータベースや、テーブルはあってもユーザーアカウントがない
+データベースは、空では *なく* 、そのまま残されます。そうしたケースはスキーマのパッチが処理します。
diff --git a/i18n/ja/_configure/users-and-groups.md b/i18n/ja/_configure/users-and-groups.md
new file mode 100644
index 0000000..0f9f832
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: ユーザーとグループ
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# ユーザーとグループ
+{: .no_toc }
+
+ローカルのユーザーとグループ、その隣の LDAP とシングルサインオンのもの、そしてサインインのブロック
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。ロールオプション `showSettings` を使い、 **設定 > アクセス > ユーザー** と **グループ** で、サインインできるユーザーを管理します。
+
+組み込みの管理者、ログインの順序、ローカルアカウントのロールへの対応付けは [ローカルアカウント](authentication/local.html) にあります。
+
+---
+
+## このセクションの内容
+
+| ページ | 内容 |
+|---|---|
+| [ローカルユーザー](users-and-groups/local-user.html) | ローカルユーザーの追加と、そのページのタブ |
+| [複数のグループ](users-and-groups/several-groups.html) | 複数のグループに所属するローカルユーザーと、そのロール |
+| [ローカルグループ](users-and-groups/local-group.html) | ローカルグループのページとそのタブ |
+| [ディレクトリのユーザーとグループ](users-and-groups/directory.html) | 最後に確認された状態の、LDAP、Entra ID、OIDC のユーザーとグループ |
+| [サインインのブロック](users-and-groups/blocking-a-sign-in.html) | サインインを許可：何も削除せずにユーザーをブロックします |
+
+
+---
+
+## リスト
+
+**ユーザー** と **グループ** のリストには、ローカルのユーザーとグループと、その隣に LDAP とシングルサインオンのものが表示されます。
+
+LDAP、Entra ID、OIDC のユーザーやグループは、サインインした（またはサインインで確認された）時点、またはロールがそれを指定した時点で表示されます。
+**ソース** 列は、それぞれの取得元を示します：ローカル、LDAP、Microsoft Entra ID、OIDC。7.3.0 からは、 **ユーザー** のリストに
+**最終サインイン** 列もあり、各ユーザーが最後にサインインした日時がわかります。
+
+行をクリックすると、そのユーザーまたはグループのページが開きます。 **ユーザーを追加** と **グループを追加** でローカルのものを作成します。
+
+---
+
+## 管理者権限を与えるアカウント
+
+config.yaml の admin ロールはローカルのグループとユーザーを指定するので、それが指定するアカウントとグループを変更できるのは管理者だけです。
+
+`showSettings` を持ち admin ロールを持たないユーザーは、admin ロールが（直接、またはそのグループのいずれかを通じて）指定するローカルアカウントの
+変更、ブロック、グループの変更、パスワードの設定、削除ができません。admin ロールが指定するグループの作成、名前の変更、削除や、
+そこへのユーザーの追加もできません。admin ロールに対応付けられる LDAP や SSO のユーザーも同様です。そのブロック、
+セッションの終了、削除、API トークンの取り消しは管理者が行います。サーバーはそうしたリクエストに `403` を返します。
+
diff --git a/i18n/ja/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/ja/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..dea0fc4
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: サインインのブロック
+parent: ユーザーとグループ
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# サインインのブロック
+{: .no_toc }
+
+サインインを許可：何も削除せずにユーザーをブロックします
+{: .fs-6 .fw-300 }
+
+**サインインを許可** スイッチは、ローカルのユーザーでもディレクトリのユーザーでも、何も削除せずにブロックします。
+
+確認の後でオフにすると、ユーザーのセッションはすぐに終了し、再びオンにするまですべてのサインインが拒否されます。
+ユーザーのリストでは、各行のメニューにある **サインインをブロック** と **サインインを許可** で同じことができます。
+
+ユーザー `admin` と、自分自身のサインインはブロックできません。
diff --git a/i18n/ja/_configure/users-and-groups/directory.md b/i18n/ja/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..6d010d8
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: ディレクトリのユーザーとグループ
+parent: ユーザーとグループ
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# ディレクトリのユーザーとグループ
+{: .no_toc }
+
+最後に確認された状態の、LDAP、Entra ID、OIDC のユーザーとグループ
+{: .fs-6 .fw-300 }
+
+LDAP、Entra ID、OIDC のユーザーのページは `/settings/users/<source>/<name>` にあり、ソースは `ldap` 、 `azuread` 、 `oidc` のいずれかです。
+たとえば `/settings/users/ldap/jdoe` です。ページには、ユーザーの最後のサインイン時に記録された内容が読み取り専用で表示されます。
+ユーザーが誰であるかとそのグループは、ディレクトリまたは ID プロバイダーが管理しているためです。
+
+タブはローカルユーザーと同じです。 **詳細** には **サインインを許可** スイッチ、ユーザー名、ソース、名前、
+メールアドレス、ユーザーが初めて確認された日時（初回確認）、最終サインインがあります。 **グループ** には最後のサインインのグループが表示されます。
+**API トークン** にはユーザーの API トークンが表示され、 **取り消す** で一つをすぐに終了します。
+
+右上の **セッションを終了** は、ユーザーをすべての場所から今すぐサインアウトさせます。 **削除** はレコードを削除しますが、レコードは
+次のサインインで戻ってきます。そのジョブ、保存済みジョブ、スケジュールは残ります。ブロックされたユーザーは削除できません。
+削除すると再び入れてしまうためです。サーバーは `409` を返すので、先にサインインを許可してください。
+
+このレコードのグループは、ユーザーのセッションがライブで読み込んで使うグループでもあります。サインイン中のユーザーを削除すると、
+再びサインインするまで、グループも、そのグループが与えるロールも持たない状態になります。
+
+ディレクトリのグループのページは `/settings/groups/<source>/<name>` にあり、読み取り専用で、タブは **詳細** 、
+**ユーザー** （最後のサインイン時にそのグループで確認されたユーザー）、 **ロール** 、 **フォーム** です。
diff --git a/i18n/ja/_configure/users-and-groups/local-group.md b/i18n/ja/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..fdd855a
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: ローカルグループ
+parent: ユーザーとグループ
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# ローカルグループ
+{: .no_toc }
+
+ローカルグループのページとそのタブ
+{: .fs-6 .fw-300 }
+
+グループのページ `/settings/groups/<id>` には、次のタブがあります。
+
+| タブ | 表示内容 |
+|---|---|
+| **詳細** | 名前と説明 |
+| **ユーザー** | グループのユーザー。 **ユーザーを追加** で追加し、行のメニューまたはチェックボックスで外します |
+| **ロール** | そのグループを指定しているロール |
+| **フォーム** | それらのロールで開けるフォーム |
+
+ユーザーのいるグループは削除できません。先にユーザーを外してください。 `admins` グループは削除も名前の変更もできません。
diff --git a/i18n/ja/_configure/users-and-groups/local-user.md b/i18n/ja/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..bc66198
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: ローカルユーザー
+parent: ユーザーとグループ
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# ローカルユーザー
+{: .no_toc }
+
+ローカルユーザーの追加と、そのページのタブ
+{: .fs-6 .fw-300 }
+
+**ユーザーを追加** を押すと、3 ステップのウィザードが開きます： **ユーザー** （ユーザー名、説明、メールアドレス）、 **パスワード** 、 **グループ** 。
+
+ユーザーのページ `/settings/users/<id>` には、次のタブがあります。
+
+| タブ | 表示内容 |
+|---|---|
+| **詳細** | **サインインを許可** スイッチ、ユーザー名、説明、メールアドレス、そして 7.3.0 からは **最終サインイン** |
+| **グループ** | ユーザーが所属するグループ |
+| **ロール** | ユーザーが持つロールと、それぞれを与えているもの： **直接** 、グループ **経由** 、または **全員** |
+| **フォーム** | それらのロールで開けるフォーム |
+| **ジョブ** | ユーザーが起動したジョブ。新しい順 |
+| **保存済みジョブ** | ユーザーが再実行用に保存したフォームの値 |
+| **スケジュール** | ユーザーが後で実行で計画したジョブ |
+| **アクティビティ** | 監査ログに記録されたユーザーの操作 |
+| **API トークン** | ユーザーの API トークンと、それぞれの作成日時、有効期限、最終使用日時。 **取り消す** で一つをすぐに終了します |
+
+7.3.0 からは、LDAP や SSO のユーザーと同じく、ローカルユーザーのサインインも記録されます。 **最終サインイン** には最新のものが表示され、
+ユーザーのリストにはすべてのソースについて並べ替え可能な **最終サインイン** 列があるので、誰も使っていないアカウントが目立ちます。拒否されたサインインは
+記録されず、アップグレード以降サインインしていないローカルユーザーには `–` が表示されます。
+
+右上に **パスワードの変更** と **削除** があります。ユーザー `admin` は削除も名前の変更もできません。
diff --git a/i18n/ja/_configure/users-and-groups/several-groups.md b/i18n/ja/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..2f01151
--- /dev/null
+++ b/i18n/ja/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: 複数のグループ
+parent: ユーザーとグループ
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# 複数のグループ
+{: .no_toc }
+
+複数のグループに所属するローカルユーザーと、そのロール
+{: .fs-6 .fw-300 }
+
+ローカルユーザーは複数のグループに所属でき、そのすべてのグループのロールが付与されます。ロールではグループを `local/<group>` と指定します。
+
+**グループ** タブでは、 **グループを追加** でユーザーを別のグループに追加し、行のメニューまたはチェックボックスで外します。
+ユーザーには少なくとも一つのグループが残ります。ユーザーのリストでは、各行のメニューにある **グループに追加** で同じことができます。
diff --git a/i18n/ja/_get_started/first-form.md b/i18n/ja/_get_started/first-form.md
new file mode 100644
index 0000000..0d8fe43
--- /dev/null
+++ b/i18n/ja/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: 最初のフォーム
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# 最初のフォーム
+{: .no_toc }
+
+プレイブックを書き、デザイナーでそのフォームを作り、起動してジョブを確認します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+このチュートリアルは新規インストールした状態から始めます。 [インストール](installation/) を参照してください。所要時間は 15 分ほどです。
+
+---
+
+## 1. ログインする
+
+ブラウザーで AnsibleForms を開き、管理者としてログインします。
+
+既定のアカウントは `admin` / `AnsibleForms!123` （または [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME) に設定した値）です。 **フォーム** ページが開きます。
+
+![サンプルフォームが表示された「フォーム」ページ](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. プレイブックを書く
+
+`ansible` フォームは playbooks フォルダーにあるプレイブックを実行するので、先にプレイブックを用意します。次の内容を `hello.yaml` として保存します。
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+このプレイブックは 4 つの変数を読み取ります。次に作るフォームが、フィールドごとに 1 つずつ extravars として送ります。
+
+ファイルは永続フォルダー（ [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) ）の `playbooks` フォルダーに置きます。
+フォルダーがまだない場合は作成してください。
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">ソースから</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+`/app/dist/persistent` にマウントしたフォルダーです。インストールの例では `/srv/apps/ansibleforms/persistent` です。
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+docker-compose プロジェクトの `data/playbooks` フォルダーです。
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+AnsibleForms の Pod の `/app/dist/persistent` にマウントされた永続ボリュームです。Pod の名前を調べてから、ファイルをコピーします。
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+サーバーの `persistent/playbooks` フォルダーです。インストールの例では `/srv/apps/ansibleforms/server` にあります。
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Git リポジトリで **playbook に使用しますか?** をオンにしている場合、プレイブックはそのリポジトリから実行されます。
+> その場合は `hello.yaml` をそのリポジトリにコミットしてください。 [デザイナーと Git](gui/designer-and-git.html) を参照してください。
+
+---
+
+## 3. フォームを作成する
+
+フォームは forms フォルダーにある YAML ファイルです。デザイナーはブラウザー上でこれを編集し、保存する前にチェックします。
+
+1. 上部メニューの **デザイナー** をクリックし、左メニューの **フォーム** をクリックします。
+2. 右上のスイッチ（ **デザイナーを開始** ）をクリックします。設定がロックされ、ほかの人が同時に編集できなくなります。
+   表示は **自分がロック中** に変わります。
+3. ツールバーの最初のボタン **新しいファイル** をクリックし、ファイル名 `hello-world.yaml` を入力します。デザイナーは
+   `New Form` という名前のフォームをそこに追加します。
+4. エディターの YAML を次のフォームに置き換えます。
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. **検証** （チェックマーク）をクリックし、次に **保存** をクリックします。保存すると `hello-world.yaml` が forms フォルダーに書き込まれます。
+6. もう一度スイッチをクリックしてロックを解除します。
+
+![フォームを編集中のデザイナー](assets/screenshots/designer.jpg)
+
+このフォームでは 4 種類のフィールドを使っています。
+
+| フィールド | 種類 | 内容 |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | 必須のテキストボックス |
+| `target_env` | [`enum`](formfields/enum.html) | `values` の固定リストから選ぶドロップダウン |
+| `vm_size` | [`enum`](formfields/enum.html) | ローカルの [式](expressions/local.html) で値を埋めるドロップダウン。 `__auto__` は最初の項目を選択します |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | チェックボックス。 `true` または `false` として送られます |
+
+`vm_size` は `size` と `cpus` の 2 列を表示し、最初の列である `size` を送ります。別の列を送るには `valueColumn` を指定します。
+
+`roles: [default]` でログインしたすべてのユーザーがこのフォームを実行できるようになり、 `categories: [Default]` で既定の
+`config.yaml` が定義しているカテゴリにフォームが入ります。
+
+{: .note }
+> `hello-world.yaml` を [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) にコピーし、 [VS Code で検証する](faq.html#vs-code-validation-for-form-files) こともできます。
+
+---
+
+## 4. 起動する
+
+**フォーム** ページからフォームを開きます。上部メニューの **フォーム** をクリックし、 **Default** カテゴリの **Hello world** を選びます。
+
+名前を入力し、必要ならほかのフィールドも変更します。 **Extravars を表示** をクリックするとプレイブックが受け取る内容を確認できます。
+最後に **送信** をクリックします。
+
+![フォーム](assets/screenshots/form.jpg)
+
+---
+
+## 5. 出力を確認する
+
+ジョブはすぐに開始され、実行中の出力がフォームの下に表示されます。最後に **完了** のバーが表示されます。
+
+![ジョブの出力](assets/screenshots/run.jpg)
+
+debug タスクが入力した値を表示します。たとえば `Hello Alice: a small machine in development (dry run: True)` です。
+
+インベントリがない場合、暗黙の localhost に関する警告が出ますが、これは想定どおりです。実際のフォームでは [`inventory`](forms/ansible.html) を設定します。
+
+---
+
+## 6. ジョブ履歴で見つける
+
+起動はすべてジョブとして記録されます。上部メニューの **ジョブ** をクリックすると、 **すべてのジョブ** の先頭に新しいジョブがあります。
+
+ジョブをクリックすると出力をもう一度確認でき、 **Extravars を表示** で送られた内容を確認できます。各ジョブの前にあるアイコンで、
+ジョブを再起動または削除できます。
+
+![ジョブ履歴](assets/screenshots/job-output.jpg)
+
+---
+
+## 次のステップ
+
+リファレンスページを参考に、このフォームを発展させてください。
+
+* **[フォーム](forms/)** : フォームのすべてのプロパティ、ランナー上のテンプレート、ワークフローフォーム、承認ポイント、通知
+* **[フォームフィールド](formfields/)** : すべてのフィールドの種類と、検証、依存関係、レイアウト
+* **[式](expressions/)** : REST API、データベース、ファイルからフィールドを埋める
+* **[ロール](config/roles.html)** と `config.yaml` の **[カテゴリ](config/categories.html)** : 誰がどのフォームを見られるかを決める
+* **[仕組み](how-it-works.html)** : 起動の裏側で何が起きるか、そしてすべてがどこに保存されるか
diff --git a/i18n/ja/_get_started/installation/docker-compose.md b/i18n/ja/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..4337081
--- /dev/null
+++ b/i18n/ja/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: インストール
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+docker-compose または podman-compose で AnsibleForms、その RTE、MySQL をまとめてインストールします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+[docker-compose プロジェクト](https://github.com/ansibleforms/docker) は 3 つのコンテナーを実行します。MySQL、AnsibleForms アプリ、そしてプレイブックを実行する RTE
+（ランタイム環境）です。設定、サンプルフォーム、プレイブックもこのプロジェクトに含まれているため、ほかに必要なのは
+Docker または Podman とその compose ツールだけです。
+
+[インストーラー](installer.html) は 1 つのコマンドでこのプロジェクトをダウンロードし、設定とシークレットを埋めて起動します。このページでは
+手動で構築する方法を説明します。
+
+---
+
+## 前提条件
+
+始める前に、次のものが必要です。
+
+* **Linux マシン** : どのディストリビューションでもよく、CPU とメモリは控えめで構いません
+* **GitHub へのアクセス** : GitHub から docker-compose プロジェクトをダウンロードまたはクローンするため
+* **Docker または Podman** : コンテナーエンジン。インストール方法は後述します
+* **compose ツール** : Docker Compose または podman-compose。いくつかの設定ファイルから 3 つのコンテナーを起動します
+
+**動画**: [AnsibleForms のインストール方法](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## インストール先を決める
+
+プロジェクト用のフォルダーを作成します。例では `/srv/apps` を使います。
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## docker-compose プロジェクトをクローンする
+
+Git をインストールします。
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+次に、docker-compose プロジェクトをそのフォルダーにクローンします。
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## 適切な権限を設定する
+
+アプリと RTE はユーザー `node` （uid 1000）として動作するため、 `data` フォルダーの所有者をこのユーザーにします。
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+コンテナーが root で動いていた 6 から移行する場合は、7 を起動する前に同じ `chown` を一度実行してください。MySQL は起動時に自分のフォルダーの所有権を取り戻します。
+
+---
+
+## コンテナーエンジンをインストールする
+
+Docker または Podman を、それぞれの compose ツールと一緒にインストールします。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Docker のリポジトリから Docker Engine と Compose プラグインをインストールします
+（ [Docker のインストールマニュアル](https://docs.docker.com/engine/install) を参照）。
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+次に、コンテナー内で名前解決できるようにし、Docker をサービスとして起動します。
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman にはサービスが必要ありません。podman-compose と一緒にインストールします。
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## カスタマイズする
+
+`.env` と `docker-compose.yml` の変数を確認し、すべてのパスワードを変更します。対象は `MYSQLDB_ROOT_PASSWORD` 、
+`MYSQLDB_PASSWORD` 、 `ADMIN_PASSWORD` 、 `RTE_TOKEN` です。 [環境変数の詳細](../customization)
+
+アプリは `ansibleforms` （ `MYSQLDB_USER` ）として MySQL に接続します。このユーザーは `AnsibleForms` スキーマに対するすべての権限を持ち、
+それ以外には権限を持ちません。root は MySQL 自体のためだけに使います。MySQL はこのユーザーを初回起動時にのみ作成します。これまで root で接続していた
+インストールでは、プロジェクトの [README](https://github.com/ansibleforms/docker#database) にあるとおり、一度だけ作成してください。
+
+RTE はホストに公開されません。7.3.0 以降、アプリは `RTE_TOKEN` を使って `http://rte:8000` の RTE に接続し、1 本の WebSocket を開いたままにします
+（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）。RTE はデータベースの設定も `.env` も受け取らず、受け取るのはトークンと
+`docker-compose.yml` にある自分用のいくつかの設定だけです。設定シード `data/seed.yaml` は、トークンとそのアドレスを持つ RTE の認証情報と、
+それでサインインするモード inbound の既定のランナー `rte` を宣言しています。RTE は同じ `data` フォルダーからプレイブックを実行します
+（ `RTE_FILES=local` ）。プレイブックにさらにコレクションや Python ライブラリが必要な場合は、独自の RTE をビルドし、
+`rte` サービスがそれを使うように設定してください（ [独自の RTE をビルドする](../rte/images.html#build-your-own-rte) を参照）。
+
+---
+
+## docker-compose プロジェクトを起動する
+
+3 つのコンテナーをバックグラウンドで起動します。アプリは MySQL が正常になるまで待ち、それから RTE に接続します。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## アプリケーションをテストする
+
+コンテナーが起動したら、ブラウザーで AnsibleForms を開きます。
+
+* `https://your_ip` を開きます（ポート 443。.env ファイルの `WEBAPP_LOCAL_PORT` を参照）
+* `.env` ファイルの `ADMIN_PASSWORD` を使って `admin` でログインします。既定の `AnsibleForms!123` のままであれば、新しいパスワードを設定してください
+* **接続 > ランナー** で、RTE が既定のランナー `rte` として一覧にあり、そのページで
+  **接続** が **接続済み** になっていることを確認します
+* 次のステップ:
+  * data/forms/ フォルダーに YAML ファイルを追加するか、組み込みのデザイナーを使ってフォームを作成します
+  * data/playbooks/ フォルダーにプレイブックを追加します
+  * LDAP 接続を追加します
+  * ユーザーとグループを追加します
+  * テンプレートフォーム用のランナーを追加します: AWX、AAP または Ascender、Semaphore、Rundeck、Jenkins
+  * ほかの MySQL サーバーや REST API などの外部接続用、または Ansible プレイブックに渡すための認証情報を追加します
+  * Git リポジトリを接続し、フォームやプレイブックをリポジトリと同期するかどうかを選びます
+
+---
+
+## ファイル構成
+
+docker-compose プロジェクトのフォルダー構成は次のとおりです。
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/ja/_get_started/installation/docker.md b/i18n/ja/_get_started/installation/docker.md
new file mode 100644
index 0000000..18fdb64
--- /dev/null
+++ b/i18n/ja/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: インストール
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Docker または Podman で AnsibleForms のアプリと RTE のイメージを実行し、自前の MySQL サーバーと組み合わせます
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+AnsibleForms は Docker または Podman で 2 つのコンテナーとして実行できます。アプリと、プレイブックを実行する RTE で、どちらも MySQL データベースに接続します。
+
+---
+
+## 前提条件
+
+始める前に、次のものが必要です。
+
+* **Docker または Podman** : どちらかがインストールされ、動作していること
+* **MySQL** : インストールされ、動作していること
+
+---
+
+## MySQL をインストールする
+
+コンテナーから到達できる Linux サーバーに MySQL 8 以上、または MariaDB をインストールします。
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu には MySQL 8 が含まれています。
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian には MySQL の代わりに MariaDB が含まれており、AnsibleForms はこれにも対応しています。
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 以降とそのリビルド版には、AppStream に MySQL 8 が含まれています。
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms はネットワーク経由で、 `DB_USER` と `DB_PASSWORD` を使ってデータベースに接続します。root ではなく専用のユーザーを用意し、
+`AnsibleForms` スキーマに対する権限だけを与えてください。
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+AnsibleForms に必要なのはこれだけです。この権限でスキーマを作成・更新し、バックアップを取ります。ユーザーがすべてのデータベースに権限を持っている場合は、
+**ステータス** ページとログに警告が出ます。Ubuntu と Debian ではサーバーが localhost でしか待ち受けないため、設定で `bind-address` を指定して
+コンテナーから到達できるようにしてください。
+
+---
+
+## フォルダーを準備する
+
+AnsibleForms 7 は 2 つのコンテナーで動作します。アプリと、プレイブックを実行する RTE（ランタイム環境）です。どちらも
+`config.yaml` 、フォーム、プレイブック、ログ、証明書を置くフォルダーと、SSH キー用のフォルダーをマウントします。イメージはユーザー `node` （uid 1000）として動作するため、
+両方のフォルダーの所有者をこのユーザーにします。
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+アプリの設定は環境ファイルに書きます。データベースの接続先、認証情報を保存する前に設定する
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) 、アプリと
+RTE が共有するトークン（ [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) 、16 文字以上）、そして RTE を宣言する設定シードです。
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+RTE にはデータベースの設定を含まない専用のファイルを用意します。7.3.0 以降はアプリが RTE に接続して 1 本の WebSocket を開いたままにし
+（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）、RTE は同じフォルダーからプレイブックを実行します（ `RTE_FILES=local` ）。
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+[設定シード](../seed/) は、RTE のアドレスとトークンを持つ RTE の認証情報と、それでサインインする既定のランナー `rte` を
+宣言します。
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## コンテナーを起動する
+
+GitHub Container Registry で公開されているイメージを実行します（ [イメージタグ](./#image-tags) を参照）。アプリには
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) 、RTE には
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) を使います。
+
+シードによって RTE が **接続 > ランナー** に既定のランナー `rte` として追加されるため、プレイブックのフォームは追加の設定なしでこの RTE で
+実行されます。アプリは初回起動時にスキーマを作成し、両方が動き出すと RTE に接続します（サンプルの `config.yaml` は
+[docker-compose プロジェクト](https://github.com/ansibleforms/docker/blob/main/data/config.yaml) にあります）。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+起動すると、両方のコンテナーが一覧に表示されます。
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman は同じオプションを受け付け、サービスを必要としません。
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+起動すると、両方のコンテナーが一覧に表示されます。
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+アプリはポート `8000` で待ち受けます。 `HTTPS=1` を設定しない限り HTTP です。RTE はホストに公開されず、ネットワーク内でアプリだけが
+RTE に接続します。 `--stop-timeout 30` は、停止時に RTE が実行中のプレイブックを終わらせる時間を与えます（RTE の設定と独自の RTE のビルドについては
+[RTE を実行する](../rte/run.html) を参照）。
+
+---
+
+## アプリケーションをテストする
+
+コンテナーが起動したら、ブラウザーで AnsibleForms を開きます。
+
+* `http://your_ip:8000` を開きます（ `HTTPS=1` を設定した場合は HTTPS）
+* `admin` / `AnsibleForms!123` （または `ADMIN_PASSWORD` で設定したパスワード）でログインし、新しいパスワードを設定します
+* **接続 > ランナー** で、RTE が既定のランナー `rte` として一覧にあり、そのページで
+  **接続** が **接続済み** になっていることを確認します
+* 次のステップ:
+  * `forms` フォルダーに YAML ファイルを追加するか、組み込みのデザイナーを使ってフォームを作成します
+  * マウントした永続フォルダーの `playbooks` フォルダーにプレイブックを追加します
+  * LDAP 接続を追加します
+  * ユーザーとグループを追加します
+  * テンプレートフォーム用のランナーを追加します: AWX、AAP または Ascender、Semaphore、Rundeck、Jenkins
+  * ほかの MySQL サーバーや REST API などの外部接続用、または Ansible プレイブックに渡すための認証情報を追加します
diff --git a/i18n/ja/_get_started/installation/from-source.md b/i18n/ja/_get_started/installation/from-source.md
new file mode 100644
index 0000000..8a4d49c
--- /dev/null
+++ b/i18n/ja/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: ソースから
+parent: インストール
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# ソースから
+{: .no_toc }
+
+AnsibleForms をソースからビルドし、Node.js で実行します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## コードの構成
+
+リポジトリには 2 つの Node.js アプリケーションが含まれており、ビルドでそれらを 1 つにまとめます。
+
+* **client** : Web インターフェース。Vue 3 で書かれ、Vite で静的ファイルにビルドされます
+* **server** : API。Express で書かれています。ジョブをランナーに渡し、データベースに接続し、ビルドしたクライアントを配信します。
+  `AF_ROLE=rte` で起動すると、同じサーバーがプレイブックを実行する RTE（ランタイム環境）になります
+
+ビルドするのはクライアントだけです。その出力は [Docker イメージ](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile) と同じく、サーバーの `views` フォルダーに入ります。
+
+---
+
+## 前提条件
+
+ソースからビルドして実行するには、Linux の確かなスキルと Node.js についてある程度の知識が必要です。すべてのコンポーネントを自分でインストールします。
+コンテナーを使わず、ビルドもせずに AnsibleForms を動かしたい場合は、インストーラーの [ネイティブインストール](native.html) がこれをすべて代わりに行います。
+
+* **Node.js 26** （ `.nvmrc` のバージョン。最低でも 24）と npm
+* **Git** 。コードの取得とリポジトリの同期に使います
+* **OpenSSH クライアント** （SSH 経由の git 用）と **sshpass** （SSH パスワードで接続するプレイブック用）
+* **MariaDB クライアント** （ `mariadb` 、 `mariadb-dump` ）。バックアップと復元に使います。MySQL サーバーの場合も必要です
+* **MySQL 8 以上または MariaDB** 。サーバーから到達できること
+* **Ansible** 。プレイブックを実行する RTE プロセス用です（パス上に `ansible-playbook` ）。アプリのプロセス自体には
+  Ansible も Python も不要で、テンプレートフォーム（AWX、AAP、Ascender、その他のランナー）だけなら RTE はまったく不要です
+
+ディストリビューションに合わせてインストールします。
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 は NodeSource のリポジトリから、その他のツールは Ubuntu 自体から入手します。
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 は NodeSource のリポジトリから、その他のツールは Debian 自体から入手します。
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js は NodeSource から、 `sshpass` は EPEL から入手します（RHEL 自体では、Red Hat のドキュメントに従って EPEL を有効にします）。
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+`node --version` （26）と `ansible-playbook --version` を確認します。データベースとそのユーザーについては [MySQL をインストールする](docker.html#install-mysql) を参照してください。
+
+---
+
+## コードを取得する
+
+アプリケーションを実行するユーザーが所有する任意のフォルダーに、リポジトリをクローンします。例では `/srv/apps/ansibleforms` を使います。
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## ビルドする
+
+リポジトリのフォルダーから 3 つのステップでビルドします。まずクライアントをビルドします。
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+次にサーバーの依存関係をインストールします。
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+最後に、ビルドしたクライアントをサーバーの `views` フォルダーにコピーします。
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## 設定する
+
+サーバーは環境変数から設定を読み取ります。本番環境では、設定ページが書き込むファイル `server/persistent/.env` からも
+読み取ります。
+
+リポジトリのルートにあるサンプルファイルから始め、少なくとも MySQL の接続設定（ `DB_HOST` 、 `DB_PORT` 、 `DB_USER` 、
+`DB_PASSWORD` ）を設定します。
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+すべての変数は [環境変数](../customization) で説明しています。それ以外のものは既定で `server/persistent` に保存されます。
+`config.yaml` 、 `forms` フォルダー、自己署名証明書は初回起動時にここに作成され、ログもここに置かれます。
+プレイブックは `server/persistent/playbooks` に置くか、それを読み取る RTE の環境で `ANSIBLE_PATH` を別の場所に向けてください。
+
+---
+
+## 実行する
+
+AnsibleForms を本番モードで実行するか、コード自体を開発する場合は開発モードで実行します。
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">本番</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">開発</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+`server` フォルダーからサーバーを本番モードで起動します。
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+コマンドラインから起動したアプリケーションは、ログオフすると停止します。 [PM2](https://pm2.keymetrics.io/) を使うと、
+バックグラウンドで動かし続け、クラッシュ後に再起動し、起動時にも自動で開始できます。
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+プレイブックは RTE で実行されます。同じサーバーを `AF_ROLE=rte` で、専用のポートでもう一度起動します。アプリは RTE に接続して
+1 本の WebSocket を開いたままにし（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）、RTE は同じフォルダーからプレイブックを実行します
+（ `RTE_FILES=local` ）。RTE も `persistent/.env` を読み取りますが、データベースの設定は一切使いません。アプリと RTE が共有する 16 文字以上のトークンと、
+RTE を宣言する設定シードを `persistent/.env` に追加します。
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+[設定シード](../seed/) は、RTE のアドレスとトークンを持つ RTE の認証情報と、それでサインインする既定のランナー `rte` を
+宣言します。
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+シードを使わない場合は、 **接続 > 認証情報** （そのアドレスとトークンを持つ RTE の認証情報）と
+**接続 > ランナー** （種類 RTE、 **モード** は **インバウンド** ）で追加します。その後、 `127.0.0.1` だけで RTE を起動します。
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+RTE の設定は [RTE を実行する](../rte/run.html) ページで説明しています。PM2 に両方のプロセスが表示されることを確認します。
+
+```bash
+pm2 status
+```
+
+どちらも `online` です。
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+コード自体を開発するには、リポジトリのルートからライブリロード付きですべてを起動します。サーバーはポート 3001、RTE はポート 8010、
+クライアントは `https://localhost:8443` です。このモードでは、サーバーと RTE は代わりに `server/.env.development` を読み取ります。
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+RTE（ `npm run dev:rte` ）にはパス上の `ansible-playbook` が必要で、非推奨のデータベースモードのランナーとして自分自身を追加します。これは
+開発専用です。 `npm run dev:local` は RTE なしでクライアントとサーバーを起動します。実行すべきテストとチェックは [コントリビューションガイド](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) に記載されています。
+
+</div>
+</div>
+
+---
+
+## 初回実行
+
+ブラウザーでサーバーを開きます（サンプルの `.env` では `https://your_ip:8443` ）。空のデータベースでは、初回起動時に
+スキーマが作成されます。
+
+既定の管理者の認証情報は次のとおりです。
+
+* ユーザー名 : `admin`
+* パスワード : `AnsibleForms!123`
diff --git a/i18n/ja/_get_started/installation/index.md b/i18n/ja/_get_started/installation/index.md
new file mode 100644
index 0000000..cd89b05
--- /dev/null
+++ b/i18n/ja/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: インストール
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# インストール
+{: .no_toc }
+
+AnsibleForms のインストール方法を選びます
+{: .fs-6 .fw-300 }
+
+---
+
+新しいインスタンスを構築する管理者向けです。インストール方法を選び、そのページの手順に従ってください。
+
+---
+
+## このセクションの内容
+
+AnsibleForms はいくつかのインストール方法に対応しており、それぞれ個別のページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [インストーラー](installer.html) | 1 つのコマンドでコントローラーまたはランナーを Docker、Podman、Kubernetes、またはネイティブにインストールし、その後のアップグレードとバックアップも行います |
+| [ネイティブ](native.html) | コンテナーを使わないインストーラーのインストール。サーバーに Node.js、MariaDB、Ansible を入れ、AnsibleForms を systemd サービスとして動かします |
+| [Docker](docker.html) | MySQL をインストールし、必要な環境変数を指定してビルド済みの Docker イメージを実行します |
+| [Docker Compose](docker-compose.html) | [docker-compose プロジェクト](https://github.com/ansibleforms/docker) をダウンロードし、docker-compose で MySQL と AnsibleForms の両方を起動します |
+| [ソースから](from-source.html) | すべての依存関係を手動でインストールし、コードをビルドして起動します |
+| [Kubernetes](kubernetes.html) | Helm チャートをインストールし、Kubernetes で AnsibleForms とその MySQL データベースを起動します |
+
+{: .note }
+> **推奨** 7.3.0 以降のインストーラーは、動作するインスタンスを最も早く用意できる方法です。いくつかの質問に答えるだけで、
+> Docker または Podman 上に Docker Compose プロジェクトを、あるいはほかの方法のいずれかを構成します。Docker イメージにはすべての依存関係が含まれています。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+既存のインストールを新しいリリースに移行するには、 [アップグレード](../upgrading/) を参照してください。
+
+どの方法でも、アプリの隣で 1 つの RTE が動きます。RTE はプレイブックを実行するコンテナー（またはサービス）です。別のホストや別の
+データセンターにもう 1 つ追加するには、 [インストーラー](installer.html#a-runner) でランナーをインストールします。ランナーは 1 本の WebSocket で AnsibleForms に接続し（アウトバウンド、
+[モード](../rte/modes.html) を参照）、データベースの認証情報は持ちません。 [ランタイム環境](../rte/) と、そのランブック
+[別のデータセンターにある RTE](../rte/another-datacenter.html) も参照してください。
+
+---
+
+## イメージタグ
+
+イメージは GitHub Container Registry に `ghcr.io/ansibleforms/ansibleforms` として公開されています。このレジストリは
+プロジェクトが所有しており、匿名の pull にレート制限はありません。7.0.0 以降のすべてのリリースはここでのみ公開され、6.x の
+リリースもここにあります。
+
+バージョン 7 以降、プレイブックは RTE で実行されます。RTE はアプリとは別に 3 つのレイヤーで公開されています（ [RTE イメージ](../rte/images.html) を参照）。
+
+| イメージ | 内容 |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | Web アプリケーションと API。python と ansible は含みません |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | python と ansible を含まない RTE。独自のイメージのベースです |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | ベースに python、ansible-core、いくつかのライブラリを加えたもの。コレクションを追加するならこれです |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | core に `ansible` パッケージ、そのコレクションとライブラリを加えたもの。既定の RTE です |
+
+4 つのイメージは同じ実行でビルドされ、同じタグが付くため、RTE のタグは常にアプリのタグと一致します。
+
+以前の Docker Hub リポジトリ `ansibleguy/ansibleforms` は更新されなくなりました。既存の
+リリースは残っていますが、どちらの系列の新しいバージョンも公開されません。そこから pull している場合は、同じタグのまま
+`ghcr.io/ansibleforms/ansibleforms` に切り替えると、引き続き更新を受け取れます。
+
+各イメージで次のタグを使用できます。RTE イメージは 7.0.0 から始まっているため、6.x のタグはありません。
+
+| タグ | 指す先 |
+|---|---|
+| `latest` | 最新のメジャーバージョンの最新リリース |
+| `7`, `6` | そのメジャーバージョンの最新リリース |
+| `7.0`, `6.5` | そのマイナーバージョンの最新リリース |
+| `7.0.0`, `6.5.5` | そのリリースそのもの |
+| `latest-rc` | 最新のリリース候補。それより新しいリリースがあればそのリリース。各候補には個別のタグもあります |
+
+`latest` は前にしか進みません。古いメジャーバージョンのパッチ（たとえば 7.0.0 の後にリリースされた
+6.5.x）は `6` と `6.5` を進めますが、 `latest` は動かしません。
+
+メジャーバージョンに留まるには、 `latest` ではなくその番号（ `6` ）を使います。
diff --git a/i18n/ja/_get_started/installation/installer.md b/i18n/ja/_get_started/installation/installer.md
new file mode 100644
index 0000000..a3543e1
--- /dev/null
+++ b/i18n/ja/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: インストーラー
+parent: インストール
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# インストーラー
+{: .no_toc }
+
+1 つのコマンドで、Linux サーバー上の AnsibleForms をインストール、アップグレード、管理します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者向けです。動作するインスタンスを用意する、あるいは別の場所にインストールされた AnsibleForms 用のランナーを用意する最も早い方法です。7.3.0 以降で使えます。
+
+---
+
+## インストールされるもの
+
+インストーラーはフルスクリーンのウィザードでいくつかの質問をし、すべての回答を確認のために表示してから、初めてサーバーを変更します。
+インストールするのは 2 つの役割のどちらかで、4 つのエンジンのいずれかの上に構築します。
+
+| 役割 | 内容 |
+|---|---|
+| コントローラー | アプリケーション一式です。Web インターフェース、そのデータベース、そして専用のランナーを含みます。初めてのインストールではこれを選びます |
+| ランナー | 別の場所にインストールされた AnsibleForms のプレイブックを実行する RTE です。別のネットワーク、DMZ、別のデータセンターなどに置きます。1 本の WebSocket で AnsibleForms と通信し、データベースの認証情報は持ちません |
+
+インストール先のエンジンは次のとおりです。
+
+| エンジン | 動作のしかた |
+|---|---|
+| Docker | Docker Engine とその compose プラグイン上の [Docker Compose プロジェクト](docker-compose.html) 。コンテナーは Docker と一緒に再起動します |
+| Podman | 同じプロジェクトを Podman 上で、rootless または root として、podman-compose で動かします。systemd ユニットが起動時にコンテナーを開始します |
+| Kubernetes | `kubectl` が接続するクラスター上の [Helm チャート](kubernetes.html) 。コントローラーは Ingress の背後で公開され、ランナーはチャートのランナーモードを使います |
+| このサーバーに直接 | コンテナーなし。サーバーに Node.js、MariaDB、Ansible を入れ、AnsibleForms を systemd サービスとして動かします。 [ネイティブインストール](native.html) を参照してください |
+
+インストール後は、同じプログラムでインストールのアップグレード、バックアップ、ステータス表示、削除を行えます。インストーラーが
+インストールしていない AnsibleForms、たとえば Docker Compose プロジェクトから手動で構築したものを引き継ぐこともできます（ [既存のインストール](#an-existing-installation) を参照）。
+
+---
+
+## 実行する
+
+インストールスクリプトがこのサーバー用のインストーラーをダウンロードして起動します。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+よく使うバリエーションは次のとおりです。Docker や Podman をインストールする場合、サーバーに直接インストールする場合、 `/opt` の下にインストールする場合は root として実行します。コマンドや
+フラグを付けて実行することもでき（ [フラグ](#flags) を参照）、最新版ではなく特定のリリースのインストーラーを使うこともできます。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+スクリプトの動作は次のとおりです。
+
+1. サーバーが amd64 または arm64 の Linux であることを確認し、 `curl` または `wget` と `sha256sum` を探します
+2. [ansibleforms/installer](https://github.com/ansibleforms/installer/releases) の最新リリース、または `AF_INSTALLER_VERSION` で指定したリリースから
+   `ansibleforms-installer_linux_<arch>` をダウンロードします
+3. リリースの `checksums.txt` と照合し、チェックサムが一致しないダウンロードは使いません
+4. 後のアップグレードやバックアップのために、root の場合は `/usr/local/bin` に、それ以外は `~/.local/bin` に `ansibleforms-installer` として保存します。
+   sudo 経由で実行するときはフルパスを指定してください。Red Hat 系のシステムのように、sudo の `secure_path` に `/usr/local/bin` が含まれていないことがよくあります
+5. 指定されたフラグで起動します。スクリプトがパイプ経由で渡されても、キーボード入力は端末から読み取ります
+
+CI ジョブなど端末がない環境では、インストーラーは無人で実行されます（ [無人実行](#unattended) を参照）。
+
+---
+
+## ウィザード
+
+ウィザードは一度に 1 つずつ質問し、左側にステップを表示します。 **Esc** で前のステップに戻ります。そのステップの回答は保持されます。
+
+| ステップ | 質問の内容 |
+|---|---|
+| 言語 | インストーラーの言語。既定ではこのサーバーのロケールから決まります。カタルーニャ語、ドイツ語、英語、スペイン語、フランス語、イタリア語、日本語、オランダ語、ポーランド語、ポルトガル語、中国語から選べます。見つかったインストールについてインストーラーが何か表示する前に、最初に質問します |
+| リリースノート | インストールするバージョンの新機能。互換性のない変更、削除、非推奨が先に表示されます |
+| 役割 | コントローラーまたはランナー |
+| エンジン | Docker、Podman、Kubernetes、またはこのサーバーに直接 |
+| フォルダー | インストール先フォルダーとインスタンス名 |
+| 参加、アプリ、モード | ランナーのみ。 [ランナー](#a-runner) を参照してください。Kubernetes ではモードは質問しません |
+| ネットワーク | Web インターフェースまたはランナーのポート。Kubernetes では質問しません |
+| HTTPS | ブラウザーがコントローラーに接続する方法 |
+| 管理者 | 最初の管理者のパスワード。2 回入力します |
+| クラスター、Ingress、ストレージ | Kubernetes のみ。Namespace とリリース、Ingress（コントローラーの場合）、ストレージクラス |
+| 確認 | すべての回答。 **インストール** または **回答を変更** |
+
+**エンジン。** 一覧にはこのサーバーにあるものが表示されます。ないエンジンは *Docker (未インストール: インストーラーが導入します)*
+のように表示され、Podman も同様です。確定すると、インストーラーは Docker を Docker 公式のスクリプト（ `get.docker.com` 、compose プラグイン
+付き）で、Podman をディストリビューションのパッケージから podman-compose と一緒にインストールします。これには root が必要です。Kubernetes は `kubectl` と
+`helm` がインストールされ、クラスターに接続できる場合に表示されます。 *このサーバーに直接* には root と対応する Linux が必要で、グレー表示のときはその理由が示されます。
+
+**フォルダー。** 既定値は次のとおりです。
+
+| | コントローラー | ランナー |
+|---|---|---|
+| フォルダー（root の場合） | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| フォルダー（その他のユーザーの場合） | `~/ansibleforms` | `~/ansibleforms-runner` |
+| インスタンス名（Docker または Podman） | `af` | `runner` |
+| インスタンス名（ネイティブ） | `ansibleforms` | `ansibleforms-runner` |
+
+Docker または Podman の場合、フォルダーには compose ファイルとシークレットを含む `.env` 、そしてデータベース、フォーム、プレイブック、
+ログといったすべてのデータが入ります。フォルダーは空でなければなりません。インスタンス名は英小文字、数字、 `-` で構成し、コンテナーの接頭辞になります（ `af_app` 、 `af_db` 、 `af_rte` ）。そのため、
+複数のインスタンスで 1 台のサーバーを共有できます。ランナーのインスタンス名は、 **接続 > ランナー** でのランナー名（ `RTE_NAME` ）にもなります。
+
+**ネットワーク。** コントローラーの Web インターフェースは `443` 、または次に空いているポートで待ち受けます。続いて **HTTPS** で次の選択肢が表示されます。
+
+| 選択肢 | 内容 |
+|---|---|
+| HTTPS、このサーバー用に作成する自己署名証明書 | このサーバーの名前に対する証明書で、10 年間有効です。ブラウザーで一度だけ受け入れる必要があります |
+| HTTPS、自分の証明書と鍵 | CA または Let's Encrypt から取得した、PEM 形式の自分の証明書と鍵 |
+| HTTP、HTTPS は前段のリバースプロキシで処理 | ポートでプレーンな HTTP を提供します。HTTPS を処理する nginx、Traefik、ロードバランサー向けです |
+
+**管理者。** `admin` ユーザーのパスワードです。入力ミスで締め出されないよう 2 回入力します。空のままにすると、インストーラーが
+強力なパスワードを生成します。
+
+**完了。** インストーラーはデータベースのパスワードとシークレットを生成し、AnsibleForms を起動して応答するまで待ちます。その後、
+開くアドレス、ユーザー、パスワード、フォルダーを表示します。このコントローラー用にインストールしたランナーは参加を求めるので、管理者が
+**接続 > ランナー** で承認します（ [ランナー](#a-runner) を参照）。
+
+---
+
+## ランナー
+
+ランナーは、別の場所で動いているバージョン 7.3.0 以降の AnsibleForms のための RTE です。データベースの認証情報は持たず、
+専用のトークンでサインインします。AnsibleForms はこのトークンを RTE の認証情報に保存します（ [モード](../rte/modes.html) を参照）。フォルダーの後、ウィザードは
+さらに 3 つのことを質問します。
+
+| ステップ | 質問の内容 |
+|---|---|
+| アプリ | このランナーが担当する AnsibleForms のアドレス。利用者がブラウザーで開くアドレスです |
+| モード | **アウトバウンド: ランナーが AnsibleForms に接続** （既定）、または **インバウンド: AnsibleForms がランナーに接続** |
+| ネットワーク | ランナーのポート。既定は `8000` です。アウトバウンドでは、ヘルスチェックだけがこのポートで待ち受け、このサーバーからしか到達できません。インバウンドでは、AnsibleForms から到達できるこのサーバーのアドレスも質問します |
+
+`--role runner` を付けると役割の質問が省略されるので、ランナーのサーバーで次のコマンドを実行すると、ランナーの質問から始まります。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+インストーラーは次に AnsibleForms に接続します。自己署名証明書やプライベート CA の証明書の場合は **この証明書を信頼しますか?** と質問され、
+はいと答えるとランナーに [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) が設定されます。インストーラーは AnsibleForms が動かしているバージョンを読み取り、
+7.3.0 より古ければ中止し、インストーラー自体が本来インストールするバージョンに関係なく、それと同じバージョンでランナーをインストールします。
+
+DMZ、NAT、または着信接続を許可しないゾーンではアウトバウンドを選びます。必要な通信は、このサーバーから AnsibleForms のポートへの
+通信だけです。中央側がすべての接続を開始するネットワークではインバウンドを選びます。
+
+確認画面には **登録: 承認を求めます** 、または `--join` で参加トークンを指定した場合は **自動 (参加トークン)** と表示されます。最後にインストーラーは
+ランナーの名前、モード、アプリ、インバウンドの場合はそのアドレスを表示し、AnsibleForms に参加を求めたことを伝えます。
+**接続 > ランナー** で、表示されるフィンガープリントがインストーラーの出力と同じであることを確認してから承認してください。
+
+```
+Fingerprint: abcd-ef12
+```
+
+フィンガープリントは、ランナーのトークン `RTE_TOKEN` の SHA-256 の先頭 16 進数 8 桁です。トークンはフォルダーの
+`.env` ファイル（ [ネイティブインストール](native.html) では `rte.env` ）に保存されています。 [RTE の承認](../runners/registration.html#approving-an-rte) を参照してください。 `--join` を使うと、ランナーはすぐに承認されます。
+ランナーは自分自身を登録し、 **接続 > ランナー** で接続済みとして表示されます。
+
+インバウンドのランナーは HTTPS でソケットを提供します。インストーラーは AnsibleForms から到達するアドレスに対する自己署名証明書を作成し
+（10 年間有効）、フォルダーの `data/certificates` に置き、 `RTE_URL` を `https://<address>:<port>` に設定します。
+ランナーは参加を求めるときに証明書を送り、AnsibleForms はそれをピン留めします。そのランナーが同じ証明書を提示した場合にのみ接続するので、
+CA は必要ありません。インストーラーはトークンのフィンガープリントの下に、証明書のフィンガープリントを表示します。
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+これは証明書の DER バイト列の SHA-256 の先頭 16 進数 8 桁で、 `xxxx-xxxx` の形式です。ランナーを承認する前に、
+承認ダイアログに同じ証明書のフィンガープリントが表示されていることを確認してください。 `--join` で登録したランナーも、これを表示します。
+
+Kubernetes では、ランナーは Helm チャートのランナーモードで、常にアウトバウンドです。外部から到達するものがないため、ウィザードはモードもネットワークも
+質問しません（ [Kubernetes](#kubernetes) を参照）。
+
+---
+
+## Kubernetes
+
+Kubernetes 上のコントローラーでは、インストーラーは `kubectl` が接続するクラスターに [Helm チャート](kubernetes.html) をインストールします。
+
+| 質問 | 既定値 |
+|---|---|
+| Namespace | `ansibleforms` |
+| Helm リリース名 | `ansibleforms` |
+| Ingress で公開するホスト名 | なし。必須です。例 `ansibleforms.example.com` |
+| Ingress クラス | クラスターにあるもののいずれか。既定は `nginx` |
+| HTTPS で公開しますか (Ingress の証明書を使用)? | はい |
+| ボリュームのストレージクラス | クラスターの既定 |
+
+管理者のパスワードは、その Namespace の Secret `<release>-secrets` のキー `ADMIN_PASSWORD` にあります。インストーラーは
+チャートの values を状態ファイルの隣にあるファイル `<release>-values.yaml` に保存し、アップグレードのたびに再適用します。 `--values` で独自のファイルを追加できます。リリースのチャートは、リリースの少し後に公開されます。
+
+ランナーの場合、インストーラーは同じチャートを [ランナーモード](kubernetes.html#a-runner-on-kubernetes) （ `runner.enabled` ）でインストールします。アプリもデータベースも Ingress もない
+RTE だけの構成で、AnsibleForms に接続します（アウトバウンド）。アプリのアドレスの後、ウィザードは次を質問します。
+
+| 質問 | 既定値 |
+|---|---|
+| Namespace | `ansibleforms` |
+| Helm リリース名 | `ansibleforms-runner` 。これは **接続 > ランナー** でのランナー名にもなります |
+| ボリュームのストレージクラス | クラスターの既定 |
+
+インストーラーはランナーのトークンを作成し、アプリのアドレスとランナー名を設定します。アプリの証明書を信頼した場合は
+`runner.appTlsVerify: false` も設定します。 `--join` を使うと参加トークンでランナーがすぐに承認されます。使わない場合はランナーが参加を求め、
+インストーラーがフィンガープリントを表示するので、それを確認してから **接続 > ランナー** で承認します。
+
+---
+
+## コマンド
+
+インストーラーはフラグの前または後にコマンドを受け取ります。コマンドを指定しなければインストールを行います。
+
+| コマンド | 内容 |
+|---|---|
+| `install` | AnsibleForms をコントローラーまたはランナーとしてインストールします（既定）。すでにインストールがあるサーバーでは、自分がインストールしたものでも見つけたものでも、アップグレードを提案します |
+| `upgrade` | 新しいバージョンにアップグレードします。先にリリースノートを表示します（ [アップグレード](#upgrade) を参照） |
+| `status` | インストール（役割、エンジン、バージョン）と、そのコンテナー、Pod、サービス、応答するかどうかを表示します。その後、サーバー上で見つかったほかの AnsibleForms を一覧表示します |
+| `backup` | 今すぐデータベースをバックアップします。保存先はインストール先フォルダーの `installer-backups` です（Kubernetes ではインストーラーの状態ファイルの隣の `backups` ）。ランナーにはバックアップするデータがありません |
+| `release-notes` | バージョン（ `--version` またはこのインストーラーのバージョン）のリリースノートを表示します。互換性のない変更が先に表示されます |
+| `uninstall` | インストールを削除します。 `--purge` を付けるとデータも削除します |
+| `version` | インストーラーのバージョンを表示します |
+
+インストーラーはインストールの情報を、root の場合は `/etc/ansibleforms/installer.json` に、それ以外のユーザーの場合は `~/.config/ansibleforms/installer.json`
+に記録します。そのため、 `install` の後のコマンドにはフラグが不要で、自動的にインストールを見つけます。このフォルダーにバイナリは入っておらず、
+インストーラーが AnsibleForms をインストールするか引き継いだ後にだけ存在します。
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` は **データ (データベース、フォーム、プレイブック、ログ) も削除しますか?** と質問します。削除するには、インスタンス名（Kubernetes では Helm リリース）を
+入力します。それ以外の場合は、コンテナー、Pod、サービスを削除してデータは残します。
+
+---
+
+## フラグ
+
+各フラグは 1 つの質問に答えるもので、ウィザードはその質問を省略します。 `ansibleforms-installer --help` で一覧を表示できます。
+
+| フラグ | 答える質問 |
+|---|---|
+| `--lang <code>` | 言語。 `ca` 、 `de` 、 `en` 、 `es` 、 `fr` 、 `it` 、 `ja` 、 `nl` 、 `pl` 、 `pt` 、 `zh` のいずれか |
+| `--version <version>` | インストールまたはアップグレード先の AnsibleForms のバージョン。既定はこのインストーラーのバージョン |
+| `--role <role>` | `controller` または `runner` |
+| `--mode <mode>` | `compose` 、 `kubernetes` 、 `native` のいずれか |
+| `--runtime <runtime>` | `docker` または `podman` （compose） |
+| `--install-runtime` | Docker または Podman がない場合、質問せずにインストールします |
+| `--dir <folder>` | インストール先フォルダー（compose） |
+| `--name <name>` | インスタンス名。コンテナーの接頭辞になります（compose、既定は `af` ） |
+| `--port <port>` | ホスト上のポート。コントローラーでは Web インターフェース、ランナーでは RTE のポート |
+| `--tls <choice>` | `self` 、 `own` 、 `off` のいずれか（compose のコントローラー） |
+| `--cert <file>`, `--key <file>` | 証明書と鍵のファイル。 `--tls own` と一緒に使います |
+| `--admin-password <password>` | 最初の管理者のパスワード。既定では生成されます |
+| `--join <token>` | API で作成した参加トークン（ `afj_...` ）。ランナーをすぐに承認します（ランナー、無人実行。 [参加トークン](../runners/registration.html#join-tokens) を参照） |
+| `--app-url <address>` | アプリのアドレス。例 `https://forms.example.com` （ランナー） |
+| `--runner-mode <mode>` | `outbound` （RTE がアプリに接続）または `inbound` （アプリが RTE に接続）（ランナー） |
+| `--host <address>` | アプリが接続するこのサーバーのアドレス（インバウンドのランナー） |
+| `--namespace <namespace>` | Kubernetes の Namespace。既定は `ansibleforms` |
+| `--release <release>` | Helm リリース。既定は `ansibleforms` |
+| `--hostname <name>` | Ingress のホスト名（kubernetes） |
+| `--ingress-class <class>` | Ingress クラス（kubernetes） |
+| `--storage-class <class>` | ストレージクラス（kubernetes） |
+| `--values <file>` | 追加の Helm values ファイル（kubernetes） |
+| `--purge` | `uninstall` と一緒に使い、データも削除します |
+| `--source <folder>` | インストール元にする [ansibleforms/docker](https://github.com/ansibleforms/docker) リポジトリのローカルコピー（エアギャップ環境） |
+| `--bundle <file>` | ネイティブインストールに使うリリースバンドル `ansibleforms-<version>-linux-<arch>.tar.gz` （ [ネイティブインストール](native.html#air-gapped) を参照） |
+| `--yes` | すべての質問に既定値で答えます（無人実行） |
+| `--verbose` | 実行するすべてのコマンドを表示します |
+
+---
+
+## 無人実行
+
+`--yes` を付けるか端末がない場合、インストーラーは何も質問しません。フラグがそれぞれの質問に答え、残りは既定値で答えます。
+言語、リリースノート、管理者のパスワード（ `--admin-password` で指定しない限り生成されます）、確認を省略し、代わりに
+リリースノートへのリンクを表示します。Docker や Podman がない場合にインストールするのは `--install-runtime` または `--yes` があるときだけで、ランナーには
+`--app-url` が必要です。 `--join` がなければランナーは参加を求めて管理者の承認を待ち、あればすぐに承認されます。
+
+Docker 上のコントローラーで、Docker がなければインストールする例です。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Podman 上のインバウンドのランナーで、アプリが `rte-dmz.example.com:8000` に接続する例です。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## 既存のインストール
+
+インストーラーは、インストールしたものを `installer.json` に記録します。このファイルがない場合、 `install` 、 `upgrade` 、 `status` はまず、
+何でインストールされたかに関係なく、サーバー上にすでにある AnsibleForms を探します。
+
+| 見つかるもの | 見つけ方 | 引き継げる条件 |
+|---|---|---|
+| Docker または Podman | アプリまたは RTE のイメージのコンテナーを、compose プロジェクトごとにまとめて見つけます | フォルダーに [ansibleforms/docker](https://github.com/ansibleforms/docker) リポジトリの compose ファイルと `.env` があること。サービス `mysqldb` 、 `app` 、 `rte` が、コンテナー `<name>_db` 、 `<name>_app` 、 `<name>_rte` で動いていること |
+| 7.2 のランナー | compose プロジェクト内に単独で存在し、アプリの `DB_*` を持ち、 `RTE_MODE` がない RTE（データベースモード） | compose ファイルが読み取れること。アップグレードでソケットモードに移行します（ [7.2 のランナー](#a-72-runner) を参照） |
+| Kubernetes | `ansibleforms` チャートの Helm リリース、およびそのイメージの Deployment と StatefulSet | チャートのリリースであること。現在の values がその values ファイルになります |
+| ネイティブ | Node.js で AnsibleForms を実行している systemd サービス | インストーラーのレイアウトに従っていること。 `releases/` 、 `current` 、 `app.env` 、 `rte.env` （ [ネイティブインストール](native.html#the-folder) を参照） |
+| エンジンなし | 通常のポート（443、3000、3001、8000、8001、8010、8443）で応答するアプリまたは RTE | 引き継げません。ソースから、または手動で実行されています。インストーラーは報告するだけです |
+
+数えるのはアプリと RTE のイメージだけです。AnsibleForms にちなんだ名前の MySQL コンテナーはインストールとはみなしません。インストーラーは
+見つけたものを 1 行ずつ一覧表示し、その理由と、引き継げないものについては手動で行うべきことを示します。引き継げない理由には、compose ファイルがリポジトリのものではない、
+データベースが compose プロジェクトの外にある、Helm チャートを使わずに Kubernetes で動いている、Argo CD で管理されている（その場合は Application の
+チャートのバージョンを変更して、Argo CD 側でアップグレードします）、バージョンを読み取れない、といったものがあります。
+
+引き継げるインストールに対して、 `install` は 3 つの選択肢を示します。
+
+| 選択肢 | 内容 |
+|---|---|
+| 引き継いでアップグレード | 記録する内容を表示し、確定すると `installer.json` を書き込んで、 [アップグレード](#upgrade) に進みます |
+| それでも隣に新しい AnsibleForms をインストールする | 専用のフォルダー、ポート、データベースを持つ 2 つ目のインストールです。別途確認があります |
+| 中止 | 何も変更しません |
+
+インストーラーがインストールするはずのバージョンがすでに動いている場合、最初の選択肢は代わりに **引き継ぐ** になります。インストーラーは
+その場所と動作方法をバックアップ、ステータス、次回以降のアップグレードのために記録し、今は何も変更しません。
+
+`upgrade` も 2 つ目の選択肢を除いて同じ選択肢を示し、引き継げるものがなければ中止します。無人実行では `install` はメッセージを出して中止し、
+`upgrade --yes` は引き継げるインストールがちょうど 1 つ見つかった場合にのみ引き継ぎます。Kubernetes のリリースの現在の values は
+`installer.json` の隣に保存され、アップグレードでは新しいバージョンのチャートと一緒に再適用されます。
+
+---
+
+## アップグレード
+
+`ansibleforms-installer upgrade` は、インストールを同じメジャーバージョン内の新しいバージョンに移行します。新しいバージョンを
+新しい順に一覧表示し（無人実行では最新を選びます）、通過するすべてのバージョンのリリースノートを、互換性のない変更と
+削除を先頭にして表示します。互換性のない変更が含まれている場合は、読んだことの確認を求めます。無人実行では `--yes` がある場合にのみ続行します。
+
+インストーラーは何かを変更する前にデータベースをバックアップします。新しいバージョンが応答しない場合はロールバックを提案します。前の
+バージョンに戻り、データベースはそのバックアップから復元されます。ダウングレードはせず、メジャーバージョンもまたぎません。その場合は
+[アップグレードガイド](../upgrade-7.html) に従ってください。たとえば 6.x から 7.x へのアップグレードでは、アップグレード前に 6.5 で行うべきことも説明しています。
+
+Docker または Podman では、コントローラーのアップグレードでファイルも docker リポジトリの新しいバージョンに合わせて更新されます。
+
+| ファイル | アップグレードでの処理 |
+|---|---|
+| `docker-compose.yml` | `installer-backups` にコピーを保存した後、新しいバージョンのものに置き換えます |
+| `.env` | 既存の行はすべて残し、新しいバージョンに必要なキーを追加します。シークレットは新規インストールと同じように作成します。先にコピーを保存します |
+| `data/seed.yaml` | docker リポジトリが配布したシードが変更されていなければ置き換えます。手動で変更したものは残し、新しいものをその隣に保存します |
+| `data/` | 新しいプレイブックなど、そのバージョンで追加されたファイルを追加します。既存のファイルはすべて残します |
+
+データベースの設定（ `MYSQLDB_USER` やパスワード）が欠けている場合、既存のデータベースに対して作り出すことはできないため、アップグレードは
+何も変更する前に中止します。ロールバックでは compose ファイル、 `.env` 、シードが元に戻ります。
+
+ランナーはその AnsibleForms と同じバージョンで動作します。先に AnsibleForms をアップグレードし、次にそのランナーをアップグレードしてください。ランナーのアップグレードでは
+新しい RTE イメージ用に compose ファイルを書き換え、 `.env` とデータはそのまま残します。
+
+---
+
+## 7.2 のランナー
+
+7.2 のランナーは、7.3.0 以降非推奨のデータベースモードで動作します。その RTE は AnsibleForms のデータベース設定を持っています。インストーラーは
+これを見つけ（ [既存のインストール](#an-existing-installation) を参照）、アップグレードで同じランナーのままソケットモードに移行します。
+
+1. 古い RTE コンテナーからランナーの名前（ `RTE_NAME` ）とトークン（ `RTE_TOKEN` ）を読み取ります。RTE が自分自身を登録していなかった場合
+   （ `RTE_REGISTER=0` ）は、 **接続 > ランナー** でのランナー名を入力します
+2. アプリのアドレスとモード（既定は **アウトバウンド** 、またはインバウンド）を質問し、インバウンドの場合はポートとこのサーバーのアドレスも質問します
+3. 計画を表示し、古い compose ファイルと `.env` を `installer-backups` にバックアップします
+4. `DB_*` の設定を含まない、インストーラーのランナーのレイアウトを書き込みます。ソケットモードの RTE も読み取る `RTE_MAX_JOBS` 、 `RTE_DRAIN_SECONDS` 、
+   `PROCESS_MAX_BUFFER` 、 `METRICS_TOKEN` は残します
+5. 古い RTE の隣で新しい RTE を起動します。新しい RTE はランナー自身のトークンでサインインし、AnsibleForms は自動でランナーを
+   新しいモードに移行します。 **承認は不要** で、そのジョブやそのランナーを指定しているフォームは変わりません
+6. 新しい RTE が接続したら、古いコンテナーを停止して削除します
+
+インバウンドのランナーは、新規のものと同様にピン留めされた証明書で HTTPS を提供し（ [ランナー](#a-runner) を参照）、インストーラーはその
+証明書のフィンガープリントを表示します。新しい RTE が必要とするポートを古い RTE が使っている場合は先に古い RTE を停止するため、新しい RTE が
+接続するまでランナーはオフラインになります。アウトバウンドのランナーの新しい RTE は `127.0.0.1` の空いているポートを使い、古い RTE と並行して動くので途切れません。
+
+インストーラーが古い RTE からトークンを読み取れない場合は、新しい RTE のサインイン方法を選びます。
+
+| 選択肢 | その後の流れ |
+|---|---|
+| ランナーのトークンを入力する | **接続 > 認証情報** にあるランナーの RTE 認証情報のパスワードです。ランナーの名前とジョブはそのまま残ります |
+| 参加トークンで新しいランナーとして参加する | [参加トークン](../runners/registration.html#join-tokens) で別の名前の新しいランナーを追加します。古いランナーは手動で廃止してください |
+
+新しい RTE が接続しない場合、インストーラーは古いファイルを戻して古いコンテナーを再起動することを提案します。AnsibleForms がすでに
+ランナーを移行していた場合は、 **接続 > ランナー** でモードをデータベースに戻してください。新しい RTE が接続した後は
+元に戻せません。古いファイルは `installer-backups` に残ります。
+
+AnsibleForms がその名前のランナーを知らない場合、新しい RTE は代わりに参加を求めて承認を待ちます。その要求を
+**接続 > ランナー** で拒否し、そこでのランナー名を指定してもう一度アップグレードを実行してください。
+
+---
+
+## バージョン
+
+インストーラーのバージョンはアプリのバージョンに従います。AnsibleForms の各リリースには同じバージョンのインストーラーが一緒にリリースされ、
+そのインストーラーは既定でそのバージョンをインストールします。 `--version` で別のバージョンをインストールできます。
+[インストーラーの Releases ページ](https://github.com/ansibleforms/installer/releases) にあるすべてのリリースには、amd64 と arm64 の Linux 用バイナリと
+チェックサムが含まれています。
diff --git a/i18n/ja/_get_started/installation/kubernetes.md b/i18n/ja/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..2259022
--- /dev/null
+++ b/i18n/ja/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: インストール
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Helm チャートで AnsibleForms とその MySQL データベースをインストールします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Helm チャートは、AnsibleForms を MySQL とプレイブックを実行する RTE と一緒にデプロイします（ [values リファレンス](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md) を参照）。
+[インストーラー](installer.html) もいくつかの質問に答えるだけでこのチャートをインストールでき、インストーラーがインストールしていないリリースもアップグレードできます。同じ
+チャートで、別の場所で動いている AnsibleForms 用のランナーだけをインストールすることもできます（ [Kubernetes 上のランナー](#a-runner-on-kubernetes) を参照）。
+
+---
+
+## 前提条件
+
+始める前に、次のものが必要です。
+
+* **Kubernetes クラスター** : `kubectl` から接続できるように設定されていること
+* **Helm 3** : チャートのインストールとアップグレードに使います
+* **ストレージ** : 動的プロビジョニング用の StorageClass、または事前に作成した PersistentVolume
+* **Ingress コントローラー** : Ingress で AnsibleForms を公開する場合のみ
+
+---
+
+## 1. チャートの values を取得する
+
+チャートリポジトリまたは OCI レジストリから、チャートの既定の values を自分用のファイルに取得します。
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">チャートリポジトリ</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">OCI レジストリ</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+リポジトリを追加する必要はありません。チャートは GitHub Container Registry から取得されます。
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. ストレージを設定する
+
+AnsibleForms と MySQL はどちらも永続ボリュームにデータを保存します。それぞれの StorageClass とサイズを設定します。
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+`className` を空にすると、クラスターの既定の StorageClass を使います。アクセスモードの既定は `ReadWriteMany` ですが、多くのストレージ
+クラスはこれに対応していません。レプリカが 1 つなら `ReadWriteOnce` で問題ありません。事前に作成した PersistentVolume を使う場合は、チャートの
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) を参照してください。
+
+---
+
+## 3. 認証情報を設定する
+
+AnsibleForms には、管理者アカウント、データベースのパスワード、そして AnsibleForms に保存される認証情報を暗号化する鍵
+`ENCRYPTION_SECRET` が必要です。後でこの鍵を変更するには、1 回の起動の間だけ [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+に古い鍵を設定します。保存されているすべてのシークレットが新しい鍵で再暗号化されます。これらは次の 3 つの方法のいずれかで指定します。
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">values ファイルで指定</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">チャートが生成</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">既存の Secret</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+`my_values.yaml` に設定します。チャートはこれを `<release>-secrets` という名前の Secret に保存します。
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+指定しなかったものを、初回インストール時にチャートに生成させます。以降のアップグレードでも同じ値が
+保持されます。
+
+```bash
+--set secrets.generate=true
+```
+
+これは、クラスターにアクセスせずにチャートをレンダリングする Argo CD や Flux では機能しません。生成された Secret は
+`helm uninstall` の後も残ります。 `ENCRYPTION_SECRET` は復元できないため、バックアップしておいてください。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+External Secrets、Sealed Secrets、SOPS などで自分が管理する Secret をチャートに指定します。この場合、チャートは
+Secret を作成しません。
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+Secret には `DB_USER` 、 `DB_PASSWORD` 、 `ENCRYPTION_SECRET` 、 `ADMIN_USERNAME` 、 `ADMIN_PASSWORD` が含まれている必要があります。
+
+</div>
+</div>
+
+---
+
+## 4. RTE イメージを選ぶ
+
+AnsibleForms 7 は自分ではプレイブックを実行せず、RTE（ランタイム環境）が実行します。チャートは RTE をサーバー Pod の
+2 つ目のコンテナーとして同じボリューム上で動かし、既定のランナー `rte` として登録するため、プレイブックのフォームは設定なしで動作します。7.3.0 以降、
+アプリは `127.0.0.1` の RTE に接続して 1 本の WebSocket を開いたままにします（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）。RTE は
+データベースの設定も暗号化キーも受け取りません。チャートの設定シードは、トークンとそのアドレスを持つ RTE の認証情報と、それでサインインする
+モード inbound のランナーを宣言しています。
+
+既定のイメージ `ghcr.io/ansibleforms/ansibleforms-rte-full` には、ansible とそのコレクション、そして 6.5 のイメージにあった Python ライブラリが含まれています。
+これより多く、または少なくしたい場合は、3 つの RTE レイヤー（ `ansibleforms-rte-base` 、 `-rte-core` 、 `-rte-full` 。
+[RTE イメージ](../rte/images.html) を参照）のいずれかをベースに独自のイメージをビルドし、チャートでそれを指定します。
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+アプリと RTE の間のトークンと、セッションに署名する鍵は、初回インストール時に
+`<release>-keys` Secret に生成され、アップグレードのたびに保持されます。独自の設定シードを使う場合は、その認証情報とランナーをシードに追加してください。方法はインストール後に Helm が表示するノートに記載されています
+（チャートの [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) を参照）。
+
+---
+
+## 5. チャートをインストールする
+
+自分の values を使って、専用の Namespace にチャートをインストールします。
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+OCI レジストリを使う場合は、チャートとして `oci://ghcr.io/ansibleforms/charts/ansibleforms` を指定します。無人で実行するものでは、
+`--version` でチャートのバージョンを固定し、新しいリリースが勝手にインストールされないようにしてください。
+
+---
+
+## 6. インストールを確認する
+
+チャートには、Web サーバーとデータベース接続の両方を確認するテストが含まれています。
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+AnsibleForms が応答し、データベースが接続を受け付ければ、テストは `OK` で終わります。
+
+---
+
+## 7. AnsibleForms を開く
+
+AnsibleForms へのアクセス方法は、サーバーの公開方法によって異なります。
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">ポートフォワード</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+既定の `ClusterIP` サービスで Ingress がない場合、クラスターの外には何も公開されません。ローカルのポートをフォワードして
+確認します。
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+その後 `http://127.0.0.1:8080/` を開きます。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+`services.server.type: LoadBalancer` を設定し（必要に応じて `services.server.loadbalancer.ip` に固定アドレスを指定）、
+サービスにアドレスが割り当てられるまで待ちます。
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Ingress を有効にし、Ingress コントローラーにルーティングされるホスト名を設定します。
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+Ingress の背後での TLS については、サーバーで HTTPS を使う場合に必要なバックエンドの設定も含め、チャートの [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) で
+説明しています。
+
+</div>
+</div>
+
+---
+
+## 8. サインインする
+
+管理者ユーザー（既定は `admin` ）としてサインインします。Secret からパスワードを読み取るには次のようにします。
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+`secrets.existingSecret` を使っている場合は、代わりに自分の Secret から読み取ります。
+
+---
+
+## Kubernetes 上のランナー
+
+`runner.enabled` を指定すると、チャートは RTE だけをインストールします。別の Namespace、別のクラスター、または VM など、別の場所にインストールされた
+AnsibleForms 用のランナーです。ランナーはアプリに接続して 1 本の WebSocket を開いたままにするため（ `RTE_MODE=outbound` 、 [モード](../rte/modes.html) を参照）、
+データベースも暗号化キーもインバウンドのポートも必要ありません。アプリ、MySQL、Service、Ingress はレンダリングされません。
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| 値 | 内容 |
+|---|---|
+| `runner.enabled` | ランナーだけをインストールします。アプリ、MySQL、Service、Ingress はありません |
+| `runner.appUrl` | 利用者が開くアプリのアドレス。 `BASE_URL` があればそれも含めます。必須です |
+| `runner.name` | 参加するときのランナー名（ `RTE_NAME` ）。空の場合はリリース名 |
+| `runner.joinToken` | アプリで作成した [参加トークン](../runners/registration.html#join-tokens) 。初回起動時に読み取られ、ランナーをすぐに承認します |
+| `runner.appTlsVerify` | `false` にするとアプリの自己署名証明書を受け入れます（ `APP_TLS_VERIFY=0` ）。信頼できる 1 つのネットワーク内でのみ使ってください |
+
+参加トークンがない場合、ランナーは参加を求め、管理者が **接続 > ランナー** で承認するまで待ちます。承認されると、
+`<release>-keys` Secret に保存された自分の `RTE_TOKEN` でサインインします。この Secret はリリースと一緒に保持してください。
+ランナーの役割と Kubernetes を選んだ場合、 [インストーラー](installer.html#kubernetes) もこのランナーモードをインストールします。
+
+---
+
+## 次のステップ
+
+設定のその他の部分は、チャートの [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) で説明しています。
+
+* **独自のデータベース** : `mysql.enabled: false` を設定し、AnsibleForms を既存の MySQL サーバーに向けます
+* **ConfigMap からのフォーム** : `config.yaml` とフォームファイルを ConfigMap で提供します
+* **Ingress の背後での HTTPS** 、リソース、ノードの配置、プライベートレジストリ
+* **RTE** : そのトークン、独自の RTE イメージ、または RTE をまったく使わない構成
+
+新しいリリースに移行するには、 [Kubernetes でのアップグレード](../upgrading/kubernetes.html) を参照してください。
diff --git a/i18n/ja/_get_started/installation/native.md b/i18n/ja/_get_started/installation/native.md
new file mode 100644
index 0000000..4170e48
--- /dev/null
+++ b/i18n/ja/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: ネイティブ
+parent: インストール
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# ネイティブインストール
+{: .no_toc }
+
+コンテナーを使わずにサーバーへ直接、インストーラーが構成する systemd サービスとして AnsibleForms を動かします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+コンテナーが許可されていないサーバーの管理者向けです。 [インストーラー](installer.html) が AnsibleForms に必要なものをすべて
+サーバー自体にインストールし、その後のアップグレードと削除も行います。インストールされるのは AnsibleForms 7.3.0 以降です。
+
+---
+
+## 必要なもの
+
+インストーラーの **エンジン** ステップで **このサーバーに直接 (コンテナーなし)** を選ぶか、 `--mode native` を指定します。必要なものは次のとおりです。
+
+* **root** : `sudo` でインストーラーを実行します（ `curl -fsSL https://ansibleforms.com/install | sudo sh` ）
+* **systemd** : サービスは systemd ユニットとして動作します
+* **対応する Linux** : Ubuntu、Debian、RHEL と Rocky Linux や AlmaLinux などのリビルド版、SUSE Linux Enterprise、openSUSE
+* **amd64 または arm64**
+* **インターネットアクセス** : ディストリビューションのリポジトリ、GitHub、nodejs.org、Python と Ansible のパッケージインデックスへ（リリースバンドルで
+  置き換えられるものについては [エアギャップ環境](#air-gapped) を参照）
+
+これらを満たさないサーバーでは、エンジンは *このサーバーに直接 (root が必要: sudo で実行)* または
+*このサーバーに直接 (この Linux では非対応)* と表示されます。どちらの役割もこの方法でインストールできます。コントローラーと [ランナー](installer.html#a-runner) です。
+
+---
+
+## インストールされるもの
+
+インストーラーは、どちらの役割でも、ディストリビューションのパッケージから次のものをインストールします。
+
+| パッケージ | 用途 |
+|---|---|
+| `git` | リポジトリ |
+| ssh クライアント | プレイブックの接続 |
+| MariaDB クライアント | アプリのバックアップ。 `app.env` は [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) と [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) に、見つかったクライアント（ `mariadb-dump` と `mariadb` 、または古い `mysqldump` と `mysql` ）を設定します |
+| `ca-certificates`, `curl`, `tar`, `gzip` | ダウンロード |
+| `libatomic` | Node.js がこれにリンクしており、最小構成のサーバーには含まれていません |
+| `sshpass` | ssh パスワードでサインインするプレイブック。RHEL とそのリビルド版では EPEL から入手し、インストーラーは `epel-release` で EPEL の有効化を試みます。インストールできない場合でもインストールは続行し、その旨を表示します |
+| MariaDB サーバー | コントローラーのみ。そのデータベースです |
+
+続いてインストール先フォルダーに次のものを入れます。ダウンロードはすべて、公開されているチェックサムと照合します。
+
+* **AnsibleForms** : アプリの GitHub リリースにあるリリースバンドル `ansibleforms-<version>-linux-<arch>.tar.gz` 。Node.js 向けにビルドされたアプリです。
+  バンドルがないバージョンでは *コンテナーなしには AnsibleForms 7.3.0 以降が必要です。* と表示されます
+* **Node.js** : バンドルが指定するメジャーバージョンの最新リリース。nodejs.org から取得します
+* **Python と Ansible** : まず uv を入れ、それを使って RTE イメージと同じ Python と、Ansible および
+  full RTE イメージのライブラリを含む仮想環境を用意し、その Ansible コレクションを入れます（ [RTE イメージ](../rte/images.html) を参照）。数分かかります
+* **初期ファイル** : [docker-compose プロジェクト](https://github.com/ansibleforms/docker) の `data` フォルダーにあるフォーム、プレイブック、設定です。
+  新規の Docker Compose インストールと同じものです。ランナーは Ansible の設定、ssh と git の設定だけを残します
+
+コントローラーの場合は、さらに MariaDB に `AnsibleForms` スキーマを作成し、インスタンス名を付けたデータベースユーザーを作成します。このユーザーは
+そのスキーマに対するすべての権限を持ち、それ以外には権限を持たず、このサーバーからのみサインインできます。
+
+---
+
+## フォルダー
+
+すべてはインストール先フォルダーに置かれます。既定は `/opt/ansibleforms` （ランナーの場合は `/opt/ansibleforms-runner` ）です。
+
+| パス | 内容 |
+|---|---|
+| `releases/<version>/` | 1 つのリリース。バンドル、Node.js へのリンク、Python の仮想環境、コレクション |
+| `current` | 実行中のリリースへのリンク。アップグレードでもロールバックでも切り替わります |
+| `runtime/` | リリース間で共有される Node.js、uv、Python |
+| `data/` | コンテナーが `/app/dist/persistent` としてマウントするもの。フォーム、プレイブック、 `config.yaml` 、設定シード、証明書、ログ |
+| `home/` | システムユーザーのホーム。 `data/ssh` と `data/git` にリンクされた `.ssh` と `.gitconfig` |
+| `app.env`, `rte.env` | サービスの設定とシークレット。root とシステムユーザーだけが読み取れます。RTE 用のファイルにはデータベースの設定は含まれません |
+| `installer-backups/` | アップグレード前や `backup` でインストーラーが作成するデータベースのバックアップ |
+
+リリースとランタイムは root が所有するため、サービスが自分のコードを変更することはできません。 `data/` と `home/` はシステムユーザーが所有します。
+データベースのファイル自体は MariaDB がフォルダーの外で管理します。
+
+---
+
+## サービス
+
+コントローラーは 2 つ、ランナーは 1 つの systemd サービスを動かします。それぞれインスタンス名（既定は `ansibleforms` ）のシステムユーザーとして、
+`current/server` から、それぞれの設定ファイルを使って動作します。
+
+| サービス | 実行するもの | 設定 |
+|---|---|---|
+| `<name>` | アプリ。Web インターフェース、API、ワーカー。コントローラーのみ | `app.env` |
+| `<name>-rte` | プレイブックを実行する RTE | `rte.env` |
+
+コントローラーの RTE は `inbound` で、 `127.0.0.1` の専用ポート（ `8001` 、または次に空いているポート。
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1` ）で待ち受け、アプリのフォルダーからプレイブックを実行し（ `RTE_FILES=local` ）、
+設定シード `data/seed.yaml` で既定のランナーとして宣言されます。
+
+ランナーの RTE にはモード、 `APP_URL` 、 `RTE_NAME` 、 `--join` を使った場合は参加トークンが設定され、プレイブックはジョブごとに受け取ります（
+[モード](../rte/modes.html) を参照）。アウトバウンドの RTE はアプリからの呼び出しを受けないため、 `127.0.0.1` でのみ待ち受けます（ `LISTEN_HOST=127.0.0.1` ）。
+インバウンドの RTE は、 `data/certificates` にある自分のアドレスの自己署名証明書で HTTPS を提供し、AnsibleForms はそれをピン留めします。
+参加トークンがない場合は参加を求め、管理者が **接続 > ランナー** で承認します。
+
+サービスは起動時に開始され、障害の後は再起動します。管理とログの確認には systemd の標準ツールを使います。
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+アプリは root でなくても `443` のような 1024 未満のポートで待ち受けられます。RTE は `sudo` を使う権限を保持しています。これはこのサーバーで
+`become` を使うプレイブックに必要なもので、プレイブックは RTE が動いているサーバー自体を管理できます。
+
+---
+
+## アップグレードとロールバック
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` は、ほかの方法と同じようにネイティブインストールをアップグレードします（ [アップグレード](installer.html#upgrade) を参照）。
+順序は次のとおりです。
+
+1. 実行中のリリースの隣に新しいリリースを配置します。バンドル、Node.js、Python、Ansible、コレクションです。実行中の
+   サービスにはまだ触れません
+2. リリースに含まれる新しい初期ファイルを追加します。既存のファイルはすべて残します
+3. データベース（コントローラー）を `installer-backups/` にバックアップし、 `app.env` と `rte.env` のコピーも保存します
+4. サービスを停止し、 `current` を新しいリリースに向けて、サービスを再び起動します
+5. アプリが新しいバージョンで応答するまで待ちます（ランナーの場合は RTE が再び待ち受けるまで）
+
+新しいバージョンが応答しない場合、インストーラーはロールバックを提案します。 `current` が再び前のリリースを指し、
+データベースはバックアップから復元され、サービスが起動します。残すのは実行中のリリースとその 1 つ前のリリースだけです。
+
+インストーラーのレイアウトに従ったネイティブサービスで、隣に `installer.json` がないもの（たとえば削除された後）は、 `install`
+と `upgrade` が見つけて引き継ぎを提案します（ [既存のインストール](installer.html#an-existing-installation) を参照）。
+
+---
+
+## アンインストール
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` はサービスを停止して削除します。データの削除を選び（または `--purge` を指定し）、
+確認のためにインスタンス名を入力しない限り、フォルダーとデータベースは残ります。削除を選んだ場合は、データベースとそのユーザー（コントローラー）も削除し、
+フォルダーを削除し、システムユーザーも削除します。
+
+パッケージは MariaDB も含めてインストールされたまま残ります。ほかのソフトウェアが使っている可能性があるためです。
+
+---
+
+## エアギャップ環境
+
+`--bundle` を使うと、GitHub からダウンロードする代わりに、サーバーにコピーしたリリースバンドルからインストールします。アプリの
+[Releases](https://github.com/ansibleforms/ansibleforms/releases) から、アーキテクチャに合ったファイル `ansibleforms-<version>-linux-amd64.tar.gz` または `-arm64` を取得します。
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` は初期ファイルについて同じことを行い、 [ansibleforms/docker](https://github.com/ansibleforms/docker)
+リポジトリのローカルコピーを使います。Node.js、Python とそのパッケージ、Ansible コレクションは、インストール中に引き続きダウンロードされます。
diff --git a/i18n/ja/_get_started/upgrade-7.md b/i18n/ja/_get_started/upgrade-7.md
new file mode 100644
index 0000000..56308fa
--- /dev/null
+++ b/i18n/ja/_get_started/upgrade-7.md
@@ -0,0 +1,301 @@
+---
+layout: default
+title: v7 へのアップグレード
+parent: アップグレード
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# v7 へのアップグレード
+{: .no_toc }
+
+6.5 のうちに変更しておくこと、そしてバージョン 7 に移行すると変わること
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+バージョン 7 では、6.x で非推奨になったものがすべて削除されます。古いものと新しいものの両方が動く 6.5 のうちに修正してから、アップグレードしてください。
+
+---
+
+## アップグレードの前に（6.5 で）
+
+### フォームは専用のファイルに置く
+
+フォームはフォームフォルダー（ `FORMS_FOLDER_PATH` ）またはフォームリポジトリにだけ置きます。 `config.yaml` にはカテゴリ、ロール、定数を残します。
+
+- **`forms.yaml` ファイル:** `config.yaml` に名前を変更します。6.5 では、設定ページにそのための
+  **Convert forms.yaml to config.yaml** ボタンがあります。
+- **ベース設定の `forms:` セクション:** バージョン 7 ではエラーになります。各フォームを専用のファイルに移してください。たとえば
+  6.5 のデザイナーでフォームをファイルにドラッグします。
+- **環境変数:**
+
+  | 削除されたもの | 代わりに使うもの |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` と `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### `table` フィールド
+
+バージョン 7 では `table` フィールドはエラーになり、そのプロパティ（ `tableFields` 、 `insertColumns` 、 `readonlyColumns` 、
+`tableTitleAdd` 、 `tableTitleEdit` ）も一緒に削除されます。 `subform` を持つ `list` フィールドを使い、各列の `from` を
+`__parent__` に対する式に置き換えてください（ [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform) を参照）。
+
+### 名前が変わったプロパティ
+
+削除された各プロパティには、そのまま置き換えられるものがあります。
+
+| 削除されたもの | 代わりに使うもの |
+|---|---|
+| `disableRelaunch: true` （フォーム） | `allowRelaunch: false` |
+| `noOutput: true` （フィールド） | `output: false` |
+| `enableLogin` （ロールのオプション） | `allowLogin` |
+
+### データソースとデータスキーマ
+
+データソースのインポートとその管理ページは削除されました。それらのためだけのモジュールを持っていた
+AnsibleForms Galaxy コレクションも削除されています。
+
+- スケジュールされたインポートは停止し、データソースのテーブルは削除されます。必要なものは先に控えておいてください。
+- インポートが埋めていたデータスキーマはそれ自体が独立したデータベースなので残ります。認証情報を使って
+  それを照会するフォームは引き続き動作します。
+- データを最新に保つには、たとえばスケジュールから、インポートを独自のプレイブックとして
+  実行してください。
+
+### API v1
+
+`/api/v1/*` は削除されました。 `/api/v2/*` を使ってください（対話型のドキュメントは `/api/v2/docs` ）。スクリプトでよく使われる
+呼び出しは次のとおりです。
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+v2 は HTTP ステータスコード（ `400` 、 `403` 、 `404` 、 `422` ）とプレーンな JSON 本文で応答し、v1 の
+`{ status, message, data }` という包みは使いません。
+
+**シングルサインオンのコールバックも同様です。** `/api/v1/` を含むリダイレクト URL は応答しなくなり、サインインはサインインしないまま
+ログインページに戻ります。2 か所で `/api/v2/` に変更してください。AnsibleForms の SSO プロバイダーと、ID プロバイダー側
+（Entra ID のアプリ登録のリダイレクト URI、OIDC クライアントの有効なリダイレクト URI）です。
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback` 、7.3.0 以降は `/api/v2/auth/entraid/callback`
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## 7 で変わること
+
+バージョン 7 ではプレイブックの実行方法が変わり、いくつかの既定値が厳しくなります。6.5 から移行するときは、以下の各項目を確認してください。
+
+### プレイブックは RTE で実行される
+
+バージョン 7 では、AnsibleForms のコンテナーで `ansible-playbook` を実行しなくなりました。プレイブックはランタイム環境（RTE）、
+つまり専用のコンテナーで実行され、アプリのイメージには ansible も python も含まれなくなりました。
+`ghcr.io/ansibleforms/ansibleforms-rte-full:7` イメージから、アプリの隣で RTE を起動します。7.3.0 以降、アプリは RTE に接続して 1 本の WebSocket を開いたままにします（
+[モード](rte/modes.html) を参照）。RTE はデータベースの設定も `ENCRYPTION_SECRET` も受け取りません。RTE の設定は次のとおりです。
+
+| 設定 | 値 |
+|---|---|
+| `AF_ROLE` | `rte` 。RTE イメージではすでに設定されています。 |
+| `RTE_MODE` | `inbound` 。アプリが RTE に接続します。別のネットワークにあるランナーは `outbound` を使います（ [モード](rte/modes.html) を参照）。 |
+| `RTE_TOKEN` | 16 文字以上のトークン。アプリはこれで RTE のソケットにサインインし、RTE はこれがないと起動しません。 |
+| `RTE_FILES` | アプリの隣に置く場合のように、RTE がアプリと同じ永続フォルダーをマウントするときは `local` 。 |
+
+次に、ansible 関連のマウントをアプリのコンテナーから RTE に移します。
+
+- `ansible.cfg` は `/etc/ansible/ansible.cfg` に、ロールは `/etc/ansible/roles` に、コレクションは
+  `/etc/ansible/collections` にマウントします。
+- プレイブックとリポジトリを見つけられるよう、アプリと同じ永続フォルダーを RTE にもマウントします。
+
+その後、Docker Compose プロジェクトと同じように [設定シード](seed/) で、または **接続 → ランナー** で、RTE をランナーとして宣言します。
+RTE のアドレス（たとえば `http://rte:8000` ）と同じトークンを持つ RTE の認証情報と、それを指定する種類 RTE、モード inbound の
+ランナーです。
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+シードは `RTE_TOKEN` をアプリの環境から読み取ります。 [ランナー](runners.html) と [ランタイム環境](rte/) を参照してください。
+
+{: .warning }
+> **アプリと RTE は同じコントラクト** アプリはジョブの認証情報を解決し、その RTE 用に封をして RTE に渡します
+> （RTE コントラクト 2、7.0.0 で新設）。別のコントラクトの RTE はアプリのジョブを拒否します。アプリと同じリリースの
+> RTE イメージを実行し、両方を一緒にアップグレードしてください。以降の 7 系のリリースは、コントラクトが同じである限り
+> 古い 7 系の RTE とも引き続き動作します（ [スケーリング](../rte/images.html#build-your-own-rte) を参照）。
+
+
+### RTE イメージの内容
+
+RTE は 3 つのレイヤーで提供され、それぞれ前のレイヤーの上にビルドされています。プレイブックに合ったものを選んでください。
+
+| イメージ | 内容 |
+|---|---|
+| `ansibleforms-rte-full` | 既定。Ansible 14 と ansible-core 2.21、そして 6.5 のイメージにあったコレクションと python ライブラリ。 |
+| `ansibleforms-rte-core` | Python 3.14、ansible-core、いくつかの一般的なライブラリ。コレクションは含みません。これをベースにしたイメージで独自に追加します。 |
+| `ansibleforms-rte-base` | サーバーのみ。python も ansible も含まず、独自のバージョンで RTE をビルドするためのものです。 |
+
+6.5（ansible 12 と ansible-core 2.19）からの移行では、プレイブックに関して次の点も変わります。
+
+- **ansible-core 2.21:** 2.20 と 2.21 の [移植ガイド](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  を読んでください。
+- **Python 3.14:** RTE のレイヤーは python 3.14 で動作します。
+- **`boto` の廃止:** 古い `boto` 2 ライブラリはなくなりました。 `amazon.aws` コレクションは同梱の `boto3` を使います。
+
+2 つの環境変数は RTE の担当になり、アプリでは読み取られなくなったので、RTE のコンテナーに設定してください。
+
+| 変数 | 変更点 |
+|---|---|
+| `ANSIBLE_PATH` | RTE 上のプレイブックのフォルダー。 |
+| `PROCESS_MAX_BUFFER` | 既定が 50 MB になりました。これを超えるとジョブの出力は保存されなくなります（ジョブにその旨が表示されます）が、プレイブックは停止せずに続行します。 |
+
+
+### コンテナーは uid 1000 で動作する
+
+アプリと RTE のイメージは root ではなくユーザー `node` （uid 1000）として動作し、ホームフォルダーは `/home/node` です。
+
+- **ボリュームの所有者を一度だけ uid 1000 にします。** 永続ボリュームと ssh ボリュームには
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v` を、ホストのフォルダーには `sudo chown -R 1000:1000 <folder>` を実行します。
+  Kubernetes では `fsGroup: 1000` を設定します。
+- **ssh フォルダーは `/root/.ssh` ではなく `/home/node/.ssh` にマウントします。**
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) を `/root` に設定している場合は、削除するか `/home/node` に設定してください。
+- RTE レイヤーをベースにした **独自の RTE イメージ** では、インストールの間だけ `USER root` に切り替え、最後に `USER node` に戻します。
+
+
+### 起動時の検証が有効
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) の既定が `enforce` になりました（6.5 では `off` ）。ブラウザーからでも
+`POST /api/v2/job` からでも、すべての起動がフォームのルールに照らしてチェックされ、ジョブはチェック済みの値からサーバーが組み立てた extravars と
+認証情報で実行されます。
+
+- **REST の呼び出し元は `rawFormData` を送る必要があります。** これはブラウザーが送るのと同じ、フィールドの生の値です。
+  `extravars` だけの起動は、値をチェックできないため拒否されます。
+- **何が拒否されるかを先に確認するには** 、 `LAUNCH_VALIDATION=log` を設定し、ログの警告を読みます。 `off` にすると
+  6.5 の動作に戻ります。
+
+詳しくは [起動時の検証](launch-validation/) を参照してください。
+
+
+### プレイブックからアプリの設定が見えなくなった
+
+プレイブックは、AnsibleForms 自身が読み取る環境変数を継承しなくなりました。 `ENCRYPTION_SECRET` 、 `DB_*` の設定、
+`ACCESS_TOKEN_SECRET` 、 `RTE_TOKEN` 、 `VAULT_*` の設定、その他ドキュメントに記載されているすべての変数、そしてすべての `MYSQL_*` 変数です。
+`PATH` 、プロキシ、 `ANSIBLE_*` の設定、クラウドの認証情報など、RTE のそれ以外の環境はこれまでどおり渡されます。
+
+`lookup('env', ...)` でこれらのいずれかを読んでいたプレイブックは、別の方法で値を受け取る必要があります。extravar や
+認証情報として渡すか、別の名前で RTE に設定してください。
+
+### ランナーと管理者を管理できるのは admin ロールだけ
+
+設定へのアクセス権を持つユーザーでも、誰が管理者になるか、認証情報がどこへ渡るかを完全には制御できなくなりました。
+
+- **ランナー:** ランナーは実行するジョブの認証情報を受け取るため、ランナーの追加、変更、削除は admin ロールだけが行えます。
+  設定へのアクセス権を持つユーザーは、引き続きランナーを表示してテストできます。
+- **管理者のアカウントとグループ:** 管理者権限を与えられるのは admin ロールだけです。admin ロールがないユーザーは、admin ロールが指定する
+  グループにアカウントを入れることも、管理者アカウントやそのようなグループを変更、リセット、削除することもできません。
+- **ロール:** admin ロールのないデザイナーはロールを変更できません。ロールが異なる保存や復元は拒否されます。
+
+ランナー、管理者、ロールを管理する人には admin ロールを与えてください。
+
+### 既定のパスワードは変更が必須
+
+公開されている既定のパスワード `AnsibleForms!123` でサインインしたユーザーは、まずパスワードを変更する必要があります。変更するまで、ほかのすべての API
+呼び出しはコード `password_change_required` 付きの `403` を返し、ブラウザーにはパスワード変更ページが表示されます。
+
+一度サインインして新しいパスワードを設定するか、初回起動の前に [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) を
+設定してください。既定のパスワードでログインするスクリプトは、別のパスワードを使う必要があります。
+
+### トークンはログアウトとパスワード変更で失効する
+
+ログアウトするとそのセッションのトークンが失効し、パスワードを変更するとそのユーザーのすべてのセッションが終了します。パスワードを変更した後は
+もう一度サインインしてください。
+
+`?expiryDays=` で要求した API トークンの有効期間は、最大で [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) 日
+（既定は 90 日）です。長期間有効な API トークンを使うスクリプトは、期限が切れる前に新しいトークンを要求する必要があります。
+
+### Entra ID にはテナントが必要
+
+Entra ID（Azure AD）のサインインは、自分のテナントに対する OpenID Connect だけを使うようになり、別のテナントのユーザーはサインイン
+できません。テナント ID がない、または `common` 、 `organizations` 、 `consumers` を指定したプロバイダーは拒否されます。
+
+- SSO プロバイダーに **テナント ID を設定します。** ディレクトリ（テナント）ID の GUID、またはテナントのドメインです。
+- **Graph のアクセス許可を付与します。** ログインは `openid profile email User.Read GroupMember.Read.All` を要求します。アプリ
+  登録に Microsoft Graph の委任されたアクセス許可 `User.Read` と `GroupMember.Read.All` を、管理者の同意付きで与えてください。
+- **ロールではグループ ID を使うことをお勧めします。** グループは表示名ではなく `azuread/<object id>` （7.3.0 以降は `entraid/<object id>` ）で指定します。
+
+設定方法は [Entra ID](authentication/entra-id.html) を参照してください。
+
+### パスワードには最小の長さがある
+
+アプリケーションで設定するローカルのパスワードは、少なくとも
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) 文字（既定は 8）が必要で、ユーザー名や
+既定のパスワードと同じにはできません。 `PASSWORD_MIN_LENGTH=0` で長さのチェックを無効にできます。既存のパスワードは引き続き使えます。
+
+### 再起動ポリシーを付けてコンテナーを実行する
+
+捕捉されない例外が発生すると、プロセスを不明な状態のまま動かし続けるのではなく、レベル `crit` でログに記録してプロセスを終了するようになりました。
+Docker の `--restart unless-stopped` のような再起動ポリシーを付けてコンテナーを実行してください（docker-compose プロジェクトでは設定済みです）。
+Kubernetes は Pod を自動的に再起動します。
+
+### AWX の接続とホームリンク
+
+7 ではさらに 2 つのものがなくなりましたが、6.5 で行うことはありません。
+
+- **AWX と AAP の接続:** `awx` テーブル、 `/api/v2/awx` 、A.A.P. ページはなくなりました。アップグレードでは、すべての AWX または
+  AAP の接続が種類 `awx` のランナーとして **接続 → ランナー** に移され、 `awx:` を持つフォームは引き続き動作します。
+- **`NAV_HOME_LABEL` と `NAV_HOME_ICON`:** 読み取られなくなりました。ヘッダーの最初のリンクは常に「フォーム」です。
+
+### 7 で非推奨、8 で削除
+
+これらは 7 ではまだ動作しますが、使うたびに警告がログに記録されます。バージョン 8 より前に代替のものへ移行してください。
+
+| 非推奨 | 代わりに使うもの |
+|---|---|
+| `VAULT_*` 環境変数 | `vault` という名前のシークレットストア（ **接続 → シークレットストア** ）。7 の初回起動時に、変数をそのストアとして一度だけインポートし、以降は無視します。 |
+| `LOG_SYSLOG_*` 環境変数 | Syslog サーバー（ **接続 → Syslog** ）。 `LOG_SYSLOG_HOST` が設定されている場合、7 の初回起動時にサーバー `syslog` として一度だけインポートし、これまでどおりサーバーログを送り、以降は無視します。監査エントリも送るには、両方を受け取るように設定します。 |
+| 認証情報の `vault_path` （API、設定シード） | `secret_store` と `secret_ref` 。 [シークレットストア](secret-stores/) を参照してください。 |
+| `config.yaml` のロール `public` | ロール `default` 。設定の読み込み時にファイル内で名前が変更されます。ytt テンプレートは手動で変更してください。フォームの `roles:` にある `public` は引き続き一致します。 |
+| `POST /api/v2/config/vault/check` 、 `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check` 、 `GET /api/v2/secretstore/{id}/mounts` |
+| フォームまたはステップの `hasApproval` | `approval` 。 `hasApproval` には効果がありません。 |
+| フォームの `awx: <name>` | `runner: <name>` 。AWX の接続は種類 `awx` のランナーです。 |
+| フォームの `type: multistep` とその `steps` | `runner` を指定するノードを持つ `type: workflow` 。 [ワークフローフォーム](forms/workflow.html) を参照してください。 |
+| 設定シードの `awx:` セクション | `type: awx` を持つ `runners:` の項目 |
+| `LOCK_PATH` | なし。読み取られなくなり、デザイナーのロックはデータベースに保存されます。 |
+| 7.3.0 以降、データベースモードの RTE: `RTE_MODE=database` または `RTE_MODE` なしで、RTE にデータベースの `DB_*` と `ENCRYPTION_SECRET` がある | `DB_*` なしの `RTE_MODE=outbound` または `RTE_MODE=inbound` 。RTE は参加トークン（ `RTE_JOIN_TOKEN` ）で一度だけ参加するか、 **接続 → ランナー** または設定シード（ `rte_mode` ）でそのランナーをそのモードに設定します。 [モード](rte/modes.html) を参照してください。 |
+| 7.3.0 以降の `RTE_REGISTER` （データベースモードのみ） | 参加トークン（ `RTE_JOIN_TOKEN` ）。RTE は、RTE の認証情報でサインインするランナーとして自分自身を追加します。 |
+| 7.3.0 以降、設定シードのランナーにある `api` または `userpass` の認証情報 | ランナーの種類に合った認証情報（ `credential_type: rte` 、 `awx` 、 `aap` 、 `ascender` 、 `semaphore` 、 `rundeck` 、 `jenkins` ）。サーバーは `url` に指定します。 |
+| 7.3.0 以降、独自の `token` 、または `username` と `password` を持つ設定シードのランナー | `credentials` セクションにある、ランナーの種類に合った認証情報。サーバーは `url` に指定し、ランナーは `credential:` でそれを指定します。それまでの間、シードはランナー名を付けた認証情報を 1 つ作成します。 |
+
+`ENABLE_SSO` と `SSO_AUTO_LOGIN` は 7.3.0 以降読み取られなくなりました。7.3 の初回起動時に一度だけ引き継がれます。 `ENABLE_SSO=0` は
+すべての SSO プロバイダーを無効にし、 `SSO_AUTO_LOGIN=1` は唯一有効なプロバイダーの **ログインページをスキップ** にチェックを入れます。その後は無視されます。設定されている間は
+起動のたびに警告がログに記録され、各プロバイダーの **有効** と **ログインページをスキップ** は **アクセス → SSO** にあります。
+
+---
+
+## イメージタグ
+
+7.0.0 で `latest` は 7 に移ります。6 に留まるには、 `latest` ではなくタグ `6` （または `6.5` ）を使います。
+すべてのタグは [イメージタグ](installation/#image-tags) に記載されています。
+
+---
+
+## ロールバック
+
+アップグレードの前にバックアップを取ってください（ **設定 → バックアップ** ）。6.5 は 7 にアップグレードされたデータベースでも動作しますが、
+削除されたデータソースの定義を復元できるのはバックアップだけです。
diff --git a/i18n/ja/_get_started/upgrading/docker-compose.md b/i18n/ja/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..5b968d8
--- /dev/null
+++ b/i18n/ja/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,163 @@
+---
+layout: default
+title: Docker Compose
+parent: アップグレード
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+docker-compose プロジェクトで作成したインストールをアップグレードします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+docker-compose プロジェクトは 3 つのコンテナーを実行します。MySQL（ `mysqldb` ）、AnsibleForms（ `app` ）、そしてプレイブックを実行する
+RTE（ `rte` ）です。AnsibleForms と RTE はイメージタグ `7` を使い、これは常に最新の 7.x リリースを指します。
+アップグレードではイメージを再び pull し、イメージが変わったコンテナーを作り直します。永続化が必要なものはすべて
+`data` フォルダーに保存されており、そのまま残ります。
+
+---
+
+## アップグレードの前に
+
+問題が起きたときに元に戻せるよう、アップグレードの準備をします。
+
+* **設定 → バックアップ** で **バックアップを取ります** 。新しいリリースは初回起動時にデータベースのスキーマをアップグレードします。
+* 現在のバージョンと新しいバージョンの間のリリースについて **[変更履歴](../changelog) を読みます** 。
+* **新しいメジャーバージョンに移行しますか?** 先に [v7 へのアップグレード](../upgrade-7.html) に従ってください。
+* **6.5 から移行しますか?** `v6` ブランチにある 6.x のプロジェクトには `rte` コンテナーがありません。 `.env` の設定と `data` フォルダーは残したまま、
+  プロジェクトのコピーを `main` ブランチに更新し、 `docker-compose.yml` に `rte` サービスが入るようにします。
+  その compose ファイルは `CONFIG_SEED_PATH` を設定しますが、6.x の `data` フォルダーには `seed.yaml` がありません。リポジトリから `data/seed.yaml` を
+  コピーし、リポジトリの `.env` と同じように `RTE_TOKEN` （16 文字以上）を `.env` に追加してください。これらがないと
+  アプリは起動しません。7 のイメージは root ではなく uid 1000 で動作します。MySQL のファイルは MySQL に任せたまま、
+  `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +` で `data` フォルダーの所有者を一度だけこのユーザーにします。
+  `data/ssh` フォルダーは `/root/.ssh` ではなく `/home/node/.ssh` にマウントされるようになりました。
+* **7.2 から移行しますか?** `docker-compose.yml` と `data/seed.yaml` を一緒に更新します。まず [7.2 から 7.3 へ](#from-72-to-73) を参照してください。
+
+---
+
+## 7.2 から 7.3 へ
+
+7.2.0 までは、 `rte` サービスがデータベースの設定を受け取り、 `data/seed.yaml` で宣言されたそのランナーはデータベースモードで動作していました。
+このモードは 7.3.0 で非推奨になり、8.0.0 で削除されます。7.3.0 以降、アプリは `http://rte:8000` の RTE に接続して 1 本の WebSocket を開いたままにし
+（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）、RTE はデータベースの設定を持ちません。 `.env` は残したまま、両方のファイルをリポジトリの
+`main` ブランチから取得してください。
+
+| ファイル | 変更点 |
+|---|---|
+| `docker-compose.yml` | `rte` サービスは `.env` を読み取らなくなります。 `RTE_MODE=inbound` 、 `RTE_TOKEN` 、 `RTE_FILES=local` を受け取り、 `DB_*` は受け取りません |
+| `data/seed.yaml` | `url: http://rte:8000` と `password: ${RTE_TOKEN}` を持つ RTE の認証情報 `rte` と、 `rte_mode: inbound` と `credential: rte` を持つランナー `rte` |
+
+両方を変更してください。新しい compose ファイルだけだと、シードはランナー `rte` をデータベースモードのまま維持します。アプリは RTE を 7.2 の RTE として呼び出しますが、
+新しい RTE はそれに応答しないため、プレイブックは実行されません。自分で変更したシードにも、同じ認証情報と `rte_mode` が必要です。
+
+シードが作成したランナーは、 `CONFIG_SEED_PATH` を削除した後も管理対象のままで、 **接続 → ランナー** では読み取り専用です。宣言しなくなったランナーを
+解放できるのは、適用されたシードだけです。そのため、 `CONFIG_SEED_PATH` を削除してランナーを手動で変更するのではなく、シードを残してそこで `rte_mode` を設定してください。
+
+[インストーラー](../installation/installer.html#upgrade) はこれを自動で行います。アップグレードで `docker-compose.yml` を置き換え、 `data/seed.yaml` も
+リポジトリが配布したもので変更されていなければ置き換えます。手動で変更したものは残し、新しいものをその隣に保存します。
+
+---
+
+## 1. 新しいイメージを pull する
+
+`docker-compose.yml` にあるタグの最新イメージをダウンロードします。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. コンテナーを作り直す
+
+プロジェクトをもう一度起動します。イメージが変わったコンテナーが作り直されます。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. アップグレードを確認する
+
+起動中の AnsibleForms のログを追います。新しいリリースの初回起動ではデータベースのスキーマがアップグレードされ、AnsibleForms が正常になると
+RTE が起動します。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+AnsibleForms では、 **ヘルプ → バージョン情報** で実行中のバージョンを確認でき、 **設定 → ステータス** でデータベース、スキーマ、
+AnsibleForms が依存するその他のシステムの状態を確認できます。
+
+---
+
+## ロールバック
+
+以前に実行していたリリース（アップグレード前に **ヘルプ → バージョン情報** に表示されていたバージョン）に戻すには、
+`docker-compose.yml` で AnsibleForms と RTE の両方のイメージについて、 `7` の代わりにその正確なタグを固定し、ステップ 2 をもう一度実行します。そのリリースが
+アップグレード済みのデータベースで起動しない場合は、 **設定 → バックアップ** で取ったバックアップを復元します。再び更新を受け取るには、タグを
+`7` に戻してください。
+
+**動画**: [AnsibleForms のアップグレード方法](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/ja/_get_started/upgrading/docker.md b/i18n/ja/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..2116725
--- /dev/null
+++ b/i18n/ja/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: アップグレード
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+docker-compose を使わない単独のコンテナーをアップグレードします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+単独のインストールは、コンテナーを置き換えることでアップグレードします。新しいイメージを pull し、古いコンテナーを削除して、
+同じ `run` コマンドで新しいコンテナーを起動します。バージョン 7 以降、コンテナーは 2 つあります。AnsibleForms と、プレイブックを実行する
+RTE で、常に同じリリースです。ファイルはマウントした `/app/dist/persistent` フォルダーに、データは
+MySQL に保存されているため、どちらもそのまま残ります。
+
+---
+
+## アップグレードの前に
+
+問題が起きたときに元に戻せるよう、アップグレードの準備をします。
+
+* **設定 → バックアップ** で **バックアップを取ります** 。新しいリリースは初回起動時にデータベースのスキーマをアップグレードします。
+* 現在のバージョンと新しいバージョンの間のリリースについて **[変更履歴](../changelog) を読みます** 。
+* **新しいメジャーバージョンに移行しますか?** 先に [v7 へのアップグレード](../upgrade-7.html) に従ってください。
+* **6.5 から移行しますか?** 7 のイメージは root ではなく uid 1000 で動作します。マウントするフォルダーの所有者を一度だけこのユーザーにしてください。
+  たとえば `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh` です。
+* **7.2 から移行しますか?** RTE は専用のファイルを使い、アプリが RTE に接続するようになります。まず [7.2 から 7.3 へ](#from-72-to-73) を参照してください。
+
+---
+
+## 7.2 から 7.3 へ
+
+7.2.0 までは、RTE はデータベースの設定を含むアプリの環境ファイルを読み取り、 `RTE_URL` から自分自身をランナーとして追加していました。これが
+データベースモードで、7.3.0 で非推奨になり、8.0.0 で削除されます。7.3.0 以降、アプリは RTE に接続して 1 本の WebSocket を開いたままにし
+（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）、RTE はデータベースの設定を持ちません。ステップ 2 の前に一度だけ、次を行います。
+
+1. [インストール](../installation/docker.html#prepare-the-folders) と同じように `/srv/apps/ansibleforms/rte.env` を作成し、
+   `RTE_MODE=inbound` 、同じ `RTE_TOKEN` 、 `RTE_FILES=local` 、 `PORT=8000` 、 `HTTPS=0` を設定します。 `DB_*` 、 `ENCRYPTION_SECRET` 、 `RTE_URL` は入れません
+2. そのモードでランナーを宣言します。インストールの [設定シード](../seed/) 、つまり RTE の認証情報
+   （ `url: http://rte:8000` 、 `password: ${RTE_TOKEN}` ）とランナー `rte` （ `rte_mode: inbound` ）を持つ `persistent/seed.yaml` を追加し、
+   アプリの環境ファイルに `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` を追加します。またはシードを使わずに、
+   **接続 → ランナー** でランナーを開き、 **モード** を **インバウンド** に設定して、 `http://rte:8000` とトークンを持つ RTE の認証情報を選びます
+
+シードを使う場合、シードはアプリの環境ファイルから `RTE_TOKEN` を読み取るため、アプリの環境ファイルにも同じトークンの `RTE_TOKEN` を入れます。
+
+---
+
+## 1. 新しいイメージを pull する
+
+実行しているタグの最新の AnsibleForms と RTE のイメージをダウンロードします。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. コンテナーを置き換える
+
+古いコンテナーを削除し、 [インストール](../installation/docker.html) の `run` コマンドで新しいコンテナーを起動します。アプリは
+環境ファイルから、AnsibleForms のデータベースユーザー（root ではない）を使ったデータベースの接続設定を読み取ります。RTE はデータベースの設定を含まない
+専用の `rte.env` を読み取り、アプリは両方のコンテナーが共有するネットワーク経由で RTE に接続します。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+6.5 から移行する場合は、まだ RTE のコンテナーがないため、 `stop` と `rm` のコマンドはアプリだけを対象にします。共有ネットワークは
+`docker network create ansibleforms` （または `podman network create ansibleforms` ）で一度だけ作成します。
+[インストール](../installation/docker.html#prepare-the-folders) と同じように、データベースの接続設定、 `ENCRYPTION_SECRET` 、16 文字以上の `RTE_TOKEN` 、
+`CONFIG_SEED_PATH` をアプリの環境ファイルに入れ、 `rte.env` と設定シードを作成します。6.5 のインストールで別のフォルダーをマウントしていた場合は、
+そのフォルダーを使ってください。シードによって RTE が **接続 → ランナー** に既定のランナー `rte` として追加されます。
+[v7 へのアップグレード](../upgrade-7.html#playbooks-run-on-an-rte) を参照してください。
+
+---
+
+## 3. アップグレードを確認する
+
+起動中の AnsibleForms のログを追います。新しいリリースの初回起動ではデータベースのスキーマがアップグレードされます。
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+RTE は専用のログを書き込み、 `docker logs rte` で確認できます。AnsibleForms では、 **ヘルプ → バージョン情報** で実行中のバージョンを確認でき、 **設定 → ステータス** でデータベース、
+スキーマ、AnsibleForms が依存するその他のシステムの状態を確認できます。
+
+---
+
+## ロールバック
+
+以前に実行していたリリース（アップグレード前に **ヘルプ → バージョン情報** に表示されていたバージョン）に戻すには、 `7` の代わりにその正確なタグを
+AnsibleForms と RTE の両方のイメージに指定して、ステップ 2 をもう一度実行します。そのリリースがアップグレード済みの
+データベースで起動しない場合は、 **設定 → バックアップ** で取ったバックアップを復元します。
diff --git a/i18n/ja/_get_started/upgrading/from-source.md b/i18n/ja/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..ac0154c
--- /dev/null
+++ b/i18n/ja/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: ソースから
+parent: アップグレード
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# ソースから
+{: .no_toc }
+
+ソースからビルドしたインストールをアップグレードします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+ソースからビルドしたインストールは、新しいリリースをチェックアウトし、再ビルドして、アプリケーションを再起動することで
+アップグレードします。設定、フォーム、プレイブック、証明書、ログは `server/persistent` に保存されており、Git や
+ビルドによって変更されることはありません。
+
+---
+
+## アップグレードの前に
+
+問題が起きたときに元に戻せるよう、アップグレードの準備をします。
+
+* **設定 → バックアップ** で **バックアップを取ります** 。新しいリリースは初回起動時にデータベースのスキーマをアップグレードします。
+* 現在のバージョンと新しいバージョンの間のリリースについて **[変更履歴](../changelog) を読みます** 。
+* **新しいメジャーバージョンに移行しますか?** 先に [v7 へのアップグレード](../upgrade-7.html) に従ってください。
+* 新しいリリースが必要とする **Node.js のバージョンを変更履歴で確認します** 。
+
+---
+
+## 1. 新しいリリースを取得する
+
+リリースタグを取得し、目的のリリースをチェックアウトします。リリースタグにはバージョン番号が付いており、 `git tag` で一覧表示できます。
+`main` ブランチには、まだリリースされていない変更が含まれていることがあります。
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. 再ビルドする
+
+インストール時と同じ 3 つのステップで再ビルドします。まずクライアントを再ビルドします。
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+次にサーバーの依存関係を更新します。
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+最後に、再ビルドしたクライアントをもう一度サーバーの `views` フォルダーにコピーします。
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+リポジトリのルートにある `.env.example` と自分の `persistent/.env` を比較し、リリースで追加された設定を取り込みます。
+
+---
+
+## 3. 再起動する
+
+新しいコードを読み込むため、アプリケーションとその RTE を再起動します。データベースのスキーマは初回起動時にアップグレードされます。
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+7.2 から移行する場合、RTE はデータベースの設定と `RTE_URL` を使うデータベースモードで動いていました。このモードは 7.3.0 で非推奨になり、8.0.0 で削除されます。
+[インストール](../installation/from-source.html#run) にあるとおり、RTE をインバウンドモードで起動し直し、そのランナーをシードまたは **接続 → ランナー** で RTE の認証情報とともに宣言します。
+手順は `pm2 delete ansibleforms-rte` の後に、その `pm2 start` コマンドです。
+
+PM2 を使わずにアプリケーションを実行している場合は、 `npm run start` を停止してもう一度起動します。
+
+---
+
+## 4. アップグレードを確認する
+
+起動中のアプリケーションのログを追います。
+
+```bash
+pm2 logs ansibleforms
+```
+
+AnsibleForms では、 **ヘルプ → バージョン情報** で実行中のバージョンを確認でき、 **設定 → ステータス** でデータベース、スキーマ、
+AnsibleForms が依存するその他のシステムの状態を確認できます。
+
+---
+
+## ロールバック
+
+以前に実行していたリリース（アップグレード前に **ヘルプ → バージョン情報** に表示されていたバージョン）に戻すには、
+`git checkout <version>` でそのタグをチェックアウトし、ステップ 2 と 3 のとおり再ビルドして再起動します。そのリリースがアップグレード済みのデータベースで起動しない場合は、
+**設定 → バックアップ** で取ったバックアップを復元します。
diff --git a/i18n/ja/_get_started/upgrading/index.md b/i18n/ja/_get_started/upgrading/index.md
new file mode 100644
index 0000000..5bdbc75
--- /dev/null
+++ b/i18n/ja/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: アップグレード
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# アップグレード
+{: .no_toc }
+
+AnsibleForms を新しいリリースに移行します
+{: .fs-6 .fw-300 }
+
+---
+
+稼働中のインスタンスの管理者向けです。インストールしたときと同じ方法で、新しいリリースに移行します。
+
+---
+
+## このセクションの内容
+
+アップグレードの手順は、AnsibleForms をどの方法でインストールしたかによって異なります。それぞれの方法を個別のページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [v7 へのアップグレード](../upgrade-7.html) | 7 に移行する前に、6.5 のうちに変更しておくこと |
+| [インストーラーで](../installation/installer.html#upgrade) | インストーラーで作成したインストールに対する `ansibleforms-installer upgrade` 。バックアップ、リリースノート、ロールバック |
+| [Docker](docker.html) | 新しいイメージを pull し、同じ設定でコンテナーを作り直します |
+| [Docker Compose](docker-compose.html) | 新しいイメージを pull し、docker-compose プロジェクトを再起動します |
+| [ソースから](from-source.html) | 新しいコードを pull し、再ビルドしてアプリケーションを再起動します |
+| [Kubernetes](kubernetes.html) | チャートリポジトリを更新し、自分の values で `helm upgrade` を実行します |
+
+{: .note }
+> **まずバックアップ** アップグレードの前にバックアップを取ってください（ **設定 → バックアップ** ）。データベースのスキーマは新しいリリースの初回
+> 起動時にアップグレードされるため、問題が起きたときにはバックアップがロールバックの起点になります。7.3.0 以降は、古いリリースからアップグレードする前に
+> ワーカー自身もリリース名を付けたバックアップを取ります。ただし
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) が `0` の場合は取りません。
+
+受け取るリリースは、実行しているイメージのタグによって決まります。 `latest` は最新のメジャーバージョンを追いかけ、 `7` のようなタグは
+そのメジャーバージョンに留まります。すべてのタグは [イメージタグ](../installation/#image-tags) に記載されています。
diff --git a/i18n/ja/_get_started/upgrading/kubernetes.md b/i18n/ja/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..f644945
--- /dev/null
+++ b/i18n/ja/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: アップグレード
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Helm チャートで作成したインストールをアップグレードします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+チャートの各バージョンは 1 つの AnsibleForms リリースをデプロイします。アップグレードでは、既存の values を使って新しいチャートのバージョンをインストールします。
+永続ボリューム上のデータはそのまま残ります。何も変更しないアップグレードでは、Pod には手が加えられません。
+
+---
+
+## アップグレードの前に
+
+問題が起きたときに元に戻せるよう、アップグレードの準備をします。
+
+* **設定 → バックアップ** で **バックアップを取ります** 。新しいリリースは初回起動時にデータベースのスキーマをアップグレードします。
+* 現在のバージョンと新しいバージョンの間のリリースについて **[変更履歴](../changelog) を読みます** 。
+* **新しいメジャーバージョンに移行しますか?** 先に [v7 へのアップグレード](../upgrade-7.html) に従ってください。
+* values の変更点について **チャートの [変更履歴](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) を読みます** 。
+* **生成された認証情報を使っている場合** （ `secrets.generate` ）は、 `<release>-secrets` Secret をバックアップしてください。 `ENCRYPTION_SECRET` は復元できません。
+* **7.2 から移行しますか?** サーバー Pod 内の RTE のモードが変わります。 [7.2 から 7.3 へ](#from-72-to-73) を参照してください。
+
+---
+
+## 7.2 から 7.3 へ
+
+チャート 7.3.0 では、アプリの隣にある RTE を、7.3.0 で非推奨になり 8.0.0 で削除されるデータベースモードから移行します。アプリは
+`127.0.0.1` の RTE に接続して 1 本の WebSocket を開いたままにします（ `RTE_MODE=inbound` 、 [モード](../rte/modes.html) を参照）。
+
+* RTE のコンテナーは `DB_HOST` 、 `DB_USER` 、 `DB_PASSWORD` 、 `ENCRYPTION_SECRET` 、 `RTE_URL` を受け取らなくなり、ジョブのファイルを
+  共有ボリュームから取得します（ `RTE_FILES=local` ）
+* チャートの設定シードは、トークンとアドレスを持つ RTE の認証情報と、それでサインインする `rte_mode: inbound` のランナーを
+  宣言します。チャートのシードを使っていれば、何もする必要はありません
+* `containers.rte.seedRunner: false` を指定している場合や独自の設定シード（ `CONFIG_SEED_PATH` ）を使っている場合、RTE は自分自身をランナーとして追加しなくなります。
+  シードまたは **接続 → ランナー** で自分で宣言してください。 `http://127.0.0.1:<port>` とトークンを持つ RTE の認証情報と、
+  それを指定する `rte_mode: inbound` の種類 RTE のランナーです。方法はアップグレード後に Helm が表示するノートに記載されています
+
+7.3.0 以降、チャートは `runner.enabled` でランナーだけをインストールすることもできます（
+[Kubernetes 上のランナー](../installation/kubernetes.html#a-runner-on-kubernetes) を参照）。
+
+---
+
+## 1. 新しいチャートのバージョンを探す
+
+チャートリポジトリを更新し、利用できるチャートのバージョンを一覧表示します。
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. リリースをアップグレードする
+
+インストール時と同じ `helm upgrade` コマンドを、自分の values ファイルと新しいチャートのバージョンを指定して実行します。
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+OCI レジストリを使う場合は、チャートとして `oci://ghcr.io/ansibleforms/charts/ansibleforms` を指定します。
+
+---
+
+## 3. アップグレードを確認する
+
+新しい Pod を待ってから、Web サーバーとデータベース接続の両方を確認するチャートのテストを実行します。
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+AnsibleForms では、 **ヘルプ → バージョン情報** で実行中のバージョンを確認でき、 **設定 → ステータス** でデータベース、スキーマ、
+AnsibleForms が依存するその他のシステムの状態を確認できます。
+
+---
+
+## ロールバック
+
+Helm はリリースの履歴を保持しています。前のリビジョンに戻すには次のようにします。
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+アップグレード済みのデータベースで起動しない場合は、バックアップを復元します（チャートの [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) を参照）。
diff --git a/i18n/ja/_integrate/api/authentication.md b/i18n/ja/_integrate/api/authentication.md
new file mode 100644
index 0000000..70f7a69
--- /dev/null
+++ b/i18n/ja/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: 認証
+parent: REST API
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# 認証
+{: .no_toc }
+
+ログイン、トークンの更新、長期間有効なトークンの利用
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+すべての呼び出しには、 `Authorization` ヘッダーにアクセストークンが必要です。トークンはログインして取得し、
+リフレッシュトークンで更新し続けます。
+
+---
+
+## ログインする
+
+ユーザー名とパスワードを使い、Basic 認証でログインします。
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+レスポンスには、アクセストークンとリフレッシュトークンの 2 つのトークンが含まれます。
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## API を呼び出す
+
+すべての呼び出しで、アクセストークンを Bearer トークンとして送ります。
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## トークンを更新する
+
+アクセストークンには有効期限があります（ `ACCESS_TOKEN_EXPIRATION` 、既定は 30 分）。パスワードを使わずに、
+リフレッシュトークンで新しいトークンを取得します。
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+レスポンスには、ログインと同じ形式で新しいペアが含まれます。リフレッシュトークンは 1 回しか使えないので、次の更新のために新しいものを保存してください。
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## 長期間有効なトークン
+
+無人で実行するスクリプトでは、より長く有効なトークンを使えます。7.3.0 以降は、ロールのオプション `allowApiTokens` が必要です。
+
+* [プロフィール > API トークン](../profile/api-token.html) で作成します。
+* または、クエリパラメーター `expiryDays` を付けてログインし、その日数だけ有効なトークンを取得します。
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` は URL からのみ読み取られ、本文からは読み取られません。ロールに `allowApiTokens` がないユーザーの場合は無視され、
+ログインでは通常の有効期間のトークンが返されます。 `expiryDays=never` には `extendedTokenExpiration` も必要です。クエリパラメーター `name`
+（ `?expiryDays=90&name=nightly-backup` ）を追加すると、ユーザーのトークン一覧でトークンに名前が付きます。
+
+長期間有効なトークンの有効期間は、最大で [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) 日（既定は 90 日）です。
+これより長い `expiryDays` は、 `never` でない限りこの値に切り詰められます。更新すると通常のトークンが返されるため、期限が切れたらもう一度ログインしてください。
+
+### サインイン中のユーザーのトークン
+
+プロフィールの **API トークン** 画面は次のエンドポイントを使います。パスワードが不要なため、SSO を含むどのアカウントでも動作します。
+
+| 呼び出し | 内容 |
+|---|---|
+| `GET /api/v2/profile/tokens` | 自分の API トークンを、 `sid` 、 `name` 、作成日時、有効期限、最終使用とともに一覧表示します |
+| `POST /api/v2/profile/tokens` | 現在のセッションからトークンを作成します。本文には `expiryDays` （数値または `never` ）と、省略可能な `name` を指定します |
+| `DELETE /api/v2/profile/tokens/{sid}` | 自分のトークンの 1 つを取り消します |
+
+`POST` は、API トークンで呼び出した場合（トークンで別のトークンは作れません）、 `allowApiTokens` がない場合、またはセッションのサインインから
+10 分以上経っている場合（コード `sign_in_again` ）に `403` を返します。その場合は先にもう一度サインインしてください。最大値を超える有効期間には `400` を返します。
+
+---
+
+## トークンが早く失効する場合
+
+長期間有効かどうかにかかわらず、次のいずれかが起きると、トークンは有効期限より前に使えなくなります。
+
+* **そのセッションのログアウト** : そのトークンで `POST /api/v2/auth/logout` を呼び出すと、そのログインのトークンだけが失効します。
+  ブラウザーでログアウトしても、スクリプトのトークンは失効しません。
+* **パスワードの変更** : ユーザーが自分のパスワードを変更するか、管理者がパスワードを設定した場合です。それ以前に発行されたトークンはすべて拒否されます。
+* **ユーザーの削除またはブロック** : ローカルユーザーを削除するか、ユーザーをブロックすると、そのユーザーのすべてのトークンが失効します。管理者は
+  LDAP や SSO のユーザーのセッションを終了することもできます。
+
+拒否されたトークンには `401` が返されます。パスワードが変わった場合は新しいパスワードで、もう一度ログインしてください。
+
+---
+
+## 実行のたびにログインするスクリプト
+
+ログインとトークンのエンドポイントは、大量のリクエストやパスワードの推測から保護されています。実行のたびにログインするスクリプトでは、
+次の制限を把握しておいてください。
+
+| 制限 | 既定値 | 起きること |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 1 つのアドレスから 1 分あたり 120 リクエスト | ログイン、ログアウト、更新、SSO のエンドポイント、 `PUT /api/v2/profile` （パスワードの変更）、 `POST` または `DELETE /api/v2/profile/tokens` が `429` を返します |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 連続 5 回のログイン失敗 | アカウントが [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) （15）分ロックされ、すべてのログインが `429` を返します |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 1 つのアドレスから 30 回のログイン失敗 | 期間が終わるまで、そのアドレスからのすべてのログインが `429` を返します |
+
+`429` には、待つべき秒数を示す `Retry-After` ヘッダーが付きます。すぐに再試行せず、止めて待ってください。ロックされたアカウントは
+ロックが解除されるまで正しいパスワードも拒否するため、間違ったパスワードを使うスクリプトは、そのユーザーを全員に対してロックアウトしてしまいます。
+パスワード変更（ `PUT /api/v2/profile` ）で現在のパスワードを間違えた場合もログイン失敗として数えられ、ロックされたアカウントは
+パスワードを変更できません。ログインに成功するとアカウントの失敗回数はリセットされ、管理者がパスワードを設定した場合もリセットされます。
+
+これらの制限に引っかからないよう、呼び出しのたびにログインするのではなく、一度ログインしてトークンを再利用するか、長期間有効なトークンを
+使ってください。リバースプロキシの背後では、サーバーがクライアントのアドレスを認識できるよう [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) を設定してください。
+設定しないと、すべてのクライアントが 1 つとして数えられます。
diff --git a/i18n/ja/_integrate/api/events.md b/i18n/ja/_integrate/api/events.md
new file mode 100644
index 0000000..3f83cbd
--- /dev/null
+++ b/i18n/ja/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: ライブイベント
+parent: REST API
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# ライブイベント
+{: .no_toc }
+
+ポーリングせずに、ジョブや設定の変更を受け取ります
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+サーバーは、変更が起きるとその都度クライアントに通知します。スクリプトも、数秒ごとにジョブを読み取る代わりに、これを受け取ることができます。
+
+---
+
+## ストリーム
+
+`GET /api/v2/events` は、開いたままになる [Server-Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+のストリームです。サインインしているユーザーなら誰でも、通常の Bearer トークンで開けます。
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+何かが変わると、変わったものの名前を付けて `changed` イベントを送ります。
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## イベント名
+
+イベントが運ぶのは名前だけでデータは含まないため、ユーザーが見られないものが漏れることはありません。送られる名前は次のとおりです。
+
+| 名前 | 変わったもの |
+|---|---|
+| `jobs` | ジョブ。起動、ステータスや出力の変化、削除 |
+| `appearance` | ヘッダーに表示される設定。テーマ、名前、お知らせ、環境変数 |
+| `designer` | デザイナーのロックの取得または解放 |
+| `runners` | ランナー（7.3.0 以降）。RTE の接続または切断、参加の要求、承認または拒否、モードや設定の変更 |
+
+名前を受け取ったら、表示しているものを通常の API（たとえば `GET /api/v2/job/42` ）で、自分の権限で読み直します。
+頻繁に変わる名前は、最大でも 1 秒に 1 回しか送られません。
+
+---
+
+## 接続を維持する
+
+ストリームはプロキシやロードバランサーを通っても切れないように作られており、クライアントは自動で再接続します。
+
+* 接続すると、サーバーは `hello` イベントを送り、再接続の前に 3 秒待つようクライアントに指示します。
+* アイドル状態の接続が閉じられないよう、15 秒ごとにコメント行（ `: ping` ）を送ります。 `:` で始まる行は無視してください。
+* どのアプリノードからのイベントも、クライアントがどのノードに接続しているかに関係なく、すべてのストリームに届きます。
+* 再接続した後は、表示しているものを読み直してください。ストリームが切れている間に送られたイベントは再送されません。
+
+---
+
+## ヘルスとメトリクス
+
+liveness と readiness のプローブ（ `/api/v2/live` 、 `/api/v2/ready` ）と Prometheus のメトリクス（ `/api/v2/metrics` ）は、
+ユーザーとして動作するスクリプトではなく、監視ツール向けのものです。 [監視](../production/monitoring.html) を参照してください。
diff --git a/i18n/ja/_integrate/api/index.md b/i18n/ja/_integrate/api/index.md
new file mode 100644
index 0000000..aa3174a
--- /dev/null
+++ b/i18n/ja/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: REST API
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# REST API
+{: .no_toc }
+
+スクリプトからフォームを起動し、AnsibleForms を管理します
+{: .fs-6 .fw-300 }
+
+---
+
+開発者と自動化エンジニア向けです。スクリプトからフォームを起動し、AnsibleForms を管理します。
+
+Web インターフェースが行うことはすべて REST API を経由するため、スクリプトやほかのツールでも同じことができます。
+
+---
+
+## 概要
+
+API は AnsibleForms サーバーの `/api/v2` で提供されています。
+
+* **完全なリファレンス** : これらのページでは、スクリプトでよく使うものを説明しています。すべてのエンドポイントは、
+  サーバーに組み込まれた Swagger ページ `https://<your server>/api/v2/docs` で説明されており、試すこともできます。
+* **権限** : 呼び出しは、ブラウザーと同じく、そのトークンの持ち主であるユーザーとして、そのユーザーのロールで実行されます。
+* **起動時の検証** : API から起動したジョブも、ブラウザーからの起動と同じようにチェックできます
+  （ [起動時の検証](../launch-validation/) を参照）。
+* **レート制限** : 制限されるのは、ログイン、ログアウト、トークンの更新、シングルサインオンのエンドポイント、パスワードの変更
+  （ `PUT /api/v2/profile` ）、API トークンのエンドポイント（ `POST` と `DELETE /api/v2/profile/tokens` ）だけです（
+  [認証](authentication.html) を参照）。それ以外の呼び出しにはレート制限がありません（ [チャットアシスタント](../chat/) には独自の
+  制限があります）。そのため、たとえばジョブを追跡するときなどは、スクリプト側で呼び出しの間隔を調整してください。
+
+---
+
+## このセクションの内容
+
+トピックごとに個別のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [認証](authentication.html) | ログイン、トークンの更新、長期間有効なトークンの利用 |
+| [ジョブ](jobs.html) | フォームの起動、ジョブの追跡、中止、再起動、承認 |
+| [レスポンスとエラー](responses.html) | レスポンスの形式とステータスコード |
+| [ライブイベント](events.html) | ポーリングせずに、ジョブや設定の変更を受け取る |
diff --git a/i18n/ja/_integrate/api/jobs.md b/i18n/ja/_integrate/api/jobs.md
new file mode 100644
index 0000000..b2d0db5
--- /dev/null
+++ b/i18n/ja/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: ジョブ
+parent: REST API
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# ジョブ
+{: .no_toc }
+
+フォームの起動、ジョブの追跡、中止、再起動、承認
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+ジョブはフォームの 1 回の実行です。フォームの名前と値を指定して起動し、その ID で追跡します。
+
+---
+
+## フォームを起動する
+
+フォーム名とその値を `POST /api/v2/job` に送ります。
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+リクエストには次のプロパティを指定します。
+
+| プロパティ | 意味 |
+|---|---|
+| `formName` | 起動するフォームの名前。必須です。 |
+| `extravars` | ジョブの追加変数。別名として `payload` も受け付けます。 |
+| `rawFormData` | ブラウザーが保持しているとおりの、フォームのフィールドの値。 [起動時の検証](../launch-validation/) はこれをチェックし、そこから extravars を組み立てます。 |
+| `credentials` | ジョブに渡す認証情報。名前で指定します。 |
+| `files` | フォームのファイルフィールドのアップロード（ [ファイルのアップロード](../launch-validation/file-uploads.html) を参照）。 |
+
+レスポンスには新しいジョブの ID が含まれます。
+
+```json
+{ "id": 42 }
+```
+
+ジョブを詳細モードで実行するには、extravars に `"__verbose__": true` を追加します。これにはロールのオプション `allowVerboseMode` が必要で、
+ない場合は起動が `403` を返します。
+
+---
+
+## ファイルをアップロードする
+
+ファイルフィールドを持つフォームでは、先にファイルをアップロードする必要があります。マルチパートのパート `file` として `POST /api/v2/job/upload` に送ります。
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+応答には保存されたアップロードの内容が記述されています。
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+これを変更せずに、起動の `files` にファイルフィールドの名前で渡します。 `"files": { "firmware": { ... } }` のようにします。サーバーは
+それを自分のディスクと照合してチェックします（ [ファイルのアップロード](../launch-validation/file-uploads.html) を参照）。
+
+---
+
+## ジョブを追跡する
+
+ID でジョブを読み取ります。
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+ジョブには `status` 、 `extravars` （同じオブジェクトが `payload` としても入ります）、 `subjobs` 、 `output` が含まれます。
+出力はジョブページの色付きの HTML です。スクリプトやログに向いたプレーンテキストにするには `?text=true` を追加します。
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+`status` は、実行中は `running` 、承認待ちの間は `approve` です。ジョブは次のいずれかで終了します。
+
+| ステータス | 意味 |
+|---|---|
+| `success` | ジョブがエラーなしで終了しました |
+| `failed` | ジョブが失敗しました |
+| `warning` | マルチステップのジョブは終了しましたが、途中で `continue` が設定されたステップが失敗しました |
+| `aborted` | ジョブが中止されました |
+| `rejected` | 承認が拒否されたため、それを待っていたものは実行されませんでした |
+| `abandoned` | ジョブを追跡していたプロセスが停止し（再起動、コンテナーの置き換え）、ジョブが放棄されました |
+
+放棄されたときにランナー上で実行中だったジョブは、そのランナーが最後まで実行すれば、実際の結果で終了することがあります。
+
+---
+
+## ジョブを探す
+
+`GET /api/v2/job` は、新しいジョブから順に `{ "count": ..., "records": [ ... ] }` として一覧を返します。次のクエリパラメーターで絞り込めます。
+
+| パラメーター | 意味 |
+|---|---|
+| `records` | 返すジョブの最大数。既定は [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) （1000）で、 `JOBS_LIST_SIZE` がそれより大きくない限り最大は 5000 です。 |
+| `user`, `user_type` | このユーザーのジョブだけ。 `user_type` は省略すると `local` です（それ以外は `ldap` 、 `azuread` 、 `oidc` ）。 |
+| `runner` | このランナーで実行されたジョブだけ |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+ユーザーに見えるのは、自分のジョブと、自分のロールのいずれかで承認できる承認待ちのジョブです。管理者、または
+`showAllJobLogs` か `manageAllJobs` のオプションを持つロールには、すべてのジョブが見えます。レコードにはジョブの概要（ `id` 、 `form` 、 `status` 、 `start` 、 `end` 、 `user` 、 `runner` など）が含まれます。
+extravars と出力を見るには、ジョブ自体を読み取ってください。
+
+`GET /api/v2/job/approvals` は数値を返します。ユーザーが承認できる、承認待ちのジョブの数です。
+
+---
+
+## ジョブの詳細
+
+次のエンドポイントで、1 つのジョブについてさらに詳しく読み取れます。
+
+| 呼び出し | 返すもの |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | ジョブを起動したときのフィールドの値。フォームが保持していたとおりのものです。再起動と同じ権限が必要です。自分のジョブ（管理者や `manageAllJobs` を持つロールならすべてのジョブ）であること、再起動を許可するフォームであること、ロールのオプション `allowJobRelaunch` があることです。 |
+| `GET /api/v2/job/{id}/events` | プレイブックのジョブの構造化されたイベント（7.3.0 以降、7.3.0 以降の RTE 上のプレイブックの場合）。各プレイ、タスク、ホストの結果、まとめを、 `order` 、 `type` 、 `play` 、 `task` 、 `host` 、 `duration` 、 `time` とともに返します |
+| `GET /api/v2/job/{id}/events/{order}` | それらのイベントの 1 つを、 **タスクの結果** ダイアログと同じく `result` 全体とともに返します。 `order` が整数でない場合は `400` 、そのイベントがジョブにない場合は `404` です |
+| `GET /api/v2/job/{id}/node/{nodeId}` | ワークフローのジョブの 1 つのノード。 `{ "node", "job", "extravars", "artifacts" }` を返します。 `job` はノード自身のジョブの ID で、ノードが実行されなかった場合は `null` です。 |
+
+---
+
+## その他の操作
+
+次のエンドポイントは既存のジョブに対して操作します。
+
+| 呼び出し | 操作 |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | 実行中のジョブを中止します |
+| `POST /api/v2/job/{id}/relaunch` | ジョブを、実行したとおりに、または変更を加えて再起動します（ [再起動](../launch-validation/relaunching.html) を参照） |
+| `POST /api/v2/job/{id}/approve` | 承認待ちのジョブを承認します。自分のジョブは、その承認で `allowSelf: true` が設定されているか管理者でない限り `403` を返します |
+| `POST /api/v2/job/{id}/reject` | 承認待ちのジョブを拒否します |
+| `GET /api/v2/job/{id}/download` | ジョブの出力をダウンロードします |
+| `DELETE /api/v2/job/{id}` | ジョブを削除します |
+
+中止、承認、拒否、削除はメッセージを返し、再起動はさらに新しいジョブの ID も返します。
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+再起動に `?verbose=true` を追加すると、ロールのオプション `allowVerboseMode` がある場合、新しいジョブを詳細モードで実行します。操作に対して
+ジョブの状態が正しくない場合、たとえばすでに終了したジョブを中止しようとした場合は、 `409` が返されます。
diff --git a/i18n/ja/_integrate/api/responses.md b/i18n/ja/_integrate/api/responses.md
new file mode 100644
index 0000000..799e3cd
--- /dev/null
+++ b/i18n/ja/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: レスポンスとエラー
+parent: REST API
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# レスポンスとエラー
+{: .no_toc }
+
+レスポンスの形式とステータスコード
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+レスポンスはプレーンな JSON で、呼び出しが成功したかどうかは HTTP ステータスコードでわかります。
+
+---
+
+## レスポンス
+
+成功した呼び出しは、オブジェクトそのもの、またはリストとそのサイズを返します。
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+エラーはメッセージを返し、詳細があればそれも返します。
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## ステータスコード
+
+ステータスコードで、何が問題だったかがわかります。
+
+| コード | 意味 |
+|---|---|
+| `200` | 呼び出しが成功しました |
+| `400` | リクエストの形式が正しくありません。たとえば、リフレッシュトークンのないトークン更新や、ファイルのないアップロードです |
+| `401` | トークンがない、間違っている、または期限切れです。ログインするか更新してください |
+| `403` | ユーザーのロールではその呼び出しが許可されていません（承認で `allowSelf: true` が設定されているか管理者でない限り、自分のジョブの承認も含みます）。または、アカウントで先に行うべきことがあります（下記を参照） |
+| `404` | オブジェクトが存在しません |
+| `409` | リクエストが不完全です（データのない起動）。または、オブジェクトがその操作を許可する状態にありません |
+| `422` | [起動時の検証](../launch-validation/) がフォームの値を拒否しました。理由は `details` に列挙されています |
+| `429` | ログインとトークンのエンドポイントへのリクエストが多すぎるか、ログインの失敗が多すぎます（ [認証](authentication.html) を参照） |
+| `500` | サーバーで失敗しました。理由はサーバーログにあります |
+
+ジョブの場合、 `409` は操作に対してジョブの状態が正しくないことを意味します。実行中でない（またはすでに中止が要求された）ジョブの中止、
+まだ実行中のジョブの再起動、承認待ちでなくなったジョブの承認や拒否です。
+
+---
+
+## コード付きの 403
+
+`403` の応答の中には `code` が付いているものがあります。ほかの呼び出しが動くようになる前に、ユーザーがブラウザーで行うべきことを示します。
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| コード | 行うこと |
+|---|---|
+| `password_change_required` | ユーザーが公開されている既定のパスワードでサインインしました。まずプロフィールで変更してください |
+| `disclaimer_required` | 免責事項が有効で、ユーザーがまだその現在のバージョンに同意していません。ブラウザーで同意してください |
+
+長期間有効な API トークン（ [認証](authentication.html#long-lived-tokens) を参照）が免責事項によって止められることはありません。
diff --git a/i18n/ja/_integrate/chat/index.md b/i18n/ja/_integrate/chat/index.md
new file mode 100644
index 0000000..7f58cb0
--- /dev/null
+++ b/i18n/ja/_integrate/chat/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: チャットアシスタント
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# チャットアシスタント
+{: .no_toc }
+
+会話を通じてフォームを入力し、起動します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+これを有効にする管理者と、これとチャットするユーザー向けです。会話を通じてフォームを入力し、起動します。
+
+すべてのページにあるチャットボタンでアシスタントが開きます。アシスタントは適切なフォームを見つけ、足りない情報を尋ね、フォーム自身の
+選択肢をボタンとして示し、 **起動** ボタン付きの概要を表示します。ジョブが開始されるのは、ユーザーがそのボタンをクリックしたときだけです。
+
+---
+
+## 仕組み
+
+アシスタントはサーバーを介して AI モデルと通信し、サーバーはブラウザーと同じフォームエンジンを使ってモデルの要求に応えます。
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **モデルの呼び出しはサーバーから行われます。** ブラウザーからは行われないため、API キーはサーバーに留まります
+  （ [プロバイダー](providers.html) を参照）。
+- **モデルは何も起動できません。** モデルが用意するのは 1 回限りの概要で、起動の前に再チェックされます。
+- **対象を選ぶのはユーザーです。** 選択肢や必須の名前はユーザーから来るもので、モデルから来ることはありません。
+- **「yes」や「launch」と入力しても何も起きません。** ジョブを起動するのはボタンだけです。
+
+---
+
+## このセクションの内容
+
+トピックごとに個別のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [有効にする](switching-it-on.html) | アシスタントを有効にし、フォームをアシスタントで使えるようにする |
+| [プロバイダー](providers.html) | アシスタントの背後にある言語モデルとプロキシ |
+| [プライバシーと制限](privacy-and-limits.html) | ネットワークの外に出るもの、ユーザーごとの制限 |
+| [再起動と監査](relaunching-and-audit.html) | チャットからの再起動、監査証跡、制限事項 |
diff --git a/i18n/ja/_integrate/chat/privacy-and-limits.md b/i18n/ja/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..7083842
--- /dev/null
+++ b/i18n/ja/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: プライバシーと制限
+parent: チャットアシスタント
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# プライバシーと制限
+{: .no_toc }
+
+ネットワークの外に出るもの、ユーザーごとの制限
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ネットワークの外に出るもの
+
+対象となるフォームについて、次のものがプロバイダーに送られます。
+
+- フォームの名前と説明、フィールドのラベル、ヘルプテキスト、選択肢、そして入力中の
+  値
+- 会話
+
+次のものは、プロバイダーにも、ページにも、ログにも送られません。
+
+- パスワード（ユーザーがブラウザーで入力します）、保存された認証情報、API キー
+- ジョブの出力と、保存された extravars（アシスタントが読み取るのはジョブのステータスだけで、それも
+  設定で **アシスタントにジョブを追跡させる** がオンの場合に限られます）
+
+シークレットのように見えるキー（ `password` 、 `secret` 、 `token` 、 `api_key` など）の下にあるものは、
+モデルやページに見える前にマスクされます。
+
+フォームのデータを社内に留めるには、公開 API ではなく、自社のテナント（Azure OpenAI）またはローカルモデル（Ollama）を使ってください。
+
+---
+
+## 制限
+
+次の制限は設定ページで設定します。
+
+- **会話あたりのメッセージ数** （20）: これを超えると、ユーザーは新しい会話を始める必要があります。
+- **メッセージあたりのツールラウンド数** （6）: モデルが回答するまでにツールを呼び出せる回数です。
+- **タイムアウト** （60 秒）: プロバイダーへの 1 回の呼び出しごとの時間です。
+
+次の制限は固定です。1 つの会話につき同時に 1 メッセージ、1 メッセージあたり最大 4000 文字、ユーザーあたり 1 時間に
+60 メッセージ、ユーザーあたり 5 つの会話です。メッセージがないまま 2 時間経った会話は破棄されます。
+
+**起動** ボタン付きの概要カードは 1 回だけ使え、15 分で期限切れになります。その場合、起動すると概要の期限が切れたと
+表示されるので、ユーザーはアシスタントに新しい概要を頼みます。会話と概要はメモリに保持されるため、
+再起動の後はユーザーが新しい会話を始める必要があります。
diff --git a/i18n/ja/_integrate/chat/providers.md b/i18n/ja/_integrate/chat/providers.md
new file mode 100644
index 0000000..916075a
--- /dev/null
+++ b/i18n/ja/_integrate/chat/providers.md
@@ -0,0 +1,82 @@
+---
+layout: default
+title: プロバイダー
+parent: チャットアシスタント
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# プロバイダー
+{: .no_toc }
+
+アシスタントの背後にある言語モデルとプロキシ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+設定ページでプロバイダーを選びます。これにより、ベース URL、認証、API バージョンが入力されます。
+いずれも後から編集できます。空のフィールドにはプロバイダーの既定値が使われます。
+
+| プロバイダー | プロトコル | ベース URL（既定） | キーの送信方法 |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | 必須: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key` 、API バージョン `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | なし |
+| **その他の OpenAI 互換** （LiteLLM、ゲートウェイ、vLLM、LM Studio など） | OpenAI | 必須。通常は `/v1` で終わります | Bearer |
+
+モデル ID は、プロバイダーやプロキシが使っているもの（ `claude-opus-5-5` 、 `gpt-5` 、 `llama3.3` など）です。
+アシスタントには **ツール呼び出し** に対応したモデルが必要です。小さなローカルモデルでは対応状況がまちまちです。
+
+キーが不要なローカルサーバーやプロキシでは、ベース URL だけで十分です。その場合、認証ヘッダーは送られません。
+
+---
+
+## API キー
+
+キーは認証情報から取得されるため、ほかのシークレットと同じように保存し、ローテーションできます。
+
+* **設定 > 接続 > 認証情報** で、キーをパスワードとする種類 **api** の認証情報を作成します（ [認証情報](../credentials.html) を参照）。
+  キーを [シークレットストア](../secret-stores/) から読み取ることもできます。
+* チャット設定の **資格情報** フィールドでそれを選びます。キーはメッセージごとに読み取られるため、
+  パスワードを変更すると次のメッセージから反映されます。
+
+認証情報の機能ができる前に設定ページで保存したキーは、認証情報を選んでいない間は引き続き使えます。
+[設定シード](../seed/) では、キー自体を `api_key` として設定します。
+
+---
+
+## プロキシの場合
+
+モデルの前段にあるプロキシやゲートウェイでは、次の設定が必要になることがあります。
+
+- **認証** : キーの送信方法。 `Authorization: Bearer` 、 `api-key` 、 `x-api-key` 、
+  またはなし。空の場合はプロバイダーの既定値を使います。
+- **API バージョン** : `anthropic-version` ヘッダー、または OpenAI 互換（Azure）の場合は URL の `?api-version=` です。
+- **ユーザー** : すべての呼び出しで `user` （OpenAI 互換）または `metadata.user_id`
+  （Anthropic）として送られます。これを必要とするプロキシもあります。空の場合は何も送りません。
+- **証明書エラーを無視** : 安全ではありません。代わりに `NODE_EXTRA_CA_CERTS` でプロキシの CA を信頼させてください。
+- **追加ヘッダー** : JSON オブジェクト。例 `{"X-Org": "ops"}` 。値は 1 行のテキストで、最大 20 個です。
+  キーとコンテンツのヘッダーは置き換えられません。
+
+---
+
+## コンテナー内でプロキシの背後にある場合
+
+チャットは、AnsibleForms サーバーのコンテナーからの通常のアウトバウンド HTTPS を使います。社内の
+送信プロキシの背後では、 `HTTPS_PROXY` **と** `NODE_USE_ENV_PROXY=1` を設定してください。2 つ目がないと、
+Node の組み込み HTTP クライアントは `HTTPS_PROXY` を無視します。社内 CA の証明書を使うプロバイダーでは、
+Node にその CA を信頼させる必要があります（ `NODE_EXTRA_CA_CERTS=/path/to/ca.pem` ）。
+`NODE_USE_ENV_PROXY=1` を使う場合、ネットワーク内にあるモデルやプロキシは `NO_PROXY` に
+記載する必要があります。記載しないと、呼び出しは到達できない送信プロキシに向かってしまいます。
+
+接続テストに失敗すると、ホストとその理由（DNS、接続の拒否、信頼されていない証明書）が表示されます。
diff --git a/i18n/ja/_integrate/chat/relaunching-and-audit.md b/i18n/ja/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..43faf60
--- /dev/null
+++ b/i18n/ja/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: 再起動と監査
+parent: チャットアシスタント
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# 再起動と監査
+{: .no_toc }
+
+チャットからの再起動、監査証跡、制限事項
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 再起動
+
+「Run job 1234 again」のような要求（ユーザーがジョブ ID を入力する必要があります）は、MCP サーバーの `relaunch_job` と同じルールで
+再起動をプレビューし、 **再起動** の概要を表示します。このルールには [起動時の検証](../launch-validation) のパスワードのルールも含まれます。ボタンを押すと
+1 回だけ起動されます。「Run job 1234 again with server web02」と頼むと、そのフィールドだけが変更されます。
+
+---
+
+## 監査
+
+チャットからの起動はすべて **chat.launch** として、ユーザー、ジョブ、フォーム、
+プロバイダー、そして承認された概要のペイロードのハッシュとともに記録されます。チャット設定の変更は、
+ほかの設定の変更と同じように記録されます。
+
+---
+
+## 制限事項
+
+チャットアシスタントは、ブラウザーでできることのすべてにはまだ対応していません。
+
+- **ウィザードフォーム** は対象にできません（ `enableForChat` を指定すると拒否されます）。また、
+  アシスタントが入力しないフィールド、つまりパスワードとファイルのアップロードも対象外です。
+- 返信はまとめて届きます。ストリーミングにはまだ対応していません。
+- モデルが要求を誤解することがあります。概要カードには送られる内容がそのまま表示されるので、
+  **起動** をクリックする前に確認してください。
diff --git a/i18n/ja/_integrate/chat/switching-it-on.md b/i18n/ja/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..0e75a85
--- /dev/null
+++ b/i18n/ja/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: 有効にする
+parent: チャットアシスタント
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# 有効にする
+{: .no_toc }
+
+アシスタントを有効にし、フォームをアシスタントで使えるようにします
+{: .fs-6 .fw-300 }
+
+---
+
+アシスタントを使うには、次の 4 つがすべて必要です。
+
+1. **`ENABLE_CHAT=1`** : 環境変数です。設定ページで変更すると、再起動なしですぐに反映されます。オフの間は、
+   チャットのエンドポイントは `404` を返します。 [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) を参照してください。
+2. **モデルプロバイダー** : 設定 -> 接続 -> **チャットアシスタント** （Kubernetes では [設定シード](../seed) ）。
+3. **対象となるフォーム** : 各フォームに `enableForChat: true` を指定します。アシスタントはそれ以外のフォームをすべて無視します。
+4. **利用できるユーザー** : ロールのオプション `allowChat` （既定: true）。ロールに
+   `allowChat: false` を設定すると、そのメンバーを除外できます。
+
+4 つの条件がすべて満たされると、ユーザーにチャットボタンが表示されます。
diff --git a/i18n/ja/_integrate/mcp/index.md b/i18n/ja/_integrate/mcp/index.md
new file mode 100644
index 0000000..b48f9a5
--- /dev/null
+++ b/i18n/ja/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: MCP サーバー
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# MCP サーバー
+{: .no_toc }
+
+Model Context Protocol を通じて、AI エージェントがフォームを使えるようにします
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+管理者とインテグレーター向けです。MCP クライアントが、保持しているトークンのユーザーとして、フォームを一覧表示し、入力し、起動できるようにします。
+
+AnsibleForms は
+[Model Context Protocol](https://modelcontextprotocol.io) サーバーを提供できます。これにより、チャットのバックエンドや IDE のアシスタントなどの
+MCP クライアントが、ユーザーが使えるフォームを一覧表示し、そのフィールドを確定し、
+ジョブを起動して進捗を追跡できます。
+
+---
+
+## これは何か、何でないか
+
+MCP サーバーは、ブラウザーが使うのと同じフォームの流れへの技術的なインターフェースです。
+**受け取ったトークンのユーザーとして** 動作します。フォームのロール、ジョブの可視性、
+予約済みの extravars に対するチェックは、ブラウザーからの送信と同じです。
+
+独自の AI ポリシーは何も加えません。起動の前にエージェントが確認を求めるべきかどうか、
+どのフォームを使えるか、どれだけのリクエストを送れるかは、MCP クライアント次第です。
+起動のツールは破壊的なものとしてマークされているため、行儀のよいクライアントはまず確認を求めますが、
+サーバーがそれを強制することはありません。
+
+---
+
+## このセクションの内容
+
+トピックごとに個別のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [セットアップ](setup.html) | サーバーを有効にし、クライアントを認証する |
+| [ツール](tools.html) | エージェントがフォームの入力、承認、再起動に使うツール |
+| [制限事項](limitations.html) | サーバーで実行される式と、MCP サーバーが行わないこと |
diff --git a/i18n/ja/_integrate/mcp/limitations.md b/i18n/ja/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..8cafbc8
--- /dev/null
+++ b/i18n/ja/_integrate/mcp/limitations.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: 制限事項
+parent: MCP サーバー
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# 制限事項
+{: .no_toc }
+
+サーバーで実行される式と、MCP サーバーが行わないこと
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## runLocal の式
+
+`runLocal` の式、 `local` / `credential` / `html` フィールド、 `evalDefault` の既定値は、
+サーバー上の独立した V8 コンテキストで評価されます。 `process` 、 `require` 、ネットワーク、
+タイマーは使えず、文字列をコードにコンパイルすることもできません。制限時間は 2 秒で、使えるのはブラウザーが提供するヘルパー
+関数（ `fnArray` 、 `fnGetNumberedName` 、 `fnToTable` など）だけです。
+
+これはバグのある式や暴走する式から守るためのものです。悪意のあるコードに対するサンドボックスではありませんが、
+その必要もありません。コードはフォームの定義から来るもので、MCP の
+呼び出し元から来ることはなく、呼び出し元が送る値はすべて JavaScript のリテラルとして埋め込まれます。
+
+ブラウザーの API（ `window` 、 `document` 、 `fetch` ）を使う式はここでは実行できず、
+`status: error` を返します。
+
+サーバー側の式（ `runLocal` なし）には、ブラウザーの場合と同じ
+[`EXPRESSION_SANITIZER`](../customization) のルールが適用されます。
+
+---
+
+## 制限事項
+
+一部のフォームとフィールドは、まだ MCP サーバーから使えません。
+
+- **ウィザードフォーム** はまだ起動できません。そのステップは `subform` で解決できます。
+- **ファイルフィールド** は入力できません。ファイルフィールドに値があるフォームは拒否されます。
+- **リストの行** （およびサブフォームを持つ `yaml` フィールド。これも行の 1 つです）: 送った行は、リストの `deleteMarker` を持つものを除いて、
+  すべてフォームの値を `__parent__` としてそのサブフォームで解決され、その後検証されます。これにはネストしたリストも含まれ、
+  その場合は `__parent__.__parent__` でフォームに届きます。プレーンな行、つまりサブフォームのフィールドの生の
+  値を送ってください。失敗した行は、リストのフィールドごとに `rowErrors` に列挙されます
+  （メッセージでは `vms[1].disks[0].size (missing)` ）。1 回の呼び出しで受け付けるのは、すべての階層を合わせて最大 500 行です。
+- `__auto__` のままの enum に、最初の選択肢が入ることはありません。呼び出し元が選ぶ必要があります。
+- MCP のリクエストは、それぞれ監査ログに 1 件のエントリ（アクション「MCP リクエスト (AI エージェント)」）を作成します。
+  ジョブ自体は、ほかの起動と同じくそのユーザーのものとして記録されます。
diff --git a/i18n/ja/_integrate/mcp/setup.md b/i18n/ja/_integrate/mcp/setup.md
new file mode 100644
index 0000000..5ea9338
--- /dev/null
+++ b/i18n/ja/_integrate/mcp/setup.md
@@ -0,0 +1,118 @@
+---
+layout: default
+title: セットアップ
+parent: MCP サーバー
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# セットアップ
+{: .no_toc }
+
+サーバーを有効にし、クライアントを認証します
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 有効にする
+
+[`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) を `1` に設定するか、 **設定 > 接続 > MCP** で有効にします
+（ [MCP ページ](#the-mcp-page) を参照）。設定ページで変更すると、再起動なしですぐに反映されます。オフの間は、
+エンドポイントは `404` を返します。エンドポイントは次のとおりです。
+
+```
+POST <your url>/api/v2/mcp
+```
+
+プレーンな JSON レスポンスを返すステートレスな Streamable HTTP を使うため、 `GET` と `DELETE` は 405 を返します。
+
+---
+
+## エージェントにできることを制限する
+
+さらに 2 つのスイッチで、すべてのクライアントに対して MCP サーバーの機能を絞れます。 `ENABLE_MCP` と同じく、再起動なしで反映されます。
+
+| 変数 | `1` の場合 |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | 起動、計画、変更を行うツール（ `launch_job` 、 `relaunch_job` 、 `plan_job` 、 `create_schedule` 、 `delete_schedule` 、 `store_job` 、 `delete_stored_job` ）をまったく提供せず、拒否します。エージェントはフォームの一覧表示、読み取り、入力、スケジュールと保存済みジョブの読み取り、ジョブの追跡はできますが、何も起動も変更もできません。エージェントを安全に試す方法です。 |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | エージェントに見えるのは `enableForChat: true` を設定したフォームだけで、 [チャットアシスタント](../chat/) と同じ一覧です。それ以外のフォームとそのジョブは、見つからないものとして応答します。 |
+
+どちらも既定ではオフです。エージェントにはユーザーのロールが許可するすべてのフォームが見え、それらを起動できます。
+
+---
+
+## MCP ページ
+
+**設定 > 接続 > MCP** には、MCP サーバーの設定が 2 つのタブにまとめられています。
+
+- **一般** には 3 つのスイッチ `ENABLE_MCP` 、 `MCP_READ_ONLY` 、 `MCP_CHAT_FORMS_ONLY` があり、 **保存** で保存します。ほかの 2 つは
+  MCP サーバーがオンの間だけ変更できます。
+- **クライアントの構成** には、コピー用のボタン付きの **エンドポイント** と、 **Claude Code**
+  （ `.mcp.json` 、または `claude mcp add` コマンド）、 **Cursor** （ `~/.cursor/mcp.json` ）、 **VS Code** （ `.vscode/mcp.json` 。サーバーの初回起動時に
+  トークンを尋ねます）、 **Codex** （ `~/.codex/config.toml` 。トークンは環境変数
+  `ANSIBLEFORMS_TOKEN` に入れます）用のすぐに使える構成が表示されます。それぞれにコピーボタンがあります。 `<your-token>` は、
+  **トークンを作成** リンクで作成した自分のトークンに置き換えてください。
+
+エンドポイントは、アプリの URL（ **設定 > URL** ）が設定されていればそこから、なければブラウザーのアドレスから組み立てられます。
+
+---
+
+## 認証
+
+すべてのリクエストに AnsibleForms のアクセストークンが必要です。
+
+```
+Authorization: Bearer <token>
+```
+
+通常の方法（ `POST /api/v2/auth/login` 、または OIDC / Entra ID のフロー）で取得し、
+`POST /api/v2/token` で更新します。 **ログイン用のツールは意図的に用意していません。** ツールの引数として渡したパスワードは、
+言語モデルのコンテキストとチャット履歴に残ってしまうためです。
+
+ユーザーのロールでも、 `allowMcp` [ロールのオプション](../config/roles.html) で MCP サーバーが許可されている必要があります。ユーザーのどのロールにも
+これが設定されていない場合は、既定でオンの `allowChat` に従います。許可されていないユーザーは、すべてのリクエストで `403` を受け取ります。
+
+- **チャットのバックエンド** は自分でユーザーをログインさせ、リフレッシュトークンを保持し、すべての MCP 呼び出しでアクセス
+  トークンを渡します。
+- **IDE のクライアント** には、一度設定すれば済むだけの長さで有効なトークンが必要です。 `allowApiTokens` オプションを持つ
+  ロールがあれば、 [プロフィール > API トークン](../profile/api-token.html) で作成するか、ログイン URL に
+  `?expiryDays=<n>` を付けてログインし、その日数だけ有効なトークンを取得します。
+
+そのようなトークンでコーディングエージェントを接続するには、次のようにします。
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+トークンをヘッダーにしてサーバーを追加します。
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+トークンを環境変数から読み取るようにして、サーバーを `~/.codex/config.toml` に追加します。
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+その後、Codex を起動する前に変数を設定します。
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/ja/_integrate/mcp/tools.md b/i18n/ja/_integrate/mcp/tools.md
new file mode 100644
index 0000000..bad8ef9
--- /dev/null
+++ b/i18n/ja/_integrate/mcp/tools.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: ツール
+parent: MCP サーバー
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# ツール
+{: .no_toc }
+
+エージェントがフォームの入力、承認、再起動に使うツール
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+MCP サーバーは最大 15 個のツールを提供します。6 個はすべてのユーザーに提供され、残りはユーザーのロールのオプションに従います。そのため、
+オプションを持たないユーザーには、そのツールはまったく提供されません。
+
+| ツール | 内容 | 提供される条件 |
+|---|---|---|
+| `list_forms` | ユーザーが使えるフォーム。名前、説明、カテゴリ、そして `enableForChat` （チャットアシスタントがそのフォームを扱うかどうか）。 | 常に |
+| `get_form` | 1 つのフォームの完全な定義。各フィールドには `dynamic` （式やクエリから評価されるか）と `dependsOn` （読み取るフィールド）も付きます。 | 常に |
+| `resolve_field` | ここまでに入力された値でフォームを評価します。下記を参照してください。 | 常に |
+| `launch_job` | 指定した値で、ブラウザーからの送信とまったく同じようにフォームを起動します。ジョブ ID を返します。 | 常に |
+| `relaunch_job` | 一部のフィールドを変更してジョブをもう一度起動します。下記を参照してください。 | 常に |
+| `get_job` | ジョブのステータスと出力（ `tail` で出力を最後の数行に制限できます）。 | 常に |
+| `plan_job` | フォームを後で 1 回、ユーザーとして実行します。フォームの **後で実行 (1 回限り)** と同じです。 | `allowPlannedJobs` |
+| `create_schedule` | **スケジュール** ページと同じく、繰り返し（ `cron` ）または 1 回限り（ `run_at` ）のスケジュールを作成します。 | `allowScheduledJobs` |
+| `list_schedules` | ユーザーが見られるスケジュール。 `allowScheduledJobs` があればすべて、なければ自分が計画した実行です。 | `allowPlannedJobs` または `allowScheduledJobs` |
+| `get_schedule` | 1 つのスケジュールを、その追加変数（シークレットらしきものはマスク）と最後の実行の出力とともに返します。 | `allowPlannedJobs` または `allowScheduledJobs` |
+| `delete_schedule` | ユーザーが見られる計画済みの実行を取り消すか、スケジュールを削除します。 | `allowPlannedJobs` または `allowScheduledJobs` |
+| `list_stored_jobs` | ユーザーが見られる [保存済みジョブ](../jobs/stored-jobs.html) 。値は含みません。 | `allowStoredJobs` |
+| `get_stored_job` | 1 つの保存済みジョブをその値とともに返します。 `id` 、またはユーザー自身のものの中から `form` と `name` で指定します。 | `allowStoredJobs` |
+| `store_job` | フォームの **データを保存** と同じく、フォームの値を名前を付けて保存します。 | `allowStoredJobs` |
+| `delete_stored_job` | ユーザーが見られる保存済みジョブを削除します。 | `allowStoredJobs` |
+
+`launch_job` 、 `relaunch_job` 、 `plan_job` は、 `verbose: true` を指定するとジョブを詳細モードで実行します。これにはロールのオプション
+`allowVerboseMode` が必要です。 [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) を指定すると、起動、計画、
+変更を行うツール（ `launch_job` 、 `relaunch_job` 、 `plan_job` 、 `create_schedule` 、 `delete_schedule` 、 `store_job` 、 `delete_stored_job` ）は
+提供されません。
+
+任意の式、クエリ、プレイブック、extravars を実行するツールはありません。式と
+クエリは、常にフォームが定義するとおりにだけ実行されます。
+
+[チャットアシスタント](../chat) もこれらのツールを使います。ただし `launch_job` の代わりに **起動** ボタンを使います。
+
+---
+
+## フォームを入力する
+
+フォーム名とここまでに得た値を指定して `resolve_field` を呼び出し、回答が得られるたびにもう一度呼び出します。フィールドを
+依存関係の順に処理し、それぞれについて次のことを報告します。
+
+- `status` : `resolved` 、 `waiting` （ `waitingFor` 付き）、 `hidden` 、または `error` （フィールドは既定値に戻ります）
+- `value` 、 `default` 、そして選択式のフィールドでは `options` （最大 `maxOptions` 個、既定は 200）
+- `needsInput` : 値のない必須フィールド、またはまだ `__auto__` のままの選択肢
+- `validationErrors` : 値が違反しているルール。ブラウザーのメッセージ付きで `[{type, description}]` として返します
+
+フォーム全体については、 `missing` と `invalid` にまだ修正が必要なものが列挙されます。 `complete` が true になるまで、 `launch_job` は起動を拒否します。
+
+検証はブラウザー自身のコードで、 [起動時の検証](../launch-validation) と共有されています。非表示のフィールドは
+検証されず、空の任意フィールドは有効です。
+
+---
+
+## スケジュールと計画済みの実行
+
+`plan_job` は `launch_job` と同じ `form` 、 `values` 、 `expectedPayloadHash` に加えて、実行の `name` と `run_at` を受け取ります。 `run_at` は
+オフセットまたは `Z` 付きの ISO 8601 の時刻（ `2026-10-15T22:00:00+02:00` ）です。タイムゾーンのない時刻は拒否されます。値はこの時点で解決・
+検証され、ブラウザーでの [計画済みの実行](../jobs/schedules.html#planned-runs) と同じく、実行時にもう一度チェックされます。
+応答では、実行時刻を UTC とアプリの時計の両方で示します。
+
+`create_schedule` は `form` 、 `name` 、 `cron` （ `0 22 * * 1-5` のような 5 つのフィールド）または `run_at` のどちらか、そしてジョブが受け取る
+`extraVars` を受け取ります。このようなスケジュールは、フォームの検証なしで `Schedule Service` として実行されます。フォームをユーザーとして 1 回実行するには、
+`plan_job` を使ってください。スケジュール名は一意です。
+
+---
+
+## 保存済みジョブ
+
+保存済みジョブは、フォームの値を名前を付けて保存したものです。ツールはブラウザーと同じ保存済みジョブを扱います。
+
+`list_stored_jobs` は、ユーザー自身の保存済みジョブを、 `showSettings` を持つユーザーにはすべての人の保存済みジョブを、名前、説明、
+フォーム、作成日時、有効期限とともに一覧表示します。 `usable` と表示されたもの（ユーザー自身のもので、起動できるフォームのもの）は、
+`storedJob` （ `{ "id": 7 }` 、またはそのフォームのユーザー自身のものの中から `{ "name": "..." }` ）として `resolve_field` 、 `launch_job` 、 `plan_job` に渡せます。
+その値が出発点になり、 `values` がその上に重ねられます。パスワードフィールドは保存されないため、 `values` で指定してください。
+保存済みジョブからの `launch_job` と `plan_job` には、 `resolve_field` がそれに対して返した `expectedPayloadHash` が必要です。また、
+`resolve_field` は `storedJob` と `subform` を一緒に指定すると拒否します。
+
+`store_job` は `form` 、そのフォームのユーザーの保存済みジョブの中で一意な `name` 、 `values` 、そして省略可能な
+`description` と `expires_at` （オフセットまたは `Z` 付きの ISO 8601）を受け取ります。応答では、どのパスワードフィールドが除外されたかを示します。
+
+---
+
+## 値を渡す
+
+`field` を渡すと、そのフィールドとそれが依存するものだけを解決します。リストの行やウィザードのステップには、 `subform` （と、
+省略可能な親フォームの値 `parent` ）を渡します。
+
+値はブラウザーが保持しているとおりに送ります。選択式のフィールドは、部分的なレコードや `valueColumn` の値
+（ `"vol1"` ）も受け付け、 `multiple` の場合は配列も受け付けます。計算されるフィールドは、 `editable` でない限り送られた値を無視します。
+
+---
+
+## 正確なペイロードを承認する
+
+フォームが完成すると、 `resolve_field` は `launch_job` が送信する内容も返します。
+
+- `modeledExtravars` : `model` 、 `valueColumn` 、 `output` を適用した後の extravars。
+  パスワードフィールドはマスクされます
+- `credentials` : ジョブが使う AnsibleForms の認証情報（シークレットではなく名前）
+- `payloadHash` : フォーム名、実際の extravars、認証情報の SHA-256 ハッシュ
+
+`modeledExtravars` をオペレーターに示し、承認された `payloadHash` を
+`expectedPayloadHash` として `launch_job` に渡します。起動ではフォームをもう一度解決し、
+ペイロードが異なる場合、たとえばクエリの答えが変わった場合などは拒否します。
+`ansibleforms_user` 、 `__jobid__` 、 `__verbose__` は起動時に追加されるもので、ハッシュには含まれません。
+
+`launch_job` がチェックするのはペイロードだけです。ペイロードが変わらないフォームの編集では、起動は拒否されません。
+`resolve_field` のすべての応答には、フォーム定義の SHA-256 ハッシュである `formFingerprint` も含まれています。フォームが少しでも
+編集されたら起動を拒否したい場合は、チャットアシスタントの **起動** ボタンと同じように、 `launch_job` を呼び出す前に自分で比較してください。
+
+---
+
+## 変更を加えて再起動する
+
+`relaunch_job` はジョブの `id` と `values` を受け取ります。 `values` には変更するフィールドだけを生の値で指定します。
+`values` はジョブが最初に起動されたときの値の上に重ねられ、その結果は `launch_job` とまったく同じように、
+リストの行も含めて解決・検証され、あなたによる新しいジョブとして起動されます（ `ansibleforms_user` は元の送信者ではなくあなたです）。
+元のジョブのファイルのアップロードは再利用されます。
+
+`values` がない場合は **実行したとおりの** 再起動です。保存された extravars がサーバーで
+再生され、パスワードも含まれます（プレビューではマスクされます）。ただし、フォームが起動時の検証の
+`enforce` の対象である場合、再起動は変更を加えた再起動と同じチェックを通ります。
+
+**パスワードはフィールドの値と一緒に保存されることはありません。** そのため、チェックを通る再起動は、
+フォームの最上位またはリストの行にパスワードフィールドが表示される場合に拒否されます
+（ `unsupported` 、 `passwordFields` 付き）。依存関係によって非表示になっているパスワードフィールドは、
+再起動を妨げません。 [起動時の検証](../launch-validation) を参照してください。
+
+まず `preview: true` で呼び出してください。起動せずに `modeledExtravars` （パスワードはマスク）、
+`credentials` 、 `payloadHash` を返します。ユーザーにそれを確認してから、
+`expectedPayloadHash` を指定してもう一度呼び出します。ブラウザーでの再起動と同じ権限が
+必要です。フォームが再起動を許可しており、ロールに `allowJobRelaunch` オプションがあることです。
+保存されたフォームデータのないジョブ（再起動の機能ができる前に起動されたもの）とウィザードフォームは、変更を加えて
+再起動できません。
+
+REST API でも、本文 `{ "values": { ... } }` を付けた `POST /api/v2/job/{id}/relaunch` で同じことができます。
+本文がない場合は、ジョブを実行したとおりに再生します。
+
+---
+
+## エラー
+
+拒否された呼び出しはツールのエラーになり、その構造化コンテンツに `code` と詳細が含まれます。
+
+| コード | 発生する場合 |
+|---|---|
+| `form_incomplete` | 完成していないフォームに対する `launch_job` または `relaunch_job` 。 `missing` 、 `invalid` 、 `waiting` 、 `validationErrors` 、 `rowErrors` 付き |
+| `payload_mismatch` | ペイロードが `expectedPayloadHash` と異なる。両方のハッシュ付き |
+| `access_denied` | ユーザーのロールにフォーム、ジョブ、スケジュール、保存済みジョブ、または詳細モードの権限がない。あるいはサーバーが読み取り専用 |
+| `not_found` | そのフォーム、サブフォーム、ジョブが存在しない |
+| `unsupported` | ウィザードフォーム、単独のサブフォーム、ファイルフィールド、または表示されるパスワードフィールドが必要になる `relaunch_job` |
+| `no_form_data` | スケジュールが起動したジョブなど、フォームの値を保存していないジョブに対する変更付きの `relaunch_job` 。代わりに変更なしで再起動してください |
+| `invalid_request` | サーバーが形式不正として拒否するリクエスト |
+| `internal_error` | その他すべて |
diff --git a/i18n/ja/_introduction/concepts.md b/i18n/ja/_introduction/concepts.md
new file mode 100644
index 0000000..ba72d65
--- /dev/null
+++ b/i18n/ja/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 概念
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# 概念
+{: .no_toc }
+
+このドキュメント全体で使う用語と、それぞれの説明ページへのリンク
+{: .fs-6 .fw-300 }
+
+---
+
+## 用語集
+
+このドキュメント全体で使う用語です。
+
+| 用語 | 意味 |
+|---|---|
+| **[フォーム](forms/)** | 入力を集め、プレイブック、テンプレート、またはワークフローを実行する YAML の定義 |
+| **[フォームフィールド](formfields/)** | `text` 、 `enum` 、 `checkbox` など、フォームの 1 つの入力。その値は extravar になります |
+| **[カテゴリ](config/categories.html)** | 「フォーム」ページに表示されるフォームのツリーのグループ。 `config.yaml` で定義します |
+| **[ロール](config/roles.html)** | ユーザーとグループの集まり。フォームには、そのフォームを表示・実行できるロールを列挙します。全員を対象にするには `default` です |
+| **[式](expressions/)** | フィールドの値を計算する JavaScript。ブラウザー（ `runLocal: true` ）またはサーバーで実行されます |
+| **[Extravars](formfields/)** | フィールドの値から組み立てられ、プレイブックやテンプレートに送られる変数 |
+| **[認証情報](expressions/credentials.html)** | `ENCRYPTION_SECRET` で暗号化して保存されたログイン情報。ユーザーとパスワード（およびホスト、ポート、データベース）、または 7.3.0 以降は LDAP ディレクトリ、SSO プロバイダー、ランナー、HashiCorp Vault のアドレスとシークレット |
+| **[シークレットストア](secret-stores/)** | 認証情報のユーザーとパスワードを提供する、HashiCorp Vault または CyberArk への接続 |
+| **[ジョブ](gui/forms-and-jobs.html)** | フォームの 1 回の実行。ステータス、extravars、出力を持ち、ジョブ履歴に残ります |
+| **[ランナー](runners.html)** | ジョブの実行場所。 **接続 > ランナー** で追加します。プレイブックには `rte` 、テンプレートやジョブには `awx` （AWX、または派生の `aap` や `ascender` ）、 `semaphore` 、 `rundeck` 、 `jenkins` を使います。フォームは `runner:` で 1 つを選ぶか、既定の `rte` （プレイブック）または `awx` （テンプレート）のランナーで実行されます |
+| **[RTE](rte/)** | ランタイム環境。 `AF_ROLE=rte` で起動した AnsibleForms サーバーで、python と ansible とともに専用のコンテナーで動き、種類 `rte` のランナーのプレイブックを実行します |
+| **[承認ポイント](forms/approval.html)** | 承認ロールを持つユーザーが承認または拒否するまで、ジョブを一時停止する箇所 |
+| **[ワークフロー](workflows/)** | 成功時、失敗時、または常にでつながれたプレイブック、承認、その他のワークフローのグラフ。AWX の構文で記述します |
+| **[マルチステップフォーム](forms/multistep.html)** | 7 以降は非推奨。複数のプレイブックやテンプレートを順に実行するフォームで、ワークフローが置き換えます |
+| **[通知チャネル](notification-channels.html)** | 通知や承認依頼の送り先となるメールサーバー、Slack や Teams の Webhook、Telegram のチャット、または Webhook |
+| **[デザイナー](designer/)** | フォーム、プレイブック、インベントリ、ワークフローを編集するブラウザー上のエディター。一度に 1 人が使います |
+| **[サブフォーム](forms/subform.html)** | `list` フィールドの行や `yaml` フィールドのオブジェクトを記述する、再利用可能なフィールドの集まり |
+| **[config.yaml](config/)** | カテゴリ、ロール、定数を記述するファイル。フォームはそれぞれ専用のファイルに置きます |
+| **[設定シード](seed/)** | ランナーや認証情報などの管理オブジェクトを宣言する YAML ファイル（ `CONFIG_SEED_PATH` ） |
+| **[永続フォルダー](customization/paths.html)** | 再起動やアップグレードをまたいで AnsibleForms が保持しなければならないファイルを置くフォルダー |
diff --git a/i18n/ja/_introduction/gui/administration.md b/i18n/ja/_introduction/gui/administration.md
new file mode 100644
index 0000000..fd15ffb
--- /dev/null
+++ b/i18n/ja/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: 管理
+parent: インターフェースの紹介
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# 管理
+{: .no_toc }
+
+「設定」メニュー。システム、外観、アクセス、接続、ログ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 「設定」メニュー
+
+ヘッダーの **設定** で管理ページが開きます。管理ページは左メニューで **システム** 、 **外観** 、
+**アクセス** 、 **接続** 、 **ログ** にまとめられています。各項目は、そのページに必要なロールのオプションを持つユーザーにだけ表示されます。
+**バックアップ** には `allowBackupOps` 、 **サーバーログ** には `showLogs` 、それ以外のすべてのページには `showSettings` が必要です。
+7.3.0 以降は、3 つのオプションでそれぞれ一部のページだけを開けます。
+
+| ロールのオプション | 開くもの |
+|---|---|
+| `showAppearanceSettings` | **外観** のページ |
+| `showConnectionsSettings` | **Syslog** を除く **接続** のページ。リポジトリ、シークレットストア、保護された認証情報の変更は引き続き管理者だけが行えます |
+| `showAuditLog` | **監査ログ** |
+
+ロールのオプションについては [ロール](../config/roles.html#role-options) を参照してください。
+
+---
+
+## 一覧とレコードのページ
+
+7.3.0 以降、設定の一覧とレコードのページは共通のレイアウトになり、操作部品はタイトルの下の専用の行に並びます。
+
+| 部分 | 動作 |
+|---|---|
+| 検索ボックス | すべての設定ページとレコードページで、その行の先頭にあります。語を入力するとすべてのタブが一度に絞り込まれ、一致したフィールド、行、ラインがそのタブの名前の下に表示されます |
+| ページサイズ | ページサイズを選ぶまでは、表は画面に収まるだけの行を表示します。選べるのは 10、20、50、100 です |
+| 列 | 名前のある列はすべて並べ替えでき、空のセルには `–` が表示されます |
+| チェックボックス | チェックした行に対して何かできる場合にだけ行に表示され、行のメニュー（⋮）にも同じ操作があります |
+| 行のメニュー | **編集** や **削除** のような短いラベルです。 **有効** 列を持つ一覧ではその列が先頭にあり、各行のメニューには状態に応じて **有効にする** または **無効にする** があります |
+
+**有効** 列を持つ一覧は、SSO プロバイダー、LDAP ディレクトリ、ランナー、スケジュール、通知
+チャネル、Syslog サーバー、お知らせ、ラベル、免責事項のバージョンです。
+
+---
+
+## システム
+
+インスタンス自体の設定、状態、バックアップです。
+
+| ページ | 用途 |
+|---|---|
+| **全般** | 環境変数。「設定」から「ロギング」までのタブに分かれています。 [環境変数](../customization/) を参照してください。 |
+| **ステータス** | インスタンスとそれが依存するシステムの状態。「チェック」と「情報」のタブがあります。 [監視](../production/monitoring.html) を参照してください。 |
+| **バックアップ** | データベース、config.yaml、フォームのバックアップの作成、復元、削除。 [バックアップ](../production/backups.html) を参照してください。 |
+
+![設定 > 全般の「設定」タブ](../assets/screenshots/settings.jpg)
+
+### バックアップ
+
+夜間と手動のバックアップの一覧です。 **バックアップを追加** で今すぐバックアップを取り、行のメニューには **バックアップを表示** 、 **復元** 、 **削除** があります。
+
+![設定 > バックアップ](../assets/screenshots/backups.jpg)
+
+### 復元
+
+**復元** はバックアップの内容を表示してから復元します。 **復元する前に新しいバックアップを作成する (推奨)** は既定でチェックされています。
+
+![バックアップの復元](../assets/screenshots/restore.jpg)
+
+---
+
+## 外観
+
+すべての人に対するインスタンスの見た目と、表示するメッセージです。
+
+| ページ | 用途 |
+|---|---|
+| **既定値** | 何も選んでいないユーザーのテーマ、言語、フォームの表示、タイムゾーン、日付の形式。 [既定値](../appearance/defaults.html) を参照してください。 |
+| **名前** | ブラウザーのタブとサインインページに表示される名前。 [名前](../appearance/name.html) を参照してください。 |
+| **ロゴ** | ヘッダーに表示する独自のロゴ。 [ロゴ](../appearance/logo.html) を参照してください。 |
+| **アイコン** | ブラウザーのタブに表示する独自のアイコン。 [アイコン](../appearance/icon.html) を参照してください。 |
+| **リンク** | デザイナーへのリンクと、ヘッダーに置く独自のリンクやメニュー。 [リンク](../appearance/links.html) を参照してください。 |
+| **ラベル** | ロゴの横に表示する PRODUCTION や EU などのラベル。 [ラベル](../appearance/labels.html) を参照してください。 |
+| **お知らせ** | ヘッダーの下に、開始から終了まで表示するメッセージ。 [お知らせ](../announcements.html) を参照してください。 |
+
+---
+
+## アクセス
+
+誰がサインインでき、サインインした後に何ができるかです。
+
+| ページ | 用途 |
+|---|---|
+| **免責事項** | すべてのユーザーが一度同意する条項と、誰がどのバージョンに同意したか。 [免責事項](../disclaimer.html) を参照してください。 |
+| **ユーザー** | ローカルユーザー、LDAP とシングルサインオンのユーザー。 [ユーザーとグループ](../users-and-groups.html) を参照してください。 |
+| **グループ** | ローカルグループ、LDAP とシングルサインオンのグループ。 [ユーザーとグループ](../users-and-groups/local-group.html) を参照してください。 |
+| **ロール** | config.yaml のロール。誰が持っていて、何を許可するか。 [ロール](../config/roles.html) を参照してください。 |
+| **LDAP** | LDAP ディレクトリまたは Active Directory でのサインイン。 [LDAP](../authentication/ldap.html) を参照してください。 |
+| **SSO** | Entra ID または OpenID Connect プロバイダーでのシングルサインオン。 [認証](../authentication/) を参照してください。 |
+
+![アクセス > LDAP、メインのディレクトリ](../assets/screenshots/ldap.jpg)
+
+---
+
+## 接続
+
+AnsibleForms が接続するシステムと、それらにログインするためのものです。
+
+| ページ | 用途 |
+|---|---|
+| **リポジトリ** | フォームとプレイブックの取得元となる Git リポジトリ。 [Git リポジトリ](../repositories/) を参照してください。 |
+| **認証情報** | フォーム、プレイブック、接続が使うアカウントとシークレット。 [認証情報](../credentials.html) を参照してください。 |
+| **シークレットストア** | 認証情報を読み取れる HashiCorp Vault と CyberArk。 [シークレットストア](../secret-stores/) を参照してください。 |
+| **ランナー** | ジョブの実行場所。プレイブック用の RTE コンテナーと、テンプレート用の AWX などです。 [ランナー](../runners.html) を参照してください。 |
+| **SSH** | アプリが Git に接続するときに使う鍵ペアと、既知のホスト。 [SSH](../repositories/authentication.html#ssh-with-the-generated-key) を参照してください。 |
+| **通知** | SMTP サーバー、Slack、Microsoft Teams、Telegram、Webhook。 [通知チャネル](../notification-channels.html) を参照してください。 |
+| **チャットアシスタント** | チャットアシスタントの AI プロバイダー。 [チャットアシスタント](../chat/) を参照してください。 |
+| **MCP** | AI エージェント用の MCP サーバー。 [MCP](../mcp/) を参照してください。 |
+| **Syslog** | サーバーログ、監査ログ、またはその両方を受け取る Syslog サーバー。 [Syslog](../production/logs.html#syslog) を参照してください。 |
+
+![接続 > 認証情報、認証情報の「接続」タブ](../assets/screenshots/credentials.jpg)
+
+---
+
+## ログ
+
+インスタンスで何が起きたかです。
+
+| ページ | 用途 |
+|---|---|
+| **監査ログ** | 誰が何を変更し、それが許可されたかどうか。ユーザー、アクション、結果で絞り込めます。 [監査証跡](../production/logs.html#audit-trail) を参照してください。 |
+| **サーバーログ** | トラブルシューティング用のサーバー自身のログ。 [ログ](../production/logs.html) を参照してください。 |
+
+### サーバーログ
+
+ログの最後の数行で、最新の行がいちばん下にあり、書き込まれるにつれて追従します。検索ボックスで絞り込め（正規
+表現）、 **クリア** はログではなく表示を空にし、 **ダウンロード** はログ全体を保存します。
+
+![ログ > サーバーログ](../assets/screenshots/logs.jpg)
+
+---
+
+## API ドキュメント
+
+ヘルプメニュー（ヘッダーの疑問符）の **API ドキュメント** は、 `/api/v2/docs` にある REST API の Swagger UI へのリンクです。
+[API](../api/) を参照してください。
+
+![Swagger インターフェース](../assets/screenshots/swagger.jpg)
diff --git a/i18n/ja/_introduction/gui/designer-and-git.md b/i18n/ja/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..814b066
--- /dev/null
+++ b/i18n/ja/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: デザイナーと Git
+parent: インターフェースの紹介
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# デザイナーと Git
+{: .no_toc }
+
+フォームの編集と Git での管理
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 組み込みのデザイナー
+
+フォーム、カテゴリ、定数、vars ファイル、プレイブック、インベントリ、ワークフローを、YAML で、フィールド（ビジュアル）で、
+そしてプレビューで編集します。各セクションについては [デザイナー](../designer/) のページで説明しています。
+
+![組み込みのデザイナー](../assets/screenshots/designer.jpg)
+
+---
+
+## Git リポジトリ
+
+Git リポジトリと連携し、フォームとプレイブックをバージョン管理します。
+
+![Git リポジトリ](../assets/screenshots/git.jpg)
+
+---
+
+## Git リポジトリのエディター
+
+Git リポジトリとの連携の設定を編集します。
+
+![Git リポジトリのエディター](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/ja/_introduction/gui/forms-and-jobs.md b/i18n/ja/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..916aec0
--- /dev/null
+++ b/i18n/ja/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: フォームとジョブ
+parent: インターフェースの紹介
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# フォームとジョブ
+{: .no_toc }
+
+サインイン、ダッシュボード、フォームの入力、そのジョブの追跡
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ログイン
+
+ユーザー認証のページです。ローカル、LDAP、Entra ID、OIDC の認証に対応しています。
+
+![ログイン](../assets/screenshots/login.jpg)
+
+---
+
+## ダッシュボード
+
+メインのダッシュボードには、利用できるすべてのフォームがカテゴリ別に表示されます。
+
+![ダッシュボード](../assets/screenshots/dashboard.jpg)
+
+---
+
+## フォーム
+
+外部のデータソースと動的なフィールドを持つフォームの例です。
+
+![フォームの例](../assets/screenshots/form.jpg)
+
+---
+
+## フォームの JSON プレビュー
+
+ジョブを実行する前に、JSON のペイロードと Ansible に渡される追加変数をプレビューします。
+
+![フォームの JSON プレビュー](../assets/screenshots/form-json.jpg)
+
+---
+
+## 実行中のジョブ
+
+Ansible プレイブックをリアルタイムで実行し、出力をその場で表示します。
+
+![実行中のジョブ](../assets/screenshots/run.jpg)
+
+---
+
+## ジョブの出力
+
+実行した Ansible プレイブックの出力全体です。
+
+![ジョブの出力](../assets/screenshots/job-output.jpg)
+
+---
+
+## ジョブのログ
+
+すべてのジョブをステータスと時刻とともに表示します。左メニューでステータスごとに絞り込めます。
+
+![ジョブのログ](../assets/screenshots/job-log.jpg)
+
+---
+
+## マルチステップ
+
+マルチステップのジョブで、各ステップの出力がメインのジョブの下に表示されます。マルチステップフォームは 7 以降非推奨です。代わりに
+[ワークフロー](../workflows/) でプレイブック、テンプレート、承認をつなげます。
+
+![マルチステップフォーム](../assets/screenshots/multistep.jpg)
+
+---
+
+## スケジュール
+
+フォームを特定の時刻や間隔で実行するようにスケジュールします。 [cron の例](../faq.html#which-cron-expressions-can-i-use) では、よく使う
+式と、スケジュールがどのタイムゾーンで実行されるかを説明しています。
+
+![スケジュール](../assets/screenshots/schedules.jpg)
diff --git a/i18n/ja/_introduction/gui/index.md b/i18n/ja/_introduction/gui/index.md
new file mode 100644
index 0000000..66a269c
--- /dev/null
+++ b/i18n/ja/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: インターフェースの紹介
+nav_order: 3
+has_children: true
+has_toc: false
+description: グラフィカルユーザーインターフェースのスクリーンショットと紹介
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# インターフェースの紹介
+{: .no_toc }
+
+ダッシュボードから高度な管理機能まで、AnsibleForms の Web インターフェースを画面で紹介します。
+{: .fs-6 .fw-300 }
+
+---
+
+すべてのユーザーと管理者向けです。Web インターフェースの画面を、そこで行う作業ごとにまとめています。
+
+---
+
+## このセクションの内容
+
+画面のグループごとに個別のページがあります。
+
+| ページ | 内容 |
+|---|---|
+| [フォームとジョブ](forms-and-jobs.html) | サインイン、ダッシュボード、フォームの入力、そのジョブの追跡 |
+| [デザイナーと Git](designer-and-git.html) | フォームの編集と Git での管理 |
+| [管理](administration.html) | 「設定」メニュー。システム、外観、アクセス、接続、ログ |
+| [個人設定](personal-settings.html) | プロフィールとダークテーマ |
diff --git a/i18n/ja/_introduction/gui/personal-settings.md b/i18n/ja/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..d761a32
--- /dev/null
+++ b/i18n/ja/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: 個人設定
+parent: インターフェースの紹介
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# 個人設定
+{: .no_toc }
+
+プロフィールとダークテーマ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ユーザープロフィール
+
+アカウント、設定、パスワード、権限、API トークンです。
+
+[プロフィール](../profile) を参照してください。
+
+![ユーザープロフィール](../assets/screenshots/profile.jpg)
+
+---
+
+## ダークモード
+
+AnsibleForms は、目の負担を減らすダークモードに対応しています。
+
+![ダークモード](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/ja/_introduction/how-it-works.md b/i18n/ja/_introduction/how-it-works.md
new file mode 100644
index 0000000..a43817d
--- /dev/null
+++ b/i18n/ja/_introduction/how-it-works.md
@@ -0,0 +1,209 @@
+---
+layout: default
+title: 仕組み
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# 仕組み
+{: .no_toc }
+
+インストールの構成要素、起動時に起きること、データの保存場所
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## アーキテクチャ
+
+AnsibleForms は、MySQL データベースを使って Web アプリケーションと REST API を提供する Node.js サーバーです。フォームは
+YAML ファイルから読み取り、自分では何も実行しません。各ジョブを [ランナー](runners.html) に渡します。プレイブックは RTE
+（ランタイム環境）コンテナーのいずれかに渡されて `ansible-playbook` が実行され、テンプレートやジョブは AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins に渡されます。
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">AnsibleForms のアーキテクチャ</title>
+<desc id="afd-desc">ブラウザーと任意の MCP クライアントが AnsibleForms サーバーと通信します。サーバーはデータを MySQL と永続フォルダーに保存し、データソース、シークレットストア、Git リポジトリ、ログインプロバイダー、通知チャネル、Syslog サーバー、任意のモデルプロバイダーに接続します。そのランナーは、各プレイブックを 1 つ以上ある RTE コンテナーのいずれかにそれぞれ 1 本の WebSocket で渡し、RTE は ansible-playbook を実行して出力をサーバーに返します。各テンプレートやジョブは AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins に渡します。</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="99" text-anchor="middle">ブラウザー</text>
+<text class="afd-s" x="105" y="118" text-anchor="middle">フォーム、デザイナー、ジョブ、チャット</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">MCP クライアント</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">任意</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">AnsibleForms サーバー</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Web アプリと REST API</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">フォームエンジン、式</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">ワークフロー、スケジュール</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">MCP サーバー（任意）</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">ランナー</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">各ジョブをそのランナーに渡す</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">データソース</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">データベース、REST API、ファイル</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">シークレットストア</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Git リポジトリ</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">フォーム、プレイブック、設定</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">ログインプロバイダー</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">通知チャネル</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">メール、Slack、Teams、Webhook</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Syslog サーバー</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">ログ、監査証跡</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">モデルプロバイダー</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">任意、チャットアシスタント</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">永続フォルダー</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">設定、フォーム、プレイブック</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="445" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="463" text-anchor="middle">ジョブ、ユーザー、認証情報</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">RTE コンテナー</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">ansible-playbook を実行</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">プレイブック、</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">テンプレート、ジョブ</text>
+</svg>
+</div>
+
+図の各コンポーネントには、それぞれ次の役割があります。
+
+| コンポーネント | 役割 |
+|---|---|
+| **ブラウザー** | Vue の Web アプリケーション。フォーム、 [デザイナー](gui/designer-and-git.html) 、ジョブ履歴、設定 |
+| **AnsibleForms サーバー** | フォームを評価し、ジョブを記録し、ワークフローとスケジュールを実行し、各ジョブをそのランナーに渡して追跡し、 [REST API](api/) を提供します |
+| **ランナー** | ジョブの実行場所で、 **接続 > ランナー** で追加します。フォームは `runner: <name>` で 1 つを指定するか、その種類の既定のランナーを使います（ [ランナー](runners.html) を参照） |
+| **RTE コンテナー** | 1 つ以上のランタイム環境コンテナーで、 `AF_ROLE=rte` で起動した同じサーバーです。それぞれが [ansible フォーム](forms/ansible.html) のために、イメージの python ライブラリとコレクションを使って `ansible-playbook` を実行し、出力と最終的なステータスを 1 本の WebSocket でサーバーに返します。データベースの認証情報は持ちません（ [RTE の動作](rte/#how-the-rte-runs) を参照） |
+| **AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins** | テンプレートとジョブ用のランナーです。 [AWX フォーム](forms/awx.html) はジョブテンプレートまたはワークフローテンプレートを起動し、 [Semaphore](forms/semaphore.html) 、 [Rundeck](forms/rundeck.html) 、 [Jenkins](forms/jenkins.html) のフォームはそれぞれのジョブを起動して、サーバーがその出力を追跡します |
+| **MySQL / MariaDB** | ジョブとその出力、ユーザー、認証情報、接続を保持します。読み書きするのはサーバーだけです |
+| **永続フォルダー** | `config.yaml` 、フォームファイル、プレイブック、ログ、バックアップを保持します |
+| **データソース** | フィールドを埋めます。 [データベースのクエリ](formfields/enum.html) 、 [REST API](expressions/rest-apis.html) 、ファイル、 [その他の関数](expressions/remote.html) です |
+| **シークレットストア** | 使用時に認証情報のユーザーとパスワードを提供します。 [シークレットストア](secret-stores/) を参照してください |
+| **Git リポジトリ** | フォーム、プレイブック、 `config.yaml` をバージョン管理します |
+| **ログインプロバイダー** | ローカルユーザーに加えて、 [LDAP、Entra ID、OIDC](authentication/) でユーザーをサインインさせます |
+| **通知チャネル** | [通知](forms/notifications.html) と承認依頼を運びます。 [メール、Slack、Microsoft Teams、Telegram、Webhook](notification-channels.html) です |
+| **Syslog サーバー** | ログと監査証跡を書き込まれるそばから受け取ります。 [Syslog](production/logs.html#syslog) を参照してください |
+| **MCP クライアント、チャット** | 任意で、どちらも既定ではオフです。 [MCP サーバー](mcp/) と [チャットアシスタント](chat/) で、チャットアシスタントにはモデルプロバイダーが必要です |
+
+既定では、1 つのコンテナーがサーバー、Web アプリ、バックグラウンド処理をまとめて実行し、その隣で 1 つの RTE が動きます。ロードバランサーの背後に複数のアプリノードを置く構成、
+バックグラウンド処理を実行するワーカー、RTE の追加については、 [スケーリング](production/scaling.html) を参照してください。
+
+### 使用している技術
+
+サーバーと Web インターフェースは、次のコンポーネントで構築されています。
+
+| 部分 | 技術 |
+|---|---|
+| **サーバー** | Node.js と Express |
+| **データベース** | MySQL または MariaDB |
+| **Web インターフェース** | Vue 3、Bootstrap 5、Font Awesome |
+
+---
+
+## フォームを起動すると何が起きるか
+
+起動は、ブラウザーからでも [REST API](api/jobs.html) からでも、同じステップを通ります。
+
+1. **読み込み** : サーバーはユーザーの [ロール](config/roles.html) が許可するフォームだけを送り、サーバー側の式を評価します
+2. **送信** : ブラウザーはフィールドの値を extravars に変換し、 `POST /api/v2/job` に送ります
+3. **チェック** : サーバーはユーザーのロールでフォームを読み込み直し、 [起動時の検証](launch-validation/) が有効なら値をチェックします
+4. **記録** : ジョブがステータス `running` で保存され、その ID が `__jobid__` として extravars に追加されます
+5. **承認** : [`approval`](forms/approval.html) ポイントを持つフォームは、承認者がジョブを受け入れるまで待ちます
+6. **認証情報** : プレイブックの場合、アプリ（RTE ではありません）がフォームの認証情報をデータベースまたは [シークレットストア](secret-stores/) から読み取ります
+7. **実行** : ジョブはそのランナー、つまりフォームが `runner:` で指定したもの、またはその種類の既定のランナーに渡されます。プレイブックの場合、アプリは
+   その RTE 用に封をした認証情報とともに、RTE の WebSocket 経由でジョブを送り、RTE が `ansible-playbook` を実行します（ [RTE の動作](rte/#how-the-rte-runs) を参照）。
+   テンプレートやジョブは AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins が実行します。 [ワークフロー](workflows/) はそのノードを、それぞれ
+   専用のランナー上の個別のジョブとして実行します
+8. **追跡** : サーバーは届いた出力をデータベースに保存します。プレイブックの場合は RTE がソケット経由で送り、それ以外は
+   ほかのランナーから読み取ります。フォームのページは 2 秒ごとにジョブを読み直し、「ジョブ」ページはサーバーが
+   変更を通知するたびにライブで追従します
+9. **終了** : ジョブは最終的なステータスになり、フォームが求めていれば、その [`notifications`](forms/notifications.html) がメールと
+   [通知チャネル](notification-channels.html) に送られます
+
+---
+
+## 保存場所
+
+AnsibleForms は状態を 2 か所に保存します。MySQL データベースと永続フォルダーです。両方をバックアップしてください。
+
+### データベース
+{: .no_toc }
+
+データベース `AnsibleForms` は初回起動時に作成され（ `ALLOW_SCHEMA_CREATION` が `0` の場合を除く）、次のものを保持します。
+
+* ジョブ、その extravars と出力、スケジュール、保存済みジョブ
+* ローカルユーザー、グループ、API トークン
+* `ENCRYPTION_SECRET` で暗号化された認証情報と、シークレットストアの接続
+* ランナー、通知チャネル（メールを含む）、Syslog サーバー、そして LDAP、SSO、リポジトリ、チャットアシスタントの設定
+* 監査ログ
+
+### 永続フォルダー
+{: .no_toc }
+
+イメージでは `/app/dist/persistent` 、ソースからの場合は `server/persistent` です。各パスには専用の [変数](customization/paths.html) があります。
+
+| 既定のパス | 変数 | 内容 |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | カテゴリ、ロール、定数 |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | フォームファイル（ `.yaml` または `.yml` ）。必要ならサブフォルダーに分けられます |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | `ansible` フォームのプレイブックと、その作業ディレクトリ |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Git リポジトリのクローン |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | デザイナーが保存の前に作成するコピー |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | データベースのバックアップ |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | `file` フィールドでアップロードされたファイル |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` と `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | `HTTPS` が `1` の場合の証明書と鍵 |
+| `.env` | | 設定ページから保存された環境変数（ `ALLOW_ENV_EDIT` が `0` の場合を除く） |
+
+生成された SSH キーは [`HOME_PATH`](customization/paths.html#env_HOME_PATH) にあり、既定では永続フォルダーの外です。
diff --git a/i18n/ja/_introduction/prerequisites.md b/i18n/ja/_introduction/prerequisites.md
new file mode 100644
index 0000000..11e373a
--- /dev/null
+++ b/i18n/ja/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: 前提条件
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# 前提条件
+{: .no_toc }
+
+AnsibleForms をインストールする前に必要なもの
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 実行環境
+
+AnsibleForms は、コンテナーとして、サーバー自体の systemd サービスとして、または自分でビルドする場合は Node.js アプリケーションとして動作します。
+
+| インストール方法 | 必要なもの |
+|---|---|
+| [インストーラー](installation/installer.html) | amd64 または arm64 の Linux、 `curl` または `wget` と `sha256sum` 、そしてインストール先のエンジンに必要なもの（下記） |
+| [ネイティブ](installation/native.html) | root、systemd、対応する Linux（Ubuntu、Debian、RHEL とそのリビルド版、SUSE）。残りはインストーラーがインストールします |
+| [Docker](installation/docker.html) | Docker または Podman と、自前の MySQL サーバー |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose または podman-compose。MySQL もプロジェクトが起動します |
+| [Kubernetes](installation/kubernetes.html) | クラスター、Helm 3、StorageClass（または事前に作成した PersistentVolume） |
+| [ソースから](installation/from-source.html) | Node.js 26（最低でも 24）と npm、Git、そしてプレイブックを実行する RTE プロセス用の Ansible |
+
+アプリのイメージ `ghcr.io/ansibleforms/ansibleforms` には、Node.js とサーバーが呼び出すツール（git、ssh、mariadb クライアント、
+ytt）が含まれていますが、Python と Ansible は含まれていません。プレイブックは RTE（ランタイム環境）で実行されます。これは
+`ghcr.io/ansibleforms/ansibleforms-rte-full` 、または `ansibleforms-rte-core` をベースに自分でビルドしたイメージから起動する 2 つ目のコンテナーです（ [スケーリング](rte/) を参照）。
+AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins のテンプレートを起動するだけのフォームには RTE は不要です。
+
+---
+
+## データベース
+
+AnsibleForms は、ジョブ、ユーザー、認証情報、接続を MySQL 8 以降または MariaDB に保存します。
+
+初回起動時に、 `AnsibleForms` スキーマを自分で作成します。root ではなく専用のデータベースユーザーを用意し、そのスキーマに対する権限だけを
+与えてください。
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+必要なのはこれだけです。この権限でスキーマを作成・更新し、バックアップを取り、ワーカーが複数ある場合は停止したワーカーのセッションを終了します。
+ユーザーがすべてのデータベースに権限を持っている場合は、 **ステータス** ページとログに警告が出ます。アプリノードとワーカーはこの
+ユーザーで接続します。ソケットモード（アウトバウンドまたはインバウンド、 [モード](rte/modes.html) を参照）の RTE はデータベースの認証情報を持ちません。接続するのは、
+7.3.0 以降非推奨のデータベースモードの RTE だけです。スキーマを自分で作成するには、 [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) を `0` に設定します。
+Docker Compose プロジェクトと Helm チャート（ `mysql:8.4` を使用）は、データベースを起動してくれます。
+
+---
+
+## サイジング
+
+測定に基づく要件はありません。負荷は主に、同時に実行されるジョブの数と、ジョブが書き出す出力の量で決まります。
+Helm チャートの既定のリソースは、小規模なチームにとって妥当な出発点です。
+
+| コンポーネント | 要求 | 上限 | ボリューム |
+|---|---|---|---|
+| AnsibleForms | 1 CPU、メモリ 1 GiB | 4 CPU、メモリ 4 GiB | 10 GiB |
+| MySQL | 0.5 CPU、メモリ 512 MiB | 2 CPU、メモリ 2 GiB | 10 GiB |
+
+アプリのコンテナーはプレイブックを実行しません。各プレイブックは、RTE 上でフォークを伴う `ansible-playbook` プロセスとして動きます。各 RTE の CPU と
+メモリは、同時に実行するプレイブック（最大 [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) 、既定は `10` ）に合わせて見積もり、さらに多く実行するには
+RTE を増やします。AWX、AAP、Ascender、その他のテンプレートランナーで実行されるジョブは、AnsibleForms にはほとんど負荷をかけません。
+
+ジョブの出力は、既定ではデータベースに無期限に保存されます。利用の多いインスタンスでは [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+を設定し、データベースが際限なく大きくならないようにしてください。
+
+---
+
+## ネットワーク
+
+アプリと各 RTE はそれぞれ専用のポートで待ち受け、フォームと設定が使うシステムへのアウトバウンド接続を開きます。
+
+### インバウンド
+{: .no_toc }
+
+サーバーはポート `8000` （ [`PORT`](customization/server.html#env_PORT) ）で、HTTP で、または
+[`HTTPS`](customization/server.html#env_HTTPS) を `1` に設定した場合は HTTPS で待ち受けます。Docker Compose プロジェクトはポート 443 で公開し、
+Helm チャートはサービスまたは Ingress で公開します。RTE も専用の `PORT` で待ち受けますが、呼び出すのはアプリだけなので、
+公開ネットワークからは切り離してください。アウトバウンドの RTE はインバウンドのポートをまったく必要としません。アプリのポートでアプリに接続します。
+
+### アウトバウンド
+{: .no_toc }
+
+AnsibleForms から、使用するシステムへの接続を開放します。
+
+| 接続先 | 用途 |
+|---|---|
+| MySQL / MariaDB | AnsibleForms のデータベース（ `DB_HOST` 、 `DB_PORT` 、既定は `3306` ） |
+| RTE | インバウンドの RTE に、そのランナーのアドレスで 1 本の WebSocket を使って接続します。またはデータベースモードの RTE を [`RTE_URL`](customization/server.html#env_RTE_URL) で呼び出し、その RTE が自分で MySQL に接続します。アウトバウンドの RTE は逆にアプリに接続します（ [モード](rte/modes.html) を参照） |
+| AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins | [ランナー](runners.html) 上のテンプレートとジョブを、その HTTP(S) API で起動・追跡します |
+| 管理対象ホスト | プレイブックが RTE から、たとえば SSH や WinRM で接続します |
+| LDAP、Entra ID、OIDC | ディレクトリやシングルサインオンのアカウントでのログイン |
+| Git サーバー | HTTPS または SSH でのリポジトリのクローンと pull |
+| REST API とデータベース | フォームの式とクエリのデータソース |
+| HashiCorp Vault、CyberArk | [シークレットストア](secret-stores/) からの認証情報の読み取り |
+| メールサーバー、Slack、Teams、Telegram、Webhook | [通知チャネル](notification-channels.html) によるジョブの通知と承認依頼 |
+| モデルプロバイダー | [チャットアシスタント](chat/) 。有効にした場合のみ |
+
+式の REST 関数が呼び出せるホストを制限するには、
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) と
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) を参照してください。
+
+---
+
+## ブラウザー
+
+Web アプリケーションは最新のブラウザー向けに作られています。Chrome または Edge 111、Firefox 114、Safari 16.4 以降です。
+それより古いブラウザーには対応していません。
+
+---
+
+## スケーリング
+
+既定では、1 つの AnsibleForms コンテナーが Web アプリとバックグラウンド処理をまとめて実行し、その隣で 1 つの RTE が動きます。
+
+より多くのユーザーに対応するには、ロードバランサーの背後で複数のアプリノード（ `AF_ROLE=app` ）を、ワーカー（ `AF_ROLE=worker` ）と並べて動かします。ワーカーは
+スケジュール、バックアップ、その他のバックグラウンド処理を実行します。同時に動くワーカーは 1 つだけで、2 つ目は引き継ぎに備えて待機します。これらは
+データベース、永続フォルダー、 `ACCESS_TOKEN_SECRET` 、 `ENCRYPTION_SECRET` を共有します。 [スケーリング](production/scaling.html) を参照してください。より多くのプレイブックを同時に実行するには、
+RTE を増やします。 [複数の RTE](rte/several.html) を参照してください。
diff --git a/i18n/ja/_introduction/what-is-ansibleforms.md b/i18n/ja/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..00c0ac4
--- /dev/null
+++ b/i18n/ja/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: AnsibleForms とは
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# AnsibleForms とは
+{: .no_toc }
+
+Ansible と AWX の前に置くセルフサービスのフォームと、それが必要になる場面
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## できること
+
+AnsibleForms は、プレイブック、ワークフロー、または AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins のテンプレートやジョブの前に
+Web フォームを置き、コマンドラインを使わずに自動化を実行できるようにします。
+
+フォームは入力を集めてチェックし、extravars の形に整えてジョブを起動します。フォームのデータは、データベース、
+REST API、ファイル、ほかのフィールドから取得でき、すべての起動はその出力とともにジョブ履歴に記録されます。
+
+---
+
+## 代表的な使い方
+
+チームは AnsibleForms を使い、定型的な自動化を、それを依頼する人に任せています。
+
+* **セルフサービスの依頼** : 仮想マシン、ストレージボリューム、共有、ユーザーアカウントを、依頼者自身が入力します
+* **保護された操作** : 承認ポイント付きの操作で、ジョブが実行される前に別の人が承認します
+* **データに基づく選択** : CMDB、データベース、REST API から埋めたドロップダウンを、フィールドからフィールドへ連動させます
+* **定期的なジョブ** : 後で、または cron のスケジュールで実行するフォームで、毎回同じように検証された入力を使います
+* **ツールとエージェントのための自動化** : REST API、MCP サーバー、チャットアシスタントが同じフォームを起動します
+
+---
+
+## AnsibleForms か、AWX のサーベイか
+
+AWX、AAP、Ascender には独自のサーベイがあります。どちらが合うかは、ジョブを起動する人に何が必要かによります。
+
+次のような場合は **サーベイ** で十分です。
+
+* 質問が固定されている。テキスト、数値、パスワード、静的なリストからの選択
+* ユーザーがすでに AWX、AAP、Ascender で作業しており、その権限で間に合う
+* アプリケーションとデータベースをもう 1 つ運用・保守したくない
+
+次のような場合は **AnsibleForms** が役立ちます。
+
+* 選択肢がほかの場所から来る。データベース、REST API、ファイル、ほかのフィールド（連動するドロップダウン）
+* プレイブックに届く前に、入力に検証、構造（リスト、ネストしたオブジェクト）、計算された値が必要
+* ジョブに承認ポイント、スケジュール、または 1 つのフォームからプレイブック、テンプレート、承認をつなげるワークフローが必要
+* ユーザーに AWX をまったく見せたくない、または AWX なしでもプレイブックを実行する
+
+AnsibleForms は AWX、AAP、Ascender のテンプレートを起動するので、両者は一緒に使えます。フォームが入力を集めて整え、
+AWX は引き続きジョブを実行します。
+
+---
+
+## 次に読むもの
+
+このセクションの残りのページでは、インストールの前に構成要素を説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [仕組み](how-it-works.html) | アーキテクチャ、起動のステップ、データの保存場所 |
+| [インターフェースの紹介](gui/) | サインインから管理ページまで、すべての画面のスクリーンショット |
+| [概念](concepts.html) | このドキュメント全体で使う用語 |
+| [前提条件](prerequisites.html) | インストールの前に必要なもの |
diff --git a/i18n/ja/_reference/faq.md b/i18n/ja/_reference/faq.md
new file mode 100644
index 0000000..2adc41a
--- /dev/null
+++ b/i18n/ja/_reference/faq.md
@@ -0,0 +1,1277 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# よくある質問
+{: .no_toc }
+
+AnsibleForms についてよくある質問と回答
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## はじめに
+
+### デプロイの構成：1 つのコンテナーか、複数のノードか
+
+既定では、1 つの AnsibleForms コンテナーが Web アプリケーションとバックグラウンド処理を 1 つのプロセスで実行し、その隣で
+プレイブックを実行する RTE コンテナーが動きます。再起動ポリシー（たとえば Docker の `restart: unless-stopped` ）を付けて実行し、データベースと
+永続ボリュームの両方をバックアップしてください。
+
+ロードバランサーの背後で複数のレプリカを動かすには、 `AF_ROLE` でプロセスを分割します。
+
+- `app` ノードは Web インターフェースと API を提供します。いくつでも動かせますが、それぞれに同じ `ACCESS_TOKEN_SECRET` が必要です
+- `worker` はバックグラウンド処理を実行します。スキーマとそのアップグレード、設定シード、スケジュール、夜間のバックアップ、リポジトリの
+  同期、クリーンアップです。データベースのロックを保持して同時に動くワーカーは 1 つだけで、2 つ目は待機し、1 つ目が停止すると引き継ぎます
+- `rte` コンテナーはプレイブックを実行します。より多くのプレイブックを同時に実行するには、これを増やします
+
+アプリノードとワーカーは、データベース、永続ボリューム、 `ENCRYPTION_SECRET` を共有します。ソケットモード（アウトバウンドまたは
+インバウンド、 [モード](rte/modes.html) を参照）の RTE には、データベースも `ENCRYPTION_SECRET` も必要ありません。チャットアシスタントにはスティッキーセッションが必要で、
+各ノードはそれぞれのログを持ちます。 [スケーリング](production/scaling.html) と
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale) の構成を参照してください。
+
+### 複数のリポジトリでのフォーム管理
+
+**フォームに使用しますか?** を有効にしたすべての Git リポジトリのフォームは、自動的にマージされます。フォーム名が重複した場合は最初のものが
+優先され、警告がログに出力されます。 `config.yaml` は 1 つのリポジトリにだけ置いてください。 [Git リポジトリ](repositories/) を参照してください。
+
+### リポジトリについて
+
+AnsibleForms は、リポジトリのパス（ `REPO_PATH` ）の下に Git リポジトリをクローンして pull し、それらは **設定 > リポジトリ** で管理します。
+各リポジトリのスイッチで、そのリポジトリが何を持つか（設定、フォーム、プレイブック、vars ファイル）を設定します。 [Git リポジトリ](repositories/) を参照してください。
+
+### フォームファイルの VS Code での検証
+
+フォームの YAML ファイルにスキーマのヘッダーを追加すると、VS Code でリアルタイムの検証と自動補完が使えます。
+
+[YAML 拡張機能](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) をインストールし、フォームファイルの **1 行目** に次のコメントを追加します。
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+これは、フォームが 1 つのファイル（YAML の辞書）と複数のフォームを含むファイル（YAML のリスト）の両方で使えます。
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+入力しながら、VS Code が不明なプロパティ、欠けている必須フィールド、正しくない型を強調表示します。
+
+---
+
+## ジョブの管理
+
+### 入力済みのデータでジョブを再起動する
+
+再起動ボタンは、以前のジョブの値を入力した状態でフォームを開きます。パスワードフィールドは決して保存されません。
+これにはロールのオプション `allowJobRelaunch` が必要で、フォームでは `allowRelaunch: false` で無効にできます。 [ジョブを再起動する](jobs/actions.html#relaunch-a-job) を参照してください。
+
+### ジョブのログファイル
+
+ジョブ専用のログファイルで進捗を追跡します（v6.1.2）。
+
+AnsibleForms は、Ansible の出力と並べて **ジョブ専用のログファイル** を表示できます。これにより、実行中に目に見える出力を出さない、長時間かかるカスタムモジュールの進捗を追跡できます。
+
+{: .note }
+> この機能は、RTE で実行されるプレイブックでのみ動作します。AWX、AAP、Ascender、Semaphore、Rundeck、
+> Jenkins 上のテンプレートやジョブにはログファイルがありません。
+
+**仕組み:**
+- ジョブの実行中、RTE はプレイブックのフォルダー内の決まったパスにあるログファイルを監視します
+- 2 秒ごとに、ファイルが変わっていれば RTE がその内容をジョブにコピーし、プレイブックの終了時にももう一度コピーします
+- ログファイルはジョブの出力の **ログファイル** セクションに、出力と同じように行番号付きで表示されます。ログの行のタイムスタンプとレベル（ERROR、WARNING、INFO、DEBUG）は出力と同様に読み取られて色付けされ、ANSI カラーにも対応しています
+
+**ログファイルのパスの規則:**
+
+ログファイルは次のパスに書き込む必要があります。
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms は `__jobid__` を自動的に渡す** ため、追加の設定なしでプレイブック内でパスを組み立てられます。
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+この変数を、ファイルに進捗を書き込むべきロールやカスタムモジュールに渡します。
+
+**プレイブックやモジュールの開発者の責任:**
+- 処理の開始時にログファイル（とその `.joblogs/` ディレクトリ）を **作成** します
+- 処理が進むにつれて、意味のある進捗メッセージを **書き込み** ます
+
+RTE は、プレイブックが終了して最後の内容がジョブに保存されると、ファイルを削除します。
+
+**ANSI カラーコードに対応しています。**  
+ログメッセージ内の標準の ANSI エスケープコード（たとえば緑の `\033[92m` 、赤の `\033[91m` ）は UI で色として表示されるため、成功、警告、エラーの状態をひと目で見分けられます。
+
+**典型的な使い方:**  
+API 呼び出しやデータ操作を長く続けて実行するカスタムの Python Ansible モジュール（たとえば SnapMirror の DR ワークフロー）は、ステップごとに 1 行をログファイルに追記できます。AnsibleForms でジョブを見ているオペレーターには、ジョブのページがジョブを追跡するにつれて、ログファイルのセクションに進捗がライブで表示されます。
+
+### Jobid
+
+現在のジョブ ID を渡します。
+
+AnsibleForms は、現在のジョブ ID を extravars の `__jobid__` として自動的に送ります。設定は必要ありません。
+
+### ユーザー情報
+
+現在のユーザーを渡します。
+
+AnsibleForms は、ユーザーの情報を extravars の `ansibleforms_user` として自動的に送ります。設定は必要ありません。
+
+送る量は選べます。 `EXTRAVARS_USER_FIELDS` には最上位のキーのカンマ区切りのリスト（ `username,email,type` ）、
+または何も送らない場合は `none` を指定します。フォームでは独自の `userExtravars` プロパティでこれを上書きできます。
+既定はこれまでどおりオブジェクト全体です。以下で説明するフォーム側の `__user__` はログインのトークンから来るもので、影響を受けることはありません。
+
+### フォームでのユーザー情報
+
+フォームで現在のユーザーの情報にアクセスします（v4.0.2）。
+
+フィールド `__user__` はフォームに自動的に追加され、式から参照できます。
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## フォームフィールド
+
+### 連動するドロップダウン
+
+連動するドロップダウンを作ります。
+
+`enum` フィールド（ドロップダウンボックス）の `query` または `expression` プロパティには、 `$(another_field)` や `$(another_field[0].name)` の形式でプレースホルダーを含められます。  
+参照先のフィールドが変わるとすぐに参照元のフィールドが再評価され、動的に連動するドロップダウンボックスになります。  
+クライアントの Web アプリケーションは 100 ms ごとにフィールドを再評価します。現在のプロセッサーと Chromium エンジンなら、これで途切れのない操作感になります。
+
+{: .note }
+> ほかの enum フィールドを参照すると、ドロップダウンの一覧全体では **なく** 、選択された値が返されます。 `placeholderColumn` プロパティか、 `$(city.name)` のようなドット記法を使ってください。  
+> **v4.0.20 の新機能**: placeholderColumn を "*" に設定すると、1 つの列ではなくレコード全体が出力されます。
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### フィールドのプレースホルダー
+
+ほかのフィールドの値を参照します。
+
+プレースホルダーは、フォーム内のほかのフィールドへの参照です。  
+プレースホルダーの形式は常に `$(reference)` で、式とクエリのどちらにもプレースホルダーを含められます。  
+単純なフィールド（text、number、password）を指すプレースホルダーは、そのフィールドの値を持ちます。  
+オブジェクトベースの enum フィールドを指すプレースホルダーでは、 `placeholderColumn` プロパティか、 `$(city.name)` のようなドット記法を使う必要があります。  
+expression フィールドを指すプレースホルダーはオブジェクト全体を返します。または `$(myarray[0].name)` のような、JavaScript に似た高度な参照も使えます。
+
+{: .important }
+> プレースホルダーは、式が評価される **前** に置き換えられます。結果を文字列として扱いたい場合は、引用符で囲む必要があります。  
+> **v4.0.20 の新機能**: placeholderColumn を "*" に設定すると、1 つの列ではなくレコード全体が出力されます。
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### フィールドを非表示にする
+
+フィールドを非表示にします。
+
+フィールドのプロパティ `hide` でフィールドを非表示にするか、フィールドのプロパティ `dependencies` と `dependencyFn` で動的に表示・非表示を切り替えます。
+
+### フィールドをグループにまとめる
+
+フィールドを 1 つのブロックにまとめます。
+
+フィールドのプロパティ `group` を使います。同じグループ名を持つフィールドは 1 つのブロックにまとめられます。
+
+### フィールドの検証
+
+フィールドを検証します。
+
+`regex` 、 `minValue` 、 `notIn` などの検証用のフィールドプロパティを使います。
+
+### enum の既定値
+
+enum の既定値です。
+
+フィールドのプロパティ `default` で既定値を設定します。 `enum` フィールドでは、 `__auto__` などの値を使って最初の項目を自動的に選択できます。
+
+式に基づく動的な既定値にするには、次の例のように、既定の項目をリストの先頭に移動します。
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### 式による既定値
+
+式による既定値です。
+
+text、number、date のフィールドでは、 `default` プロパティで静的な既定値を設定します。
+
+既定値を式に基づく動的なものにするには、次の 2 つのプロパティのどちらかを使います。
+* `editable` : editable プロパティを使って、expression フィールドを編集可能にします
+* `evalDefault` : evalDefault プロパティを使って、既定値を式として評価します
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## ウィザードとワークフロー
+
+### ウィザードとワークフローの違いは何ですか?
+
+**ウィザード** と **ワークフロー** はどちらもステップで構成されますが、異なる層で動作し、組み合わせることができます。
+
+| | [`workflow`](forms/workflow.html) （ワークフロー） | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **層** | 実行 | フォーム / UI |
+| **分割するもの** | ジョブを、順に、または並行して実行されるノードに分けます | 1 つのフォームの入力を複数のページに分けます |
+| **結果** | ノードごとのジョブ（それぞれ独自のプレイブックやテンプレート）を持つ 1 つのワークフロージョブ | 最後に 1 つのジョブが実行されます |
+| **フォームの `type`** | `workflow` である必要があります | `subform` 以外のすべての種類のフォームで使えます |
+| **定義するもの** | デザイナーの [ワークフローファイル](workflows/file.html) （ `workflow:` ） | [サブフォーム](forms/subform.html) の参照のリスト（ `wizard:` ） |
+| **使う場面** | 「A を実行し、次に B、次に C を別々のジョブとして実行したい」 | 「フォームのフィールドが多すぎて 1 ページに収まらない」 |
+
+**要点:** ワークフローは *何をどの順で実行するか* に関するもので、 `wizard` は *ユーザーがフォームをどう入力するか* に関するものです。
+
+{: .note }
+> `steps` を持つフォームの種類 `multistep` は、7 より前に実行の部分を担っていました。7 以降は非推奨で、
+> 8 で削除されます。ワークフローは multistep ができることをすべて行えます。 [マルチステップフォーム](forms/multistep.html) を参照してください。
+
+#### ワークフローのみ
+{: .no_toc }
+
+`type: workflow` のフォームは、デザイナーのワークフローの 1 つを実行します。ユーザーは 1 ページのフィールドを入力して「送信」を押し、
+ワークフローは各ノードを、フォームの値を追加変数として実行します。
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### ウィザードのみ
+{: .no_toc }
+
+フォームの `wizard:` ブロックは、入力の収集を複数のページに分けます。最後に実行されるジョブは **1 つ** だけです。すべてのページからマージされた extravars が、1 つのプレイブック、テンプレート、またはワークフローに送られます。
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+読み取り専用の確認ページが、ウィザードの最後のページとして自動的に追加されます。YAML で宣言する必要はありません。
+
+#### 組み合わせ（ワークフローの上にウィザード）
+{: .no_toc }
+
+ウィザードは、ワークフローのフォームの上に重ねることができます。ユーザーがウィザードのページを入力して「送信」を押すと、 **その後で**
+ワークフローが開始されます。ウィザードのステップの `defaultModel` をノードの
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) と一致させると、 **ウィザードの 1 ページを 1 つのノードに** 振り分けられます。
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+そして、デザイナーのワークフローファイルにあるワークフロー `provision-host` です。
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` は 1 階層だけの参照なので、一致させたい場合は `defaultModel` にフラットな名前を使ってください（たとえば `defaultModel: input.basics` ではなく `defaultModel: basics` ）。
+
+プロパティの完全なリファレンスは [ウィザードのページ](forms/wizard.html) を参照してください。
+
+### ウィザードのステップを条件によって表示したりスキップしたりするには?
+
+ステップを完全に **非表示** にするには `when:` を、表示されているステップをユーザーが **スキップ** できるようにするには `optional: true` を使います。この 2 つは独立しており、一般に組み合わせるべきではありません。
+
+#### `when:` : 条件付きの表示
+{: .no_toc }
+
+式が偽の値に評価されると、ステップは非表示になります。ユーザーにはまったく表示されず、その値も収集されません。式では `__parent__.<stepname>.<field>` で前のステップを読み取れます。
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+選ばれた `kind` に一致するページだけが表示されます。非表示のステップより後のステップは、自動的に番号が振り直されます。
+
+#### `optional: true` : 表示されているステップのスキップを許可する
+{: .no_toc }
+
+ステップはステッパーに **常に表示** されますが、ユーザーは入力せずに **次へ** を押せます。また、そのページを開かなかった場合や完了しなかった場合でも **送信** できます。
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+ユーザーは「詳細」ページを開いて空のままにし、「次へ」を押して確認ページに直接進めます。
+
+{: .note }
+> `when:` は *表示* を制御し、 `optional:` は *ページを完了しなければならないかどうか* を制御します。組み合わせないでください。ページを消すには `when:` を、表示したままスキップできるようにするには `optional:` を使います。
+
+### 前のウィザードステップの値を参照するには?
+
+後のステップのどのフィールドでも、 `$(__parent__.<stepname>.<field>)` を使います。
+
+ウィザードのステップの `name` （既定ではその `subform` の名前）が名前空間になり、その値は後のステップにその下で公開されます。
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+これは `list` と `yaml` のサブフォームが使うのと同じ `__parent__` の仕組みです。 [サブフォームの中で親フォームのデータにアクセスするには?](#how-do-i-access-parent-form-data-inside-a-subform) を参照してください。
+
+---
+
+## セキュリティと認証情報
+
+### 認証情報
+
+認証情報を渡します。
+
+認証情報はいくつかの方法で渡せます。
+* フィールドのプロパティ `asCredential` を使う  
+* フォームのプロパティ `credentials` （キーと値のペア）を使う
+* `__credentials__` という extravar を使う
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### 管理者パスワードを紛失した場合
+
+ローカルの `admin` アカウントのパスワードを紛失し、ほかに管理者ユーザーがいない場合は、復旧オプション `REINIT_ADMIN` を使います。 **これは実行時に認証を迂回するものではありません。** 起動時にローカルの管理者アカウントを一度だけ強制的にリセットするもので、その後は通常の認証が行われます。
+
+**仕組み**
+
+起動時に `REINIT_ADMIN=1` が設定されていると、AnsibleForms は次のことを行います。
+
+1. `admins` グループが存在することを確認します（なければ作成します）。
+2. ローカルの管理者ユーザーを探します（既定のユーザー名は `admin` で、 `ADMIN_USERNAME` で変更できます）。
+3. 存在する場合は、パスワードを `ADMIN_PASSWORD` の値にリセットし、 `admins` グループに再び所属させます。
+4. 存在しない場合は、新規インストールと同じように作成します。
+5. ログで目立つように、この操作を記録します。
+
+**手順**
+
+1. AnsibleForms を停止します。
+2. 環境変数を設定します（強力なパスワードを使ってください）。
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   Docker Compose では、AnsibleForms サービスの `environment:` ブロックに追加します。
+3. AnsibleForms を起動し、ログに次のような行が出るのを確認します。
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. `admin` / `YourNewStrongPasswordHere` でログインします。
+5. 以降の再起動で管理者のパスワードが再びリセットされないよう、 **`REINIT_ADMIN` を削除する（または `0` に戻す）** して、再起動します。
+
+**注意事項**
+
+- LDAP が唯一のログイン方法として設定されていてそれが失敗したために締め出された場合でも、復旧したローカルの `admin` アカウントは常にローカルのデータベース認証にフォールバックするため、ログインして LDAP を修正できます。
+- 以前の環境変数 `ENABLE_BYPASS` は削除されました。これは任意のパスワードで admin としてログインできるもので、有効のままにしておくのは危険でした。 `REINIT_ADMIN` はパスワードをリセットするだけで、その後は通常の認証が適用されます。
+- `REINIT_ADMIN` は既存のセッションやトークンを無効にしません。変わるのはパスワードのハッシュとグループの所属だけです。
+
+### REST ヘルパーの接続先の制限（許可リストと拒否リスト）
+
+`fn.fnRestBasic` 、 `fn.fnRestAdvanced` 、 `fn.fnRestJwt` 、 `fn.fnRestJwtSecure` のヘルパーは、フォームの `expression` プロパティから呼び出して HTTP でデータを取得できます。既定では、式の作成者は AnsibleForms のホストから到達できる **どの** URL でも対象にできるため、機密性の高いネットワークでは制限したい場合があります。
+
+2 つの環境変数で、許可リストと拒否リストを指定できます。
+
+| 変数 | 動作 |
+|---|---|
+| `REST_ALLOWED_HOSTS` | カンマ区切りのホスト名または CIDR。設定すると、これらの接続先 **だけ** が許可されます。 |
+| `REST_DENIED_HOSTS` | カンマ区切りのホスト名または CIDR。常にブロックされます。許可リストより優先されます。 |
+
+ホスト名は URL のホストと大文字小文字を区別せずに照合されます。CIDR は、そのホストが解決されるすべての IP と照合されるため、 `10.0.0.0/8` はプライベートの範囲に解決されるあらゆる DNS 名をブロックします。
+
+**例:**
+
+1 行目は 2 つのホストだけを許可し、2 行目は特定の接続先をブロックします。
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **このガードが保護するのは AnsibleForms の Node.js プロセスだけです。** プレイブックが実行されると、Ansible 自体は AnsibleForms の制御の外で、ホストから何にでも到達できます。これらのリストは、フォームの作成者が式をメタデータサービスや内部の UI へのプロキシにしてしまうのを防ぐために使い、ネットワークのファイアウォールとして頼らないでください。
+
+7.3.0 以降、REST ヘルパーはほかのすべての接続と同じくエンドポイントの TLS 証明書をチェックし、
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) （既定は `60` ）を過ぎると諦めます。プライベート CA は
+`NODE_EXTRA_CA_CERTS` で信頼させるか、自己署名証明書のエンドポイントに対してだけ [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) を `1` に設定してください。
+
+### HashiCorp Vault との連携
+
+認証情報は、 **シークレットストア** として設定した HashiCorp Vault からユーザーとパスワードを読み取れます。
+[シークレットストア](secret-stores) を参照してください。以前のバージョンの `VAULT_*` 環境変数は、
+7.x の初回起動時にストア `vault` として一度だけインポートされます。
+
+1 つのプレイブックの中だけで使うシークレットには、 `community.hashi_vault` の
+lookup プラグインも使えます。これは Vault から直接読み取り、AnsibleForms を経由しません。
+
+---
+
+## 連携
+
+### AWX/Tower/AAP を照会する
+
+AWX または Ansible Automation Platform の情報を照会します。
+
+AWX や Tower のデータでドロップダウンボックスを埋めるには、 `fn.fnRestBasic` または `fn.fnRestJwtSecure` を使います。7.3.0 以降、これらのヘルパーは
+AWX のアドレスの証明書をチェックします。自己署名証明書の場合は、 `NODE_EXTRA_CA_CERTS` でその CA を信頼させるか、
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) を `1` に設定してください。
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## カスタマイズ
+
+### カスタマイズ
+
+AnsibleForms をカスタマイズします。
+
+AnsibleForms は Web アプリケーションです。Node.js でネイティブに実行している場合は、そのファイルを置き換えたり変更したりできます。  
+ただし推奨されるのは、Docker イメージとして実行し、ボリュームやファイルのマッピングを追加する方法です。Docker Compose プロジェクトでは、データベース、プレイブック、ログ、証明書、SSH キーを永続化するためのディレクトリがすでにマッピングされており、さらにマッピングを追加できます。独自のロゴは設定の **ロゴ** ページでアップロードします。  
+`custom.js` ファイルには、式で使う独自の JavaScript 関数を記述します。組み込みの関数は接頭辞 `fn.` を使い（たとえば fn.fnRestBasic）、カスタム関数は接頭辞 `fnc.` を使います。  
+同じように、 `jq.custom.definitions` ファイルに独自の jq の定義を追加できます。
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### YTT を有効にする
+
+ytt を有効にします。
+
+ytt を使うには、 `USE_YTT=1` を設定します。  
+ytt について詳しくは https://carvel.dev/ytt/ を参照してください。
+
+{: .important }  
+> この機能は十分にテストされておらず、機能強化として追加されて以来、フィードバックも寄せられていません。  
+> ytt を使う場合は、デザイナーを無効にする必要があります。デザイナーは YAML ファイルを中間の JSON に変換し、ytt の構文（YAML のコメントで構成されています）を落としてしまいます。
+
+ルートディレクトリに `lib` ディレクトリが存在する必要があり、これは ytt の呼び出しに自動的に含まれます。
+データは、接頭辞付きの環境変数を設定することでグローバルに提供できます。  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+または、ライブラリのデータファイルを提供します。
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**ライブラリ `demo` が ytt のコンテキストに存在する必要があります（lib/_ytt_lib/demo/values.yml）**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+読み込んだデータは次のように使えます。
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## アクセス制御
+
+### ユーザーにできることを制限するには（ロールのオプション）?
+
+ロールが見られるフォームを制限するだけでなく、ロールの `options` で、そのメンバーに対して UI の機能をオンまたはオフにできます。
+すべてのオプション、その既定値、ロールをまたいだオプションの組み合わせ方については、 [ロールのオプション](config/roles.html#role-options) を参照してください。
+
+### プレイブックやフォームで独自の RBAC ロジックを実装するには?
+
+ユーザーの ID は、実行のたびにフロントエンドとバックエンドの両方で利用できます。
+
+フォームが送信されるたびに、AnsibleForms は現在のユーザーの完全な ID を、Ansible に送る extravars に自動的に入れます。
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+そのため、プレイブックや任意のカスタム Ansible モジュールは、 `ansibleforms_user` を直接使って細かな判断ができます。たとえば、本番のインベントリの変更を特定のグループだけに許可したり、送信者のユーザー名で監査証跡を書き込んだりできます。
+
+**フロントエンド** では、同じオブジェクトを特別なフィールド `__user__` で利用できます。
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**典型的なパターン:**
+
+ユーザーの ID を使うと、次のようなパターンを実現できます。
+
+- **RBAC の設定ファイルやデータベースとの照合** : グループと許可されたリソースを対応付ける YAML や JSON のファイルを（ `fn.fnReadYamlFile` や式で）読み込み、 `$(__user__.groups)` で絞り込みます
+- **監査証跡** : `ansibleforms_user.username` を追加変数として渡し、誰がジョブを実行したかを記録します
+- **動的なフィールドの値** : ユーザーのグループやロールに応じて、異なる enum の選択肢を示したり、フィールドに値を入れたり、セクションを非表示にしたりします
+- **プレイブック側での認可** : フォームの `roles` リストとは独立した多層防御のチェックとして、プレイブックが処理を進める前に `ansibleforms_user.groups` に必要なグループが含まれていることを確認します
+
+{: .note }
+> 上のオブジェクトは既定で送られるものです。インスタンスで `EXTRAVARS_USER_FIELDS` が設定されている場合、
+> またはフォームで `userExtravars` が設定されている場合は、そこで指定したキーだけが送られます。そのため、
+> `ansibleforms_user.groups` を確認するプレイブックでは、 `groups` がその中に含まれている必要があります。フロントエンドの
+> `__user__` フィールドはログインのトークンから来るもので、どちらの設定によっても削られることはありません。
+
+---
+
+## ジョブのスケジュール
+
+### フォームを自動的に実行するようにスケジュールするには?
+
+**送信** の横のドロップダウンを開き、 **スケジュール (定期実行)** または **後で実行 (1 回限り)** を選びます。これにはロールの
+オプション `allowScheduledJobs` （管理者レベル）と `allowPlannedJobs` が必要です。 [スケジュール](jobs/schedules.html) を参照してください。
+
+### どのような cron 式を使えますか?
+
+定期的なスケジュールには、標準の 5 フィールドの cron 式（分、時、日、月、曜日）を指定します。
+
+| 式 | 実行タイミング |
+|---|---|
+| `*/15 * * * *` | 15 分ごと |
+| `0 * * * *` | 毎時 0 分 |
+| `0 */6 * * *` | 6 時間ごと。00:00、06:00、12:00、18:00 |
+| `0 2 * * *` | 毎日 02:00 |
+| `30 7 * * 1-5` | 月曜日から金曜日の 07:30 |
+| `0 8 * * MON` | 毎週月曜日の 08:00（曜日と月の名前も使えます） |
+| `0 0 1 * *` | 毎月 1 日の 0 時 |
+| `0 22 L * *` | 毎月最終日の 22:00 |
+| `0 6 * * 1#1` | 毎月第 1 月曜日の 06:00 |
+| `*/30 * * * * *` | 30 秒ごと（先頭に任意の 6 番目のフィールドを置くと秒になります） |
+
+日と曜日の両方を指定した場合、スケジュールはどちらかが一致したときに実行されます。 `0 0 13 * 5` は
+13 日と毎週金曜日に実行されます。実行できない式や、決して起こりえない式（ `0 0 30 2 *` ）は、サーバーが拒否します。
+
+**スケジュール** ページでは、cron エディターが式の内容を説明し、次回以降の実行をプレビューします。 `@daily` のような
+ニックネーム、 `?` のワイルドカード、 `W` （最も近い平日）の修飾子は受け付けないため、表にある形式を使ってください。
+
+{: .note }
+> **タイムゾーン** cron のスケジュールは、プロフィールやブラウザーのタイムゾーンではなく、 [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> （既定は `UTC` ）で設定したサーバーのタイムゾーンで実行されます。 `LOG_TZ=Europe/Madrid` で `0 2 * * *` は、夏時間に従って、1 年を通してマドリード時間の 02:00 に
+> 実行されます。cron エディターは、次回以降の実行を同じタイムゾーンでプレビューします。リポジトリの
+> pull のスケジュールも同じタイムゾーンを使います。
+
+---
+
+## フォームデータの保存と読み込み
+
+### ジョブを実行せずにフォームのデータを保存して読み込み直すには?
+
+**送信** の横のドロップダウンで **データを保存** を選んでフィールドの値を保存し、後で **保存済みデータから読み込む** で元に戻します。
+パスワードフィールドは決して保存されません。これにはロールのオプション `allowStoredJobs` が必要です。 [保存済みジョブ](jobs/stored-jobs.html) を参照してください。
+
+---
+
+## ネストしたフォームと構造化されたフィールド
+
+### フォームで構造化されたデータや繰り返しのデータを集めるには?
+
+サブフォームと組み合わせた `list` と `yaml` のフィールドを使います（6.2.0 以降）。
+
+サーバーの一覧、ネットワークインターフェースの組、1 つのネストしたオブジェクトなど、複雑な構造化データを集めるには、 `list` または `yaml` のフィールドの種類を `subform` と一緒に使います。
+
+**サブフォーム** は再利用可能なフォームの断片で（ `type: subform` で定義します）、単独のタイルとして表示されることはありません。ほかのフォームのフィールドから参照されるためだけに存在します。完全なリファレンスは [サブフォームのドキュメント](forms/subform.html) を参照してください。
+
+**構造化された行のリストを集める: `list` フィールド:**
+
+`list` フィールドは、参照するサブフォームを行ごとに 1 回開きます。
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+Ansible に送られる extravar `servers` は、オブジェクトの配列です: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**1 つの構造化オブジェクトを編集する: `yaml` フィールド:**
+
+`yaml` フィールドには 3 つのモードがあります。
+
+| モード | 指定方法 | 動作 |
+|---|---|---|
+| **エディター** | 既定 | YAML の構文を強調表示する完全なエディターを表示し、ユーザーが直接入力できます |
+| **読み取り専用** | `readonly: true` | YAML の値を整形された読み取り専用のテキストとして表示し、編集はできません |
+| **サブフォーム** | `subform: MySubform` | 生のエディターを隠し、クリックするとサブフォームをドリルダウンのエディターとして開きます |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**アップロードとダウンロード: `list` と `yaml` のフィールド:**
+
+どちらのフィールドの種類も、2 つの任意のプロパティで、クライアント側でのファイルのやり取りに対応しています。
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> `list` フィールドとフォームの種類 `subform` は、7.0.0 で削除された `table` フィールドと `tableFields` を置き換えたものです。
+
+### サブフォームの中で親フォームのデータにアクセスするには?
+
+サブフォームの中から、 `__parent__` で親のフィールドの値を参照します（v6.3.0 以降）。
+
+サブフォームが開かれると、 **`list`** フィールド（各行のエディター）からでも、サブフォームモードの **`yaml`** フィールドからでも、AnsibleForms は `__parent__` という特別な読み取り専用のフィールドをサブフォームに自動的に入れます。これには、定数と vars を含め、 **サブフォームが開かれた時点での親フォームのすべてのフィールドの値** のスナップショットが含まれます。
+
+これにより、サブフォームのフィールドは、追加の設定なしで親のデータを参照する式を使えます。
+
+#### `__parent__` には何が入っていますか?
+{: .no_toc }
+
+`__parent__` は、親フォームのフィールド名をキーとするプレーンなオブジェクトです。
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` は **Ansible には送られません** 。 `__user__` と同じく、extravars から取り除かれます。これは純粋に、サブフォーム内の式のためのフロントエンドのヘルパーです。
+
+#### サブフォームの式で親の値にアクセスする
+{: .no_toc }
+
+標準の `$(...)` の式の構文で、親の値を参照します。
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### ネストしたサブフォーム
+{: .no_toc }
+
+`__parent__` は常に **直接の親** フォームを指します。親フォームから開かれたサブフォームの中に `list` をネストした場合、内側のサブフォームの `__parent__` には中間のサブフォームのデータが入ります。さらに上の階層に届くには、中間のサブフォームも自分の `__parent__` を引き継いでいれば、 `$(__parent__.__parent__.someField)` のように参照をつなげます。
+
+### `table` / `tableFields` から `list` / `subform` に移行するには?
+
+`table` フィールドと `tableFields` プロパティは 6.2.0 で非推奨になり、7.0.0 で削除されました。これらをまだ使っているフォームは検証に失敗します。移行するには次のようにします。
+
+1. `tableFields` の列を、通常の `formfields` を持つ新しい `type: subform` のフォームに取り出します
+2. `table` フィールドを、 `subform: MySubformName` でそのサブフォームを参照する `list` フィールドに置き換えます
+
+**変更前:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**変更後:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### `tableFields` の `from` を `__parent__` の式に移行する
+{: .no_toc }
+
+`tableFields` の enum 列の `from` プロパティは、親フォームのほかのフィールドからドロップダウンの選択肢を埋めていました。 `subform` では、同じ値を `__parent__` で読み取る `expression` に置き換えます。
+
+**変更前: `from` を持つ `tableFields`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**変更後: `__parent__` の式を持つサブフォーム:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` はそのフィールドの **現在の値** を返すため、そのフィールド自体が動的な expression フィールドであっても、サブフォームには常に親で最後に評価された結果が見えます。
diff --git a/i18n/ja/_reference/getting-help.md b/i18n/ja/_reference/getting-help.md
new file mode 100644
index 0000000..634b1e9
--- /dev/null
+++ b/i18n/ja/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: ヘルプを得る
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# ヘルプを得る
+{: .no_toc }
+
+質問、バグやセキュリティ問題の報告、改善の提案をする場所
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 質問する前に
+
+答えのほとんどはすでに文書化されています。少し調べるだけで、やり取りを 1 往復省けることがよくあります。
+
+1. 各ページの上部にある検索ボックスで、このサイトを検索します。
+2. 正確なエラーメッセージを [トラブルシューティング](troubleshooting.html) で調べ、 [FAQ](faq.html) にも目を通します。
+3. サーバーログ（ **設定** 、次に **サーバーログ** ）と **ステータス** ページを確認します。設定の問題の多くはここに表示されます。
+4. [変更履歴](changelog.html) を確認します。問題は新しいリリースですでに修正されているかもしれません。
+
+---
+
+## 問い合わせ先
+
+依頼の種類ごとに場所が決まっており、すべて GitHub にあります。
+
+| したいこと | 行き先 |
+|---|---|
+| 質問する、アイデアを共有する | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| バグを報告する | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| 機能を提案する | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| セキュリティ問題を報告する | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new) で非公開に |
+| このドキュメントを修正・改善する | 各ページの下部にある **GitHub でこのページを編集** 、または [Web サイトの issue](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## バグを報告する
+
+再現できる報告ほど早く修正されます。バグ報告のテンプレートでは、次の情報を求めています。
+
+* **バージョン** : 上部バーのヘルプ（ **?** ）メニューの **バージョン情報** に表示されます
+* **デプロイ方法** : Docker、Docker Compose、Kubernetes、インストーラー（とそのエンジン）、ネイティブインストール、またはソースから
+* **再現手順** : 何をしたか、何を期待したか、そして実際に何が起きたか
+* **証拠** : サーバーログの関連する行と、問題が目に見える場合はスクリーンショット
+
+フォームの問題の場合は、それを再現する最小限のフォーム定義を含めてください。投稿する前に、ログやフォームからパスワード、トークン、ホスト名、その他の
+非公開のデータを取り除いてください。issue とディスカッションは公開されています。
+
+---
+
+## セキュリティ問題を報告する
+
+**公開の issue は決して作成しないでください。** メンテナーだけが見られる [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new) を使ってください。
+
+[セキュリティポリシー](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) に、サポート対象のバージョンと
+報告後の流れが記載されています。
diff --git a/i18n/ja/_reference/troubleshooting.md b/i18n/ja/_reference/troubleshooting.md
new file mode 100644
index 0000000..4ed5ff6
--- /dev/null
+++ b/i18n/ja/_reference/troubleshooting.md
@@ -0,0 +1,759 @@
+---
+layout: default
+title: トラブルシューティング
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# トラブルシューティング
+{: .no_toc }
+
+エラーメッセージと症状、その原因と解決方法
+{: .fs-6 .fw-300 }
+
+---
+
+以下の各問題は、表示されるメッセージまたは症状を見出しにし、その原因と解決方法を続けています。メッセージは
+AnsibleForms が出力するとおりに引用しています。 `<name>` はケースごとに異なる値を表します。ほとんどのメッセージはサーバー
+ログに出力され、 [サーバーログ](gui/administration.html#server-log) または `docker logs` で確認できます。
+
+**データベースと起動**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**設定とフォーム**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [ベース設定に forms セクションがある](#the-base-config-has-a-forms-section)
+* [フォームがダッシュボードに表示されない](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**ログイン**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Azure AD または OIDC の認証に失敗する](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [再起動後または 1 日後にログアウトされる](#logged-out-after-a-restart-or-after-a-day)
+* [シングルサインオン後にフォームとジョブが空になる（HTTP 431）](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**ジョブ**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [ジョブのステータスが abandoned になる](#a-job-shows-the-status-abandoned)
+* [RTE が接続しない](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Git リポジトリとバックアップ**
+
+* [リポジトリのクローンまたは pull に失敗する](#a-repository-clone-or-pull-failed)
+* [フォームリポジトリがまだクローンされていない](#the-forms-repository-is-not-cloned-yet)
+* [バックアップに失敗する](#a-backup-failed)
+
+関連する 2 つの問題については、 [FAQ](faq.html) で詳しく説明しています。
+[管理者パスワードを紛失した場合](faq.html#recovering-a-lost-admin-password) と
+[REST ヘルパーの接続先の制限](faq.html#restricting-rest-helper-destinations-allowdeny-lists) です。
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms が起動せず、ログに次の行が 5 秒ごとに繰り返し出力されます。
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**原因**
+
+起動時、AnsibleForms はデータベースがクエリに応答するまで待ち、応答しない限り待ち続けます。
+`<reason>` はデータベースドライバー自身のメッセージです。接続の拒否やタイムアウトはホストやポートを、
+アクセス拒否のメッセージはユーザー名やパスワードを示しています。
+
+**解決方法**
+
+[`DB_HOST`](customization/server.html#env_DB_HOST) 、 [`DB_PORT`](customization/server.html#env_DB_PORT) 、
+[`DB_USER`](customization/server.html#env_DB_USER) 、 [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD) を確認します。
+コンテナーの中では、 `localhost` は MySQL を動かしているホストではなく、コンテナー自身です。MySQL がネットワークアドレスで
+待ち受けていること、そしてユーザーが AnsibleForms のホストから接続できることを確認してください。データベースが応答すると、
+AnsibleForms は自動的に処理を続けます。再起動は必要ありません。
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+ブラウザーでログインページではなくデータベースのページが開き、ログに次のように表示されます。
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**原因**
+
+`AnsibleForms` スキーマがないか、不完全です。 *空の* データベースは、
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) が `0` でない限り、起動時に自動的に準備されます。たとえば
+データベースユーザーにスキーマを作成する権限がないなどの理由でこれに失敗すると、ログに `Failed to create the schema automatically : <reason>` と出力されます。
+存在するもののテーブルが欠けているスキーマ（ `Table '<name>' is not present` ）が自動的に作り直されることはありません。スキーマを
+作成するとまずすべてのテーブルが削除されるためです。その場合、データベースのページには *It appears that you have an unuseable schema* と表示されます。
+
+**解決方法**
+
+新規インストールでは、データベースユーザーに `AnsibleForms` スキーマを作成する権限を与えて再起動するか、データベースのページで
+**作成** を押します。スキーマが一部だけ存在する場合は、バックアップを復元するか、不完全な `AnsibleForms`
+スキーマを削除して AnsibleForms が作り直せるようにします。失敗したテーブルとパッチはログに一覧表示されます。
+
+---
+
+## Schema creation is disabled
+
+データベースのページから、または `POST /api/v2/schema` でスキーマを作成しようとすると、次のエラーで失敗します。
+
+```
+Schema creation is disabled
+```
+
+**原因**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) が `0` で、起動時の自動作成とエンドポイントの両方が
+無効になっています。すでにユーザーがいるデータベースでは、管理者としてログインしていない呼び出し元もエンドポイントが
+`Schema creation requires an authenticated administrator` で拒否します。
+
+**解決方法**
+
+一度だけ `ALLOW_SCHEMA_CREATION=1` （これが既定です）でスキーマを作成するか、バックアップから復元し、その後
+変数を `0` に戻します。準備済みのデータベースでは、スキーマを作り直す前に管理者としてログインしてください。また、
+すべてのテーブルが削除されて作り直されることに注意してください。
+
+---
+
+## Config seed failed, refusing to start
+
+コンテナーが起動直後に終了し、その出力の最後が次のようになります。
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**原因**
+
+[`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) のファイルを適用できませんでした。たとえば有効な
+YAML でない、シードのスキーマに違反している、などです。何が問題だったかは `<reason>` に示されます。AnsibleForms は、宣言されたオブジェクトの半分だけで
+動くよりも、起動を拒否します。理由は標準エラーにも出力されるため、 `docker logs` や `kubectl logs` で確認できます。
+
+**解決方法**
+
+`<reason>` が示すものを修正して、もう一度起動します。シードの適用方法は [再読み込みと起動](seed/reloading.html) を、
+有効なファイルについては [例](seed/example.html) を参照してください。
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+起動のたびに次の警告がログに出力されます。
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+または、ワーカーが次のメッセージで起動を拒否します。
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**原因**
+
+保存されたシークレットは [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET) で暗号化されます。7.3.0 以降、シークレットは
+認証情報（LDAP ディレクトリ、SSO プロバイダー、ランナー、シークレットストアなどのパスワードやトークン）に、Slack と
+Teams の Webhook のアドレスと並んで保存されています。これが設定されていないと、ソースコードで公開されている鍵が使われます。7.3.0 以降、新しい
+`ENCRYPTION_SECRET` で起動すると、保存されているすべてのシークレットが 1 つのトランザクションでその鍵で再暗号化されます。初めて設定したときは既定の鍵から、
+変更したときは [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) から再暗号化します。
+保存されたシークレットがどちらの鍵でも暗号化されていなかった場合は、何も変更されず、AnsibleForms は起動しません。
+
+**解決方法**
+
+`ENCRYPTION_SECRET` を設定し、ほかのシークレットと一緒に保管してください。バックアップには決して含まれません。次の起動では
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET` がログに出力されます。後で変更するには、1 回の起動の間だけ
+`ENCRYPTION_SECRET` に新しい値を、 `ENCRYPTION_SECRET_PREVIOUS` に古い値を設定し、その後 `ENCRYPTION_SECRET_PREVIOUS` を削除します。
+ワーカーが起動を拒否する場合は、 `ENCRYPTION_SECRET_PREVIOUS` にシークレットを暗号化した鍵を設定するか、古い値に戻してください。
+
+---
+
+## Could not load the forms
+
+ダッシュボードにフォームが表示されず、次のように報告されます。
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**原因**
+
+ベース設定（ `config.yaml` ）を読み取れないか、有効ではありません。どちらかは `<reason>` でわかります。
+
+| 理由 | 原因 |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | YAML の構文エラー |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | 空のファイル、またはコメントだけのファイル |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | 同じロールが 2 回定義されている |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` がなく、そのフォルダーに書き込めない |
+| `There is no forms directory nor could there be one created from template.` | フォームフォルダーがなく、作成もできない |
+| その他の行 | 設定がスキーマに違反している。たとえば `groups` のないロール |
+
+**解決方法**
+
+[`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) が指すファイル、または設定に使っているリポジトリの
+`config.yaml` を修正します。ファイルがない場合は、 [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) と
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) が書き込み可能な永続的な場所を指すようにします。構造については
+[config.yaml](config/) を参照してください。
+
+---
+
+## ベース設定に forms セクションがある
+
+6.x からアップグレードした後、ダッシュボードが空になり、警告パネルに次のように表示されます。
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**原因**
+
+7.0.0 以降、フォームはそれぞれフォームフォルダー内の専用のファイルに置かれます。まだ `config.yaml` に記載されているフォームは
+無視されます。
+
+**解決方法**
+
+各フォームを [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) 内の専用のファイルに移します。
+[7.x へのアップグレード](upgrade-7.html) を参照してください。
+
+---
+
+## フォームがダッシュボードに表示されない
+
+フォームのファイルは存在するのに、ユーザーのダッシュボードにそのフォームが表示されません。
+
+**原因**
+
+ユーザーにフォームが表示されるのは、フォームの `roles` のいずれかがユーザーのロールのいずれかと一致する場合だけです。管理者にはすべてのフォームが表示されます。すべてのユーザーは
+`default` ロールを持つため、 `roles: [default]` のフォームは全員に表示されます。ユーザーのロールは、 `config.yaml` の `roles` に
+記載されたグループとユーザーから決まります。 `categories` のないフォームは **Default** に表示されるため、ほかのカテゴリには
+表示されませんが、 **すべてのフォーム** には表示されます。最後に、検証に失敗したフォームはスキップされます。その場合
+ダッシュボードには **この設定の警告またはエラー** ボタンが表示され、次のようなメッセージが開きます。
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**解決方法**
+
+警告パネルを開き、そこに列挙されたものを修正します。プロフィールの [権限](profile/permissions.html) でユーザーのロールを確認し、
+フォームの `roles` と `categories` も確認します。 [ロール](config/roles.html) と [カテゴリ](config/categories.html) を参照してください。2 つのファイルで同じフォーム名を定義している場合は、
+最初に読み込まれたものが優先されます。
+
+---
+
+## Could not save the forms
+
+デザイナーでの保存が、次のエラーで失敗します。
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**原因**
+
+デザイナーは、何かを書き込む前にすべてのフォームをスキーマに照らして検証します。 `<messages>` の各行は、ルールに違反している
+フォームとフィールドを示します。7.0.0 で削除されたオプションには専用のメッセージがあります。たとえば
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform` です。
+
+**解決方法**
+
+メッセージが示すフィールドを修正します。7.0.0 で削除されたオプションについては、 [7.x へのアップグレード](upgrade-7.html) に従ってください。
+フォームファイルを AnsibleForms に渡す前に検証するには、FAQ の
+[フォームファイルの VS Code での検証](faq.html#vs-code-validation-for-form-files) を参照してください。
+
+---
+
+## The editor is read-only
+
+デザイナーに別のユーザーの名前とともに **ロック中** と表示され、保存が次のエラーで失敗します。
+
+```
+The editor is read-only
+```
+
+**原因**
+
+フォームを編集できるのは一度に 1 人だけです。ロックは誰かがデザイナーを開始したときに取得され、その人が停止するまで残ります。
+停止せずにブラウザーを閉じた場合も同様です。ほかの人による保存は、API が
+`Designer is locked by <username>` で拒否します。
+
+**解決方法**
+
+`<username>` にデザイナーを停止するよう依頼します。それができない場合は、デザイナーの **解除** を使います。ロックを持っていた人は、
+保存していない変更を失います。
+
+---
+
+## Abuse attempt of eval function
+
+式のフィールドにエラーが表示され、ログに次のような行があります。
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**原因**
+
+サーバー側の式は、実行の前にチェックされます。呼び出せるのは `fn.` と `fnc.` の関数だけで、複数の文、
+複数行、テンプレートリテラル、 `process.env` 、 `require` や `constructor` などの語は拒否されます。どのルールに違反したかは
+メッセージに示されます。 [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) を
+`off` にすると、すべてのサーバー側の式が
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal` で失敗します。
+
+**解決方法**
+
+式を 1 つの `fn.` 呼び出しか単純な演算に書き直すか、 `runLocal: true` でブラウザーで実行します。
+[式](expressions/) と [ローカルの式](expressions/local.html) を参照してください。
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+REST API を呼び出すフィールドが空のままになり、ログに次のように表示されます。
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**原因**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) が設定されており、URL のホストがそこに含まれていません。
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) に一致するホストは
+`blocked by REST_DENIED_HOSTS entry "<entry>"` で、名前解決できないホストは `cannot resolve <host>` で拒否されます。
+
+**解決方法**
+
+ホスト名、またはそのアドレスを含む CIDR を `REST_ALLOWED_HOSTS` に追加するか、それをブロックしているエントリを
+`REST_DENIED_HOSTS` から削除します。 [REST ヘルパーの接続先の制限](faq.html#restricting-rest-helper-destinations-allowdeny-lists) を参照してください。
+
+---
+
+## Authentication failed: Invalid credentials
+
+ログインページが、ユーザー名とパスワードを次のメッセージで拒否します。
+
+```
+Authentication failed: Invalid credentials
+```
+
+**原因**
+
+ユーザーが存在するかどうかを明かさないよう、ログインページはどの失敗にも同じ応答を返します。AnsibleForms は
+まずローカルユーザーを、次に LDAP を試します。ディレクトリが複数ある場合、ユーザー名は **アクセス > LDAP** の順序で検索されます。
+ただし、ディレクトリ（ `corp\jane` ）やそのサインインドメインのいずれか（ `jane@corp.example` ）を指定した場合は別です。本当の理由はログに出力されます。LDAP の
+失敗は `Error connecting to ldap: <reason>` としてログに出力され、理由には `Wrong binding credentials` や
+`Unable to verify the certificate` などがあります。Active Directory のコードは `Wrong password` 、 `User not found` 、
+`Account disabled` 、 `Account locked` 、 `Password expired` に変換されます。
+
+**解決方法**
+
+ログで理由を確認します。失敗したすべてのログインの完全な理由を得るには、
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) を `debug` に設定すると、 `Ldap authentication failed: <reason>` がログに出力されます。
+ローカルの管理者パスワードを紛失した場合は、 [管理者パスワードを紛失した場合](faq.html#recovering-a-lost-admin-password) を参照してください。
+
+---
+
+## LDAP check failed
+
+**アクセス > LDAP** で LDAP ディレクトリをテストすると、次のいずれかで失敗します。
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**原因**
+
+バインドユーザーまたはそのパスワードが間違っている、サーバーやポートに到達できない、あるいは TLS で、サーバーの証明書を
+CA バンドルで検証できません。7.3.0 以降、これらは **接続 > 認証情報** にあるディレクトリの ldap 認証情報に設定されています。存在しないテストユーザーでも、
+接続とバインドが成功していればテストは成功とみなされます。
+
+**解決方法**
+
+**接続 > 認証情報** で、ディレクトリが指定している認証情報（既定のディレクトリは `main` ）を開き、バインド
+DN とそのパスワード、サーバー、ポート（通常は 389、LDAPS では 636）を修正します。TLS の問題では、LDAP サーバーの証明書に署名した
+CA バンドルを貼り付けます。証明書のチェックを省略するのは本番環境向けではありません。 [LDAP](authentication/ldap.html) を参照してください。
+
+---
+
+## Azure AD または OIDC の認証に失敗する
+
+シングルサインオンのログインが、次のメッセージとともにログインページに戻ります。
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**原因**
+
+ID プロバイダーはユーザーを戻しましたが、AnsibleForms がログインを完了できませんでした。よくある理由は
+`azuread login is not enabled` または `oidc login is not enabled` （プロバイダーがオフになっている）と、 `jwt expired` です。後者は、
+プロバイダーからの引き渡しが 5 分間しか有効でないためです。プロバイダーからのコールバック中に発生したエラーも、
+ログインページに表示され、ログに出力されます。
+
+**解決方法**
+
+**アクセス > SSO** でプロバイダーを有効にし、AnsibleForms が使うとおりのコールバック URL を ID プロバイダーに登録します。
+Entra ID では `https://<your host>/api/v2/auth/entraid/callback` （7.3.0 以降。 `azureadoauth2` も引き続き使えます）、
+OIDC では `https://<your host>/api/v2/auth/oidc/callback` です。7 より前、または 6.1.5 より前の
+`/api/v1/` を含むコールバック URL は更新する必要があります。更新しないと、ログインページがサインインもエラーもなしに再読み込みされます。引き渡しの期限が
+切れた場合は、ログインをやり直してください。
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+有効なパスワードを持つユーザーがログインできず、次のメッセージが表示されます。
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**原因**
+
+ユーザーのロールのいずれかで、ロールのオプション `allowLogin` が `false` に設定されています。ログには
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings` と出力されます。
+
+**解決方法**
+
+ロールから `allowLogin: false` を削除するか、ユーザーをそのロールから外します。 [ロール](config/roles.html) を参照してください。
+
+---
+
+## 再起動後または 1 日後にログアウトされる
+
+AnsibleForms の再起動後、または 1 日使った後に、すべてのユーザーがログインページに戻されます。
+
+**原因**
+
+[`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) が設定されていないと、起動のたびに
+新しい署名鍵が生成され、次のメッセージがログに出力されます。
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+その結果、再起動前のトークンは
+受け付けられなくなります。これとは別に、セッションはリフレッシュトークンの期限が切れると終了します
+（ `Refresh token is expired` ）。期限は
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) で、既定は 24 時間です。
+
+**解決方法**
+
+`ACCESS_TOKEN_SECRET` に固定の秘密の値を設定します。1 日では短すぎる場合は `ACCESS_TOKEN_REFRESH_EXPIRATION` を大きくします。
+長期間の API アクセスには [API トークン](profile/api-token.html) を使ってください。
+
+---
+
+## シングルサインオン後にフォームとジョブが空になる（HTTP 431）
+
+ユーザーは Entra ID または OIDC でエラーなくサインインできますが、フォームとジョブのページが空のままです。ブラウザーのネットワーク
+タブでは、API の呼び出しが次の応答を返しています。
+
+```
+431 Request Header Fields Too Large
+```
+
+サーバーログにはこれらの呼び出しについて何も出力されず、同じユーザーでも LDAP やローカルのアカウントなら問題なく使えることがあります。
+
+**原因**
+
+7.1.0 より前は、サインインのトークンにユーザーのすべてのグループが含まれ、Entra ID のグループはオブジェクト ID と
+名前で 2 回含まれていました。ブラウザーはこのトークンをすべてのリクエストの `Authorization` ヘッダーで送るため、100 前後
+以上のグループに属するユーザーでは、ヘッダーが 16 KB を大きく超えます。Node.js は 16 KB を超えるリクエストヘッダーを、リクエストが
+AnsibleForms に届く前に 431 で拒否するため、何もログに出力されません。前段のリバースプロキシは、さらに早い段階でリクエストを拒否することがあります。
+Nginx の既定ではヘッダーフィールドあたり 8 KB までで
+（ `large_client_header_buffers 4 8k` ）、代わりに 400 を返します。
+
+**解決方法**
+
+7.1.0 以降にアップグレードします。サインインのトークンにグループが含まれなくなるため、そのサイズはユーザーが属するグループの数に
+左右されなくなります。また、リクエストが 431 で拒否されたときは、空のページを表示する代わりにインターフェースがそう伝えます。
+アップグレードできるまでは、次のどちらかを行います。
+
+* **アクセス > SSO** でプロバイダーに **グループフィルター** を設定します。これはロールが使うグループだけを残す正規表現です。
+  [Entra ID](authentication/entra-id.html) または [OIDC](authentication/oidc.html) を参照してください。ユーザーはもう一度サインインして
+  小さなトークンを取得します
+* または、環境変数 `NODE_OPTIONS=--max-http-header-size=65536` で Node.js の上限を引き上げ、
+  AnsibleForms を再起動します
+
+7.1.0 以降は、 [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) で同じ上限を設定できます。既定は 16384
+バイトで、起動時に読み取られます。前段のシングルサインオンゲートウェイが設定する大きなクッキーなど、ほかの大きなヘッダーにも使えます。
+プロキシのヘッダーの上限も引き上げてください。 [リクエストヘッダーのサイズ](production/reverse-proxy.html#request-header-size) を参照してください。
+
+---
+
+## Playbook failed with status
+
+Ansible のジョブが失敗で終わり、その出力の最後の行が次のようになります。
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**原因**
+
+`ansible-playbook` が 0 以外のコードで終了しました。その上の行に Ansible 自身のエラーがあります。プレイブックが
+見つからなかった、ホストに到達できなかった、タスクが失敗した、インベントリが間違っている、などです。プレイブックは
+**playbook に使用しますか?** を有効にしたリポジトリ、または [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) で探されます。
+ログの行 `Running from directory : <path>` で、使われたフォルダーがわかります。
+
+**解決方法**
+
+最後の行より上のジョブの出力を読みます。プレイブックが見つからない場合は、フォームの `playbook` を
+`Running from directory` のフォルダーと照らし合わせます。 [Ansible フォーム](forms/ansible.html) を参照してください。
+
+---
+
+## Playbook was aborted by the main process
+
+Ansible のジョブが次のメッセージで失敗します。
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**原因**
+
+RTE 上の `ansible-playbook` プロセスがシグナルで終了しましたが、誰もジョブを中止していません。7.0.0 以降、
+出力のサイズが原因になることはなくなりました。 [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) （既定はストリームあたり 50 MB）を
+超えると残りの出力は保存されず、ジョブに
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on` と表示され、
+プレイブックは最後まで実行されます。現在よくある原因はメモリです。RTE のコンテナーがメモリの上限に達し、
+カーネルがプレイブックを強制終了したもので、たとえばフォークが多い場合や facts が大きい場合に起きます。
+
+**解決方法**
+
+プレイブックの実行中に RTE のコンテナーのメモリを確認し（ `docker stats` 、 `kubectl top pod` ）、上限を引き上げるか、
+プレイブックのメモリ使用量を減らします（ `forks` を減らす、不要な facts の収集をしない）。 `PROCESS_MAX_BUFFER` の警告だけが出ていて
+出力全体が必要な場合は、RTE のコンテナーの環境で `PROCESS_MAX_BUFFER` を引き上げます。これを読み取るのはアプリではなく RTE です。
+---
+
+## Failed to launch awx template
+
+AWX のジョブが失敗で終わり、出力が次のように始まります。
+
+```
+failed to launch awx template <name>
+```
+
+**原因**
+
+次の行に理由が示されます。 `Request failed with status code 401` は、AWX ランナーの認証情報にあるトークン、またはユーザー名とパスワードが
+拒否されたことを意味します。 `could not find job template <name>` は、その名前と完全に一致するジョブテンプレートもワークフロージョブテンプレートも
+ない、または接続のユーザーがそれを見られないことを意味します。 `unable to verify the first certificate` のような証明書のエラーは、
+AWX の証明書が信頼されていないことを意味します。
+
+**解決方法**
+
+ランナー（ **接続 > ランナー** ）の **接続テスト** を使います。正常であれば `Runner connection is OK` と応答します。7.3.0 以降、
+トークンまたはユーザーとパスワード、アドレス、 **CA バンドル** は、 **接続 > 認証情報** にあるランナーの認証情報に設定されています。
+トークンやパスワードはそこで更新し、証明書のエラーではその **CA バンドル** に CA を貼り付けてください。
+テンプレートの名前と権限を確認します。アドレスは `/api/v2` を付けずに入力してください。AnsibleForms が
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX) を自動で付け加えます。
+[AWX フォーム](forms/awx.html) を参照してください。
+
+---
+
+## ジョブのステータスが abandoned になる
+
+実行中だったジョブが `abandoned` とマークされ、ノードまたは RTE のログに次のいずれかが出力されます。
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+非推奨のデータベースモードの RTE は、独自のメッセージを出力します。
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**原因**
+
+ジョブは、それを実行または追跡するコンテナーに属します。プレイブックはその RTE に、それ以外のジョブ（AWX のジョブ、マルチステップ
+フォームのステップ）はそれを開始したアプリノードに属します。そのコンテナーが再起動すると、自分の未完了のジョブを終了させます。たとえば Pod が
+置き換えられてコンテナーがなくなった場合は、2 分間応答がなければワーカーがそのジョブを終了させます。ソケットモードの RTE が、実行中だったジョブを持たずに
+戻ってきた場合（たとえばスプールのない新しいコンテナー）は、そのジョブは abandoned で終わります。停止する RTE は、まず
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) の間、プレイブックの終了を待ちます。また 1 時間ごとに、
+1 日以上実行中のままのジョブも abandoned とマークされます。
+
+7.3.0 以降、AWX、AAP、Ascender 上のジョブはそのランナーで続行されます。再起動でジョブが放棄された直後に、それが過去 24 時間以内に開始されたものであれば
+ノードがもう一度追跡し、ジョブはそこで実際に起きた結果で終わります。その場合、ログには `Following <n> abandoned job(s) again on their runner` と出力されます。
+
+**解決方法**
+
+プレイブックのジョブを再起動します。RTE やアプリノードの再起動やアップグレードはジョブが実行されていないときに行い、停止する RTE には十分な時間を
+与えてください（ [スケーリング](rte/run.html) を参照）。プレイブックは途中まで実行されている可能性があるため、再起動する前に、管理対象ホストで
+本当に完了したかどうかを確認してください。
+
+---
+
+## RTE が接続しない
+
+RTE ランナー（ **接続 > ランナー** ）の **接続テスト** が、次のメッセージで失敗します。
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**原因**
+
+ソケットモードの RTE は、1 本の WebSocket でアプリと通信します。アウトバウンドでは RTE がアプリに接続し、インバウンドではアプリが RTE に接続します（
+[モード](rte/modes.html) を参照）。ソケットが開かない理由は、アプリと RTE のログに出力されます。
+
+| メッセージ | 出力される場所 | 意味 |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | RTE（インバウンド） | ランナーの RTE 認証情報のトークンが、RTE の `RTE_TOKEN` と一致しない |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | アプリ（インバウンド） | 同じことをアプリ側から見たもの |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | アプリと、拒否された RTE（ `401` ） | RTE が、アプリがそのランナー用に保持しているものとは別のトークンでサインインしている |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | RTE（アウトバウンド） | 参加を求めて承認を待っている |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | RTE（インバウンド、 `APP_URL` あり） | インバウンドの RTE で同じ状況 |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | アプリと、拒否された RTE（ `409` ） | 設定シードがランナーを `rte_mode` なし、つまりデータベースモードで宣言しており、そのモードはシードが決める。インバウンドの RTE には `rte_mode: inbound` と `(and its credential with the address the app dials, RTE_URL)` が表示される |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | RTE | 自分自身を登録するインバウンドの RTE には、アプリが接続するアドレスが必要 |
+| `Runner '<name>': dialing <address>: <reason>` | アプリ（ `debug` レベル） | アプリがソケットを開けない。たとえば RTE の証明書が、そのランナーにピン留めされたものと違う |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | RTE | データベースモードで動いており、ソケットをまったく開かない |
+
+**解決方法**
+
+* **トークンが拒否される** : RTE に、そのランナーの RTE 認証情報（ **接続 > 認証情報** ）のトークンを与えます。またはその逆を行います
+* **承認待ち** : **接続 > ランナー** で、そこに表示されるフィンガープリントがログのものと同じであることを確認してから承認します
+  （ [RTE の承認](runners/registration.html#approving-an-rte) を参照）
+* **データベースモードの設定シードで管理されている** : シードのランナーに、RTE の認証情報（インバウンドの場合はそのアドレス付き）とともに
+  `rte_mode` を設定し、RTE を再起動します
+* **`RTE_URL` のないインバウンド** : `RTE_URL` にアプリが RTE に到達するアドレスを設定するか、 `APP_URL` を外して、ランナーを
+  シードまたは **接続 > ランナー** で宣言します
+* **ピン留めされたものと違う証明書** : HTTPS のインバウンドの RTE は登録時に証明書を送り、アプリはその証明書でのみ
+  接続します。証明書を新しくすると、RTE は登録時にもう一度それを送ります。認証情報の CA バンドルが手動で設定されていた場合、
+  アプリはそれを維持し、次のログを出力します。
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **[DEPRECATED] の警告** : RTE に `RTE_MODE` を設定し、その環境から `DB_*` を削除して、ランナーをそのモードに設定します（
+  [モード](rte/modes.html) を参照）
+
+---
+
+## The form data is not valid
+
+起動時の検証が `enforce` のとき、起動が `422` と次のメッセージで拒否されます。
+
+```
+The form data is not valid
+```
+
+**原因**
+
+サーバーがフィールドの値をフォームのルールに照らしてチェックし、欠けているフィールドや無効なフィールドを見つけました。それらは応答の
+`details` に列挙されます。 `rawFormData` のない起動も拒否されます。ウィザードなど、まだチェックできないフォームは
+`Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>` で拒否されます。
+
+**解決方法**
+
+詳細に示されたフィールドを修正するか、ルールが厳しすぎる場合はフォームのルールを修正します。まず `log` で実行してください。
+何も拒否せずに `Launch validation would refuse form '<name>' ...` をログに出力します。
+[enforce の動作](launch-validation/log-and-enforce.html#what-enforce-does) と
+[段階的な導入](launch-validation/rolling-it-out.html) を参照してください。
+
+---
+
+## リポジトリのクローンまたは pull に失敗する
+
+リポジトリのステータスが失敗を示し、その出力に git のエラーが含まれるか、ログに
+`Background clone of '<name>' failed : <reason>` と出力されます。
+
+**原因**
+
+Git がリモートに到達できないか、認証できませんでした。SSH の URL（ `git@host:path` ）では、リモートが AnsibleForms の
+公開鍵を受け入れる必要があります。HTTPS では、ユーザー名とトークンが有効である必要があります。作業ツリーに変更がある場合も
+pull は拒否され、次のメッセージが出ます。
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**解決方法**
+
+SSH の場合は、 **接続 > SSH** の **キー** タブから公開鍵をコピーし、デプロイキーとして、またはリポジトリにアクセスできるユーザーに
+追加します。AnsibleForms はクローン時にリモートホストを既知のホストに追加します。それ以外のホストには、同じページの
+**既知のホスト** タブを使います。
+HTTPS の場合は、トークンを更新します。 [Git リポジトリ](gui/designer-and-git.html#git-repositories) と
+[リポジトリについて](faq.html#about-repositories) を参照してください。
+
+---
+
+## フォームリポジトリがまだクローンされていない
+
+デザイナーでのフォームの保存が、次のエラーで失敗します。
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**原因**
+
+**フォームに使用しますか?** を有効にしたリポジトリに、まだ作業ツリーがありません。クローンが実行されていないか、失敗しています。
+
+**解決方法**
+
+リポジトリの設定からリポジトリをクローンします。クローンに失敗する場合は、
+[リポジトリのクローンまたは pull に失敗する](#a-repository-clone-or-pull-failed) を参照してください。
+
+---
+
+## バックアップに失敗する
+
+バックアップが失敗し、バックアップの一覧に何も追加されません。理由は次のいずれかです。
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**原因**
+
+ダンプのコマンド [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND) がインストールされていない、
+接続に失敗した、または空のファイルを生成しました。大きなデータベースでは、
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) （既定は 1 時間）より長くかかることもあります。
+失敗したバックアップはフォルダーを残しません。ログには `Backup failed, removing the incomplete folder '<folder>' : <reason>` と出力されます。
+
+**解決方法**
+
+MySQL または MariaDB のクライアントツールをインストールするか、 `MYSQLDUMP_COMMAND` （復元には `MYSQL_COMMAND` も）を、
+このホストで、サーバーのバージョンに対して動作するコマンドに設定します。大きなデータベースでは `BACKUP_COMMAND_TIMEOUT_SECONDS` を引き上げます。
+[バックアップ](gui/administration.html#backups) を参照してください。
diff --git a/i18n/ja/_security_assessment/security-assessment/advisories.md b/i18n/ja/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..9712789
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: セキュリティアドバイザリ
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# セキュリティアドバイザリ
+{: .no_toc }
+
+公開されたすべての脆弱性と、その深刻度および修正
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 公開済みのアドバイザリ
+
+このサイトのビルドのたびに、 [リポジトリの Security タブ](https://github.com/ansibleforms/ansibleforms/security/advisories) から読み込んでいます。
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>アドバイザリ</th>
+      <th>深刻度</th>
+      <th>脆弱性の種類</th>
+      <th>影響を受けるバージョン</th>
+      <th>修正バージョン</th>
+      <th>公開日</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+公開されたアドバイザリはありません。
+{% endif %}
+
+GitHub の各アドバイザリに、影響、条件、CVSS ベクトル、修正の詳細が記載されています。
+
+---
+
+## ご利用のバージョンへの影響
+
+アドバイザリには、影響を受けるバージョンと、最初に修正されたバージョンが記載されています。修正はサポート対象のリリース
+( [7.x と 6.5.x](development.html#supported-versions) ) で提供され、それより古いリリースにはパッチは適用されません。アップグレードが対策になります。
+
+インスタンスのバージョン (ヘルプメニューの **バージョン情報** 、または `GET /api/v2/version` ) を **影響を受けるバージョン** と比較してください。
+
+---
+
+## 新しいアドバイザリの通知を受け取る
+
+アドバイザリが公開されると、GitHub はリポジトリをウォッチしているユーザーに通知します。
+
+* [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) で **Watch > Custom > Security alerts** を選びます。
+* [変更履歴](../changelog.html) には、すべてのセキュリティ修正が、それを含むリリースの下に記載されています。
diff --git a/i18n/ja/_security_assessment/security-assessment/development.md b/i18n/ja/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..c441e9f
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: セキュアな開発
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# セキュアな開発
+{: .no_toc }
+
+変更のチェックとリリースの方法、およびサポート対象
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ソースコード
+
+AnsibleForms はオープンソースなので、このページの内容はすべてリポジトリ自体で確認できます。
+
+* コード、その履歴、ビルドパイプラインは [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) で公開されています。
+* [ライセンス](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) は GPL-3.0 です。
+* [変更履歴](../changelog.html) には、セキュリティ修正を含め、すべてのリリースのすべての変更が記載されています。
+
+---
+
+## 変更のマージ方法
+
+すべての変更は、誰も回避できないルールセットのもとで、プルリクエストを通じて `main` に入ります。
+
+| ルール | 意味 |
+|---|---|
+| プルリクエストが必須 | `main` に直接プッシュされるものはありません |
+| 必須のチェック | プルリクエストは、下記のすべてのチェックに合格した場合にだけマージされます |
+| 強制プッシュと削除の禁止 | `main` の履歴を書き換えたり削除したりすることはできません |
+| 直線的な履歴 | 各プルリクエストは 1 つのコミットになるため、変更を個別に追跡し、元に戻せます |
+
+プルリクエストが合格しなければならないチェック:
+
+| チェック | 内容 |
+|---|---|
+| Client、Server | Web インターフェイスとサーバーの単体テスト |
+| CodeQL | GitHub による JavaScript と TypeScript のコードの静的解析。インジェクション、クロスサイトスクリプティング、その他の脆弱性を検出します |
+| Public schema is up to date | コードが想定するデータベーススキーマと、同梱されているスキーマが一致すること |
+| Title、Branch | プルリクエストが命名規則に従っていること。これにより変更履歴が正確に保たれます |
+
+さらに 2 つのチェックがすべてのプルリクエストで実行され、結果を報告します。
+
+* **Database** は MySQL と MariaDB でサーバーをテストし、 **Browser** はブラウザーでインターフェイスを操作します。
+* **Dependency review** は、深刻度が高いまたは重大な既知の脆弱性を持つ新しい依存関係をブロックします。
+
+---
+
+## コード分析と依存関係
+
+コードとその依存関係は、マージ後にも再度チェックされます。
+
+* **CodeQL** は、 `main` とリリースブランチへのすべてのプッシュも分析し、毎週コードベース全体も分析します。
+  そのため、新しい CodeQL のルールは、それ以前にマージされたコードもチェックします。
+* **Dependabot** は、依存関係の新しいバージョンごとにプルリクエストを作成します。サーバーとインターフェイスの npm パッケージ、
+  ランタイム環境の Python パッケージ、パイプラインの GitHub Actions は毎週、
+  コンテナーのベースイメージは毎日です。
+* ベースイメージはダイジェストで固定されている ( `node:26-trixie-slim@sha256:...` ) ため、ビルドではレビュー済みのイメージがそのまま使われます。
+  アップストリームでイメージが再ビルドされると、Dependabot がダイジェストを更新します。
+
+---
+
+## リリースとイメージ
+
+リリースのビルドと公開は GitHub Actions だけで行われ、開発者のマシンから行われることはありません。
+
+* リリースは `main` (または `release/6.x` ) から作成され、変更履歴はそのプルリクエストから生成されます。
+* イメージは [Publish ワークフロー](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml) でビルドされ、
+  GitHub Container Registry の `ghcr.io/ansibleforms/ansibleforms` に、ランタイム環境のイメージとともに
+  プッシュされます。ワークフローとそのログは公開されているため、誰でもイメージに何が含まれたかを確認できます。
+* アプリケーションとランタイム環境のイメージは、root ではなく、特権を持たない `node` ユーザー (uid 1000) として実行されます。
+
+---
+
+## サポート対象のバージョン
+
+セキュリティ修正は、サポート対象の各系列の最新リリースに含まれます。
+
+| バージョン | セキュリティ修正の提供 |
+|---|---|
+| 7.x | あり |
+| 6.5.x | あり |
+| 6.5 より前 | なし。アップグレードが対策になります |
+
+新しいリリースへの移行については [アップグレードガイド](../upgrading/) を、6.5 からの移行については [v7 へのアップグレード](../upgrade-7.html) を参照してください。
diff --git a/i18n/ja/_security_assessment/security-assessment/faq.md b/i18n/ja/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..055a4ad
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: 評価に関する FAQ
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# 評価に関する FAQ
+{: .no_toc }
+
+セキュリティ質問票でよく聞かれる質問への簡潔な回答
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## データとホスティング
+
+データの保存場所と、誰がアクセスできるか:
+
+| 質問 | 回答 |
+|---|---|
+| データはどこに保存されますか? | お客様が運用する MySQL または MariaDB のデータベースと、インスタンスの永続フォルダーです。AnsibleForms はセルフホスト型で、背後にクラウドサービスはありません。 |
+| 開発者にデータを送信しますか? | いいえ。テレメトリ、使用状況の報告、更新チェックはありません。 |
+| 何に接続しますか? | 管理者が設定したシステムだけです。 [外部への接続](measures.html#outbound-connections) を参照してください。 |
+| AI を使用したり、モデルプロバイダーにデータを送信したりしますか? | [チャットアシスタント](../chat/) を有効にした場合だけです (既定では無効)。その場合、フォームの定義と入力中の値を、設定したプロバイダーに送信します。 |
+| インターネットに接続せずに実行できますか? | はい。アプリケーションにインターネット接続は不要です。playbook には、そのタスクがアクセスする先への接続が必要です。 |
+
+---
+
+## 暗号化
+
+何が、どの鍵で暗号化されるか:
+
+| 質問 | 回答 |
+|---|---|
+| 通信中のデータは暗号化されますか? | アプリケーションまたはリバースプロキシが提供する [HTTPS](../security/https.html) と、アプリケーションとランタイム環境の間の `wss://` で暗号化されます。 |
+| 保存データは暗号化されますか? | 保存されるシークレットはすべて、アプリケーションによって AES-256 で暗号化されます。ジョブとその出力はそのまま保存されるため、データベース自体の保存時暗号化を使用してください。 [保存されたシークレット](measures.html#stored-secrets) を参照してください。 |
+| 鍵は誰が保持しますか? | お客様です。 [`ENCRYPTION_SECRET`](../security/secrets.html) はお客様が設定し、バックアップには含まれず、ローテーションできます。 |
+| シークレットを自社の Vault に置いたままにできますか? | はい。 [HashiCorp Vault と CyberArk](../secret-stores/) は、ジョブが必要とするときに読み取られます。 |
+
+---
+
+## アクセスと説明責任
+
+誰がサインインでき、何ができ、何が記録されるか:
+
+| 質問 | 回答 |
+|---|---|
+| シングルサインオンに対応していますか? | はい。LDAP / Active Directory、OpenID Connect、Entra ID に対応しています。 [認証](../authentication/) を参照してください。 |
+| 多要素認証に対応していますか? | シングルサインオンを通じて対応しており、ID プロバイダーの MFA が適用されます。ローカルアカウントには独自の MFA はありません。 |
+| 権限はどのように管理されますか? | グループに対応付けたロールで管理し、サーバーがリクエストごとにチェックします。 [権限](measures.html#permissions) を参照してください。 |
+| 監査ログはありますか? | はい。すべての変更と拒否されたすべての試行が記録され、既定で 365 日間保持され、syslog に転送できます。 [監査証跡](measures.html#audit-trail) を参照してください。 |
+| 既定のパスワードはありますか? | 最初の管理者アカウントには公開されている既定のパスワードがあり、初回サインイン時に変更する必要があります。 [管理者アカウント](../security/hardening.html#the-admin-account) を参照してください。 |
+
+---
+
+## 脆弱性と更新
+
+問題の発見、修正、告知の方法:
+
+| 質問 | 回答 |
+|---|---|
+| 脆弱性は見つかっていますか? | はい。公開されたものはすべて、修正されたバージョンとともに [セキュリティアドバイザリ](advisories.html) に記載されています。 |
+| 脆弱性はどのように報告すればよいですか? | GitHub を通じて非公開で報告してください。 [脆弱性の報告](reporting.html) を参照してください。 |
+| コードはどのようにチェックされていますか? | すべてのプルリクエストでの CodeQL による静的解析と依存関係のレビュー、自動テスト、Dependabot による更新です。 [セキュアな開発](development.html) を参照してください。 |
+| どのバージョンにセキュリティ修正が提供されますか? | 7.x と 6.5.x です。 [サポート対象のバージョン](development.html#supported-versions) を参照してください。 |
+| 新しいアドバイザリはどうすれば知ることができますか? | GitHub でリポジトリのセキュリティアラートをウォッチしてください。 [新しいアドバイザリの通知を受け取る](advisories.html#being-told-of-new-advisories) を参照してください。 |
+| ペネトレーションテストは実施されていますか? | 第三者によるペネトレーションテストの報告書は公開されていません。コードは公開されているため、自社のチームやテスターが評価でき、発見事項は上記の方法で報告できます。 |
+
+---
+
+## イメージとサプライチェーン
+
+イメージの入手元と、その確認方法:
+
+| 質問 | 回答 |
+|---|---|
+| イメージはどこで公開されていますか? | GitHub Container Registry の `ghcr.io/ansibleforms/ansibleforms` で、公開されている GitHub Actions のワークフローでビルドされています。 [リリースとイメージ](development.html#releases-and-images) を参照してください。 |
+| コンテナーは root で実行されますか? | いいえ。特権を持たない `node` ユーザーとして実行されます。 |
+| イメージは署名されていますか? | まだです。レビューしたイメージを確実に実行するには、ダイジェスト ( `@sha256:...` ) を指定してプルしてください。 |
+| SBOM はありますか? | イメージとともに公開されているものはまだありません。Trivy や Syft などのスキャナーで、イメージから作成できます。 |
+| イメージの脆弱性スキャンは行われていますか? | リリースパイプラインでは行われていません。ベースイメージはダイジェストで固定され、Dependabot によって最新に保たれています。独自のポリシーを適用するには、自社のレジストリでイメージをスキャンしてください。 |
+| ライセンスは何ですか? | GPL-3.0 で、オープンソース、無保証です。 |
diff --git a/i18n/ja/_security_assessment/security-assessment/index.md b/i18n/ja/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..f2a7549
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: 概要
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# セキュリティ評価
+{: .no_toc }
+
+セキュリティレビュー向け: 対策、開発、アドバイザリ
+{: .fs-6 .fw-300 }
+
+---
+
+## 要約
+
+AnsibleForms は playbook を実行し、その認証情報を保持するため、信頼の連鎖の一部になります。
+
+* **セルフホスト型** です。お使いのインフラストラクチャ上で動作し、データはお使いのデータベースに保存され、開発者には何も送信しません。
+* **オープンソース** (GPL-3.0) です。コード、パイプライン、すべてのアドバイザリが公開されています。
+* 保存されるシークレットはすべて **暗号化** され、すべての変更は **監査** され、リクエストごとに **ロール** がチェックされます。
+* 脆弱性は **非公開で報告** され、サポート対象のすべてのリリースで修正され、 **公開** されます。
+
+---
+
+## このセクションの内容
+
+各ページでは、設計から CVE の一覧まで、セキュリティレビューで問われる質問に答えています。
+
+| ページ | 内容 |
+|---|---|
+| [セキュリティ対策](measures.html) | サインイン、権限、保存されたシークレット、監査証跡、ブラウザー、サーバー、接続、コンテナー |
+| [セキュアな開発](development.html) | 変更のレビューとテストの方法、コードと依存関係の分析、イメージのビルド方法、サポート対象のバージョン |
+| [脆弱性の報告](reporting.html) | 問題を非公開で報告する方法と、その後の流れ |
+| [セキュリティアドバイザリ](advisories.html) | 公開されたすべての脆弱性と、その CVE、深刻度、修正バージョン |
+| [評価に関する FAQ](faq.html) | セキュリティ質問票でよく聞かれる質問への簡潔な回答 |
+
+インスタンスを評価するのではなく保護したい場合は、管理者ガイドの [セキュリティ](../security/) を参照してください。
diff --git a/i18n/ja/_security_assessment/security-assessment/measures.md b/i18n/ja/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..a2f2e19
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: セキュリティ対策
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# セキュリティ対策
+{: .no_toc }
+
+サインイン、権限、シークレット、接続の保護方法
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 実行場所
+
+AnsibleForms はセルフホスト型で、お客様のインフラストラクチャ上で動作し、データはお客様が運用するデータベースに保存されます。
+
+* AnsibleForms のクラウドサービスやライセンスサーバーはなく、テレメトリや更新チェックもありません。
+* インターフェイスはアプリケーション自体が提供し、ほかのサイトから何も読み込みません。
+* アプリケーションが接続するのは、管理者が設定したシステムだけです。一覧は [外部への接続](#outbound-connections) にあります。
+
+構成要素と、それぞれが保持するもの:
+
+| 構成要素 | 役割 | 保持するもの |
+|---|---|---|
+| アプリケーション | Web インターフェイス、REST API、スケジューラー | 独自のデータはありません。すべてデータベースにあります |
+| MySQL または MariaDB | アプリケーションのデータベース | ユーザー、グループ、認証情報 (暗号化済み)、extravars と出力を含むジョブ、監査ログ |
+| ランタイム環境 (RTE) | 専用のコンテナーで playbook を実行します | 実行するジョブのファイルと、そのジョブの実行中だけ保持するシークレット |
+| 永続フォルダー | 設定、フォーム、playbook、アップロード | フォームと playbook が使うファイル |
+
+全体像は [動作のしくみ](../how-it-works.html) を、ランタイム環境については [RTE](../rte/) を参照してください。
+
+---
+
+## サインイン
+
+データを読み取ったり変更したりするページと API 呼び出しには、すべてサインインしたユーザーが必要です。サインインなしで利用できる数少ないエンドポイントは、
+サインイン自体、バージョン、インスタンスの名前とロゴ、API ドキュメント、初回起動時のデータベースセットアップを提供するもので、
+最後のものは [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` で閉じられます。
+
+| 方式 | しくみ |
+|---|---|
+| ローカルアカウント | パスワードは bcrypt でハッシュ化され、 [最小の長さ](../security/hardening.html#sign-in-limits-and-passwords) があり、公開されている既定の管理者パスワードは初回サインイン時に変更する必要があります |
+| LDAP / Active Directory | ディレクトリがパスワードをチェックし、そのグループがロールに対応付けられます。 [LDAP](../authentication/ldap.html) を参照してください |
+| OpenID Connect、Entra ID | ID プロバイダーを通じたシングルサインオンで、プロバイダー独自の多要素認証も利用できます。 [認証](../authentication/) を参照してください |
+
+* サインインに失敗すると [アカウントがロック](../security/hardening.html#sign-in-limits-and-passwords) され、サインインにはレート制限があります。
+* サインインすると、30 分間有効な署名付きアクセストークンと、24 時間有効なリフレッシュトークンが返されます。
+* トークンは有効期限前に終了させられます。サインアウト、パスワードの変更、ユーザーのブロック、API トークンの取り消しによって、
+  すべてのノードで同時に終了します。 [トークン](../security/secrets.html#tokens) を参照してください。
+* AnsibleForms には独自の多要素認証はありません。必要な場合はシングルサインオンを使用してください。
+
+---
+
+## 権限
+
+ユーザーができることは所属グループのロールで決まり、サーバーがリクエストごとにチェックします。
+
+* ロールは [config.yaml](../config/roles.html) で定義します。ユーザーに表示されるフォームと、デザイナー、設定ページ、
+  ほかのユーザーのジョブなど、ユーザーが持つオプションを決めます。
+* サーバーは、REST API を通じた起動も含め、すべての起動をフォームのルール (フィールド、その値、ユーザーのアクセス権) に照らしてチェックします。
+  [起動時の検証](../launch-validation/) を参照してください。
+* 管理者ロールは、設計上どの playbook でも実行できます。ほかのロールには付与されたものだけが与えられます。複数のロールを持つユーザーは、
+  どのロールもそのオプションを拒否していない場合にだけ、そのオプションを得ます。そのため、制限的なロールが 1 つあれば、そのオプションを差し止められます。
+
+---
+
+## 保存されたシークレット
+
+パスワード、トークン、鍵は、データベースに書き込まれる前に暗号化されます。
+
+* 認証情報、LDAP のバインドパスワード、ランナーのトークン、シングルサインオンのクライアントシークレット、Webhook の
+  アドレス、API キーなど、保存されるシークレットはすべて、お客様が設定した [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) のもとで、
+  値ごとにランダムな初期化ベクトルを使って AES-256 で暗号化されます。
+* 保存されたシークレットを表示する API 呼び出しや設定ページはなく、バックアップにはマスターシークレットが含まれません。
+* シークレットを自社の Vault に置いたままにできます。 [HashiCorp Vault と CyberArk](../secret-stores/) は、ジョブが必要とするときに読み取られます。
+* ジョブのシークレットは、そのトークンから導出した鍵を使って AES-256-GCM で封をされた状態でランタイム環境に届きます。
+* 名前がシークレットのように見える extravars はジョブの表示でマスクされ、パスワードフィールドは常にマスクされます。 [ジョブのデータ](../security/hardening.html#job-data) を参照してください。
+
+データベースのそれ以外の部分 (ジョブ、その extravars と出力) はそのまま保存されます。データベース自体の保存時暗号化と
+アクセス制御で保護してください。 [データベース](../security/hardening.html#the-database) を参照してください。
+
+---
+
+## 監査証跡
+
+すべての変更と、拒否されたすべての試行が記録されます。
+
+* インターフェイスまたは API を通じた作成、変更、削除は、それぞれユーザー、そのアドレス、操作、対象、結果とともに
+  監査ログに書き込まれます。拒否とサインインも、失敗したものを含めて記録されます。
+* シークレットのように見える値は、書き込まれる前に伏せられます。
+* ログは既定で 365 日間保持され、UDP、TCP、TLS で syslog にコピーできます。
+
+---
+
+## ブラウザー側
+
+インターフェイスは、ページに注入されたコードから保護されています。
+
+* [Content-Security-Policy](../security/hardening.html#the-content-security-policy) により、アプリケーション自身のスクリプトとフレームだけが許可されます。
+* すべての応答には保護用のヘッダーが付きます: nosniff、フレーム保護、HTTPS での HSTS です。
+* フォーム、ヘルプテキスト、チャットの回答の HTML はサニタイズされ、ジョブの出力はエスケープされます。
+
+---
+
+## サーバー側
+
+ユーザーの入力を扱うコードは、典型的なインジェクションを回避しています。
+
+* データベースクエリは、値をクエリに連結したテキストとしてではなく、常にパラメーターとして渡します。
+* git を含むコマンドは、シェルではなく引数リストから実行されるため、シェルの特殊文字は効果を持ちません。
+* サーバー式は [式のサニタイザー](../security/hardening.html#expressions-and-outbound-calls) を通り、その REST 呼び出しはホストフィルターを通ります。
+* [MCP サーバー](../mcp/)、 [チャットアシスタント](../chat/)、メトリクスのエンドポイントは、有効にするまでオフです。
+
+---
+
+## 接続
+
+AnsibleForms との間の通信は、エンドツーエンドで暗号化できます。
+
+* アプリケーションは自身で [HTTPS](../security/https.html) を提供するか、リバースプロキシの背後に置かれます。
+* ランタイム環境は WebSocket (HTTPS のアドレスでは `wss://` ) でアプリケーションと通信し、アプリケーションは
+  インバウンドの RTE の証明書をピン留めします。 [RTE のモード](../rte/modes.html) を参照してください。
+* LDAP、シングルサインオン、ランナー、git、シークレットストア、式の REST 呼び出しは、接続先サーバーの証明書を
+  チェックします。ただし、自己署名証明書を使うサーバーに対して管理者がチェックをオフにした場合は除きます。
+
+### 外部への接続
+
+AnsibleForms が接続するのは、管理者が設定したものだけです。
+
+| 接続先 | 接続するとき |
+|---|---|
+| LDAP、OpenID Connect、Entra ID (Microsoft のログインと Graph) | そのサインイン方式が設定されているとき |
+| AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins | フォームがそのランナーで実行されるとき |
+| Git サーバー | リポジトリが設定されているとき |
+| メールサーバー、Slack、Teams、Telegram、Webhook | 通知チャネルが設定されているとき |
+| HashiCorp Vault、CyberArk | シークレットストアが設定されているとき |
+| モデルプロバイダー (Anthropic、OpenAI など) | [チャットアシスタント](../chat/) を有効にした場合のみ (既定では無効) |
+| フォームで指定されたホストと API | フォームの式や playbook がそれらを呼び出すとき |
+| Syslog サーバー | 監査ログやログの転送が設定されているとき |
+
+---
+
+## コンテナー
+
+イメージは、できるだけ少ない権限で実行されるようにビルドされています。
+
+* アプリケーションとランタイム環境は、root ではなく、特権を持たない `node` ユーザーとして実行されます。
+* ダイジェストで固定された軽量な Debian イメージをベースにビルドされています。 [セキュアな開発](development.html#code-analysis-and-dependencies) を参照してください。
+* アプリケーションが待ち受けるポートは 8000 の 1 つだけです。
+
+新しいインスタンスを保護する手順については、 [ハードニング](../security/hardening.html) に従ってください。
diff --git a/i18n/ja/_security_assessment/security-assessment/reporting.md b/i18n/ja/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..8c2b90d
--- /dev/null
+++ b/i18n/ja/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: 脆弱性の報告
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# 脆弱性の報告
+{: .no_toc }
+
+セキュリティ問題を非公開で報告する方法と、その後の流れ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 非公開で報告する
+
+AnsibleForms は認証情報や Vault のトークンを保持しているため、セキュリティ問題を公開の issue で報告しないでください。
+
+1. **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)** を開きます。これはメンテナーだけが見られる非公開のアドバイザリです。
+2. そのページを利用できない場合は、セキュリティの報告があることだけを書いて非公開の連絡手段を求める通常の issue を作成してください。
+   詳細、再現手順、バージョン番号は書かないでください。メンテナーが非公開のアドバイザリを作成し、
+   そこに招待します。
+
+ポリシーの全文は、リポジトリの [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) にあります。
+
+---
+
+## 報告に含める内容
+
+次の情報が多く含まれているほど、修正が早くなります。
+
+* 攻撃者が得られるもの: ほかのユーザーのデータ、実行を許可されていない playbook、ホスト、または管理者権限。
+* バージョンとデプロイ方法: Docker、Kubernetes、またはネイティブインストール。
+* 再現手順、またはそれを引き起こすリクエスト。
+* サインインしたユーザーが必要かどうか、必要な場合はどの [ロールオプション](../config/roles.html) か。
+
+---
+
+## その後の流れ
+
+報告は、最初のメッセージから公開まで、同じ非公開のアドバイザリで扱われます。
+
+| ステップ | 受け取るもの |
+|---|---|
+| 受領確認 | 報告が届いたことと、再現できるかどうかの確認 |
+| 受理 | すべての [サポート対象のバージョン](development.html#supported-versions) の次のリリースでの修正と、報告者のクレジットを記載した公開アドバイザリ (名前を出したくない場合を除く) |
+| 却下 | その理由。通常は、その動作に報告者がすでに持っていた権限が必要だったというものです |
+
+修正がリリースされると、アドバイザリが公開され、 [セキュリティアドバイザリ](advisories.html) に表示されます。
+
+---
+
+## 対象範囲
+
+ポリシーは、ロールモデルと同じところに線を引いています。
+
+| 対象 | 対象外 |
+|---|---|
+| サインインしたユーザーが、ロールで付与された範囲を超えてアクセスできるもの | 管理者アカウントがすでに侵害されていることを前提とする発見事項。管理者がどの playbook でも実行できるのは製品の仕様です |
+| サインインせずにアクセスできるもの | 影響が実証されていないスキャナーの報告 |
+| 保存された認証情報が読み取れる状態になる、またはログに書き込まれること | |
+| シェル、データベース、ブラウザーへのインジェクション | |
diff --git a/i18n/ja/_use/designer/index.md b/i18n/ja/_use/designer/index.md
new file mode 100644
index 0000000..0a620ef
--- /dev/null
+++ b/i18n/ja/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: デザイナー
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# デザイナー
+{: .no_toc }
+
+フォーム、playbook、インベントリ、ワークフローをブラウザーで編集する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+フォーム作成者向け: デザイナーのセクションと、それぞれのタブに表示される内容を説明します。
+
+デザイナーを使うには `showDesigner` [ロールオプション](../config/roles.html#role-options) が必要です。デザイナーでは一度に 1 つの項目
+(フォーム、playbook、ワークフローファイル) を編集し、左側のメニューにそのセクションが並びます。ファイルの種類ごとにも専用のオプションが必要で、
+いずれも既定で有効です: **Playbook** には `allowPlaybookDesign`、 **ワークフロー** には `allowWorkflowDesign`、
+**インベントリ** には `allowInventoryDesign`、 **変数ファイル** には `allowVarsFileDesign` です。オプションがない場合、そのセクションは
+読み取り専用になり、サーバーはそのファイルの保存、作成、削除、プッシュを拒否します。ただし、フォームやワークフローからは引き続き選択できます。
+**フォーム**、 **カテゴリ**、 **定数** にも同じように `allowFormDesign` が必要です。ない場合は読み取り専用になり、サーバーは
+保存、プル、プッシュを拒否します。一度に編集できるのは 1 人だけです。 [デザイナーのロック](lock.html) を参照してください。
+
+---
+
+## セクション
+
+各セクションでは 1 種類のファイルを編集します。ファイルはローカル、または [リポジトリ](../repositories/) に置かれます。
+
+| セクション | 編集する内容 |
+|---|---|
+| **フォーム** | フォームファイル |
+| **カテゴリ** | `config.yaml` のカテゴリ |
+| **定数** | `config.yaml` の定数 |
+| **変数ファイル** | フォームが読み込む変数ファイル |
+| **Playbook** | フォームとワークフローが実行する playbook |
+| **インベントリ** | インベントリ: `inventory.yaml`、 `group_vars`、 `host_vars` |
+| **ワークフロー** | [ワークフロー](../workflows/) ファイル |
+
+ファイルを扱うセクションでは、ファイルがファイルエクスプローラーに一覧表示され、最初のファイルが開きます。まだファイルがないセクションにはその旨が表示されます。
+**フォーム** セクションとすべてのファイルセクションでは、ツールバーの先頭に **新しいファイル** ボタンがあります。インベントリでは新しい
+インベントリを、ワークフローでは新しい空のワークフローを作成します。エクスプローラーの虫眼鏡をクリックすると、ファイルを名前で絞り込むボックスが開きます。
+
+タイトル行の検索ボックスでは、開いている YAML 内のテキストを検索し、出現箇所をすべてマークします。デザイナーのロックを取得していれば、
+**YAML** タブで使用できます。
+
+---
+
+## タブ
+
+どのセクションにも同じ 3 つのタブがあり、すべて同じ YAML を扱います。1 つのタブでの編集はほかのタブにも反映され、 **保存** で保存されます。
+
+- **YAML** は、書かれているとおりのファイルです。
+- **ビジュアル** は、フィールドを使ってファイルを編集します。変更されるのは編集したキーだけなので、コメントやその他の部分は書かれたまま残ります。
+- **プレビュー** は、ファイルの動作を表示するだけで、何も編集しません。
+
+ビジュアルタブとプレビュータブに表示される内容は、セクションごとに次のとおりです。
+
+| セクション | ビジュアル | プレビュー |
+|---|---|---|
+| **フォーム** | フォームの設定とフィールド。デザイナーの playbook、インベントリ、ワークフローの一覧付き | 未保存の編集を含む現在のフォーム。送信しても何も実行されません |
+| **カテゴリ** | カテゴリを表として編集 | カテゴリから作られるフォームページのメニュー |
+| **定数** | 定数をアウトラインとして編集 (キーは矢印キーで移動) | 各定数と、コピー用のその参照 `$(NAME)`、それを使うフォーム |
+| **変数ファイル** | 変数を編集 | 各変数と、コピー用の playbook での参照 {% raw %}`{{ name }}`{% endraw %}、そのファイルを読み込むフォーム |
+| **Playbook** | プレイ: 各プレイの名前、ホスト、 **Become**、 **facts を収集**、ロール、およびタスク (それぞれモジュールと引数付き) | playbook のアウトライン: プレイとそのホスト、ロール、タスク、インポートする playbook |
+| **インベントリ** | グループ、子グループ、ホスト、それぞれが設定する変数 | `group_vars` と `host_vars` を含む、ツリー表示のインベントリ |
+| **ワークフロー** | [編集](../workflows/designer.html) するためのワークフローのグラフ | [ドライラン](../workflows/designer.html#trying-it-out): ノードをクリックすると失敗させられます |
+
+YAML を読み取れない場合、ビジュアルタブとプレビュータブにはその理由が表示され、 **YAML で表示** でその行の YAML を開けます。
diff --git a/i18n/ja/_use/designer/lock.md b/i18n/ja/_use/designer/lock.md
new file mode 100644
index 0000000..c5ecd6d
--- /dev/null
+++ b/i18n/ja/_use/designer/lock.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: デザイナーのロック
+parent: デザイナー
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# デザイナーのロック
+{: .no_toc }
+
+一度に編集できるのは 1 人だけ
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ロックを取得する
+
+デザイナーは、右上のスイッチでオンにするまでオフのままです。オンにするとロックを
+取得し、それ以降は再びオフにするまで、保存できるのは自分だけになります。
+
+ロックがない場合、デザイナーには **デザイナーはアクティブではありません** と表示され、何も編集できません。
+
+保存が重なることはありません。7.3.0 以降、保存、プッシュ、読み込みの実行中に 2 回目の **保存** (ダブルクリックや Ctrl+S の押しっぱなし) をしても
+無視されるため、1 回目と競合して 2 つ目のバックアップや 2 つ目のコミットが書き込まれることはありません。
+
+---
+
+## ほかのユーザーがロックしているとき
+
+ほかのユーザーがロックを保持している間、デザイナーには **デザイナーは (ユーザー名) が使用中です** と表示され、それ以外は何も表示されません。セクションも
+ファイルも表示されません。
+
+スイッチはオンの状態でグレー表示になり、横に **(ユーザー名) がロック中** と表示されます。そのユーザーがデザイナーをオフにすると、
+ロックを取得できます。ロックが取得または解放されると、開いているすべてのデザイナーに再読み込みなしですぐに反映されます。
+
+2 人のユーザーが同時にデザイナーをオンにした場合、どちらか一方がロックを取得します。7.3.0 以降、もう一方のユーザーには誰がロックを保持しているかが表示され、
+すべてのエディターが読み取り専用のままになるため、保存できない内容を入力してしまうことはありません。
+
+---
+
+## 他人のロックを解除する
+
+管理者は、ほかのユーザーが保持しているロックを解放できます。たとえば、デザイナーを開いたまま帰宅してしまった場合などです。
+
+**(ユーザー名) がロック中** の横にある **解除** は、管理者にだけ表示されます。実行前に確認が求められ、そのユーザーの未保存の変更は失われます。
+
+7.3.0 以降、ロックを解除されたユーザーには、そのことと解除した人が通知されます: **デザイナーのロックが (管理者名) によって解除されました。未保存の変更は保存できなくなりました。**
+そのユーザーのデザイナーが自動的にロックを取り戻すことはありません。作業を続けたいときに、もう一度オンにします。
+
+---
+
+## 放置されたロック
+
+誰も使っていないロックは自動的に解放されるため、誰も開いていないデザイナーを待ち続けることはありません。
+
+ロックを保持しているユーザーの開いているデザイナーは、まだ開いていることをサーバーに通知し続けます。ブラウザーが閉じられた、コンピューターがシャットダウンした、
+ネットワークが切れたなどの理由で、サーバーに 5 分間通知が届かないと、ロックは再び解放されます。保持していたユーザーが
+デザイナーに戻ったとき、ほかの誰もロックを取得していなければ、再びロックを取得します。例外は管理者による解除で、その場合は
+ロックが取り戻されることはありません。
diff --git a/i18n/ja/_use/jobs/actions.md b/i18n/ja/_use/jobs/actions.md
new file mode 100644
index 0000000..576d881
--- /dev/null
+++ b/i18n/ja/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: ジョブの操作
+parent: ジョブ
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# ジョブの操作
+{: .no_toc }
+
+ジョブの起動、中止、再起動、承認または却下、削除
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ジョブを起動する
+
+ジョブはすべてフォームから始まります。 **フォーム** ページからフォームを開き、フィールドに入力して **送信** を押します。
+
+1. フォームがブラウザーで検証され、フィールドの値がサーバーに送信されます。
+2. サーバーがジョブを作成してその番号を返し、フォームの [`onSubmit`](../forms/job-status-action.html) アクションが実行されます。
+3. フォームの下にジョブの出力が表示され、ジョブが終了するまで 2 秒ごとに更新されます。
+
+ジョブは **ジョブ** ページにも表示され、後からそこで追跡できます。
+
+### フォームを起動できるユーザー
+
+フォームは、その `roles` リストにある [ロール](../config/roles.html) のいずれかを持つユーザーに一覧表示され、起動できます。
+すべてのユーザーが持つ `default` ロールを指定すると、サインインできる全員がフォームを使えるようになります。
+
+### 送信する前に
+
+フィールドの上のバーにはいくつかのツールがあり、それぞれロールで許可されている場合にだけ表示されます。
+
+| ボタン | 内容 | ロールオプション |
+|---|---|---|
+| **Extravars を表示** | フィールドへの入力に合わせて、ジョブが受け取る extravars をプレビューします | `showExtraVars` |
+| **verbose** | ジョブを詳細モードで実行します | `allowVerboseMode` |
+| **保存済みデータから読み込む** | [保存済みジョブ](stored-jobs.html) からフィールドに入力します | `allowStoredJobs` |
+| **このフォームを再読み込み** | フォームを既定値で再び読み込みます | なし |
+
+### 起動時の選択
+
+フォームでは、予約名のフィールドを宣言することで、ユーザーが起動時に一部の Ansible オプションを選べるようにできます。
+その場合、フィールドの値がフォーム自体の設定より優先されます。
+
+| フィールド名 | 上書きするもの | 一般的なフィールドの種類 |
+|---|---|---|
+| `__check__` | チェックモード (何も変更しないドライラン) | `checkbox` |
+| `__diff__` | 差分モード (何が変わるかを表示) | `checkbox` |
+| `__limit__` | playbook を実行するホスト | `text` または `enum` |
+| `__tags__` | 実行するタグ | `text` または `enum` |
+| `__inventory__` | インベントリ | `enum` |
+| `__playbook__`、 `__template__` | playbook、または AWX / AAP のテンプレート | `enum` |
+
+たとえば、ドライランとホストの制限を提供するフォームは次のようになります。
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+サーバーがこれらの名前を受け付けるのは、それらをフィールドとして宣言しているフォームからだけなので、API からの起動で勝手に追加することはできません。
+上書きされるプロパティについては、 [Ansible フォーム](../forms/ansible.html) と [AWX フォーム](../forms/awx.html) で説明しています。
+
+### 起動が止まる場合
+
+起動しても、すぐに実行中のジョブになるとは限りません。
+
+* **無効なフィールド** : フォームは送信されず、検証に失敗した各フィールドにその理由が表示されます。
+* **起動時の検証** : [起動時の検証](../launch-validation/) が `enforce` に設定されている場合、サーバーが値を
+  再度チェックし、フォームのルールに反する起動を拒否します。
+* **承認** : [承認ポイント](../forms/approval.html) のあるフォームはジョブを作成し、ジョブはステータス
+  `approve` で待機します。 [ジョブを承認または却下する](#approve-or-reject-a-job) を参照してください。
+
+ジョブが終了すると、フォームの [通知](../forms/notifications.html) がメールやチャネルへのメッセージを送信し、ジョブ
+ステータスアクションが実行されます。
+
+### ジョブを開始するその他の方法
+
+フォームは、人が **送信** を押さなくてもジョブを開始できます。
+
+| 開始するもの | 方法 | ページ |
+|---|---|---|
+| 後で実行または cron スケジュール | **送信** の横の **後で実行 (1 回限り)** または **スケジュール (定期実行)** | [スケジュール](schedules.html) |
+| スクリプトまたはパイプライン | API トークンを使った `POST /api/v2/job` | [REST API のジョブ](../api/jobs.html) |
+| AI エージェント | MCP サーバーの `launch_job` ツール | [MCP ツール](../mcp/tools.html) |
+| 会話 | チャットアシスタントがフォームに入力して起動します | [チャットアシスタント](../chat/) |
+| 以前のジョブ | 下記の **再起動** | [ジョブを再起動する](#relaunch-a-job) |
+
+---
+
+## ジョブを中止する
+
+一覧の行メニュー (⋮) の **中止**、またはジョブのページの **ジョブを中止** で、ステータスが `running` のジョブを停止します。確認すると、
+AnsibleForms はジョブに中止のマークを付けます。
+
+* **`ansible`**: RTE が playbook のプロセスを (すべてのワーカーとともに) 停止し、ジョブは
+  `... was aborted by the operator` とともに `aborted` で終了します。空いている RTE を待っているジョブは、開始前に中止されます。
+* **テンプレートジョブ** (AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins): AnsibleForms がランナーにジョブのキャンセルまたは停止を
+  要求し、ジョブは `aborted` で終了します。ランナーが拒否した場合、出力に `Abort request denied` と、続いて
+  `reverting abort request` が表示され、ジョブは実行を続けます。キューにある Jenkins のビルドはキューから取り除かれます。
+* **`workflow`**: 実行中のノードのジョブが中止され、それ以降は何も開始されません (
+  [ワークフローの実行](../workflows/running.html#abort) を参照)。
+* **`multistep`**: まだ開始していないステップはスキップされ ( `skipping: [Abort is requested]` )、メインジョブは
+  `aborted` で終了します。すでに実行中のステップは個別のジョブなので、それも停止するにはそのジョブを開いて中止してください。
+
+自分のジョブは中止できます。管理者、または 7.3.0 以降はロールで `manageAllJobs` が設定されているユーザーは、どのジョブでも中止できます。 `showAllJobLogs` では、
+ほかのユーザーのジョブを表示できますが、中止はできません。
+
+---
+
+## ジョブを再起動する
+
+一覧の行メニュー (⋮) の **再起動**、またはジョブのページの **ジョブを再起動** で、終了したジョブから新しいジョブを開始します。これは
+`running` でも承認待ちでもないジョブで、ロールで `allowJobRelaunch` ロールオプションが設定されているユーザーに表示されます。
+
+ダイアログには次の選択肢があります。
+
+* **再起動**: 実行時と同じ値で、自分の名前の新しいジョブとしてもう一度実行します。
+* **詳細モード**: 詳細モードで再起動します。 `allowVerboseMode` ロールオプションがある場合に表示されます。
+* **再起動する前に値を編集**、続いて **編集して再起動**: ジョブの値を事前入力したフォームを開くので、
+  送信する前に値を変更できます。
+
+再起動するには、フォームがそれを許可していること ( `allowRelaunch`、既定は true ) と、ジョブが **自分のもの** であることも必要です。ただし、
+管理者または 7.3.0 以降で `manageAllJobs` を持つ場合は除きます。7.2 まではどのジョブでも再起動できた `showAllJobLogs` では、もう再起動できません。再起動がフォームのルールに対してどのようにチェックされるか、
+またパスワードフィールドのあるフォームで再起動が拒否されることがある理由については、 [再起動](../launch-validation/relaunching.html) で説明しています。
+
+### 事前入力したデータで再起動する
+
+**編集して再起動** は `prefillJobId` URL パラメーターを付けてフォームを開きます。このパラメーターは自分で作るリンクにも使えます。
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+フォームはジョブ `61` に保存されたフィールドの値を読み込み、 `Form pre-filled with data from previous job #61` と表示します。
+送信すると新しいジョブが開始され、ほかの起動と同じようにチェックされます。事前入力には再起動と同じルールが適用されます。
+
+* **パスワードフィールドは保存されない** ため、事前入力されることはありません。もう一度入力してください。定数も保存されません。
+* `allowJobRelaunch` ロールオプションが必要で、ジョブは自分のものである必要があります (または管理者であるか、 `manageAllJobs` を持っている)。
+* `allowRelaunch: false` のフォームは、再起動も事前入力もできません。
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+フィールドの値が保存されるようになる前のジョブは事前入力できず、代わりにフォームにエラーが表示されます。
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## ジョブを承認または却下する
+
+[承認ポイント](../forms/approval.html) のあるジョブは、ステータス `approve` で停止して待機します。このジョブは、承認者 (承認のロールの
+いずれかを持つユーザー) のジョブページに一覧表示されるので、承認者はそれを見つけられます。7.3.0 以降、ほかのユーザーには表示されなくなりました。
+
+**承認を確認** は、管理者と、承認のロールのいずれかを持つユーザーに表示されます。ジョブの行をクリックするか、
+行メニューの **承認を確認**、またはジョブのページの **承認を確認** ボタンを使います。ダイアログには、ジョブの値を埋め込んだ承認の
+メッセージ (メッセージがない場合は汎用の文) と、フォーム、ジョブ ID、起動したユーザーと日時、ジョブへのリンクが
+表示されます。 **拒否** と **承認** で応答します。
+
+* **承認**: ジョブが続行され、ステータスが `running` に戻ります。
+* **拒否**: ジョブは `rejected` で終了し、出力に `rejected by <username>` が記録されます。
+
+承認待ちのジョブは、ジョブページから再起動も削除もできません。先に承認または却下してください。
+
+7.3.0 以降、ジョブを起動したユーザーはそのジョブを承認できないため、必ず別の人が確認することになります。ただし、取り下げるために却下することはできます。
+管理者は、自分のジョブも含めて常に承認できます。承認ポイントで
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) を設定したフォームでは、起動したユーザーも自分のジョブを承認できます。
+
+---
+
+## ジョブを削除する
+
+一覧の行メニュー (⋮) の **削除**、またはジョブのページの **ジョブを削除** で、確認後にジョブをその出力とともに削除します。
+マルチステップジョブを削除すると、そのステップも削除されます。複数のジョブを一度に削除するには、一覧の最初の列でチェックし、
+その上の **削除 (n)** をクリックします。
+
+自分のジョブは削除できます。管理者と、7.3.0 以降は `manageAllJobs` ロールオプションを持つユーザーは、どのジョブでも削除できます。 `showAllJobLogs` では
+もう削除できません。 `allowJobDeletion: false` を設定したロールは、自分のジョブも含めて一切削除できないため、ジョブの履歴はすべて残ります。ジョブの
+ページでは、ジョブの実行中または中止処理中 (管理者と `manageAllJobs` を除く) と承認待ちの間はボタンが非表示になります。一覧では、
+削除できないジョブのメニュー項目とチェックボックスがグレー表示になります。
diff --git a/i18n/ja/_use/jobs/cleanup.md b/i18n/ja/_use/jobs/cleanup.md
new file mode 100644
index 0000000..b467511
--- /dev/null
+++ b/i18n/ja/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: クリーンアップ
+parent: ジョブ
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# クリーンアップ
+{: .no_toc }
+
+再起動で中断されたジョブと、終了したジョブの保持期間
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 放棄されたジョブ
+
+実行中のジョブは、それを開始した AnsibleForms のプロセスによって追跡されます。その追跡が止まると、ジョブは
+`abandoned` としてマークされます。
+
+* **起動時**: このプロセスが再起動前に追跡していたジョブと、どのプロセスも追跡していないバージョン 7 より前のジョブは、
+  まだ `running` または中止処理中であれば放棄としてマークされます。ログには `Abandoned <n> jobs` と表示されます。RTE で
+  実行されるジョブは対象外で、開始したプロセスがなくても実行を続けます。
+* **1 分ごと**: 2 分間応答しなくなった別の AnsibleForms プロセス (または RTE) が追跡していたジョブは、放棄として
+  マークされます。ログには `Abandoned <n> jobs followed by a node that stopped answering` と表示されます。
+* **1 時間ごと**: 1 日以上前に開始され、まだ `running` で、1 日間出力がないジョブは放棄としてマークされます。
+  ここでも RTE で実行されるジョブは対象外です。RTE は再起動時に自分のジョブをクリーンアップします。
+
+7.3.0 以降、再起動や停止したノードによって放棄された AWX、AAP、Ascender のテンプレートジョブは、過去 24 時間以内に開始されたものであれば
+再び引き継がれます。1 つの AnsibleForms プロセスがそれを引き継いでランナー上で再び追跡し、ジョブは実際にそこで起きた結果で
+終了します。ほかのランナーのジョブ、playbook、ワークフロー、マルチステップのジョブは放棄されたままです。
+
+放棄された playbook は、一部だけ実行されている可能性があります。再起動する前に管理対象ホストを確認してください。
+[ジョブのステータスが abandoned になる](../troubleshooting.html#a-job-shows-the-status-abandoned) を参照してください。
+
+---
+
+## ジョブの保持
+
+管理者が保持期間を設定しない限り、ジョブは削除されるまで保持されます。
+
+[`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) を設定すると、毎晩 (2:30) 実行されるタスクが、
+指定した日数より前に終了したジョブを、その出力とステップとともに削除します。削除されるのはステータスが
+`success`、 `failed`、 `warning`、 `aborted`、 `rejected`、 `abandoned` のジョブだけなので、実行中のジョブと承認待ちの
+ジョブは、どれだけ古くても保持されます。既定値の `0` では、すべてのジョブが保持されます。
diff --git a/i18n/ja/_use/jobs/following.md b/i18n/ja/_use/jobs/following.md
new file mode 100644
index 0000000..2b2643d
--- /dev/null
+++ b/i18n/ja/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: ジョブの追跡
+parent: ジョブ
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# ジョブの追跡
+{: .no_toc }
+
+ライブ出力、extravars、フィルター、ダウンロード
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ジョブを追跡する
+
+ジョブをクリックするとそのページが開きます。タイトルにジョブのフォーム、ヘッダーに操作、その下に出力が表示されます。
+
+![ジョブの出力](../assets/screenshots/job-output.jpg)
+
+7.3.0 以降、このページはカードで構成されており、各カードはヘッダーの下に折りたためます。
+
+| カード | 表示内容 |
+|---|---|
+| **概要** | ヘッダーにジョブの名前、ステータス、種類が表示され、その下にジョブの情報が 3 列のグリッドで表示されます (幅の狭いページでは 2 列、さらに 1 列) |
+| **ワークフロー** | ワークフロージョブ (AWX または AAP のワークフロージョブを含む) の場合、そのグラフとノード数 ( [ワークフローのグラフ](#the-workflow-graph) を参照) |
+| **出力** | ジョブの出力とそのツールバー |
+
+AWX、AAP、Ascender、Jenkins、Semaphore、Rundeck で実行されたジョブには、そのツールでのジョブ番号が、ツール内のページへのリンクとして表示されます。リンクは
+新しいタブで開きます。リンクはジョブに保存されるため、後でランナーの名前が変更されたり削除されたりしても機能します。
+
+ページはリアルタイムで更新されます。ジョブが起動された、ステータスが変わった、出力が書き込まれた、または削除されたときに、サーバーがイベントを送信し、
+ページがジョブを再読み込みするため、ジョブが書き込むにつれて出力が伸びていきます。ジョブ一覧も同じように更新されます。
+**更新** で、ジョブを手動で再読み込みします。
+
+出力の末尾を表示している間は、新しい行が届くとページがそれに合わせて下へスクロールします。上にスクロールして前の行を読むと、
+その位置にとどまります。このとき出力の下部に **最新へ移動** が表示され、さらに行が届くと **新しい行** に変わります。
+これをクリックするか、末尾までスクロールし直すと、再び新しい行を追うようになります。 **送信** 後にフォームのページに表示される出力と
+[サーバーログ](../production/logs.html) も、同じように新しい行を追います。
+
+出力のツールバーには次のものがあります。
+
+| ボタン | 内容 |
+|---|---|
+| **Extravars を表示** | ジョブの実行に使われた extravars を出力の上のパネルに表示します。 **JSON** / **YAML** の切り替えと **コピー** があります |
+| **Artifacts を表示** | ジョブのアーティファクトを同じパネルに表示します (下記参照) |
+| **パラメーターを表示** | Jenkins のジョブでは **Extravars を表示** の代わりに表示されます。実行に使われた値、つまりビルドパラメーターです |
+| **payload を表示** | Rundeck のジョブでは **Extravars を表示** の代わりに表示されます。送信された payload です |
+| **ホストとタスク** | playbook のホストとタスクを出力の上に表示します ( [ホストとタスク](#hosts-and-tasks) を参照) |
+| **更新** | 出力を再読み込みします |
+| **フィルターを適用** | 名前が出力フィルターに一致するタスクを非表示にします。 **フィルターを解除** で再び表示されます |
+| **出力をコピー** | 出力をプレーンテキストとしてコピーします。フィルターの適用状態はそのままです |
+| **出力をダウンロード** | 出力を `ansibleforms-job-<id>.txt` としてダウンロードします |
+
+**Artifacts を表示** は、テンプレートジョブ以外のすべてのジョブ (RTE での playbook やワークフローなど。playbook が `set_stats` で
+アーティファクトを収集していない場合は空です) と、AWX、AAP、Ascender で実行されたテンプレートジョブで使用できます。Semaphore、Rundeck、
+Jenkins のジョブにはアーティファクトがないため、表示されることはありません。
+
+ツールバーの左端にある **すべて折りたたむ** ボタンは、出力のすべてのセクション (各プレイとタスク) を折りたたみ、
+**すべて展開** に変わります。 **すべて展開** で再び展開されます。
+
+**Extravars を表示** には `showExtravars` ロールオプションが、 **Artifacts を表示** には `showArtifacts` ロールオプションが必要です
+( [ロールオプション](../config/roles.html#role-options) を参照)。パスワードフィールドの値と、
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) に一致するキーの値はマスクされます。
+
+フィルターは [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) で設定し、既定値は `\[low\]` です。
+出力の多いタスクの名前に `[low]` を入れておくと、 **フィルターを適用** でそのタスクとその行が非表示になります。
+
+マルチステップジョブのページでは、メインジョブの下にすべてのステップが順に表示され、それぞれ
+**ステップ 1 · Prepare the server (ジョブ ID 98)** のようなタイトルバーとステータスが付きます。タイトルをクリック (またはタイトル上で Enter キーかスペースキーを押す) すると、その出力が
+折りたたまれ、もう一度クリックすると展開されます。AWX/AAP のワークフローでは、ノードのステータスも表示されます。
+
+[ワークフロー](../workflows/running.html#the-job) ジョブは、すべてのノードの出力を自身の出力に保持し、ノードごとに `WORKFLOW NODE` の見出しを
+付けます。グラフはリアルタイムで描画され、ノードをクリックするとその出力が開きます。
+
+---
+
+## 出力内のテキストを検索する
+
+7.3.0 以降、ジョブのページのタイトル行には、ジョブの操作の左に検索ボックス **出力を検索** があります。
+
+出力内でテキストが現れる箇所は、大文字と小文字に関係なくすべて強調表示され、ページは最初の箇所に移動します。 **Enter** で
+次の箇所に移動し、その箇所はより強く表示されます。ツールバーには全体の何件目かが ( **2 / 4** ) 、または **見つかりません** と表示されます。検索時には出力と
+そのセクションが先に展開され、ジョブの実行中は新しい行も検索されますが、ページは移動しません。
+
+---
+
+## 長い出力を移動する
+
+7.3.0 以降、ジョブのページと **送信** 後のフォームの下に表示される長い出力では、次の方法で移動できます。
+
+| コントロール | 内容 |
+|---|---|
+| 固定ヘッダー | セクション (ワークフローのノード、ジョブの playbook、マルチステップジョブのステップ) のヘッダーは、その行がスクロールする間、上部に固定されます |
+| **2 件失敗** | 失敗したタスクの数です。Ansible で無視するよう指定された失敗は含みません。クリックするたびに次の失敗に移動し、展開して強調表示します。失敗したタスクがない場合は、代わりに **1 件のエラー** でエラー行の数を示します |
+| 行番号 | 各行番号はその行へのリンクで、アドレスに `#L45` のように付きます。そのアドレスを開くと、その行までスクロールして強調表示します |
+| 上下ボタン | ページをスクロールすると右下に表示され、先頭または末尾に戻れます |
+| **実行中** と **中止** | ジョブの実行中は、フォームのページのバーがウィンドウの下部に固定され、そこにある **中止** でジョブをすぐに停止できます |
+
+---
+
+## タスクの結果
+
+7.3.0 以降、playbook の出力にあるホストの結果行をクリックすると、AWX と同じように **タスクの結果** ダイアログでその結果が開きます。
+
+結果行、その後に続く結果の本体 ( `=> { ... }` )、失敗した結果の前に出力されたエラーは、ポインターを合わせると 1 つのブロックとして強調表示され、
+クリックするとダイアログが開きます。これはジョブのページと **送信** 後のフォームの下で、7.3.0 以降の RTE で実行された playbook に対して機能します。
+結果は [ホストとタスク](#hosts-and-tasks) と同じイベントから取得されるためです。ダイアログには次のタブがあります。
+
+| タブ | 表示内容 |
+|---|---|
+| **詳細** | ステータス、ホスト、プレイ、タスク、モジュール、ループ項目、開始時刻、所要時間、リターンコード、メッセージ |
+| **JSON** と **YAML** | モジュールの結果全体。色付けされ、行番号が付きます |
+| **標準出力** と **標準エラー** | 結果の `stdout` と `stderr` (ある場合) |
+
+結果全体、つまり **JSON**、 **YAML**、出力のタブの内容が保存されるのは、ジョブを詳細モードで実行した場合だけです。その場合は出力にも
+同じ内容が表示されるためです。それ以外の場合、ダイアログには詳細だけが表示されます。詳細モードでも、モジュールの引数 ( `invocation` ) は
+除外され、シークレットのように見えるキーの値はマスクされ、JSON で 64 KB を超える結果は切り詰められます。
+
+---
+
+## ワークフローのグラフ
+
+7.3.0 以降、実行中のワークフローのグラフは、実行中のノードが見えるようにスライドします。
+
+グラフをスクロールして離れると、その位置にとどまり、 **実行中のノードを追う** ボタンで再び追跡できます。ノードにポインターを合わせると、
+名前全体を含むカードが表示され、そのノードとリンクが強調され、グラフのほかの部分は薄く表示されます。グラフには **画面に
+合わせる** と **全画面表示** のボタンがあり、 **送信** 後のフォームの下では、ジョブのページと同じようにノードをクリックするとその出力が開きます。
+
+---
+
+## ホストとタスク
+
+7.3.0 以降、7.3.0 以降の RTE で実行された playbook ジョブは、テキストの出力とともに構造化されたイベントを記録します。各プレイ、タスク、
+ホストの結果と、リキャップです。出力のツールバーにある **ホストとタスク** で、ジョブのページと **送信** 後のフォームの下に、これらを出力の上のパネルに
+表示します。ジョブにイベントがあれば使用でき、ジョブの実行中は数秒ごとにパネルが再読み込みされます。
+
+| ビュー | 表示内容 |
+|---|---|
+| **グリッド** | ホストごとのリキャップ (ok、changed、failed、unreachable、skipped、rescued、ignored) と、ホストとタスクのグリッド。各セルはそのタスクに対するホストの結果で色分けされ、ポインターを合わせるとメッセージと時刻が表示されます。実行されていない場合は *未実行* です |
+| **タイムライン** | 各タスクを、最も時間のかかったホストの長さのバーで表示し、秒単位の時間と合計を示します |
+
+テキストの出力はそのままです。イベントは RTE 独自の `af_events` コールバックプラグインによって書き込まれるため、playbook を変更する必要はありません。
diff --git a/i18n/ja/_use/jobs/index.md b/i18n/ja/_use/jobs/index.md
new file mode 100644
index 0000000..fba4b9c
--- /dev/null
+++ b/i18n/ja/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: ジョブ
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# ジョブ
+{: .no_toc }
+
+フォームが開始したジョブの追跡、中止、再起動、承認、削除
+{: .fs-6 .fw-300 }
+
+---
+
+フォームを起動するすべてのユーザー向け: ジョブとは何か、どこで見つけられるか、誰が見られるかを説明します。
+
+---
+
+## ジョブとは
+
+ジョブとは、フォームの 1 回の実行のことです。フォームが送信されるとすぐに、AnsibleForms はそのステータス、extravars、出力とともにジョブを記録します。
+
+各ジョブには次の情報が保存されます。
+
+* 実行した **フォーム** と、起動した **ユーザー** ( `local` や `ldap` などのユーザーの種類を含む)
+* **ジョブの種類** と **ステータス**、 **開始時刻** と **終了時刻**
+* **出力**、実行に使われた extravars と認証情報、フォームに入力されたフィールドの値
+
+マルチステップフォームでは、フォームに対して 1 つのジョブと、ステップごとに 1 つのジョブが作成されます。ステップはメインジョブに関連付けられ、その下に一覧表示されます。
+
+同じジョブは [REST API](../api/jobs.html) からも起動、追跡、管理できます。
+
+---
+
+## ジョブページ
+
+ヘッダーの **ジョブ** リンクをクリックすると、すべてのジョブの一覧が新しい順に開きます ( `/jobs/all` )。このページとリンクは、ロールで
+`showJobs` [ロールオプション](../config/roles.html#role-options) が設定されているユーザーに表示されます。
+
+![ジョブ一覧](../assets/screenshots/job-log.jpg)
+
+左側のメニューはジョブを時間で分類し、各項目にジョブの数を表示します。ステータスの項目を選ぶと、一覧がそのステータスで絞り込まれます。
+
+| セクション | メニュー項目 | 表示内容 |
+|---|---|---|
+| **過去** | **成功** | ステータスが `success` のジョブ |
+| | **失敗** | ステータスが `failed` のジョブ |
+| | **中止** | ステータスが `aborted` のジョブ |
+| | **却下** | ステータスが `rejected` のジョブ |
+| | **放棄** | ステータスが `abandoned` のジョブ |
+| **現在** | **実行中** | ステータスが `running` のジョブ |
+| | **承認待ち** | ステータスが `approve` のジョブ。待機中のジョブがあると件数がオレンジ色になります |
+| **未来** | **スケジュール済み** | [スケジュール](schedules.html) ページ (ロールオプション `allowScheduledJobs` ) |
+| | **保存済み** | [保存済みジョブ](stored-jobs.html) ページ (ロールオプション `allowStoredJobs` ) |
+
+メニューにはすべてのジョブを表示する項目はありません。ヘッダーの **ジョブ** リンクで、 `warning` のジョブも含めてすべてが表示されます。
+
+表の上のタイトル行には次のものがあります。
+
+* **検索ボックス**: 表示されている列にそのテキストを含むジョブ (大文字と小文字を区別しない)、またはステップのいずれかの ID
+  またはターゲットがそのテキストであるジョブを残します。
+* **削除** (チェックしたジョブの数付き): 最初の列でチェックしたジョブをまとめて削除します。
+* **列**: `id`、 `form`、 `job type`、 `status`、 `start time`、 `end time`、 `duration`、 `user` の列を表示または非表示にします。
+  実行中のジョブの所要時間はカウントアップします。
+* **更新**: 一覧を再読み込みします。
+
+一覧には、 [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) の設定
+( **設定 > システム > 全般** の **ジョブ** タブ、既定は `1000` ) で指定した数だけ、新しいジョブが読み込まれます。ページ、検索、フィルターはこれらのジョブが対象です。
+
+各列は並べ替えが可能で、それぞれにフィルター欄があります。マルチステップのジョブには `form` の直前に矢印があり、クリックすると
+ステップが展開されます。行のそれ以外の部分をクリックするとジョブが開きます。
+
+ヘッダーのベルは、自分の承認を待っているジョブの数を示し、クリックすると **承認待ち** で一覧が開きます。ランナーを表示できる
+ユーザーには、 [承認待ちのランナー](../runners/registration.html#approving-an-rte) (参加を要求した RTE) の数も含まれ、
+待機しているのがランナーだけの場合は **接続 > ランナー** が開きます。両方が待機している場合は、 **承認待ちのジョブ** と
+**承認待ちのランナー** のメニューが件数付きで開きます。
+
+---
+
+## 誰がどのジョブを見られるか
+
+ユーザーが見られるジョブは、そのユーザーのロールによって決まります。
+
+| ユーザー | 表示されるジョブ |
+|---|---|
+| 管理者 ( `admin` ロール) | すべてのジョブ |
+| ロールオプション `showAllJobLogs` | すべてのジョブ |
+| ロールオプション `manageAllJobs` (7.3.0 以降) | すべてのジョブ。中止、削除、再起動もできます |
+| その他のユーザー | 自分のジョブと、自分のロールのいずれかを指定した承認を待っているジョブ |
+
+7.2 までは、どのユーザーも承認待ちのジョブを extravars や出力も含めて開くことができました。7.3.0 以降は、ジョブの所有者と承認者だけが開けます。
+ジョブが見えても、そのジョブに対するすべての操作が許可されるわけではありません。ほかのユーザーのジョブを中止、削除、再起動するには管理者または
+`manageAllJobs` が必要で、 `showAllJobLogs` はジョブを表示するだけです。削除にはさらに `allowJobDeletion` が、再起動には `allowJobRelaunch` が必要です。
+
+---
+
+## このセクションの内容
+
+各トピックはそれぞれのページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [ステータスと種類](statuses.html) | ジョブがとりうるすべてのステータスと、ジョブの種類 |
+| [ジョブの追跡](following.html) | ライブ出力、extravars、フィルター、ダウンロード |
+| [ジョブの操作](actions.html) | ジョブの起動、中止、再起動、承認または却下、削除 |
+| [スケジュール](schedules.html) | フォームを後で、または cron スケジュールで実行し、すべてのスケジュールを管理する |
+| [保存済みジョブ](stored-jobs.html) | フォームのデータを保存して後で再び読み込む |
+| [クリーンアップ](cleanup.html) | 再起動で中断されたジョブと、終了したジョブの保持期間 |
diff --git a/i18n/ja/_use/jobs/schedules.md b/i18n/ja/_use/jobs/schedules.md
new file mode 100644
index 0000000..6e33516
--- /dev/null
+++ b/i18n/ja/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: スケジュール
+parent: ジョブ
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# スケジュール
+{: .no_toc }
+
+フォームを後で、または cron スケジュールで実行し、すべてのスケジュールを管理する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## フォームの操作
+
+フォームはすぐに実行する以外のこともできます。 **送信** ボタンの横のドロップダウンには、さらに 3 つの操作があります。
+
+| 操作 | 内容 | ロールオプション |
+|---|---|---|
+| **スケジュール (定期実行)** | cron 式に従ってフォームを実行するスケジュールを作成します | `allowScheduledJobs` |
+| **後で実行 (1 回限り)** | 選んだ日時にフォームを 1 回だけ実行するスケジュールを作成します | `allowPlannedJobs` |
+| **ストア** | フィールドの値を保存し、後でフォームに再び読み込めるようにします | `allowStoredJobs` |
+
+ロールオプションがオフの操作は表示されません。どの操作でも、 **送信** と同じように事前にフォームが検証されます。
+2 つのスケジュール操作は **スケジュール** ページに項目を作成し、 **ストア** は **保存済みジョブ** ページに項目を作成します。
+[ジョブ](./) ページのサイドバーでは、 **未来** の下の **スケジュール済み** と **保存済み** からこれらを開けます。ロールオプションについては
+[ロールオプション](../config/roles.html#role-options) で説明しています。
+
+{: .warning }
+> `allowScheduledJobs` は管理者レベルのオプションとして扱ってください。このオプションで作成したスケジュールは、作成したユーザーの所有にはなりません。このオプションを
+> 持つすべてのユーザーが、すべてのスケジュールを表示し、変更できます。また、そのようなスケジュールは、作成者自身のアクセス権にかかわらず、どのフォームでも
+> 管理者権限で実行されます。管理者として信頼できるロールにだけ付与してください。
+
+{: .note }
+> **後で実行 (1 回限り)** に必要なのは `allowPlannedJobs` だけです。 `allowScheduledJobs` を持たないユーザーの場合、 **そのユーザーとして** 実行を
+> 予定します。サーバーはそのユーザーがフォームを実行できるかをチェックし、時刻になるとジョブはそのユーザーとして、そのユーザーの所有で実行されます
+> ( [予定された実行](#planned-runs) を参照)。
+
+---
+
+## フォームをスケジュールする
+
+フォームに入力してから、 **送信** の横のドロップダウンを開き、スケジュール操作のいずれかを選びます。
+
+- **スケジュール (定期実行)** は **スケジュールを作成** を開きます。 **名前** と **cron 式** (既定値の `0 0 * * *` は
+  毎日午前 0 時に実行) を入力し、 **スケジュールを作成** を選びます。
+- **後で実行 (1 回限り)** は **後で実行** を開きます。 **名前** を入力して **実行日時** を選び、
+  **ジョブをスケジュール** を選びます。
+
+名前はすべてのスケジュールの中で一意である必要があります。スケジュールには、フォームの名前と、その時点でフォームが生成した extravars のコピーが
+YAML で保存されます。毎回の実行ではそのコピーが使われるため、ジョブが受け取る内容を変えるには **スケジュール** ページで編集してください。
+
+![スケジュール](../assets/screenshots/schedules.jpg)
+
+---
+
+## スケジュールページ
+
+**スケジュール** ページには、すべてのスケジュールが一覧表示され、7.3.0 以降は **有効** 列もあります。 `allowScheduledJobs` が必要です。各行のメニューには次の操作があります。
+
+| 操作 | 内容 |
+|---|---|
+| **編集** | 名前、種類、cron 式または実行日時、フォーム、extra vars を変更します |
+| **今すぐ実行** | cron 式や実行日時を待たずに、スケジュールを今すぐ実行します |
+| **有効にする** または **無効にする** | **有効** 列の表示に応じて、スケジュールをオンまたはオフにします (7.3.0 以降) |
+| **削除** | スケジュールを削除します。すぐに実行されなくなります |
+| **最後の出力** | スケジュールのページで、前回の実行が報告した内容 (開始したジョブの番号など) を表示します |
+
+ここでスケジュールを一から作成することもできます。 **フォーム** を選び、 **1 回限りの実行** にチェックを入れて
+**実行日時** を設定するか、チェックを入れずに **cron スケジュール** を設定します。 **Extra vars** は入力用のフォームがない YAML なので、
+playbook に必要な値を自分で、ディクショナリ (key: value のペア) として追加してください。
+
+**cron スケジュール** フィールドは cron エディターで、式を言葉で説明し、プリセットを提供し、次回以降の実行をプレビューします。
+サーバーは、実行できない式や、決して発生しない式を拒否します。
+
+7.3.0 以降、各スケジュールには **有効** スイッチがあり、削除せずに一時停止できます。オフにしたスケジュールは設定とともにページに残りますが、
+自動では実行されません。定期実行のスケジュールは cron のタイミングをスキップし、1 回限りのスケジュールは **実行日時** を過ぎても、再びオンにされるまで
+待機します。 **今すぐ実行** では引き続き必要に応じて実行できます。新しいスケジュールはオンで作成され、7.3.0 より前から
+あったスケジュールはアップグレード後にオンになります。
+
+---
+
+## cron 式とタイムゾーン
+
+定期実行のスケジュールには、標準的な 5 フィールドの cron 式を指定します: 分、時、日、月、曜日です。
+
+| 式 | 実行タイミング |
+|---|---|
+| `*/15 * * * *` | 15 分ごと |
+| `0 2 * * *` | 毎日 02:00 |
+| `30 7 * * 1-5` | 月曜日から金曜日の 07:30 |
+| `0 0 1 * *` | 毎月 1 日の午前 0 時 |
+
+その他の例と、エディターが受け付けない cron の機能については、FAQ の
+[どの cron 式を使えますか?](../faq.html#which-cron-expressions-can-i-use) を参照してください。
+
+{: .note }
+> cron スケジュールは、プロフィールやブラウザーのタイムゾーンではなく、 [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (既定は `UTC` ) で設定した
+> サーバーのタイムゾーンで実行されます。cron エディターも、同じタイムゾーンで次回以降の実行をプレビューします。
+
+---
+
+## スケジュールの実行のしくみ
+
+スケジュールの時刻になるとキューに入れられ、サーバーは 10 秒ごとにキューを確認して、キューにあるスケジュールを 1 つずつ開始します。
+
+- **定期実行** のスケジュールは、前回の実行がまだキューにあるか実行中の場合はそのタイミングをスキップするため、実行が重なることはありません。
+- **1 回限り** のスケジュールは **実行日時** から 1 分以内に実行され、その後削除されます。 **今すぐ実行** で開始した場合も同じです。
+- **ステータス** は、ジョブが開始された場合は `success`、開始できなかった場合は `failed` です。 `success` はジョブが
+  起動されたことを示すだけなので、どう終了したかはジョブを開いて確認してください。
+
+`allowScheduledJobs` で作成したスケジュールは、組み込みユーザー `Schedule Service` (種類 `schedule` ) として
+`admin` ロールで実行されます。スケジュールを作成した人のアクセス権にかかわらずどのフォームでも実行でき、extravars の
+`ansibleforms_user` はこのユーザーを表します。 [予定された実行](#planned-runs) は、代わりに予定したユーザーとして実行されます。
+
+ジョブには `schedule` オブジェクト ( `id`、 `name`、 `form` を含む) も渡されるため、playbook はスケジュールによって開始されたことがわかります。
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## 予定された実行
+
+`allowScheduledJobs` を持たないユーザーが **後で実行 (1 回限り)** を使うと、予定された実行が作成されます。これはそのユーザーに結び付いた 1 回限りのスケジュールです。
+
+- **予定したとき**、サーバーはそのユーザーがフォームを実行できるか (フォームの `roles` ) をチェックします。詳細モードには
+  `allowVerboseMode` が必要です。予定された実行は常に 1 回限りで、cron 式は拒否されます。
+- **起動時の検証が `enforce` の場合**、予定した時点でフィールドの値がチェックされるため、拒否される実行は、
+  ユーザーがまだ画面を見ている間に拒否されます。
+- **実行されるとき**、ジョブはそのユーザーとして、そのユーザーの所有で、ブラウザーからの起動と同じチェックを経て実行されます。
+  その時点でのフォームのロール、予約済みの extravars の除去、起動時の検証です。 `ansibleforms_user` はそのユーザーを表します。
+
+予定したユーザーには、 `allowScheduledJobs` が必要な **スケジュール** ページは表示されません。ジョブは自分のジョブ履歴に表示されます。
+
+---
+
+## フォームが変更された場合
+
+スケジュールは名前でフォームを参照し、実行のたびに、その時点で定義されているとおりにフォームを実行します。
+
+- **フォームが編集された場合**: 次回の実行では、新しい定義 (playbook、テンプレート、インベントリ) が、スケジュールに保存された
+  extravars とともに使われます。フォームは描画されないため、フィールドは再計算されません。それに合わせてスケジュールの extra vars を編集してください。
+- **フォームの名前が変更された、または削除された場合**: 実行は失敗し、 **ステータス** は `failed` になり、 **最後の出力** には
+  `Failed to launch : No such form '<name>'` と表示されます。スケジュールを編集して正しいフォームを選ぶか、削除してください。
+
+---
+
+## ジョブ履歴でのスケジュールされたジョブ
+
+スケジュールの実行ごとに通常のジョブが作成され、 [ジョブ](./) ページに、ユーザーを `Schedule Service` として、
+予定された実行の場合は予定したユーザーとして一覧表示されます。
+
+`Schedule Service` のジョブはスケジュールを作成した人のものではないため、管理者と `showAllJobLogs` を持つユーザーにしか
+表示されません。予定された実行のジョブは、そのユーザーにも表示されます。スケジュールの **最後の出力** には開始したジョブが示されるので、一覧でそのジョブを見つけられます。
diff --git a/i18n/ja/_use/jobs/statuses.md b/i18n/ja/_use/jobs/statuses.md
new file mode 100644
index 0000000..c861b05
--- /dev/null
+++ b/i18n/ja/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: ステータスと種類
+parent: ジョブ
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# ステータスと種類
+{: .no_toc }
+
+ジョブがとりうるすべてのステータスと、ジョブの種類
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## ジョブのステータス
+
+AnsibleForms はジョブに次のステータスを設定します。一覧では、各ステータスが色付きのラベルで表示されます。
+
+| ステータス | 意味 | できること |
+|---|---|---|
+| `running` | ジョブが実行中、または承認されたジョブが再開した | 出力を追跡する、中止する |
+| `approve` | ジョブが実行前 (またはマルチステップのステップの実行前) に [承認ポイント](../forms/approval.html) で待機している | 自分のロールのいずれかが承認者であれば、承認または却下する |
+| `success` | playbook、テンプレート、またはすべてのステップがエラーなく終了した | 出力を表示する、再起動する、削除する |
+| `failed` | ジョブがエラーで終了した、または起動自体に失敗した | 出力を表示して原因を確認する、再起動する、削除する |
+| `warning` | マルチステップは終了したが、 `continue` が設定されたステップが失敗した | 出力を表示する、再起動する、削除する |
+| `aborted` | AnsibleForms からジョブが中止された、または AWX / AAP のジョブがキャンセルされた | 出力を表示する、再起動する、削除する |
+| `rejected` | 承認者がジョブを却下したため、一度も実行されなかった | 出力を表示する、再起動する、削除する |
+| `abandoned` | AnsibleForms がジョブの追跡を停止した ( [放棄されたジョブ](cleanup.html#abandoned-jobs) を参照) | 管理対象ホストを確認する、再起動する、削除する |
+
+`running` は青、 `success` は緑で **成功** と表示され、 `failed` は赤です。 `approve` はオレンジで **承認待ち** と表示されるため、
+人の対応を待っているジョブは停止したジョブと区別できます。 `warning`、 `aborted`、 `rejected` は琥珀色です。 `abandoned` は
+グレーです。誰かが停止したのではなく、実行していたものがなくなったことを示します。
+
+---
+
+## ジョブの種類
+
+ジョブの種類は、ジョブを開始したフォームの `type` に従い、一覧とジョブのページに次のように表示されます。
+
+| 表示される種類 | 実行されるもの |
+|---|---|
+| `ansible` | RTE で実行される Ansible の playbook |
+| `awx`、 `aap`、 `ascender` | AWX、AAP、Ascender のジョブテンプレートまたはワークフローテンプレート |
+| `semaphore` | Semaphore UI のテンプレート |
+| `rundeck`、 `jenkins` | Rundeck または Jenkins のジョブ |
+| `workflow` | [ワークフロー](../workflows/)。playbook ノードはその下で個別のジョブとして実行されます |
+| `multistep` | 非推奨です。 `workflow` を使ってください。一連のステップで、各ステップはメインジョブの下に個別のジョブとして記録されます |
+
+テンプレートのジョブは `awx` ジョブとして (REST API でも) 保存され、フォームでの呼び方にかかわらず、実行されたランナーの種類で
+表示されます。たとえば、AAP ランナーで実行される `awx` タイプのフォームは `aap` と表示されます。
+
+フォーム側については、 [Ansible フォーム](../forms/ansible.html)、 [AWX フォーム](../forms/awx.html)、 [ワークフローフォーム](../forms/workflow.html)、
+[マルチステップフォーム](../forms/multistep.html) を参照してください。
diff --git a/i18n/ja/_use/jobs/stored-jobs.md b/i18n/ja/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..91c4e6a
--- /dev/null
+++ b/i18n/ja/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: 保存済みジョブ
+parent: ジョブ
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# 保存済みジョブ
+{: .no_toc }
+
+フォームのデータを保存して後で再び読み込む
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 保存済みジョブ
+
+保存済みジョブはフォームの値を保存しておくもので、毎回同じフィールドに入力する代わりに、その値を再び読み込めます。
+
+保存するには、フォームに入力し、 **送信** の横のドロップダウンを開いて **ストア** を選びます。 **フォームデータを保存** で
+**名前**、任意の **説明**、 **有効期限 (任意)** の日付を入力して保存します。パスワードと定数のフィールドは
+保存されません。サブフォームにも **保存** ボタンの横に同じ **ストア** 操作があり、入力途中の値を検証せずに
+保存します。
+
+読み込むには、フォームの上部で **保存済みデータから読み込む** を選びます。 **保存したフォームを読み込む** に、そのフォームの保存済みジョブが
+作成日と有効期限とともに一覧表示されます。1 つ選ぶと、その値がフォームに入力されます。送信するまで何も実行されません。
+
+保存済みジョブは AnsibleForms のデータベース (テーブル `stored_jobs` ) に、フォーム名、 `<type>/<username>` 形式のユーザー
+(たとえば `local/admin` )、JSON 形式の値とともに保存されます。名前はユーザーとフォームごとに一意である必要があり、
+同じ名前で 2 つ目を保存しようとすると「A saved form with this name already exists」で失敗します。
+
+---
+
+## 保存済みジョブを管理する
+
+**保存済みジョブ** ページには、保存済みジョブがフォーム、ユーザー、作成日、有効期限とともに一覧表示されます。 `allowStoredJobs` が必要です。
+
+- **編集** で、保存済みジョブ自体のページを開きます。 **詳細** (名前、フォーム、有効期限) と **値** (保存された
+  フィールド値の YAML) があり、そこで変更して保存できます。
+- **フォームで開く** で、保存された値を入力した状態でフォームを開きます。送信するまで何も実行されません。
+- **削除** で削除します。自分の保存済みジョブは削除でき、 `showSettings` を持つユーザーはどれでも削除できます。
+- **有効期限** が過ぎた保存済みジョブは、毎日 04:00 ( `LOG_TZ` ) に自動的に削除されます。
diff --git a/i18n/ja/_use/profile/account.md b/i18n/ja/_use/profile/account.md
new file mode 100644
index 0000000..e9da798
--- /dev/null
+++ b/i18n/ja/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: アカウント
+parent: プロフィール
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# アカウント
+{: .no_toc }
+
+どのユーザーとしてサインインしているか
+{: .fs-6 .fw-300 }
+
+---
+
+アカウントビューには、どのユーザーとしてサインインしているかと、アクセス権を決めている要素が表示されます。
+
+- **ユーザー名** と **ログインの種類**: ローカルアカウント、LDAP、Microsoft Entra ID、OpenID Connect のいずれかです。
+- **グループ**: ログインに付随するグループです。たとえば `local/admins` や `ldap/Domain Admins` などです。
+- **ロール**: `config.yaml` のロールのうち、これらのグループとユーザーに一致するものです。ロールによって、
+  表示されるフォームと使用できるオプションが決まります。
diff --git a/i18n/ja/_use/profile/api-token.md b/i18n/ja/_use/profile/api-token.md
new file mode 100644
index 0000000..dd2bf40
--- /dev/null
+++ b/i18n/ja/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: API トークン
+parent: プロフィール
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# API トークン
+{: .no_toc }
+
+スクリプトや AI エージェント用のトークンを作成する
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 作成できるユーザー
+
+有効期間の長いトークンを使うと、スクリプトはパスワードなしで API を呼び出せます。7.3.0 以降、作成には `allowApiTokens` ロールオプションが必要です。
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+7.2.0 までは、このオプションは `extendedTokenExpiration` だけでした。7.3.0 より前のロールでこのオプションだけを設定しているものには
+`allowApiTokens` が付与されるため、既存のトークンはそのまま使えます。両方を設定すると、期限のないトークンも作成できます。 [ロールオプション](../config/roles.html#role-options) を参照してください。
+
+---
+
+## トークンを作成する
+
+**プロフィール > API トークン** のタイトル行にある **新しいトークン** をクリックすると、3 ステップのウィザードが開きます。
+
+1. **詳細**: 一覧でトークンを見分けるための名前と、有効期間を指定します。選択肢は 30、90、180、
+   365 日のうち [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (既定は 90) までのもの、
+   その上限値そのもの、そして `extendedTokenExpiration` がある場合は **期限なし** です。スクリプトに必要な最短の期間を選んでください。
+2. **確認**: ローカルまたは LDAP のアカウントはパスワードを入力します。パスワードはトークンには保存されません。Microsoft Entra ID や
+   OIDC のアカウントはここではパスワードがありません。トークンはセッションから作成され、そのセッションは 10 分以内に
+   サインインしたものである必要があるため、先にプロバイダーから再サインインを求められることがあります。
+3. **コピー**: トークンが表示されます。表示されるのは **一度だけ** です。 **コピー** でコピーし、パスワードと同じように安全に保管してください。
+
+API を呼び出すたびに、トークンを `Authorization` ヘッダーで送ります。
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+API トークンから別のトークンを作成することはできません。SSO アカウントのトークンには、最後にサインインしたときのロールが含まれます。ID
+プロバイダー側でグループを変更しても、再度サインインして新しいトークンを作成するまでは反映されません。
+
+---
+
+## 自分のトークン
+
+作成したトークンは、名前、作成日時、有効期限、最終使用日時とともに一覧に表示されます。行のメニューにある **取り消す** でトークンを無効にできます。
+管理者も **設定 > ユーザー** のあなたのページでトークンを確認し、取り消すことができます。トークンは有効期限で終了するほか、次の場合にはそれより早く終了します。
+
+- 一覧からの **取り消し**
+- **トークンを使ったログアウト** ( `Authorization` ヘッダーにトークンを付けた `POST /api/v2/auth/logout` )。トークンが作成された
+  セッションとともに終了します。
+- **パスワードの変更**。それ以前に作成されたアカウントのすべてのトークンとセッションが終了します。アカウントのブロックも同様です。
+
+期限のないトークンも、これらの場合には終了します。スクリプトはログイン API とその `expiryDays` パラメーターを使って、自分でトークンを
+要求することもできます ( `POST /api/v2/auth/login?expiryDays=90` または `expiryDays=never` )。 `API_TOKEN_MAX_DAYS` より長い `expiryDays` は
+その値に切り詰められます。
diff --git a/i18n/ja/_use/profile/index.md b/i18n/ja/_use/profile/index.md
new file mode 100644
index 0000000..e36ebae
--- /dev/null
+++ b/i18n/ja/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: プロフィール
+nav_order: 4
+description: アカウント、個人設定、パスワード、権限、API トークン
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# プロフィール
+{: .no_toc }
+
+アカウント、個人設定、パスワード、権限、API トークン
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+すべてのユーザー向け: 自分のアカウント、個人設定、パスワード、権限、API トークンについて説明します。
+
+プロフィールは、右上のアバターから **プロフィール** を選んで開きます。
+
+---
+
+## ビューを開く
+
+左側のメニューには、プロフィールのビューがアルファベット順に並んでいます。各ビューには固有のアドレスがあるため、
+直接リンクできます。
+
+| ビュー | アドレス |
+|---|---|
+| アカウント | `/profile/account` |
+| API トークン | `/profile/token` |
+| パスワード | `/profile/password` |
+| 権限 | `/profile/permissions` |
+| 個人設定 | `/profile/preferences` |
+
+`/profile` だけを指定すると、メニューの最初のビューが開きます。ロールで許可されていないビューは表示されず、そのアドレスを開くと代わりに最初の
+ビューが開きます。 **API トークン** は、ロールのいずれかに `allowApiTokens` ロールオプションがある場合にだけ表示されます。
+
+---
+
+## このセクションの内容
+
+各トピックはそれぞれのページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [アカウント](account.html) | どのユーザーとしてサインインしているか |
+| [個人設定](preferences.html) | 言語、テーマ、タイムゾーン、日付形式、デスクトップ通知 |
+| [パスワード](password.html) | ローカルアカウントのパスワードを変更する |
+| [権限](permissions.html) | ロールで何が許可されているか |
+| [API トークン](api-token.html) | スクリプトや AI エージェント用のトークンを作成する |
diff --git a/i18n/ja/_use/profile/password.md b/i18n/ja/_use/profile/password.md
new file mode 100644
index 0000000..c766663
--- /dev/null
+++ b/i18n/ja/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: パスワード
+parent: プロフィール
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# パスワード
+{: .no_toc }
+
+ローカルアカウントのパスワードを変更する
+{: .fs-6 .fw-300 }
+
+---
+
+現在のパスワードと新しいパスワードを 2 回入力し、 **パスワードの変更** をクリックします。
+
+LDAP、Entra ID、OpenID Connect のアカウントは、それぞれのプロバイダー側でパスワードを変更します。
diff --git a/i18n/ja/_use/profile/permissions.md b/i18n/ja/_use/profile/permissions.md
new file mode 100644
index 0000000..671bc4d
--- /dev/null
+++ b/i18n/ja/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: 権限
+parent: プロフィール
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# 権限
+{: .no_toc }
+
+ロールで何が許可されているか
+{: .fs-6 .fw-300 }
+
+---
+
+ロールオプションはタブごとにまとめられており、各タブには、そのタブのオプションのうち自分が持っている数が `5/8` のように表示されます。
+
+| タブ | 対象のオプション |
+|---|---|
+| **アクセスと連携** | サインイン、チャットアシスタント、MCP サーバー、ファイルのアップロード、API トークン |
+| **デザイナー** | デザイナーを開くこと、およびフォーム、playbook、ワークフロー、インベントリ、変数ファイルの編集 |
+| **ジョブ** | ジョブとその extravars やアーティファクトの表示、再起動、削除、スケジュール設定、ジョブの保存 |
+| **設定** | 設定ページ、ログ、監査ログ、バックアップ |
+| **その他** | ロールに手動で設定した、ほかのどのタブにも属さないオプション。常に最後のタブです |
+
+それ以外のタブはアルファベット順に並びます。各タブは表になっており、 **設定** (オプション)、 **説明**
+(その働き)、 **あなたのアクセス権** ( **許可** または **不許可** ) の列があります。別のオプションによって適用されるオプションには、
+説明の下にその旨が表示されます。 **〜に含まれます** は、持っているオプションによって有効になっていることを、 **〜が必要です** は、持っていないオプションのために無効のままであることを示します。
+
+オプションは `config.yaml` にあるロールの `options` から決まります。オプションがどう組み合わされるかは
+[ロール](../config/roles.html) のページで説明しています。
diff --git a/i18n/ja/_use/profile/preferences.md b/i18n/ja/_use/profile/preferences.md
new file mode 100644
index 0000000..ed97b10
--- /dev/null
+++ b/i18n/ja/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: 個人設定
+parent: プロフィール
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# 個人設定
+{: .no_toc }
+
+言語、テーマ、タイムゾーン、日付形式、デスクトップ通知
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 個人設定の項目
+
+個人設定ビューでは、自分に対する AnsibleForms の見た目を変更できます。それぞれの選択は、設定を行ったブラウザーに
+保存されるため、別のブラウザーやコンピューターでは既定値から始まります。
+
+| 設定 | 選択肢 | ほかに設定できる場所 |
+|---|---|---|
+| 言語 | Català、Deutsch、English、Español、Français、Italiano、Nederlands、Polski、Português、日本語、简体中文 (簡体字中国語) | ヘッダーの国旗 |
+| テーマ | ブラウザーに合わせる、ライト、ダーク、色 (選んだ色のヘッダー) | ヘッダーの太陽アイコン |
+| フォームの表示 | タイルまたはリスト | フォームページのボタン |
+| タイムゾーン | UTC、このブラウザーのタイムゾーン、または名前で指定した任意のタイムゾーン | ここのみ |
+| 日付形式 | `YYYY-MM-DD`、 `DD/MM/YYYY`、 `MM/DD/YYYY`、 `DD.MM.YYYY` | ここのみ |
+| デスクトップ通知 | オンまたはオフ | ここのみ |
+
+7.3.0 以降、このビューはタブに分かれており、各タブに固有のアドレス ( `/profile/preferences/<tab>` ) があります。 **外観** (言語、テーマ、フォームの
+表示)、 **日付と時刻** (タイムゾーンと日付形式)、 **通知** の 3 つです。上の検索ボックスには、一致する設定がタブ名の下に
+一覧表示されます。選択内容は **保存** するまで下書きのままで、変更を保存せずにビューを離れようとすると確認を求められます。
+
+**ブラウザーに合わせる** は、ブラウザーと同じようにライトまたはダークに切り替わり、ブラウザーの変更にも追従します。7.3.0 以降の既定のテーマで、
+管理者が別のテーマを選んでいない限りこれが使われます。 **色** テーマの色にポインターを合わせると、ここでもヘッダーのテーマメニューでも、その色でアプリを
+プレビューでき、ポインターがパレットから離れると元のテーマに戻ります。クリックするまでは何も変わりません。
+
+---
+
+## デスクトップ通知
+
+7.3.0 以降、 **通知** タブでは、ロールで `showJobs` が設定されているユーザーに対して、このブラウザーでのデスクトップ通知を有効にできます。
+
+初回はブラウザーが許可を求めます。ブラウザーがこのサイトの通知をブロックしている場合、スイッチはオフのままになり、許可する方法が
+表示されます。また、通常の `http` のサイトでは通知をまったく表示できません。有効にすると、次のときに通知が届きます。
+
+| タイミング | 内容 | クリックしたとき |
+|---|---|---|
+| 自分が起動したジョブが終了したとき | フォームとその結果 ( *Patch Linux servers: 成功* など)、ジョブ番号、所要時間 | そのジョブを表示した状態でタブを前面に出します |
+| ジョブが自分の承認を待っているとき | フォーム、ジョブ番号、起動したユーザー、 **承認** ボタンと **拒否** ボタン | 承認待ちのジョブを開きます |
+
+**承認** ボタンと **拒否** ボタンは Chrome と Edge で表示されます。Firefox と Safari ではボタンなしで通知が表示され、自己署名証明書を使った
+サイトでも同様です。ボタンには Service Worker が必要なためです。通知が届くのは、AnsibleForms のタブが開いている間だけです (バックグラウンドでもかまいません)。
+タブをすべて閉じると何も送られません。開いているタブの数にかかわらず、各通知は 1 回だけ表示されます。また、マルチステップ
+ジョブの各ステップと、現在表示しているジョブについては通知されません。
+
+---
+
+## タイムゾーン
+
+AnsibleForms 全体の日付と時刻は、選択したタイムゾーンで表示されます。対象には、ジョブの開始
+時刻と終了時刻、監査ログ、ステータスページ、バックアップ、保存済みジョブ、API
+トークンの有効期限が含まれます。タイムゾーンを変更すると、再読み込みしなくてもすべてのページがすぐに更新されます。
+
+自分で選ぶまでは、管理者が全員向けに設定したタイムゾーンが適用されます ( **設定 > 外観 > 既定値** 、
+[外観](../appearance.html) を参照)。変更されていなければ **UTC** です。 **このブラウザー** はコンピューターのタイムゾーンに従い、
+一覧には `Europe/Madrid` のように名前ですべてのタイムゾーンが含まれます。カードには、選択したタイムゾーンと形式での現在時刻が表示されます。
+
+---
+
+## 日付形式
+
+日付形式では、すべての日付の日付部分の表記を設定します。各選択肢は今日の日付で表示されます: `YYYY-MM-DD`
+(2026-10-12)、 `DD/MM/YYYY`、 `MM/DD/YYYY`、 `DD.MM.YYYY`。自分で選ぶまでは管理者の既定の日付形式が
+適用され、変更されていなければ `YYYY-MM-DD` です。ほかの選択と同様に、このブラウザーに保存されます。
+
+---
+
+## サーバーの時刻のまま表示されるもの
+
+次の 2 つは例外で、サーバー自体の時刻のまま表示されます。
+
+- **サーバーログとジョブの出力** は、サーバーが書き込んだ時刻を含むテキストです。
+- **自分で入力する時刻** (予定したジョブの実行時刻など) と cron スケジュールは、
+  これまでどおりに動作します。
diff --git a/i18n/ja/_use/repositories/adding.md b/i18n/ja/_use/repositories/adding.md
new file mode 100644
index 0000000..172c5ef
--- /dev/null
+++ b/i18n/ja/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: リポジトリの追加
+parent: Git リポジトリ
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# リポジトリの追加
+{: .no_toc }
+
+リポジトリページ、リポジトリの各フィールド、設定シードでの宣言
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## リポジトリページ
+
+リポジトリは **設定 > 接続 > リポジトリ** で管理します。このページには `showSettings`、または 7.3.0 以降は
+`showConnectionsSettings` [ロールオプション](../config/roles.html#role-options) が必要です。一部の変更は管理者しか行えません。 [後述](#who-may-change-a-repository) を参照してください。
+
+![リポジトリ](../assets/screenshots/git.jpg)
+
+一覧には **名前**、 **説明**、 **ブランチ**、 **HEAD** (チェックアウトされているコミットの短縮ハッシュ)、 **プル**、
+**プッシュ** が表示されます。リポジトリの **詳細** タブでも、HEAD の上に同じプルとプッシュのバッジが表示されます。
+
+| 列 | 意味 |
+|---|---|
+| **プル** | 前回のクローン、プル、リセットの結果。git の処理中は **実行中**、その後は **成功** または **失敗**。初回までは「-」 |
+| **プッシュ** | 前回のプッシュが失敗した場合は **失敗**。ここで (デザイナーによって) 保存した変更がまだリモートにプッシュされていない場合は **保留中の変更**。待機中のものがなければ **成功**。初回のプッシュまでは「-」 |
+
+プッシュ列の **成功** は、プッシュ待ちのものがないという意味にすぎません。リモートには、プルで取り込まれる新しいコミットがまだあるかもしれません。
+各行のメニューには次の操作があります。
+
+| 操作 | 内容 |
+|---|---|
+| **編集** | 下記のフィールドを変更します |
+| **プル** | リポジトリをクローンします。作業ツリーがすでにある場合はプルします |
+| **プッシュ** | 作業ツリーをコミットしてプッシュします。フォーム、設定、playbook、ワークフロー、インベントリに使用するリポジトリでのみ使え、まだプッシュしていない変更がある間だけ有効です |
+| **リセット** | 作業ツリーを削除して再度クローンします。ローカルの変更は破棄されます |
+| **資格情報を変更** | リポジトリの **認証情報** タブを開き、git が使う認証情報を選びます |
+| **前回のプルの出力を表示** | 前回のクローン、プル、リセットの git の出力を、パスワードをマスクして表示します |
+| **前回のプッシュの出力を表示** | 前回のプッシュの git の出力を、パスワードをマスクして表示します |
+| **削除** | レコードと `REPO_PATH` 配下の作業ツリーを削除します。管理者のみ実行できます |
+
+一覧の上にある **すべてプル** で、すべてのリポジトリを一度にプルします。
+
+1 つのリポジトリで同時に実行される git 操作は 1 つだけです。2 つ目の操作は
+`Repository '<name>' not found or already running, try again later` で拒否されます。
+
+---
+
+## リポジトリを追加する
+
+**リポジトリを追加** をクリックすると、ウィザードが 4 つのステップ ( **リポジトリ**、 **認証情報**、 **用途**、 **プルの
+スケジュール** ) でフィールドを尋ねます。保存するとすぐに、AnsibleForms がバックグラウンドでクローンを開始します。
+
+![リポジトリの編集](../assets/screenshots/git-edit.jpg)
+
+| フィールド | 必須 | 意味 |
+|---|---|---|
+| **名前** | はい | `REPO_PATH` 配下のフォルダー名。英字、数字、ハイフン、アンダースコア、ドットが使えます |
+| **ブランチ** | はい | クローン、プル、プッシュするブランチ ( `main` など)。7.3.0 以降は必須です。省略できるのは設定シードのリポジトリだけで、その場合はリモートの既定のブランチがクローンされます |
+| **認証情報** | いいえ | git が使うユーザーとパスワードまたはトークンを持つ、 [接続 > 認証情報](../credentials.html) の認証情報。 **認証情報を追加** で新しく作成できます |
+| **URI** | はい | リモート。 `https://...` または SSH ( `git@git.example.com:team/forms.git`、 `ssh://...` ) |
+| **定期プルを有効にする** | いいえ | スケジュールに従ってリポジトリをプルします |
+| **プルのスケジュール** | いいえ | プルするタイミングを cron 式で指定します。定期プルを有効にすると表示されます |
+| **説明** | はい | 自由記述の説明 |
+| **設定に使用しますか?** ... **インベントリに使用しますか?** | いいえ | リポジトリが保持するもの。 [前述](./#what-a-repository-is-for) を参照してください |
+| **アプリ起動時にプル** | いいえ | AnsibleForms の起動時に毎回リポジトリをクローンまたはプルします |
+
+リポジトリの名前を変更すると、作業ツリーが新しいフォルダーに移動し、プルのスケジュールも一緒に移ります。バージョン 7
+より前のリポジトリで独自のユーザーを持っているものは、 **認証情報** タブにその旨が表示されます。認証情報を選んで置き換えてください。
+
+---
+
+## リポジトリを変更できるユーザー
+
+リポジトリの内容は AnsibleForms が読み込んで実行するものになるため、7.3.0 以降、 `admin` ロールを持たないユーザーは次の操作ができなくなりました。
+
+- リポジトリの追加または削除
+- **URI** または **ブランチ** の変更
+- **〜に使用** フラグのオンとオフの切り替え
+
+説明、プルのスケジュール、認証情報の変更や、プル、プッシュ、リセットは引き続き行えます。ランナー、
+接続、サインインで使われている認証情報は選択できません。拒否された場合はその認証情報の名前が示されますが、中身については何も表示されません。
+
+---
+
+## 設定シードでリポジトリを宣言する
+
+リポジトリは [設定シード](../seed/) でも宣言できます。こうしておくと、新しいインスタンスは初回起動時にそのリポジトリをクローンします。
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+フィールドはページのものと同じで、 `credential` (シードまたはアプリの認証情報)、 `rebase_on_start` ( **アプリ起動時に
+プル** )、 `cron` (プルのスケジュール) も含まれます。認証情報の代わりに `user` と `password` も引き続き使用できます。シードで
+作成したリポジトリはインターフェイス上では読み取り専用で、作業ツリーがない場合は起動時に再度クローンされます。
+[管理対象オブジェクト](../seed/managed-objects.html) を参照してください。
diff --git a/i18n/ja/_use/repositories/authentication.md b/i18n/ja/_use/repositories/authentication.md
new file mode 100644
index 0000000..6ebd370
--- /dev/null
+++ b/i18n/ja/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: 認証
+parent: Git リポジトリ
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# 認証
+{: .no_toc }
+
+トークンを使った HTTPS、生成された鍵を使った SSH、カスタム git コマンド
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 認証
+
+AnsibleForms の認証方法は、 **URI** の形式によって決まります。
+
+### トークンを使った HTTPS
+
+プライベートな HTTPS リモートの場合は、ユーザーが git ユーザーで、パスワードが個人用アクセストークン (またはパスワード) である
+**認証情報** を選びます。
+
+7.3.0 以降、git は `GIT_ASKPASS` を通じてサインインします。ユーザーとトークンはサーバーと通信する各 git コマンドに渡され、URL に
+含まれることはありません。そのため、クローンの `.git/config` には残らず、トークンを変更すると次回のプルまたはプッシュから新しいトークンが使われます。トークンには、
+プルには読み取り権限、プッシュには書き込み権限が必要です。公開リモートには認証情報は不要です。
+
+7.2.0 までは、両方が `https://<user>:<token>@git.example.com/team/forms.git` のように URL に埋め込まれていました。その当時に作成したクローンは、
+次回のプルまたはプッシュでリモートがリポジトリ自身の **URI** に戻されるまで、その URL を保持します。
+
+### 生成された鍵を使った SSH
+
+SSH リモートの場合、AnsibleForms は初回起動時に生成する独自の鍵ペアで認証します。
+
+1. **設定 > 接続 > SSH** の **キー** タブを開き、 **公開鍵** をコピーします。
+2. git サーバーで、リポジトリのデプロイキーとして (プッシュする場合は書き込み権限付きで)、またはアクセス権を持つユーザーに追加します。
+3. `git@git.example.com:team/forms.git` のような SSH の **URI** でリポジトリを追加し、認証情報は選びません。
+
+鍵ペアは [`HOME_PATH`](../customization/paths.html#env_HOME_PATH) 配下の `.ssh/id_rsa` に置かれます。このフォルダーは
+永続ストレージに置いてください。そうしないと、コンテナーを再作成したときに鍵が変わってしまいます。
+
+`user@host:path` 形式の URI でクローンする場合、AnsibleForms はまずそのホストに対して `ssh-keyscan` を実行し、ホストの鍵を
+既知のホストに追加します。それ以外のリモートでは、最初のクローンの前に **設定 > 接続 > SSH** の **既知のホスト** タブでホストを
+追加してください。
+
+### カスタム git コマンド
+
+クローン、プル、プッシュのコマンドは、git のオプションを追加するなどの目的で、3 つの設定によって置き換えられます。
+
+| 設定 | 既定値 | AnsibleForms が追加するもの |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`、 `--verbose`、URI、名前 |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+7.3.0 以降、これらのコマンドはシェルを介さずに実行されます。引用符は使えますが、 `;`、 `|`、 `&&`、 `>` などのシェル演算子は拒否されます。
diff --git a/i18n/ja/_use/repositories/designer.md b/i18n/ja/_use/repositories/designer.md
new file mode 100644
index 0000000..282e725
--- /dev/null
+++ b/i18n/ja/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: デザイナーとプッシュ
+parent: Git リポジトリ
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# デザイナーとプッシュ
+{: .no_toc }
+
+デザイナーでフォームを編集し、リポジトリにプッシュする
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## デザイナーからの編集とプッシュ
+
+フォームに使用するリポジトリがある場合、デザイナーはその作業ツリー内のファイルを編集し、リモートにプッシュします。
+
+| ボタン | 内容 |
+|---|---|
+| **保存 (ローカル)** | フォームと `config.yaml` を作業ツリーに書き込みます。コミットはしません |
+| **保存 (リポジトリ)** | 保存した変更をコミットしてプッシュします。未プッシュの変更がある場合に有効になります |
+| **読み込み (リポジトリ)** | フォームリポジトリをプルしてデザイナーを再読み込みします。未保存の編集がある場合は確認が求められます |
+
+フォームはそのリポジトリに置かれたままです。新しいフォームは、プッシュするまで [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) で待機しますが、その間も使用できます。
+サブフォルダーに保存したフォームは相対パスを保持します。 `team/deploy.yaml` は、リポジトリのフォームフォルダー配下の `team/deploy.yaml` に
+プッシュされます。新しいフォームのパスがすでにリポジトリに存在する場合は上書きされず、ステージングに残るので、名前を変更してください。
+フォームリポジトリが複数ある場合、 **保存 (リポジトリ)** と **読み込み (リポジトリ)** はどのリポジトリを使うかを尋ねます。既定は `config.yaml` のあるリポジトリです。
+
+プッシュでは、すべての変更をステージングし、 `AnsibleForms` として `Forms sync by <user>` というメッセージでコミットしてから、フェッチし、リモートに
+リベースしてプッシュします。最大 5 回まで再試行します。リベースで競合が発生した場合は中止され、競合したファイルが一覧表示されます。
+リモート側で修正するか、リポジトリページで **リセット** を使ってください。リポジトリページの **プッシュ** も同じ処理を行います。
+
+フォームリポジトリが 1 つだけで、空の状態でクローンされた場合、AnsibleForms はローカルの `config.yaml` とフォームをその作業
+ツリーにコピーします。そのため、プッシュ ( **保存 (リポジトリ)** 、またはリポジトリページの **プッシュ** ) でそれらが公開されます。デザイナーの詳細は [デザイナーと git](../gui/designer-and-git.html) を参照してください。
diff --git a/i18n/ja/_use/repositories/index.md b/i18n/ja/_use/repositories/index.md
new file mode 100644
index 0000000..2461b01
--- /dev/null
+++ b/i18n/ja/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Git リポジトリ
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Git リポジトリ
+{: .no_toc }
+
+フォーム、変数ファイル、設定、playbook を git で管理する
+{: .fs-6 .fw-300 }
+
+---
+
+フォーム、設定、playbook を git で管理する管理者向け: リポジトリに置けるものと、どのソースが優先されるかを説明します。
+
+---
+
+## リポジトリの用途
+
+リポジトリとは、AnsibleForms がクローンして最新の状態に保つ git リモートです。リポジトリごとに、何を保持しているかを示すスイッチがあります。
+
+| スイッチ | AnsibleForms が読み取るもの | リポジトリ内のフォルダー |
+|---|---|---|
+| **設定に使用しますか?** | カテゴリ、ロール、定数を含む `config.yaml` | ルート |
+| **フォームに使用しますか?** | フォームファイル (デザイナーもここに保存します) と、その変数ファイル | `forms` またはルート。変数ファイルは `vars` |
+| **playbook に使用しますか?** | ジョブが実行する Ansible の playbook | `playbooks` またはルート |
+| **ワークフローに使用しますか?** | [ワークフロー](../workflows/) ファイル (デザイナーもここに保存します) | 任意のフォルダー |
+| **インベントリに使用しますか?** | リポジトリ名を名前とする 1 つのインベントリ。フォームは `inventory:` でこれを指定します | ルート: `inventory.yaml`、 `group_vars`、 `host_vars` |
+
+サブフォルダーがない場合は、リポジトリのルートが使われます。1 つのリポジトリにすべてを入れることもできます。分ける場合、複数のリポジトリで有効にできるのは **フォームに使用しますか?**、
+**ワークフローに使用しますか?**、 **インベントリに使用しますか?** だけです。ほかのスイッチは最初のリポジトリが使われ、
+警告がログに記録されます。
+
+各リポジトリは、 [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) の下にあるリポジトリ名のサブフォルダーにクローンされます。
+
+### すべてを 1 つのリポジトリに
+
+1 つのリポジトリに、フォーム、変数ファイル、設定、playbook を入れることができます。その場合はスイッチを有効にし、種類ごとにサブフォルダーを 1 つずつ設けます。
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### 用途ごとに 1 つのリポジトリ
+
+リポジトリを分けると、チームがそれぞれの担当部分を管理できます。各リポジトリでスイッチを 1 つだけ有効にし、ファイルはルートに直接置きます。
+
+| リポジトリ | スイッチ | ルートの内容 |
+|---|---|---|
+| `af-config` | **設定に使用しますか?** | `config.yaml` |
+| `af-forms-network`、 `af-forms-storage` | **フォームに使用しますか?** | 各チームのフォームファイル。1 つの一覧にまとめられます |
+| `af-playbooks` | **playbook に使用しますか?** | playbook とロール |
+
+複数のリポジトリから取得できるのはフォームだけで、設定と playbook はそれぞれ 1 つのリポジトリから取得します。変数ファイルは、 `vars`
+フォルダーを持つ最初のフォームリポジトリから取得します。
+
+---
+
+## リポジトリとローカルフォルダーの組み合わせ
+
+リポジトリの内容は、対応するローカルフォルダーの代わりに使われます。次の表は、ファイルの種類ごとの読み取り元をまとめたものです。
+
+| 内容 | 読み取り元 (最初に一致したものが優先) |
+|---|---|
+| 設定 | 1. 設定をデータベースに保存している場合はデータベース ( [`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE) ) <br> 2. **設定に使用** するリポジトリの `config.yaml` <br> 3. 設定用のリポジトリがない場合は、 **フォームに使用** するリポジトリの `config.yaml` <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| フォーム | **フォームに使用** するすべてのリポジトリと `FORMS_STAGING_PATH`。 [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) はそれらがない場合のみ |
+| Playbook | **playbook に使用** するリポジトリ。ない場合は [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| 変数ファイル | `vars` フォルダーを持つ最初の **フォームに使用** するリポジトリのそのフォルダー。ない場合は [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| ワークフロー | **ワークフローに使用** するすべてのリポジトリと [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH) の両方 |
+
+複数のリポジトリのフォームは 1 つの一覧にまとめられます。2 つのリポジトリに同じ名前のフォームがある場合は、最初に読み込まれたものが
+残り、警告 `skipping duplicate form <name>` がログに記録されます。そのため、フォーム名はリポジトリ間で重複しないようにしてください。
+
+---
+
+## トラブルシューティング
+
+ほとんどの問題は **プル** 列と **前回のプルの出力を表示** (または **前回のプッシュの出力を表示** ) に現れ、そこには git 自体の
+エラーメッセージが含まれています。
+
+- [リポジトリのクローンまたはプルに失敗した](../troubleshooting.html#a-repository-clone-or-pull-failed): 認証、known
+  hosts、ローカルの変更。
+- [フォームリポジトリがまだクローンされていない](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): 最初のクローンが終わるまで、デザイナーは
+  保存できません。
+- `running` のまま止まったリポジトリは `failed` にリセットされます。再起動した場合は次回の起動時、git 操作を実行しているノードが
+  2 分間応答しなくなった場合は 1 分以内、いずれの場合でも 2 時間後にリセットされます。もう一度 **プル** を実行してください。
+
+---
+
+## このセクションの内容
+
+各トピックはそれぞれのページで説明しています。
+
+| ページ | 内容 |
+|---|---|
+| [リポジトリの追加](adding.html) | リポジトリページ、リポジトリの各フィールド、設定シードでの宣言 |
+| [認証](authentication.html) | トークンを使った HTTPS、生成された鍵を使った SSH、カスタム git コマンド |
+| [変更のプル](pulling.html) | スケジュール、手動、API によるプルと、ローカルの変更 |
+| [デザイナーとプッシュ](designer.html) | デザイナーでフォームを編集し、リポジトリにプッシュする |
diff --git a/i18n/ja/_use/repositories/pulling.md b/i18n/ja/_use/repositories/pulling.md
new file mode 100644
index 0000000..3e936f5
--- /dev/null
+++ b/i18n/ja/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: 変更のプル
+parent: Git リポジトリ
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# 変更のプル
+{: .no_toc }
+
+スケジュール、手動、API によるプルと、ローカルの変更
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 変更のプル
+
+リポジトリは、スケジュールに従って、起動時に、ページから、または API を通じてプルされます。Webhook のエンドポイントはありません。
+
+| トリガー | 方法 |
+|---|---|
+| スケジュール | **定期プルを有効にする** と **プルのスケジュール** 。たとえば `0 * * * *` で 1 時間ごと |
+| 起動時 | **アプリ起動時にプル** で、リポジトリをクローンするか、すでにクローン済みならプルします |
+| 設定ページ | 行メニューの **プル** 、または一覧の上の **すべてプル** |
+| デザイナー | **読み込み (リポジトリ)** 。フォームリポジトリをプルしてデザイナーを再読み込みします。デザイナーのロックを取得したときにも、先にすべてのフォームリポジトリがプルされます |
+| API | `POST /api/v2/repository/<name>/pull` ( `showSettings` または `showConnectionsSettings` ) または `POST /api/v2/forms-repos/pull/<name>` (下記参照) |
+
+### パイプラインや Webhook からプルする
+
+AnsibleForms には専用の Webhook 受信機能はありませんが、CI ジョブや git サーバーの Webhook からプルのエンドポイントを呼び出せます。
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+トークンは [API トークン](../profile/api-token.html) の説明に従い、ロールに `showSettings` または
+`showConnectionsSettings` を持つユーザーで作成します。 `/api/v2/forms-repos/pull/<name>` には代わりに `showDesigner` と `allowFormDesign` が必要で、デザイナーが
+有効になっている必要があります ( [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) )。 `GET /api/v2/repository/<name>` は
+`head`、 `status`、 `output` を返すため、パイプラインはプルの後にインスタンスがどのコミットで動いているかを確認できます。
+
+### ローカルの変更
+
+プルによって、まだプッシュされていない作業が上書きされることはありません。そのため、定期プルは実行前に作業ツリーを確認します。
+
+作業ツリーに未コミットの変更や未プッシュのコミットがある間、またはデザイナーが
+デザイナーのロックを保持している間は、定期プルはスキップされます。競合する変更がある作業ツリーを手動でプルすると、次のエラーで失敗します。
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+変更をプッシュするか、行メニューの **リセット** で破棄してください。リセットは作業ツリーを削除して再度クローンします。
diff --git a/i18n/ja/index.md b/i18n/ja/index.md
new file mode 100644
index 0000000..937d880
--- /dev/null
+++ b/i18n/ja/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: ホーム
+nav_order: 1
+description: "AnsibleForms: Ansible による自動化のための、データ駆動型の動的なフォームを作成できます"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc"><span>Ansible</span> のためのセルフサービスフォーム</h1>
+    <p class="af-hero-lead">
+      Ansible は強力な自動化ツールですが、あくまでコマンドラインのアプリケーションです。また AWX/AAP/Ascender には、
+      複数のソースからデータを集めるフォームがありません。AnsibleForms を使うと、データ駆動型の動的なフォームを作成して extravars を生成し、
+      それを Ansible、AWX/AAP/Ascender、Semaphore、Rundeck、Jenkins に送ってテンプレートを実行できます。
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">AnsibleForms をインストール</a>
+      <a href="first-form.html" class="btn btn-outline">最初のフォームを作成</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="AnsibleForms のダッシュボード">
+  </div>
+</div>
+
+## 機能
+
+AnsibleForms が Ansible 環境にもたらすものと、1 つのフォームでできることを紹介します。
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>アプリケーション</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>自動化プラットフォーム</strong><span>RTE での playbook、Ascender や Semaphore などでのテンプレート</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>アクセス制御</strong><span>ロールとロールオプション、ローカル、LDAP、Entra ID、OIDC によるログイン</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>スケジュール</strong><span>フォームを後で、または cron スケジュールで実行</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>ジョブ履歴</strong><span>ジョブの追跡、中止、再起動</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>認証情報とシークレット</strong><span>認証情報を保存するか、Vault や CyberArk から読み取る</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Git リポジトリ</strong><span>フォーム、playbook、設定を Git で管理</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>デザイナー</strong><span>検証付きで、フォームを YAML として編集</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API、MCP、チャット</strong><span>スクリプト、AI エージェント、チャットからフォームを起動</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>フォーム</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>連動するドロップダウン</strong><span>ほかのフィールドに応じて変わるドロップダウン</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>式とデータソース</strong><span>データベース、REST API、ファイル、JavaScript からフィールドに値を入れる</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>フィールドの依存関係</strong><span>ほかのフィールドに応じてフィールドを表示、非表示にする</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>検証</strong><span>最小値、最大値、正規表現など。必要に応じてサーバー側でもチェック</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>ワークフローとウィザードフォーム</strong><span>playbook と承認をつなげたり、入力を複数のページに分けたりする</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>構造化フィールド</strong><span>再利用できるサブフォームによるリストとオブジェクト</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>承認ポイント</strong><span>誰かが承認するまでジョブを一時停止</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>通知</strong><span>ジョブのイベントをメール、Slack、Teams、Telegram、Webhook で通知</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## お困りですか?
+
+質問、バグ、セキュリティの報告には、それぞれ専用の窓口があります。
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>トラブルシューティング</strong>
+    <span>エラーメッセージとその対処方法を調べる</span>
+    <span class="af-card-more">トラブルシューティング &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>質問する</strong>
+    <span>コミュニティとメンテナーに質問する</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>バグを報告する</strong>
+    <span>再現手順を添えて issue を作成する</span>
+    <span class="af-card-more">新しい issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>サポートを受ける</strong>
+    <span>伝えるべき情報と、セキュリティ問題の報告方法</span>
+    <span class="af-card-more">サポートを受ける &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/nl.yml b/i18n/nl.yml
new file mode 100644
index 0000000..c7e174d
--- /dev/null
+++ b/i18n/nl.yml
@@ -0,0 +1,42 @@
+# The Dutch docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: nl
+docs_language: "nl"
+
+title: "AnsibleForms-documentatie"
+description: "Technische documentatie van AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Alle rechten voorbehouden."
+
+# "Edit this page on GitHub" opens the Dutch page's source
+gh_edit_link_text: "Deze pagina bewerken op GitHub"
+gh_edit_source: i18n/nl
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Introductie"
+    get_started:
+      name: "Aan de slag"
+    configure:
+      name: "Configureren"
+    build_forms:
+      name: "Formulieren bouwen"
+    use:
+      name: "Gebruikershandleiding"
+    integrate:
+      name: "Integreren"
+    security_assessment:
+      name: "Beveiliging"
+    reference:
+      name: "Naslag"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (nieuwste)"
+    url: "/nl/"
+  - name: "6"
+    title: "6.x (in het Engels)"
+    url: "/v6/"
diff --git a/i18n/nl/_build_forms/expressions/credentials.md b/i18n/nl/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..f55c524
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Inloggegevens
+parent: Expressies
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Inloggegevens
+{: .no_toc }
+
+Opgeslagen inloggegevens lezen in een expressie
+{: .fs-6 .fw-300 }
+
+---
+
+Lees opgeslagen inloggegevens op naam of via een reguliere expressie, met een terugvaloptie:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Eerst wordt de exacte naam geprobeerd. Heeft geen enkele referentie die naam, dan wordt de naam als reguliere expressie gebruikt, en daarna wordt de terugvaloptie geprobeerd.
+
+#### Beperkt per rol
+
+Wanneer een van de rollen van de gebruiker `credentials` opsomt in `config.yaml`, geeft `fn.fnCredentials` alleen een referentie terug die zo'n rol
+toestaat: de patronen van de rol worden vergeleken met de naam van de gevonden referentie (op naam, via reguliere expressie of via de terugvaloptie),
+en elke andere wordt geweigerd. Rollen zonder die lijst beperken het niet, en een admin wordt nooit beperkt.
+
+#### Inloggegevens uit een secret store
+
+Een referentie die een [secret store](../secret-stores) noemt, haalt haar `user` en `password`
+tijdens de uitvoering uit die store. `fn.fnCredentials('myapp')` blijft ongewijzigd werken.
+
+Een geheim kan ook zonder rij met inloggegevens worden gelezen, overal waar een naam van een referentie wordt geaccepteerd
+(ook in `fnRestBasic`, `fnRestJwtSecure` en de headervervangingen van `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+De sleutels van het geheim worden gekoppeld zoals beschreven onder [Sleutelnamen](../secret-stores#key-names).
+Een geheim met een andere vorm wordt omgevormd met een `jq`-expressie als derde argument:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/nl/_build_forms/expressions/index.md b/i18n/nl/_build_forms/expressions/index.md
new file mode 100644
index 0000000..b5c11b4
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Expressies
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Expressies
+{: .no_toc }
+
+Bereken veldwaarden met JavaScript, in de browser of op de server
+{: .fs-6 .fw-300 }
+
+---
+
+Voor formulierauteurs: vul velden dynamisch met JavaScript, berekend in de browser of opgehaald op de server.
+
+Met het attribuut `expression` van een formulierveld maak je dynamische formulieren met JavaScript-expressies.
+
+---
+
+## Inleiding
+
+Het attribuut `expression` is beschikbaar op meerdere veldtypen:
+- `enum`-veld - om de opties van een keuzelijst dynamisch te vullen
+- `expression`-veld - om elke vorm van gegevens op te halen of te genereren
+- `html`-veld - om de HTML-inhoud op te bouwen
+- `yaml`- en `list`-velden - om hun gegevens te vullen
+
+JavaScript-expressies worden geëvalueerd aan de **serverkant** (standaard) of aan de **clientkant**, zoals ingesteld met de veldeigenschap `runLocal`.
+Een `html`-veld, en de veldtypen `local`, `local_out` en `credential`, voeren hun expressie altijd uit in de browser, wat
+`runLocal` ook zegt.
+
+- **Aan de serverkant** (`runLocal: false`, de standaard) - vooraf gedefinieerde functies die gegevens ophalen uit API's, bestanden en databases.
+- **Aan de clientkant** (`runLocal: true`) - de code benut de volledige JavaScript-engine in de sandbox van de browser voor berekeningen, transformaties en bewerkingen.
+
+---
+
+## Beveiligingsaspecten
+
+Omdat expressies worden geëvalueerd met de JavaScript-functie `eval`, is code-injectie een mogelijk risico:
+
+- **Expressies aan de serverkant** gaan eerst door een sanitizer: elke aanroep moet een `fn.`- of `fnc.`-functie zijn, en meerdere regels,
+  `;`, template literals, `process.env` en de uitwegen uit `eval` (`import`, `require`, `constructor`, ...) worden geweigerd.
+- **Expressies aan de clientkant** worden geëvalueerd in de sandbox van de browser en kunnen als veilig worden beschouwd.
+
+Hoe streng de sanitizer is, hangt af van
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER):
+
+| Waarde | Expressies aan de serverkant |
+|---|---|
+| `strict` (standaard) | `fn.`- en `fnc.`-aanroepen, en methoden op hun resultaat, zoals `fn.fnTime().format('YYYY')` |
+| `paranoid` | alleen directe `fn.`- en `fnc.`-aanroepen, geen methoden op hun resultaat |
+| `off` | elke expressie aan de serverkant wordt geweigerd; alleen `runLocal`-expressies werken |
+| `legacy` | de regels van 6.2.1, waarmee elke geauthenticeerde gebruiker code op de server kon uitvoeren; alleen voor een upgrade, en alleen in de echte omgeving (niet vanaf de instellingenpagina) |
+
+Een lege of onbekende waarde betekent `strict`. Een wijziging geldt voor de volgende expressie, zonder herstart.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Placeholders](placeholders.html) | Verwijs naar een ander veld, een constante of de gebruiker met `$(...)` |
+| [Lokale expressies](local.html) | JavaScript dat in de sandbox van de browser draait |
+| [Remote expressies](remote.html) | Functies aan de serverkant voor datums, netwerken, bestanden, SSH en genummerde namen |
+| [REST API's](rest-apis.html) | REST API's aanroepen met basic-, token- of eigen authenticatie |
+| [Inloggegevens](credentials.html) | Opgeslagen inloggegevens lezen |
+| [Sorteren](sorting.html) | Arrays sorteren met een sorteerobject |
+| [jq-query's](jq.html) | Gegevens omvormen met jq |
diff --git a/i18n/nl/_build_forms/expressions/jq.md b/i18n/nl/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..0c91ca9
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: jq-query's
+parent: Expressies
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# jq-query's
+{: .no_toc }
+
+Gegevens omvormen met jq, inclusief de ingebouwde functies
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Een JSON-query (jq) uitvoeren op een object
+
+Vorm een object om, bijvoorbeeld de waarde van een ander veld, met een jq-expressie:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+Vanaf 7.3.0 draait een jq-filter hooguit [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (standaard 30)
+voordat hij wordt gestopt, en de uitvoer is begrensd op 64 MB. Dit geldt voor `fn.fnJq` en voor de jq-expressie van de functies voor REST, bestanden,
+inloggegevens en databasequery's.
+
+---
+
+## Ingebouwde jq-functies
+
+Alle functies die gegevens ophalen, accepteren een JSON-query (jq), een taal om gegevensobjecten en arrays te bewerken.  
+Bij het bewerken van gegevens moet je soms bytes omrekenen naar KB, MB of GB, of getallen afronden.  
+Daarvoor heeft AnsibleForms een paar eigen jq-functies:
+
+- **fn2KB**: bytes naar KB
+- **fn2MB**: bytes naar MB
+- **fn2GB**: bytes naar GB
+- **fnRound0**: afronden op 0 decimalen
+- **fnRound1**: afronden op 1 decimaal
+- **fnRound2**: afronden op 2 decimalen
+- **fnRound**: afronden op 2 decimalen
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/nl/_build_forms/expressions/local.md b/i18n/nl/_build_forms/expressions/local.md
new file mode 100644
index 0000000..16185bc
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Lokale expressies
+parent: Expressies
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Lokale expressies
+{: .no_toc }
+
+JavaScript dat in de sandbox van de browser draait
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+De volgende voorbeelden draaien met de veldeigenschap `runLocal: true`.  
+Ze worden uitgevoerd in de sandbox van de browser en kunnen de volledige JavaScript-engine benutten.
+
+{: .note }
+> **Tip**: gebruik het type `local` als alias voor `type: expression, runLocal: true, hide: true, output: false`  
+> **Tip**: gebruik het type `local_out` als alias voor `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Naamgevingsconventie
+
+Gebruik stringbewerkingen om naamgevingsconventies toe te passen.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Berekening
+
+Gebruik wiskunde om berekeningen te maken.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Conversies
+
+Reken bytes om naar gigabytes.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Een array van objecten omzetten naar een HTML-tabel
+
+Zet een array van objecten, bijvoorbeeld uit een ander veld, om naar een HTML-tabel voor een `html`-veld:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Een naam met oplopende nummering ophalen
+
+Bij automatische nummering moet je soms de volgende naam vinden in een array van genummerde strings.  
+Deze functie is ook beschikbaar als expressie aan de serverkant (met het voorvoegsel `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Is het eerste argument geen array, dan geeft de lokale functie de standaardwaarde terug. De serverfunctie `fn.fnGetNumberedName`
+mislukt in dat geval met een fout.
+
+---
+
+## Arrays van objecten bewerken
+
+Arrays van objecten moeten vaak worden gefilterd, aangepast en gesorteerd.  
+AnsibleForms heeft een eigen hulpfunctie die deze code beknopt houdt.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Arrays van objecten bewerken met gewoon JavaScript
+
+Alle standaard arraymethoden van JavaScript blijven beschikbaar om je gegevens te filteren en aan te passen, zoals `map`, `forEach`, `find`, `filter` en `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/nl/_build_forms/expressions/placeholders.md b/i18n/nl/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..bf08dd6
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Placeholders
+parent: Expressies
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Placeholders
+{: .no_toc }
+
+Verwijs naar een ander veld, een constante of de huidige gebruiker met `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wat een placeholder is
+
+Een placeholder is een verwijzing in de vorm `$(reference)`. Die wordt door een waarde vervangen voordat de tekst waarin hij staat wordt gebruikt.
+
+Placeholders werken in `expression`, `query` en `default` van een veld (geëvalueerd met `evalDefault`), en in `label`,
+`help` en `placeholder`. Een veld met een placeholder hangt af van het veld dat de placeholder noemt: het wacht tot dat veld een
+waarde heeft, en wordt opnieuw geëvalueerd telkens als die waarde verandert. Zo bouw je trapsgewijze keuzelijsten.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## Waarnaar een placeholder kan verwijzen
+
+Een placeholder noemt een veld van het formulier, of een van deze, die elk formulier heeft:
+
+| Verwijzing | Wat erin zit |
+|---|---|
+| `$(field)` | de waarde van een ander veld van het formulier |
+| `$(name)`, een constante | een [constante](../config/constants.html) uit `config.yaml`, of een waarde uit de `varsFiles` van het formulier |
+| `$(__user__)` | de aangemelde gebruiker: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | in een [subformulier](../forms/subform.html) (een rij van een lijst, een stap van een wizard), een waarde van het bovenliggende formulier |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Een deel van een waarde lezen
+
+Met punt- en indexnotatie lees je een deel van een waarde, zolang het pad alleen letters, cijfers, `_`, `-`, `.` en `[n]` bevat:
+
+| Placeholder | Op | Geeft |
+|---|---|---|
+| `$(field)` | een tekst-, getal- of wachtwoordveld | de waarde |
+| `$(field)` | een enum met records | de `placeholderColumn` van het geselecteerde record, anders de eerste kolom |
+| `$(field.col)` | een enum met records | die kolom van het geselecteerde record |
+| `$(field)` | een enum met `multiple: true` | de gekozen kolom van elk geselecteerd record, als array |
+| `$(field)` | een expressie, lijst of constante | de hele waarde (een lijst geeft haar rijen) |
+| `$(field.a.b)`, `$(f[0].x)` | een expressie, lijst of constante | dat deel van het object of de array |
+
+Met `placeholderColumn: "*"` op een enum geeft `$(field)` het hele geselecteerde record in plaats van één kolom.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Hoe de waarde wordt ingevoegd
+
+Hoe een waarde in de tekst wordt ingevoegd, hangt af van waar de placeholder staat.
+
+| Waar | Voorbeeld | Wordt |
+|---|---|---|
+| een expressie, buiten aanhalingstekens | `$(count) + 1` | een JavaScript-literal: een getal blijft een getal, een tekst wordt een string tussen aanhalingstekens, een object of array een literal |
+| een expressie, een volledige string tussen aanhalingstekens | `fn.fnLs('$(dir)')` | dezelfde literal, aanhalingstekens inbegrepen, zodat een waarde met een aanhalingsteken erin niet kan ontsnappen |
+| een expressie, binnen een langere string | `'$(dir)/vars'` | de tekst, ge-escaped voor die string |
+| een query, een label, een helptekst | `where city='$(city)'` | de tekst |
+
+Een veld waarvan nog niet alle placeholders kunnen worden opgelost, wordt niet geëvalueerd; met `ignoreIncomplete: true` wordt een ontbrekende waarde
+in plaats daarvan als `undefined` ingevoegd.
+
+### Backticks en `${` in een waarde
+
+Vanaf 7.3.0 kan een veldwaarde niet als code draaien wanneer de server haar in een expressie invoegt (remote expressies, launch-validatie,
+MCP en chat). Een backtick of `${` in de waarde wordt als unicode-escape geschreven (```, `${`), zodat het
+tekst blijft, zelfs binnen een template literal. Expressies aan de serverkant weigeren template literals helemaal; gebruik daarvoor `runLocal`.
+
+Een `runLocal`-expressie die in de browser wordt geëvalueerd, voegt de waarde in zoals de tabel hierboven zegt, zonder die escape, dus zet daar
+geen placeholder binnen een template literal.
+
+---
+
+## Zie ook
+
+Gerelateerde pagina's en FAQ-items:
+
+- [Lokale expressies](local.html) en [Remote expressies](remote.html): waar de meeste placeholders worden gebruikt
+- [FAQ: Trapsgewijze keuzelijsten](../faq.html#cascaded-dropdowns) en [Placeholders in velden](../faq.html#field-placeholders): meer voorbeelden
+- [FAQ: Hoe krijg ik toegang tot de gegevens van het bovenliggende formulier in een subformulier?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/nl/_build_forms/expressions/remote.md b/i18n/nl/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..7261e8f
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Remote expressies
+parent: Expressies
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Remote expressies
+{: .no_toc }
+
+Functies aan de serverkant voor datums, netwerken, bestanden, SSH en genummerde namen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+De volgende voorbeelden draaien met de veldeigenschap `runLocal: false` (standaard).  
+Ze worden aan de serverkant geëvalueerd.
+
+Omdat het evalueren van code op de server een beveiligingsrisico is, wordt de expressie opgeschoond en beperkt tot de functies die
+met AnsibleForms worden meegeleverd en de [functies die je zelf toevoegt](#your-own-functions).  
+Expressies aan de serverkant zijn bedoeld om informatie op te halen uit gegevensbronnen zoals bestanden, REST API's en SSH-commando's.
+
+{: .important }
+De ingebouwde functies aan de serverkant hebben het voorvoegsel `fn.` (bijvoorbeeld `fn.fnRestBasic`), je eigen functies `fnc.`.
+
+---
+
+## Datum en tijd bewerken
+
+Werk met datums en tijden via [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## CIDR-informatie van een IP-adres ophalen
+
+Haal het subnet van een IP-adres en netmasker op, en controleer welke adressen erbij horen:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## SSH-uitvoer ophalen
+
+Voer via SSH een commando uit op een remote host en gebruik de uitvoer:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Bestanden in een map opsommen
+
+Som de bestanden van een map op de AnsibleForms-server op, desgewenst recursief en gefilterd:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Een HTML-pagina parsen
+
+Haal een HTML-pagina op en haal de delen eruit die overeenkomen met een reguliere expressie:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+De pagina wordt opgehaald onder [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) en
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), net als bij de REST-functies. Anders dan die negeert ze
+`REST_IGNORE_CERTS` en `REST_TIMEOUT_SECONDS`: ze controleert altijd het certificaat en wacht hooguit 30 seconden.
+
+---
+
+## DNS-informatie ophalen
+
+Los een DNS-record van een domein op:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Een JSON-bestand lezen
+
+Lees een JSON-bestand op de server, desgewenst gefilterd met jq:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Een YAML-bestand lezen
+
+Lees een YAML-bestand op de server, desgewenst gefilterd met jq:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Een naam met oplopende nummering ophalen
+
+In een array van strings met oplopende nummers (server001, server002, ...) moet je soms de volgende vrije naam vinden.  
+Deze functie is ook beschikbaar als lokale expressie (zonder het voorvoegsel `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Op de server mislukt `fn.fnGetNumberedName` met een fout wanneer het eerste argument geen array is. De lokale expressie
+(zonder `fn.`) geeft in dat geval de standaardwaarde terug.
+
+---
+
+## Je eigen functies
+
+Voeg eigen JavaScript-functies toe aan `custom.js`, en roep ze in een serverexpressie aan met het voorvoegsel `fnc.`.
+
+Het bestand exporteert een object met functies. Het bestand dat met de image wordt meegeleverd, bevat twee voorbeelden:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+Op dezelfde manier bevat `jq.custom.definitions` je eigen jq-definities. Die worden vóór elke jq-query gezet die de
+server uitvoert, zodat de [jq-query's](jq.html) van elke functie ze kunnen gebruiken.
+
+Koppel in een container beide bestanden over die in de image heen, en herstart; ze worden gelezen wanneer de server start:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Een eigen functie draait binnen het serverproces, met de rechten daarvan, telkens als een expressie haar aanroept. De
+> [sanitizer](index.html#security-concerns) controleert dat de expressie alleen `fn.`- en `fnc.`-functies aanroept; wat een
+> functie met haar argumenten doet, is jouw verantwoordelijkheid.
diff --git a/i18n/nl/_build_forms/expressions/rest-apis.md b/i18n/nl/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..0557d8b
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: REST API's
+parent: Expressies
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# REST API's
+{: .no_toc }
+
+REST API's aanroepen met basic-, token- of eigen authenticatie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## REST API met basic-authenticatie
+
+Roep een REST API aan met de gebruiker en het wachtwoord van opgeslagen inloggegevens:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## REST API met tokenauthenticatie
+
+Roep een REST API aan met een bearer-token dat in de expressie staat:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST API met beveiligde tokenauthenticatie
+
+Roep een REST API aan met een bearer-token uit opgeslagen inloggegevens, zodat het nooit in het formulier verschijnt:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST API met eigen headers
+
+Roep een REST API aan met je eigen headers, voor elke andere vorm van authenticatie:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certificaten en time-outs
+
+Vanaf 7.3.0 controleert elke REST-hulpfunctie (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) het TLS-certificaat
+van het endpoint en stopt ze na een ingestelde tijd met wachten:
+
+| Instelling | Wat het verandert |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` slaat de certificaatcontrole over. Tot en met 7.2.0 werd het nooit gecontroleerd; laat het op `0` staan en vertrouw in plaats daarvan een eigen CA met `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Hoe lang een aanroep op een antwoord wacht, standaard 60 seconden; een endpoint dat nooit antwoordt, laat het veld dan mislukken in plaats van het vast te houden |
+
+Vanaf 7.3.0 mislukt een veld waarvan het endpoint een zelfondertekend certificaat heeft met een certificaatfout, tot een van de twee is ingesteld.
+[REST-aanroepen en jq](../customization/security.html#rest-calls-and-jq) beschrijft beide, en hoe je een eigen CA in één keer voor elke REST-aanroep vertrouwt.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) is geen REST-hulpfunctie: ze negeert beide instellingen, controleert altijd het
+certificaat en wacht hooguit 30 seconden.
diff --git a/i18n/nl/_build_forms/expressions/sorting.md b/i18n/nl/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..60062b9
--- /dev/null
+++ b/i18n/nl/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Sorteren
+parent: Expressies
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Sorteren
+{: .no_toc }
+
+Arrays sorteren met een sorteerobject
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Een array sorteren
+
+Sorteer een array uit een expressie, een REST API of een database met een sorteerobject:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## Het sorteerobject
+
+De REST-functies (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) nemen dit sorteerobject
+als argument. Voor elk ander resultaat, zoals `fn.fnJq` of het lezen van een bestand, verpak je het in `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/nl/_build_forms/formfields/checkbox.md b/i18n/nl/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..41d4b03
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Formuliervelden
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Veld Checkbox
+{: .no_toc }
+
+Een waarde true of false, om een optie in te schakelen of een vlag te zetten
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `checkbox`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `checkbox`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/datetime.md b/i18n/nl/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..e1b2177
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Formuliervelden
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Veld Datetime
+{: .no_toc }
+
+Een kiezer voor datum, tijd, week, maand of jaar
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `datetime`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `datetime`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/enum.md b/i18n/nl/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..8d1c954
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Formuliervelden
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Veld Enum
+{: .no_toc }
+
+Een keuzelijst met zoekfunctie, voor één of meerdere keuzes
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `enum`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `enum`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/expression.md b/i18n/nl/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..0078c91
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Formuliervelden
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Veld Expression
+{: .no_toc }
+
+Een waarde berekend door JavaScript, in de browser of op de server
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `expression`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `expression`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/file.md b/i18n/nl/_build_forms/formfields/file.md
new file mode 100644
index 0000000..20e998c
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Formuliervelden
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Veld File
+{: .no_toc }
+
+Bestanden uploaden, zoals configuratiebestanden of certificaten
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `file`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `file`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/html.md b/i18n/nl/_build_forms/formfields/html.md
new file mode 100644
index 0000000..ce6c8de
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Formuliervelden
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Veld Html
+{: .no_toc }
+
+Rijke HTML-inhoud binnen een formulier
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `html`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `html`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/index.md b/i18n/nl/_build_forms/formfields/index.md
new file mode 100644
index 0000000..408030f
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Formuliervelden
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Formuliervelden
+{: .no_toc }
+
+De invoerelementen van een formulier
+{: .fs-6 .fw-300 }
+
+---
+
+Voor formulierauteurs: de veldtypen die een formulier kan bevatten, en de eigenschappen die elk type ondersteunt.
+
+Formuliervelden definiëren de invoerelementen van een formulier. Elk veldtype heeft zijn eigen eigenschappen en gedrag om een bepaald soort gegevens te verzamelen.
+
+Kies het veldtype dat past bij de gegevens die je wilt verzamelen, van gewone tekst tot gestructureerde lijsten.
+
+---
+
+## Gemeenschappelijke eigenschappen
+
+Alle formuliervelden delen twee fundamentele eigenschappen:
+
+- **name** (string, verplicht): de unieke identifier van het veld
+- **type** (string, verplicht): het veldtype, dat bepaalt welke van de pagina's hieronder de beschikbare eigenschappen beschrijft
+
+Elk veldtype voegt eigenschappen toe die bij zijn functie horen. Kies een veldtype in de navigatiebalk of in de tabel hieronder om de volledige referentie van zijn eigenschappen te openen:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Veldtype</th>
+      <th>Beschrijving</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/nl/_build_forms/formfields/list.md b/i18n/nl/_build_forms/formfields/list.md
new file mode 100644
index 0000000..62f5ce6
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Formuliervelden
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Veld List
+{: .no_toc }
+
+Een tabel met rijen, elk bewerkt in een subformulier
+{: .fs-6 .fw-300 }
+
+---
+
+Een list-veld toont een tabel met rijen, die elk worden aangemaakt en bewerkt in een eigen paneel met een **subformulier** (een drilldownpatroon). Het vervangt het veld `table`, dat in 7.0.0 is verwijderd.
+
+---
+
+## Belangrijkste kenmerken
+
+Het list-veld biedt de volgende mogelijkheden:
+
+- Elke rij wordt bewerkt in een subformulier op volledig scherm, met toegang tot elk veldtype, geneste lijsten inbegrepen.
+- Het subformulier is een eigen formulier, van type `subform`, en kan worden **hergebruikt in meerdere list-velden** in verschillende formulieren (bijvoorbeeld één subformulier `Address` dat klanten, leveranciers, orders… delen).
+- Markeringseigenschappen (`insertMarker`, `updateMarker`, `deleteMarker`) ondersteunen idempotente playbookpatronen.
+- Met `allowDelete: false` zijn bestaande rijen beschermd; alleen rijen die in de huidige sessie zijn toegevoegd (met de `insertMarker`) kunnen worden verwijderd.
+- De eigenschap `columns` bepaalt welke velden van het subformulier als kolommen in de overzichtstabel verschijnen.
+- De uitvoer is altijd een array van objecten. `model`, `output`, `outputObject` en `valueColumn` die op velden van het subformulier zijn gedeclareerd, worden gerespecteerd wanneer de extravars worden gegenereerd.
+
+---
+
+## Declaratie van het subformulier
+
+Een subformulier is een eigen formulier met `type: subform`, in een bestand van de formulierenmap zoals elk ander formulier. Het accepteert dezelfde array `fields` als elk ander formulier, maar het verschijnt nooit in de lijst met formuliertegels en wordt nooit rechtstreeks verzonden.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `list`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Voorbeelden</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Voorbeelden
+
+### Gedeeld adressubformulier
+
+Eén subformulier `Address`, hergebruikt door twee list-velden van hetzelfde formulier:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Bijhouden met markeringen (idempotent)
+
+Vooraf geladen rijen zijn beschermd, en de markeringen vertellen het playbook welke rijen nieuw, gewijzigd of verwijderd zijn:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Rijen vooraf vullen
+
+Een lijst kan vanuit drie bronnen vooraf worden gevuld. In elk geval moeten de resulterende rijen objecten zijn waarvan de sleutels overeenkomen met de veldnamen van het subformulier waarnaar wordt verwezen.
+
+#### Statische `default`
+
+Rijen die in het formulier zelf staan:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Uit een REST API (`expression`)
+
+Rijen die door een expressie aan de serverkant uit een REST API worden geladen:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Uit een databasequery (`dbConfig` + `query`)
+
+Rijen die uit een databasequery worden geladen:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Uit een lokale expressie (`runLocal`)
+
+Rijen die in de browser door een lokale expressie worden berekend:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Geneste lijsten
+
+Een subformulier kan een eigen list-veld bevatten, voor een lijst binnen elke rij:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Gegevens van het bovenliggende formulier lezen via `__parent__`
+
+Wanneer de rij-editor van een subformulier opent, voegt AnsibleForms een variabele `__parent__` aan het subformulier toe. Die bevat een momentopname van **alle veldwaarden van het bovenliggende formulier**, inclusief constanten en vars.
+
+Verwijs ernaar met de gewone expressiesyntax `$(...)` in de velddefinities van het subformulier:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` is een hulpmiddel dat **alleen in de frontend** bestaat. Het wordt uit de Ansible-extravars verwijderd en nooit naar het playbook gestuurd.
+
diff --git a/i18n/nl/_build_forms/formfields/number.md b/i18n/nl/_build_forms/formfields/number.md
new file mode 100644
index 0000000..bd14d0f
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Formuliervelden
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Veld Number
+{: .no_toc }
+
+Een geheel of decimaal getal, zoals een poort of een hoeveelheid
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `number`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `number`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/password.md b/i18n/nl/_build_forms/formfields/password.md
new file mode 100644
index 0000000..7f8c9f0
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Formuliervelden
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Veld Password
+{: .no_toc }
+
+Een gemaskeerde waarde, voor wachtwoorden, geheimen en tokens
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `password`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `password`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/radio.md b/i18n/nl/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..791dad8
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Formuliervelden
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Veld Radio
+{: .no_toc }
+
+Eén keuze uit een reeks opties die elkaar uitsluiten
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `radio`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `radio`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/text.md b/i18n/nl/_build_forms/formfields/text.md
new file mode 100644
index 0000000..f42a6b4
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Formuliervelden
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Veld Text
+{: .no_toc }
+
+Eén regel tekst, zoals een naam of een hostnaam
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `text`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `text`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/textarea.md b/i18n/nl/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..db2bd98
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Formuliervelden
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Veld Textarea
+{: .no_toc }
+
+Tekst over meerdere regels, zoals een beschrijving of een stukje configuratie
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `textarea`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `textarea`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/nl/_build_forms/formfields/yaml.md b/i18n/nl/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..72ab2f6
--- /dev/null
+++ b/i18n/nl/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Formuliervelden
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Veld YAML
+{: .no_toc }
+
+Gestructureerde gegevens in een YAML-editor, met validatie en bestandsimport
+{: .fs-6 .fw-300 }
+
+---
+
+## Eigenschappen
+
+De eigenschappen die beschikbaar zijn voor een `yaml`-veld, gegroepeerd naar doel:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Waarde:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van `yaml`-velden, in YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De velddefinitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Gegevens van het bovenliggende formulier lezen via `__parent__`
+
+Gebruikt een `yaml`-veld de modus `subform`, dan voegt AnsibleForms een variabele `__parent__` aan het subformulier toe. Die bevat een momentopname van **alle veldwaarden van het bovenliggende formulier** op het moment dat de editor opent, inclusief constanten en vars.
+
+Verwijs ernaar met de gewone expressiesyntax `$(...)` in de velddefinities van het subformulier:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` is een hulpmiddel dat **alleen in de frontend** bestaat. Het wordt uit de Ansible-extravars verwijderd en nooit naar het playbook gestuurd.
diff --git a/i18n/nl/_build_forms/forms/ansible.md b/i18n/nl/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..aa3ac7d
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Ansible-formulieren
+parent: Formulieren
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Ansible-formulieren
+{: .no_toc }
+
+Formulieren die een lokaal Ansible-playbook uitvoeren
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: ansible`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/approval.md b/i18n/nl/_build_forms/forms/approval.md
new file mode 100644
index 0000000..c174a6a
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Goedkeuringspunten
+parent: Formulieren
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Goedkeuringspunten
+{: .no_toc }
+
+Zet een job stil tot iemand hem goedkeurt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Hoe het werkt
+
+Een goedkeuringspunt zet de job stil op zijn plek in het formulier, tot een goedkeurder antwoordt:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Je eigen job goedkeuren
+
+Vanaf 7.3.0 kan de gebruiker die een job startte hem niet goedkeuren, ook niet met een van de rollen van de goedkeuring, dus er is een tweede persoon voor nodig; een admin kan altijd goedkeuren, ook zijn eigen jobs.
+Degene die de job startte, kan zijn eigen job nog wel afwijzen (intrekken). Stel `allowSelf: true` in wanneer hij hem ook mag goedkeuren, bijvoorbeeld in een testformulier:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Attributen
+
+De attributen van een goedkeuringspunt:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van goedkeuringspunten, in YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De definitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/awx.md b/i18n/nl/_build_forms/forms/awx.md
new file mode 100644
index 0000000..e94c38d
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: AWX-formulieren
+parent: Formulieren
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# AWX-formulieren
+{: .no_toc }
+
+Formulieren die een jobsjabloon van AWX, AAP of Ascender starten
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: awx`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/common.md b/i18n/nl/_build_forms/forms/common.md
new file mode 100644
index 0000000..15d4f9b
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Gemeenschappelijke eigenschappen
+parent: Formulieren
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Gemeenschappelijke eigenschappen van formulieren
+{: .no_toc }
+
+Eigenschappen die elk formuliertype deelt
+{: .fs-6 .fw-300 }
+
+---
+
+Deze eigenschappen gelden voor **alle formuliertypen**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (verouderd) en `subform`.
+
+Alle andere eigenschappen zijn specifiek per type en staan beschreven op de pagina van het betreffende formuliertype.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Eigenschappen
+
+De eigenschappen die alle formuliertypen delen:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/nl/_build_forms/forms/index.md b/i18n/nl/_build_forms/forms/index.md
new file mode 100644
index 0000000..3886ebb
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formulieren
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formulieren
+{: .no_toc }
+
+Definieer de formulieren die je gebruikers invullen
+{: .fs-6 .fw-300 }
+
+---
+
+Voor formulierauteurs: hoe formulieren in YAML worden geschreven, waar ze vandaan worden geladen en de eigenschappen van elk formuliertype.
+
+Formulieren vormen de kern van AnsibleForms. Elk formulier is een webinterface die invoer van de gebruiker verzamelt en met die gegevens een
+Ansible-playbook uitvoert, een sjabloon van AWX, AAP of Ascender, een sjabloon van Semaphore, een job van Rundeck of Jenkins, of een
+[workflow](../workflows/).
+
+Formulieren worden gedefinieerd in YAML-bestanden in de formulierenmap. Elk YAML-bestand bevat één formulier of een lijst met formulieren, en je kunt submappen gebruiken om ze te ordenen.
+
+**VIDEO**: [Je eerste formulier maken](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## De opbouw van een formulier
+
+Elk formulier in AnsibleForms wordt geconfigureerd met een reeks eigenschappen. **[Gemeenschappelijke eigenschappen](common.html)** somt de eigenschappen op die voor alle formuliertypen gelden; de pagina's per type beschrijven de extra eigenschappen.
+
+---
+
+## Hoe formulieren worden geladen
+
+AnsibleForms laadt formulieren vanaf de volgende locaties:
+
+1. **UIT REPOSITORIES** : alle repositories waarbij de schakelaar "Gebruiken voor formulieren?" aanstaat (meerdere repositories worden ondersteund)
+   - Formulieren uit alle ingeschakelde repositories worden automatisch samengevoegd.
+   - In elke repository wordt eerst gezocht naar een submap `forms/`.
+   - Bestaat er geen submap `forms/`, dan wordt de root van de repository gebruikt.
+   - Formulieren die in de ontwerper zijn gemaakt en nog niet zijn gepusht, worden bewaard in een stagingmap
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) en samen met de andere geladen.
+
+2. **UIT DE LOKALE MAP** : de lokale map `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), wanneer bij geen enkele repository "Gebruiken voor formulieren?" aanstaat
+
+{: .warning }
+> **Let op:** staat "Gebruiken voor formulieren?" bij meerdere repositories aan, dan worden al hun formulieren samengevoegd. Formuliernamen moeten over alle repositories heen uniek zijn om conflicten te voorkomen.
+
+---
+
+## Waar een formulier draait
+
+Het type van een formulier bepaalt op wat voor [runner](../runners.html) zijn job draait: een RTE voor `ansible`, een AWX-runner voor `awx`,
+`aap` en `ascender`, en een runner van het eigen type voor `semaphore`, `rundeck` en `jenkins`.
+
+- `runner: <name>` op het formulier kiest op naam een runner van dat type; zonder die sleutel draait de job op de standaardrunner van het type.
+- Een runner die onder **Verbindingen > Runners** is uitgeschakeld, laat de job mislukken, of het formulier hem nu noemt of hij de standaard is. De job
+  valt nooit terug op een andere runner.
+- Wanneer een van de rollen van de gebruiker `runners` opsomt in `config.yaml`, mag de job alleen draaien op een runner die zo'n rol opsomt; anders wordt hij
+  geweigerd. Rollen zonder die lijst beperken het niet, en een admin wordt nooit beperkt.
+
+---
+
+## In deze sectie
+
+De volgende pagina's beschrijven de eigenschappen van formulieren in detail:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Gemeenschappelijke eigenschappen](common.html) | Eigenschappen die voor alle formuliertypen gelden (`name`, `description`, `help`, `type`, `fields`) |
+| [Ansible-formulieren](ansible.html) | Eigenschappen specifiek voor `type: ansible` |
+| [AWX-formulieren](awx.html) | Eigenschappen specifiek voor `type: awx` |
+| [Semaphore-formulieren](semaphore.html) | Eigenschappen specifiek voor `type: semaphore`, dat een sjabloon van Semaphore uitvoert |
+| [Rundeck-formulieren](rundeck.html) | Eigenschappen specifiek voor `type: rundeck`, dat een job van Rundeck uitvoert |
+| [Jenkins-formulieren](jenkins.html) | Eigenschappen specifiek voor `type: jenkins`, dat een job van Jenkins bouwt |
+| [Multistep-formulieren](multistep.html) | Eigenschappen specifiek voor `type: multistep`, verouderd ten gunste van `workflow` |
+| [Workflowformulieren](workflow.html) | Eigenschappen specifiek voor `type: workflow`, dat een [workflow](../workflows/) uitvoert |
+| [Wizard](wizard.html) | De invoer van een formulier over meerdere pagina's verdelen (werkt bovenop elk uitvoerbaar formuliertype) |
+| [Subformulier](subform.html) | Subformulieren gebruiken alleen de gemeenschappelijke eigenschappen |
+| [Goedkeuringspunten](approval.html) | Een job stilzetten tot hij is goedgekeurd (`approval`) |
+| [Meldingen](notifications.html) | E-mails en kanaalberichten versturen bij jobstatussen of gebeurtenissen (`notifications`) |
+| [Acties bij jobstatus](job-status-action.html) | Iets doen op het formulier wanneer een job van status verandert (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/nl/_build_forms/forms/jenkins.md b/i18n/nl/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..4be4db5
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Jenkins-formulieren
+parent: Formulieren
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Jenkins-formulieren
+{: .no_toc }
+
+Formulieren die een job van Jenkins bouwen
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: jenkins`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/job-status-action.md b/i18n/nl/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..eae7705
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Acties bij jobstatus
+parent: Formulieren
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Acties bij jobstatus
+{: .no_toc }
+
+Iets doen op het formulier wanneer zijn job wordt verzonden, slaagt, mislukt of eindigt
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+De volgende hooks zijn beschikbaar:
+
+- `onSubmit` - gaat af wanneer het formulier wordt verzonden
+- `onSuccess` - gaat af wanneer de job met succes is voltooid
+- `onFailure` - gaat af wanneer de job mislukt
+- `onFinish` - gaat af wanneer de job eindigt, ongeacht zijn status
+- `onAbort` - gaat af wanneer de job wordt afgebroken
+
+---
+
+## Attributen
+
+De attributen van een actie bij jobstatus:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van acties bij jobstatus, in YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De definitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/multistep.md b/i18n/nl/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..543cd4c
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Multistep-formulieren
+parent: Formulieren
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Multistep-formulieren
+{: .no_toc }
+
+Voer vanuit één formulier meerdere playbooks of sjablonen na elkaar uit
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` is verouderd sinds 7 en verdwijnt in 8: gebruik in plaats daarvan een [workflow](workflow.html). Een workflow doet alles wat een
+> multistep doet, met voorwaarden, eigen waarden per knooppunt, goedkeuringsknooppunten en takken die naast elkaar draaien.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschap op formulierniveau
+
+Een multistep-formulier definieert zijn stappen in één eigenschap op formulierniveau:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / verplicht</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Naast `steps` accepteert een multistep-formulier deze eigenschappen op formulierniveau, beschreven op de pagina [Ansible-formulieren](ansible.html):
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (verplicht){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Eigenschappen van een stap
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Alleen beschikbaar bij de typen:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Toegevoegd</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Voorbeelden
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeeld
+
+Een multistep-formulier voert meerdere jobs na elkaar uit, waarbij elke stap zijn eigen playbook of AWX-sjabloon start. Alle stappen delen de velden van het formulier: standaard krijgt elke stap de volledige extravars, en de `key` van een stap beperkt die tot dat deel ervan.
+
+### Een server aanmaken en configureren
+
+Elke stap krijgt zijn eigen deel van de extravars: een AWX-stap maakt de server aan, een Ansible-stap configureert het netwerk, en een laatste stap stuurt altijd een rapport:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/nl/_build_forms/forms/notifications.md b/i18n/nl/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..4e770ed
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Meldingen
+parent: Formulieren
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Meldingen
+{: .no_toc }
+
+Stuur een e-mail of een kanaalbericht wanneer een job eindigt of er iets met hem gebeurt
+{: .fs-6 .fw-300 }
+
+---
+
+De `notifications` van een formulier bepalen wie over zijn jobs hoort, en wanneer:
+
+- **Wie**: `recipients`, e-mailadressen, en `channels`, de namen van
+  [meldingskanalen](../notification-channels.html) (mail, Slack, Microsoft Teams, Telegram, een webhook). Minstens een
+  van de twee is verplicht.
+- **Wanneer**: `onStatus`, wanneer een job eindigt (`success`, `failed`, `aborted`, `warning` of `any`), en `onEvent`, wanneer
+  er iets met een job gebeurt (`launch`, `relaunch`, `delete`, `approve`, `reject` of `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Attributen
+
+De attributen van het object `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Voorbeelden
+
+Voorbeelden van meldingen, in YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}De definitie, in YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/rundeck.md b/i18n/nl/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..88c4081
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Rundeck-formulieren
+parent: Formulieren
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Rundeck-formulieren
+{: .no_toc }
+
+Formulieren die een job van Rundeck uitvoeren
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: rundeck`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/semaphore.md b/i18n/nl/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..f837880
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Semaphore-formulieren
+parent: Formulieren
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Semaphore-formulieren
+{: .no_toc }
+
+Formulieren die een sjabloon van Semaphore UI uitvoeren
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: semaphore`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/forms/subform.md b/i18n/nl/_build_forms/forms/subform.md
new file mode 100644
index 0000000..bf0d538
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Subformulier
+parent: Formulieren
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Subformulier
+{: .no_toc }
+
+Een herbruikbaar formulierfragment voor list-velden, yaml-velden en wizardpagina's
+{: .fs-6 .fw-300 }
+
+---
+
+Een subformulier is een herbruikbaar formulierfragment. Het verschijnt niet in de tegelweergave en kan niet rechtstreeks worden verzonden. In plaats daarvan wordt ernaar verwezen door:
+
+- Een [`list`](../formfields/list.html)-veld: opent het subformulier als drilldown-editor voor elke rij
+- Een [`yaml`](../formfields/yaml.html)-veld met de eigenschap `subform`: opent het subformulier als drilldown-editor voor één object
+- Een stap van een [`wizard`](wizard.html): toont het subformulier als één pagina van de wizard
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Subformulieren hebben **geen typespecifieke eigenschappen**. Ze gebruiken alleen de [gemeenschappelijke eigenschappen van formulieren](common.html): `name`, `description`, `help`, `type` en `fields`.
+
+Dient een subformulier als wizardpagina, dan leveren zijn `description` en `help` de standaardwaarden voor `title` en `help` van de stap. Het kan ook `showHelp` instellen om die help open te klappen wanneer de pagina laadt.
+
+Uitvoeringseigenschappen (`playbook`, `template`, `roles`, `inventory`, enz.) gelden niet voor subformulieren, omdat een subformulier nooit rechtstreeks wordt verzonden.
+
diff --git a/i18n/nl/_build_forms/forms/wizard.md b/i18n/nl/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..f0cb3b6
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Wizard
+parent: Formulieren
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Wizard
+{: .no_toc }
+
+Verdeel de invoer van een formulier over pagina's met Terug en Volgende
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Wat is een wizard?
+
+Een **wizard** maakt van één formulier een reeks pagina's. Elke pagina wordt opgebouwd uit een [`subform`](subform.html), en de gebruiker navigeert met de knoppen **Terug** en **Volgende**. Validatie wordt per pagina afgedwongen: de gebruiker kan pas verder als de huidige stap geldig is, tenzij de stap als `optional` is gemarkeerd.
+
+Aan het eind van elke wizard wordt automatisch een alleen-lezen **controlepagina** toegevoegd. Die toont elke stap met de verzamelde waarden, zodat de gebruiker ze kan bevestigen voordat hij verzendt. De controlepagina wordt **niet** in YAML gedeclareerd; de titel komt uit de actieve taal.
+
+Bij het verzenden worden **de verzamelde waarden van alle stappen samengevoegd tot één set extravars** en naar het onderliggende playbook, sjabloon of de onderliggende workflow gestuurd, precies alsof de gebruiker één groot formulier had ingevuld.
+
+Een formulier met een `wizard` heeft geen eigen `fields` nodig, maar kan `enableForChat` niet instellen, en een `subform` kan zelf geen `wizard` hebben. [Launch-validatie](../launch-validation/rolling-it-out.html#wizard-forms) controleert een wizardstart stap voor stap.
+
+{: .note }
+> Hoe een `wizard` verschilt van een workflow, en hoe je de twee combineert, lees je in het FAQ-item [Wat is het verschil tussen een wizard en een workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Eigenschap op formulierniveau
+
+Een wizard schakel je in met één eigenschap op formulierniveau:
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">toegevoegd in versie {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Voorbeelden:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen van een wizardstap
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / verplicht</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / uniek</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Toegevoegd</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Voorbeelden
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Een wizard combineren met een workflow
+
+Een wizard kan bovenop een [workflowformulier](workflow.html) worden gelegd. Komt de `defaultModel` van elke wizardstap overeen met de [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) van het bijbehorende knooppunt van de workflow, dan krijgt elk playbook of sjabloon alleen de waarden van zijn eigen wizardpagina.
+
+De FAQ bevat een uitgewerkt voorbeeld en de opbouw van de samengevoegde extravars: [Wat is het verschil tussen een wizard en een workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (sectie *Gecombineerd (wizard bovenop een workflow)*).
+
+Een wizard op een verouderd [`multistep`](multistep.html)-formulier werkt op dezelfde manier, met de [`key`](multistep.html#step_key) van de stap in plaats van `extra_vars_key`.
+
+---
+
+## Zie ook
+
+Gerelateerde pagina's en FAQ-items:
+
+- [Subformulier](subform.html): wizardpagina's worden opgebouwd uit subformulieren
+- [Workflowformulieren](workflow.html): de tegenhanger van de wizard op uitvoeringsniveau
+- [`__parent__` in subformulieren](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): hoe je in een latere stap naar eerdere wizardstappen verwijst
diff --git a/i18n/nl/_build_forms/forms/workflow.md b/i18n/nl/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..09bec2b
--- /dev/null
+++ b/i18n/nl/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Workflowformulieren
+parent: Formulieren
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Workflowformulieren
+{: .no_toc }
+
+Formulieren die een van de workflows uit de ontwerper uitvoeren
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Eigenschappen
+
+Eigenschappen specifiek voor `type: workflow`, naast de [gemeenschappelijke eigenschappen van formulieren](common.html). De sectie
+[Workflows](../workflows/) beschrijft de workflowbestanden zelf.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Attribuut</th>
+      <th>Opmerkingen</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / verplicht</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">toegevoegd in versie {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Keuzes:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (standaard)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Standaard:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Voorbeelden:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/nl/_build_forms/launch-validation/file-uploads.md b/i18n/nl/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..ef7c71c
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Bestandsuploads
+parent: Launch-validatie
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Bestandsuploads
+{: .no_toc }
+
+Hoe bestandsvelden worden gevalideerd
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een bestandsveld vertrouwt nooit wat het startverzoek over een bestand zegt. Launch-validatie controleert het bestand zelf, op de
+schijf van de server.
+
+---
+
+## Hoe een upload bij een job komt
+
+Een bestand wordt geüpload voordat het formulier wordt gestart, in twee stappen:
+
+1. De browser uploadt het bestand met `POST /api/v2/job/upload`. De server slaat het op in `UPLOAD_PATH`.
+2. Het startverzoek beschrijft die upload in zijn deel `files`.
+
+Launch-validatie controleert daarna de beschrijving tegen de schijf:
+
+* Het bestand moet binnen `UPLOAD_PATH` bestaan.
+* Het pad en de grootte worden van de schijf gelezen, nooit uit het verzoek.
+
+---
+
+## Wat wordt geaccepteerd
+
+Een bestandsveld krijgt alleen een waarde uit een geverifieerde upload. Al het andere wordt genegeerd:
+
+* Een pad dat de aanroeper in `rawFormData` of `extravars` schrijft, wordt genegeerd.
+* Een verplicht bestandsveld zonder echte upload wordt gemeld als `missing`.
+
+---
+
+## Bestandsregels
+
+De regels van een bestandsveld worden gecontroleerd tegen de echte upload, met groottes in bytes:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` en `maxSize` vergelijken de echte grootte van het bestand, en `regex` de bestandsnaam. Los van elk formulier
+begrenst `UPLOAD_MAX_GB` de grootte van één upload (standaard 10 GB).
diff --git a/i18n/nl/_build_forms/launch-validation/index.md b/i18n/nl/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..c58cfcc
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Launch-validatie
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Launch-validatie
+{: .no_toc }
+
+Controleer elke start van een formulier op de server
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders en formulierauteurs: laat de server elke start controleren, met zijn regels en zijn extravars, wie hem ook verstuurt.
+
+De controle geldt ongeacht wie of wat het formulier start: de browser, een script dat de REST API aanroept,
+of een AI-agent via de MCP-server.
+
+---
+
+## Waarom het bestaat
+
+De regels van een formulier (`required`, `regex`, `minValue`, `sameAs`, ...) werden altijd al
+in de browser gecontroleerd. De browser stuurt daarna twee dingen naar `POST /api/v2/job`:
+
+- `rawFormData`: de veldwaarden zoals de gebruiker ze heeft ingevuld;
+- `extravars`: wat het playbook ontvangt, in de browser opgebouwd uit die waarden.
+
+Zonder launch-validatie vertrouwt de server beide. Iedereen met een geldig token kan dat
+endpoint rechtstreeks aanroepen en willekeurige extravars sturen, zonder dat er een regex, verplicht veld of lijstregel
+wordt toegepast. Voor een formulier dat alleen ooit in de browser wordt gebruikt, kan dat acceptabel zijn; voor een
+formulier dat andere systemen via REST starten, betekent het dat de regels van het formulier helemaal niet worden afgedwongen.
+
+De server kan ook op geen enkele manier een verzoek uit de browser onderscheiden van een verzoek van een
+script: beide gebruiken hetzelfde endpoint, hetzelfde token en dezelfde body, en gebruikers kunnen elk verzoek
+aanpassen dat hun eigen browser verstuurt. Een controle is alleen op de server te vertrouwen, en launch-validatie
+is die controle.
+
+---
+
+## De drie ingangen
+
+Hoe een start wordt gevalideerd, hangt af van hoe hij binnenkomt en van de modus van launch-validatie:
+
+| Gestart door | Gevalideerd | Extravars waarmee de job draait |
+|---|---|---|
+| **MCP-server** (AI-agent) | altijd, op de server | altijd door de server opgebouwd |
+| **Browser** of **REST API**, launch-validatie `off` | alleen in de browser | die de browser (of de aanroeper) stuurde |
+| **Browser** of **REST API**, launch-validatie `log` | op de server, weigeringen alleen gelogd | die zijn gestuurd; verschillen gelogd |
+| **Browser** of **REST API**, launch-validatie `enforce` | op de server, geweigerd als ongeldig | **door de server opgebouwd** |
+
+De browser, de MCP-server en launch-validatie gebruiken dezelfde code voor de regels (de
+gedeelde formulierengine): dezelfde regels, in dezelfde volgorde, met dezelfde meldingen. Een fout die de
+browser toont, weigert de server met dezelfde tekst.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Inschakelen](switching-it-on.html) | Voor de hele instantie, of voor één formulier |
+| [Log en enforce](log-and-enforce.html) | Wat elke modus doet met een start die de regels overtreedt |
+| [Lijstrijen](list-rows-and-subforms.html) | Hoe rijen van lijstvelden worden gevalideerd |
+| [Bestandsuploads](file-uploads.html) | Hoe bestandsvelden worden gevalideerd |
+| [Wachtwoorden](passwords.html) | Hoe wachtwoordvelden worden gevalideerd en buiten API's worden gehouden |
+| [Opnieuw starten](relaunching.html) | Hoe een opnieuw gestarte job wordt gevalideerd |
+| [Uitrollen](rolling-it-out.html) | Een instantie naar enforce brengen, en de bekende beperkingen |
diff --git a/i18n/nl/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/nl/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..6df39cc
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Lijstrijen
+parent: Launch-validatie
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Lijstrijen
+{: .no_toc }
+
+Hoe rijen van lijstvelden worden gevalideerd
+{: .fs-6 .fw-300 }
+
+---
+
+Een `list`-veld bevat rijen; elke rij is een instantie van zijn subformulier, ingevuld via de
+rij-editor. Een `yaml`-veld met een `subform` is één zo'n rij. De server behandelt ze op dezelfde manier
+als de rij-editor van de browser: elke rij wordt via haar subformulier opgelost, met de waarden van het formulier
+als `__parent__`, haar regels gecontroleerd en haar berekende velden geëvalueerd. Geneste lijsten werken
+net zo: in de eigen lijst van een rij bereikt `$(__parent__.__parent__.x)` het formulier.
+
+Rijen worden als volgt gecontroleerd:
+
+- **Een rij die de gebruiker in de editor heeft toegevoegd of bewerkt**, wordt opgelost en gevalideerd.
+- **Een rij die niemand heeft aangeraakt**, een rij die uit de eigen default, expressie of query van de lijst komt
+  (zoals de bestaande items van een ACL-lijst), gaat **precies zoals ze binnenkwam** door, net als in de
+  browser: ze wordt niet opnieuw gevalideerd en er wordt niets toegevoegd. Een bestaand item dat een regel overtreedt
+  die later is geschreven, houdt de start niet tegen.
+- **Een rij die als verwijderd is gemarkeerd** (de `deleteMarker` van de lijst), blijft zoals ze is en wordt niet gevalideerd.
+
+Om deze rijen te onderscheiden zonder het verzoek te vertrouwen, voert de server de eigen
+bron van de lijst (haar default, anders haar expressie of query) onder launch-validatie opnieuw uit. Een rij
+die niet door de editor is gegaan, gaat ongewijzigd door **alleen als ze een van de rijen is die
+die bron oplevert**. Elke andere rij, zoals een rij die een REST-aanroeper heeft verzonnen, wordt opgelost en
+gevalideerd als een bewerkte rij. Een gewone rij kan de controles dus niet omzeilen, terwijl de
+onaangeraakte rijen van de browser nog steeds ongewijzigd doorgaan.
+
+Een gebruiker in de browser merkt dit maar in één geval: de gegevens van de bron zijn veranderd tussen het openen van het
+formulier en het starten ervan (een item is in de tussentijd gewijzigd of verwijderd), **en** die rij
+overtreedt een regel van haar subformulier. De rij telt dan niet meer als een van de rijen van de bron, dus
+wordt ze gevalideerd en wordt de start geweigerd met de rij erbij genoemd, bijvoorbeeld
+`acls[2].user_or_group (regex)`.
+
+Rijen die niet slagen, verschijnen in `rowErrors` met hun `index` (een `yaml`-veld heeft er geen) en in het log als
+`disks[1].size (maxValue)`.
+
+Een start mag over alle nestingniveaus samen hooguit **500 rijen** bevatten, omdat elke rij de query's van haar subformulier uitvoert.
+
+---
+
+## Rijmarkeringen
+
+De markeringen die een lijst op haar rijen zet (`insertMarker`, `updateMarker` en `deleteMarker`; zonder
+`insertMarker` krijgen nieuwe rijen `__inserted__` wanneer de lijst `allowDelete: false`, een `deleteMarker` of een `updateMarker` instelt)
+komen bij het playbook aan op elke rij die er een draagt. Een verwijderde rij wordt verstuurd met haar verwijder-
+markering, zodat het playbook haar kan verwijderen. Vóór 6.4.1 droeg een lijstrij alleen een markering als haar
+subformulier die als (verborgen) veld declareerde.
diff --git a/i18n/nl/_build_forms/launch-validation/log-and-enforce.md b/i18n/nl/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..ed41507
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Log en enforce
+parent: Launch-validatie
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Log en enforce
+{: .no_toc }
+
+Wat elke modus doet met een start die de regels overtreedt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wat `log` doet
+
+Elke start wordt gecontroleerd, maar voor de gebruiker verandert er niets. Er wordt een waarschuwing in het log geschreven wanneer:
+
+- de start **geweigerd zou worden**, met de reden (alleen veldnamen en soorten regels, nooit
+  waarden):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- de extravars die de client stuurde **verschillen** van de extravars die de server opbouwt, met de
+  sleutels op het hoogste niveau die verschillen:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Draai eerst een tijdje `log` op een echte instantie. Dat laat zien welke formulieren geweigerd zouden worden en
+welke op de server andere waarden berekenen, voordat iemand er last van heeft.
+
+---
+
+## Wat `enforce` doet
+
+Onder `enforce` wordt een ongeldige start geweigerd, en draait een geldige start met de extravars die de server
+opbouwt.
+
+### Een start die de regels overtreedt, wordt geweigerd
+
+`POST /api/v2/job` antwoordt `422` met de velden die niet slagen:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing` - verplichte velden zonder waarde;
+- `invalid` - velden die een regel overtreden, keuzes die geen van de opties zijn, en lijst-
+  velden met een rij die niet slaagt;
+- `waiting` - velden die niet geëvalueerd konden worden (een veld dat ze nodig hebben, kreeg nooit een waarde);
+- `validationErrors` - per veld elke regel die niet slaagt, met de melding die de browser toont;
+- `rowErrors` - per lijstveld de rijen die niet slagen (zie [Lijstrijen](list-rows-and-subforms.html));
+- `uploads` - bestandsvelden waarvan de upload niet geverifieerd kon worden.
+
+Een start **zonder `rawFormData`** wordt ook geweigerd: de waarden ervan kunnen niet worden gecontroleerd.
+
+### Een geldige start draait met de extravars van de server
+
+De job draait niet met de extravars die de client stuurde. De server bouwt ze op uit de gecontroleerde
+waarden, met dezelfde code als de browser, en draait met die. Een aanroeper die geldige
+`rawFormData` stuurt naast andere `extravars`, krijgt de extravars die bij de waarden horen, niet
+die hij stuurde.
+
+Uit het verzoek behoudt de server `__verbose__` (alleen voor gebruikers die de verbose-modus mogen gebruiken). De
+gereserveerde sleutels (`__playbook__`, `__inventory__`, ...) komen zoals altijd uit het formulier, en
+`ansibleforms_user` is de gebruiker die de start uitvoert.
+
+### Wat de gebruiker zag, is niet altijd wat er draait
+
+De extravars opbouwen betekent het formulier opnieuw evalueren: elke expressie en query draait
+nog een keer op de server, een moment nadat de browser ze uitvoerde, als de gebruiker die de start uitvoert. Een waarde
+die afhangt van **wanneer** of **waar** ze wordt geëvalueerd, kan verschillen, en in dat geval wordt de
+waarde van de server gebruikt:
+
+| Wat | Waarom het kan verschillen | Hoeveel |
+|---|---|---|
+| `fn.fnTime()`, een tijdstempel, een naam die uit de tijd is opgebouwd | opnieuw geëvalueerd, een paar seconden later | doet er alleen toe op de grens van een seconde of een datum. `fnTime` draait ook in de browserflow al op de server, met dezelfde tijdzone (de `TZ` van de container) |
+| een query, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, het lezen van een bestand | de externe gegevens zijn in de tussentijd veranderd | alleen als ze veranderd zijn |
+| een `runLocal`-expressie die `new Date()`, `toLocaleString` of `Intl` gebruikt | de browser gebruikt de tijdzone en de locale van de gebruiker, de server die van zichzelf | alleen zulke expressies |
+
+Hetzelfde geldt voor **validatie**: een regel die zo'n veld leest (`notIn` tegen het resultaat van een query,
+`validIf` op een berekende vlag), wordt gecontroleerd tegen de waarde van de server. Formulieren waarvan de
+extravars verschillen, verschijnen in de hierboven beschreven `log`-waarschuwingen; bekijk ze voordat je enforce inschakelt.
diff --git a/i18n/nl/_build_forms/launch-validation/passwords.md b/i18n/nl/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..2a9a8b0
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Wachtwoorden
+parent: Launch-validatie
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Wachtwoorden
+{: .no_toc }
+
+Hoe wachtwoordvelden worden gevalideerd, opgeslagen en buiten API's worden gehouden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een wachtwoordveld wordt gevalideerd zoals elk ander veld. De waarde ervan blijft echter op de server en wordt nooit teruggegeven aan
+een client.
+
+---
+
+## Waar een wachtwoord wordt bewaard
+
+De server slaat het wachtwoord op bij de job, in de extravars:
+
+* Een **goedkeuring** kan de job dan voortzetten met het wachtwoord dat de gebruiker invoerde.
+* Een **herstart zoals hij draaide** kan het opnieuw gebruiken, wanneer launch-validatie niet op `enforce` staat.
+
+Het opgeslagen wachtwoord wordt alleen op de server gebruikt.
+
+---
+
+## Wat de API's teruggeven
+
+Geen enkele API geeft ooit een wachtwoord terug:
+
+* Een job die via de REST API of via `get_job` van de MCP-server wordt gelezen, maskeert elk `password`-veld van zijn formulier, ook binnen
+  lijstrijen en YAML-subformulieren.
+* `MASK_EXTRAVARS_REGEX` (standaard `password|secret|token`) maskeert daarnaast elke extravar waarvan de naam overeenkomt, voor
+  geheimen die geen wachtwoordvelden zijn.
+
+---
+
+## Wat een herstart ontvangt
+
+Om een herstart vooraf in te vullen, ontvangt de browser de ruwe formuliergegevens van de job. Die gegevens bevatten nooit een wachtwoord, ook niet binnen
+lijstrijen of YAML-subformulieren, dus de gebruiker voert het wachtwoord opnieuw in.
+
+Een wachtwoordveld dat door de afhankelijkheden van het formulier wordt verborgen, is niet nodig en hoeft niet opnieuw te worden ingevoerd.
diff --git a/i18n/nl/_build_forms/launch-validation/relaunching.md b/i18n/nl/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..69255d2
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Opnieuw starten
+parent: Launch-validatie
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Opnieuw starten
+{: .no_toc }
+
+Hoe een opnieuw gestarte job wordt gevalideerd
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een job kan op twee manieren opnieuw worden gestart. Hoe de herstart wordt gecontroleerd, hangt af van welke manier, en van de modus van
+launch-validatie.
+
+---
+
+## Twee soorten herstart
+
+De twee soorten verschillen in of de aanroeper nieuwe waarden stuurt:
+
+* **Zoals hij draaide**: de knop Herstarten, `POST /api/v2/job/{id}/relaunch` zonder body, of `relaunch_job` zonder
+  `values`.
+* **Met wijzigingen**: dezelfde aanroepen met nieuwe waarden, over de opgeslagen veldwaarden van de job heen gelegd:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Hoe elk wordt gecontroleerd
+
+De modus van launch-validatie bepaalt of een herstart opnieuw wordt afgespeeld of opnieuw wordt gecontroleerd:
+
+| Herstart | `off` / `log` | `enforce` |
+|---|---|---|
+| **Zoals hij draaide** | speelt de opgeslagen extravars van de job opnieuw af, wachtwoorden inbegrepen | de volledige controle, vanuit de opgeslagen veldwaarden |
+| **Met wijzigingen** | de volledige controle, op de opgeslagen waarden met de wijzigingen eroverheen | de volledige controle, op dezelfde manier |
+
+Eén uitzondering onder `enforce`: een job die door een planning op adminniveau is gestart, heeft geen eigen veldwaarden, dus een herstart zoals hij draaide
+speelt de opgeslagen extravars van de planning opnieuw af, voor een admin of een gebruiker met de roloptie `allowScheduledJobs`.
+
+Een gecontroleerde herstart (zie [Log en enforce](log-and-enforce.html)) start een nieuwe job op naam van de aanroeper.
+
+---
+
+## Wachtwoordvelden
+
+Opgeslagen veldwaarden bevatten geen wachtwoorden, dus een gecontroleerde herstart heeft er geen voor een **zichtbaar wachtwoordveld**:
+
+* De herstart wordt geweigerd als `unsupported`, met de `passwordFields` die ontbreken.
+* Start het formulier opnieuw en voer het wachtwoord in.
+* Een wachtwoordveld dat de afhankelijkheden van het formulier **verbergen**, is niet nodig en blokkeert de herstart niet.
+
+Onder `enforce` geldt dit ook voor de knop Herstarten.
+
+---
+
+## Wie opnieuw kan starten
+
+Beide soorten herstart vereisen:
+
+* dat het formulier herstarten toestaat (`allowRelaunch`, standaard true);
+* de roloptie `allowJobRelaunch`;
+* dat de gebruiker **de eigenaar van de job** is, een admin, of een gebruiker met de roloptie `manageAllJobs`.
+
+Elke job kunnen zien (`showAllJobLogs`) is niet genoeg om de job van een andere gebruiker opnieuw te starten. Goedkeurders kunnen een job zien die op hun
+goedkeuring wacht, maar kunnen hem ook niet opnieuw starten.
diff --git a/i18n/nl/_build_forms/launch-validation/rolling-it-out.md b/i18n/nl/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..408d6ee
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Uitrollen
+parent: Launch-validatie
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Uitrollen
+{: .no_toc }
+
+Een instantie naar enforce brengen, en de bekende beperkingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Uitrollen
+
+`enforce` is de standaard. Op een instantie met scripts of andere systemen die formulieren via
+REST starten, bereik je die stap voor stap, waarbij je het log in de gaten houdt voordat er iets wordt geweigerd:
+
+1. Stel `LAUNCH_VALIDATION=log` in voor de hele instantie (vóór het upgraden, bij een upgrade).
+2. Draai een tijdje in deze modus en bekijk het log: waarschuwingen `would refuse` wijzen op starts
+   die de regels overtreden; waarschuwingen `extravars differ` wijzen op formulieren die iets
+   anders berekenen op de server (een tijdstempel, externe gegevens). Bepaal per formulier of dat
+   ertoe doet.
+3. Zet die formulieren op `launchValidation: enforce`. Aanroepers die ongeldige waarden of
+   verzonnen extravars stuurden, krijgen nu een `422` met de reden.
+4. Gedraagt elk formulier zich zoals verwacht, verwijder dan `LAUNCH_VALIDATION` (of zet het op `enforce`) voor de hele instantie.
+
+---
+
+## Beperkingen
+
+Launch-validatie dekt nog niet alles:
+
+- **Wizardformulieren** kunnen niet met wijzigingen opnieuw worden gestart, en een wizardjob die vóór 7.0 is gestart,
+  kan onder `enforce` niet opnieuw worden gestart (hij sloeg zijn stapwaarden niet op). De MCP-server
+  kan geen wizardformulieren starten.
+- **Het oplossen van placeholders** in de browser gebruikt nog een eigen kopie van de code van de server; in
+  zeldzame randgevallen (`__undefined__`, aanhalingstekens binnen expressies) kunnen de twee een
+  placeholder verschillend oplossen. `log` brengt zulke verschillen aan het licht.
+- **`runLocal`**-expressies draaien in de browser in de JavaScript-engine van de browser, en op de server in een
+  sandbox; dezelfde code geeft hetzelfde resultaat, behalve waar die afhangt van
+  de tijdzone of de locale van de browser.
+
+---
+
+## Wizardformulieren
+
+Een [wizard](../forms/wizard.html) wordt stap voor stap gecontroleerd: de browser stuurt de waarden van
+elke stap, en de server controleert elke stap die de gebruiker zou indienen tegen het eigen subformulier van die stap.
+
+- Een stap wordt weggelaten wanneer hij `optional` is en de gebruiker hem oversloeg, of wanneer zijn `when` false is.
+- Een stap leest de eerdere stappen via `$(__parent__.<step>.<field>)`, met hun gecontroleerde waarden.
+- Fouten noemen de stap en het veld, als `<step>.<field>`.
+- Onder `enforce` worden de extravars op de server opgebouwd, elke stap onder zijn `defaultModel`.
+- Bestandsvelden worden in een wizard niet ondersteund.
diff --git a/i18n/nl/_build_forms/launch-validation/switching-it-on.md b/i18n/nl/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..d4ee907
--- /dev/null
+++ b/i18n/nl/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Inschakelen
+parent: Launch-validatie
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Inschakelen
+{: .no_toc }
+
+Voor de hele instantie, of voor één formulier
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Launch-validatie heeft twee instellingen. **De strengste van de twee geldt.**
+
+---
+
+## Voor de hele instantie: `LAUNCH_VALIDATION`
+
+De omgevingsvariabele [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) geldt voor elk formulier:
+
+- `off` - geen controle aan de serverkant: de job draait met de extravars die de browser of de aanroeper stuurde.
+- `log` - elke start wordt gecontroleerd; wat geweigerd zou worden, wordt als waarschuwing in het log
+  geschreven, en de start draait nog net als voorheen.
+- `enforce` (standaard) - een ongeldige start wordt geweigerd, en een geldige start draait met de extravars die de
+  server opbouwt.
+
+Een lege of onbekende waarde betekent ook `enforce`. Wijzigingen gaan in zonder herstart.
+
+{: .warning }
+> **Upgraden verandert het gedrag.** Een instantie die `LAUNCH_VALIDATION` niet instelt, dwingt na de upgrade
+> elke start af. Scripts die `POST /api/v2/job` aanroepen zonder `rawFormData`,
+> of met waarden die de regels van een formulier overtreden, worden geweigerd met een `422`. Stel
+> `LAUNCH_VALIDATION=log` in vóór het upgraden om te zien wat geweigerd zou worden, of `off` om het
+> oude gedrag te behouden (zie [Uitrollen](rolling-it-out.html)).
+
+---
+
+## Voor één formulier: `launchValidation`
+
+Een formulier kan zijn eigen niveau instellen:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Gebruik deze instelling op een instantie die op `off` of `log` draait, voor een formulier waarvan je weet dat het
+via REST wordt gestart: dat formulier wordt afgedwongen, de rest van de instantie niet. Het kan ook in de ontwerper worden ingesteld, in de
+formulierinstellingen.
+
+**Een formulier kan strenger worden gemaakt dan de instantie, nooit soepeler.** Staat `LAUNCH_VALIDATION`
+op `enforce`, dan heeft `launchValidation: off` van een formulier geen effect: een formulier kan
+de beslissing van een beheerder niet terzijde schuiven.
+
+Wizardformulieren gebruiken het ook: een wizardstart wordt stap voor stap gecontroleerd, elke stap tegen zijn eigen
+subformulier (zie [Wizardformulieren](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/nl/_build_forms/workflows/designer.md b/i18n/nl/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..59dad9a
--- /dev/null
+++ b/i18n/nl/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Bewerken in de ontwerper
+parent: Workflows
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Bewerken in de ontwerper
+{: .no_toc }
+
+Teken een workflow en probeer hem uit zonder iets te starten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De sectie Workflows
+
+**Ontwerper > Workflows** toont de workflowbestanden in een bestandsverkenner, met de tabbladen YAML, Visueel en Voorbeeld die elke
+sectie van de [ontwerper](../designer/) heeft.
+
+- **De knop `+`** in de werkbalk maakt een workflowbestand aan, met een lege workflow om mee te beginnen.
+- **YAML** toont het bestand zoals het geschreven is. Commentaar en de volgorde van de sleutels blijven ook in de andere tabbladen behouden.
+- **Visueel** tekent elke workflow van het bestand als een graaf, met de naam en beschrijving erboven. Een bestand met twee workflows
+  toont ze allebei, onder elkaar.
+- **Voorbeeld** is een proefrun van de workflow: zie [Uitproberen](#trying-it-out).
+
+Problemen staan boven de graaf, elk met een link die de YAML op de juiste regel opent: een koppeling naar een knooppunt dat niet
+bestaat, een lus, een playbook, inventaris, referentie, runner of repository die de ontwerper niet kent.
+
+---
+
+## De graaf
+
+De graaf lees je van links naar rechts, van **START** tot de laatste knooppunten. Elk knooppunt toont zijn identifier en daaronder wat
+het uitvoert; de koppelingen zijn gekleurd naar wat ze laat afgaan, zoals de legenda in de graaf aangeeft: bij succes, bij fout,
+altijd.
+
+- **Klik op START** om een eerste knooppunt toe te voegen: een knooppunt zonder ouder, dat draait zodra de workflow start.
+- **Klik op een knooppunt** om het te bewerken.
+- **Klik op een koppeling** om te wijzigen wat haar laat afgaan, of om haar te verwijderen.
+
+---
+
+## Een knooppunt toevoegen
+
+Een nieuw knooppunt voeg je toe met een wizard: **Nieuw knooppunt bij succes**, **Nieuw knooppunt bij fout** of **Nieuw knooppunt altijd** op een bestaand
+knooppunt, of START voor een eerste.
+
+1. **Wat het uitvoert**: de identifier van het knooppunt, **Voert uit** (wat voor knooppunt het is en, bij een playbookknooppunt, waar het draait)
+   en wat het uitvoert: een playbook of een sjabloon of job, een workflow, de naam en time-out van een goedkeuring, of een repository. Zie
+   [Waar een knooppunt draait](#where-a-node-runs).
+2. **Hoe het draait**: de uitvoeringsinstellingen: de inventaris, de referenties, de limiet, de tags, de uitgebreidheid,
+   check- en diff-modus, de voorwaarde (**Draait als**) en **Waarden uit** (zie [het workflowbestand](file.html#run-settings)).
+3. **Waar het heen gaat**: het knooppunt waarna het draait, en wanneer.
+
+**Aanmaken** voegt het knooppunt toe aan de YAML.
+
+---
+
+## Waar een knooppunt draait
+
+**Voert uit** zegt wat een knooppunt uitvoert en waar, in één lijst: **Playbook op de RTE**, **Sjabloon op AWX**, **Sjabloon op
+Semaphore**, **Job op Rundeck**, **Job op Jenkins**, en daarna **Workflow**, **Goedkeuring** en **Repository-pull**.
+
+| Voert uit | Het veld eronder | Runner |
+|---|---|---|
+| **Playbook op de RTE** | **Playbook**: een playbook uit de ontwerper | **De standaard RTE**, of een RTE-runner op naam |
+| **Sjabloon op AWX** (inclusief AAP en Ascender) | **Sjabloon**: de naam van de sjabloon, getypt | de AWX-runners, elk met zijn variant |
+| **Sjabloon op Semaphore** | **Sjabloon**: de naam van de sjabloon, getypt | de Semaphore-runners |
+| **Job op Rundeck** of **Job op Jenkins** | **Job**: de naam van de job, getypt | de Rundeck- of Jenkins-runners |
+
+- **Playbook op de RTE** wordt altijd aangeboden; de andere alleen wanneer de instantie een [runner](../runners.html) van dat type heeft.
+- **Runner** toont alleen de runners van dat type, met de standaardrunner gemarkeerd en vooraf geselecteerd (of anders de eerste op naam).
+- Kies je een andere plek, dan wordt gewist wat het knooppunt uitvoert, zodat je dat opnieuw kiest.
+- Een knooppunt waarvan de ontwerper de runner niet kent, toont **Sjabloon of job op** die runner.
+
+Het workflowbestand verandert niet: zo'n knooppunt is een `job_template`-knooppunt met een `runner:` (zie
+[het workflowbestand](file.html#run-settings)).
+
+---
+
+## Een knooppunt bewerken
+
+Klik je op een knooppunt, dan opent zijn dialoog, met vier tabbladen:
+
+| Tabblad | Wat erin staat |
+|---|---|
+| **Wat het uitvoert** | De identifier, **Voert uit**, wat het uitvoert en, bij een playbookknooppunt, de runner |
+| **Hoe het draait** | De uitvoeringsinstellingen; referenties kies je uit een lijst, elk toegevoegd met `+` |
+| **Draait na** | De koppelingen naar het knooppunt toe, en **Alle ouders moeten samenkomen** |
+| **Daarna** | De koppelingen vanuit het knooppunt, met **Koppelen aan een bestaand knooppunt:** en **Koppelen aan een nieuw knooppunt:** |
+
+**Tonen in YAML** opent de YAML op het knooppunt, en **Knooppunt verwijderen** verwijdert het samen met zijn koppelingen. Elke wijziging wordt meteen naar de
+YAML geschreven; **Opslaan** slaat het bestand op.
+
+---
+
+## Uitproberen
+
+Het tabblad **Voorbeeld** speelt de workflow door zonder iets te starten, volgens de regels van AWX.
+
+Elk knooppunt begint als een succes. Klik op een knooppunt om het te laten mislukken, en klik nog eens om het weer te laten slagen; de graaf toont dan
+welke knooppunten zouden draaien, welke niet zouden draaien en of de workflow zou mislukken. **Herstellen** laat elk knooppunt weer slagen.
diff --git a/i18n/nl/_build_forms/workflows/file.md b/i18n/nl/_build_forms/workflows/file.md
new file mode 100644
index 0000000..5d2f966
--- /dev/null
+++ b/i18n/nl/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Het workflowbestand
+parent: Workflows
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# Het workflowbestand
+{: .no_toc }
+
+De syntax van een workflow, de soorten knooppunten en de uitvoeringsinstellingen van elk knooppunt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Waar workflowbestanden staan
+
+Workflowbestanden zijn YAML-bestanden in de lokale map voor workflows en in elke repository die voor workflows wordt gebruikt.
+
+- **De lokale map** is [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), standaard `workflows` onder de
+  persistente map.
+- **Een repository** met **Gebruiken voor workflows?** aan wordt in zijn geheel gelezen, dus de workflowbestanden kunnen in elke map staan. De
+  ontwerper slaat ze terug op in de repository, en **Push** stuurt ze naar de remote.
+
+Elk YAML-bestand met `workflow_job_templates` wordt gelezen, tot zes mappen diep, en één bestand kan meerdere
+workflows bevatten. Een formulier verwijst naar een workflow via zijn `name`, dus houd de namen uniek: delen twee workflows een naam, dan mislukt een job die
+hem uitvoert, met de melding dat je er een moet hernoemen.
+
+---
+
+## De syntax
+
+Een workflowbestand is geschreven in de syntax van een AWX-export, met de knooppunten onder `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+De vorm van de collectie `awx.awx` wordt ook gelezen: `workflow_nodes` direct onder de workflow, en namen geschreven als
+gewone strings (`inventory: staging`) in plaats van maps (`inventory: {name: staging}`).
+
+### De workflow
+
+Een workflow heeft naast zijn knooppunten een paar eigen sleutels:
+
+| Sleutel | Wat het is |
+|---|---|
+| `name` | De naam van de workflow, waarnaar `workflow:` in een formulier verwijst |
+| `description` | Waarvoor hij dient, getoond in de ontwerper |
+| `extra_vars` | Variabelen die elk knooppunt krijgt; de waarden van het formulier winnen ervan |
+| `related.workflow_nodes` | De knooppunten |
+
+### Een knooppunt
+
+Elk knooppunt heeft een identifier, iets dat het uitvoert en zijn koppelingen:
+
+| Sleutel | Wat het is |
+|---|---|
+| `identifier` | De id van het knooppunt: letters, cijfers, punten, streepjes, dubbele punten en underscores, uniek binnen de workflow |
+| `unified_job_template.type` | Wat het knooppunt uitvoert: zie [soorten knooppunten](#node-types) |
+| `unified_job_template.name` | Het playbook, de workflow, de goedkeuring of de repository die het uitvoert |
+| `related.success_nodes` | De knooppunten die draaien wanneer dit knooppunt slaagt |
+| `related.failure_nodes` | De knooppunten die draaien wanneer dit knooppunt mislukt |
+| `related.always_nodes` | De knooppunten die draaien wanneer dit knooppunt klaar is, hoe dan ook |
+| `all_parents_must_converge` | `true`: het knooppunt wacht tot elke koppeling ernaartoe afgaat, niet slechts één |
+
+Koppelingen moeten vooruit wijzen: een workflow waarvan de koppelingen een lus vormen, draait niet.
+
+---
+
+## Soorten knooppunten
+
+Een knooppunt voert een van vier dingen uit, genoemd zoals AWX ze noemt:
+
+| Type | Wat het knooppunt uitvoert |
+|---|---|
+| `job_template` | Een van de playbooks uit de ontwerper, als eigen job op de RTE; of, met `runner:`, de template of job van die runner |
+| `workflow_job_template` | Een andere workflow, als onderliggende workflowjob; workflows nesten tot vijf niveaus diep |
+| `workflow_approval_template` | Een goedkeuring: de workflowjob wacht tot iemand die goedkeurt of afwijst |
+| `project` | Een pull van de repository die het noemt (de project update van AWX) |
+
+De `unified_job_template.timeout` van een goedkeuringsknooppunt is in seconden. Verstrijkt die zonder antwoord, dan mislukt het knooppunt; `0` of geen
+timeout wacht op een antwoord, hoe lang dat ook duurt. Een afgewezen goedkeuring laat het knooppunt mislukken, en de workflow gaat verder langs zijn
+koppelingen.
+
+---
+
+## Uitvoeringsinstellingen
+
+Een `job_template`-knooppunt neemt de instellingen van een AWX-knooppunt, op het knooppunt zelf:
+
+| Sleutel | Wat het doet |
+|---|---|
+| `inventory` | De inventaris waartegen het playbook draait, op naam, zoals `inventory:` in een formulier |
+| `related.credentials` | De inloggegevens: elk komt onder zijn eigen naam bij het playbook aan, en de eerste *SSH*-referentie is ook de login waarmee ansible verbindt. Een vault-referentie opent alleen de vaults |
+| `limit` | Draait alleen op deze hosts (`--limit`) |
+| `job_tags` | Voert alleen de taken met deze tags uit (`--tags`) |
+| `skip_tags` | Slaat de taken met deze tags over (`--skip-tags`) |
+| `verbosity` | `0` tot `5`: het aantal `-v` |
+| `diff_mode` | `true`: toont de wijzigingen (`--diff`) |
+| `job_type` | `check`: een proefrun (`--check`); `run` of niets: een echte run |
+| `extra_data` | Variabelen die dit knooppunt krijgt, onder de `extra_vars` van de workflow en de waarden van het formulier |
+
+De job van het knooppunt krijgt de waarden van het formulier als extra vars. De waarden van het formulier winnen van de `extra_vars` van de workflow, die op hun beurt winnen
+van de `extra_data` van het knooppunt, zoals de antwoorden op een survey dat in AWX doen.
+
+---
+
+## Eigen sleutels van AnsibleForms
+
+Drie sleutels van een knooppunt zijn eigen aan AnsibleForms, en AWX negeert ze, zodat een workflow kan doen wat een multistep-formulier doet:
+
+| Sleutel | Wat het doet |
+|---|---|
+| `runner` | Op een `job_template`-knooppunt: voert de template of job van die runner uit in plaats van een playbook uit de ontwerper: AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins. Een RTE-runner voert daar het playbook van het knooppunt uit. Eén workflow kan ze combineren. |
+| `if_extra_var` | Het knooppunt draait alleen wanneer deze extra var `true` is, zoals `ifExtraVar` van een multistep-stap. Wordt er niet aan voldaan, dan wordt het knooppunt overgeslagen en draait wat erna komt als na een succes. Niet op een goedkeuringsknooppunt, dat altijd draait. |
+| `extra_vars_key` | Het knooppunt krijgt alleen deze sleutel van de extra vars, met de gebruiker erin gekopieerd, zoals `key` van een multistep-stap |
+
+Op een template-runner is `unified_job_template.name` de template of job die wordt uitgevoerd, en de `limit`, `job_tags`, check-modus
+en diff-modus van het knooppunt worden doorgegeven zoals een formulier van het type van die runner ze zou doorgeven. Een `verbosity` boven `0` zet
+`verbose` van het formulier aan, en `skip_tags` wordt niet doorgegeven. Alleen een AWX-runner (AWX, AAP of Ascender) krijgt de inventaris van het knooppunt, en de
+inloggegevens als zijn AWX-credentials; Semaphore, Rundeck en Jenkins krijgen de inloggegevens als de `credentials` van een formulier.
diff --git a/i18n/nl/_build_forms/workflows/index.md b/i18n/nl/_build_forms/workflows/index.md
new file mode 100644
index 0000000..920b5ec
--- /dev/null
+++ b/i18n/nl/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflows
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflows
+{: .no_toc }
+
+Koppel playbooks, goedkeuringen en andere workflows aan elkaar, zoals AWX dat doet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor formulierauteurs: wat een workflow is, hoe de knooppunten draaien en waar je verder kunt lezen.
+
+Een workflow is een graaf van knooppunten. Elk knooppunt voert iets uit: een van de playbooks uit de ontwerper, een andere workflow, een goedkeuring
+of een pull van een repository. Koppelingen tussen de knooppunten bepalen wat daarna draait, bij succes, bij fout of altijd. Een formulier van
+[type `workflow`](../forms/workflow.html) start de workflow, en de jobspagina tekent hem live terwijl hij draait.
+
+Workflows volgen de syntax en de regels van AWX, dus een workflow die je uit AWX exporteert, leest in AnsibleForms precies hetzelfde. Ze draaien op
+de RTE, zonder AWX: een playbookknooppunt is een eigen job, met de inventaris, inloggegevens, limit en tags van dat knooppunt.
+
+---
+
+## Hoe een workflow draait
+
+De knooppunten draaien volgens de regels van AWX, en takken die niet van elkaar afhangen draaien naast elkaar.
+
+- **Een knooppunt zonder ouder start meteen**, zodra de workflow start.
+- **Een koppeling gaat af wanneer haar knooppunt klaar is**: een *bij succes*-koppeling na een succes, een *bij fout*-koppeling na een fout,
+  een *altijd*-koppeling na allebei. Een geannuleerd knooppunt laat geen enkele koppeling afgaan.
+- **Een knooppunt start zodra één koppeling ernaartoe afgaat.** Staat **Alle ouders moeten samenkomen** aan, dan wacht het tot elke koppeling
+  ernaartoe is afgegaan.
+- **Een knooppunt dat niet meer kan starten, krijgt de markering *draait niet***, net als de knooppunten die alleen door dat knooppunt gestart konden worden.
+- **De workflow mislukt wanneer een knooppunt mislukte en niets dat opvangt**: dat knooppunt heeft geen *bij fout*- en geen *altijd*-koppeling.
+  Een fout die door een koppeling wordt opgevangen, laat de workflow niet mislukken.
+
+Een knooppunt met een voorwaarde (`if_extra_var`) waaraan niet wordt voldaan, wordt overgeslagen. Wat erna komt draait als na een succes. Een
+goedkeuringsknooppunt neemt geen voorwaarde: het wacht altijd op een antwoord.
+
+---
+
+## Gegevens doorgeven tussen knooppunten
+
+Wat het playbook van een knooppunt met `set_stats` verzamelt, komt bij de knooppunten erna aan als extra vars, zoals AWX de artifacts van een
+job doorgeeft. Een knooppunt krijgt de gegevens van elke ouder waarvan de koppeling ernaartoe afging, samengevoegd in de volgorde waarin de ouders
+staan, en geeft door wat het kreeg plus de gegevens van zijn eigen job, waarbij die van hemzelf winnen als beide dezelfde sleutel zetten.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Een knooppunt erna leest dan {% raw %}`{{ version }}` en `{{ build_id }}`{% endraw %} zoals elke andere extra var.
+
+De extra vars van een knooppunt komen van vier plekken. Een daarvan, `extra_data`, zijn de eigen variabelen van het knooppunt: de naam die AWX ervoor gebruikt,
+ingesteld op het knooppunt in het [workflowbestand](file.html#run-settings). Zetten twee bronnen dezelfde sleutel, dan geldt de voorrangsvolgorde
+van AWX, laagste eerst:
+
+| Bron | Wint van |
+|---|---|
+| de eigen variabelen van het knooppunt (`extra_data`) | niets |
+| de gegevens die met `set_stats` zijn doorgegeven | de `extra_data` van het knooppunt |
+| de `extra_vars` van de workflow | de doorgegeven gegevens |
+| de waarden van het formulier | alles |
+
+- Alleen de gegevens voor het hele playbook worden doorgegeven: `set_stats` met `per_host: false`, de standaard.
+- Een goedkeuringsknooppunt, een overgeslagen knooppunt en een projectknooppunt geven door wat bij hen binnenkwam.
+- De uitvoer van een knooppunt eindigt met de sleutels die het doorgaf, alleen op naam, omdat de waarden geheim kunnen zijn.
+- De job van het knooppunt bewaart zijn gegevens als artifacts (**Toon artifacts** op zijn pagina), en de workflowjob bewaart de gegevens van al zijn
+  knooppunten, zodat een geneste workflow ze ook doorgeeft aan de knooppunten erna.
+- Een knooppunt dat op een AWX-runner draait, geeft de artifacts van zijn AWX-job op dezelfde manier door.
+---
+
+## In deze sectie
+
+De volgende pagina's beschrijven workflows in detail:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Het workflowbestand](file.html) | De syntax van het bestand, de soorten knooppunten en de uitvoeringsinstellingen van elk knooppunt |
+| [Bewerken in de ontwerper](designer.html) | De sectie Workflows van de ontwerper: de graaf, de dialogen voor knooppunten en koppelingen en de proefrun |
+| [Een workflow uitvoeren](running.html) | Het formulier dat hem start, de jobpagina, de uitvoer van knooppunten, goedkeuringen en afbreken |
diff --git a/i18n/nl/_build_forms/workflows/running.md b/i18n/nl/_build_forms/workflows/running.md
new file mode 100644
index 0000000..f7bb70b
--- /dev/null
+++ b/i18n/nl/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Een workflow uitvoeren
+parent: Workflows
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Een workflow uitvoeren
+{: .no_toc }
+
+Start een workflow vanuit een formulier en volg hem op de jobspagina
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het formulier
+
+Een formulier van [type `workflow`](../forms/workflow.html) start een workflow, aangeduid met `workflow:` zoals een playbook: via
+zijn **bestand** in de map voor workflows, met de submappen (`team/deploy-app.yml`), of via de **naam** van de workflow in
+het bestand (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+De velden van het formulier komen als extra vars bij elk knooppunt aan, en dat geldt ook voor zijn [`credentials`](../forms/workflow.html#workflow_credentials), onder de namen
+die het formulier ze geeft, zoals die van een multistep-formulier bij zijn stappen aankomen:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+De eigen referenties van een knooppunt, ingesteld in het workflowbestand, komen onder hun eigen naam bij zijn playbook aan en winnen als beide dezelfde naam gebruiken. In het tabblad Visueel van een formulier in de ontwerper is **Workflow** een lijst van de
+workflowbestanden van de ontwerper.
+
+Een bestandsnaam alleen wordt ook in een submap gevonden, zolang maar één bestand die naam heeft. Twee workflows met dezelfde naam houden een formulier tegen dat
+de workflow op naam aanduidt, en de ontwerper waarschuwt wanneer je de tweede opslaat: hernoem er een, of verwijs naar het bestand. Een workflow die niet
+gevonden wordt, laat de job mislukken, met de reden in de uitvoer.
+
+---
+
+## De job
+
+Een workflowjob draait op de AnsibleForms-server, en elk playbookknooppunt draait als een eigen job, een kind van de workflowjob,
+zoals de stappen van een multistep-formulier: een playbook uit de ontwerper op de RTE, of, bij een knooppunt met een `runner:`, de
+sjabloon of job van die runner op AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins (zie [Waar een knooppunt draait](designer.html#where-a-node-runs)).
+
+De pagina van de job tekent de workflow, live: elk knooppunt gekleurd naar zijn status, de koppelingen die afgingen en de knooppunten die niet
+zullen draaien. De gegevens bovenaan noemen de workflow in plaats van een playbook.
+
+- **Klik op een knooppunt** dat klaar is om de uitvoer in een dialoog te openen.
+- **De uitvoer** bevat de uitvoer van elk knooppunt onder een banner `WORKFLOW NODE [identifier] (status)`, in de volgorde waarin de knooppunten
+  klaar waren.
+- **Toon extravars** en **Toon artifacts**, in de kop van elk knooppunt in de uitvoer en in de dialoog die je vanuit de graaf opent,
+  tonen de eigen extravars en artifacts van dat knooppunt (`{}` als er geen zijn), als JSON of YAML, met een knop Kopiëren.
+
+De extravars van een knooppunt bevatten wat de knooppunten ervoor doorgaven, en zijn artifacts wat zijn playbook met
+`set_stats` verzamelde. De twee knoppen volgen de [rolopties](../config/roles.html#role-options) `showExtravars` en
+`showArtifacts`. Dezelfde gegevens komen uit `GET /api/v2/job/{id}/node/{nodeId}`, voor iedereen die de job mag zien.
+
+De job mislukt wanneer een knooppunt mislukte en niets dat opving, volgens de regel van AWX; anders slaagt hij.
+
+---
+
+## Goedkeuringen
+
+Een goedkeuringsknooppunt houdt de workflowjob vast tot iemand antwoordt.
+
+Bereikt de workflow een goedkeuringsknooppunt, dan wordt de status van de job **Wacht op goedkeuring**: dat zie je bij de bel en op de
+pagina van de job, zoals bij een [goedkeuringspunt](../forms/approval.html) van een formulier. De naam van het knooppunt is de titel van de goedkeuring en de beschrijving
+het bericht; de rest komt uit `approval` van het formulier:
+
+- zijn `roles` bepalen wie hem kan goedkeuren of afwijzen, en `allowSelf` of degene die de job startte hem ook mag goedkeuren;
+- naar zijn `notifications` en `channels` wordt het verzoek gestuurd.
+
+Een workflowformulier zonder `approval` houdt de job nog steeds vast bij een goedkeuringsknooppunt, maar dan kan alleen een admin hem goedkeuren.
+
+- **Goedgekeurd**: het knooppunt slaagt en de workflow gaat verder langs zijn *bij succes*-koppelingen.
+- **Afgewezen**: het knooppunt mislukt en de workflow gaat verder langs zijn *bij fout*-koppelingen.
+- **Verlopen**, na de time-out van het knooppunt zonder antwoord: ook dan mislukt het knooppunt.
+
+---
+
+## Afbreken
+
+**Afbreken** op een lopende workflowjob stopt hem: de lopende jobs van knooppunten worden afgebroken, er start niets meer, en een goedkeuring waarop hij
+wacht wordt geannuleerd. Ook een workflowjob die op een goedkeuring wacht, kun je afbreken.
diff --git a/i18n/nl/_configure/announcements.md b/i18n/nl/_configure/announcements.md
new file mode 100644
index 0000000..13e462c
--- /dev/null
+++ b/i18n/nl/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Aankondigingen
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Aankondigingen
+{: .no_toc }
+
+Berichten onder de kopbalk voor iedereen, zoals een onderhoudsvenster, elk van het begin tot het einde ervan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: informeer alle gebruikers over een onderhoudsvenster of een incident, onder **Instellingen > Uiterlijk > Aankondigingen**.
+
+De pagina vereist de rolinstelling `showSettings` of `showAppearanceSettings`. Vanaf 7.3.0 is het één lijst, en heeft elke aankondiging
+een eigen pagina en een eigen schakelaar Ingeschakeld.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Algemeen](announcements/general.html) | De schakelaar Ingeschakeld van elke aankondiging, die de schakelaar voor alle aankondigingen samen verving |
+| [Lijst](announcements/list.html) | De aankondigingen die nog niet zijn afgelopen, hun kolommen en de pagina van een aankondiging |
+| [Er een toevoegen](announcements/adding-one.html) | De wizard in twee stappen: het bericht, en daarna wanneer het wordt getoond |
+
+
+---
+
+## Waar ze verschijnen
+
+Aankondigingen verschijnen als een regel onder de kopbalk van elke pagina, voor elke aangemelde gebruiker, elk in de kleur van het type.
+
+Er kunnen meerdere ingeschakelde tegelijk verschijnen, de nieuwste eerst. De aanmeldpagina en een formulier dat in een andere site is ingesloten tonen er geen.
+
+Elke aankondiging heeft een sluitknop. Een gesloten aankondiging blijft in dat browsertabblad gesloten totdat het tabblad wordt gesloten, of
+totdat het bericht of de einddatum verandert. Een opgeslagen aankondiging bereikt alle geopende browsers tegelijk; een aankondiging die
+haar start- of einddatum bereikt, verschijnt of verdwijnt daar binnen een minuut.
diff --git a/i18n/nl/_configure/announcements/adding-one.md b/i18n/nl/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..e25aff3
--- /dev/null
+++ b/i18n/nl/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Er een toevoegen
+parent: Aankondigingen
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Er een toevoegen
+{: .no_toc }
+
+De wizard in twee stappen: het bericht, en daarna wanneer het wordt getoond
+{: .fs-6 .fw-300 }
+
+**Aankondiging toevoegen** opent een wizard in twee stappen. **Bericht** vraagt wat erin staat:
+
+| Veld | Betekenis |
+|---|---|
+| **Bericht** | De tekst, maximaal 500 tekens. Verplicht. |
+| **Type** | De kleur en het pictogram: blauw voor Info (de standaard), oranjegeel voor Waarschuwing, rood voor Gevaar |
+
+**Wanneer** vraagt wanneer het wordt getoond:
+
+| Veld | Betekenis |
+|---|---|
+| **Startdatum** | Vanaf dit moment wordt het getoond. Laat het leeg om het meteen te tonen. |
+| **Einddatum** | Op dit moment verdwijnt het en wordt het verwijderd. Laat het leeg om het te bewaren totdat je het verwijdert. |
+
+De einddatum moet na de startdatum liggen, en in de toekomst.
diff --git a/i18n/nl/_configure/announcements/general.md b/i18n/nl/_configure/announcements/general.md
new file mode 100644
index 0000000..0555482
--- /dev/null
+++ b/i18n/nl/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Algemeen
+parent: Aankondigingen
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Algemeen
+{: .no_toc }
+
+De schakelaar Ingeschakeld van elke aankondiging, die de schakelaar voor alle aankondigingen samen verving
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Een aankondiging in- of uitschakelen
+
+Vanaf 7.3.0 wordt elke aankondiging afzonderlijk in- of uitgeschakeld, met haar schakelaar **Ingeschakeld**.
+
+Een nieuwe aankondiging is ingeschakeld. **Uitschakelen** in het menu van haar rij, of de schakelaar **Ingeschakeld** op haar pagina, verbergt haar onder de kopbalk en houdt haar
+in de lijst, en **Inschakelen** toont haar weer vanaf haar startdatum tot haar einddatum. De schakelaar wordt meteen opgeslagen.
+
+---
+
+## De schakelaar Aankondigingen tonen van 7.2
+
+Tot en met 7.2 had een tabblad **Algemeen** een schakelaar **Aankondigingen tonen** die ze allemaal tegelijk in- of uitschakelde.
+
+Vanaf 7.3.0 bestaat die schakelaar niet meer. Stond hij uit, dan schakelt de upgrade alle aankondigingen uit, zodat er geen begint te verschijnen: schakel de aankondigingen die je wilt opnieuw in.
diff --git a/i18n/nl/_configure/announcements/list.md b/i18n/nl/_configure/announcements/list.md
new file mode 100644
index 0000000..51f0aa6
--- /dev/null
+++ b/i18n/nl/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Lijst
+parent: Aankondigingen
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Lijst
+{: .no_toc }
+
+De aankondigingen die nog niet zijn afgelopen, hun kolommen en de pagina van een aankondiging
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De lijst
+
+**Instellingen > Uiterlijk > Aankondigingen** toont elke aankondiging die nog niet is afgelopen, met deze kolommen:
+
+| Kolom | Betekenis |
+|---|---|
+| **Ingeschakeld** | Of ze onder de kopbalk verschijnt van haar begin tot haar einde (vanaf 7.3.0) |
+| **Bericht** | De tekst onder de kopbalk |
+| **Type** | Info, Waarschuwing of Gevaar |
+| **Startdatum** | Wanneer ze begint te verschijnen; `–` als ze meteen verschijnt |
+| **Einddatum** | Wanneer ze eindigt; `–` als ze verschijnt totdat ze wordt verwijderd |
+| **Gemaakt door** | Wie haar heeft toegevoegd |
+
+Een klik op een rij, of **Bewerken** in het menu van de rij, opent de pagina van de aankondiging. Het menu heeft ook **Inschakelen** of **Uitschakelen**, en **Verwijderen**.
+
+Zodra de einddatum voorbij is, wordt een aankondiging verwijderd: de lijst bewaart alleen de komende en de aankondigingen die nu verschijnen.
+
+---
+
+## De pagina van een aankondiging
+
+Vanaf 7.3.0 opent elke aankondiging op een eigen pagina, op `/settings/announcements/<id>`, met één tabblad, **Details**.
+
+Daarop staan het bericht, het type, de start- en einddatum en de schakelaar **Ingeschakeld**, die meteen wordt opgeslagen; de andere velden worden opgeslagen
+met **Opslaan**, en **Verwijderen** verwijdert de aankondiging. De titel van de pagina noemt haar bij de eerste tekens van haar bericht.
diff --git a/i18n/nl/_configure/appearance.md b/i18n/nl/_configure/appearance.md
new file mode 100644
index 0000000..2c6ac92
--- /dev/null
+++ b/i18n/nl/_configure/appearance.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Uiterlijk
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Uiterlijk
+{: .no_toc }
+
+De standaardwaarden, de naam, het logo, het browserpictogram, de links in de kopbalk en de labels naast het logo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: geef de instantie je eigen uiterlijk, onder **Instellingen > Uiterlijk**, met de rolinstelling `showSettings`.
+Alleen de rolinstelling `showAppearanceSettings` opent deze pagina's ook, aankondigingen inbegrepen, zonder de rest van de instellingen.
+
+De pagina's van deze groep zijn **Standaardwaarden**, **Naam**, **Logo**, **Pictogram**, **Links**, **Labels** en **Aankondigingen**;
+aankondigingen hebben een eigen pagina, [Aankondigingen](announcements.html). Een opgeslagen standaardwaarde, naam, link of label
+verschijnt meteen in alle geopende browsers.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Standaardwaarden](appearance/defaults.html) | Het thema, de taal, de tijdzone en de datumnotatie voor gebruikers die zelf niets hebben gekozen |
+| [Naam](appearance/name.html) | De applicatienaam in het browsertabblad en op de aanmeldpagina |
+| [Logo](appearance/logo.html) | Je eigen logo in de kopbalk |
+| [Pictogram](appearance/icon.html) | Je eigen pictogram in het browsertabblad en in bladwijzers |
+| [Links](appearance/links.html) | De links in de kopbalk, ingebouwd en eigen |
+| [Labels](appearance/labels.html) | Labels naast het logo die aangeven welke instantie dit is; tot en met 7.2 één label Omgeving |
+
diff --git a/i18n/nl/_configure/appearance/defaults.md b/i18n/nl/_configure/appearance/defaults.md
new file mode 100644
index 0000000..46c4ce3
--- /dev/null
+++ b/i18n/nl/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Standaardwaarden
+parent: Uiterlijk
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Standaardwaarden
+{: .no_toc }
+
+Het thema, de taal, de tijdzone en de datumnotatie voor gebruikers die zelf niets hebben gekozen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De standaardwaarden
+
+**Standaardwaarden** bepaalt hoe de app eruitziet voor een gebruiker die in zijn
+[voorkeuren](../profile/preferences.html) zelf geen keuze heeft gemaakt; de eigen keuze van een gebruiker gaat altijd voor:
+
+| Veld | Keuzes | Zonder keuze |
+|---|---|---|
+| **Standaardthema** | Browser volgen, Licht, Donker of Kleur, met een van 12 kleuren voor Kleur | Browser volgen (Licht tot en met 7.2) |
+| **Standaardtaal** | De talen van de app, bewaard in [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Engels |
+| **Standaard formulierweergave** | Tegels of Lijst, voor de formulierenpagina | Tegels |
+| **Standaard tijdzone** | UTC, de browser van elke gebruiker, of een willekeurige zone op naam | UTC |
+| **Standaard datumnotatie** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` of `DD.MM.YYYY`, getoond met de datum van vandaag | `YYYY-MM-DD` |
+
+De taal is een omgevingsvariabele en geldt zonder herstart. Met
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) op `0` toont de pagina haar alleen-lezen.
+
+Vanaf 7.3.0 staat de pagina in de twee tabbladen van de profielvoorkeuren, **Weergave** (thema, taal en formulierweergave) en **Datum en
+tijd** (tijdzone en datumnotatie, met een voorbeeld van de huidige tijd), en het zoekvak toont de treffers onder de naam van elk tabblad.
+
+---
+
+## De browser volgen
+
+Vanaf 7.3.0 toont **Browser volgen** elke gebruiker het lichte of donkere thema waar zijn browser om vraagt, en wisselt mee.
+
+Het is de standaard als er geen standaardthema is gekozen, dus een nieuwe installatie volgt de browser. Als je met de muis over een van de kleuren van
+**Kleur** gaat, zie je een voorbeeld van de app in die kleur; het thema dat je had komt terug zodra de aanwijzer weggaat, en er wordt niets bewaard tot **Opslaan**.
diff --git a/i18n/nl/_configure/appearance/icon.md b/i18n/nl/_configure/appearance/icon.md
new file mode 100644
index 0000000..38e598e
--- /dev/null
+++ b/i18n/nl/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Pictogram
+parent: Uiterlijk
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Pictogram
+{: .no_toc }
+
+Je eigen pictogram in het browsertabblad en in bladwijzers
+{: .fs-6 .fw-300 }
+
+**Pictogram** vervangt het pictogram van AnsibleForms in het browsertabblad en in bladwijzers:
+
+| Regel | Waarde |
+|---|---|
+| Typen | PNG, ICO, SVG, WEBP, GIF en JPEG |
+| Grootste bestand | 256 KB |
+| Beste resultaat | Een vierkante afbeelding van minstens 64 × 64 px, of een SVG |
+
+Kies een bestand onder **Nieuw pictogram** en klik op **Uploaden**; **Eigen pictogram verwijderen** zet het standaardpictogram terug.
diff --git a/i18n/nl/_configure/appearance/labels.md b/i18n/nl/_configure/appearance/labels.md
new file mode 100644
index 0000000..84abf8f
--- /dev/null
+++ b/i18n/nl/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Labels
+parent: Uiterlijk
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Labels
+{: .no_toc }
+
+Labels naast het logo die aangeven welke instantie dit is
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De lijst
+
+Vanaf 7.3.0 bevat **Instellingen > Uiterlijk > Labels** meerdere labels naast het logo in de kopbalk, zoals PRODUCTION en EU:
+
+| Kolom | Betekenis |
+|---|---|
+| **Ingeschakeld** | Of het label naast het logo en op de aanmeldpagina verschijnt |
+| **Label** | De tekst ervan, getoond als het gekleurde pilletje in de kopbalk |
+
+De rijen staan in de volgorde van de kopbalk. Een klik op een rij, of **Bewerken** in het menu van de rij, opent de pagina van het label; het menu van de rij heeft ook
+**Inschakelen** of **Uitschakelen**, afhankelijk van wat van toepassing is, **Omhoog** en **Omlaag** om de volgorde te wijzigen, en **Verwijderen**.
+
+De kopbalk en de aanmeldpagina tonen de ingeschakelde labels in hun volgorde. Boven de drie bevat een grijze **+N** de overige in zijn tooltip,
+en een telefoon toont het eerste label en de **+N**. Een opgeslagen label verschijnt meteen in alle geopende browsers.
+
+---
+
+## Een label toevoegen
+
+**Label toevoegen** opent een dialoogvenster met de twee velden van het label, beide verplicht:
+
+| Veld | Betekenis |
+|---|---|
+| **Label** | De tekst van het label, zoals PRODUCTION |
+| **Kleur** | Blauw, groen, oranjegeel, oranje, rood of grijs, als ronde stalen; eerst rood |
+
+Een voorbeeld toont de kopbalk met alle ingeschakelde labels en het nieuwe terwijl het wordt getypt. Een nieuw label is ingeschakeld en komt na de
+andere. De pagina ervan heeft één tabblad, **Details**, met dezelfde velden, de schakelaar **Ingeschakeld**, die meteen wordt opgeslagen, en het voorbeeld.
+
+---
+
+## Het omgevingslabel van 7.2
+
+Tot en met 7.2 stelde **Instellingen > Uiterlijk > Omgeving** één label naast het logo in.
+
+Met één label lezen PRODUCTION EU en PRODUCTION US allebei PRODUCTION wanneer meerdere instanties naast elkaar open staan. Vanaf 7.3.0
+maakt de upgrade van dat label het eerste van de lijst, met zijn tekst, zijn kleur en of het werd getoond, en het oude adres
+**Omgeving** opent de lijst.
+
+---
+
+## Labels in de configuratie-seed
+
+Vanaf 7.3.0 declareert de [configuratie-seed](../seed/) labels in zijn sectie `labels`, elk met de tekst en optioneel de kleur:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` is een van `blue`, `green`, `amber`, `orange`, `red` of `grey`, en `position` bepaalt de volgorde, laagste eerst. Een label dat
+in de seed is gedeclareerd, is op zijn pagina alleen-lezen, zoals elk [beheerd object](../seed/managed-objects.html).
diff --git a/i18n/nl/_configure/appearance/links.md b/i18n/nl/_configure/appearance/links.md
new file mode 100644
index 0000000..c8107e5
--- /dev/null
+++ b/i18n/nl/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Links
+parent: Uiterlijk
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Links
+{: .no_toc }
+
+De links in de kopbalk, ingebouwd en eigen
+{: .fs-6 .fw-300 }
+
+**Links** stelt de links in de kopbalk in, voor elke aangemelde gebruiker, in twee tabbladen.
+
+**Ingebouwd** heeft de schakelaar **Designer**, bewaard in [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) en toegepast
+zonder herstart. Uitgeschakeld is de designer voor iedereen verdwenen: de link, de pagina en de API.
+
+**Eigen** bevat je eigen links, zoals een wiki, een runbook of een supportportaal. **Link toevoegen** voegt een rij toe met deze velden:
+
+| Veld | Betekenis |
+|---|---|
+| **Pictogram** | Het pictogram voor het label, gekozen uit een lijst |
+| **Label** | De tekst van de link |
+| **Adres** | Een site (`https://…`) of een pagina van de app (`/forms/all`) |
+| **Nieuw tabblad** | Opent de link in een nieuw browsertabblad |
+
+De knoppen van een rij verplaatsen hem: **→** zet de link in de link erboven, die dan als menu in de kopbalk opent,
+**←** haalt hem er weer uit naar de kopbalk, en de pijlen omhoog en omlaag verplaatsen hem (een menu met de links erin).
+Een menu heeft geen eigen adres nodig.
+
+De kopbalk bevat maximaal 5 van je links na de ingebouwde, en maximaal 10 in elk menu.
diff --git a/i18n/nl/_configure/appearance/logo.md b/i18n/nl/_configure/appearance/logo.md
new file mode 100644
index 0000000..d880238
--- /dev/null
+++ b/i18n/nl/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logo
+parent: Uiterlijk
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logo
+{: .no_toc }
+
+Je eigen logo in de kopbalk
+{: .fs-6 .fw-300 }
+
+**Logo** vervangt het AnsibleForms-logo in de kopbalk door je eigen afbeelding, getoond in elk thema:
+
+| Regel | Waarde |
+|---|---|
+| Typen | PNG, JPEG, WEBP, GIF en SVG |
+| Grootste bestand | 900 KB |
+| Grootte in de kopbalk | Maximaal 200 × 33 px, met behoud van verhoudingen |
+
+Kies een bestand onder **Nieuw logo** om een voorbeeld te zien en klik dan op **Uploaden**. **Huidig logo** toont het logo dat in gebruik is en de grootte
+waarop de kopbalk het toont. **Eigen logo verwijderen** zet het standaardlogo terug, dat het thema volgt.
diff --git a/i18n/nl/_configure/appearance/name.md b/i18n/nl/_configure/appearance/name.md
new file mode 100644
index 0000000..ab2438b
--- /dev/null
+++ b/i18n/nl/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Naam
+parent: Uiterlijk
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Naam
+{: .no_toc }
+
+De applicatienaam in het browsertabblad en op de aanmeldpagina
+{: .fs-6 .fw-300 }
+
+**Naam** bevat de **Applicatienaam**, getoond in het browsertabblad en op de aanmeldpagina. Leeg toont het browsertabblad
+`AnsibleForms` en toont de aanmeldpagina geen naam.
diff --git a/i18n/nl/_configure/authentication/entra-id.md b/i18n/nl/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..f237cad
--- /dev/null
+++ b/i18n/nl/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Authenticatie
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Single sign-on met Microsoft Entra ID (Azure AD), met rollen op basis van de Entra ID-groepen van de gebruiker
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Hoe het werkt
+
+Met een ingeschakelde Entra ID-provider toont de aanmeldpagina een Entra ID-knop onder **Aanmelden**. Een aanmelding verloopt dan als volgt:
+
+1. De knop stuurt de browser naar `/api/v2/auth/entraid`, dat hem doorstuurt naar Microsoft.
+2. De gebruiker meldt zich aan bij Microsoft, dat met een autorisatiecode terugstuurt naar de **Omleidings-URI**. De server
+   wisselt die code bij Microsoft in voor het ID-token en een toegangstoken voor Microsoft Graph.
+3. De server leest de groepen van de gebruiker uit Microsoft Graph (`/v1.0/me/transitiveMemberOf`), zodat geneste groepen ook meetellen.
+4. De groepen worden met het **Groepfilter** op hun weergavenaam gefilterd, en elke groep die overblijft wordt twee keer opgeslagen,
+   als `azuread/<object id>` en als `azuread/<display name>`.
+
+De gebruikersnaam is de claim `upn` van het token, bijv. `jdoe@example.com`, of de claim `preferred_username` als het token
+geen `upn` heeft; voor een werkaccount bevatten beide dezelfde waarde.
+
+---
+
+## De applicatie registreren
+
+AnsibleForms heeft een app-registratie nodig in het Entra-beheercentrum, onder **App registrations > New registration**:
+
+1. Geef haar een naam, kies **Accounts in this organizational directory only** als ondersteunde accounttypen, en voeg een
+   omleidings-URI van het type **Web** toe: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. Maak onder **Certificates & secrets** een clientgeheim aan en kopieer de waarde; die wordt maar één keer getoond.
+3. Voeg onder **API permissions** de **gedelegeerde** Microsoft Graph-machtigingen `User.Read` en `GroupMember.Read.All` toe,
+   en verleen er beheerderstoestemming voor.
+4. Noteer op de pagina **Overview** de **Application (client) ID** en de **Directory (tenant) ID**.
+
+De omleidings-URI is het adres waarop gebruikers AnsibleForms bereiken, gevolgd door `/api/v2/auth/entraid/callback`.
+Met [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms` wordt dat
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Hij moet exact overeenkomen met de **Omleidings-URI** van de
+referentie van de provider.
+
+Tot en met 7.2.0 was het pad `/api/v2/auth/azureadoauth2/callback`. Vanaf 7.3.0 werkt het nog steeds, dus een bestaande registratie
+hoeft niet te worden gewijzigd; een referentie met een lege **Omleidings-URI** gebruikt het nieuwe pad, dus voeg dat dan aan de registratie toe.
+
+AnsibleForms leest de groepen uit Graph en gebruikt geen groepsclaim in het token, dus er hoeft geen groepsclaim
+op de registratie te worden geconfigureerd.
+
+---
+
+## De provider toevoegen
+
+Voeg de provider toe onder **Toegang > SSO**: een wizard vraagt de velden in vier stappen, met **Microsoft Entra ID** in de stap **Type**:
+
+| Stap | Veld | Betekenis |
+|---|---|---|
+| Details | Naam, Beschrijving | Een unieke naam voor de provider, en een optionele beschrijving |
+| Type | Provider | **Microsoft Entra ID**; ingesteld bij het aanmaken, blijft zo |
+| Referenties | Referentie | Een referentie van het type **Microsoft Entra ID** uit [Verbindingen > Inloggegevens](../credentials.html), zie hieronder |
+| Groepen | Groepfilter | Reguliere expressie; alleen de groepen waarvan de weergavenaam overeenkomt blijven over. Leeg houdt elke groep |
+
+De referentie bevat de app-registratie, dus alleen een admin kan haar toevoegen of wijzigen:
+
+| Veld | Betekenis |
+|---|---|
+| Tenant ID | Verplicht. De Directory (tenant) ID, een GUID, of een van de domeinen van de tenant. Alleen gebruikers van die tenant kunnen zich aanmelden |
+| Client ID | De Application (client) ID |
+| Client secret | De waarde van het clientgeheim, versleuteld opgeslagen of gelezen uit een [secret store](../secret-stores/) |
+| Omleidings-URI | Zoals geregistreerd, bijv. `https://af.example.com/api/v2/auth/entraid/callback`. Leeg: de URL van de app en het callbackpad |
+
+Een referentie met een lege tenant ID wordt bij het opslaan geweigerd. De multi-tenant-endpoints `common`, `organizations`
+en `consumers` worden geweigerd wanneer de provider die de referentie noemt wordt opgeslagen, omdat ze gebruikers van elke
+Microsoft-tenant zouden laten aanmelden. Bij het aanmelden controleert de server ook dat het token van de geconfigureerde tenant komt. Een provider
+die eerder zonder tenant ID is opgeslagen, meldt niemand aan: zolang de tenant ID niet is ingevuld, logt de server
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Tot en met 7.2.0 waren de tenant, de client ID, het geheim en de redirect URL velden van de provider. De upgrade naar 7.3.0 verplaatst ze naar een
+referentie met de naam `<provider>-sso`, zie [Adressen in referenties](../credentials/types.html#addresses-in-credentials).
+Kies voor elke nieuwe provider een referentie: de server accepteert nog steeds een provider met een eigen client ID en geheim van
+vóór 7.3.0, die zich daarmee aanmeldt totdat er een referentie is gekozen.
+
+Er is steeds één Entra ID-provider ingeschakeld, degene waarmee de Entra ID-knop aanmeldt. **Inschakelen** in het menu van de rij van een andere,
+of zijn schakelaar **Ingeschakeld**, schakelt de andere van hetzelfde type uit; de kolom **Ingeschakeld** van de lijst toont welke in gebruik is. Een provider
+kan ook de aanmeldpagina overslaan, zie [Single sign-on omschakelen](./#switching-single-sign-on). Opslaan past het meteen toe, zonder herstart.
+
+---
+
+## Koppelen aan rollen
+
+In config.yaml is een Entra ID-groep `entraid/<object id>` of `entraid/<display name>`, en een gebruiker `entraid/<upn>`.
+Het object-id is uniek in de tenant en dus de veiligere keuze; een weergavenaam is makkelijker te lezen:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Tot en met 7.2.0 was het voorvoegsel `azuread/`. In een rol matcht het vanaf 7.3.0 nog steeds dezelfde leden en wordt het in 8.0 verwijderd; de
+roleditor schrijft `entraid/`. Alleen de rollen accepteren `entraid/`: de groepen van de gebruiker worden opgeslagen als `azuread/<object id>` en
+`azuread/<display name>`, en de profielpagina en de extravar `ansibleforms_user` tonen ze zo. Een **Groepfilter** zoals `^AF-` houdt alleen de groepen over die je rollen gebruiken; zie [Rollen](../config/roles.html). Vanaf 7.1.0
+draagt het aanmeldtoken de groepen niet meer, dus de grootte ervan groeit er niet meer mee. Het filter blijft belangrijk voor
+gebruikers in veel groepen: er worden bij elke aanmelding minder groepen met de rollen vergeleken, en het
+[directoryrecord](../users-and-groups/directory.html) van de gebruiker toont alleen de groepen die meetellen. Vóór 7.1.0
+heeft een gebruiker in honderd groepen of meer het nodig om überhaupt formulieren te zien, zie
+[Lege formulieren en jobs na een single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Microsoft Graph-endpoint
+
+De server meldt gebruikers standaard aan bij `https://login.microsoftonline.com` en roept Microsoft Graph aan op `https://graph.microsoft.com`:
+
+| Variabele | Wat ze wijzigt |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | De aanmeldautoriteit, voor een nationale cloud zoals `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | Het Graph-endpoint waaruit de groepen worden gelezen, zoals `https://graph.microsoft.us` |
+
+Beide nemen een basis-URI zonder afsluitende slash, en zijn nieuw in 7.3.0. `AZURE_AUTHORITY_URI` en `AZURE_GRAPH_URI` worden nog gelezen
+als die niet zijn ingesteld, met een waarschuwing in het log, en worden in 8.0 verwijderd. De server moet Graph kunnen bereiken: een aanmelding mislukt als de groepen niet kunnen worden gelezen.
+
+---
+
+## Beperkingen
+
+Entra ID-gebruikers melden zich aan bij Microsoft, dus een paar dingen werken anders dan bij lokale en LDAP-accounts:
+
+- Ze hebben geen wachtwoord in AnsibleForms, dus ze kunnen het daar niet wijzigen; een [API-token](../profile/api-token.html) wordt gemaakt vanuit hun sessie.
+- Weergavenamen zijn niet uniek in Entra ID: twee groepen met dezelfde naam worden aan dezelfde rol gekoppeld. Noem de groep in de rol bij zijn
+  object-id, `entraid/<object id>`, om alleen die groep te matchen.
diff --git a/i18n/nl/_configure/authentication/index.md b/i18n/nl/_configure/authentication/index.md
new file mode 100644
index 0000000..2c0745a
--- /dev/null
+++ b/i18n/nl/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Authenticatie
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Authenticatie
+{: .no_toc }
+
+Kies hoe gebruikers zich aanmelden, en hoe hun account en groepen tot rollen leiden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Aanmeldmethoden
+
+AnsibleForms ondersteunt vier aanmeldmethoden, en er kunnen er meerdere tegelijk actief zijn:
+
+| Methode | Wanneer te gebruiken | Pagina |
+|---|---|---|
+| Lokale accounts | De ingebouwde admin, serviceaccounts, kleine teams, of als terugvaloptie wanneer de directory onbereikbaar is. | [Lokale accounts](local.html) |
+| LDAP | Gebruikers en groepen staan in Active Directory, OpenLDAP of een andere LDAP-directory. | [LDAP](ldap.html) |
+| Entra ID | Gebruikers melden zich aan met hun Microsoft 365 / Entra ID-account (single sign-on). | [Entra ID](entra-id.html) |
+| OIDC | Single sign-on via een andere OpenID Connect-provider, zoals Keycloak. | [OIDC](oidc.html) |
+
+Lokale accounts en LDAP worden ingesteld onder **Toegang > Gebruikers**, **Groepen** en **LDAP**; Entra ID en OIDC onder
+**Toegang > SSO**.
+
+---
+
+## Hoe een aanmelding de methode kiest
+
+De aanmeldpagina heeft een formulier voor gebruikersnaam en wachtwoord, plus één knop per ingeschakelde single sign-on-provider:
+
+- **Gebruikersnaam en wachtwoord** worden eerst gecontroleerd tegen de lokale gebruikers. Alleen als geen enkele lokale gebruiker die naam heeft, en LDAP
+  is ingeschakeld, wordt de directory geprobeerd. Een lokale gebruiker met een verkeerd wachtwoord wordt geweigerd zonder LDAP te raadplegen.
+- **De knoppen voor Entra ID en OpenID** verschijnen onder **Aanmelden** wanneer zo'n provider is ingeschakeld. Ze sturen de browser naar
+  de provider en weer terug; er bereikt geen wachtwoord AnsibleForms.
+
+Er is steeds maar één Entra ID-provider en één OIDC-provider tegelijk ingeschakeld: als je er een inschakelt, worden de andere van hetzelfde type uitgeschakeld.
+Een mislukte aanmelding met gebruikersnaam en wachtwoord toont altijd hetzelfde algemene bericht; de reden staat in het serverlog en het auditlogboek.
+
+---
+
+## Single sign-on omschakelen
+
+Vanaf 7.3.0 heeft elke provider onder **Toegang > SSO** twee eigen schakelaars, die zonder herstart gelden:
+
+| Schakelaar | Effect |
+|---|---|
+| **Ingeschakeld** | Toont de knop van de provider op de aanmeldpagina en accepteert zijn aanmelding. Inschakelen schakelt de andere providers van hetzelfde type uit. |
+| **Aanmeldpagina overslaan** | Gebruikers gaan rechtstreeks naar deze provider, zonder de aanmeldpagina, zolang de provider is ingeschakeld. Inschakelen voor één provider schakelt het uit voor de andere; bij een uitgeschakelde provider is hij grijs. |
+
+Het formulier voor gebruikersnaam en wachtwoord blijft bereikbaar op `/login?local`, voor de lokale admin of wanneer de provider faalt,
+en het wordt getoond na het afmelden en wanneer een single sign-on-aanmelding met een fout terugkomt.
+
+De variabelen `ENABLE_SSO` en `SSO_AUTO_LOGIN` zijn in 7.3.0 verwijderd. De eerste start van 7.3.0 leest ze eenmaal, en
+logt bij elke start een waarschuwing zolang ze nog zijn ingesteld, dus verwijder ze na de upgrade uit de omgeving:
+
+| Variabele vóór 7.3.0 | Wat de upgrade doet |
+|---|---|
+| `ENABLE_SSO=0` | Schakelt elke provider uit: de providers blijven geconfigureerd, zonder knop op de aanmeldpagina |
+| `SSO_AUTO_LOGIN=1` | Schakelt **Aanmeldpagina overslaan** in voor de ingeschakelde provider, als er precies één is ingeschakeld en `ENABLE_SSO` niet `0` is |
+
+---
+
+## Van gebruiker naar rollen
+
+Elke aanmelding levert een gebruiker op met een **type** (`local`, `ldap`, `azuread` of `oidc`), een gebruikersnaam en een lijst groepen.
+Elke groep krijgt het voorvoegsel van zijn type, dus een Entra ID-groep wordt opgeslagen en getoond als `azuread/...`:
+
+| Aanmeldmethode | Gebruikersnaam | Groepen |
+|---|---|---|
+| Lokaal | de lokale gebruikersnaam | `local/<group>`, één voor elke lokale groep van de gebruiker |
+| LDAP, directory `main` | de waarde van het Username Attribute | `ldap/<cn>`, de CN van elke groep die de directory teruggeeft |
+| LDAP, een andere directory | `<directory>/<username>` | `ldap/<directory>/<cn>`, zie [Meerdere directory's](ldap.html#several-directories) |
+| Entra ID | de claim `upn`, of `preferred_username` als het token geen `upn` heeft | `azuread/<object id>` en `azuread/<display name>` van elke groep, gelezen uit Microsoft Graph |
+| OIDC | de claim `preferred_username` | `oidc/<name>`, uit de claim `groups` van het ID-token |
+
+De [rollen](../config/roles.html) in config.yaml matchen vervolgens met deze waarden: een rol is van toepassing wanneer een van zijn `groups` een
+van de groepen van de gebruiker is, of wanneer zijn `users` `<type>/<username>` bevat. Elke gebruiker krijgt ook de rol `default`. Vanaf 7.3.0
+noemt een rol een Entra ID-lid `entraid/<group>` of `entraid/<upn>`, wat overeenkomt met de opgeslagen waarde `azuread/`; `azuread/`
+in een rol werkt nog steeds en wordt in 8.0 verwijderd. Het profiel en de extravars van de job blijven `azuread/` tonen.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+De **profiel**pagina van een gebruiker toont het aanmeldtype, de groepen en de rollen; dat is de snelste manier om een koppeling te controleren.
+De rolinstelling `allowLogin` kan de aanmelding weigeren van gebruikers die met geen enkele rol overeenkomen: zet haar op `false` bij `default` en op
+`true` bij de rollen die zich mogen aanmelden.
diff --git a/i18n/nl/_configure/authentication/ldap.md b/i18n/nl/_configure/authentication/ldap.md
new file mode 100644
index 0000000..a9bc619
--- /dev/null
+++ b/i18n/nl/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Authenticatie
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Laat directorygebruikers zich aanmelden met hun eigen wachtwoord, en geef ze rollen via hun directorygroepen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Hoe het werkt
+
+AnsibleForms maakt verbinding met de directory via een bindaccount, zoekt de gebruiker op en bindt daarna als die gebruiker om
+het wachtwoord te controleren:
+
+1. De gebruiker meldt zich aan met gebruikersnaam en wachtwoord. Als geen enkele **lokale** gebruiker die naam heeft, wordt LDAP geprobeerd.
+2. AnsibleForms bindt met het bindaccount van de referentie van de directory, en doorzoekt de **Zoekbasis** naar een item waarvan het
+   **Gebruikersnaam attribuut** gelijk is aan de gebruikersnaam.
+3. Het bindt als het gevonden item, met het getypte wachtwoord.
+4. De groepen worden uit het item gelezen (of uit een groepszoekopdracht), gefilterd, en krijgen het voorvoegsel `ldap/`.
+
+Een gebruikersnaam in UPN-vorm (`jdoe@example.com`) die geen gebruiker vindt, wordt één keer opnieuw geprobeerd met het deel vóór de `@`, zodat gebruikers
+zich met beide vormen kunnen aanmelden, ook als het Gebruikersnaam attribuut de korte naam bevat. Een verkeerd wachtwoord wordt nooit opnieuw geprobeerd.
+
+Eén set instellingen dient voor Active Directory, OpenLDAP en andere; vanaf 7.3.0 kunnen er [meerdere directory's](#several-directories) zijn.
+
+---
+
+## Instellingen
+
+Vanaf 7.3.0 gelden de instellingen per directory. **Toegang > LDAP** toont de directory's, in de volgorde waarin een kale gebruikersnaam wordt opgezocht:
+
+![Toegang > LDAP](../assets/screenshots/ldap.jpg)
+
+| Rijmenu | Wat het doet |
+|---|---|
+| Bewerken | Opent de pagina van de directory |
+| Verbinding testen | Probeert een aanmelding met een testgebruikersnaam en -wachtwoord, zie [De verbinding testen](#testing-the-connection) |
+| Inschakelen, Uitschakelen | Schakelt de directory in of uit; `main` wordt uitgeschakeld in plaats van verwijderd |
+| Omhoog, Omlaag | Wijzigt de plaats in de opzoekvolgorde |
+| Verwijderen | Verwijdert de directory; bij `main` getoond maar uitgeschakeld |
+
+Het toevoegen van een directory vraagt de velden in vier stappen, de tabbladen van de pagina. **Details** bevat **Ingeschakeld**, de **Naam** en een **Beschrijving**:
+
+| Tabblad | Instelling | Betekenis |
+|---|---|---|
+| Referenties | Referentie | Verplicht. Een `ldap`-referentie uit [Verbindingen > Inloggegevens](../credentials.html), die de verbinding bevat, zie hieronder |
+| Gebruikers | Zoekbasis | DN waar het zoeken naar gebruikers begint, bijv. `OU=Users,DC=example,DC=com`. Subbomen worden ook doorzocht |
+| Gebruikers | Gebruikersnaam attribuut | Attribuut dat met de aanmeldnaam wordt vergeleken: `sAMAccountName` in AD (de standaard), `uid` in OpenLDAP |
+| Gebruikers | Mail attribuut | Attribuut met het e-mailadres, meestal `mail` |
+| Gebruikers | Aanmelddomeinen | Domeinen waarvan aanmeldingen als `user@domain` rechtstreeks naar deze directory gaan, zie [Meerdere directory's](#several-directories) |
+| Groepen | Groepen attribuut | Attribuut van het gebruikersitem dat de groepen bevat (`memberOf`, de standaard), of `groups` met een groepszoekopdracht |
+| Groepen | Groepen zoekbasis | DN waar het zoeken naar groepen begint |
+| Groepen | Groep klasse | objectClass van de groepen, bijv. `group`, `groupOfNames` of `posixGroup` |
+| Groepen | Groepslid attribuut | Attribuut van een groep dat de leden opsomt, bijv. `member`, `uniqueMember` of `memberUid`; standaard `member` |
+| Groepen | Groepslid gebruiker attribuut | Attribuut van de gebruiker dat in die lidwaarden staat, bijv. `dn` of `uid`; standaard `dn` |
+| Groepen | Groepfilter | Reguliere expressie; alleen de groepen waarvan de naam overeenkomt blijven over. Leeg houdt elke groep |
+
+De standaardwaarden van de laatste drie groepsvelden gelden alleen als de groepszoekopdracht wordt gebruikt, zie de volgende sectie.
+
+De `ldap`-referentie bepaalt hoe de directory wordt bereikt en als wie er wordt gezocht:
+
+| Veld | Betekenis |
+|---|---|
+| Servers | Eén per veld, als `host`, `host:port` of `ldaps://host:port`, in deze volgorde geprobeerd: als er een onbereikbaar is, wordt de volgende geprobeerd |
+| Poort | `389` voor gewone LDAP, `636` voor LDAPS |
+| TLS inschakelen | Verbinden met LDAPS (`ldaps://`). StartTLS op poort 389 wordt niet ondersteund |
+| Certificaten negeren | De validatie van het servercertificaat overslaan. Alleen getoond met **TLS inschakelen** |
+| Certificaat | Het clientcertificaat dat AnsibleForms aan de servers presenteert, in PEM, wanneer de certificaten worden gecontroleerd |
+| CA-bundel | Het CA-certificaat of de CA-certificaten die het servercertificaat hebben ondertekend, in PEM, wanneer de certificaten worden gecontroleerd |
+| Bind gebruiker DN | De DN van het serviceaccount dat de directory doorzoekt |
+| Bind gebruiker wachtwoord | Het wachtwoord ervan, versleuteld opgeslagen of gelezen uit een [secret store](../secret-stores/) |
+
+Alleen een admin kan een `ldap`-referentie toevoegen of wijzigen, zie [Wie een referentie mag wijzigen](../credentials.html#who-may-change-a-credential).
+Tot en met 7.2.0 waren de servers, TLS en het bindaccount velden van de LDAP-instellingen. De upgrade naar 7.3.0 verplaatst ze naar een referentie,
+zie [Adressen in referenties](../credentials/types.html#addresses-in-credentials):
+
+| De directory vóór de upgrade | Waar de servers naartoe gaan |
+|---|---|
+| Een eigen bind-DN en wachtwoord, geen referentie | Een nieuwe `ldap`-referentie met de naam `<directory>-ldap`, zoals `main-ldap` |
+| Een referentie zonder servers | Naar die referentie |
+| Een referentie die al andere servers bevat | Een kopie van de referentie met de naam `<credential>-<directory>`, die de directory dan noemt |
+
+Een naam die al bezet is, krijgt `-2`, `-3` enzovoort. Een directory uit de configuratie-seed blijft zoals hij is: de seed is er eigenaar van.
+
+---
+
+## Groepen
+
+De groepen komen van een van twee plaatsen, en het **Groepen attribuut** bepaalt welke wordt gebruikt:
+
+- **Een attribuut van het gebruikersitem**, meestal `memberOf`. Dit is de gebruikelijke opzet voor Active Directory, en voor
+  OpenLDAP met de overlay `memberof`.
+- **Een groepszoekopdracht**, voor directory's zonder `memberOf`. Die draait alleen als **Groepen zoekbasis** en **Groep klasse**
+  allebei zijn ingesteld: AnsibleForms zoekt dan naar groepen van die klasse waarvan het **Groepslid attribuut** het
+  **Groepslid gebruiker attribuut** van de gebruiker bevat, en slaat het resultaat op in het attribuut `groups`. Zet **Groepen attribuut** op `groups`
+  om het te gebruiken.
+
+{: .note }
+> Met **Groepen attribuut** `memberOf` draait een geconfigureerde groepszoekopdracht wel, maar wordt het resultaat niet voor de rollen gebruikt.
+
+Elke groep is een DN, en AnsibleForms houdt de eerste CN: `CN=AF-Admins,OU=Groups,DC=example,DC=com` wordt `AF-Admins`.
+Het **Groepfilter** wordt dan op die naam toegepast, en de overgebleven groepen krijgen het voorvoegsel `ldap/`: `ldap/AF-Admins`.
+
+In grote directory's houdt het filter tokens en jobs klein; een ongeldige reguliere expressie houdt alle groepen en wordt gelogd.
+
+---
+
+## Koppelen aan rollen
+
+In config.yaml is een LDAP-groep `ldap/<group CN>` en een LDAP-gebruiker `ldap/<username>`, beide hoofdlettergevoelig:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+De gebruikersnaam is de waarde van het **Gebruikersnaam attribuut** zoals de directory die teruggeeft, niet zoals de gebruiker hem typte.
+Zie [Rollen](../config/roles.html) voor de rolinstellingen.
+
+---
+
+## Meerdere directory's
+
+Vanaf 7.3.0 kunnen er meerdere directory's zijn, elk met eigen servers, gebruikers en groepen. Hun namen houden hun leden uit elkaar:
+
+| Directory | Gebruikersnaam | Groepen | In een rol |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Elke andere, zoals `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Een gebruiker noemt de directory bij het aanmelden als `corp\jdoe` of `corp/jdoe`, of meldt zich aan met een adres van een domein dat de directory
+bezit. Een kale gebruikersnaam wordt in elke ingeschakelde directory geprobeerd, in hun volgorde, en dat geldt ook voor een naam zoals `other\jdoe` als er geen
+directory `other` heet: die wordt dan opgezocht zoals getypt.
+
+De eerste directory die de gebruiker kent, beslist: een verkeerd wachtwoord daar is het antwoord, en de volgende directory wordt niet
+geprobeerd, omdat die iemand anders met dezelfde naam kan bevatten. Een directory die onbereikbaar is, wordt overgeslagen.
+
+De directory die tot en met 7.2.0 `default` heette, heet vanaf 7.3.0 `main`: de upgrade hernoemt hem, en een nieuwe installatie begint
+met `main`. De leden behouden hun korte namen, dus de rollen die ze noemen hoeven niet te worden gewijzigd. De directory `main` kan niet
+worden hernoemd, en een directorynaam bevat alleen letters, cijfers, `-` en `_`.
+
+---
+
+## De verbinding testen
+
+**Verbinding testen** vraagt om een testgebruikersnaam en -wachtwoord, en probeert een aanmelding met de instellingen op het scherm, opgeslagen of niet.
+Bij succes toont het het directory-item van de gebruiker, dat je de exacte attribuutnamen en groeps-DN's laat zien die je moet gebruiken.
+
+Een testgebruiker die niet bestaat, meldt toch succes: de verbinding en het bindaccount werken, alleen de gebruiker wordt niet
+gevonden. Typische fouten:
+
+| Bericht | Oorzaak |
+|---|---|
+| `Bad server or port (connection failed)` | De hostnaam wordt niet opgelost of de poort is niet bereikbaar. |
+| `Wrong binding credentials` | De bind-DN of het wachtwoord van de referentie van de directory is onjuist. |
+| `Unable to verify the certificate` | Het servercertificaat is niet ondertekend door de CA-bundel van de referentie. |
+| `Certificate is not valid` | Het Certificaat of de CA-bundel van de referentie bevat geen geldig PEM-certificaat. |
+
+---
+
+## Voorbeeld voor Active Directory
+
+Dit voorbeeld maakt via LDAPS verbinding met twee domeincontrollers en houdt alleen de groepen waarvan de naam met `AF-` begint:
+
+| Instelling | Waarde |
+|---|---|
+| Referentie > Servers | `dc01.example.com`, daarna `dc02.example.com` |
+| Referentie > Poort | `636` |
+| Referentie > TLS inschakelen | aan |
+| Referentie > Certificaten negeren | uit, met een clientcertificaat en de CA-keten van de enterprise-CA |
+| Referentie > Bind gebruiker DN | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Zoekbasis | `OU=Users,DC=example,DC=com` |
+| Mail attribuut | `mail` |
+| Gebruikersnaam attribuut | `sAMAccountName` |
+| Groepen attribuut | `memberOf` |
+| Groepfilter | `^AF-` |
+
+Leden van `CN=AF-Operators,…` matchen rollen met `ldap/AF-Operators`, en melden zich aan als `jdoe` of `jdoe@example.com`.
+
+---
+
+## Voorbeeld voor OpenLDAP
+
+Dit voorbeeld gebruikt een groepszoekopdracht op items van het type `groupOfNames`, zodat het zonder de overlay `memberof` werkt:
+
+| Instelling | Waarde |
+|---|---|
+| Referentie > Servers | `ldap.example.com` |
+| Referentie > Poort | `636` |
+| Referentie > TLS inschakelen | aan |
+| Referentie > Bind gebruiker DN | `cn=readonly,dc=example,dc=com` |
+| Zoekbasis | `ou=people,dc=example,dc=com` |
+| Mail attribuut | `mail` |
+| Gebruikersnaam attribuut | `uid` |
+| Groepen attribuut | `groups` |
+| Groepen zoekbasis | `ou=groups,dc=example,dc=com` |
+| Groep klasse | `groupOfNames` |
+| Groepslid attribuut | `member` |
+| Groepslid gebruiker attribuut | `dn` |
+
+Een gebruiker die in `cn=af-admins,ou=groups,dc=example,dc=com` staat, krijgt de groep `ldap/af-admins`. Gebruik voor groepen van het type `posixGroup`
+**Groepslid attribuut** `memberUid` en **Groepslid gebruiker attribuut** `uid`.
+
+Laat met de overlay `memberof` de velden van de groepszoekopdracht leeg en zet **Groepen attribuut** op `memberOf`.
+
+---
+
+## Veelvoorkomende valkuilen
+
+De meeste LDAP-problemen komen neer op een van deze:
+
+- **Een lokale gebruiker met dezelfde naam.** Lokale gebruikers worden eerst gecontroleerd, dus de directory wordt nooit naar die naam gevraagd.
+- **Geen groepen, of de verkeerde.** Het Groepen attribuut moet bestaan (`groups` met een groepszoekopdracht); `memberOf` slaat nesting over.
+- **Groepsnamen die niet overeenkomen.** Gebruik `ldap/<CN>` met dezelfde hoofdletters, en controleer of het Groepfilter de groep behoudt.
+- **Groeps-DN's die niet met een CN beginnen.** Alleen de eerste waarde `CN=` wordt als groepsnaam gebruikt, dus elke groeps-DN
+  moet met `CN=` (of `cn=`) beginnen.
+- **Certificaten.** TLS heeft beide certificaatvelden van de referentie nodig en een overeenkomende servernaam; Certificaten negeren is alleen om te testen.
+- **Instellingen die niet kunnen worden opgeslagen.** Als een directory uit de [configuratie-seed](../seed/managed-objects.html) komt, is de pagina ervan
+  alleen-lezen: wijzig dan het seedbestand.
+
+Een mislukte aanmelding toont een algemeen bericht. De reden wordt door de server gelogd en in het auditlogboek bewaard, en voor Active
+Directory wordt ze vertaald vanuit de code van de directory, bijv. `Wrong password`, `Account locked` of `Password expired`.
diff --git a/i18n/nl/_configure/authentication/local.md b/i18n/nl/_configure/authentication/local.md
new file mode 100644
index 0000000..77338b8
--- /dev/null
+++ b/i18n/nl/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Lokale accounts
+parent: Authenticatie
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Lokale accounts
+{: .no_toc }
+
+De ingebouwde admin, en de gebruikers en groepen die in de AnsibleForms-database staan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De ingebouwde admin
+
+Bij elke start worden de lokale groep `admins` en de admin-gebruiker aangemaakt als ze ontbreken; drie variabelen sturen de admin:
+
+| Variabele | Standaard | Betekenis |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Gebruikersnaam van de admin, aangemaakt in de groep `admins` als geen enkele gebruiker die naam heeft. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Wachtwoord dat de admin krijgt wanneer hij wordt aangemaakt (of gereset). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` zet het wachtwoord van de admin terug op `ADMIN_PASSWORD` en plaatst hem weer in `admins`. |
+
+`ADMIN_PASSWORD` wordt alleen gebruikt wanneer de gebruiker wordt aangemaakt of gereset: het later wijzigen doet op zichzelf niets.
+
+Een lokale gebruiker die zich aanmeldt met het openbare standaardwachtwoord `AnsibleForms!123` kan het alleen wijzigen. De browser opent een
+pagina om het wachtwoord te wijzigen die niet kan worden gesloten, en de server beantwoordt elk ander verzoek met `403` (code
+`password_change_required`) totdat het wachtwoord is gewijzigd. Het nieuwe wachtwoord moet verschillen van het standaardwachtwoord; na de
+wijziging meldt de gebruiker zich er opnieuw mee aan. Stel `ADMIN_PASSWORD` vóór de eerste start in op je eigen waarde om deze stap over te slaan.
+
+Als je `ADMIN_USERNAME` na de eerste start wijzigt, wordt een tweede admin-gebruiker met die naam aangemaakt; de oude blijft bestaan.
+
+{: .warning }
+> `REINIT_ADMIN=1` reset het wachtwoord bij **elke** start zolang het is ingesteld. Gebruik het om een verloren adminwachtwoord te herstellen,
+> verwijder het daarna en herstart.
+
+---
+
+## Gebruikers en groepen
+
+Lokale gebruikers en groepen worden beheerd onder **Toegang > Gebruikers** en **Toegang > Groepen**. Een gebruiker heeft deze velden:
+
+| Veld | Betekenis |
+|---|---|
+| Gebruikersnaam | De aanmeldnaam. Moet uniek zijn. |
+| Beschrijving | Optioneel. |
+| Wachtwoord | Opgeslagen als hash. Wijzig het later met de actie **Wachtwoord wijzigen**. |
+| E-mail | Optioneel. |
+| Groep | De eerste lokale groep van de gebruiker. Voeg er meer toe op het tabblad **Groepen** van de pagina van de gebruiker. |
+
+Lokale gebruikers wijzigen hun eigen wachtwoord in hun profiel; andere gebruikers doen dat in hun directory of identity provider.
+
+Een gebruiker kan tot meerdere groepen behoren, en krijgt de rollen van al die groepen. Het tabblad **Groepen** van de pagina van een gebruiker voegt
+groepen toe en verwijdert ze, en dat doet ook het tabblad **Gebruikers** van de pagina van een groep. Een gebruiker houdt minstens één groep: de laatste kan niet
+worden verwijderd.
+
+Een groep die nog gebruikers heeft, kan niet worden verwijderd: verwijder eerst de gebruikers. De groep `admins` kan nooit worden verwijderd of
+hernoemd, en de gebruiker `admin` kan nooit worden verwijderd.
+
+---
+
+## Aanmelden toestaan
+
+Het tabblad **Details** van de pagina van een gebruiker heeft een schakelaar **Aanmelden toestaan**, ook beschikbaar als **Aanmelden blokkeren** en **Aanmelden
+toestaan** in het rijmenu van de gebruikerslijst. Hij bestaat voor lokale gebruikers en evengoed voor LDAP- en SSO-gebruikers:
+
+- **Aan**: de gebruiker meldt zich zoals gewoonlijk aan.
+- **Uit**: de sessies van de gebruiker eindigen meteen en elke aanmelding wordt geweigerd, totdat een admin hem weer inschakelt. De pagina
+  vraagt eerst om bevestiging.
+
+De schakelaar kan niet worden uitgezet voor de gebruiker `admin`, de weg terug naar binnen, en ook niet door een admin voor zijn eigen account. De pagina van
+een LDAP- of SSO-gebruiker heeft ook **Sessies beëindigen**, waarmee de gebruiker overal wordt afgemeld zonder hem te blokkeren.
+
+---
+
+## Koppelen aan rollen
+
+Rollen noemen lokale groepen `local/<group>` en gebruikers `local/<user>`; standaard krijgt `admins` de rol `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Houd `local/admins` in de rol `admin`, zodat de ingebouwde admin zich altijd kan aanmelden, ook als de directory of de
+identity provider niet beschikbaar is. Als config.yaml helemaal niet kan worden geladen, krijgen leden van `local/admins` nog steeds de
+rol `admin`, zodat je je kunt aanmelden en het kunt herstellen. Zie [Rollen](../config/roles.html) voor de rolinstellingen.
+
+---
+
+## Lokale accounts en LDAP
+
+Een aanmelding met gebruikersnaam en wachtwoord controleert de lokale gebruikers vóór LDAP. Als een lokale gebruiker dezelfde naam heeft als een directorygebruiker,
+wint het lokale account altijd en werkt het directorywachtwoord niet voor die naam. Geef lokale accounts namen
+die niet kunnen botsen met directoryaccounts, bijvoorbeeld met het voorvoegsel `svc-`.
diff --git a/i18n/nl/_configure/authentication/oidc.md b/i18n/nl/_configure/authentication/oidc.md
new file mode 100644
index 0000000..f1ac949
--- /dev/null
+++ b/i18n/nl/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Authenticatie
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Single sign-on met een OpenID Connect-provider zoals Keycloak, met rollen uit een groepsclaim
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Hoe het werkt
+
+Met een ingeschakelde OIDC-provider toont de aanmeldpagina een OpenID-knop onder **Aanmelden**. Een aanmelding verloopt dan als volgt:
+
+1. De knop stuurt de browser naar `/api/v2/auth/oidc`, dat hem doorstuurt naar de provider (authorization code flow
+   met PKCE).
+2. De gebruiker meldt zich aan bij de provider, die terugstuurt naar de **Omleidings-URI**.
+3. De server wisselt de code in voor tokens en leest de claims van het ID-token.
+4. De gebruikersnaam is de claim `preferred_username`, en elke waarde van de claim `groups` die door het
+   **Groepfilter** komt, wordt een groep `oidc/<value>`.
+
+AnsibleForms vraagt de scopes `openid profile email` aan; de scopes zijn niet configureerbaar. Afmelden bij AnsibleForms
+stuurt de browser ook naar het end-session-endpoint van de provider, als de provider er een publiceert.
+
+{: .note }
+> OIDC is getest met Keycloak. Andere providers werken als ze aan de onderstaande vereisten voldoen.
+
+---
+
+## Vereisten voor de provider
+
+De provider moet OpenID Connect discovery bieden, en een vertrouwelijke client voor AnsibleForms:
+
+- **Discovery**: AnsibleForms leest `<issuer>/.well-known/openid-configuration`, dus de issuer moet bereikbaar zijn vanaf
+  de AnsibleForms-server, via HTTPS.
+- **Een vertrouwelijke client** met de authorization code flow, een client ID en een client secret.
+- **De omleidings-URI** `https://af.example.com/api/v2/auth/oidc/callback`, dat wil zeggen het adres waarop gebruikers
+  AnsibleForms bereiken, gevolgd door `/api/v2/auth/oidc/callback`. Met [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms` wordt dat `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Een claim `groups` in het ID-token**, met een lijst groepsnamen. Zonder die claim krijgt de gebruiker geen OIDC-groepen.
+- **Een claim `preferred_username`**, die de gebruikersnaam wordt.
+
+---
+
+## Voorbeeld voor Keycloak
+
+Dit voorbeeld gebruikt een realm `example` op `https://keycloak.example.com`; de issuer is dan
+`https://keycloak.example.com/realms/example`. In die realm:
+
+1. Maak onder **Clients** een OpenID Connect-client aan met client ID `ansibleforms`. Zet **Client authentication** aan,
+   laat **Standard flow** aan, en stel **Valid redirect URIs** in op `https://af.example.com/api/v2/auth/oidc/callback`.
+2. Kopieer op het tabblad **Credentials** van de client het **Client secret**.
+3. Open op het tabblad **Client scopes** `ansibleforms-dedicated` en voeg een mapper **By configuration > Group Membership** toe,
+   met **Token Claim Name** `groups`, **Full group path** uit en **Add to ID token** aan.
+
+Met **Full group path** aan bevat de claim paden zoals `/af-admins`, en moet de rol dan `oidc//af-admins` gebruiken.
+
+---
+
+## De provider toevoegen
+
+Voeg de provider toe onder **Toegang > SSO**: een wizard vraagt de velden in vier stappen, met **Open ID** in de stap **Type**:
+
+| Stap | Veld | Betekenis |
+|---|---|---|
+| Details | Naam, Beschrijving | Een unieke naam voor de provider, en een optionele beschrijving |
+| Type | Provider | **Open ID**; ingesteld bij het aanmaken, blijft zo |
+| Referenties | Referentie | Een referentie van het type **Open ID** uit [Verbindingen > Inloggegevens](../credentials.html), zie hieronder |
+| Groepen | Groepfilter | Reguliere expressie; alleen de waarden van de claim `groups` die overeenkomen blijven over. Leeg houdt elke groep |
+
+De referentie bevat de client, dus alleen een admin kan haar toevoegen of wijzigen:
+
+| Veld | Betekenis |
+|---|---|
+| Issuer | Verplicht. De issuer-URL, bijv. `https://keycloak.example.com/realms/example` |
+| Client ID | De client ID bij de provider, bijv. `ansibleforms` |
+| Client secret | Het client secret, versleuteld opgeslagen of gelezen uit een [secret store](../secret-stores/) |
+| Omleidings-URI | Zoals geregistreerd, bijv. `https://af.example.com/api/v2/auth/oidc/callback`. Leeg: de URL van de app en het callbackpad |
+
+Tot en met 7.2.0 waren de issuer, de client ID, het secret en de redirect URL velden van de provider. De upgrade naar 7.3.0 verplaatst ze naar een
+referentie met de naam `<provider>-sso`, zie [Adressen in referenties](../credentials/types.html#addresses-in-credentials).
+Kies voor elke nieuwe provider een referentie: de server accepteert nog steeds een provider met een eigen client ID en secret van
+vóór 7.3.0, die zich daarmee aanmeldt totdat er een referentie is gekozen.
+
+Er is steeds één OIDC-provider ingeschakeld, degene waarmee de OpenID-knop aanmeldt. **Inschakelen** in het rijmenu van een andere,
+of zijn schakelaar **Ingeschakeld**, schakelt de andere van hetzelfde type uit; de kolom **Ingeschakeld** van de lijst toont welke in gebruik is.
+Een provider kan ook de aanmeldpagina overslaan, zie [Single sign-on omschakelen](./#switching-single-sign-on).
+
+Het opslaan van de provider past hem meteen toe. Als de issuer niet bereikbaar is, logt de server
+`Failed to initialize OIDC strategy` en mislukken OIDC-aanmeldingen totdat de provider opnieuw wordt opgeslagen of de server herstart.
+
+---
+
+## Koppelen aan rollen
+
+In config.yaml is een OIDC-groep `oidc/<group>` en een gebruiker `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+De waarden worden exact vergeleken, hoofdletters inbegrepen. Zie [Rollen](../config/roles.html) voor de rolinstellingen.
+
+---
+
+## Beperkingen
+
+OIDC-gebruikers melden zich aan bij de provider, dus een paar dingen werken anders dan bij lokale en LDAP-accounts:
+
+- Ze hebben geen wachtwoord in AnsibleForms, dus ze kunnen het daar niet wijzigen; vanaf 7.2.0 wordt een [API-token](../profile/api-token.html)
+  gemaakt vanuit hun sessie.
+- Houd de claim `groups` kort: stuur alleen de groepen die voor AnsibleForms van belang zijn, bijvoorbeeld met een eigen
+  client scope of groepsstructuur bij de provider, of filter ze met het **Groepfilter**. Vanaf 7.1.0 draagt het aanmeldtoken
+  van AnsibleForms de groepen niet meer; daarvoor kon een gebruiker in honderd groepen of meer geen formulieren zien, zie
+  [Lege formulieren en jobs na een single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/nl/_configure/config/categories.md b/i18n/nl/_configure/config/categories.md
new file mode 100644
index 0000000..753d478
--- /dev/null
+++ b/i18n/nl/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Categorieën
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Categorieën
+{: .no_toc }
+
+De formulieren op het dashboard groeperen.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het attribuut categories
+
+De lijst `categories` op het hoogste niveau van config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Het object Category
+
+Elk item van de lijst `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/nl/_configure/config/constants.md b/i18n/nl/_configure/config/constants.md
new file mode 100644
index 0000000..7a665ad
--- /dev/null
+++ b/i18n/nl/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Constanten
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Constanten
+{: .no_toc }
+
+Vrije objecten die elk formulier kan hergebruiken.
+{: .fs-6 .fw-300 }
+
+---
+
+## Het attribuut constants
+
+Het object `constants` op het hoogste niveau van config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/nl/_configure/config/index.md b/i18n/nl/_configure/config/index.md
new file mode 100644
index 0000000..fd09a6b
--- /dev/null
+++ b/i18n/nl/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Categorieën, rollen en constanten voor alle formulieren
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders: het bestand config.yaml met de categorieën, rollen en constanten die alle formulieren delen.
+
+AnsibleForms gebruikt een bestand config.yaml om categorieën, rollen en constanten te configureren. Als er geen bestand is, wordt er een gegenereerd met een minimale configuratie. De configuratie kan ook in de database worden geïmporteerd, zodat er geen bestand config.yaml meer nodig is.
+
+---
+
+## Overzicht
+
+Het bestand config.yaml bevat de configuratie van de categorieën, rollen en constanten die AnsibleForms gebruikt.
+
+**VIDEO**: [Je eerste formulier maken](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+De volgende minimale config.yaml dient als startpunt. Hij bevat alleen de verplichte categorie `Default` en de verplichte rollen `admin` en `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Prioriteit bij het laden van de configuratie
+
+AnsibleForms laadt het bestand config.yaml in de volgende volgorde (de eerste treffer wint):
+
+1. **UIT DE DATABASE** : de configuratie die in de database is geïmporteerd, alleen als `ENABLE_CONFIG_IN_DATABASE=1`, of als die
+   variabele niet is ingesteld en de configuratiebron die in de database is opgeslagen `database` is (een lege kopie valt terug op het bestand)
+2. **UIT EEN REPOSITORY (use_for_config)** : de repository met de schakelaar "gebruiken voor configuratie" ingeschakeld (nieuw in 6.1.0)
+3. **UIT EEN REPOSITORY (use_for_forms)** : de repository met de schakelaar "gebruiken voor formulieren" ingeschakeld (terugvaloptie voor achterwaartse compatibiliteit)
+4. **UIT EEN LOKAAL BESTAND** : het lokale bestand `config.yaml` (omgevingsvariabele CONFIG_PATH)
+
+{: .warning }
+> **Let op:** schakel "gebruiken voor configuratie" op slechts één repository in. Als meerdere het ingeschakeld hebben, wordt een waarschuwing gelogd en wordt de eerste gebruikt.
+
+---
+
+## In deze sectie
+
+Het bestand heeft drie attributen op het hoogste niveau, en elk heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Categorieën](categories.html) | De formulieren op het dashboard groeperen in een boom van categorieën met pictogrammen |
+| [Rollen](roles.html) | Gebruikers en groepen aan rollen koppelen, en instellen wat elke rol mag doen |
+| [Constanten](constants.html) | Vrije objecten die elk formulier kan hergebruiken |
diff --git a/i18n/nl/_configure/config/roles.md b/i18n/nl/_configure/config/roles.md
new file mode 100644
index 0000000..d896247
--- /dev/null
+++ b/i18n/nl/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Rollen
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Rollen
+{: .no_toc }
+
+Gebruikers en groepen aan rollen koppelen, en instellen wat elke rol mag doen.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het attribuut roles
+
+De lijst `roles` op het hoogste niveau van config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## De rol default
+
+Elke aangemelde gebruiker heeft de rol `default`, dus een formulier met `roles: [default]` staat open voor iedereen die zich kan aanmelden. Er
+is geen anonieme toegang: niemand krijgt deze rol zonder zich aan te melden.
+
+De rol bevat geen groepen en geen gebruikers, omdat hij al voor iedereen geldt. Zijn `options` zijn de standaardwaarden voor iedereen, zoals
+beschreven onder [Rolinstellingen](#role-options) hieronder. `config.yaml` moet een rol `admin` en een rol `default` hebben, en de
+rollenpagina toont beide als **Vereist**.
+
+`default` heette vóór 7.0.0 `public`, en de oude naam blijft werken:
+
+- **In een formulier** matcht `roles: [public]` nog steeds elke gebruiker, dus formulieren in je repositories hoeven niet te worden gewijzigd.
+- **In `config.yaml`** wordt een rol met de naam `public` in het bestand hernoemd naar `default` wanneer de configuratie laadt. Alleen de naam
+  verandert, er wordt eerst een back-up van de configuratie gemaakt, en een configuratie die in een repository staat heeft dan een wijziging om te pushen.
+- **In een ytt-template** wordt de template niet herschreven: de configuratie die hij produceert wordt hernoemd, en een waarschuwing in het log vraagt
+  je de rol ook in de template te hernoemen. Versie 8 weigert daar een rol `public`.
+
+Een configuratie met zowel een rol `default` als een rol `public` wordt geweigerd, omdat het dezelfde rol is.
+
+---
+
+## Het object Role
+
+Elk item van de lijst `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Rolinstellingen
+
+De `options` van een rol schakelen functies in of uit voor de leden ervan. Vanaf 7.3.0 toont de pagina van de rol ze in vier groepen,
+elke instelling met een (i) die zegt wat ze geeft, dezelfde tekst die de weergave **Rechten** van het profiel toont:
+
+| Instelling | Laat de gebruiker toe om | Standaard |
+|---|---|---|
+| **Instellingen** | | |
+| `showSettings` | Elke instellingenpagina te zien en te wijzigen; het serverlog en de back-ups hebben eigen instellingen | Alleen admins |
+| `showAppearanceSettings` | De instellingen voor het uiterlijk te wijzigen, zonder de andere instellingen (vanaf 7.3.0) | Uit |
+| `showConnectionsSettings` | De verbindingsinstellingen te beheren (referenties, runners en meer), zonder de andere instellingen (vanaf 7.3.0) | Uit |
+| `showLogs` | Het serverlog te zien | Alleen admins |
+| `showAuditLog` | Het auditlogboek te zien, zonder de andere instellingen (vanaf 7.3.0) | Alleen admins |
+| `allowBackupOps` | Back-ups van de database te maken en terug te zetten | Alleen admins |
+| **Designer** | | |
+| `showDesigner` | De designer te zien en te gebruiken | Alleen admins |
+| `allowFormDesign` | De formulierconfiguratie in de designer te bewerken: categorieën, constanten en formulieren. Zonder deze instelling alleen-lezen (vanaf 7.3.0) | Aan |
+| `allowPlaybookDesign` | De playbooks in de designer te bewerken: opslaan, aanmaken, verwijderen en pushen. Zonder deze instelling alleen-lezen | Aan |
+| `allowWorkflowDesign` | De workflows in de designer te bewerken: opslaan, aanmaken, verwijderen en pushen. Zonder deze instelling alleen-lezen | Aan |
+| `allowInventoryDesign` | De inventories in de designer te bewerken: opslaan, aanmaken, verwijderen en pushen. Zonder deze instelling alleen-lezen | Aan |
+| `allowVarsFileDesign` | De vars-bestanden in de designer te bewerken: opslaan, aanmaken, verwijderen en pushen. Zonder deze instelling alleen-lezen | Aan |
+| **Jobs** | | |
+| `showJobs` | De jobpagina te zien | Aan |
+| `showAllJobLogs` | De jobs van elke gebruiker te zien, niet alleen de eigen | Alleen admins |
+| `manageAllJobs` | De jobs van elke gebruiker af te breken, te verwijderen en opnieuw te starten; verwijderen en opnieuw starten vereisen ook de twee instellingen hieronder (vanaf 7.3.0) | Alleen admins |
+| `showExtravars` | De extravars van een formulier en van een job te zien | Aan |
+| `showDebugButtons` | De debugknoppen op een formulier te zien | Aan |
+| `showArtifacts` | De artifacts van een job te zien: wat een AWX-job teruggeeft, of wat een playbook met `set_stats` heeft verzameld | Aan |
+| `allowVerboseMode` | Jobs in verbose-modus uit te voeren | Aan |
+| `allowJobRelaunch` | Een job opnieuw te starten met de formuliergegevens van een eerdere uitvoering | Alleen admins |
+| `allowJobDeletion` | Jobs te verwijderen: de eigen, of die van elke gebruiker met `manageAllJobs`. Zonder deze instelling blijft de jobgeschiedenis volledig (vanaf 7.3.0) | Aan |
+| `allowScheduledJobs` | Terugkerende en eenmalige planningen aan te maken en te beheren, op de pagina **Planner** (zie de waarschuwing hieronder) | Alleen admins |
+| `allowPlannedJobs` | Een job te plannen om eenmaal op een vast tijdstip te draaien (**Later uitvoeren**) | Aan |
+| `allowStoredJobs` | De gegevens van een formulier op te slaan en later weer te laden | Aan |
+| **Toegang en integraties** | | |
+| `allowLogin` | Zich aan te melden bij AnsibleForms | Aan |
+| `allowChat` | De [chat-assistent](../chat/) te gebruiken, als die is ingeschakeld | Aan |
+| `allowMcp` | De [MCP-server](../mcp/) vanuit een AI-agent te gebruiken, als die is ingeschakeld | De `allowChat` van de rol |
+| `allowFileUploads` | Bestanden te uploaden via de bestandsvelden van een formulier (vanaf 7.3.0) | Aan |
+| `allowApiTokens` | [API-tokens](../profile/api-token.html) voor scripts te maken, tot de langste levensduur die de instantie toestaat (vanaf 7.3.0) | Uit |
+| `extendedTokenExpiration` | Ook API-tokens te maken die nooit verlopen; vereist `allowApiTokens` | Uit |
+
+Sommige instellingen omvatten andere, en de pagina van de rol toont de inbegrepen instellingen als aan en grijs:
+
+- **`showSettings`** geeft ook `showAppearanceSettings`, `showConnectionsSettings` en `showAuditLog`.
+- **`manageAllJobs`** geeft ook `showAllJobLogs`, omdat handelen op de jobs van elke gebruiker betekent dat je ze ziet.
+- **De ontwerpinstellingen** tellen alleen mee met `showDesigner`, en `extendedTokenExpiration` alleen met `allowApiTokens`.
+
+Tot en met 7.2.0 liet `showAllJobLogs` een gebruiker ook de getoonde jobs afbreken en verwijderen; vanaf 7.3.0 is daarvoor `manageAllJobs` nodig.
+Een rol van vóór 7.3.0 met `extendedTokenExpiration` en zonder `allowApiTokens` krijgt `allowApiTokens`, zodat hij zijn tokens behoudt.
+
+**Alleen admins** betekent aan voor gebruikers met de rol `admin`, en uit voor alle anderen. Als een gebruiker met meerdere rollen overeenkomt,
+worden de instellingen als volgt gecombineerd:
+
+- **Tussen de rollen van de gebruiker** is een instelling alleen aan als elke rol die haar instelt het eens is: een expliciete `false` wint.
+- **De rol `default`** vult de instellingen aan die geen van de andere rollen van de gebruiker instelt, zodat hij standaardwaarden voor iedereen kan bevatten.
+- **Instellingen die nergens zijn ingesteld** nemen de standaardwaarde uit de tabel.
+
+`showExtraVars`, met een hoofdletter V, wordt geaccepteerd als andere schrijfwijze van `showExtravars`; als een van beide schrijfwijzen `false` is, staat de
+instelling uit.
+
+{: .warning }
+> Behandel `allowScheduledJobs` als een instelling op adminniveau. Planningen zijn geen eigendom van de gebruiker die ze heeft aangemaakt: elke gebruiker met
+> de instelling ziet alle planningen en kan ze wijzigen. Een planning draait ook met adminrechten, voor elk formulier, ongeacht de eigen
+> toegang van de maker. Geef haar alleen aan rollen die je als admins zou vertrouwen.
+
+{: .warning }
+> `allowLogin: false` op de rol `default` sluit elke gebruiker buiten wiens andere rollen geen `allowLogin: true` instellen, inclusief
+> de admins. Geef haar terug aan de rollen die zich moeten aanmelden voordat je opslaat.
diff --git a/i18n/nl/_configure/credentials.md b/i18n/nl/_configure/credentials.md
new file mode 100644
index 0000000..c402a39
--- /dev/null
+++ b/i18n/nl/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Inloggegevens
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Inloggegevens
+{: .no_toc }
+
+Bewaar de aanmeldgegevens waarmee formulieren, repositories, secret stores en meldingskanalen verbinding maken
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: voeg de gebruikers, wachtwoorden en tokens toe waarmee AnsibleForms verbinding maakt, versleuteld bewaard of gelezen uit een secret store.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Typen referenties](credentials/types.html) | Wat elk type bevat, en waar het kan worden gekozen |
+| [De pagina met inloggegevens](credentials/list.html) | De lijst met referenties, en het dialoogvenster waarmee je er een toevoegt |
+| [De pagina van een referentie](credentials/credential-page.html) | De tabbladen van een referentie, en wat haar gebruikt |
+
+---
+
+## Hoe het werkt
+
+Een **referentie** is een benoemde aanmelding, toegevoegd onder **Verbindingen > Inloggegevens**. Formulieren en de andere beheerobjecten verwijzen
+ernaar met haar naam, zodat het wachtwoord zelf nooit in een formulier verschijnt. De gebruiker en het wachtwoord worden ofwel in de
+AnsibleForms-database bewaard, versleuteld met `ENCRYPTION_SECRET`, ofwel elke keer dat de referentie wordt gebruikt uit een [secret store](secret-stores/)
+gelezen.
+
+---
+
+## Wie een referentie mag wijzigen
+
+Vanaf 7.3.0 kan een referentie waarvan een verbinding of een aanmelding afhangt alleen door een admin worden toegevoegd, gewijzigd of verwijderd:
+
+| Referenties | Waarom |
+|---|---|
+| Verbindingstypen: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` en `cyberark` | Een runner of een secret store haalt er zijn adres en zijn geheim uit |
+| Aanmeldtypen: `oidc`, `entraid` en `ldap` | Een SSO-provider of een LDAP-directory meldt er gebruikers mee aan |
+| Elke referentie die een runner noemt | De runner meldt zich ermee aan, en voor een wijziging van de runner zelf is ook een admin nodig |
+
+Andere gebruikers met toegang tot de referenties zien deze alleen-lezen. Een gebruiker die zo'n referentie naar een andere
+server zou kunnen laten wijzen, zou elk geheim ontvangen dat erdoorheen wordt verstuurd; daarom volgt de regel die voor runners. Nog drie regels
+houden die gebruikers weg van geheimen die ze anders niet zouden kunnen lezen:
+
+- **Een beschermde referentie noemen**: alleen een admin kan een van deze referenties elders noemen, zoals in een repository,
+  een meldingskanaal of de instellingen van de chat-assistent. Een referentie die haar wachtwoord uit een secret store leest, is
+  op dezelfde manier beschermd, ongeacht haar type.
+- **Een secret store kiezen**: alleen een admin kan een referentie naar een [secret store](secret-stores/) laten wijzen, of de
+  store of de referentie die ze leest wijzigen; een andere gebruiker mag ze nog wel ongewijzigd terugsturen, of ze allemaal leegmaken.
+- **Een referentie verplaatsen**: als een andere gebruiker wijzigt waar een referentie zich aanmeldt (host, poort, issuer, tenant of
+  serveradres) zonder het wachtwoord opnieuw te typen, wordt het opgeslagen wachtwoord gewist, en ook de verwijzing naar de secret store
+  die ze leest, zodat het oude geheim nooit naar het nieuwe doel gaat.
+
+---
+
+## Referenties in gebruik
+
+Een referentie die nog door records wordt genoemd, kan niet worden verwijderd of hernoemd, omdat die records dan naar niets zouden wijzen.
+De weigering noemt hoeveel records haar gebruiken; het tabblad **Gebruikt door** van [haar pagina](credentials/credential-page.html) toont ze.
+Laat ze eerst naar een andere referentie wijzen, en verwijder of hernoem haar daarna.
diff --git a/i18n/nl/_configure/credentials/credential-page.md b/i18n/nl/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..828d5af
--- /dev/null
+++ b/i18n/nl/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "De pagina van een referentie"
+parent: Inloggegevens
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# De pagina van een referentie
+{: .no_toc }
+
+De tabbladen van een referentie, en wat haar gebruikt
+{: .fs-6 .fw-300 }
+
+De pagina van een referentie toont de stappen van haar dialoogvenster als tabbladen, plus wat haar gebruikt:
+
+| Tabblad | Wat het bevat |
+|---|---|
+| Details | Naam en beschrijving. |
+| Type | Waarvoor de referentie dient. |
+| Aanmelding | Elk veld van haar type, zoals in de stap **Aanmelding** van het dialoogvenster: de gebruiker, het wachtwoord, en waar ze zich aanmeldt (host en poort, de database, de mailserver, de servers van de directory, de tenant of issuer, het adres van de server en de TLS ervan). Voor een CyberArk-referentie de AppID, het clientcertificaat en de sleutel. |
+| Opslag | Database of Geheimenkluis, en de store en de referentie. Niet voor CyberArk of HashiCorp Vault. |
+| Gebruikt door | Alles wat deze referentie noemt: secret stores, meldingskanalen, repositories, LDAP-directory's, SSO-providers, runners, de chat-assistent, formulieren en de workflows van de designer. Een rij opent het. |
+
+Het wachtwoord wordt in het tabblad **Aanmelding** getypt en wordt na het opslaan nooit meer getoond: leeg gelaten blijft het opgeslagen wachtwoord staan. Laat voor een CyberArk-referentie
+de clientsleutel leeg om de opgeslagen sleutel te behouden. Rechtsboven staan **Verbinding testen** (alleen voor databasereferenties),
+**Verwijderen** en **Opslaan**.
+
+Vanaf 7.3.0 worden **Verwijderen** en een nieuwe naam geweigerd zolang **Gebruikt door** iets toont, zie [Referenties in gebruik](../credentials.html#credentials-in-use).
+
+Een referentie die in de [configuratie-seed](../seed/) is gedeclareerd, is op deze pagina alleen-lezen: wijzig haar dan in het seedbestand.
diff --git a/i18n/nl/_configure/credentials/list.md b/i18n/nl/_configure/credentials/list.md
new file mode 100644
index 0000000..5b2eae4
--- /dev/null
+++ b/i18n/nl/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: De pagina met inloggegevens
+parent: Inloggegevens
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# De pagina met inloggegevens
+{: .no_toc }
+
+De lijst met referenties, en het dialoogvenster waarmee je er een toevoegt
+{: .fs-6 .fw-300 }
+
+De pagina onder **Verbindingen > Inloggegevens** toont elke referentie met haar **Naam**, **Type**, **Beschrijving** en **Gebruikt door**, het
+aantal records, formulieren en workflows dat haar noemt (zie [Referenties in gebruik](../credentials.html#credentials-in-use)).
+
+**Inloggegevens toevoegen** opent een dialoogvenster in stappen:
+
+| Stap | Velden |
+|---|---|
+| Referentie | Naam en beschrijving, beide verplicht. |
+| Type | Een van 18 typen, zie hieronder. |
+| Aanmelding | Waarmee en waar het type zich aanmeldt, zie hieronder. |
+| Opslag | Waar de gebruiker en het wachtwoord worden bewaard: **Database** (versleuteld in de AnsibleForms-database) of **Geheimenkluis**, met de store en de **Referentie** daarin. Niet voor CyberArk of HashiCorp Vault, waarmee een secret store zich aanmeldt. |
+
+De stap **Type** toont de typen op naam: AAP, API, Ascender, AWX, CyberArk, Database, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH, en Gebruiker en wachtwoord (zie [Typen referenties](types.html)).
+
+De stap **Aanmelding** bevat elk veld van het type, het adres inbegrepen; er is geen aparte verbindingsstap:
+
+| Typen | Velden van de stap Aanmelding |
+|---|---|
+| Elk type behalve CyberArk | Het wachtwoord, of wat ervoor in de plaats komt: het bindwachtwoord van LDAP, het client secret van Entra ID en Open ID, het token van HashiCorp Vault, het RTE-token, het API-token van Semaphore, Rundeck en Jenkins, een token of wachtwoord voor AWX, AAP en Ascender |
+| Elk type behalve HashiCorp Vault, RTE, Semaphore en Rundeck | De gebruiker: de AppID van CyberArk, de bind-DN van LDAP, de client ID van Entra ID en Open ID, optioneel voor AWX, AAP en Ascender |
+| SSH, Database | **Host** en **Poort**; voor een database ook het **Database type** en de **Database** |
+| SMTP | **Mail server** (verplicht), de **Poort** en **TLS gebruiken** |
+| LDAP | De **Servers** van de directory (verplicht), de **Poort** en **TLS inschakelen**; met TLS ook **Certificaten negeren**, de **CA-bundel** en een **Clientcertificaat** |
+| Microsoft Entra ID | **Tenant ID** (verplicht) en **Omleidings-URI** |
+| Open ID | **Issuer** (verplicht) en **Omleidings-URI** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Server**, het adres waarbij het zich aanmeldt, verplicht, met **Certificaatcontrole overslaan** en de **CA-bundel** |
+| CyberArk | **Clientcertificaat** en **Clientsleutel** |
+
+Een rij opent de eigen pagina van de referentie. Het menu biedt **Bewerken**, **Verbinding testen** (alleen voor databasereferenties) en **Verwijderen**. Het
+wachtwoord wordt gewijzigd op de pagina van de referentie, in het tabblad **Aanmelding**.
diff --git a/i18n/nl/_configure/credentials/types.md b/i18n/nl/_configure/credentials/types.md
new file mode 100644
index 0000000..125a81a
--- /dev/null
+++ b/i18n/nl/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Typen referenties
+parent: Inloggegevens
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Typen referenties
+{: .no_toc }
+
+Wat elk type bevat, en waar het kan worden gekozen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De typen
+
+Het type zegt waarvoor een referentie dient. Het bepaalt welke velden het dialoogvenster vraagt, en waar de referentie kan worden gekozen:
+
+| Type | Wat het bevat | Gebruikt door |
+|---|---|---|
+| Gebruiker en wachtwoord | Een gebruiker en wachtwoord voor elke aanmelding: een REST API met basic auth, een service en meer. De standaard | Playbooks, via de `credentials` van een formulier of een referentieveld; [REST-expressies](../expressions/credentials.html) |
+| SSH | Een gebruiker en wachtwoord voor SSH naar een server, met de host en poort | Playbooks, via de `credentials` of `ansibleCredentials` van een formulier of een referentieveld, en de aanmelding van een workflownode |
+| Git | Een gebruiker en wachtwoord of token voor git-repositories | [Repositories](../repositories/authentication.html) |
+| API | Een gebruiker en wachtwoord of token voor een REST API | [REST-expressies](../expressions/credentials.html), een Telegram-bottoken, het bearer-token van een webhook, de API-sleutel van de chat-assistent |
+| Database | Een database-aanmelding, met het type, de host, de poort en de databasenaam | Formulierquery's (`dbConfig`) en `fnCredentials`; ze kan worden getest |
+| CyberArk | Het adres van de CyberArk Central Credential Provider (CCP) en de TLS ervan, en de AppID, het clientcertificaat en de sleutel waarmee een CyberArk-store zich aanmeldt | Een [CyberArk](../secret-stores/cyberark.html)-secret store |
+| SMTP | Een mailserver, de poort en TLS, en de aanmelding (geen voor een relay) | Een [meldingskanaal](../notification-channels.html) voor mail |
+| LDAP | De servers, poort, TLS en certificaten van een directory, en de bind-DN en het wachtwoord | Een [LDAP-directory](../authentication/ldap.html) |
+| Microsoft Entra ID | De app-registratie van een provider: tenant ID, client ID, client secret en omleidings-URI | Een [Entra ID-provider](../authentication/entra-id.html) |
+| Open ID | De client van een provider: issuer, client ID, client secret en omleidings-URI | Een [OIDC-provider](../authentication/oidc.html) |
+| RTE | Het token (`RTE_TOKEN`) en het adres van een RTE | Een RTE-[runner](../runners.html) |
+| AWX, AAP, Ascender | Het token of de aanmelding, en het adres, van dat platform | Een runner van dat type |
+| Semaphore, Rundeck | Het API-token en het adres van dat product | Een runner van dat type |
+| Jenkins | Een gebruiker, het API-token en het adres van een Jenkins | Een Jenkins-runner |
+| HashiCorp Vault | Het token en het adres waarmee een Vault-store zich aanmeldt | Een [HashiCorp Vault](../secret-stores/hashicorp-vault.html)-secret store |
+
+Een databasereferentie kan van het type MySQL, MSSQL, PostgreSQL, Oracle of MongoDB zijn.
+
+In de API en de [configuratie-seed](../seed/) zijn de typen `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` en `vault`. De upgrade vanaf 6
+geeft elke referentie het type `userpass`, of `database` voor een databasereferentie: een formulier gebruikt haar zoals in 6. Wijzig het naar SSH voor een
+aanmelding waarmee het playbook van een workflownode verbinding maakt, of naar API voor een REST API.
+
+---
+
+## Adressen in referenties
+
+Vanaf 7.3.0 draagt een aanmelding die op één server werkt die server mee, zodat het record dat haar gebruikt alleen de referentie noemt:
+
+| Record | Wat naar de referentie is verplaatst |
+|---|---|
+| Een LDAP-directory | De servers, poort, TLS, certificaten en het bindaccount, naar een `ldap`-referentie met de naam `<directory>-ldap` |
+| Een SSO-provider | De client ID en het secret, de tenant of issuer, en de omleidings-URI, naar een `entraid`- of `oidc`-referentie met de naam `<provider>-sso` |
+| Een runner | Het adres en de TLS, en het token of de aanmelding, naar een referentie van zijn type, `<runner>-token` of `<runner>-login` |
+| Een secret store | Het adres en de TLS, en het token (`<store>-token`) of de CyberArk-AppID en het certificaat (`<store>-appid`) |
+| Een mailkanaal | De server, poort en TLS, naar zijn `smtp`-referentie, of een nieuwe met de naam `<channel>-smtp` |
+
+De upgrade naar 7.3.0 voert deze verplaatsingen eenmaal uit. Een record dat al een referentie noemde, behoudt haar, en krijgt er een kopie van als
+een ander record dezelfde aanmelding met een andere server gebruikte. Records die in de [configuratie-seed](../seed/) zijn gedeclareerd, blijven zoals de seed ze heeft.
+De referenties van de verbindingen en aanmeldingen kunnen alleen door een admin worden gewijzigd, zie [Wie een referentie mag wijzigen](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/nl/_configure/customization/configuration.md b/i18n/nl/_configure/customization/configuration.md
new file mode 100644
index 0000000..b1c98a0
--- /dev/null
+++ b/i18n/nl/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Configuratie
+parent: Omgevingsvariabelen
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Configuratie
+{: .no_toc }
+
+De configuratie-seed, waar de configuratie wordt bewaard, git en ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om te bepalen waar de configuratie vandaan komt: een configuratie-seed, de database, git of ytt-templates.
+
+---
+
+## Voorbeeld
+
+Pas een gekoppelde configuratie-seed toe, controleer hem elke vijf minuten, en bewaar `config.yaml` in de database. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Een ongeldige seed verhindert dat de server start. Zie [Configuratie-seed](../seed/) voor het bestandsformaat.
+
+---
+
+## Waar config.yaml wordt gelezen
+
+De categorieën, rollen en constanten komen uit `config.yaml` op schijf of uit de kopie ervan in de database, bepaald in deze volgorde:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), als die is ingesteld, in de omgeving of op het
+   tabblad **Configuratie** van de instellingenpagina: `1` leest de database, `0` leest het bestand.
+2. Anders de configuratiebron die in de database is opgeslagen (`file` of `database`), die instanties die
+   vóór 6.3.0 zijn opgezet op de instellingenpagina kozen.
+3. Anders het bestand: de `config.yaml` van de repository met **Gebruiken voor configuratie?** ingeschakeld, anders van een repository met
+   **Gebruiken voor formulieren?** ingeschakeld, anders die op [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Een expliciet ingestelde `ENABLE_CONFIG_IN_DATABASE` wint altijd, zelfs `0` boven een opgeslagen `database`. Ze wordt gelezen elke keer dat de
+configuratie laadt, dus een wijziging geldt zonder herstart. De pagina **Status** toont de gebruikte bron op het tabblad **Informatie**.
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/nl/_configure/customization/features.md b/i18n/nl/_configure/customization/features.md
new file mode 100644
index 0000000..d50e00d
--- /dev/null
+++ b/i18n/nl/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Functies
+parent: Omgevingsvariabelen
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Functies
+{: .no_toc }
+
+De designer, MCP, chat, validatie bij het starten, de jobslijst, metrics, de AWX API en het loggen van query's
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om optionele onderdelen van de applicatie in of uit te schakelen.
+
+---
+
+## Voorbeeld
+
+Bied de MCP-server aan voor AI-agents en dwing de validatieregels van het formulier af bij elke start. In de `.env` van het compose-project:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` en `ENABLE_CHAT` gelden zonder herstart: ze worden bij elk verzoek gelezen, dus je kunt ze op de
+instellingenpagina inschakelen. Zolang er een uit staat, antwoordt het endpoint ervan (`/api/v2/mcp` of `/api/v2/chat`) met `404`.
+
+Draai eerst een tijdje met `LAUNCH_VALIDATION=log`: dat logt wat `enforce` zou weigeren, zonder het te weigeren. Zie [MCP](../mcp/)
+en [Loggen en afdwingen](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/nl/_configure/customization/index.md b/i18n/nl/_configure/customization/index.md
new file mode 100644
index 0000000..25f6adf
--- /dev/null
+++ b/i18n/nl/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Omgevingsvariabelen
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Omgevingsvariabelen
+{: .no_toc }
+
+AnsibleForms configureren met omgevingsvariabelen
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders die AnsibleForms uitrollen: de omgevingsvariabelen die de server leest, gegroepeerd per onderwerp.
+
+AnsibleForms wordt afgesteld met omgevingsvariabelen, of het nu draait met Docker Compose, op Kubernetes of vanuit de broncode.
+
+---
+
+## Waar de waarden vandaan komen
+
+De server leest elke variabele uit de eerste van deze bronnen die haar instelt, dus een waarde hoger in de lijst wint altijd:
+
+1. **De procesomgeving**: `environment:` en `env_file:` in docker-compose (de `.env` van het project wordt zo doorgegeven),
+   `env` en `envFrom` op Kubernetes, of de shell die `node` start.
+2. **`persistent/.env`**, het bestand dat de instellingenpagina's schrijven (`data/.env` in het docker-compose-project, een ander pad met
+   `MANAGED_ENV_PATH`). Het wordt bij elke start gelezen, ook in productie, en overschrijft nooit een variabele die al is ingesteld.
+3. **`server/.env.<NODE_ENV>`**, bijvoorbeeld `.env.development`. Alleen gelezen als `NODE_ENV` niet `production` is (of met
+   `FORCE_DOTENV=1`), in de praktijk wanneer je [vanuit de broncode](../installation/from-source.html) in ontwikkelmodus draait.
+4. **De ingebouwde standaardwaarde**, getoond in de tabellen van elke groep.
+
+De instellingenpagina's, onder **Instellingen > Algemeen**, tonen de geldende waarde en slaan wijzigingen op in `persistent/.env`. Veel variabelen
+gelden zodra ze zijn opgeslagen; de andere worden opgeslagen maar vereisen een herstart, en de pagina toont ze na het opslaan. Een variabele die in
+de procesomgeving is ingesteld, kan daar niet worden gewijzigd: de pagina toont haar als *Ingesteld in de omgeving en hier niet aanpasbaar.*
+Een paar variabelen, zoals `ENCRYPTION_SECRET` en `ACCESS_TOKEN_SECRET`, kunnen nooit vanaf de pagina worden gewijzigd.
+
+De variabelen die een RTE leest, zoals `AF_ROLE`, `RTE_MODE`, `APP_URL` of `RTE_MAX_JOBS`, staan helemaal niet op de instellingenpagina's: de
+app gebruikt ze niet, dus stel ze in in de omgeving waar de RTE draait. De `RTE_*`-variabelen die de app zelf leest,
+`RTE_QUEUE_MINUTES` en `RTE_FILES_MAX_MB`, zijn de uitzondering en blijven op de pagina's. Vier RTE-variabelen, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` en `RTE_DRAIN_SECONDS`, kunnen in plaats daarvan per RTE op de runnerpagina worden ingesteld, waar een waarde voorgaat op de
+variabele (zie [De instellingen van een RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Met [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` tonen de pagina's alleen de waarden en wordt het opslaan geweigerd. Gebruik dit
+wanneer de omgeving in een manifest is gedeclareerd, zoals beschreven in [Bewerken en audit](../seed/environment-and-audit.html).
+
+De [configuratie-seed](../seed/) stelt geen omgevingsvariabelen in. Hij declareert objecten die in de database worden opgeslagen, en de
+verwijzingen `${ENV_VAR}` erin worden opgelost uit de omgeving van de draaiende server.
+
+Een paar variabelen worden alleen uit de omgeving gelezen en staan niet in de tabellen: `MANAGED_ENV_PATH` en `FORCE_DOTENV`, hierboven
+beschreven, en de proxyvariabelen van het systeem `HTTPS_PROXY` en `NO_PROXY` (ook in kleine letters gelezen). Een uitgaande RTE belt de app via
+`HTTPS_PROXY`, en een inkomende RTE stuurt zijn registratieaanroep erdoorheen, tenzij de host van de app in `NO_PROXY` staat (hostnamen,
+achtervoegsels `.domain`, of `*` voor elke host).
+
+Variabelen gemarkeerd met <span class="af-badge af-badge-secret">Geheim</span> bevatten een wachtwoord, token of sleutel: houd ze buiten
+versiebeheer, bijvoorbeeld in een Kubernetes Secret of een `.env`-bestand dat niet wordt gecommit.
+
+---
+
+## In deze sectie
+
+De variabelen zijn gegroepeerd per onderwerp, met één pagina per groep:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Overige variabelen
+
+De volgende variabelen zijn nog niet aan een groep toegewezen:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/nl/_configure/customization/logging.md b/i18n/nl/_configure/customization/logging.md
new file mode 100644
index 0000000..025faa6
--- /dev/null
+++ b/i18n/nl/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Logging
+parent: Omgevingsvariabelen
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Logging
+{: .no_toc }
+
+Logniveaus, bestanden, syslog en consolekleuren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om aan te passen hoeveel er wordt gelogd, waar de logbestanden terechtkomen, of om tijdstempels in je eigen tijdzone te tonen.
+
+---
+
+## Voorbeeld
+
+Log meer in de bestanden dan op de console, en toon de tijdstempels van log en jobs in Amsterdamse tijd.
+In de `.env` van het compose-project:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Syslogservers worden hier niet meer geconfigureerd: voeg ze toe onder **Instellingen > Verbindingen > Syslog**, zie [Logs](../production/logs.html#syslog).
+De variabelen `LOG_SYSLOG_*` hieronder zijn sinds 7 verouderd. De eerste start die `LOG_SYSLOG_HOST` ingesteld vindt, importeert ze
+eenmaal als de syslogserver `syslog`, die het serverlog ontvangt, en negeert ze vanaf dan.
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/nl/_configure/customization/paths.md b/i18n/nl/_configure/customization/paths.md
new file mode 100644
index 0000000..90a4373
--- /dev/null
+++ b/i18n/nl/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Paden
+parent: Omgevingsvariabelen
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Paden
+{: .no_toc }
+
+Waar de configuratie, formulieren, playbooks, uploads en back-ups staan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om een deel van de gegevens op een ander volume te bewaren, bijvoorbeeld back-ups en uploads op grotere of goedkopere opslag.
+
+---
+
+## Voorbeeld
+
+Back-ups en geüploade bestanden op een apart volume, de rest van de gegevens in de gebruikelijke persistente map. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Een nieuw pad geldt alleen voor nieuwe bestanden: wat al in de oude map staat, wordt niet verplaatst, dus kopieer het zelf over.
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/nl/_configure/customization/retention.md b/i18n/nl/_configure/customization/retention.md
new file mode 100644
index 0000000..4c370c5
--- /dev/null
+++ b/i18n/nl/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Back-ups en bewaartermijn
+parent: Omgevingsvariabelen
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Back-ups en bewaartermijn
+{: .no_toc }
+
+De back-upopdrachten, en hoe lang back-ups, jobs en auditrecords worden bewaard
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om te bepalen hoeveel geschiedenis de database bewaart, en hoeveel back-ups op schijf blijven staan.
+
+---
+
+## Voorbeeld
+
+Bewaar voltooide jobs 90 dagen en het audittrail twee jaar. In de `.env` van het compose-project:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Een dagelijkse taak verwijdert om 2:30 uur voltooide jobs die ouder zijn dan dit en om 3:30 uur auditregels. Een lopende job, of een die op
+goedkeuring wacht, wordt nooit verwijderd. Beide variabelen gelden zonder herstart als ze op de instellingenpagina worden gewijzigd.
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/nl/_configure/customization/security.md b/i18n/nl/_configure/customization/security.md
new file mode 100644
index 0000000..0054b64
--- /dev/null
+++ b/i18n/nl/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Beveiligingsvariabelen
+parent: Omgevingsvariabelen
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Beveiligingsvariabelen
+{: .no_toc }
+
+Tokens, versleuteling, uitgaande REST-hosts, maskering en de oude VAULT_*-instellingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze om je eigen geheimen voor tokens en versleuteling in te stellen, en om te beperken wat formulieren mogen aanroepen en tonen.
+
+---
+
+## Voorbeeld
+
+Je eigen geheimen, REST-aanroepen beperkt tot één API en een intern netwerk, en één extra gemaskeerde sleutel. In de `.env` van het compose-project:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Stel `ENCRYPTION_SECRET` in voordat de eerste referentie wordt opgeslagen. Vanaf 7.3.0 versleutelt het instellen of wijzigen ervan bij de volgende start elk opgeslagen
+geheim opnieuw, waarbij `ENCRYPTION_SECRET_PREVIOUS` de oude sleutel noemt als die van jezelf was, zie
+[Het versleutelingsgeheim wijzigen](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## REST-aanroepen en jq
+
+Vanaf 7.3.0 controleren de REST-hulpfuncties (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) het
+certificaat van het endpoint dat ze aanroepen, zoals elke andere verbinding; tot en met 7.2.0 deden ze dat nooit. Drie instellingen zijn erop van toepassing:
+
+| Variabele | Standaard | Effect |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` slaat de certificaatcontrole over: alleen voor endpoints met een zelfondertekend certificaat |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Hoe lang een REST-aanroep op een antwoord wacht voordat hij met een time-out mislukt |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Hoe lang een jq-filter mag draaien voordat het wordt gestopt; de uitvoer van jq is ook begrensd op 64 MB |
+
+Alle drie gelden zodra ze zijn opgeslagen, zonder herstart. Laat voor een endpoint waarvan het certificaat door een private CA is ondertekend de controle aan
+en geef Node.js in plaats daarvan die CA: stel `NODE_EXTRA_CA_CERTS` in de omgeving van de app in op een PEM-bestand dat haar bevat, en herstart daarna de app.
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/nl/_configure/customization/server.md b/i18n/nl/_configure/customization/server.md
new file mode 100644
index 0000000..174bf54
--- /dev/null
+++ b/i18n/nl/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Server en database
+parent: Omgevingsvariabelen
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Server en database
+{: .no_toc }
+
+De webserver, de MySQL-verbinding, het adminaccount, en wat elk proces draait (AF_ROLE en de RTE_*-variabelen)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wijzig deze wanneer de applicatie achter een reverse proxy draait, op een andere poort, of tegen een database buiten het compose-project.
+
+---
+
+## Voorbeeld
+
+Achter een reverse proxy die TLS afhandelt, onder `/ansibleforms`, met een externe MySQL. In `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Deze vervangen de regels `DB_*` en `PORT` die het compose-bestand daar al heeft, en die voorgaan op dezelfde namen in `.env`. Verwijder
+de service `mysqldb` en de `depends_on` die erop wacht, en koppel poort 8000 in `ports`. De kant van de proxy wordt beschreven op de
+pagina [Reverse proxy](../production/reverse-proxy.html).
+
+---
+
+## Variabelen
+
+Elke variabele van deze groep, met het type, de standaardwaarde en de beschrijving:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/nl/_configure/disclaimer.md b/i18n/nl/_configure/disclaimer.md
new file mode 100644
index 0000000..a4b31ab
--- /dev/null
+++ b/i18n/nl/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Disclaimer
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Disclaimer
+{: .no_toc }
+
+Voorwaarden die elke gebruiker één keer accepteert voordat hij de app gebruikt, vastgelegd met wie welke versie wanneer accepteerde
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: vraag elke gebruiker gebruiksvoorwaarden te accepteren, onder **Instellingen > Toegang > Disclaimer**, met de rolinstelling `showSettings`.
+
+Vanaf 7.3.0 toont de pagina elke versie van de disclaimer, en opent elke versie op een eigen pagina met haar acceptaties.
+Tot en met 7.2 had de pagina in plaats daarvan drie tabbladen (**Algemeen**, **Versies** en **Acceptaties**); de upgrade behoudt elke versie.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Algemeen](disclaimer/general.html) | De lijst met versies, er een toevoegen, en de versie inschakelen die gebruikers accepteren |
+| [Versies](disclaimer/versions.html) | De pagina van een versie, en de tekst wijzigen als correctie of opnieuw voor iedereen |
+| [Acceptaties](disclaimer/acceptances.html) | Wie welke versie accepteerde, en gekozen gebruikers opnieuw vragen |
+
+
+---
+
+## Wat gebruikers zien
+
+Met een ingeschakelde versie krijgt elke gebruiker die zich aanmeldt haar vóór al het andere in een dialoogvenster, admins inbegrepen:
+
+1. Ze lezen de titel en de tekst.
+2. Ze vinken het selectievakje aan en klikken op **Accepteren**. **Weigeren**, in rood, meldt ze in plaats daarvan af.
+
+Vanaf 7.3.0 is de pagina achter het dialoogvenster vervaagd totdat ze antwoorden.
+
+Een gebruiker accepteert elke versie één keer: bij de volgende aanmelding wordt het niet opnieuw gevraagd, alleen als er een nieuwe versie komt, als
+een admin een gewijzigde tekst opslaat met [Iedereen opnieuw vragen](disclaimer/versions.html#changing-the-text), of als een admin
+[Opnieuw vragen](disclaimer/acceptances.html#asking-users-again) op hun acceptatie gebruikt.
+
+Totdat ze accepteren, beantwoordt de API elke aanroep van hun sessie met status `403` en de code `disclaimer_required`,
+behalve de aanroepen onder `/api/v2/disclaimer` en `/api/v2/profile`, en de live events die de browser volgt.
+Een [API-token](profile/api-token.html) wordt het nooit gevraagd, omdat een script niemand heeft die kan klikken.
+
diff --git a/i18n/nl/_configure/disclaimer/acceptances.md b/i18n/nl/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..b5bb064
--- /dev/null
+++ b/i18n/nl/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Acceptaties
+parent: Disclaimer
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Acceptaties
+{: .no_toc }
+
+Wie welke versie accepteerde, en gekozen gebruikers opnieuw vragen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wie accepteerde
+
+Elke acceptatie wordt vastgelegd voor de gebruiker en de versie, en het tabblad **Acceptaties** van de pagina van een versie toont ze, de nieuwste eerst:
+
+| Kolom | Betekenis |
+|---|---|
+| **Gebruiker** | De gebruikersnaam |
+| **Aanmelding** | Hoe ze zich aanmeldden: Lokaal, LDAP, Microsoft Entra ID of OpenID Connect |
+| **Geaccepteerd** | Wanneer |
+| **IP-adres** | Vanwaar |
+| **Browser** | Hun browser |
+
+---
+
+## Gebruikers opnieuw vragen
+
+Vanaf 7.3.0 kunnen gekozen gebruikers worden gevraagd een versie opnieuw te accepteren, zonder iedereen te vragen.
+
+**Opnieuw vragen** in een rijmenu, of op de rijen die in de lijst zijn aangevinkt, wist die acceptaties na een bevestiging: die gebruikers krijgen de
+disclaimer opnieuw bij hun volgende verzoek, zonder zich opnieuw aan te melden. De lijst kan ook worden geëxporteerd, zoals elke tabel.
+
+Het [auditlogboek](../production/logs.html#audit-trail) legt ook elke acceptatie, elke weigering en elke wijziging van de disclaimer vast.
diff --git a/i18n/nl/_configure/disclaimer/general.md b/i18n/nl/_configure/disclaimer/general.md
new file mode 100644
index 0000000..99cbf53
--- /dev/null
+++ b/i18n/nl/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Algemeen
+parent: Disclaimer
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Algemeen
+{: .no_toc }
+
+De lijst met versies, er een toevoegen, en de versie inschakelen die gebruikers accepteren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De lijst
+
+Vanaf 7.3.0 is **Instellingen > Toegang > Disclaimer** een lijst van de versies van de disclaimer, één per tekst zoals die werd geaccepteerd:
+
+| Kolom | Betekenis |
+|---|---|
+| **Ingeschakeld** | Of dit de versie is die gebruikers accepteren; er is er hoogstens één ingeschakeld |
+| **Versie** | Het nummer, oplopend vanaf 1 |
+| **Titel** | De titel van het dialoogvenster |
+| **Gepubliceerd door** | Wie haar heeft toegevoegd |
+| **Gepubliceerd** | Wanneer |
+| **Acceptaties** | Hoeveel gebruikers haar accepteerden |
+
+Een klik op een rij, of **Bewerken** in het rijmenu, opent de [pagina van de versie](versions.html). Het menu heeft ook **Inschakelen** of **Uitschakelen**, en **Verwijderen**.
+
+---
+
+## Een versie toevoegen
+
+**Disclaimer toevoegen** opent een dialoogvenster voor een nieuwe versie, met het volgende nummer, die pas is ingeschakeld als je haar inschakelt:
+
+| Veld | Betekenis |
+|---|---|
+| **Titel** | De titel van het dialoogvenster, zoals Gebruiksvoorwaarden |
+| **Tekst** | Waarmee gebruikers akkoord gaan, maximaal 20000 tekens. Platte tekst: regeleinden blijven behouden. |
+| **Selectievakje** | Wat gebruikers aanvinken voordat ze kunnen accepteren, eerst "Ik heb deze voorwaarden gelezen en ga ermee akkoord." |
+
+Alle drie zijn verplicht. De versie die tot dan toe was ingeschakeld, blijft degene die gebruikers accepteren, zodat een nieuwe tekst vooraf kan worden voorbereid.
+
+---
+
+## Een versie inschakelen
+
+**Inschakelen** in een rijmenu, of de schakelaar **Ingeschakeld** op de pagina van de versie, maakt die versie degene die gebruikers accepteren en schakelt de
+andere uit.
+
+Gebruikers die die versie al accepteerden, worden niet opnieuw gevraagd, dus een eerdere versie kan opnieuw worden ingeschakeld zonder iedereen te vragen.
+**Uitschakelen** op de ingeschakelde versie zet de disclaimer uit totdat er weer een versie wordt ingeschakeld; de versies en acceptaties blijven bestaan.
+Het verwijderen van een versie verwijdert ook haar acceptaties, en het verwijderen van de ingeschakelde versie zet de disclaimer uit.
diff --git a/i18n/nl/_configure/disclaimer/versions.md b/i18n/nl/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..8b1cda7
--- /dev/null
+++ b/i18n/nl/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versies
+parent: Disclaimer
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versies
+{: .no_toc }
+
+De pagina van een versie, en de tekst wijzigen als correctie of opnieuw voor iedereen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De pagina van een versie
+
+Vanaf 7.3.0 heeft elke versie een eigen pagina, op `/settings/disclaimer/<version>`, met twee tabbladen:
+
+| Tabblad | Wat het bevat |
+|---|---|
+| **Details** | De titel, de tekst en het label van het selectievakje, en de schakelaar **Ingeschakeld**, die meteen wordt opgeslagen |
+| **Acceptaties** | Wie deze versie accepteerde, zie [Acceptaties](acceptances.html) |
+
+**Voorbeeld** toont het dialoogvenster zoals gebruikers het zullen zien, en **Verwijderen** verwijdert de versie met haar acceptaties. Het zoekvak boven de
+tabbladen doorzoekt beide tegelijk: de overeenkomende velden onder **Details** en de overeenkomende rijen onder **Acceptaties**.
+
+---
+
+## De tekst wijzigen
+
+**Opslaan** van een gewijzigde titel, tekst of label van het selectievakje dat gebruikers al accepteerden, vraagt **Iedereen opnieuw vragen?**:
+
+| Antwoord | Wat er gebeurt |
+|---|---|
+| **Iedereen opnieuw vragen** | De acceptaties van deze versie worden gewist, en elke gebruiker accepteert haar opnieuw bij zijn volgende verzoek |
+| **Houden als correctie** | De tekst wordt herschreven, bijvoorbeeld voor een typfout, en de acceptaties blijven gelden: niemand wordt opnieuw gevraagd |
+
+Een versie die nog niemand accepteerde, wordt opgeslagen zonder te vragen. Om de geaccepteerde tekst te behouden, [voeg je een nieuwe versie toe](general.html#adding-a-version) en schakel je die in.
diff --git a/i18n/nl/_configure/notification-channels.md b/i18n/nl/_configure/notification-channels.md
new file mode 100644
index 0000000..f1797e2
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Meldingskanalen
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Meldingskanalen
+{: .no_toc }
+
+Verstuur goedkeuringsaanvragen en jobmeldingen per mail, naar Slack, Microsoft Teams, Telegram of een willekeurige webhook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: voeg de mailservers en chatkanalen toe waarnaar formulieren hun meldingen en goedkeuringen sturen.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Mail](notification-channels/mail.html) | SMTP-servers, de standaardserver, en hun aanmelding |
+| [Slack en Microsoft Teams](notification-channels/slack-and-teams.html) | Een kanaalwebhook van Slack of Teams |
+| [Telegram](notification-channels/telegram.html) | Een bot die in een Telegram-chat post |
+| [Webhook](notification-channels/webhook.html) | Een JSON-verzoek naar een willekeurig HTTP-endpoint |
+| [Kanalen in een formulier gebruiken](notification-channels/in-a-form.html) | Kanalen noemen in meldingen en goedkeuringen |
+| [Een kanaal testen](notification-channels/testing.html) | Test versturen, en wat het bewijst |
+
+
+---
+
+## Hoe het werkt
+
+Een **meldingskanaal** is een plek waar meldingen naartoe gaan, toegevoegd onder **Verbindingen > Meldingen**. Elk kanaal heeft
+een van deze typen:
+
+| Type | Wat het verstuurt |
+|---|---|
+| Mail | Mail via een SMTP-server: goedkeuringsaanvragen en jobmeldingen. |
+| Slack | Een bericht in een Slack-kanaal, via zijn inkomende webhook, met een knop naar de job. |
+| Microsoft Teams | Een kaart in een Teams-kanaal, via een Workflows-webhook, met een knop naar de job. |
+| Telegram | Een bericht van een bot in een Telegram-chat, met een link naar de job. |
+| Webhook | Een JSON-verzoek naar een willekeurig HTTP-endpoint, opgebouwd uit een template. |
+
+Een formulier noemt zijn kanalen in zijn [meldingen](forms/notifications.html) en zijn [goedkeuring](forms/approval.html),
+met `channels:`. Een melding die niet kan worden verstuurd, wordt in het log geschreven; ze laat nooit de job of de goedkeuring mislukken.
+
+---
+
+## De pagina Meldingen
+
+De pagina onder **Verbindingen > Meldingen** toont elk kanaal met deze kolommen:
+
+| Kolom | Betekenis |
+|---|---|
+| Ingeschakeld | Of er meldingen naartoe worden gestuurd, zie [Kanalen in een formulier gebruiken](notification-channels/in-a-form.html). |
+| Naam | Hoe formulieren ernaar verwijzen in `channels:`. |
+| Type | Mail, Slack, Microsoft Teams, Telegram of Webhook. Het standaardmailkanaal toont een pilletje **Standaard** na het type. |
+| Beschrijving | Waarvoor het kanaal dient. |
+
+**Meldingskanaal toevoegen** opent een dialoogvenster: **Kanaal** (naam en beschrijving), **Type**, en daarna de stappen van het gekozen
+type. Het type wordt ingesteld wanneer het kanaal wordt aangemaakt en blijft zo. Een rij opent de eigen pagina van het kanaal, met dezelfde stappen als
+tabbladen na **Details**, en rechtsboven **Test versturen**, **Verwijderen** en **Opslaan**. Het rijmenu biedt
+**Bewerken**, **Inschakelen** of **Uitschakelen** (afhankelijk van wat van toepassing is), **Als standaard instellen** (mail), **Test versturen** en **Verwijderen**.
+
+Het tabblad **Details** van de pagina van een kanaal bevat de schakelaar **Ingeschakeld**, die meteen wordt opgeslagen, en voor mail de schakelaar **Standaard**,
+die met **Opslaan** wordt opgeslagen.
+
+Een gebruiker die deze pagina's opent met `showConnectionsSettings` maar zonder de rol admin, kan geen referentie kiezen die alleen
+een admin mag noemen, zie [Wie een referentie mag wijzigen](credentials.html#who-may-change-a-credential). Als zo'n gebruiker wijzigt
+waarheen een kanaal verstuurt (de url van een webhook of de certificaatcontrole ervan, het adres van een Telegram Bot API), verliest het kanaal de
+referentie die het noemde, tenzij hij in dezelfde wijziging er een kiest.
+
+Een kanaal dat in de [configuratie-seed](seed/) is gedeclareerd, is op deze pagina alleen-lezen, en kan nog steeds worden getest.
+
diff --git a/i18n/nl/_configure/notification-channels/in-a-form.md b/i18n/nl/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..53abc2b
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Kanalen in een formulier gebruiken
+parent: Meldingskanalen
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Kanalen in een formulier gebruiken
+{: .no_toc }
+
+Kanalen noemen in meldingen en goedkeuringen
+{: .fs-6 .fw-300 }
+
+Formulieren noemen kanalen bij hun naam, in `notifications` voor jobstatus en jobevents, en in `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- De chat- en webhookkanalen krijgen een kort bericht (het formulier, de job, wat er gebeurde) met een link naar de job; bij een
+  goedkeuring is de pagina van de job de plek waar die wordt goedgekeurd of afgewezen.
+- Een **mail**kanaal in de lijst verstuurt de gebruikelijke mail naar `recipients` (de `notifications`-adressen van een goedkeuring) via
+  die server in plaats van de standaardserver.
+- Een naam die niet bestaat, of een chat- of webhookkanaal dat is uitgeschakeld, wordt overgeslagen en in het log vermeld.
+- Een **mail**kanaal dat is uitgeschakeld, wordt niet overgeslagen: de mail gaat in plaats daarvan via het standaardmailkanaal, en het
+  log vermeldt dat.
diff --git a/i18n/nl/_configure/notification-channels/mail.md b/i18n/nl/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..713b74d
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Mail
+parent: Meldingskanalen
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Mail
+{: .no_toc }
+
+SMTP-servers, de standaardserver, en hun aanmelding
+{: .fs-6 .fw-300 }
+
+Een mailkanaal is een SMTP-server. Je kunt er meerdere hebben; degene die als **Standaard** is gemarkeerd, is de server waarmee de app haar
+mail verstuurt als een formulier geen mailkanaal noemt. Het eerste mailkanaal wordt de standaard, en **Als standaard instellen** verplaatst dat.
+
+| Stap | Veld | Betekenis |
+|---|---|---|
+| Referenties | Inloggegevens | Verplicht. Een **smtp**-referentie uit [Verbindingen > Inloggegevens](../credentials.html): de mailserver, de poort en TLS, en de aanmelding. Voor een relay zonder aanmelding een smtp-referentie zonder gebruiker. |
+| Afzender | Mail afzender | Het afzenderadres dat ontvangers zien. |
+
+De schakelaar **Standaard** op het tabblad **Details** van de pagina van een mailkanaal maakt het de standaard, zoals **Als standaard instellen** doet.
+De mailinstellingen van de configuratie-seed worden gebruikt zolang geen enkel mailkanaal de standaard is, of zolang het standaardkanaal is uitgeschakeld.
diff --git a/i18n/nl/_configure/notification-channels/slack-and-teams.md b/i18n/nl/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..25f539e
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack en Microsoft Teams
+parent: Meldingskanalen
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack en Microsoft Teams
+{: .no_toc }
+
+Een kanaalwebhook van Slack of Teams
+{: .fs-6 .fw-300 }
+
+Slack- en Teams-kanalen hebben alleen het adres van de webhook van het kanaal nodig:
+
+| Type | Webhookadres |
+|---|---|
+| Slack | De inkomende webhook van het kanaal (Slack-app > Incoming Webhooks). |
+| Microsoft Teams | De Workflows-webhook van het kanaal ("post to a channel when a webhook request is received"). |
+
+Het adres is het geheim waarmee iedereen in het kanaal kan posten: het wordt versleuteld opgeslagen en na het opslaan nooit meer getoond.
diff --git a/i18n/nl/_configure/notification-channels/telegram.md b/i18n/nl/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..101e632
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Meldingskanalen
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Een bot die in een Telegram-chat post
+{: .fs-6 .fw-300 }
+
+Een Telegram-kanaal is een bot die in een chat post. De stap **Referenties** bevat het **Bottoken**, de stap **Bot** de rest:
+
+| Veld | Betekenis |
+|---|---|
+| Bottoken | Een **api**-referentie uit [Verbindingen > Inloggegevens](../credentials.html) waarvan het wachtwoord het bottoken van BotFather is. |
+| Chat-id | De chat, groep of het kanaal waarin de bot post; een negatief getal voor een groep of een kanaal. |
+| Bot API-adres | Een eigen Bot API-server; leeg voor `api.telegram.org`. |
diff --git a/i18n/nl/_configure/notification-channels/testing.md b/i18n/nl/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..cd0fc13
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Een kanaal testen
+parent: Meldingskanalen
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Een kanaal testen
+{: .no_toc }
+
+Test versturen, en wat het bewijst
+{: .fs-6 .fw-300 }
+
+**Test versturen** stuurt een testmelding via het kanaal zoals het is opgeslagen, dus sla je wijzigingen eerst op. Het werkt ook op een kanaal
+dat is uitgeschakeld. Voor een mailkanaal
+vraagt het dialoogvenster naar welk adres er moet worden verstuurd; de andere posten in hun eigen kanaal. Het dialoogvenster toont of het werkte,
+en de reden als het niet werkte.
diff --git a/i18n/nl/_configure/notification-channels/webhook.md b/i18n/nl/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..6e780fe
--- /dev/null
+++ b/i18n/nl/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Meldingskanalen
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Een JSON-verzoek naar een willekeurig HTTP-endpoint
+{: .fs-6 .fw-300 }
+
+Een webhookkanaal stuurt een JSON-verzoek naar een willekeurig HTTP-endpoint. De stap **Endpoint** zegt waarheen en hoe, en de stap
+**Referenties** bevat het **Bearer-token**:
+
+| Veld | Betekenis |
+|---|---|
+| Url | Het adres waarnaar het verzoek wordt gestuurd. |
+| Methode | `POST` (standaard) of `PUT`. |
+| Bearer-token | Een **api**-referentie uit [Verbindingen > Inloggegevens](../credentials.html) waarvan het wachtwoord wordt verstuurd als `Authorization: Bearer <password>`. Leeg: geen token. |
+| Het TLS-certificaat controleren | Standaard aan; schakel het alleen uit voor een endpoint met een zelfondertekend certificaat. |
+
+{% raw %}
+De stap **Inhoud** bevat **Headers**, extra headers als JSON-object zoals `{ "X-Source": "ansibleforms" }`, en de
+**Inhoud**, de JSON-template van de body. Deze placeholders worden ingevuld:
+
+| Placeholder | Waarde |
+|---|---|
+| `{{title}}` | De titel van de melding |
+| `{{text}}` | De tekst ervan |
+| `{{status}}` | De jobstatus |
+| `{{event}}` | Het jobevent |
+| `{{jobId}}` | Het job-id |
+| `{{form}}` | De formuliernaam |
+| `{{user}}` | De gebruiker die de job startte |
+| `{{link}}` | De link naar de job |
+
+Een placeholder die een hele JSON-string is (`"{{text}}"`) wordt vervangen door de waarde als JSON; binnen een langere string wordt de
+tekst ervan voor JSON ge-escapet. Een onbekende placeholder blijft staan zoals hij geschreven is. Een lege inhoud verstuurt deze template:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/nl/_configure/production/backups.md b/i18n/nl/_configure/production/backups.md
new file mode 100644
index 0000000..c01ac9e
--- /dev/null
+++ b/i18n/nl/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Back-ups
+parent: Draaien in productie
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Back-ups
+{: .no_toc }
+
+Nachtelijke back-ups, wat ze bevatten, terugzetten, en wat je verder moet bewaren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Nachtelijke back-ups
+
+AnsibleForms maakt elke nacht om middernacht een back-up van zichzelf, in de tijdzone van [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(standaard UTC). Deze instellingen sturen dat:
+
+| Variabele | Standaard | Betekenis |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Waar back-ups worden geschreven, elk in een map met tijdstempel |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Hoeveel nachtelijke back-ups worden bewaard, `0` bewaart ze allemaal |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | De opdracht die de database dumpt |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | De opdracht die bij het terugzetten een dump afspeelt |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Hoe lang de dump en het terugzetten mogen duren |
+
+Gebruikers met de rolinstelling `allowBackupOps` kunnen op de pagina **Back-ups** ook op elk moment een back-up maken. Alleen nachtelijke
+back-ups worden door de bewaartermijn verwijderd, en alleen back-ups met een bruikbare dump tellen daarvoor mee, zodat een reeks mislukte
+nachten nooit de laatste goede verdringt.
+
+Voordat een upgrade de database wijzigt, maakt de worker eerst een gewone back-up, één keer per release, met de naam *Before the upgrade to
+&lt;version&gt;*. Die verschijnt op de pagina **Back-ups** en wordt nooit door de nachtelijke bewaartermijn verwijderd. Als ze mislukt (geen dumptool,
+`BACKUP_PATH` niet schrijfbaar), stopt de upgrade en zegt waarom, zodat de app nooit start op een half bijgewerkte database.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` voert de upgrade uit zonder back-up.
+
+De opdrachten mogen wrappers zijn zoals `docker exec <container> mysqldump`, als hun eerste woord lokaal bestaat. Vanaf 7.3.0 draaien ze
+zonder shell: aanhalingstekens en `$NAME` uit de omgeving van de opdracht werken, maar `;`, `|`, `&&`, `>` en `<` worden geweigerd.
+
+---
+
+## Databaserechten
+
+De dump draait als [`DB_USER`](../customization/server.html#env_DB_USER), en heeft niet meer rechten nodig dan de applicatie zelf:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+De dump wordt gemaakt met `--no-tablespaces`, zodat het serverbrede recht `PROCESS` niet nodig is, en slaat de tabellen over
+die de draaiende processen beschrijven (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). Het terugzetten speelt hem af als dezelfde gebruiker.
+De pagina **Status** toont een waarschuwing bij de controle **Databasegebruiker** als de gebruiker rechten heeft op elke database, zoals `root`.
+
+---
+
+## Wat een back-up bevat
+
+Elke back-up is een map onder `BACKUP_PATH`, genoemd naar de UTC-tijdstempel (`YYYYMMDDHHmmss`), met daarin:
+
+| Bestand | Inhoud |
+|------|---------|
+| `ansibleforms.sql` | De dump van de database `AnsibleForms`: gebruikers, groepen, referenties, jobs, instellingen, het audittrail |
+| `config.yaml` | Het bestand op [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | De map op [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | Het omgevingsbestand dat de instellingenpagina's schrijven, zonder `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` en `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | De beschrijving van de back-up |
+
+Een back-up waarvan de dump mislukt, wordt weer verwijderd en als fout gelogd. De pagina **Status** waarschuwt als er geen back-up is,
+als de nieuwste meer dan twee dagen oud is, of als die geen bruikbare dump heeft, en controleert of het dumptool bestaat.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) bewaart in plaats daarvan de herstelpunten van de designer (standaard 60 dagen).
+
+---
+
+## Een back-up terugzetten
+
+Zet terug vanaf de [pagina **Back-ups**](../gui/administration.html#restore), met **Maak eerst een nieuwe back-up aan voor het herstellen** aangevinkt. Bij het terugzetten:
+
+* wordt `ansibleforms.sql` afgespeeld, wat de hele database vervangt; vanaf 7.3.0 wordt een back-up van een oudere release daarna opnieuw
+  bijgewerkt, zoals bij de start van een nieuwe release, en wordt een patch die mislukt gemeld
+* wordt `config.yaml` teruggekopieerd en de map `forms/` vervangen door die van de back-up: vanaf 7.3.0 worden formulieren die niet in de back-up staan
+  verwijderd in plaats van bewaard, blijven de links en de modus van de map behouden, en draait een mislukte kopie de map terug
+* wordt `managed.env` **niet** teruggezet, omdat die de host beschrijft waar de back-up vandaan kwam. De knop **Omgeving herstellen**
+  zet hem op verzoek terug, bewaart het huidige bestand als `.env.bak`, en vereist een herstart.
+
+Een back-up zonder bruikbare dump wordt geweigerd; los na een onderbroken terugzetting de oorzaak op en zet opnieuw terug.
+
+Stel op een nieuwe host hetzelfde `ENCRYPTION_SECRET` in voordat je terugzet, anders kunnen de opgeslagen referenties niet worden ontsleuteld.
+
+---
+
+## Wat je verder moet back-uppen
+
+De nachtelijke back-up dekt de database, de configuratie en de formulieren, maar verder niets in de persistente map:
+
+* **`ENCRYPTION_SECRET` en `ACCESS_TOKEN_SECRET`** : nooit in een back-up, bewust. Bewaar ze in je secret manager;
+  zonder het versleutelingsgeheim is een databasedump nutteloos voor referenties.
+* **de back-ups zelf** : die staan op hetzelfde volume als de instantie. Kopieer `BACKUP_PATH` naar een andere host.
+* **de rest van de persistente map** : playbooks, uploads, vars-bestanden, gekloonde repositories, certificaten en logs.
+  Maak met het docker-compose-project een back-up van de hele map `data/`, die ook de SSH-sleutel, de eigen
+  functies en de Ansible-rollen en -collecties bevat.
+
+Inhoud die uit git komt (repositories, formulieren in een repository) kan opnieuw worden gekloond, dus de back-up ervan is minder belangrijk.
diff --git a/i18n/nl/_configure/production/index.md b/i18n/nl/_configure/production/index.md
new file mode 100644
index 0000000..4aabed9
--- /dev/null
+++ b/i18n/nl/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Draaien in productie
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# Draaien in productie
+{: .no_toc }
+
+Publiceer, back-up en monitor een instantie waarvan mensen afhankelijk zijn
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Voordat je live gaat
+
+Met de standaardwaarden draait een instantie snel, maar een aantal ervan is alleen bedoeld om eens rond te kijken. AnsibleForms
+logt bij het opstarten een waarschuwing `[SECURITY]` als `ENCRYPTION_SECRET` of `ACCESS_TOKEN_SECRET` niet is ingesteld, en de
+pagina **Status** rapporteert over de back-ups, de instellingen voor de bewaartermijn en de expressie-sanitizer.
+
+---
+
+## Checklist voor productie
+
+Loop deze punten één keer door voordat gebruikers van de instantie afhankelijk zijn, en opnieuw na een grote upgrade:
+
+| Punt | Wat te doen | Details |
+|------|------------|---------|
+| Adminwachtwoord | Wijzig het wachtwoord van het lokale adminaccount | [Hardening](../security/hardening.html#the-admin-account) |
+| Versleutelingsgeheim | Stel [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) in voordat je een referentie opslaat | [Geheimen en versleuteling](../security/secrets.html#the-two-master-secrets) |
+| Tokengeheim | Stel [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) in, zodat sessies een herstart overleven | [Geheimen en versleuteling](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Handel TLS af met je eigen certificaat, niet met het voorbeeldcertificaat | [HTTPS](../security/https.html) |
+| Reverse proxy | Publiceer de instantie achter een proxy, optioneel onder [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse proxy](reverse-proxy.html) |
+| Schema-endpoint | Zet [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) op `0` zodra het schema bestaat | [Hardening](../security/hardening.html#the-database) |
+| Uitgaande aanroepen | Beperk REST-expressies met [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Hardening](../security/hardening.html#expressions-and-outbound-calls) |
+| Optionele functies | Laat MCP en de chat-assistent uit, tenzij je ze gebruikt | [Hardening](../security/hardening.html#optional-features) |
+| Back-ups | Controleer of de nachtelijke back-up werkt, en kopieer hem van de host af | [Back-ups](backups.html) |
+| Bewaartermijn | Bepaal hoe lang jobs en auditregels worden bewaard | [Logs](logs.html#retention) |
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina; het beveiligen van de instantie wordt behandeld onder [Beveiliging](../security/):
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Reverse proxy](reverse-proxy.html) | AnsibleForms publiceren achter Nginx, Traefik of Apache, op de root of onder een subpad |
+| [Back-ups](backups.html) | Nachtelijke back-ups, wat ze bevatten, terugzetten, en wat je verder moet bewaren |
+| [Logs](logs.html) | Logbestanden, syslog, het audittrail, en de bewaartermijn van jobs en auditregels |
+| [Schalen](scaling.html) | Meerdere app-nodes met een worker; de RTE heeft een eigen sectie, [Runtime-omgevingen](../rte/) |
+| [Monitoring](monitoring.html) | Health probes, Prometheus-metrics en de pagina Status |
diff --git a/i18n/nl/_configure/production/logs.md b/i18n/nl/_configure/production/logs.md
new file mode 100644
index 0000000..3f27428
--- /dev/null
+++ b/i18n/nl/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Logs
+parent: Draaien in productie
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Logs
+{: .no_toc }
+
+Logbestanden, syslog, het audittrail, en hoe lang jobs en auditregels worden bewaard
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Logbestanden
+
+AnsibleForms schrijft twee dagelijks geroteerde logs naar [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), comprimeert oudere dagen en bewaart ze [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS) dagen
+(standaard 30, `0` bewaart elk bestand; een wijziging op de instellingenpagina geldt meteen):
+
+* `ansibleforms.<date>.log` : alles op [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) en hoger
+* `ansibleforms.errors.<date>.log` : alleen fouten
+
+De console, gelezen met `docker logs` of `kubectl logs`, heeft een eigen niveau,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Beide staan standaard op `notice`, wat juist is voor
+productie; gebruik `info` of `debug` alleen tijdens het oplossen van problemen, en laat
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) uit. De niveaus kunnen op
+de instellingenpagina's zonder herstart worden gewijzigd, en de pagina **Serverlog** toont het log aan gebruikers met de instelling `showLogs`.
+
+---
+
+## JSON-regels
+
+Stel voor een logcollector zoals Loki, ELK of Splunk [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) in op `json`. Elke
+regel, op de console en in de bestanden, is dan één JSON-object in plaats van `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Veld | Inhoud |
+|-------|---------|
+| `time` | Het tijdstip, in ISO 8601 UTC |
+| `level` | Het logniveau |
+| `message` | Het bericht |
+| `requestId` | Het verzoek waartoe de regel behoort, als hij werd geschreven tijdens het afhandelen ervan |
+| `role` | De rol van het proces, [`AF_ROLE`](scaling.html), of `all` als die niet is ingesteld |
+| `host` | De hostnaam van de machine of container waarin het proces draait |
+
+Elk verzoek krijgt een id: de header `X-Request-Id` die een reverse proxy meestuurde, of een nieuwe. Die wordt teruggegeven in de header
+`X-Request-Id` van het antwoord en meegenomen in elke regel die tijdens het afhandelen van het verzoek wordt geschreven (als `[req <id>]` in tekstregels),
+zodat een verzoek door het log kan worden gevolgd en met dat van de proxy kan worden vergeleken. Een wijziging op de instellingenpagina geldt meteen.
+
+---
+
+## Syslog
+
+Syslogservers worden beheerd onder **Instellingen > Verbindingen > Syslog**, zodat een syslogserver of SIEM het log krijgt zodra het wordt geschreven.
+Je kunt meerdere servers toevoegen, en elke server heeft eigen instellingen:
+
+| Instelling | Wat ze doet |
+|---------|--------------|
+| Ingeschakeld | Alleen ingeschakelde servers krijgen iets, zodat een server kan worden gepauzeerd zonder hem te verwijderen; **Inschakelen** en **Uitschakelen** in het rijmenu schakelen hem ook om |
+| Protocol | `udp4` (standaard), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` of `unix-connect` |
+| Host en poort | De server waarnaar wordt verstuurd, standaard poort `514`; een `unix`-protocol neemt in plaats daarvan een socketpad |
+| Ontvangt | Het serverlog, de auditregels, of beide (de standaard voor een nieuwe server) |
+| Niveau | Het laagste niveau van het serverlog dat hij krijgt, standaard `info`; auditregels worden altijd verstuurd |
+| Formaat | `BSD` (RFC 3164, de standaard) of `RFC 5424` |
+
+Een wijziging geldt op elke node zonder herstart, en de pagina van de server heeft een knop die er een testbericht naartoe stuurt.
+Een server die onbereikbaar is, stopt nooit de applicatie: de fout wordt naar de console geschreven.
+
+Vanaf 7.3.0 vereisen de syslogservers de volledige instellingenrechten, de rolinstelling [`showSettings`](../config/roles.html#role-options):
+toegang tot alleen de verbindingsinstellingen is niet genoeg, omdat een syslogserver het serverlog en de auditregels ontvangt.
+
+De variabelen `LOG_SYSLOG_*` van eerdere versies zijn sinds 7 verouderd. De eerste start die
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) ingesteld vindt, importeert ze eenmaal als de server `syslog`,
+die zoals voorheen het serverlog ontvangt, en negeert ze vanaf dan. Verwijder ze na die eerste
+start uit de omgeving, en beheer de server op de instellingenpagina.
+
+---
+
+## Audittrail
+
+De pagina **Auditlogboek** (onder **Instellingen > Logboeken**) legt vast wie wat heeft gewijzigd, een vraag die de logbestanden slecht beantwoorden.
+Ze legt vast:
+
+* elke wijziging via de API (`POST`, `PUT`, `PATCH`, `DELETE`), inclusief pogingen die met 401 of 403 zijn geweigerd
+* aanmeldingen, met de gebruikersnaam die werd geprobeerd
+* gebeurtenissen van de applicatie zelf, zoals nachtelijke back-ups, verwijderde back-ups, opgeschoonde jobs en toepassingen van de configuratie-seed
+
+Elke regel heeft een tijdstip, de actor (een gebruiker, of de applicatie zelf voor haar eigen taken), het IP-adres van de client,
+de actie, het doel en de uitkomst: `success`, `failure` of `denied`. De pagina filtert op actor, actie en
+uitkomst, en gebruikers met de rolinstelling `showSettings` kunnen haar openen.
+
+Het IP-adres is het adres dat AnsibleForms ziet, en dat is dat van de proxy als het erachter draait. Stel
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) in op het aantal of de adressen van je proxy's, en AnsibleForms
+legt dan het clientadres vast dat de proxy in `X-Forwarded-For` meldt; zie [Reverse proxy](reverse-proxy.html).
+
+Om het audittrail buiten de instantie te bewaren, voor een SIEM, voeg je een syslogserver toe die de auditregels ontvangt (zie
+[Syslog](#syslog)). Elke regel wordt verstuurd zodra hij ontstaat, als één regel `audit {...}` met de regel als JSON, ongeacht het
+niveau van de server. De syslogkopie wordt niet verwijderd door de bewaartermijn hieronder, en ook niet vervangen door het terugzetten van de database.
+
+---
+
+## Bewaartermijn
+
+Twee dagelijkse taken met een instelling voorkomen dat de database onbeperkt groeit:
+
+| Variabele | Standaard | Draait om | Verwijdert |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Auditregels die ouder zijn dan dit |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (alles bewaren) | 2:30 | Voltooide jobs die ouder zijn dan dit, met hun uitvoer |
+
+`0` bewaart bij beide alles. Nog twee dagelijkse taken hebben geen instelling: om 3:00 worden de opgeslagen refresh tokens die ouder zijn dan 30 dagen en
+de verlopen tokenintrekkingen verwijderd, en om 4:00 de [opgeslagen jobs](../jobs/stored-jobs.html) waarvan de vervaldatum voorbij is.
+De tijden zijn in de tijdzone van [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), en de worker voert ze uit.
+
+De joboutput is meestal de snelst groeiende tabel: de pagina **Status** meldt de grootte ervan
+en waarschuwt als die 1 GB overschrijdt zonder ingestelde bewaartermijn. Lopende jobs en jobs die op goedkeuring wachten, worden nooit verwijderd.
+Kies een bewaartermijn voor jobs die past bij je auditvereisten, en bewaar het audittrail minstens zo lang.
diff --git a/i18n/nl/_configure/production/monitoring.md b/i18n/nl/_configure/production/monitoring.md
new file mode 100644
index 0000000..1c7a23d
--- /dev/null
+++ b/i18n/nl/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Monitoring
+parent: Draaien in productie
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Monitoring
+{: .no_toc }
+
+Health probes voor een load balancer of Kubernetes, Prometheus-metrics, en de pagina Status
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Health probes
+
+Twee endpoints vertellen een load balancer, een container-healthcheck of Kubernetes of een proces verkeer kan aannemen.
+Geen van beide vereist een aanmelding, en geen van beide geeft iets prijs over de opzet:
+
+| Endpoint | Antwoordt | Gebruik het voor |
+|----------|---------|------------|
+| `/api/v2/live` | `200` met `{"status":"live"}` zolang het proces draait | Een liveness probe: herstart het proces als het niet meer antwoordt |
+| `/api/v2/ready` | `200` met `{"status":"ready"}`, of `503` met `{"status":"not ready","reason":"..."}` | Een readiness probe: stuur alleen verkeer naar processen die gereed zijn |
+
+Een proces is gereed als al deze voorwaarden gelden:
+
+* het wordt niet afgesloten (`stopping`)
+* de database antwoordt (`database unreachable`)
+* het schema bestaat (`schema not provisioned`) en is volledig, met elke tabel, kolom en index van deze versie
+  (`schema not upgraded`); deze laatste controle wordt 30 seconden gecachet, zodat een probe om de paar seconden goedkoop blijft
+
+Onder een [`BASE_URL`](../customization/server.html#env_BASE_URL) beginnen de paden daarmee, bijvoorbeeld
+`/ansibleforms/api/v2/ready`. Een runtime-omgeving (RTE) beantwoordt dezelfde probes op `/live` en `/ready`, zonder de
+controle op de volledigheid van het schema; ze is niet gereed terwijl ze bij het afsluiten haar jobs afbouwt, zodat er geen nieuwe job naartoe wordt gestuurd. Een uitgaande RTE
+is ook niet gereed (`not connected to the app`) totdat haar socket naar de app open is.
+Een proces dat met `AF_ROLE=worker` is gestart, heeft geen webinterface: het beantwoordt alleen `/api/v2/version` en `/health` voor zijn
+container-healthcheck. Zie [Schalen](scaling.html) voor de rollen.
+
+---
+
+## Prometheus-metrics
+
+Stel [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) in op een lange willekeurige string om Prometheus-metrics aan te bieden.
+Een proces dat de webapplicatie bedient, antwoordt op `/api/v2/metrics`, een RTE op `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Zonder `METRICS_TOKEN` antwoorden de endpoints met `404`, alsof ze niet bestaan, en een verzoek zonder de juiste
+header `Authorization: Bearer <token>` krijgt `401`. Elk proces rapporteert zijn eigen cijfers, dus scrape ze allemaal:
+
+| Metric | Wat ze meet |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | Het proces: CPU, geheugen, vertraging van de event loop, garbage collection |
+| `af_http_requests_total{route,method,status}` | De afgehandelde verzoeken |
+| `af_http_request_duration_seconds{route}` | Hoe lang ze duurden |
+| `af_jobs{status}` | Jobs die nu draaien (`running`) of op goedkeuring wachten (`approve`) |
+| `af_jobs_ended_24h{status}` | Jobs die in de laatste 24 uur zijn geëindigd, per status |
+| `af_nodes{role,alive}` | De processen die in de database zijn geregistreerd, per rol, levend of niet |
+| `af_login_failures_total`, `af_login_lockouts_total` | Mislukte aanmeldingen en accountblokkeringen |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Op een RTE: de playbooks die ze nu draait, en hoeveel ze er tegelijk mag draaien |
+| `af_rte_socket_connected` | Op een RTE in socketmodus: `1` zolang haar socket naar de app open is, `0` als dat niet zo is |
+
+De job- en nodecijfers worden bij elke scrape uit de database gelezen. Als de database niet antwoordt, worden ze weggelaten
+en slaagt de scrape toch met de andere metrics.
+
+---
+
+## De pagina Status
+
+De pagina **Status**, onder **Instellingen > Systeem**, laat gebruikers met de rolinstelling `showSettings` zien hoe het met de instantie gaat.
+Ze leest alleen, dus het vernieuwen ervan verstuurt nooit mail en start nooit een job. Ze heeft twee tabbladen, en het aantal problemen staat op het label van het tabblad **Controles**.
+
+### Controles
+
+Elke controle is groen (gezond), oranjegeel (vraagt aandacht) of rood (een probleem), met de details als je de rij uitklapt:
+
+| Controle | Waar ze naar kijkt |
+|-------|------------------|
+| Databaseverbinding | De database antwoordt |
+| Databasegebruiker | Oranjegeel als de gebruiker rechten heeft op elke database, zoals `root`, in plaats van alleen op `AnsibleForms.*` |
+| Databaseschema | Elke tabel, kolom en index van deze versie bestaat, en welke patch mislukte als dat niet zo is |
+| Planner | Een worker voert de systeemtaken uit, en geen ervan is gestopt met plannen |
+| Nodes | De processen in de database, oranjegeel als ze verschillende versies draaien |
+| Jobs | Lopende jobs en jobs die op goedkeuring wachten, oranjegeel als een job langer dan 24 uur draait |
+| Back-uptools | De dumpopdracht van [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) bestaat, en de versie ervan |
+| Laatste back-up | Oranjegeel als er geen is of de nieuwste meer dan twee dagen oud is, rood als die geen bruikbare dump heeft |
+| Designer-vergrendeling | Wie de designer-vergrendeling heeft, oranjegeel als die langer dan 8 uur wordt vastgehouden |
+| Repositories | Rood als een repository is mislukt of geen werkboom op schijf heeft |
+| Configuratie-seed | Het bestand van de [configuratie-seed](../seed/) is leesbaar en te parsen, en de laatste herlaadbeurt werkte |
+| Secret stores | Elke secret store antwoordt, oranjegeel als het token van een HashiCorp Vault binnenkort verloopt |
+| Runners | Elke runner antwoordt, oranjegeel als er geen is of geen standaard-RTE |
+| Serverexpressies | Oranjegeel als [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) `legacy` is |
+| Geheimen | Oranjegeel als `ENCRYPTION_SECRET` de openbare standaardwaarde is of `ACCESS_TOKEN_SECRET` niet is ingesteld |
+| LDAP | De LDAP-server is bereikbaar en zijn TLS-certificaat is geldig, zonder erop aan te melden |
+| Jobopslag | De grootte van de jobtabellen, oranjegeel boven 1 GB als er geen bewaartermijn voor jobs is ingesteld |
+| Schrijfbare mappen | Naar elke geconfigureerde map kan worden geschreven |
+| Schijfruimte | De schijf met de back-ups, oranjegeel vanaf 85% gebruikt en rood vanaf 95% |
+
+### Informatie
+
+Feiten over de instantie zonder oordeel, het eerste waar een supportgesprek om vraagt: de AnsibleForms-versie,
+de basis-URL, de databaseversie en -host, de configuratiebron, de configuratie-seed, de instellingen voor de bewaartermijn,
+de authenticatiemethoden, de server van het actieve [mailkanaal](../notification-channels.html), het logniveau
+en -pad, de uptime, de tijdzone, de Node.js-versie en het platform.
+
+De pagina leest `/api/v2/health`, waarvoor een aangemelde gebruiker met `showSettings` nodig is. Gebruik voor een monitoringsysteem in plaats daarvan
+de probes en de metrics hierboven.
diff --git a/i18n/nl/_configure/production/reverse-proxy.md b/i18n/nl/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..385d6ea
--- /dev/null
+++ b/i18n/nl/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse proxy
+parent: Draaien in productie
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse proxy
+{: .no_toc }
+
+AnsibleForms publiceren achter Nginx, Traefik of Apache, op de root of onder een subpad
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wanneer je er een gebruikt
+
+AnsibleForms bedient de interface, de REST API en Swagger op één poort; met een reverse proxy ervoor kun je:
+
+* het op poort 443 aanbieden met een certificaat dat door je bestaande tooling wordt beheerd (ACME, een bedrijfs-CA)
+* één hostnaam delen met andere applicaties, door AnsibleForms onder een subpad te publiceren
+* de applicatiepoort en de database buiten het openbare netwerk houden
+
+Een proxy is optioneel: de applicatie kan zelf HTTPS bedienen, zie [HTTPS](../security/https.html).
+
+---
+
+## De instellingen die ertoe doen
+
+Slechts een paar instellingen beïnvloeden hoe AnsibleForms zich achter een proxy gedraagt:
+
+| Instelling | Achter een proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | De poort waarnaar de proxy doorstuurt, standaard `8000`. Het docker-compose-project zet hem op `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` als de proxy TLS afhandelt en de applicatie via een privénetwerk bereikt, `1` om ook dat traject te versleutelen. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | Het subpad, bijvoorbeeld `/ansibleforms`. Laat het op `/` als de applicatie een eigen hostnaam heeft. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Welke proxy's het clientadres in `X-Forwarded-For` mogen melden, meestal `1`. Zie [Clientadressen](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | Grootste JSON-verzoek dat de applicatie accepteert, standaard 50 MB. De proxy moet minstens dit toestaan. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | Grootste bestand dat een uploadveld van een formulier accepteert, standaard 10 GB. De proxy moet het ook toestaan, anders mislukken uploads daar. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | Grootste set verzoekheaders die de applicatie accepteert, standaard 16 KB, vanaf 7.1.0. Zie [Grootte van verzoekheaders](#request-header-size). |
+| **Publieke root URL** | Onder **Systeem > Algemeen**, op het tabblad **Server**: het adres dat gebruikers bereiken, subpad inbegrepen. Het bouwt de links in meldingsmails, kanaalberichten en goedkeuringsaanvragen. |
+
+Registreer voor Entra ID of OIDC het openbare adres als omleidings-URI, met het subpad van `BASE_URL` als dat is ingesteld.
+
+---
+
+## Aanbieden onder een subpad
+
+`BASE_URL` koppelt de hele applicatie onder het subpad; de proxy moet het pad **ongewijzigd** doorsturen.
+Met `BASE_URL=/ansibleforms`:
+
+* worden de interface, `/api/v2/...` en de Swagger-interface allemaal onder `/ansibleforms/` aangeboden
+* wordt de `<base href>` van de interface bij het opstarten herschreven, zodat assets en API-aanroepen onder het subpad worden opgelost
+* wordt een verzoek voor `/` of voor `/ansibleforms` (zonder afsluitende slash) doorgestuurd naar `/ansibleforms/`
+
+Behoud het voorvoegsel: geen `StripPrefix` in Traefik, geen URI op `proxy_pass` in Nginx, omdat de applicatie het verwacht.
+
+De pagina **Status** toont de geldende basis-URL.
+
+---
+
+## Time-outs, uploads en live uitvoer
+
+De jobpagina en de jobtellers horen van wijzigingen via één langlevende stroom server-sent events,
+[`/api/v2/events`](../api/events.html), die per browser open wordt gehouden. De stroom stuurt headers die proxybuffering uitschakelen
+(`X-Accel-Buffering: no`) en elke 15 seconden een keep-alive-regel, zodat de gebruikelijke leestime-out van 60 seconden hem open houdt;
+als een proxy hem toch sluit, maakt de browser zelf opnieuw verbinding. De uitvoer onder een formulier, direct na een start, wordt
+in plaats daarvan elke twee seconden gelezen. Het starten van een job keert terug zodra de job is aangemaakt, zodat een lang playbook
+geen verzoek open houdt.
+
+De verzoeken die lang kunnen duren, zijn:
+
+* **back-up en terugzetten** vanaf de pagina **Back-ups**, die wachten tot de dump- of terugzetopdracht klaar is, tot
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (standaard 3600)
+* **grote uploads** via een bestandsveld, die het hele bestand in één verzoek streamen
+* **chatberichten**, als de [chat-assistent](../chat/) is ingeschakeld, die wachten tot de modelprovider antwoordt
+
+Proxy's hebben vaak een time-out na 60 seconden en begrenzen de verzoekbody (Nginx accepteert standaard 1 MB). Verhoog beide voor
+de AnsibleForms-routes, zoals in de voorbeelden hieronder.
+
+---
+
+## Runner-WebSockets
+
+Vanaf 7.3.0 belt een [uitgaande Runner](../rte/modes.html#outbound) de applicatie en houdt één WebSocket open op
+`<BASE_URL>/api/v2/rte/socket`. De proxy moet de upgrade doorgeven, anders maakt de Runner nooit verbinding en blijft hij bellen:
+
+| Proxy | Wat de WebSocket nodig heeft |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` en de headers `Upgrade` en `Connection`, die Nginx standaard niet doorstuurt |
+| Traefik | Niets: WebSockets gaan ongewijzigd door |
+| Apache | `upgrade=websocket` op de regel `ProxyPass` (2.4.47 en later), of daarvoor `mod_proxy_wstunnel` |
+
+Beide kanten sturen elke 20 seconden een ping, zodat de gebruikelijke leestime-out van 60 seconden een inactieve socket open houdt.
+
+---
+
+## Grootte van verzoekheaders
+
+Elk verzoek draagt het aanmeldtoken in de header `Authorization`, naast cookies en de headers die de proxy toevoegt.
+Zowel de proxy als de applicatie begrenzen de grootte van de verzoekheaders, en weigeren een verzoek boven de grens voordat
+AnsibleForms het ziet, dus er komt niets in het serverlog. De standaardwaarden:
+
+| Component | Limiet | Standaard | Geweigerd met |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), alle headers samen | 16384 bytes | 431 |
+| Nginx | `large_client_header_buffers`, per headerveld | `4 8k`: 8 KB per veld | 400 |
+| Traefik | `http.maxHeaderBytes` van het entrypoint, alle headers samen | 1 MB | 431 |
+| HAProxy | `tune.bufsize` in de sectie `global`, het hele headerblok, min de reserve `tune.maxrewrite` (1024 bytes) | 16384 bytes: 15360 bytes aan headers | 400 |
+| Apache | `LimitRequestFieldSize`, per headerveld | 8190 bytes | 400 |
+
+Tot en met 7.0.3 droeg het aanmeldtoken elke groep van een single sign-on-gebruiker, en kon het deze limieten ontgroeien, zie
+[Lege formulieren en jobs na een single sign-on](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Vanaf 7.1.0 blijft het token klein, en volstaan de standaardwaarden. Als iets anders de headers groot maakt, zoals
+cookies van andere applicaties op hetzelfde domein of een single sign-on-gateway ervoor, verhoog de limieten dan samen:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536`, of vóór 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; beide worden
+  bij het starten gelezen, dus herstart de applicatie na een wijziging
+* Nginx: `large_client_header_buffers 4 32k;` in het blok `http` of `server`
+* HAProxy: `tune.bufsize 65536` in de sectie `global`; elke stream krijgt een buffer van die grootte, dus HAProxy raadt aan
+  de globale `maxconn` met dezelfde factor te verlagen, en HTTP/2 heeft minstens de standaard 16384 nodig
+* Apache: `LimitRequestFieldSize 32768` in de serverconfiguratie of de virtual host
+
+---
+
+## Clientadressen
+
+Achter een proxy komt elke verbinding van de proxy. Zonder [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY)
+legt het audittrail voor elke actie het adres van de proxy vast, en tellen de
+[aanmeldlimieten](../security/hardening.html#sign-in-limits-and-passwords) per adres alle clients als één adres.
+`TRUST_PROXY` zegt welke proxy's de applicatie mag geloven als ze de client in `X-Forwarded-For` melden:
+
+| Waarde | Clientadres |
+|-------|----------------|
+| `0` (standaard) | Het adres van de verbinding. `X-Forwarded-For` wordt genegeerd; leeg, `false`, `off` en `no` betekenen hetzelfde. |
+| Een getal, bijv. `1` | Vertrouwt zoveel proxy's voor de applicatie: `1` voor één reverse proxy, `2` voor een load balancer voor een ingress. |
+| Een lijst, bijv. `10.0.0.5,172.16.0.0/12` | Vertrouwt de proxy's op deze adressen en CIDR-bereiken. De presets `loopback`, `linklocal` en `uniquelocal` worden ook geaccepteerd. |
+| `true` | Vertrouwt elke hop: het meest linkse adres van `X-Forwarded-For` wordt gebruikt. |
+
+De applicatie loopt `X-Forwarded-For` van rechts af, slaat de vertrouwde proxy's over, en neemt het eerste adres dat
+er geen van is. Gebruik het exacte aantal proxy's, of hun adressen:
+
+* `X-Forwarded-For` is een gewone verzoekheader die elke client kan sturen. Een te hoog getal, of `true`, laat een
+  client kiezen welk adres het audittrail vastlegt. `true` is alleen veilig als de applicatie uitsluitend via
+  de proxy bereikbaar is, en de server logt bij het starten een waarschuwing `[SECURITY]` als het is ingesteld.
+* De proxy moet het adres toevoegen waarvan hij de verbinding ontving, zoals de voorbeelden hieronder doen
+  (`$proxy_add_x_forwarded_for` in Nginx; Traefik en Apache `mod_proxy` voegen het standaard toe).
+* Een ongeldige waarde wordt op de instellingenpagina geweigerd; ingesteld in de omgeving wordt ze bij het starten als fout gelogd en
+  wordt geen enkele proxy vertrouwd. Een wijziging die op de instellingenpagina is opgeslagen, geldt zonder herstart.
+
+---
+
+## Voorbeelden
+
+Elk voorbeeld publiceert AnsibleForms op `https://forms.example.com/ansibleforms/`, met TLS afgehandeld door de proxy en
+de applicatie draaiend met `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` en `TRUST_PROXY=1`:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` noemt geen URI, dus Nginx stuurt het pad door zoals het binnenkwam, voorvoegsel inbegrepen. Het blok `map` hoort in de
+context `http` (een bestand onder `conf.d/` wordt daar ingevoegd), en geeft de WebSocket-upgrade van de Runners door:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Gebruik zonder subpad `location /` en laat `BASE_URL` leeg.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Labels op de service `app` van het docker-compose-project, met Traefik op hetzelfde Docker-netwerk. De service
+publiceert geen eigen poort, Traefik bereikt hem via het netwerk:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Er is bewust geen middleware `StripPrefix`. Traefik stelt de headers `X-Forwarded-*` zelf in en begrenst
+de bodygrootte niet, maar controleer de `respondingTimeouts` van het entrypoint als back-ups of uploads langer duren dan de
+leestime-out ervan. Houd zonder subpad alleen het deel `Host(...)` van de regel.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Vereist `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl`, en Apache 2.4.47 of later voor `upgrade=websocket` van de Runners.
+Beide kanten van `ProxyPass` dragen het voorvoegsel:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Proxy zonder subpad `/` naar `http://10.0.0.20:8000/` en laat `BASE_URL` leeg.
+
+</div>
+</div>
+
+Om het traject tussen proxy en applicatie versleuteld te houden, draai je de applicatie met `HTTPS=1`, laat je de proxy naar
+`https://` wijzen, en geef je de applicatie een certificaat dat de proxy vertrouwt, zie [HTTPS](../security/https.html).
diff --git a/i18n/nl/_configure/production/scaling.md b/i18n/nl/_configure/production/scaling.md
new file mode 100644
index 0000000..d863019
--- /dev/null
+++ b/i18n/nl/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Schalen
+parent: Draaien in productie
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Schalen
+{: .no_toc }
+
+AnsibleForms verdeeld over meerdere app-nodes en een worker, naast een of meer RTE's
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Rollen
+
+Elke AnsibleForms-container draait dezelfde servercode, en [`AF_ROLE`](../customization/server.html#env_AF_ROLE) bepaalt wat hij doet:
+
+| `AF_ROLE` | Image | Draait | Hoeveel |
+|---|---|---|---|
+| `all` (niet ingesteld) | `ansibleforms` | De webapp en de worker in één proces: de standaard | 1 |
+| `app` | `ansibleforms` | De webinterface en de API | Zoveel als je wilt, achter een load balancer |
+| `worker` | `ansibleforms` | Het achtergrondwerk: het databaseschema en de upgrades ervan, de configuratie-seed, de planningen, de nachtelijke back-up, de synchronisaties van repositories en de opschoningen | Eén aan het werk; meer wachten en nemen het over |
+| `rte` | `ansibleforms-rte-full` (of `-rte-core`, `-rte-base`) | De playbooks | Zoveel als je wilt |
+
+De kleinste installatie is één container zonder `AF_ROLE` naast één RTE: dat is wat het [Docker Compose-project](../installation/docker-compose.html)
+en de [Helm-chart](../installation/kubernetes.html) draaien. Elke andere waarde van `AF_ROLE` stopt het proces bij de start.
+
+---
+
+## De RTE
+
+De RTE, de runtime-omgeving die de playbooks draait, heeft een eigen sectie: [Runtime-omgevingen](../rte/). Daar staat hoe een RTE
+een job draait, [de images](../rte/images.html), [hoe je er een draait](../rte/run.html), [meerdere RTE's](../rte/several.html) als runners of
+replica's, en [een RTE in een ander datacenter](../rte/another-datacenter.html).
+
+---
+
+## Meerdere app-nodes
+
+Om meer gebruikers te bedienen, of het verlies van één node te overleven, splits je de app op in `app`-nodes achter een load balancer en een `worker`.
+
+### Wat de nodes delen
+{: .no_toc }
+
+De nodes stemmen met elkaar af via de database en een gedeeld volume:
+
+* **De database** : de jobs, de workervergrendeling, de designer-vergrendeling, de lijst met nodes, de runnerleases (welke app-node de
+  socket van elke RTE vasthoudt) en de wijzigingsberichten die de caches van elke node actueel houden. Een referentie, een runner of een planning die
+  op één node is bewerkt, geldt binnen 5 seconden op alle nodes
+* **Het persistente volume** (`/app/dist/persistent`) : formulieren, de configuratie, repositories, uploads, back-ups en de beheerde `.env`.
+  Elke app-node en de worker koppelen hetzelfde volume, met lees- en schrijfrechten
+* **De ssh-map** (`/home/node/.ssh`) : de sleutel en de known hosts voor git over ssh; de worker maakt de sleutel bij zijn eerste start aan
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : hetzelfde op elke app-node, anders wordt een token dat door
+  de ene node is ondertekend door de volgende geweigerd. Een app-node weigert zonder dit geheim te starten
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : hetzelfde op elke app-node en worker, anders kan een
+  referentie die door de ene is opgeslagen door de andere niet worden gelezen. Een RTE in socketmodus leest het nooit; alleen een verouderde RTE in databasemodus
+  die zichzelf registreert, heeft het nodig
+
+Geef elke container ook dezelfde databasegebruiker: een wachtende worker kan de sessie van een dode worker alleen beëindigen als het zijn eigen sessie is.
+
+### De workervergrendeling
+{: .no_toc }
+
+Er werkt steeds maar één worker. Die houdt de databasevergrendeling `ansibleforms_worker` vast; als hij stopt, geeft de database de vergrendeling vrij en neemt een
+wachtende worker haar binnen 10 seconden over. Als de host van de worker zonder afscheid uitvalt, zou de database de vergrendeling uren kunnen vasthouden,
+dus beëindigt een wachtende worker die sessie zodra geen enkele worker twee minuten lang een heartbeat heeft geschreven, en neemt hij het over.
+
+Een worker die de vergrendeling aan een andere verliest, stopt, en zijn container herstart als de wachtende. Een worker waarvan de start mislukt, stopt
+ook, zodat hij de vergrendeling nooit vasthoudt zonder iets te doen. Galera en group replication delen de vergrendeling niet tussen databasenodes: laat elke
+worker naar dezelfde databasenode wijzen.
+
+### Jobs en nodes
+{: .no_toc }
+
+Elke container noemt zichzelf `<role>-<hostname>-<port>`, zonder dat je iets hoeft in te stellen, en de pagina **Status** toont ze allemaal met hun rol
+en versie, welke de worker is, en een waarschuwing als ze verschillende versies draaien.
+
+Een job die op een RTE draait, hoort bij die RTE, en loopt door als de app-node die hem startte wegvalt. Elke andere job (een templatejob
+op AWX of een andere runner, een workflowjob, of de stappen van een verouderd multistep-formulier) hoort bij de app-node die hem startte. Een container die herstart, beëindigt zijn eigen onvoltooide jobs, en de
+worker beëindigt de jobs van een container die twee minuten lang niet antwoordde, zoals een vervangen pod.
+
+Een `SIGHUP` die naar een willekeurige node wordt gestuurd, past de [configuratie-seed](../seed/) opnieuw toe: een app-node vraagt de worker dat te doen.
+
+### Upgraden
+{: .no_toc }
+
+Upgrade **eerst de worker**, daarna de app-nodes. De worker patcht het schema, en een app-node van de nieuwe versie wacht tot het
+schema is gepatcht en logt waarop hij wacht. App-nodes die eerst zijn geüpgraded, blijven niet gereed totdat de worker volgt, terwijl de oude blijven
+bedienen. RTE's kunnen op elk moment volgen, zolang ze hetzelfde contract spreken.
+
+### Beperkingen
+{: .no_toc }
+
+Een paar dingen blijven bij één node:
+
+* **De chat-assistent** bewaart zijn gesprekken in het geheugen van één app-node: gebruik sticky sessions op de load balancer (nginx
+  `ip_hash`), of één enkele app-node
+* **Logs** blijven in elke container. Zet [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) buiten het gedeelde volume, omdat meerdere
+  processen die één bestand roteren regels verliezen. De logviewer toont het log van de node die antwoordt, dus verzamel de logs centraal
+* **Instellingen** die op de instellingenpagina's worden gewijzigd, worden naar de beheerde `.env` op het gedeelde volume geschreven en gelden op elke node; de instellingen
+  die een herstart vereisen, vereisen die op elke node
+
+---
+
+## Voorbeeldopzet
+
+De app-repository heeft een compleet startpunt in [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Service | Image | Rol |
+|---|---|---|
+| `db` | `mariadb:11` | De database, met een gebruiker die alleen rechten heeft op het schema `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, achter de load balancer |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: de tweede wacht en neemt het over |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Draait de playbooks met `RTE_MODE=inbound` en `RTE_FILES=local`: de app belt haar |
+| `lb` | `nginx:stable` | Handelt HTTPS af op poort 8443 en verdeelt de browsers over de app-nodes met `ip_hash` |
+
+De runner `rte` van de RTE en de referentie waarmee hij zich aanmeldt (zijn adres `http://rte:8000` en `RTE_TOKEN`) worden gedeclareerd in de
+[configuratie-seed](../seed/) `seed.yaml`, die de worker bij elke start toepast; de RTE stelt geen `RTE_URL` in en wordt niet op de host gepubliceerd.
+
+De app-nodes en de workers delen één `.env`, met de databasegebruiker, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` achter de load balancer en een `LOG_PATH` buiten het gedeelde volume. De RTE heeft geen `env_file`: hij krijgt
+alleen `RTE_TOKEN` uit `compose.yaml`, dus hij bevat geen databasewachtwoord. De app-nodes, de workers en de RTE koppelen dezelfde
+persistente en ssh-volumes:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/nl/_configure/rte/another-datacenter.md b/i18n/nl/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..d3c142f
--- /dev/null
+++ b/i18n/nl/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Een ander datacenter
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Een RTE in een ander datacenter
+{: .no_toc }
+
+Van een kale host in een tweede datacenter tot een uitgaande RTE die haar eerste playbook draait
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Voor beheerders: wanneer de beheerde hosts van een tweede datacenter vanuit een RTE in dat datacenter moeten worden bereikt, niet vanuit het eerste.
+
+{: .note }
+> **De makkelijke weg.** Het [installatieprogramma](../installation/installer.html#a-runner) voert elke stap hieronder met één opdracht uit op de RTE-host:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, met `--join afj_...` om haar meteen te laten goedkeuren.
+> Dit runbook doet hetzelfde met de hand, met Docker of Podman, zodat je elk onderdeel kunt zien en aanpassen.
+
+---
+
+## Waar je mee eindigt
+
+De app, de worker en de database blijven waar ze zijn, in datacenter 1. Datacenter 2 krijgt een host die één RTE-container in
+uitgaande modus draait ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), zie [Modi](modes.html#outbound)): ze belt de app via
+HTTPS en houdt één WebSocket open, wordt lid als eigen runner, en draait de playbooks van de formulieren die haar noemen tegen de beheerde
+hosts van datacenter 2.
+
+| Waar | Wat daar draait | Praat met |
+|---|---|---|
+| Datacenter 1 | De app-nodes, de worker, de database (zoals nu) | Niets nieuws: het neemt de socket van de RTE aan op zijn gebruikelijke HTTPS-adres |
+| Datacenter 2, de RTE-host | Docker of Podman, en de RTE-container | De app op `APP_URL` via HTTPS, en de beheerde hosts van datacenter 2 |
+
+De RTE bevat geen databasereferenties en geen `ENCRYPTION_SECRET`, alleen een eigen token. Niets maakt er verbinding mee, dus ze heeft geen open
+poort, geen DNS-naam en geen certificaat nodig. De app stuurt de playbooks en de inventories met elke job mee (`RTE_FILES=transfer`, de
+standaard), dus de RTE heeft er geen kopie van nodig en geen gedeelde schijf.
+
+Elke opdracht hieronder draait in een terminal op de RTE-host, als een gebruiker met `sudo`, tenzij anders vermeld. Het duurt ongeveer 20 minuten,
+waarvan het meeste wachten op de image.
+
+---
+
+## 0. Voordat je begint
+
+Verzamel het volgende:
+
+| Wat | Waar het vandaan komt |
+|---|---|
+| Het adres van de app | `APP_URL`: het adres dat mensen in een browser openen, zoals `https://forms.example.com`, met het basispad als dat er is |
+| Het certificaat van de app | Ondertekend door een publieke CA, een private CA (je hebt het certificaat ervan nodig, stap 6), of zelfondertekend |
+| Een proxy | De `HTTPS_PROXY` die dit datacenter gebruikt om datacenter 1 te bereiken, als die er is |
+| De naam van de RTE | De naam van haar runner onder **Verbindingen > Runners**, die formulieren noemen met `runner:`, zoals `rte-dc2`: letters, cijfers en `_ . : @ -` |
+| Een jointoken | Optioneel: een [jointoken](../runners/registration.html#join-tokens) (`afj_...`) keurt de RTE meteen goed. Zonder jointoken keurt een admin haar goed (stap 8) |
+| De ssh-sleutel | De privésleutel die de playbooks gebruiken om de beheerde hosts te bereiken, of het recht om er een aan te maken |
+
+De app moet 7.3.0 of later draaien. Om een jointoken voor deze ene RTE te maken, roept een admin de API één keer aan (zie
+[Jointokens](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. De host voorbereiden
+
+De RTE is een container, dus de host heeft een container-engine nodig en verder niets: Node.js, python en ansible zitten in de image.
+
+| Nodig | Waarom |
+|---|---|
+| Linux op **x86_64** (amd64) | De RTE-images worden alleen voor amd64 gepubliceerd |
+| 2 CPU's en 4 GB geheugen, of meer | Eén RTE draait tot [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks tegelijk (10), elk met zijn forks: dimensioneer haar daarvoor |
+| 20 GB vrije schijfruimte | De image `-rte-full` is ongeveer 3,3 GB, plus een image tijdens updates, de jobbestanden die de app stuurt en de tijdelijke bestanden van de jobs |
+| Docker, of Podman met podman-compose | Om de image te pullen en te draaien |
+| De tijd ingesteld via NTP | De tijden van de jobs worden met die van de app vergeleken |
+
+**Docker**, op Ubuntu of Debian (andere distributies: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, op RHEL, Rocky of Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Schrijf met Podman in elke opdracht hieronder `podman` voor `docker` en `podman-compose` voor `docker compose`.
+
+---
+
+## 2. Netwerk en firewall
+
+De RTE opent elke verbinding zelf. Niets bereikt haar van buitenaf:
+
+| Van | Naar | Poort | Waarom |
+|---|---|---|---|
+| De RTE-host | De app, op `APP_URL` (via `HTTPS_PROXY` als die is ingesteld) | De poort van de app, `443` achter de meeste proxy's | De socket waarover de jobs, hun bestanden en hun uitvoer gaan |
+| De RTE-host | De beheerde hosts van datacenter 2 | ssh (`22`), WinRM, hun API's | De playbooks draaien vanaf hier |
+| De RTE-host | `ghcr.io` | `443` | Om de image te pullen, tenzij die uit je eigen registry of een bestand komt (stap 4) |
+
+Open geen inkomende poort voor de RTE. Haar `PORT` (`8000`) bedient alleen `/live`, `/ready` en `/metrics`, voor de probes op deze host.
+
+De RTE belt `APP_URL` met `/api/v2/rte/socket` erachter, als WebSocket. Een reverse proxy voor de app moet de upgrade voor
+dat pad doorgeven (zie [Runner-WebSockets](../production/reverse-proxy.html#runner-websockets)). Controleer vanaf hier of de app antwoordt:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Mappen
+
+Alles staat onder `/opt/af-rte`. De RTE draait als de gebruiker `node` (uid 1000), dus haar gegevens horen bij die uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Map | In de container | Bevat |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | De spool (`rte-spool`: de uitvoer en het einde van elke job tot de app ze heeft opgeslagen), de jobbestanden die de app stuurde (`rte-files`), een private CA, de python-bibliotheken die een playbook installeert |
+| `data/ssh/` | `/home/node/.ssh` | De ssh-sleutel en `known_hosts` van de playbooks |
+| `data/ansible/` | `/etc/ansible/...` | Een eigen `ansible.cfg`, rollen en collecties, gekoppeld in plaats van ingebouwd |
+
+Houd `data/` op de host: een herstarte RTE verstuurt dan nog wat de app nog niet had opgeslagen, en behoudt haar cache van jobbestanden.
+
+**ssh-sleutel.** Kopieer de sleutel die de playbooks in datacenter 1 gebruiken, of maak er een voor dit datacenter en geef de publieke helft aan de beheerde hosts:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Geef daarna alles aan uid 1000, met de sleutel alleen leesbaar voor de eigenaar:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. De image
+
+Kies een van de twee.
+
+### Optie A: de officiële image
+{: .no_toc }
+
+De gepubliceerde images staan in de GitHub Container Registry, openbaar, zonder aanmelding (zie [Images](images.html) voor de drie lagen).
+Neem dezelfde laag als in datacenter 1. `:7` volgt de nieuwste release van 7, zoals de `:7` van de app:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Een host zonder internettoegang haalt de image van een host die dat wel heeft:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Of push haar één keer naar je eigen registry (`docker tag` en `docker push`), en gebruik die naam in de volgende stappen.
+
+### Optie B: je eigen image
+{: .no_toc }
+
+Als de playbooks van datacenter 2 collecties of python-bibliotheken nodig hebben die de officiële image mist (bijvoorbeeld die van VMware voor de vCenter van dit
+datacenter), bouw dan op `ansibleforms-rte-core`:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Bouw haar opnieuw bij elke nieuwe release van de app (zie [Je eigen RTE bouwen](images.html#build-your-own-rte)). Bouw met meerdere RTE-hosts
+één keer en push naar je eigen registry. Offline doe je `docker save` en `docker load` met de gebouwde image zoals in optie A.
+
+---
+
+## 5. Instellingen
+
+Een nieuw eigen [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), minstens 16 tekens. Het is het wachtwoord van deze RTE: de app
+bewaart het in de RTE-referentie van de runner, en verzegelt er de geheimen van elke job mee.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variabele | Betekenis |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: de RTE belt de app. Zonder deze variabele start de RTE in de verouderde databasemodus |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Het adres van de app, `http://` of `https://`, met het basispad als dat er is |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | De naam van haar runner. Niet ingesteld: haar node-id, `rte-<hostname>-<port>`, dat met de container verandert |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Haar eigen token, minstens 16 tekens. Bewaar het: de runner meldt zich er vanaf nu mee aan |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Optioneel: een jointoken, alleen gebruikt zolang haar runner nog niet bestaat of op goedkeuring wacht |
+
+Voeg deze toe als het netwerk ze nodig heeft:
+
+| Variabele | Wanneer |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | De RTE bereikt de app via een proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Een host die in `NO_PROXY` staat (kommagescheiden, `.example.com` voor een domein) wordt rechtstreeks gebeld |
+| `NODE_EXTRA_CA_CERTS` | Het certificaat van de app komt van een private CA: zet het certificaat van de CA in `/opt/af-rte/data/certificates/ca.pem` en stel `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` in |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` accepteert elk certificaat van de app, ook een zelfondertekend. Alleen binnen één vertrouwd netwerk: gebruik liever `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (standaard) krijgt de playbooks en inventories met elke job mee. Laat het zo, tenzij je ze zelf op de RTE koppelt (`local`) |
+
+De andere instellingen die een RTE leest, staan op [Een RTE draaien](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` en
+`RTE_DRAIN_SECONDS` kunnen later ook op haar runnerpagina worden ingesteld, wat voorgaat op de variabele (zie
+[De instellingen van een RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Haar starten
+
+Een compose-bestand houdt de hele definitie op één plek, naast de instellingen. Zet de image van stap 4 in `image:`:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker start haar na een herstart van de host opnieuw (`unless-stopped`). Podman heeft geen daemon die dat doet: schakel `podman-restart.service` in
+(`sudo systemctl enable --now podman-restart`), of draai de container als systemd-service met een Quadlet-bestand. Voeg op een host met SELinux
+in enforcing-modus `:Z` toe aan elk volume (`./data:/app/dist/persistent:Z`).
+
+Zonder compose, dezelfde container in één opdracht:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Controleren op de host
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+Het log toont hoe de RTE start, de app belt en verbinding maakt:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Zonder jointoken zegt nog een regel dat ze wacht:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Noteer de vingerafdruk.
+
+`/ready` antwoordt `503` met `not connected to the app` totdat de socket open is. De healthcheck zegt alleen dat het proces luistert.
+
+---
+
+## 8. Haar goedkeuren
+
+Zonder jointoken heeft de RTE gevraagd om lid te worden: **Verbindingen > Runners** toont een oranje melding boven de lijst,
+**1 Runner wacht op goedkeuring**. Open die, controleer dat de **Vingerafdruk** die uit het log van de RTE is en dat **Modus**
+Uitgaand zegt, en klik dan op **Goedkeuren** (zie [Een RTE goedkeuren](../runners/registration.html#approving-an-rte)). Alleen een admin keurt goed. Een aanvraag
+die niemand binnen 24 uur afhandelt, wordt verwijderd, en de RTE vraagt het opnieuw wanneer ze de app de volgende keer belt.
+
+Met een jointoken wordt de runner meteen goedgekeurd en noemt de beschrijving het jointoken. In beide gevallen bewaart de app het token van de RTE
+in een nieuwe RTE-referentie, `rte-dc2-rte`, en meldt de RTE zich vanaf dan aan met haar eigen `RTE_TOKEN`: `RTE_JOIN_TOKEN` wordt niet meer
+gebruikt, en je kunt het uit `rte.env` verwijderen.
+
+---
+
+## 9. Controleren in AnsibleForms
+
+1. **Verbindingen > Runners** toont de runner `rte-dc2`, type RTE. Zet **Kolommen > Verbinding** aan om **Verbonden** in de lijst te zien
+2. Open hem. Het tabblad **RTE** toont **Modus** Uitgaand en de badge **Verbinding** **Verbonden**; bij aanwijzen noemt die de app-node die
+   de socket vasthoudt, de release van de RTE en hoeveel van haar jobs draaien
+3. Klik op **Verbinding testen**: dat zegt **Runner connection is OK**. Het roept niets aan: het leest welke app-node de socket van de RTE vasthoudt
+   (`runner_leases`) en controleert het contract dat de RTE sprak toen ze verbinding maakte
+4. Geef hem een beschrijving, zoals *Datacenter 2*
+5. Laat **Standaard** aan bij de runner van datacenter 1, tenzij elk playbookformulier zonder `runner:` in datacenter 2 moet draaien
+
+De pagina **Status** toont de nieuwe RTE met haar versie, naast de andere.
+
+---
+
+## 10. Een eerste job
+
+Bewijs het hele pad met een playbook dat niets wijzigt. Voeg in de playbooks van de app (de playbookmap of -repository, zoals in
+datacenter 1) `ping-dc2.yaml` toe:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Voeg daarna in de designer een formulier toe dat de nieuwe runner noemt:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Start het. De app stuurt de playbookmap en de inventory met de job mee, en de RTE bewaart ze op hun hash, zodat een ongewijzigde
+map nooit twee keer wordt verstuurd. De uitvoer begint met `Running on RTE rte-dc2 (outbound)`, toont `pong` voor elke host, en de job
+eindigt met succes. Een map die groter is dan [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (standaard 512) wordt niet
+verstuurd: de job mislukt en zegt dat.
+
+---
+
+## 11. De formulieren ernaartoe sturen
+
+Een formulier draait op de RTE die het noemt, dus voeg dezelfde regel toe aan elk formulier voor datacenter 2:
+
+```yaml
+runner: rte-dc2
+```
+
+Zie [Runners](../runners.html) voor de standaardrunner en de andere typen runners.
+
+---
+
+## Als er iets misgaat
+
+De RTE schrijft naar `docker logs` vanaf `notice`. Een verbinding die mislukt voordat de socket opengaat (een DNS-naam, een geweigerde poort, een
+certificaat) verschijnt alleen als `RTE: dialing the app again in <n> seconds`, op `info`: stel
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) in `rte.env` in en herstart haar om
+`RTE: socket to wss://...: <the error>` te zien.
+
+| Wat je ziet | Waar | Wat te doen |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `RTE_TOKEN` ontbreekt of is te kort in `rte.env` |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Stel `APP_URL` in `rte.env` in |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` begint met `https://` (of `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | `RTE_MODE=outbound` ontbreekt in `rte.env` |
+| Geen regel `connected to the app`, `/ready` blijft `503` | `docker logs`, `/ready` | Het netwerk van stap 2: `curl` de app vanaf deze host, de proxy (`HTTPS_PROXY`, `NO_PROXY`), het certificaat van de app (`NODE_EXTRA_CA_CERTS`, stap 5). Stel `LOG_CONSOLE_LEVEL=debug` in om de fout te zien |
+| `the app refused the socket (404)` of een andere status dan 401, 403 en 409 | `docker logs` | Een reverse proxy geeft de WebSocket op `/api/v2/rte/socket` niet door, of `APP_URL` mist het basispad van de app |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Er bestaat een runner `rte-dc2` met een ander token. Geef de RTE dat token (het wachtwoord van de referentie van de runner), of verwijder de runner zodat ze vraagt om lid te worden |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Maak een nieuw jointoken, of verwijder `RTE_JOIN_TOKEN` en keur de RTE goed (stap 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | De RTE is opnieuw geïnstalleerd met een nieuw token: gebruik het token van de referentie van haar runner, of laat een admin het wijzigen |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Volgt op een weigering. Los de oorzaak op, en doe dan `docker restart af_rte_dc2` in plaats van te wachten |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Keur haar goed (stap 8). Ze is verbonden, maar krijgt tot dan geen job |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | De app en de RTE draaien releases van een ander [contract](images.html#the-contract): werk de RTE bij naar de release van de app (zie Bijwerken) |
+| **Niet verbonden**, of **Verbinding testen** zegt *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | De app | Geen enkele app-node houdt haar socket vast: de RTE is gestopt, of kan de app niet bereiken. Lees haar `docker logs` |
+| Een job wacht, en mislukt dan met *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | De uitvoer van de job | De RTE was niet verbonden terwijl de job wachtte |
+| `Permission denied` op de ssh-sleutel | De uitvoer van de job | De bestanden van `data/` moeten bij uid 1000 horen (stap 3) |
+| `UNREACHABLE` voor de beheerde hosts | De uitvoer van de job | ssh vanaf deze host: de sleutel, `known_hosts`, en de firewall naar de hosts |
+
+Aan de kant van de app verschijnt een geweigerde RTE in het log van de app als `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Bijwerken
+
+Als de app naar een nieuwe release gaat, volg die dan ook op deze host. Een RTE met hetzelfde contract blijft in de tussentijd werken; als een release
+het contract wijzigt, zeggen de release notes dat (zie [Het contract](images.html#the-contract)). Met `:7` in `compose.yml`, of in de
+`FROM` van je Dockerfile:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Werk haar bij als er geen playbook op draait: een stop wacht `RTE_DRAIN_SECONDS` (25) op de lopende playbooks, en de playbooks die dan nog draaien,
+eindigen als verlaten. Wat ze vóór de stop hebben afgedrukt, wordt in de spool bewaard en verstuurd zodra de RTE terug is. Doe offline eerst `docker load`
+met de nieuwe image (stap 4) vóór `docker compose up -d`.
+
+---
+
+## Terugdraaien
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+De socket sluit, en de runner toont meteen **Niet verbonden**: geen enkele app-node houdt zijn socket nog vast (`runner_leases`). Een host
+die verdwijnt zonder hem te sluiten, toont binnen ongeveer een minuut **Niet verbonden**, zodra de app-node niets meer op de socket hoort. De
+runner blijft: een runner die via een socket lid is geworden, wordt nooit vanzelf verwijderd. Verwijder hem onder **Verbindingen > Runners**, en zijn
+referentie `rte-dc2-rte` onder **Verbindingen > Inloggegevens**. Verwijder eerst de regel `runner:` uit de formulieren die hem noemden: tot
+dan wachten hun jobs op de RTE, tot `RTE_QUEUE_MINUTES`, en mislukken ze.
+
+---
+
+## Meer capaciteit in datacenter 2
+
+Herhaal stap 1 tot en met 9 op meer hosts van datacenter 2, elk met een eigen `RTE_NAME` en `RTE_TOKEN`, zoals `rte-dc2-b`: elk wordt lid als
+eigen runner en neemt tot [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks. Een formulier kiest er een met
+`runner:`. Twee RTE's met dezelfde `RTE_NAME` delen het werk niet: de tweede neemt de socket van de eerste over (zie
+[Meerdere RTE's](several.html#several-rtes)).
+
+---
+
+## Een RTE in databasemodus
+
+Vóór 7.3.0 zette dit runbook een RTE in databasemodus op: die bevatte de referenties van de database (`DB_*`, `ENCRYPTION_SECRET`), maakte via poort `3306`
+verbinding met de database van datacenter 1, en de app riep haar aan op haar poort `8000`. Die modus is sinds 7.3.0 verouderd en wordt
+in 8.0.0 verwijderd. Om zo'n RTE naar uitgaand te verplaatsen zonder nieuwe runner, stel je `RTE_MODE=outbound`, `APP_URL` en `RTE_NAME` (de naam van
+haar runner) erop in, behoud je haar `RTE_TOKEN`, en verwijder je `DB_*`, `ENCRYPTION_SECRET` en `RTE_REGISTER`: zie
+[Database (verouderd)](modes.html#database-deprecated). Sluit daarna poort `8000` en de databasepoort die ze niet meer nodig heeft.
diff --git a/i18n/nl/_configure/rte/images.md b/i18n/nl/_configure/rte/images.md
new file mode 100644
index 0000000..01b9ff5
--- /dev/null
+++ b/i18n/nl/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Images
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# RTE-images
+{: .no_toc }
+
+De drie gepubliceerde RTE-images, en een eigen RTE met de collecties en bibliotheken die je playbooks gebruiken
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De RTE-images
+
+De RTE wordt in drie lagen gepubliceerd, elk gebouwd op de vorige, met dezelfde tags als de app (zie [Image-tags](../installation/#image-tags)):
+
+| Image | Wat erin zit | Gebruik het |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js en de AnsibleForms-server, git, ssh en sshpass. Geen python en geen ansible, dus op zichzelf draait ze geen playbook | Om een RTE te bouwen met je eigen versies van python en ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | De base, plus python 3.14, ansible-core en een paar gangbare bibliotheken (`jmespath`, `netaddr`, `requests`, `paramiko`). Geen collecties | Om een kleinere RTE te bouwen met alleen de collecties en bibliotheken die je playbooks gebruiken |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | De core, plus het pakket `ansible` op dezelfde ansible-core, en wat de image van AnsibleForms 6.5 had: de collecties van NetApp, AWS en community, `pandas`, `pyvmomi`, `boto3`, de mariadb-client, ytt en een paar os-tools | **De standaard.** Draai haar zoals ze is: playbooks van 6.5 vinden wat ze gebruikten |
+
+Net als de app-image draait elke laag als de gebruiker `node` (uid 1000), en de playbooks draaien ook als die gebruiker.
+
+---
+
+## Je eigen RTE bouwen
+
+Bouw op `ansibleforms-rte-core` en voeg de collecties en python-bibliotheken toe die je playbooks gebruiken. Dit NetApp-voorbeeld is een van
+de Dockerfiles in [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+De python-omgeving en de map met collecties zijn van `node`, dus deze installaties hebben geen root nodig. Een laag die os-pakketten
+installeert, schakelt daarvoor over naar `USER root` en aan het einde terug naar `USER node`. Bouw op
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` in dezelfde map) om je eigen python en ansible mee te brengen.
+
+Houd de image op de release van de app: `:7` volgt de `:7` van de app. Collecties en rollen kunnen ook worden gekoppeld in plaats van ingebakken, op
+`/etc/ansible/collections` en `/etc/ansible/roles`. Dan is er per wijziging geen nieuwe build nodig, maar hangt wat er draait af van dat volume;
+python-bibliotheken gaan altijd in de image. Alles inbakken is reproduceerbaar en start snel, en is daarom de manier voor productie.
+
+---
+
+## Het contract
+
+Wat de app en een RTE moeten delen, is hun contract, een nummer dat beide melden. Een RTE van een oudere release blijft werken met een nieuwere
+app zolang beide hetzelfde contract spreken; als een release het wijzigt, zeggen de release notes dat RTE's moeten worden bijgewerkt. Elke modus
+heeft een eigen contract:
+
+| Modus | Contract | Bij een verschil |
+|---|---|---|
+| Uitgaand, Inkomend | 3, nieuw in 7.3.0 | De app sluit de socket van de RTE met de code `4409` en logt *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Een uitgaande RTE logt *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Een job die met een ander contract wordt gestuurd, wordt geweigerd |
+| Database (verouderd) | 2, sinds 7.0.0 | De RTE weigert de jobs van de app |
+
+**Verbinding testen** op de runner zegt welk contract de RTE spreekt en welk de app nodig heeft (zie
+[Verbinding testen](../runners/runner-page.html#test-connection)), en de rij **Runners** van de pagina **Status** voert dezelfde controle uit.
diff --git a/i18n/nl/_configure/rte/index.md b/i18n/nl/_configure/rte/index.md
new file mode 100644
index 0000000..dbdfa90
--- /dev/null
+++ b/i18n/nl/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Runtime-omgevingen (RTE)
+{: .no_toc }
+
+Wat een RTE is, hoe ze een playbook draait, en waar ze aan mag komen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: begrijp de RTE voordat je er een draait, haar dimensioneert of naar een ander netwerk verplaatst.
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Images](images.html) | De drie RTE-images, en je eigen image bouwen met de collecties die je playbooks gebruiken |
+| [Modi](modes.html) | Uitgaand, inkomend of database: wie de verbinding opent, de spool, de bestanden van de job |
+| [Een RTE draaien](run.html) | De instellingen van elke modus, en van elke een voorbeeld met `docker run` |
+| [Meerdere RTE's](several.html) | Capaciteit, replica's achter één adres, en wat er gebeurt als een RTE stopt of uitvalt |
+| [Een ander datacenter](another-datacenter.html) | Een runbook: een RTE toevoegen in een tweede datacenter, van een kale host tot de eerste job |
+
+---
+
+## Wat een RTE is
+
+AnsibleForms 7 draait geen playbook in de app-container. De job van een `ansible`-formulier wordt overgedragen aan een [runner](../runners.html) van het type
+`rte`, een runtime-omgeving: de AnsibleForms-server gestart met `AF_ROLE=rte`, naast python en ansible, zonder
+webinterface. Ze praat met de app over één WebSocket en bevat geen databasereferenties
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` of `inbound`, zie [Modi](modes.html)): de app stuurt haar de job,
+de RTE draait `ansible-playbook`, en de app slaat de uitvoer en de eindstatus op die ze terugstuurt, waar de browser ze leest.
+
+De app lost de referenties van de job op en geeft ze aan de RTE, verzegeld voor alleen die RTE en die job. De RTE leest nooit de
+tabel met referenties of een secret store, en een playbook erft de eigen omgevingsvariabelen van AnsibleForms niet
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` en de andere): geef zo'n waarde door als extravar of als referentie. De RTE van 7.0 tot en met 7.2,
+die zelf de database las en schreef, draait in 7.x nog als de verouderde databasemodus (zie [Databasemodus](#database-mode-deprecated)).
+
+---
+
+## Hoe de RTE draait
+
+De RTE is een container die je zelf draait, naast de app of in een ander netwerk: AnsibleForms maakt er nooit een aan. Hieronder zie je
+waar ze draait, wat ze met de app deelt, en wat er binnenin gebeurt vanaf het moment dat een formulier wordt gestart tot het proces van het playbook
+verdwenen is:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Hoe de RTE een playbook draait</title>
+<desc id="afr-desc">Op een containerhost of in een Kubernetes-cluster, beide beheerd door de operator, houden de app-container en een of meer RTE-containers elk één WebSocket tussen hen open, geopend door de app (inkomend) of door de RTE (uitgaand). Alleen de app praat met de database. 1: de browser start een formulier op de app. 2: de app slaat de job op in de database, kiest de runner en verzegelt de geheimen van de job ervoor. 3: de app stuurt de job over de socket. 4: de RTE claimt hem en haalt de bestanden van de job op, uit zijn cache of bij de app. 5: de RTE start ansible-playbook als kindproces, één per job, tot RTE_MAX_JOBS. 6: het playbook bereikt de beheerde hosts. 7: de RTE schrijft de uitvoer, de events en het einde naar zijn spool en stuurt ze over de socket; de app slaat ze op in de database en bevestigt ze. 8: de browser volgt de job via de app. Het volume van de app wordt alleen met RTE_FILES=local in de RTE gekoppeld.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Containerhost of Kubernetes-cluster</text>
+<text class="afr-s" x="181" y="61">door jou beheerd; een uitgaande RTE kan in een ander netwerk staan</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Browser</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">formulieren, jobpagina</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">App-container</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">webapp, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runners</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">verzegelen de geheimen</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">RTE-hub</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">slaat op, bevestigt dan</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">RTE-container</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">Jobbestanden</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">gecachet op hash</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">tot RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">bewaard tot bevestiging</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">één</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Beheerde hosts</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volume van de app</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbooks, inventories</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">alleen RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">alleen van de app</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+Het diagram toont één socket per RTE, welke kant hem ook opende: de app belt een inkomende RTE, een uitgaande RTE belt de app (zie
+[Modi](modes.html)). Zodra hij open is, gaan dezelfde berichten beide kanten op, en alleen de app leest en schrijft de database.
+
+**Wie haar start.** Een RTE is een langdraaiende container, gestart door wat je andere containers ook draait. Ze wacht op jobs en blijft
+tussendoor draaien:
+
+| Hoe je AnsibleForms draait | Wie de RTE start |
+|---|---|
+| `docker run` of `podman run` | Jij, met een opdracht zoals die in [Een RTE draaien](run.html), op elke host die de app bereikt, of die de app bereikt |
+| [Docker Compose](../installation/docker-compose.html) | De service `rte` van `docker-compose.yml`, naast `app` en `mysqldb`. De configuratie-seed declareert haar als de standaardrunner `rte`, inkomend, op `http://rte:8000` |
+| [Helm-chart](../installation/kubernetes.html) | Kubernetes, als tweede container met de naam `rte` in de pod van de app (`containers.rte`). De app belt haar op `127.0.0.1`, inkomend, en de seed van de chart declareert haar als de standaardrunner |
+| [Het installatieprogramma](../installation/installer.html) | Docker Compose of de Helm-chart zoals hierboven, of een systemd-service [zonder containers](../installation/native.html); een eigen Runner, die vraagt om lid te worden en wacht op de goedkeuring van een admin |
+
+De container-engine is van jou: Docker of Podman op de host, of de container-runtime van je Kubernetes-cluster, door jou geïnstalleerd en
+bijgehouden. AnsibleForms praat er nooit mee. Noch de app noch de RTE roept Docker of Podman aan, koppelt hun socket, of start een
+container: de app praat alleen met de RTE over haar socket.
+
+**Wat erin zit.** Eén container, met wat nodig is om een playbook te draaien en niets meer:
+
+* **De server** : dezelfde Node.js-server als de app, gestart met `AF_ROLE=rte` (ingesteld in de image) onder `tini`
+* **Weggelaten** : de webinterface, de aanmelding, de planner, de worker en elke databasemodule, die deze rol niet laadt
+* **Waarop ze luistert** : haar `PORT` (`8000`): `/live` en `/ready` voor probes en `/metrics` voor Prometheus, en bij inkomend de socket
+  die de app belt, `/rte/v1/socket`. Een uitgaande RTE neemt geen verbinding van de app aan
+* **Python en ansible** : meegebracht door de imagelaag die je kiest (zie [De RTE-images](images.html))
+* **De gebruiker** : de server en elk playbook draaien als `node` (uid 1000), nooit als root
+
+**Wat ze met de app deelt.** Haar token, en met `RTE_FILES=local` de bestanden van de app. Met `RTE_FILES=transfer`, de standaard, komen de
+playbooks en inventories met elke job mee, en heeft de RTE geen gedeelde schijf nodig:
+
+| Gedeeld met de app | Wat de RTE ermee doet |
+|---|---|
+| `RTE_TOKEN` | Presenteert het als ze de app belt (uitgaand), of controleert het als de app haar belt (inkomend). De app bewaart dezelfde waarde in de RTE-referentie van de runner, en de geheimen van de job worden ermee verzegeld |
+| Het persistente volume, `/app/dist/persistent`, alleen met `RTE_FILES=local` | De playbookmap ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)), of de playbookrepository die de worker onder [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) heeft gekloond, de inventories ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) en de inventoryrepositories) en de uploads. De RTE schrijft de extravars-bestanden van de job in de playbookmap, dus koppel die met lees- en schrijfrechten |
+| De ssh-map, `/home/node/.ssh` | De privésleutel en de `known_hosts` die de ssh-verbindingen van het playbook gebruiken: koppel die van de app, beheerd op de instellingenpagina's, of geef de RTE een eigen |
+
+De RTE kloont niets: een repository bereikt haar in de bestanden van een job, of op het volume dat ze met de app deelt. Collecties, rollen en
+`ansible.cfg` komen uit de image, uit de mappen `/etc/ansible/collections`, `/etc/ansible/roles` en `/etc/ansible/ansible.cfg` als
+je ze daar koppelt (het Docker Compose-project doet dat), of uit een `ansible.cfg` naast de playbooks.
+
+**Het leven van een job.** De nummers hieronder zijn de nummers in het diagram, voor een playbookformulier dat vanuit de browser of de API wordt gestart:
+
+1. **Starten** : de app controleert het formulier en zijn waarden, bouwt de extravars en slaat de job op met status `running`. Een formulier met een
+   [goedkeuring](../forms/approval.html) stopt hier totdat een goedkeurder het accepteert, en bereikt daarvoor geen RTE
+2. **De runner kiezen** : de app neemt de RTE die het formulier noemt met `runner: <name>`, anders de standaardrunner van het type RTE, en slaat de
+   naam ervan op de job op. Ze lost de referenties van de job op uit de database of een [secret store](../secret-stores/), de ansible-aanmelding en het
+   vault-wachtwoord, en verzegelt ze met AES-256-GCM onder een sleutel die is afgeleid van het token van die runner en het job-id
+3. **Overdracht** : de app-node die de socket van de RTE vasthoudt, stuurt haar de job: de extravars, de opties van het formulier, de verzegelde geheimen en
+   de hashes van de bestanden van de job. Elke app-node mag de job starten; degene die de socket vasthoudt, stuurt hem binnen twee seconden. Een volle RTE,
+   of een die niet verbonden is, laat de job wachten, tot [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Claimen** : de RTE antwoordt `claimed`, of `refused` als ze vol is, stopt, de geheimen niet kan openen, of de job met een ander
+   [contract](images.html#the-contract) komt dan het hare. Met `RTE_FILES=transfer` haalt ze de playbooks en de inventories op hun hash uit haar
+   cache, vraagt de app om een hash die ze niet heeft, en pakt ze uit in een eigen map van de job
+5. **Starten van het proces** : in de playbookmap (plus de `playbookSubPath` van het formulier, die moet bestaan) schrijft ze twee bestanden: `extravars_<id>.json`
+   met de waarden van het formulier en de referenties, en een verborgen bestand met de ansible-aanmelding. Daarna start ze `ansible-playbook` als haar eigen
+   kindproces, zonder shell, in een eigen procesgroep, met `-e @` die bestanden, één `-i` per inventory, en de tags, limit, check,
+   diff en verbosity van het formulier. Het vault-wachtwoord gaat via stdin naar binnen, nooit in een bestand of op de opdrachtregel, en het proces draait als
+   `node` met een gefilterde omgeving (zie hieronder)
+6. **Draaien** : het playbook maakt vanuit de RTE-container verbinding met de beheerde hosts, via ssh met de sleutel en de `known_hosts` van
+   `/home/node/.ssh`, met `sshpass` voor een aanmelding met wachtwoord, of via de API's die de modules aanroepen. De RTE, niet de app, moet ze kunnen bereiken
+7. **Uitvoer en einde** : de RTE bundelt stdout en stderr elke halve seconde of per 64 KB, met de referenties gemaskeerd, en nummert elke
+   bundel. Ze schrijft elk item naar de spool van de job op haar schijf voordat ze het verstuurt: de uitvoer, de events, het joblog van
+   `.joblogs/job_log_<id>.log` (elke 2 seconden), de start en het einde met de eindstatus (`success`, `failed` of `aborted`). De app
+   slaat elk item één keer op en bevestigt het, en de RTE gooit de spool weg zodra het einde is opgeslagen. Boven
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) bytes op een stream (standaard 50 MB) stuurt ze niets meer, en
+   gaat het playbook door. De app verstuurt dan de [meldingen](../forms/notifications.html) van het formulier
+8. **Volgen** : de browser praat nooit met de RTE: de formulierpagina leest de job elke 2 seconden opnieuw via de app, en de pagina Jobs
+   volgt hem live terwijl de app elk item opslaat
+
+**Een verbroken socket.** Het playbook gaat door. De RTE belt opnieuw (uitgaand), of een app-node belt haar opnieuw (inkomend), en stuurt opnieuw wat
+de app nog niet had bevestigd: de app slaat over wat ze al had opgeslagen, zodat geen regel verloren gaat of twee keer wordt opgeslagen. Dat geldt zolang de socket
+binnen twee minuten terug is: de app schrijft de heartbeat van de RTE alleen zolang haar socket open is, en zodra die heartbeat twee minuten
+oud is, beëindigt de worker de lopende jobs van de RTE als verlaten, ook als hun playbooks nog draaien. Houd de spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) op een volume, zodat een herstarte RTE nog verstuurt wat ze had bewaard. Een
+playbook dat draaide toen zijn RTE herstartte, kan niet doorgaan: de app beëindigt zijn job als verlaten wanneer de RTE zonder hem terugkomt.
+
+**Afbreken.** Een afbreking zet de afbreekvlag van de job, en de app-node die de socket van de RTE vasthoudt, stuurt binnen twee seconden `cancel`. De RTE
+stuurt `SIGTERM` naar de procesgroep van het playbook, zodat `ansible-playbook` en elke fork die het startte samen stoppen, en de job eindigt
+als `aborted`. Een cancel die vóór zijn job aankomt, wordt een minuut bewaard, en de job start dan afgebroken.
+
+**Opruimen.** Zodra het proces eindigt, wat de uitkomst ook is, verwijdert de RTE beide extravars-bestanden (een formulier met `keepExtravars`
+houdt het zichtbare, nooit het verborgen), het artifactsbestand in `/tmp`, het joblogbestand en de eigen map met bestanden van de job. Het
+einde wordt één keer opgeslagen: een tweede schrijver, zoals de app die een job laat mislukken die de RTE al had beëindigd, verandert niets.
+
+**Eén proces per job, niet één container per job.** AWX en AAP starten voor elke job een nieuwe pod of container vanuit een execution environment-image.
+AnsibleForms start niets: de RTE-container draait al, en elke job is een kindproces daarin. Een job start
+zonder een image te pullen of een pod te schedulen, en AnsibleForms heeft geen rechten op je container-engine of cluster nodig. Daar staat tegenover dat de
+playbooks die op één RTE draaien haar CPU, geheugen, `/tmp`, thuismap en python delen: geef de container genoeg resources voor
+`RTE_MAX_JOBS` playbooks met hun forks. Wijzig de image om te veranderen wat een playbook kan gebruiken, niet de job.
+
+---
+
+## De beveiligingsgrens
+
+De RTE draait code die formulierauteurs hebben geschreven, dus ze is gebouwd om zo weinig mogelijk te bevatten:
+
+* **Alleen haar token** : de RTE bevat geen databasereferenties en geen `ENCRYPTION_SECRET`. Ze neemt geen aanroep aan behalve de socket van de app, met
+  haar token, en heeft geen gebruikers, geen aanmelding en geen webpagina's. Over de socket kan ze alleen de jobs draaien die de app haar stuurt, erover rapporteren en
+  om hun bestanden vragen: ze kan geen job aanmaken, geen andere job lezen en geen referenties uitdelen
+* **Verzegelde geheimen** : om een job te draaien leest de RTE nooit de tabel met referenties of een secret store. Ze krijgt de geheimen van de jobs die ze
+  draait, verzegeld voor alleen haar token en dat job-id, zodat een bundel die voor een andere RTE of een andere job bedoeld is niet opengaat, en een gewijzigde byte
+  wordt geweigerd
+* **Een gecontroleerde verbinding** : bij uitgaand controleert de RTE het certificaat van de app. Bij inkomend via HTTPS pint de app het eigen certificaat van de RTE
+  wanneer die lid wordt, en belt haar alleen als ze dat certificaat presenteert (zie [Modi](modes.html#inbound)). Een inkomende RTE via gewone HTTP hoort
+  op een privénetwerk, zoals dat van het Docker Compose-project
+* **Geen overgeërfde omgeving** : `ansible-playbook` krijgt de omgeving van de RTE zonder elke variabele die AnsibleForms zelf leest
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, de `MYSQL_*`-variabelen en de andere), zodat
+  `lookup('env', ...)` ze niet kan bereiken. Wat je voor playbooks instelt (`PATH`, proxy's, `ANSIBLE_*`) gaat ongewijzigd door
+* **Geen templates van gebruikers** : {% raw %}een formulierwaarde die `{{`, `{%` of `{#` bevat, bereikt het playbook als een unsafe string{% endraw %}
+  die ansible nooit templatet, tenzij het formulier `allowJinjaInExtravars` instelt, en geen enkele shell draait ooit de opdrachtregel
+* **Niet root** : de RTE en haar playbooks draaien als `node` (uid 1000), dus een playbook kan doen wat die gebruiker in de container kan, zoals
+  haar bestanden en de ssh-sleutel lezen, en niets meer
+
+Behandel haar container, haar image en haar omgeving met dezelfde zorg als die van de app.
+
+---
+
+## Databasemodus (verouderd)
+
+De RTE van 7.0 tot en met 7.2, zonder `RTE_MODE`, draait door heel 7.x en wordt in 8.0.0 verwijderd. Ze verschilt op vier punten van de stappen hierboven:
+
+* **Ze heeft de database** : haar `DB_*`-instellingen, en `ENCRYPTION_SECRET` als ze zichzelf registreert
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **De overdracht is een HTTP-aanroep** : de app roept `POST <address>/rte/v1/jobs` aan met het token en de verzegelde geheimen, en de RTE claimt
+  de job door haar naam erop te schrijven in de database (stappen 3 en 4)
+* **Ze schrijft de uitvoer zelf** : in de database, in bundels, zonder spool (stap 7). Een afbreking bereikt haar via de afbreekvlag van de job,
+  die ze elke 2 seconden leest, en een aanroep `/cancel`
+* **Ze leest de bestanden van het volume van de app** : ze heeft dezelfde schijf nodig als de app, zoals bij `RTE_FILES=local`
+
+Haar runnerpagina heeft geen van de [RTE-instellingen](../runners/runner-page.html#an-rtes-settings): ze leest haar eigen variabelen. Zie
+[Modi](modes.html#database-deprecated) om haar naar een socketmodus te verplaatsen.
diff --git a/i18n/nl/_configure/rte/modes.md b/i18n/nl/_configure/rte/modes.md
new file mode 100644
index 0000000..9a987be
--- /dev/null
+++ b/i18n/nl/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modi
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Hoe een RTE met de app praat
+{: .no_toc }
+
+Uitgaand, inkomend of database: wie de verbinding opent, en wat erover gaat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: sinds 7.3.0 praat een RTE met de app over één WebSocket en bevat ze geen databasereferenties. Kies de modus
+die past bij het netwerk ertussen: wie een verbinding mag openen naar wie, en via welke proxy's en firewalls die loopt.
+
+---
+
+## De drie modi
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) op de RTE zegt hoe ze de app bereikt; haar runner heeft dezelfde **Modus**:
+
+| Modus | Wie de verbinding opent | Wat de RTE bevat | Voor |
+|---|---|---|---|
+| `outbound` | De RTE belt de app op [`APP_URL`](../customization/server.html#env_APP_URL) en houdt één WebSocket open | Haar `RTE_TOKEN`, geen databasereferenties | Een DMZ, NAT, of een zone die geen inkomende verbindingen toestaat: van buitenaf bereikt niets de RTE |
+| `inbound` | De app belt de RTE op het adres van haar runner en houdt één WebSocket open | Haar `RTE_TOKEN`, geen databasereferenties | Een netwerk waarin de centrale kant elke verbinding opent, een compose-project, een pod |
+| `database` (verouderd) | De app roept de API van de RTE via HTTP aan, en de RTE leest en schrijft zelf de database van de app | De referenties van de database (`DB_*`) en `ENCRYPTION_SECRET` | Het gedrag van 7.0 tot en met 7.2, verwijderd in 8.0.0 |
+
+Een RTE zonder `RTE_MODE` draait in heel 7.x in databasemodus, en logt bij het starten een waarschuwing `[DEPRECATED] This RTE runs in database mode`.
+Een runner die vóór 7.3.0 is toegevoegd, heeft de modus **Database (verouderd)**; stel hem in op de modus waarin zijn RTE draait wanneer je haar overzet.
+
+---
+
+## Uitgaand
+
+De RTE opent de verbinding, dus het werkt vanuit een netwerk dat helemaal geen inkomende verbinding accepteert:
+
+* **De socket** : de RTE belt `APP_URL` met `/api/v2/rte/socket` erachter, via `wss://` (`ws://` voor een `http://`-adres), met haar
+  `RTE_TOKEN` en de naam van haar runner, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Ze belt opnieuw als de socket wegvalt
+* **De eerste keer** : ze vraagt om lid te worden, en haar runner wacht op de goedkeuring van een admin onder **Verbindingen > Runners**, verbonden
+  maar zonder jobs (zie [Vragen om lid te worden](../runners/registration.html#asking-to-join)). Een jointoken,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), keurt haar meteen goed. Vanaf dan meldt ze zich aan met haar eigen token
+* **Het netwerk** : alleen van de zone van de RTE naar de app, op de poort van de app, via een proxy als `HTTPS_PROXY` dat zegt. Een reverse
+  proxy voor de app moet de WebSocket op dat pad doorlaten (zie [Runner-WebSockets](../production/reverse-proxy.html#runner-websockets))
+* **Het certificaat** : het certificaat van de app wordt gecontroleerd. Noem een private CA met `NODE_EXTRA_CA_CERTS`, of schakel, alleen binnen één vertrouwd
+  netwerk, de controle uit met [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **De runner** : die heeft geen adres nodig, dus zijn RTE-referentie bevat alleen het token
+* **Gereed** : `/ready` antwoordt `503` totdat de socket naar de app open is
+
+Met meerdere app-nodes achter een load balancer houdt de node die de RTE bereikt haar socket vast. Elke node mag een job starten: de node die
+de socket vasthoudt, stuurt hem naar de RTE, binnen twee seconden als de job op een andere node is gestart.
+
+---
+
+## Inkomend
+
+De RTE luistert op haar `PORT`, en de app belt haar op het adres van haar runner, met `/rte/v1/socket` erachter en het token van de RTE. Met
+meerdere app-nodes houdt er steeds één de socket van elke inkomende runner vast; als die node stopt, neemt een andere het over en belt opnieuw.
+
+De app heeft de runner van de RTE nodig voordat hij haar kan bellen: type RTE, modus **Inkomend**, en een RTE-referentie met het adres van de RTE en haar
+`RTE_TOKEN`. Die komt er op een van twee manieren:
+
+| Hoe | Wat in te stellen |
+|---|---|
+| De RTE vraagt om lid te worden | `APP_URL` en [`RTE_URL`](../customization/server.html#env_RTE_URL) (het adres dat de app belt). De RTE doet één aanroep, `POST /api/v2/rte/register`, en haar runner wacht op de goedkeuring van een admin: de app belt haar zodra ze is goedgekeurd (zie [Vragen om lid te worden](../runners/registration.html#asking-to-join)). Met `RTE_JOIN_TOKEN` is ze meteen goedgekeurd. Een inkomende RTE met `APP_URL` maar zonder `RTE_URL` weigert te starten |
+| Je voegt de runner toe | Geen `APP_URL`: voeg de runner toe onder **Verbindingen > Runners**, of in de [configuratie-seed](../seed/), zoals in [Een RTE draaien](run.html#start-it) |
+
+Het Docker Compose-project, de Helm-chart en de controller van het installatieprogramma draaien hun eigen RTE op deze manier, inkomend, gedeclareerd door de seed.
+
+**Via HTTPS.** Met [`HTTPS=1`](../customization/server.html#env_HTTPS) bedient de RTE haar socket via TLS, met de sleutel en het certificaat
+van [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) en [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(standaard `key.pem` en `cert.pem` in haar map `certificates`). Een RTE met een `RTE_URL` die met `https://` begint, stuurt dat certificaat mee wanneer ze
+vraagt om lid te worden, en de app pint het: hij belt de RTE alleen als ze hetzelfde certificaat presenteert, zodat een zelfondertekend certificaat werkt zonder CA.
+De RTE logt bij het starten de vingerafdruk van het certificaat (de eerste 8 hexadecimale cijfers van de SHA-256 van de DER-bytes, als `abcd-ef12`),
+en het goedkeuringsdialoogvenster toont de vingerafdruk die de app ontving: controleer dat ze overeenkomen voordat je haar goedkeurt.
+Het [installatieprogramma](../installation/installer.html#a-runner) zet zijn inkomende Runners zo op, met een certificaat van hun eigen adres.
+
+---
+
+## Database (verouderd)
+
+De RTE van 7.0 tot en met 7.2: de app roept haar API via HTTP aan, en de RTE claimt de job in de database, schrijft daar de uitvoer en houdt haar
+eigen runnerrij bij, met [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Databasemodus](./#database-mode-deprecated)
+zegt hoe haar stappen verschillen. Ze werkt nog in 7.x, met een waarschuwing bij elke start, en wordt in 8.0.0 verwijderd.
+
+Om zo'n RTE naar een socketmodus te verplaatsen, behoud je haar runner en haar token:
+
+1. Een runner van de [configuratie-seed](../seed/): stel daarvoor eerst `rte_mode: outbound` of `rte_mode: inbound` in de seed in (inkomend: met
+   het adres dat de app belt in de `url` van zijn referentie). De RTE kan een runner uit de seed niet zelf verplaatsen
+2. Stel op de RTE `RTE_MODE=outbound` in met `APP_URL`, of `RTE_MODE=inbound` (met `APP_URL` en `RTE_URL` om haar ene
+   registratieaanroep te doen), en stel [`RTE_NAME`](../customization/server.html#env_RTE_NAME) in op de naam die haar runner heeft onder
+   **Verbindingen > Runners**. Behoud haar `RTE_TOKEN`
+3. Verwijder `DB_*` en `ENCRYPTION_SECRET` uit haar omgeving, en `RTE_REGISTER`, dat alleen de databasemodus leest, en herstart haar daarna
+
+Wanneer de bijgewerkte RTE zich aanmeldt met de naam van de runner en het eigen token van de runner, verplaatst de app die runner meteen naar de modus van de RTE,
+zonder goedkeuring, en logt *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. De runner is dan geen rij meer die zijn RTE heeft geregistreerd, dus de worker verwijdert hem nooit als de oude container niet meer antwoordt. Een
+runner van de configuratie-seed die nog in databasemodus staat, wordt in plaats daarvan geweigerd, met *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. Gebruik hiervoor geen jointoken: een jointoken
+wordt geweigerd voor een runner die al is goedgekeurd. Een inkomende RTE zonder `APP_URL` doet geen aanroep: zet dan de **Modus** van haar runner op
+**Inkomend** onder **Verbindingen > Runners**, en de app belt haar. Het [installatieprogramma](../installation/installer.html#a-72-runner)
+werkt een Runner van 7.2 op deze manier bij.
+
+---
+
+## Wat er over de socket gaat
+
+In beide socketmodi stuurt de app de RTE elke job met alles wat de RTE vroeger in de database las, en slaat wat terugkomt,
+de uitvoer, de events, het joblog en het einde, precies één keer op. De app verstuurt ook de eindmeldingen.
+
+**De spool.** Elke uitvoerbundel, eventbundel, log, start en einde wordt genummerd en naar het spoolbestand van de job geschreven
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) voordat het wordt verstuurd, en bewaard tot de app zegt dat ze het heeft opgeslagen.
+Na een nieuwe verbinding, met dezelfde app-node of een andere, stuurt de RTE opnieuw wat niet was bevestigd, en de app slaat over wat ze al had
+opgeslagen: er gaat niets verloren, en niets wordt twee keer opgeslagen. Houd de spool op een volume, zodat een RTE die herstart nog verstuurt wat ze nog niet had
+afgeleverd. Een playbook dat draaide toen de RTE herstartte, kan niet doorgaan: zijn job eindigt als verlaten.
+
+**Capaciteit.** De RTE draait tot [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks tegelijk, of de waarde die
+op haar [runnerpagina](../runners/runner-page.html#an-rtes-settings) is ingesteld, en vertelt de app elke 20 seconden hoeveel er draaien. Een job voor een volle
+RTE wacht, zoals beschreven in [Meerdere RTE's](several.html#several-jobs-on-one-rte).
+
+**De bestanden van de job.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES), of de instelling **Jobbestanden** van haar runnerpagina, zegt
+waar de RTE de playbooks en de inventories vandaan haalt:
+
+| `RTE_FILES` | Waar de bestanden vandaan komen |
+|---|---|
+| `transfer` (standaard) | De app stuurt de playbookmap en de inventories met de job mee, elk ingepakt en genoemd naar een hash van de inhoud. De RTE bewaart ze ingepakt onder [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), de laatst gebruikte tot [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (standaard 1024 MB), en vraagt alleen om een hash die ze niet heeft: een ongewijzigde map wordt nooit twee keer verstuurd. De RTE heeft geen gedeelde schijf en geen toegang tot de repositories nodig |
+| `local` | De RTE draait vanuit haar eigen mappen, zoals een RTE in databasemodus: koppel de playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) en de repositories ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) erop |
+
+Met `transfer` pakt elke job zijn bestanden uit in een eigen privémap, die wordt verwijderd als de job eindigt: geen job ziet wat een andere
+schreef, en geen inventory- of extravars-bestand blijft uitgepakt op de schijf van de RTE staan. RTE's mogen één `RTE_CACHE_PATH` delen; elk houdt haar jobs in
+een eigen map, en de map van een RTE die is gestopt (midden in een job beëindigd, of opnieuw aangemaakt met een andere hostnaam) wordt door de andere
+na 10 minuten verwijderd. Een map die groter is dan [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (standaard 512, gelezen door
+de app, toegepast zonder herstart) wordt niet verstuurd: de job mislukt en zegt dat je de map in plaats daarvan op de RTE moet koppelen. De ssh-map wordt nooit verstuurd: de RTE houdt haar eigen
+privésleutel en `known_hosts` in `/home/node/.ssh`.
+
+**Hosts en taken.** Sinds 7.3.0 legt een RTE in elke modus de gestructureerde events van een playbook vast naast de tekstuitvoer: elke play, taak en
+hostresultaat, en de recap, geschreven door haar callback-plugin `af_events`. De jobpagina toont ze onder **Hosts en taken** (zie
+[Een job volgen](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Netwerk
+
+Wat je per modus moet openzetten tussen de app, de RTE en de beheerde hosts:
+
+| Modus | Van | Naar | Poort |
+|---|---|---|---|
+| Uitgaand | De RTE | De app, op `APP_URL` | De poort van de app (`443` achter de meeste proxy's) |
+| Inkomend | De app-nodes | De RTE, op het adres van haar runner | De `PORT` van de RTE (`8000`) |
+| Database (verouderd) | De RTE, en de app-nodes en de worker | De database, en de RTE | `3306`, en de `PORT` van de RTE |
+| Elke modus | De RTE | De beheerde hosts | ssh (`22`), WinRM, hun API's |
+
+In een socketmodus maakt de RTE nooit verbinding met de database. Haar API beantwoordt alleen de socket en de probes: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/nl/_configure/rte/run.md b/i18n/nl/_configure/rte/run.md
new file mode 100644
index 0000000..a1f1dd2
--- /dev/null
+++ b/i18n/nl/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Een RTE draaien
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Een RTE draaien
+{: .no_toc }
+
+De instellingen van elke modus, en hoe je een RTE start
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Instellingen
+
+Wat een RTE nodig heeft, hangt af van haar modus (zie [Modi](modes.html)). Elke RTE leest deze:
+
+| Variabele | Betekenis |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Sinds 7.3.0: `outbound` (ze belt de app), `inbound` (de app belt haar) of `database` (verouderd, de standaard in heel 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Het token tussen de app en de RTE, minstens 16 tekens; zonder token weigert de RTE te starten |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Hoeveel playbooks ze tegelijk draait, standaard `10` (`0` stelt geen limiet in). Een job voor een volle RTE wacht tot een playbook eindigt |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Bij een stop, hoe lang ze op haar lopende playbooks wacht, standaard `25`; de playbooks die dan nog draaien, eindigen als verlaten |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Gelezen door de app-nodes en de worker, niet door de RTE: hoe lang een job wacht op een volle of stoppende RTE, standaard `60` |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | De playbookmap en de uitvoerlimiet: gelezen door de RTE, dus stel ze in haar omgeving in |
+| `LISTEN_HOST` | Sinds 7.3.0: het adres waaraan haar listeners binden, standaard elke interface; `127.0.0.1` als niets haar van buitenaf belt (een uitgaande RTE) |
+
+Een RTE in een socketmodus, `outbound` of `inbound`, leest ook deze, en geen `DB_*` en geen `ENCRYPTION_SECRET`:
+
+| Variabele | Betekenis |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Het adres van de app zoals mensen hem openen, zoals `https://forms.example.com`. Uitgaand: het adres dat ze belt. Inkomend: het adres van haar ene registratieaanroep |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (standaard): het certificaat van de app moet geldig zijn. `0` accepteert elk certificaat, alleen binnen één vertrouwd netwerk |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | De naam van haar runner, die formulieren noemen met `runner:`. Niet ingesteld: haar node-id, `rte-<hostname>-<port>`, dat met de container verandert: stel het in productie in |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Optioneel, alleen de eerste keer: een jointoken, gemaakt via de API, dat haar runner meteen goedkeurt in plaats van op een admin te wachten (zie [Jointokens](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Inkomend, als ze vraagt om lid te worden: het adres dat de app belt, zoals `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (standaard): de app stuurt de playbooks en inventories met de job mee. `local`: ze draait vanuit haar eigen gekoppelde mappen |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Waar de uitvoer, de events en het einde van elke job wachten tot de app ze heeft opgeslagen, standaard `<persistent>/rte-spool`: houd het op een volume |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Met `transfer`: waar de mappen die de app stuurde worden bewaard, standaard `<persistent>/rte-files` |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Met `transfer`: hoeveel ruimte die mappen mogen innemen, standaard `1024`; de mappen die het langst geleden zijn gebruikt gaan eerst, en `0` bewaart er geen |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Gelezen door de app, niet door de RTE: de grootste map die ze met `transfer` verstuurt, standaard `512` |
+
+Op een RTE in een socketmodus kunnen `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` en `RTE_CACHE_MB` ook op haar runnerpagina worden ingesteld,
+onder het tabblad RTE: een waarde daar wint van de variabele, die dan alleen een leeg gelaten veld invult (zie
+[De instellingen van een RTE](../runners/runner-page.html#an-rtes-settings)). Een waarde buiten het bereik wordt op haar grens gebracht, en de RTE meldt dat
+bij het starten.
+
+Een RTE in databasemodus (verouderd) leest in plaats daarvan de database-instellingen, en registreert zichzelf:
+
+| Variabele | Betekenis |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | De eigen waarden van de app: de RTE leest haar jobs uit de database en schrijft hun uitvoer daarheen |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Het adres waarop de app de RTE aanroept, zoals `http://rte:8000`. De runner krijgt de naam van zijn host (`rte`), zodat formulieren `runner: rte` kunnen gebruiken |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Verouderd in 7.3.0, samen met de databasemodus: een RTE in socketmodus wordt in plaats daarvan lid met een jointoken. `1` (standaard): de RTE voegt zichzelf bij het starten toe onder **Verbindingen > Runners**, en de eerste wordt de standaardrunner. `0`: voeg haar daar zelf toe, of in de [configuratie-seed](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | De eigen waarde van de app, alleen nodig om zichzelf te registreren (het token van de runner wordt versleuteld opgeslagen); laat het weg met `RTE_REGISTER=0` |
+
+In databasemodus registreert de RTE zonder `RTE_URL` haar IP-adres en poort onder de naam `rte-<hostname>-<port>`, die veranderen wanneer
+de container opnieuw wordt aangemaakt: stel `RTE_URL` in productie in. De worker verwijdert een runner die de RTE zelf heeft geregistreerd 10 minuten na de
+laatste heartbeat van de RTE.
+
+---
+
+## Haar starten
+
+De RTE draait de playbooks, dus ze heeft haar ssh-map nodig, met de privésleutel en de `known_hosts` die de playbooks gebruiken, en een persistente
+map voor haar spool en de bestanden die de app stuurt. Kies de modus:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Uitgaand</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Inkomend</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Database (verouderd)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Start de RTE op elke host die de app bereikt, met haar eigen token en de naam die haar runner krijgt:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Ze belt de app en vraagt om lid te worden: **Verbindingen > Runners** toont de runner `rte-dmz` als wachtend op goedkeuring, en haar log toont
+de vingerafdruk van haar token. Controleer dat de beoordeling dezelfde vingerafdruk toont, en klik dan op **Goedkeuren** (zie
+[Een RTE goedkeuren](../runners/registration.html#approving-an-rte)): vanaf dan krijgt ze jobs, en meldt ze zich aan met haar eigen `RTE_TOKEN`.
+Voeg voor een onbeheerde start `-e RTE_JOIN_TOKEN=<a join token, afj_...>` toe, dat haar meteen goedkeurt. Niets hoeft deze
+host te bereiken: publiceer geen poort. Alleen `/live`, `/ready` en `/metrics` luisteren op haar `PORT`, voor de probes.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Start de RTE waar de app haar bereikt. Deze draait naast de app en draait de playbooks vanuit haar mappen (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Geef de app daarna haar runner: in de [configuratie-seed](../seed/), een RTE-referentie en een inkomende runner die zich ermee aanmeldt:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Of voeg dezelfde twee met de hand toe: de referentie onder **Verbindingen > Inloggegevens**, type RTE, en de runner onder
+**Verbindingen > Runners**, type RTE, modus **Inkomend**, met die referentie. Om de RTE in plaats daarvan te laten vragen om lid te worden, start je haar met
+`APP_URL` en `RTE_URL`, en keur je haar goed onder **Verbindingen > Runners** (zie [Inkomend](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Verouderd sinds 7.3.0 en verwijderd in 8.0.0. De RTE draait de playbooks vanaf haar eigen schijf, dus koppel ook het persistente volume van de app
+(playbooks, repositories, uploads) en zijn ssh-map erop. Een Docker-voorbeeld, met de app bereikbaar als `ansibleforms` op
+hetzelfde netwerk:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Houd een inkomende RTE buiten het openbare netwerk: haar socket antwoordt iedereen die het token heeft. `docker stop` wacht maar 10 seconden voordat
+het een container afschiet, dus geef de RTE een langere stoptime-out (`--stop-timeout`, of `stop_grace_period` in compose) of verlaag
+`RTE_DRAIN_SECONDS`. Kubernetes wacht standaard 30 seconden.
+
+Het [installatieprogramma](../installation/installer.html) zet een uitgaande of inkomende RTE op een eigen server op, met Docker, Podman of
+[zonder containers](../installation/native.html), en drukt de vingerafdruk af waarmee je haar goedkeurt. Volg [Een ander datacenter](another-datacenter.html)
+om een RTE met de hand in een ander datacenter te draaien.
diff --git a/i18n/nl/_configure/rte/several.md b/i18n/nl/_configure/rte/several.md
new file mode 100644
index 0000000..d4cf1e9
--- /dev/null
+++ b/i18n/nl/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Meerdere RTE's
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Meerdere RTE's
+{: .no_toc }
+
+Hoeveel playbooks één RTE draait, meer RTE's als runners of replica's, en wat er gebeurt als er een stopt of uitvalt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Meerdere jobs op één RTE
+
+Eén RTE draait tot [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks naast elkaar, standaard
+10 (`0` stelt geen limiet in). Een job voor een volle RTE wordt niet geclaimd. In een socketmodus verstuurt de app hem niet zolang het laatste
+gezondheidsrapport van de RTE geen vrije plek toont, en een RTE die vol is of stopt, antwoordt `refused` als bezet; in databasemodus antwoordt de RTE
+`503`. In beide gevallen schrijft de app één keer `Waiting for a free slot on RTE <name>` in de uitvoer en biedt de job elke 10 seconden opnieuw aan,
+maximaal [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) lang (standaard 60). Daarna mislukt de job met
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Een job die tijdens het wachten wordt afgebroken, eindigt als `aborted` zonder ooit
+de RTE te bereiken.
+
+---
+
+## Meerdere RTE's
+
+De app verdeelt jobs niet zelf over runners: elke job gaat naar één runner, degene die het formulier noemt of de
+standaard. Meer RTE-containers helpen op twee manieren:
+
+* **Als eigen runners** : elke RTE heeft een eigen `RTE_NAME` en wordt lid als eigen runner: ze vraagt om lid te worden en een admin
+  keurt haar goed, of ze presenteert een jointoken (zie [Registratie](../runners/registration.html)). Een formulier kiest er een met `runner: <name>`,
+  bijvoorbeeld een RTE met de VMware-collecties, of een in een andere netwerkzone; de andere draaien op de standaard-RTE
+* **Als replica's achter één adres** (alleen databasemodus) : meerdere RTE-containers met dezelfde `RTE_URL` en hetzelfde `RTE_TOKEN`,
+  zoals de pods achter een Kubernetes Service, delen één runner, en het adres verdeelt de aanroepen over ze. Een volle replica antwoordt
+  `503`, en de volgende poging kan op een andere uitkomen. De app volgt een job via de database, dus het maakt niet uit welke replica
+  zijn statusaanroepen beantwoordt
+
+In een socketmodus (zie [Modi](modes.html)) houdt een runner één socket naar één RTE vast, en een tweede RTE die zich met dezelfde
+`RTE_NAME` aanmeldt, neemt de socket van de eerste over. Geef elke RTE een eigen naam en een eigen runner, en laat formulieren met
+`runner:` tussen ze kiezen.
+
+Elke RTE in databasemodus schrijft elke 10 seconden een heartbeat in de database, en een RTE die zichzelf registreert, controleert haar runnerrij elke
+30 seconden. Voor een RTE in een socketmodus schrijft de app-node die haar socket vasthoudt de heartbeat elke 20 seconden voor haar, zolang de
+socket open is. De pagina **Status** toont elke RTE met haar versie. De worker verwijdert een runner die een RTE in databasemodus zelf heeft geregistreerd
+zodra die RTE 10 minuten lang geen heartbeat heeft geschreven, en als de standaardrunner zo'n rij is waarvan de RTE is gestopt, neemt de volgende RTE
+die controleert de standaard over. Een runner uit de configuratie-seed, met de hand toegevoegd of via een socket lid geworden, wordt nooit op die manier verwijderd.
+
+---
+
+## Als een RTE stopt of uitvalt
+
+**Als een RTE stopt.** Bij `SIGTERM` (`docker stop`, een rolling update, een scale down) neemt de RTE geen jobs meer aan: `/ready` antwoordt `503`,
+en een nieuwe job wordt geweigerd als bezet (`503` in databasemodus), dus de app wacht, of in databasemodus stuurt het adres hem naar een andere
+replica. De lopende playbooks krijgen [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) om af te ronden, standaard 25,
+daarna sluit de RTE af.
+
+**Als een RTE uitvalt.** Een afgeschoten container (geheugen vol, een verloren node, het einde van de stoptime-out) neemt zijn playbooks mee: niets
+verplaatst ze naar een andere RTE, en niets draait ze opnieuw. Hun jobs worden beëindigd als `abandoned`, door de RTE zelf of door de app wanneer ze
+terugkomt onder hetzelfde id, dat een herstarte container behoudt (`rte-<hostname>-<port>`), of door de worker, zodra de heartbeat van de RTE
+twee minuten oud is. Controleer op de beheerde hosts wat het playbook deed voordat je het opnieuw start.
+
+**Terwijl een RTE onbereikbaar is.** In een socketmodus wacht een nieuwe job voor haar op haar socket, tot `RTE_QUEUE_MINUTES` plus nog een minuut, en
+mislukt dan met *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+In databasemodus mislukt hij meteen met *the RTE at ... is unreachable*, tenzij een andere replica op haar adres antwoordt.
diff --git a/i18n/nl/_configure/runners.md b/i18n/nl/_configure/runners.md
new file mode 100644
index 0000000..88a59d0
--- /dev/null
+++ b/i18n/nl/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Runners
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runners
+{: .no_toc }
+
+Waar jobs draaien: containers met een runtime-omgeving voor playbooks, en AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins voor templates
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: voeg de runners toe waarop je jobs draaien, kies de standaard van elk type, keur de RTE's goed die vragen om lid te worden, en test ze.
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [De pagina Runners](runners/list.html) | De lijst met runners, er een toevoegen, er een in- of uitschakelen, en de standaard van elk type |
+| [Typen runners](runners/types.html) | De producten die een runner kan zijn, hun adres en aanmelding |
+| [Registratie](runners/registration.html) | Hoe een RTE vraagt om lid te worden en wordt goedgekeurd, jointokens voor onbeheerde installaties, en databasemodus |
+| [De pagina van een runner](runners/runner-page.html) | De tabbladen van een runner, de modus en verbinding van een RTE, en Verbinding testen |
+| [Wie runners beheert](runners/permissions.html) | Wie runners mag toevoegen, wijzigen en testen |
+
+
+---
+
+## Hoe het werkt
+
+Sinds versie 7 draait de app zelf niets: elke job draait op een **runner**, toegevoegd onder **Verbindingen > Runners**.
+Het type van een formulier bepaalt welk type runner het nodig heeft:
+
+| Formuliertype | Draait op een runner van het type | Wat er draait |
+|---|---|---|
+| `ansible` | RTE | Een playbook, in een container met een runtime-omgeving |
+| `awx`, `aap`, `ascender` | AWX (de varianten AWX, AAP en Ascender) | Een job- of workflowtemplate |
+| `semaphore` | Semaphore | Een template van Semaphore UI |
+| `rundeck` | Rundeck | Een Rundeck-job |
+| `jenkins` | Jenkins | Een Jenkins-job |
+
+Een formulier van het type `workflow` of `subform` heeft geen eigen runner: elke node van een [workflow](workflows/) kiest zijn eigen runner. Een node
+met een `runner:` draait op die runner (een RTE, of een template of job op AWX, Semaphore, Rundeck of Jenkins), elke andere op
+de standaard-RTE, zodat de nodes van één job op verschillende runners kunnen draaien. Het formulier `multistep`, verouderd sinds 7 en
+vervangen door workflows, werkt op dezelfde manier: elk van zijn stappen draait op de runner die het eigen type nodig heeft.
+
+Een formulier kiest zijn runner op een van twee manieren:
+
+- **Op naam**: `runner: <name>` op het formulier, op een workflownode, of op een stap van een verouderd multistep-formulier (ook in de
+  formulierinstellingen van de designer). De runner moet van het type zijn dat het formulier nodig heeft, anders mislukt de job. Het oudere `awx: <name>`
+  werkt nog, logt een waarschuwing over veroudering, en verdwijnt in 8.
+- **Als standaard**: een formulier dat geen runner noemt, draait op de standaardrunner van zijn type. Zonder standaardrunner mislukt de job
+  met een bericht dat zegt welk type runner je moet toevoegen.
+
+Een runner die onder **Verbindingen > Runners** is uitgeschakeld, krijgt geen job, niet op naam en niet als standaard: de job mislukt en zegt dat je hem moet inschakelen
+of een andere runner moet noemen (zie [Standaard en Ingeschakeld](runners/list.html#default-and-enabled)).
+
diff --git a/i18n/nl/_configure/runners/list.md b/i18n/nl/_configure/runners/list.md
new file mode 100644
index 0000000..f24699e
--- /dev/null
+++ b/i18n/nl/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: De pagina Runners
+parent: Runners
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# De pagina Runners
+{: .no_toc }
+
+De lijst met runners, er een toevoegen, er een in- of uitschakelen, en de standaard van elk type
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De lijst
+
+De pagina onder **Verbindingen > Runners** toont elke runner met deze kolommen:
+
+| Kolom | Betekenis |
+|---|---|
+| Ingeschakeld | Of hij jobs aanneemt. Een uitgeschakelde runner krijgt geen job, ook niet als standaard van zijn type. |
+| Naam | Hoe formulieren ernaar verwijzen, met `runner: <name>`. |
+| Type | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck of Jenkins. De standaardrunner van zijn type heeft een pilletje **Standaard** erachter. |
+| Beschrijving | Waarvoor hij dient. |
+
+**Kolommen** voegt er nog twee toe, standaard uit: **Modus**, de modus van een RTE (Uitgaand, Inkomend of Database (verouderd), zie
+[Modi](../rte/modes.html)), en **Verbinding**, of een app-node een socket naar een RTE in een socketmodus vasthoudt: **Verbonden** of
+**Niet verbonden**.
+
+Vanaf 7.3.0 staan de runners die op goedkeuring wachten niet in de lijst maar in een melding erboven, zie [Een RTE goedkeuren](registration.html#approving-an-rte).
+**Runner toevoegen** opent een dialoogvenster in stappen: **Runner** (naam en beschrijving), **Type** en **Referenties**, met voor een RTE een stap **Modus** na
+**Type** (Uitgaand, de standaard voor een nieuwe, Inkomend of Database (verouderd)): vier stappen voor een RTE, drie voor de
+andere. In de stap **Type** heeft elk product een hint: die van de RTE geeft de volledige naam, *Runtime-omgeving*. Een rij opent de eigen
+pagina van de runner, en het menu ervan biedt:
+
+| Actie | Wat ze doet |
+|---|---|
+| Bewerken | Opent de pagina |
+| Verbinding testen | Controleert of hij antwoordt en zijn referentie accepteert, zie [Verbinding testen](runner-page.html#test-connection) |
+| Inschakelen, Uitschakelen | Schakelt hem in of uit, wat hij nog niet is |
+| Referenties wijzigen | Opent het tabblad Referenties van de pagina |
+| Verwijderen | Verwijdert hem |
+
+---
+
+## Standaard en Ingeschakeld
+
+De standaard van elk type is waar de formulieren van dat type draaien als ze geen runner noemen:
+
+| Standaard voor | Waar deze formulieren draaien als ze geen runner noemen |
+|---|---|
+| Playbookformulieren | `ansible`-formulieren, op een RTE |
+| AWX-, AAP- en Ascender-formulieren | `awx`-, `aap`- en `ascender`-formulieren, op een AWX-runner |
+| Semaphore-formulieren | `semaphore`-formulieren |
+| Rundeck-formulieren | `rundeck`-formulieren |
+| Jenkins-formulieren | `jenkins`-formulieren |
+
+De eerste runner van een type wordt de standaard, dus voor één runner per type is geen extra stap nodig. Om een andere runner de standaard te maken,
+zet je de schakelaar **Standaard** op zijn pagina aan (zie [De pagina van een runner](runner-page.html)).
+
+Een uitgeschakelde runner blijft met zijn instellingen in de lijst staan, maar er gaat geen job naartoe, ook niet als standaard van zijn type. Een job voor hem mislukt met
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Schakel hem in of uit met **Inschakelen** of **Uitschakelen** in het menu van zijn rij, of met de schakelaar **Ingeschakeld** op zijn pagina. Een nieuwe runner staat aan, en de
+runners die vóór 7.3.0 bestonden, staan na de upgrade aan. De [configuratie-seed](../seed/example.html) kan er een uitschakelen met
+`enabled: false`.
diff --git a/i18n/nl/_configure/runners/permissions.md b/i18n/nl/_configure/runners/permissions.md
new file mode 100644
index 0000000..4d0e8d8
--- /dev/null
+++ b/i18n/nl/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Wie runners beheert
+parent: Runners
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Wie runners beheert
+{: .no_toc }
+
+Wie runners mag toevoegen, wijzigen en testen
+{: .fs-6 .fw-300 }
+
+Een runner ontvangt de referenties van elke job die hij draait, dus alleen de rol **admin** voegt runners toe, wijzigt ze, schakelt ze in of uit en verwijdert ze,
+en keurt een RTE die vroeg om lid te worden goed of wijst hem af. Gebruikers met toegang tot de instellingen zien ze en kunnen ze testen, maar niet wijzigen.
+
+Een runner die in de [configuratie-seed](../seed/) is gedeclareerd, is op deze pagina alleen-lezen: wijzig hem dan in het seedbestand.
diff --git a/i18n/nl/_configure/runners/registration.md b/i18n/nl/_configure/runners/registration.md
new file mode 100644
index 0000000..93addb4
--- /dev/null
+++ b/i18n/nl/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Registratie
+parent: Runners
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Registratie
+{: .no_toc }
+
+Hoe een RTE vraagt om lid te worden en wordt goedgekeurd, jointokens voor onbeheerde installaties, en databasemodus
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Vragen om lid te worden
+
+Sinds 7.3.0 vraagt een RTE in een socketmodus (`outbound` of `inbound`) die de app nog niet kent om lid te worden, en keurt een admin hem goed.
+Hij meldt zich met zijn eigen `RTE_TOKEN` en zijn `RTE_NAME`: een uitgaande RTE wanneer hij de app voor het eerst belt, een inkomende in zijn ene
+registratieaanroep. Zonder jointoken doet de app dan het volgende:
+
+1. Ze slaat het `RTE_TOKEN` van de RTE op in een nieuwe referentie van het type RTE met de naam `<name>-rte` (met een nummer erbij als die naam bezet is), en
+   voor een inkomende RTE ook zijn adres, `RTE_URL`
+2. Ze voegt een runner toe met de naam uit `RTE_NAME`, type RTE, in de modus van de RTE, die zich met die referentie aanmeldt, gemarkeerd als **Wacht op goedkeuring**
+   en uitgeschakeld. De beschrijving noemt de host waarvandaan hij het vroeg
+
+Een uitgaande RTE blijft verbonden terwijl hij wacht, maar krijgt geen job. De app belt een inkomende RTE pas als hij is goedgekeurd. Beide loggen
+dat ze wachten tot een admin ze goedkeurt onder **Verbindingen > Runners**, met de vingerafdruk van hun token.
+
+Een inkomende RTE met een `RTE_URL` die met `https://` begint, stuurt bij het vragen om lid te worden ook zijn certificaat mee, en de app pint het: vanaf dan
+belt de app die RTE alleen als hij hetzelfde certificaat presenteert, zodat een zelfondertekend certificaat werkt zonder CA (zie [Inkomend](../rte/modes.html#inbound)).
+
+Er wachten maximaal 20 RTE's tegelijk op goedkeuring: meer worden geweigerd totdat er enkele zijn goedgekeurd of afgewezen. Een aanvraag die niemand binnen
+24 uur afhandelt, wordt door de worker verwijderd, met haar referentie.
+
+Een RTE met de naam van een runner die de app al kent, maar met een ander token, wordt geweigerd en vraagt niet om lid te worden. Geef hem het token van die runner,
+of verwijder de runner zodat hij vraagt om lid te worden. Een [jointoken](#join-tokens) helpt alleen zolang die runner nog op goedkeuring wacht.
+
+---
+
+## Een RTE goedkeuren
+
+De runners die op goedkeuring wachten, verdwijnen uit de lijst van **Verbindingen > Runners** naar een oranje melding erboven, zoals
+**2 Runners wachten op goedkeuring**, met een regel per runner: de naam, host, het IP-adres, de modus, het adres en de vingerafdruk.
+De bel in de kopbalk telt ze, voor de gebruikers die de runners kunnen zien (zie [de bel](../jobs/#the-jobs-page)).
+
+Een klik op de melding opent het dialoogvenster **Goedkeuring beoordelen** voor elke runner om de beurt; een klik op een naam opent alleen die runner.
+Zijn pagina toont dezelfde gegevens in een geel vak, **Deze RTE vraagt om lid te worden**. Controleer dat het er een is die je zelf hebt gestart voordat je hem goedkeurt:
+
+| Veld | Wat het toont |
+|---|---|
+| Vingerafdruk | De eerste 8 hexadecimale cijfers van de SHA-256 van zijn `RTE_TOKEN`, als `abcd-ef12`. De RTE logt hem bij het starten, en het [installatieprogramma](../installation/installer.html#a-runner) drukt hem aan het einde af. Hij moet gelijk zijn |
+| Vingerafdruk van het certificaat | In het dialoogvenster, voor een inkomende RTE via HTTPS: de eerste 8 hexadecimale cijfers van de SHA-256 van het certificaat dat de app pint (de DER-bytes), als `abcd-ef12`. De RTE logt hem bij het starten en het [installatieprogramma](../installation/installer.html#a-runner) drukt hem aan het einde af. Hij moet gelijk zijn |
+| Host | De host waarop hij draait |
+| IP-adres | Het adres van waaruit hij de app aanriep |
+| Modus | Uitgaand of Inkomend |
+| Uri | Het adres van een inkomende RTE, waar de app hem belt |
+| Versie | Zijn release |
+| Aangevraagd op | Wanneer hij vroeg om lid te worden |
+
+**Goedkeuren** en **Afwijzen**, in het dialoogvenster of in het vak op zijn pagina, beslissen:
+
+| Actie | Wat er gebeurt |
+|---|---|
+| Goedkeuren | De runner wordt ingeschakeld en krijgt vanaf nu jobs. Hij wordt de standaard van zijn type als er geen is |
+| Afwijzen | De runner wordt met zijn referentie verwijderd, en zijn socket wordt gesloten. De RTE mag opnieuw vragen om lid te worden; hij wacht dan opnieuw op goedkeuring |
+
+Alleen een admin keurt een RTE goed of wijst hem af.
+
+---
+
+## Jointokens
+
+Een jointoken keurt een RTE meteen goed, voor onbeheerde installaties: een RTE die is gestart met
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), of een Runner die is geïnstalleerd met `--join` van het installatieprogramma, presenteert het één keer
+en zijn runner wordt ingeschakeld toegevoegd, zonder te wachten. Jointokens hebben geen pagina in de interface: een admin maakt ze via de
+[REST API](../api/), onder `/api/v2/runner`:
+
+| Aanroep | Wat ze doet |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Maakt een jointoken. De body bevat de `name`, en optioneel `expiresInHours` (geen: verloopt nooit) en `maxUses` (geen: een willekeurig aantal RTE's) |
+| `GET /api/v2/runner/jointoken` | Toont de jointokens, de nieuwste eerst, met hun gebruik en of ze nog bruikbaar zijn; nooit de tokens zelf |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Trekt het in: het voegt geen runner meer toe, en blijft in de lijst staan |
+| `DELETE /api/v2/runner/jointoken/<id>` | Verwijdert het |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+Het antwoord bevat het token, dat met `afj_` begint, deze ene keer: alleen de SHA-256 ervan wordt opgeslagen. Een RTE die het presenteert, krijgt dezelfde
+referentie en runner als een RTE die [vraagt om lid te worden](#asking-to-join), ingeschakeld, en de beschrijving noemt het jointoken. Vanaf dan
+meldt de RTE zich aan met zijn eigen token, zodat het jointoken kan verlopen of worden ingetrokken zonder dat dat hem raakt. Het intrekken of verwijderen van een jointoken
+laat de runners staan die het heeft toegevoegd.
+
+Een jointoken geeft een goedgekeurde runner nooit een nieuw token. Als er al een RTE-runner met die naam bestaat:
+
+| De runner | Wat er gebeurt |
+|---|---|
+| Wacht op goedkeuring | Hij krijgt het nieuwe token in zijn referentie, en wacht nog steeds op de goedkeuring van een admin |
+| Is goedgekeurd | Geweigerd met `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. Het jointoken wordt niet verbruikt |
+| Komt uit de [configuratie-seed](../seed/) | Geweigerd: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Een RTE die opnieuw met een nieuw token is geïnstalleerd, meldt zich daarom aan met het token uit de referentie van zijn runner, of een admin wijzigt dat token
+onder **Verbindingen > Inloggegevens**, of verwijdert de runner zodat de RTE als nieuwe lid wordt.
+
+---
+
+## Registratie in databasemodus
+
+Een RTE in databasemodus, verouderd sinds 7.3.0, registreert zichzelf standaard, op zijn `RTE_URL` of anders op zijn eigen adres en poort. De
+worker verwijdert zo'n runner zodra zijn RTE 10 minuten lang geen heartbeat heeft geschreven. Een runner die met de hand, door de configuratie-seed of door een
+RTE in een socketmodus is toegevoegd, wordt nooit op die manier verwijderd.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), dat deze registratie in- of uitschakelt, is in 7.3.0 samen met
+de databasemodus verouderd: een RTE in een socketmodus vraagt om lid te worden, of wordt lid met een jointoken. Om zulke runners in de tussentijd zelf te beheren, start je de
+RTE met `RTE_REGISTER=0` en voeg je hem hier toe met type RTE, modus **Database (verouderd)**, en een RTE-referentie met zijn adres en hetzelfde
+token. Zie [Modi](../rte/modes.html#database-deprecated) om hem naar een socketmodus te verplaatsen.
diff --git a/i18n/nl/_configure/runners/runner-page.md b/i18n/nl/_configure/runners/runner-page.md
new file mode 100644
index 0000000..85e37fa
--- /dev/null
+++ b/i18n/nl/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "De pagina van een runner"
+parent: Runners
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# De pagina van een runner
+{: .no_toc }
+
+De tabbladen van een runner, de modus, verbinding en instellingen van een RTE, en Verbinding testen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tabbladen
+
+De pagina van een runner toont de stappen van zijn dialoogvenster als tabbladen, plus wat erop draait:
+
+| Tabblad | Wat het bevat |
+|---|---|
+| Details | De naam en beschrijving, de schakelaar **Standaard** en de schakelaar **Ingeschakeld**, hetzelfde voor elk type runner |
+| Type | Het product, zoals in het dialoogvenster. Voor een RTE ook de **Modus**: **Database (verouderd)**, **Inkomend** of **Uitgaand**, de `RTE_MODE` waarmee zijn RTE draait (zie [Modi](../rte/modes.html)) |
+| RTE | Alleen voor een RTE: de **Modus** in woorden en, in een socketmodus, de **Verbinding** en de instellingen (zie [De instellingen van een RTE](#an-rtes-settings)) |
+| Referenties | De **Referentie** waarmee hij zich aanmeldt, een referentie uit Verbindingen > Inloggegevens van het type van de runner, die het token of de aanmelding en het adres van de server bevat. Die van een RTE bevat zijn `RTE_TOKEN`, en het adres van de RTE tenzij hij uitgaand is. **Project** voor Semaphore, Rundeck en Jenkins |
+| Formulieren | De formulieren die erop draaien, en hoe: **Noemt hem** of **Als standaardrunner**. Een rij opent het formulier |
+| Jobs | De laatste 100 jobs die erop draaiden, met hun status, start, einde en duur. Een rij opent de job |
+
+Elk tabblad heeft een eigen adres, zoals `/settings/runners/<id>/rte`, zodat een link of een bladwijzer het opent. Een runner zonder dat tabblad opent op
+Details.
+
+De twee schakelaars van het tabblad Details worden meteen opgeslagen. **Standaard** maakt de runner de standaard van zijn type; hij wordt uitgezet door
+een andere runner de standaard te maken. **Ingeschakeld** schakelt de runner in of uit: uitgeschakeld gaat er geen job naartoe, ook niet als standaard van zijn type (zie
+[Standaard en Ingeschakeld](list.html#default-and-enabled)).
+
+Een RTE die vroeg om lid te worden, opent met een geel vak, **Deze RTE vraagt om lid te worden**, met zijn vingerafdruk en wat hij over zichzelf zei, en
+**Goedkeuren** en **Afwijzen** (zie [Een RTE goedkeuren](registration.html#approving-an-rte)). Een runner uit de [configuratie-seed](../seed/) vermeldt
+dat boven aan zijn pagina, en is alleen-lezen.
+
+---
+
+## De instellingen van een RTE
+
+Het tabblad RTE beheert een RTE vanuit de app, zonder de omgeving te bewerken op de machine waarop hij draait.
+
+**Verbinding.** Een RTE in een socketmodus toont een badge: **Verbonden** of **Niet verbonden**. Bij aanwijzen toont **Verbonden** de app-node
+die zijn socket vasthoudt, de release van de RTE, en hoeveel van zijn jobs draaien. **Niet verbonden** betekent dat geen enkele app-node een socket naar hem vasthoudt:
+controleer of de RTE draait, zijn adres of `APP_URL`, en zijn token.
+
+**Instellingen.** Een RTE in uitgaande of inkomende modus heeft vier instellingen, elk standaard leeg:
+
+| Instelling | Hetzelfde als | Wat ze doet |
+|---|---|---|
+| Max. gelijktijdige jobs | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Hoeveel playbooks hij tegelijk draait, standaard `10`; `0` stelt geen limiet in |
+| Cache voor jobbestanden | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Hoeveel van de jobbestanden die de app hem stuurde hij bewaart, in MB, standaard `1024`; `0` bewaart niets |
+| Wachttijd bij stoppen | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Hoe lang een stoppende RTE op zijn lopende playbooks wacht, standaard `25` seconden |
+| Jobbestanden | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Overdracht**: de app stuurt de bestanden van een job met de job mee. **Lokaal**: hij draait vanuit zijn eigen gekoppelde mappen |
+
+**Welke waarde wint.** Een waarde op de pagina wint van dezelfde variabele die op de RTE is ingesteld. Een veld dat leeg blijft, gebruikt de eigen variabele van de RTE,
+anders de standaard. Onder elk veld zegt de pagina welke: **Overschrijft RTE_MAX_JOBS op de RTE (3).**, of **Leeg: de RTE gebruikt zijn
+eigen RTE_MAX_JOBS, 3.**; de placeholder toont de waarde waarvoor een leeg veld staat.
+
+**Hoe ze de RTE bereiken.** De instellingen worden met de runner in de database van de app opgeslagen. De app stuurt ze over de socket van de RTE
+wanneer die verbinding maakt en telkens wanneer ze worden opgeslagen, en de RTE past ze meteen toe: een kleinere cache wordt ingekort, een nieuwe limiet telt vanaf de
+volgende job. De RTE bewaart ze alleen in het geheugen en schrijft geen bestand: na een herstart krijgt hij ze opnieuw als hij verbinding maakt, vóór zijn eerste job.
+
+Een RTE in databasemodus (verouderd) heeft geen socket: hij leest deze instellingen uit zijn eigen variabelen, en het tabblad vermeldt dat.
+
+---
+
+## Verbinding testen
+
+De knoppen rechtsboven werken op de runner zoals hij is opgeslagen.
+
+Naast **Opslaan** staan **Verbinding testen** en **Verwijderen**, en op het tabblad Referenties **Referentie toevoegen**, dat een referentie van het
+type van de runner aanmaakt en kiest. Een token of wachtwoord wordt na het opslaan nooit meer getoond: wijzig het op de referentie.
+
+**Verbinding testen** controleert of de runner antwoordt en zijn token of aanmelding accepteert, en zegt dat in een bericht: **Runner connection is
+OK**, of waarom het mislukte. Er draait geen job. Voor een RTE controleert het ook het contract dat de RTE spreekt (zie
+[Het contract](../rte/images.html#the-contract)):
+
+| RTE | Wat de test leest | Wanneer hij mislukt |
+|---|---|---|
+| Uitgaand of Inkomend | Wie zijn socket vasthoudt, zoals elke app-node dat vastlegt, en wat de RTE zei toen hij verbinding maakte. Hij roept niets aan | Geen enkele app-node houdt een socket naar hem vast: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, of voor een inkomende, *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Of de RTE spreekt een ander contract dan 3 |
+| Database (verouderd) | De `/rte/v1/health` van de RTE, aangeroepen met zijn token | De RTE antwoordt niet op zijn adres, weigert het token, of spreekt een ander contract dan 2 |
+
+De badge **Verbinding** van het tabblad RTE toont dezelfde socketstatus zonder test.
diff --git a/i18n/nl/_configure/runners/types.md b/i18n/nl/_configure/runners/types.md
new file mode 100644
index 0000000..3932d2c
--- /dev/null
+++ b/i18n/nl/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Typen runners
+parent: Runners
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Typen runners
+{: .no_toc }
+
+De producten die een runner kan zijn, hun adres en aanmelding
+{: .fs-6 .fw-300 }
+
+De stap **Type** biedt één keuze per product, elk met een hint; die van de RTE schrijft de naam voluit, *Runtime-omgeving*. AAP en
+Ascender worden opgeslagen als een runner van het type `awx` met een variant (`aap` of `ascender`), wat ook de configuratie-seed gebruikt:
+
+| Type | Voorbeeld-uri | Project | Authenticatie |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | Het `RTE_TOKEN` van de RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Een API-token, of een gebruiker en wachtwoord |
+| Ascender | `https://ascender.example.com/api/v2` | | Een API-token, of een gebruiker en wachtwoord |
+| AWX | `https://awx.example.com/api/v2` | | Een API-token, of een gebruiker en wachtwoord |
+| Jenkins | `https://jenkins.example.com` | De map waarin de jobs staan (optioneel) | Een gebruiker en het API-token van die gebruiker |
+| Rundeck | `https://rundeck.example.com` | De projectnaam | Het API-token van een gebruiker |
+| Semaphore | `https://semaphore.example.com` | Het project-id, het getal in `/project/<id>` | Het API-token van een gebruiker |
+
+Een adres van AWX, AAP of Ascender bevat het API-pad: `/api/v2`, of `/api/controller/v2` voor AAP 2.5 en later.
+Een RTE is de AnsibleForms-image gestart met `AF_ROLE=rte`; hoe je er een draait, staat beschreven in
+[Runtime-omgevingen](../rte/).
diff --git a/i18n/nl/_configure/secret-stores/cyberark.md b/i18n/nl/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..29d718e
--- /dev/null
+++ b/i18n/nl/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Secret stores
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Referenties lezen uit de CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Experimenteel.** Nog niet getest tegen een draaiende CyberArk-installatie; meld je bevindingen.
+
+De CCP is de REST-interface van de Application Access Manager van CyberArk.
+
+---
+
+## Velden van de store
+
+Naast de [velden die elke store heeft](./#adding-a-store) heeft een CyberArk-store deze velden:
+
+| Veld | Betekenis |
+|---|---|
+| Referentie | Een **CyberArk**-referentie uit [Verbindingen > Inloggegevens](../credentials.html): de basis-URL van de CCP, bijv. `https://ccp.example.com` (`/AIMWebService/api/Accounts` wordt toegevoegd), de TLS-instellingen, de AppID (de applicatie die voor AnsibleForms in CyberArk is gedefinieerd), en een clientcertificaat en -sleutel in PEM, alleen als de AppID die vereist. |
+
+---
+
+## Secret reference
+
+De secret reference identificeert het account als door `;` gescheiden sleutel-waardeparen:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Toegestane sleutels: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` geeft de rest van de verwijzing door als een native CCP-query, met `QueryFormat=Exact`
+  tenzij je het anders instelt.
+- Een `AppID` in de verwijzing wordt genegeerd: de AppID van de store wordt altijd gebruikt.
+- Het wachtwoord van het account (`Content`) wordt het wachtwoord; `UserName`, `Address`, `Port` en
+  `Database` vullen gebruiker, host, poort en databasenaam in.
+
+---
+
+## Extra opties
+
+De extra opties van de store worden ingesteld als JSON-object:
+
+| Sleutel | Betekenis |
+|---|---|
+| `reason` | Verstuurd als `Reason` als de verwijzing er geen heeft, voor de audit van CyberArk. |
+| `check_ref` | Een verwijzing die **Verbinding testen** echt leest. Zonder deze sleutel controleert de test alleen of de CCP antwoordt en de AppID accepteert. |
+| `timeout_ms` | Time-out van het verzoek, standaard 10000. |
+
+Bijvoorbeeld, om een reden mee te sturen en **Verbinding testen** een testaccount te laten lezen:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/nl/_configure/secret-stores/hashicorp-vault.md b/i18n/nl/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..1e3a88c
--- /dev/null
+++ b/i18n/nl/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Secret stores
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Referenties lezen uit HashiCorp Vault, uit KV v1 of v2 of een dynamische secrets engine
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Velden van de store
+
+Naast de [velden die elke store heeft](./#adding-a-store) heeft een HashiCorp Vault-store deze velden:
+
+| Veld | Betekenis |
+|---|---|
+| Referentie | Een **HashiCorp Vault**-referentie uit [Verbindingen > Inloggegevens](../credentials.html): het adres van de Vault, de TLS-instellingen, en het token als wachtwoord, met leestoegang tot de paden die je referenties gebruiken. **Referentie toevoegen** maakt er een van dat type. AnsibleForms vernieuwt het token niet. |
+| Namespace | De namespace van Vault Enterprise, verstuurd als `X-Vault-Namespace`. Getoond zodra **Vault Enterprise** is ingeschakeld, in de stap **Type**. |
+| KV versie | `2` (standaard) of `1`. |
+| Standaard mount | Gebruikt voor een verwijzing zonder slash, bijv. `myapp` wordt `secret/data/myapp`. |
+
+De secret reference is het pad, bijv. `secret/myapp/prod`. Voor KV v2 wordt het segment `/data/`
+ingevoegd als je het weglaat.
+
+---
+
+## Dynamische databasereferenties
+
+Een verwijzing van de vorm `<mount>/creds/<role>`, bijv. `database/creds/readonly`, leest uit een
+dynamische secrets engine zoals de database engine van Vault. Vault maakt dan bij elke leesactie een nieuw
+databaseaccount aan, geldig zolang de lease duurt.
+
+- Een account wordt hergebruikt gedurende 80% van zijn lease, niet de cachetijd; met cache `0` leest elke query een nieuw account.
+- Vault geeft alleen een gebruiker en wachtwoord terug: zet de rest van de verbinding in de referentierij.
+- De lease wordt nooit vroegtijdig ingetrokken; het account verloopt wanneer Vault de lease beëindigt.
diff --git a/i18n/nl/_configure/secret-stores/index.md b/i18n/nl/_configure/secret-stores/index.md
new file mode 100644
index 0000000..3a3b1c8
--- /dev/null
+++ b/i18n/nl/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Secret stores
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Secret stores
+{: .no_toc }
+
+Lees referenties uit een secret manager in plaats van ze in AnsibleForms op te slaan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: koppel een secret manager, en laat referenties hun gebruiker en wachtwoord daaruit lezen.
+
+---
+
+## Hoe het werkt
+
+Een **secret store** is een verbinding met een secret manager, toegevoegd onder
+**Verbindingen > Secret stores**. Een **referentie** kan dan een store en een plaats daarin noemen
+(de *secret reference*). Wanneer een formulier, een playbook of een expressie die referentie gebruikt:
+
+- worden **user** en **password** elke keer uit de store gelezen (binnen de cachetijd van de store);
+- blijven **host**, **port** en **database** die van de referentierij. Als de rij er een van
+  leeg laat en het geheim hem bevat, wordt de waarde uit het geheim gebruikt.
+
+Formulieren blijven op naam naar de referentie verwijzen, dus een wachtwoord naar een store verplaatsen verandert
+niets aan je formulieren.
+
+| Type store | Status |
+|---|---|
+| HashiCorp Vault (KV v1 en v2, tokenauthenticatie) | beschikbaar |
+| Dynamische referenties van HashiCorp Vault (`<mount>/creds/<role>`) | experimenteel |
+| CyberArk Central Credential Provider (CCP) | experimenteel |
+
+---
+
+## Een store toevoegen
+
+Vanaf 7.3.0 kan alleen een admin een store toevoegen, wijzigen of verwijderen, omdat het token of de sleutel ervan naar zijn adres wordt gestuurd. Elke store heeft deze velden:
+
+| Veld | Betekenis |
+|---|---|
+| Naam | Hoe referenties naar de store verwijzen. |
+| Type | De secret manager. |
+| Referentie | Hoe en waar de store zich aanmeldt: een referentie uit [Verbindingen > Inloggegevens](../credentials.html), in de stap **Referenties**, van het type **HashiCorp Vault** (het token en het adres) of **CyberArk**. Ze bevat de basis-URL, bijv. `https://vault.example.com:8200`, en de TLS-instellingen: certificaatcontrole overslaan, of een CA-bundel in PEM voor een private CA. Ze kan zelf niet uit een secret store lezen. |
+| Cache (seconden) | Hoe lang een gelezen geheim wordt hergebruikt. `0` leest het bij elk gebruik. Standaard 60. |
+| Extra opties (JSON) | Opties die specifiek zijn voor het type, als JSON-object. |
+
+Tot en met 7.2.0 waren het adres, het token en de TLS-instellingen velden van de store. De upgrade naar 7.3.0 verplaatst ze naar zijn
+referentie, met de naam `<store>-token` (of `<store>-appid` voor CyberArk), zie [Adressen in referenties](../credentials/types.html#addresses-in-credentials).
+
+**Verbinding testen** controleert de toegang zonder een geheim te lezen. De pagina **Status** controleert elke store, en waarschuwt 7 dagen
+voordat een Vault-token verloopt.
+
+Elke secret manager heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 en v2 met tokenauthenticatie, en dynamische databasereferenties |
+| [CyberArk](cyberark.html) | De Central Credential Provider (CCP) van de Application Access Manager van CyberArk |
+
+---
+
+## Een store gebruiken
+
+### In een referentie
+
+Kies onder **Verbindingen > Inloggegevens**, in de stap **Opslag** van de referentie, **Geheimenkluis**, kies dan de
+**Secret store** en vul de **Referentie** in. De gebruiker en het wachtwoord worden dan uit de store gelezen, niet ingetypt.
+
+### Inline, zonder referentierij
+
+Overal waar een referentienaam wordt geaccepteerd, kun je in plaats daarvan rechtstreeks naar een store verwijzen (`fnCredentials`, `fnRestBasic`,
+de `credentials:` van een formulier, de `dbConfig` van een query).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Zonder referentierij heeft een databasegeheim minstens een `db_type` en een host nodig, bijvoorbeeld:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Zonder `db_type` is het geheim een gewone referentie (gebruiker, wachtwoord en eventuele andere sleutels), en gaat een query erop uit van `mysql`.
+
+### Sleutelnamen
+
+Een geheim wordt met deze aliassen aan een referentie gekoppeld. Andere sleutels worden doorgegeven.
+
+| Veld van de referentie | Geaccepteerde sleutels in het geheim |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | dezelfde naam (alleen inline geheimen) |
+
+Voor een referentierij worden host, poort en databasenaam uit het geheim alleen gebruikt waar de
+rij ze leeg laat.
+
+Een geheim met een andere structuur kan worden omgevormd met een `jq`-expressie, doorgegeven als derde argument van
+`fnCredentials`:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## In de configuratie-seed
+
+Stores kunnen ook in de configuratie-seed worden gedeclareerd, net als de andere beheerobjecten:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+De store meldt zich aan met zijn referentie: een `vault`-referentie bevat het adres van de Vault in `url` en het token als wachtwoord, een `cyberark`-referentie
+de AppID en het CCP-adres. Zonder referentie worden de eigen `url` en `token` van de store gebruikt.
+Zie [Configuratie-seed](../seed) voor details.
+
+---
+
+## Upgraden vanaf de VAULT_*-variabelen
+
+Vóór 7 was de enige store een HashiCorp Vault die met `VAULT_*`-omgevingsvariabelen werd geconfigureerd, en een referentie
+wees ernaar met **Vault path**.
+
+- **De variabelen worden eenmaal geïmporteerd** als een store met de naam `vault`; verwijder ze daarna.
+- **Referenties met een `vault_path`** gebruiken nu die store; `vault_path` verdwijnt in 8.
diff --git a/i18n/nl/_configure/security/hardening.md b/i18n/nl/_configure/security/hardening.md
new file mode 100644
index 0000000..c316785
--- /dev/null
+++ b/i18n/nl/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Hardening
+parent: Beveiliging
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Hardening
+{: .no_toc }
+
+Het adminaccount, aanmeldlimieten, de database, expressies, jobgegevens, het browserbeleid, optionele functies en rolinstellingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het adminaccount
+
+Het lokale adminaccount wordt bij de eerste start aangemaakt op basis van [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+en [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), waarvan de standaardwaarde `AnsibleForms!123` is.
+
+* Wie zich aanmeldt met het openbare standaardwachtwoord `AnsibleForms!123`, moet het eerst wijzigen: tot dan beantwoordt de server
+  elk verzoek behalve de wachtwoordwijziging met `403` (code `password_change_required`), en toont de browser een
+  pagina om het wachtwoord te wijzigen die niet kan worden gesloten. Het nieuwe wachtwoord mag niet opnieuw het standaardwachtwoord zijn.
+* `ADMIN_PASSWORD` wordt alleen gelezen wanneer het account voor het eerst wordt aangemaakt: stel je eigen waarde in vóór de eerste start.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` zet het wachtwoord bij elke start terug op `ADMIN_PASSWORD`.
+  Gebruik het alleen om een verloren wachtwoord te herstellen, verwijder het daarna en herstart.
+* Stel eerst de twee hoofdgeheimen in: zie [Geheimen en versleuteling](secrets.html).
+* Zodra aanmelden via LDAP of SSO werkt, bewaar je de lokale admin alleen voor noodgevallen, met een lang wachtwoord in je kluis.
+
+---
+
+## Aanmeldlimieten en wachtwoorden
+
+Het raden van wachtwoorden wordt door drie limieten afgeremd. De mislukte pogingen worden in de database geteld, zodat elke app-node dezelfde
+pogingen ziet, en elke limiet geldt zonder herstart:
+
+| Variabele | Standaard | Wat ze doet |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Na zoveel mislukte aanmeldingen wordt een lokaal of LDAP-account `LOGIN_LOCKOUT_MINUTES` lang geblokkeerd. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Een adres met zoveel mislukte aanmeldingen binnen `LOGIN_LOCKOUT_MINUTES` wordt tegengehouden tot dat venster eindigt: één adres dat veel accounts probeert. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Hoe lang een account geblokkeerd blijft, en het venster waarin mislukte pogingen worden geteld. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Verzoeken per minuut van één adres, per app-node, op de callbacks voor aanmelden, afmelden, tokenvernieuwing en single sign-on. |
+
+Een geblokkeerd account of een tegengehouden adres krijgt `429` met een header `Retry-After`, voordat er een wachtwoord wordt gecontroleerd en
+ongeacht of het account bestaat; boven `AUTH_RATE_LIMIT` is het antwoord ook `429`. Een geslaagde aanmelding wist de
+telling van het account, en dat doet ook een admin die het wachtwoord van de gebruiker instelt. `0` schakelt een limiet uit; `LOGIN_LOCKOUT_MINUTES=0`
+schakelt zowel de blokkering als de limiet per adres uit.
+
+`LOGIN_MAX_FAILURES_PER_IP` en `AUTH_RATE_LIMIT` tellen per clientadres: stel achter een reverse proxy `TRUST_PROXY` in,
+zodat het adres dat van de client is en niet dat van de proxy, zie [Clientadressen](../production/reverse-proxy.html#client-addresses).
+
+Een lokaal wachtwoord dat via de applicatie wordt ingesteld, voor een nieuwe gebruiker, door een admin of door gebruikers die hun eigen wachtwoord wijzigen, moet
+minstens [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) tekens hebben (standaard `8`,
+`0` controleert geen lengte). Het mag niet de gebruikersnaam of het openbare standaardwachtwoord zijn. `ADMIN_PASSWORD` wordt niet gecontroleerd.
+
+---
+
+## De database
+
+AnsibleForms bewaart elke referentie en elke job in zijn MySQL-database, dus houd die database van het netwerk af:
+
+* Het docker-compose-project publiceert MySQL op de host (`MYSQLDB_LOCAL_PORT`, `3306`) en wordt geleverd met het
+  rootwachtwoord `AnsibleForms!123`. Verwijder die poortkoppeling, of bind haar aan `127.0.0.1`, en wijzig het wachtwoord.
+* Maak verbinding met een eigen account in plaats van `root`, ingesteld in [`DB_USER`](../customization/server.html#env_DB_USER) en
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Het heeft alleen rechten op het schema `AnsibleForms` nodig:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Dat dekt het aanmaken van het schema (de `CREATE DATABASE` inbegrepen), het patchen ervan bij upgrades, en de
+  [back-ups](../production/backups.html) en het terugzetten, die als dezelfde gebruiker draaien: de dump wordt gemaakt met
+  `--no-tablespaces`, dus er is geen serverbreed recht zoals `PROCESS` nodig. Vervang `%` waar mogelijk door het adres van de
+  applicatie. Een gebruiker met rechten op elke database, zoals `root`, maakt van een gat in de applicatie
+  een gat in de hele databaseserver: de pagina **Status** waarschuwt ervoor in de controle **Databasegebruiker**, en het log
+  bij elke start.
+* Zet [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) op `0` zodra het schema bestaat.
+  Het aanmaken van het schema verwijdert eerst elke tabel; met `0` kunnen noch de bootstrap bij het opstarten noch het endpoint
+  `/api/v2/schema` het uitvoeren.
+
+---
+
+## Expressies en uitgaande aanroepen
+
+Serverexpressies draaien op de server voor elke aangemelde gebruiker, dus de sanitizer en de uitgaande filters doen ertoe:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` of `paranoid`, nooit `legacy`, waarmee gebruikers servercode kunnen uitvoeren.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : hosts die REST-expressies niet mogen bereiken, bijv. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : als die is ingesteld, kunnen REST-expressies
+  alleen deze hosts en bereiken bereiken. De lijst met geweigerde hosts gaat erboven.
+
+Beide lijsten dekken alleen de REST-hulpfuncties van AnsibleForms zelf; playbooks draaien daarbuiten en worden niet gefilterd.
+
+Vanaf 7.3.0 controleren de REST-hulpfuncties het certificaat van het endpoint, zoals elke andere verbinding.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` schakelt de controle uit: gebruik het alleen voor
+endpoints met een zelfondertekend certificaat.
+
+---
+
+## Jobgegevens
+
+De extravars en uitvoer van jobs worden in de database opgeslagen en getoond aan iedereen die de job kan zien:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : extravars waarvan de sleutel overeenkomt, worden
+  getoond als `********`. De standaard is `password|secret|token`; wachtwoordvelden worden altijd gemaskeerd. Breid het uit met
+  de namen die je formulieren gebruiken, bijvoorbeeld `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : beperkt het object `ansibleforms_user`
+  dat met elke job wordt meegestuurd, dat anders het hele groepslidmaatschap van de gebruiker bevat.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) verbergt alleen luidruchtige taken; verberg geheimen met `no_log`.
+
+---
+
+## De Content-Security-Policy
+
+De interface wordt geleverd met een header Content-Security-Policy, die beperkt wat een pagina in de browser mag laden en uitvoeren:
+
+* Scripts komen alleen van de applicatie zelf, dus een script dat in een pagina is geïnjecteerd, draait niet.
+* Geen andere site mag de interface in een frame tonen.
+* Ze staat toe wat de applicatie nodig heeft: lokale formulierexpressies die in de browser worden geëvalueerd (`'unsafe-eval'`), inline
+  stijlen, afbeeldingen van elke URL (afbeeldingen van formulieren en categorieën), en de workers van de code-editor.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) is standaard `1` en hoort dat te
+blijven. Met `0` wordt het beleid verstuurd als `Content-Security-Policy-Report-Only`: de browserconsole toont wat het zou
+blokkeren, en er wordt niets geblokkeerd. Gebruik `0` alleen voor een opzet die nog niet met het beleid kan werken, zoals een reverse proxy
+die een eigen script injecteert. Een wijziging op de instellingenpagina geldt zonder herstart.
+
+---
+
+## De instellingenpagina's en de designer
+
+Beheerders kunnen een groot deel van de configuratie vanuit de browser wijzigen. Beperk dat waar de configuratie elders staat:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : alleen-lezen instellingen, voor een [beheerde omgeving](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : verwijdert de ingebouwde designer wanneer formulieren
+  in git worden onderhouden.
+
+---
+
+## Optionele functies
+
+Deze functies staan standaard uit. Schakel ze alleen in als je ze gebruikt; een wijziging op de instellingenpagina geldt zonder herstart:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : biedt de [MCP-server](../mcp/) aan op `/api/v2/mcp`,
+  zodat MCP-clients formulieren kunnen starten met het token van een gebruiker.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : de [chat-assistent](../chat/). Formulierdefinities
+  en de waarden die worden ingevuld, worden naar de geconfigureerde modelprovider gestuurd.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) werkt andersom: die staat standaard op `enforce`,
+zodat de server een start weigert waarvan de waarden de regels van het formulier overtreden, ook starts via de REST API.
+Laat hem zo staan: `log` logt alleen wat zou worden geweigerd en `off` controleert niets, zie [Validatie bij het starten](../launch-validation/).
+
+---
+
+## Rolinstellingen
+
+Sommige rolinstellingen in [config.yaml](../config/roles.html) geven meer dan hun naam doet vermoeden. Geef ze met zorg:
+
+| Instelling | Waarom het ertoe doet |
+|--------|----------------|
+| `allowScheduledJobs` | Een gebruiker met deze instelling ziet elke planning en kan ze wijzigen, en een planning draait met adminrechten, voor elk formulier. Behandel haar als instelling op adminniveau. |
+| `allowBackupOps` | Omvat **terugzetten**, wat de hele database vervangt. |
+| `showSettings` | Opent de beheerpagina's. Zonder de rol admin kan ze de accounts en groepen die de rol admin noemt niet wijzigen, zie [Gebruikers en groepen](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Toont het serverlog, dat hostnamen, gebruikersnamen en foutdetails kan bevatten. |
+| `showConnectionsSettings` | Opent de verbindingspagina's: referenties, runners, meldingskanalen en meer. Runners en secret stores toevoegen, wijzigen en verwijderen blijft voorbehouden aan een admin, net als de referenties van verbindingen en aanmeldingen. Bij een repository blijven toevoegen of verwijderen en het wijzigen van het adres, de branch of de vlaggen `use_for_*` voorbehouden aan een admin. |
+| `showAllJobLogs` | Toont de jobs van elke gebruiker, niet alleen de eigen. |
+| `manageAllJobs` | Breekt de jobs van elke gebruiker af, verwijdert ze en start ze opnieuw. |
+| `allowApiTokens` | Laat de gebruiker API-tokens maken die tot [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) leven (standaard 90). Afmelden met een token of het intrekken ervan beëindigt het, en een wachtwoordwijziging beëindigt alle tokens van de gebruiker, zie [Tokens](secrets.html#tokens). |
+| `extendedTokenExpiration` | Laat de gebruiker met `allowApiTokens` ook API-tokens maken die nooit verlopen. |
+| `allowFileUploads` | Laat de gebruiker bestanden uploaden via de bestandsvelden van een formulier. Aan voor elke gebruiker, tenzij een rol het uitzet. |
+| `allowChat`, `allowMcp` | Laten de gebruiker de chat-assistent en de MCP-server gebruiken, als die zijn ingeschakeld. `allowChat` staat aan voor elke gebruiker, tenzij een rol het uitzet, en `allowMcp` volgt `allowChat`, tenzij een rol het instelt. |
+
+Een gebruiker zonder de rol `admin` krijgt geen van de instellingen op adminniveau hierboven, tenzij een rol ze geeft. Als de rol `admin`
+geen instellingen instelt, krijgen zijn gebruikers `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` en `allowScheduledJobs`. `allowApiTokens` en
+`extendedTokenExpiration` blijven zelfs voor de rol `admin` uit: stel ze in op de rollen die ze nodig hebben.
+
+Als meerdere rollen van een gebruiker dezelfde instelling instellen, wint `false`. De instellingen van de rol `default` vullen alleen de instellingen aan
+die geen van de eigen rollen van de gebruiker instelt; ze gaan er nooit boven.
diff --git a/i18n/nl/_configure/security/https.md b/i18n/nl/_configure/security/https.md
new file mode 100644
index 0000000..d83e693
--- /dev/null
+++ b/i18n/nl/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Beveiliging
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+HTTPS vanuit de applicatie zelf bedienen, en het voorbeeldcertificaat vervangen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Waar TLS eindigt
+
+TLS kan op een van drie plaatsen eindigen, en alleen bij de eerste spelen de instellingen op deze pagina een rol:
+
+* **in AnsibleForms**, met `HTTPS=1` : HTTPS op [`PORT`](../customization/server.html#env_PORT) met de bestanden hieronder, zoals docker-compose op 443 doet.
+* **in een reverse proxy**, met `HTTPS=0` erachter : zie [Reverse proxy](../production/reverse-proxy.html).
+* **in een Kubernetes-ingress** : zie het tabblad Ingress van [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) en de README van de chart.
+
+Je kunt de eerste combineren met de andere twee om ook het traject tussen de proxy en de applicatie te versleutelen.
+
+---
+
+## De instellingen
+
+Drie variabelen sturen HTTPS in de applicatie:
+
+| Variabele | Standaard | Betekenis |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` bedient HTTPS, `0` gewone HTTP |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | De privésleutel, PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | Het servercertificaat, PEM |
+
+In de containerimage is de persistente map `/app/dist/persistent`, dus de standaardbestanden zijn
+`/app/dist/persistent/certificates/key.pem` en `cert.pem`. Met het docker-compose-project is dat `data/certificates/`
+op de host.
+
+---
+
+## Het voorbeeldcertificaat
+
+Als `HTTPS=1` en een van beide bestanden bij het opstarten ontbreekt, logt AnsibleForms `httpsKey or httpsCert not found, copying from
+templates` en kopieert een voorbeeldsleutel en -certificaat uit de image naar de geconfigureerde paden. Als die kopie mislukt, stopt de
+applicatie.
+
+Dat certificaat is zelfondertekend voor `CN=ansibleforms`, en het is **op elke installatie hetzelfde**: de privésleutel ervan
+zit in de openbare image. Het is prima om eens rond te kijken, maar browsers waarschuwen ervoor en iedereen kan verkeer ontsleutelen
+dat ermee is beschermd. Vervang het voordat de instantie echte referenties bevat.
+
+---
+
+## Het certificaat vervangen
+
+Gebruik een certificaat dat is uitgegeven voor de hostnaam die gebruikers typen, door je CA of een ACME-client, in PEM-formaat.
+Het certificaatbestand mag de volledige keten bevatten: eerst het servercertificaat, daarna de tussencertificaten.
+
+1. Kopieer de bestanden naar de persistente map, of naar een andere plek waar de applicatie ze kan lezen:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Als ze elders staan, stel `HTTPS_KEY` en `HTTPS_CERT` dan in op hun paden **binnen de container**.
+
+3. Herstart de applicatie, die beide bestanden bij het opstarten leest.
+
+Voor een snel eigen zelfondertekend certificaat (een testinstantie, of het traject achter een proxy) maakt `openssl` er een aan:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Vernieuwen zonder herstart
+
+Als je `HTTPS_KEY` of `HTTPS_CERT` op de instellingenpagina's wijzigt, worden de sleutel en het certificaat in de draaiende server opnieuw geladen.
+Nieuwe verbindingen krijgen het nieuwe certificaat, open verbindingen houden het oude. Als de nieuwe bestanden niet kunnen worden gelezen of geen geldig
+paar vormen, blijft het huidige certificaat staan en wordt een waarschuwing gelogd.
+
+Dat werkt alleen als de instellingenpagina's de omgeving mogen schrijven ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+is `1`) en de variabele niet in de echte omgeving is ingesteld. Als een vernieuwing de bestanden onder dezelfde
+paden vervangt, herstart dan de applicatie.
diff --git a/i18n/nl/_configure/security/index.md b/i18n/nl/_configure/security/index.md
new file mode 100644
index 0000000..0b35dde
--- /dev/null
+++ b/i18n/nl/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Beveiliging
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Beveiliging
+{: .no_toc }
+
+Een instantie dichttimmeren: het adminaccount, de geheimen, HTTPS en wat gebruikers en formulieren mogen doen
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders die een instantie op productie voorbereiden, en voor beveiligingsreviews van een bestaande instantie.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Hardening](hardening.html) | Het adminaccount, aanmeldlimieten, de database, expressies, jobgegevens, het browserbeleid, optionele functies en rolinstellingen |
+| [HTTPS](https.html) | Waar TLS eindigt, HTTPS vanuit de applicatie bedienen, en het voorbeeldcertificaat vervangen |
+| [Geheimen en versleuteling](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, en de levensduur van tokens |
+
+Gerelateerde pagina's: [Authenticatie](../authentication/) voor aanmeldmethoden, [Validatie bij het starten](../launch-validation/) voor
+controles aan de serverkant van elke start, en de [Beveiligingsvariabelen](../customization/security.html).
diff --git a/i18n/nl/_configure/security/secrets.md b/i18n/nl/_configure/security/secrets.md
new file mode 100644
index 0000000..21cd082
--- /dev/null
+++ b/i18n/nl/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Geheimen en versleuteling
+parent: Beveiliging
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Geheimen en versleuteling
+{: .no_toc }
+
+De twee hoofdgeheimen, wat ze beschermen, en hoe lang sessies en tokens geldig zijn
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De twee hoofdgeheimen
+
+Twee geheimen beschermen al het andere. Stel beide in voordat de instantie echte gegevens bevat, bewaar ze buiten de instantie,
+en wijzig ze nooit zomaar:
+
+| Geheim | Wat het beschermt | Als het niet is ingesteld | Als het verloren gaat of wordt gewijzigd |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Elk wachtwoord en token dat in de database is opgeslagen: referenties, het LDAP-bindwachtwoord, runnertokens, SSO-clientgeheimen, webhookadressen van Slack en Teams, de API-sleutel van de chat | Er wordt een standaardsleutel gebruikt, die openbaar in de broncode staat | Verloren: elk opgeslagen geheim moet opnieuw worden ingevoerd. Gewijzigd: vanaf 7.3.0 wordt elk opgeslagen geheim opnieuw versleuteld, zie [hieronder](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | De handtekening van access- en refresh-tokens, inclusief langlevende [API-tokens](../profile/api-token.html) | Bij elke start wordt een willekeurig geheim gegenereerd, dus elke herstart meldt iedereen af | Elke sessie en elk API-token wordt ongeldig |
+
+Zolang ze ontbreken, worden beide bij het opstarten gelogd als waarschuwing `[SECURITY]`. De instellingenpagina's weigeren ze te bewerken,
+de API geeft ze nooit terug, en back-ups laten ze bewust weg, dus een verloren `ENCRYPTION_SECRET` kan nergens vandaan worden
+hersteld: bewaar een kopie in je secret manager. Het versleutelingsgeheim wordt gebruikt als sleutel van 32 tekens; een kortere of
+langere waarde wordt aangevuld of ingekort.
+
+Het wijzigen van `ACCESS_TOKEN_SECRET` beëindigt elke sessie en elk API-token in één keer. Gebruik de intrekkingen die onder [Tokens](#tokens)
+worden beschreven om de tokens van één gebruiker of één sessie te beëindigen.
+
+---
+
+## Het versleutelingsgeheim wijzigen
+
+Vanaf 7.3.0 gaan de opgeslagen geheimen niet meer verloren bij het instellen of wijzigen van `ENCRYPTION_SECRET`. Bij de volgende start versleutelt de worker
+ze allemaal opnieuw met de nieuwe sleutel, in één databasetransactie, voordat iets anders een geheim schrijft:
+
+| Situatie | Wat in te stellen |
+|---|---|
+| De instantie draaide zonder `ENCRYPTION_SECRET`, op de openbare standaardsleutel | Alleen `ENCRYPTION_SECRET`: de geheimen worden opnieuw versleuteld vanaf de standaardsleutel |
+| De instantie draaide met een eigen sleutel | `ENCRYPTION_SECRET` op de nieuwe sleutel en [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) op de oude, voor die ene start |
+
+Als de opgeslagen geheimen zijn versleuteld met een sleutel die geen van beide is, wordt er niets gewijzigd en weigert de app te starten totdat
+`ENCRYPTION_SECRET_PREVIOUS` die sleutel noemt. Verwijder `ENCRYPTION_SECRET_PREVIOUS` zodra de start ze opnieuw heeft versleuteld, en stel de
+nieuwe `ENCRYPTION_SECRET` in op elke app-node, de worker en elke RTE in databasemodus die zichzelf registreert. Die
+zelfregistratie (`RTE_REGISTER`) is in 7.3.0 verouderd: een RTE die in socketmodus lid wordt met een jointoken (`RTE_JOIN_TOKEN`)
+heeft geen `ENCRYPTION_SECRET` nodig, zie [RTE-modi](../rte/modes.html).
+
+---
+
+## Tokens
+
+Een aanmelding geeft een kortlevend access-token en een langer refresh-token terug, waarmee de browser een nieuw paar ophaalt:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : standaard `30m`. Korter
+  beperkt het gebruik van een onderschept token.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : standaard
+  `24h`. Zo lang blijft een inactieve browser aangemeld.
+* De rolinstelling `allowApiTokens` laat een gebruiker een API-token aanvragen dat een aantal dagen geldig is, en
+  `extendedTokenExpiration` voegt er een toe dat nooit verloopt. Geef ze alleen aan rollen die vanuit scripts API-toegang nodig hebben.
+  Op de [profielpagina](../profile/api-token.html) wordt een token gemaakt vanuit een browsersessie die zich maximaal 10 minuten geleden heeft aangemeld,
+  en nooit vanuit een ander API-token. Een token dat nooit verloopt, leeft 50 jaar, en de gebeurtenissen hieronder beëindigen het nog steeds.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : standaard `90`. Het langste dat een API-token
+  leeft: een langere aanvraag wordt daarop ingekort.
+
+Een token is een ondertekende JWT, maar de server houdt ook een lijst met ingetrokken tokens bij, gedeeld door elke app-node, zodat een token
+kan eindigen voordat het verloopt:
+
+| Gebeurtenis | Wat er eindigt |
+|-------|-----------|
+| Afmelden | Elk token van die aanmelding: het access-token, het refresh-token, en een API-token als het afmelden daarmee gebeurt |
+| Een wachtwoordwijziging, door de gebruiker of door een admin | Elk token van de gebruiker dat vóór de wijziging is uitgegeven, API-tokens inbegrepen, op elk apparaat |
+| De schakelaar **Aanmelden toestaan** van een gebruiker uitgezet (lokale, LDAP- of SSO-gebruiker), of een lokale gebruiker verwijderd | Elk token van de gebruiker |
+| **Sessies beëindigen** op de pagina van een LDAP- of SSO-gebruiker | Elk token van de gebruiker; hij kan zich opnieuw aanmelden, tenzij hij geblokkeerd is |
+| **Intrekken** op een API-token, op de profielpagina of op het tabblad **API-tokens** van de gebruiker | Dat ene API-token, meteen |
+
+Een script beëindigt zijn eigen API-token door zich ermee af te melden: `POST /api/v2/auth/logout` met het token in de
+header `Authorization`.
diff --git a/i18n/nl/_configure/seed/environment-and-audit.md b/i18n/nl/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..9dc46f1
--- /dev/null
+++ b/i18n/nl/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Bewerken en audit
+parent: Configuratie-seed
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Bewerken en audit
+{: .no_toc }
+
+De instellingenpagina's vergrendelen, en wat het auditlogboek vastlegt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het bewerken van de omgeving uitschakelen
+
+`ALLOW_ENV_EDIT=0` maakt de instellingenpagina's alleen-lezen. Elke variabele wordt nog steeds getoond met
+de geldende waarde en de reden waarom ze niet kan worden gewijzigd, en het endpoint voor opslaan antwoordt met
+403.
+
+Gebruik het wanneer de omgeving elders wordt gedeclareerd. Anders schrijft de instellingenpagina
+`persistent/.env`, dat op een vluchtig volume bij de volgende herstart ongemerkt verloren gaat, en op
+een duurzaam volume afdrijft van het manifest dat leidend hoort te zijn.
+
+{: .note }
+> Back-ups bevatten `persistent/.env` als `managed.env`, zodat een herbouw de database- en
+> padinstellingen terugkrijgt. **`ENCRYPTION_SECRET` en `ACCESS_TOKEN_SECRET` worden eruit gehaald**:
+> de dump ernaast bevat elke opgeslagen referentie als AES-versleutelde tekst, en de sleutel die
+> die ontsleutelt in dezelfde map schrijven zou een gekopieerde back-up genoeg maken om ze allemaal te lezen. Stel
+> die twee in plaats daarvan op de doelhost in; een opmerking in het bestand vermeldt dat.
+>
+> Wat overblijft, kan nog referenties bevatten (`DB_PASSWORD`, `METRICS_TOKEN`, een oud `VAULT_TOKEN`), dus het bestand wordt
+> geschreven met `0600`. Het terugzetten ervan is een aparte stap waarvoor je bewust kiest, en geen onderdeel van een gewone terugzetting,
+> omdat de databasehost en de paden erin de machine beschrijven waar de back-up vandaan kwam. Het
+> dialoogvenster voor terugzetten toont het bestand en biedt een eigen knop *Omgeving herstellen*
+> (`POST /api/v2/backup/:folder/restore-env`), die het vorige bestand bewaart als `.env.bak`.
+
+---
+
+## Wat er wordt vastgelegd
+
+Elke toepassing die iets wijzigt, schrijft één regel `seed.apply` in het auditlogboek, met
+de objecten die zijn aangemaakt, bijgewerkt, vrijgegeven en opgeschoond. Waarden worden nooit vastgelegd, omdat de meeste
+ervan geheimen zijn. Een toepassing die niets wijzigt, schrijft niets, zodat het trail betekenisvol blijft. Een
+controle die het bestand ongewijzigd vindt, wijzigt niets, dus het trail krijgt er niet elke minuut een rij bij.
+
+Een toepassing die via het endpoint is aangevraagd, wordt bewust twee keer vastgelegd, en de twee rijen
+leggen verschillende dingen vast: `config-seed.apply.create` is **wie** erom vroeg, `seed.apply` is
+**wat** ze wijzigde.
+
+De pagina Status meldt de seed twee keer: een **controle** dat het bestand nog leesbaar en te parsen is,
+en dat de laatste herlaadbeurt is geslaagd, en een **informatie**rij die zegt hoeveel records hij
+momenteel bezit. De controle is de enige plek die meldt wanneer het bestand op schijf en de geldende configuratie
+uit elkaar zijn gelopen, omdat een mislukte herlaadbeurt de instantie laat doordraaien.
diff --git a/i18n/nl/_configure/seed/example.md b/i18n/nl/_configure/seed/example.md
new file mode 100644
index 0000000..822a32b
--- /dev/null
+++ b/i18n/nl/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Voorbeeld
+parent: Configuratie-seed
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Voorbeeld
+{: .no_toc }
+
+Een compleet seedbestand, sectie voor sectie
+{: .fs-6 .fw-300 }
+
+---
+
+Het volgende seedbestand declareert elke sectie behalve `oauth2` en de verouderde `awx`; geheimen komen uit
+omgevingsvariabelen zoals `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` is een van:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : elk ander OpenAI-compatibel endpoint
+
+Net als `ldap` is de sectie `chat` één rij, dus elk veld is verplicht behalve de optionele
+velden; een optioneel veld dat wordt weggelaten, blijft ongewijzigd.
+
+De chat-assistent heeft ook `ENABLE_CHAT=1` nodig; zie de pagina [Chat-assistent](../chat).
+
+Sinds 7.3.0 meldt een runner zich aan met een referentie van zijn type, die het adres van zijn server in `url` bevat. Een runner met een eigen `token`,
+of `username` en `password`, werkt nog: de seed logt een waarschuwing en zet ze om in zo'n referentie, genoemd naar de runner. Een
+runner die een `api`- of `userpass`-referentie noemt, werkt ook nog, met een waarschuwing: geef die referentie in plaats daarvan het type van de runner.
+Beide zijn sinds 7.3.0 verouderd en worden in 8.0.0 verwijderd. Een RTE-runner zonder `rte_mode` staat in databasemodus, verouderd (zie
+[Modi](../rte/modes.html)). Een runner met `enabled: false` krijgt geen job, ook niet als standaard van zijn type (zie
+[Standaard en Ingeschakeld](../runners/list.html#default-and-enabled)); zonder `enabled` laat de seed hem zoals hij is.
+
+Een runneritem neemt naast `name`, `type`, `description`, `credential`, `is_default` en `enabled` deze sleutels:
+
+| Sleutel | Wat ze instelt |
+|---|---|
+| `rte_mode` | De modus van een RTE: `outbound`, `inbound` of `database` (verouderd, de standaard) |
+| `rte_max_jobs` | De **Max. gelijktijdige jobs** van een RTE in socketmodus, `0` tot `10000` (`0`: geen limiet) |
+| `rte_cache_mb` | De **Cache voor jobbestanden** in MB, `0` tot `1048576` (`0` bewaart niets) |
+| `rte_files` | De **Jobbestanden**: `transfer` of `local` |
+| `rte_drain_seconds` | De **Wachttijd bij stoppen** in seconden, `0` tot `86400` |
+| `flavour` | Een `awx`-runner die een AAP of een Ascender is: `aap` of `ascender`; geen voor AWX |
+| `project` | Het project-id van een Semaphore-runner, de projectnaam van een Rundeck-runner, de map van een Jenkins-runner |
+| `uri`, `ignore_certs`, `ca_bundle` | Het eigen adres en de TLS van de runner, van vóór 7.3.0: alleen gebruikt zolang zijn referentie geen `url` bevat |
+
+De vier `rte_*`-instellingen zijn die van het tabblad RTE van de runnerpagina (zie [De instellingen van een RTE](../runners/runner-page.html#an-rtes-settings)):
+ze winnen van dezelfde variabelen die op de RTE zijn ingesteld, en een RTE in databasemodus negeert ze. Een waarde buiten het bereik laat de
+validatie van de seed mislukken.
+
+Een RTE in databasemodus kan zichzelf registreren voordat de seed wordt toegepast. Een RTE-runner uit de seed waarvan de `uri` het adres is waarop zo'n RTE
+zich registreerde, **neemt** die rij **over**: hij krijgt de gedeclareerde naam en velden, en de worker verwijdert hem niet meer als de RTE niet meer
+antwoordt, in plaats van een tweede runner voor dezelfde RTE.
diff --git a/i18n/nl/_configure/seed/index.md b/i18n/nl/_configure/seed/index.md
new file mode 100644
index 0000000..a93069c
--- /dev/null
+++ b/i18n/nl/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Configuratie-seed
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Configuratie-seed
+{: .no_toc }
+
+De beheerobjecten in een bestand declareren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders die vanuit git uitrollen: declareer de beheerobjecten in een bestand, zodat een instantie op een lege database opnieuw kan worden opgebouwd.
+
+---
+
+## Wat het dekt
+
+Stel `CONFIG_SEED_PATH` in op een YAML-bestand, en AnsibleForms past het bij het opstarten toe. Het bestand
+declareert objecten die voorheen alleen in de database bestonden:
+
+| Sectie                  | Wat ze declareert                                                   |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Waar jobs draaien: RTE's, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Secret stores (HashiCorp Vault, ...)                                |
+| `credentials`           | Referenties                                                         |
+| `oauth2`                | SSO-providers: Entra ID en OIDC                                     |
+| `repositories`          | Git-repositories                                                    |
+| `syslog_servers`        | De syslogservers die het serverlog en de auditregels krijgen        |
+| `notification_channels` | Mailservers, Slack, Teams, Telegram en webhooks voor meldingen      |
+| `labels`                | De labels naast het logo in de kopbalk, vanaf 7.3.0                 |
+| `ldap`                  | De LDAP-configuratie                                                |
+| `settings`              | De publieke URL, en de mailinstellingen die worden gebruikt als er geen mailkanaal actief is |
+| `chat`                  | De modelprovider van de chat-assistent                              |
+| `awx`                   | Verouderd sinds 7, verwijderd in 8: gebruik `runners` met `type: awx` |
+
+Een seed die vóór 7 is geschreven, blijft werken: elk item van de sectie `awx` wordt toegepast als runner van het type `awx`, en het log
+waarschuwt bij elke toepassing. Verplaats die items naar `runners` met `type: awx` voordat je naar 8 upgradet.
+
+De seed is **niet** hetzelfde als `config.yaml`, dat de categorieën, rollen en constanten bevat
+en een eigen `CONFIG_PATH` heeft. De twee worden bewust gescheiden gehouden: de
+repository die `config.yaml` *bevat*, is een van de objecten die de seed declareert, dus de seed
+kan er niet in staan.
+
+Gebruikers en groepen blijven erbuiten: die komen uit LDAP of SSO, en de eerste admin uit `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Voorbeeld](example.html) | Een compleet seedbestand, sectie voor sectie |
+| [Beheerde objecten](managed-objects.html) | Hoe de seed eigenaar is van de objecten die hij noemt, en hoe hij geheimen buiten houdt |
+| [Herladen en opstarten](reloading.html) | Het bestand wijzigen zonder herstart, en wat er bij het opstarten gebeurt |
+| [Kubernetes](kubernetes.html) | AnsibleForms uitrollen vanuit een ConfigMap en Secrets |
+| [Bewerken en audit](environment-and-audit.html) | De instellingenpagina's vergrendelen, en wat het auditlogboek vastlegt |
diff --git a/i18n/nl/_configure/seed/kubernetes.md b/i18n/nl/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..fc03d9d
--- /dev/null
+++ b/i18n/nl/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Configuratie-seed
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+AnsibleForms uitrollen vanuit een ConfigMap en Secrets
+{: .fs-6 .fw-300 }
+
+---
+
+Koppel de seed vanuit een `ConfigMap` en de geheimen ervan vanuit een `Secret`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Eén pod, met `AF_ROLE` niet ingesteld.** Deze pod draait de webapp en de worker in één proces. De planningen, de nachtelijke
+> back-up en het andere achtergrondwerk draaien alleen in het proces dat de workervergrendeling in de database vasthoudt, de designer-vergrendeling
+> is een databasetabel, en de playbooks draaien op een RTE, niet in deze pod. Houd toch `replicas: 1` met de strategie
+> `Recreate` aan: bij een upgrade wacht de nieuwe pod tot de worker het schema heeft gepatcht, en de oude pod houdt de
+> workervergrendeling vast tot hij stopt. Om meerdere webnodes te draaien, splits je ze op in `AF_ROLE=app`-nodes en een worker, zoals
+> [Schalen](../production/scaling.html) beschrijft.
+
+`ENCRYPTION_SECRET` moet zijn ingesteld voordat er een referentie wordt ingevoerd. Zodra referenties uit de seed
+komen, is de database in feite een cache, dus roteren betekent de seed opnieuw toepassen
+in plaats van alles met de hand opnieuw in te voeren.
+
+De twee probes vereisen geen aanmelding. Onder een [`BASE_URL`](../customization/server.html#env_BASE_URL) beginnen hun paden daarmee, en
+[Monitoring](../production/monitoring.html) beschrijft wat elke probe controleert.
diff --git a/i18n/nl/_configure/seed/managed-objects.md b/i18n/nl/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..ec66c8f
--- /dev/null
+++ b/i18n/nl/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Beheerde objecten
+parent: Configuratie-seed
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Beheerde objecten
+{: .no_toc }
+
+Hoe de seed eigenaar is van de objecten die hij noemt, en hoe hij geheimen buiten houdt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Secties van één rij zijn alles of niets
+
+`ldap`, `settings` en `chat` zijn elk **één rij**, dus de seed moet al hun velden declareren; de andere secties zijn lijsten.
+
+Een seed die een veld weglaat, weigert te starten en noemt het veld:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Declareer een lege waarde expliciet met `""` of `false`. Een paar velden zijn optioneel, en een optioneel veld dat wordt weggelaten, blijft ongewijzigd:
+
+| Sectie | Optionele velden |
+|---|---|
+| `ldap` | `description`, `credential` (een referentie om mee te binden) en `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` en `extra_headers` |
+| `settings` | Geen |
+
+`settings` dekt alleen de mailvelden en de URL; alle andere instellingen blijven bewerkbaar.
+
+---
+
+## Het bestand bevat geen geheimen
+
+Elke `${VARIABLE}` wordt vervangen door die omgevingsvariabele (op Kubernetes uit een `Secret`), zodat het bestand in Git kan staan.
+
+Een variabele die niet is ingesteld, is een **fatale fout**, zodat een placeholder nooit als wachtwoord kan worden opgeslagen.
+
+Referenties kunnen ook een [secret store](../secret-stores) gebruiken (`secret_store`, `secret_ref`); `vault_path` verdwijnt in 8.
+
+---
+
+## Beheerde objecten
+
+Een object dat uit de seed komt, wordt gemarkeerd als **beheerd**:
+
+- Het wordt bij **elke** start afgedwongen, zodat het bestand leidend blijft.
+- Het is alleen-lezen: de API antwoordt met **403**, de interface schakelt Bewerken en Verwijderen uit, en de eigen pagina zegt dat het uit het
+  configuratie-seedbestand komt en alleen-lezen is.
+- Alleen de seed kan de markering zetten of wissen.
+
+Objecten die met de hand zijn aangemaakt, worden **nooit aangeraakt**, tenzij de seed dezelfde naam declareert. Dat record wordt dan **overgenomen**:
+de gedeclareerde velden worden afgedwongen en het wordt alleen-lezen. Overname wordt gelogd als waarschuwing en in het audittrail.
+
+Het toepassen van de seed is idempotent: records die al overeenkomen, blijven ongemoeid, dus een herstart meldt normaal `0 updated`.
+
+Een gedeclareerde repository waarvan de werkboom ontbreekt, wordt bij elke start **opnieuw gekloond**, zodat een mislukte eerste kloon
+opnieuw wordt geprobeerd. De rij *Repositories* van de pagina Status toont elke repository zonder werkboom.
+
+### Een object verwijderen
+
+Een object uit het bestand verwijderen **geeft het vrij**: het record blijft bestaan en wordt weer bewerkbaar. Een hele sectie verwijderen
+doet hetzelfde.
+
+Voeg `prune: true` toe aan een lijstsectie om de beheerde records te **verwijderen** die het bestand niet meer declareert:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` verwijdert nooit een record dat met de hand is aangemaakt.
+
+### De seed uitschakelen
+
+Het verwijderen van `CONFIG_SEED_PATH` geeft **niets** vrij: de seed wordt niet meer toegepast, en de records die hij beheerde blijven beheerd
+en alleen-lezen. Om ze weer te bewerken, geef je ze eerst vrij: laat `CONFIG_SEED_PATH` naar een bestand zonder die records wijzen (een leeg bestand declareert
+niets en geeft elk record vrij), laat het toepassen bij een start of een herlaadbeurt, en verwijder dan de variabele. De vrijgegeven records blijven zoals ze
+zijn, en worden bewerkbaar.
diff --git a/i18n/nl/_configure/seed/reloading.md b/i18n/nl/_configure/seed/reloading.md
new file mode 100644
index 0000000..1e5e762
--- /dev/null
+++ b/i18n/nl/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Herladen en opstarten
+parent: Configuratie-seed
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Herladen en opstarten
+{: .no_toc }
+
+Het bestand wijzigen zonder herstart, en wat er bij het opstarten gebeurt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het bestand wijzigen zonder herstart
+
+De seed wordt elke `CONFIG_SEED_RELOAD_SECONDS` opnieuw gelezen (standaard 60, `0` schakelt het uit)
+en opnieuw toegepast als de inhoud is gewijzigd. Een wijziging die in git is gecommit, bereikt daardoor automatisch een
+draaiende instantie: op Kubernetes wordt een `ConfigMap` binnen ongeveer een minuut opnieuw onder de pod gekoppeld,
+en de volgende controle pikt hem op. Er is geen rollout en geen herstart, en geen
+hook hoeft iets aan te roepen.
+
+Voor een ongewijzigd bestand berekent de controle één hash en stopt, dus ze herschrijft nooit een rij die ze al
+heeft toegepast.
+
+Om het bestand meteen toe te passen in plaats van op de volgende controle te wachten, gebruik je een van deze:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Beide **forceren** een toepassing, ook als het bestand niet is gewijzigd. Een geforceerde toepassing herstelt een
+beheerd record dat rechtstreeks in de database is bewerkt, en kloont een gedeclareerde repository opnieuw
+waarvan de werkboom ontbreekt.
+
+{: .note }
+> Een herlaadbeurt is **nooit fataal**, in tegenstelling tot de toepassing bij het opstarten. Een instantie die al
+> draait, behoudt haar huidige configuratie, de reden wordt gelogd, en de rij *Configuratie-seed*
+> op de pagina Status wordt rood en noemt de reden. Een typfout die naar git is gepusht, mag een draaiende instantie
+> niet kunnen platleggen zonder dat een beheerder iets doet.
+>
+> Dezelfde kapotte inhoud wordt ook niet bij elke controle opnieuw geprobeerd; anders zou één slechte wijziging
+> eindeloos dezelfde fout in het log schrijven. Herstel het bestand, of roep het endpoint aan om het
+> meteen opnieuw te proberen.
+
+---
+
+## Een kapotte seed weigert te starten
+
+Een onleesbaar bestand, ongeldige YAML, een onbekend veld, een dubbele naam of een niet-opgeloste
+`${VARIABLE}` laat de server **afsluiten** in plaats van starten. Dit geldt alleen voor het **opstart**pad:
+zie de opmerking hierboven voor wat hetzelfde bestand doet met een instantie die al draait.
+
+Dit is bewust. Doorgaan met de vorige configuratie zou een instantie opleveren waarvan het
+gedrag niet meer overeenkomt met het manifest dat haar zou moeten beschrijven, zonder dat iets
+het verschil meldt. De reden wordt naar standard error en naar het logbestand geschreven, zodat
+`kubectl logs` en `docker logs` hem tonen.
+
+De validatie is streng: onbekende velden worden geweigerd in plaats van genegeerd, en de fout noemt
+de foute sleutel:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Een lege database richt zichzelf in
+
+Met `ALLOW_SCHEMA_CREATION` aan (de standaard) krijgt een database die **helemaal geen
+AnsibleForms-tabellen** bevat bij het opstarten haar schema. Een nieuwe uitrol start daardoor
+zonder dat iemand het endpoint `/schema` met de hand hoeft aan te roepen.
+
+De voorwaarde is bewust streng: het aanmaken van het schema **verwijdert eerst elke tabel**, dus
+het draait alleen tegen een database die helemaal leeg is. Een database waarin één kolom ontbreekt, of
+die tabellen maar geen gebruikersaccounts heeft, is *niet* leeg en blijft onaangeroerd;
+de schemapatches handelen die gevallen af.
diff --git a/i18n/nl/_configure/users-and-groups.md b/i18n/nl/_configure/users-and-groups.md
new file mode 100644
index 0000000..96fe196
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Gebruikers en groepen
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Gebruikers en groepen
+{: .no_toc }
+
+De lokale gebruikers en groepen, de LDAP- en single sign-on-gebruikers en -groepen ernaast, en een aanmelding blokkeren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: beheer wie zich mag aanmelden onder **Instellingen > Toegang > Gebruikers** en **Groepen**, met de rolinstelling `showSettings`.
+
+De ingebouwde admin, de aanmeldvolgorde en de rolkoppeling van lokale accounts staan op [Lokale accounts](authentication/local.html).
+
+---
+
+## In deze sectie
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Een lokale gebruiker](users-and-groups/local-user.html) | Een lokale gebruiker toevoegen, en de tabbladen van zijn pagina |
+| [Meerdere groepen](users-and-groups/several-groups.html) | Een lokale gebruiker in meerdere groepen, en zijn rollen |
+| [Een lokale groep](users-and-groups/local-group.html) | De pagina van een lokale groep en haar tabbladen |
+| [Directorygebruikers en -groepen](users-and-groups/directory.html) | Gebruikers en groepen van LDAP, Entra ID en OIDC, zoals laatst gezien |
+| [Een aanmelding blokkeren](users-and-groups/blocking-a-sign-in.html) | Aanmelden toestaan: een gebruiker blokkeren zonder iets te verwijderen |
+
+
+---
+
+## De lijsten
+
+De lijsten **Gebruikers** en **Groepen** tonen de lokale gebruikers en groepen en, daarnaast, die van LDAP en single sign-on.
+
+Een gebruiker of groep van LDAP, Entra ID of OIDC verschijnt in de lijst zodra hij zich heeft aangemeld (of bij een aanmelding is gezien), of zodra een rol hem noemt.
+De kolom **Bron** zegt waar elk vandaan komt: Lokaal, LDAP, Microsoft Entra ID of OIDC. Vanaf 7.3.0 heeft de lijst **Gebruikers** ook
+een kolom **Laatst aangemeld**, die zegt wanneer elke gebruiker zich voor het laatst heeft aangemeld.
+
+Een rij opent de pagina van de gebruiker of groep. **Gebruiker toevoegen** en **Groep toevoegen** maken een lokale aan.
+
+---
+
+## Accounts die admin geven
+
+De rol admin in config.yaml noemt lokale groepen en gebruikers, dus alleen een admin mag de accounts en groepen wijzigen die hij noemt.
+
+Een gebruiker met `showSettings` maar zonder de rol admin kan een lokaal account dat de rol admin noemt (rechtstreeks of via een van zijn groepen) niet wijzigen,
+blokkeren, in andere groepen plaatsen, er het wachtwoord van instellen of het verwijderen. Hij kan ook geen groep aanmaken, hernoemen of verwijderen
+die de rol admin noemt, of er een gebruiker in plaatsen. Hetzelfde geldt voor een LDAP- of SSO-gebruiker die aan de rol admin is gekoppeld: hem blokkeren,
+zijn sessies beëindigen, hem vergeten en zijn API-tokens intrekken zijn voorbehouden aan een admin. De server beantwoordt zo'n verzoek met `403`.
+
diff --git a/i18n/nl/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/nl/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..9e22107
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Een aanmelding blokkeren
+parent: Gebruikers en groepen
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Een aanmelding blokkeren
+{: .no_toc }
+
+Aanmelden toestaan: een gebruiker blokkeren zonder iets te verwijderen
+{: .fs-6 .fw-300 }
+
+De schakelaar **Aanmelden toestaan** blokkeert een gebruiker, lokaal of uit een directory, zonder iets te verwijderen.
+
+Uitgezet, na een bevestiging, eindigen de sessies van de gebruiker meteen en wordt elke aanmelding geweigerd totdat je hem weer aanzet.
+De gebruikerslijst heeft daarvoor **Aanmelden blokkeren** en **Aanmelden toestaan** in het menu van elke rij.
+
+Je kunt de gebruiker `admin` niet blokkeren, en ook je eigen aanmelding niet.
diff --git a/i18n/nl/_configure/users-and-groups/directory.md b/i18n/nl/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..b7a216b
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Directorygebruikers en -groepen
+parent: Gebruikers en groepen
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Directorygebruikers en -groepen
+{: .no_toc }
+
+Gebruikers en groepen van LDAP, Entra ID en OIDC, zoals laatst gezien
+{: .fs-6 .fw-300 }
+
+Een gebruiker van LDAP, Entra ID of OIDC heeft zijn pagina op `/settings/users/<source>/<name>`, met `ldap`, `azuread` of `oidc`
+als bron, zoals `/settings/users/ldap/jdoe`. Die toont wat bij de laatste aanmelding van de gebruiker is vastgelegd, alleen-lezen,
+omdat de directory of de identity provider bepaalt wie de gebruiker is en wat zijn groepen zijn.
+
+De tabbladen zijn die van een lokale gebruiker. **Details** heeft de schakelaar **Aanmelden toestaan**, de gebruikersnaam, de bron, de naam,
+het e-mailadres, wanneer de gebruiker voor het eerst is gezien en zijn laatste aanmelding. **Groepen** toont de groepen van de laatste aanmelding.
+**API-tokens** toont de API-tokens van de gebruiker, en **Intrekken** beëindigt er een meteen.
+
+Rechtsboven meldt **Sessies beëindigen** de gebruiker nu overal af. **Vergeten** verwijdert het record, dat bij de volgende aanmelding
+terugkomt; zijn jobs, opgeslagen jobs en planningen blijven bestaan. Een geblokkeerde gebruiker kan niet worden vergeten, omdat hij dan
+weer binnen zou komen: de server antwoordt met `409`, dus sta eerst zijn aanmelding toe.
+
+De groepen van dit record zijn ook de groepen waarmee de sessie van de gebruiker werkt, live gelezen. Een aangemelde gebruiker vergeten
+laat hem zonder groepen achter, en zonder de rollen die die groepen geven, totdat hij zich opnieuw aanmeldt.
+
+Een directorygroep heeft haar pagina op `/settings/groups/<source>/<name>`, alleen-lezen, met de tabbladen **Details**,
+**Gebruikers** (de gebruikers die er bij hun laatste aanmelding in zijn gezien), **Rollen** en **Formulieren**.
diff --git a/i18n/nl/_configure/users-and-groups/local-group.md b/i18n/nl/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..7107c35
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Een lokale groep
+parent: Gebruikers en groepen
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Een lokale groep
+{: .no_toc }
+
+De pagina van een lokale groep en haar tabbladen
+{: .fs-6 .fw-300 }
+
+De pagina van een groep, `/settings/groups/<id>`, heeft deze tabbladen:
+
+| Tabblad | Wat het toont |
+|---|---|
+| **Details** | De naam en de beschrijving |
+| **Gebruikers** | De gebruikers in de groep; **Gebruiker toevoegen** voegt er een toe, het menu van een rij of de selectievakjes verwijderen er een |
+| **Rollen** | De rollen die de groep noemen |
+| **Formulieren** | De formulieren die die rollen openen |
+
+Een groep met gebruikers kan niet worden verwijderd: verwijder eerst de gebruikers. De groep `admins` kan nooit worden verwijderd of hernoemd.
diff --git a/i18n/nl/_configure/users-and-groups/local-user.md b/i18n/nl/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..9300069
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Een lokale gebruiker
+parent: Gebruikers en groepen
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Een lokale gebruiker
+{: .no_toc }
+
+Een lokale gebruiker toevoegen, en de tabbladen van zijn pagina
+{: .fs-6 .fw-300 }
+
+**Gebruiker toevoegen** opent een wizard in drie stappen: **Gebruiker** (gebruikersnaam, beschrijving, e-mail), **Wachtwoord** en **Groep**.
+
+De pagina van een gebruiker, `/settings/users/<id>`, heeft deze tabbladen:
+
+| Tabblad | Wat het toont |
+|---|---|
+| **Details** | De schakelaar **Aanmelden toestaan**, de gebruikersnaam, de beschrijving, het e-mailadres en, vanaf 7.3.0, **Laatst aangemeld** |
+| **Groepen** | De groepen waartoe de gebruiker behoort |
+| **Rollen** | De rollen die de gebruiker heeft, en waar elke rol vandaan komt: **Direct**, **Via** een groep, of **Iedereen** |
+| **Formulieren** | De formulieren die die rollen openen |
+| **Jobs** | De jobs die de gebruiker heeft gestart, de nieuwste eerst |
+| **Opgeslagen invoer** | De formulierwaarden die de gebruiker heeft opgeslagen om opnieuw uit te voeren |
+| **Planners** | De jobs die de gebruiker met Later uitvoeren heeft gepland |
+| **Activiteit** | Wat het auditlogboek de gebruiker heeft zien doen |
+| **API-tokens** | De API-tokens van de gebruiker, met wanneer elk is aangemaakt, verloopt en voor het laatst is gebruikt; **Intrekken** beëindigt er een meteen |
+
+Vanaf 7.3.0 worden de aanmeldingen van een lokale gebruiker vastgelegd, zoals dat bij een LDAP- of SSO-gebruiker al gebeurde: **Laatst aangemeld** toont de laatste, en
+de gebruikerslijst heeft voor elke bron een sorteerbare kolom **Laatst aangemeld**, zodat een account dat niemand gebruikt opvalt. Een geweigerde aanmelding wordt niet
+vastgelegd, en een lokale gebruiker die zich sinds de upgrade niet heeft aangemeld, toont `–`.
+
+**Wachtwoord wijzigen** en **Verwijderen** staan rechtsboven. De gebruiker `admin` kan nooit worden verwijderd of hernoemd.
diff --git a/i18n/nl/_configure/users-and-groups/several-groups.md b/i18n/nl/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..2456d51
--- /dev/null
+++ b/i18n/nl/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Meerdere groepen
+parent: Gebruikers en groepen
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Meerdere groepen
+{: .no_toc }
+
+Een lokale gebruiker in meerdere groepen, en zijn rollen
+{: .fs-6 .fw-300 }
+
+Een lokale gebruiker kan tot meerdere groepen behoren, en krijgt de rollen van elk daarvan: rollen noemen een groep `local/<group>`.
+
+Op het tabblad **Groepen** voegt **Groep toevoegen** de gebruiker aan een andere groep toe, en het menu van een rij of de selectievakjes verwijderen er een.
+Een gebruiker houdt minstens één groep. De gebruikerslijst heeft daarvoor **Aan groep toevoegen** in het menu van elke rij.
diff --git a/i18n/nl/_get_started/first-form.md b/i18n/nl/_get_started/first-form.md
new file mode 100644
index 0000000..5022b95
--- /dev/null
+++ b/i18n/nl/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: Je eerste formulier
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# Je eerste formulier
+{: .no_toc }
+
+Schrijf een playbook, bouw er in de Designer een formulier voor, start het en zoek de job terug
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Deze tutorial gaat uit van een verse installatie, zie [Installatie](installation/). Reken op ongeveer een kwartier.
+
+---
+
+## 1. Meld je aan
+
+Open AnsibleForms in een browser en meld je aan als beheerder.
+
+Het standaardaccount is `admin` / `AnsibleForms!123` (of je eigen [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)-waarden); de pagina **Formulieren** gaat open:
+
+![De pagina Formulieren, met voorbeeldformulieren](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Schrijf het playbook
+
+Een `ansible`-formulier voert een playbook uit de map met playbooks uit, dus het playbook komt eerst. Sla dit op als `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+Het playbook leest vier variabelen. Het formulier dat je hierna bouwt stuurt ze mee als extravars, één per veld.
+
+Zet het bestand in de map `playbooks` van de persistente map
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); maak de map aan als die nog niet bestaat:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Vanuit de broncode</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+De map die je op `/app/dist/persistent` hebt gekoppeld, `/srv/apps/ansibleforms/persistent` in het installatievoorbeeld:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+De map `data/playbooks` van het docker-compose-project:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+Het persistente volume, gekoppeld op `/app/dist/persistent` in de AnsibleForms-pod. Zoek de naam van de pod op en kopieer het bestand erin:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+De map `persistent/playbooks` van de server, `/srv/apps/ansibleforms/server` in het installatievoorbeeld:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Als bij een git-repository **Gebruiken voor playbooks** aan staat, worden playbooks in plaats daarvan uit die repository uitgevoerd:
+> commit `hello.yaml` daar. Zie [Designer en git](gui/designer-and-git.html).
+
+---
+
+## 3. Maak het formulier
+
+Formulieren zijn YAML-bestanden in de map met formulieren. De Designer bewerkt ze in de browser en controleert ze voordat hij ze opslaat.
+
+1. Klik op **Ontwerper** in het bovenste menu en daarna op **Formulieren** in het linkermenu.
+2. Klik op de schakelaar rechtsboven (**Start designer**). Die vergrendelt de configuratie zodat niemand anders haar tegelijk
+   bewerkt, en toont daarna **Vergrendeld door mij**.
+3. Klik op **Nieuw bestand**, de eerste knop van de werkbalk, en geef de bestandsnaam `hello-world.yaml` op. De Designer voegt er
+   een formulier met de naam `New Form` aan toe.
+4. Vervang de YAML in de editor door dit formulier:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Klik op **Valideren** (het vinkje) en daarna op **Opslaan**. Bij het opslaan wordt `hello-world.yaml` in de map met formulieren geschreven.
+6. Klik opnieuw op de schakelaar om de vergrendeling vrij te geven.
+
+![De Designer, tijdens het bewerken van een formulier](assets/screenshots/designer.jpg)
+
+Het formulier gebruikt vier veldtypen:
+
+| Veld | Type | Wat het doet |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Een verplicht tekstvak |
+| `target_env` | [`enum`](formfields/enum.html) | Een keuzelijst met een vaste lijst `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Een keuzelijst gevuld door een lokale [expressie](expressions/local.html); `__auto__` selecteert het eerste item |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Een selectievakje, verstuurd als `true` of `false` |
+
+`vm_size` toont beide kolommen, `size` en `cpus`, en verstuurt `size`, de eerste; met `valueColumn` kies je een andere.
+
+Met `roles: [default]` mag elke aangemelde gebruiker het formulier uitvoeren, en `categories: [Default]` zet het in de categorie die de standaard-
+`config.yaml` definieert.
+
+{: .note }
+> Je kunt `hello-world.yaml` ook naar [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) kopiëren en [het in VS Code valideren](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Start het
+
+Open het formulier vanaf de pagina **Formulieren**: klik op **Formulieren** in het bovenste menu en kies **Hello world** in de categorie **Default**.
+
+Vul je naam in en pas de andere velden aan als je wilt. Klik op **Toon extravars** om te zien wat het playbook
+ontvangt, en klik daarna op **Verzenden**:
+
+![Een formulier](assets/screenshots/form.jpg)
+
+---
+
+## 5. Bekijk de uitvoer
+
+De job start meteen, en de uitvoer verschijnt onder het formulier terwijl hij loopt, met aan het eind een balk **Voltooid**:
+
+![De uitvoer van een job](assets/screenshots/run.jpg)
+
+De debug-taak toont je waarden, bijvoorbeeld `Hello Alice: a small machine in development (dry run: True)`.
+
+De waarschuwing over de impliciete localhost is normaal zonder inventory; een echt formulier stelt [`inventory`](forms/ansible.html) in.
+
+---
+
+## 6. Vind het terug in de jobgeschiedenis
+
+Elke start wordt bewaard als job. Klik op **Taken** in het bovenste menu: de nieuwe job staat bovenaan in **Alle jobs**.
+
+Klik op de job om de uitvoer opnieuw te zien, en op **Toon extravars** om te zien wat er verstuurd is. Met de pictogrammen vóór elke job
+start je hem opnieuw of verwijder je hem:
+
+![De jobgeschiedenis](assets/screenshots/job-output.jpg)
+
+---
+
+## Volgende stappen
+
+Bouw verder op dit formulier met de referentiepagina's:
+
+* **[Formulieren](forms/)** : elke eigenschap van een formulier, templates op runners, workflowformulieren, goedkeuringspunten en meldingen
+* **[Formuliervelden](formfields/)** : alle veldtypen, met validatie, afhankelijkheden en opmaak
+* **[Expressies](expressions/)** : vul velden vanuit REST API's, databases en bestanden
+* **[Rollen](config/roles.html)** en **[categorieën](config/categories.html)** in `config.yaml` : bepaal wie welk formulier ziet
+* **[Hoe het werkt](how-it-works.html)** : wat er achter een start gebeurt, en waar alles wordt opgeslagen
diff --git a/i18n/nl/_get_started/installation/docker-compose.md b/i18n/nl/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..6e1c4ae
--- /dev/null
+++ b/i18n/nl/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Installatie
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Installeer AnsibleForms, de RTE en MySQL samen met docker-compose of podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Het [docker-compose-project](https://github.com/ansibleforms/docker) draait drie containers: MySQL, de AnsibleForms-app en de RTE
+(runtime-omgeving) die de playbooks uitvoert. Het bevat hun instellingen, voorbeeldformulieren en playbooks, dus het enige andere vereiste is
+Docker of Podman met de bijbehorende compose-tool.
+
+Het [installatieprogramma](installer.html) downloadt dit project, vult de instellingen en secrets in en start het, in één commando. Deze pagina
+zet het met de hand op.
+
+---
+
+## Vereisten
+
+Voordat je begint, heb je nodig:
+
+* **Linux-machine** : elke distributie, met bescheiden CPU en geheugen
+* **Toegang tot GitHub** : om het docker-compose-project van GitHub te downloaden of te clonen
+* **Docker of Podman** : een container-engine, hieronder geïnstalleerd
+* **Een compose-tool** : Docker Compose of podman-compose, om de drie containers vanuit een paar configuratiebestanden te starten
+
+**VIDEO**: [AnsibleForms installeren](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Kies een installatielocatie
+
+Maak een map voor het project; de voorbeelden gebruiken `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Clone het docker-compose-project
+
+Installeer Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Clone daarna het docker-compose-project in die map:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Stel de juiste rechten in
+
+De app en de RTE draaien als de gebruiker `node` (uid 1000), dus maak die gebruiker eigenaar van de map `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Kom je van 6, waarvan de container als root draaide, voer dan dezelfde `chown` één keer uit voordat je 7 start. MySQL neemt zijn eigen map bij het starten weer over.
+
+---
+
+## Installeer een container-engine
+
+Installeer Docker of Podman, elk met de bijbehorende compose-tool:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Installeer Docker Engine met de Compose-plugin uit de repository van Docker
+(zie de [installatiehandleidingen van Docker](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Zorg er daarna voor dat namen binnen de containers worden opgelost, en start Docker als service:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman heeft geen service nodig. Installeer het samen met podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Aanpassen
+
+Bekijk de variabelen in de bestanden `.env` en `docker-compose.yml`, en wijzig elk wachtwoord: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` en `RTE_TOKEN`. [Meer over de omgevingsvariabelen](../customization)
+
+De app maakt verbinding met MySQL als `ansibleforms` (`MYSQLDB_USER`), met alle rechten op het schema `AnsibleForms` en nergens
+anders; root is alleen voor MySQL zelf. MySQL maakt die gebruiker alleen bij de eerste start aan: een installatie die tot nu toe als root
+verbond, maakt hem één keer aan, zoals de [README](https://github.com/ansibleforms/docker#database) van het project laat zien.
+
+De RTE wordt niet op de host gepubliceerd. Sinds 7.3.0 belt de app hem aan op `http://rte:8000` met `RTE_TOKEN` en houdt één WebSocket open
+(`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)): de RTE krijgt geen database-instellingen en niet de `.env`, alleen zijn token en een paar
+eigen instellingen in `docker-compose.yml`. De config seed `data/seed.yaml` declareert een RTE-referentie met het token en dat
+adres, en de standaardrunner `rte`, modus inbound, die zich daarmee aanmeldt. De RTE voert de playbooks uit vanuit dezelfde map `data`
+(`RTE_FILES=local`). Hebben je playbooks meer collections of Python-bibliotheken nodig, bouw dan een eigen RTE
+en laat de service `rte` daarnaar wijzen (zie [Bouw je eigen RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Start het docker-compose-project
+
+Start de drie containers op de achtergrond. De app wacht tot MySQL gezond is en belt dan de RTE aan:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Test de applicatie
+
+Zodra de containers draaien, open je AnsibleForms in een browser:
+
+* Open `https://your_ip` (poort 443, zie `WEBAPP_LOCAL_PORT` in het .env-bestand)
+* Meld je aan als `admin` met het `ADMIN_PASSWORD` uit het `.env`-bestand; zolang dat nog de standaardwaarde `AnsibleForms!123` is, kies je een nieuw wachtwoord
+* Controleer onder **Verbindingen > Runners** dat de RTE in de lijst staat als `rte`, de standaardrunner, en dat zijn pagina bij
+  **Verbinding** de status **Verbonden** toont
+* Volgende stappen:
+  * Maak formulieren door YAML-bestanden aan de map data/forms/ toe te voegen of met de ingebouwde designer
+  * Zet je playbooks in de map data/playbooks/
+  * Voeg een LDAP-verbinding toe
+  * Voeg gebruikers en groepen toe
+  * Voeg runners toe voor templateformulieren: AWX, AAP of Ascender, Semaphore, Rundeck of Jenkins
+  * Voeg referenties toe voor externe verbindingen, zoals andere MySQL-servers of REST API's, of om aan Ansible-playbooks door te geven
+  * Koppel Git-repositories en kies of je formulieren en/of playbooks met een repository synchroniseren
+
+---
+
+## Bestandsstructuur
+
+Het docker-compose-project heeft de volgende mappenstructuur:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/nl/_get_started/installation/docker.md b/i18n/nl/_get_started/installation/docker.md
new file mode 100644
index 0000000..866e567
--- /dev/null
+++ b/i18n/nl/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Installatie
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Draai de images van de AnsibleForms-app en de RTE met Docker of Podman, naast een eigen MySQL-server
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Je kunt AnsibleForms met Docker of Podman draaien als twee containers, de app en de RTE die de playbooks uitvoert, verbonden met een MySQL-database.
+
+---
+
+## Vereisten
+
+Voordat je begint, heb je nodig:
+
+* **Docker of Podman** : een van beide geïnstalleerd en actief
+* **MySQL** : geïnstalleerd en actief
+
+---
+
+## Installeer MySQL
+
+Installeer MySQL 8+, of MariaDB, op een Linux-server die de container kan bereiken:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu levert MySQL 8 mee:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian levert MariaDB mee in plaats van MySQL, en dat ondersteunt AnsibleForms ook:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 en later, en de rebuilds ervan, leveren MySQL 8 mee in AppStream:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms maakt via het netwerk verbinding met de database, als `DB_USER` met `DB_PASSWORD`. Geef het een eigen gebruiker, met rechten op
+alleen het schema `AnsibleForms`, niet root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Meer heeft AnsibleForms niet nodig: daarmee maakt en patcht het zijn schema en maakt het zijn back-ups. De pagina **Status** en het log
+waarschuwen als de gebruiker rechten op alle databases heeft. Op Ubuntu en Debian luistert de server alleen op localhost: stel `bind-address` in de
+configuratie ervan in zodat de containers hem kunnen bereiken.
+
+---
+
+## Bereid de mappen voor
+
+AnsibleForms 7 draait in twee containers: de app, en de RTE (runtime-omgeving) die de playbooks uitvoert. Beide koppelen een map voor
+je `config.yaml`, formulieren, playbooks, logs en certificaten, en een map voor de SSH-sleutel. De images draaien als de gebruiker `node` (uid 1000),
+dus maak die gebruiker eigenaar van beide mappen:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Zet de instellingen van de app in een omgevingsbestand: de databaseverbinding,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) voordat je ook maar één referentie opslaat, het token dat de app en de
+RTE delen ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), minstens 16 tekens) en de config seed die de RTE declareert:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+De RTE krijgt een eigen bestand, zonder de instellingen van de database: sinds 7.3.0 belt de app hem aan en houdt één WebSocket open
+(`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)), en hij voert de playbooks uit vanuit dezelfde mappen (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+De [config seed](../seed/) declareert een RTE-referentie met het adres en het token van de RTE, en de standaardrunner `rte` die zich
+daarmee aanmeldt:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Start de containers
+
+Draai de gepubliceerde images uit de GitHub Container Registry (zie [Image-tags](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) voor de app en
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) voor de RTE.
+
+De seed voegt de RTE onder **Verbindingen > Runners** toe als de runner `rte`, de standaardrunner, zodat playbookformulieren er zonder verdere
+instellingen op draaien. De app maakt het schema bij de eerste start aan, en belt de RTE aan zodra beide draaien (een voorbeeld-`config.yaml` staat in het
+[docker-compose-project](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Eenmaal gestart staan beide containers in de lijst:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman neemt dezelfde opties en heeft geen service nodig:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Eenmaal gestart staan beide containers in de lijst:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+De app luistert op poort `8000`, over HTTP tenzij je `HTTPS=1` instelt. De RTE wordt niet op de host gepubliceerd: alleen de app belt hem aan, binnen
+het netwerk. `--stop-timeout 30` geeft de RTE bij een stop de tijd om lopende playbooks af te laten ronden (zie
+[Een RTE draaien](../rte/run.html) voor de RTE-instellingen en voor het bouwen van een eigen RTE).
+
+---
+
+## Test de applicatie
+
+Zodra de containers draaien, open je AnsibleForms in een browser:
+
+* Open `http://your_ip:8000` (of HTTPS, als je `HTTPS=1` hebt ingesteld)
+* Meld je aan als `admin` / `AnsibleForms!123` (of met het wachtwoord dat je met `ADMIN_PASSWORD` hebt ingesteld), en kies een nieuw wachtwoord
+* Controleer onder **Verbindingen > Runners** dat de RTE in de lijst staat als `rte`, de standaardrunner, en dat zijn pagina bij
+  **Verbinding** de status **Verbonden** toont
+* Volgende stappen:
+  * Maak formulieren door YAML-bestanden aan de map `forms` toe te voegen of met de ingebouwde designer
+  * Zet je playbooks in de map `playbooks` van de gekoppelde persistente map
+  * Voeg een LDAP-verbinding toe
+  * Voeg gebruikers en groepen toe
+  * Voeg runners toe voor templateformulieren: AWX, AAP of Ascender, Semaphore, Rundeck of Jenkins
+  * Voeg referenties toe voor externe verbindingen, zoals andere MySQL-servers of REST API's, of om aan Ansible-playbooks door te geven
diff --git a/i18n/nl/_get_started/installation/from-source.md b/i18n/nl/_get_started/installation/from-source.md
new file mode 100644
index 0000000..ec46620
--- /dev/null
+++ b/i18n/nl/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Vanuit de broncode
+parent: Installatie
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Vanuit de broncode
+{: .no_toc }
+
+Bouw AnsibleForms vanuit de broncode en draai het met Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Hoe de code is georganiseerd
+
+De repository bevat twee Node.js-applicaties, en een build voegt ze samen tot één:
+
+* **client** : de webinterface, geschreven in Vue 3 en met Vite gebouwd tot statische bestanden
+* **server** : de API, geschreven in Express. Die geeft de jobs door aan runners, maakt verbinding met de database en serveert de gebouwde client.
+  Gestart met `AF_ROLE=rte` is dezelfde server de RTE (runtime-omgeving) die de playbooks uitvoert
+
+Alleen de client wordt gebouwd; de uitvoer daarvan gaat naar de map `views` van de server, zoals in de [Docker-image](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Vereisten
+
+Bouwen en draaien vanuit de broncode vraagt goede Linux-kennis en enige kennis van Node.js. Je installeert elk onderdeel zelf. Wil je
+AnsibleForms zonder containers en zonder het zelf te bouwen draaien, dan doet de [native installatie](native.html) van het installatieprogramma dit allemaal voor je:
+
+* **Node.js 26** (de versie in `.nvmrc`; minstens 24), met npm
+* **Git**, om de code op te halen en repositories te synchroniseren
+* **OpenSSH-client**, voor git over SSH, en **sshpass**, voor playbooks die met een SSH-wachtwoord verbinden
+* **MariaDB-client** (`mariadb`, `mariadb-dump`), voor back-ups en herstel, ook bij een MySQL-server
+* **MySQL 8+ of MariaDB**, bereikbaar vanaf de server
+* **Ansible**, voor het RTE-proces dat de playbooks uitvoert (`ansible-playbook` in het path). Het app-proces zelf heeft geen
+  Ansible en geen Python nodig, en met alleen templateformulieren (AWX, AAP, Ascender en de andere runners) heb je helemaal geen RTE nodig
+
+Installeer ze voor je distributie:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 komt uit de NodeSource-repository, de andere tools uit Ubuntu zelf:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 komt uit de NodeSource-repository, de andere tools uit Debian zelf:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js komt van NodeSource en `sshpass` uit EPEL (op RHEL zelf schakel je EPEL in zoals Red Hat het beschrijft):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Controleer `node --version` (26) en `ansible-playbook --version`; voor de database en de gebruiker ervan, zie [Installeer MySQL](docker.html#install-mysql).
+
+---
+
+## Haal de code op
+
+Clone de repository in een map naar keuze, eigendom van de gebruiker die de applicatie gaat draaien. De voorbeelden gebruiken `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Bouwen
+
+Bouw in drie stappen, vanuit de map van de repository. Bouw eerst de client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Installeer daarna de afhankelijkheden van de server:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Kopieer tot slot de gebouwde client naar de map `views` van de server:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Configureren
+
+De server leest zijn instellingen uit omgevingsvariabelen en, in productie, ook uit `server/persistent/.env`, het bestand
+waarnaar de instellingenpagina's schrijven.
+
+Begin met het voorbeeldbestand in de root van de repository en stel minstens de MySQL-verbinding in (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Alle variabelen worden beschreven onder [Omgevingsvariabelen](../customization). Al het andere wordt standaard in `server/persistent` opgeslagen:
+`config.yaml`, de map `forms` en zelfondertekende certificaten worden daar bij de eerste start aangemaakt, naast de logs.
+Zet je playbooks in `server/persistent/playbooks`, of laat `ANSIBLE_PATH` ergens anders heen wijzen in de omgeving van de RTE, die het leest.
+
+---
+
+## Draaien
+
+Draai AnsibleForms in productie, of in ontwikkelmodus om aan de code zelf te werken:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Productie</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Ontwikkeling</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Start de server in productiemodus vanuit de map `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Een applicatie die je vanaf de commandoregel start, stopt zodra je je afmeldt. [PM2](https://pm2.keymetrics.io/) houdt haar op de
+achtergrond draaiende, herstart haar na een crash en start haar opnieuw bij het opstarten:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Playbooks draaien op een RTE: start dezelfde server een tweede keer met `AF_ROLE=rte`, op een eigen poort. De app belt hem aan en houdt
+één WebSocket open (`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)), en hij voert de playbooks uit vanuit dezelfde mappen
+(`RTE_FILES=local`). Hij leest ook `persistent/.env`, maar gebruikt geen van de database-instellingen daarin. Voeg het token dat de app en de RTE delen,
+minstens 16 tekens, en de config seed die de RTE declareert, toe aan `persistent/.env`:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+De [config seed](../seed/) declareert een RTE-referentie met het adres en het token van de RTE, en de standaardrunner `rte` die zich
+daarmee aanmeldt:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Zonder seed voeg je ze toe onder **Verbindingen > Inloggegevens** (een RTE-referentie met dat adres en het token) en
+**Verbindingen > Runners** (type RTE, **Modus** **Inkomend**). Start daarna de RTE, alleen op `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+De RTE-instellingen worden beschreven op de pagina [Een RTE draaien](../rte/run.html). Controleer dat PM2 beide processen toont:
+
+```bash
+pm2 status
+```
+
+Beide zijn `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Om aan de code zelf te werken, start je alles vanuit de root van de repository met live reload: de server op poort 3001, een RTE op poort 8010
+en de client op `https://localhost:8443`. In deze modus lezen de server en de RTE in plaats daarvan `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+De RTE (`npm run dev:rte`) heeft `ansible-playbook` in het path nodig, en voegt zichzelf toe als runner in databasemodus, verouderd en alleen
+bedoeld voor ontwikkeling; `npm run dev:local` start de client en de server zonder RTE. De [handleiding voor bijdragers](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) beschrijft welke tests en controles je moet draaien.
+
+</div>
+</div>
+
+---
+
+## Eerste keer starten
+
+Open de server in een browser (met de voorbeeld-`.env`, `https://your_ip:8443`). Op een lege database wordt het schema bij de
+eerste start aangemaakt.
+
+De standaard beheerdersgegevens zijn:
+
+* gebruikersnaam : `admin`
+* wachtwoord : `AnsibleForms!123`
diff --git a/i18n/nl/_get_started/installation/index.md b/i18n/nl/_get_started/installation/index.md
new file mode 100644
index 0000000..d17d1df
--- /dev/null
+++ b/i18n/nl/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Installatie
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Installatie
+{: .no_toc }
+
+Kies een installatiemethode voor AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders die een nieuwe instantie opzetten: kies een installatiemethode en volg de bijbehorende pagina.
+
+---
+
+## In deze sectie
+
+AnsibleForms ondersteunt verschillende installatiemethoden, elk beschreven op een eigen pagina:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Installatieprogramma](installer.html) | Eén commando dat een controller of een Runner installeert op Docker, Podman, Kubernetes of native, en die daarna bijwerkt en er back-ups van maakt |
+| [Native](native.html) | De installatie van het installatieprogramma zonder containers: Node.js, MariaDB en Ansible op de server, AnsibleForms als systemd-services |
+| [Docker](docker.html) | Installeer MySQL en draai de kant-en-klare Docker-image met de vereiste omgevingsvariabelen |
+| [Docker Compose](docker-compose.html) | Download het [docker-compose-project](https://github.com/ansibleforms/docker) en start met docker-compose zowel MySQL als AnsibleForms |
+| [Vanuit de broncode](from-source.html) | Installeer alle afhankelijkheden met de hand, en bouw en start daarna de code |
+| [Kubernetes](kubernetes.html) | Installeer de Helm-chart en start met Kubernetes AnsibleForms en de bijbehorende MySQL-database |
+
+{: .note }
+> **Aanbeveling** Het installatieprogramma is sinds 7.3.0 de snelste weg naar een werkende instantie: op basis van een paar vragen zet het het Docker Compose-project op
+> Docker of Podman op, of een van de andere methoden. De Docker-images bevatten alle afhankelijkheden.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Om een bestaande installatie naar een nieuwere release te brengen, zie [Upgraden](../upgrading/).
+
+Elke methode draait één RTE naast de app, de container (of service) die de playbooks uitvoert. Wil je er nog een toevoegen, op een andere host of in een ander
+datacenter, installeer dan een Runner met het [installatieprogramma](installer.html#a-runner): die belt AnsibleForms aan over één WebSocket (uitgaand, zie
+[Modi](../rte/modes.html)) en bevat geen database-inloggegevens. Zie ook [Runtime-omgevingen](../rte/) en het bijbehorende runbook
+[Een RTE in een ander datacenter](../rte/another-datacenter.html).
+
+---
+
+## Image-tags
+
+De image wordt gepubliceerd als `ghcr.io/ansibleforms/ansibleforms` op de GitHub Container Registry, die van het
+project is en anonieme pulls niet beperkt. Elke release vanaf 7.0.0 wordt alleen daar gepubliceerd, en de 6.x-releases
+staan er ook.
+
+Sinds 7 draaien playbooks op een RTE, die naast de app in drie lagen wordt gepubliceerd (zie [De RTE-images](../rte/images.html)):
+
+| Image | Wat het is |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | De webapplicatie en de API, zonder python of ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | De RTE zonder python of ansible: de basis voor je eigen RTE |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | De basis met python, ansible-core en een paar bibliotheken: de image om je collections aan toe te voegen |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | De core met het `ansible`-pakket, de bijbehorende collections en bibliotheken: de standaard-RTE |
+
+De vier images worden in dezelfde run gebouwd en dragen dezelfde tags, dus een RTE-tag komt altijd overeen met die van de app.
+
+De oude Docker Hub-repository, `ansibleguy/ansibleforms`, wordt niet meer bijgewerkt. De bestaande
+releases blijven staan, maar er komen geen nieuwe versies van welke lijn dan ook bij. Pull je daarvandaan, stap dan over
+op `ghcr.io/ansibleforms/ansibleforms` met dezelfde tag om updates te blijven ontvangen.
+
+Op elke image zijn de volgende tags beschikbaar; de RTE-images beginnen bij 7.0.0 en hebben dus geen 6.x-tags:
+
+| Tag | Verwijst naar |
+|---|---|
+| `latest` | de nieuwste release van de nieuwste hoofdversie |
+| `7`, `6` | de nieuwste release van die hoofdversie |
+| `7.0`, `6.5` | de nieuwste release van die minor-versie |
+| `7.0.0`, `6.5.5` | precies die release |
+| `latest-rc` | de nieuwste release candidate, of de nieuwste release als die nieuwer is; elke candidate heeft ook een eigen tag |
+
+`latest` gaat alleen vooruit: een patch voor een oudere hoofdversie (bijvoorbeeld een 6.5.x die na 7.0.0
+uitkomt) verplaatst `6` en `6.5`, maar nooit `latest`.
+
+Wil je op een hoofdversie blijven, gebruik dan het nummer ervan (`6`) in plaats van `latest`.
diff --git a/i18n/nl/_get_started/installation/installer.md b/i18n/nl/_get_started/installation/installer.md
new file mode 100644
index 0000000..5d1fde7
--- /dev/null
+++ b/i18n/nl/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Installatieprogramma
+parent: Installatie
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# Het installatieprogramma
+{: .no_toc }
+
+Installeer, upgrade en onderhoud AnsibleForms op een Linux-server, met één commando
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders: de snelste weg naar een werkende instantie, of naar een Runner voor een AnsibleForms dat elders is geïnstalleerd. Sinds 7.3.0.
+
+---
+
+## Wat het installeert
+
+Het installatieprogramma stelt een paar vragen in een wizard op volledig scherm, toont elk antwoord ter controle, en past pas daarna de server aan.
+Het installeert een van twee rollen, op een van vier engines:
+
+| Rol | Wat het is |
+|---|---|
+| Controller | De complete applicatie: de webinterface, de database en een eigen Runner. Kies dit voor een eerste installatie |
+| Runner | Een RTE die de playbooks uitvoert van een AnsibleForms dat elders is geïnstalleerd, bijvoorbeeld in een ander netwerk, een DMZ of een ander datacenter. Hij praat met AnsibleForms over één WebSocket en bevat geen database-inloggegevens |
+
+De engines waarop het ze installeert:
+
+| Engine | Hoe het draait |
+|---|---|
+| Docker | Het [Docker Compose-project](docker-compose.html), op Docker Engine met de compose-plugin. De containers herstarten samen met Docker |
+| Podman | Hetzelfde project op Podman, rootless of als root, met podman-compose. Een systemd-unit start de containers bij het opstarten |
+| Kubernetes | De [Helm-chart](kubernetes.html), op het cluster dat `kubectl` bereikt. Een controller wordt achter een ingress geserveerd; een Runner gebruikt de runnermodus van de chart |
+| Direct op deze server | Geen containers: Node.js, MariaDB en Ansible op de server, en AnsibleForms als systemd-services. Zie [Native installatie](native.html) |
+
+Na de installatie upgradet hetzelfde programma de installatie, maakt er back-ups van, toont de status en verwijdert haar. Het neemt ook een
+AnsibleForms over dat het niet zelf heeft geïnstalleerd, zoals een installatie die met de hand vanuit het Docker Compose-project is opgezet (zie [Een bestaande installatie](#an-existing-installation)).
+
+---
+
+## Starten
+
+Het installatiescript downloadt het installatieprogramma voor deze server en start het:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+De gebruikelijke varianten: als root, om Docker of Podman te installeren, om direct op de server of onder `/opt` te installeren; met een commando of
+flags (zie [Flags](#flags)); en een installatieprogramma van een bepaalde release in plaats van de nieuwste:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+Het script:
+
+1. Controleert dat de server Linux draait op amd64 of arm64, en zoekt `curl` of `wget` en `sha256sum`
+2. Downloadt `ansibleforms-installer_linux_<arch>` uit de nieuwste release van
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases), of uit de release die `AF_INSTALLER_VERSION` noemt
+3. Controleert het tegen de `checksums.txt` van de release, en gebruikt geen download waarvan de checksum afwijkt
+4. Bewaart het als `ansibleforms-installer`, in `/usr/local/bin` voor root en anders in `~/.local/bin`, voor de latere upgrades en back-ups.
+   Via sudo start je het met het volledige pad: de `secure_path` van sudo laat, zoals op Red Hat-systemen, vaak `/usr/local/bin` weg
+5. Start het met de opgegeven flags, en leest het toetsenbord vanaf de terminal, ook al kwam het script via een pipe binnen
+
+Zonder terminal, zoals in een CI-job, draait het installatieprogramma zonder toezicht (zie [Zonder toezicht](#unattended)).
+
+---
+
+## De wizard
+
+De wizard stelt één vraag tegelijk, met de stappen links op een rij. **Esc** gaat terug naar de vorige stap, met het antwoord bewaard:
+
+| Stap | Wat hij vraagt |
+|---|---|
+| Taal | De taal van het installatieprogramma, standaard volgens de locale van deze server: Catalaans, Duits, Engels, Spaans, Frans, Italiaans, Japans, Nederlands, Pools, Portugees of Chinees. Wordt als eerste gevraagd, voordat het installatieprogramma iets zegt over een installatie die het heeft gevonden |
+| Release notes | Wat er nieuw is in de versie die het installeert, met eerst de breaking changes, verwijderingen en afschaffingen |
+| Rol | Controller of Runner |
+| Engine | Docker, Podman, Kubernetes, of direct op deze server |
+| Map | De installatiemap, en de naam van de instantie |
+| Join, App, Modus | Alleen bij een Runner: zie [Een Runner](#a-runner). De modus niet op Kubernetes |
+| Netwerk | De poort van de webinterface, of van de Runner. Niet op Kubernetes |
+| HTTPS | Hoe browsers verbinding maken met een controller |
+| Beheerder | Het wachtwoord van de eerste beheerder, twee keer ingetypt |
+| Cluster, Ingress, Opslag | Alleen Kubernetes: de namespace en release, de ingress (bij een controller), de storage-klasse |
+| Controle | Elk antwoord: **Installeren**, of **Antwoorden wijzigen** |
+
+**Engine.** De lijst toont wat deze server heeft. Een engine die ontbreekt wordt aangeboden als *Docker (niet geïnstalleerd: het installatieprogramma installeert het)*
+of hetzelfde voor Podman: zodra je bevestigt, installeert het installatieprogramma Docker met het eigen script van Docker (`get.docker.com`, compose-plugin
+inbegrepen) of Podman met podman-compose uit de pakketten van de distributie. Daarvoor is root nodig. Kubernetes wordt aangeboden als `kubectl` en
+`helm` geïnstalleerd zijn en een cluster bereiken. *Direct op deze server* vereist root en een ondersteunde Linux, en zegt waarom als de optie grijs is.
+
+**Map.** De standaardwaarden:
+
+| | Controller | Runner |
+|---|---|---|
+| Map, als root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Map, als andere gebruiker | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Naam van de instantie, Docker of Podman | `af` | `runner` |
+| Naam van de instantie, native | `ansibleforms` | `ansibleforms-runner` |
+
+Met Docker of Podman bevat de map het compose-bestand en de `.env` ervan met de secrets, en alle gegevens: database, formulieren, playbooks
+en logs. Hij moet leeg zijn. De naam van de instantie, kleine letters, cijfers en `-`, is het voorvoegsel van de containers (`af_app`, `af_db`, `af_rte`), zodat meerdere
+instanties een server kunnen delen. De naam van de instantie van een Runner is ook de naam van zijn runner onder **Verbindingen > Runners** (`RTE_NAME`).
+
+**Netwerk.** De webinterface van een controller luistert op `443`, of op de eerstvolgende vrije poort. **HTTPS** biedt daarna:
+
+| Keuze | Wat het doet |
+|---|---|
+| HTTPS met een zelfondertekend certificaat voor deze server | Een certificaat voor de namen van deze server, tien jaar geldig. Browsers vragen je het één keer te accepteren |
+| HTTPS met mijn eigen certificaat en sleutel | Je eigen certificaat en sleutel, in PEM-formaat, van je CA of van Let's Encrypt |
+| HTTP, met HTTPS via een reverse proxy ervoor | Gewoon HTTP op de poort, voor nginx, Traefik of een load balancer die HTTPS afhandelt |
+
+**Beheerder.** Het wachtwoord van de gebruiker `admin`, twee keer ingetypt zodat een tikfout je niet buitensluit. Laat je het leeg, dan genereert het installatieprogramma
+een sterk wachtwoord.
+
+**Het einde.** Het installatieprogramma genereert het databasewachtwoord en de secrets, start AnsibleForms en wacht tot het antwoordt. Daarna
+toont het het adres om te openen, de gebruiker en het wachtwoord, en de map. Runners die ervoor geïnstalleerd worden vragen om aan te sluiten, en een beheerder keurt ze
+goed onder **Verbindingen > Runners** (zie [Een Runner](#a-runner)).
+
+---
+
+## Een Runner
+
+Een Runner is een RTE voor een AnsibleForms dat elders draait, op versie 7.3.0 of later. Hij bevat geen database-inloggegevens: hij meldt zich aan
+met een eigen token, dat AnsibleForms in een RTE-referentie bewaart (zie [Modi](../rte/modes.html)). Na de map vraagt de wizard
+nog drie dingen:
+
+| Stap | Wat hij vraagt |
+|---|---|
+| App | Het adres van het AnsibleForms waarvoor deze Runner werkt, het adres dat mensen in een browser openen |
+| Modus | **Uitgaand: de Runner maakt verbinding met AnsibleForms** (de standaard), of **Inkomend: AnsibleForms maakt verbinding met de Runner** |
+| Netwerk | De poort van de Runner, standaard `8000`. Bij uitgaand luisteren daar alleen de health checks, en alleen bereikbaar vanaf deze server. Bij inkomend ook het adres van deze server zoals AnsibleForms het bereikt |
+
+`--role runner` slaat de vraag naar de rol over, dus dit commando, uitgevoerd op de server van de Runner, begint met de vragen voor een Runner:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+Het installatieprogramma maakt daarna verbinding met AnsibleForms. Bij een zelfondertekend certificaat, of een van een private CA, vraagt het **Dit certificaat vertrouwen?**:
+ja zet [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) op de Runner. Het leest de versie die AnsibleForms draait,
+weigert een versie ouder dan 7.3.0, en installeert de Runner met precies die versie, ongeacht welke versie het installatieprogramma zelf zou installeren.
+
+Kies uitgaand voor een DMZ, NAT of een zone die geen inkomende verbindingen toestaat: alleen verkeer van deze server naar AnsibleForms, op de
+poort daarvan. Kies inkomend voor netwerken waar de centrale kant elke verbinding opent.
+
+De controle toont **Registratie: vraagt goedkeuring**, of **zelf, met een jointoken** als `--join` er een gaf. Aan het eind toont het installatieprogramma
+de naam van de Runner, de modus, de app en, bij inkomend, het adres, en zegt dan dat de Runner gevraagd heeft om bij AnsibleForms aan te sluiten: keur hem goed onder
+**Verbindingen > Runners**, nadat je hebt gecontroleerd dat de vingerafdruk die daar staat dezelfde is als die het installatieprogramma toont:
+
+```
+Fingerprint: abcd-ef12
+```
+
+De vingerafdruk bestaat uit de eerste 8 hexadecimale cijfers van de SHA-256 van het token van de Runner, `RTE_TOKEN`, dat in het `.env`-bestand
+van de map wordt bewaard (`rte.env` bij een [native installatie](native.html)). Zie [Een RTE goedkeuren](../runners/registration.html#approving-an-rte). Met `--join` is de Runner meteen goedgekeurd:
+hij heeft zichzelf geregistreerd, en staat als verbonden onder **Verbindingen > Runners**.
+
+Een inkomende Runner serveert zijn socket over HTTPS. Het installatieprogramma maakt een zelfondertekend certificaat voor het adres waarop AnsibleForms
+hem bereikt, tien jaar geldig, in `data/certificates` van de map, en zet `RTE_URL` op `https://<address>:<port>`.
+De Runner stuurt het certificaat mee als hij vraagt om aan te sluiten, en AnsibleForms pint het: het belt die Runner alleen aan als die
+precies dat certificaat toont, dus er is geen CA nodig. Het installatieprogramma toont de vingerafdruk van het certificaat onder die van het token:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+Het zijn de eerste 8 hexadecimale cijfers van de SHA-256 van de DER-bytes van het certificaat, als `xxxx-xxxx`. Controleer voordat je de Runner goedkeurt
+dat het goedkeuringsvenster dezelfde certificaatvingerafdruk toont. Een Runner die met `--join` is geregistreerd toont hem ook.
+
+Op Kubernetes is een Runner de runnermodus van de Helm-chart, en altijd uitgaand: de wizard vraagt geen modus en geen netwerk, omdat niets
+hem van buitenaf bereikt (zie [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Voor een controller op Kubernetes installeert het installatieprogramma de [Helm-chart](kubernetes.html) op het cluster dat `kubectl` bereikt:
+
+| Vraag | Standaard |
+|---|---|
+| Namespace | `ansibleforms` |
+| Naam van de Helm-release | `ansibleforms` |
+| Hostnaam van de ingress | Geen: verplicht, bijvoorbeeld `ansibleforms.example.com` |
+| Ingress-klasse | Een van die van het cluster, standaard `nginx` |
+| Aanbieden via HTTPS (met het certificaat van de ingress)? | Ja |
+| Storage-klasse voor de volumes | De standaard van het cluster |
+
+Het beheerderswachtwoord staat in de Secret `<release>-secrets` van die namespace, onder de sleutel `ADMIN_PASSWORD`. Het installatieprogramma bewaart de
+chartwaarden in een bestand naast zijn statusbestand, `<release>-values.yaml`, en past het bij upgrades opnieuw toe; met `--values` voeg je een eigen bestand toe. De chart van een release wordt kort na de release gepubliceerd.
+
+Voor een Runner installeert het installatieprogramma dezelfde chart in de [runnermodus](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): een RTE
+alleen, zonder app, zonder database en zonder ingress, die AnsibleForms aanbelt (uitgaand). Na het adres van de app vraagt de wizard:
+
+| Vraag | Standaard |
+|---|---|
+| Namespace | `ansibleforms` |
+| Naam van de Helm-release | `ansibleforms-runner`, wat ook de naam van zijn runner is onder **Verbindingen > Runners** |
+| Storage-klasse voor de volumes | De standaard van het cluster |
+
+Het installatieprogramma maakt het token van de Runner en stelt het adres van de app in, de naam van de runner en, als je het certificaat van de app vertrouwt,
+`runner.appTlsVerify: false`. Met `--join` keurt het jointoken de Runner meteen goed; zonder vraagt de Runner om aan te sluiten, en het
+installatieprogramma toont de vingerafdruk die je controleert voordat je hem goedkeurt onder **Verbindingen > Runners**.
+
+---
+
+## Commando's
+
+Het installatieprogramma neemt een commando, voor of na de flags. Zonder commando installeert het:
+
+| Commando | Wat het doet |
+|---|---|
+| `install` | Installeert AnsibleForms, als controller of als Runner (de standaard). Op een server die al een installatie heeft, een eigen of een die het vindt, biedt het aan die te upgraden |
+| `upgrade` | Upgradet naar een nieuwere versie, en toont eerst de release notes (zie [Upgraden](#upgrade)) |
+| `status` | Toont de installatie (rol, engine en versie) en de containers, pods of services ervan, en of die antwoordt. Daarna somt het elk ander AnsibleForms op dat het op de server vindt |
+| `backup` | Maakt nu een back-up van de database, in `installer-backups` in de installatiemap (op Kubernetes in `backups` naast het statusbestand van het installatieprogramma). Een Runner bevat geen gegevens om te back-uppen |
+| `release-notes` | Toont de release notes van een versie, `--version` of die van dit installatieprogramma, met de breaking changes eerst |
+| `uninstall` | Verwijdert de installatie, en met `--purge` ook de gegevens |
+| `version` | Toont de versie van het installatieprogramma |
+
+Het installatieprogramma onthoudt de installatie in `/etc/ansibleforms/installer.json` voor root, of `~/.config/ansibleforms/installer.json`
+voor een andere gebruiker, dus de commando's na `install` hebben geen flags nodig en vinden de installatie zelf. Die map bevat geen binary,
+en bestaat pas zodra het installatieprogramma een AnsibleForms heeft geïnstalleerd of overgenomen:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` vraagt **Ook de gegevens verwijderen (database, formulieren, playbooks, logs)?**. Om ze te verwijderen typ je de naam van de instantie (de Helm-release
+op Kubernetes); anders verwijdert het de containers, pods of services en houdt het de gegevens.
+
+---
+
+## Flags
+
+Elke flag beantwoordt een vraag, die de wizard dan overslaat. `ansibleforms-installer --help` toont ze:
+
+| Flag | Wat hij beantwoordt |
+|---|---|
+| `--lang <code>` | De taal: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` of `zh` |
+| `--version <version>` | De versie van AnsibleForms om te installeren of naar te upgraden; standaard die van dit installatieprogramma |
+| `--role <role>` | `controller` of `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` of `native` |
+| `--runtime <runtime>` | `docker` of `podman` (compose) |
+| `--install-runtime` | Installeert Docker of Podman als het ontbreekt, zonder te vragen |
+| `--dir <folder>` | De installatiemap (compose) |
+| `--name <name>` | De naam van de instantie, het voorvoegsel van de containers (compose, standaard `af`) |
+| `--port <port>` | De poort op de host: de webinterface bij een controller, de RTE bij een Runner |
+| `--tls <choice>` | `self`, `own` of `off` (een compose-controller) |
+| `--cert <file>`, `--key <file>` | De certificaat- en sleutelbestanden, met `--tls own` |
+| `--admin-password <password>` | Het wachtwoord van de eerste beheerder; standaard gegenereerd |
+| `--join <token>` | Een jointoken (`afj_...`), gemaakt via de API, dat de Runner meteen goedkeurt (een Runner, zonder toezicht; zie [Jointokens](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | Het adres van de app, bijvoorbeeld `https://forms.example.com` (een Runner) |
+| `--runner-mode <mode>` | `outbound` (de RTE belt de app aan) of `inbound` (de app belt de RTE aan) (een Runner) |
+| `--host <address>` | Het adres van deze server, dat de app aanbelt (een inkomende Runner) |
+| `--namespace <namespace>` | De Kubernetes-namespace, standaard `ansibleforms` |
+| `--release <release>` | De Helm-release, standaard `ansibleforms` |
+| `--hostname <name>` | De hostnaam van de ingress (kubernetes) |
+| `--ingress-class <class>` | De ingress-klasse (kubernetes) |
+| `--storage-class <class>` | De storage-klasse (kubernetes) |
+| `--values <file>` | Een extra Helm-valuesbestand (kubernetes) |
+| `--purge` | Met `uninstall`: verwijdert ook de gegevens |
+| `--source <folder>` | Een lokale kopie van de repository [ansibleforms/docker](https://github.com/ansibleforms/docker) om vanuit te installeren (air-gapped) |
+| `--bundle <file>` | Een releasebundel, `ansibleforms-<version>-linux-<arch>.tar.gz`, om native vanuit te installeren (zie [Native installatie](native.html#air-gapped)) |
+| `--yes` | Beantwoordt elke vraag met de standaardwaarde (zonder toezicht) |
+| `--verbose` | Toont elk commando dat het uitvoert |
+
+---
+
+## Zonder toezicht
+
+Met `--yes`, of zonder terminal, vraagt het installatieprogramma niets: de flags beantwoorden hun vragen en de standaardwaarden de rest. Het
+slaat de taal, de release notes, het beheerderswachtwoord (gegenereerd, tenzij `--admin-password` er een geeft) en de controle over, en toont
+in plaats daarvan de link naar de release notes. Het installeert een ontbrekend Docker of Podman alleen met `--install-runtime` of `--yes`, en een Runner
+heeft `--app-url` nodig. Zonder `--join` vraagt de Runner om aan te sluiten en wacht hij op goedkeuring door een beheerder; met `--join` is hij meteen goedgekeurd.
+
+Een controller op Docker, die Docker installeert als het ontbreekt:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Een inkomende Runner op Podman, die de app aanbelt op `rte-dmz.example.com:8000`:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Een bestaande installatie
+
+Het installatieprogramma onthoudt wat het heeft geïnstalleerd in `installer.json`. Zonder dat bestand zoeken `install`, `upgrade` en `status` eerst naar een
+AnsibleForms dat al op de server staat, ongeacht wat het heeft geïnstalleerd:
+
+| Gevonden | Hoe het wordt gevonden | Overgenomen als |
+|---|---|---|
+| Docker of Podman | Containers van de app- of RTE-image, gegroepeerd per compose-project | De map het compose-bestand en de `.env` van de repository [ansibleforms/docker](https://github.com/ansibleforms/docker) bevat: de services `mysqldb`, `app` en `rte`, in de containers `<name>_db`, `<name>_app` en `<name>_rte` |
+| Een 7.2-Runner | Een RTE alleen in zijn compose-project, met de `DB_*` van de app en zonder `RTE_MODE` (databasemodus) | Het compose-bestand leesbaar is. De upgrade zet hem over naar een socketmodus (zie [Een 7.2-Runner](#a-72-runner)) |
+| Kubernetes | Helm-releases van de chart `ansibleforms`, en Deployments en StatefulSets van de images ervan | Het een release van de chart is: de huidige waarden worden het valuesbestand |
+| Native | systemd-services die AnsibleForms met Node.js draaien | Ze de indeling van het installatieprogramma volgen: `releases/`, `current`, `app.env` en `rte.env` (zie [Native installatie](native.html#the-folder)) |
+| Geen engine | De app of een RTE die antwoordt op een gebruikelijke poort: 443, 3000, 3001, 8000, 8001, 8010 of 8443 | Nooit: het draait vanuit de broncode of met de hand. Het installatieprogramma meldt het alleen |
+
+Alleen de images van de app en de RTE tellen: een MySQL-container met een naam die naar AnsibleForms verwijst is geen installatie. Het installatieprogramma somt op wat
+het vond, één regel per installatie, met de reden en wat je met de hand moet doen voor een installatie die het niet kan overnemen: het compose-bestand is niet dat van de repository,
+de database staat buiten het compose-project, het draait op Kubernetes zonder de Helm-chart, het wordt beheerd door Argo CD (upgrade het daar,
+door de chartversie van de Application te wijzigen), of de versie kan niet worden gelezen.
+
+Voor een installatie die het kan overnemen, biedt `install` drie keuzes:
+
+| Keuze | Wat het doet |
+|---|---|
+| Overnemen en upgraden | Toont wat het gaat onthouden, schrijft `installer.json` zodra je bevestigt, en gaat verder met de [upgrade](#upgrade) |
+| Toch een nieuw AnsibleForms ernaast installeren | Een tweede installatie, met een eigen map, poorten en database, na een eigen bevestiging |
+| Stoppen | Er wordt niets gewijzigd |
+
+Voor een installatie die al de versie draait die het installatieprogramma zou installeren, is de eerste keuze in plaats daarvan **Overnemen**: het installatieprogramma
+onthoudt waar ze staat en hoe ze draait, voor de back-ups, de status en de volgende upgrades, en er wordt nu niets gewijzigd.
+
+`upgrade` biedt hetzelfde zonder de tweede keuze, en stopt als er niets over te nemen valt. Zonder toezicht stopt `install` met een melding,
+en neemt `upgrade --yes` een installatie alleen over als het er precies één vindt die het kan overnemen. De huidige waarden van een Kubernetes-release worden
+naast `installer.json` opgeslagen, en de upgrades passen ze opnieuw toe met de chart van de nieuwe versie.
+
+---
+
+## Upgraden
+
+`ansibleforms-installer upgrade` brengt de installatie naar een nieuwere versie van dezelfde hoofdversie. Het toont de nieuwere versies,
+de nieuwste eerst (zonder toezicht neemt het de nieuwste), en toont de release notes van elke versie die het passeert, met de breaking changes
+en verwijderingen eerst. Als die breaking changes bevatten, vraagt het je te bevestigen dat je ze gelezen hebt; zonder toezicht gaat het alleen door met `--yes`.
+
+Het installatieprogramma maakt een back-up van de database voordat er iets verandert. Als de nieuwe versie niet reageert, biedt het aan terug te draaien: de vorige
+versie komt terug, en de database wordt uit die back-up hersteld. Het downgradet niet, en het gaat niet over een hoofdversie heen: volg
+daarvoor de [upgradegids](../upgrade-7.html), bijvoorbeeld van 6.x naar 7.x, met wat je op 6.5 moet doen voordat je upgradet.
+
+Op Docker of Podman brengt de upgrade van een controller ook de bestanden bij met de nieuwe versie van de docker-repository:
+
+| Bestand | Wat de upgrade doet |
+|---|---|
+| `docker-compose.yml` | Vervangen door dat van de nieuwe versie, nadat er een kopie is opgeslagen in `installer-backups` |
+| `.env` | Elke bestaande regel blijft staan, en de sleutels die de nieuwe versie nodig heeft worden toegevoegd, met secrets gemaakt zoals een verse installatie ze maakt. Eerst wordt een kopie opgeslagen |
+| `data/seed.yaml` | Vervangen als het een seed is die de docker-repository meeleverde, ongewijzigd. Een met de hand gewijzigde seed blijft staan, en de nieuwe wordt ernaast opgeslagen |
+| `data/` | De nieuwe bestanden die de versie meebrengt, zoals een nieuw playbook, worden toegevoegd. Elk bestaand bestand blijft staan |
+
+Een ontbrekende database-instelling (`MYSQLDB_USER` of een wachtwoord) kan niet worden verzonnen voor een database die al bestaat, dus dan stopt de upgrade vóór
+enige wijziging. Een rollback zet het compose-bestand, de `.env` en de seed terug zoals ze waren.
+
+Een Runner draait dezelfde versie als zijn AnsibleForms: upgrade eerst AnsibleForms, en daarna de Runners. De upgrade van een Runner herschrijft het
+compose-bestand voor de nieuwe RTE-image en laat de `.env` en de gegevens zoals ze zijn.
+
+---
+
+## Een 7.2-Runner
+
+Een Runner van 7.2 draait in databasemodus, verouderd sinds 7.3.0: zijn RTE bevat de database-instellingen van AnsibleForms. Het installatieprogramma vindt
+hem (zie [Een bestaande installatie](#an-existing-installation)), en de upgrade zet hem over naar een socketmodus onder dezelfde runner:
+
+1. Het leest de naam (`RTE_NAME`) en het token (`RTE_TOKEN`) van de runner uit de oude RTE-container. Als de RTE zichzelf niet registreerde
+   (`RTE_REGISTER=0`), typ je de naam die zijn runner heeft onder **Verbindingen > Runners**
+2. Het vraagt het adres van de app en de modus, standaard **uitgaand** of inkomend, en bij inkomend de poort en het adres van deze server
+3. Het toont het plan, en maakt daarna een back-up van het oude compose-bestand en de `.env` in `installer-backups`
+4. Het schrijft de Runner-indeling van het installatieprogramma zonder de `DB_*`-instellingen. Het behoudt `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` en `METRICS_TOKEN`, die een RTE in socketmodus nog steeds leest
+5. Het start de nieuwe RTE naast de oude. De nieuwe RTE meldt zich aan met het eigen token van de runner, en AnsibleForms zet de runner zelf over naar de
+   nieuwe modus, **zonder goedkeuring**: de jobs ervan en de formulieren die hem noemen blijven ongewijzigd
+6. Zodra de nieuwe RTE verbonden is, wordt de oude container gestopt en verwijderd
+
+Een inkomende Runner serveert HTTPS met een gepind certificaat, net als een nieuwe (zie [Een Runner](#a-runner)), en het installatieprogramma toont de
+vingerafdruk van het certificaat. Als de oude RTE de poort bezet die de nieuwe nodig heeft, wordt hij eerst gestopt, dus is de Runner offline tot de
+nieuwe verbinding maakt. De nieuwe RTE van een uitgaande Runner neemt een vrije poort op `127.0.0.1` en draait zonder onderbreking naast de oude.
+
+Als het installatieprogramma geen token uit de oude RTE kan lezen, kies je hoe de nieuwe RTE zich aanmeldt:
+
+| Keuze | Wat er volgt |
+|---|---|
+| Het token van de runner typen | Het wachtwoord van de RTE-referentie van de runner onder **Verbindingen > Inloggegevens**. De runner behoudt zijn naam en jobs |
+| Als nieuwe runner aansluiten met een jointoken | Een [jointoken](../runners/registration.html#join-tokens) voegt een nieuwe runner toe onder een andere naam. Zet de oude runner met de hand buiten gebruik |
+
+Als de nieuwe RTE geen verbinding maakt, biedt het installatieprogramma aan de oude bestanden terug te zetten en de oude container opnieuw te starten; als AnsibleForms
+de runner al had overgezet, zet je de modus terug op database onder **Verbindingen > Runners**. Zodra de nieuwe RTE verbonden is, is er
+geen weg terug: de oude bestanden blijven in `installer-backups`.
+
+Als AnsibleForms geen runner met die naam kent, vraagt de nieuwe RTE in plaats daarvan om aan te sluiten en wacht hij op goedkeuring. Wijs dat verzoek af onder
+**Verbindingen > Runners**, en voer de upgrade opnieuw uit met de naam die de runner daar heeft.
+
+---
+
+## Versies
+
+De versie van het installatieprogramma volgt die van de app: elke release van AnsibleForms komt met een installatieprogramma van dezelfde versie, dat er samen mee wordt uitgebracht, en
+dat installatieprogramma installeert standaard die versie. Met `--version` installeer je een andere. Elke release op de
+[Releases-pagina van het installatieprogramma](https://github.com/ansibleforms/installer/releases) heeft binaries voor Linux op amd64 en arm64, met hun
+checksums.
diff --git a/i18n/nl/_get_started/installation/kubernetes.md b/i18n/nl/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..9605db1
--- /dev/null
+++ b/i18n/nl/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Installatie
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Installeer AnsibleForms en de bijbehorende MySQL-database met de Helm-chart
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+De Helm-chart deployt AnsibleForms met MySQL en de RTE die de playbooks uitvoert (zie de [referentie van de values](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+Het [installatieprogramma](installer.html) installeert de chart ook, op basis van een paar vragen, en upgradet een release die het niet zelf heeft geïnstalleerd. Dezelfde
+chart installeert ook een losse Runner, voor een AnsibleForms dat elders draait (zie [Een Runner op Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Vereisten
+
+Voordat je begint, heb je nodig:
+
+* **Kubernetes-cluster** : met `kubectl` zo geconfigureerd dat het het cluster bereikt
+* **Helm 3** : om de chart te installeren en te upgraden
+* **Opslag** : een StorageClass voor dynamische provisioning, of vooraf aangemaakte PersistentVolumes
+* **Ingress-controller** : alleen als je AnsibleForms via een ingress wilt aanbieden
+
+---
+
+## 1. Haal de chartwaarden op
+
+Haal de standaardwaarden van de chart op in een eigen bestand, uit de chartrepository of uit de OCI-registry:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Chartrepository</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">OCI-registry</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Geen repository om toe te voegen: de chart wordt uit de GitHub Container Registry gehaald.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Configureer de opslag
+
+Zowel AnsibleForms als MySQL slaan hun gegevens op een persistent volume op. Stel voor elk de StorageClass en de grootte in:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Een lege `className` gebruikt de standaard-StorageClass van het cluster. De toegangsmodus is standaard `ReadWriteMany`, wat veel storage-
+klassen niet bieden; `ReadWriteOnce` is prima met één replica. Voor vooraf aangemaakte PersistentVolumes, zie de
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) van de chart.
+
+---
+
+## 3. Stel de inloggegevens in
+
+AnsibleForms heeft een beheerdersaccount nodig, een databasewachtwoord en een `ENCRYPTION_SECRET`, de sleutel die de referenties
+versleutelt die in AnsibleForms zijn opgeslagen. Om die sleutel later te wijzigen, zet je [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+voor één start op de oude: elk opgeslagen secret wordt dan opnieuw versleuteld met de nieuwe sleutel. Lever ze op een van drie manieren aan:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">In het valuesbestand</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Gegenereerd door de chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Bestaande Secret</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Zet ze in `my_values.yaml`. De chart bewaart ze in een Secret met de naam `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Laat de chart bij de eerste installatie genereren wat je niet aanlevert. Hij behoudt daarna bij elke
+upgrade dezelfde waarden:
+
+```bash
+--set secrets.generate=true
+```
+
+Dit werkt niet met Argo CD of Flux, die de chart renderen zonder toegang tot het cluster. De gegenereerde Secret
+overleeft `helm uninstall`; maak er een back-up van, want `ENCRYPTION_SECRET` is niet te herstellen.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Laat de chart wijzen naar een Secret die je zelf beheert, bijvoorbeeld met External Secrets, Sealed Secrets of SOPS. De chart
+maakt er dan geen aan:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+De Secret moet `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` en `ADMIN_PASSWORD` bevatten.
+
+</div>
+</div>
+
+---
+
+## 4. Kies de RTE-image
+
+AnsibleForms 7 voert zelf geen playbook uit: dat doet de RTE (runtime-omgeving). De chart draait hem als tweede container in de
+serverpod, op hetzelfde volume, en registreert hem als de standaardrunner `rte`, zodat playbookformulieren zonder enige instelling werken. Sinds 7.3.0
+belt de app hem aan op `127.0.0.1` en houdt één WebSocket open (`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)): de RTE krijgt geen
+database-instellingen en geen versleutelingssleutel. De config seed van de chart declareert een RTE-referentie met het token en dat adres, en
+de runner, modus inbound, die zich daarmee aanmeldt.
+
+De standaardimage, `ghcr.io/ansibleforms/ansibleforms-rte-full`, bevat ansible met de bijbehorende collections en de Python-bibliotheken die de 6.5-image had.
+Wil je meer, of minder, bouw dan je eigen image op een van de drie RTE-lagen (`ansibleforms-rte-base`, `-rte-core` of `-rte-full`, zie
+[De RTE-images](../rte/images.html)) en laat de chart ernaar wijzen:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+Het token tussen de app en de RTE, en de sleutel die de sessies ondertekent, worden bij de eerste installatie gegenereerd in
+de Secret `<release>-keys` en bij elke upgrade behouden. Met een eigen config seed voeg je die referentie en runner daaraan toe: de notes die Helm na de installatie toont laten zien hoe
+(zie de [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) van de chart).
+
+---
+
+## 5. Installeer de chart
+
+Installeer de chart in een eigen namespace met je waarden:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Met de OCI-registry gebruik je `oci://ghcr.io/ansibleforms/charts/ansibleforms` als chart. In alles wat zonder toezicht draait,
+pin je de chartversie met `--version`, zodat er nooit vanzelf een nieuwe release wordt geïnstalleerd.
+
+---
+
+## 6. Controleer de installatie
+
+De chart bevat een test die zowel de webserver als de databaseverbinding controleert:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+De test eindigt met `OK` als AnsibleForms antwoordt en de database verbindingen accepteert.
+
+---
+
+## 7. Open AnsibleForms
+
+Hoe je AnsibleForms bereikt, hangt af van hoe de server wordt aangeboden:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Met de standaardservice `ClusterIP` en zonder ingress wordt niets buiten het cluster aangeboden. Forward een lokale poort om
+even te kijken:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Open daarna `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Zet `services.server.type: LoadBalancer` (eventueel met een vast adres in `services.server.loadbalancer.ip`),
+en wacht tot de service zijn adres krijgt:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Schakel de ingress in en stel de hostnaam in die naar je ingress-controller routeert:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+De [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) van de chart behandelt TLS achter een ingress, inclusief de backend-instelling die HTTPS op de
+server nodig heeft.
+
+</div>
+</div>
+
+---
+
+## 8. Meld je aan
+
+Meld je aan als de beheerder, standaard `admin`. Zo lees je het wachtwoord uit de Secret:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Met `secrets.existingSecret` lees je het in plaats daarvan uit je eigen Secret.
+
+---
+
+## Een Runner op Kubernetes
+
+Met `runner.enabled` installeert de chart alleen een RTE: een Runner voor een AnsibleForms dat elders is geïnstalleerd, in een andere namespace, een ander
+cluster of op een VM. Hij belt de app aan en houdt één WebSocket open (`RTE_MODE=outbound`, zie [Modi](../rte/modes.html)), dus hij heeft
+geen database, geen versleutelingssleutel en geen inkomende poort nodig. Hij rendert geen app, geen MySQL, geen Service en geen Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Waarde | Wat het doet |
+|---|---|
+| `runner.enabled` | Installeert alleen de Runner: geen app, geen MySQL, geen Service, geen Ingress |
+| `runner.appUrl` | Het adres van de app zoals mensen het openen, met de eventuele `BASE_URL`. Verplicht |
+| `runner.name` | De runnernaam waarmee hij aansluit (`RTE_NAME`). Leeg: de naam van de release |
+| `runner.joinToken` | Een [jointoken](../runners/registration.html#join-tokens) gemaakt in de app, gelezen bij de eerste start om de Runner meteen goed te keuren |
+| `runner.appTlsVerify` | `false` accepteert het zelfondertekende certificaat van de app (`APP_TLS_VERIFY=0`), alleen binnen één vertrouwd netwerk |
+
+Zonder jointoken vraagt de Runner om aan te sluiten en wacht hij tot een beheerder hem goedkeurt onder **Verbindingen > Runners**. Eenmaal goedgekeurd
+meldt hij zich aan met zijn eigen `RTE_TOKEN`, bewaard in de Secret `<release>-keys`: bewaar die Secret samen met de release. Het
+[installatieprogramma](installer.html#kubernetes) installeert deze runnermodus ook, als je de rol Runner en Kubernetes kiest.
+
+---
+
+## Volgende stappen
+
+De [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) van de chart behandelt de rest van de configuratie:
+
+* **Je eigen database** : zet `mysql.enabled: false` en laat AnsibleForms naar een bestaande MySQL-server wijzen
+* **Formulieren uit ConfigMaps** : lever `config.yaml` en de formulierbestanden aan via ConfigMaps
+* **HTTPS achter een ingress**, resources, plaatsing op nodes en private registries
+* **De RTE** : het token, een eigen RTE-image, of helemaal geen RTE
+
+Om naar een nieuwere release te gaan, zie [Upgraden op Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/nl/_get_started/installation/native.md b/i18n/nl/_get_started/installation/native.md
new file mode 100644
index 0000000..bafd4b2
--- /dev/null
+++ b/i18n/nl/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Native
+parent: Installatie
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Native installatie
+{: .no_toc }
+
+AnsibleForms direct op de server, zonder containers, als systemd-services die het installatieprogramma opzet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders van servers waarop containers niet zijn toegestaan: het [installatieprogramma](installer.html) installeert alles wat AnsibleForms nodig heeft op
+de server zelf, en upgradet en verwijdert het daarna. Het installeert AnsibleForms 7.3.0 of later.
+
+---
+
+## Wat het nodig heeft
+
+Kies **Direct op deze server, zonder containers** bij de stap **Engine** van het installatieprogramma, of geef `--mode native` mee. Het heeft nodig:
+
+* **Root** : start het installatieprogramma met `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : de services draaien als systemd-units
+* **Een ondersteunde Linux** : Ubuntu, Debian, RHEL en de rebuilds ervan zoals Rocky Linux en AlmaLinux, SUSE Linux Enterprise of openSUSE
+* **amd64 of arm64**
+* **Internettoegang** : naar de repositories van de distributie, GitHub, nodejs.org en de pakketindexen van Python en Ansible (zie
+  [Air-gapped](#air-gapped) voor wat een releasebundel vervangt)
+
+Op een server die hier niet aan voldoet, verschijnt de engine als *Direct op deze server (vereist root: start het met sudo)* of
+*Direct op deze server (niet ondersteund op deze Linux)*. Beide rollen installeren op deze manier: een controller, en een [Runner](installer.html#a-runner).
+
+---
+
+## Wat het installeert
+
+Het installatieprogramma installeert deze uit de pakketten van de distributie, voor beide rollen:
+
+| Pakket | Waarom |
+|---|---|
+| `git` | De repositories |
+| De ssh-client | De verbindingen van de playbooks |
+| De MariaDB-client | De back-ups van de app: `app.env` zet [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) en [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) op de gevonden client, `mariadb-dump` en `mariadb` of de oudere `mysqldump` en `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | De downloads |
+| `libatomic` | Node.js linkt ertegen, en minimale servers missen het |
+| `sshpass` | Playbooks die zich met een ssh-wachtwoord aanmelden. Op RHEL en de rebuilds ervan komt het uit EPEL, dat het installatieprogramma met `epel-release` probeert in te schakelen; als het niet kan worden geïnstalleerd, gaat de installatie door en meldt het dat |
+| De MariaDB-server | Alleen bij een controller: de database |
+
+Daarna, in de installatiemap, met elke download gecontroleerd tegen de gepubliceerde checksum:
+
+* **AnsibleForms** : de releasebundel `ansibleforms-<version>-linux-<arch>.tar.gz` uit de GitHub-release van de app, de app gebouwd voor
+  Node.js. Een versie zonder bundel meldt *Installeren zonder containers vereist AnsibleForms 7.3.0 of hoger.*
+* **Node.js** : de nieuwste release van de hoofdversie die de bundel noemt, van nodejs.org
+* **Python en Ansible** : uv, en daarmee de Python van de RTE-images en een virtuele omgeving met Ansible en de bibliotheken van
+  de volledige RTE-image, en daarna de Ansible-collections ervan (zie [De RTE-images](../rte/images.html)). Dit duurt een paar minuten
+* **De startbestanden** : de formulieren, playbooks en instellingen uit de map `data` van het
+  [docker-compose-project](https://github.com/ansibleforms/docker), zoals een nieuwe Docker Compose-installatie ze krijgt. Een Runner houdt alleen zijn Ansible-configuratie en ssh- en git-instellingen
+
+Voor een controller maakt het daarna het schema `AnsibleForms` in MariaDB aan, en een databasegebruiker met de naam van de instantie, met alle rechten op dat
+schema en nergens anders, die zich alleen vanaf deze server aanmeldt.
+
+---
+
+## De map
+
+Alles staat in de installatiemap, standaard `/opt/ansibleforms` (of `/opt/ansibleforms-runner` voor een Runner):
+
+| Pad | Wat het bevat |
+|---|---|
+| `releases/<version>/` | Een release: de bundel, de link naar Node.js, de virtuele Python-omgeving en de collections |
+| `current` | De link naar de release die draait; een upgrade verplaatst hem, en een rollback ook |
+| `runtime/` | Node.js, uv en Python, gedeeld door de releases |
+| `data/` | Wat de containers koppelen als `/app/dist/persistent`: formulieren, playbooks, `config.yaml`, de config seed, certificaten en logs |
+| `home/` | De homemap van de systeemgebruiker: `.ssh` en `.gitconfig`, gelinkt aan `data/ssh` en `data/git` |
+| `app.env`, `rte.env` | De instellingen en secrets van de services, alleen leesbaar voor root en de systeemgebruiker. Die van de RTE bevat geen database-instellingen |
+| `installer-backups/` | De databaseback-ups die het installatieprogramma maakt, vóór een upgrade of met `backup` |
+
+De releases en de runtimes zijn van root, zodat de services hun eigen code niet kunnen wijzigen; `data/` en `home/` zijn van de systeemgebruiker.
+De databasebestanden zelf worden door MariaDB bewaard, buiten de map.
+
+---
+
+## De services
+
+Een controller draait twee systemd-services, een Runner één. Elke service draait als een systeemgebruiker met de naam van de instantie (standaard `ansibleforms`),
+vanuit `current/server`, met zijn instellingenbestand:
+
+| Service | Wat hij draait | Instellingen |
+|---|---|---|
+| `<name>` | De app: de webinterface, de API en de worker. Alleen bij een controller | `app.env` |
+| `<name>-rte` | De RTE die de playbooks uitvoert | `rte.env` |
+
+De RTE van een controller is `inbound` op een eigen poort op `127.0.0.1` (`8001`, of de eerstvolgende vrije, met
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), voert de playbooks uit vanuit de mappen van de app (`RTE_FILES=local`),
+en wordt door de config seed `data/seed.yaml` als standaardrunner gedeclareerd.
+
+De RTE van een Runner krijgt de modus, `APP_URL`, `RTE_NAME` en, met `--join`, het jointoken, en ontvangt de playbooks bij elke job (zie
+[Modi](../rte/modes.html)). Een uitgaande RTE krijgt geen aanroepen van de app, dus luistert hij alleen op `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Een inkomende serveert HTTPS met een zelfondertekend certificaat voor zijn eigen adres in `data/certificates`, dat AnsibleForms pint.
+Zonder jointoken vraagt hij om aan te sluiten, en een beheerder keurt hem goed onder **Verbindingen > Runners**.
+
+Ze starten bij het opstarten en herstarten na een storing. Beheer ze en lees hun logs met de eigen tools van systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+De app mag zonder root op een poort onder 1024 luisteren, zoals `443`. De RTE behoudt het recht om `sudo` te gebruiken, wat playbooks met
+`become` op deze server nodig hebben, zodat een playbook de server kan beheren waarop de RTE draait.
+
+---
+
+## Upgraden en terugdraaien
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` upgradet een native installatie zoals de andere (zie [Upgraden](installer.html#upgrade)), in
+deze volgorde:
+
+1. Zet de nieuwe release klaar naast de release die draait: de bundel, Node.js, Python, Ansible en de collections. De draaiende
+   services worden nog niet aangeraakt
+2. Voegt de nieuwe startbestanden toe die de release meebrengt, en behoudt elk bestaand bestand
+3. Maakt een back-up van de database (bij een controller) in `installer-backups/`, met een kopie van `app.env` en `rte.env`
+4. Stopt de services, laat `current` naar de nieuwe release wijzen, en start ze weer
+5. Wacht tot de app antwoordt met de nieuwe versie (bij een Runner: tot zijn RTE weer luistert)
+
+Als de nieuwe versie niet antwoordt, biedt het installatieprogramma aan terug te draaien: `current` wijst weer naar de vorige release, de
+database wordt uit de back-up hersteld, en de services starten. Alleen de draaiende release en de release daarvoor worden bewaard.
+
+Native services in de indeling van het installatieprogramma zonder `installer.json` ernaast, bijvoorbeeld nadat dat bestand is verwijderd, worden gevonden door `install`
+en `upgrade`, die aanbieden ze over te nemen (zie [Een bestaande installatie](installer.html#an-existing-installation)).
+
+---
+
+## Verwijderen
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` stopt en verwijdert de services. Het houdt de map en de database, tenzij je ervoor kiest
+de gegevens te verwijderen (of `--purge` meegeeft), en de naam van de instantie typt om te bevestigen. Dan verwijdert het ook de database en de gebruiker ervan (bij een controller),
+wist het de map en verwijdert het de systeemgebruiker.
+
+De pakketten blijven geïnstalleerd, MariaDB ook: andere software kan ze gebruiken.
+
+---
+
+## Air-gapped
+
+`--bundle` installeert vanuit een releasebundel die je naar de server hebt gekopieerd, in plaats van hem van GitHub te downloaden. Neem het bestand voor de
+architectuur, `ansibleforms-<version>-linux-amd64.tar.gz` of `-arm64`, uit de [Releases](https://github.com/ansibleforms/ansibleforms/releases) van de app:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` doet hetzelfde voor de startbestanden, vanuit een lokale kopie van de repository [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python met de pakketten en de Ansible-collections worden tijdens de installatie nog steeds gedownload.
diff --git a/i18n/nl/_get_started/upgrade-7.md b/i18n/nl/_get_started/upgrade-7.md
new file mode 100644
index 0000000..52745ce
--- /dev/null
+++ b/i18n/nl/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Upgraden naar v7
+parent: Upgraden
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Upgraden naar v7
+{: .no_toc }
+
+Wat je nog op 6.5 moet aanpassen, en wat er verandert als je naar versie 7 gaat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Versie 7 schrapt alles wat 6.x als verouderd markeerde; los het eerst op 6.5 op, waar oud en nieuw allebei werken, en upgrade daarna.
+
+---
+
+## Voordat je upgradet (op 6.5)
+
+### Formulieren staan in eigen bestanden
+
+Formulieren staan alleen nog in de map met formulieren (`FORMS_FOLDER_PATH`) of in een formulierenrepository; `config.yaml` bevat de categorieën, rollen en constanten.
+
+- **Een bestand `forms.yaml`:** hernoem het naar `config.yaml`. Op 6.5 heeft de instellingenpagina daarvoor een knop
+  **Convert forms.yaml to config.yaml**.
+- **Een sectie `forms:` in de basisconfiguratie:** versie 7 weigert die. Zet elk formulier in een eigen bestand, bijvoorbeeld
+  door het in de designer van 6.5 naar een bestand te slepen.
+- **Omgevingsvariabelen:**
+
+  | Verwijderd | Gebruik in plaats daarvan |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` en `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### Het veld `table`
+
+Versie 7 weigert velden van het type `table`, en hun eigenschappen (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`) verdwijnen mee: gebruik een veld `list` met een `subform`, en maak van de `from` van elke kolom een expressie
+op `__parent__` (zie de [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Hernoemde eigenschappen
+
+Elke verwijderde eigenschap heeft een directe vervanger:
+
+| Verwijderd | Gebruik in plaats daarvan |
+|---|---|
+| `disableRelaunch: true` (formulier) | `allowRelaunch: false` |
+| `noOutput: true` (veld) | `output: false` |
+| `enableLogin` (rol-optie) | `allowLogin` |
+
+### Datasources en dataschema's
+
+De datasource-imports en hun beheerpagina's zijn verwijderd, net als de
+AnsibleForms Galaxy-collection, waarvan de modules alleen daarvoor dienden.
+
+- Geplande imports stoppen en de datasourcetabellen worden verwijderd: noteer eerst wat je nodig hebt.
+- De dataschema's die een import vulde zijn eigen databases en blijven bestaan. Een formulier dat
+  ze via een referentie bevraagt, blijft werken.
+- Om die gegevens actueel te houden, voer je de import uit als een eigen playbook, bijvoorbeeld vanuit een
+  planning.
+
+### API v1
+
+`/api/v1/*` is verwijderd; gebruik `/api/v2/*` (interactieve documentatie op `/api/v2/docs`). De aanroepen die
+scripts meestal gebruiken zijn:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+v2 antwoordt met HTTP-statuscodes (`400`, `403`, `404`, `422`) en een gewone JSON-body, niet met de envelop
+`{ status, message, data }` van v1.
+
+**Ook de callbacks van single sign-on.** Een redirect-URL met `/api/v1/` antwoordt niet meer: de aanmelding keert terug naar
+de aanmeldpagina zonder je aan te melden. Wijzig hem naar `/api/v2/` op twee plaatsen, bij de SSO-provider in
+AnsibleForms en bij de identity provider (de redirect-URI's van de app-registratie in Entra ID, de geldige redirect-URI's van de OIDC-
+client):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback`, of `/api/v2/auth/entraid/callback` vanaf 7.3.0
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Wat er verandert in 7
+
+Versie 7 verandert hoe playbooks draaien en maakt verschillende standaardwaarden strenger. Controleer elk punt hieronder als je van 6.5 overstapt.
+
+### Playbooks draaien op een RTE
+
+Versie 7 draait `ansible-playbook` niet meer in de AnsibleForms-container. Playbooks draaien op een runtime-omgeving (RTE),
+een eigen container, en de app-image bevat geen ansible of python meer. Start een RTE naast de app, vanuit de
+image `ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Sinds 7.3.0 belt de app de RTE aan en houdt één WebSocket open (zie
+[Modi](rte/modes.html)): de RTE krijgt geen database-instellingen en geen `ENCRYPTION_SECRET`. De instellingen ervan:
+
+| Instelling | Waarde |
+|---|---|
+| `AF_ROLE` | `rte`. De RTE-images zetten dit al. |
+| `RTE_MODE` | `inbound`: de app belt de RTE aan. Een Runner in een ander netwerk gebruikt `outbound` (zie [Modi](rte/modes.html)). |
+| `RTE_TOKEN` | Een token van minstens 16 tekens. De app meldt zich daarmee aan bij de socket van de RTE, en de RTE weigert te starten zonder token. |
+| `RTE_FILES` | `local` als de RTE dezelfde persistente map koppelt als de app, zoals wanneer hij ernaast draait. |
+
+Verplaats daarna de ansible-koppelingen van de app-container naar de RTE:
+
+- `ansible.cfg` op `/etc/ansible/ansible.cfg`, je rollen op `/etc/ansible/roles` en je collections op
+  `/etc/ansible/collections`.
+- Koppel dezelfde persistente map als de app ook op de RTE, zodat die de playbooks en de repositories vindt.
+
+Declareer de RTE daarna als runner, in de [config seed](seed/) zoals het Docker Compose-project doet, of onder **Verbindingen → Runners**:
+een RTE-referentie met het adres van de RTE (bijvoorbeeld `http://rte:8000`) en hetzelfde token, en een runner van het type RTE, modus inbound,
+die haar noemt:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+De seed leest `RTE_TOKEN` uit de omgeving van de app. Zie [Runners](runners.html) en [Runtime-omgevingen](rte/).
+
+{: .warning }
+> **Hetzelfde contract voor de app en de RTE** De app lost de referenties van een job op en geeft ze aan de RTE, verzegeld voor
+> die RTE (RTE-contract 2, nieuw in 7.0.0). Een RTE met een ander contract weigert de jobs van de app: draai de RTE-image van dezelfde
+> release als de app, en upgrade beide samen. Latere 7-releases blijven werken met een oudere 7-RTE zolang het contract
+> hetzelfde blijft (zie [Schalen](../rte/images.html#build-your-own-rte)).
+
+
+### Wat de RTE-image bevat
+
+De RTE komt in drie lagen, elk gebouwd op de vorige. Kies de laag die bij je playbooks past:
+
+| Image | Inhoud |
+|---|---|
+| `ansibleforms-rte-full` | De standaard. Ansible 14 met ansible-core 2.21, en de collections en python-bibliotheken die de 6.5-image had. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core en een paar gangbare bibliotheken, zonder collections. Voeg je eigen toe in een image die erop is gebouwd. |
+| `ansibleforms-rte-base` | Alleen de server, zonder python of ansible, om een RTE met je eigen versies te bouwen. |
+
+De overstap van 6.5 (ansible 12 met ansible-core 2.19) verandert voor je playbooks ook het volgende:
+
+- **ansible-core 2.21:** lees de [porting guides](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  voor 2.20 en 2.21.
+- **Python 3.14:** de RTE-lagen draaien op python 3.14.
+- **Geen `boto` meer:** de oude bibliotheek `boto` 2 is weg. De collection `amazon.aws` gebruikt `boto3`, dat erin zit.
+
+Twee omgevingsvariabelen horen nu bij de RTE en worden niet meer door de app gelezen, dus stel ze in de RTE-container in:
+
+| Variabele | Wijziging |
+|---|---|
+| `ANSIBLE_PATH` | De map met playbooks, op de RTE. |
+| `PROCESS_MAX_BUFFER` | Nu standaard 50 MB. Daarboven wordt de uitvoer van de job niet meer opgeslagen (de job meldt dat), maar gaat het playbook door in plaats van te worden gestopt. |
+
+
+### De containers draaien als uid 1000
+
+De images van de app en de RTE draaien als de gebruiker `node` (uid 1000) in plaats van root, en hun homemap is `/home/node`:
+
+- **Maak uid 1000 eenmalig eigenaar van de volumes.** Voor de persistente en ssh-volumes voer je
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v` uit; voor een map op de host `sudo chown -R 1000:1000 <folder>`.
+  Op Kubernetes zet je `fsGroup: 1000`.
+- **Koppel de ssh-map op `/home/node/.ssh`**, niet op `/root/.ssh`. Als je
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) op `/root` hebt gezet, verwijder het dan of zet het op `/home/node`.
+- **Je eigen RTE-image**, gebouwd op een RTE-laag, schakelt voor de installaties over naar `USER root` en aan het eind terug naar `USER node`.
+
+
+### Startvalidatie staat aan
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) staat nu standaard op `enforce` (6.5: `off`). Elke
+start, vanuit de browser of via `POST /api/v2/job`, wordt gecontroleerd tegen de regels van het formulier, en de job draait met de extravars en
+referenties die de server uit de gecontroleerde waarden opbouwt.
+
+- **REST-aanroepers moeten `rawFormData` meesturen**, de ruwe veldwaarden zoals de browser ze stuurt. Een start met alleen
+  `extravars` wordt geweigerd, omdat de waarden ervan niet te controleren zijn.
+- **Om eerst te zien wat geweigerd zou worden**, zet je `LAUNCH_VALIDATION=log` en lees je de waarschuwingen in het log. `off` herstelt het
+  gedrag van 6.5.
+
+Zie [Startvalidatie](launch-validation/) voor de details.
+
+
+### Playbooks zien de instellingen van de app niet meer
+
+Een playbook erft niet meer de omgevingsvariabelen die AnsibleForms zelf leest: `ENCRYPTION_SECRET`, de `DB_*`-instellingen,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, de `VAULT_*`-instellingen, elke andere gedocumenteerde variabele en elke `MYSQL_*`-variabele.
+De rest van de omgeving van de RTE, zoals `PATH`, proxy's, `ANSIBLE_*`-instellingen en cloudreferenties, wordt doorgegeven zoals voorheen.
+
+Een playbook dat een van deze met `lookup('env', ...)` las, moet de waarde op een andere manier krijgen: geef hem door als extravar of als
+referentie, of stel hem op de RTE in onder een andere naam.
+
+### Alleen de rol admin beheert runners en beheerders
+
+Een gebruiker met toegang tot de instellingen heeft niet langer volledige controle over wie beheerder is en waar referenties naartoe gaan:
+
+- **Runners:** alleen de rol admin voegt een runner toe, wijzigt of verwijdert hem, omdat een runner de referenties ontvangt van de jobs
+  die hij uitvoert. Gebruikers met toegang tot de instellingen kunnen runners nog steeds zien en testen.
+- **Beheerdersaccounts en -groepen:** alleen de rol admin kent beheerdersrechten toe. Zonder die rol kan een gebruiker geen account in een groep zetten die de
+  rol admin noemt, en geen beheerdersaccount of zo'n groep wijzigen, resetten of verwijderen.
+- **Rollen:** een designer zonder de rol admin kan de rollen niet wijzigen. Een opslag of herstel waarvan de rollen afwijken, wordt geweigerd.
+
+Geef de rol admin aan wie runners, beheerders en rollen beheert.
+
+### Het standaardwachtwoord moet worden gewijzigd
+
+Een gebruiker die zich aanmeldt met het openbare standaardwachtwoord `AnsibleForms!123` moet het eerst wijzigen. Tot die tijd antwoordt elke andere API-
+aanroep met `403` en de code `password_change_required`, en toont de browser de pagina om het wachtwoord te wijzigen.
+
+Meld je één keer aan en kies een nieuw wachtwoord, of stel [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) in vóór de
+eerste start. Scripts die zich met het standaardwachtwoord aanmelden, moeten een ander gebruiken.
+
+### Tokens vervallen bij afmelden en wachtwoordwijziging
+
+Afmelden beëindigt nu de tokens van die sessie, en een wachtwoordwijziging beëindigt elke sessie van die gebruiker, dus meld je opnieuw aan na
+het wijzigen van een wachtwoord.
+
+Een API-token dat met `?expiryDays=` is aangevraagd, leeft hooguit [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) dagen
+(standaard 90). Scripts die langlevende API-tokens gebruiken, moeten een nieuw token aanvragen voordat het oude verloopt.
+
+### Entra ID heeft je tenant nodig
+
+Aanmelden met Entra ID (Azure AD) gebruikt nu OpenID Connect, alleen tegen je eigen tenant, en een gebruiker van een andere tenant kan zich niet
+aanmelden. Een provider zonder tenant-id, of met `common`, `organizations` of `consumers`, wordt geweigerd.
+
+- **Stel de tenant-id in** bij de SSO-provider: de Directory (tenant) ID, een GUID, of het domein van de tenant.
+- **Ken de Graph-machtigingen toe:** de aanmelding vraagt om `openid profile email User.Read GroupMember.Read.All`. Geef de app-
+  registratie de gedelegeerde Microsoft Graph-machtigingen `User.Read` en `GroupMember.Read.All`, met admin consent.
+- **Gebruik bij voorkeur groeps-id's in rollen:** noem een groep als `azuread/<object id>` (`entraid/<object id>` vanaf 7.3.0) in plaats van met de weergavenaam.
+
+Zie [Entra ID](authentication/entra-id.html) voor de instelling.
+
+### Wachtwoorden hebben een minimale lengte
+
+Een lokaal wachtwoord dat via de applicatie wordt ingesteld, heeft minstens
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) tekens nodig (standaard 8), en mag niet de gebruikersnaam of het
+standaardwachtwoord zijn. `PASSWORD_MIN_LENGTH=0` schakelt de lengtecontrole uit. Bestaande wachtwoorden blijven werken.
+
+### Draai de containers met een restart policy
+
+Een niet-afgevangen exceptie beëindigt nu het proces, gelogd op niveau `crit`, in plaats van het in een onbekende toestand te laten doordraaien. Draai
+de containers met een restart policy, zoals `--restart unless-stopped` met Docker (het docker-compose-project stelt die in).
+Kubernetes herstart de pods zelf.
+
+### AWX-verbindingen en de homelink
+
+Nog twee dingen zijn weg in 7, zonder dat je op 6.5 iets hoeft te doen:
+
+- **AWX- en AAP-verbindingen:** de tabel `awx`, `/api/v2/awx` en de pagina A.A.P. zijn weg. De upgrade zet elke AWX- of
+  AAP-verbinding over naar **Verbindingen → Runners**, als runner van het type `awx`, en formulieren met `awx:` blijven werken.
+- **`NAV_HOME_LABEL` en `NAV_HOME_ICON`:** worden niet meer gelezen. De eerste link in de kopbalk is altijd Formulieren.
+
+### Verouderd in 7, verwijderd in 8
+
+Deze werken nog in 7, maar elk logt een waarschuwing als het wordt gebruikt. Stap vóór versie 8 over op de vervanger:
+
+| Verouderd | Gebruik in plaats daarvan |
+|---|---|
+| Omgevingsvariabelen `VAULT_*` | Een secret store met de naam `vault` (**Verbindingen → Secret stores**). De eerste start van 7 importeert de variabelen één keer als die store, en negeert ze daarna. |
+| Omgevingsvariabelen `LOG_SYSLOG_*` | Een syslogserver (**Verbindingen → Syslog**). Als `LOG_SYSLOG_HOST` is ingesteld, importeert de eerste start van 7 ze één keer als de server `syslog`, die net als voorheen het serverlog ontvangt, en negeert ze daarna. Om ook de auditregels te versturen, stel je hem in om beide te ontvangen. |
+| `vault_path` op een referentie (API, config seed) | `secret_store` en `secret_ref`. Zie [Secret stores](secret-stores/). |
+| De rol `public` in `config.yaml` | De rol `default`. Het bestand wordt hernoemd als de configuratie laadt; hernoem een ytt-template met de hand. `public` in de `roles:` van een formulier blijft overeenkomen. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` op een formulier of een stap | `approval`. `hasApproval` heeft geen effect. |
+| `awx: <name>` op een formulier | `runner: <name>`. Een AWX-verbinding is een runner van het type `awx`. |
+| `type: multistep` op een formulier, met de bijbehorende `steps` | `type: workflow`, met nodes die een `runner` noemen. Zie [Workflowformulieren](forms/workflow.html). |
+| De sectie `awx:` van de config seed | Items onder `runners:` met `type: awx` |
+| `LOCK_PATH` | Niets: wordt niet meer gelezen, de vergrendeling van de designer wordt in de database bijgehouden. |
+| Een RTE in databasemodus, sinds 7.3.0: `RTE_MODE=database` of geen `RTE_MODE`, met de `DB_*` en `ENCRYPTION_SECRET` van de database op de RTE | `RTE_MODE=outbound` of `RTE_MODE=inbound`, zonder `DB_*`. De RTE sluit één keer aan met een jointoken (`RTE_JOIN_TOKEN`), of zijn runner wordt op die modus gezet onder **Verbindingen → Runners** of in de config seed (`rte_mode`). Zie [Modi](rte/modes.html). |
+| `RTE_REGISTER`, sinds 7.3.0 (alleen databasemodus) | Een jointoken (`RTE_JOIN_TOKEN`): de RTE voegt zichzelf toe als runner die zich aanmeldt met een RTE-referentie. |
+| Een referentie `api` of `userpass` op een runner van de config seed, sinds 7.3.0 | Een referentie van het soort van de runner (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` of `jenkins`), met de server in `url`. |
+| Een runner van de config seed met een eigen `token`, of `username` en `password`, sinds 7.3.0 | Een referentie van het soort van de runner in de sectie `credentials`, met de server in `url`, die de runner noemt met `credential:`. De seed maakt intussen een referentie met de naam van de runner. |
+
+`ENABLE_SSO` en `SSO_AUTO_LOGIN` worden sinds 7.3.0 niet meer gelezen. De eerste start van 7.3 neemt ze één keer over: `ENABLE_SSO=0` schakelt
+elke SSO-provider uit, en `SSO_AUTO_LOGIN=1` vinkt **Aanmeldpagina overslaan** aan bij de enige ingeschakelde provider. Daarna worden ze genegeerd: elke start
+logt een waarschuwing zolang ze zijn ingesteld, en elke provider heeft **Ingeschakeld** en **Aanmeldpagina overslaan** onder **Toegang → SSO**.
+
+---
+
+## Image-tags
+
+`latest` gaat met 7.0.0 naar 7. Om op 6 te blijven, gebruik je de tag `6` (of `6.5`) in plaats van `latest`.
+Alle tags staan onder [Image-tags](installation/#image-tags).
+
+---
+
+## Terugdraaien
+
+Maak een back-up voordat je upgradet (**Instellingen → Back-ups**). 6.5 draait op een database die naar 7 is geüpgraded, maar alleen
+de back-up herstelt de verwijderde datasourcedefinities.
diff --git a/i18n/nl/_get_started/upgrading/docker-compose.md b/i18n/nl/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..d4edabc
--- /dev/null
+++ b/i18n/nl/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Upgraden
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Upgrade een installatie die met het docker-compose-project is gemaakt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Het docker-compose-project draait drie containers: MySQL (`mysqldb`), AnsibleForms (`app`) en de RTE die de
+playbooks uitvoert (`rte`). AnsibleForms en de RTE gebruiken de image-tag `7`, die altijd naar de nieuwste 7.x-release wijst. Een
+upgrade haalt de images opnieuw op en maakt de containers waarvan de image is veranderd opnieuw aan. Alles wat bewaard moet blijven, staat
+in de map `data` en blijft behouden.
+
+---
+
+## Voordat je upgradet
+
+Bereid de upgrade zo voor dat je terug kunt als er iets misgaat:
+
+* **Maak een back-up** onder **Instellingen → Back-ups**. De nieuwe release upgradet het databaseschema bij de eerste start.
+* **Lees de [changelog](../changelog)** voor de releases tussen je versie en de nieuwe.
+* **Ga je naar een nieuwe hoofdversie?** Volg eerst [Upgraden naar v7](../upgrade-7.html).
+* **Kom je van 6.5?** Het 6.x-project, op de branch `v6`, heeft geen container `rte`. Werk je kopie van het project bij naar
+  de branch `main`, en behoud daarbij je `.env`-instellingen en je map `data`, zodat `docker-compose.yml` de service `rte`
+  heeft. Dat compose-bestand zet `CONFIG_SEED_PATH`, en een 6.x-map `data` heeft geen `seed.yaml`: kopieer `data/seed.yaml` uit
+  de repository, en voeg `RTE_TOKEN` (minstens 16 tekens) toe aan je `.env`, zoals de `.env` van de repository het heeft. Zonder die twee
+  weigert de app te starten. De images van 7 draaien als uid 1000 in plaats van root: maak die gebruiker één keer eigenaar van de map `data`, en laat de MySQL-
+  bestanden aan MySQL, met `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  De map `data/ssh` wordt nu gekoppeld op `/home/node/.ssh` in plaats van `/root/.ssh`.
+* **Kom je van 7.2?** Werk `docker-compose.yml` en `data/seed.yaml` samen bij: zie eerst [Van 7.2 naar 7.3](#from-72-to-73).
+
+---
+
+## Van 7.2 naar 7.3
+
+Tot en met 7.2.0 kreeg de service `rte` de instellingen van de database, en zijn runner, gedeclareerd in `data/seed.yaml`, draaide in databasemodus,
+verouderd in 7.3.0 en verwijderd in 8.0.0. Sinds 7.3.0 belt de app de RTE aan op `http://rte:8000` en houdt één WebSocket open
+(`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)), en bevat de RTE geen database-instellingen. Neem beide bestanden uit de branch
+`main` van de repository, en behoud je `.env`:
+
+| Bestand | Wat er verandert |
+|---|---|
+| `docker-compose.yml` | De service `rte` leest `.env` niet meer: hij krijgt `RTE_MODE=inbound`, `RTE_TOKEN` en `RTE_FILES=local`, en geen `DB_*` |
+| `data/seed.yaml` | Een RTE-referentie `rte`, met `url: http://rte:8000` en `password: ${RTE_TOKEN}`, en de runner `rte` met `rte_mode: inbound` en `credential: rte` |
+
+Wijzig beide. Met alleen het nieuwe compose-bestand houdt de seed de runner `rte` in databasemodus: de app roept de RTE aan als een 7.2-RTE,
+waarop de nieuwe RTE niet antwoordt, en er draait geen enkel playbook. Een seed die je zelf hebt gewijzigd, heeft dezelfde referentie en `rte_mode` nodig.
+
+Een runner die de seed heeft gemaakt, blijft beheerd en alleen-lezen onder **Verbindingen → Runners**, ook nadat je `CONFIG_SEED_PATH` verwijdert: alleen een
+seed die wordt toegepast, geeft een runner vrij die hij niet meer declareert. Houd de seed dus en zet `rte_mode` daar, in plaats van
+`CONFIG_SEED_PATH` te verwijderen om de runner met de hand te wijzigen.
+
+Het [installatieprogramma](../installation/installer.html#upgrade) doet dit zelf: de upgrade vervangt `docker-compose.yml`, en `data/seed.yaml`
+als dat een seed is die de repository meeleverde, ongewijzigd. Een met de hand gewijzigde seed blijft staan, en de nieuwe wordt ernaast opgeslagen.
+
+---
+
+## 1. Haal de nieuwe images op
+
+Download de nieuwste images van de tags in `docker-compose.yml`:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Maak de containers opnieuw aan
+
+Start het project opnieuw; de containers waarvan de image is veranderd, worden opnieuw aangemaakt:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Controleer de upgrade
+
+Volg het log van AnsibleForms terwijl het start. De eerste start van een nieuwe release upgradet het databaseschema, en de RTE
+start zodra AnsibleForms gezond is:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+In AnsibleForms toont **Help → Over** de versie die draait, en **Instellingen → Status** de gezondheid van de
+database, het schema en de andere systemen waarvan AnsibleForms afhankelijk is.
+
+---
+
+## Terugdraaien
+
+Om terug te gaan naar de release die je eerder draaide, de versie die **Help → Over** vóór de upgrade toonde, pin je de exacte tag daarvan in
+`docker-compose.yml`, op zowel de image van AnsibleForms als die van de RTE, in plaats van `7`, en voer je stap 2 opnieuw uit. Als die release
+niet start op de geüpgradede database, herstel je de back-up die je onder **Instellingen → Back-ups** hebt gemaakt. Zet de tags terug op
+`7` om weer updates te ontvangen.
+
+**VIDEO**: [AnsibleForms upgraden](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/nl/_get_started/upgrading/docker.md b/i18n/nl/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..b43d140
--- /dev/null
+++ b/i18n/nl/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Upgraden
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Upgrade een losse container, zonder docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een losse installatie upgrade je door de containers te vervangen: haal de nieuwe images op, verwijder de oude containers en
+start nieuwe met dezelfde `run`-commando's. Sinds versie 7 zijn het er twee: AnsibleForms en de RTE die de
+playbooks uitvoert, altijd op dezelfde release. Je bestanden staan in de gekoppelde map `/app/dist/persistent` en je gegevens in
+MySQL, dus beide blijven behouden.
+
+---
+
+## Voordat je upgradet
+
+Bereid de upgrade zo voor dat je terug kunt als er iets misgaat:
+
+* **Maak een back-up** onder **Instellingen → Back-ups**. De nieuwe release upgradet het databaseschema bij de eerste start.
+* **Lees de [changelog](../changelog)** voor de releases tussen je versie en de nieuwe.
+* **Ga je naar een nieuwe hoofdversie?** Volg eerst [Upgraden naar v7](../upgrade-7.html).
+* **Kom je van 6.5?** De images van 7 draaien als uid 1000 in plaats van root: maak die gebruiker één keer eigenaar van de mappen die je koppelt, bijvoorbeeld
+  `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Kom je van 7.2?** De RTE krijgt een eigen bestand en de app belt hem aan: zie eerst [Van 7.2 naar 7.3](#from-72-to-73).
+
+---
+
+## Van 7.2 naar 7.3
+
+Tot en met 7.2.0 las de RTE het omgevingsbestand van de app, met de instellingen van de database, en voegde hij zichzelf toe als runner vanuit `RTE_URL`. Dat
+is databasemodus, verouderd in 7.3.0 en verwijderd in 8.0.0. Sinds 7.3.0 belt de app de RTE aan en houdt één WebSocket open
+(`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)), en bevat de RTE geen database-instellingen. Eén keer, vóór stap 2:
+
+1. Maak `/srv/apps/ansibleforms/rte.env` aan zoals de [installatie](../installation/docker.html#prepare-the-folders) dat doet, met
+   `RTE_MODE=inbound`, hetzelfde `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` en `HTTPS=0`. Geen `DB_*`, geen `ENCRYPTION_SECRET`, geen `RTE_URL`
+2. Declareer de runner in die modus. Voeg ofwel de [config seed](../seed/) van de installatie toe, `persistent/seed.yaml` met de RTE-referentie
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) en de runner `rte` (`rte_mode: inbound`), en voeg
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` toe aan het omgevingsbestand van de app. Of open, zonder seed, de runner onder
+   **Verbindingen → Runners**, zet de **Modus** op **Inkomend**, en kies een RTE-referentie die `http://rte:8000` en het token bevat
+
+Met de seed bevat het omgevingsbestand van de app ook `RTE_TOKEN`, hetzelfde token, omdat de seed het daaruit leest.
+
+---
+
+## 1. Haal de nieuwe images op
+
+Download de nieuwste images van AnsibleForms en de RTE voor de tag die je draait:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Vervang de containers
+
+Verwijder de oude containers en start nieuwe met de `run`-commando's van de [installatie](../installation/docker.html). De app
+leest de databaseverbinding uit zijn omgevingsbestand, met de databasegebruiker van AnsibleForms (niet root). De RTE leest zijn eigen
+`rte.env`, zonder de instellingen van de database, en de app belt hem aan over een netwerk dat beide containers delen:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Kom je van 6.5, dan is er nog geen RTE-container: de commando's `stop` en `rm` vinden alleen de app. Maak het gedeelde netwerk
+één keer aan met `docker network create ansibleforms` (of `podman network create ansibleforms`). Zet, zoals de
+[installatie](../installation/docker.html#prepare-the-folders) doet, de databaseverbinding, `ENCRYPTION_SECRET`, een `RTE_TOKEN`
+van minstens 16 tekens en `CONFIG_SEED_PATH` in het omgevingsbestand van de app, en maak `rte.env` en de config seed aan. Gebruik je eigen
+mappen waar je 6.5-installatie andere koppelde. De seed voegt de RTE onder **Verbindingen → Runners** toe als de standaardrunner `rte`;
+zie [Upgraden naar v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Controleer de upgrade
+
+Volg het log van AnsibleForms terwijl het start. De eerste start van een nieuwe release upgradet het databaseschema:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+De RTE schrijft een eigen log, dat `docker logs rte` toont. In AnsibleForms toont **Help → Over** de versie die draait, en **Instellingen → Status** de gezondheid van de
+database, het schema en de andere systemen waarvan AnsibleForms afhankelijk is.
+
+---
+
+## Terugdraaien
+
+Om terug te gaan naar de release die je eerder draaide, de versie die **Help → Over** vóór de upgrade toonde, voer je stap 2 opnieuw uit met
+de exacte tag daarvan in plaats van `7`, op zowel de image van AnsibleForms als die van de RTE. Als die release niet start op de geüpgradede
+database, herstel je de back-up die je onder **Instellingen → Back-ups** hebt gemaakt.
diff --git a/i18n/nl/_get_started/upgrading/from-source.md b/i18n/nl/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..a4d2b32
--- /dev/null
+++ b/i18n/nl/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Vanuit de broncode
+parent: Upgraden
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Vanuit de broncode
+{: .no_toc }
+
+Upgrade een installatie die vanuit de broncode is gebouwd
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een installatie die vanuit de broncode is gebouwd, upgrade je door de nieuwe release uit te checken, opnieuw te bouwen en de
+applicatie te herstarten. Je instellingen, formulieren, playbooks, certificaten en logs staan in `server/persistent`, dat Git en de
+build niet wijzigen.
+
+---
+
+## Voordat je upgradet
+
+Bereid de upgrade zo voor dat je terug kunt als er iets misgaat:
+
+* **Maak een back-up** onder **Instellingen → Back-ups**. De nieuwe release upgradet het databaseschema bij de eerste start.
+* **Lees de [changelog](../changelog)** voor de releases tussen je versie en de nieuwe.
+* **Ga je naar een nieuwe hoofdversie?** Volg eerst [Upgraden naar v7](../upgrade-7.html).
+* **Controleer welke Node.js-versie** de nieuwe release vereist, in de changelog.
+
+---
+
+## 1. Haal de nieuwe release op
+
+Haal de release-tags op en check de gewenste release uit. Release-tags dragen het versienummer, en `git tag` toont
+ze; de branch `main` kan wijzigingen bevatten die nog niet zijn uitgebracht:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Opnieuw bouwen
+
+Bouw opnieuw in dezelfde drie stappen als bij de installatie. Bouw eerst de client opnieuw:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Werk daarna de afhankelijkheden van de server bij:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Kopieer tot slot de opnieuw gebouwde client weer naar de map `views` van de server:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Vergelijk `.env.example`, in de root van de repository, met je `persistent/.env` om instellingen over te nemen die de release toevoegt.
+
+---
+
+## 3. Herstarten
+
+Herstart de applicatie en de RTE om de nieuwe code te laden. Het databaseschema wordt bij de eerste start geüpgraded:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Kom je van 7.2, dan draaide de RTE in databasemodus, met de database-instellingen en `RTE_URL`, verouderd in 7.3.0 en verwijderd in 8.0.0.
+Start hem opnieuw in inbound-modus, en declareer zijn runner met een RTE-referentie in de seed of onder **Verbindingen → Runners**, zoals de
+[installatie](../installation/from-source.html#run) laat zien: `pm2 delete ansibleforms-rte`, en daarna het bijbehorende `pm2 start`-commando.
+
+Draai je de applicatie zonder PM2, stop dan `npm run start` en start het opnieuw.
+
+---
+
+## 4. Controleer de upgrade
+
+Volg het log van de applicatie terwijl die start:
+
+```bash
+pm2 logs ansibleforms
+```
+
+In AnsibleForms toont **Help → Over** de versie die draait, en **Instellingen → Status** de gezondheid van de
+database, het schema en de andere systemen waarvan AnsibleForms afhankelijk is.
+
+---
+
+## Terugdraaien
+
+Om terug te gaan naar de release die je eerder draaide, de versie die **Help → Over** vóór de upgrade toonde, check je de tag daarvan uit met
+`git checkout <version>`, en bouw en herstart je zoals in stap 2 en 3. Als die release niet start op de geüpgradede database, herstel je de back-up die je onder
+**Instellingen → Back-ups** hebt gemaakt.
diff --git a/i18n/nl/_get_started/upgrading/index.md b/i18n/nl/_get_started/upgrading/index.md
new file mode 100644
index 0000000..a8f7eb7
--- /dev/null
+++ b/i18n/nl/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Upgraden
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Upgraden
+{: .no_toc }
+
+Breng AnsibleForms naar een nieuwere release
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders van een draaiende instantie: ga naar een nieuwere release, met de methode waarmee je hebt geïnstalleerd.
+
+---
+
+## In deze sectie
+
+De upgradeprocedure hangt af van hoe je AnsibleForms hebt geïnstalleerd. Elke methode wordt op een eigen pagina beschreven:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Upgraden naar v7](../upgrade-7.html) | Wat je nog op 6.5 moet aanpassen, voordat je naar 7 gaat |
+| [Met het installatieprogramma](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, voor een installatie die het installatieprogramma heeft gemaakt: back-up, release notes en rollback |
+| [Docker](docker.html) | Haal de nieuwe image op en maak de container opnieuw aan met dezelfde instellingen |
+| [Docker Compose](docker-compose.html) | Haal de nieuwe image op en herstart het docker-compose-project |
+| [Vanuit de broncode](from-source.html) | Haal de nieuwe code op, bouw hem opnieuw en herstart de applicatie |
+| [Kubernetes](kubernetes.html) | Ververs de chartrepository en voer `helm upgrade` uit met je waarden |
+
+{: .note }
+> **Eerst een back-up** Maak een back-up voordat je upgradet (**Instellingen → Back-ups**). Het databaseschema wordt bij de eerste
+> start van de nieuwe release geüpgraded, dus de back-up is je terugvalpunt als er iets misgaat. Vanaf 7.3.0 maakt de worker er ook
+> zelf een voordat hij vanaf een oudere release upgradet, met de naam van de release, tenzij
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) `0` is.
+
+Welke release je krijgt, hangt af van de image-tag die je draait: `latest` volgt de nieuwste hoofdversie, terwijl een tag als `7`
+op die hoofdversie blijft. Alle tags staan onder [Image-tags](../installation/#image-tags).
diff --git a/i18n/nl/_get_started/upgrading/kubernetes.md b/i18n/nl/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..2ab9da2
--- /dev/null
+++ b/i18n/nl/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Upgraden
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Upgrade een installatie die met de Helm-chart is gemaakt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Elke chartversie deployt één release van AnsibleForms. Een upgrade installeert een nieuwere chartversie met je bestaande waarden;
+de gegevens op de persistente volumes blijven behouden. Een upgrade die niets verandert, laat de pods ongemoeid.
+
+---
+
+## Voordat je upgradet
+
+Bereid de upgrade zo voor dat je terug kunt als er iets misgaat:
+
+* **Maak een back-up** onder **Instellingen → Back-ups**. De nieuwe release upgradet het databaseschema bij de eerste start.
+* **Lees de [changelog](../changelog)** voor de releases tussen je versie en de nieuwe.
+* **Ga je naar een nieuwe hoofdversie?** Volg eerst [Upgraden naar v7](../upgrade-7.html).
+* **Lees de [changelog](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) van de chart** voor wijzigingen in de values.
+* **Met gegenereerde inloggegevens** (`secrets.generate`) maak je een back-up van de Secret `<release>-secrets`: `ENCRYPTION_SECRET` is niet te herstellen.
+* **Kom je van 7.2?** De RTE in de serverpod verandert van modus: zie [Van 7.2 naar 7.3](#from-72-to-73).
+
+---
+
+## Van 7.2 naar 7.3
+
+Chart 7.3.0 haalt de RTE naast de app uit databasemodus, verouderd in 7.3.0 en verwijderd in 8.0.0. De app belt hem aan op
+`127.0.0.1` en houdt één WebSocket open (`RTE_MODE=inbound`, zie [Modi](../rte/modes.html)):
+
+* De RTE-container krijgt geen `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` of `RTE_URL` meer, en haalt de bestanden van de job van
+  het gedeelde volume (`RTE_FILES=local`)
+* De config seed van de chart declareert een RTE-referentie met het token en het adres, en de runner, `rte_mode: inbound`, die zich
+  daarmee aanmeldt. Met de seed van de chart hoef je niets te doen
+* Met `containers.rte.seedRunner: false`, of een eigen config seed (`CONFIG_SEED_PATH`), voegt de RTE zichzelf niet meer toe als runner.
+  Declareer hem zelf, in je seed of onder **Verbindingen → Runners**: een RTE-referentie met `http://127.0.0.1:<port>` en het token,
+  en een runner van het type RTE met `rte_mode: inbound` die haar noemt. De notes die Helm na de upgrade toont laten zien hoe
+
+Sinds 7.3.0 installeert de chart ook een losse Runner, met `runner.enabled` (zie
+[Een Runner op Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Zoek de nieuwe chartversie
+
+Ververs de chartrepository en toon de beschikbare chartversies:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Upgrade de release
+
+Voer hetzelfde `helm upgrade`-commando uit als bij de installatie, met je valuesbestand en de nieuwe chartversie:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Met de OCI-registry gebruik je `oci://ghcr.io/ansibleforms/charts/ansibleforms` als chart.
+
+---
+
+## 3. Controleer de upgrade
+
+Wacht op de nieuwe pods en voer daarna de test van de chart uit, die zowel de webserver als de databaseverbinding controleert:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+In AnsibleForms toont **Help → Over** de versie die draait, en **Instellingen → Status** de gezondheid van de
+database, het schema en de andere systemen waarvan AnsibleForms afhankelijk is.
+
+---
+
+## Terugdraaien
+
+Helm houdt de geschiedenis van de release bij. Om terug te gaan naar de vorige revisie:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Als die niet start op de geüpgradede database, herstel dan je back-up (zie de [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) van de chart).
diff --git a/i18n/nl/_integrate/api/authentication.md b/i18n/nl/_integrate/api/authentication.md
new file mode 100644
index 0000000..2107a6c
--- /dev/null
+++ b/i18n/nl/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Authenticatie
+parent: REST API
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Authenticatie
+{: .no_toc }
+
+Aanmelden, het token vernieuwen, of een langlevend token gebruiken
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Elke aanroep heeft een access token nodig in de header `Authorization`. Je krijgt een token door je aan te melden, en houdt het vers met
+het refresh token.
+
+---
+
+## Aanmelden
+
+Meld je aan met basic authentication, met de naam en het wachtwoord van de gebruiker:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+Het antwoord bevat twee tokens, het access token en het refresh token:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## De API aanroepen
+
+Stuur het access token bij elke aanroep mee als bearer token:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Het token vernieuwen
+
+Het access token verloopt (`ACCESS_TOKEN_EXPIRATION`, standaard 30 minuten). Haal een nieuw op met het refresh token,
+zonder het wachtwoord:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+Het antwoord bevat een nieuw paar, in dezelfde vorm als bij het aanmelden. Een refresh token werkt één keer: bewaar het nieuwe voor de volgende vernieuwing.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Langlevende tokens
+
+Een script dat zonder toezicht draait, kan een token gebruiken dat langer meegaat. Vanaf 7.3.0 is daarvoor de rol-optie `allowApiTokens` nodig:
+
+* Maak er een aan onder [Profiel > API-tokens](../profile/api-token.html).
+* Of meld je aan met de queryparameter `expiryDays`, voor een token dat zoveel dagen geldig is:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` wordt alleen uit de URL gelezen, nooit uit de body. Voor een gebruiker zonder `allowApiTokens` in zijn rollen wordt het genegeerd,
+en geeft de aanmelding een token met de gebruikelijke levensduur. `expiryDays=never` vereist ook `extendedTokenExpiration`. Voeg de queryparameter `name`
+toe (`?expiryDays=90&name=nightly-backup`) om het token een naam te geven in de tokenlijst van de gebruiker.
+
+Een langlevend token leeft hooguit [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) dagen, standaard
+90: een langere `expiryDays` wordt daartoe ingekort, tenzij het `never` is. Vernieuwen geeft een gewoon token terug, dus meld je opnieuw aan als het verloopt.
+
+### Tokens van de aangemelde gebruiker
+
+De weergave **API-tokens** van het profiel gebruikt deze endpoints, die voor elk account werken, SSO inbegrepen, omdat ze geen wachtwoord nodig hebben:
+
+| Aanroep | Wat hij doet |
+|---|---|
+| `GET /api/v2/profile/tokens` | Toont je API-tokens, met hun `sid`, `name`, aanmaakdatum, vervaldatum en laatste gebruik |
+| `POST /api/v2/profile/tokens` | Maakt een token vanuit je sessie; de body bevat `expiryDays` (een getal, of `never`) en eventueel een `name` |
+| `DELETE /api/v2/profile/tokens/{sid}` | Trekt een van je tokens in |
+
+`POST` antwoordt `403` als het wordt aangeroepen met een API-token (een token kan geen ander token maken), zonder `allowApiTokens`, of als de
+sessie zich meer dan 10 minuten geleden heeft aangemeld (code `sign_in_again`): meld je dan eerst opnieuw aan. Een levensduur boven het maximum antwoordt `400`.
+
+---
+
+## Als een token eerder vervalt
+
+Een token, langlevend of niet, werkt niet meer vóór het verloopt als een van deze dingen gebeurt:
+
+* **Afmelden van de sessie**: `POST /api/v2/auth/logout` met het token beëindigt de tokens van die aanmelding, en alleen die. Een
+  afmelding in de browser beëindigt het token van een script niet.
+* **Een wachtwoordwijziging**: de gebruiker wijzigt zijn wachtwoord, of een beheerder stelt het in. Elk eerder uitgegeven token wordt geweigerd.
+* **De gebruiker wordt verwijderd of geblokkeerd**: een lokale gebruiker verwijderen, of een gebruiker blokkeren, beëindigt al zijn tokens. Een beheerder kan ook
+  de sessies van een LDAP- of SSO-gebruiker beëindigen.
+
+Een geweigerd token antwoordt `401`. Meld je opnieuw aan, met het nieuwe wachtwoord als het gewijzigd is.
+
+---
+
+## Scripts die zich bij elke run aanmelden
+
+De endpoints voor aanmelden en tokens zijn beschermd tegen floods en het raden van wachtwoorden, dus een script dat zich bij elke run aanmeldt,
+moet deze limieten kennen:
+
+| Limiet | Standaard | Wat er gebeurt |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 verzoeken per minuut vanaf één adres | Aanmelden, afmelden, vernieuwen, de SSO-endpoints, `PUT /api/v2/profile` (wachtwoordwijziging) en `POST` of `DELETE /api/v2/profile/tokens` antwoorden `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 mislukte aanmeldingen op rij | Het account wordt vergrendeld voor [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), elke aanmelding antwoordt `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 mislukte aanmeldingen vanaf één adres | Elke aanmelding vanaf dat adres antwoordt `429` tot het venster afloopt |
+
+Een `429` bevat een header `Retry-After` met het aantal seconden om te wachten: stop en wacht, probeer het niet meteen opnieuw. Een vergrendeld account
+weigert zelfs het juiste wachtwoord tot de vergrendeling afloopt, dus een script met een verkeerd wachtwoord sluit zijn gebruiker voor iedereen buiten.
+Een verkeerd huidig wachtwoord bij een wachtwoordwijziging (`PUT /api/v2/profile`) telt ook als mislukte aanmelding, en een vergrendeld account
+kan zijn wachtwoord niet wijzigen. Een geslaagde aanmelding zet de teller van het account op nul, net als een beheerder die het wachtwoord instelt.
+
+Om ver van deze limieten te blijven, meld je je één keer aan en hergebruik je het token, of gebruik je een langlevend token, in plaats van je voor
+elke aanroep aan te melden. Achter een reverse proxy stel je [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) in zodat de server
+het adres van de client ziet, anders telt elke client als één.
diff --git a/i18n/nl/_integrate/api/events.md b/i18n/nl/_integrate/api/events.md
new file mode 100644
index 0000000..1d73902
--- /dev/null
+++ b/i18n/nl/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Live events
+parent: REST API
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Live events
+{: .no_toc }
+
+Hoor wanneer jobs en instellingen veranderen, in plaats van te pollen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+De server vertelt zijn clients wat er verandert, op het moment dat het verandert. Een script kan ook meeluisteren, in plaats van om de paar seconden een job te lezen.
+
+---
+
+## De stream
+
+`GET /api/v2/events` is een stream van [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+die open blijft. Elke aangemelde gebruiker mag hem openen, met het gebruikelijke bearer token:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Als er iets verandert, stuurt hij een event `changed` met de naam van wat er veranderd is:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Namen van events
+
+Een event bevat alleen een naam, nooit gegevens, dus het verraadt niets wat de gebruiker niet mag zien. Deze namen worden verstuurd:
+
+| Naam | Wat er veranderd is |
+|---|---|
+| `jobs` | Een job: gestart, de status of uitvoer ervan, verwijderd |
+| `appearance` | De instellingen die de kopbalk toont: het thema, de naam, een aankondiging, een omgevingsvariabele |
+| `designer` | Een vergrendeling van de designer, genomen of vrijgegeven |
+| `runners` | Een runner (vanaf 7.3.0): een RTE heeft verbinding gemaakt of verbroken, gevraagd om aan te sluiten, is goedgekeurd of afgewezen, of heeft zijn modus of instellingen gewijzigd |
+
+Als je een naam hoort, lees je wat je toont opnieuw via de normale API (bijvoorbeeld `GET /api/v2/job/42`), met je eigen
+rechten. Een drukke naam wordt hooguit één keer per seconde verstuurd.
+
+---
+
+## Open houden
+
+De stream is gebouwd om proxy's en load balancers te overleven, en een client maakt zelf opnieuw verbinding:
+
+* Bij het verbinden stuurt de server een event `hello`, en vraagt de client 3 seconden te wachten voordat hij opnieuw verbinding maakt.
+* Elke 15 seconden stuurt hij een commentaarregel (`: ping`), zodat een inactieve verbinding niet wordt gesloten. Negeer regels die met `:` beginnen.
+* Events van elke app-node bereiken elke stream, met welke node de client ook verbonden is.
+* Lees na het opnieuw verbinden opnieuw wat je toont: een event dat werd verstuurd terwijl de stream weg was, wordt niet opnieuw verstuurd.
+
+---
+
+## Health en metrics
+
+De liveness- en readiness-probes (`/api/v2/live`, `/api/v2/ready`) en de Prometheus-metrics (`/api/v2/metrics`) zijn
+bedoeld voor monitoringtools, niet voor scripts die als gebruiker handelen. Zie [Monitoring](../production/monitoring.html).
diff --git a/i18n/nl/_integrate/api/index.md b/i18n/nl/_integrate/api/index.md
new file mode 100644
index 0000000..a367103
--- /dev/null
+++ b/i18n/nl/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: REST API
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# REST API
+{: .no_toc }
+
+Start formulieren en beheer AnsibleForms vanuit scripts
+{: .fs-6 .fw-300 }
+
+---
+
+Voor ontwikkelaars en automation engineers: start formulieren en beheer AnsibleForms vanuit scripts.
+
+Alles wat de webinterface doet, loopt via de REST API, dus scripts en andere tools kunnen hetzelfde.
+
+---
+
+## Overzicht
+
+De API wordt aangeboden onder `/api/v2` op de AnsibleForms-server:
+
+* **Volledige referentie** : deze pagina's behandelen wat scripts het meest gebruiken. Elk endpoint wordt beschreven, en kan worden uitgeprobeerd, op de
+  ingebouwde Swagger-pagina van de server, `https://<your server>/api/v2/docs`.
+* **Rechten** : een aanroep draait als de gebruiker wiens token hij meestuurt, met de rollen van die gebruiker, net als in de browser.
+* **Startvalidatie** : jobs die via de API worden gestart, kunnen net zo worden gecontroleerd als starts vanuit de browser
+  (zie [Startvalidatie](../launch-validation/)).
+* **Rate limits** : alleen de endpoints voor aanmelden, afmelden, tokenvernieuwing en single sign-on, de wachtwoordwijziging
+  (`PUT /api/v2/profile`) en de endpoints voor API-tokens (`POST` en `DELETE /api/v2/profile/tokens`) zijn beperkt (zie
+  [Authenticatie](authentication.html)). Andere aanroepen hebben geen rate limit (de [chatassistent](../chat/) heeft eigen
+  limieten), dus een script moet zelf zijn tempo bewaken, bijvoorbeeld als het een job volgt.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Authenticatie](authentication.html) | Aanmelden, het token vernieuwen, of een langlevend token gebruiken |
+| [Jobs](jobs.html) | Een formulier starten, de job volgen, afbreken, opnieuw starten of goedkeuren |
+| [Antwoorden en fouten](responses.html) | De vorm van een antwoord, en de statuscodes |
+| [Live events](events.html) | Horen wanneer jobs en instellingen veranderen, in plaats van te pollen |
diff --git a/i18n/nl/_integrate/api/jobs.md b/i18n/nl/_integrate/api/jobs.md
new file mode 100644
index 0000000..d2a596b
--- /dev/null
+++ b/i18n/nl/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Jobs
+parent: REST API
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Jobs
+{: .no_toc }
+
+Start een formulier, volg de job, breek hem af, start hem opnieuw of keur hem goed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Een job is één run van een formulier. Start hem met de naam en de waarden van het formulier, en volg hem daarna via zijn ID.
+
+---
+
+## Een formulier starten
+
+Stuur de naam van het formulier en de waarden ervan naar `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+Het verzoek neemt deze eigenschappen:
+
+| Eigenschap | Betekenis |
+|---|---|
+| `formName` | De naam van het formulier om te starten. Verplicht. |
+| `extravars` | De extra variabelen voor de job. `payload` wordt geaccepteerd als andere naam ervoor. |
+| `rawFormData` | De waarden van de velden van het formulier, zoals de browser ze bijhoudt. [Startvalidatie](../launch-validation/) controleert deze, en bouwt er de extravars uit op. |
+| `credentials` | Referenties om aan de job door te geven, op naam. |
+| `files` | De uploads van de bestandsvelden van het formulier (zie [Bestandsuploads](../launch-validation/file-uploads.html)). |
+
+Het antwoord bevat het ID van de nieuwe job:
+
+```json
+{ "id": 42 }
+```
+
+Om de job in verbose-modus te draaien, voeg je `"__verbose__": true` toe aan de extravars. Daarvoor is de rol-optie `allowVerboseMode` nodig,
+anders antwoordt de start `403`.
+
+---
+
+## Een bestand uploaden
+
+Een formulier met een bestandsveld heeft eerst het geüploade bestand nodig. Stuur het als multipart-deel `file` naar `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+Het antwoord beschrijft de opgeslagen upload:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Geef het ongewijzigd mee in de `files` van de start, onder de naam van het bestandsveld: `"files": { "firmware": { ... } }`. De server
+controleert het tegen zijn eigen schijf (zie [Bestandsuploads](../launch-validation/file-uploads.html)).
+
+---
+
+## De job volgen
+
+Lees de job via zijn ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+De job bevat zijn `status`, zijn `extravars` (ook als `payload`, hetzelfde object), zijn `subjobs` en zijn `output`. De
+uitvoer is HTML met de kleuren van de jobpagina; voeg `?text=true` toe voor platte tekst, wat beter past bij een script of een log:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+De `status` is `running` terwijl hij draait, en `approve` terwijl hij op goedkeuring wacht. Een job eindigt met een van deze:
+
+| Status | Betekenis |
+|---|---|
+| `success` | De job is zonder fouten voltooid |
+| `failed` | De job is mislukt |
+| `warning` | Een multistep-job is voltooid, maar onderweg is een stap met `continue` mislukt |
+| `aborted` | De job is afgebroken |
+| `rejected` | De goedkeuring is geweigerd, dus wat erop wachtte is niet uitgevoerd |
+| `abandoned` | Het proces dat de job volgde is gestopt (een herstart, een vervangen container) en de job is opgegeven |
+
+Een job die op een runner draaide toen hij werd opgegeven, kan alsnog eindigen met zijn echte uitkomst, als die runner hem toch afmaakt.
+
+---
+
+## Jobs zoeken
+
+`GET /api/v2/job` toont de nieuwste jobs eerst, als `{ "count": ..., "records": [ ... ] }`. Deze queryparameters beperken de lijst:
+
+| Parameter | Betekenis |
+|---|---|
+| `records` | Hoeveel jobs, hooguit. De standaard is [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), en 5000 het maximum tenzij `JOBS_LIST_SIZE` hoger is. |
+| `user`, `user_type` | Alleen de jobs van deze gebruiker. `user_type` is `local` als je het weglaat (`ldap`, `azuread`, `oidc` voor de andere). |
+| `runner` | Alleen de jobs die op deze runner draaiden |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Een gebruiker ziet zijn eigen jobs en de jobs die wachten op een goedkeuring die een van zijn rollen mag geven. Een beheerder, of een rol met de
+optie `showAllJobLogs` of `manageAllJobs`, ziet elke job. Een record bevat de samenvatting van de job (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); lees
+de job zelf voor de extravars en de uitvoer.
+
+`GET /api/v2/job/approvals` antwoordt met een getal: hoeveel jobs wachten op een goedkeuring die de gebruiker mag geven.
+
+---
+
+## Meer over een job
+
+Deze endpoints lezen meer van één job:
+
+| Aanroep | Wat hij teruggeeft |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | De veldwaarden waarmee de job is gestart, zoals het formulier ze bijhield. Dezelfde rechten als bij opnieuw starten gelden: je eigen job (of elke job voor een beheerder of een rol met `manageAllJobs`), een formulier dat opnieuw starten toestaat, en de rol-optie `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | De gestructureerde events van een playbookjob (vanaf 7.3.0, voor een playbook op een RTE van 7.3.0 of later): elke play, taak, hostresultaat en de recap, met hun `order`, `type`, `play`, `task`, `host`, `duration` en `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Een van die events met zijn volledige `result`, zoals het venster **Resultaat van de taak** het toont; `400` als `order` geen geheel getal is, `404` als de job zo'n event niet heeft |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Eén node van een workflowjob: `{ "node", "job", "extravars", "artifacts" }`, waarbij `job` het ID is van de eigen job van de node, of `null` als de node niet is uitgevoerd. |
+
+---
+
+## Andere acties
+
+Deze endpoints werken op een bestaande job:
+
+| Aanroep | Actie |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Een lopende job afbreken |
+| `POST /api/v2/job/{id}/relaunch` | Een job opnieuw starten, zoals hij draaide of met wijzigingen (zie [Opnieuw starten](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Een job goedkeuren die op goedkeuring wacht; je eigen job antwoordt `403`, tenzij de goedkeuring ervan `allowSelf: true` zet of je beheerder bent |
+| `POST /api/v2/job/{id}/reject` | Een job afwijzen die op goedkeuring wacht |
+| `GET /api/v2/job/{id}/download` | De uitvoer van de job downloaden |
+| `DELETE /api/v2/job/{id}` | Een job verwijderen |
+
+Afbreken, goedkeuren, afwijzen en verwijderen antwoorden met een bericht, en opnieuw starten ook met het ID van de nieuwe job:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Voeg `?verbose=true` toe aan het opnieuw starten om de nieuwe job in verbose-modus te draaien, met de rol-optie `allowVerboseMode`. Een job die
+in de verkeerde toestand is voor de actie, bijvoorbeeld bij het afbreken van een job die al is geëindigd, antwoordt `409`.
diff --git a/i18n/nl/_integrate/api/responses.md b/i18n/nl/_integrate/api/responses.md
new file mode 100644
index 0000000..897fb67
--- /dev/null
+++ b/i18n/nl/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Antwoorden en fouten
+parent: REST API
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Antwoorden en fouten
+{: .no_toc }
+
+De vorm van een antwoord, en de statuscodes
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Antwoorden zijn gewone JSON, en de HTTP-statuscode vertelt of een aanroep is geslaagd.
+
+---
+
+## Antwoorden
+
+Een geslaagde aanroep geeft het object zelf terug, of een lijst met de grootte ervan:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Een fout geeft een bericht terug, en details als die er zijn:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Statuscodes
+
+De statuscode vertelt wat er misging:
+
+| Code | Betekenis |
+|---|---|
+| `200` | De aanroep is geslaagd |
+| `400` | Het verzoek is onjuist opgebouwd, bijvoorbeeld een tokenvernieuwing zonder refresh token, of een upload zonder bestand |
+| `401` | Het token ontbreekt, is onjuist of is verlopen: meld je aan of vernieuw het |
+| `403` | De rollen van de gebruiker staan de aanroep niet toe (inclusief het goedkeuren van je eigen job, tenzij de goedkeuring ervan `allowSelf: true` zet of je beheerder bent), of het account moet eerst iets doen (zie hieronder) |
+| `404` | Het object bestaat niet |
+| `409` | Het verzoek is onvolledig (een start zonder gegevens), of het object is niet in een toestand die de actie toestaat |
+| `422` | [Startvalidatie](../launch-validation/) heeft de waarden van het formulier geweigerd; `details` vertelt waarom |
+| `429` | Te veel verzoeken naar de endpoints voor aanmelden en tokens, of te veel mislukte aanmeldingen (zie [Authenticatie](authentication.html)) |
+| `500` | De server is mislukt; het serverlog bevat de reden |
+
+Bij een job betekent een `409` dat hij in de verkeerde toestand is voor de actie: een job afbreken die niet draait (of waarvan het afbreken al gevraagd is),
+een job opnieuw starten die nog draait, of een job goedkeuren of afwijzen die niet meer op goedkeuring wacht.
+
+---
+
+## Een 403 met een code
+
+Sommige `403`-antwoorden bevatten een `code`, voor iets wat de gebruiker eerst in de browser moet doen voordat een andere aanroep werkt:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Code | Wat te doen |
+|---|---|
+| `password_change_required` | De gebruiker heeft zich aangemeld met het openbare standaardwachtwoord: wijzig het eerst in het profiel |
+| `disclaimer_required` | De disclaimer staat aan en de gebruiker heeft de huidige versie ervan nog niet geaccepteerd: accepteer hem in de browser |
+
+Een langlevend API-token (zie [Authenticatie](authentication.html#long-lived-tokens)) wordt nooit tegengehouden door de disclaimer.
diff --git a/i18n/nl/_integrate/chat/index.md b/i18n/nl/_integrate/chat/index.md
new file mode 100644
index 0000000..4f10f7e
--- /dev/null
+++ b/i18n/nl/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Chat-assistent
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Chat-assistent
+{: .no_toc }
+
+Vul formulieren in en start ze via een gesprek
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders die hem inschakelen, en de gebruikers die ermee chatten: vul formulieren in en start ze via een gesprek.
+
+Een chatknop op elke pagina opent een
+assistent die het juiste formulier vindt, om ontbrekende informatie vraagt, de eigen keuzes van het formulier
+als knoppen aanbiedt, en een samenvatting toont met een knop **Starten**. Een job start pas als de gebruiker daarop klikt.
+
+---
+
+## Hoe het werkt
+
+De assistent communiceert via de server met het AI-model, en de server beantwoordt de verzoeken van het model met dezelfde formulier-engine als de browser:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Aanroepen naar het model komen van de server**, nooit van de browser, dus de API-sleutel blijft op de server
+  (zie [Providers](providers.html)).
+- **Het model kan niets starten.** Het bereidt een eenmalige samenvatting voor; Starten controleert die opnieuw voordat er iets draait.
+- **De gebruiker kiest de doelen.** Keuzes en verplichte namen komen van de gebruiker, nooit van het model.
+- **"Ja" of "start" typen doet niets.** Alleen de knop start een job.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Inschakelen](switching-it-on.html) | De assistent inschakelen en er formulieren in aanbieden |
+| [Providers](providers.html) | Het taalmodel achter de assistent, en proxy's |
+| [Privacy en limieten](privacy-and-limits.html) | Wat het netwerk verlaat, en de limieten per gebruiker |
+| [Opnieuw starten en audit](relaunching-and-audit.html) | Opnieuw starten vanuit de chat, het audittrail en de beperkingen |
diff --git a/i18n/nl/_integrate/chat/privacy-and-limits.md b/i18n/nl/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..bc9d98d
--- /dev/null
+++ b/i18n/nl/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Privacy en limieten
+parent: Chat-assistent
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Privacy en limieten
+{: .no_toc }
+
+Wat het netwerk verlaat, en de limieten per gebruiker
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wat het netwerk verlaat
+
+Voor de formulieren die meedoen, wordt het volgende naar de provider gestuurd:
+
+- de namen en beschrijvingen van de formulieren, de veldlabels, helpteksten, keuzes en de waarden die
+  worden ingevuld;
+- het gesprek.
+
+Het volgende wordt nooit naar de provider, de pagina of het log gestuurd:
+
+- wachtwoorden (die voert de gebruiker in de browser in), opgeslagen referenties en de API-sleutel;
+- de uitvoer van een job, en de opgeslagen extravars ervan (de assistent leest alleen de status van een job, en alleen
+  als **De assistent zijn jobs laten volgen** aan staat in de instellingen).
+
+Alles onder een sleutel die op een secret lijkt (`password`, `secret`, `token`, `api_key`, ...)
+wordt gemaskeerd voordat het model of de pagina het ziet.
+
+Om formuliergegevens binnenshuis te houden, gebruik je je eigen tenant (Azure OpenAI) of een lokaal model (Ollama), geen publieke API.
+
+---
+
+## Limieten
+
+De volgende limieten worden op de instellingenpagina ingesteld:
+
+- **Berichten per gesprek** (20) - waarna de gebruiker een nieuw gesprek moet beginnen.
+- **Tool-rondes per bericht** (6) - hoe vaak het model een tool mag aanroepen voordat het antwoordt.
+- **Timeout** (60 s) - per aanroep naar de provider.
+
+De volgende limieten liggen vast: één bericht tegelijk per gesprek, hooguit 4000 tekens per bericht, 60 berichten per
+gebruiker per uur, en 5 gesprekken per gebruiker. Een gesprek wordt na 2 uur zonder bericht weggegooid.
+
+Een samenvattingskaart met een knop **Starten** kan één keer worden gebruikt, en verloopt na 15 minuten: Starten antwoordt dan dat de
+samenvatting verlopen is, en de gebruiker vraagt de assistent om een nieuwe. Gesprekken en samenvattingen worden in het geheugen bewaard, dus na
+een herstart moet de gebruiker een nieuw gesprek beginnen.
diff --git a/i18n/nl/_integrate/chat/providers.md b/i18n/nl/_integrate/chat/providers.md
new file mode 100644
index 0000000..ed32d67
--- /dev/null
+++ b/i18n/nl/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Providers
+parent: Chat-assistent
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Providers
+{: .no_toc }
+
+Het taalmodel achter de assistent, en proxy's
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Kies de provider op de instellingenpagina. Dat vult de base URL, de authenticatie en
+de API-versie in, die allemaal te wijzigen blijven. Lege velden vallen terug op de standaardwaarden van de provider.
+
+| Provider | Protocol | Base URL (standaard) | Sleutel verstuurd als |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | verplicht: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, API-versie `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | geen |
+| **Andere OpenAI-compatibele** (LiteLLM, een gateway, vLLM, LM Studio, ...) | OpenAI | verplicht, meestal eindigend op `/v1` | Bearer |
+
+Het model-ID is het ID dat de provider of proxy gebruikt (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). De assistent vereist een model dat **tool calling** ondersteunt; bij kleine lokale modellen
+verschilt die ondersteuning.
+
+Voor lokale servers en proxy's die geen sleutel nodig hebben, is alleen een base URL genoeg; er wordt dan geen authorization-header verstuurd.
+
+---
+
+## De API-sleutel
+
+De sleutel komt uit een referentie, dus hij wordt opgeslagen en geroteerd zoals elk ander secret:
+
+* Maak een referentie van het type **api** onder **Instellingen > Verbindingen > Inloggegevens** (zie [Referenties](../credentials.html)),
+  met de sleutel als wachtwoord. Hij kan de sleutel ook uit een [secret store](../secret-stores/) lezen.
+* Kies hem in het veld **Referentie** van de chatinstellingen. De sleutel wordt bij elk bericht gelezen, dus een
+  gewijzigd wachtwoord geldt vanaf het volgende bericht.
+
+Een sleutel die op de instellingenpagina is opgeslagen voordat er referenties bestonden, blijft werken zolang er geen referentie is gekozen. De
+[config seed](../seed/) stelt de sleutel zelf in, als `api_key`.
+
+---
+
+## Voor een proxy
+
+Een proxy of gateway voor het model kan deze instellingen nodig hebben:
+
+- **Authenticatie** - hoe de sleutel wordt verstuurd: `Authorization: Bearer`, `api-key`, `x-api-key`,
+  of geen. Leeg gebruikt de standaard van de provider.
+- **API-versie** - de header `anthropic-version`, of `?api-version=` in de URL bij OpenAI-compatibel (Azure).
+- **Gebruiker** - bij elke aanroep verstuurd als `user` (OpenAI-compatibel) of `metadata.user_id`
+  (Anthropic). Sommige proxy's vereisen het. Leeg verstuurt niets.
+- **Certificaatfouten negeren** - onveilig; vertrouw in plaats daarvan de CA van de proxy met `NODE_EXTRA_CA_CERTS`.
+- **Extra headers** - een JSON-object, bijv. `{"X-Org": "ops"}`. Tekstwaarden op één regel, hooguit 20;
+  de sleutel- en content-headers kunnen niet worden vervangen.
+
+---
+
+## In een container, achter een proxy
+
+De chat gebruikt gewone uitgaande HTTPS vanuit de servercontainer van AnsibleForms. Achter een
+uitgaande bedrijfsproxy stel je `HTTPS_PROXY` **en** `NODE_USE_ENV_PROXY=1` in; zonder de tweede
+negeert de ingebouwde HTTP-client van Node `HTTPS_PROXY`. Een provider met een certificaat van een
+interne CA vereist dat Node die CA vertrouwt (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Met `NODE_USE_ENV_PROXY=1` moet een model of proxy binnen het netwerk in
+`NO_PROXY` staan, anders gaat de aanroep naar de uitgaande proxy, die het niet kan bereiken.
+
+Een mislukte verbindingstest noemt de host en de reden (DNS, geweigerde verbinding of niet-vertrouwd certificaat).
diff --git a/i18n/nl/_integrate/chat/relaunching-and-audit.md b/i18n/nl/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..d24e1a2
--- /dev/null
+++ b/i18n/nl/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Opnieuw starten en audit
+parent: Chat-assistent
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Opnieuw starten en audit
+{: .no_toc }
+
+Opnieuw starten vanuit de chat, het audittrail en de beperkingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Opnieuw starten
+
+Een verzoek als "Start job 1234 opnieuw" (de gebruiker moet het job-ID typen) toont een voorbeeld van een herstart
+onder dezelfde regels als `relaunch_job` van de MCP-server, inclusief de wachtwoordregel van
+[startvalidatie](../launch-validation), en toont een samenvatting **Opnieuw starten**; de knop
+start hem één keer. "Start job 1234 opnieuw met server web02" wijzigt alleen dat veld.
+
+---
+
+## Audit
+
+Elke start vanuit de chat wordt vastgelegd als **chat.launch** met de gebruiker, de job, het formulier,
+de provider, en de payload-hash van de samenvatting die is goedgekeurd. Wijzigingen in de chatinstellingen worden
+vastgelegd zoals elke andere wijziging van de instellingen.
+
+---
+
+## Beperkingen
+
+De chat-assistent doet nog niet alles wat een browser doet:
+
+- **Wizardformulieren** kunnen niet meedoen (`enableForChat` wordt daarop geweigerd), en de velden
+  die de assistent niet invult ook niet: wachtwoorden en bestandsuploads.
+- Antwoorden komen in één keer binnen; streaming wordt nog niet ondersteund.
+- Het model kan een verzoek verkeerd begrijpen. De samenvattingskaart toont precies wat er wordt verstuurd;
+  controleer die voordat je op **Starten** klikt.
diff --git a/i18n/nl/_integrate/chat/switching-it-on.md b/i18n/nl/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..918e38d
--- /dev/null
+++ b/i18n/nl/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Inschakelen
+parent: Chat-assistent
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Inschakelen
+{: .no_toc }
+
+Schakel de assistent in en bied er formulieren in aan
+{: .fs-6 .fw-300 }
+
+---
+
+De assistent vereist alle vier van de volgende:
+
+1. **`ENABLE_CHAT=1`** - de omgevingsvariabele. Gewijzigd op de instellingenpagina geldt hij meteen, zonder herstart; zolang
+   hij uit staat, antwoorden de chat-endpoints `404`. Zie [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Een modelprovider** - Instellingen -> Verbindingen -> **Chat-assistent** (of de [config seed](../seed) op Kubernetes).
+3. **Formulieren die meedoen** - `enableForChat: true` op elk formulier; de assistent negeert alle andere.
+4. **Gebruikers die hem mogen gebruiken** - de rol-optie `allowChat` (standaard: true). Zet
+   `allowChat: false` op een rol om de leden ervan uit te sluiten.
+
+De chatknop verschijnt voor een gebruiker zodra aan alle vier de voorwaarden is voldaan.
diff --git a/i18n/nl/_integrate/mcp/index.md b/i18n/nl/_integrate/mcp/index.md
new file mode 100644
index 0000000..9952073
--- /dev/null
+++ b/i18n/nl/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: MCP-server
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# MCP-server
+{: .no_toc }
+
+Laat AI-agents je formulieren gebruiken via het Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor beheerders en integrators: laat MCP-clients formulieren tonen, invullen en starten als de gebruiker wiens token ze hebben.
+
+AnsibleForms kan een
+[Model Context Protocol](https://modelcontextprotocol.io)-server aanbieden, zodat een MCP-client, zoals
+een chatbackend of een IDE-assistent, de formulieren kan tonen die een gebruiker mag gebruiken, de velden ervan kan bepalen,
+jobs kan starten en de voortgang ervan kan volgen.
+
+---
+
+## Wat het is, en wat het niet is
+
+De MCP-server is een technische interface naar dezelfde formulierflow die de browser gebruikt. Hij draait
+**als de gebruiker wiens token hij ontvangt**: dezelfde formulierrollen, dezelfde zichtbaarheid van jobs, dezelfde
+controles op gereserveerde extravars als bij een verzending vanuit de browser.
+
+Hij voegt geen eigen AI-beleid toe. Of een agent om bevestiging moet vragen voor een start,
+welke formulieren hij mag gebruiken, of hoeveel verzoeken hij mag doen, bepaalt de MCP-client. De
+start-tool is gemarkeerd als destructief, dus een nette client vraagt eerst om bevestiging,
+maar de server dwingt dat niet af.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Instellen](setup.html) | De server inschakelen en de client authenticeren |
+| [Tools](tools.html) | De tools die een agent gebruikt om formulieren in te vullen, goed te keuren en opnieuw te starten |
+| [Beperkingen](limitations.html) | Expressies draaien op de server, en wat de MCP-server niet doet |
diff --git a/i18n/nl/_integrate/mcp/limitations.md b/i18n/nl/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..b35bc23
--- /dev/null
+++ b/i18n/nl/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Beperkingen
+parent: MCP-server
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Beperkingen
+{: .no_toc }
+
+Expressies draaien op de server, en wat de MCP-server niet doet
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## runLocal-expressies
+
+`runLocal`-expressies, velden `local` / `credential` / `html` en standaardwaarden met `evalDefault` worden
+op de server geëvalueerd, in een aparte V8-context: geen `process`, `require`, netwerk of
+timers, geen strings die tot code worden gecompileerd, een tijdslimiet van 2 seconden, en alleen de hulpfuncties
+die de browser biedt (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Dit beschermt tegen foutieve of op hol geslagen expressies. Het is geen sandbox voor kwaadwillende code,
+en dat hoeft ook niet: de code komt uit de formulierdefinitie, nooit van de MCP-
+aanroeper, en elke waarde die een aanroeper stuurt wordt ingevuld als JavaScript-literal.
+
+Een expressie die een browser-API gebruikt (`window`, `document`, `fetch`) kan hier niet draaien en
+geeft `status: error` terug.
+
+Expressies aan de serverkant (zonder `runLocal`) doorlopen dezelfde
+[`EXPRESSION_SANITIZER`](../customization)-regels als voor de browser.
+
+---
+
+## Beperkingen
+
+Sommige formulieren en velden kunnen nog niet via de MCP-server worden gebruikt:
+
+- **Wizardformulieren** kunnen nog niet worden gestart. Hun stappen kunnen wel met `subform` worden opgelost.
+- **Bestandsvelden** kunnen niet worden ingevuld; een formulier waarvan het bestandsveld een waarde heeft, wordt geweigerd.
+- **Lijstrijen** (en een veld `yaml` met een subform, wat zo'n rij is): elke rij die je
+  stuurt, behalve een rij met de `deleteMarker` van de lijst, wordt opgelost via zijn subform met
+  de waarden van het formulier als `__parent__` en daarna gevalideerd. Dat geldt ook voor geneste lijsten, waar
+  `__parent__.__parent__` het formulier bereikt. Stuur gewone rijen, dat wil zeggen de ruwe veldwaarden van het
+  subform. Rijen die falen worden per lijstveld opgesomd in `rowErrors`
+  (`vms[1].disks[0].size (missing)` in het bericht). Per aanroep worden hooguit 500 rijen geaccepteerd,
+  over alle niveaus samen.
+- Een enum die op `__auto__` blijft staan, wordt nooit met de eerste optie ingevuld; de aanroeper moet kiezen.
+- Elk MCP-verzoek maakt één regel in het auditlogboek (actie "MCP-verzoek (AI-agent)"); de
+  job zelf wordt onder de gebruiker vastgelegd, zoals bij elke andere start.
diff --git a/i18n/nl/_integrate/mcp/setup.md b/i18n/nl/_integrate/mcp/setup.md
new file mode 100644
index 0000000..464cd24
--- /dev/null
+++ b/i18n/nl/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Instellen
+parent: MCP-server
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Instellen
+{: .no_toc }
+
+Schakel de server in en authenticeer de client
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Inschakelen
+
+Zet [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) op `1`, of schakel hem in onder **Instellingen > Verbindingen > MCP**
+(zie [De MCP-pagina](#the-mcp-page)). Gewijzigd op de instellingenpagina geldt de schakelaar meteen, zonder herstart. Zolang hij
+uit staat, antwoordt het endpoint `404`. Het endpoint is:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Het gebruikt stateless Streamable HTTP met gewone JSON-antwoorden, dus `GET` en `DELETE` geven 405 terug.
+
+---
+
+## Beperken wat agents kunnen doen
+
+Nog twee schakelaars beperken de MCP-server voor elke client. Net als `ENABLE_MCP` gelden ze zonder herstart:
+
+| Variabele | Met `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | De server biedt geen van de tools die starten, plannen of wijzigen (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), en weigert ze. Agents kunnen formulieren tonen, lezen en invullen, planningen en opgeslagen jobs lezen, en jobs volgen, maar niets starten of wijzigen: een veilige manier om een agent uit te proberen. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Agents zien alleen de formulieren die `enableForChat: true` zetten, dezelfde lijst als de [chat-assistent](../chat/). Elk ander formulier, en elke job daarvan, antwoordt als niet gevonden. |
+
+Beide staan standaard uit: agents zien elk formulier dat de rollen van de gebruiker toestaan, en mogen ze starten.
+
+---
+
+## De MCP-pagina
+
+**Instellingen > Verbindingen > MCP** bevat de instellingen van de MCP-server in twee tabbladen.
+
+- **Algemeen** heeft de drie schakelaars, `ENABLE_MCP`, `MCP_READ_ONLY` en `MCP_CHAT_FORMS_ONLY`, opgeslagen met **Opslaan**. De twee
+  andere kunnen alleen worden gewijzigd zolang de MCP-server aan staat.
+- **Clientconfiguratie** toont het **Eindpunt**, met een knop om het te kopiëren, en een kant-en-klare configuratie voor **Claude Code**
+  (`.mcp.json`, of een commando `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, dat
+  om het token vraagt als de server voor het eerst start) en **Codex** (`~/.codex/config.toml`, met het token in de
+  omgevingsvariabele `ANSIBLEFORMS_TOKEN`). Elk heeft een kopieerknop; vervang `<your-token>` door een eigen token, gemaakt
+  met de link **Token maken**.
+
+Het endpoint wordt opgebouwd uit de URL van de app (**Instellingen > URL**) als die is ingesteld, en anders uit het adres van de browser.
+
+---
+
+## Authenticatie
+
+Elk verzoek heeft een access token van AnsibleForms nodig:
+
+```
+Authorization: Bearer <token>
+```
+
+Haal er een op de gebruikelijke manier op (`POST /api/v2/auth/login`, of de flows van OIDC / Entra ID) en
+vernieuw het met `POST /api/v2/token`. Er is bewust **geen login-tool**: een wachtwoord dat als
+tool-argument wordt meegegeven, zou in de context en de chatgeschiedenis van het taalmodel belanden.
+
+De rollen van de gebruiker moeten de MCP-server ook toestaan, via de [rol-optie](../config/roles.html) `allowMcp`. Als geen enkele rol
+van de gebruiker die instelt, volgt hij `allowChat`, dat standaard aan staat. Een gebruiker aan wie hij wordt geweigerd, krijgt `403` op elk verzoek.
+
+- **Een chatbackend** meldt de gebruiker zelf aan, bewaart het refresh token en geeft het access
+  token mee bij elke MCP-aanroep.
+- **Een IDE-client** heeft een token nodig dat lang genoeg meegaat om één keer te worden geconfigureerd. Met een rol
+  die de optie `allowApiTokens` heeft, maak je er een aan onder
+  [Profiel > API-tokens](../profile/api-token.html), of meld je je aan met `?expiryDays=<n>` op de
+  login-URL voor een token dat zoveel dagen geldig is.
+
+Om een coding agent met zo'n token te verbinden:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Voeg de server toe met het token als header:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Voeg de server toe aan `~/.codex/config.toml`, met het token gelezen uit een omgevingsvariabele:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Zet daarna de variabele voordat je Codex start:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/nl/_integrate/mcp/tools.md b/i18n/nl/_integrate/mcp/tools.md
new file mode 100644
index 0000000..b011398
--- /dev/null
+++ b/i18n/nl/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Tools
+parent: MCP-server
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Tools
+{: .no_toc }
+
+De tools die een agent gebruikt om formulieren in te vullen, goed te keuren en opnieuw te starten
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+De MCP-server biedt tot 15 tools. Zes worden aan elke gebruiker aangeboden; de andere volgen de rol-opties van de gebruiker, dus een gebruiker
+zonder een optie krijgt de bijbehorende tools helemaal niet aangeboden:
+
+| Tool | Wat hij doet | Aangeboden met |
+|---|---|---|
+| `list_forms` | De formulieren die de gebruiker mag gebruiken: naam, beschrijving, categorieën, en `enableForChat` (of de chat-assistent het aanbiedt). | altijd |
+| `get_form` | De volledige definitie van één formulier. Elk veld bevat ook `dynamic` (geëvalueerd uit een expressie of query) en `dependsOn` (de velden die het leest). | altijd |
+| `resolve_field` | Evalueert het formulier voor de waarden die tot nu toe zijn ingevuld. Zie hieronder. | altijd |
+| `launch_job` | Start het formulier met de opgegeven waarden, precies zoals een verzending vanuit de browser dat zou doen. Geeft het job-id terug. | altijd |
+| `relaunch_job` | Start een job opnieuw met enkele gewijzigde velden. Zie hieronder. | altijd |
+| `get_job` | Status en uitvoer van een job (`tail` beperkt de uitvoer tot de laatste regels). | altijd |
+| `plan_job` | Voert het formulier één keer uit, later, als de gebruiker: wat **Later uitvoeren (eenmalig)** op het formulier doet. | `allowPlannedJobs` |
+| `create_schedule` | Maakt een planning, terugkerend (`cron`) of eenmalig (`run_at`), zoals op de pagina **Planner**. | `allowScheduledJobs` |
+| `list_schedules` | De planningen die de gebruiker mag zien: allemaal met `allowScheduledJobs`, anders de runs die hij zelf heeft gepland. | `allowPlannedJobs` of `allowScheduledJobs` |
+| `get_schedule` | Eén planning, met de extra vars (die op secrets lijken gemaskeerd) en de uitvoer van de laatste run. | `allowPlannedJobs` of `allowScheduledJobs` |
+| `delete_schedule` | Annuleert een geplande run of verwijdert een planning die de gebruiker mag zien. | `allowPlannedJobs` of `allowScheduledJobs` |
+| `list_stored_jobs` | De [opgeslagen jobs](../jobs/stored-jobs.html) die de gebruiker mag zien, zonder hun waarden. | `allowStoredJobs` |
+| `get_stored_job` | Eén opgeslagen job met zijn waarden, op `id`, of op `form` en `name` onder de eigen jobs van de gebruiker. | `allowStoredJobs` |
+| `store_job` | Slaat waarden van een formulier op onder een naam, zoals **Store** op het formulier doet. | `allowStoredJobs` |
+| `delete_stored_job` | Verwijdert een opgeslagen job die de gebruiker mag zien. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` en `plan_job` nemen `verbose: true` om de job in verbose-modus te draaien, wat de
+rol-optie `allowVerboseMode` vereist. Met [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) worden de tools die starten, plannen of
+wijzigen (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` en `delete_stored_job`)
+niet aangeboden.
+
+Er is geen tool om een willekeurige expressie, query, playbook of extravars uit te voeren. Expressies
+en queries draaien altijd alleen zoals het formulier ze definieert.
+
+De [Chat-assistent](../chat) gebruikt deze tools ook, met een knop **Starten** in plaats van `launch_job`.
+
+---
+
+## Een formulier invullen
+
+Roep `resolve_field` aan met de naam van het formulier en de waarden die je tot nu toe hebt, en opnieuw na elk antwoord. Het werkt
+de velden af in volgorde van afhankelijkheid en meldt voor elk veld:
+
+- `status`: `resolved`, `waiting` (met `waitingFor`), `hidden`, of `error` (het veld valt terug op zijn standaardwaarde);
+- `value`, `default` en, voor keuzevelden, `options` (hooguit `maxOptions`, standaard 200);
+- `needsInput`: een verplicht veld zonder waarde, of een keuze die nog op `__auto__` staat;
+- `validationErrors`: de regels die de waarde schendt, als `[{type, description}]`, met het bericht van de browser.
+
+Voor het hele formulier tonen `missing` en `invalid` wat er nog moet worden opgelost; `launch_job` weigert het tot `complete` true is.
+
+De validatie is de eigen code van de browser, gedeeld met [startvalidatie](../launch-validation). Verborgen velden worden niet
+gevalideerd, en een leeg optioneel veld is geldig.
+
+---
+
+## Planningen en geplande runs
+
+`plan_job` neemt dezelfde `form`, `values` en `expectedPayloadHash` als `launch_job`, met een `name` voor de run en `run_at`, een
+ISO 8601-tijd met de offset of `Z` (`2026-10-15T22:00:00+02:00`); een tijd zonder zone wordt geweigerd. De waarden worden nu opgelost
+en gevalideerd, en opnieuw gecontroleerd als de run afgaat, zoals bij een [geplande run](../jobs/schedules.html#planned-runs) in de
+browser. Het antwoord geeft de runtijd in UTC en volgens de klok van de app.
+
+`create_schedule` neemt een `form`, een `name`, ofwel `cron` (vijf velden, zoals `0 22 * * 1-5`) of `run_at`, en de
+`extraVars` die de job krijgt. Zo'n planning draait als de `Schedule Service`, zonder de validatie van het formulier; om een formulier één keer als
+de gebruiker uit te voeren, gebruik je `plan_job`. Namen van planningen zijn uniek.
+
+---
+
+## Opgeslagen jobs
+
+Een opgeslagen job is een set waarden van een formulier, opgeslagen onder een naam; de tools werken op dezelfde opgeslagen jobs als de browser.
+
+`list_stored_jobs` toont de eigen opgeslagen jobs van de gebruiker, of die van iedereen voor een gebruiker met `showSettings`, met hun naam, beschrijving,
+formulier, aanmaakdatum en vervaldatum. Een job gemarkeerd als `usable` (van de gebruiker zelf, van een formulier dat hij mag starten) kan worden meegegeven als `storedJob`
+(`{ "id": 7 }`, of `{ "name": "..." }` onder de eigen jobs van de gebruiker voor dat formulier) aan `resolve_field`, `launch_job` of `plan_job`: de
+waarden ervan zijn het startpunt en `values` worden eroverheen gelegd. Wachtwoordvelden worden niet opgeslagen, dus geef ze mee in `values`.
+`launch_job` en `plan_job` vanuit een opgeslagen job hebben de `expectedPayloadHash` nodig die `resolve_field` ervoor teruggaf, en
+`resolve_field` weigert `storedJob` samen met `subform`.
+
+`store_job` neemt het `form`, een `name` die uniek is onder de opgeslagen jobs van de gebruiker voor dat formulier, de `values`, en eventueel een
+`description` en `expires_at` (ISO 8601 met de offset of `Z`). Het antwoord zegt welke wachtwoordvelden zijn weggelaten.
+
+---
+
+## Waarden meegeven
+
+Geef `field` mee om alleen dat veld op te lossen en waar het van afhangt. Voor een lijstrij of een wizardstap geef je `subform` mee (en
+eventueel `parent`, de waarden van het bovenliggende formulier).
+
+Stuur waarden zoals de browser ze bijhoudt. Een keuzeveld accepteert ook een gedeeltelijk record of de waarde van zijn `valueColumn`
+(`"vol1"`), en een array als het `multiple` is. Berekende velden negeren verstuurde waarden tenzij ze `editable` zijn.
+
+---
+
+## De exacte payload goedkeuren
+
+Als het formulier compleet is, geeft `resolve_field` ook terug wat `launch_job` gaat versturen:
+
+- `modeledExtravars`: de extravars nadat `model`, `valueColumn` en `output` zijn toegepast,
+  met wachtwoordvelden gemaskeerd;
+- `credentials`: de AnsibleForms-referenties die de job gaat gebruiken (namen, geen secrets);
+- `payloadHash`: een SHA-256-hash van de naam van het formulier, de echte extravars en de referenties.
+
+Toon `modeledExtravars` aan de operator, en geef de `payloadHash` die hij heeft goedgekeurd mee aan
+`launch_job` als `expectedPayloadHash`. De start lost het formulier opnieuw op en wordt geweigerd
+als de payload afwijkt, bijvoorbeeld omdat een query nu anders antwoordt.
+`ansibleforms_user`, `__jobid__` en `__verbose__` worden bij de start toegevoegd en maken geen deel uit van de hash.
+
+`launch_job` controleert alleen de payload. Een wijziging van het formulier waarbij de payload gelijk blijft, laat de start niet weigeren.
+Elk antwoord van `resolve_field` bevat ook een `formFingerprint`, een SHA-256-hash van de formulierdefinitie: om een
+start na elke wijziging van het formulier te weigeren, vergelijk je die zelf voordat je `launch_job` aanroept, zoals de knop
+**Starten** van de chat-assistent doet.
+
+---
+
+## Opnieuw starten met wijzigingen
+
+`relaunch_job` neemt een job-`id` en `values`: alleen de velden die moeten veranderen, als ruwe waarden.
+`values` wordt over de waarden gelegd waarmee de job oorspronkelijk is gestart, en het resultaat wordt
+opgelost en gevalideerd precies zoals door `launch_job`, lijstrijen inbegrepen, en daarna door jou gestart als een
+nieuwe job (`ansibleforms_user` ben jij, niet de oorspronkelijke indiener). Bestandsuploads van
+de oorspronkelijke job worden hergebruikt.
+
+Zonder `values` is het een herstart **zoals de job draaide**: de opgeslagen extravars ervan worden op
+de server opnieuw afgespeeld, wachtwoorden inbegrepen (het voorbeeld maskeert ze). Als het formulier echter onder startvalidatie
+`enforce` valt, doorloopt de herstart dezelfde controle als een herstart met
+wijzigingen.
+
+**Wachtwoorden worden nooit met de veldwaarden opgeslagen**, dus een herstart die door de
+controle gaat, wordt geweigerd als het formulier een wachtwoordveld toont, op het hoogste niveau of in een lijstrij
+(`unsupported`, met de `passwordFields`). Een wachtwoordveld dat door zijn afhankelijkheden verborgen is,
+blokkeert de herstart niet. Zie [Startvalidatie](../launch-validation).
+
+Roep het eerst aan met `preview: true`: het geeft `modeledExtravars` (wachtwoorden gemaskeerd),
+`credentials` en een `payloadHash` terug zonder te starten. Bevestig ze met de gebruiker, en roep
+het daarna opnieuw aan met `expectedPayloadHash`. Dezelfde rechten als bij opnieuw starten in de browser
+gelden: het formulier moet opnieuw starten toestaan en je rollen hebben de optie `allowJobRelaunch` nodig. Een
+job zonder opgeslagen formuliergegevens (gestart voordat opnieuw starten bestond) en een wizardformulier kunnen niet
+met wijzigingen opnieuw worden gestart.
+
+De REST API biedt hetzelfde via `POST /api/v2/job/{id}/relaunch` met de body
+`{ "values": { ... } }`; zonder body speelt het de job af zoals hij draaide.
+
+---
+
+## Fouten
+
+Een geweigerde aanroep is een tool-fout waarvan de gestructureerde inhoud een `code` en de details bevat:
+
+| Code | Wanneer |
+|---|---|
+| `form_incomplete` | `launch_job` of `relaunch_job` op een formulier dat niet compleet is, met `missing`, `invalid`, `waiting`, `validationErrors` en `rowErrors` |
+| `payload_mismatch` | de payload wijkt af van `expectedPayloadHash`, met beide hashes |
+| `access_denied` | de rollen van de gebruiker geven geen toegang tot het formulier, de job, de planning of de opgeslagen job, of tot verbose-modus, of de server is alleen-lezen |
+| `not_found` | zo'n formulier, subform of job bestaat niet |
+| `unsupported` | een wizardformulier, een subform op zichzelf, een bestandsveld, of een `relaunch_job` die een getoond wachtwoordveld nodig zou hebben |
+| `no_form_data` | `relaunch_job` met wijzigingen voor een job die geen formulierwaarden heeft opgeslagen, zoals een job die een planning startte; start hem in plaats daarvan zonder wijzigingen opnieuw |
+| `invalid_request` | een verzoek dat de server als onjuist opgebouwd weigert |
+| `internal_error` | al het andere |
diff --git a/i18n/nl/_introduction/concepts.md b/i18n/nl/_introduction/concepts.md
new file mode 100644
index 0000000..d684012
--- /dev/null
+++ b/i18n/nl/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Begrippen
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Begrippen
+{: .no_toc }
+
+De termen die in deze documentatie worden gebruikt, elk gelinkt aan de eigen pagina
+{: .fs-6 .fw-300 }
+
+---
+
+## Woordenlijst
+
+De termen die in deze documentatie worden gebruikt:
+
+| Term | Betekenis |
+|---|---|
+| **[Formulier](forms/)** | Een YAML-definitie die invoer verzamelt en een playbook, een template of een workflow uitvoert |
+| **[Formulierveld](formfields/)** | Eén invoer van een formulier, zoals `text`, `enum` of `checkbox`; de waarde ervan wordt een extravar |
+| **[Categorie](config/categories.html)** | Een groep in de boom met formulieren op de pagina Formulieren, gedefinieerd in `config.yaml` |
+| **[Rol](config/roles.html)** | Een set gebruikers en groepen; een formulier noemt de rollen die het mogen zien en uitvoeren, `default` voor iedereen |
+| **[Expressie](expressions/)** | JavaScript dat een veldwaarde berekent, in de browser (`runLocal: true`) of op de server |
+| **[Extravars](formfields/)** | De variabelen die naar het playbook of de template worden gestuurd, opgebouwd uit de veldwaarden |
+| **[Referentie](expressions/credentials.html)** | Een opgeslagen login, versleuteld met `ENCRYPTION_SECRET`: een gebruiker en wachtwoord (en host, poort, database), of sinds 7.3.0 het adres en de secrets van een LDAP-directory, een SSO-provider, een runner of een HashiCorp Vault |
+| **[Secret store](secret-stores/)** | Een verbinding met HashiCorp Vault of CyberArk die de gebruiker en het wachtwoord van een referentie levert |
+| **[Job](gui/forms-and-jobs.html)** | Eén run van een formulier, met zijn status, extravars en uitvoer, bewaard in de jobgeschiedenis |
+| **[Runner](runners.html)** | Waar een job draait, toegevoegd onder **Verbindingen > Runners**: `rte` voor playbooks, `awx` (AWX, of de varianten `aap` of `ascender`), `semaphore`, `rundeck` of `jenkins` voor templates en jobs. Een formulier kiest er een met `runner:`, of draait op de standaardrunner `rte` (playbooks) of `awx` (templates) |
+| **[RTE](rte/)** | Een runtime-omgeving: de AnsibleForms-server gestart met `AF_ROLE=rte` in een eigen container, naast python en ansible, die de playbooks uitvoert van een runner van het type `rte` |
+| **[Goedkeuringspunt](forms/approval.html)** | Een pauze in een job tot een gebruiker met een goedkeuringsrol hem goedkeurt of afwijst |
+| **[Workflow](workflows/)** | Een graaf van playbooks, goedkeuringen en andere workflows, gekoppeld bij succes, bij fout of altijd, in de syntaxis van AWX |
+| **[Multistep-formulier](forms/multistep.html)** | Verouderd sinds 7: een formulier dat meerdere playbooks of templates na elkaar uitvoert; een workflow vervangt het |
+| **[Meldingskanaal](notification-channels.html)** | Een mailserver, een Slack- of Teams-webhook, een Telegram-chat of een webhook waar meldingen en goedkeuringsverzoeken naartoe gaan |
+| **[Designer](designer/)** | De browsereditor voor formulieren, playbooks, inventories en workflows, die door één persoon tegelijk wordt gebruikt |
+| **[Subform](forms/subform.html)** | Een herbruikbare set velden die de rijen van een veld `list` of het object van een veld `yaml` beschrijft |
+| **[config.yaml](config/)** | Het bestand met de categorieën, de rollen en de constanten; de formulieren staan in eigen bestanden |
+| **[Config seed](seed/)** | Een YAML-bestand (`CONFIG_SEED_PATH`) dat de beheerobjecten declareert, zoals runners en referenties |
+| **[Persistente map](customization/paths.html)** | De map met de bestanden die AnsibleForms moet bewaren over herstarts en upgrades heen |
diff --git a/i18n/nl/_introduction/gui/administration.md b/i18n/nl/_introduction/gui/administration.md
new file mode 100644
index 0000000..232f64e
--- /dev/null
+++ b/i18n/nl/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Beheer
+parent: Rondleiding door de interface
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Beheer
+{: .no_toc }
+
+Het menu Instellingen: het systeem, het uiterlijk, toegang, verbindingen en logs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Het menu Instellingen
+
+**Instellingen** in de kopbalk opent de beheerpagina's, in het linkermenu gegroepeerd onder **Systeem**, **Uiterlijk**,
+**Toegang**, **Verbindingen** en **Logboeken**. Elk item verschijnt alleen voor een gebruiker met de rol-optie die de pagina nodig heeft:
+`allowBackupOps` voor **Back-ups**, `showLogs` voor **Serverlog**, en `showSettings` voor elke andere pagina.
+Vanaf 7.3.0 openen drie opties een deel ervan zonder de rest:
+
+| Rol-optie | Opent |
+|---|---|
+| `showAppearanceSettings` | De pagina's onder **Uiterlijk** |
+| `showConnectionsSettings` | De pagina's onder **Verbindingen**, behalve **Syslog**; repositories, secret stores en beschermde referenties blijven door een beheerder te wijzigen |
+| `showAuditLog` | Het **Auditlogboek** |
+
+Zie [Rollen](../config/roles.html#role-options) voor de rol-opties.
+
+---
+
+## Lijsten en recordpagina's
+
+Vanaf 7.3.0 delen de lijsten en recordpagina's van de instellingen één indeling, met hun bedieningselementen op een eigen rij onder de titel:
+
+| Deel | Hoe het werkt |
+|---|---|
+| Zoekvak | Als eerste in die rij op elke instellingenpagina en recordpagina. Een woord beperkt alle tabbladen tegelijk: de overeenkomende velden, rijen of regels verschijnen onder de naam van hun tabblad |
+| Paginagrootte | Een tabel toont zoveel rijen als op het scherm passen, tot er een paginagrootte wordt gekozen: 10, 20, 50 of 100 |
+| Kolommen | Elke kolom met een naam is sorteerbaar, en een lege cel toont `–` |
+| Selectievakjes | Rijen hebben ze alleen waar er iets te doen valt met de aangevinkte rijen, en het rijmenu (⋮) biedt dezelfde actie |
+| Rijmenu | Korte labels, zoals **Bewerken** en **Verwijderen**. Een lijst met een kolom **Ingeschakeld** heeft die als eerste, en biedt in elk rijmenu **Inschakelen** of **Uitschakelen**, al naar gelang wat van toepassing is |
+
+De lijsten met een kolom **Ingeschakeld** zijn de SSO-providers, de LDAP-directory's, de runners, de planningen, de meldingskanalen,
+de syslogservers, de aankondigingen, de labels en de versies van de disclaimer.
+
+---
+
+## Systeem
+
+De instantie zelf: de instellingen, de gezondheid en de back-ups.
+
+| Pagina | Waarvoor het dient |
+|---|---|
+| **Algemeen** | De omgevingsvariabelen, in tabbladen van Configuratie tot Logboek. Zie [Omgevingsvariabelen](../customization/). |
+| **Status** | De gezondheid van de instantie en de systemen waarvan ze afhankelijk is, in de tabbladen Controles en Informatie. Zie [Monitoring](../production/monitoring.html). |
+| **Back-ups** | Back-ups maken, herstellen en verwijderen van de database, config.yaml en de formulieren. Zie [Back-ups](../production/backups.html). |
+
+![Instellingen > Algemeen, het tabblad Configuratie](../assets/screenshots/settings.jpg)
+
+### Back-ups
+
+De lijst met back-ups, nachtelijk en handmatig: **Back-up toevoegen** maakt er nu een, en het menu van een rij heeft **Back-up tonen**, **Herstellen** en **Verwijderen**.
+
+![Instellingen > Back-ups](../assets/screenshots/backups.jpg)
+
+### Herstellen
+
+**Herstellen** toont wat de back-up bevat en herstelt die daarna; **Maak eerst een nieuwe back-up aan voor het herstellen (aanbevolen)** is standaard aangevinkt.
+
+![Een back-up herstellen](../assets/screenshots/restore.jpg)
+
+---
+
+## Uiterlijk
+
+Hoe de instantie er voor iedereen uitziet, en de berichten die ze toont.
+
+| Pagina | Waarvoor het dient |
+|---|---|
+| **Standaardwaarden** | Het thema, de taal, de formulierweergave, de tijdzone en het datumformaat van gebruikers die niets hebben gekozen. Zie [Standaardwaarden](../appearance/defaults.html). |
+| **Naam** | De naam in het browsertabblad en op de aanmeldpagina. Zie [Naam](../appearance/name.html). |
+| **Logo** | Je eigen logo in de kopbalk. Zie [Logo](../appearance/logo.html). |
+| **Pictogram** | Je eigen pictogram in het browsertabblad. Zie [Pictogram](../appearance/icon.html). |
+| **Links** | De link naar de Designer, en je eigen links en menu's in de kopbalk. Zie [Links](../appearance/links.html). |
+| **Labels** | Labels naast het logo, zoals PRODUCTION en EU. Zie [Labels](../appearance/labels.html). |
+| **Aankondigingen** | Berichten onder de kopbalk, elk van zijn begin tot zijn einde. Zie [Aankondigingen](../announcements.html). |
+
+---
+
+## Toegang
+
+Wie zich mag aanmelden, en wat hij daarna mag doen.
+
+| Pagina | Waarvoor het dient |
+|---|---|
+| **Disclaimer** | Voorwaarden die elke gebruiker één keer accepteert, en wie welke versie heeft geaccepteerd. Zie [Disclaimer](../disclaimer.html). |
+| **Gebruikers** | De lokale gebruikers, en die van LDAP en single sign-on. Zie [Gebruikers en groepen](../users-and-groups.html). |
+| **Groepen** | De lokale groepen, en die van LDAP en single sign-on. Zie [Gebruikers en groepen](../users-and-groups/local-group.html). |
+| **Rollen** | De rollen van config.yaml: wie ze heeft en wat ze toestaan. Zie [Rollen](../config/roles.html). |
+| **LDAP** | Aanmelden met een LDAP-directory of Active Directory. Zie [LDAP](../authentication/ldap.html). |
+| **SSO** | Single sign-on met Entra ID of OpenID Connect-providers. Zie [Authenticatie](../authentication/). |
+
+![Toegang > LDAP, de hoofddirectory](../assets/screenshots/ldap.jpg)
+
+---
+
+## Verbindingen
+
+De systemen die AnsibleForms bereikt, en waarmee het zich daarbij aanmeldt.
+
+| Pagina | Waarvoor het dient |
+|---|---|
+| **Repositories** | De git-repositories waar de formulieren en playbooks vandaan komen. Zie [Git-repositories](../repositories/). |
+| **Inloggegevens** | De accounts en secrets die formulieren, playbooks en verbindingen gebruiken. Zie [Referenties](../credentials.html). |
+| **Secret stores** | HashiCorp Vault en CyberArk, waaruit referenties kunnen worden gelezen. Zie [Secret stores](../secret-stores/). |
+| **Runners** | Waar jobs draaien: RTE-containers voor playbooks, en AWX en dergelijke voor templates. Zie [Runners](../runners.html). |
+| **SSH** | Het sleutelpaar waarmee de app verbinding maakt met git, en de known hosts. Zie [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Meldingen** | SMTP-servers, Slack, Microsoft Teams, Telegram en webhooks. Zie [Meldingskanalen](../notification-channels.html). |
+| **Chat-assistent** | De AI-provider van de chat-assistent. Zie [Chat-assistent](../chat/). |
+| **MCP** | De MCP-server voor AI-agents. Zie [MCP](../mcp/). |
+| **Syslog** | Syslogservers die het serverlog, het auditlogboek of beide ontvangen. Zie [Syslog](../production/logs.html#syslog). |
+
+![Verbindingen > Inloggegevens, het tabblad Verbinding van een referentie](../assets/screenshots/credentials.jpg)
+
+---
+
+## Logboeken
+
+Wat er op de instantie is gebeurd.
+
+| Pagina | Waarvoor het dient |
+|---|---|
+| **Auditlogboek** | Wie wat heeft gewijzigd, en of dat was toegestaan, gefilterd op gebruiker, actie en resultaat. Zie [Audittrail](../production/logs.html#audit-trail). |
+| **Serverlog** | Het eigen log van de server, voor het oplossen van problemen. Zie [Logs](../production/logs.html). |
+
+### Serverlog
+
+De laatste regels van het log, de nieuwste onderaan, gevolgd terwijl ze worden geschreven. Het zoekvak filtert ze (een reguliere
+expressie), **Wissen** maakt de weergave leeg, niet het log, en **Downloaden** slaat het hele log op.
+
+![Logboeken > Serverlog](../assets/screenshots/logs.jpg)
+
+---
+
+## API-documentatie
+
+**API-documentatie** in het helpmenu (het vraagteken in de kopbalk) linkt naar de Swagger UI van de REST API op `/api/v2/docs`.
+Zie [API](../api/).
+
+![Swagger-interface](../assets/screenshots/swagger.jpg)
diff --git a/i18n/nl/_introduction/gui/designer-and-git.md b/i18n/nl/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..1ddebe3
--- /dev/null
+++ b/i18n/nl/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Designer en git
+parent: Rondleiding door de interface
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Designer en git
+{: .no_toc }
+
+Formulieren bewerken en ze in git bewaren
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ingebouwde Designer
+
+Bewerk formulieren, categorieën, constanten, vars-bestanden, playbooks, inventories en workflows, elk als YAML, met velden (Visueel)
+en als voorbeeld. De pagina's over de [Designer](../designer/) beschrijven elke sectie.
+
+![Ingebouwde Designer](../assets/screenshots/designer.jpg)
+
+---
+
+## Git-repositories
+
+Integreer met Git-repositories om je formulieren en playbooks onder versiebeheer te brengen.
+
+![Git-repositories](../assets/screenshots/git.jpg)
+
+---
+
+## Editor voor Git-repositories
+
+Bewerk en configureer de instellingen voor de integratie met Git-repositories.
+
+![Editor voor Git-repositories](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/nl/_introduction/gui/forms-and-jobs.md b/i18n/nl/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..7ee3392
--- /dev/null
+++ b/i18n/nl/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formulieren en jobs
+parent: Rondleiding door de interface
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formulieren en jobs
+{: .no_toc }
+
+Aanmelden, het dashboard, een formulier invullen en de jobs ervan volgen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Aanmelden
+
+De aanmeldpagina, met ondersteuning voor lokale authenticatie, LDAP, Entra ID en OIDC.
+
+![Aanmelden](../assets/screenshots/login.jpg)
+
+---
+
+## Het dashboard
+
+Het hoofddashboard toont alle beschikbare formulieren, geordend per categorie.
+
+![Dashboard](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Een formulier
+
+Een voorbeeld van een formulier met externe gegevensbronnen en dynamische velden.
+
+![Voorbeeld van een formulier](../assets/screenshots/form.jpg)
+
+---
+
+## JSON-voorbeeld van een formulier
+
+Bekijk de JSON-payload en de extra variabelen die aan Ansible worden doorgegeven voordat je de job uitvoert.
+
+![JSON-voorbeeld van een formulier](../assets/screenshots/form-json.jpg)
+
+---
+
+## Lopende job
+
+Uitvoering van een Ansible-playbook in real time, met live uitvoer.
+
+![Lopende job](../assets/screenshots/run.jpg)
+
+---
+
+## Uitvoer van een job
+
+De volledige uitvoer van een uitgevoerd Ansible-playbook.
+
+![Uitvoer van een job](../assets/screenshots/job-output.jpg)
+
+---
+
+## Joblogs
+
+Alle jobs met hun status en tijden, gefilterd op status via het linkermenu.
+
+![Joblogs](../assets/screenshots/job-log.jpg)
+
+---
+
+## Multistep
+
+Een multistep-job, met de uitvoer van elke stap onder de hoofdjob. Multistep-formulieren zijn verouderd sinds 7: een
+[workflow](../workflows/) rijgt in plaats daarvan playbooks, templates en goedkeuringen aan elkaar.
+
+![Multistep-formulier](../assets/screenshots/multistep.jpg)
+
+---
+
+## Planningen
+
+Plan formulieren om op specifieke tijden of met intervallen te draaien. De [cron-voorbeelden](../faq.html#which-cron-expressions-can-i-use) tonen gangbare
+expressies, en leggen uit in welke tijdzone een planning draait.
+
+![Planningen](../assets/screenshots/schedules.jpg)
diff --git a/i18n/nl/_introduction/gui/index.md b/i18n/nl/_introduction/gui/index.md
new file mode 100644
index 0000000..689ac3d
--- /dev/null
+++ b/i18n/nl/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Rondleiding door de interface
+nav_order: 3
+has_children: true
+has_toc: false
+description: Schermafbeeldingen en een rondleiding door de grafische gebruikersinterface
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Rondleiding door de interface
+{: .no_toc }
+
+Een visuele rondleiding door de webinterface van AnsibleForms, van het dashboard tot de geavanceerde beheerfuncties.
+{: .fs-6 .fw-300 }
+
+---
+
+Voor elke gebruiker en beheerder: de schermen van de webinterface, gegroepeerd naar wat je ermee doet.
+
+---
+
+## In deze sectie
+
+Elke groep schermen heeft een eigen pagina:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Formulieren en jobs](forms-and-jobs.html) | Aanmelden, het dashboard, een formulier invullen en de jobs ervan volgen |
+| [Designer en git](designer-and-git.html) | Formulieren bewerken en ze in git bewaren |
+| [Beheer](administration.html) | Het menu Instellingen: het systeem, het uiterlijk, toegang, verbindingen en logs |
+| [Persoonlijke instellingen](personal-settings.html) | Je profiel en het donkere thema |
diff --git a/i18n/nl/_introduction/gui/personal-settings.md b/i18n/nl/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..97868d0
--- /dev/null
+++ b/i18n/nl/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Persoonlijke instellingen
+parent: Rondleiding door de interface
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Persoonlijke instellingen
+{: .no_toc }
+
+Je profiel en het donkere thema
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gebruikersprofiel
+
+Je account, voorkeuren, wachtwoord, rechten en API-tokens.
+
+Zie [Je profiel](../profile).
+
+![Gebruikersprofiel](../assets/screenshots/profile.jpg)
+
+---
+
+## Donkere modus
+
+AnsibleForms ondersteunt een donkere modus, die minder vermoeiend is voor de ogen.
+
+![Donkere modus](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/nl/_introduction/how-it-works.md b/i18n/nl/_introduction/how-it-works.md
new file mode 100644
index 0000000..bda9cd3
--- /dev/null
+++ b/i18n/nl/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Hoe het werkt
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Hoe het werkt
+{: .no_toc }
+
+De onderdelen van een installatie, wat er bij een start gebeurt, en waar gegevens worden bewaard
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Architectuur
+
+AnsibleForms is een Node.js-server die de webapplicatie en een REST API aanbiedt, ondersteund door een MySQL-database. Hij leest formulieren
+uit YAML-bestanden en voert zelf niets uit: hij geeft elke job aan een [runner](runners.html). Een playbook gaat naar een van je RTE-containers
+(runtime-omgeving), die `ansible-playbook` uitvoert, en een template of job gaat naar AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Architectuur van AnsibleForms</title>
+<desc id="afd-desc">De browser en een optionele MCP-client praten met de AnsibleForms-server. De server slaat zijn gegevens op in MySQL en in de persistente map, en maakt verbinding met gegevensbronnen, secret stores, git-repositories, aanmeldproviders, meldingskanalen, syslogservers en een optionele modelprovider. Zijn runners geven elk playbook aan een van een of meer RTE-containers, elk over een eigen WebSocket, die ansible-playbook uitvoeren en de uitvoer terugsturen naar de server, en elke template of job aan AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Browser</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">formulieren, designer,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">jobs, chat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">MCP-client</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">optioneel</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">AnsibleForms-server</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Webapp en REST API</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formulieren, expressies</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflows, planningen</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">MCP-server (optioneel)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runners</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">geven elke job aan zijn runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Gegevensbronnen</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">databases, API's, bestanden</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Secret stores</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Git-repositories</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">formulieren, playbooks, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Aanmeldproviders</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Meldingskanalen</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">mail, Slack, Teams, webhooks</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Syslogservers</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">het log, het audittrail</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Modelprovider</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">optioneel, chat-assistent</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Persistente map</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, formulieren, playbooks</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">jobs, gebruikers,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">referenties</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">RTE-containers</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">draaien ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbooks,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">templates, jobs</text>
+</svg>
+</div>
+
+De onderdelen in het diagram hebben elk een eigen rol:
+
+| Onderdeel | Rol |
+|---|---|
+| **Browser** | De Vue-webapplicatie: de formulieren, de [Designer](gui/designer-and-git.html), de jobgeschiedenis en de instellingen |
+| **AnsibleForms-server** | Evalueert de formulieren, legt de jobs vast, voert de workflows en de planningen uit, geeft elke job aan zijn runner en volgt hem, en biedt de [REST API](api/) aan |
+| **Runners** | Waar jobs draaien, toegevoegd onder **Verbindingen > Runners**: een formulier noemt er een met `runner: <name>`, of gebruikt de standaardrunner van zijn type (zie [Runners](runners.html)) |
+| **RTE-containers** | Een of meer containers met een runtime-omgeving, dezelfde server gestart met `AF_ROLE=rte`: elk voert `ansible-playbook` uit voor [ansible-formulieren](forms/ansible.html), met de python-bibliotheken en collections van zijn image, en stuurt de uitvoer en de eindstatus terug naar de server over één WebSocket, zonder database-inloggegevens (zie [Hoe de RTE draait](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runners voor templates en jobs: [AWX-formulieren](forms/awx.html) starten een job- of workflowtemplate, formulieren voor [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) en [Jenkins](forms/jenkins.html) starten een van hun jobs, en de server volgt de uitvoer |
+| **MySQL / MariaDB** | Bevat de jobs en hun uitvoer, de gebruikers, de referenties en de verbindingen; alleen de server leest en schrijft erin |
+| **Persistente map** | Bevat `config.yaml`, de formulierbestanden, de playbooks, de logs en de back-ups |
+| **Gegevensbronnen** | Vullen de velden: [databasequery's](formfields/enum.html), [REST API's](expressions/rest-apis.html), bestanden en [andere functies](expressions/remote.html) |
+| **Secret stores** | Leveren de gebruiker en het wachtwoord van een referentie op het moment van gebruik, zie [Secret stores](secret-stores/) |
+| **Git-repositories** | Houden de formulieren, de playbooks en `config.yaml` onder versiebeheer |
+| **Aanmeldproviders** | Melden de gebruikers aan: [LDAP, Entra ID en OIDC](authentication/), naast de lokale gebruikers |
+| **Meldingskanalen** | Brengen de [meldingen](forms/notifications.html) en de goedkeuringsverzoeken over: [mail, Slack, Microsoft Teams, Telegram of een webhook](notification-channels.html) |
+| **Syslogservers** | Ontvangen het log en het audittrail terwijl ze worden geschreven, zie [Syslog](production/logs.html#syslog) |
+| **MCP-client, chat** | Optioneel, beide standaard uit: de [MCP-server](mcp/) en de [chat-assistent](chat/), die een modelprovider nodig heeft |
+
+Standaard draait één container de server, de webapp en het achtergrondwerk samen, naast één RTE. Voor meerdere app-nodes achter een
+load balancer, een worker die het achtergrondwerk uitvoert, en meer RTE's, zie [Schalen](production/scaling.html).
+
+### Gebouwd met
+
+De server en de webinterface zijn gebouwd op deze onderdelen:
+
+| Deel | Technologie |
+|---|---|
+| **Server** | Node.js en Express |
+| **Database** | MySQL of MariaDB |
+| **Webinterface** | Vue 3, met Bootstrap 5 en Font Awesome |
+
+---
+
+## Wat er gebeurt als je een formulier start
+
+Een start doorloopt dezelfde stappen, of hij nu uit de browser komt of uit de [REST API](api/jobs.html):
+
+1. **Laden** : de server stuurt alleen de formulieren die de [rollen](config/roles.html) van de gebruiker toestaan, en evalueert de serverexpressies
+2. **Verzenden** : de browser zet de veldwaarden om in extravars en post ze naar `POST /api/v2/job`
+3. **Controleren** : de server laadt het formulier opnieuw voor de rollen van de gebruiker en controleert, met [startvalidatie](launch-validation/) aan, de waarden
+4. **Vastleggen** : de job wordt opgeslagen met status `running`, en het id ervan wordt aan de extravars toegevoegd als `__jobid__`
+5. **Goedkeuren** : een formulier met een [`approval`](forms/approval.html)-punt wacht tot een goedkeurder de job accepteert
+6. **Referenties** : voor een playbook leest de app (nooit de RTE) de referenties van het formulier uit de database of een [secret store](secret-stores/)
+7. **Uitvoeren** : de job gaat naar zijn runner, de runner die het formulier met `runner:` noemt of de standaard van zijn type. Voor een playbook stuurt de app de job naar zijn
+   RTE over de WebSocket van de RTE, met de referenties voor die RTE verzegeld, en de RTE voert `ansible-playbook` uit (zie [Hoe de RTE draait](rte/#how-the-rte-runs)),
+   en AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins voert een template of een job uit. Een [workflow](workflows/) voert zijn nodes uit, elk als een
+   eigen job op een eigen runner
+8. **Volgen** : de server slaat de uitvoer in de database op zodra die binnenkomt, voor een playbook door de RTE over zijn socket gestuurd, of gelezen van de
+   andere runners. De formulierpagina leest de job elke twee seconden opnieuw, en de pagina Taken volgt hem live terwijl de server
+   elke wijziging aankondigt
+9. **Einde** : de job krijgt zijn eindstatus, en zijn [`notifications`](forms/notifications.html) gaan per mail en naar zijn
+   [meldingskanalen](notification-channels.html) als het formulier daarom vraagt
+
+---
+
+## Waar alles wordt opgeslagen
+
+AnsibleForms bewaart zijn toestand op twee plaatsen: de MySQL-database en de persistente map. Maak van beide een back-up.
+
+### In de database
+{: .no_toc }
+
+De database, `AnsibleForms`, wordt bij de eerste start aangemaakt (tenzij `ALLOW_SCHEMA_CREATION` `0` is) en bevat:
+
+* de jobs, hun extravars en hun uitvoer, de planningen en de opgeslagen jobs
+* de lokale gebruikers, de groepen en de API-tokens
+* de referenties, versleuteld met `ENCRYPTION_SECRET`, en de verbindingen met secret stores
+* de runners, de meldingskanalen (mail inbegrepen), de syslogservers, en de instellingen voor LDAP, SSO, repositories en de chat-assistent
+* het auditlogboek
+
+### In de persistente map
+{: .no_toc }
+
+Dat is `/app/dist/persistent` in de image en `server/persistent` vanuit de broncode; elk pad heeft een eigen [variabele](customization/paths.html):
+
+| Standaardpad | Variabele | Inhoud |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | De categorieën, de rollen en de constanten |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | De formulierbestanden, `.yaml` of `.yml`, desgewenst in submappen |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | De playbooks van `ansible`-formulieren, en hun werkmap |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | De clones van de git-repositories |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | De kopieën die de Designer maakt voordat hij opslaat |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | De databaseback-ups |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | De bestanden die via `file`-velden zijn geüpload |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` en `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | Het certificaat en de sleutel, als `HTTPS` `1` is |
+| `.env` | | De omgevingsvariabelen die vanuit de instellingenpagina's zijn opgeslagen (tenzij `ALLOW_ENV_EDIT` `0` is) |
+
+De gegenereerde SSH-sleutel staat in [`HOME_PATH`](customization/paths.html#env_HOME_PATH), standaard buiten de persistente map.
diff --git a/i18n/nl/_introduction/prerequisites.md b/i18n/nl/_introduction/prerequisites.md
new file mode 100644
index 0000000..5c486e1
--- /dev/null
+++ b/i18n/nl/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Vereisten
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Vereisten
+{: .no_toc }
+
+Wat je nodig hebt voordat je AnsibleForms installeert
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Runtime
+
+AnsibleForms draait als container, als systemd-services op de server zelf of, voor wie het zelf bouwt, als Node.js-applicatie:
+
+| Installatie | Je hebt nodig |
+|---|---|
+| [Installatieprogramma](installation/installer.html) | Linux op amd64 of arm64, `curl` of `wget` en `sha256sum`, en wat de engine nodig heeft waarop het installeert (hieronder) |
+| [Native](installation/native.html) | Root, systemd en een ondersteunde Linux (Ubuntu, Debian, RHEL en de rebuilds ervan, SUSE); het installatieprogramma installeert de rest |
+| [Docker](installation/docker.html) | Docker of Podman, en een eigen MySQL-server |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose of podman-compose; het project start ook MySQL |
+| [Kubernetes](installation/kubernetes.html) | Een cluster, Helm 3 en een StorageClass (of vooraf aangemaakte PersistentVolumes) |
+| [Vanuit de broncode](installation/from-source.html) | Node.js 26 (minstens 24) met npm, Git, en Ansible voor het RTE-proces dat de playbooks uitvoert |
+
+De app-image, `ghcr.io/ansibleforms/ansibleforms`, bevat Node.js en de tools die de server aanroept (git, ssh, de mariadb-client en
+ytt), maar geen Python en geen Ansible. Playbooks draaien op een RTE (runtime-omgeving), een tweede container van
+`ghcr.io/ansibleforms/ansibleforms-rte-full`, of van een image die je op `ansibleforms-rte-core` bouwt (zie [Schalen](rte/)).
+Formulieren die alleen templates starten op AWX, AAP, Ascender, Semaphore, Rundeck of Jenkins hebben geen RTE nodig.
+
+---
+
+## Database
+
+AnsibleForms slaat zijn jobs, gebruikers, referenties en verbindingen op in MySQL 8 of later, of in MariaDB.
+
+Bij de eerste start maakt het zelf het schema `AnsibleForms` aan. Geef het een eigen databasegebruiker, met rechten op alleen dat schema,
+niet root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Meer heeft het niet nodig: het maakt en patcht het schema, maakt zijn back-ups en beëindigt, met meerdere workers, de sessie van een dode worker.
+De pagina **Status** en het log waarschuwen als de gebruiker rechten op alle databases heeft. De app-nodes en de workers verbinden met deze
+gebruiker. Een RTE in een socketmodus (uitgaand of inkomend, zie [Modi](rte/modes.html)) bevat geen database-inloggegevens: alleen een RTE in databasemodus,
+verouderd sinds 7.3.0, maakt ook verbinding. Om het schema zelf aan te maken, zet je [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) op `0`.
+Het Docker Compose-project en de Helm-chart (die `mysql:8.4` gebruikt) starten een database voor je.
+
+---
+
+## Dimensionering
+
+Er zijn geen gemeten vereisten: de belasting hangt vooral af van hoeveel jobs tegelijk draaien en hoeveel uitvoer ze schrijven.
+De standaardresources van de Helm-chart zijn een redelijk startpunt voor een klein team:
+
+| Onderdeel | Requests | Limits | Volume |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB geheugen | 4 CPU, 4 GiB geheugen | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB geheugen | 2 CPU, 2 GiB geheugen | 10 GiB |
+
+De app-container draait geen playbook. Elk playbook is een `ansible-playbook`-proces, met zijn forks, op een RTE: dimensioneer de CPU en
+het geheugen van elke RTE voor de playbooks die hij tegelijk draait, hooguit [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (standaard `10`), en draai meer
+RTE's om meer te draaien. Jobs die op AWX, AAP, Ascender of de andere templaterunners draaien, kosten AnsibleForms weinig.
+
+De uitvoer van jobs wordt standaard voor altijd in de database bewaard. Stel [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+in op een drukke instantie om te voorkomen dat de database onbeperkt groeit.
+
+---
+
+## Netwerk
+
+De app en elke RTE luisteren op een eigen poort, en openen uitgaande verbindingen naar de systemen die je formulieren en instellingen gebruiken.
+
+### Inkomend
+{: .no_toc }
+
+De server luistert op poort `8000` ([`PORT`](customization/server.html#env_PORT)), over HTTP of, met
+[`HTTPS`](customization/server.html#env_HTTPS) op `1`, over HTTPS. Het Docker Compose-project publiceert hem op poort 443,
+en de Helm-chart biedt hem aan via een service of een ingress. Een RTE luistert ook op zijn eigen `PORT`, maar alleen de app roept hem aan:
+houd hem van het publieke netwerk af. Een uitgaande RTE heeft helemaal geen inkomende poort nodig: hij belt de app aan op de poort van de app.
+
+### Uitgaand
+{: .no_toc }
+
+Open de verbindingen van AnsibleForms naar de systemen die je gebruikt:
+
+| Bestemming | Gebruikt voor |
+|---|---|
+| MySQL / MariaDB | De database van AnsibleForms (`DB_HOST`, `DB_PORT`, standaard `3306`) |
+| De RTE | Een inkomende RTE aanbellen op het adres van zijn runner over één WebSocket, of een RTE in databasemodus aanroepen op zijn [`RTE_URL`](customization/server.html#env_RTE_URL), die dan zelf verbinding maakt met MySQL; een uitgaande RTE belt in plaats daarvan de app aan (zie [Modi](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Templates en jobs starten en volgen op [runners](runners.html), via hun HTTP(S)-API |
+| De beheerde hosts | Playbooks maken er vanaf de RTE verbinding mee, bijvoorbeeld over SSH of WinRM |
+| LDAP, Entra ID, OIDC | Aanmelden met directory- of single sign-on-accounts |
+| Git-servers | Repositories clonen en pullen, over HTTPS of SSH |
+| REST API's en databases | De gegevensbronnen van expressies en queries in je formulieren |
+| HashiCorp Vault, CyberArk | Referenties lezen uit een [secret store](secret-stores/) |
+| Mailservers, Slack, Teams, Telegram, webhooks | Jobmeldingen en goedkeuringsverzoeken, via de [meldingskanalen](notification-channels.html) |
+| Modelprovider | De [chat-assistent](chat/), alleen als die is ingeschakeld |
+
+Om te beperken welke hosts de REST-functies van expressies mogen aanroepen, zie
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) en
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Browser
+
+De webapplicatie is gebouwd voor actuele browsers: Chrome of Edge 111, Firefox 114, Safari 16.4 of nieuwer.
+Oudere browsers worden niet ondersteund.
+
+---
+
+## Schalen
+
+Standaard draait één AnsibleForms-container de webapp en het achtergrondwerk samen, naast één RTE.
+
+Om meer gebruikers te bedienen, draai je meerdere app-nodes achter een load balancer (`AF_ROLE=app`) naast een worker (`AF_ROLE=worker`), die de
+planningen, de back-ups en het andere achtergrondwerk uitvoert; er werkt maar één worker tegelijk, en een tweede wacht om het over te nemen. Ze delen
+de database, de persistente map, `ACCESS_TOKEN_SECRET` en `ENCRYPTION_SECRET`. Zie [Schalen](production/scaling.html). Draai meer
+RTE's om meer playbooks tegelijk te draaien: zie [Meerdere RTE's](rte/several.html).
diff --git a/i18n/nl/_introduction/what-is-ansibleforms.md b/i18n/nl/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..2d1e6d7
--- /dev/null
+++ b/i18n/nl/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Wat is AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Wat is AnsibleForms
+{: .no_toc }
+
+Selfserviceformulieren voor Ansible en AWX, en wanneer je ze nodig hebt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wat het doet
+
+AnsibleForms zet een webformulier voor een playbook, een workflow, of een template of job op AWX, AAP, Ascender, Semaphore, Rundeck
+of Jenkins, zodat mensen automatisering kunnen uitvoeren zonder de commandoregel.
+
+Een formulier verzamelt de invoer, controleert die, giet haar in extravars en start de job. De gegevens in een formulier kunnen uit databases,
+REST API's, bestanden en andere velden komen, en elke start wordt met zijn uitvoer vastgelegd in de jobgeschiedenis.
+
+---
+
+## Typisch gebruik
+
+Teams gebruiken AnsibleForms om routinematige automatisering over te dragen aan de mensen die erom vragen:
+
+* **Selfserviceverzoeken** : een virtuele machine, een opslagvolume, een share of een gebruikersaccount, ingevuld door de aanvrager
+* **Bewaakte handelingen** : acties met goedkeuringspunten, zodat een tweede persoon tekent voordat de job draait
+* **Keuzes op basis van gegevens** : keuzelijsten gevuld vanuit een CMDB, een database of een REST API, trapsgewijs van het ene veld naar het volgende
+* **Terugkerende jobs** : formulieren die later of volgens een cron-planning draaien, elke keer met dezelfde gevalideerde invoer
+* **Automatisering voor tools en agents** : de REST API, de MCP-server en de chat-assistent starten dezelfde formulieren
+
+---
+
+## AnsibleForms of AWX-surveys?
+
+AWX, AAP en Ascender hebben eigen surveys. Welke past, hangt af van wat de mensen die de jobs starten nodig hebben.
+
+Een **survey** volstaat als:
+
+* de vragen vastliggen: tekst, getallen, wachtwoorden en keuzes uit een statische lijst
+* de gebruikers al in AWX, AAP of Ascender werken, en de rechten daarvan bij hen passen
+* je geen extra applicatie en database wilt draaien en onderhouden
+
+**AnsibleForms** helpt als:
+
+* de keuzes ergens anders vandaan komen: een database, een REST API, een bestand, of een ander veld (trapsgewijze keuzelijsten)
+* de invoer validatie, structuur (lijsten, geneste objecten) of berekende waarden nodig heeft voordat ze het playbook bereikt
+* de jobs goedkeuringspunten, planning, of een workflow nodig hebben die playbooks, templates en goedkeuringen vanuit één formulier aan elkaar rijgt
+* de gebruikers AWX helemaal niet moeten zien, of je ook playbooks zonder AWX draait
+
+AnsibleForms start templates van AWX, AAP en Ascender, dus de twee werken samen: de formulieren verzamelen en vormen de invoer, en
+AWX blijft de jobs draaien.
+
+---
+
+## Waar verder
+
+De rest van deze sectie legt de onderdelen uit voordat je installeert:
+
+| Pagina | Wat het behandelt |
+|---|---|
+| [Hoe het werkt](how-it-works.html) | De architectuur, de stappen van een start, en waar gegevens worden bewaard |
+| [Rondleiding door de interface](gui/) | Schermafbeeldingen van elk scherm, van het aanmelden tot de beheerpagina's |
+| [Begrippen](concepts.html) | De termen die in deze documentatie worden gebruikt |
+| [Vereisten](prerequisites.html) | Wat je nodig hebt voordat je installeert |
diff --git a/i18n/nl/_reference/faq.md b/i18n/nl/_reference/faq.md
new file mode 100644
index 0000000..d97938f
--- /dev/null
+++ b/i18n/nl/_reference/faq.md
@@ -0,0 +1,1278 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Veelgestelde vragen
+{: .no_toc }
+
+Veelgestelde vragen en antwoorden over AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Aan de slag
+
+### Deploymenttopologie: één container of meerdere nodes
+
+Standaard draait één AnsibleForms-container de webapplicatie en het achtergrondwerk in één proces, naast een RTE-container die
+de playbooks uitvoert. Draai hem met een restart policy (bijvoorbeeld `restart: unless-stopped` in Docker), en maak een back-up van zowel de database als
+het persistente volume.
+
+Om meerdere replica's achter een load balancer te draaien, splits je het proces met `AF_ROLE`:
+
+- `app`-nodes bieden de webinterface en de API aan: draai er zoveel als je wilt, elk met hetzelfde `ACCESS_TOKEN_SECRET`
+- een `worker` voert het achtergrondwerk uit: het schema en de upgrades ervan, de config seed, de planningen, de nachtelijke back-up, de synchronisatie
+  van repositories en de opruimtaken. Er werkt één worker tegelijk, met een vergrendeling in de database; een tweede wacht en neemt het over als de eerste stopt
+- `rte`-containers voeren de playbooks uit: draai er meer om meer playbooks tegelijk uit te voeren
+
+De app-nodes en de worker delen de database, het persistente volume en `ENCRYPTION_SECRET`. Een RTE in een socketmodus (uitgaand of
+inkomend, zie [Modi](rte/modes.html)) heeft de database noch `ENCRYPTION_SECRET` nodig. De chat-assistent heeft sticky sessions nodig, en
+elke node houdt zijn eigen log bij. Zie [Schalen](production/scaling.html) en de opzet in
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Formulieren beheren over meerdere repositories
+
+Formulieren uit elke Git-repository waarbij **Gebruiken voor formulieren** aan staat, worden automatisch samengevoegd; bij dubbele formuliernamen wint
+de eerste en wordt een waarschuwing gelogd. Bewaar `config.yaml` in slechts één repository. Zie [Git-repositories](repositories/).
+
+### Over repositories
+
+AnsibleForms clonet en pullt Git-repositories onder het pad voor repositories (`REPO_PATH`), beheerd onder **Instellingen > Repositories**.
+Schakelaars op elke repository bepalen wat hij bevat: configuratie, formulieren, playbooks of vars-bestanden. Zie [Git-repositories](repositories/).
+
+### VS Code-validatie voor formulierbestanden
+
+Voeg een schemaheader toe aan je YAML-formulierbestanden voor live validatie en autocomplete in VS Code.
+
+Installeer de [YAML-extensie](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) en zet dit commentaar als **eerste regel** van elk formulierbestand:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Dit werkt zowel voor bestanden met één formulier (een YAML-dict) als voor bestanden met meerdere formulieren (een YAML-lijst):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code markeert onbekende eigenschappen, ontbrekende verplichte velden en onjuiste typen terwijl je typt.
+
+---
+
+## Jobbeheer
+
+### Een job opnieuw starten met vooraf ingevulde gegevens
+
+De knop voor opnieuw starten opent het formulier, vooraf ingevuld met de waarden van de eerdere job; wachtwoordvelden worden nooit opgeslagen.
+Daarvoor is de rol-optie `allowJobRelaunch` nodig, en een formulier kan het uitschakelen met `allowRelaunch: false`. Zie [Een job opnieuw starten](jobs/actions.html#relaunch-a-job).
+
+### Logbestand van een job
+
+Volg de voortgang via een logbestand per job (v6.1.2).
+
+AnsibleForms kan een **logbestand per job** naast de Ansible-uitvoer tonen. Zo kun je de voortgang volgen van langlopende custom modules die tijdens de uitvoering anders geen zichtbare feedback geven.
+
+{: .note }
+> Deze functie werkt alleen voor playbooks die op een RTE draaien. Templates en jobs op AWX, AAP, Ascender, Semaphore, Rundeck of
+> Jenkins hebben geen logbestand.
+
+**Hoe het werkt:**
+- Tijdens een jobrun let de RTE op een logbestand op een vast pad binnen de map van het playbook
+- Elke twee seconden kopieert de RTE, als het bestand is gewijzigd, de inhoud ervan naar de job, en nog één keer als het playbook eindigt
+- Het logbestand wordt getoond in een sectie **Logbestand** van de uitvoer van de job, genummerd zoals de regels van de uitvoer: de tijdstempel en het niveau (ERROR, WARNING, INFO, DEBUG) van een logregel worden gelezen en gekleurd zoals die van de uitvoer, en ANSI-kleuren worden ondersteund
+
+**Conventie voor het pad van het logbestand:**
+
+Het logbestand moet naar dit pad worden geschreven:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms geeft `__jobid__` automatisch mee**, dus je kunt het pad in je playbook samenstellen zonder extra configuratie:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Geef deze variabele door aan elke rol of custom module die voortgang naar het bestand moet schrijven.
+
+**Verantwoordelijkheden van de ontwikkelaar van het playbook / de module:**
+- **Maak** het logbestand (en de map `.joblogs/` ervan) aan het begin van de bewerking aan
+- **Schrijf** zinvolle voortgangsberichten terwijl de bewerking verloopt
+
+De RTE verwijdert het bestand zodra het playbook eindigt en de laatste inhoud bij de job is opgeslagen.
+
+**ANSI-kleurcodes worden ondersteund.**  
+Standaard ANSI-escapecodes (bijvoorbeeld `\033[92m` voor groen en `\033[91m` voor rood) in je logberichten worden in de UI als kleuren weergegeven, zodat je succes, waarschuwingen en fouten in één oogopslag onderscheidt.
+
+**Typisch gebruik:**  
+Een custom Python-module voor Ansible die een lange reeks API-aanroepen of gegevensbewerkingen uitvoert (bijvoorbeeld een SnapMirror DR-workflow) kan per stap één regel aan het logbestand toevoegen. Een operator die de job in AnsibleForms volgt, ziet dan live voortgang in de sectie Logbestand terwijl de jobpagina de job volgt.
+
+### Jobid
+
+Geef het huidige job-ID mee.
+
+AnsibleForms stuurt het huidige job-ID automatisch mee in de extravars als `__jobid__`; er is geen configuratie nodig.
+
+### Gebruikersinformatie
+
+Geef de huidige gebruiker mee.
+
+AnsibleForms stuurt de gebruikersinformatie automatisch mee in de extravars als `ansibleforms_user`; er is geen configuratie nodig.
+
+Je kunt kiezen hoeveel ervan wordt verstuurd. `EXTRAVARS_USER_FIELDS` neemt een kommagescheiden lijst van sleutels op het hoogste niveau
+(`username,email,type`), of `none` om niets te versturen; een formulier kan dit overschrijven met zijn eigen eigenschap `userExtravars`.
+De standaard is het hele object, zoals voorheen. De `__user__` aan de formulierkant die hieronder wordt beschreven, komt uit het aanmeldtoken en wordt nooit beïnvloed.
+
+### Gebruikersinformatie in het formulier
+
+Gebruik de informatie van de huidige gebruiker in het formulier (v4.0.2).
+
+Het veld `__user__` wordt automatisch aan het formulier toegevoegd en kan in expressies worden gebruikt:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Formuliervelden
+
+### Trapsgewijze keuzelijsten
+
+Maak trapsgewijze keuzelijsten.
+
+Velden van het type `enum` (keuzelijsten) kunnen placeholders bevatten in hun eigenschap `query` of `expression`, in de vorm `$(another_field)` of `$(another_field[0].name)`.  
+Zodra het veld waarnaar wordt verwezen verandert, wordt het verwijzende veld opnieuw geëvalueerd, wat dynamische, trapsgewijze keuzelijsten oplevert.  
+De webapplicatie aan de clientkant evalueert velden elke 100 ms opnieuw; met de huidige processors en de Chromium-engine levert dat een naadloze ervaring op.
+
+{: .note }
+> Een verwijzing naar een ander enum-veld geeft de geselecteerde waarden terug, **niet** de volledige keuzelijst. Gebruik de eigenschap `placeholderColumn` of puntnotatie zoals `$(city.name)`.  
+> **Nieuw in v4.0.20**: als je placeholderColumn op "*" zet, wordt het hele record uitgevoerd in plaats van één kolom.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Placeholders in velden
+
+Verwijs naar de waarde van een ander veld.
+
+Placeholders zijn verwijzingen naar andere velden in het formulier.  
+Een placeholder heeft altijd de vorm `$(reference)`, en zowel expressies als queries kunnen placeholders bevatten.  
+Een placeholder die naar een eenvoudig veld (text, number, password) wijst, bevat de waarde van dat veld.  
+Een placeholder die naar een enum-veld op basis van objecten wijst, moet ofwel de eigenschap `placeholderColumn` gebruiken of puntnotatie zoals `$(city.name)`.  
+Een placeholder die naar een expressieveld wijst, geeft het volledige object terug, of je gebruikt een geavanceerde, JavaScript-achtige verwijzing zoals `$(myarray[0].name)`.
+
+{: .important }
+> De placeholder wordt vervangen **voordat** de expressie wordt geëvalueerd. Verwacht je een string als resultaat, dan moet je hem tussen aanhalingstekens zetten.  
+> **Nieuw in v4.0.20**: als je placeholderColumn op "*" zet, wordt het hele record uitgevoerd in plaats van één kolom.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Een veld verbergen
+
+Verberg een veld.
+
+Verberg een veld met de veldeigenschap `hide`, of toon en verberg het dynamisch met de veldeigenschappen `dependencies` en `dependencyFn`.
+
+### Velden groeperen
+
+Groepeer velden samen in een blok.
+
+Gebruik de veldeigenschap `group`. Velden met dezelfde groepsnaam worden in een blok gegroepeerd.
+
+### Veldvalidatie
+
+Valideer een veld.
+
+Gebruik de validatie-eigenschappen van velden, zoals `regex`, `minValue` en `notIn`.
+
+### Standaardwaarde bij een enum
+
+Standaardwaarde van een enum.
+
+De veldeigenschap `default` stelt een standaardwaarde in, en bij velden van het type `enum` kun je waarden zoals `__auto__` gebruiken om automatisch het eerste item te selecteren.
+
+Voor een dynamische standaardwaarde op basis van een expressie verplaats je het standaarditem naar de top van de lijst, zoals in het volgende voorbeeld.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Standaardwaarde met een expressie
+
+Standaardwaarde met een expressie.
+
+Voor tekst-, getal- of datumvelden stelt de eigenschap `default` een statische standaardwaarde in.
+
+Om de standaardwaarde dynamisch te maken, op basis van een expressie, gebruik je een van twee eigenschappen:
+* `editable`: gebruik de eigenschap editable om een expressieveld bewerkbaar te maken
+* `evalDefault`: gebruik de eigenschap evalDefault om de standaardwaarde als expressie te evalueren
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Wizard en workflows
+
+### Wat is het verschil tussen een wizard en een workflow?
+
+Een **wizard** en een **workflow** werken allebei in stappen, maar ze werken op verschillende lagen en kunnen worden gecombineerd.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Laag** | Uitvoering | Formulier / UI |
+| **Wat het opsplitst** | De job in nodes die na elkaar, of naast elkaar, draaien | De invoer van één formulier in meerdere pagina's |
+| **Resultaat** | 1 workflowjob, met een job per node (elk met een eigen playbook of template) | Aan het eind draait 1 job |
+| **`type` van het formulier** | Moet `workflow` zijn | Werkt met elk formuliertype behalve `subform` |
+| **Gedefinieerd door** | Een [workflowbestand](workflows/file.html) van de designer (`workflow:`) | Een lijst met verwijzingen naar [subforms](forms/subform.html) (`wizard:`) |
+| **Gebruik het als** | "Doe A, dan B, dan C als aparte jobs" | "Mijn formulier heeft te veel velden voor één pagina" |
+
+**Belangrijkste les:** een workflow gaat over *wat er draait en in welke volgorde*; `wizard` gaat over *hoe de gebruiker het formulier invult*.
+
+{: .note }
+> Het formuliertype `multistep`, met zijn `steps`, deed vóór 7 het uitvoeringsdeel. Het is verouderd sinds 7 en wordt verwijderd in
+> 8: een workflow doet alles wat een multistep doet, zie [Multistep-formulieren](forms/multistep.html).
+
+#### Alleen een workflow
+{: .no_toc }
+
+Een formulier met `type: workflow` voert een van de workflows van de designer uit. De gebruiker vult één pagina met velden in en drukt op Verzenden,
+en de workflow voert zijn nodes uit, elk met de waarden van het formulier als extra vars:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Alleen een wizard
+{: .no_toc }
+
+Een blok `wizard:` op een formulier spreidt het verzamelen van invoer over meerdere pagina's. Aan het eind draait maar **één** job: de samengevoegde extravars van alle pagina's gaan naar één playbook, template of workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Een alleen-lezen controlepagina wordt automatisch als laatste wizardpagina toegevoegd; die declareer je niet in YAML.
+
+#### Gecombineerd (een wizard boven op een workflow)
+{: .no_toc }
+
+Een wizard kan boven op een workflowformulier worden gelegd. De gebruiker vult de wizardpagina's in en drukt op Verzenden, en **daarna**
+start de workflow. Door de `defaultModel` van een wizardstap te laten overeenkomen met de
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) van een node, kun je **één wizardpagina naar één node** sturen:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+En de workflow `provision-host`, in een workflowbestand van de designer:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` zoekt op één niveau, dus gebruik een platte naam in `defaultModel` (bijvoorbeeld `defaultModel: basics`, niet `defaultModel: input.basics`) als je wilt dat ze overeenkomen.
+
+Zie de [pagina over de wizard](forms/wizard.html) voor de volledige referentie van de eigenschappen.
+
+### Hoe toon ik wizardstappen of sla ik ze over op basis van een voorwaarde?
+
+Gebruik `when:` om een stap helemaal te **verbergen**, of `optional: true` om de gebruiker een zichtbare stap te laten **overslaan**. De twee staan los van elkaar en kun je doorgaans beter niet combineren.
+
+#### `when:`: voorwaardelijke zichtbaarheid
+{: .no_toc }
+
+De stap wordt verborgen als de expressie een falsy waarde oplevert. De gebruiker ziet hem nooit, en de waarden ervan worden niet verzameld. De expressie kan eerdere stappen lezen via `__parent__.<stepname>.<field>`:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Alleen de pagina die bij de gekozen `kind` hoort, wordt getoond. Stappen na een verborgen stap worden automatisch opnieuw genummerd.
+
+#### `optional: true`: een zichtbare stap laten overslaan
+{: .no_toc }
+
+De stap wordt **altijd getoond** in de stappenbalk, maar de gebruiker kan op **Volgende** drukken zonder hem in te vullen, en **Verzenden** mag ook als de pagina nooit is bezocht of afgerond:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+De gebruiker kan de pagina Advanced openen, leeg laten, op Volgende drukken en direct doorgaan naar de controlepagina.
+
+{: .note }
+> `when:` regelt de *zichtbaarheid*; `optional:` regelt *of de pagina moet worden afgerond*. Combineer ze niet: om een pagina te laten verdwijnen, gebruik je `when:`; om haar zichtbaar maar overslaanbaar te houden, gebruik je `optional:`.
+
+### Hoe verwijs ik naar waarden uit een eerdere wizardstap?
+
+Gebruik `$(__parent__.<stepname>.<field>)` in een willekeurig veld van een latere stap.
+
+De `name` van een wizardstap (standaard de naam van zijn `subform`) is de namespace waaronder de waarden ervan aan latere stappen worden aangeboden:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+Dit is hetzelfde `__parent__`-mechanisme dat subforms van `list` en `yaml` gebruiken; zie [Hoe gebruik ik gegevens van het bovenliggende formulier in een subform?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Beveiliging en referenties
+
+### Referenties
+
+Geef referenties door.
+
+Referenties kunnen op verschillende manieren worden doorgegeven:
+* met de veldeigenschap `asCredential`  
+* met de formuliereigenschap `credentials` (sleutel-waardeparen)
+* met een extravar met de naam `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Een verloren beheerderswachtwoord herstellen
+
+Ben je het wachtwoord van het lokale account `admin` kwijt en is er geen andere beheerder beschikbaar, gebruik dan de herstel-optie `REINIT_ADMIN`. **Dit is geen manier om de authenticatie tijdens het draaien te omzeilen**: het dwingt alleen bij het opstarten een eenmalige reset van het lokale beheerdersaccount af, waarna de normale authenticatie verdergaat.
+
+**Hoe het werkt**
+
+Als `REINIT_ADMIN=1` bij het opstarten is ingesteld, doet AnsibleForms het volgende:
+
+1. Het zorgt dat de groep `admins` bestaat (en maakt die aan als ze ontbreekt).
+2. Het zoekt de lokale beheerder op (standaard gebruikersnaam `admin`, te overschrijven met `ADMIN_USERNAME`).
+3. Als die bestaat, zet het het wachtwoord op de waarde van `ADMIN_PASSWORD` en koppelt het hem opnieuw aan de groep `admins`.
+4. Als die niet bestaat, maakt het hem aan (zoals bij een verse installatie).
+5. Het logt de actie duidelijk zichtbaar, zodat ze in de logs te zien is.
+
+**Stappen**
+
+1. Stop AnsibleForms.
+2. Stel de omgevingsvariabelen in (gebruik een sterk wachtwoord):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   In Docker Compose voeg je ze toe aan het blok `environment:` van de AnsibleForms-service.
+3. Start AnsibleForms en let in de logs op een regel zoals:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Meld je aan met `admin` / `YourNewStrongPasswordHere`.
+5. **Verwijder `REINIT_ADMIN` (of zet het terug op `0`)** en herstart, zodat toekomstige herstarts het beheerderswachtwoord niet opnieuw resetten.
+
+**Opmerkingen**
+
+- Was je buitengesloten omdat LDAP de enige ingestelde aanmeldmethode was en die faalde, dan valt het herstelde lokale account `admin` altijd terug op authenticatie via de lokale database, wat genoeg is om je aan te melden en LDAP te repareren.
+- De vroegere omgevingsvariabele `ENABLE_BYPASS` is verwijderd. Die stond aanmelden als admin met elk wachtwoord toe en was onveilig om aan te laten staan. `REINIT_ADMIN` reset alleen het wachtwoord; daarna geldt de normale authenticatie.
+- `REINIT_ADMIN` maakt bestaande sessies en tokens niet ongeldig; alleen de wachtwoordhash en het groepslidmaatschap veranderen.
+
+### Bestemmingen van REST-helpers beperken (allow- en denylijsten)
+
+De helpers `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` en `fn.fnRestJwtSecure` kunnen vanuit de eigenschap `expression` van een formulier worden aangeroepen om gegevens over HTTP op te halen. Standaard kunnen auteurs van expressies **elke** URL aanspreken die de AnsibleForms-host kan bereiken, wat je op een gevoelig netwerk misschien wilt beperken.
+
+Twee omgevingsvariabelen bieden een allowlijst en een denylijst:
+
+| Variabele | Gedrag |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Kommagescheiden hostnamen of CIDR's. Als dit is ingesteld, zijn **alleen** deze doelen toegestaan. |
+| `REST_DENIED_HOSTS` | Kommagescheiden hostnamen of CIDR's. Altijd geblokkeerd. Gaat voor de allowlijst. |
+
+Hostnamen worden hoofdletterongevoelig vergeleken met de host van de URL. CIDR's worden vergeleken met elk IP-adres waarnaar de host wordt opgelost, dus `10.0.0.0/8` blokkeert elke DNS-naam die in het private bereik uitkomt.
+
+**Voorbeelden:**
+
+De eerste regel staat alleen twee hosts toe; de tweede blokkeert specifieke doelen:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Deze bescherming geldt alleen voor het Node.js-proces van AnsibleForms.** Zodra een playbook draait, kan Ansible zelf alles bereiken vanaf de host, buiten de controle van AnsibleForms. Gebruik deze lijsten om te voorkomen dat formulierauteurs expressies tot een proxy voor metadataservices of interne UI's maken; vertrouw er niet op als netwerkfirewall.
+
+Sinds 7.3.0 controleren de REST-helpers het TLS-certificaat van het endpoint, zoals elke andere verbinding dat doet, en geven ze het op na
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (standaard `60`). Vertrouw een private CA met
+`NODE_EXTRA_CA_CERTS`, of zet [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) alleen op `1` voor endpoints met een
+zelfondertekend certificaat.
+
+### Integratie met HashiCorp Vault
+
+Referenties kunnen hun gebruiker en wachtwoord uit HashiCorp Vault lezen, ingesteld als
+**secret store**. Zie [Secret stores](secret-stores). De omgevingsvariabelen `VAULT_*`
+van eerdere versies worden bij de eerste start van 7.x één keer geïmporteerd als de store `vault`.
+
+Voor secrets die alleen binnen één playbook worden gebruikt, kun je ook de lookup-plugin `community.hashi_vault`
+gebruiken, die rechtstreeks uit Vault leest en AnsibleForms omzeilt.
+
+---
+
+## Integratie
+
+### AWX/Tower/AAP bevragen
+
+Vraag informatie op uit AWX of Ansible Automation Platform.
+
+Om keuzelijsten te vullen met gegevens uit AWX of Tower, gebruik je `fn.fnRestBasic` of `fn.fnRestJwtSecure`. Sinds 7.3.0 controleren deze helpers
+het certificaat van het AWX-adres: bij een zelfondertekend certificaat vertrouw je de CA ervan met `NODE_EXTRA_CA_CERTS`, of zet je
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) op `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Aanpassen
+
+### Aanpassen
+
+Pas AnsibleForms aan.
+
+AnsibleForms is een webapplicatie. Als je het native in Node.js draait, kun je de bestanden ervan vervangen of wijzigen.  
+De aanbevolen aanpak is echter om het als Docker-image te draaien en volume- of bestandskoppelingen toe te voegen. De Docker Compose-projecten koppelen al mappen om de database, playbooks, logs, certificaten en SSH-sleutels persistent te houden, en je kunt meer koppelingen toevoegen. Een eigen logo upload je op de instellingenpagina **Logo**.  
+Het bestand `custom.js` bevat je eigen JavaScript-functies voor gebruik in expressies. De ingebouwde functies gebruiken het voorvoegsel `fn.` (bijvoorbeeld fn.fnRestBasic); eigen functies gebruiken het voorvoegsel `fnc.`.  
+Op dezelfde manier kun je eigen jq-definities toevoegen in het bestand `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### YTT inschakelen
+
+Schakel ytt in.
+
+Om ytt te gebruiken, zet je `USE_YTT=1`.  
+Zie https://carvel.dev/ytt/ voor meer informatie over ytt.
+
+{: .important }  
+> Deze functie is niet uitgebreid getest, en sinds ze als verbetering is toegevoegd, is er geen feedback over binnengekomen.  
+> Als je ytt gebruikt, moet je de designer uitschakelen: de designer zet de YAML-bestanden om naar tussenliggende JSON en laat daarbij de ytt-syntaxis (die uit YAML-commentaar bestaat) vallen.
+
+Er moet een map `lib` in de hoofdmap staan; die wordt automatisch meegenomen in de aanroep van ytt.
+Gegevens kunnen globaal worden aangeleverd door omgevingsvariabelen met een voorvoegsel in te stellen:  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Je kunt ook gegevensbestanden voor bibliotheken aanleveren:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**De bibliotheek `demo` moet in de ytt-context bestaan (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+De geladen gegevens kunnen dan worden gebruikt:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Toegangsbeheer
+
+### Hoe beperk ik wat gebruikers kunnen doen (rol-opties)?
+
+Naast het beperken van welke formulieren een rol kan zien, schakelen de `options` van een rol UI-functies aan of uit voor de leden ervan.
+Zie [Rol-opties](config/roles.html#role-options) voor elke optie, de standaardwaarde en hoe opties over rollen heen worden gecombineerd.
+
+### Hoe bouw ik eigen RBAC-logica in mijn playbooks of formulieren?
+
+De identiteit van de gebruiker is bij elke uitvoering beschikbaar, zowel in de frontend als in de backend.
+
+Bij elke verzending van een formulier voegt AnsibleForms automatisch de volledige identiteit van de huidige gebruiker toe aan de extravars die naar Ansible gaan:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+Je playbook of een custom Ansible-module kan `ansibleforms_user` dus direct gebruiken voor fijnmazige beslissingen, bijvoorbeeld om alleen bepaalde groepen de productie-inventory te laten wijzigen, of om een audittrail met de gebruikersnaam van de indiener te schrijven.
+
+In de **frontend** is hetzelfde object beschikbaar via het speciale veld `__user__`:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Typische patronen:**
+
+De identiteit van de gebruiker maakt patronen als de volgende mogelijk:
+
+- **Vergelijken met een RBAC-configuratiebestand of -database**: laad een YAML- of JSON-bestand (met `fn.fnReadYamlFile` of een expressie) dat groepen aan toegestane resources koppelt, en filter dan op `$(__user__.groups)`
+- **Audittrail**: geef `ansibleforms_user.username` mee als extra variabele om vast te leggen wie de job heeft gestart
+- **Dynamische veldwaarden**: toon een andere set enum-keuzes, vul velden vooraf in, of verberg secties op basis van de groepen of rollen van de gebruiker
+- **Autorisatie in het playbook**: controleer met een assert dat `ansibleforms_user.groups` een vereiste groep bevat voordat het playbook verdergaat, als extra verdedigingslaag die losstaat van de lijst `roles` van het formulier
+
+{: .note }
+> Het object hierboven is wat standaard wordt verstuurd. Als de instantie `EXTRAVARS_USER_FIELDS` instelt,
+> of het formulier `userExtravars` instelt, worden alleen de sleutels verstuurd die daar staan, dus een playbook dat
+> een assert doet op `ansibleforms_user.groups` vereist dat `groups` daar een van is. Het frontendveld
+> `__user__` komt uit het aanmeldtoken en wordt door geen van beide instellingen ingekort.
+
+---
+
+## Jobs plannen
+
+### Hoe plan ik een formulier om automatisch te draaien?
+
+Open de keuzelijst naast **Verzenden** en kies **Schedule (terugkerend)** of **Later uitvoeren (eenmalig)**; daarvoor zijn de rol-opties
+`allowScheduledJobs` (beheerdersniveau) en `allowPlannedJobs` nodig. Zie [Planningen](jobs/schedules.html).
+
+### Welke cron-expressies kan ik gebruiken?
+
+Een terugkerende planning neemt een standaard cron-expressie met 5 velden (minuut, uur, dag van de maand, maand, dag van de week).
+
+| Expressie | Draait |
+|---|---|
+| `*/15 * * * *` | Elke 15 minuten |
+| `0 * * * *` | Elk uur, op het hele uur |
+| `0 */6 * * *` | Elke 6 uur, om 00:00, 06:00, 12:00 en 18:00 |
+| `0 2 * * *` | Elke dag om 02:00 |
+| `30 7 * * 1-5` | Maandag tot en met vrijdag om 07:30 |
+| `0 8 * * MON` | Elke maandag om 08:00 (namen van dagen en maanden worden geaccepteerd) |
+| `0 0 1 * *` | Om middernacht op de eerste dag van elke maand |
+| `0 22 L * *` | Om 22:00 op de laatste dag van elke maand |
+| `0 6 * * 1#1` | Om 06:00 op de eerste maandag van elke maand |
+| `*/30 * * * * *` | Elke 30 seconden (een optioneel zesde veld vooraan is de seconde) |
+
+Als zowel de dag van de maand als de dag van de week zijn ingesteld, draait de planning wanneer een van beide overeenkomt: `0 0 13 * 5` draait op
+de 13e en op elke vrijdag. De server weigert een expressie die hij niet kan uitvoeren, of een die nooit kan voorkomen (`0 0 30 2 *`).
+
+Op de pagina **Planner** beschrijft de cron-editor de expressie en toont hij een voorbeeld van de volgende runs. Hij accepteert geen bijnamen
+zoals `@daily`, het jokerteken `?` of de modifier `W` (dichtstbijzijnde werkdag), dus houd je aan de vormen in de tabel.
+
+{: .note }
+> **Tijdzone** Cron-planningen draaien in de tijdzone van de server, ingesteld met [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (standaard `UTC`), niet in de tijdzone van je profiel of je browser. `0 2 * * *` met `LOG_TZ=Europe/Madrid` draait het hele jaar om 02:00
+> tijd in Madrid, en volgt de zomertijd. De cron-editor toont de volgende runs in diezelfde zone. Pull-planningen van repositories
+> gebruiken dezelfde zone.
+
+---
+
+## Formuliergegevens opslaan en laden
+
+### Hoe sla ik formuliergegevens op en laad ik ze opnieuw zonder een job uit te voeren?
+
+Kies **Store** in de keuzelijst naast **Verzenden** om de veldwaarden op te slaan, en daarna **Laden uit opslag** om ze later terug te zetten.
+Wachtwoordvelden worden nooit opgeslagen. Daarvoor is de rol-optie `allowStoredJobs` nodig. Zie [Opgeslagen jobs](jobs/stored-jobs.html).
+
+---
+
+## Geneste formulieren en gestructureerde velden
+
+### Hoe verzamel ik gestructureerde of herhaalde gegevens in een formulier?
+
+Gebruik velden `list` en `yaml` met subforms (6.2.0+).
+
+Om complexe gestructureerde gegevens te verzamelen, zoals een lijst met servers, een set netwerkinterfaces of één genest object, gebruik je het veldtype `list` of `yaml` samen met een `subform`.
+
+Een **subform** is een herbruikbaar formulierfragment (gedefinieerd met `type: subform`) dat nooit als losse tegel wordt getoond. Het bestaat alleen om naar te verwijzen vanuit velden in andere formulieren. Zie de [documentatie over subforms](forms/subform.html) voor de volledige referentie.
+
+**Een lijst met gestructureerde rijen verzamelen: het veld `list`:**
+
+Een veld `list` opent het subform waarnaar het verwijst één keer per rij:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+De extravar `servers` die naar Ansible gaat, is een array van objecten: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Eén gestructureerd object bewerken: het veld `yaml`:**
+
+Het veld `yaml` heeft drie modi:
+
+| Modus | Hoe | Gedrag |
+|---|---|---|
+| **Editor** | standaard | Toont een volledige YAML-editor met syntaxiskleuring waarin de gebruiker direct kan typen |
+| **Alleen-lezen** | `readonly: true` | Toont de YAML-waarde als opgemaakte alleen-lezen tekst, zonder bewerken |
+| **Subform** | `subform: MySubform` | Verbergt de ruwe editor; opent bij een klik het subform als drilldown-editor |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Uploaden en downloaden: de velden `list` en `yaml`:**
+
+Beide veldtypen ondersteunen bestandsoverdracht aan de clientkant via twee optionele eigenschappen:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> Het veld `list` en het formuliertype `subform` vervangen het veld `table` en `tableFields`, die in 7.0.0 zijn verwijderd.
+
+### Hoe gebruik ik gegevens van het bovenliggende formulier in een subform?
+
+Verwijs vanuit een subform naar veldwaarden van het bovenliggende formulier via `__parent__` (v6.3.0+).
+
+Als een subform opent, vanuit een veld **`list`** (elke rij-editor) of een veld **`yaml`** in subformmodus, voegt AnsibleForms automatisch een speciaal alleen-lezen veld `__parent__` aan het subform toe. Het bevat een momentopname van **elke veldwaarde in het bovenliggende formulier op het moment dat het subform werd geopend**, inclusief constanten en vars.
+
+Zo kunnen velden van een subform expressies gebruiken die naar gegevens van het bovenliggende formulier verwijzen, zonder extra configuratie.
+
+#### Wat zit er in `__parent__`?
+{: .no_toc }
+
+`__parent__` is een gewoon object waarvan de sleutels de veldnamen van het bovenliggende formulier zijn:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` wordt **niet naar Ansible gestuurd**; net als `__user__` wordt het uit de extravars gehaald. Het is puur een hulpmiddel in de frontend voor expressies binnen subforms.
+
+#### Waarden van het bovenliggende formulier gebruiken in expressies van een subform
+{: .no_toc }
+
+Verwijs naar waarden van het bovenliggende formulier met de standaard expressiesyntaxis `$(...)`:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Geneste subforms
+{: .no_toc }
+
+`__parent__` verwijst altijd naar het **direct bovenliggende** formulier. Als je een `list` nest in een subform dat zelf vanuit een bovenliggend formulier wordt geopend, bevat de `__parent__` van het binnenste subform de gegevens van het middelste subform. Om verdere niveaus te bereiken, keten je verwijzingen zoals `$(__parent__.__parent__.someField)`, als het middelste subform ook zijn eigen `__parent__` doorgeeft.
+
+### Hoe migreer ik van `table` / `tableFields` naar `list` / `subform`?
+
+Het veld `table` en de eigenschap `tableFields` zijn verouderd sinds 6.2.0 en verwijderd in 7.0.0, en een formulier dat ze nog gebruikt, komt niet door de validatie. Om te migreren:
+
+1. Haal de kolommen uit `tableFields` naar een nieuw formulier met `type: subform` en gewone `formfields`
+2. Vervang het veld `table` door een veld `list` dat via `subform: MySubformName` naar het subform verwijst
+
+**Voor:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Na:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### `from` in `tableFields` migreren naar expressies met `__parent__`
+{: .no_toc }
+
+De eigenschap `from` van enum-kolommen in `tableFields` vulde de keuzes van een keuzelijst vanuit een ander veld in het bovenliggende formulier. In een `subform` wordt die vervangen door een `expression` die dezelfde waarde via `__parent__` leest.
+
+**Voor: `tableFields` met `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Na: subform met een expressie op `__parent__`:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` geeft de **huidige waarde** van dat veld terug, dus als dat veld zelf een dynamisch expressieveld is, ziet het subform altijd het laatst geëvalueerde resultaat van het bovenliggende formulier.
diff --git a/i18n/nl/_reference/getting-help.md b/i18n/nl/_reference/getting-help.md
new file mode 100644
index 0000000..1b87906
--- /dev/null
+++ b/i18n/nl/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Hulp krijgen
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Hulp krijgen
+{: .no_toc }
+
+Waar je een vraag stelt, een bug of een beveiligingsprobleem meldt, en een verbetering voorstelt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Voordat je het vraagt
+
+De meeste antwoorden staan al ergens beschreven; even kijken bespaart vaak een rondje heen en weer:
+
+1. Doorzoek deze site met het zoekvak bovenaan elke pagina.
+2. Zoek de exacte foutmelding op in [Probleemoplossing](troubleshooting.html), en blader door de [FAQ](faq.html).
+3. Bekijk het serverlog (**Instellingen**, daarna **Serverlog**) en de pagina **Status**, die de meeste configuratieproblemen melden.
+4. Bekijk de [Changelog](changelog.html): het probleem kan in een nieuwere release al zijn opgelost.
+
+---
+
+## Waar je terechtkunt
+
+Elk soort verzoek heeft een eigen plek, allemaal op GitHub:
+
+| Je wilt | Ga naar |
+|---|---|
+| Een vraag stellen of een idee delen | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Een bug melden | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Een functie voorstellen | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Een beveiligingsprobleem melden | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), privé |
+| Deze documentatie corrigeren of verbeteren | **Edit this page on GitHub** onderaan elke pagina, of een [issue op de website](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Een bug melden
+
+Een melding die kan worden gereproduceerd, wordt het snelst opgelost. Het sjabloon voor bugmeldingen vraagt om het volgende:
+
+* **Versie** : te zien onder **Over** in het helpmenu (**?**) van de bovenbalk
+* **Deployment** : Docker, Docker Compose, Kubernetes, het installatieprogramma (en de engine ervan), een native installatie of vanuit de broncode
+* **Stappen om te reproduceren** : wat je deed, wat je verwachtte, en wat er in plaats daarvan gebeurde
+* **Bewijs** : de relevante regels uit het serverlog, en een schermafbeelding als het probleem zichtbaar is
+
+Voeg bij een probleem met een formulier een minimale formulierdefinitie toe die het laat zien. Verwijder wachtwoorden, tokens, hostnamen en alle
+andere privégegevens uit logs en formulieren voordat je ze plaatst: issues en discussies zijn openbaar.
+
+---
+
+## Een beveiligingsprobleem melden
+
+**Open er nooit een openbaar issue voor:** gebruik [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), dat alleen de maintainers zien.
+
+Het [beveiligingsbeleid](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) noemt de ondersteunde versies en
+wat er gebeurt nadat je een melding hebt gedaan.
diff --git a/i18n/nl/_reference/troubleshooting.md b/i18n/nl/_reference/troubleshooting.md
new file mode 100644
index 0000000..0bb6ec8
--- /dev/null
+++ b/i18n/nl/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Probleemoplossing
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Probleemoplossing
+{: .no_toc }
+
+Foutmeldingen en symptomen, waarom ze optreden en hoe je ze oplost
+{: .fs-6 .fw-300 }
+
+---
+
+Elk probleem hieronder heeft als titel de melding of het symptoom dat je ziet, gevolgd door de oorzaak en de oplossing. Meldingen worden
+letterlijk geciteerd zoals AnsibleForms ze schrijft; `<name>` staat voor een waarde die per geval verschilt. De meeste komen in het serverlog
+terecht, dat je kunt lezen onder [Serverlog](gui/administration.html#server-log) of met `docker logs`.
+
+**Database en opstarten**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Configuratie en formulieren**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [De basisconfiguratie heeft een sectie forms](#the-base-config-has-a-forms-section)
+* [Een formulier ontbreekt op het dashboard](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Aanmelden**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Authenticatie met Azure AD of OIDC mislukt](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Afgemeld na een herstart of na een dag](#logged-out-after-a-restart-or-after-a-day)
+* [Lege formulieren en jobs na een single sign-on (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Jobs**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Een job toont de status abandoned](#a-job-shows-the-status-abandoned)
+* [Een RTE maakt geen verbinding](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Git-repositories en back-ups**
+
+* [Een clone of pull van een repository is mislukt](#a-repository-clone-or-pull-failed)
+* [De formulierenrepository is nog niet gecloned](#the-forms-repository-is-not-cloned-yet)
+* [Een back-up is mislukt](#a-backup-failed)
+
+De [FAQ](faq.html) behandelt twee verwante problemen uitgebreid: een
+[verloren beheerderswachtwoord](faq.html#recovering-a-lost-admin-password) en
+[het beperken van de bestemmingen van REST-helpers](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms start niet, en het log herhaalt deze regels elke 5 seconden:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Waarom dit gebeurt**
+
+Bij het opstarten wacht AnsibleForms tot de database op een query antwoordt, en het blijft wachten zolang dat niet gebeurt.
+De `<reason>` is het eigen bericht van de databasedriver: een geweigerde of verlopen verbinding wijst op de host of de poort,
+een access-denied-melding op de gebruikersnaam of het wachtwoord.
+
+**Hoe je het oplost**
+
+Controleer [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) en [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Binnen een container is `localhost` de container zelf, niet de host waarop MySQL draait. Zorg dat MySQL luistert
+op een netwerkadres en dat de gebruiker verbinding mag maken vanaf de AnsibleForms-host. AnsibleForms gaat vanzelf verder zodra
+de database antwoordt; er is geen herstart nodig.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+De browser opent een databasepagina in plaats van de aanmeldpagina, en het log toont:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Waarom dit gebeurt**
+
+Het schema `AnsibleForms` ontbreekt of is onvolledig. Een *lege* database wordt bij het opstarten automatisch ingericht, tenzij
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) `0` is. Als dat mislukt, bijvoorbeeld omdat
+de databasegebruiker geen schema mag aanmaken, zegt het log `Failed to create the schema automatically : <reason>`. Een schema
+dat bestaat maar tabellen mist (`Table '<name>' is not present`) wordt nooit automatisch opnieuw aangemaakt, omdat het aanmaken van het
+schema eerst alle tabellen verwijdert. De databasepagina zegt dan *It appears that you have an unuseable schema*.
+
+**Hoe je het oplost**
+
+Geef bij een verse installatie de databasegebruiker het recht om het schema `AnsibleForms` aan te maken en herstart, of druk op
+**Aanmaken** op de databasepagina. Bij een gedeeltelijk aanwezig schema herstel je een back-up of verwijder je het onvolledige schema `AnsibleForms`
+zodat AnsibleForms het opnieuw kan aanmaken. Het log toont welke tabellen en patches zijn mislukt.
+
+---
+
+## Schema creation is disabled
+
+Het aanmaken van het schema, vanaf de databasepagina of met `POST /api/v2/schema`, mislukt met:
+
+```
+Schema creation is disabled
+```
+
+**Waarom dit gebeurt**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) is `0`, wat zowel het automatisch
+aanmaken bij het opstarten als het endpoint uitschakelt. Op een database die al gebruikers heeft, weigert het endpoint ook aanroepers die niet
+als beheerder zijn aangemeld, met `Schema creation requires an authenticated administrator`.
+
+**Hoe je het oplost**
+
+Maak het schema één keer aan met `ALLOW_SCHEMA_CREATION=1` (dat is de standaard), of herstel het uit een back-up, en zet de
+variabele daarna terug op `0`. Meld je op een ingerichte database aan als beheerder voordat je het schema opnieuw aanmaakt, en onthoud
+dat dit elke tabel verwijdert en opnieuw aanmaakt.
+
+---
+
+## Config seed failed, refusing to start
+
+De container stopt direct na het opstarten, en de uitvoer eindigt met:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Waarom dit gebeurt**
+
+Het bestand in [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) kon niet worden toegepast: het is bijvoorbeeld geen geldige
+YAML of schendt het seedschema; `<reason>` zegt wat er misging. AnsibleForms weigert te starten in plaats van
+te draaien met de helft van zijn gedeclareerde objecten. De reden wordt ook naar standard error geschreven, dus `docker logs` en `kubectl logs` tonen hem.
+
+**Hoe je het oplost**
+
+Corrigeer wat `<reason>` noemt en start opnieuw. Zie [Herladen en opstarten](seed/reloading.html) voor hoe de seed wordt
+toegepast, en [Voorbeeld](seed/example.html) voor een geldig bestand.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Elke start logt deze waarschuwing:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Of de worker weigert te starten met:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Waarom dit gebeurt**
+
+Opgeslagen secrets worden versleuteld met [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET): sinds 7.3.0 staan ze in
+referenties (onder andere de wachtwoorden en tokens van LDAP-directory's, SSO-providers, runners en secret stores), naast de webhookadressen van Slack
+en Teams. Zonder deze variabele wordt een sleutel gebruikt die openbaar in de broncode staat. Sinds 7.3.0 versleutelt een start met een nieuwe
+`ENCRYPTION_SECRET` elk opgeslagen secret opnieuw daarmee, in één transactie: vanaf de standaardsleutel als hij voor het eerst wordt
+ingesteld, of vanaf [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) als hij verandert. Als de
+opgeslagen secrets met geen van beide zijn versleuteld, wordt er niets gewijzigd en start AnsibleForms niet.
+
+**Hoe je het oplost**
+
+Stel `ENCRYPTION_SECRET` in, en bewaar hem bij je andere secrets: back-ups bevatten hem nooit. De volgende start logt
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Om hem later te wijzigen, zet je de nieuwe waarde in
+`ENCRYPTION_SECRET` en de oude in `ENCRYPTION_SECRET_PREVIOUS` voor één start, en verwijder je daarna `ENCRYPTION_SECRET_PREVIOUS`. Als de
+worker weigert te starten, zet je `ENCRYPTION_SECRET_PREVIOUS` op de sleutel waarmee de secrets zijn versleuteld, of zet je de oude waarde terug.
+
+---
+
+## Could not load the forms
+
+Het dashboard toont geen formulieren en meldt:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Waarom dit gebeurt**
+
+De basisconfiguratie (`config.yaml`) kon niet worden gelezen of is niet geldig. De `<reason>` zegt welke van de twee:
+
+| Reden | Oorzaak |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Een YAML-syntaxfout |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Een leeg bestand, of een bestand met alleen commentaar |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | Dezelfde rol is twee keer gedefinieerd |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` ontbreekt en de map ervan is niet beschrijfbaar |
+| `There is no forms directory nor could there be one created from template.` | De map met formulieren ontbreekt en kan niet worden aangemaakt |
+| Elke andere regel | De configuratie schendt het schema, bijvoorbeeld een rol zonder `groups` |
+
+**Hoe je het oplost**
+
+Corrigeer het bestand dat [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) noemt, of de `config.yaml` in de
+repository die voor de configuratie wordt gebruikt. Als er bestanden ontbreken, laat je [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) en
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) naar een beschrijfbare, persistente locatie wijzen. Zie
+[config.yaml](config/) voor de structuur.
+
+---
+
+## De basisconfiguratie heeft een sectie forms
+
+Na een upgrade vanaf 6.x is het dashboard leeg, en het waarschuwingspaneel toont:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Waarom dit gebeurt**
+
+Sinds 7.0.0 staat elk formulier in een eigen bestand in de map met formulieren. Formulieren die nog in `config.yaml` staan, worden
+genegeerd.
+
+**Hoe je het oplost**
+
+Zet elk formulier in een eigen bestand in [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Zie
+[Upgraden naar 7.x](upgrade-7.html).
+
+---
+
+## Een formulier ontbreekt op het dashboard
+
+Een formulierbestand bestaat, maar een gebruiker ziet het formulier niet op het dashboard.
+
+**Waarom dit gebeurt**
+
+Een gebruiker ziet een formulier alleen als een van de `roles` van het formulier een van zijn rollen is; beheerders zien elk formulier. Elke gebruiker heeft
+de rol `default`, dus een formulier met `roles: [default]` is voor iedereen zichtbaar. De rollen van een gebruiker komen uit de groepen en gebruikers
+die onder `roles` in `config.yaml` staan. Een formulier zonder `categories` verschijnt onder **Default**, en ontbreekt dus in de
+andere categorieën, al staat het nog wel onder **Alle formulieren**. Tot slot wordt een formulier dat niet door de validatie komt, overgeslagen. Het
+dashboard toont dan een knop **Deze configuratie heeft Waarschuwingen of fouten**, die meldingen opent zoals:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Hoe je het oplost**
+
+Open het waarschuwingspaneel en corrigeer wat het opsomt. Controleer de rollen van de gebruiker onder
+[Rechten](profile/permissions.html) in het profiel, en de `roles` en `categories` van het formulier. Zie
+[Rollen](config/roles.html) en [Categorieën](config/categories.html). Als twee bestanden dezelfde formuliernaam definiëren,
+wint het bestand dat als eerste wordt geladen.
+
+---
+
+## Could not save the forms
+
+Opslaan in de designer mislukt met:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Waarom dit gebeurt**
+
+De designer valideert elk formulier tegen het schema voordat hij iets schrijft. Elke regel van `<messages>` noemt het
+formulier en het veld dat een regel schendt. Opties die in 7.0.0 zijn verwijderd, krijgen een eigen melding, bijvoorbeeld
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Hoe je het oplost**
+
+Corrigeer de velden die de meldingen noemen. Voor opties die 7.0.0 heeft verwijderd, volg je [Upgraden naar 7.x](upgrade-7.html).
+Om formulierbestanden te valideren voordat ze AnsibleForms bereiken, zie
+[VS Code-validatie voor formulierbestanden](faq.html#vs-code-validation-for-form-files) in de FAQ.
+
+---
+
+## The editor is read-only
+
+De designer toont **Vergrendeld door** met de naam van een andere gebruiker, en opslaan mislukt met:
+
+```
+The editor is read-only
+```
+
+**Waarom dit gebeurt**
+
+Er kan maar één persoon tegelijk de formulieren bewerken. De vergrendeling wordt genomen als iemand de designer start, en blijft staan tot
+die persoon hem stopt, ook als hij de browser heeft gesloten zonder te stoppen. De API weigert een opslag door ieder ander met
+`Designer is locked by <username>`.
+
+**Hoe je het oplost**
+
+Vraag `<username>` de designer te stoppen. Als dat niet kan, gebruik je **Force Unlock** in de designer. Wie de
+vergrendeling heeft, verliest de wijzigingen die nog niet zijn opgeslagen.
+
+---
+
+## Abuse attempt of eval function
+
+Een expressieveld toont een fout, en het log bevat een regel zoals:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Waarom dit gebeurt**
+
+Expressies aan de serverkant worden gecontroleerd voordat ze draaien. Ze mogen alleen `fn.`- en `fnc.`-functies aanroepen; meerdere statements,
+meerdere regels, template literals, `process.env` en woorden zoals `require` of `constructor` worden geweigerd. De melding
+zegt welke regel is geschonden. Met [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) op
+`off` mislukt elke serverexpressie met
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Hoe je het oplost**
+
+Herschrijf de expressie als één `fn.`-aanroep of een eenvoudige bewerking, of voer haar in de browser uit met `runLocal: true`. Zie
+[Expressies](expressions/) en [Lokale expressies](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Een veld dat een REST API aanroept blijft leeg, en het log toont:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Waarom dit gebeurt**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) is ingesteld, en de host van de URL staat er niet in.
+Een host die overeenkomt met [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) wordt geweigerd met
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, en een host die niet wordt opgelost met `cannot resolve <host>`.
+
+**Hoe je het oplost**
+
+Voeg de hostnaam, of een CIDR die de adressen ervan dekt, toe aan `REST_ALLOWED_HOSTS`, of verwijder de regel die hem blokkeert uit
+`REST_DENIED_HOSTS`. Zie [Bestemmingen van REST-helpers beperken](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+De aanmeldpagina weigert een gebruikersnaam en wachtwoord met:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Waarom dit gebeurt**
+
+De aanmeldpagina geeft bij elke mislukking hetzelfde antwoord, zodat ze niet verraadt of een gebruiker bestaat. AnsibleForms
+probeert eerst de lokale gebruikers en daarna LDAP: met meerdere directory's wordt een gebruikersnaam opgezocht in hun volgorde onder **Toegang > LDAP**,
+tenzij hij een directory noemt (`corp\jane`) of een van haar aanmelddomeinen (`jane@corp.example`). De echte reden gaat naar het log. LDAP-
+fouten worden gelogd als `Error connecting to ldap: <reason>`, met redenen zoals `Wrong binding credentials` of
+`Unable to verify the certificate`; codes van Active Directory worden vertaald naar `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` of `Password expired`.
+
+**Hoe je het oplost**
+
+Lees de reden in het log. Voor de volledige reden van elke mislukte aanmelding zet je
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) op `debug`, wat `Ldap authentication failed: <reason>` logt.
+Als het lokale beheerderswachtwoord kwijt is, zie [Een verloren beheerderswachtwoord herstellen](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Het testen van een LDAP-directory onder **Toegang > LDAP** mislukt met een van deze:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Waarom dit gebeurt**
+
+De bind-gebruiker of zijn wachtwoord is onjuist, de server of poort is niet bereikbaar, of, met TLS, het certificaat van de server kan niet
+worden geverifieerd tegen de CA-bundel. Sinds 7.3.0 staan deze op de ldap-referentie van de directory, onder **Verbindingen > Inloggegevens**. Een testgebruiker die niet bestaat,
+telt nog steeds als geslaagde test, omdat de verbinding en de bind werkten.
+
+**Hoe je het oplost**
+
+Open de referentie die de directory noemt (de standaarddirectory is `main`) onder **Verbindingen > Inloggegevens**, en corrigeer de bind-
+DN en het wachtwoord, de servers en de poort (meestal 389, of 636 voor LDAPS). Bij TLS-problemen plak je de CA-bundel die het
+certificaat van de LDAP-server heeft ondertekend; de certificaatcontrole overslaan is niet bedoeld voor productie. Zie [LDAP](authentication/ldap.html).
+
+---
+
+## Authenticatie met Azure AD of OIDC mislukt
+
+Een aanmelding via single sign-on keert terug naar de aanmeldpagina met:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Waarom dit gebeurt**
+
+De identity provider heeft de gebruiker teruggestuurd, maar AnsibleForms kon de aanmelding niet afronden. Gangbare redenen zijn
+`azuread login is not enabled` of `oidc login is not enabled` (de provider is uitgeschakeld), en `jwt expired`, omdat
+de overdracht vanaf de provider maar 5 minuten geldig is. Een fout tijdens de callback van de provider wordt ook
+op de aanmeldpagina getoond, en gelogd.
+
+**Hoe je het oplost**
+
+Schakel de provider in onder **Toegang > SSO**, en registreer de callback-URL in de identity provider precies zoals
+AnsibleForms hem gebruikt: `https://<your host>/api/v2/auth/entraid/callback` voor Entra ID (vanaf 7.3.0; `azureadoauth2` werkt nog), of
+`https://<your host>/api/v2/auth/oidc/callback` voor OIDC. Een callback-URL met `/api/v1/`, van vóór 7 of vóór
+6.1.5, moet worden bijgewerkt: de aanmeldpagina herlaadt dan zonder aan te melden en zonder foutmelding. Probeer de aanmelding opnieuw na
+een verlopen overdracht.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Een gebruiker met een geldig wachtwoord kan zich niet aanmelden, en krijgt:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Waarom dit gebeurt**
+
+Een van de rollen van de gebruiker zet de rol-optie `allowLogin` op `false`. Het log zegt
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Hoe je het oplost**
+
+Verwijder `allowLogin: false` uit de rol, of haal de gebruiker uit die rol. Zie [Rollen](config/roles.html).
+
+---
+
+## Afgemeld na een herstart of na een dag
+
+Elke gebruiker wordt teruggestuurd naar de aanmeldpagina nadat AnsibleForms herstart, of na een dag gebruik.
+
+**Waarom dit gebeurt**
+
+Als [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) niet is ingesteld, genereert elke start een
+nieuwe ondertekeningssleutel, en logt
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Tokens van vóór de
+herstart worden dan niet meer geaccepteerd. Los daarvan eindigt een sessie als het refresh token ervan verloopt
+(`Refresh token is expired`), na
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), standaard 24 uur.
+
+**Hoe je het oplost**
+
+Zet `ACCESS_TOKEN_SECRET` op een vaste, geheime waarde. Verhoog `ACCESS_TOKEN_REFRESH_EXPIRATION` als een dag te kort is. Voor
+langdurige API-toegang gebruik je een [API-token](profile/api-token.html).
+
+---
+
+## Lege formulieren en jobs na een single sign-on (HTTP 431)
+
+Een gebruiker meldt zich zonder fout aan met Entra ID of OIDC, maar de pagina's met formulieren en jobs blijven leeg. Het netwerktabblad
+van de browser toont dat de API-aanroepen worden beantwoord met:
+
+```
+431 Request Header Fields Too Large
+```
+
+Het serverlog toont niets voor deze aanroepen, en dezelfde gebruiker kan prima werken met een LDAP- of lokaal account.
+
+**Waarom dit gebeurt**
+
+Vóór 7.1.0 bevatte het aanmeldtoken elke groep van de gebruiker, en stonden Entra ID-groepen er twee keer in, op object-id
+en op naam. De browser stuurt dat token mee in de header `Authorization` van elk verzoek, dus een gebruiker in ongeveer honderd
+groepen of meer krijgt een header van ruim 16 KB. Node.js weigert requestheaders groter dan 16 KB met een 431,
+voordat het verzoek AnsibleForms bereikt, en daarom wordt er niets gelogd. Een reverse proxy ervoor kan het
+verzoek nog eerder weigeren: Nginx staat standaard 8 KB per headerveld toe
+(`large_client_header_buffers 4 8k`), en antwoordt dan 400.
+
+**Hoe je het oplost**
+
+Upgrade naar 7.1.0 of later: het aanmeldtoken bevat de groepen niet meer, dus de grootte ervan hangt niet meer af van in hoeveel
+groepen een gebruiker zit, en de interface meldt het als een verzoek met 431 wordt geweigerd in plaats van lege pagina's te tonen.
+Tot je kunt upgraden, kun je ofwel:
+
+* een **Groepfilter** instellen op de provider onder **Toegang > SSO**, een reguliere expressie die alleen de groepen houdt die je
+  rollen gebruiken, zie [Entra ID](authentication/entra-id.html) of [OIDC](authentication/oidc.html); de gebruiker meldt zich opnieuw aan
+  om een kleiner token te krijgen
+* of de limiet van Node.js verhogen met de omgevingsvariabele `NODE_OPTIONS=--max-http-header-size=65536`, en
+  AnsibleForms herstarten
+
+Vanaf 7.1.0 stelt [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) dezelfde limiet in, standaard 16384
+bytes en gelezen bij de start, voor andere grote headers, zoals grote cookies die een single sign-on-gateway ervoor
+zet. Verhoog ook de headerlimieten van de proxy, zie [Grootte van requestheaders](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Een Ansible-job eindigt als mislukt, en de laatste regel van de uitvoer is:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Waarom dit gebeurt**
+
+`ansible-playbook` is gestopt met een code die niet nul is. De regels erboven bevatten de eigen fout van Ansible: het playbook kon niet worden
+gevonden, een host was onbereikbaar, een taak is mislukt, of de inventory klopt niet. Het playbook wordt opgezocht in de repository
+waarbij **Gebruiken voor playbooks** aan staat, of in [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); de logregel
+`Running from directory : <path>` toont de map die is gebruikt.
+
+**Hoe je het oplost**
+
+Lees de uitvoer van de job boven de laatste regel. Als het playbook niet wordt gevonden, vergelijk je de `playbook` van het formulier met de
+map in `Running from directory`. Zie [Ansible-formulieren](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Een Ansible-job eindigt als mislukt met:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Waarom dit gebeurt**
+
+Het proces `ansible-playbook` op de RTE is beëindigd door een signaal, en niemand heeft de job afgebroken. Sinds 7.0.0 veroorzaakt de grootte van de
+uitvoer dit niet meer: boven [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (standaard 50 MB per stream)
+wordt de rest van de uitvoer niet opgeslagen, toont de job
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+en draait het playbook tot het einde. De gebruikelijke oorzaak is nu geheugen: de RTE-container bereikte zijn geheugenlimiet en de
+kernel heeft het playbook gestopt, bijvoorbeeld met veel forks of grote facts.
+
+**Hoe je het oplost**
+
+Controleer het geheugen van de RTE-container terwijl het playbook draait (`docker stats`, `kubectl top pod`) en verhoog de limiet, of verlaag
+het geheugengebruik van het playbook (minder `forks`, geen onnodig verzamelen van facts). Zie je alleen de waarschuwing over `PROCESS_MAX_BUFFER` en
+heb je de hele uitvoer nodig, verhoog dan `PROCESS_MAX_BUFFER` in de omgeving van de RTE-container; die wordt door de RTE gelezen, niet door de app.
+---
+
+## Failed to launch awx template
+
+Een AWX-job eindigt als mislukt, met uitvoer die begint met:
+
+```
+failed to launch awx template <name>
+```
+
+**Waarom dit gebeurt**
+
+De volgende regel geeft de reden. `Request failed with status code 401` betekent dat het token of de gebruikersnaam en het wachtwoord op de
+referentie van de AWX-runner worden geweigerd. `could not find job template <name>` betekent dat geen job template en geen workflow job template
+precies die naam heeft, of dat de gebruiker van de verbinding hem niet kan zien. Een certificaatfout, zoals
+`unable to verify the first certificate`, betekent dat het AWX-certificaat niet wordt vertrouwd.
+
+**Hoe je het oplost**
+
+Gebruik **Verbinding testen** op de runner (**Verbindingen > Runners**), die `Runner connection is OK` antwoordt als het werkt. Sinds
+7.3.0 staan het token of de gebruiker en het wachtwoord, het adres en de **CA-bundel** op de referentie van de runner, onder
+**Verbindingen > Inloggegevens**: vernieuw daar het token of wachtwoord, en plak bij certificaatfouten de CA in de **CA-bundel** ervan.
+Controleer de naam en de rechten van de template. Voer het adres in zonder `/api/v2`: AnsibleForms voegt
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX) zelf toe.
+Zie [AWX-formulieren](forms/awx.html).
+
+---
+
+## Een job toont de status abandoned
+
+Een job die draaide, is nu gemarkeerd als `abandoned`, en het log van een node of een RTE toont een van:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Een RTE in databasemodus, verouderd, logt zijn eigen meldingen:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Waarom dit gebeurt**
+
+Een job hoort bij de container die hem uitvoert of volgt: een playbook bij zijn RTE, elke andere job (een AWX-job, de stappen van een multistep-
+formulier) bij de app-node die hem startte. Als die container herstart, beëindigt hij zijn eigen onvoltooide jobs. Als hij verdwijnt, bijvoorbeeld een vervangen
+pod, beëindigt de worker zijn jobs zodra hij twee minuten niet heeft geantwoord. Bij een RTE in een socketmodus die terugkomt zonder
+een job die hij uitvoerde, bijvoorbeeld een nieuwe container zonder zijn spool, eindigt die job als abandoned. Een RTE die stopt, wacht eerst
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) op zijn playbooks. Elk uur worden jobs die al langer
+dan een dag draaien ook als abandoned gemarkeerd.
+
+Sinds 7.3.0 loopt een job op AWX, AAP of Ascender door op zijn runner: direct nadat een herstart hem opgeeft, volgt een node hem opnieuw,
+als hij in de afgelopen 24 uur is gestart, en eindigt hij met wat daar echt is gebeurd. Het log zegt dan `Following <n> abandoned job(s) again on their runner`.
+
+**Hoe je het oplost**
+
+Start een playbookjob opnieuw. Herstart of upgrade RTE's en app-nodes terwijl er geen job draait, en geef een RTE die stopt genoeg tijd
+(zie [Schalen](rte/run.html)). Controleer of het playbook echt is voltooid op de beheerde hosts voordat je
+opnieuw start, want het kan gedeeltelijk zijn uitgevoerd.
+
+---
+
+## Een RTE maakt geen verbinding
+
+**Verbinding testen** op een RTE-runner (**Verbindingen > Runners**) mislukt met:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Waarom dit gebeurt**
+
+Een RTE in een socketmodus praat met de app over één WebSocket: uitgaand belt hij de app aan, inkomend belt de app hem aan (zie
+[Modi](rte/modes.html)). De logs van de app en van de RTE zeggen waarom de socket niet open is:
+
+| Melding | Waar | Wat het betekent |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | De RTE (inkomend) | Het token van de RTE-referentie van de runner is niet het `RTE_TOKEN` van de RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | De app (inkomend) | Hetzelfde, gezien vanaf de app |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | De app, en de RTE die wordt geweigerd (`401`) | De RTE meldt zich aan met een ander token dan het token dat de app voor zijn runner bewaart |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | De RTE (uitgaand) | Hij heeft gevraagd om aan te sluiten en wacht op goedkeuring |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | De RTE (inkomend, met `APP_URL`) | Hetzelfde, voor een inkomende RTE |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | De app, en de RTE die wordt geweigerd (`409`) | De config seed declareert de runner zonder `rte_mode`, dus in databasemodus, en de seed bepaalt zijn modus. Een inkomende RTE krijgt `rte_mode: inbound` en `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | De RTE | Een inkomende RTE die zichzelf registreert, heeft het adres nodig waarop de app hem aanbelt |
+| `Runner '<name>': dialing <address>: <reason>` | De app, op niveau `debug` | De app kan de socket niet openen, bijvoorbeeld omdat het certificaat van de RTE niet het certificaat is dat voor zijn runner is gepind |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | De RTE | Hij draait in databasemodus, en opent helemaal geen socket |
+
+**Hoe je het oplost**
+
+* **Een geweigerd token** : geef de RTE het token van de RTE-referentie van zijn runner (**Verbindingen > Inloggegevens**), of andersom
+* **Wacht op goedkeuring** : keur hem goed onder **Verbindingen > Runners**, nadat je hebt gecontroleerd dat de vingerafdruk die daar staat dezelfde is als die in zijn
+  log (zie [Een RTE goedkeuren](runners/registration.html#approving-an-rte))
+* **Beheerd door de config seed in databasemodus** : zet `rte_mode` op de runner in de seed, met een RTE-referentie (voor inkomend met het
+  adres ervan), en herstart daarna de RTE
+* **Inkomend zonder `RTE_URL`** : zet `RTE_URL` op het adres waarop de app de RTE bereikt, of laat `APP_URL` weg en declareer de
+  runner in de seed of onder **Verbindingen > Runners**
+* **Een certificaat dat niet het gepinde is** : een inkomende RTE over HTTPS stuurt zijn certificaat mee als hij zich registreert, en de app belt
+  hem alleen aan met dat certificaat. Na een nieuw certificaat stuurt de RTE het opnieuw als hij zich registreert; als de CA-bundel van de referentie met de hand
+  is ingesteld, houdt de app die en logt hij
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **De waarschuwing [DEPRECATED]** : zet `RTE_MODE` op de RTE, verwijder `DB_*` uit zijn omgeving, en zet zijn runner op die modus (zie
+  [Modi](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Met startvalidatie op `enforce` wordt een start geweigerd met `422` en:
+
+```
+The form data is not valid
+```
+
+**Waarom dit gebeurt**
+
+De server heeft de veldwaarden gecontroleerd tegen de regels van het formulier en ontbrekende of ongeldige velden gevonden; het antwoord somt
+ze op onder `details`. Een start zonder `rawFormData` wordt ook geweigerd. Een formulier dat nog niet kan worden gecontroleerd, zoals een wizard,
+wordt geweigerd met `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Hoe je het oplost**
+
+Corrigeer de velden die de details noemen, of de regels van het formulier als die te streng zijn. Draai eerst onder `log`: dat logt
+`Launch validation would refuse form '<name>' ...` zonder iets te weigeren. Zie
+[Wat enforce doet](launch-validation/log-and-enforce.html#what-enforce-does) en
+[Uitrollen](launch-validation/rolling-it-out.html).
+
+---
+
+## Een clone of pull van een repository is mislukt
+
+Een repository toont een mislukte status, en de uitvoer ervan bevat de fout van git, of het log toont
+`Background clone of '<name>' failed : <reason>`.
+
+**Waarom dit gebeurt**
+
+Git kon de remote niet bereiken of zich er niet bij authenticeren. Voor SSH-URL's (`git@host:path`) moet de remote de publieke
+sleutel van AnsibleForms accepteren; voor HTTPS moeten de gebruikersnaam en het token geldig zijn. Een pull wordt ook geweigerd als de working tree
+wijzigingen heeft, met
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Hoe je het oplost**
+
+Kopieer voor SSH de publieke sleutel uit het tabblad **Sleutel** van **Verbindingen > SSH** en voeg hem toe als deploy key, of aan een gebruiker met
+toegang tot de repository. AnsibleForms voegt de remote host bij een clone toe aan de known hosts; voor andere hosts gebruik je het
+tabblad **Known hosts** van dezelfde pagina. Vernieuw voor
+HTTPS het token. Zie [Git-repositories](gui/designer-and-git.html#git-repositories) en
+[Over repositories](faq.html#about-repositories).
+
+---
+
+## De formulierenrepository is nog niet gecloned
+
+Formulieren opslaan in de designer mislukt met:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Waarom dit gebeurt**
+
+Een repository waarbij **Gebruiken voor formulieren** aan staat, heeft nog geen working tree, omdat de clone niet heeft gedraaid of is mislukt.
+
+**Hoe je het oplost**
+
+Clone de repository vanuit de instellingen van de repositories. Als de clone mislukt, zie
+[Een clone of pull van een repository is mislukt](#a-repository-clone-or-pull-failed).
+
+---
+
+## Een back-up is mislukt
+
+Een back-up mislukt, en er wordt niets aan de lijst met back-ups toegevoegd. De reden is een van:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Waarom dit gebeurt**
+
+Het dumpcommando, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), is niet geïnstalleerd, kon geen verbinding
+maken, of leverde een leeg bestand op. Een grote database kan ook langer duren dan
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), standaard één uur.
+Een mislukte back-up laat geen map achter; het log zegt `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Hoe je het oplost**
+
+Installeer de clienttools van MySQL of MariaDB, of zet `MYSQLDUMP_COMMAND` (en `MYSQL_COMMAND` voor herstel) op een commando
+dat op deze host en tegen de versie van je server werkt. Verhoog `BACKUP_COMMAND_TIMEOUT_SECONDS` voor een grote database.
+Zie [Back-ups](gui/administration.html#backups).
diff --git a/i18n/nl/_security_assessment/security-assessment/advisories.md b/i18n/nl/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..c680cb4
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Beveiligingsadvisories
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Beveiligingsadvisories
+{: .no_toc }
+
+Elke gepubliceerde kwetsbaarheid, de ernst ervan en de oplossing
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gepubliceerde advisories
+
+Bij elke build van deze site gelezen uit het [tabblad Security van de repository](https://github.com/ansibleforms/ansibleforms/security/advisories):
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Advisory</th>
+      <th>Ernst</th>
+      <th>Zwakte</th>
+      <th>Getroffen</th>
+      <th>Opgelost in</th>
+      <th>Gepubliceerd</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Er is nog geen advisory gepubliceerd.
+{% endif %}
+
+Elke advisory op GitHub geeft de details: de impact, de voorwaarden, de CVSS-vector en de oplossing.
+
+---
+
+## Wat dit betekent voor je versie
+
+Een advisory noemt de versies die getroffen zijn en de eerste versie waarin het is opgelost. De oplossing komt in de ondersteunde releases,
+[7.x en 6.5.x](development.html#supported-versions), en oudere releases krijgen geen patch: upgraden is de oplossing.
+
+Vergelijk de versie van een instantie (**Over** in het helpmenu, of `GET /api/v2/version`) met **Getroffen**.
+
+---
+
+## Op de hoogte blijven van nieuwe advisories
+
+GitHub waarschuwt wie de repository volgt wanneer er een advisory wordt gepubliceerd:
+
+* Kies op [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) **Watch > Custom > Security alerts**.
+* De [changelog](../changelog.html) noemt elke beveiligingsoplossing onder de release waarin die zit.
diff --git a/i18n/nl/_security_assessment/security-assessment/development.md b/i18n/nl/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..01615cd
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Veilige ontwikkeling
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Veilige ontwikkeling
+{: .no_toc }
+
+Hoe wijzigingen worden gecontroleerd en uitgebracht, en wat wordt ondersteund
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De broncode
+
+AnsibleForms is open source, dus alles op deze pagina kun je in de repository zelf controleren:
+
+* De code, de geschiedenis en de build-pipelines zijn openbaar op [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* De [licentie](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) is GPL-3.0.
+* De [changelog](../changelog.html) noemt elke wijziging van elke release, inclusief beveiligingsoplossingen.
+
+---
+
+## Hoe een wijziging wordt gemerged
+
+Elke wijziging komt via een pull request in `main`, onder een ruleset die niemand kan omzeilen:
+
+| Regel | Wat het betekent |
+|---|---|
+| Pull request verplicht | Er wordt niets rechtstreeks naar `main` gepusht |
+| Verplichte checks | De pull request wordt pas gemerged als elke check hieronder slaagt |
+| Geen force push, geen verwijdering | De geschiedenis van `main` kan niet worden herschreven of verwijderd |
+| Lineaire geschiedenis | Elke pull request wordt één commit, zodat elke wijziging afzonderlijk te traceren en terug te draaien is |
+
+De checks waaraan een pull request moet voldoen:
+
+| Check | Wat het doet |
+|---|---|
+| Client, Server | De unittests van de webinterface en van de server |
+| CodeQL | De statische analyse van GitHub op de JavaScript- en TypeScript-code, op injectie, cross-site scripting en andere zwakheden |
+| Public schema is up to date | Het databaseschema dat de code verwacht, komt overeen met het schema dat wordt meegeleverd |
+| Title, Branch | De pull request volgt de naamgevingsregels, zodat de changelog klopt |
+
+Nog twee draaien op elke pull request en rapporteren daarover:
+
+* **Database** test de server op MySQL en MariaDB, en **Browser** bedient de interface in een browser.
+* **Dependency review** blokkeert een nieuwe afhankelijkheid met een bekende kwetsbaarheid van hoge of kritieke ernst.
+
+---
+
+## Codeanalyse en afhankelijkheden
+
+De code en waarvan die afhangt, worden na het mergen opnieuw gecontroleerd:
+
+* **CodeQL** analyseert ook elke push naar `main` en naar de releasebranches, en elke week de hele codebase:
+  een nieuwe CodeQL-regel controleert dan ook de code die eerder is gemerged.
+* **Dependabot** opent een pull request voor elke nieuwe versie van een afhankelijkheid: de npm-pakketten van de server en de
+  interface, de Python-pakketten van de runtime-omgeving en de GitHub Actions van de pipelines elke week, en
+  de basisimages van de containers elke dag.
+* De basisimages zijn vastgepind op digest (`node:26-trixie-slim@sha256:...`), zodat een build precies de gereviewde image gebruikt.
+  Dependabot verplaatst de digest wanneer de image upstream opnieuw wordt gebouwd.
+
+---
+
+## Releases en images
+
+Een release wordt uitsluitend door GitHub Actions gebouwd en gepubliceerd, nooit vanaf de machine van een ontwikkelaar:
+
+* Een release wordt gemaakt vanaf `main` (of `release/6.x`), met een changelog die uit de pull requests wordt opgebouwd.
+* De images worden gebouwd door de [Publish-workflow](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  en gepusht naar de GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, met de images van de runtime-omgeving
+  ernaast. De workflow en zijn logs zijn openbaar, dus iedereen kan zien wat er in een image is gegaan.
+* De images van de applicatie en de runtime-omgeving draaien als de niet-geprivilegieerde gebruiker `node` (uid 1000), nooit als root.
+
+---
+
+## Ondersteunde versies
+
+Beveiligingsoplossingen komen in de nieuwste release van elke ondersteunde lijn:
+
+| Versie | Krijgt beveiligingsoplossingen |
+|---|---|
+| 7.x | Ja |
+| 6.5.x | Ja |
+| Ouder dan 6.5 | Nee: upgraden is de oplossing |
+
+De [upgradehandleiding](../upgrading/) behandelt de overstap naar een nieuwere release, en [Upgraden naar v7](../upgrade-7.html) de overstap vanaf 6.5.
diff --git a/i18n/nl/_security_assessment/security-assessment/faq.md b/i18n/nl/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..9fa3eef
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Veelgestelde vragen bij een beoordeling
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# Veelgestelde vragen bij een beoordeling
+{: .no_toc }
+
+Korte antwoorden op de vragen die beveiligingsvragenlijsten het vaakst stellen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gegevens en hosting
+
+Waar de gegevens staan, en wie erbij kan:
+
+| Vraag | Antwoord |
+|---|---|
+| Waar worden onze gegevens opgeslagen? | In de MySQL- of MariaDB-database die jij draait, en in de persistente map van je instantie. AnsibleForms is self-hosted, zonder clouddienst erachter. |
+| Stuurt het gegevens naar de makers? | Nee. Er is geen telemetrie, geen gebruiksrapportage en geen updatecontrole. |
+| Waarmee maakt het verbinding? | Alleen met de systemen die een beheerder configureert: zie [Uitgaande verbindingen](measures.html#outbound-connections). |
+| Gebruikt het AI of stuurt het gegevens naar een modelprovider? | Alleen als de [chatassistent](../chat/) aanstaat, en die staat standaard uit. Dan stuurt het formulierdefinities en de ingevulde waarden naar de provider die je configureert. |
+| Kan het draaien zonder internettoegang? | Ja. De applicatie heeft geen internettoegang nodig; de playbooks hebben nodig wat hun taken bereiken. |
+
+---
+
+## Versleuteling
+
+Wat er versleuteld is, en met welke sleutels:
+
+| Vraag | Antwoord |
+|---|---|
+| Zijn gegevens versleuteld tijdens transport? | Met [HTTPS](../security/https.html), aangeboden door de applicatie of door je reverse proxy, en `wss://` tussen de applicatie en haar runtime-omgevingen. |
+| Zijn gegevens versleuteld in rust? | Elk opgeslagen geheim wordt door de applicatie versleuteld met AES-256. Jobs en hun uitvoer worden opgeslagen zoals ze zijn: gebruik de eigen versleuteling in rust van de database. Zie [Opgeslagen geheimen](measures.html#stored-secrets). |
+| Wie beheert de sleutels? | Jij: het [`ENCRYPTION_SECRET`](../security/secrets.html) stel je zelf in, het blijft buiten back-ups en kan worden geroteerd. |
+| Kunnen geheimen in onze eigen vault blijven? | Ja: [HashiCorp Vault en CyberArk](../secret-stores/) worden gelezen wanneer een job ze nodig heeft. |
+
+---
+
+## Toegang en verantwoording
+
+Wie kan aanmelden, wat ze kunnen doen en wat er wordt vastgelegd:
+
+| Vraag | Antwoord |
+|---|---|
+| Ondersteunt het single sign-on? | Ja: LDAP / Active Directory, OpenID Connect en Entra ID. Zie [Authenticatie](../authentication/). |
+| Ondersteunt het meervoudige authenticatie? | Via single sign-on: de MFA van je identiteitsprovider is van toepassing. Lokale accounts hebben geen eigen MFA. |
+| Hoe worden rechten beheerd? | Met rollen die aan groepen zijn gekoppeld, bij elk verzoek door de server gecontroleerd. Zie [Rechten](measures.html#permissions). |
+| Is er een auditlogboek? | Ja: elke wijziging en elke geweigerde poging, standaard 365 dagen bewaard en door te sturen naar syslog. Zie [Audittrail](measures.html#audit-trail). |
+| Is er een standaardwachtwoord? | Het eerste adminaccount heeft een openbaar standaardwachtwoord, dat bij de eerste aanmelding moet worden gewijzigd. Zie [Het adminaccount](../security/hardening.html#the-admin-account). |
+
+---
+
+## Kwetsbaarheden en updates
+
+Hoe problemen worden gevonden, opgelost en aangekondigd:
+
+| Vraag | Antwoord |
+|---|---|
+| Zijn er kwetsbaarheden gevonden? | Ja. Elke gepubliceerde staat in [Beveiligingsadvisories](advisories.html), met de versie waarin die is opgelost. |
+| Hoe melden we er een? | Vertrouwelijk, via GitHub: zie [Een kwetsbaarheid melden](reporting.html). |
+| Hoe wordt de code gecontroleerd? | Statische analyse met CodeQL en dependency review op elke pull request, geautomatiseerde tests en updates via Dependabot. Zie [Veilige ontwikkeling](development.html). |
+| Welke versies krijgen beveiligingsoplossingen? | 7.x en 6.5.x. Zie [Ondersteunde versies](development.html#supported-versions). |
+| Hoe horen we van een nieuwe advisory? | Volg de beveiligingsmeldingen van de repository op GitHub. Zie [Op de hoogte blijven van nieuwe advisories](advisories.html#being-told-of-new-advisories). |
+| Is er een penetratietest uitgevoerd? | Er is geen rapport van een penetratietest door derden gepubliceerd. De code is openbaar, dus je eigen team of tester kan die beoordelen, en bevindingen worden gemeld zoals hierboven. |
+
+---
+
+## Images en toeleveringsketen
+
+Waar de images vandaan komen, en hoe je ze controleert:
+
+| Vraag | Antwoord |
+|---|---|
+| Waar worden de images gepubliceerd? | Op de GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, gebouwd door openbare GitHub Actions-workflows. Zie [Releases en images](development.html#releases-and-images). |
+| Draaien de containers als root? | Nee: als de niet-geprivilegieerde gebruiker `node`. |
+| Zijn de images ondertekend? | Nog niet. Haal ze op via digest (`@sha256:...`) om zeker te weten dat je de image draait die je hebt gereviewd. |
+| Is er een SBOM? | Er wordt nog geen SBOM met de images gepubliceerd. Een scanner zoals Trivy of Syft maakt er een op basis van de image. |
+| Worden de images gescand op kwetsbaarheden? | Niet in de releasepipeline. Hun basisimages zijn vastgepind op digest en worden door Dependabot actueel gehouden; scan de images in je eigen registry om je eigen beleid toe te passen. |
+| Onder welke licentie valt het? | GPL-3.0, open source, zonder garantie. |
diff --git a/i18n/nl/_security_assessment/security-assessment/index.md b/i18n/nl/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..3777b21
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Overzicht
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Beveiligingsbeoordeling
+{: .no_toc }
+
+Voor beveiligingsreviews: maatregelen, ontwikkeling en advisories
+{: .fs-6 .fw-300 }
+
+---
+
+## In het kort
+
+AnsibleForms voert playbooks uit en beheert hun inloggegevens, dus het maakt deel uit van je vertrouwensketen:
+
+* Het is **self-hosted**: het draait op je eigen infrastructuur, bewaart zijn gegevens in je eigen database en stuurt niets naar de makers.
+* Het is **open source** (GPL-3.0): de code, de pipelines en elke advisory zijn openbaar.
+* Elk opgeslagen geheim is **versleuteld**, elke wijziging wordt **geaudit** en **rollen** worden bij elk verzoek gecontroleerd.
+* Kwetsbaarheden worden **vertrouwelijk gemeld**, in elke ondersteunde release opgelost en **gepubliceerd**.
+
+---
+
+## In deze sectie
+
+De pagina's beantwoorden de vragen van een beveiligingsreview, van het ontwerp tot de lijst met CVE's:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Beveiligingsmaatregelen](measures.html) | Aanmelden, rechten, opgeslagen geheimen, de audittrail, de browser, de server, verbindingen en containers |
+| [Veilige ontwikkeling](development.html) | Hoe een wijziging wordt gereviewd en getest, analyse van code en afhankelijkheden, hoe images worden gebouwd, ondersteunde versies |
+| [Een kwetsbaarheid melden](reporting.html) | Hoe je een probleem vertrouwelijk meldt, en wat er daarna gebeurt |
+| [Beveiligingsadvisories](advisories.html) | Elke gepubliceerde kwetsbaarheid, met CVE, ernst en de versie met de oplossing |
+| [Veelgestelde vragen bij een beoordeling](faq.html) | Korte antwoorden op de vragen die beveiligingsvragenlijsten het vaakst stellen |
+
+Wil je een instantie beveiligen in plaats van beoordelen, zie dan [Beveiliging](../security/) in de handleiding voor beheerders.
diff --git a/i18n/nl/_security_assessment/security-assessment/measures.md b/i18n/nl/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..b508f58
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Beveiligingsmaatregelen
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Beveiligingsmaatregelen
+{: .no_toc }
+
+Hoe aanmelden, rechten, geheimen en verbindingen worden beschermd
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Waar het draait
+
+AnsibleForms is self-hosted, op je eigen infrastructuur, met zijn gegevens in een database die jij draait.
+
+* Er is geen clouddienst of licentieserver van AnsibleForms, en geen telemetrie of updatecontrole.
+* De interface wordt door de applicatie zelf aangeboden en laadt niets van een andere site.
+* De applicatie maakt alleen verbinding met de systemen die een beheerder configureert, opgesomd in [Uitgaande verbindingen](#outbound-connections).
+
+De onderdelen en wat elk ervan bevat:
+
+| Onderdeel | Wat het doet | Wat het bevat |
+|---|---|---|
+| Applicatie | De webinterface, de REST API, de planner | Geen eigen gegevens: alles staat in de database |
+| MySQL of MariaDB | De database van de applicatie | Gebruikers, groepen, inloggegevens (versleuteld), jobs met hun extravars en uitvoer, het auditlogboek |
+| Runtime-omgeving (RTE) | Voert de playbooks uit, in een eigen container | De bestanden van de jobs die ze uitvoert, en de geheimen van een job alleen zolang die job draait |
+| Persistente map | De configuratie, formulieren, playbooks en uploads | De bestanden die de formulieren en playbooks gebruiken |
+
+Zie [Hoe het werkt](../how-it-works.html) voor het volledige plaatje, en [RTE](../rte/) voor de runtime-omgeving.
+
+---
+
+## Aanmelden
+
+Elke pagina en API-aanroep die gegevens leest of wijzigt, vereist een aangemelde gebruiker. De paar endpoints die zonder aanmelding openstaan, dienen
+het aanmelden zelf, de versie, de naam en het logo van de instantie, de API-documentatie en de database-installatie bij een eerste start,
+die [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` afsluit:
+
+| Methode | Hoe het werkt |
+|---|---|
+| Lokale accounts | Wachtwoorden gehasht met bcrypt, een [minimale lengte](../security/hardening.html#sign-in-limits-and-passwords), en het openbare standaardwachtwoord van admin moet bij de eerste aanmelding worden gewijzigd |
+| LDAP / Active Directory | De directory controleert het wachtwoord, en de groepen ervan worden aan rollen gekoppeld. Zie [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Single sign-on via je identiteitsprovider, die ook zijn eigen meervoudige authenticatie meebrengt. Zie [Authenticatie](../authentication/) |
+
+* Mislukte aanmeldingen [vergrendelen het account](../security/hardening.html#sign-in-limits-and-passwords), en het aanmelden is aan een snelheidslimiet gebonden.
+* Een aanmelding levert een ondertekend toegangstoken op dat 30 minuten geldig is, en een vernieuwingstoken dat 24 uur geldig is.
+* Tokens kunnen worden beëindigd voordat ze verlopen: afmelden, een wachtwoordwijziging, een geblokkeerde gebruiker en een ingetrokken API-token beëindigen ze
+  meteen op elk knooppunt, zie [Tokens](../security/secrets.html#tokens).
+* AnsibleForms heeft geen eigen meervoudige authenticatie: gebruik single sign-on waar die vereist is.
+
+---
+
+## Rechten
+
+Wat een gebruiker mag doen, volgt uit de rollen van zijn groepen, bij elk verzoek door de server gecontroleerd:
+
+* Rollen worden gedefinieerd in [config.yaml](../config/roles.html): welke formulieren een gebruiker ziet en welke opties hij heeft,
+  zoals de ontwerper, de instellingenpagina's of de jobs van andere gebruikers.
+* De server controleert elke start tegen de regels van het formulier (de velden, hun waarden en de toegang van de gebruiker), ook
+  starts via de REST API, zie [Launch-validatie](../launch-validation/).
+* De adminrol voert bewust elk playbook uit. Andere rollen krijgen alleen wat is toegekend: een gebruiker met meerdere rollen krijgt een
+  optie alleen als geen van die rollen haar weigert, dus één beperkende rol is genoeg om haar te onthouden.
+
+---
+
+## Opgeslagen geheimen
+
+Wachtwoorden, tokens en sleutels worden versleuteld voordat ze in de database worden geschreven:
+
+* Elk opgeslagen geheim, inloggegevens, het bind-wachtwoord van LDAP, runnertokens, client secrets voor single sign-on, webhook-adressen
+  en API-sleutels, wordt versleuteld met AES-256 en een willekeurige initialisatievector per waarde, onder het
+  [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) dat je instelt.
+* Geen enkele API-aanroep of instellingenpagina toont een opgeslagen geheim, en back-ups laten de hoofdgeheimen weg.
+* Geheimen kunnen in je vault blijven: [HashiCorp Vault en CyberArk](../secret-stores/) worden gelezen wanneer een job ze nodig heeft.
+* De geheimen van een job komen bij de runtime-omgeving aan verzegeld met AES-256-GCM, onder een sleutel die van zijn token is afgeleid.
+* Extravars waarvan de naam op een geheim lijkt, worden in de jobweergave gemaskeerd, en wachtwoordvelden altijd, zie [Jobgegevens](../security/hardening.html#job-data).
+
+De rest van de database, jobs, hun extravars en hun uitvoer, wordt opgeslagen zoals het is: bescherm die met de eigen versleuteling in rust
+en het toegangsbeheer van de database, zie [De database](../security/hardening.html#the-database).
+
+---
+
+## Audittrail
+
+Elke wijziging, en elke poging die wordt geweigerd, wordt vastgelegd:
+
+* Elke aanmaak, wijziging en verwijdering, via de interface of de API, wordt in het auditlogboek geschreven met de gebruiker, zijn
+  adres, de actie, het object en het resultaat. Weigeringen en aanmeldingen worden ook vastgelegd, mislukte inbegrepen.
+* Waarden die op geheimen lijken, worden onleesbaar gemaakt voordat ze worden geschreven.
+* Het logboek wordt standaard 365 dagen bewaard, en kan naar syslog worden gekopieerd via UDP, TCP of TLS.
+
+---
+
+## In de browser
+
+De interface is beschermd tegen code die in een pagina wordt geïnjecteerd:
+
+* Een [Content-Security-Policy](../security/hardening.html#the-content-security-policy) staat alleen de eigen scripts en frames van de applicatie toe.
+* Elk antwoord bevat beschermende headers: nosniff, framebescherming, en HSTS via HTTPS.
+* De HTML van formulieren, helpteksten en chatantwoorden wordt opgeschoond, en joboutput wordt ge-escaped.
+
+---
+
+## Op de server
+
+De code die gebruikersinvoer verwerkt, vermijdt de klassieke injecties:
+
+* Databasequery's geven hun waarden door als parameters, nooit als tekst die in de query is geplakt.
+* Commando's, git inbegrepen, draaien vanuit een argumentenlijst, nooit via een shell, dus shelltekens doen niets.
+* Serverexpressies gaan door een [expressie-sanitizer](../security/hardening.html#expressions-and-outbound-calls), en hun REST-aanroepen door een hostfilter.
+* De [MCP-server](../mcp/), de [chatassistent](../chat/) en het metrics-endpoint staan uit tot je ze aanzet.
+
+---
+
+## Verbindingen
+
+Verkeer van en naar AnsibleForms kan van begin tot eind versleuteld worden:
+
+* De applicatie biedt zelf [HTTPS](../security/https.html) aan, of staat achter je reverse proxy.
+* Een runtime-omgeving praat met de applicatie via een WebSocket, `wss://` bij een HTTPS-adres, en de applicatie
+  pint het certificaat van een inkomende vast, zie [RTE-modi](../rte/modes.html).
+* LDAP, single sign-on, de runners, git, de secret stores en de REST-aanroepen van expressies controleren het certificaat van de
+  server die ze bereiken, tenzij een beheerder die controle uitzet voor een server met een zelfondertekend certificaat.
+
+### Uitgaande verbindingen
+
+AnsibleForms maakt alleen verbinding met wat een beheerder configureert:
+
+| Verbinding | Wanneer |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (Microsoft-aanmelding en Graph) | Wanneer die aanmeldmethode is ingesteld |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Wanneer een formulier op die runner draait |
+| Git-servers | Wanneer een repository is ingesteld |
+| Mailserver, Slack, Teams, Telegram, webhooks | Wanneer een meldingskanaal is ingesteld |
+| HashiCorp Vault, CyberArk | Wanneer een secret store is ingesteld |
+| Een modelprovider (Anthropic, OpenAI en andere) | Alleen als de [chatassistent](../chat/) aanstaat, en die staat standaard uit |
+| Hosts en API's die in formulieren worden genoemd | Wanneer de expressies van een formulier of een playbook ze aanroepen |
+| Syslog-servers | Wanneer het doorsturen van audit of logs is ingesteld |
+
+---
+
+## De containers
+
+De images zijn gebouwd om met zo weinig mogelijk rechten te draaien:
+
+* De applicatie en de runtime-omgeving draaien als de niet-geprivilegieerde gebruiker `node`, niet als root.
+* Ze zijn gebouwd op slanke Debian-images die op digest zijn vastgepind, zie [Veilige ontwikkeling](development.html#code-analysis-and-dependencies).
+* De applicatie luistert op één poort, 8000.
+
+Volg [Hardening](../security/hardening.html) voor de stappen om een nieuwe instantie te beveiligen.
diff --git a/i18n/nl/_security_assessment/security-assessment/reporting.md b/i18n/nl/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..3300858
--- /dev/null
+++ b/i18n/nl/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Een kwetsbaarheid melden
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Een kwetsbaarheid melden
+{: .no_toc }
+
+Hoe je een beveiligingsprobleem vertrouwelijk meldt, en wat er daarna gebeurt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Meld het vertrouwelijk
+
+AnsibleForms bewaart inloggegevens en vault-tokens, dus meld een beveiligingsprobleem nooit in een openbaar issue:
+
+1. Open **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: een vertrouwelijke advisory die alleen de maintainers zien.
+2. Is die pagina voor jou niet beschikbaar, open dan een gewoon issue waarin je alleen zegt dat je een beveiligingsmelding hebt en vraagt
+   om een vertrouwelijk kanaal: geen details, geen reproductie, geen versienummers. Een maintainer opent een vertrouwelijke advisory en
+   nodigt je daarvoor uit.
+
+Het volledige beleid staat in [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) van de repository.
+
+---
+
+## Wat je meestuurt
+
+Hoe meer hiervan een melding bevat, hoe sneller het wordt opgelost:
+
+* Wat een aanvaller wint: de gegevens van een andere gebruiker, een playbook dat hij niet mag uitvoeren, de host, of adminrechten.
+* De versie, en hoe die is uitgerold: Docker, Kubernetes, of native geïnstalleerd.
+* Een reproductie, of het verzoek dat het probleem veroorzaakt.
+* Of er een aangemelde gebruiker voor nodig is, en met welke [rolopties](../config/roles.html).
+
+---
+
+## Wat er daarna gebeurt
+
+Een melding loopt via dezelfde vertrouwelijke advisory, van het eerste bericht tot de publicatie:
+
+| Stap | Wat je krijgt |
+|---|---|
+| Ontvangstbevestiging | Bevestiging dat de melding is aangekomen, en of het probleem te reproduceren is |
+| Geaccepteerd | Een oplossing in de volgende release van elke [ondersteunde versie](development.html#supported-versions), en een gepubliceerde advisory die jou vermeldt, tenzij je liever niet genoemd wordt |
+| Afgewezen | De redenering, meestal dat het gedrag een recht vereist dat de melder al had |
+
+Zodra de oplossing is uitgebracht, wordt de advisory gepubliceerd en verschijnt die in [Beveiligingsadvisories](advisories.html).
+
+---
+
+## Reikwijdte
+
+Het beleid trekt de grens waar het rollenmodel die trekt:
+
+| Binnen de reikwijdte | Buiten de reikwijdte |
+|---|---|
+| Alles wat een aangemelde gebruiker kan bereiken buiten wat zijn rol toestaat | Bevindingen waarvoor het adminaccount al gecompromitteerd moet zijn: een admin die elk playbook kan uitvoeren, is het product |
+| Alles wat bereikbaar is zonder aan te melden | Scannerrapporten zonder aangetoonde impact |
+| Opgeslagen inloggegevens die leesbaar worden, of in een log terechtkomen | |
+| Injectie in de shell, de database of de browser | |
diff --git a/i18n/nl/_use/designer/index.md b/i18n/nl/_use/designer/index.md
new file mode 100644
index 0000000..014507a
--- /dev/null
+++ b/i18n/nl/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Ontwerper
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Ontwerper
+{: .no_toc }
+
+Bewerk formulieren, playbooks, inventarissen en workflows in de browser
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor formulierauteurs: de secties van de ontwerper, en wat elk van hun tabbladen toont.
+
+De ontwerper vereist de [roloptie](../config/roles.html#role-options) `showDesigner`. Hij bewerkt één item tegelijk, een
+formulier, een playbook of een workflowbestand, met zijn secties in het linkermenu. Elk soort bestand vereist ook een eigen optie, die allemaal
+standaard aanstaan: `allowPlaybookDesign` voor de **Playbooks**, `allowWorkflowDesign` voor de **Workflows**,
+`allowInventoryDesign` voor de **Inventarissen** en `allowVarsFileDesign` voor de **Variabelenbestanden**. Zonder die optie is de sectie
+alleen-lezen en weigert de server de bestanden op te slaan, aan te maken, te verwijderen of te pushen; formulieren en workflows kunnen ze nog wel kiezen. De
+**Formulieren**, **Categorieën** en **Constanten** vereisen op dezelfde manier `allowFormDesign`: zonder die optie zijn ze alleen-lezen, en weigert de server
+ze op te slaan, te pullen of te pushen. Er bewerkt maar één persoon tegelijk: zie [De vergrendeling van de ontwerper](lock.html).
+
+---
+
+## De secties
+
+Elke sectie bewerkt één soort bestand, lokaal bewaard of in een [repository](../repositories/):
+
+| Sectie | Wat ze bewerkt |
+|---|---|
+| **Formulieren** | De formulierbestanden |
+| **Categorieën** | De categorieën van `config.yaml` |
+| **Constanten** | De constanten van `config.yaml` |
+| **Variabelenbestanden** | De variabelenbestanden die formulieren laden |
+| **Playbooks** | De playbooks die formulieren en workflows uitvoeren |
+| **Inventarissen** | De inventarissen: `inventory.yaml`, `group_vars` en `host_vars` |
+| **Workflows** | De [workflow](../workflows/)bestanden |
+
+De secties met bestanden tonen die in een bestandsverkenner en openen het eerste; een sectie die nog geen bestanden heeft, zegt dat. De
+sectie **Formulieren** en elke bestandssectie hebben een knop **Nieuw bestand** als eerste in hun werkbalk: in Inventarissen maakt die een nieuwe
+inventaris, in Workflows een nieuwe, lege workflow. Het vergrootglas van de verkenner opent een vak dat de bestanden op naam filtert.
+
+Het zoekvak op de titelregel vindt een tekst in de YAML die open is: het markeert elke plek waar die voorkomt. Het werkt op het
+tabblad **YAML**, zodra de vergrendeling van de ontwerper van jou is.
+
+---
+
+## De tabbladen
+
+Elke sectie heeft dezelfde drie tabbladen, allemaal op dezelfde YAML: een wijziging in het ene is te zien in de andere, en **Opslaan** slaat haar op.
+
+- **YAML** is het bestand zoals het geschreven is.
+- **Visueel** bewerkt het met velden. Alleen de sleutels die een wijziging raakt, veranderen, dus commentaar en de rest blijven zoals ze geschreven zijn.
+- **Voorbeeld** toont wat het doet, en bewerkt niets.
+
+Wat de tabbladen Visueel en Voorbeeld tonen, per sectie:
+
+| Sectie | Visueel | Voorbeeld |
+|---|---|---|
+| **Formulieren** | De instellingen en de velden van het formulier, met lijsten van de playbooks, inventarissen en workflows van de ontwerper | Het formulier zoals het nu is, niet-opgeslagen wijzigingen inbegrepen; verzenden voert niets uit |
+| **Categorieën** | De categorieën als tabel, bewerkbaar | Het menu van de pagina Formulieren, daaruit opgebouwd |
+| **Constanten** | De constanten als overzicht, bewerkbaar (een sleutel verplaats je met de pijltjestoetsen) | Elke constante met haar verwijzing, `$(NAME)`, om te kopiëren, en de formulieren die haar gebruiken |
+| **Variabelenbestanden** | De variabelen, bewerkbaar | Elke variabele met haar verwijzing in een playbook, {% raw %}`{{ name }}`{% endraw %}, om te kopiëren, en de formulieren die het bestand laden |
+| **Playbooks** | De plays: van elke play de naam, hosts, **Become**, **Facts verzamelen** en rollen, en de taken, elk met module en argumenten | Het overzicht van het playbook: de plays, met hun hosts, rollen en taken, en de playbooks die het importeert |
+| **Inventarissen** | De groepen, hun subgroepen, hun hosts, en de variabelen die elk instelt | De inventaris als boom, met zijn `group_vars` en `host_vars` |
+| **Workflows** | De graaf van de workflow, om [hem te bewerken](../workflows/designer.html) | Een [proefrun](../workflows/designer.html#trying-it-out): klik op een knooppunt om het te laten mislukken |
+
+Kan de YAML niet worden gelezen, dan zeggen de tabbladen Visueel en Voorbeeld waarom, met **Tonen in YAML** om de YAML op de regel te openen.
diff --git a/i18n/nl/_use/designer/lock.md b/i18n/nl/_use/designer/lock.md
new file mode 100644
index 0000000..4fc2305
--- /dev/null
+++ b/i18n/nl/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: De vergrendeling van de ontwerper
+parent: Ontwerper
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# De vergrendeling van de ontwerper
+{: .no_toc }
+
+Er bewerkt maar één persoon tegelijk
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De vergrendeling nemen
+
+De ontwerper staat uit tot je hem aanzet, met de schakelaar rechtsboven in de ontwerper. Door hem aan te zetten neem je de
+vergrendeling: vanaf dat moment ben jij de enige die kan opslaan, tot je hem weer uitzet.
+
+Zonder de vergrendeling toont de ontwerper **Designer is niet actief**, en kan er niets worden bewerkt.
+
+Opslagacties overlappen nooit: vanaf 7.3.0 wordt, terwijl een opslag, een push of een laadactie loopt, een tweede **Opslaan** (een dubbelklik, of Ctrl+S ingedrukt gehouden)
+genegeerd, zodat die geen tweede back-up of tweede commit kan schrijven die met de eerste concurreert.
+
+---
+
+## Als iemand anders hem heeft
+
+Zolang een andere gebruiker de vergrendeling heeft, toont de ontwerper **De designer wordt gebruikt door** die gebruiker, en verder niets: geen secties,
+geen bestanden.
+
+De schakelaar staat aan maar is grijs, met **Vergrendeld door** en de naam van de gebruiker ernaast. Je kunt de vergrendeling nemen zodra die gebruiker
+de ontwerper uitzet. Elke geopende ontwerper ziet het meteen wanneer de vergrendeling wordt genomen of vrijgegeven, zonder herladen.
+
+Zetten twee gebruikers de ontwerper op hetzelfde moment aan, dan krijgt een van hen de vergrendeling. Vanaf 7.3.0 ziet de ander wie hem heeft,
+en blijft elke editor alleen-lezen, zodat er niets kan worden getypt dat niet kan worden opgeslagen.
+
+---
+
+## De vergrendeling van iemand anders vrijgeven
+
+Een admin kan een vergrendeling vrijgeven die iemand anders heeft, bijvoorbeeld als die naar huis is gegaan met de ontwerper open.
+
+**Vrijgeven**, naast **Vergrendeld door**, is alleen zichtbaar voor admins. Het vraagt eerst om bevestiging: de wijzigingen van de gebruiker die nog niet waren opgeslagen, gaan verloren.
+
+Vanaf 7.3.0 krijgt de gebruiker van wie de vergrendeling is vrijgegeven, te horen dat dat is gebeurd, en door wie: **Uw designervergrendeling is vrijgegeven door** de naam van de admin,
+met **Niet-opgeslagen wijzigingen kunnen niet meer worden opgeslagen.** Zijn ontwerper neemt de vergrendeling niet vanzelf terug; hij zet hem weer aan
+wanneer hij verder wil.
+
+---
+
+## Een vergeten vergrendeling
+
+Een vergrendeling die niemand gebruikt, komt vanzelf vrij, zodat niemand wacht op een ontwerper die niemand open heeft.
+
+De geopende ontwerper van de houder laat de server steeds weten dat hij er nog is. Heeft de server
+5 minuten niets van hem gehoord, omdat de browser is gesloten, de computer is uitgezet of het netwerk wegviel, dan is de vergrendeling weer vrij. Komt
+de houder terug in de ontwerper, dan neemt die de vergrendeling opnieuw als niemand anders dat heeft gedaan. Het vrijgeven door een admin is de uitzondering: daarna
+wordt de vergrendeling niet teruggenomen.
diff --git a/i18n/nl/_use/jobs/actions.md b/i18n/nl/_use/jobs/actions.md
new file mode 100644
index 0000000..8077857
--- /dev/null
+++ b/i18n/nl/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Jobacties
+parent: Jobs
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Jobacties
+{: .no_toc }
+
+Een job starten, afbreken, herstarten, goedkeuren of afwijzen, en verwijderen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Een job starten
+
+Elke job begint bij een formulier. Open het vanaf de pagina **Formulieren**, vul de velden in en druk op **Verzenden**:
+
+1. Het formulier wordt in de browser gevalideerd, en de veldwaarden worden naar de server gestuurd.
+2. De server maakt de job aan en geeft zijn nummer terug; de [`onSubmit`](../forms/job-status-action.html)-acties van het formulier worden uitgevoerd.
+3. De uitvoer van de job verschijnt onder het formulier en wordt elke twee seconden vernieuwd tot de job eindigt.
+
+De job verschijnt ook op de pagina **Jobs**, waar je hem later kunt volgen.
+
+### Wie een formulier kan starten
+
+Een formulier wordt getoond, en kan worden gestart, voor gebruikers die een van de [rollen](../config/roles.html) uit zijn lijst `roles` hebben.
+De rol `default`, die elke gebruiker heeft, maakt een formulier beschikbaar voor iedereen die kan aanmelden.
+
+### Voordat je verzendt
+
+De balk boven de velden biedt een paar hulpmiddelen, elk alleen zichtbaar als je rol het toestaat:
+
+| Knop | Wat het doet | Roloptie |
+|---|---|---|
+| **Toon extravars** | Toont vooraf de extravars die de job krijgt, terwijl je de velden invult | `showExtraVars` |
+| **verbose** | Voert de job uit in verbose-modus | `allowVerboseMode` |
+| **Laden uit opslag** | Vult de velden vanuit een [opgeslagen job](stored-jobs.html) | `allowStoredJobs` |
+| **Formulier herladen** | Laadt het formulier opnieuw, met de standaardwaarden | geen |
+
+### Keuzes bij het starten
+
+Een formulier kan zijn gebruikers bij het starten een paar Ansible-opties laten kiezen, door een veld met een gereserveerde naam te declareren. De
+waarde van het veld gaat dan boven de eigen instelling van het formulier:
+
+| Veldnaam | Overschrijft | Gebruikelijk veldtype |
+|---|---|---|
+| `__check__` | Check-modus, een proefrun die niets verandert | `checkbox` |
+| `__diff__` | Diff-modus, die toont wat er zou veranderen | `checkbox` |
+| `__limit__` | De hosts waarop het playbook draait | `text` of `enum` |
+| `__tags__` | De tags die worden uitgevoerd | `text` of `enum` |
+| `__inventory__` | De inventaris | `enum` |
+| `__playbook__`, `__template__` | Het playbook, of de AWX- / AAP-sjabloon | `enum` |
+
+Bijvoorbeeld een formulier dat een proefrun en een hostlimiet aanbiedt:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+De server accepteert deze namen alleen van een formulier dat ze als velden declareert, dus een start via de API kan ze niet
+op eigen houtje toevoegen. De eigenschappen die ze overschrijven, staan beschreven bij [Ansible-formulieren](../forms/ansible.html) en [AWX-formulieren](../forms/awx.html).
+
+### Wat een start kan tegenhouden
+
+Een start wordt niet altijd meteen een lopende job:
+
+* **Ongeldige velden** : het formulier wordt niet verzonden, en elk veld dat zijn validatie niet doorstaat, toont waarom.
+* **Launch-validatie** : staat [launch-validatie](../launch-validation/) op `enforce`, dan controleert de server de waarden
+  opnieuw en weigert hij een start die de regels van het formulier overtreedt.
+* **Goedkeuring** : een formulier met een [goedkeuringspunt](../forms/approval.html) maakt de job aan, die dan wacht in status
+  `approve`; zie [Een job goedkeuren of afwijzen](#approve-or-reject-a-job).
+
+Wanneer de job eindigt, versturen de [meldingen](../forms/notifications.html) van het formulier hun mails en kanaalberichten, en worden zijn
+acties bij jobstatus uitgevoerd.
+
+### Andere manieren om een job te starten
+
+Een formulier kan ook een job starten zonder dat iemand op **Verzenden** drukt:
+
+| Gestart door | Hoe | Pagina |
+|---|---|---|
+| Later uitvoeren of een cron-schema | **Later uitvoeren (eenmalig)** of **Schedule (terugkerend)** naast **Verzenden** | [Planningen](schedules.html) |
+| Een script of een pipeline | `POST /api/v2/job` met een API-token | [Jobs in de REST API](../api/jobs.html) |
+| Een AI-agent | De tool `launch_job` van de MCP-server | [MCP-tools](../mcp/tools.html) |
+| Een gesprek | De chatassistent vult het formulier in en start het | [Chatassistent](../chat/) |
+| Een eerdere job | **Herstarten**, hieronder | [Een job herstarten](#relaunch-a-job) |
+
+---
+
+## Een job afbreken
+
+**Afbreken** in het menu van de rij (⋮) in de lijst, of **Job afbreken** op de pagina van de job, stopt een job met status `running`. Na je bevestiging
+markeert AnsibleForms de job om af te breken:
+
+* **`ansible`**: de RTE stopt het playbookproces (met al zijn workers), en de job eindigt als `aborted` met
+  `... was aborted by the operator`. Een job die nog op een vrije RTE wacht, wordt afgebroken voordat hij start.
+* **Een sjabloonjob** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): AnsibleForms vraagt de runner de job te annuleren of te stoppen,
+  en de job eindigt als `aborted`. Weigert de runner, dan toont de uitvoer `Abort request denied`, gevolgd door
+  `reverting abort request`, en blijft de job draaien. Een Jenkins-build die nog in de wachtrij staat, wordt eruit gehaald.
+* **`workflow`**: de lopende jobs van knooppunten worden afgebroken en er start niets meer (zie
+  [Een workflow uitvoeren](../workflows/running.html#abort)).
+* **`multistep`**: de stappen die nog niet zijn begonnen, worden overgeslagen (`skipping: [Abort is requested]`), en de hoofdjob
+  eindigt als `aborted`. Een stap die al draait, is een eigen job: open hem en breek hem af om ook die te stoppen.
+
+Je kunt je eigen jobs afbreken; een admin, of vanaf 7.3.0 een gebruiker van wie de rol `manageAllJobs` instelt, kan elke job afbreken. Met `showAllJobLogs` kan een
+gebruiker de jobs van andere gebruikers zien, niet afbreken.
+
+---
+
+## Een job herstarten
+
+**Herstarten** in het menu van de rij (⋮) in de lijst, of **Job herstarten** op de pagina van de job, start een nieuwe job vanuit een afgeronde job. Het wordt aangeboden bij elke
+job die niet `running` is en niet op goedkeuring wacht, aan gebruikers van wie de rol de roloptie `allowJobRelaunch` instelt.
+
+De dialoog biedt:
+
+* **Herstarten**: voert de job opnieuw uit met de waarden waarmee hij draaide, als een nieuwe job op jouw naam.
+* **Uitgebreide modus**: herstart in verbose-modus; getoond met de roloptie `allowVerboseMode`.
+* **Waarden bewerken voor herstarten**, en daarna **Bewerken & herstarten**: opent het formulier vooraf ingevuld met de waarden van de job, zodat je
+  ze kunt wijzigen voordat je verzendt.
+
+Een herstart vereist ook dat het formulier het toestaat (`allowRelaunch`, standaard true) en dat de job **van jou** is, tenzij
+je admin bent of, vanaf 7.3.0, `manageAllJobs` hebt; `showAllJobLogs`, waarmee je tot en met 7.2 elke job kon herstarten, kan dat niet meer. Hoe een herstart tegen de regels van het formulier wordt gecontroleerd, en waarom een formulier met een
+wachtwoordveld hem kan weigeren, staat beschreven in [Opnieuw starten](../launch-validation/relaunching.html).
+
+### Herstarten met vooraf ingevulde gegevens
+
+**Bewerken & herstarten** opent het formulier met de URL-parameter `prefillJobId`, die je ook in een eigen link kunt gebruiken:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+Het formulier laadt de veldwaarden die bij job `61` zijn opgeslagen, en toont `Formulier vooraf ingevuld met de gegevens van de vorige job #61`.
+Verzenden start een nieuwe job, gecontroleerd zoals elke andere start. Het vooraf invullen volgt dezelfde regels als een herstart:
+
+* **Wachtwoordvelden worden nooit opgeslagen**, dus ze worden nooit vooraf ingevuld: voer ze opnieuw in. Constanten worden ook niet opgeslagen.
+* De roloptie `allowJobRelaunch` is vereist, en de job moet van jou zijn (of je bent admin of hebt `manageAllJobs`).
+* Een formulier met `allowRelaunch: false` kan niet worden herstart of vooraf ingevuld:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Een job van vóór de tijd dat de veldwaarden werden opgeslagen, kan niet vooraf worden ingevuld, en het formulier toont in plaats daarvan een fout:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Een job goedkeuren of afwijzen
+
+Een job met een [goedkeuringspunt](../forms/approval.html) stopt in status `approve` en wacht. Hij staat op de pagina Jobs van
+zijn goedkeurders, de gebruikers met een van de rollen van de goedkeuring, zodat zij hem kunnen vinden; vanaf 7.3.0 zien andere gebruikers hem niet meer.
+
+**Goedkeuring beoordelen** wordt aangeboden aan admins en aan gebruikers met een van de rollen van de goedkeuring: een klik op de rij van de job,
+**Goedkeuring beoordelen** in het menu van de rij, of de knop **Goedkeuring beoordelen** op de pagina van de job. De dialoog toont het bericht
+van de goedkeuring, met de waarden van de job ingevuld (of een algemene regel als er geen bericht is), en het formulier, de job-id, wie hem startte en
+wanneer, met een link naar de job; **Afwijzen** en **Goedkeuren** beantwoorden hem:
+
+* **Goedkeuren**: de job gaat verder en zijn status wordt weer `running`.
+* **Afwijzen**: de job eindigt als `rejected`, en zijn uitvoer vermeldt `rejected by <username>`.
+
+Een job die op goedkeuring wacht, kan vanaf de pagina Jobs niet worden herstart of verwijderd; keur hem eerst goed of wijs hem af.
+
+Vanaf 7.3.0 kan de gebruiker die een job startte hem niet goedkeuren, zodat er altijd een tweede persoon naar kijkt, al kan hij hem nog wel afwijzen om hem
+in te trekken. Een admin kan altijd goedkeuren, ook zijn eigen jobs. Een formulier waarvan het goedkeuringspunt
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) instelt, laat degene die het startte zijn eigen job ook goedkeuren.
+
+---
+
+## Een job verwijderen
+
+**Verwijderen** in het menu van de rij (⋮) in de lijst, of **Job verwijderen** op de pagina van de job, verwijdert na je bevestiging een job met zijn uitvoer.
+Een multistep-job verwijderen verwijdert ook zijn stappen. Om meerdere jobs tegelijk te verwijderen, vink je ze aan in de eerste kolom van de lijst en
+klik je op **Verwijderen (n)** erboven.
+
+Je kunt je eigen jobs verwijderen. Admins en, vanaf 7.3.0, gebruikers met de roloptie `manageAllJobs` kunnen elke job verwijderen; met `showAllJobLogs`
+kan dat niet meer. Een rol die `allowJobDeletion: false` instelt, verwijdert helemaal geen jobs, ook niet de eigen, zodat de jobgeschiedenis volledig blijft. Op de pagina
+van de job is de knop verborgen terwijl de job draait of wordt afgebroken (behalve voor admins en `manageAllJobs`) en terwijl hij op goedkeuring wacht; in de lijst zijn het
+menu-item en het selectievakje grijs voor een job die je niet kunt verwijderen.
diff --git a/i18n/nl/_use/jobs/cleanup.md b/i18n/nl/_use/jobs/cleanup.md
new file mode 100644
index 0000000..ee8a11f
--- /dev/null
+++ b/i18n/nl/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Opruimen
+parent: Jobs
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Opruimen
+{: .no_toc }
+
+Jobs die door een herstart zijn afgebroken, en hoe lang afgeronde jobs bewaard blijven
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Verlaten jobs
+
+Een lopende job wordt gevolgd door het AnsibleForms-proces dat hem startte. Stopt dat volgen, dan wordt de job gemarkeerd als
+`abandoned`:
+
+* **Bij het opstarten** worden de jobs die dit proces vóór zijn herstart volgde, en de jobs van vóór 7 die door geen enkel proces
+  worden gevolgd, als verlaten gemarkeerd als ze nog `running` zijn of worden afgebroken; het log toont `Abandoned <n> jobs`. Een job die
+  op een RTE draait, wordt niet aangeraakt: die gaat door zonder het proces dat hem startte.
+* **Elke minuut** worden de jobs die worden gevolgd door een ander AnsibleForms-proces (of RTE) dat 2 minuten niet meer heeft geantwoord,
+  als verlaten gemarkeerd; het log toont `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Elk uur** worden jobs die meer dan een dag geleden zijn gestart, nog `running` zijn en een dag lang geen uitvoer schreven, als verlaten gemarkeerd.
+  Een job die op een RTE draait, blijft ook hier ongemoeid: de RTE ruimt zijn eigen jobs op wanneer hij herstart.
+
+Vanaf 7.3.0 wordt een sjabloonjob op AWX, AAP of Ascender die door een herstart of een gestopt knooppunt is verlaten, weer opgepakt als hij
+in de afgelopen 24 uur is gestart: één AnsibleForms-proces neemt hem over, volgt hem opnieuw op de runner, en de job eindigt met wat
+daar echt is gebeurd. Jobs op de andere runners, playbooks, workflows en multistep-jobs blijven verlaten.
+
+Een verlaten playbook kan gedeeltelijk zijn uitgevoerd. Controleer de beheerde hosts voordat je het herstart; zie
+[Een job toont de status abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Bewaartermijn van jobs
+
+Jobs blijven bewaard tot ze worden verwijderd, tenzij de beheerder een bewaartermijn instelt.
+
+Is [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) ingesteld, dan verwijdert een nachtelijke taak (om 2:30)
+de afgeronde jobs, met hun uitvoer en stappen, die meer dan dat aantal dagen geleden zijn geëindigd. Ze verwijdert alleen jobs met
+status `success`, `failed`, `warning`, `aborted`, `rejected` of `abandoned`, dus lopende jobs en jobs die op goedkeuring
+wachten, blijven bewaard hoe oud ze ook zijn. De standaard, `0`, bewaart elke job.
diff --git a/i18n/nl/_use/jobs/following.md b/i18n/nl/_use/jobs/following.md
new file mode 100644
index 0000000..e59d5f6
--- /dev/null
+++ b/i18n/nl/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Een job volgen
+parent: Jobs
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Een job volgen
+{: .no_toc }
+
+Live uitvoer, extravars, filters en downloads
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Een job volgen
+
+Klik je op een job, dan opent zijn pagina: het formulier van de job als titel, de acties in de kop en de uitvoer eronder.
+
+![De uitvoer van een job](../assets/screenshots/job-output.jpg)
+
+Vanaf 7.3.0 bestaat de pagina uit kaarten, en elke kaart klapt in onder haar kop:
+
+| Kaart | Wat ze toont |
+|---|---|
+| **Overzicht** | De naam, status en het type van de job als kop, en de gegevens eronder in een raster van drie kolommen (twee, en dan één, op een smalle pagina) |
+| **Workflow** | Bij een workflowjob, ook een workflowjob van AWX of AAP, de graaf en het aantal knooppunten (zie [De workflowgraaf](#the-workflow-graph)) |
+| **Uitvoer** | De uitvoer van de job en de werkbalk ervan |
+
+Een job die op AWX, AAP, Ascender, Jenkins, Semaphore of Rundeck draaide, toont daar zijn nummer als link naar zijn pagina in die tool, geopend
+in een nieuw tabblad. De link wordt bij de job bewaard, dus hij blijft werken wanneer de runner later wordt hernoemd of verwijderd.
+
+De pagina wordt live bijgewerkt: de server stuurt een gebeurtenis telkens als een job wordt gestart, van status verandert, uitvoer schrijft of wordt
+verwijderd, en de pagina leest de job opnieuw, zodat de uitvoer groeit terwijl de job schrijft. De lijst met jobs wordt op dezelfde manier bijgewerkt.
+**Vernieuwen** laadt de job handmatig opnieuw.
+
+Zolang je aan het eind van de uitvoer staat, volgt de pagina die naar beneden terwijl er nieuwe regels binnenkomen. Scrol omhoog om een eerdere regel te lezen,
+en de pagina blijft waar je bent: **Naar nieuwste** verschijnt dan onderaan over de uitvoer, en wordt **Nieuwe regels** zodra
+er meer zijn binnengekomen. Klik erop, of scrol terug naar het eind, om de nieuwe regels weer te volgen. De uitvoer op de pagina van het formulier, na
+**Verzenden**, en het [serverlog](../production/logs.html) volgen hun nieuwe regels op dezelfde manier.
+
+De werkbalk van de uitvoer heeft:
+
+| Knop | Wat het doet |
+|---|---|
+| **Toon extravars** | Toont de extravars waarmee de job draaide in een paneel over de uitvoer, met een schakelaar **JSON** / **YAML** en **Kopiëren** |
+| **Toon artifacts** | Toont de artifacts van de job in hetzelfde paneel (zie hieronder) |
+| **Parameters tonen** | Neemt bij een Jenkins-job de plaats in van **Toon extravars**: de waarden waarmee hij draaide, zijn buildparameters |
+| **Payload tonen** | Neemt bij een Rundeck-job de plaats in van **Toon extravars**: de payload die hem werd gestuurd |
+| **Hosts en taken** | Toont de hosts en taken van een playbook over de uitvoer (zie [Hosts en taken](#hosts-and-tasks)) |
+| **Vernieuwen** | Laadt de uitvoer opnieuw |
+| **Filter toepassen** | Verbergt de taken waarvan de naam overeenkomt met het uitvoerfilter; **Filter verwijderen** toont ze weer |
+| **Uitvoer kopiëren** | Kopieert de uitvoer als platte tekst, met of zonder het filter |
+| **Uitvoer downloaden** | Downloadt de uitvoer als `ansibleforms-job-<id>.txt` |
+
+**Toon artifacts** wordt aangeboden bij elke job die geen sjabloonjob is, zoals een playbook op de RTE of een workflow (leeg wanneer
+de playbooks geen artifacts met `set_stats` verzamelden), en bij een sjabloonjob die op AWX, AAP of Ascender draaide. Jobs van Semaphore, Rundeck
+en Jenkins hebben geen artifacts, dus daar wordt het nooit aangeboden.
+
+Links in de werkbalk klapt de knop **Alles samenvouwen** elke sectie van de uitvoer in (elke play en taak) en wordt dan
+**Alles uitvouwen**, waarmee je ze weer uitklapt.
+
+**Toon extravars** vereist de roloptie `showExtravars` en **Toon artifacts** de roloptie `showArtifacts` (zie
+[rolopties](../config/roles.html#role-options)). Waarden van wachtwoordvelden en sleutels die overeenkomen met
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX), worden gemaskeerd.
+
+Het filter wordt ingesteld met [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), standaard `\[low\]`.
+Zet `[low]` in de naam van een taak die veel ruis geeft, en **Filter toepassen** verbergt die taak en haar regels.
+
+De pagina van een multistep-job toont elke stap onder de hoofdjob, onder elkaar, elk onder een titelbalk zoals
+**Stap 1 · Prepare the server (job-id 98)** met de status. Klik op een titel (of druk er op Enter of Spatie) om die uitvoer
+in te klappen, en nog eens om hem uit te klappen. AWX/AAP-workflows tonen ook de status van hun knooppunten.
+
+[Workflowjobs](../workflows/running.html#the-job) bewaren de uitvoer van elk knooppunt in hun eigen uitvoer, onder een banner `WORKFLOW NODE` per
+knooppunt; ze tekenen hun graaf, live, en een klik op een knooppunt opent de uitvoer ervan.
+
+---
+
+## Tekst zoeken in de uitvoer
+
+Vanaf 7.3.0 heeft de pagina van de job een zoekvak, **Zoeken in de uitvoer**, op de titelregel, links van de acties van de job.
+
+Elke plek waar de tekst in de uitvoer staat, wordt gemarkeerd, ongeacht hoofdletters, en de pagina gaat naar de eerste. **Enter** gaat naar
+de volgende, sterker gemarkeerd, en de werkbalk zegt welke van hoeveel het is (**2 van 4**), of **Niet gevonden**. Zoeken klapt eerst de uitvoer en
+haar secties uit, en terwijl de job draait worden ook de nieuwe regels doorzocht, zonder dat de pagina verspringt.
+
+---
+
+## Door een lange uitvoer bewegen
+
+Vanaf 7.3.0 heeft een lange uitvoer, op de pagina van de job en onder een formulier na **Verzenden**, deze manieren om erdoorheen te gaan:
+
+| Element | Wat het doet |
+|---|---|
+| Vaste koppen | De kop van een sectie (een knooppunt van een workflow, het playbook van de job, een stap van een multistep-job) blijft bovenaan staan terwijl de regels voorbij scrollen |
+| **2 mislukt** | Telt de mislukte taken, zonder de fouten die Ansible moest negeren; elke klik gaat naar de volgende, uitgeklapt en gemarkeerd. Zonder mislukte taken telt **1 fout** in plaats daarvan de foutregels |
+| Regelnummers | Elk regelnummer linkt naar zijn regel, zoals `#L45` in het adres: wie dat adres opent, scrolt naar de regel en ziet hem gemarkeerd |
+| Knoppen omhoog en omlaag | Verschijnen rechtsonder zodra de pagina is gescrold, om terug te gaan naar het begin of naar het eind |
+| **Bezig** en **Afbreken** | Terwijl de job draait, blijft de balk van de pagina van het formulier onderaan het venster staan, en **Afbreken** daar stopt de job meteen |
+
+---
+
+## Resultaten van taken
+
+Vanaf 7.3.0 opent een resultaatregel van een host in de uitvoer van een playbook dat resultaat in een dialoog **Resultaat van de taak**, zoals AWX dat doet.
+
+De regel, de body van het resultaat erna (`=> { ... }`) en de fout die vóór een mislukt resultaat is afgedrukt, lichten bij hover op als één blok, en een
+klik opent de dialoog. Het werkt op de pagina van de job en onder een formulier na **Verzenden**, voor een playbook dat op een RTE van 7.3.0 of
+later draaide, omdat het resultaat uit dezelfde gebeurtenissen komt als [Hosts en taken](#hosts-and-tasks). De dialoog heeft deze tabbladen:
+
+| Tabblad | Wat het toont |
+|---|---|
+| **Details** | De status, host, play, taak, module, loop-item, starttijd, duur, returncode en het bericht |
+| **JSON** en **YAML** | Het volledige resultaat van de module, gekleurd en met genummerde regels |
+| **Standaarduitvoer** en **Standaardfout** | De `stdout` en `stderr` van het resultaat, als het die heeft |
+
+Het volledige resultaat, en daarmee de tabbladen **JSON**, **YAML** en de uitvoertabbladen, wordt alleen opgeslagen wanneer de job in verbose-modus draait, omdat de uitvoer
+het dan ook toont; anders toont de dialoog alleen de details. Ook in verbose-modus worden de argumenten van de module (`invocation`) weggelaten,
+worden waarden van sleutels die op een geheim lijken gemaskeerd, en wordt een resultaat afgekapt zodra het groter is dan 64 KB JSON.
+
+---
+
+## De workflowgraaf
+
+Vanaf 7.3.0 schuift de graaf van een lopende workflow mee om het lopende knooppunt in beeld te houden.
+
+Scrol je de graaf weg, dan blijft hij waar je hem neerzet, met een knop **Lopende node volgen** om weer te volgen. Beweeg je over een knooppunt,
+dan verschijnt zijn kaart met de volledige naam en komen het knooppunt en zijn koppelingen op de voorgrond, met de rest van de graaf vervaagd. De graaf heeft de knoppen **Aanpassen
+aan scherm** en **Volledig scherm**, en onder een formulier na **Verzenden** opent een klik op een knooppunt de uitvoer ervan, net als op de pagina van de job.
+
+---
+
+## Hosts en taken
+
+Sinds 7.3.0 legt een playbookjob die op een RTE van 7.3.0 of later draaide, zijn gestructureerde gebeurtenissen vast naast zijn tekstuitvoer: elke play, taak
+en elk hostresultaat, en de recap. **Hosts en taken**, in de werkbalk van de uitvoer, toont ze in een paneel over de uitvoer, op de pagina van de job en
+onder een formulier na **Verzenden**. Het wordt aangeboden zodra de job gebeurtenissen heeft, en het paneel wordt om de paar seconden opnieuw gelezen terwijl de job draait:
+
+| Weergave | Wat ze toont |
+|---|---|
+| **Raster** | De recap per host (ok, gewijzigd, mislukt, onbereikbaar, overgeslagen, gered, genegeerd), en daarna een raster van hosts tegen taken: elke cel is gekleurd naar het resultaat van de host voor die taak, met bericht en tijd bij hover, of *niet uitgevoerd* |
+| **Tijdlijn** | Elke taak als balk, zo lang als de traagste host erover deed, met de tijd in seconden en het totaal |
+
+De tekstuitvoer blijft zoals hij is. De gebeurtenissen worden geschreven door de eigen callback-plugin `af_events` van de RTE, dus het playbook hoeft niet te veranderen.
diff --git a/i18n/nl/_use/jobs/index.md b/i18n/nl/_use/jobs/index.md
new file mode 100644
index 0000000..d362e8f
--- /dev/null
+++ b/i18n/nl/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Jobs
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Jobs
+{: .no_toc }
+
+Volg, breek af, herstart, keur goed en verwijder de jobs die je formulieren starten
+{: .fs-6 .fw-300 }
+
+---
+
+Voor iedereen die formulieren start: wat een job is, waar je hem vindt en wie hem kan zien.
+
+---
+
+## Wat een job is
+
+Een job is één uitvoering van een formulier: AnsibleForms legt hem vast met zijn status, extravars en uitvoer zodra het formulier wordt verzonden.
+
+Elke job bewaart:
+
+* het **formulier** dat hij uitvoerde en de **gebruiker** die hem startte (met het type gebruiker, zoals `local` of `ldap`);
+* zijn **jobtype** en **status**, en zijn **starttijd** en **eindtijd**;
+* zijn **uitvoer**, de extravars en inloggegevens waarmee hij draaide, en de veldwaarden die in het formulier zijn ingevuld.
+
+Een multistep-formulier maakt één job voor het formulier en één job per stap. De stappen zijn gekoppeld aan de hoofdjob en staan eronder.
+
+Dezelfde jobs kun je ook starten, volgen en beheren via de [REST API](../api/jobs.html).
+
+---
+
+## De pagina Jobs
+
+De link **Taken** in de kopbalk opent de lijst van alle jobs, de nieuwste eerst (`/jobs/all`). De pagina en de link worden getoond aan gebruikers
+van wie de rol de [roloptie](../config/roles.html#role-options) `showJobs` instelt.
+
+![De lijst met jobs](../assets/screenshots/job-log.jpg)
+
+Het linkermenu ordent de jobs in de tijd, met het aantal jobs bij elk item; een statusitem filtert de lijst op die status:
+
+| Sectie | Menu-item | Toont |
+|---|---|---|
+| **Verleden** | **Geslaagd** | Jobs met status `success` |
+| | **Mislukt** | Jobs met status `failed` |
+| | **Afgebroken** | Jobs met status `aborted` |
+| | **Afgewezen** | Jobs met status `rejected` |
+| | **Verlaten** | Jobs met status `abandoned` |
+| **Heden** | **Bezig** | Jobs met status `running` |
+| | **Wacht op goedkeuring** | Jobs met status `approve`; het aantal wordt oranje zodra er een wacht |
+| **Toekomst** | **Gepland** | De pagina [Planner](schedules.html) (roloptie `allowScheduledJobs`) |
+| | **Opgeslagen** | De pagina [Opgeslagen invoer](stored-jobs.html) (roloptie `allowStoredJobs`) |
+
+Het menu heeft geen item voor alle jobs: de link **Taken** in de kopbalk toont ze allemaal, `warning`-jobs inbegrepen.
+
+Boven de tabel, op de titelregel:
+
+* het **zoekvak** houdt de jobs over waarvan de getoonde kolommen de tekst bevatten (niet hoofdlettergevoelig), of waarvan een stap die tekst als id
+  of doel heeft;
+* **Verwijderen** (met het aantal aangevinkte jobs) verwijdert de jobs die in de eerste kolom zijn aangevinkt in één keer;
+* **Kolommen** toont of verbergt de kolommen `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` en `user`;
+  de duur van een lopende job telt op;
+* **Vernieuwen** laadt de lijst opnieuw.
+
+De lijst laadt de nieuwste jobs, zoveel als de instelling [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) aangeeft
+(**Instellingen > Systeem > Algemeen**, tabblad **Jobs**, standaard `1000`); de pagina's, het zoeken en de filters gelden voor die jobs.
+
+Elke kolom is sorteerbaar en heeft een eigen filterveld. Een multistep-job heeft vlak voor zijn `form` een pijltje dat
+de stappen uitklapt; een klik op de rest van een rij opent de job.
+
+De bel in de kopbalk telt de jobs die op jouw goedkeuring wachten en opent de lijst op **Wacht op goedkeuring**. Voor gebruikers die
+de runners kunnen zien, telt hij ook de [runners die op goedkeuring wachten](../runners/registration.html#approving-an-rte), RTE's die vroegen om toe te treden,
+en opent hij **Verbindingen > Runners** wanneer alleen runners wachten. Wachten er beide, dan opent hij een menu, **Jobs die wachten op goedkeuring** en
+**Runners die wachten op goedkeuring**, elk met het aantal.
+
+---
+
+## Wie welke jobs ziet
+
+Welke jobs een gebruiker ziet, hangt af van zijn rollen:
+
+| Gebruiker | Ziet |
+|---|---|
+| Admin (rol `admin`) | Elke job |
+| Roloptie `showAllJobLogs` | Elke job |
+| Roloptie `manageAllJobs` (vanaf 7.3.0) | Elke job, en mag hem afbreken, verwijderen en herstarten |
+| Elke andere gebruiker | Zijn eigen jobs, en de jobs die wachten op een goedkeuring die een van zijn rollen noemt |
+
+Tot en met 7.2 kon elke gebruiker elke job openen die op goedkeuring wachtte, extravars en uitvoer inbegrepen; vanaf 7.3.0 kunnen alleen de eigenaar en de
+goedkeurders dat. Een job zien geeft niet elke actie erop: de job van een andere gebruiker afbreken, verwijderen en herstarten vereist een admin of
+`manageAllJobs`, en `showAllJobLogs` toont de jobs alleen. Verwijderen vereist daarnaast `allowJobDeletion` en herstarten `allowJobRelaunch`.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Statussen en typen](statuses.html) | Elke status die een job kan hebben, en de soorten jobs |
+| [Een job volgen](following.html) | Live uitvoer, extravars, filters en downloads |
+| [Jobacties](actions.html) | Een job starten, afbreken, herstarten, goedkeuren of afwijzen, en verwijderen |
+| [Planningen](schedules.html) | Een formulier later of volgens een cron-schema uitvoeren, en elke planning beheren |
+| [Opgeslagen jobs](stored-jobs.html) | De gegevens van een formulier bewaren om ze later weer te laden |
+| [Opruimen](cleanup.html) | Jobs die door een herstart zijn afgebroken, en hoe lang afgeronde jobs bewaard blijven |
diff --git a/i18n/nl/_use/jobs/schedules.md b/i18n/nl/_use/jobs/schedules.md
new file mode 100644
index 0000000..74ad9c1
--- /dev/null
+++ b/i18n/nl/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Planningen
+parent: Jobs
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Planningen
+{: .no_toc }
+
+Voer een formulier later of volgens een cron-schema uit, en beheer elke planning
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De acties van het formulier
+
+Een formulier kan meer dan meteen uitvoeren: de keuzelijst naast de knop **Verzenden** bevat nog drie acties.
+
+| Actie | Wat het doet | Roloptie |
+|---|---|---|
+| **Schedule (terugkerend)** | Maakt een planning die het formulier volgens een cron-expressie uitvoert | `allowScheduledJobs` |
+| **Later uitvoeren (eenmalig)** | Maakt een planning die het formulier één keer uitvoert, op een datum en tijd die je kiest | `allowPlannedJobs` |
+| **Store** | Slaat de veldwaarden op, om ze later weer in het formulier te laden | `allowStoredJobs` |
+
+Een actie waarvan de roloptie uitstaat, wordt niet getoond. Het formulier wordt vóór elk van deze acties gevalideerd, net als bij **Verzenden**. Beide
+planningsacties maken een item aan op de pagina **Planner**; **Store** maakt een item aan op de pagina **Opgeslagen invoer**. De
+zijbalk van de pagina [Jobs](./) opent ze onder **Toekomst**, als **Gepland** en **Opgeslagen**. De rolopties staan beschreven
+in [Rolopties](../config/roles.html#role-options).
+
+{: .warning }
+> Behandel `allowScheduledJobs` als een optie op adminniveau. De planningen zijn niet van de gebruiker die ze aanmaakte: elke gebruiker
+> met de optie ziet alle planningen en kan ze wijzigen. Zo'n planning draait bovendien met adminrechten, voor elk formulier, ongeacht de
+> eigen toegang van de maker. Ken haar alleen toe aan rollen die je als admin zou vertrouwen.
+
+{: .note }
+> **Later uitvoeren (eenmalig)** vereist alleen `allowPlannedJobs`. Voor een gebruiker zonder `allowScheduledJobs` plant het een uitvoering **als die
+> gebruiker**: de server controleert of de gebruiker het formulier mag uitvoeren, en de job draait als die gebruiker, met die gebruiker als eigenaar, wanneer het zover is
+> (zie [Geplande uitvoeringen](#planned-runs)).
+
+---
+
+## Een formulier plannen
+
+Vul het formulier in, open daarna de keuzelijst naast **Verzenden** en kies een van de planningsacties.
+
+- **Schedule (terugkerend)** opent **Planning aanmaken**: vul een **Naam** en een **Cron expressie** in (de standaard, `0 0 * * *`,
+  draait elke dag om middernacht), en kies dan **Planning aanmaken**.
+- **Later uitvoeren (eenmalig)** opent **Later uitvoeren**: vul een **Naam** in en kies de datum en tijd bij **Uitvoeren op**, en kies dan
+  **Job plannen**.
+
+De naam moet uniek zijn over alle planningen. De planning bewaart de naam van het formulier en een kopie van de extravars die het formulier op
+dat moment opleverde, als YAML; elke uitvoering gebruikt die kopie, dus bewerk haar op de pagina **Planner** om te veranderen wat de job krijgt.
+
+![Planningen](../assets/screenshots/schedules.jpg)
+
+---
+
+## De pagina Planner
+
+De pagina **Planner** toont elke planning, vanaf 7.3.0 met de kolom **Ingeschakeld**, en vereist `allowScheduledJobs`. Het menu van elke rij biedt:
+
+| Actie | Wat het doet |
+|---|---|
+| **Bewerken** | Wijzigt de naam, het type, de cron-expressie of het tijdstip van uitvoering, het formulier en de extra vars |
+| **Nu uitvoeren** | Voert de planning nu uit, zonder op haar cron-expressie of tijdstip te wachten |
+| **Inschakelen** of **Uitschakelen** | Zet de planning aan of uit, afhankelijk van wat van toepassing is, zoals haar kolom **Ingeschakeld** toont (vanaf 7.3.0) |
+| **Verwijderen** | Verwijdert de planning; ze stopt meteen met draaien |
+| **Laatste uitvoer** | Op de pagina van de planning, wat de laatste uitvoering meldde, zoals het nummer van de job die ze startte |
+
+Een planning kan hier ook vanaf nul worden aangemaakt. Kies het **Formulier**, en vink dan **Eenmalige uitvoering** aan en stel
+**Uitvoeren op** in, of laat het uit en stel een **Cron-schema** in. **Extra vars** is YAML zonder formulier dat het vult, dus voeg de
+waarden die het playbook nodig heeft zelf toe, als dictionary (paren sleutel: waarde).
+
+Het veld **Cron-schema** is een cron-editor: het beschrijft de expressie in woorden, biedt presets en toont vooraf de volgende
+uitvoeringen. De server weigert een expressie die hij niet kan uitvoeren, of een die nooit kan voorkomen.
+
+Vanaf 7.3.0 heeft elke planning een schakelaar **Ingeschakeld**, om haar te pauzeren zonder haar te verwijderen. Een uitgezette planning blijft op de pagina staan
+met haar instellingen, maar draait niet vanzelf: een terugkerende planning slaat haar cron-tikken over, en een eenmalige wacht voorbij haar
+**Uitvoeren op** tot ze weer wordt aangezet. **Nu uitvoeren** voert haar nog steeds op verzoek uit. Een nieuwe planning staat aan, en de planningen
+die vóór 7.3.0 bestonden, staan na de upgrade aan.
+
+---
+
+## Cron-expressies en tijdzone
+
+Een terugkerende planning gebruikt een standaard cron-expressie met 5 velden: minuut, uur, dag van de maand, maand en dag van de week.
+
+| Expressie | Draait |
+|---|---|
+| `*/15 * * * *` | Elke 15 minuten |
+| `0 2 * * *` | Elke dag om 02:00 |
+| `30 7 * * 1-5` | Maandag tot en met vrijdag om 07:30 |
+| `0 0 1 * *` | Om middernacht op de eerste dag van elke maand |
+
+Meer voorbeelden, en de cron-functies die de editor niet accepteert, staan in de FAQ onder
+[Welke cron-expressies kan ik gebruiken?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Cron-planningen draaien in de tijdzone van de server, ingesteld met [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (standaard `UTC`),
+> niet in de tijdzone van je profiel of je browser. De cron-editor toont de volgende uitvoeringen in diezelfde zone.
+
+---
+
+## Hoe een planning draait
+
+Is een planning aan de beurt, dan komt ze in de wachtrij, en de server start planningen uit de wachtrij één voor één, waarbij hij de wachtrij elke 10 seconden controleert.
+
+- **Terugkerende** planningen slaan een tik over zolang de vorige uitvoering nog in de wachtrij staat of draait, zodat uitvoeringen nooit overlappen.
+- **Eenmalige** planningen draaien binnen een minuut na **Uitvoeren op** en worden daarna verwijderd, ook wanneer ze met **Nu uitvoeren** zijn gestart.
+- **Status** is `success` wanneer de job is gestart en `failed` wanneer dat niet lukte. Een `success` zegt alleen dat de job is
+  gestart: open de job om te zien hoe hij eindigde.
+
+Een planning die met `allowScheduledJobs` is gemaakt, draait als de ingebouwde gebruiker `Schedule Service` (type `schedule`) met de
+rol `admin`. Ze kan elk formulier uitvoeren, ongeacht de toegang van degene die de planning maakte, en `ansibleforms_user` in
+haar extravars beschrijft die gebruiker. Een [geplande uitvoering](#planned-runs) draait in plaats daarvan als de gebruiker die haar plande.
+
+De job krijgt ook een object `schedule` (met zijn `id`, `name` en `form`), zodat een playbook weet dat een planning hem startte:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Geplande uitvoeringen
+
+**Later uitvoeren (eenmalig)** door een gebruiker zonder `allowScheduledJobs` maakt een geplande uitvoering: een eenmalige planning die aan die gebruiker is gekoppeld.
+
+- **Bij het plannen** controleert de server of de gebruiker het formulier mag uitvoeren (de `roles` ervan), en verbose-modus vereist
+  `allowVerboseMode`. Een geplande uitvoering is altijd eenmalig; een cron-expressie wordt geweigerd.
+- **Onder launch-validatie `enforce`** worden de veldwaarden bij het plannen gecontroleerd, zodat een uitvoering die geweigerd zou worden,
+  wordt geweigerd terwijl de gebruiker er nog naar kijkt.
+- **Wanneer ze draait**, draait de job als die gebruiker, met die gebruiker als eigenaar, met dezelfde controles als een start vanuit de browser: de
+  rollen van het formulier zoals ze dan zijn, de gereserveerde extravars verwijderd, en launch-validatie. `ansibleforms_user` beschrijft die gebruiker.
+
+Wie plant, ziet de pagina **Planner** niet, want die vereist `allowScheduledJobs`; de job verschijnt in zijn eigen jobgeschiedenis.
+
+---
+
+## Wanneer het formulier verandert
+
+Een planning verwijst op naam naar haar formulier en voert het uit zoals het op het moment van elke uitvoering is gedefinieerd.
+
+- **Het formulier wordt bewerkt**: de volgende uitvoering gebruikt de nieuwe definitie (playbook, sjabloon, inventaris) met de extravars die in
+  de planning zijn opgeslagen. Het formulier wordt niet opgebouwd, dus er wordt geen veld opnieuw berekend; pas de extra vars van de planning daarop aan.
+- **Het formulier wordt hernoemd of verwijderd**: de uitvoering mislukt, **Status** wordt `failed` en **Laatste uitvoer** toont
+  `Failed to launch : No such form '<name>'`. Bewerk de planning en kies het juiste formulier, of verwijder haar.
+
+---
+
+## Geplande jobs in de jobgeschiedenis
+
+Elke uitvoering van een planning maakt een gewone job, die op de pagina [Jobs](./) staat met `Schedule Service` als gebruiker, of,
+bij een geplande uitvoering, met de gebruiker die haar plande.
+
+Een job van `Schedule Service` is niet van degene die de planning maakte, dus alleen admins en
+gebruikers met `showAllJobLogs` zien hem; de job van een geplande uitvoering is ook zichtbaar voor zijn gebruiker. De **Laatste uitvoer** van de planning noemt de job die ze startte, zodat je hem in de lijst kunt vinden.
diff --git a/i18n/nl/_use/jobs/statuses.md b/i18n/nl/_use/jobs/statuses.md
new file mode 100644
index 0000000..0a63497
--- /dev/null
+++ b/i18n/nl/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Statussen en typen
+parent: Jobs
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Statussen en typen
+{: .no_toc }
+
+Elke status die een job kan hebben, en de soorten jobs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jobstatussen
+
+AnsibleForms zet de volgende statussen op een job. De lijst toont elke status als een gekleurd label:
+
+| Status | Betekenis | Wat je kunt doen |
+|---|---|---|
+| `running` | De job draait, of een goedgekeurde job is hervat | De uitvoer volgen, hem afbreken |
+| `approve` | De job wacht bij een [goedkeuringspunt](../forms/approval.html) voordat hij draait (of voordat een stap van een multistep draait) | Hem goedkeuren of afwijzen, als een van je rollen goedkeurder is |
+| `success` | Het playbook, de sjabloon of elke stap is zonder fouten afgerond | De uitvoer bekijken, herstarten, verwijderen |
+| `failed` | De job is met een fout geëindigd, of het starten zelf is mislukt | De uitvoer bekijken om te zien waarom, herstarten, verwijderen |
+| `warning` | Een multistep is afgerond, maar een stap met `continue` is mislukt | De uitvoer bekijken, herstarten, verwijderen |
+| `aborted` | De job is vanuit AnsibleForms afgebroken, of de AWX- / AAP-job is geannuleerd | De uitvoer bekijken, herstarten, verwijderen |
+| `rejected` | Een goedkeurder heeft de job afgewezen; hij heeft nooit gedraaid | De uitvoer bekijken, herstarten, verwijderen |
+| `abandoned` | AnsibleForms is gestopt met het volgen van de job (zie [Verlaten jobs](cleanup.html#abandoned-jobs)) | De beheerde hosts controleren, herstarten, verwijderen |
+
+`running` is blauw, `success` groen met de tekst **Geslaagd**, en `failed` rood. `approve` is oranje met de tekst **Wacht op goedkeuring**,
+zodat een job die op een persoon wacht zich onderscheidt van de gestopte jobs; `warning`, `aborted` en `rejected` zijn amber. `abandoned` is
+grijs: niemand heeft hem gestopt, wat hem uitvoerde is weg.
+
+---
+
+## Jobtypen
+
+Het jobtype volgt het `type` van het formulier dat de job startte, zoals de lijst en de pagina van de job het tonen:
+
+| Getoond type | Wat er draait |
+|---|---|
+| `ansible` | Een Ansible-playbook, uitgevoerd op een RTE |
+| `awx`, `aap`, `ascender` | Een jobsjabloon of workflowsjabloon op AWX, AAP of Ascender |
+| `semaphore` | Een sjabloon op Semaphore UI |
+| `rundeck`, `jenkins` | Een job op Rundeck of Jenkins |
+| `workflow` | Een [workflow](../workflows/), waarvan de playbookknooppunten als eigen jobs eronder draaien |
+| `multistep` | Verouderd, gebruik `workflow`: een reeks stappen, elk vastgelegd als eigen job onder de hoofdjob |
+
+Een sjabloonjob wordt opgeslagen als `awx`-job (ook in de REST API) en getoond met het soort runner waarop hij draaide, hoe het
+formulier hem ook noemde: een formulier van type `awx` dat op een AAP-runner draait, toont `aap`.
+
+Zie [Ansible-formulieren](../forms/ansible.html), [AWX-formulieren](../forms/awx.html), [Workflowformulieren](../forms/workflow.html) en
+[Multistep-formulieren](../forms/multistep.html) voor de kant van het formulier.
diff --git a/i18n/nl/_use/jobs/stored-jobs.md b/i18n/nl/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..b8a5318
--- /dev/null
+++ b/i18n/nl/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Opgeslagen jobs
+parent: Jobs
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Opgeslagen jobs
+{: .no_toc }
+
+De gegevens van een formulier bewaren om ze later weer te laden
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Opgeslagen jobs
+
+Opgeslagen jobs bewaren de waarden van een formulier, zodat je ze opnieuw kunt laden in plaats van elke keer dezelfde velden in te vullen.
+
+Om op te slaan vul je het formulier in, open je de keuzelijst naast **Verzenden** en kies je **Store**. Vul in **Formuliergegevens opslaan** een
+**Naam**, een optionele **Beschrijving** en een datum bij **Verloopt op (optioneel)** in, en sla op. Wachtwoord- en constante velden worden
+nooit opgeslagen. Een subformulier heeft dezelfde actie **Store** naast zijn knop **Opslaan**, en bewaart onvoltooide waarden zonder
+ze te valideren.
+
+Om te laden kies je **Laden uit opslag** bovenaan het formulier. **Opgeslagen formulier laden** toont je opgeslagen jobs voor dat formulier, met
+hun aanmaak- en vervaldatum; kies er een om het formulier met de waarden ervan te vullen. Er draait niets tot je verzendt.
+
+Opgeslagen jobs worden bewaard in de database van AnsibleForms (tabel `stored_jobs`), met de naam van het formulier, je gebruiker als
+`<type>/<username>` (bijvoorbeeld `local/admin`) en de waarden als JSON. Een naam moet uniek zijn per gebruiker en formulier; een tweede
+met dezelfde naam opslaan mislukt met "Er bestaat al een opgeslagen formulier met deze naam".
+
+---
+
+## Opgeslagen jobs beheren
+
+De pagina **Opgeslagen invoer** toont de opgeslagen jobs met hun formulier, gebruiker, aanmaak- en vervaldatum, en vereist `allowStoredJobs`.
+
+- **Bewerken** opent de eigen pagina van de opgeslagen job: de **Details** (naam, formulier, vervaldatum) en de **Waarden**, de opgeslagen
+  veldwaarden als YAML, die je daar kunt wijzigen en opslaan.
+- **Openen in formulier** opent het formulier met de opgeslagen waarden ingevuld; er draait niets tot je verzendt.
+- **Verwijderen** verwijdert hem. Je kunt je eigen opgeslagen jobs verwijderen; gebruikers met `showSettings` kunnen er elke verwijderen.
+- Opgeslagen jobs met een datum bij **Verloopt op** in het verleden worden elke dag om 04:00 (in `LOG_TZ`) automatisch verwijderd.
diff --git a/i18n/nl/_use/profile/account.md b/i18n/nl/_use/profile/account.md
new file mode 100644
index 0000000..729ed12
--- /dev/null
+++ b/i18n/nl/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Account
+parent: Je profiel
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Account
+{: .no_toc }
+
+Als wie je bent aangemeld
+{: .fs-6 .fw-300 }
+
+---
+
+De weergave Account toont als wie je bent aangemeld en wat je toegang bepaalt:
+
+- **Gebruikersnaam** en **Aanmeldtype**: een lokaal account, LDAP, Microsoft Entra ID of OpenID Connect.
+- **Groepen**: de groepen die bij je aanmelding horen, zoals `local/admins` of `ldap/Domain Admins`.
+- **Rollen**: de rollen in `config.yaml` die bij die groepen en bij je gebruiker passen. Ze bepalen
+  welke formulieren je ziet en welke opties je hebt.
diff --git a/i18n/nl/_use/profile/api-token.md b/i18n/nl/_use/profile/api-token.md
new file mode 100644
index 0000000..b82c199
--- /dev/null
+++ b/i18n/nl/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: API-token
+parent: Je profiel
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# API-token
+{: .no_toc }
+
+Een token maken voor scripts en AI-agents
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wie er een kan maken
+
+Met een langlevend token kunnen scripts de API aanroepen zonder je wachtwoord. Vanaf 7.3.0 vereist het de roloptie `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Tot en met 7.2.0 was de optie alleen `extendedTokenExpiration`. Een rol van vóór 7.3.0 die alleen die optie instelt, krijgt
+`allowApiTokens`, zodat ze haar tokens houdt; met beide kan ook een token worden gemaakt dat nooit verloopt. Zie [Rolopties](../config/roles.html#role-options).
+
+---
+
+## Een token maken
+
+**Nieuw token**, op de titelregel van **Profiel > API-tokens**, opent een wizard in drie stappen:
+
+1. **Details**: een naam, zodat je het token in de lijst herkent, en hoe lang het geldig blijft. De keuzes zijn 30, 90, 180
+   of 365 dagen tot [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (standaard 90), dat
+   maximum zelf, en **Verloopt nooit** met `extendedTokenExpiration`. Kies de kortste periode die je script nodig heeft.
+2. **Bevestigen**: een lokaal account of een LDAP-account voert zijn wachtwoord in, dat niet in het token wordt opgeslagen. Een account van Microsoft Entra ID of
+   OIDC heeft hier geen wachtwoord: zijn token wordt gemaakt vanuit zijn sessie, waarin hooguit 10 minuten eerder moet zijn aangemeld,
+   dus de provider kan je vragen eerst opnieuw aan te melden.
+3. **Kopiëren**: het token, **maar één keer** getoond. Kopieer het met **Kopiëren** en bewaar het net zo veilig als een wachtwoord.
+
+Stuur het token mee in de `Authorization`-header van elke API-aanroep:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Een API-token kan geen ander token maken. Het token van een SSO-account draagt de rollen van zijn laatste aanmelding: een groepswijziging bij de
+identiteitsprovider bereikt het pas wanneer je opnieuw aanmeldt en een nieuw token maakt.
+
+---
+
+## Je tokens
+
+De tokens die je hebt gemaakt, staan in een lijst met hun naam en wanneer elk is gemaakt, verloopt en voor het laatst is gebruikt; **Intrekken** in het menu van een rij beëindigt er een.
+Een admin ziet ze ook op jouw pagina onder **Instellingen > Gebruikers** en kan ze daar intrekken. Een token eindigt wanneer het verloopt, of eerder:
+
+- **door intrekken**, vanuit de lijst;
+- **door afmelden met het token** (`POST /api/v2/auth/logout` met het token in de `Authorization`-header), wat het beëindigt samen met
+  de sessie waarin het is gemaakt;
+- **door een wachtwoordwijziging**, die elk token en elke sessie van je account beëindigt die daarvoor zijn gemaakt, en door een blokkering van je account.
+
+Ook een token dat nooit verloopt, eindigt in deze gevallen. Een script kan ook zelf een token aanvragen via de login-API en
+de parameter `expiryDays` (`POST /api/v2/auth/login?expiryDays=90`, of `expiryDays=never`); een langere `expiryDays` wordt ingekort
+tot `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/nl/_use/profile/index.md b/i18n/nl/_use/profile/index.md
new file mode 100644
index 0000000..74aff67
--- /dev/null
+++ b/i18n/nl/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: Je profiel
+nav_order: 4
+description: Je account, voorkeuren, wachtwoord, rechten en API-tokens
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# Je profiel
+{: .no_toc }
+
+Je account, voorkeuren, wachtwoord, rechten en API-tokens
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Voor elke gebruiker: je eigen account, voorkeuren, wachtwoord, rechten en API-tokens.
+
+Open je profiel via de avatar rechtsboven: **Profiel**.
+
+---
+
+## Een weergave openen
+
+Het linkermenu toont de weergaven van het profiel in alfabetische volgorde. Elke weergave heeft een eigen adres,
+zodat je er rechtstreeks naar kunt linken:
+
+| Weergave | Adres |
+|---|---|
+| Account | `/profile/account` |
+| API-tokens | `/profile/token` |
+| Wachtwoord | `/profile/password` |
+| Rechten | `/profile/permissions` |
+| Voorkeuren | `/profile/preferences` |
+
+`/profile` alleen opent de eerste weergave van het menu. Weergaven die je rollen niet toestaan, zijn verborgen; hun adres opent in plaats daarvan de eerste
+weergave. **API-tokens** wordt alleen getoond wanneer een van je rollen de roloptie `allowApiTokens` heeft.
+
+---
+
+## In deze sectie
+
+Elk onderwerp staat op een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Account](account.html) | Als wie je bent aangemeld |
+| [Voorkeuren](preferences.html) | Taal, thema, tijdzone, datumnotatie en bureaubladmeldingen |
+| [Wachtwoord](password.html) | Het wachtwoord van een lokaal account wijzigen |
+| [Rechten](permissions.html) | Wat je rollen je toestaan |
+| [API-tokens](api-token.html) | Een token maken voor scripts en AI-agents |
diff --git a/i18n/nl/_use/profile/password.md b/i18n/nl/_use/profile/password.md
new file mode 100644
index 0000000..f7e7f34
--- /dev/null
+++ b/i18n/nl/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Wachtwoord
+parent: Je profiel
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Wachtwoord
+{: .no_toc }
+
+Het wachtwoord van een lokaal account wijzigen
+{: .fs-6 .fw-300 }
+
+---
+
+Voer je huidige wachtwoord in en twee keer het nieuwe, en klik dan op **Wachtwoord wijzigen**.
+
+Accounts van LDAP, Entra ID en OpenID Connect wijzigen hun wachtwoord in plaats daarvan bij die provider.
diff --git a/i18n/nl/_use/profile/permissions.md b/i18n/nl/_use/profile/permissions.md
new file mode 100644
index 0000000..60acbe4
--- /dev/null
+++ b/i18n/nl/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Rechten
+parent: Je profiel
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Rechten
+{: .no_toc }
+
+Wat je rollen je toestaan
+{: .fs-6 .fw-300 }
+
+---
+
+De rolopties zijn gegroepeerd in tabbladen, elk met het aantal opties dat je ervan hebt, zoals `5/8`:
+
+| Tabblad | Opties over |
+|---|---|
+| **Toegang en integraties** | Aanmelden, de chatassistent, de MCP-server, bestandsuploads en API-tokens |
+| **Ontwerper** | De ontwerper openen, en formulieren, playbooks, workflows, inventarissen en variabelenbestanden bewerken |
+| **Jobs** | Jobs en hun extravars of artifacts zien, jobs herstarten, verwijderen, plannen en opslaan |
+| **Instellingen** | De instellingenpagina's, de logs, het auditlogboek en back-ups |
+| **Overig** | Een optie die met de hand in een rol is gezet en in geen ander tabblad staat; altijd het laatste tabblad |
+
+De andere tabbladen staan in alfabetische volgorde. Elk tabblad is een tabel met de kolommen **Instelling** (de optie), **Omschrijving**
+(wat ze doet) en **Jouw toegang**: **Toegestaan** of **Niet toegestaan**. Een optie die geldt vanwege een andere optie, zegt dat
+onder haar omschrijving: **Inbegrepen in** een optie die je hebt, zet haar aan, en **Vereist** een optie die je mist, houdt haar uit.
+
+Opties komen uit de `options` van je rollen in `config.yaml`; de pagina [Rollen](../config/roles.html) legt uit hoe
+ze worden gecombineerd.
diff --git a/i18n/nl/_use/profile/preferences.md b/i18n/nl/_use/profile/preferences.md
new file mode 100644
index 0000000..2699f49
--- /dev/null
+++ b/i18n/nl/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Voorkeuren
+parent: Je profiel
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Voorkeuren
+{: .no_toc }
+
+Taal, thema, tijdzone, datumnotatie en bureaubladmeldingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De voorkeuren
+
+De weergave Voorkeuren verandert hoe AnsibleForms er voor jou uitziet. Elke keuze wordt bewaard in de browser
+waarin je haar maakt, dus een andere browser of computer begint met de standaardwaarden.
+
+| Instelling | Keuzes | Ook in te stellen via |
+|---|---|---|
+| Taal | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (Japans), 简体中文 (vereenvoudigd Chinees) | de vlag in de kopbalk |
+| Thema | Browser volgen, Licht, Donker, of Kleur (een kopbalk in een kleur naar keuze) | het zonicoon in de kopbalk |
+| Weergave formulieren | Tegels of Lijst | de knop op de pagina Formulieren |
+| Tijdzone | UTC, de zone van deze browser, of elke zone op naam | alleen hier |
+| Datumnotatie | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` of `DD.MM.YYYY` | alleen hier |
+| Bureaubladmeldingen | Aan of uit | alleen hier |
+
+Vanaf 7.3.0 bestaat de weergave uit tabbladen, elk met een eigen adres (`/profile/preferences/<tab>`): **Weergave** (taal, thema en weergave
+formulieren), **Datum en tijd** (tijdzone en datumnotatie) en **Meldingen**. Het zoekvak erboven toont de instellingen die overeenkomen,
+onder de naam van hun tabblad. Een keuze is een concept tot **Opslaan**, en wie de weergave verlaat met een niet-opgeslagen wijziging, krijgt eerst een vraag.
+
+**Browser volgen** wordt licht of donker zoals de browser, en verandert mee. Het is vanaf 7.3.0 het standaardthema, tenzij je
+beheerder een ander kiest. Beweeg je over een kleur van het thema **Kleur**, hier of in het themamenu van de kopbalk, dan zie je de app vooraf in die
+kleur, en het vorige thema komt terug wanneer de aanwijzer het palet verlaat; er verandert niets tot je klikt.
+
+---
+
+## Bureaubladmeldingen
+
+Vanaf 7.3.0 zet het tabblad **Meldingen** bureaubladmeldingen in deze browser aan, voor gebruikers van wie de rol `showJobs` instelt.
+
+De browser vraagt de eerste keer om toestemming. Blokkeert hij meldingen voor de site, dan blijft de schakelaar uit en staat erbij hoe je ze
+toestaat, en een site op gewone `http` kan ze helemaal niet tonen. Staat het aan, dan komt er een melding:
+
+| Wanneer | Wat ze zegt | Een klik erop |
+|---|---|---|
+| Een job die je startte, eindigt | Het formulier en de uitkomst, zoals *Patch Linux servers: Geslaagd*, met het jobnummer en de duur | Brengt het tabblad naar voren op die job |
+| Een job wacht op jouw goedkeuring | Het formulier, het jobnummer en wie hem startte, met de knoppen **Goedkeuren** en **Afwijzen** | Opent de jobs die op goedkeuring wachten |
+
+De knoppen **Goedkeuren** en **Afwijzen** verschijnen in Chrome en Edge; Firefox en Safari tonen de melding zonder die knoppen, en dat geldt ook voor een
+site met een zelfondertekend certificaat, omdat de knoppen een service worker nodig hebben. Meldingen komen alleen zolang er een tabblad van AnsibleForms open is,
+ook op de achtergrond: zodra elk tabblad is gesloten, wordt er niets meer gestuurd. Elke melding verschijnt één keer, hoeveel tabbladen er ook open zijn, en de stappen van een
+multistep-job en de job die je aan het bekijken bent, blijven stil.
+
+---
+
+## Tijdzone
+
+Datums en tijden in heel AnsibleForms worden getoond in de tijdzone die je kiest. Dat geldt ook voor de start-
+en eindtijden van jobs, het auditlogboek, de statuspagina, back-ups, opgeslagen jobs en het verlopen van een API-token.
+Een andere tijdzone kiezen werkt elke pagina meteen bij, zonder herladen.
+
+Tot je er een kiest, geldt de tijdzone die je beheerder voor iedereen heeft ingesteld (**Instellingen > Uiterlijk > Standaardwaarden**, zie
+[Uiterlijk](../appearance.html)), **UTC** tenzij gewijzigd. **Deze browser** volgt de tijdzone van je computer, en de
+lijst bevat elke zone op naam, zoals `Europe/Madrid`. De kaart toont de huidige tijd in de gekozen zone en notatie.
+
+---
+
+## Datumnotatie
+
+De datumnotatie bepaalt hoe het datumdeel van elke datum wordt getoond, elke keuze met de datum van vandaag als voorbeeld: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` of `DD.MM.YYYY`. Tot je er een kiest, geldt de standaard datumnotatie van je beheerder,
+`YYYY-MM-DD` tenzij gewijzigd. Net als de andere keuzes wordt die in deze browser bewaard.
+
+---
+
+## Wat de tijden van de server houdt
+
+Twee uitzonderingen houden de eigen tijden van de server:
+
+- **Het serverlog en de joboutput** zijn tekst met de tijden die de server erin schreef.
+- **Tijden die je invoert**, zoals wanneer een geplande job moet draaien, en cron-schema's, werken zoals
+  voorheen.
diff --git a/i18n/nl/_use/repositories/adding.md b/i18n/nl/_use/repositories/adding.md
new file mode 100644
index 0000000..978e0af
--- /dev/null
+++ b/i18n/nl/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Een repository toevoegen
+parent: Git-repositories
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Een repository toevoegen
+{: .no_toc }
+
+De pagina Repositories, elk veld van een repository, en er een declareren in de config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## De pagina Repositories
+
+Repositories worden beheerd onder **Instellingen > Verbindingen > Repositories**, waarvoor de [roloptie](../config/roles.html#role-options) `showSettings` of, vanaf 7.3.0,
+`showConnectionsSettings` nodig is. Sommige wijzigingen zijn alleen voor een admin, zie [hieronder](#who-may-change-a-repository).
+
+![Repositories](../assets/screenshots/git.jpg)
+
+De lijst toont **Naam**, **Beschrijving**, **Branch**, **Head** (de korte hash van de uitgecheckte commit), **Pull** en
+**Push**. Het tabblad **Details** van een repository toont dezelfde badges Pull en Push boven de head:
+
+| Kolom | Wat ze zegt |
+|---|---|
+| **Pull** | De laatste clone, pull of reset: **Bezig** terwijl git werkt, daarna **Geslaagd** of **Mislukt**; een streepje vóór de eerste |
+| **Push** | **Mislukt** wanneer de laatste push mislukte; **Openstaande wijzigingen** wanneer wijzigingen die hier, door de ontwerper, zijn opgeslagen nog niet naar de remote zijn gepusht; **Geslaagd** wanneer er niets wacht; een streepje vóór de eerste push |
+
+**Geslaagd** in de kolom Push betekent alleen dat er niets wacht om te worden gepusht: de remote kan nog nieuwere commits hebben die een
+pull binnenhaalt. Het menu van elke rij bevat deze acties:
+
+| Actie | Wat ze doet |
+|---|---|
+| **Bewerken** | De velden hieronder wijzigen |
+| **Pull** | De repository klonen, of pullen als de working tree al bestaat |
+| **Push** | De working tree committen en pushen; alleen bij repositories die voor formulieren, configuratie, playbooks, workflows of inventarissen worden gebruikt, en alleen beschikbaar zolang er wijzigingen zijn die nog niet zijn gepusht |
+| **Resetten** | De working tree verwijderen en opnieuw klonen, waarbij lokale wijzigingen verloren gaan |
+| **Referenties wijzigen** | Het tabblad **Referenties** van de repository openen, om de referentie te kiezen die git gebruikt |
+| **Uitvoer van laatste pull tonen** | De uitvoer van git bij de laatste clone, pull of reset tonen, met het wachtwoord gemaskeerd |
+| **Uitvoer van laatste push tonen** | De uitvoer van git bij de laatste push tonen, met het wachtwoord gemaskeerd |
+| **Verwijderen** | Het record en de working tree onder `REPO_PATH` verwijderen; alleen voor een admin |
+
+**Alles pullen**, boven de lijst, pullt alle repositories tegelijk.
+
+Er draait maar één git-bewerking tegelijk op een repository. Een tweede wordt geweigerd met
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Een repository toevoegen
+
+Klik op **Repository toevoegen**: een wizard vraagt de velden in vier stappen (**Repository**, **Referenties**, **Gebruik**, **Pull-schema**),
+en AnsibleForms start de clone op de achtergrond zodra je opslaat.
+
+![Edit Repository](../assets/screenshots/git-edit.jpg)
+
+| Veld | Verplicht | Betekenis |
+|---|---|---|
+| **Naam** | ja | De mapnaam onder `REPO_PATH`; letters, cijfers, streepje, underscore en punt |
+| **Branch** | ja | De branch om te klonen, te pullen en te pushen, bijvoorbeeld `main`; verplicht vanaf 7.3.0. Alleen een repository uit de config seed mag hem weglaten, om de standaardbranch van de remote te klonen |
+| **Referentie** | nee | Een referentie uit [Verbindingen > Inloggegevens](../credentials.html) met de gebruiker en het wachtwoord of token die git gebruikt; **Referentie toevoegen** maakt er een aan |
+| **Uri** | ja | De remote, `https://...` of SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Geplande pull inschakelen** | nee | De repository volgens een schema pullen |
+| **Pull-schema** | nee | Wanneer er wordt gepulld, als cron-expressie; zichtbaar zodra de geplande pull is ingeschakeld |
+| **Beschrijving** | ja | Een vrije beschrijving |
+| **Gebruiken voor configuratie?** ... **Gebruiken voor inventarissen?** | nee | Wat de repository bevat, zie [hierboven](./#what-a-repository-is-for) |
+| **Pullen bij het starten van de app** | nee | De repository klonen, of pullen, telkens als AnsibleForms start |
+
+Een repository hernoemen verplaatst de working tree naar de nieuwe map en neemt het pull-schema mee. Een repository van
+vóór 7 die nog een eigen gebruiker heeft, meldt dat op het tabblad **Referenties**: kies een referentie om die te vervangen.
+
+---
+
+## Wie een repository mag wijzigen
+
+De inhoud van een repository wordt wat AnsibleForms laadt en uitvoert, dus vanaf 7.3.0 kan een gebruiker zonder de rol `admin` niet langer:
+
+- een repository toevoegen of verwijderen;
+- de **Uri** of de **Branch** ervan wijzigen;
+- een van de schakelaars **Gebruiken voor** aan- of uitzetten.
+
+Hij kan nog wel de beschrijving, het pull-schema en de referentie wijzigen, en de repository pullen, pushen of resetten. Een referentie die een runner,
+een verbinding of een aanmelding gebruikt, kan hij niet kiezen; de weigering noemt haar, en zegt niets over wat ze bevat.
+
+---
+
+## Repositories declareren in de config seed
+
+Repositories kunnen ook in de [config seed](../seed/) worden gedeclareerd, zodat een nieuwe instantie ze bij haar eerste start kloont.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+De velden zijn die van de pagina, inclusief `credential` (een referentie uit de seed of uit de app), `rebase_on_start` (**Pullen bij het starten
+van de app**) en `cron` (het pull-schema); `user` en `password` worden nog geaccepteerd in plaats van een referentie. Een
+repository uit de seed is in de interface alleen-lezen, en wordt bij het starten opnieuw gekloond als de working tree ontbreekt; zie
+[Beheerde objecten](../seed/managed-objects.html).
diff --git a/i18n/nl/_use/repositories/authentication.md b/i18n/nl/_use/repositories/authentication.md
new file mode 100644
index 0000000..d283468
--- /dev/null
+++ b/i18n/nl/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Authenticatie
+parent: Git-repositories
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Authenticatie
+{: .no_toc }
+
+HTTPS met een token, SSH met de gegenereerde sleutel, en eigen git-commando's
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Authenticatie
+
+Hoe AnsibleForms zich authenticeert, hangt af van de vorm van de **Uri**.
+
+### HTTPS met een token
+
+Kies voor een private HTTPS-remote een **Referentie** waarvan de gebruiker de git-gebruiker is en het wachtwoord een personal access token
+(of het wachtwoord).
+
+Vanaf 7.3.0 meldt git zich aan via `GIT_ASKPASS`: de gebruiker en het token gaan naar elk git-commando dat met de server praat, nooit in
+de URL, dus ze blijven niet in `.git/config` van de clone staan en een gewijzigd token wordt bij de volgende pull of push gebruikt. Het token heeft
+leestoegang nodig om te pullen, en schrijftoegang om te pushen. Een openbare remote heeft geen referentie nodig.
+
+Tot en met 7.2.0 werden beide in de URL gezet, als `https://<user>:<token>@git.example.com/team/forms.git`. Een clone die toen is gemaakt, houdt
+die URL tot zijn volgende pull of push, die zijn remote terugzet naar de eigen **Uri** van de repository.
+
+### SSH met de gegenereerde sleutel
+
+Voor een SSH-remote authenticeert AnsibleForms zich met een eigen sleutelpaar, dat het bij de eerste start genereert.
+
+1. Open **Instellingen > Verbindingen > SSH**, op het tabblad **Sleutel**, en kopieer de **Publieke sleutel**.
+2. Voeg hem toe op de git-server, als deploy key van de repository (met schrijftoegang als je pusht), of bij een gebruiker met toegang.
+3. Voeg de repository toe met een SSH-**Uri**, bijvoorbeeld `git@git.example.com:team/forms.git`, en kies geen referentie.
+
+Het sleutelpaar staat in `.ssh/id_rsa` onder [`HOME_PATH`](../customization/paths.html#env_HOME_PATH), dus houd die map op
+persistente opslag, anders verandert de sleutel wanneer de container opnieuw wordt aangemaakt.
+
+Bij een clone met een Uri van de vorm `user@host:path` voert AnsibleForms eerst `ssh-keyscan` uit op de host en voegt het de sleutel toe aan de
+known hosts. Voeg voor andere remotes de host toe op het tabblad **Known hosts** van **Instellingen > Verbindingen > SSH**, vóór de
+eerste clone.
+
+### Eigen git-commando's
+
+De commando's voor clone, pull en push kunnen worden vervangen, bijvoorbeeld om git-opties toe te voegen, met drie instellingen.
+
+| Instelling | Standaard | Wat AnsibleForms toevoegt |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, de Uri en de naam |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+Vanaf 7.3.0 draaien deze commando's zonder shell: aanhalingstekens werken, maar een shell-operator zoals `;`, `|`, `&&` of `>` wordt geweigerd.
diff --git a/i18n/nl/_use/repositories/designer.md b/i18n/nl/_use/repositories/designer.md
new file mode 100644
index 0000000..b601e3a
--- /dev/null
+++ b/i18n/nl/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Ontwerper en push
+parent: Git-repositories
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Ontwerper en push
+{: .no_toc }
+
+Formulieren bewerken in de ontwerper en ze naar de repository pushen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Bewerken en pushen vanuit de ontwerper
+
+Met een repository die voor formulieren wordt gebruikt, bewerkt de ontwerper de bestanden in haar working tree en pusht hij ze terug naar de remote.
+
+| Knop | Wat ze doet |
+|---|---|
+| **Opslaan (lokaal)** | Schrijft de formulieren en `config.yaml` naar de working trees, zonder te committen |
+| **Opslaan (repository)** | Commit en pusht de opgeslagen wijzigingen; beschikbaar zodra er wijzigingen zijn die nog niet zijn gepusht |
+| **Laden (repository)** | Pullt de formulierenrepositories en laadt de ontwerper opnieuw, na een bevestiging als er niet-opgeslagen wijzigingen zijn |
+
+Formulieren blijven in hun repository; nieuwe wachten, al bruikbaar, in [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) tot je pusht.
+Een formulier dat in een submap is opgeslagen, houdt zijn relatieve pad: `team/deploy.yaml` wordt gepusht naar `team/deploy.yaml` onder de formulierenmap
+van de repository. Een nieuw formulier waarvan het pad daar al bestaat, wordt niet overschreven; het blijft in staging, dus geef het een andere naam.
+Met meerdere formulierenrepositories vragen **Opslaan (repository)** en **Laden (repository)** welke, met als standaard die met `config.yaml`.
+
+Een push zet alle wijzigingen klaar, commit ze als `AnsibleForms` met het bericht `Forms sync by <user>`, en doet daarna een fetch, een rebase op
+de remote en een push, met tot vijf nieuwe pogingen. Een rebaseconflict wordt afgebroken en de bestanden met een conflict worden opgesomd;
+los ze op in de remote, of gebruik **Resetten** op de pagina Repositories. **Push** op de pagina Repositories doet hetzelfde.
+
+Wordt één enkele formulierenrepository leeg gekloond, dan kopieert AnsibleForms de lokale `config.yaml` en formulieren naar haar working
+tree, zodat een push (**Opslaan (repository)**, of **Push** op de pagina Repositories) ze publiceert. Meer over de ontwerper staat in [Ontwerper en git](../gui/designer-and-git.html).
diff --git a/i18n/nl/_use/repositories/index.md b/i18n/nl/_use/repositories/index.md
new file mode 100644
index 0000000..a524714
--- /dev/null
+++ b/i18n/nl/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Git-repositories
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Git-repositories
+{: .no_toc }
+
+Bewaar formulieren, variabelenbestanden, configuratie en playbooks in git
+{: .fs-6 .fw-300 }
+
+---
+
+Voor beheerders die formulieren, configuratie en playbooks in git bewaren: wat een repository kan bevatten en welke bron wint.
+
+---
+
+## Waarvoor een repository dient
+
+Een repository is een git-remote die AnsibleForms kloont en bijwerkt, en elke repository heeft schakelaars die zeggen wat ze bevat:
+
+| Schakelaar | Wat AnsibleForms eruit leest | Map in de repository |
+|---|---|---|
+| **Gebruiken voor configuratie?** | `config.yaml` met de categorieën, rollen en constanten | de root |
+| **Gebruiken voor formulieren?** | De formulierbestanden, die de ontwerper er ook in terug opslaat, en hun variabelenbestanden | `forms`, of de root; variabelenbestanden in `vars` |
+| **Gebruiken voor playbooks?** | De Ansible-playbooks die jobs uitvoeren | `playbooks`, of de root |
+| **Gebruiken voor workflows?** | De [workflow](../workflows/)bestanden, die de ontwerper er ook in terug opslaat | elke map |
+| **Gebruiken voor inventarissen?** | Eén inventaris, genoemd naar de repository, waarnaar een formulier verwijst met `inventory:` | de root: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Zonder de submap wordt de root van de repository gebruikt. Eén repository kan alles bevatten; verdeel je het, dan mogen alleen **Gebruiken voor
+formulieren**, **Gebruiken voor workflows** en **Gebruiken voor inventarissen** op meerdere repositories aanstaan: de andere schakelaars nemen de eerste repository
+en loggen een waarschuwing.
+
+Elke repository wordt gekloond in een submap met haar naam, onder [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Eén repository voor alles
+
+Eén repository kan formulieren, variabelenbestanden, configuratie en playbooks bevatten, met de schakelaars aan en één submap per soort.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Eén repository per doel
+
+Met afzonderlijke repositories kunnen teams hun eigen deel beheren, met elk één schakelaar en de bestanden direct in de root.
+
+| Repository | Schakelaar | Inhoud in de root |
+|---|---|---|
+| `af-config` | **Gebruiken voor configuratie?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Gebruiken voor formulieren?** | De formulierbestanden van elk team, samengevoegd tot één lijst |
+| `af-playbooks` | **Gebruiken voor playbooks?** | De playbooks en rollen |
+
+Alleen formulieren kunnen uit meerdere repositories komen; configuratie en playbooks komen elk uit één. De variabelenbestanden komen uit de map `vars`
+van de eerste formulierenrepository die er een heeft.
+
+---
+
+## Hoe repositories samengaan met lokale mappen
+
+De inhoud van een repository vervangt de bijbehorende lokale map; deze tabel vat samen waar elk soort bestand vandaan wordt gelezen.
+
+| Inhoud | Gelezen uit, de eerste treffer wint |
+|---|---|
+| Configuratie | 1. de database, wanneer de configuratie daar wordt bewaard ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. `config.yaml` van de repository met **Gebruiken voor configuratie** <br> 3. `config.yaml` van een repository met **Gebruiken voor formulieren**, wanneer geen repository voor configuratie wordt gebruikt <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formulieren | Elke repository met **Gebruiken voor formulieren** plus `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) alleen als er geen is |
+| Playbooks | De repository met **Gebruiken voor playbooks**, anders [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Variabelenbestanden | De map `vars` van de eerste repository met **Gebruiken voor formulieren** die er een heeft, anders [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflows | Elke repository met **Gebruiken voor workflows** plus [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), samen |
+
+Formulieren uit meerdere repositories worden samengevoegd tot één lijst. Bevatten twee ervan een formulier met dezelfde naam, dan blijft het eerst
+geladen formulier behouden en wordt de waarschuwing `skipping duplicate form <name>` gelogd, dus houd formuliernamen uniek over alle repositories.
+
+---
+
+## Probleemoplossing
+
+De meeste problemen zie je in de kolom **Pull** en in **Uitvoer van laatste pull tonen** (of **Uitvoer van laatste push tonen**), die de eigen
+foutmelding van git bevatten.
+
+- [Een clone of pull van een repository is mislukt](../troubleshooting.html#a-repository-clone-or-pull-failed): authenticatie, known
+  hosts en lokale wijzigingen.
+- [De formulierenrepository is nog niet gekloond](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): de ontwerper
+  kan niet opslaan vóór de eerste clone.
+- Een repository die vastzit in `running`, wordt teruggezet naar `failed`: na een herstart, bij de volgende start; binnen een minuut zodra het knooppunt
+  dat zijn git-bewerking uitvoert 2 minuten niet meer antwoordt; en in elk geval na 2 uur. Voer **Pull** opnieuw uit.
+
+---
+
+## In deze sectie
+
+Elk onderwerp heeft een eigen pagina:
+
+| Pagina | Wat er aan bod komt |
+|---|---|
+| [Een repository toevoegen](adding.html) | De pagina Repositories, elk veld van een repository, en er een declareren in de config seed |
+| [Authenticatie](authentication.html) | HTTPS met een token, SSH met de gegenereerde sleutel, en eigen git-commando's |
+| [Wijzigingen pullen](pulling.html) | Geplande, handmatige en API-pulls, en lokale wijzigingen |
+| [Ontwerper en push](designer.html) | Formulieren bewerken in de ontwerper en ze naar de repository pushen |
diff --git a/i18n/nl/_use/repositories/pulling.md b/i18n/nl/_use/repositories/pulling.md
new file mode 100644
index 0000000..3df2c13
--- /dev/null
+++ b/i18n/nl/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Wijzigingen pullen
+parent: Git-repositories
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Wijzigingen pullen
+{: .no_toc }
+
+Geplande, handmatige en API-pulls, en lokale wijzigingen
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wijzigingen pullen
+
+Een repository wordt gepulld volgens haar schema, bij het starten, vanaf de pagina of via de API; er is geen webhook-endpoint.
+
+| Aanleiding | Hoe |
+|---|---|
+| Schema | **Geplande pull inschakelen** en een **Pull-schema**, bijvoorbeeld `0 * * * *` voor elk uur |
+| Start | **Pullen bij het starten van de app** kloont de repository, of pullt haar als ze al gekloond is |
+| Instellingenpagina | **Pull** in het menu van de rij, of **Alles pullen** boven de lijst |
+| Ontwerper | **Laden (repository)**, dat de formulierenrepositories pullt en de ontwerper opnieuw laadt; het nemen van de vergrendeling van de ontwerper pullt ook eerst elke formulierenrepository |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` of `showConnectionsSettings`) of `POST /api/v2/forms-repos/pull/<name>` (zie hieronder) |
+
+### Pullen vanuit een pipeline of een webhook
+
+AnsibleForms heeft geen aparte webhook-ontvanger, maar een CI-job of een webhook van een git-server kan het pull-endpoint aanroepen.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Maak het token aan zoals beschreven in [API-tokens](../profile/api-token.html), voor een gebruiker van wie de rol `showSettings` of
+`showConnectionsSettings` heeft. `/api/v2/forms-repos/pull/<name>` vereist in plaats daarvan `showDesigner` en `allowFormDesign`, met de ontwerper
+ingeschakeld ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` geeft de
+`head`, `status` en `output` terug, zodat een pipeline kan controleren welke commit de instantie na een pull draait.
+
+### Lokale wijzigingen
+
+Een pull overschrijft nooit werk dat nog niet is gepusht, dus een geplande pull controleert de working tree voordat hij draait.
+
+Een geplande pull wordt overgeslagen zolang de working tree niet-gecommitte wijzigingen of niet-gepushte commits heeft, en zolang een ontwerper
+de vergrendeling van de ontwerper heeft. Een handmatige pull van een working tree met conflicterende wijzigingen mislukt met:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Push de wijzigingen, of gooi ze weg met **Resetten** in het menu van de rij, dat de working tree verwijdert en opnieuw kloont.
diff --git a/i18n/nl/index.md b/i18n/nl/index.md
new file mode 100644
index 0000000..e44e14b
--- /dev/null
+++ b/i18n/nl/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Home
+nav_order: 1
+description: "AnsibleForms: bouw dynamische, datagedreven formulieren voor automatisering met Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Selfserviceformulieren voor <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible is een krachtige automatiseringstool, maar het blijft een commandoregelapplicatie, en AWX/AAP/Ascender mist
+      formulieren die gegevens uit meerdere bronnen verzamelen. Met AnsibleForms bouw je dynamische, datagedreven formulieren, genereer je extravars
+      en stuur je die naar Ansible, AWX/AAP/Ascender, Semaphore, Rundeck of Jenkins om daar templates uit te voeren.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">AnsibleForms installeren</a>
+      <a href="first-form.html" class="btn btn-outline">Bouw je eerste formulier</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="Het dashboard van AnsibleForms">
+  </div>
+</div>
+
+## Mogelijkheden
+
+Wat AnsibleForms toevoegt aan je Ansible-omgeving, en wat één formulier kan doen:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Applicatie</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Automatiseringsplatforms</strong><span>Playbooks op RTE's, templates op Ascender, Semaphore en meer</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Toegangsbeheer</strong><span>Rollen en rolopties, met lokale, LDAP-, Entra ID- en OIDC-aanmeldingen</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Planning</strong><span>Voer een formulier later uit, of volgens een cron-schema</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Jobgeschiedenis</strong><span>Jobs volgen, afbreken en opnieuw starten</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Inloggegevens en secrets</strong><span>Sla inloggegevens op, of lees ze uit Vault of CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Git-repositories</strong><span>Bewaar formulieren, playbooks en configuratie in Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Ontwerper</strong><span>Bewerk formulieren als YAML, met validatie</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP en chat</strong><span>Start formulieren vanuit scripts, AI-agents of een chat</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formulieren</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Trapsgewijze keuzelijsten</strong><span>Keuzelijsten die reageren op andere velden</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Expressies en gegevensbronnen</strong><span>Vul velden vanuit databases, REST API's, bestanden en JavaScript</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Veldafhankelijkheden</strong><span>Toon of verberg velden op basis van andere velden</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validatie</strong><span>Min, max, regex en meer, desgewenst gecontroleerd op de server</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflows en wizardformulieren</strong><span>Koppel playbooks en goedkeuringen aan elkaar, of verdeel invoer over pagina's</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Gestructureerde velden</strong><span>Lijsten en objecten op basis van herbruikbare subformulieren</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Goedkeuringspunten</strong><span>Zet een job stil tot iemand hem goedkeurt</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Meldingen</strong><span>Mail, Slack, Teams, Telegram of een webhook bij jobgebeurtenissen</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Hulp nodig?
+
+Vragen, bugs en beveiligingsmeldingen hebben elk hun eigen plek:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Probleemoplossing</strong>
+    <span>Zoek een foutmelding op en lees hoe je die oplost</span>
+    <span class="af-card-more">Probleemoplossing &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Een vraag stellen</strong>
+    <span>Vraag het de community en de maintainers</span>
+    <span class="af-card-more">Discussions &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Een bug melden</strong>
+    <span>Open een issue met de stappen om het te reproduceren</span>
+    <span class="af-card-more">Nieuw issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Hulp krijgen</strong>
+    <span>Wat je moet meesturen, en hoe je een beveiligingsprobleem meldt</span>
+    <span class="af-card-more">Hulp krijgen &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/pl.yml b/i18n/pl.yml
new file mode 100644
index 0000000..1ac2eac
--- /dev/null
+++ b/i18n/pl.yml
@@ -0,0 +1,42 @@
+# The Polish docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: pl
+docs_language: "pl"
+
+title: "Dokumentacja AnsibleForms"
+description: "Dokumentacja techniczna AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Wszelkie prawa zastrzeżone."
+
+# "Edit this page on GitHub" opens the Polish page's source
+gh_edit_link_text: "Edytuj tę stronę w GitHub"
+gh_edit_source: i18n/pl
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Wprowadzenie"
+    get_started:
+      name: "Pierwsze kroki"
+    configure:
+      name: "Konfiguracja"
+    build_forms:
+      name: "Tworzenie formularzy"
+    use:
+      name: "Podręcznik użytkownika"
+    integrate:
+      name: "Integracje"
+    security_assessment:
+      name: "Bezpieczeństwo"
+    reference:
+      name: "Dokumentacja referencyjna"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (najnowsza)"
+    url: "/pl/"
+  - name: "6"
+    title: "6.x (po angielsku)"
+    url: "/v6/"
diff --git a/i18n/pl/_build_forms/expressions/credentials.md b/i18n/pl/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..598da8f
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Poświadczenia
+parent: Wyrażenia
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Poświadczenia
+{: .no_toc }
+
+Odczyt zapisanego poświadczenia w wyrażeniu
+{: .fs-6 .fw-300 }
+
+---
+
+Odczytaj zapisane poświadczenie po nazwie lub wyrażeniu regularnym, z wartością zapasową:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Najpierw sprawdzana jest dokładna nazwa. Gdy żadne poświadczenie nie ma takiej nazwy, nazwa jest traktowana jako wyrażenie regularne, a potem sprawdzana jest wartość zapasowa.
+
+#### Ograniczenie przez rolę
+
+Gdy jedna z ról użytkownika ma listę `credentials` w `config.yaml`, `fn.fnCredentials` zwraca tylko poświadczenie, na które taka rola
+pozwala: wzorce roli są porównywane z nazwą znalezionego poświadczenia (po nazwie, wyrażeniu regularnym lub wartości zapasowej),
+a każde inne jest odrzucane. Role bez tej listy go nie ograniczają, a administrator nigdy nie jest ograniczony.
+
+#### Poświadczenia z magazynu sekretów
+
+Poświadczenie, które wskazuje [magazyn sekretów](../secret-stores), pobiera swoje `user` i `password`
+z tego magazynu w czasie działania. `fn.fnCredentials('myapp')` działa dalej bez zmian.
+
+Sekret można też odczytać bez wiersza poświadczenia, wszędzie tam, gdzie przyjmowana jest nazwa poświadczenia
+(w tym w `fnRestBasic`, `fnRestJwtSecure` i podstawieniach nagłówków w `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+Klucze sekretu są mapowane tak, jak opisano w [Nazwy kluczy](../secret-stores#key-names).
+Sekret o innym kształcie przekształca się wyrażeniem `jq` podanym jako trzeci argument:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/pl/_build_forms/expressions/index.md b/i18n/pl/_build_forms/expressions/index.md
new file mode 100644
index 0000000..967737f
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Wyrażenia
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Wyrażenia
+{: .no_toc }
+
+Obliczaj wartości pól w JavaScript, w przeglądarce lub na serwerze
+{: .fs-6 .fw-300 }
+
+---
+
+Dla autorów formularzy: wypełniaj pola dynamicznie za pomocą JavaScriptu, obliczając je w przeglądarce lub pobierając na serwerze.
+
+Atrybut `expression` pola formularza pozwala tworzyć dynamiczne formularze z wyrażeniami JavaScript.
+
+---
+
+## Wprowadzenie
+
+Atrybut `expression` jest dostępny w kilku typach pól:
+- pole `enum` - do dynamicznego wypełniania opcji listy rozwijanej
+- pole `expression` - do pobierania lub generowania dowolnych danych
+- pole `html` - do budowania jego treści HTML
+- pola `yaml` i `list` - do wypełniania ich danych
+
+Wyrażenia JavaScript są obliczane albo **po stronie serwera** (domyślnie), albo **po stronie klienta**, zależnie od właściwości pola `runLocal`.
+Pole `html` oraz typy pól `local`, `local_out` i `credential` zawsze wykonują swoje wyrażenie w przeglądarce, niezależnie od
+wartości `runLocal`.
+
+- **Po stronie serwera** (`runLocal: false`, domyślnie) - predefiniowane funkcje, które pobierają dane z API, plików i baz danych.
+- **Po stronie klienta** (`runLocal: true`) - kod korzysta z pełnego silnika JavaScript w piaskownicy przeglądarki do obliczeń, przekształceń i operacji na danych.
+
+---
+
+## Kwestie bezpieczeństwa
+
+Ponieważ wyrażenia są obliczane funkcją JavaScript `eval`, wstrzyknięcie kodu jest potencjalnym zagrożeniem:
+
+- **Wyrażenia po stronie serwera** najpierw przechodzą przez sanitizer: każde wywołanie musi być funkcją `fn.` lub `fnc.`, a wiele wierszy,
+  `;`, literały szablonowe, `process.env` i sposoby wyjścia z `eval` (`import`, `require`, `constructor`, ...) są odrzucane.
+- **Wyrażenia po stronie klienta** są obliczane w piaskownicy przeglądarki i można je uznać za bezpieczne.
+
+To, jak restrykcyjny jest sanitizer, zależy od
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER):
+
+| Wartość | Wyrażenia po stronie serwera |
+|---|---|
+| `strict` (domyślnie) | wywołania `fn.` i `fnc.` oraz metody na ich wyniku, np. `fn.fnTime().format('YYYY')` |
+| `paranoid` | tylko bezpośrednie wywołania `fn.` i `fnc.`, bez metod na ich wyniku |
+| `off` | każde wyrażenie po stronie serwera jest odrzucane; działają tylko wyrażenia `runLocal` |
+| `legacy` | zasady z wersji 6.2.1, które pozwalały każdemu uwierzytelnionemu użytkownikowi uruchamiać kod na serwerze; tylko na czas aktualizacji i tylko w rzeczywistym środowisku (nie ze strony ustawień) |
+
+Pusta lub nieznana wartość oznacza `strict`. Zmiana obowiązuje od następnego wyrażenia, bez restartu.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Symbole zastępcze](placeholders.html) | Odwołanie do innego pola, stałej lub użytkownika przez `$(...)` |
+| [Wyrażenia lokalne](local.html) | JavaScript wykonywany w piaskownicy przeglądarki |
+| [Wyrażenia zdalne](remote.html) | Funkcje po stronie serwera do dat, sieci, plików, SSH i numerowanych nazw |
+| [REST API](rest-apis.html) | Wywoływanie REST API z uwierzytelnianiem basic, tokenem lub własnym |
+| [Poświadczenia](credentials.html) | Odczyt zapisanego poświadczenia |
+| [Sortowanie](sorting.html) | Sortowanie tablic obiektem sortowania |
+| [Zapytania jq](jq.html) | Przekształcanie danych za pomocą jq |
diff --git a/i18n/pl/_build_forms/expressions/jq.md b/i18n/pl/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..67ca49e
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Zapytania jq
+parent: Wyrażenia
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# Zapytania jq
+{: .no_toc }
+
+Przekształcanie danych za pomocą jq, łącznie z funkcjami wbudowanymi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Uruchomienie zapytania JSON (jq) na obiekcie
+
+Przekształć obiekt, na przykład wartość innego pola, wyrażeniem jq:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+Od wersji 7.3.0 filtr jq działa najwyżej [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (domyślnie 30)
+zanim zostanie zatrzymany, a jego wynik jest ograniczony do 64 MB. Dotyczy to `fn.fnJq` oraz wyrażenia jq w funkcjach REST, plików,
+poświadczeń i zapytań do bazy danych.
+
+---
+
+## Wbudowane funkcje JQ
+
+Wszystkie funkcje pobierające dane przyjmują zapytanie JSON (jq), czyli język do operacji na obiektach i tablicach danych.  
+Przy przetwarzaniu danych może być potrzebna zamiana bajtów na KB, MB lub GB albo zaokrąglanie liczb.  
+Do tego celu AnsibleForms zawiera kilka własnych funkcji jq:
+
+- **fn2KB**: bajty na KB
+- **fn2MB**: bajty na MB
+- **fn2GB**: bajty na GB
+- **fnRound0**: zaokrąglenie do 0 miejsc po przecinku
+- **fnRound1**: zaokrąglenie do 1 miejsca po przecinku
+- **fnRound2**: zaokrąglenie do 2 miejsc po przecinku
+- **fnRound**: zaokrąglenie do 2 miejsc po przecinku
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/pl/_build_forms/expressions/local.md b/i18n/pl/_build_forms/expressions/local.md
new file mode 100644
index 0000000..ee8670d
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Wyrażenia lokalne
+parent: Wyrażenia
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Wyrażenia lokalne
+{: .no_toc }
+
+JavaScript wykonywany w piaskownicy przeglądarki
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Poniższe przykłady działają z właściwością pola `runLocal: true`.  
+Wykonują się w piaskownicy przeglądarki i mogą korzystać z pełnego silnika JavaScript.
+
+{: .note }
+> **Wskazówka**: typu `local` używaj jako aliasu dla `type: expression, runLocal: true, hide: true, output: false`  
+> **Wskazówka**: typu `local_out` używaj jako aliasu dla `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Konwencja nazewnictwa
+
+Stosuj konwencje nazewnictwa za pomocą operacji na ciągach znaków.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Obliczenia
+
+Wykonuj obliczenia za pomocą matematyki.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Konwersje
+
+Zamiana bajtów na gigabajty.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Zamiana tablicy obiektów na tabelę HTML
+
+Zamień tablicę obiektów, na przykład z innego pola, na tabelę HTML dla pola `html`:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Nazwa z kolejnym numerem
+
+Przy automatycznej numeracji może być potrzebne znalezienie następnej nazwy w tablicy numerowanych ciągów.  
+Ta funkcja jest dostępna także jako wyrażenie po stronie serwera (z prefiksem `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Gdy pierwszy argument nie jest tablicą, funkcja lokalna zwraca wartość domyślną. Funkcja serwerowa `fn.fnGetNumberedName`
+w takim przypadku kończy się błędem.
+
+---
+
+## Operacje na tablicach obiektów
+
+Tablice obiektów często trzeba filtrować, modyfikować i sortować.  
+AnsibleForms zawiera własną funkcję pomocniczą, dzięki której ten kod pozostaje zwięzły.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Operacje na tablicach obiektów w czystym JavaScripcie
+
+Do filtrowania i modyfikowania danych nadal dostępne są wszystkie standardowe metody tablic JavaScript, takie jak `map`, `forEach`, `find`, `filter` i `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/pl/_build_forms/expressions/placeholders.md b/i18n/pl/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..cdb23e9
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Symbole zastępcze
+parent: Wyrażenia
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Symbole zastępcze
+{: .no_toc }
+
+Odwołanie do innego pola, stałej lub bieżącego użytkownika przez `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Czym jest symbol zastępczy
+
+Symbol zastępczy to odwołanie zapisane jako `$(reference)`. Zanim tekst, który go zawiera, zostanie użyty, symbol jest zastępowany wartością.
+
+Symbole zastępcze działają we właściwościach pola `expression`, `query` i `default` (obliczanej przy `evalDefault`), a także w `label`,
+`help` i `placeholder`. Pole, które zawiera symbol zastępczy, zależy od pola, które ten symbol wskazuje: czeka, aż tamto pole będzie miało
+wartość, i jest obliczane ponownie przy każdej zmianie tej wartości. W ten sposób buduje się kaskadowe listy rozwijane.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## Do czego może odwoływać się symbol zastępczy
+
+Symbol zastępczy wskazuje pole formularza albo jedną z poniższych wartości, które ma każdy formularz:
+
+| Odwołanie | Co zawiera |
+|---|---|
+| `$(field)` | wartość innego pola formularza |
+| `$(name)`, stała | [stała](../config/constants.html) z `config.yaml` albo wartość z `varsFiles` formularza |
+| `$(__user__)` | zalogowany użytkownik: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | w [podformularzu](../forms/subform.html) (wiersz listy, krok kreatora) wartość formularza nadrzędnego |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Sięganie w głąb wartości
+
+Notacja kropkowa i indeksowa odczytuje część wartości, o ile ścieżka zawiera tylko litery, cyfry, `_`, `-`, `.` i `[n]`:
+
+| Symbol zastępczy | Na | Daje |
+|---|---|---|
+| `$(field)` | polu tekstowym, liczbowym lub haśle | wartość |
+| `$(field)` | polu enum z rekordami | `placeholderColumn` wybranego rekordu, a w przeciwnym razie jego pierwszą kolumnę |
+| `$(field.col)` | polu enum z rekordami | tę kolumnę wybranego rekordu |
+| `$(field)` | polu enum z `multiple: true` | wybraną kolumnę każdego zaznaczonego rekordu, jako tablicę |
+| `$(field)` | wyrażeniu, liście lub stałej | całą wartość (lista daje swoje wiersze) |
+| `$(field.a.b)`, `$(f[0].x)` | wyrażeniu, liście lub stałej | tę część obiektu lub tablicy |
+
+Ustawienie `placeholderColumn: "*"` w polu enum sprawia, że `$(field)` daje cały wybrany rekord zamiast jednej kolumny.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Jak wartość jest wstawiana
+
+Sposób wstawienia wartości do tekstu zależy od miejsca, w którym stoi symbol zastępczy.
+
+| Gdzie | Przykład | Staje się |
+|---|---|---|
+| w wyrażeniu, poza cudzysłowem | `$(count) + 1` | literałem JavaScript: liczba zostaje liczbą, tekst staje się ciągiem w cudzysłowie, obiekt lub tablica literałem |
+| w wyrażeniu, jako cały ciąg w cudzysłowie | `fn.fnLs('$(dir)')` | tym samym literałem, łącznie z cudzysłowem, więc wartość zawierająca cudzysłów nie może się z niego wydostać |
+| w wyrażeniu, wewnątrz dłuższego ciągu | `'$(dir)/vars'` | tekstem, poddanym escapowaniu dla tego ciągu |
+| w zapytaniu, etykiecie, tekście pomocy | `where city='$(city)'` | tekstem |
+
+Pole, którego symboli zastępczych nie da się jeszcze wszystkich rozwiązać, nie jest obliczane; przy `ignoreIncomplete: true` brakująca wartość
+jest wstawiana jako `undefined`.
+
+### Grawisy i `${` w wartości
+
+Od wersji 7.3.0 wartość pola nie może zostać wykonana jako kod, gdy serwer wstawia ją do wyrażenia (wyrażenia zdalne, weryfikacja
+uruchomienia, MCP i czat). Grawis lub `${` w wartości jest zapisywany jako sekwencja unicode (`\u0060`, `\u0024{`), więc pozostaje
+tekstem nawet wewnątrz literału szablonowego. Wyrażenia po stronie serwera w ogóle odrzucają literały szablonowe; do nich używaj `runLocal`.
+
+Wyrażenie `runLocal` obliczane w przeglądarce wstawia wartość tak, jak mówi powyższa tabela, bez tego escapowania, więc nie umieszczaj tam
+symbolu zastępczego wewnątrz literału szablonowego.
+
+---
+
+## Zobacz też
+
+Powiązane strony i wpisy FAQ:
+
+- [Wyrażenia lokalne](local.html) i [Wyrażenia zdalne](remote.html): miejsca, gdzie używa się większości symboli zastępczych
+- [FAQ: Kaskadowe listy rozwijane](../faq.html#cascaded-dropdowns) i [Symbole zastępcze pól](../faq.html#field-placeholders): więcej przykładów
+- [FAQ: Jak uzyskać dostęp do danych formularza nadrzędnego w podformularzu?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/pl/_build_forms/expressions/remote.md b/i18n/pl/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..8650784
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Wyrażenia zdalne
+parent: Wyrażenia
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Wyrażenia zdalne
+{: .no_toc }
+
+Funkcje po stronie serwera do dat, sieci, plików, SSH i numerowanych nazw
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Poniższe przykłady działają z właściwością pola `runLocal: false` (domyślnie).  
+Są obliczane po stronie serwera.
+
+Ponieważ wykonywanie kodu na serwerze stanowi zagrożenie bezpieczeństwa, wyrażenie jest oczyszczane i ograniczone do funkcji
+dostarczanych z AnsibleForms oraz [funkcji dodanych przez ciebie](#your-own-functions).  
+Wyrażenia po stronie serwera służą do pobierania informacji ze źródeł danych, takich jak pliki, REST API i polecenia SSH.
+
+{: .important }
+Wbudowane funkcje po stronie serwera mają prefiks `fn.` (na przykład `fn.fnRestBasic`), a twoje własne prefiks `fnc.`.
+
+---
+
+## Operacje na dacie i czasie
+
+Pracuj z datami i godzinami za pomocą [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## Informacje CIDR dla adresu IP
+
+Pobierz podsieć dla adresu IP i maski sieci oraz sprawdź, które adresy do niej należą:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## Wynik polecenia SSH
+
+Uruchom polecenie na zdalnym hoście przez SSH i użyj jego wyniku:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Lista plików w katalogu
+
+Wyświetl pliki katalogu na serwerze AnsibleForms, opcjonalnie rekurencyjnie i z filtrem:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Parsowanie strony HTML
+
+Pobierz stronę HTML i wyodrębnij fragmenty pasujące do wyrażenia regularnego:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+Strona jest pobierana z uwzględnieniem [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) i
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), tak jak w funkcjach REST. W odróżnieniu od nich ignoruje
+`REST_IGNORE_CERTS` i `REST_TIMEOUT_SECONDS`: zawsze sprawdza certyfikat i czeka najwyżej 30 sekund.
+
+---
+
+## Informacje DNS
+
+Rozwiąż rekord DNS domeny:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Odczyt pliku JSON
+
+Odczytaj plik JSON na serwerze, opcjonalnie z filtrem jq:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Odczyt pliku YAML
+
+Odczytaj plik YAML na serwerze, opcjonalnie z filtrem jq:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Nazwa z kolejnym numerem
+
+W tablicy ciągów z kolejnymi numerami (server001, server002, ...) może być potrzebne znalezienie następnej wolnej nazwy.  
+Ta funkcja jest dostępna także jako wyrażenie lokalne (bez prefiksu `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Na serwerze `fn.fnGetNumberedName` kończy się błędem, gdy pierwszy argument nie jest tablicą. Wyrażenie lokalne
+(bez `fn.`) zwraca wtedy wartość domyślną.
+
+---
+
+## Własne funkcje
+
+Dodaj własne funkcje JavaScript do `custom.js` i wywołuj je w wyrażeniu serwerowym z prefiksem `fnc.`.
+
+Plik eksportuje obiekt z funkcjami. Plik dostarczany z obrazem zawiera dwa przykłady:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+W ten sam sposób `jq.custom.definitions` zawiera twoje własne definicje jq. Są one dodawane na początku każdego zapytania jq,
+które uruchamia serwer, więc [zapytania jq](jq.html) każdej funkcji mogą z nich korzystać.
+
+W kontenerze zamapuj oba pliki w miejsce tych z obrazu i uruchom go ponownie; są odczytywane przy starcie serwera:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Własna funkcja działa wewnątrz procesu serwera, z jego uprawnieniami, za każdym razem, gdy wywoła ją wyrażenie.
+> [Sanitizer](index.html#security-concerns) sprawdza, czy wyrażenie wywołuje tylko funkcje `fn.` i `fnc.`; to, co
+> funkcja robi ze swoimi argumentami, zależy od ciebie.
diff --git a/i18n/pl/_build_forms/expressions/rest-apis.md b/i18n/pl/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..776c619
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: REST API
+parent: Wyrażenia
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# REST API
+{: .no_toc }
+
+Wywoływanie REST API z uwierzytelnianiem basic, tokenem lub własnym
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## REST API z uwierzytelnianiem basic
+
+Wywołaj REST API z użytkownikiem i hasłem zapisanego poświadczenia:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## REST API z uwierzytelnianiem tokenem
+
+Wywołaj REST API z tokenem bearer zapisanym w wyrażeniu:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST API z zabezpieczonym uwierzytelnianiem tokenem
+
+Wywołaj REST API z tokenem bearer pobranym z zapisanego poświadczenia, dzięki czemu nigdy nie pojawia się on w formularzu:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## REST API z własnymi nagłówkami
+
+Wywołaj REST API z własnymi nagłówkami, dla każdego innego rodzaju uwierzytelniania:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certyfikaty i limity czasu
+
+Od wersji 7.3.0 każda pomocnicza funkcja REST (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) sprawdza certyfikat
+TLS punktu końcowego i przestaje czekać po określonym czasie:
+
+| Ustawienie | Co zmienia |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` pomija sprawdzanie certyfikatu. Do wersji 7.2.0 nigdy nie był sprawdzany; zostaw `0` i zamiast tego zaufaj prywatnemu CA przez `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Jak długo wywołanie czeka na odpowiedź, domyślnie 60 sekund; punkt końcowy, który nigdy nie odpowiada, powoduje wtedy błąd pola zamiast jego zawieszenia |
+
+Od wersji 7.3.0 pole, którego punkt końcowy ma certyfikat samopodpisany, kończy się błędem certyfikatu, dopóki nie ustawisz jednego z tych dwóch ustawień.
+[Wywołania REST i jq](../customization/security.html#rest-calls-and-jq) opisuje oba oraz to, jak jednocześnie zaufać prywatnemu CA dla wszystkich wywołań REST.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) nie jest pomocniczą funkcją REST: ignoruje oba ustawienia, zawsze sprawdza
+certyfikat i czeka najwyżej 30 sekund.
diff --git a/i18n/pl/_build_forms/expressions/sorting.md b/i18n/pl/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..856bfc2
--- /dev/null
+++ b/i18n/pl/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Sortowanie
+parent: Wyrażenia
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Sortowanie
+{: .no_toc }
+
+Sortowanie tablic obiektem sortowania
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sortowanie tablicy
+
+Posortuj tablicę z wyrażenia, REST API lub bazy danych za pomocą obiektu sortowania:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## Obiekt sortowania
+
+Funkcje REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) przyjmują ten obiekt sortowania
+jako argument. Każdy inny wynik, na przykład z `fn.fnJq` lub odczytu pliku, opakuj w `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/pl/_build_forms/formfields/checkbox.md b/i18n/pl/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..991f3bc
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Pola formularza
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Pole Checkbox
+{: .no_toc }
+
+Wartość prawda lub fałsz, do włączenia opcji lub ustawienia flagi
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `checkbox`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `checkbox` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/datetime.md b/i18n/pl/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..6d85c0b
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Pola formularza
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Pole Datetime
+{: .no_toc }
+
+Wybór daty, godziny, tygodnia, miesiąca lub roku
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `datetime`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `datetime` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/enum.md b/i18n/pl/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..ff4779b
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Pola formularza
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Pole Enum
+{: .no_toc }
+
+Lista rozwijana z wyszukiwaniem, do wyboru jednej lub wielu opcji
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `enum`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `enum` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/expression.md b/i18n/pl/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..79e5a50
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Pola formularza
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Pole Expression
+{: .no_toc }
+
+Wartość obliczana przez JavaScript, w przeglądarce lub na serwerze
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `expression`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `expression` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/file.md b/i18n/pl/_build_forms/formfields/file.md
new file mode 100644
index 0000000..ff8725c
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Pola formularza
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Pole File
+{: .no_toc }
+
+Przesyłanie plików, takich jak pliki konfiguracyjne lub certyfikaty
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `file`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `file` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/html.md b/i18n/pl/_build_forms/formfields/html.md
new file mode 100644
index 0000000..6303fde
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Pola formularza
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Pole Html
+{: .no_toc }
+
+Bogata treść HTML wewnątrz formularza
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `html`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `html` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/index.md b/i18n/pl/_build_forms/formfields/index.md
new file mode 100644
index 0000000..54e74e8
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Pola formularza
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Pola formularza
+{: .no_toc }
+
+Kontrolki wejściowe formularza
+{: .fs-6 .fw-300 }
+
+---
+
+Dla autorów formularzy: typy pól, jakie może zawierać formularz, i właściwości obsługiwane przez każdy z nich.
+
+Pola formularza definiują kontrolki wejściowe formularza. Każdy typ pola ma własne właściwości i zachowanie, służące do zbierania określonego rodzaju danych.
+
+Wybierz typ pola pasujący do danych, które chcesz zebrać, od zwykłego tekstu po listy strukturalne.
+
+---
+
+## Wspólne właściwości
+
+Wszystkie pola formularza mają dwie podstawowe właściwości:
+
+- **name** (string, wymagane): unikalny identyfikator pola
+- **type** (string, wymagane): typ pola, od którego zależy, która z poniższych stron opisuje dostępne właściwości
+
+Każdy typ pola dodaje właściwości związane z jego funkcją. Wybierz typ pola w bocznym pasku nawigacji lub w tabeli poniżej, aby otworzyć pełny opis jego właściwości:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Typ pola</th>
+      <th>Opis</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/pl/_build_forms/formfields/list.md b/i18n/pl/_build_forms/formfields/list.md
new file mode 100644
index 0000000..aaed29c
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Pola formularza
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Pole List
+{: .no_toc }
+
+Tabela wierszy, z których każdy edytuje się w podformularzu
+{: .fs-6 .fw-300 }
+
+---
+
+Pole list wyświetla tabelę wierszy, z których każdy tworzy się i edytuje w osobnym panelu **podformularza** (wzorzec drilldown). Zastępuje pole `table`, usunięte w wersji 7.0.0.
+
+---
+
+## Najważniejsze funkcje
+
+Pole list oferuje następujące możliwości:
+
+- Każdy wiersz edytuje się w pełnoekranowym podformularzu, który daje dostęp do wszystkich typów pól, łącznie z zagnieżdżonymi listami.
+- Podformularz to osobny formularz typu `subform` i można go **używać ponownie w wielu polach list** w różnych formularzach (np. jeden podformularz `Address` wspólny dla klientów, dostawców, zamówień…).
+- Właściwości znaczników (`insertMarker`, `updateMarker`, `deleteMarker`) wspierają idempotentne wzorce playbooków.
+- Przy `allowDelete: false` istniejące wcześniej wiersze są chronione; usunąć można tylko wiersze dodane w bieżącej sesji (oznaczone `insertMarker`).
+- Właściwość `columns` określa, które pola podformularza pojawiają się jako kolumny w tabeli podsumowania.
+- Wynikiem jest zawsze tablica obiektów. Właściwości `model`, `output`, `outputObject` i `valueColumn` zadeklarowane w polach podformularza są respektowane przy generowaniu extravars.
+
+---
+
+## Deklaracja podformularza
+
+Podformularz to osobny formularz z `type: subform`, zapisany w pliku folderu formularzy jak każdy inny formularz. Przyjmuje tę samą tablicę `fields` co każdy inny formularz, ale nigdy nie pojawia się na liście kafelków formularzy i nigdy nie jest wysyłany bezpośrednio.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `list`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Przykłady</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Przykłady
+
+### Wspólny podformularz adresu
+
+Jeden podformularz `Address` używany przez dwa pola list tego samego formularza:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Śledzenie znacznikami (z myślą o idempotencji)
+
+Wstępnie załadowane wiersze są chronione, a znaczniki mówią playbookowi, które wiersze są nowe, zmienione lub usunięte:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Wstępne wypełnianie wierszy
+
+Listę można wstępnie wypełnić z trzech źródeł. W każdym przypadku wynikowe wiersze muszą być obiektami, których klucze odpowiadają nazwom pól wskazanego podformularza.
+
+#### Statyczny `default`
+
+Wiersze zapisane w samym formularzu:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### Z REST API (`expression`)
+
+Wiersze ładowane z REST API przez wyrażenie po stronie serwera:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### Z zapytania do bazy danych (`dbConfig` + `query`)
+
+Wiersze ładowane z zapytania do bazy danych:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### Z wyrażenia lokalnego (`runLocal`)
+
+Wiersze obliczane w przeglądarce przez wyrażenie lokalne:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Zagnieżdżone listy
+
+Podformularz może mieć własne pole list, aby w każdym wierszu była lista:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Dostęp do danych formularza nadrzędnego przez `__parent__`
+
+Gdy otwiera się edytor wiersza podformularza, AnsibleForms wstrzykuje do podformularza zmienną `__parent__`. Zawiera ona migawkę **wszystkich wartości pól formularza nadrzędnego**, łącznie ze stałymi i vars.
+
+Odwołuj się do niej standardową składnią wyrażeń `$(...)` w definicjach pól podformularza:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` to pomocnik działający **wyłącznie we frontendzie**. Jest usuwany z extravars Ansible i nigdy nie trafia do playbooka.
+
diff --git a/i18n/pl/_build_forms/formfields/number.md b/i18n/pl/_build_forms/formfields/number.md
new file mode 100644
index 0000000..8176cfd
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Pola formularza
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Pole Number
+{: .no_toc }
+
+Wartość całkowita lub dziesiętna, taka jak port lub ilość
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `number`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `number` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/password.md b/i18n/pl/_build_forms/formfields/password.md
new file mode 100644
index 0000000..ddb4cad
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Pola formularza
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Pole Password
+{: .no_toc }
+
+Wartość maskowana, dla haseł, sekretów i tokenów
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `password`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `password` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/radio.md b/i18n/pl/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..c1ac68f
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Pola formularza
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Pole Radio
+{: .no_toc }
+
+Jeden wybór spośród zestawu wzajemnie wykluczających się opcji
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `radio`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `radio` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/text.md b/i18n/pl/_build_forms/formfields/text.md
new file mode 100644
index 0000000..a3221cc
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Pola formularza
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Pole Text
+{: .no_toc }
+
+Pojedynczy wiersz tekstu, taki jak nazwa lub nazwa hosta
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `text`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `text` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/textarea.md b/i18n/pl/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..41c23fe
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Pola formularza
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Pole Textarea
+{: .no_toc }
+
+Tekst wielowierszowy, taki jak opis lub fragment konfiguracji
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `textarea`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `textarea` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pl/_build_forms/formfields/yaml.md b/i18n/pl/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..b7b05c3
--- /dev/null
+++ b/i18n/pl/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Pola formularza
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Pole YAML
+{: .no_toc }
+
+Dane strukturalne w edytorze YAML, z walidacją i importem z pliku
+{: .fs-6 .fw-300 }
+
+---
+
+## Właściwości
+
+Właściwości dostępne dla pola `yaml`, pogrupowane według przeznaczenia:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Wartość:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe pola `yaml` w YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja pola w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Dostęp do danych formularza nadrzędnego przez `__parent__`
+
+Gdy pole `yaml` działa w trybie `subform`, AnsibleForms wstrzykuje do podformularza zmienną `__parent__`. Zawiera ona migawkę **wszystkich wartości pól formularza nadrzędnego** z chwili otwarcia edytora, łącznie ze stałymi i vars.
+
+Odwołuj się do niej standardową składnią wyrażeń `$(...)` w definicjach pól podformularza:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` to pomocnik działający **wyłącznie we frontendzie**. Jest usuwany z extravars Ansible i nigdy nie trafia do playbooka.
diff --git a/i18n/pl/_build_forms/forms/ansible.md b/i18n/pl/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..6e174ea
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularze Ansible
+parent: Formularze
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Formularze Ansible
+{: .no_toc }
+
+Formularze, które uruchamiają lokalny playbook Ansible
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: ansible`, oprócz [wspólnych właściwości formularzy](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/approval.md b/i18n/pl/_build_forms/forms/approval.md
new file mode 100644
index 0000000..6db112a
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Punkty zatwierdzenia
+parent: Formularze
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Punkty zatwierdzenia
+{: .no_toc }
+
+Wstrzymanie zadania, dopóki ktoś go nie zatwierdzi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jak to działa
+
+Punkt zatwierdzenia wstrzymuje zadanie w swoim miejscu formularza, dopóki zatwierdzający nie udzieli odpowiedzi:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Zatwierdzanie własnego zadania
+
+Od wersji 7.3.0 użytkownik, który uruchomił zadanie, nie może go zatwierdzić, nawet jeśli ma jedną z ról zatwierdzenia, więc potrzebna jest druga osoba; administrator zawsze może zatwierdzać, także własne zadania.
+Uruchamiający nadal może odrzucić (wycofać) własne zadanie. Ustaw `allowSelf: true`, jeśli on także może je zatwierdzić, na przykład w formularzu testowym:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Atrybuty
+
+Atrybuty punktu zatwierdzenia:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe punkty zatwierdzenia w YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/awx.md b/i18n/pl/_build_forms/forms/awx.md
new file mode 100644
index 0000000..5429445
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularze AWX
+parent: Formularze
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# Formularze AWX
+{: .no_toc }
+
+Formularze, które uruchamiają szablon zadania AWX, AAP lub Ascender
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: awx`, oprócz [wspólnych właściwości formularzy](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/common.md b/i18n/pl/_build_forms/forms/common.md
new file mode 100644
index 0000000..b724604
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Wspólne właściwości
+parent: Formularze
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Wspólne właściwości formularzy
+{: .no_toc }
+
+Właściwości wspólne dla wszystkich typów formularzy
+{: .fs-6 .fw-300 }
+
+---
+
+Te właściwości dotyczą **wszystkich typów formularzy**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (przestarzały) i `subform`.
+
+Wszystkie pozostałe właściwości zależą od typu i są opisane na stronie odpowiedniego typu formularza.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Właściwości
+
+Właściwości wspólne dla wszystkich typów formularzy:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/pl/_build_forms/forms/index.md b/i18n/pl/_build_forms/forms/index.md
new file mode 100644
index 0000000..810f9d4
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formularze
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formularze
+{: .no_toc }
+
+Definiowanie formularzy, które wypełniają twoi użytkownicy
+{: .fs-6 .fw-300 }
+
+---
+
+Dla autorów formularzy: jak formularze zapisuje się w YAML, skąd są ładowane i jakie właściwości ma każdy typ formularza.
+
+Formularze są sercem AnsibleForms. Każdy formularz to interfejs webowy, który zbiera dane od użytkownika i na ich podstawie uruchamia
+playbook Ansible, szablon AWX, AAP lub Ascender, szablon Semaphore, zadanie Rundeck lub Jenkins albo
+[workflow](../workflows/).
+
+Formularze definiuje się w plikach YAML w folderze formularzy. Każdy plik YAML zawiera jeden formularz lub listę formularzy, a do ich porządkowania można używać podfolderów.
+
+**WIDEO**: [Utwórz swój pierwszy formularz](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Struktura formularza
+
+Każdy formularz w AnsibleForms konfiguruje się zestawem właściwości. **[Wspólne właściwości](common.html)** wymienia właściwości dotyczące wszystkich typów formularzy; strony poszczególnych typów opisują dodatkowe.
+
+---
+
+## Jak ładowane są formularze
+
+AnsibleForms ładuje formularze z następujących miejsc:
+
+1. **Z REPOZYTORIÓW** : wszystkie repozytoria z włączonym przełącznikiem „Używać do formularzy?” (obsługiwanych jest wiele repozytoriów)
+   - Formularze ze wszystkich włączonych repozytoriów są scalane automatycznie.
+   - W każdym repozytorium najpierw sprawdzany jest podfolder `forms/`.
+   - Jeśli podfolder `forms/` nie istnieje, używany jest katalog główny repozytorium.
+   - Formularze utworzone w projektancie i jeszcze niewypchnięte są przechowywane w folderze przejściowym
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) i ładowane razem z nimi.
+
+2. **Z FOLDERU LOKALNEGO** : lokalny folder `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), gdy żadne repozytorium nie ma włączonego „Używać do formularzy?”
+
+{: .warning }
+> **Uwaga:** Gdy „Używać do formularzy?” jest włączone w kilku repozytoriach, wszystkie ich formularze są scalane. Nazwy formularzy muszą być unikalne we wszystkich repozytoriach, aby uniknąć konfliktów.
+
+---
+
+## Gdzie działa formularz
+
+Typ formularza decyduje o rodzaju [runnera](../runners.html), na którym działa jego zadanie: RTE dla `ansible`, runner AWX dla `awx`,
+`aap` i `ascender` oraz runner własnego typu dla `semaphore`, `rundeck` i `jenkins`.
+
+- `runner: <name>` w formularzu wybiera runner tego typu po nazwie; bez tego zadanie działa na domyślnym runnerze danego typu.
+- Runner wyłączony w **Połączenia > Runnery** powoduje błąd zadania, niezależnie od tego, czy formularz go wskazuje, czy jest on domyślny. Zadanie
+  nigdy nie przechodzi na inny runner.
+- Gdy jedna z ról użytkownika ma listę `runners` w `config.yaml`, zadanie może działać tylko na runnerze wymienionym przez taką rolę, w przeciwnym razie
+  zostaje odrzucone. Role bez tej listy go nie ograniczają, a administrator nigdy nie jest ograniczony.
+
+---
+
+## W tej sekcji
+
+Na kolejnych stronach szczegółowo opisano właściwości formularzy:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Wspólne właściwości](common.html) | Właściwości dotyczące wszystkich typów formularzy (`name`, `description`, `help`, `type`, `fields`) |
+| [Formularze Ansible](ansible.html) | Właściwości specyficzne dla `type: ansible` |
+| [Formularze AWX](awx.html) | Właściwości specyficzne dla `type: awx` |
+| [Formularze Semaphore](semaphore.html) | Właściwości specyficzne dla `type: semaphore`, który uruchamia szablon Semaphore |
+| [Formularze Rundeck](rundeck.html) | Właściwości specyficzne dla `type: rundeck`, który uruchamia zadanie Rundeck |
+| [Formularze Jenkins](jenkins.html) | Właściwości specyficzne dla `type: jenkins`, który buduje zadanie Jenkins |
+| [Formularze wieloetapowe](multistep.html) | Właściwości specyficzne dla `type: multistep`, przestarzałego na rzecz `workflow` |
+| [Formularze workflow](workflow.html) | Właściwości specyficzne dla `type: workflow`, który uruchamia [workflow](../workflows/) |
+| [Kreator](wizard.html) | Podział danych formularza na kilka stron (działa z każdym wykonywalnym typem formularza) |
+| [Podformularz](subform.html) | Podformularze używają tylko wspólnych właściwości |
+| [Punkty zatwierdzenia](approval.html) | Wstrzymanie zadania do czasu zatwierdzenia (`approval`) |
+| [Powiadomienia](notifications.html) | Wysyłanie e-maili i wiadomości na kanały przy stanie zadania lub zdarzeniach (`notifications`) |
+| [Akcje stanu zadania](job-status-action.html) | Działania na formularzu, gdy zadanie zmienia stan (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/pl/_build_forms/forms/jenkins.md b/i18n/pl/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..3d36191
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularze Jenkins
+parent: Formularze
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Formularze Jenkins
+{: .no_toc }
+
+Formularze, które budują zadanie Jenkins
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: jenkins`, oprócz [wspólnych właściwości formularzy](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/job-status-action.md b/i18n/pl/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..0cfca54
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Akcje stanu zadania
+parent: Formularze
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Akcje stanu zadania
+{: .no_toc }
+
+Działania na formularzu, gdy jego zadanie zostaje wysłane, kończy się sukcesem, błędem lub po prostu się kończy
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Dostępne są następujące hooki:
+
+- `onSubmit` - wywoływany, gdy formularz zostaje wysłany
+- `onSuccess` - wywoływany, gdy zadanie kończy się powodzeniem
+- `onFailure` - wywoływany, gdy zadanie kończy się błędem
+- `onFinish` - wywoływany, gdy zadanie się kończy, niezależnie od jego stanu
+- `onAbort` - wywoływany, gdy zadanie zostaje przerwane
+
+---
+
+## Atrybuty
+
+Atrybuty akcji stanu zadania:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe akcje stanu zadania w YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/multistep.md b/i18n/pl/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..6bbb103
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Formularze wieloetapowe
+parent: Formularze
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Formularze wieloetapowe
+{: .no_toc }
+
+Uruchamianie kilku playbooków lub szablonów po kolei z jednego formularza
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` jest przestarzały od wersji 7 i zostanie usunięty w wersji 8: zamiast niego używaj [workflow](workflow.html). Workflow robi wszystko,
+> co multistep, a do tego ma warunki, własne wartości dla każdego węzła, węzły zatwierdzenia i gałęzie działające równolegle.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwość na poziomie formularza
+
+Formularz wieloetapowy definiuje swoje kroki w jednej właściwości na poziomie formularza:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / wymagane</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Oprócz `steps` formularz wieloetapowy przyjmuje następujące właściwości na poziomie formularza, opisane na stronie [Formularze Ansible](ansible.html):
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (wymagane){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Właściwości kroków
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Dostępne tylko dla typów:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Dodano</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Przykłady
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Przykład
+
+Formularz wieloetapowy uruchamia kilka zadań po kolei, a każdy krok uruchamia własny playbook lub szablon AWX. Wszystkie kroki współdzielą pola formularza: domyślnie każdy krok otrzymuje pełne extravars, a `key` kroku ogranicza go do tej ich części.
+
+### Utworzenie i konfiguracja serwera
+
+Każdy krok otrzymuje własną część extravars: krok AWX tworzy serwer, krok Ansible konfiguruje jego sieć, a ostatni krok zawsze wysyła raport:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/pl/_build_forms/forms/notifications.md b/i18n/pl/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..c515417
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Powiadomienia
+parent: Formularze
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Powiadomienia
+{: .no_toc }
+
+Wysyłanie e-maila lub wiadomości na kanał, gdy zadanie się kończy lub coś się z nim dzieje
+{: .fs-6 .fw-300 }
+
+---
+
+Właściwość `notifications` formularza określa, kto i kiedy dowiaduje się o jego zadaniach:
+
+- **Kto**: `recipients`, czyli adresy e-mail, oraz `channels`, czyli nazwy
+  [kanałów powiadomień](../notification-channels.html) (poczta, Slack, Microsoft Teams, Telegram, webhook). Wymagane jest
+  co najmniej jedno z nich.
+- **Kiedy**: `onStatus`, gdy zadanie się kończy (`success`, `failed`, `aborted`, `warning` lub `any`), oraz `onEvent`, gdy
+  coś dzieje się z zadaniem (`launch`, `relaunch`, `delete`, `approve`, `reject` lub `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Atrybuty
+
+Atrybuty obiektu `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Przykłady
+
+Przykładowe powiadomienia w YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}Definicja w YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/rundeck.md b/i18n/pl/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..b9e466c
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularze Rundeck
+parent: Formularze
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Formularze Rundeck
+{: .no_toc }
+
+Formularze, które uruchamiają zadanie Rundeck
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: rundeck`, oprócz [wspólnych właściwości formularzy](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/semaphore.md b/i18n/pl/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..536db22
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formularze Semaphore
+parent: Formularze
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Formularze Semaphore
+{: .no_toc }
+
+Formularze, które uruchamiają szablon Semaphore UI
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: semaphore`, oprócz [wspólnych właściwości formularzy](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/forms/subform.md b/i18n/pl/_build_forms/forms/subform.md
new file mode 100644
index 0000000..d1e3081
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Podformularz
+parent: Formularze
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Podformularz
+{: .no_toc }
+
+Fragment formularza wielokrotnego użytku dla pól list, pól yaml i stron kreatora
+{: .fs-6 .fw-300 }
+
+---
+
+Podformularz to fragment formularza wielokrotnego użytku. Nie pojawia się w widoku kafelków i nie można go wysłać bezpośrednio. Odwołują się do niego:
+
+- Pole [`list`](../formfields/list.html): otwiera podformularz jako edytor drilldown dla każdego wiersza
+- Pole [`yaml`](../formfields/yaml.html) z właściwością `subform`: otwiera podformularz jako edytor drilldown dla pojedynczego obiektu
+- Krok [`wizard`](wizard.html): wyświetla podformularz jako jedną stronę kreatora
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Podformularze **nie mają właściwości specyficznych dla typu**. Używają tylko [wspólnych właściwości formularzy](common.html): `name`, `description`, `help`, `type` i `fields`.
+
+Gdy podformularz służy jako strona kreatora, jego `description` i `help` dostarczają wartości domyślnych dla `title` i `help` kroku. Może też ustawić `showHelp`, aby ta pomoc była rozwinięta po załadowaniu strony.
+
+Właściwości wykonania (`playbook`, `template`, `roles`, `inventory` itp.) nie dotyczą podformularzy, ponieważ podformularz nigdy nie jest wysyłany bezpośrednio.
+
diff --git a/i18n/pl/_build_forms/forms/wizard.md b/i18n/pl/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..b1810ca
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Kreator
+parent: Formularze
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Kreator
+{: .no_toc }
+
+Podział danych formularza na strony z przyciskami Wstecz i Dalej
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## Czym jest kreator?
+
+**Kreator** zamienia pojedynczy formularz w sekwencję stron. Każda strona jest wyświetlana z [`subform`](subform.html), a użytkownik przechodzi między nimi przyciskami **Wstecz** i **Dalej**. Walidacja odbywa się dla każdej strony osobno: użytkownik nie może przejść dalej, dopóki bieżący krok nie jest poprawny, chyba że krok jest oznaczony jako `optional`.
+
+Na końcu każdego kreatora automatycznie dodawana jest **strona podsumowania** tylko do odczytu. Wyświetla każdy krok z zebranymi wartościami, aby użytkownik mógł je potwierdzić przed wysłaniem. Strony podsumowania **nie** deklaruje się w YAML; jej tytuł pochodzi z aktywnego języka.
+
+Przy wysyłaniu **wartości zebrane ze wszystkich kroków są scalane w jeden zestaw extravars** i przekazywane do docelowego playbooka, szablonu lub workflow, dokładnie tak, jakby użytkownik wypełnił jeden duży formularz.
+
+Formularz z `wizard` nie potrzebuje własnych `fields`, ale nie może ustawić `enableForChat`, a `subform` sam nie może mieć `wizard`. [Weryfikacja uruchomienia](../launch-validation/rolling-it-out.html#wizard-forms) sprawdza uruchomienie kreatora krok po kroku.
+
+{: .note }
+> Czym `wizard` różni się od workflow i jak je połączyć, opisuje wpis FAQ [Jaka jest różnica między kreatorem a workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Właściwość na poziomie formularza
+
+Kreator włącza się jedną właściwością na poziomie formularza:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">dodano w wersji {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Przykłady:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości kroku kreatora
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / wymagane</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / unikalne</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Dodano</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Przykłady
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Łączenie kreatora z workflow
+
+Kreator można nałożyć na formularz [workflow](workflow.html). Gdy `defaultModel` każdego kroku kreatora odpowiada [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) odpowiedniego węzła workflow, każdy playbook lub szablon otrzymuje tylko wartości z własnej strony kreatora.
+
+FAQ zawiera rozpracowany przykład i układ scalonych extravars: [Jaka jest różnica między kreatorem a workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (sekcja *Połączenie (kreator na workflow)*).
+
+Kreator na przestarzałym formularzu [`multistep`](multistep.html) działa tak samo, z [`key`](multistep.html#step_key) kroku zamiast `extra_vars_key`.
+
+---
+
+## Zobacz też
+
+Powiązane strony i wpisy FAQ:
+
+- [Podformularz](subform.html): strony kreatora są wyświetlane z podformularzy
+- [Formularze workflow](workflow.html): odpowiednik kreatora w warstwie wykonania
+- [`__parent__` w podformularzach](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): jak w późniejszym kroku odwołać się do wcześniejszych kroków kreatora
diff --git a/i18n/pl/_build_forms/forms/workflow.md b/i18n/pl/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..83e71b7
--- /dev/null
+++ b/i18n/pl/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Formularze workflow
+parent: Formularze
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Formularze workflow
+{: .no_toc }
+
+Formularze, które uruchamiają jeden z workflow projektanta
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Właściwości
+
+Właściwości specyficzne dla `type: workflow`, oprócz [wspólnych właściwości formularzy](common.html). Same pliki workflow
+opisuje sekcja [Workflow](../workflows/).
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atrybut</th>
+      <th>Komentarze</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / wymagane</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">dodano w wersji {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opcje:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (domyślnie)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Domyślnie:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Przykłady:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pl/_build_forms/launch-validation/file-uploads.md b/i18n/pl/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..61d1dfe
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Przesyłanie plików
+parent: Weryfikacja uruchomienia
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Przesyłanie plików
+{: .no_toc }
+
+Jak weryfikowane są pola plików
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pole pliku nigdy nie ufa temu, co żądanie uruchomienia mówi o pliku. Weryfikacja uruchomienia sprawdza sam plik, na
+dysku serwera.
+
+---
+
+## Jak przesłany plik trafia do zadania
+
+Plik jest przesyłany przed uruchomieniem formularza, w dwóch krokach:
+
+1. Przeglądarka przesyła plik przez `POST /api/v2/job/upload`. Serwer zapisuje go w `UPLOAD_PATH`.
+2. Żądanie uruchomienia opisuje ten przesłany plik w swojej części `files`.
+
+Weryfikacja uruchomienia porównuje następnie opis z dyskiem:
+
+* Plik musi istnieć wewnątrz `UPLOAD_PATH`.
+* Jego ścieżka i rozmiar są odczytywane z dysku, nigdy z żądania.
+
+---
+
+## Co jest akceptowane
+
+Pole pliku otrzymuje wartość tylko ze zweryfikowanego przesłania. Wszystko inne jest odrzucane:
+
+* Ścieżka, którą wywołujący wpisze do `rawFormData` lub `extravars`, jest ignorowana.
+* Wymagane pole pliku bez faktycznego przesłania jest zgłaszane jako `missing`.
+
+---
+
+## Reguły plików
+
+Reguły pola pliku są sprawdzane względem faktycznie przesłanego pliku, z rozmiarami w bajtach:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` i `maxSize` porównują rzeczywisty rozmiar pliku, a `regex` jego nazwę. Niezależnie od formularza
+`UPLOAD_MAX_GB` ogranicza rozmiar pojedynczego przesłania (domyślnie 10 GB).
diff --git a/i18n/pl/_build_forms/launch-validation/index.md b/i18n/pl/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..fcf370e
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Weryfikacja uruchomienia
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Weryfikacja uruchomienia
+{: .no_toc }
+
+Sprawdzanie na serwerze każdego uruchomienia formularza
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów i autorów formularzy: niech serwer sprawdza każde uruchomienie, jego reguły i extravars, niezależnie od tego, kto je wysyła.
+
+Sprawdzenie obowiązuje bez względu na to, kto lub co uruchamia formularz: przeglądarka, skrypt wywołujący REST API
+czy agent AI przez serwer MCP.
+
+---
+
+## Dlaczego istnieje
+
+Reguły formularza (`required`, `regex`, `minValue`, `sameAs`, ...) zawsze były sprawdzane
+w przeglądarce. Przeglądarka wysyła następnie do `POST /api/v2/job` dwie rzeczy:
+
+- `rawFormData`: wartości pól w takiej postaci, w jakiej wypełnił je użytkownik;
+- `extravars`: to, co otrzymuje playbook, zbudowane z tych wartości w przeglądarce.
+
+Bez weryfikacji uruchomienia serwer ufa obu. Każdy z ważnym tokenem może wywołać ten
+punkt końcowy bezpośrednio i wysłać dowolne extravars, bez zastosowania regex, pól wymaganych
+czy reguł list. Dla formularza używanego wyłącznie w przeglądarce może to być do przyjęcia; dla
+formularza, który inne systemy uruchamiają przez REST, oznacza to, że reguły formularza w ogóle nie są egzekwowane.
+
+Serwer nie ma też sposobu, by odróżnić żądanie z przeglądarki od żądania wysłanego przez
+skrypt: oba używają tego samego punktu końcowego, tego samego tokenu i tej samej treści, a użytkownicy mogą zmodyfikować
+każde żądanie wysyłane przez ich własną przeglądarkę. Sprawdzeniu można ufać tylko na serwerze, a weryfikacja
+uruchomienia jest właśnie takim sprawdzeniem.
+
+---
+
+## Trzy drogi wejścia
+
+Sposób weryfikacji uruchomienia zależy od tego, jak ono przychodzi, i od trybu weryfikacji uruchomienia:
+
+| Uruchamiane przez | Weryfikowane | Extravars, z którymi działa zadanie |
+|---|---|---|
+| **Serwer MCP** (agent AI) | zawsze, na serwerze | zawsze budowane przez serwer |
+| **Przeglądarka** lub **REST API**, weryfikacja uruchomienia `off` | tylko w przeglądarce | te, które wysłała przeglądarka (lub wywołujący) |
+| **Przeglądarka** lub **REST API**, weryfikacja uruchomienia `log` | na serwerze, odmowy tylko logowane | wysłane; różnice są logowane |
+| **Przeglądarka** lub **REST API**, weryfikacja uruchomienia `enforce` | na serwerze, odrzucane, gdy nieprawidłowe | **budowane przez serwer** |
+
+Przeglądarka, serwer MCP i weryfikacja uruchomienia używają tego samego kodu reguł (wspólnego
+silnika formularzy): tych samych reguł, w tej samej kolejności, z tymi samymi komunikatami. Błąd, który
+pokazuje przeglądarka, serwer odrzuca z tym samym tekstem.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Włączanie](switching-it-on.html) | Dla całej instancji lub dla jednego formularza |
+| [Log i enforce](log-and-enforce.html) | Co każdy tryb robi z uruchomieniem, które łamie reguły |
+| [Wiersze list](list-rows-and-subforms.html) | Jak weryfikowane są wiersze pól list |
+| [Przesyłanie plików](file-uploads.html) | Jak weryfikowane są pola plików |
+| [Hasła](passwords.html) | Jak weryfikowane są pola haseł i jak są trzymane z dala od API |
+| [Ponowne uruchamianie](relaunching.html) | Jak weryfikowane jest ponownie uruchomione zadanie |
+| [Wdrażanie](rolling-it-out.html) | Przejście instancji na enforce i znane ograniczenia |
diff --git a/i18n/pl/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/pl/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..6841ecf
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Wiersze list
+parent: Weryfikacja uruchomienia
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Wiersze list
+{: .no_toc }
+
+Jak weryfikowane są wiersze pól list
+{: .fs-6 .fw-300 }
+
+---
+
+Pole `list` zawiera wiersze; każdy wiersz jest instancją jego podformularza, wypełnianą w edytorze
+wierszy. Pole `yaml` z `subform` to jeden taki wiersz. Serwer traktuje je tak samo
+jak edytor wierszy w przeglądarce: każdy wiersz jest rozwiązywany przez swój podformularz, z wartościami formularza
+jako `__parent__`, z sprawdzeniem jego reguł i obliczeniem pól wyliczanych. Zagnieżdżone listy działają
+tak samo: we własnej liście wiersza `$(__parent__.__parent__.x)` sięga do formularza.
+
+Wiersze są sprawdzane w następujący sposób:
+
+- **Wiersz, który użytkownik dodał lub edytował** w edytorze, jest rozwiązywany i weryfikowany.
+- **Wiersz, którego nikt nie ruszał**, wygenerowany przez własną wartość domyślną, wyrażenie lub zapytanie listy
+  (np. istniejące wpisy listy ACL), przechodzi **dokładnie w takiej postaci, w jakiej przyszedł**, tak jak w
+  przeglądarce: nie jest ponownie weryfikowany i nic nie jest do niego dodawane. Istniejący wpis, który łamie regułę
+  dopisaną później, nie blokuje uruchomienia.
+- **Wiersz oznaczony jako usunięty** (`deleteMarker` listy) jest zachowywany bez zmian i nie jest weryfikowany.
+
+Aby odróżnić te wiersze bez ufania żądaniu, serwer ponownie uruchamia własne
+źródło listy (jej wartość domyślną, a w przeciwnym razie wyrażenie lub zapytanie) w ramach weryfikacji uruchomienia. Wiersz,
+który nie przeszedł przez edytor, przechodzi bez zmian **tylko wtedy, gdy jest jednym z wierszy, które
+to źródło generuje**. Każdy inny wiersz, na przykład wymyślony przez wywołującego REST, jest rozwiązywany i
+weryfikowany jak wiersz edytowany. Zwykły wiersz nie może więc ominąć sprawdzeń, a nieruszane wiersze
+z przeglądarki nadal przechodzą bez zmian.
+
+Użytkownik przeglądarki zauważy to tylko w jednym przypadku: dane źródła zmieniły się między otwarciem
+formularza a jego uruchomieniem (wpis został w międzyczasie zmieniony lub usunięty), **a** ten wiersz
+łamie regułę swojego podformularza. Wiersz nie jest wtedy już traktowany jako jeden z wierszy źródła, więc
+jest weryfikowany, a uruchomienie zostaje odrzucone ze wskazaniem wiersza, na przykład
+`acls[2].user_or_group (regex)`.
+
+Błędne wiersze pojawiają się w `rowErrors` ze swoim `index` (pole `yaml` go nie ma) oraz w logu jako
+`disks[1].size (maxValue)`.
+
+Uruchomienie może zawierać najwyżej **500 wierszy** na wszystkich poziomach zagnieżdżenia, ponieważ każdy wiersz uruchamia zapytania swojego podformularza.
+
+---
+
+## Znaczniki wierszy
+
+Znaczniki, które lista ustawia na swoich wierszach (`insertMarker`, `updateMarker` i `deleteMarker`; bez
+`insertMarker` nowe wiersze dostają `__inserted__`, gdy lista ustawia `allowDelete: false`, `deleteMarker` lub `updateMarker`),
+trafiają do playbooka w każdym wierszu, który je ma. Usunięty wiersz jest wysyłany ze swoim znacznikiem
+usunięcia, aby playbook mógł go usunąć. Przed wersją 6.4.1 wiersz listy miał znacznik tylko wtedy, gdy jego
+podformularz deklarował go jako (ukryte) pole.
diff --git a/i18n/pl/_build_forms/launch-validation/log-and-enforce.md b/i18n/pl/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..c570c2e
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Log i enforce
+parent: Weryfikacja uruchomienia
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Log i enforce
+{: .no_toc }
+
+Co każdy tryb robi z uruchomieniem, które łamie reguły
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Co robi `log`
+
+Każde uruchomienie jest sprawdzane, ale dla użytkownika nic się nie zmienia. Ostrzeżenie trafia do logu, gdy:
+
+- uruchomienie **zostałoby odrzucone**, wraz z powodem (tylko nazwy pól i typy reguł, nigdy
+  wartości):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- extravars wysłane przez klienta **różnią się** od tych, które buduje serwer, wraz z
+  kluczami najwyższego poziomu, które się różnią:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Najpierw uruchom `log` przez jakiś czas w rzeczywistej instancji. Pokazuje to, które formularze zostałyby odrzucone, a
+które obliczają wartości inaczej na serwerze, zanim ktokolwiek zostanie tym dotknięty.
+
+---
+
+## Co robi `enforce`
+
+W trybie `enforce` nieprawidłowe uruchomienie jest odrzucane, a prawidłowe działa z extravars zbudowanymi
+przez serwer.
+
+### Uruchomienie łamiące reguły jest odrzucane
+
+`POST /api/v2/job` odpowiada kodem `422` z listą błędnych pól:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing` - wymagane pola bez wartości;
+- `invalid` - pola łamiące regułę, wybory spoza dostępnych opcji oraz pola list
+  z błędnym wierszem;
+- `waiting` - pola, których nie dało się obliczyć (pole, którego potrzebują, nigdy nie otrzymało wartości);
+- `validationErrors` - dla każdego pola każda niespełniona reguła z komunikatem, który pokazuje przeglądarka;
+- `rowErrors` - dla każdego pola listy błędne wiersze (zobacz [Wiersze list](list-rows-and-subforms.html));
+- `uploads` - pola plików, których przesłania nie dało się zweryfikować.
+
+Uruchomienie **bez `rawFormData`** również jest odrzucane: jego wartości nie da się sprawdzić.
+
+### Prawidłowe uruchomienie działa z extravars serwera
+
+Zadanie nie działa z extravars wysłanymi przez klienta. Serwer buduje je ze sprawdzonych
+wartości, tym samym kodem co przeglądarka, i uruchamia właśnie je. Wywołujący, który wysyła prawidłowe
+`rawFormData` obok innych `extravars`, otrzymuje extravars odpowiadające wartościom, a nie
+te, które wysłał.
+
+Z żądania serwer zachowuje `__verbose__` (tylko dla użytkowników, którym wolno używać trybu verbose).
+Klucze zastrzeżone (`__playbook__`, `__inventory__`, ...) jak zawsze pochodzą z formularza, a
+`ansibleforms_user` to użytkownik, który uruchamia zadanie.
+
+### To, co widział użytkownik, nie zawsze jest tym, co działa
+
+Zbudowanie extravars oznacza ponowne obliczenie formularza: każde wyrażenie i zapytanie wykonuje się
+jeszcze raz na serwerze, chwilę po tym, jak wykonała je przeglądarka, jako uruchamiający użytkownik. Wartość,
+która zależy od tego, **kiedy** lub **gdzie** jest obliczana, może się różnić i wtedy
+używana jest wartość serwera:
+
+| Co | Dlaczego może się różnić | Jak bardzo |
+|---|---|---|
+| `fn.fnTime()`, znacznik czasu, nazwa zbudowana z czasu | obliczane ponownie, kilka sekund później | ma znaczenie tylko na granicy sekundy lub daty. `fnTime` także w przepływie przeglądarki działa już na serwerze, w tej samej strefie czasowej (`TZ` kontenera) |
+| zapytanie, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, odczyt pliku | dane zewnętrzne zmieniły się w międzyczasie | tylko gdy się zmieniły |
+| wyrażenie `runLocal` używające `new Date()`, `toLocaleString`, `Intl` | przeglądarka używa strefy czasowej i ustawień regionalnych użytkownika, serwer własnych | tylko takie wyrażenia |
+
+To samo dotyczy **walidacji**: reguła, która odczytuje takie pole (`notIn` względem wyniku zapytania,
+`validIf` na obliczonej fladze), jest sprawdzana względem wartości serwera. Formularze, których
+extravars się różnią, pojawiają się w opisanych wyżej ostrzeżeniach `log`; przejrzyj je przed włączeniem enforce.
diff --git a/i18n/pl/_build_forms/launch-validation/passwords.md b/i18n/pl/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..ae84308
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Hasła
+parent: Weryfikacja uruchomienia
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Hasła
+{: .no_toc }
+
+Jak pola haseł są weryfikowane, przechowywane i trzymane z dala od API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pole hasła jest weryfikowane jak każde inne pole. Jego wartość jest jednak przechowywana na serwerze i nigdy nie jest zwracana
+klientowi.
+
+---
+
+## Gdzie przechowywane jest hasło
+
+Serwer przechowuje hasło razem z zadaniem, w jego extravars:
+
+* **Zatwierdzenie** może wtedy kontynuować zadanie z hasłem wprowadzonym przez użytkownika.
+* **Ponowne uruchomienie w pierwotnej postaci** może je odtworzyć, gdy weryfikacja uruchomienia nie jest ustawiona na `enforce`.
+
+Zapisane hasło jest używane wyłącznie na serwerze.
+
+---
+
+## Co zwracają API
+
+Żadne API nigdy nie zwraca hasła:
+
+* Zadanie odczytane przez REST API lub przez `get_job` serwera MCP ma zamaskowane wszystkie pola `password` swojego formularza, także wewnątrz
+  wierszy list i podformularzy YAML.
+* `MASK_EXTRAVARS_REGEX` (domyślnie `password|secret|token`) maskuje też każdą zmienną extravars, której nazwa pasuje, dla
+  sekretów, które nie są polami haseł.
+
+---
+
+## Co otrzymuje ponowne uruchomienie
+
+Aby wstępnie wypełnić ponowne uruchomienie, przeglądarka otrzymuje surowe dane formularza zadania. Te dane nigdy nie zawierają hasła, nawet wewnątrz
+wierszy list czy podformularzy YAML, więc użytkownik wprowadza hasło ponownie.
+
+Pole hasła ukryte przez zależności formularza nie jest potrzebne i nie trzeba go wprowadzać ponownie.
diff --git a/i18n/pl/_build_forms/launch-validation/relaunching.md b/i18n/pl/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..0adf9c9
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Ponowne uruchamianie
+parent: Weryfikacja uruchomienia
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Ponowne uruchamianie
+{: .no_toc }
+
+Jak weryfikowane jest ponownie uruchomione zadanie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zadanie można uruchomić ponownie na dwa sposoby. Sposób sprawdzenia ponownego uruchomienia zależy od tego, który z nich wybrano, i od trybu
+weryfikacji uruchomienia.
+
+---
+
+## Dwa rodzaje ponownego uruchomienia
+
+Oba rodzaje różnią się tym, czy wywołujący wysyła nowe wartości:
+
+* **W pierwotnej postaci**: przycisk Uruchom ponownie, `POST /api/v2/job/{id}/relaunch` bez treści lub `relaunch_job` bez
+  `values`.
+* **Ze zmianami**: te same wywołania z nowymi wartościami, nałożonymi na zapisane wartości pól zadania:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Jak sprawdzany jest każdy z nich
+
+Tryb weryfikacji uruchomienia decyduje, czy ponowne uruchomienie jest odtwarzane, czy sprawdzane od nowa:
+
+| Ponowne uruchomienie | `off` / `log` | `enforce` |
+|---|---|---|
+| **W pierwotnej postaci** | odtwarza zapisane extravars zadania, łącznie z hasłami | pełne sprawdzenie na podstawie zapisanych wartości pól |
+| **Ze zmianami** | pełne sprawdzenie na zapisanych wartościach z nałożonymi zmianami | pełne sprawdzenie, w ten sam sposób |
+
+Jeden wyjątek w trybie `enforce`: zadanie uruchomione przez harmonogram na poziomie administratora nie ma własnych wartości pól, więc ponowne uruchomienie go w pierwotnej postaci
+odtwarza zapisane extravars harmonogramu, dla administratora lub użytkownika z opcją roli `allowScheduledJobs`.
+
+Sprawdzone ponowne uruchomienie (zobacz [Log i enforce](log-and-enforce.html)) rozpoczyna nowe zadanie w imieniu wywołującego.
+
+---
+
+## Pola haseł
+
+Zapisane wartości pól nie zawierają haseł, więc sprawdzone ponowne uruchomienie nie ma żadnego dla **widocznego pola hasła**:
+
+* Ponowne uruchomienie jest odrzucane jako `unsupported`, z listą brakujących `passwordFields`.
+* Uruchom formularz ponownie i wprowadź hasło.
+* Pole hasła, które zależności formularza **ukrywają**, nie jest potrzebne i nie blokuje ponownego uruchomienia.
+
+W trybie `enforce` dotyczy to także przycisku Uruchom ponownie.
+
+---
+
+## Kto może uruchomić ponownie
+
+Oba rodzaje ponownego uruchomienia wymagają:
+
+* aby formularz pozwalał na ponowne uruchomienie (`allowRelaunch`, domyślnie true);
+* opcji roli `allowJobRelaunch`;
+* aby użytkownik był **właścicielem zadania**, administratorem lub użytkownikiem z opcją roli `manageAllJobs`.
+
+Widzenie wszystkich zadań (`showAllJobLogs`) nie wystarcza, aby uruchomić ponownie zadanie innego użytkownika. Zatwierdzający widzą zadanie, które czeka na ich
+zatwierdzenie, ale też nie mogą go uruchomić ponownie.
diff --git a/i18n/pl/_build_forms/launch-validation/rolling-it-out.md b/i18n/pl/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..fa11f0e
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Wdrażanie
+parent: Weryfikacja uruchomienia
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Wdrażanie
+{: .no_toc }
+
+Przejście instancji na enforce i znane ograniczenia
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wdrażanie
+
+`enforce` jest wartością domyślną. W instancji, w której skrypty lub inne systemy uruchamiają formularze przez
+REST, dochodź do niego etapami, obserwując log, zanim cokolwiek zostanie odrzucone:
+
+1. Ustaw `LAUNCH_VALIDATION=log` dla całej instancji (przed aktualizacją, przy aktualizacji).
+2. Działaj w tym trybie przez jakiś czas i przeglądaj log: ostrzeżenia `would refuse` wskazują uruchomienia,
+   które łamią reguły; ostrzeżenia `extravars differ` wskazują formularze, które obliczają coś
+   inaczej na serwerze (znacznik czasu, dane zewnętrzne). Zdecyduj dla każdego formularza, czy ma to
+   znaczenie.
+3. Przełącz te formularze na `launchValidation: enforce`. Wywołujący, którzy wysyłali nieprawidłowe wartości lub
+   zmyślone extravars, dostają teraz `422` z powodem.
+4. Gdy każdy formularz zachowuje się zgodnie z oczekiwaniami, usuń `LAUNCH_VALIDATION` (lub ustaw ją na `enforce`) dla całej instancji.
+
+---
+
+## Ograniczenia
+
+Weryfikacja uruchomienia nie obejmuje jeszcze wszystkiego:
+
+- **Formularzy kreatora** nie można uruchomić ponownie ze zmianami, a zadania kreatora uruchomionego przed wersją 7.0
+  nie można uruchomić ponownie w trybie `enforce` (nie zapisywało wartości kroków). Serwer MCP
+  nie może uruchamiać formularzy kreatora.
+- **Rozwiązywanie symboli zastępczych** w przeglądarce nadal używa własnej kopii kodu serwera; w
+  rzadkich przypadkach brzegowych (`__undefined__`, cudzysłowy wewnątrz wyrażeń) oba mogą rozwiązać
+  symbol zastępczy inaczej. `log` ujawnia takie różnice.
+- Wyrażenia **`runLocal`** działają w silniku JavaScript przeglądarki, gdy są w przeglądarce, a na serwerze w
+  piaskownicy; ten sam kod daje ten sam wynik, z wyjątkiem sytuacji, gdy zależy od
+  strefy czasowej lub ustawień regionalnych przeglądarki.
+
+---
+
+## Formularze kreatora
+
+[Kreator](../forms/wizard.html) jest sprawdzany krok po kroku: przeglądarka wysyła wartości
+każdego kroku, a serwer sprawdza każdy krok, który użytkownik by wysłał, względem jego własnego podformularza.
+
+- Krok jest pomijany, gdy jest `optional` i użytkownik go pominął albo gdy jego `when` jest fałszywe.
+- Krok odczytuje wcześniejsze kroki przez `$(__parent__.<step>.<field>)`, z ich sprawdzonymi wartościami.
+- Błędy wskazują krok i pole jako `<step>.<field>`.
+- W trybie `enforce` extravars są budowane na serwerze, każdy krok pod swoim `defaultModel`.
+- Pola plików nie są obsługiwane w kreatorze.
diff --git a/i18n/pl/_build_forms/launch-validation/switching-it-on.md b/i18n/pl/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..9d391e2
--- /dev/null
+++ b/i18n/pl/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Włączanie
+parent: Weryfikacja uruchomienia
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Włączanie
+{: .no_toc }
+
+Dla całej instancji lub dla jednego formularza
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Weryfikacja uruchomienia ma dwa ustawienia. **Obowiązuje bardziej restrykcyjne z nich.**
+
+---
+
+## Dla całej instancji: `LAUNCH_VALIDATION`
+
+Zmienna środowiskowa [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) dotyczy każdego formularza:
+
+- `off` - brak sprawdzania po stronie serwera: zadanie działa z extravars wysłanymi przez przeglądarkę lub wywołującego.
+- `log` - każde uruchomienie jest sprawdzane; to, co zostałoby odrzucone, trafia do logu jako
+  ostrzeżenie, a uruchomienie przebiega jak dotąd.
+- `enforce` (domyślnie) - nieprawidłowe uruchomienie jest odrzucane, a prawidłowe działa z extravars
+  zbudowanymi przez serwer.
+
+Pusta lub nieznana wartość również oznacza `enforce`. Zmiany obowiązują bez restartu.
+
+{: .warning }
+> **Aktualizacja zmienia zachowanie.** Instancja, która nie ustawia `LAUNCH_VALIDATION`, po aktualizacji
+> egzekwuje każde uruchomienie. Skrypty, które wywołują `POST /api/v2/job` bez `rawFormData`
+> lub z wartościami łamiącymi reguły formularza, są odrzucane z kodem `422`. Ustaw
+> `LAUNCH_VALIDATION=log` przed aktualizacją, aby zobaczyć, co zostałoby odrzucone, albo `off`, aby zachować
+> dotychczasowe zachowanie (zobacz [Wdrażanie](rolling-it-out.html)).
+
+---
+
+## Dla jednego formularza: `launchValidation`
+
+Formularz może ustawić własny poziom:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Używaj tego ustawienia w instancji działającej z `off` lub `log`, dla formularza, o którym wiesz, że będzie
+uruchamiany przez REST: ten formularz jest egzekwowany, a reszta instancji nie. Można je też ustawić w projektancie, w
+ustawieniach formularza.
+
+**Formularz może być bardziej restrykcyjny niż instancja, nigdy mniej.** Gdy `LAUNCH_VALIDATION`
+ma wartość `enforce`, `launchValidation: off` w formularzu nie ma żadnego efektu: formularz nie może nadpisać
+decyzji operatora.
+
+Formularze kreatora również z niego korzystają: uruchomienie kreatora jest sprawdzane krok po kroku, każdy krok względem własnego
+podformularza (zobacz [Formularze kreatora](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/pl/_build_forms/workflows/designer.md b/i18n/pl/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..842753f
--- /dev/null
+++ b/i18n/pl/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Edycja w projektancie
+parent: Workflowy
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Edycja w projektancie
+{: .no_toc }
+
+Narysuj workflow i wypróbuj go, niczego nie uruchamiając
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sekcja Przepływy pracy
+
+**Projektant > Przepływy pracy** wyświetla pliki workflow w eksploratorze plików, z kartami YAML, Wizualny i Podgląd, takimi jak w każdej
+sekcji [projektanta](../designer/).
+
+- **Przycisk `+`** na pasku narzędzi tworzy plik workflow z pustym workflow na początek.
+- **YAML** pokazuje plik w takiej postaci, w jakiej jest zapisany. Komentarze i kolejność kluczy są zachowywane także przez pozostałe karty.
+- **Wizualny** rysuje każdy workflow z pliku jako graf, z nazwą i opisem nad nim. Plik z dwoma workflow
+  pokazuje oba, jeden pod drugim.
+- **Podgląd** to próbne uruchomienie workflow: zobacz [Wypróbowanie](#trying-it-out).
+
+Problemy są wymienione nad grafem, każdy z linkiem otwierającym YAML w odpowiednim wierszu: połączenie do węzła, który nie
+istnieje, pętla, playbook, inwentarz, poświadczenie, runner lub repozytorium, których projektant nie zna.
+
+---
+
+## Graf
+
+Graf czyta się od lewej do prawej, od **START** do ostatnich węzłów. Każdy węzeł pokazuje swój identyfikator, a pod nim to, co
+uruchamia; połączenia są pokolorowane według tego, co je uruchamia, jak mówi legenda wewnątrz grafu: przy sukcesie, przy błędzie,
+zawsze.
+
+- **Kliknij START**, aby dodać pierwszy węzeł: węzeł bez rodzica, który uruchamia się, gdy tylko wystartuje workflow.
+- **Kliknij węzeł**, aby go edytować.
+- **Kliknij połączenie**, aby zmienić to, co je uruchamia, lub je usunąć.
+
+---
+
+## Dodawanie węzła
+
+Nowy węzeł dodaje się kreatorem: **Nowy węzeł przy sukcesie**, **Nowy węzeł przy błędzie** lub **Nowy węzeł zawsze** na istniejącym
+węźle albo START dla pierwszego.
+
+1. **Co uruchamia**: identyfikator węzła, **Uruchamia** (jakiego rodzaju jest węzeł i, dla węzła playbooka, gdzie działa)
+   oraz to, co uruchamia: playbook albo szablon lub zadanie, workflow, nazwę i limit czasu zatwierdzenia albo repozytorium. Zobacz
+   [Gdzie działa węzeł](#where-a-node-runs).
+2. **Jak działa**: ustawienia uruchamiania: inwentarz, poświadczenia, limit, tagi, szczegółowość,
+   tryb check i diff, warunek (**Działa, gdy**) oraz **Wartości z** (zobacz [plik workflow](file.html#run-settings)).
+3. **Dokąd prowadzi**: węzeł, po którym się uruchamia, i w jakiej sytuacji.
+
+**Utwórz** dodaje węzeł do YAML.
+
+---
+
+## Gdzie działa węzeł
+
+**Uruchamia** mówi, co węzeł uruchamia i gdzie, na jednej liście: **Playbook na RTE**, **Szablon na AWX**, **Szablon na
+Semaphore**, **Zadanie na Rundeck**, **Zadanie na Jenkins**, a potem **Workflow**, **Zatwierdzenie** i **Pull repozytorium**.
+
+| Uruchamia | Pole pod nim | Runner |
+|---|---|---|
+| **Playbook na RTE** | **Playbook**: playbook z projektanta | **Domyślne RTE** lub runner RTE wskazany z nazwy |
+| **Szablon na AWX** (łącznie z AAP i Ascender) | **Szablon**: wpisana nazwa szablonu | runnery AWX, każdy ze swoim wariantem |
+| **Szablon na Semaphore** | **Szablon**: wpisana nazwa szablonu | runnery Semaphore |
+| **Zadanie na Rundeck** lub **Zadanie na Jenkins** | **Zadanie**: wpisana nazwa zadania | runnery Rundeck lub Jenkins |
+
+- **Playbook na RTE** jest zawsze dostępny; pozostałe tylko wtedy, gdy instancja ma [runner](../runners.html) danego typu.
+- **Runner** wyświetla tylko runnery danego typu, z oznaczonym i wstępnie wybranym domyślnym (lub pierwszym według nazwy).
+- Wybór innego miejsca czyści to, co węzeł uruchamia, więc trzeba to wybrać ponownie.
+- Węzeł, którego runnera projektant nie zna, pokazuje **Szablon lub zadanie na** tym runnerze.
+
+Plik workflow się nie zmienia: taki węzeł to węzeł `job_template` z `runner:` (zobacz
+[plik workflow](file.html#run-settings)).
+
+---
+
+## Edycja węzła
+
+Kliknięcie węzła otwiera jego okno dialogowe z czterema kartami:
+
+| Karta | Co zawiera |
+|---|---|
+| **Co uruchamia** | Identyfikator, **Uruchamia**, to, co uruchamia, oraz, dla węzła playbooka, runner |
+| **Jak działa** | Ustawienia uruchamiania; poświadczenia wybiera się z listy, każde dodaje się przez `+` |
+| **Uruchamia się po** | Połączenia prowadzące do węzła oraz **Wszyscy rodzice muszą się zbiec** |
+| **Uruchamia potem** | Połączenia wychodzące z niego, z **Połącz z istniejącym węzłem:** i **Połącz z nowym węzłem:** |
+
+**Pokaż w YAML** otwiera YAML na węźle, a **Usuń węzeł** usuwa go wraz z jego połączeniami. Każda zmiana jest od razu zapisywana w
+YAML; **Zapisz** zapisuje plik.
+
+---
+
+## Wypróbowanie
+
+Karta **Podgląd** odtwarza workflow bez uruchamiania czegokolwiek, według zasad AWX.
+
+Każdy węzeł zaczyna jako sukces. Kliknij węzeł, aby zakończył się błędem, i kliknij ponownie, aby znów zakończył się sukcesem; graf pokazuje wtedy,
+które węzły by się uruchomiły, które by się nie uruchomiły i czy workflow zakończyłby się błędem. **Resetuj** sprawia, że każdy węzeł znów kończy się sukcesem.
diff --git a/i18n/pl/_build_forms/workflows/file.md b/i18n/pl/_build_forms/workflows/file.md
new file mode 100644
index 0000000..fcc73b6
--- /dev/null
+++ b/i18n/pl/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Plik workflow
+parent: Workflowy
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# Plik workflow
+{: .no_toc }
+
+Składnia workflow, typy węzłów i ustawienia uruchamiania każdego węzła
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gdzie znajdują się pliki workflow
+
+Pliki workflow to pliki YAML w lokalnym folderze workflow i w każdym repozytorium używanym do workflowów.
+
+- **Folder lokalny** to [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), domyślnie `workflows` w
+  folderze trwałym.
+- **Repozytorium** z włączonym **Używać do workflowów?** jest odczytywane w całości, więc jego pliki workflow mogą leżeć w dowolnym folderze.
+  Projektant zapisuje je z powrotem do repozytorium, a **Push** wysyła je do repozytorium zdalnego.
+
+Odczytywany jest każdy plik YAML zawierający `workflow_job_templates`, do sześciu poziomów folderów w głąb, a jeden plik może zawierać kilka
+workflowów. Formularz wskazuje workflow po jego `name`, więc nazwy muszą być unikalne: gdy dwa workflowy mają tę samą nazwę, zadanie,
+które go uruchamia, kończy się błędem z informacją, by zmienić nazwę jednego z nich.
+
+---
+
+## Składnia
+
+Plik workflow zapisuje się w składni eksportu AWX, z węzłami pod `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+Odczytywany jest też kształt z kolekcji `awx.awx`: `workflow_nodes` bezpośrednio pod workflow i nazwy zapisane jako
+zwykłe ciągi (`inventory: staging`), a nie mapy (`inventory: {name: staging}`).
+
+### Workflow
+
+Wpis workflow ma obok swoich węzłów kilka własnych kluczy:
+
+| Klucz | Co to jest |
+|---|---|
+| `name` | Nazwa workflow, którą wskazuje `workflow:` formularza |
+| `description` | Do czego służy, wyświetlane w projektancie |
+| `extra_vars` | Zmienne, które otrzymuje każdy węzeł; wartości formularza mają nad nimi pierwszeństwo |
+| `related.workflow_nodes` | Węzły |
+
+### Węzeł
+
+Każdy węzeł ma identyfikator, to, co uruchamia, i swoje połączenia:
+
+| Klucz | Co to jest |
+|---|---|
+| `identifier` | Id węzła: litery, cyfry, kropki, myślniki, dwukropki i podkreślenia, unikalne w workflow |
+| `unified_job_template.type` | Co uruchamia węzeł: zobacz [typy węzłów](#node-types) |
+| `unified_job_template.name` | Playbook, workflow, zatwierdzenie lub repozytorium, które uruchamia |
+| `related.success_nodes` | Węzły uruchamiane, gdy ten zakończy się sukcesem |
+| `related.failure_nodes` | Węzły uruchamiane, gdy ten zakończy się błędem |
+| `related.always_nodes` | Węzły uruchamiane, gdy ten się zakończy, w dowolny sposób |
+| `all_parents_must_converge` | `true`: węzeł czeka, aż zadziałają wszystkie prowadzące do niego połączenia, a nie tylko jedno |
+
+Połączenia muszą prowadzić do przodu: workflow, którego połączenia tworzą pętlę, nie zostanie uruchomiony.
+
+---
+
+## Typy węzłów
+
+Węzeł uruchamia jedną z czterech rzeczy, nazwanych tak jak w AWX:
+
+| Typ | Co uruchamia węzeł |
+|---|---|
+| `job_template` | Jeden z playbooków projektanta, jako osobne zadanie na RTE; albo, z `runner:`, szablon lub zadanie tego runnera |
+| `workflow_job_template` | Inny workflow, jako podrzędne zadanie workflow; workflowy można zagnieżdżać do pięciu poziomów |
+| `workflow_approval_template` | Zatwierdzenie: zadanie workflow czeka, aż ktoś je zatwierdzi lub odrzuci |
+| `project` | Pull wskazanego repozytorium (aktualizacja projektu w AWX) |
+
+`unified_job_template.timeout` węzła zatwierdzenia podaje się w sekundach. Gdy upłynie bez odpowiedzi, węzeł kończy się błędem; `0` lub brak
+limitu czasu oznacza czekanie na odpowiedź bez względu na to, jak długo to potrwa. Odrzucone zatwierdzenie kończy węzeł błędem, a workflow idzie dalej swoimi
+połączeniami.
+
+---
+
+## Ustawienia uruchamiania
+
+Węzeł `job_template` przyjmuje ustawienia węzła AWX, na samym węźle:
+
+| Klucz | Co robi |
+|---|---|
+| `inventory` | Inwentarz, na którym działa playbook, wskazany z nazwy, jak `inventory:` formularza |
+| `related.credentials` | Poświadczenia: każde trafia do playbooka pod własną nazwą, a pierwsze typu *SSH* jest też loginem, którym łączy się ansible. Poświadczenie vault służy tylko do otwierania vaultów |
+| `limit` | Uruchamia tylko na tych hostach (`--limit`) |
+| `job_tags` | Uruchamia tylko zadania z tymi tagami (`--tags`) |
+| `skip_tags` | Pomija zadania z tymi tagami (`--skip-tags`) |
+| `verbosity` | Od `0` do `5`: liczba `-v` |
+| `diff_mode` | `true`: pokazuje zmiany (`--diff`) |
+| `job_type` | `check`: uruchomienie próbne (`--check`); `run` lub brak: rzeczywiste uruchomienie |
+| `extra_data` | Zmienne, które otrzymuje ten węzeł, poniżej `extra_vars` workflow i wartości formularza |
+
+Zadanie węzła otrzymuje wartości formularza jako extra vars. Wartości formularza mają pierwszeństwo przed `extra_vars` workflow, które mają pierwszeństwo
+przed `extra_data` węzła, tak jak odpowiedzi ankiety w AWX.
+
+---
+
+## Własne klucze AnsibleForms
+
+Trzy klucze węzła należą do AnsibleForms, a AWX je ignoruje, dzięki czemu workflow może robić to, co formularz wieloetapowy:
+
+| Klucz | Co robi |
+|---|---|
+| `runner` | W węźle `job_template` uruchamia szablon lub zadanie tego runnera zamiast playbooka projektanta: AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins. Runner RTE uruchamia tam playbook węzła. Jeden workflow może je łączyć. |
+| `if_extra_var` | Węzeł uruchamia się tylko wtedy, gdy ta extra var ma wartość `true`, jak `ifExtraVar` kroku formularza wieloetapowego. Gdy warunek nie jest spełniony, węzeł jest pomijany, a to, co następuje po nim, działa jak po sukcesie. Nie dotyczy węzła zatwierdzenia, który zawsze działa. |
+| `extra_vars_key` | Węzeł otrzymuje tylko ten klucz extra vars, ze skopiowanym użytkownikiem, jak `key` kroku formularza wieloetapowego |
+
+Na runnerze szablonów `unified_job_template.name` to szablon lub zadanie do uruchomienia, a `limit`, `job_tags`, tryb check
+i tryb diff węzła są przekazywane tak, jak przekazałby je formularz typu tego runnera. `verbosity` powyżej `0` włącza
+`verbose` formularza, a `skip_tags` nie jest przekazywany. Tylko runner AWX (AWX, AAP lub Ascender) otrzymuje inwentarz węzła, a
+poświadczenia jako swoje poświadczenia AWX; Semaphore, Rundeck i Jenkins otrzymują poświadczenia jako `credentials` formularza.
diff --git a/i18n/pl/_build_forms/workflows/index.md b/i18n/pl/_build_forms/workflows/index.md
new file mode 100644
index 0000000..147fe83
--- /dev/null
+++ b/i18n/pl/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflowy
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflowy
+{: .no_toc }
+
+Łączenie playbooków, zatwierdzeń i innych workflow w łańcuch, tak jak w AWX
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla autorów formularzy: czym jest workflow, jak działają jego węzły i gdzie czytać dalej.
+
+Workflow to graf węzłów. Każdy węzeł coś uruchamia: jeden z playbooków projektanta, inny workflow, zatwierdzenie
+lub pull repozytorium. Połączenia między węzłami mówią, co uruchamia się potem: przy sukcesie, przy błędzie lub zawsze. Uruchamia go formularz
+[typu `workflow`](../forms/workflow.html), a strona zadań rysuje go na żywo w trakcie działania.
+
+Workflowy stosują składnię i zasady AWX, więc workflow wyeksportowany z AWX czyta się w AnsibleForms tak samo. Działają
+na RTE, bez AWX: węzeł playbooka to osobne zadanie, z inwentarzem, poświadczeniami, limitem i tagami węzła.
+
+---
+
+## Jak działa workflow
+
+Węzły działają według zasad AWX, a gałęzie, które od siebie nie zależą, działają równolegle.
+
+- **Węzeł bez rodzica startuje od razu**, gdy startuje workflow.
+- **Połączenie zadziała, gdy jego węzeł się zakończy**: połączenie *przy sukcesie* po sukcesie, połączenie *przy błędzie* po błędzie,
+  połączenie *zawsze* po jednym lub drugim. Anulowany węzeł nie uruchamia żadnego ze swoich połączeń.
+- **Węzeł startuje, gdy tylko zadziała jedno prowadzące do niego połączenie.** Przy włączonym **Wszyscy rodzice muszą się zbiec** czeka, aż zadziałają wszystkie
+  połączenia do niego.
+- **Węzeł, który nie może już wystartować, jest oznaczany jako *nie uruchamia się***, podobnie jak węzły, które tylko on mógł uruchomić.
+- **Workflow kończy się błędem, gdy węzeł zakończył się błędem i nic go nie obsługuje**: ten węzeł nie ma połączenia *przy błędzie* ani *zawsze*.
+  Błąd obsłużony przez połączenie nie powoduje błędu workflow.
+
+Węzeł z niespełnionym warunkiem (`if_extra_var`) jest pomijany. To, co następuje po nim, działa jak po sukcesie. Węzeł
+zatwierdzenia nie przyjmuje warunku: zawsze czeka na odpowiedź.
+
+---
+
+## Przekazywanie danych między węzłami
+
+To, co playbook węzła zbierze przez `set_stats`, trafia do kolejnych węzłów jako extra vars, tak jak AWX przekazuje dalej
+artefakty zadania. Węzeł otrzymuje dane od każdego rodzica, którego połączenie do niego zadziałało, scalone w kolejności zapisania
+rodziców, i przekazuje dalej to, co dostał, plus dane własnego zadania; przy kluczu ustawionym przez oba wygrywają jego własne.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Węzeł po nim odczytuje wtedy {% raw %}`{{ version }}` i `{{ build_id }}`{% endraw %} jak każdą inną extra var.
+
+Extra vars węzła pochodzą z czterech miejsc. Jedno z nich, `extra_data`, to własne zmienne węzła: tak nazywa je AWX,
+ustawiane na węźle w [pliku workflow](file.html#run-settings). Gdy dwa z nich ustawiają ten sam klucz, kolejność pierwszeństwa jest
+taka jak w AWX, od najniższego:
+
+| Źródło | Wygrywa z |
+|---|---|
+| własne zmienne węzła (`extra_data`) | niczym |
+| dane przekazane dalej przez `set_stats` | `extra_data` węzła |
+| `extra_vars` workflow | przekazanymi danymi |
+| wartości formularza | wszystkim |
+
+- Przekazywane są tylko dane dotyczące całego playbooka: `set_stats` z `per_host: false`, czyli domyślnie.
+- Węzeł zatwierdzenia, węzeł pominięty i węzeł projektu przekazują dalej to, co do nich dotarło.
+- Wynik węzła kończy się kluczami, które przekazał dalej, tylko z nazwy, ponieważ ich wartości mogą być tajne.
+- Zadanie węzła zachowuje swoje dane jako artefakty (**Pokaż artefakty** na jego stronie), a zadanie workflow zachowuje dane wszystkich
+  swoich węzłów, więc zagnieżdżony workflow również przekazuje je kolejnym węzłom.
+- Węzeł działający na runnerze AWX w ten sam sposób przekazuje dalej artefakty swojego zadania AWX.
+---
+
+## W tej sekcji
+
+Na kolejnych stronach szczegółowo opisano workflowy:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Plik workflow](file.html) | Składnia pliku, typy węzłów i ustawienia uruchamiania każdego węzła |
+| [Edycja w projektancie](designer.html) | Sekcja Przepływy pracy w projektancie: graf, okna dialogowe węzłów i połączeń oraz próbne uruchomienie |
+| [Uruchamianie workflow](running.html) | Formularz, który go uruchamia, strona zadania, wyniki węzłów, zatwierdzenia i przerywanie |
diff --git a/i18n/pl/_build_forms/workflows/running.md b/i18n/pl/_build_forms/workflows/running.md
new file mode 100644
index 0000000..de62a3a
--- /dev/null
+++ b/i18n/pl/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Uruchamianie workflow
+parent: Workflowy
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Uruchamianie workflow
+{: .no_toc }
+
+Uruchom workflow z formularza i śledź go na stronie zadań
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Formularz
+
+Formularz [typu `workflow`](../forms/workflow.html) uruchamia workflow wskazany przez `workflow:`, tak jak playbook: przez
+jego **plik** w folderze workflow, z podfolderami (`team/deploy-app.yml`), albo przez **nazwę** workflow wewnątrz
+pliku (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+Pola formularza trafiają do każdego węzła jako extra vars, podobnie jak jego [`credentials`](../forms/workflow.html#workflow_credentials), pod nazwami,
+które nadaje im formularz, tak jak w formularzu wieloetapowym trafiają do jego kroków:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+Własne poświadczenia węzła, ustawione w pliku workflow, trafiają do jego playbooka pod własną nazwą i wygrywają przy nazwie używanej przez oba. Na karcie Wizualny formularza w projektancie
+**Workflow** to lista plików workflow projektanta.
+
+Sama nazwa pliku zostanie znaleziona także w podfolderze, jeśli ma ją tylko jeden plik. Dwa workflowy o tej samej nazwie blokują formularz, który wskazuje
+workflow po nazwie, a projektant ostrzega przy zapisywaniu drugiego: zmień nazwę jednego z nich albo wskaż jego plik. Workflow, którego nie da się
+znaleźć, kończy zadanie błędem, z powodem w wyniku.
+
+---
+
+## Zadanie
+
+Zadanie workflow działa na serwerze AnsibleForms, a każdy węzeł playbooka działa jako osobne zadanie, podrzędne wobec zadania
+workflow, tak jak kroki formularza wieloetapowego: playbook projektanta na RTE albo, dla węzła z `runner:`, szablon
+lub zadanie tego runnera na AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins (zobacz [Gdzie działa węzeł](designer.html#where-a-node-runs)).
+
+Strona zadania rysuje workflow na żywo: każdy węzeł pokolorowany według stanu, połączenia, które zadziałały, i węzły, które
+się nie uruchomią. Informacje na górze wskazują workflow zamiast playbooka.
+
+- **Kliknij węzeł**, który się zakończył, aby otworzyć jego wynik w oknie dialogowym.
+- **Wynik** zawiera wynik każdego węzła pod banerem `WORKFLOW NODE [identifier] (status)`, w kolejności, w jakiej węzły
+  się zakończyły.
+- **Pokaż extravars** i **Pokaż artefakty**, w nagłówku każdego węzła w wyniku i w oknie dialogowym otwieranym z grafu,
+  pokazują własne extravars i artefakty tego węzła (`{}`, gdy ich nie ma), jako JSON lub YAML, z przyciskiem Kopiuj.
+
+Extravars węzła zawierają to, co przekazały mu wcześniejsze węzły, a jego artefakty to, co jego playbook zebrał przez
+`set_stats`. Oba przyciski zależą od [opcji ról](../config/roles.html#role-options) `showExtravars` i
+`showArtifacts`. Te same dane zwraca `GET /api/v2/job/{id}/node/{nodeId}`, dla każdego, kto może widzieć zadanie.
+
+Zadanie kończy się błędem, gdy węzeł zakończył się błędem i nic go nie obsłużyło, zgodnie z zasadą AWX; w przeciwnym razie kończy się sukcesem.
+
+---
+
+## Zatwierdzenia
+
+Węzeł zatwierdzenia wstrzymuje zadanie workflow, dopóki ktoś nie udzieli odpowiedzi.
+
+Gdy workflow dochodzi do węzła zatwierdzenia, stan zadania zmienia się na **Oczekuje na zatwierdzenie**: widać to przy dzwonku i na
+stronie zadania, tak jak w przypadku [punktu zatwierdzenia](../forms/approval.html) formularza. Nazwa węzła jest tytułem zatwierdzenia, a jego opis
+komunikatem; reszta pochodzi z `approval` formularza:
+
+- jego `roles` decydują, kto może je zatwierdzić lub odrzucić, a `allowSelf`, czy uruchamiający także może je zatwierdzić;
+- do jego `notifications` i `channels` wysyłana jest prośba.
+
+Formularz workflow bez `approval` również wstrzymuje zadanie na węźle zatwierdzenia, ale wtedy zatwierdzić je może tylko administrator.
+
+- **Zatwierdzone**: węzeł kończy się sukcesem, a workflow idzie dalej połączeniami *przy sukcesie*.
+- **Odrzucone**: węzeł kończy się błędem, a workflow idzie dalej połączeniami *przy błędzie*.
+- **Przekroczony czas**: po upływie limitu czasu węzła bez odpowiedzi węzeł również kończy się błędem.
+
+---
+
+## Przerywanie
+
+**Przerwij** w działającym zadaniu workflow zatrzymuje je: działające zadania węzłów są przerywane, nic więcej nie startuje, a zatwierdzenie,
+na które czeka, jest anulowane. Zadanie workflow czekające na zatwierdzenie także można przerwać.
diff --git a/i18n/pl/_configure/announcements.md b/i18n/pl/_configure/announcements.md
new file mode 100644
index 0000000..14b2a3e
--- /dev/null
+++ b/i18n/pl/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Ogłoszenia
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Ogłoszenia
+{: .no_toc }
+
+Komunikaty pod nagłówkiem dla wszystkich, np. o oknie serwisowym, każdy widoczny od swojego początku do końca
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: poinformuj wszystkich użytkowników o oknie serwisowym lub awarii w **Ustawienia > Wygląd > Ogłoszenia**.
+
+Strona wymaga opcji roli `showSettings` lub `showAppearanceSettings`. Od wersji 7.3.0 jest to jedna lista, a każde ogłoszenie
+ma własną stronę i przełącznik Włączone.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Ogólne](announcements/general.html) | Przełącznik Włączone każdego ogłoszenia, który zastąpił wspólny przełącznik dla wszystkich |
+| [Lista](announcements/list.html) | Ogłoszenia, które się jeszcze nie zakończyły, ich kolumny i strona ogłoszenia |
+| [Dodawanie ogłoszenia](announcements/adding-one.html) | Dwuetapowy kreator: najpierw treść, potem czas wyświetlania |
+
+
+---
+
+## Gdzie się wyświetlają
+
+Ogłoszenia wyświetlają się jako wiersz pod nagłówkiem każdej strony, każdemu zalogowanemu użytkownikowi, każde w kolorze swojego typu.
+
+Kilka włączonych ogłoszeń może być widocznych naraz, najnowsze na górze. Strona logowania i formularz osadzony w innej witrynie nie pokazują żadnego.
+
+Każde ma przycisk zamknięcia. Zamknięte ogłoszenie pozostaje zamknięte w tej karcie przeglądarki, dopóki karta nie zostanie zamknięta albo
+dopóki nie zmieni się jego treść lub data zakończenia. Zapisane ogłoszenie od razu trafia do wszystkich otwartych przeglądarek; ogłoszenie, które
+osiąga datę rozpoczęcia lub zakończenia, pojawia się w nich lub znika w ciągu minuty.
diff --git a/i18n/pl/_configure/announcements/adding-one.md b/i18n/pl/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..3116e64
--- /dev/null
+++ b/i18n/pl/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Dodawanie ogłoszenia
+parent: Ogłoszenia
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Dodawanie ogłoszenia
+{: .no_toc }
+
+Dwuetapowy kreator: najpierw treść, potem czas wyświetlania
+{: .fs-6 .fw-300 }
+
+**Dodaj ogłoszenie** otwiera dwuetapowy kreator. Krok **Komunikat** pyta o treść:
+
+| Pole | Znaczenie |
+|---|---|
+| **Wiadomość** | Tekst, maksymalnie 500 znaków. Wymagane. |
+| **Typ** | Kolor i ikona: niebieski dla Informacja (domyślnie), bursztynowy dla Ostrzeżenie, czerwony dla Zagrożenie |
+
+Krok **Kiedy** pyta, kiedy ma się wyświetlać:
+
+| Pole | Znaczenie |
+|---|---|
+| **Data rozpoczęcia** | Od tej chwili ogłoszenie jest widoczne. Pozostaw puste, aby pokazać je od razu. |
+| **Data zakończenia** | W tej chwili ogłoszenie zostaje ukryte i usunięte. Pozostaw puste, aby zostało, dopóki go nie usuniesz. |
+
+Data zakończenia musi przypadać po dacie rozpoczęcia i leżeć w przyszłości.
diff --git a/i18n/pl/_configure/announcements/general.md b/i18n/pl/_configure/announcements/general.md
new file mode 100644
index 0000000..b620be3
--- /dev/null
+++ b/i18n/pl/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Ogólne
+parent: Ogłoszenia
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Ogólne
+{: .no_toc }
+
+Przełącznik Włączone każdego ogłoszenia, który zastąpił wspólny przełącznik dla wszystkich
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Włączanie i wyłączanie ogłoszenia
+
+Od wersji 7.3.0 każde ogłoszenie włącza się i wyłącza osobno, jego przełącznikiem **Włączone**.
+
+Nowe ogłoszenie jest włączone. **Wyłącz** w menu jego wiersza albo przełącznik **Włączone** na jego stronie ukrywa je pod nagłówkiem, ale zostawia
+na liście, a **Włącz** znów je pokazuje od daty rozpoczęcia do daty zakończenia. Przełącznik zapisuje się od razu.
+
+---
+
+## Przełącznik Pokaż ogłoszenia z wersji 7.2
+
+Do wersji 7.2 karta **Ogólne** miała przełącznik **Pokaż ogłoszenia**, który włączał lub wyłączał wszystkie naraz.
+
+Od wersji 7.3.0 tego przełącznika już nie ma. Jeśli był wyłączony, aktualizacja wyłącza wszystkie ogłoszenia, żeby żadne nie zaczęło się wyświetlać: włącz ponownie te, które chcesz.
diff --git a/i18n/pl/_configure/announcements/list.md b/i18n/pl/_configure/announcements/list.md
new file mode 100644
index 0000000..94f807d
--- /dev/null
+++ b/i18n/pl/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Lista
+parent: Ogłoszenia
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Lista
+{: .no_toc }
+
+Ogłoszenia, które się jeszcze nie zakończyły, ich kolumny i strona ogłoszenia
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lista
+
+**Ustawienia > Wygląd > Ogłoszenia** wyświetla wszystkie ogłoszenia, które się jeszcze nie zakończyły, z tymi kolumnami:
+
+| Kolumna | Znaczenie |
+|---|---|
+| **Włączone** | Czy wyświetla się pod nagłówkiem od początku do końca (od wersji 7.3.0) |
+| **Wiadomość** | Tekst pod nagłówkiem |
+| **Typ** | Informacja, Ostrzeżenie lub Zagrożenie |
+| **Data rozpoczęcia** | Kiedy zaczyna się wyświetlać; `–`, gdy wyświetla się od razu |
+| **Data zakończenia** | Kiedy się kończy; `–`, gdy wyświetla się do usunięcia |
+| **Utworzone przez** | Kto je dodał |
+
+Kliknięcie wiersza albo **Edytuj** w menu wiersza otwiera stronę ogłoszenia. W menu są też **Włącz** lub **Wyłącz** oraz **Usuń**.
+
+Po upływie daty zakończenia ogłoszenie jest usuwane: na liście zostają tylko te nadchodzące i te, które są właśnie widoczne.
+
+---
+
+## Strona ogłoszenia
+
+Od wersji 7.3.0 każde ogłoszenie otwiera się na własnej stronie, pod adresem `/settings/announcements/<id>`, z jedną kartą, **Szczegóły**.
+
+Zawiera treść, typ, daty rozpoczęcia i zakończenia oraz przełącznik **Włączone**, który zapisuje się od razu; pozostałe pola zapisuje się
+przyciskiem **Zapisz**, a **Usuń** usuwa ogłoszenie. Tytuł strony nazywa je pierwszymi znakami jego treści.
diff --git a/i18n/pl/_configure/appearance.md b/i18n/pl/_configure/appearance.md
new file mode 100644
index 0000000..80e6138
--- /dev/null
+++ b/i18n/pl/_configure/appearance.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Wygląd
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Wygląd
+{: .no_toc }
+
+Wartości domyślne, nazwa, logo, ikona przeglądarki, linki nagłówka i etykiety obok logo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: dopasuj wygląd instancji do swojej organizacji w **Ustawienia > Wygląd**, z opcją roli `showSettings`.
+Sama opcja roli `showAppearanceSettings` też otwiera te strony, razem z ogłoszeniami, bez reszty ustawień.
+
+Strony tej grupy to **Wartości domyślne**, **Nazwa**, **Logo**, **Ikona**, **Linki**, **Etykiety** i **Ogłoszenia**;
+ogłoszenia mają własną stronę, [Ogłoszenia](announcements.html). Zapisana wartość domyślna, nazwa, link lub etykieta
+pojawia się od razu w każdej otwartej przeglądarce.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Wartości domyślne](appearance/defaults.html) | Motyw, język, strefa czasowa i format daty dla użytkowników, którzy żadnych nie wybrali |
+| [Nazwa](appearance/name.html) | Nazwa aplikacji na karcie przeglądarki i na stronie logowania |
+| [Logo](appearance/logo.html) | Własne logo w nagłówku |
+| [Ikona](appearance/icon.html) | Własna ikona na karcie przeglądarki i w zakładkach |
+| [Linki](appearance/links.html) | Linki nagłówka, wbudowane i własne |
+| [Etykiety](appearance/labels.html) | Etykiety obok logo, które mówią, która to instancja; do wersji 7.2 jedna etykieta Środowisko |
+
diff --git a/i18n/pl/_configure/appearance/defaults.md b/i18n/pl/_configure/appearance/defaults.md
new file mode 100644
index 0000000..e34cf56
--- /dev/null
+++ b/i18n/pl/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Wartości domyślne
+parent: Wygląd
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Wartości domyślne
+{: .no_toc }
+
+Motyw, język, strefa czasowa i format daty dla użytkowników, którzy żadnych nie wybrali
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wartości domyślne
+
+**Wartości domyślne** określają, jak aplikacja wygląda dla użytkownika, który nie dokonał własnego wyboru w swoich
+[preferencjach](../profile/preferences.html); własny wybór użytkownika zawsze wygrywa:
+
+| Pole | Możliwości | Bez wyboru |
+|---|---|---|
+| **Domyślny motyw** | Zgodnie z przeglądarką, Jasny, Ciemny lub Kolor, z jednym z 12 kolorów dla Kolor | Zgodnie z przeglądarką (do wersji 7.2 Jasny) |
+| **Domyślny język** | Języki aplikacji, zapisany w [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | angielski |
+| **Domyślny widok formularzy** | Kafelki lub Lista, dla strony formularzy | Kafelki |
+| **Domyślna strefa czasowa** | UTC, przeglądarka każdego użytkownika lub dowolna strefa według nazwy | UTC |
+| **Domyślny format daty** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` lub `DD.MM.YYYY`, pokazany z dzisiejszą datą | `YYYY-MM-DD` |
+
+Język jest zmienną środowiskową i działa bez restartu. Przy
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) ustawionym na `0` strona pokazuje go tylko do odczytu.
+
+Od wersji 7.3.0 strona ma te same dwie karty co preferencje profilu, **Wygląd** (motyw, język i widok formularzy) oraz **Data i
+godzina** (strefa czasowa i format daty, z podglądem bieżącej godziny), a jej pole wyszukiwania wyświetla trafienia pod nazwą każdej karty.
+
+---
+
+## Zgodnie z przeglądarką
+
+Od wersji 7.3.0 **Zgodnie z przeglądarką** pokazuje każdemu użytkownikowi jasny lub ciemny motyw, o który prosi jego przeglądarka, i zmienia się razem z nią.
+
+Jest to wartość domyślna, gdy nie wybrano domyślnego motywu, więc nowa instalacja podąża za przeglądarką. Najechanie na jeden z kolorów
+motywu **Kolor** pokazuje podgląd aplikacji w tym kolorze; poprzedni motyw wraca, gdy wskaźnik się oddali, a nic nie zostaje zapisane przed kliknięciem **Zapisz**.
diff --git a/i18n/pl/_configure/appearance/icon.md b/i18n/pl/_configure/appearance/icon.md
new file mode 100644
index 0000000..d7c6d96
--- /dev/null
+++ b/i18n/pl/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Ikona
+parent: Wygląd
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Ikona
+{: .no_toc }
+
+Własna ikona na karcie przeglądarki i w zakładkach
+{: .fs-6 .fw-300 }
+
+**Ikona** zastępuje ikonę AnsibleForms na karcie przeglądarki i w zakładkach:
+
+| Zasada | Wartość |
+|---|---|
+| Typy | PNG, ICO, SVG, WEBP, GIF i JPEG |
+| Największy plik | 256 KB |
+| Najlepszy efekt | Kwadratowy obraz o wymiarach co najmniej 64 × 64 px lub plik SVG |
+
+Wybierz plik w **Nowa ikona** i kliknij **Prześlij**; **Usuń własną ikonę** przywraca ikonę domyślną.
diff --git a/i18n/pl/_configure/appearance/labels.md b/i18n/pl/_configure/appearance/labels.md
new file mode 100644
index 0000000..e985fc9
--- /dev/null
+++ b/i18n/pl/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Etykiety
+parent: Wygląd
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Etykiety
+{: .no_toc }
+
+Etykiety obok logo, które mówią, która to instancja
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lista
+
+Od wersji 7.3.0 **Ustawienia > Wygląd > Etykiety** przechowuje kilka etykiet obok logo w nagłówku, np. PRODUCTION i EU:
+
+| Kolumna | Znaczenie |
+|---|---|
+| **Włączone** | Czy etykieta jest widoczna obok logo i na stronie logowania |
+| **Etykieta** | Jej tekst, pokazany jako kolorowa pigułka w nagłówku |
+
+Wiersze są w kolejności nagłówka. Kliknięcie wiersza albo **Edytuj** w menu wiersza otwiera stronę etykiety; menu wiersza ma też
+**Włącz** lub **Wyłącz**, zależnie od stanu, **Przenieś w górę** i **Przenieś w dół** do zmiany kolejności oraz **Usuń**.
+
+Nagłówek i strona logowania pokazują włączone etykiety w ich kolejności. Powyżej trzech szare **+N** zbiera pozostałe w swojej podpowiedzi,
+a telefon pokazuje pierwszą etykietę i **+N**. Zapisana etykieta pojawia się od razu w każdej otwartej przeglądarce.
+
+---
+
+## Dodawanie etykiety
+
+**Dodaj etykietę** otwiera okno z dwoma polami etykiety, oba wymagane:
+
+| Pole | Znaczenie |
+|---|---|
+| **Etykieta** | Tekst etykiety, np. PRODUCTION |
+| **Kolor** | Niebieski, zielony, bursztynowy, pomarańczowy, czerwony lub szary, jako okrągłe próbki; na początku czerwony |
+
+Podgląd pokazuje nagłówek ze wszystkimi włączonymi etykietami i nową, w miarę jak ją wpisujesz. Nowa etykieta jest włączona i trafia za
+pozostałe. Jej strona ma jedną kartę, **Szczegóły**, z tymi samymi polami, przełącznikiem **Włączone**, który zapisuje się od razu, i podglądem.
+
+---
+
+## Etykieta środowiska z wersji 7.2
+
+Do wersji 7.2 **Ustawienia > Wygląd > Środowisko** ustawiało jedną etykietę obok logo.
+
+Przy jednej etykiecie PRODUCTION EU i PRODUCTION US czyta się tak samo, jako PRODUCTION, gdy kilka instancji jest otwartych obok siebie. Od wersji 7.3.0
+aktualizacja robi z tej etykiety pierwszą pozycję listy, z jej tekstem, kolorem i informacją, czy była widoczna, a stary adres **Środowisko**
+otwiera listę.
+
+---
+
+## Etykiety w config seed
+
+Od wersji 7.3.0 [config seed](../seed/) deklaruje etykiety w sekcji `labels`, każdą z tekstem i opcjonalnie z kolorem:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` to jedno z `blue`, `green`, `amber`, `orange`, `red` lub `grey`, a `position` ustala kolejność, od najniższej. Etykieta zadeklarowana
+w seedzie jest na swojej stronie tylko do odczytu, jak każdy [obiekt zarządzany](../seed/managed-objects.html).
diff --git a/i18n/pl/_configure/appearance/links.md b/i18n/pl/_configure/appearance/links.md
new file mode 100644
index 0000000..9223db8
--- /dev/null
+++ b/i18n/pl/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Linki
+parent: Wygląd
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Linki
+{: .no_toc }
+
+Linki nagłówka, wbudowane i własne
+{: .fs-6 .fw-300 }
+
+**Linki** ustawiają linki nagłówka dla każdego zalogowanego użytkownika, w dwóch kartach.
+
+**Wbudowane** ma przełącznik **Projektant**, zapisany w [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) i stosowany
+bez restartu. Po wyłączeniu projektant znika dla wszystkich: jego link, strona i API.
+
+**Własne** przechowuje Twoje własne linki, np. do wiki, runbooka lub portalu wsparcia. **Dodaj link** dodaje wiersz z tymi polami:
+
+| Pole | Znaczenie |
+|---|---|
+| **Ikona** | Ikona przed etykietą, wybrana z listy |
+| **Etykieta** | Tekst linku |
+| **Adres** | Witryna (`https://…`) lub strona aplikacji (`/forms/all`) |
+| **Nowa karta** | Otwiera link w nowej karcie przeglądarki |
+
+Przyciski wiersza go przesuwają: **→** umieszcza link wewnątrz linku powyżej, który wtedy otwiera się w nagłówku jako menu,
+**←** wyjmuje go z powrotem do nagłówka, a strzałki w górę i w dół go przesuwają (menu razem z linkami w środku).
+Menu nie potrzebuje własnego adresu.
+
+Nagłówek mieści najwyżej 5 Twoich linków po wbudowanych i najwyżej 10 wewnątrz każdego menu.
diff --git a/i18n/pl/_configure/appearance/logo.md b/i18n/pl/_configure/appearance/logo.md
new file mode 100644
index 0000000..46ca820
--- /dev/null
+++ b/i18n/pl/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logo
+parent: Wygląd
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logo
+{: .no_toc }
+
+Własne logo w nagłówku
+{: .fs-6 .fw-300 }
+
+**Logo** zastępuje logo AnsibleForms w nagłówku własnym obrazem, widocznym w każdym motywie:
+
+| Zasada | Wartość |
+|---|---|
+| Typy | PNG, JPEG, WEBP, GIF i SVG |
+| Największy plik | 900 KB |
+| Rozmiar w nagłówku | Najwyżej 200 × 33 px, z zachowaniem proporcji |
+
+Wybierz plik w **Nowe logo**, aby zobaczyć podgląd, a potem kliknij **Prześlij**. **Bieżące logo** pokazuje używane logo i rozmiar,
+w jakim wyświetla je nagłówek. **Usuń własne logo** przywraca logo domyślne, które dopasowuje się do motywu.
diff --git a/i18n/pl/_configure/appearance/name.md b/i18n/pl/_configure/appearance/name.md
new file mode 100644
index 0000000..cd4b72c
--- /dev/null
+++ b/i18n/pl/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Nazwa
+parent: Wygląd
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Nazwa
+{: .no_toc }
+
+Nazwa aplikacji na karcie przeglądarki i na stronie logowania
+{: .fs-6 .fw-300 }
+
+**Nazwa** przechowuje **Nazwę aplikacji**, widoczną na karcie przeglądarki i na stronie logowania. Gdy jest pusta, karta przeglądarki pokazuje
+`AnsibleForms`, a strona logowania nie pokazuje żadnej nazwy.
diff --git a/i18n/pl/_configure/authentication/entra-id.md b/i18n/pl/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..d3dd4fb
--- /dev/null
+++ b/i18n/pl/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Uwierzytelnianie
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Logowanie jednokrotne przez Microsoft Entra ID (Azure AD), z rolami z grup Entra ID użytkownika
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jak to działa
+
+Gdy dostawca Entra ID jest włączony, strona logowania pokazuje przycisk Entra ID pod **Zaloguj się**. Logowanie przebiega wtedy tak:
+
+1. Przycisk wysyła przeglądarkę do `/api/v2/auth/entraid`, który przekierowuje ją do Microsoft.
+2. Użytkownik loguje się w Microsoft, a ten przekierowuje z powrotem na **Redirect URL** z kodem autoryzacji. Serwer
+   wymienia ten kod w Microsoft na token ID i token dostępu do Microsoft Graph.
+3. Serwer odczytuje grupy użytkownika z Microsoft Graph (`/v1.0/me/transitiveMemberOf`), więc liczą się też grupy zagnieżdżone.
+4. Grupy są filtrowane **Filtrem grup** po nazwie wyświetlanej, a każda zachowana grupa jest zapisywana dwukrotnie,
+   jako `azuread/<object id>` i jako `azuread/<display name>`.
+
+Nazwa użytkownika to claim `upn` tokenu, np. `jdoe@example.com`, albo claim `preferred_username`, gdy token
+nie ma `upn`; dla konta służbowego oba mają tę samą wartość.
+
+---
+
+## Zarejestruj aplikację
+
+AnsibleForms potrzebuje rejestracji aplikacji w centrum administracyjnym Entra, w **App registrations > New registration**:
+
+1. Nadaj jej nazwę, jako obsługiwane typy kont wybierz **Accounts in this organizational directory only** i dodaj
+   identyfikator URI przekierowania typu **Web**: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. W **Certificates & secrets** utwórz client secret i skopiuj jego wartość; jest pokazywana tylko raz.
+3. W **API permissions** dodaj **delegowane** uprawnienia Microsoft Graph `User.Read` i `GroupMember.Read.All`
+   i udziel dla nich zgody administratora.
+4. Na stronie **Overview** zanotuj **Application (client) ID** i **Directory (tenant) ID**.
+
+Identyfikator URI przekierowania to adres, pod którym użytkownicy otwierają AnsibleForms, z dopisanym `/api/v2/auth/entraid/callback`.
+Przy [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms` staje się on
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Musi dokładnie odpowiadać polu **Identyfikator URI przekierowania** w poświadczeniu
+dostawcy.
+
+Do wersji 7.2.0 ścieżka brzmiała `/api/v2/auth/azureadoauth2/callback`. Od 7.3.0 nadal działa, więc istniejąca rejestracja
+nie wymaga zmian; poświadczenie z pustym **Identyfikatorem URI przekierowania** używa nowej ścieżki, więc wtedy dodaj ją do rejestracji.
+
+AnsibleForms odczytuje grupy z Graph i nie używa claimu groups w tokenie, więc w rejestracji nie trzeba konfigurować
+żadnego claimu grup.
+
+---
+
+## Dodaj dostawcę
+
+Dodaj dostawcę w **Dostęp > SSO**: kreator pyta o pola w czterech krokach, z **Microsoft Entra ID** w kroku **Typ**:
+
+| Krok | Pole | Znaczenie |
+|---|---|---|
+| Szczegóły | Nazwa, Opis | Unikalna nazwa dostawcy i opcjonalny opis |
+| Typ | Dostawca | **Microsoft Entra ID**; ustawiany przy tworzeniu, potem się nie zmienia |
+| Poświadczenia | Poświadczenie | Poświadczenie **Microsoft Entra ID** z [Połączenia > Poświadczenia](../credentials.html), zobacz niżej |
+| Grupy | Filtr grup | Wyrażenie regularne; zachowywane są tylko grupy, których nazwa wyświetlana pasuje. Puste zachowuje wszystkie grupy |
+
+Poświadczenie przechowuje rejestrację aplikacji, więc tylko admin może je dodać lub zmienić:
+
+| Pole | Znaczenie |
+|---|---|
+| Tenant ID | Wymagane. Directory (tenant) ID, czyli GUID, albo jedna z domen dzierżawy. Zalogować się mogą tylko użytkownicy tej dzierżawy |
+| Client ID | Application (client) ID |
+| Client secret | Wartość client secret, przechowywana w postaci zaszyfrowanej lub odczytywana z [magazynu sekretów](../secret-stores/) |
+| Identyfikator URI przekierowania | Tak jak zarejestrowano, np. `https://af.example.com/api/v2/auth/entraid/callback`. Puste: adres URL aplikacji i ścieżka zwrotna |
+
+Poświadczenie z pustym tenant ID jest odrzucane przy zapisie. Wielodzierżawowe punkty końcowe `common`, `organizations`
+i `consumers` są odrzucane przy zapisie dostawcy, który wskazuje to poświadczenie, bo pozwoliłyby zalogować się użytkownikom dowolnej
+dzierżawy Microsoft. Przy logowaniu serwer sprawdza też, czy token pochodzi ze skonfigurowanej dzierżawy. Dostawca
+zapisany wcześniej bez tenant ID nikogo nie loguje: dopóki tenant ID nie zostanie uzupełniony, serwer zapisuje w dzienniku
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Do wersji 7.2.0 tenant, client ID, secret i redirect URL były polami dostawcy. Aktualizacja do 7.3.0 przenosi je do
+poświadczenia o nazwie `<provider>-sso`, zobacz [Adresy w poświadczeniach](../credentials/types.html#addresses-in-credentials).
+Wybierz poświadczenie dla każdego nowego dostawcy: serwer nadal akceptuje dostawcę z własnym client ID i secret sprzed
+7.3.0, który loguje nimi, dopóki nie zostanie wybrane poświadczenie.
+
+Naraz włączony jest jeden dostawca Entra ID, ten, przez którego loguje przycisk Entra ID. **Włącz** w menu wiersza innego dostawcy
+albo jego przełącznik **Włączony** wyłącza pozostałych tego typu; kolumna **Włączony** na liście pokazuje, który jest używany. Dostawca
+może też pomijać stronę logowania, zobacz [Przełączanie logowania jednokrotnego](./#switching-single-sign-on). Zapis działa od razu, bez restartu.
+
+---
+
+## Mapowanie na role
+
+W config.yaml grupa Entra ID to `entraid/<object id>` lub `entraid/<display name>`, a użytkownik to `entraid/<upn>`.
+Object id jest unikalny w dzierżawie, więc to bezpieczniejszy wybór; nazwa wyświetlana jest łatwiejsza do odczytania:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Do wersji 7.2.0 prefiks brzmiał `azuread/`. W roli od 7.3.0 nadal pasuje do tych samych członków i zostanie usunięty w 8.0;
+edytor ról zapisuje `entraid/`. Tylko role przyjmują `entraid/`: grupy użytkownika są zapisywane jako `azuread/<object id>` i
+`azuread/<display name>` i tak pokazują je strona profilu oraz extravar `ansibleforms_user`. **Filtr grup** taki jak `^AF-` zachowuje tylko grupy, których używają Twoje role; zobacz [Role](../config/roles.html). Od wersji 7.1.0
+token logowania nie zawiera już grup, więc jego rozmiar nie rośnie razem z nimi. Filtr nadal ma znaczenie dla
+użytkowników w wielu grupach: przy każdym logowaniu mniej grup jest dopasowywanych do ról, a
+[wpis w katalogu](../users-and-groups/directory.html) użytkownika pokazuje tylko grupy, które się liczą. Przed wersją 7.1.0
+użytkownik w stu lub więcej grupach potrzebuje go, żeby w ogóle zobaczyć formularze, zobacz
+[Puste formularze i zadania po logowaniu jednokrotnym](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Punkt końcowy Microsoft Graph
+
+Serwer domyślnie loguje użytkowników w `https://login.microsoftonline.com` i wywołuje Microsoft Graph pod `https://graph.microsoft.com`:
+
+| Zmienna | Co zmienia |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | Urząd logowania (authority), dla chmury krajowej, np. `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | Punkt końcowy Graph, z którego odczytywane są grupy, np. `https://graph.microsoft.us` |
+
+Obie przyjmują bazowy URI bez końcowego ukośnika i są nowe w wersji 7.3.0. `AZURE_AUTHORITY_URI` i `AZURE_GRAPH_URI` są nadal odczytywane,
+gdy tamte nie są ustawione, z ostrzeżeniem w dzienniku, i zostaną usunięte w 8.0. Serwer musi mieć dostęp do Graph: logowanie się nie udaje, gdy nie da się odczytać grup.
+
+---
+
+## Ograniczenia
+
+Użytkownicy Entra ID logują się przez Microsoft, więc kilka rzeczy działa inaczej niż w przypadku kont lokalnych i LDAP:
+
+- Nie mają hasła w AnsibleForms, więc nie mogą go tam zmienić; [token API](../profile/api-token.html) tworzy się z ich sesji.
+- Nazwy wyświetlane nie są w Entra ID unikalne: dwie grupy o tej samej nazwie mapują się na tę samą rolę. Wskaż grupę w roli
+  przez jej object id, `entraid/<object id>`, żeby pasowała tylko ta grupa.
diff --git a/i18n/pl/_configure/authentication/index.md b/i18n/pl/_configure/authentication/index.md
new file mode 100644
index 0000000..7d7d64c
--- /dev/null
+++ b/i18n/pl/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Uwierzytelnianie
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Uwierzytelnianie
+{: .no_toc }
+
+Wybierz, jak użytkownicy się logują i jak ich konto oraz grupy przekładają się na role
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Metody logowania
+
+AnsibleForms obsługuje cztery metody logowania, a kilka z nich może być aktywnych jednocześnie:
+
+| Metoda | Kiedy jej używać | Strona |
+|---|---|---|
+| Konta lokalne | Wbudowany admin, konta usługowe, małe zespoły albo awaryjne logowanie, gdy katalog nie działa. | [Konta lokalne](local.html) |
+| LDAP | Użytkownicy i grupy są w Active Directory, OpenLDAP lub innym katalogu LDAP. | [LDAP](ldap.html) |
+| Entra ID | Użytkownicy logują się kontem Microsoft 365 / Entra ID (logowanie jednokrotne). | [Entra ID](entra-id.html) |
+| OIDC | Logowanie jednokrotne przez innego dostawcę OpenID Connect, np. Keycloak. | [OIDC](oidc.html) |
+
+Konta lokalne i LDAP konfiguruje się w **Dostęp > Użytkownicy**, **Grupy** i **LDAP**; Entra ID i OIDC w
+**Dostęp > SSO**.
+
+---
+
+## Jak logowanie wybiera metodę
+
+Strona logowania ma formularz z nazwą użytkownika i hasłem oraz po jednym przycisku dla każdego włączonego dostawcy logowania jednokrotnego:
+
+- **Nazwa użytkownika i hasło** są najpierw sprawdzane wśród użytkowników lokalnych. Dopiero gdy żaden lokalny użytkownik nie ma tej nazwy, a LDAP
+  jest włączony, sprawdzany jest katalog. Lokalny użytkownik z błędnym hasłem zostaje odrzucony bez pytania LDAP.
+- **Przyciski Entra ID i OpenID** pojawiają się pod **Zaloguj się**, gdy taki dostawca jest włączony. Przekierowują przeglądarkę do
+  dostawcy i z powrotem; żadne hasło nie trafia do AnsibleForms.
+
+Naraz może być włączony tylko jeden dostawca Entra ID i jeden dostawca OIDC: włączenie jednego wyłącza pozostałych tego samego typu.
+Nieudane logowanie nazwą użytkownika i hasłem zawsze pokazuje ten sam ogólny komunikat; przyczyna jest w dzienniku serwera i w dzienniku audytu.
+
+---
+
+## Przełączanie logowania jednokrotnego
+
+Od wersji 7.3.0 każdy dostawca w **Dostęp > SSO** ma dwa własne przełączniki, które działają bez restartu:
+
+| Przełącznik | Efekt |
+|---|---|
+| **Włączony** | Pokazuje przycisk dostawcy na stronie logowania i przyjmuje jego logowanie. Włączenie go wyłącza pozostałych dostawców tego typu. |
+| **Pomiń stronę logowania** | Użytkownicy trafiają prosto do tego dostawcy, bez strony logowania, dopóki dostawca jest włączony. Włączenie tej opcji u jednego dostawcy wyłącza ją u pozostałych; u wyłączonego dostawcy jest wyszarzona. |
+
+Formularz z nazwą użytkownika i hasłem pozostaje dostępny pod `/login?local`, dla lokalnego admina lub gdy dostawca zawiedzie,
+i jest pokazywany po wylogowaniu oraz gdy logowanie jednokrotne wraca z błędem.
+
+Zmienne `ENABLE_SSO` i `SSO_AUTO_LOGIN` zostały usunięte w wersji 7.3.0. Pierwsze uruchomienie 7.3.0 odczytuje je jeden raz i
+przy każdym starcie zapisuje ostrzeżenie w dzienniku, dopóki są ustawione, więc po aktualizacji usuń je ze środowiska:
+
+| Zmienna przed 7.3.0 | Co robi aktualizacja |
+|---|---|
+| `ENABLE_SSO=0` | Wyłącza wszystkich dostawców: pozostają skonfigurowani, ale bez przycisku na stronie logowania |
+| `SSO_AUTO_LOGIN=1` | Włącza **Pomiń stronę logowania** dla włączonego dostawcy, gdy włączony jest dokładnie jeden, a `ENABLE_SSO` nie jest `0` |
+
+---
+
+## Od użytkownika do ról
+
+Każde logowanie daje użytkownika z **typem** (`local`, `ldap`, `azuread` lub `oidc`), nazwą użytkownika i listą grup.
+Każda grupa dostaje prefiks swojego typu, więc grupa Entra ID jest zapisywana i wyświetlana jako `azuread/...`:
+
+| Metoda logowania | Nazwa użytkownika | Grupy |
+|---|---|---|
+| Lokalna | lokalna nazwa użytkownika | `local/<group>`, po jednej dla każdej lokalnej grupy użytkownika |
+| LDAP, katalog `main` | wartość atrybutu nazwy użytkownika (Username Attribute) | `ldap/<cn>`, CN każdej grupy zwróconej przez katalog |
+| LDAP, inny katalog | `<directory>/<username>` | `ldap/<directory>/<cn>`, zobacz [Kilka katalogów](ldap.html#several-directories) |
+| Entra ID | claim `upn` albo `preferred_username`, gdy token nie ma `upn` | `azuread/<object id>` i `azuread/<display name>` każdej grupy, odczytane z Microsoft Graph |
+| OIDC | claim `preferred_username` | `oidc/<name>`, z claimu `groups` tokenu ID |
+
+[Role](../config/roles.html) w config.yaml dopasowują następnie te wartości: rola obowiązuje, gdy jedna z jej `groups` jest jedną
+z grup użytkownika albo gdy jej `users` zawiera `<type>/<username>`. Każdy użytkownik dostaje też rolę `default`. Od wersji 7.3.0
+rola nazywa członka Entra ID `entraid/<group>` lub `entraid/<upn>`, co pasuje do zapisanej wartości `azuread/`; `azuread/`
+w roli nadal działa i zostanie usunięte w 8.0. Profil i extravars zadania nadal pokazują `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+Strona **profilu** użytkownika pokazuje typ logowania, grupy i role, co jest najszybszym sposobem sprawdzenia mapowania.
+Opcja roli `allowLogin` może odmówić logowania użytkownikom, którzy nie pasują do żadnej roli: ustaw ją na `false` w `default` i na
+`true` w rolach, które mogą się logować.
diff --git a/i18n/pl/_configure/authentication/ldap.md b/i18n/pl/_configure/authentication/ldap.md
new file mode 100644
index 0000000..c205d09
--- /dev/null
+++ b/i18n/pl/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Uwierzytelnianie
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Pozwól użytkownikom katalogu logować się własnym hasłem i nadawaj im role przez ich grupy w katalogu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jak to działa
+
+AnsibleForms łączy się z katalogiem kontem bind, wyszukuje użytkownika, a następnie wykonuje bind jako ten użytkownik, żeby sprawdzić
+hasło:
+
+1. Użytkownik loguje się nazwą użytkownika i hasłem. Gdy żaden użytkownik **lokalny** nie ma tej nazwy, sprawdzany jest LDAP.
+2. AnsibleForms wykonuje bind kontem bind z poświadczenia katalogu i szuka w **Bazie wyszukiwania** wpisu, którego
+   **Atrybut nazwy użytkownika** jest równy nazwie użytkownika.
+3. Wykonuje bind jako znaleziony wpis, z wpisanym hasłem.
+4. Grupy są odczytywane z wpisu (lub z wyszukiwania grup), filtrowane i poprzedzane prefiksem `ldap/`.
+
+Nazwa użytkownika w formie UPN (`jdoe@example.com`), która nie znajduje użytkownika, jest ponawiana raz z częścią przed `@`, więc użytkownicy
+mogą logować się w obu formach, nawet gdy Atrybut nazwy użytkownika zawiera krótką nazwę. Błędne hasło nigdy nie jest ponawiane.
+
+Jeden zestaw ustawień obsługuje Active Directory, OpenLDAP i inne; od wersji 7.3.0 może być [kilka katalogów](#several-directories).
+
+---
+
+## Ustawienia
+
+Od wersji 7.3.0 ustawienia są osobne dla każdego katalogu. **Dostęp > LDAP** wyświetla katalogi w kolejności, w jakiej wyszukiwana jest sama nazwa użytkownika:
+
+![Dostęp > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menu wiersza | Co robi |
+|---|---|
+| Edytuj | Otwiera stronę katalogu |
+| Testuj połączenie | Próbuje zalogować się testową nazwą użytkownika i hasłem, zobacz [Testowanie połączenia](#testing-the-connection) |
+| Włącz, Wyłącz | Włącza lub wyłącza katalog; `main` jest wyłączany zamiast usuwania |
+| Przenieś w górę, Przenieś w dół | Zmienia jego miejsce w kolejności wyszukiwania |
+| Usuń | Usuwa katalog; w `main` widoczne, ale nieaktywne |
+
+Dodawanie katalogu pyta o pola w czterech krokach, którymi są karty jego strony. **Szczegóły** zawierają **Włączony**, **Nazwę** i **Opis**:
+
+| Karta | Ustawienie | Znaczenie |
+|---|---|---|
+| Poświadczenia | Poświadczenie | Wymagane. Poświadczenie `ldap` z [Połączenia > Poświadczenia](../credentials.html), które przechowuje połączenie, zobacz niżej |
+| Użytkownicy | Baza wyszukiwania | DN, od którego zaczyna się wyszukiwanie użytkownika, np. `OU=Users,DC=example,DC=com`. Przeszukiwane są też poddrzewa |
+| Użytkownicy | Atrybut nazwy użytkownika | Atrybut porównywany z nazwą logowania: `sAMAccountName` w AD (domyślnie), `uid` w OpenLDAP |
+| Użytkownicy | Atrybut poczty | Atrybut z adresem e-mail, zwykle `mail` |
+| Użytkownicy | Domeny logowania | Domeny, których logowania `user@domain` trafiają prosto do tego katalogu, zobacz [Kilka katalogów](#several-directories) |
+| Grupy | Atrybut grup | Atrybut wpisu użytkownika, który zawiera grupy (`memberOf`, domyślnie), lub `groups` przy wyszukiwaniu grup |
+| Grupy | Baza wyszukiwania grup | DN, od którego zaczyna się wyszukiwanie grup |
+| Grupy | Klasa grupy | objectClass grup, np. `group`, `groupOfNames` lub `posixGroup` |
+| Grupy | Atrybut członka grupy | Atrybut grupy z listą jej członków, np. `member`, `uniqueMember` lub `memberUid`; domyślnie `member` |
+| Grupy | Atrybut użytkownika członka grupy | Atrybut użytkownika, który zawierają te wartości członków, np. `dn` lub `uid`; domyślnie `dn` |
+| Grupy | Filtr grup | Wyrażenie regularne; zachowywane są tylko grupy o pasującej nazwie. Puste zachowuje wszystkie grupy |
+
+Wartości domyślne trzech ostatnich pól grup obowiązują tylko przy wyszukiwaniu grup, zobacz następną sekcję.
+
+Poświadczenie `ldap` określa, jak dotrzeć do katalogu i jako kto go przeszukiwać:
+
+| Pole | Znaczenie |
+|---|---|
+| Serwery | Jeden na pole, jako `host`, `host:port` lub `ldaps://host:port`, próbowane w tej kolejności: gdy jeden nie odpowiada, próbowany jest następny |
+| Port | `389` dla zwykłego LDAP, `636` dla LDAPS |
+| Włącz TLS | Łączy przez LDAPS (`ldaps://`). StartTLS na porcie 389 nie jest obsługiwany |
+| Ignoruj certyfikaty | Pomija weryfikację certyfikatu serwera. Widoczne tylko przy **Włącz TLS** |
+| Certyfikat | Certyfikat klienta, który AnsibleForms przedstawia serwerom, w PEM, gdy certyfikaty są sprawdzane |
+| Pakiet CA | Certyfikat(y) CA, które podpisały certyfikat serwera, w PEM, gdy certyfikaty są sprawdzane |
+| DN użytkownika bind | DN konta usługi, które przeszukuje katalog |
+| Hasło użytkownika bind | Jego hasło, przechowywane w postaci zaszyfrowanej lub odczytywane z [magazynu sekretów](../secret-stores/) |
+
+Tylko admin może dodać lub zmienić poświadczenie `ldap`, zobacz [Kto może zmienić poświadczenie](../credentials.html#who-may-change-a-credential).
+Do wersji 7.2.0 serwery, TLS i konto bind były polami ustawień LDAP. Aktualizacja do 7.3.0 przenosi je do poświadczenia,
+zobacz [Adresy w poświadczeniach](../credentials/types.html#addresses-in-credentials):
+
+| Katalog przed aktualizacją | Dokąd trafiają jego serwery |
+|---|---|
+| Własny bind DN i hasło, bez poświadczenia | Nowe poświadczenie `ldap` o nazwie `<directory>-ldap`, np. `main-ldap` |
+| Poświadczenie bez serwerów | Do tego poświadczenia |
+| Poświadczenie, które ma już inne serwery | Kopia poświadczenia o nazwie `<credential>-<directory>`, którą katalog potem wskazuje |
+
+Zajęta nazwa dostaje `-2`, `-3` i tak dalej. Katalog z config seed zostaje bez zmian: należy do seeda.
+
+---
+
+## Grupy
+
+Grupy pochodzą z jednego z dwóch miejsc, a **Atrybut grup** decyduje, z którego:
+
+- **Atrybut wpisu użytkownika**, zwykle `memberOf`. To typowa konfiguracja dla Active Directory i dla
+  OpenLDAP z nakładką `memberof`.
+- **Wyszukiwanie grup**, dla katalogów bez `memberOf`. Uruchamia się tylko wtedy, gdy ustawione są zarówno **Baza wyszukiwania grup**, jak i **Klasa grupy**:
+  AnsibleForms szuka wtedy grup tej klasy, których **Atrybut członka grupy** zawiera **Atrybut użytkownika członka grupy**
+  danego użytkownika, i zapisuje wynik w atrybucie `groups`. Ustaw **Atrybut grup** na `groups`,
+  żeby go użyć.
+
+{: .note }
+> Przy **Atrybucie grup** `memberOf` skonfigurowane wyszukiwanie grup się uruchamia, ale jego wynik nie jest używany dla ról.
+
+Każda grupa jest DN, a AnsibleForms zachowuje jej pierwszy CN: `CN=AF-Admins,OU=Groups,DC=example,DC=com` staje się `AF-Admins`.
+Następnie do tej nazwy stosowany jest **Filtr grup**, a pozostałe grupy dostają prefiks `ldap/`: `ldap/AF-Admins`.
+
+W dużych katalogach filtr utrzymuje małe tokeny i zadania; nieprawidłowe wyrażenie regularne zachowuje wszystkie grupy i trafia do dziennika.
+
+---
+
+## Mapowanie na role
+
+W config.yaml grupa LDAP to `ldap/<group CN>`, a użytkownik LDAP to `ldap/<username>`, w obu przypadkach z rozróżnianiem wielkości liter:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+Nazwa użytkownika to wartość **Atrybutu nazwy użytkownika** w postaci zwróconej przez katalog, a nie wpisanej przez użytkownika.
+Opcje ról opisuje strona [Role](../config/roles.html).
+
+---
+
+## Kilka katalogów
+
+Od wersji 7.3.0 może być kilka katalogów, każdy z własnymi serwerami, użytkownikami i grupami. Ich nazwy rozróżniają członków:
+
+| Katalog | Nazwa użytkownika | Grupy | W roli |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Każdy inny, np. `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Użytkownik wskazuje katalog przy logowaniu jako `corp\jdoe` lub `corp/jdoe` albo loguje się adresem w domenie, która należy
+do katalogu. Sama nazwa użytkownika jest sprawdzana w każdym włączonym katalogu, w ich kolejności, tak samo jak nazwa w rodzaju `other\jdoe`, gdy żaden
+katalog nie nazywa się `other`: jest wtedy wyszukiwana dokładnie tak, jak ją wpisano.
+
+Decyduje pierwszy katalog, który zna użytkownika: błędne hasło w nim jest ostateczną odpowiedzią, a następny katalog nie jest
+sprawdzany, bo mógłby zawierać kogoś innego o tej samej nazwie. Katalog, z którym nie można się połączyć, jest pomijany.
+
+Katalog o nazwie `default` do wersji 7.2.0 od 7.3.0 nazywa się `main`: aktualizacja zmienia mu nazwę, a nowa instalacja zaczyna
+od `main`. Jego członkowie zachowują krótkie nazwy, więc role, które ich wskazują, nie wymagają zmian. Nazwy katalogu `main` nie można
+zmienić, a nazwa katalogu zawiera tylko litery, cyfry, `-` i `_`.
+
+---
+
+## Testowanie połączenia
+
+**Testuj połączenie** prosi o testową nazwę użytkownika i hasło i próbuje zalogować się z ustawieniami widocznymi na ekranie, zapisanymi lub nie.
+Po sukcesie pokazuje wpis użytkownika w katalogu, z którego odczytasz dokładne nazwy atrybutów i DN grup do użycia.
+
+Testowy użytkownik, który nie istnieje, i tak zgłasza sukces: połączenie i konto bind działają, tylko użytkownik nie
+został znaleziony. Typowe błędy:
+
+| Komunikat | Przyczyna |
+|---|---|
+| `Bad server or port (connection failed)` | Nazwa hosta nie jest rozwiązywana lub port jest nieosiągalny. |
+| `Wrong binding credentials` | Bind DN lub hasło w poświadczeniu katalogu są błędne. |
+| `Unable to verify the certificate` | Certyfikat serwera nie jest podpisany przez pakiet CA z poświadczenia. |
+| `Certificate is not valid` | Certyfikat lub pakiet CA w poświadczeniu nie zawiera prawidłowego certyfikatu PEM. |
+
+---
+
+## Przykład Active Directory
+
+Ten przykład łączy się z dwoma kontrolerami domeny przez LDAPS i zachowuje tylko grupy, których nazwa zaczyna się od `AF-`:
+
+| Ustawienie | Wartość |
+|---|---|
+| Poświadczenie > Serwery | `dc01.example.com`, potem `dc02.example.com` |
+| Poświadczenie > Port | `636` |
+| Poświadczenie > Włącz TLS | włączone |
+| Poświadczenie > Ignoruj certyfikaty | wyłączone, z certyfikatem klienta i łańcuchem CA firmowego urzędu certyfikacji |
+| Poświadczenie > DN użytkownika bind | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Baza wyszukiwania | `OU=Users,DC=example,DC=com` |
+| Atrybut poczty | `mail` |
+| Atrybut nazwy użytkownika | `sAMAccountName` |
+| Atrybut grup | `memberOf` |
+| Filtr grup | `^AF-` |
+
+Członkowie `CN=AF-Operators,…` pasują do ról z `ldap/AF-Operators` i logują się jako `jdoe` lub `jdoe@example.com`.
+
+---
+
+## Przykład OpenLDAP
+
+Ten przykład używa wyszukiwania grup na wpisach `groupOfNames`, więc działa bez nakładki `memberof`:
+
+| Ustawienie | Wartość |
+|---|---|
+| Poświadczenie > Serwery | `ldap.example.com` |
+| Poświadczenie > Port | `636` |
+| Poświadczenie > Włącz TLS | włączone |
+| Poświadczenie > DN użytkownika bind | `cn=readonly,dc=example,dc=com` |
+| Baza wyszukiwania | `ou=people,dc=example,dc=com` |
+| Atrybut poczty | `mail` |
+| Atrybut nazwy użytkownika | `uid` |
+| Atrybut grup | `groups` |
+| Baza wyszukiwania grup | `ou=groups,dc=example,dc=com` |
+| Klasa grupy | `groupOfNames` |
+| Atrybut członka grupy | `member` |
+| Atrybut użytkownika członka grupy | `dn` |
+
+Użytkownik wymieniony w `cn=af-admins,ou=groups,dc=example,dc=com` dostaje grupę `ldap/af-admins`. Dla grup `posixGroup`
+użyj **Atrybutu członka grupy** `memberUid` i **Atrybutu użytkownika członka grupy** `uid`.
+
+Z nakładką `memberof` zostaw pola wyszukiwania grup puste i ustaw **Atrybut grup** na `memberOf`.
+
+---
+
+## Typowe pułapki
+
+Większość problemów z LDAP sprowadza się do jednego z tych:
+
+- **Lokalny użytkownik o tej samej nazwie.** Użytkownicy lokalni są sprawdzani najpierw, więc katalog nigdy nie jest pytany o tę nazwę.
+- **Brak grup lub niewłaściwe grupy.** Atrybut grup musi istnieć (`groups` przy wyszukiwaniu grup); `memberOf` pomija zagnieżdżenia.
+- **Nazwy grup, które nie pasują.** Używaj `ldap/<CN>` z tą samą wielkością liter i sprawdź, czy Filtr grup zachowuje grupę.
+- **DN grup, które nie zaczynają się od CN.** Jako nazwa grupy używana jest tylko pierwsza wartość `CN=`, więc każdy DN grupy
+  musi zaczynać się od `CN=` (lub `cn=`).
+- **Certyfikaty.** TLS wymaga obu pól certyfikatów w poświadczeniu i pasującej nazwy serwera; Ignoruj certyfikaty służy tylko do testów.
+- **Ustawienia, których nie da się zapisać.** Gdy katalog pochodzi z [config seed](../seed/managed-objects.html), jego strona
+  jest tylko do odczytu: zmień zamiast tego plik seed.
+
+Nieudane logowanie pokazuje ogólny komunikat. Przyczynę zapisuje serwer w dzienniku i dziennik audytu, a w przypadku Active
+Directory jest ona tłumaczona z kodu katalogu, np. `Wrong password`, `Account locked` lub `Password expired`.
diff --git a/i18n/pl/_configure/authentication/local.md b/i18n/pl/_configure/authentication/local.md
new file mode 100644
index 0000000..564f45d
--- /dev/null
+++ b/i18n/pl/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Konta lokalne
+parent: Uwierzytelnianie
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Konta lokalne
+{: .no_toc }
+
+Wbudowany admin oraz użytkownicy i grupy przechowywani w bazie danych AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wbudowany admin
+
+Każde uruchomienie tworzy lokalną grupę `admins` i użytkownika admin, jeśli ich brakuje; admina kontrolują trzy zmienne:
+
+| Zmienna | Domyślnie | Znaczenie |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Nazwa użytkownika admina, tworzonego w grupie `admins`, gdy żaden użytkownik nie ma tej nazwy. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Hasło nadawane adminowi przy tworzeniu (lub resetowaniu). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` resetuje hasło admina do `ADMIN_PASSWORD` i przywraca go do `admins`. |
+
+`ADMIN_PASSWORD` jest używane tylko przy tworzeniu lub resetowaniu użytkownika: późniejsza zmiana sama w sobie nic nie robi.
+
+Lokalny użytkownik, który loguje się publicznym hasłem domyślnym `AnsibleForms!123`, może tylko je zmienić. Przeglądarka otwiera
+stronę zmiany hasła, której nie da się zamknąć, a serwer odpowiada na każde inne żądanie kodem `403` (kod
+`password_change_required`), dopóki hasło nie zostanie zmienione. Nowe hasło musi różnić się od domyślnego; po
+zmianie użytkownik loguje się ponownie nowym hasłem. Ustaw `ADMIN_PASSWORD` na własną wartość przed pierwszym uruchomieniem, aby pominąć ten krok.
+
+Zmiana `ADMIN_USERNAME` po pierwszym uruchomieniu tworzy drugiego użytkownika admin o tej nazwie; stary zostaje.
+
+{: .warning }
+> `REINIT_ADMIN=1` resetuje hasło przy **każdym** uruchomieniu, dopóki jest ustawione. Użyj go, aby odzyskać utracone hasło admina,
+> a potem je usuń i uruchom ponownie.
+
+---
+
+## Użytkownicy i grupy
+
+Lokalnymi użytkownikami i grupami zarządza się w **Dostęp > Użytkownicy** i **Dostęp > Grupy**. Użytkownik ma te pola:
+
+| Pole | Znaczenie |
+|---|---|
+| Nazwa użytkownika | Nazwa logowania. Musi być unikalna. |
+| Opis | Opcjonalny. |
+| Hasło | Przechowywane jako skrót. Zmienisz je później akcją **Zmień hasło**. |
+| E-mail | Opcjonalny. |
+| Grupa | Pierwsza lokalna grupa użytkownika. Kolejne dodasz na karcie **Grupy** na stronie użytkownika. |
+
+Użytkownicy lokalni zmieniają własne hasło w swoim profilu; pozostali użytkownicy robią to w swoim katalogu lub u dostawcy tożsamości.
+
+Użytkownik może należeć do kilku grup i dostaje role ich wszystkich. Karta **Grupy** na stronie użytkownika dodaje i
+usuwa grupy, tak samo jak karta **Użytkownicy** na stronie grupy. Użytkownik zachowuje co najmniej jedną grupę: ostatniej nie można
+usunąć.
+
+Grupy, która nadal ma użytkowników, nie można usunąć: najpierw usuń z niej użytkowników. Grupy `admins` nigdy nie można usunąć ani
+zmienić jej nazwy, a użytkownika `admin` nigdy nie można usunąć.
+
+---
+
+## Zezwalanie na logowanie
+
+Karta **Szczegóły** na stronie użytkownika ma przełącznik **Zezwól na logowanie**, dostępny też jako **Zablokuj logowanie** i **Zezwól
+na logowanie** w menu wiersza na liście użytkowników. Istnieje zarówno dla użytkowników lokalnych, jak i dla użytkowników LDAP i SSO:
+
+- **Włączony**: użytkownik loguje się normalnie.
+- **Wyłączony**: sesje użytkownika kończą się natychmiast, a każde logowanie jest odrzucane, dopóki admin go znowu nie włączy. Strona
+  najpierw prosi o potwierdzenie.
+
+Przełącznika nie można wyłączyć dla użytkownika `admin`, który jest drogą powrotną, ani nie może go wyłączyć admin dla własnego konta. Strona
+użytkownika LDAP lub SSO ma też **Zakończ sesje**, co wylogowuje użytkownika wszędzie, bez blokowania go.
+
+---
+
+## Mapowanie na role
+
+Role wskazują grupy lokalne jako `local/<group>`, a użytkowników jako `local/<user>`; domyślnie `admins` dostaje `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Zachowaj `local/admins` w roli `admin`, żeby wbudowany admin zawsze mógł się zalogować, nawet gdy katalog lub
+dostawca tożsamości jest niedostępny. Gdy config.yaml w ogóle nie da się wczytać, członkowie `local/admins` nadal dostają rolę
+`admin`, więc możesz się zalogować i to naprawić. Opcje ról opisuje strona [Role](../config/roles.html).
+
+---
+
+## Konta lokalne i LDAP
+
+Logowanie nazwą użytkownika i hasłem sprawdza użytkowników lokalnych przed LDAP. Gdy lokalny użytkownik ma tę samą nazwę co użytkownik
+katalogu, konto lokalne zawsze wygrywa, a hasło z katalogu nie działa dla tej nazwy. Nadawaj kontom lokalnym nazwy,
+które nie mogą kolidować z kontami katalogu, np. z prefiksem `svc-`.
diff --git a/i18n/pl/_configure/authentication/oidc.md b/i18n/pl/_configure/authentication/oidc.md
new file mode 100644
index 0000000..5db9f47
--- /dev/null
+++ b/i18n/pl/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Uwierzytelnianie
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Logowanie jednokrotne przez dostawcę OpenID Connect, np. Keycloak, z rolami z claimu grup
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jak to działa
+
+Gdy dostawca OIDC jest włączony, strona logowania pokazuje przycisk OpenID pod **Zaloguj się**. Logowanie przebiega wtedy tak:
+
+1. Przycisk wysyła przeglądarkę do `/api/v2/auth/oidc`, który przekierowuje ją do dostawcy (przepływ kodu autoryzacji
+   z PKCE).
+2. Użytkownik loguje się u dostawcy, a ten przekierowuje z powrotem na **Redirect URL**.
+3. Serwer wymienia kod na tokeny i odczytuje claimy tokenu ID.
+4. Nazwa użytkownika to claim `preferred_username`, a każda wartość claimu `groups`, która przejdzie przez
+   **Filtr grup**, staje się grupą `oidc/<value>`.
+
+AnsibleForms żąda zakresów `openid profile email`; zakresów nie można konfigurować. Wylogowanie z AnsibleForms
+wysyła też przeglądarkę do punktu końcowego zakończenia sesji u dostawcy, jeśli dostawca go publikuje.
+
+{: .note }
+> OIDC zostało przetestowane z Keycloak. Inni dostawcy działają, jeśli spełniają poniższe wymagania.
+
+---
+
+## Wymagania wobec dostawcy
+
+Dostawca musi oferować OpenID Connect discovery i klienta poufnego dla AnsibleForms:
+
+- **Discovery**: AnsibleForms odczytuje `<issuer>/.well-known/openid-configuration`, więc wystawca musi być osiągalny z
+  serwera AnsibleForms, przez HTTPS.
+- **Klient poufny** z przepływem kodu autoryzacji, client ID i client secret.
+- **Identyfikator URI przekierowania** `https://af.example.com/api/v2/auth/oidc/callback`, czyli adres, pod którym użytkownicy otwierają
+  AnsibleForms, z dopisanym `/api/v2/auth/oidc/callback`. Przy [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms` staje się on `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Claim `groups` w tokenie ID**, zawierający listę nazw grup. Bez niego użytkownik nie dostaje żadnych grup OIDC.
+- **Claim `preferred_username`**, który staje się nazwą użytkownika.
+
+---
+
+## Przykład Keycloak
+
+Ten przykład używa realmu `example` na `https://keycloak.example.com`; wystawca to wtedy
+`https://keycloak.example.com/realms/example`. W tym realmie:
+
+1. W **Clients** utwórz klienta OpenID Connect z client ID `ansibleforms`. Włącz **Client authentication**,
+   zostaw **Standard flow** i ustaw **Valid redirect URIs** na `https://af.example.com/api/v2/auth/oidc/callback`.
+2. Na karcie **Credentials** klienta skopiuj **Client secret**.
+3. Na karcie **Client scopes** otwórz `ansibleforms-dedicated` i dodaj mapper **By configuration > Group Membership**,
+   z **Token Claim Name** `groups`, wyłączonym **Full group path** i włączonym **Add to ID token**.
+
+Przy włączonym **Full group path** claim zawiera ścieżki takie jak `/af-admins`, a rola musi wtedy używać `oidc//af-admins`.
+
+---
+
+## Dodaj dostawcę
+
+Dodaj dostawcę w **Dostęp > SSO**: kreator pyta o pola w czterech krokach, z **Open ID** w kroku **Typ**:
+
+| Krok | Pole | Znaczenie |
+|---|---|---|
+| Szczegóły | Nazwa, Opis | Unikalna nazwa dostawcy i opcjonalny opis |
+| Typ | Dostawca | **Open ID**; ustawiany przy tworzeniu, potem się nie zmienia |
+| Poświadczenia | Poświadczenie | Poświadczenie **Open ID** z [Połączenia > Poświadczenia](../credentials.html), zobacz niżej |
+| Grupy | Filtr grup | Wyrażenie regularne; zachowywane są tylko pasujące wartości claimu `groups`. Puste zachowuje wszystkie grupy |
+
+Poświadczenie przechowuje klienta, więc tylko admin może je dodać lub zmienić:
+
+| Pole | Znaczenie |
+|---|---|
+| Wystawca | Wymagane. Adres URL wystawcy, np. `https://keycloak.example.com/realms/example` |
+| Client ID | Client ID u dostawcy, np. `ansibleforms` |
+| Client secret | Client secret, przechowywany w postaci zaszyfrowanej lub odczytywany z [magazynu sekretów](../secret-stores/) |
+| Identyfikator URI przekierowania | Tak jak zarejestrowano, np. `https://af.example.com/api/v2/auth/oidc/callback`. Puste: adres URL aplikacji i ścieżka zwrotna |
+
+Do wersji 7.2.0 wystawca, client ID, secret i redirect URL były polami dostawcy. Aktualizacja do 7.3.0 przenosi je do
+poświadczenia o nazwie `<provider>-sso`, zobacz [Adresy w poświadczeniach](../credentials/types.html#addresses-in-credentials).
+Wybierz poświadczenie dla każdego nowego dostawcy: serwer nadal akceptuje dostawcę z własnym client ID i secret sprzed
+7.3.0, który loguje nimi, dopóki nie zostanie wybrane poświadczenie.
+
+Naraz włączony jest jeden dostawca OIDC, ten, przez którego loguje przycisk OpenID. **Włącz** w menu wiersza innego dostawcy
+albo jego przełącznik **Włączony** wyłącza pozostałych tego typu; kolumna **Włączony** na liście pokazuje, który jest używany.
+Dostawca może też pomijać stronę logowania, zobacz [Przełączanie logowania jednokrotnego](./#switching-single-sign-on).
+
+Zapisanie dostawcy stosuje go natychmiast. Gdy wystawca jest nieosiągalny, serwer zapisuje w dzienniku
+`Failed to initialize OIDC strategy`, a logowania OIDC się nie udają, dopóki dostawca nie zostanie ponownie zapisany lub serwer nie zostanie uruchomiony ponownie.
+
+---
+
+## Mapowanie na role
+
+W config.yaml grupa OIDC to `oidc/<group>`, a użytkownik to `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+Wartości są dopasowywane dokładnie, z uwzględnieniem wielkości liter. Opcje ról opisuje strona [Role](../config/roles.html).
+
+---
+
+## Ograniczenia
+
+Użytkownicy OIDC logują się u dostawcy, więc kilka rzeczy działa inaczej niż w przypadku kont lokalnych i LDAP:
+
+- Nie mają hasła w AnsibleForms, więc nie mogą go tam zmienić; od wersji 7.2.0 [token API](../profile/api-token.html)
+  tworzy się z ich sesji.
+- Utrzymuj krótki claim `groups`: wysyłaj tylko grupy istotne dla AnsibleForms, np. przez dedykowany
+  client scope lub strukturę grup u dostawcy, albo filtruj je **Filtrem grup**. Od wersji 7.1.0 token logowania
+  AnsibleForms nie zawiera już grup; wcześniej użytkownik w stu lub więcej grupach mógł nie widzieć żadnych formularzy, zobacz
+  [Puste formularze i zadania po logowaniu jednokrotnym](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/pl/_configure/config/categories.md b/i18n/pl/_configure/config/categories.md
new file mode 100644
index 0000000..fd8bbf5
--- /dev/null
+++ b/i18n/pl/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Kategorie
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Kategorie
+{: .no_toc }
+
+Grupuj formularze na pulpicie.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Atrybut categories
+
+Lista `categories` najwyższego poziomu w config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Obiekt Category
+
+Każdy wpis listy `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/pl/_configure/config/constants.md b/i18n/pl/_configure/config/constants.md
new file mode 100644
index 0000000..32c49ca
--- /dev/null
+++ b/i18n/pl/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Stałe
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Stałe
+{: .no_toc }
+
+Dowolne obiekty, których może używać każdy formularz.
+{: .fs-6 .fw-300 }
+
+---
+
+## Atrybut constants
+
+Obiekt `constants` najwyższego poziomu w config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/pl/_configure/config/index.md b/i18n/pl/_configure/config/index.md
new file mode 100644
index 0000000..d676393
--- /dev/null
+++ b/i18n/pl/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Kategorie, role i stałe dla wszystkich formularzy
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów: plik config.yaml, który przechowuje kategorie, role i stałe wspólne dla wszystkich formularzy.
+
+AnsibleForms używa pliku config.yaml do konfiguracji kategorii, ról i stałych. Jeśli nie podano żadnego pliku, generowany jest plik z minimalną konfiguracją. Konfigurację można też zaimportować do bazy danych, dzięki czemu plik config.yaml nie jest już potrzebny.
+
+---
+
+## Przegląd
+
+Plik config.yaml zawiera konfigurację kategorii, ról i stałych używanych przez AnsibleForms.
+
+**WIDEO**: [Utwórz swój pierwszy formularz](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+Poniższy minimalny config.yaml służy jako punkt wyjścia. Zawiera tylko wymaganą kategorię `Default` oraz wymagane role `admin` i `default`.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Priorytet wczytywania konfiguracji
+
+AnsibleForms wczytuje plik config.yaml w następującej kolejności (wygrywa pierwsze dopasowanie):
+
+1. **Z BAZY DANYCH** : konfiguracja zaimportowana do bazy danych, tylko gdy `ENABLE_CONFIG_IN_DATABASE=1` albo gdy ta
+   zmienna nie jest ustawiona, a źródło konfiguracji zapisane w bazie danych to `database` (pusta kopia przechodzi z powrotem na plik)
+2. **Z REPOZYTORIUM (use_for_config)** : repozytorium z włączonym przełącznikiem "Używać do konfiguracji?" (nowość w 6.1.0)
+3. **Z REPOZYTORIUM (use_for_forms)** : repozytorium z włączonym przełącznikiem "Używać do formularzy?" (rozwiązanie zapasowe dla zgodności wstecznej)
+4. **Z PLIKU LOKALNEGO** : lokalny plik `config.yaml` (zmienna środowiskowa CONFIG_PATH)
+
+{: .warning }
+> **Uwaga:** Włącz "Używać do konfiguracji?" tylko w jednym repozytorium. Jeśli ma go włączone kilka, w dzienniku pojawia się ostrzeżenie i używane jest pierwsze.
+
+---
+
+## W tej sekcji
+
+Plik ma trzy atrybuty najwyższego poziomu, a każdy ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Kategorie](categories.html) | Grupowanie formularzy na pulpicie w drzewo kategorii z ikonami |
+| [Role](roles.html) | Mapowanie użytkowników i grup na role oraz ustalanie, co każda rola może robić |
+| [Stałe](constants.html) | Dowolne obiekty, których może używać każdy formularz |
diff --git a/i18n/pl/_configure/config/roles.md b/i18n/pl/_configure/config/roles.md
new file mode 100644
index 0000000..164d7ec
--- /dev/null
+++ b/i18n/pl/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Role
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Role
+{: .no_toc }
+
+Mapuj użytkowników i grupy na role i ustalaj, co każda rola może robić.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Atrybut roles
+
+Lista `roles` najwyższego poziomu w config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## Rola default
+
+Każdy zalogowany użytkownik ma rolę `default`, więc formularz z `roles: [default]` jest dostępny dla każdego, kto może się zalogować. Nie
+ma dostępu anonimowego: nikt nie dostaje tej roli bez zalogowania.
+
+Rola nie zawiera grup ani użytkowników, bo i tak obowiązuje wszystkich. Jej `options` są wartościami domyślnymi dla wszystkich, jak
+opisano niżej w [Opcje ról](#role-options). `config.yaml` musi mieć rolę `admin` i rolę `default`, a
+strona ról pokazuje obie jako **Wymagane**.
+
+Przed wersją 7.0.0 `default` nazywała się `public`, a stara nazwa nadal działa:
+
+- **W formularzu** `roles: [public]` nadal pasuje do każdego użytkownika, więc formularze w Twoich repozytoriach nie wymagają zmian.
+- **W `config.yaml`** rola o nazwie `public` jest przy wczytywaniu konfiguracji przemianowywana w pliku na `default`. Zmienia się tylko
+  nazwa, najpierw tworzona jest kopia zapasowa konfiguracji, a konfiguracja trzymana w repozytorium ma potem zmianę do wypchnięcia.
+- **W szablonie ytt** szablon nie jest przepisywany: przemianowywana jest konfiguracja, którą generuje, a ostrzeżenie w dzienniku prosi
+  o zmianę nazwy roli także w szablonie. Wersja 8 odrzuci tam rolę `public`.
+
+Konfiguracja z rolą `default` i rolą `public` jednocześnie jest odrzucana, bo to ta sama rola.
+
+---
+
+## Obiekt Role
+
+Każdy wpis listy `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Opcje ról
+
+`options` roli włączają lub wyłączają funkcje dla jej członków. Od wersji 7.3.0 strona roli pokazuje je w czterech grupach,
+każdą opcję z (i), które mówi, co daje, tym samym tekstem, który pokazuje widok **Uprawnienia** w profilu:
+
+| Opcja | Pozwala użytkownikowi | Domyślnie |
+|---|---|---|
+| **Ustawienia** | | |
+| `showSettings` | Widzieć i zmieniać każdą stronę ustawień; dziennik serwera i kopie zapasowe mają własne opcje | Tylko admini |
+| `showAppearanceSettings` | Zmieniać ustawienia wyglądu, bez pozostałych ustawień (od 7.3.0) | Wyłączona |
+| `showConnectionsSettings` | Zarządzać ustawieniami połączeń (poświadczenia, runnery i inne), bez pozostałych ustawień (od 7.3.0) | Wyłączona |
+| `showLogs` | Widzieć dziennik serwera | Tylko admini |
+| `showAuditLog` | Widzieć dziennik audytu, bez pozostałych ustawień (od 7.3.0) | Tylko admini |
+| `allowBackupOps` | Tworzyć kopię zapasową bazy danych i ją przywracać | Tylko admini |
+| **Projektant** | | |
+| `showDesigner` | Widzieć projektanta i z niego korzystać | Tylko admini |
+| `allowFormDesign` | Edytować konfigurację formularzy w projektancie: kategorie, stałe i formularze. Bez niej tylko do odczytu (od 7.3.0) | Włączona |
+| `allowPlaybookDesign` | Edytować playbooki w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu | Włączona |
+| `allowWorkflowDesign` | Edytować workflowy w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu | Włączona |
+| `allowInventoryDesign` | Edytować inwentarze w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu | Włączona |
+| `allowVarsFileDesign` | Edytować pliki zmiennych w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu | Włączona |
+| **Zadania** | | |
+| `showJobs` | Widzieć stronę zadań | Włączona |
+| `showAllJobLogs` | Widzieć zadania każdego użytkownika, nie tylko własne | Tylko admini |
+| `manageAllJobs` | Przerywać, usuwać i ponownie uruchamiać zadania każdego użytkownika; usuwanie i ponowne uruchamianie wymagają też dwóch opcji poniżej (od 7.3.0) | Tylko admini |
+| `showExtravars` | Widzieć extravars formularza i zadania | Włączona |
+| `showDebugButtons` | Widzieć przyciski debugowania w formularzu | Włączona |
+| `showArtifacts` | Widzieć artefakty zadania: to, co zwraca zadanie AWX, lub to, co playbook zebrał przez `set_stats` | Włączona |
+| `allowVerboseMode` | Uruchamiać zadania w trybie verbose | Włączona |
+| `allowJobRelaunch` | Ponownie uruchamiać zadanie z danymi formularza z wcześniejszego uruchomienia | Tylko admini |
+| `allowJobDeletion` | Usuwać zadania: własne albo, z `manageAllJobs`, każdego użytkownika. Bez niej historia zadań pozostaje kompletna (od 7.3.0) | Włączona |
+| `allowScheduledJobs` | Tworzyć harmonogramy cykliczne i jednorazowe oraz nimi zarządzać na stronie **Harmonogramy** (zobacz ostrzeżenie poniżej) | Tylko admini |
+| `allowPlannedJobs` | Zaplanować jednorazowe uruchomienie zadania o ustalonej porze (**Uruchom później**) | Włączona |
+| `allowStoredJobs` | Zapisywać dane formularza i wczytywać je później | Włączona |
+| **Dostęp i integracje** | | |
+| `allowLogin` | Logować się do AnsibleForms | Włączona |
+| `allowChat` | Używać [asystenta czatu](../chat/), gdy jest włączony | Włączona |
+| `allowMcp` | Używać [serwera MCP](../mcp/) z agenta AI, gdy jest włączony | `allowChat` danej roli |
+| `allowFileUploads` | Przesyłać pliki przez pola plików formularza (od 7.3.0) | Włączona |
+| `allowApiTokens` | Tworzyć [tokeny API](../profile/api-token.html) dla skryptów, do najdłuższego czasu życia, na jaki pozwala instancja (od 7.3.0) | Wyłączona |
+| `extendedTokenExpiration` | Tworzyć też tokeny API, które nigdy nie wygasają; wymaga `allowApiTokens` | Wyłączona |
+
+Niektóre opcje obejmują inne, a strona roli pokazuje te objęte jako włączone i wyszarzone:
+
+- **`showSettings`** daje też `showAppearanceSettings`, `showConnectionsSettings` i `showAuditLog`.
+- **`manageAllJobs`** daje też `showAllJobLogs`, bo działanie na zadaniach każdego użytkownika oznacza ich widzenie.
+- **Opcje projektowania** mają znaczenie tylko z `showDesigner`, a `extendedTokenExpiration` tylko z `allowApiTokens`.
+
+Do wersji 7.2.0 `showAllJobLogs` pozwalało też przerywać i usuwać wyświetlane zadania; od 7.3.0 wymaga to `manageAllJobs`.
+Rola sprzed 7.3.0 z `extendedTokenExpiration` i bez `allowApiTokens` dostaje `allowApiTokens`, więc zachowuje swoje tokeny.
+
+**Tylko admini** oznacza włączoną dla użytkowników z rolą `admin` i wyłączoną dla wszystkich pozostałych. Gdy użytkownik pasuje do kilku ról,
+opcje łączą się następująco:
+
+- **Między rolami użytkownika** opcja jest włączona tylko wtedy, gdy zgadza się każda rola, która ją ustawia: jawne `false` wygrywa.
+- **Rola `default`** uzupełnia opcje, których nie ustawia żadna inna rola użytkownika, więc może zawierać wartości domyślne dla wszystkich.
+- **Opcje nigdzie nieustawione** przyjmują wartość domyślną z tabeli.
+
+`showExtraVars`, z wielkim V, jest akceptowane jako inna pisownia `showExtravars`; gdy którakolwiek pisownia ma wartość `false`,
+opcja jest wyłączona.
+
+{: .warning }
+> Traktuj `allowScheduledJobs` jak opcję na poziomie admina. Harmonogramy nie należą do użytkownika, który je utworzył: każdy użytkownik z
+> tą opcją widzi i może zmieniać wszystkie harmonogramy. Harmonogram działa też z uprawnieniami admina, dla dowolnego formularza, niezależnie od
+> uprawnień twórcy. Nadawaj ją tylko rolom, którym ufasz jak adminom.
+
+{: .warning }
+> `allowLogin: false` w roli `default` blokuje każdego użytkownika, którego pozostałe role nie ustawiają `allowLogin: true`, łącznie
+> z adminami. Przed zapisem przywróć ją w rolach, które muszą się logować.
diff --git a/i18n/pl/_configure/credentials.md b/i18n/pl/_configure/credentials.md
new file mode 100644
index 0000000..4e110b5
--- /dev/null
+++ b/i18n/pl/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Poświadczenia
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Poświadczenia
+{: .no_toc }
+
+Przechowuj dane logowania, których używają formularze, repozytoria, magazyny sekretów i kanały powiadomień
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: dodaj użytkowników, hasła i tokeny, którymi łączy się AnsibleForms, przechowywane w postaci zaszyfrowanej lub odczytywane z magazynu sekretów.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Typy poświadczeń](credentials/types.html) | Co zawiera każdy typ i gdzie można go wybrać |
+| [Strona poświadczeń](credentials/list.html) | Lista poświadczeń i okno, które dodaje nowe |
+| [Strona poświadczenia](credentials/credential-page.html) | Karty poświadczenia i to, co go używa |
+
+---
+
+## Jak to działa
+
+**Poświadczenie** to nazwane dane logowania, dodawane w **Połączenia > Poświadczenia**. Formularze i inne obiekty administracyjne odwołują się
+do niego po nazwie, więc samo hasło nigdy nie pojawia się w formularzu. Jego użytkownik i hasło są albo przechowywane w
+bazie danych AnsibleForms, zaszyfrowane kluczem `ENCRYPTION_SECRET`, albo odczytywane z [magazynu sekretów](secret-stores/) przy każdym
+użyciu poświadczenia.
+
+---
+
+## Kto może zmienić poświadczenie
+
+Od wersji 7.3.0 poświadczenie, od którego zależy połączenie lub logowanie, może dodać, zmienić lub usunąć tylko admin:
+
+| Poświadczenia | Dlaczego |
+|---|---|
+| Typy połączeń: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` i `cyberark` | Runner lub magazyn sekretów bierze z niego swój adres i sekret |
+| Typy logowania: `oidc`, `entraid` i `ldap` | Dostawca SSO lub katalog LDAP loguje nim użytkowników |
+| Każde poświadczenie wskazane przez runner | Runner loguje się nim, a zmiana samego runnera też wymaga admina |
+
+Inni użytkownicy z dostępem do poświadczeń widzą je tylko do odczytu. Użytkownik, który mógłby skierować takie poświadczenie na inny
+serwer, dostałby każdy sekret wysyłany przez nie, dlatego ta zasada odpowiada zasadzie dla runnerów. Trzy kolejne zasady
+trzymają tych użytkowników z dala od sekretów, których inaczej nie mogliby odczytać:
+
+- **Wskazywanie chronionego poświadczenia**: tylko admin może wskazać jedno z tych poświadczeń gdzie indziej, np. w repozytorium,
+  kanale powiadomień lub ustawieniach asystenta czatu. Poświadczenie, które odczytuje hasło z magazynu sekretów, jest
+  chronione tak samo, niezależnie od typu.
+- **Wybór magazynu sekretów**: tylko admin może skierować poświadczenie na [magazyn sekretów](secret-stores/) albo zmienić
+  magazyn lub odwołanie, które odczytuje; inny użytkownik może je nadal odesłać bez zmian albo wyczyścić wszystkie.
+- **Przenoszenie poświadczenia**: gdy inny użytkownik zmienia, gdzie loguje się poświadczenie (jego host, port, wystawcę, dzierżawę lub
+  adres serwera), nie wpisując ponownie hasła, zapisane hasło jest czyszczone, tak samo jak odwołanie do magazynu sekretów,
+  które odczytuje, więc stary sekret nigdy nie trafia do nowego celu.
+
+---
+
+## Poświadczenia w użyciu
+
+Poświadczenia, na które wciąż wskazują jakieś rekordy, nie można usunąć ani przemianować, bo te rekordy wskazywałyby na nic.
+Odmowa podaje, ile rekordów go używa; karta **Używane przez** na [jego stronie](credentials/credential-page.html) je wymienia.
+Najpierw skieruj je na inne poświadczenie, potem je usuń lub przemianuj.
diff --git a/i18n/pl/_configure/credentials/credential-page.md b/i18n/pl/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..8f57343
--- /dev/null
+++ b/i18n/pl/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "Strona poświadczenia"
+parent: Poświadczenia
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# Strona poświadczenia
+{: .no_toc }
+
+Karty poświadczenia i to, co go używa
+{: .fs-6 .fw-300 }
+
+Strona poświadczenia pokazuje kroki jego okna jako karty, a do tego to, co go używa:
+
+| Karta | Co zawiera |
+|---|---|
+| Szczegóły | Nazwa i opis. |
+| Typ | Do czego służy poświadczenie. |
+| Logowanie | Każde pole jego typu, jak w kroku **Logowanie** okna: użytkownik, hasło i miejsce logowania (host i port, baza danych, serwer poczty, serwery katalogu, dzierżawa lub wystawca, adres serwera i jego TLS). W poświadczeniu CyberArk: AppID, certyfikat klienta i klucz. |
+| Magazyn | Baza danych lub Magazyn sekretów oraz magazyn i odwołanie. Nie dotyczy CyberArk ani HashiCorp Vault. |
+| Używane przez | Wszystko, co wskazuje to poświadczenie: magazyny sekretów, kanały powiadomień, repozytoria, katalogi LDAP, dostawcy SSO, runnery, asystent czatu, formularze i workflowy projektanta. Wiersz je otwiera. |
+
+Hasło wpisuje się na karcie **Logowanie** i po zapisaniu nigdy nie jest już pokazywane: pozostawione puste, zapisane hasło zostaje. W poświadczeniu
+CyberArk zostaw klucz klienta pusty, żeby zachować zapisany. W prawym górnym rogu są **Testuj połączenie** (tylko poświadczenia bazy danych),
+**Usuń** i **Zapisz**.
+
+Od wersji 7.3.0 **Usuń** i nowa nazwa są odrzucane, dopóki **Używane przez** cokolwiek wymienia, zobacz [Poświadczenia w użyciu](../credentials.html#credentials-in-use).
+
+Poświadczenie zadeklarowane w [config seed](../seed/) jest na tej stronie tylko do odczytu: zmień je zamiast tego w pliku seed.
diff --git a/i18n/pl/_configure/credentials/list.md b/i18n/pl/_configure/credentials/list.md
new file mode 100644
index 0000000..d1ce8f2
--- /dev/null
+++ b/i18n/pl/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Strona poświadczeń
+parent: Poświadczenia
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# Strona poświadczeń
+{: .no_toc }
+
+Lista poświadczeń i okno, które dodaje nowe
+{: .fs-6 .fw-300 }
+
+Strona w **Połączenia > Poświadczenia** wyświetla każde poświadczenie z jego **Nazwą**, **Typem**, **Opisem** i **Używane przez**, czyli
+liczbą rekordów, formularzy i workflowów, które je wskazują (zobacz [Poświadczenia w użyciu](../credentials.html#credentials-in-use)).
+
+**Dodaj poświadczenie** otwiera okno w krokach:
+
+| Krok | Pola |
+|---|---|
+| Poświadczenie | Nazwa i opis, oba wymagane. |
+| Typ | Jeden z 18 typów, zobacz niżej. |
+| Logowanie | Czym i gdzie loguje się dany typ, zobacz niżej. |
+| Magazyn | Gdzie przechowywane są użytkownik i hasło: **Baza danych** (zaszyfrowane w bazie danych AnsibleForms) lub **Magazyn sekretów**, z magazynem i **Odwołaniem** w nim. Nie dotyczy CyberArk ani HashiCorp Vault, którymi loguje się magazyn sekretów. |
+
+Krok **Typ** wyświetla typy według nazwy: AAP, API, Ascender, AWX, CyberArk, Baza danych, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH oraz Użytkownik i hasło (zobacz [Typy poświadczeń](types.html)).
+
+Krok **Logowanie** zawiera każde pole typu, łącznie z adresem; nie ma osobnego kroku połączenia:
+
+| Typy | Pola kroku Logowanie |
+|---|---|
+| Każdy typ poza CyberArk | Hasło lub to, co je zastępuje: hasło bind w LDAP, client secret w Entra ID i Open ID, token w HashiCorp Vault, token RTE, token API w Semaphore, Rundeck i Jenkins, token lub hasło w AWX, AAP i Ascender |
+| Każdy typ poza HashiCorp Vault, RTE, Semaphore i Rundeck | Użytkownik: AppID w CyberArk, bind DN w LDAP, client ID w Entra ID i Open ID, opcjonalny w AWX, AAP i Ascender |
+| SSH, Baza danych | **Host** i **Port**; dla bazy danych także **Typ bazy danych** i **Baza danych** |
+| SMTP | **Serwer poczty** (wymagany), jego **Port** i **Używaj TLS** |
+| LDAP | **Serwery** katalogu (wymagane), jego **Port** i **Włącz TLS**; z TLS także **Ignoruj certyfikaty**, **Pakiet CA** i **Certyfikat klienta** |
+| Microsoft Entra ID | **Tenant ID** (wymagany) i **Identyfikator URI przekierowania** |
+| Open ID | **Wystawca** (wymagany) i **Identyfikator URI przekierowania** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Serwer**, adres, do którego się loguje, wymagany, z **Pomiń weryfikację certyfikatu** i **Pakietem CA** |
+| CyberArk | **Certyfikat klienta** i **Klucz klienta** |
+
+Wiersz otwiera własną stronę poświadczenia. Jego menu oferuje **Edytuj**, **Testuj połączenie** (tylko poświadczenia bazy danych) i **Usuń**.
+Hasło zmienia się na stronie poświadczenia, na karcie **Logowanie**.
diff --git a/i18n/pl/_configure/credentials/types.md b/i18n/pl/_configure/credentials/types.md
new file mode 100644
index 0000000..e3cfb6f
--- /dev/null
+++ b/i18n/pl/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Typy poświadczeń
+parent: Poświadczenia
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Typy poświadczeń
+{: .no_toc }
+
+Co zawiera każdy typ i gdzie można go wybrać
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Typy
+
+Typ mówi, do czego służy poświadczenie. Decyduje, o które pola pyta okno i gdzie można je wybrać:
+
+| Typ | Co zawiera | Używane przez |
+|---|---|---|
+| Użytkownik i hasło | Użytkownik i hasło do dowolnego logowania: API REST z basic auth, usługa i inne. Domyślny | Playbooki, przez `credentials` formularza lub pole poświadczenia; [wyrażenia REST](../expressions/credentials.html) |
+| SSH | Użytkownik i hasło do SSH na serwer, z jego hostem i portem | Playbooki, przez `credentials`, `ansibleCredentials` formularza lub pole poświadczenia, oraz logowanie węzła workflow |
+| Git | Użytkownik i hasło lub token do repozytoriów git | [Repozytoria](../repositories/authentication.html) |
+| API | Użytkownik i hasło lub token do API REST | [Wyrażenia REST](../expressions/credentials.html), token bota Telegram, token bearer webhooka, klucz API asystenta czatu |
+| Baza danych | Dostęp do bazy danych z jej typem, hostem, portem i nazwą bazy | Zapytania formularzy (`dbConfig`) i `fnCredentials`; można go przetestować |
+| CyberArk | Adres CyberArk Central Credential Provider (CCP) i jego TLS oraz AppID, certyfikat klienta i klucz, którymi loguje się magazyn CyberArk | Magazyn sekretów [CyberArk](../secret-stores/cyberark.html) |
+| SMTP | Serwer poczty, jego port i TLS oraz logowanie (brak dla przekaźnika) | Pocztowy [kanał powiadomień](../notification-channels.html) |
+| LDAP | Serwery katalogu, port, TLS i certyfikaty oraz jego bind DN i hasło | [Katalog LDAP](../authentication/ldap.html) |
+| Microsoft Entra ID | Rejestracja aplikacji dostawcy: tenant ID, client ID, client secret i identyfikator URI przekierowania | [Dostawca Entra ID](../authentication/entra-id.html) |
+| Open ID | Klient dostawcy: wystawca, client ID, client secret i identyfikator URI przekierowania | [Dostawca OIDC](../authentication/oidc.html) |
+| RTE | Token (`RTE_TOKEN`) i adres RTE | [Runner](../runners.html) RTE |
+| AWX, AAP, Ascender | Token lub login oraz adres tej platformy | Runner tego typu |
+| Semaphore, Rundeck | Token API i adres tego produktu | Runner tego typu |
+| Jenkins | Użytkownik, jego token API i adres Jenkinsa | Runner Jenkins |
+| HashiCorp Vault | Token i adres, którymi loguje się magazyn Vault | Magazyn sekretów [HashiCorp Vault](../secret-stores/hashicorp-vault.html) |
+
+Poświadczenie bazy danych może być typu MySQL, MSSQL, PostgreSQL, Oracle lub MongoDB.
+
+W API i w [config seed](../seed/) typy to `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` i `vault`. Aktualizacja z wersji 6
+nadaje każdemu poświadczeniu typ `userpass` albo `database` dla poświadczenia bazy danych: formularz używa go tak jak w 6. Zmień go na SSH dla
+logowania, którym łączy się playbook węzła workflow, albo na API dla API REST.
+
+---
+
+## Adresy w poświadczeniach
+
+Od wersji 7.3.0 dane logowania, które działają na jednym serwerze, zawierają ten serwer, więc rekord, który ich używa, tylko wskazuje poświadczenie:
+
+| Rekord | Co przeniesiono do jego poświadczenia |
+|---|---|
+| Katalog LDAP | Jego serwery, port, TLS, certyfikaty i konto bind, do poświadczenia `ldap` o nazwie `<directory>-ldap` |
+| Dostawca SSO | Jego client ID i secret, dzierżawa lub wystawca oraz identyfikator URI przekierowania, do poświadczenia `entraid` lub `oidc` o nazwie `<provider>-sso` |
+| Runner | Jego adres i TLS oraz token lub login, do poświadczenia jego typu, `<runner>-token` lub `<runner>-login` |
+| Magazyn sekretów | Jego adres i TLS oraz token (`<store>-token`) lub AppID i certyfikat CyberArk (`<store>-appid`) |
+| Kanał pocztowy | Jego serwer, port i TLS, do jego poświadczenia `smtp` lub nowego o nazwie `<channel>-smtp` |
+
+Aktualizacja do 7.3.0 wykonuje te przeniesienia raz. Rekord, który już wskazywał poświadczenie, zachowuje je i dostaje jego kopię, gdy
+inny rekord używał tych samych danych logowania z innym serwerem. Rekordy zadeklarowane w [config seed](../seed/) pozostają takie, jak w seedzie.
+Poświadczenia połączeń i logowań może zmienić tylko admin, zobacz [Kto może zmienić poświadczenie](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/pl/_configure/customization/configuration.md b/i18n/pl/_configure/customization/configuration.md
new file mode 100644
index 0000000..cadbeb3
--- /dev/null
+++ b/i18n/pl/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Konfiguracja
+parent: Zmienne środowiskowe
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Konfiguracja
+{: .no_toc }
+
+Config seed, miejsce przechowywania konfiguracji, git i ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby zdecydować, skąd pochodzi konfiguracja: z config seed, bazy danych, gita lub szablonów ytt.
+
+---
+
+## Przykład
+
+Zastosuj zamontowany config seed, sprawdzaj go co pięć minut i trzymaj `config.yaml` w bazie danych. W `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Nieprawidłowy seed nie pozwala serwerowi się uruchomić. Format pliku opisuje [Config seed](../seed/).
+
+---
+
+## Skąd odczytywany jest config.yaml
+
+Kategorie, role i stałe pochodzą z `config.yaml` na dysku lub z jego kopii w bazie danych, o czym decyduje ta kolejność:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), gdy jest ustawiona, w środowisku lub na
+   karcie **Konfiguracja** strony ustawień: `1` odczytuje bazę danych, `0` odczytuje plik.
+2. W przeciwnym razie źródło konfiguracji zapisane w bazie danych (`file` lub `database`), które instancje skonfigurowane
+   przed wersją 6.3.0 wybrały na stronie ustawień.
+3. W przeciwnym razie plik: `config.yaml` repozytorium z włączonym **Używać do konfiguracji?**, a jeśli takiego nie ma, repozytorium z włączonym
+   **Używać do formularzy?**, a jeśli i takiego nie ma, ten z [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Jawnie ustawiona `ENABLE_CONFIG_IN_DATABASE` zawsze wygrywa, nawet `0` z zapisanym `database`. Jest odczytywana przy każdym
+wczytaniu konfiguracji, więc zmiana działa bez restartu. Strona **Stan** pokazuje używane źródło na karcie **Informacje**.
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/pl/_configure/customization/features.md b/i18n/pl/_configure/customization/features.md
new file mode 100644
index 0000000..019f06c
--- /dev/null
+++ b/i18n/pl/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Funkcje
+parent: Zmienne środowiskowe
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Funkcje
+{: .no_toc }
+
+Projektant, MCP, czat, walidacja uruchomień, lista zadań, metryki, API AWX i logowanie zapytań
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby włączyć lub wyłączyć opcjonalne części aplikacji.
+
+---
+
+## Przykład
+
+Udostępnij serwer MCP agentom AI i wymuszaj reguły walidacji formularza przy każdym uruchomieniu. W `.env` projektu compose:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` i `ENABLE_CHAT` działają bez restartu: są odczytywane przy każdym żądaniu, więc możesz je przełączać na
+stronie ustawień. Gdy któraś jest wyłączona, jej punkt końcowy (`/api/v2/mcp` lub `/api/v2/chat`) odpowiada `404`.
+
+Najpierw uruchom na jakiś czas `LAUNCH_VALIDATION=log`: zapisuje w dzienniku to, co `enforce` by odrzuciło, ale tego nie odrzuca. Zobacz [MCP](../mcp/)
+i [Rejestrowanie i wymuszanie](../launch-validation/log-and-enforce.html).
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/pl/_configure/customization/index.md b/i18n/pl/_configure/customization/index.md
new file mode 100644
index 0000000..c52ac04
--- /dev/null
+++ b/i18n/pl/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Zmienne środowiskowe
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Zmienne środowiskowe
+{: .no_toc }
+
+Konfiguruj AnsibleForms za pomocą zmiennych środowiskowych
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów, którzy wdrażają AnsibleForms: zmienne środowiskowe odczytywane przez serwer, pogrupowane tematycznie.
+
+AnsibleForms dostraja się zmiennymi środowiskowymi, niezależnie od tego, czy działa z Docker Compose, na Kubernetes, czy ze źródeł.
+
+---
+
+## Skąd pochodzą wartości
+
+Serwer odczytuje każdą zmienną z pierwszego z tych źródeł, które ją ustawia, więc wartość wyżej na liście zawsze wygrywa:
+
+1. **Środowisko procesu**: `environment:` i `env_file:` w docker-compose (tak przekazywany jest `.env` projektu),
+   `env` i `envFrom` na Kubernetes albo powłoka, która uruchamia `node`.
+2. **`persistent/.env`**, plik zapisywany przez strony ustawień (`data/.env` w projekcie docker-compose, inna ścieżka przy
+   `MANAGED_ENV_PATH`). Jest odczytywany przy każdym uruchomieniu, także w produkcji, i nigdy nie nadpisuje zmiennej, która jest już ustawiona.
+3. **`server/.env.<NODE_ENV>`**, np. `.env.development`. Odczytywany tylko wtedy, gdy `NODE_ENV` nie jest `production` (lub z
+   `FORCE_DOTENV=1`), w praktyce przy uruchamianiu [ze źródeł](../installation/from-source.html) w trybie deweloperskim.
+4. **Wbudowana wartość domyślna**, pokazana w tabelach każdej grupy.
+
+Strony ustawień, w **Ustawienia > Ogólne**, pokazują obowiązującą wartość i zapisują zmiany w `persistent/.env`. Wiele zmiennych
+działa od razu po zapisaniu; pozostałe są zapisywane, ale wymagają restartu, a strona wymienia je po zapisie. Zmiennej ustawionej w
+środowisku procesu nie można tam zmienić: strona pokazuje ją jako *Ustawione w środowisku, więc nie można tego tutaj zmienić.*
+Kilku zmiennych, takich jak `ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET`, nigdy nie można zmienić ze strony.
+
+Zmiennych odczytywanych przez RTE, takich jak `AF_ROLE`, `RTE_MODE`, `APP_URL` czy `RTE_MAX_JOBS`, w ogóle nie ma na stronach ustawień:
+aplikacja ich nie używa, więc ustaw je w środowisku, w którym działa RTE. Wyjątkiem są zmienne `RTE_*` odczytywane przez samą aplikację,
+`RTE_QUEUE_MINUTES` i `RTE_FILES_MAX_MB`, które zostają na stronach. Cztery zmienne RTE, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` i `RTE_DRAIN_SECONDS`, można zamiast tego ustawić dla każdego RTE na jego stronie runnera, gdzie wartość wygrywa ze
+zmienną (zobacz [Ustawienia RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Przy [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` strony tylko pokazują wartości, a zapis jest odrzucany. Używaj tego,
+gdy środowisko jest zadeklarowane w manifeście, jak opisano w [Edycja i audyt](../seed/environment-and-audit.html).
+
+[Config seed](../seed/) nie ustawia żadnych zmiennych środowiskowych. Deklaruje obiekty przechowywane w bazie danych, a
+odwołania `${ENV_VAR}` w nim są rozwiązywane ze środowiska działającego serwera.
+
+Kilka zmiennych jest odczytywanych tylko ze środowiska i nie ma ich w tabelach: `MANAGED_ENV_PATH` i `FORCE_DOTENV`, opisane
+wyżej, oraz systemowe zmienne proxy `HTTPS_PROXY` i `NO_PROXY` (odczytywane też małymi literami). RTE w trybie wychodzącym łączy się z aplikacją przez
+`HTTPS_PROXY`, a RTE w trybie przychodzącym wysyła przez nie swoje wywołanie rejestracji, chyba że host aplikacji jest w `NO_PROXY` (nazwy hostów,
+sufiksy `.domain` lub `*` dla każdego hosta).
+
+Zmienne oznaczone <span class="af-badge af-badge-secret">Sekret</span> zawierają hasło, token lub klucz: trzymaj je poza systemem kontroli
+wersji, np. w Secret Kubernetes lub w pliku `.env`, który nie jest commitowany.
+
+---
+
+## W tej sekcji
+
+Zmienne są pogrupowane tematycznie, z jedną stroną na grupę:
+
+| Strona | Czego dotyczy |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Inne zmienne
+
+Poniższe zmienne nie są jeszcze przypisane do żadnej grupy:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/pl/_configure/customization/logging.md b/i18n/pl/_configure/customization/logging.md
new file mode 100644
index 0000000..58f199c
--- /dev/null
+++ b/i18n/pl/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Rejestrowanie
+parent: Zmienne środowiskowe
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Rejestrowanie
+{: .no_toc }
+
+Poziomy logowania, pliki, syslog i kolory konsoli
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby ustawić, ile jest zapisywane w dzienniku, gdzie trafiają pliki dziennika, albo aby pokazywać znaczniki czasu we własnej strefie czasowej.
+
+---
+
+## Przykład
+
+Zapisuj w plikach więcej niż na konsoli i pokazuj znaczniki czasu dziennika i zadań w czasie Amsterdamu.
+W `.env` projektu compose:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Serwerów syslog nie konfiguruje się już tutaj: dodaj je w **Ustawienia > Połączenia > Syslog**, zobacz [Dzienniki](../production/logs.html#syslog).
+Poniższe zmienne `LOG_SYSLOG_*` są przestarzałe od wersji 7. Pierwsze uruchomienie, które znajdzie ustawioną `LOG_SYSLOG_HOST`, importuje je
+jednorazowo jako serwer syslog `syslog`, który otrzymuje dziennik serwera, i od tej pory je ignoruje.
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/pl/_configure/customization/paths.md b/i18n/pl/_configure/customization/paths.md
new file mode 100644
index 0000000..512c655
--- /dev/null
+++ b/i18n/pl/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Ścieżki
+parent: Zmienne środowiskowe
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Ścieżki
+{: .no_toc }
+
+Gdzie znajdują się konfiguracja, formularze, playbooki, przesłane pliki i kopie zapasowe
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby trzymać część danych na innym wolumenie, np. kopie zapasowe i przesłane pliki na większym lub tańszym magazynie.
+
+---
+
+## Przykład
+
+Kopie zapasowe i przesłane pliki na osobnym wolumenie, reszta danych w zwykłym folderze trwałym. W `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Nowa ścieżka dotyczy tylko nowych plików: to, co już jest w starym folderze, nie jest przenoszone, więc skopiuj to samodzielnie.
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/pl/_configure/customization/retention.md b/i18n/pl/_configure/customization/retention.md
new file mode 100644
index 0000000..5255f45
--- /dev/null
+++ b/i18n/pl/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Kopie zapasowe i retencja
+parent: Zmienne środowiskowe
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Kopie zapasowe i retencja
+{: .no_toc }
+
+Polecenia kopii zapasowych oraz jak długo przechowywane są kopie zapasowe, zadania i wpisy audytu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby kontrolować, ile historii przechowuje baza danych i ile kopii zapasowych zostaje na dysku.
+
+---
+
+## Przykład
+
+Przechowuj zakończone zadania przez 90 dni, a ślad audytu przez dwa lata. W `.env` projektu compose:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Codzienne zadanie usuwa starsze zakończone zadania o 2:30, a wpisy audytu o 3:30. Działające zadanie albo takie, które czeka na
+zatwierdzenie, nigdy nie jest usuwane. Obie zmienne działają bez restartu, gdy zmienia się je na stronie ustawień.
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/pl/_configure/customization/security.md b/i18n/pl/_configure/customization/security.md
new file mode 100644
index 0000000..c159d85
--- /dev/null
+++ b/i18n/pl/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Zmienne bezpieczeństwa
+parent: Zmienne środowiskowe
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Zmienne bezpieczeństwa
+{: .no_toc }
+
+Tokeny, szyfrowanie, wychodzące hosty REST, maskowanie i stare ustawienia VAULT_*
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, aby ustawić własne sekrety tokenów i szyfrowania oraz ograniczyć to, co formularze mogą wywoływać i pokazywać.
+
+---
+
+## Przykład
+
+Własne sekrety, wywołania REST ograniczone do jednego API i sieci wewnętrznej oraz jeden dodatkowy maskowany klucz. W `.env` projektu compose:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Ustaw `ENCRYPTION_SECRET`, zanim zostanie zapisane pierwsze poświadczenie. Od wersji 7.3.0 ustawienie lub zmiana go ponownie szyfruje każdy zapisany
+sekret przy następnym uruchomieniu, przy czym `ENCRYPTION_SECRET_PREVIOUS` wskazuje stary klucz, jeśli był Twój własny, zobacz
+[Zmiana sekretu szyfrowania](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## Wywołania REST i jq
+
+Od wersji 7.3.0 funkcje pomocnicze REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) sprawdzają
+certyfikat wywoływanego punktu końcowego, jak każde inne połączenie; do wersji 7.2.0 nigdy tego nie robiły. Dotyczą ich trzy ustawienia:
+
+| Zmienna | Domyślnie | Efekt |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` pomija sprawdzanie certyfikatu: tylko dla punktów końcowych z certyfikatem samopodpisanym |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Jak długo wywołanie REST czeka na odpowiedź, zanim zakończy się błędem przekroczenia czasu |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Jak długo może działać filtr jq, zanim zostanie zatrzymany; wynik jq jest też ograniczony do 64 MB |
+
+Wszystkie trzy działają po zapisaniu, bez restartu. Dla punktu końcowego, którego certyfikat jest podpisany przez prywatne CA, zostaw sprawdzanie włączone
+i zamiast tego przekaż to CA do Node.js: ustaw w środowisku aplikacji `NODE_EXTRA_CA_CERTS` na plik PEM, który je zawiera, a potem uruchom aplikację ponownie.
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/pl/_configure/customization/server.md b/i18n/pl/_configure/customization/server.md
new file mode 100644
index 0000000..d74898d
--- /dev/null
+++ b/i18n/pl/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Serwer i baza danych
+parent: Zmienne środowiskowe
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Serwer i baza danych
+{: .no_toc }
+
+Serwer WWW, połączenie z MySQL, konto admina i to, co uruchamia każdy proces (AF_ROLE i zmienne RTE_*)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zmień je, gdy aplikacja działa za reverse proxy, na innym porcie lub z bazą danych spoza projektu compose.
+
+---
+
+## Przykład
+
+Za reverse proxy, które terminuje TLS, pod `/ansibleforms`, z zewnętrzną bazą MySQL. W `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Zastępują one linie `DB_*` i `PORT`, które plik compose już tam ma i które wygrywają z tymi samymi nazwami w `.env`. Usuń
+usługę `mysqldb` i `depends_on`, które na nią czeka, a w `ports` zmapuj port 8000. Konfigurację po stronie proxy opisuje
+strona [Reverse proxy](../production/reverse-proxy.html).
+
+---
+
+## Zmienne
+
+Każda zmienna tej grupy, z typem, wartością domyślną i opisem:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/pl/_configure/disclaimer.md b/i18n/pl/_configure/disclaimer.md
new file mode 100644
index 0000000..b62c38a
--- /dev/null
+++ b/i18n/pl/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Zastrzeżenie
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Zastrzeżenie
+{: .no_toc }
+
+Warunki, które każdy użytkownik akceptuje raz przed użyciem aplikacji, zapisywane z tym, kto zaakceptował którą wersję i kiedy
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: poproś każdego użytkownika o akceptację warunków korzystania w **Ustawienia > Dostęp > Zastrzeżenie**, z opcją roli `showSettings`.
+
+Od wersji 7.3.0 strona wyświetla każdą wersję zastrzeżenia, a każda wersja otwiera się na własnej stronie ze swoimi akceptacjami.
+Do wersji 7.2 strona miała zamiast tego trzy karty (**Ogólne**, **Wersje** i **Akceptacje**); aktualizacja zachowuje każdą wersję.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Ogólne](disclaimer/general.html) | Lista wersji, dodawanie wersji i włączanie tej, którą akceptują użytkownicy |
+| [Wersje](disclaimer/versions.html) | Strona wersji i zmiana jej tekstu jako poprawki lub ponownie dla wszystkich |
+| [Akceptacje](disclaimer/acceptances.html) | Kto zaakceptował którą wersję i ponowne pytanie wybranych użytkowników |
+
+
+---
+
+## Co widzą użytkownicy
+
+Gdy jakaś wersja jest włączona, każdy użytkownik, który się loguje, dostaje ją w oknie przed czymkolwiek innym, także admini:
+
+1. Czytają jej tytuł i tekst.
+2. Zaznaczają pole wyboru, a potem klikają **Akceptuj**. **Odrzuć**, na czerwono, zamiast tego ich wylogowuje.
+
+Od wersji 7.3.0 strona za oknem jest rozmyta, dopóki nie odpowiedzą.
+
+Użytkownik akceptuje każdą wersję raz: przy następnym logowaniu nie jest pytany ponownie, tylko gdy pojawi się nowa wersja, gdy
+admin zapisze zmieniony tekst z [Zapytaj wszystkich ponownie](disclaimer/versions.html#changing-the-text) albo gdy admin użyje
+[Poproś ponownie](disclaimer/acceptances.html#asking-users-again) na jego akceptacji.
+
+Dopóki nie zaakceptują, API odpowiada na każde wywołanie z ich sesji statusem `403` i kodem `disclaimer_required`,
+z wyjątkiem wywołań pod `/api/v2/disclaimer` i `/api/v2/profile` oraz zdarzeń na żywo, które śledzi przeglądarka.
+[Token API](profile/api-token.html) nigdy nie jest pytany, bo w skrypcie nie ma nikogo, kto mógłby kliknąć.
+
diff --git a/i18n/pl/_configure/disclaimer/acceptances.md b/i18n/pl/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..94a5536
--- /dev/null
+++ b/i18n/pl/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Akceptacje
+parent: Zastrzeżenie
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Akceptacje
+{: .no_toc }
+
+Kto zaakceptował którą wersję i ponowne pytanie wybranych użytkowników
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Kto zaakceptował
+
+Każda akceptacja jest zapisywana dla użytkownika i wersji, a karta **Akceptacje** na stronie wersji wyświetla je, od najnowszej:
+
+| Kolumna | Znaczenie |
+|---|---|
+| **Użytkownik** | Nazwa użytkownika |
+| **Logowanie** | Jak się zalogował: lokalnie, LDAP, Microsoft Entra ID lub OpenID Connect |
+| **Zaakceptowano** | Kiedy |
+| **Adres IP** | Skąd |
+| **Przeglądarka** | Jego przeglądarka |
+
+---
+
+## Ponowne pytanie użytkowników
+
+Od wersji 7.3.0 wybranych użytkowników można poprosić o ponowną akceptację wersji, bez pytania wszystkich.
+
+**Poproś ponownie** w menu wiersza albo na wierszach zaznaczonych na liście usuwa te akceptacje po potwierdzeniu: ci użytkownicy dostają
+zastrzeżenie ponownie przy następnym żądaniu, bez ponownego logowania. Listę można też wyeksportować, jak każdą tabelę.
+
+[Dziennik audytu](../production/logs.html#audit-trail) zapisuje też każdą akceptację, każde odrzucenie i każdą zmianę zastrzeżenia.
diff --git a/i18n/pl/_configure/disclaimer/general.md b/i18n/pl/_configure/disclaimer/general.md
new file mode 100644
index 0000000..ca073a0
--- /dev/null
+++ b/i18n/pl/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Ogólne
+parent: Zastrzeżenie
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Ogólne
+{: .no_toc }
+
+Lista wersji, dodawanie wersji i włączanie tej, którą akceptują użytkownicy
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lista
+
+Od wersji 7.3.0 **Ustawienia > Dostęp > Zastrzeżenie** to lista wersji zastrzeżenia, po jednej na każdy tekst w postaci, w jakiej go zaakceptowano:
+
+| Kolumna | Znaczenie |
+|---|---|
+| **Włączona** | Czy to ta wersja, którą akceptują użytkownicy; włączona może być najwyżej jedna |
+| **Wersja** | Jej numer, liczony od 1 |
+| **Tytuł** | Tytuł jej okna |
+| **Opublikował** | Kto ją dodał |
+| **Opublikowano** | Kiedy |
+| **Akceptacje** | Ilu użytkowników ją zaakceptowało |
+
+Kliknięcie wiersza albo **Edytuj** w menu wiersza otwiera [stronę wersji](versions.html). W menu są też **Włącz** lub **Wyłącz** oraz **Usuń**.
+
+---
+
+## Dodawanie wersji
+
+**Dodaj zastrzeżenie** otwiera okno nowej wersji, z kolejnym numerem, która nie jest włączona, dopóki jej nie włączysz:
+
+| Pole | Znaczenie |
+|---|---|
+| **Tytuł** | Tytuł okna, np. Warunki korzystania |
+| **Tekst** | Na co zgadzają się użytkownicy, najwyżej 20000 znaków. Zwykły tekst: podziały wierszy są zachowane. |
+| **Pole wyboru** | Co użytkownicy zaznaczają, zanim mogą zaakceptować, na początku "Przeczytałem i akceptuję te warunki." |
+
+Wszystkie trzy są wymagane. Wersja włączona do tej pory pozostaje tą, którą akceptują użytkownicy, więc nowy tekst można przygotować z wyprzedzeniem.
+
+---
+
+## Włączanie wersji
+
+**Włącz** w menu wiersza albo przełącznik **Włączona** na stronie wersji czyni tę wersję tą, którą akceptują użytkownicy, i wyłącza
+pozostałe.
+
+Użytkownicy, którzy już zaakceptowali tę wersję, nie są pytani ponownie, więc wcześniejszą wersję można włączyć ponownie bez pytania wszystkich.
+**Wyłącz** na włączonej wersji wyłącza zastrzeżenie, dopóki jakaś wersja nie zostanie ponownie włączona; wersje i akceptacje zostają.
+Usunięcie wersji usuwa też jej akceptacje, a usunięcie włączonej wyłącza zastrzeżenie.
diff --git a/i18n/pl/_configure/disclaimer/versions.md b/i18n/pl/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..6762d77
--- /dev/null
+++ b/i18n/pl/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Wersje
+parent: Zastrzeżenie
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Wersje
+{: .no_toc }
+
+Strona wersji i zmiana jej tekstu jako poprawki lub ponownie dla wszystkich
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Strona wersji
+
+Od wersji 7.3.0 każda wersja ma własną stronę, pod adresem `/settings/disclaimer/<version>`, z dwiema kartami:
+
+| Karta | Co zawiera |
+|---|---|
+| **Szczegóły** | Tytuł, tekst i etykietę pola wyboru oraz przełącznik **Włączona**, który zapisuje się od razu |
+| **Akceptacje** | Kto zaakceptował tę wersję, zobacz [Akceptacje](acceptances.html) |
+
+**Podgląd** pokazuje okno tak, jak zobaczą je użytkownicy, a **Usuń** usuwa wersję razem z jej akceptacjami. Pole wyszukiwania nad
+kartami przeszukuje obie naraz: pasujące pola w **Szczegóły** i pasujące wiersze w **Akceptacje**.
+
+---
+
+## Zmiana tekstu
+
+**Zapisz** przy zmienionym tytule, tekście lub etykiecie pola wyboru, które użytkownicy już zaakceptowali, pyta **Zapytać wszystkich ponownie?**:
+
+| Odpowiedź | Co się dzieje |
+|---|---|
+| **Zapytaj wszystkich ponownie** | Akceptacje tej wersji są usuwane, a każdy użytkownik akceptuje ją ponownie przy następnym żądaniu |
+| **Zachowaj jako poprawkę** | Tekst zostaje przepisany, np. z powodu literówki, a akceptacje nadal się liczą: nikt nie jest pytany ponownie |
+
+Wersja, której nikt jeszcze nie zaakceptował, zapisuje się bez pytania. Aby zachować zaakceptowany tekst, [dodaj nową wersję](general.html#adding-a-version) i ją włącz.
diff --git a/i18n/pl/_configure/notification-channels.md b/i18n/pl/_configure/notification-channels.md
new file mode 100644
index 0000000..22fcf93
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Kanały powiadomień
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Kanały powiadomień
+{: .no_toc }
+
+Wysyłaj prośby o zatwierdzenie i powiadomienia o zadaniach pocztą, na Slack, do Microsoft Teams, na Telegram lub do dowolnego webhooka
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: dodaj serwery poczty i kanały czatu, do których formularze wysyłają powiadomienia i zatwierdzenia.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Poczta](notification-channels/mail.html) | Serwery SMTP, serwer domyślny i ich logowanie |
+| [Slack i Microsoft Teams](notification-channels/slack-and-teams.html) | Webhook kanału Slack lub Teams |
+| [Telegram](notification-channels/telegram.html) | Bot piszący na czacie Telegram |
+| [Webhook](notification-channels/webhook.html) | Żądanie JSON do dowolnego endpointu HTTP |
+| [Kanały w formularzu](notification-channels/in-a-form.html) | Wskazywanie kanałów w powiadomieniach i zatwierdzeniach |
+| [Testowanie kanału](notification-channels/testing.html) | Wyślij test i co on dowodzi |
+
+
+---
+
+## Jak to działa
+
+**Kanał powiadomień** to miejsce, do którego trafiają powiadomienia, dodawane w **Połączenia > Powiadomienia**. Każdy kanał ma
+jeden z tych typów:
+
+| Typ | Co wysyła |
+|---|---|
+| Poczta | Pocztę przez serwer SMTP: prośby o zatwierdzenie i powiadomienia o zadaniach. |
+| Slack | Wiadomość na kanale Slack, przez jego webhook przychodzący, z przyciskiem do zadania. |
+| Microsoft Teams | Kartę na kanale Teams, przez webhook Workflows, z przyciskiem do zadania. |
+| Telegram | Wiadomość od bota na czacie Telegram, z linkiem do zadania. |
+| Webhook | Żądanie JSON do dowolnego endpointu HTTP, zbudowane z szablonu. |
+
+Formularz wskazuje swoje kanały w [powiadomieniach](forms/notifications.html) i w [zatwierdzeniu](forms/approval.html),
+przez `channels:`. Powiadomienie, którego nie da się wysłać, trafia do dziennika; nigdy nie powoduje niepowodzenia zadania ani zatwierdzenia.
+
+---
+
+## Strona powiadomień
+
+Strona w **Połączenia > Powiadomienia** wyświetla każdy kanał z tymi kolumnami:
+
+| Kolumna | Znaczenie |
+|---|---|
+| Włączony | Czy wysyłane są do niego powiadomienia, zobacz [Kanały w formularzu](notification-channels/in-a-form.html). |
+| Nazwa | Jak formularze odwołują się do niego w `channels:`. |
+| Typ | Poczta, Slack, Microsoft Teams, Telegram lub Webhook. Domyślny kanał pocztowy pokazuje po typie pigułkę **Domyślny**. |
+| Opis | Do czego służy kanał. |
+
+**Dodaj kanał powiadomień** otwiera okno: **Kanał** (nazwa i opis), **Typ**, a potem kroki wybranego
+typu. Typ ustala się przy tworzeniu kanału i potem się nie zmienia. Wiersz otwiera własną stronę kanału, z tymi samymi krokami jako
+kartami po **Szczegóły** oraz z **Wyślij test**, **Usuń** i **Zapisz** w prawym górnym rogu. Menu wiersza oferuje
+**Edytuj**, **Włącz** lub **Wyłącz** (zależnie od stanu), **Ustaw jako domyślny** (poczta), **Wyślij test** i **Usuń**.
+
+Karta **Szczegóły** na stronie kanału zawiera przełącznik **Włączony**, który zapisuje się od razu, a dla poczty przełącznik **Domyślny**,
+który zapisuje się przyciskiem **Zapisz**.
+
+Użytkownik, który otwiera te strony z `showConnectionsSettings`, ale bez roli admin, nie może wybrać poświadczenia, które
+może wskazać tylko admin, zobacz [Kto może zmienić poświadczenie](credentials.html#who-may-change-a-credential). Gdy taki użytkownik zmienia,
+dokąd kanał wysyła (url webhooka lub jego sprawdzanie certyfikatu, adres Bot API Telegrama), kanał traci
+wskazane poświadczenie, chyba że w tej samej zmianie wybierze nowe.
+
+Kanał zadeklarowany w [config seed](seed/) jest na tej stronie tylko do odczytu, ale nadal można go przetestować.
+
diff --git a/i18n/pl/_configure/notification-channels/in-a-form.md b/i18n/pl/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..efc344f
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Kanały w formularzu
+parent: Kanały powiadomień
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Kanały w formularzu
+{: .no_toc }
+
+Wskazywanie kanałów w powiadomieniach i zatwierdzeniach
+{: .fs-6 .fw-300 }
+
+Formularze wskazują kanały po nazwie, w `notifications` dla statusu i zdarzeń zadania oraz w `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- Kanały czatu i webhooka dostają krótką wiadomość (formularz, zadanie, co się stało) z linkiem do zadania; przy
+  zatwierdzeniu to na stronie zadania się je zatwierdza lub odrzuca.
+- Kanał **pocztowy** na liście wysyła zwykłą wiadomość do `recipients` (adresów `notifications` zatwierdzenia) przez
+  ten serwer zamiast domyślnego.
+- Nazwa, która nie istnieje, albo wyłączony kanał czatu lub webhooka jest pomijany, z informacją w dzienniku.
+- Wyłączony kanał **pocztowy** nie jest pomijany: wiadomość idzie zamiast niego przez domyślny kanał pocztowy, a
+  dziennik to odnotowuje.
diff --git a/i18n/pl/_configure/notification-channels/mail.md b/i18n/pl/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..8fd94b7
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Poczta
+parent: Kanały powiadomień
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Poczta
+{: .no_toc }
+
+Serwery SMTP, serwer domyślny i ich logowanie
+{: .fs-6 .fw-300 }
+
+Kanał pocztowy to serwer SMTP. Możesz mieć ich kilka; ten oznaczony jako **Domyślny** to serwer, przez który aplikacja wysyła
+pocztę, gdy formularz nie wskazuje żadnego kanału pocztowego. Pierwszy kanał pocztowy staje się domyślnym, a **Ustaw jako domyślny** to zmienia.
+
+| Krok | Pole | Znaczenie |
+|---|---|---|
+| Poświadczenia | Poświadczenie | Wymagane. Poświadczenie **smtp** z [Połączenia > Poświadczenia](../credentials.html): serwer poczty, jego port i TLS oraz logowanie. Dla przekaźnika bez logowania poświadczenie smtp bez użytkownika. |
+| Nadawca | Nadawca | Adres nadawcy widoczny dla odbiorców. |
+
+Przełącznik **Domyślny** na karcie **Szczegóły** strony kanału pocztowego ustawia go jako domyślny, tak jak **Ustaw jako domyślny**.
+Ustawienia poczty z config seed są używane, dopóki żaden kanał pocztowy nie jest domyślny lub dopóki domyślny jest wyłączony.
diff --git a/i18n/pl/_configure/notification-channels/slack-and-teams.md b/i18n/pl/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..8cb0541
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack i Microsoft Teams
+parent: Kanały powiadomień
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack i Microsoft Teams
+{: .no_toc }
+
+Webhook kanału Slack lub Teams
+{: .fs-6 .fw-300 }
+
+Kanały Slack i Teams potrzebują tylko adresu webhooka kanału:
+
+| Typ | Adres webhooka |
+|---|---|
+| Slack | Webhook przychodzący kanału (aplikacja Slack > Incoming Webhooks). |
+| Microsoft Teams | Webhook Workflows kanału ("post to a channel when a webhook request is received"). |
+
+Adres jest sekretem, który pozwala każdemu pisać na kanale: jest przechowywany w postaci zaszyfrowanej i po zapisaniu nigdy więcej nie jest pokazywany.
diff --git a/i18n/pl/_configure/notification-channels/telegram.md b/i18n/pl/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..62c3e2e
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Kanały powiadomień
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Bot piszący na czacie Telegram
+{: .fs-6 .fw-300 }
+
+Kanał Telegram to bot piszący na czacie. Jego krok **Poświadczenia** zawiera **Token bota**, a krok **Bot** resztę:
+
+| Pole | Znaczenie |
+|---|---|
+| Token bota | Poświadczenie **api** z [Połączenia > Poświadczenia](../credentials.html), którego hasło jest tokenem bota od BotFather. |
+| Id czatu | Czat, grupa lub kanał, w którym pisze bot; liczba ujemna dla grupy lub kanału. |
+| Adres Bot API | Własny serwer Bot API; puste dla `api.telegram.org`. |
diff --git a/i18n/pl/_configure/notification-channels/testing.md b/i18n/pl/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..4a0ab49
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Testowanie kanału
+parent: Kanały powiadomień
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Testowanie kanału
+{: .no_toc }
+
+Wyślij test i co on dowodzi
+{: .fs-6 .fw-300 }
+
+**Wyślij test** wysyła powiadomienie testowe przez kanał w zapisanej postaci, więc najpierw zapisz zmiany. Działa też na kanale,
+który jest wyłączony. Dla kanału pocztowego
+okno pyta o adres docelowy; pozostałe piszą na własnym kanale. Okno pokazuje, czy się udało,
+a jeśli nie, to dlaczego.
diff --git a/i18n/pl/_configure/notification-channels/webhook.md b/i18n/pl/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..99be53f
--- /dev/null
+++ b/i18n/pl/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Kanały powiadomień
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Żądanie JSON do dowolnego endpointu HTTP
+{: .fs-6 .fw-300 }
+
+Kanał webhook wysyła żądanie JSON do dowolnego endpointu HTTP. Jego krok **Endpoint** mówi dokąd i jak, a krok
+**Poświadczenia** zawiera **Token bearer**:
+
+| Pole | Znaczenie |
+|---|---|
+| Url | Adres, na który wysyłane jest żądanie. |
+| Metoda | `POST` (domyślnie) lub `PUT`. |
+| Token bearer | Poświadczenie **api** z [Połączenia > Poświadczenia](../credentials.html), którego hasło jest wysyłane jako `Authorization: Bearer <password>`. Puste: bez tokenu. |
+| Sprawdzaj certyfikat TLS | Domyślnie włączone; wyłącz tylko dla endpointu z certyfikatem samopodpisanym. |
+
+{% raw %}
+Jego krok **Treść** zawiera **Nagłówki**, czyli dodatkowe nagłówki jako obiekt JSON, np. `{ "X-Source": "ansibleforms" }`, oraz
+**Treść**, czyli szablon JSON ciała żądania. Wypełniane są te symbole zastępcze:
+
+| Symbol zastępczy | Wartość |
+|---|---|
+| `{{title}}` | Tytuł powiadomienia |
+| `{{text}}` | Jego tekst |
+| `{{status}}` | Status zadania |
+| `{{event}}` | Zdarzenie zadania |
+| `{{jobId}}` | Id zadania |
+| `{{form}}` | Nazwa formularza |
+| `{{user}}` | Użytkownik, który uruchomił zadanie |
+| `{{link}}` | Link do zadania |
+
+Symbol zastępczy, który jest całym ciągiem JSON (`"{{text}}"`), jest zastępowany wartością jako JSON; wewnątrz dłuższego ciągu jego
+tekst jest escapowany dla JSON. Nieznany symbol zastępczy zostaje tak, jak go zapisano. Pusta treść wysyła ten szablon:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/pl/_configure/production/backups.md b/i18n/pl/_configure/production/backups.md
new file mode 100644
index 0000000..baff537
--- /dev/null
+++ b/i18n/pl/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Kopie zapasowe
+parent: Środowisko produkcyjne
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Kopie zapasowe
+{: .no_toc }
+
+Nocne kopie zapasowe, ich zawartość, przywracanie i co jeszcze warto zachować
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Nocne kopie zapasowe
+
+AnsibleForms tworzy własną kopię zapasową każdej nocy o północy, w strefie czasowej [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(domyślnie UTC). Sterują tym te ustawienia:
+
+| Zmienna | Domyślnie | Znaczenie |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Gdzie zapisywane są kopie zapasowe, każda w folderze ze znacznikiem czasu |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Ile nocnych kopii zapasowych jest przechowywanych, `0` zachowuje wszystkie |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | Polecenie, które zrzuca bazę danych |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | Polecenie, które odtwarza zrzut przy przywracaniu |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Jak długo mogą trwać zrzut i przywracanie |
+
+Użytkownicy z opcją roli `allowBackupOps` mogą też w dowolnej chwili utworzyć kopię zapasową na stronie **Kopie zapasowe**. Retencja usuwa tylko
+nocne kopie zapasowe, a liczą się do niej tylko kopie z użytecznym zrzutem, więc seria nieudanych
+nocy nigdy nie wypycha ostatniej dobrej.
+
+Zanim aktualizacja zmieni bazę danych, worker najpierw tworzy zwykłą kopię zapasową, raz na wydanie, o nazwie *Before the upgrade to
+&lt;version&gt;*. Pojawia się na stronie **Kopie zapasowe** i nocna retencja nigdy jej nie usuwa. Jeśli się nie uda (brak narzędzia do zrzutu,
+brak prawa zapisu w `BACKUP_PATH`), aktualizacja zatrzymuje się i podaje przyczynę, więc aplikacja nigdy nie startuje na częściowo zaktualizowanej bazie danych.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` aktualizuje bez kopii zapasowej.
+
+Polecenia mogą być nakładkami, np. `docker exec <container> mysqldump`, o ile ich pierwsze słowo istnieje lokalnie. Od wersji 7.3.0 uruchamiają się
+bez powłoki: cudzysłowy i `$NAME` ze środowiska polecenia działają, ale `;`, `|`, `&&`, `>` i `<` są odrzucane.
+
+---
+
+## Uprawnienia w bazie danych
+
+Zrzut działa jako [`DB_USER`](../customization/server.html#env_DB_USER) i nie potrzebuje więcej uprawnień niż sama aplikacja:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+Zrzut jest wykonywany z `--no-tablespaces`, więc globalne uprawnienie `PROCESS` nie jest potrzebne, i pomija tabele
+opisujące działające procesy (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). Przywracanie odtwarza go jako ten sam użytkownik.
+Strona **Stan** pokazuje ostrzeżenie przy sprawdzeniu **Użytkownik bazy danych**, gdy użytkownik ma uprawnienia do każdej bazy danych, tak jak `root`.
+
+---
+
+## Co zawiera kopia zapasowa
+
+Każda kopia zapasowa to folder w `BACKUP_PATH`, nazwany od jej znacznika czasu UTC (`YYYYMMDDHHmmss`), zawierający:
+
+| Plik | Zawartość |
+|------|---------|
+| `ansibleforms.sql` | Zrzut bazy danych `AnsibleForms`: użytkownicy, grupy, poświadczenia, zadania, ustawienia, ślad audytu |
+| `config.yaml` | Plik z [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | Folder z [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | Plik środowiska zapisywany przez strony ustawień, bez `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` i `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | Opis kopii zapasowej |
+
+Kopia zapasowa, której zrzut się nie udał, jest z powrotem usuwana i zapisywana w dzienniku jako błąd. Strona **Stan** ostrzega, gdy nie ma żadnej kopii zapasowej,
+gdy najnowsza ma więcej niż dwa dni lub gdy nie ma użytecznego zrzutu, i sprawdza, czy narzędzie do zrzutu istnieje.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) dotyczy natomiast punktów przywracania projektanta (domyślnie 60 dni).
+
+---
+
+## Przywracanie kopii zapasowej
+
+Przywracaj ze [strony **Kopie zapasowe**](../gui/administration.html#restore), z zaznaczonym **Utwórz nową kopię zapasową przed przywróceniem**. Przywracanie:
+
+* odtwarza `ansibleforms.sql`, który zastępuje całą bazę danych; od wersji 7.3.0 kopia zapasowa starszego wydania jest potem ponownie
+  aktualizowana, jak przy starcie nowego wydania, a łatka, która się nie powiedzie, jest zgłaszana
+* kopiuje z powrotem `config.yaml` i zastępuje folder `forms/` folderem z kopii zapasowej: od wersji 7.3.0 formularze, których nie ma w kopii, są
+  usuwane, a nie zachowywane, linki i tryb folderu zostają, a nieudane kopiowanie przywraca folder do poprzedniego stanu
+* **nie** przywraca `managed.env`, bo opisuje on hosta, z którego pochodzi kopia zapasowa. Przycisk **Przywróć środowisko**
+  przywraca go na żądanie, zachowuje bieżący plik jako `.env.bak` i wymaga restartu.
+
+Kopia zapasowa bez użytecznego zrzutu jest odrzucana; po przerwanym przywracaniu usuń przyczynę i przywróć ponownie.
+
+Na nowym hoście ustaw ten sam `ENCRYPTION_SECRET` przed przywróceniem, inaczej zapisanych poświadczeń nie da się odszyfrować.
+
+---
+
+## Co jeszcze zabezpieczyć
+
+Nocna kopia zapasowa obejmuje bazę danych, konfigurację i formularze, ale nic więcej z folderu trwałego:
+
+* **`ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET`** : celowo nigdy nie trafiają do kopii zapasowej. Trzymaj je w swoim menedżerze sekretów;
+  bez sekretu szyfrowania zrzut bazy danych jest bezużyteczny dla poświadczeń.
+* **same kopie zapasowe** : leżą na tym samym wolumenie co instancja. Kopiuj `BACKUP_PATH` na inny host.
+* **reszta folderu trwałego** : playbooki, przesłane pliki, pliki zmiennych, sklonowane repozytoria, certyfikaty i dzienniki.
+  W projekcie docker-compose zabezpieczaj cały folder `data/`, który zawiera też klucz SSH, własne
+  funkcje oraz role i kolekcje Ansible.
+
+Treści pochodzące z gita (repozytoria, formularze w repozytorium) można sklonować ponownie, więc ich kopia zapasowa ma mniejsze znaczenie.
diff --git a/i18n/pl/_configure/production/index.md b/i18n/pl/_configure/production/index.md
new file mode 100644
index 0000000..be2e764
--- /dev/null
+++ b/i18n/pl/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Środowisko produkcyjne
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# Środowisko produkcyjne
+{: .no_toc }
+
+Publikuj, zabezpieczaj kopiami i monitoruj instancję, od której zależą ludzie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Zanim uruchomisz produkcję
+
+Wartości domyślne pozwalają szybko uruchomić instancję, ale kilka z nich służy tylko do pierwszego zapoznania się. AnsibleForms
+zapisuje przy starcie ostrzeżenie `[SECURITY]`, gdy `ENCRYPTION_SECRET` lub `ACCESS_TOKEN_SECRET` nie jest ustawione, a
+strona **Stan** raportuje kopie zapasowe, ustawienia retencji i sanitizer wyrażeń.
+
+---
+
+## Lista kontrolna dla produkcji
+
+Przejdź przez te punkty raz, zanim użytkownicy zaczną polegać na instancji, i ponownie po dużej aktualizacji:
+
+| Punkt | Co zrobić | Szczegóły |
+|------|------------|---------|
+| Hasło admina | Zmień hasło lokalnego konta admina | [Utwardzanie](../security/hardening.html#the-admin-account) |
+| Sekret szyfrowania | Ustaw [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET), zanim zapiszesz jakiekolwiek poświadczenie | [Sekrety i szyfrowanie](../security/secrets.html#the-two-master-secrets) |
+| Sekret tokenów | Ustaw [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET), żeby sesje przetrwały restart | [Sekrety i szyfrowanie](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Terminuj TLS własnym certyfikatem, nie przykładowym | [HTTPS](../security/https.html) |
+| Reverse proxy | Opublikuj instancję za proxy, opcjonalnie pod [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse proxy](reverse-proxy.html) |
+| Endpoint schematu | Ustaw [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) na `0`, gdy schemat już istnieje | [Utwardzanie](../security/hardening.html#the-database) |
+| Wywołania wychodzące | Ogranicz wyrażenia REST przez [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Utwardzanie](../security/hardening.html#expressions-and-outbound-calls) |
+| Funkcje opcjonalne | Zostaw MCP i asystenta czatu wyłączone, jeśli z nich nie korzystasz | [Utwardzanie](../security/hardening.html#optional-features) |
+| Kopie zapasowe | Sprawdź, czy nocna kopia zapasowa działa, i kopiuj ją poza hosta | [Kopie zapasowe](backups.html) |
+| Retencja | Zdecyduj, jak długo przechowywać zadania i wpisy audytu | [Dzienniki](logs.html#retention) |
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę; zabezpieczanie instancji opisuje sekcja [Bezpieczeństwo](../security/):
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Reverse proxy](reverse-proxy.html) | Publikowanie AnsibleForms za Nginx, Traefik lub Apache, w katalogu głównym lub pod podścieżką |
+| [Kopie zapasowe](backups.html) | Nocne kopie zapasowe, ich zawartość, przywracanie i co jeszcze warto zachować |
+| [Dzienniki](logs.html) | Pliki dziennika, syslog, ślad audytu oraz retencja zadań i wpisów audytu |
+| [Skalowanie](scaling.html) | Kilka węzłów aplikacji z workerem; RTE ma własną sekcję, [Środowiska uruchomieniowe](../rte/) |
+| [Monitorowanie](monitoring.html) | Sondy stanu, metryki Prometheus i strona Stan |
diff --git a/i18n/pl/_configure/production/logs.md b/i18n/pl/_configure/production/logs.md
new file mode 100644
index 0000000..d45edc8
--- /dev/null
+++ b/i18n/pl/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Dzienniki
+parent: Środowisko produkcyjne
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Dzienniki
+{: .no_toc }
+
+Pliki dziennika, syslog, ślad audytu oraz jak długo przechowywane są zadania i wpisy audytu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pliki dziennika
+
+AnsibleForms zapisuje dwa dzienniki rotowane codziennie w [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), kompresuje starsze dni i przechowuje je przez [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+(domyślnie 30, `0` zachowuje każdy plik; zmiana na stronie ustawień działa od razu):
+
+* `ansibleforms.<date>.log` : wszystko na poziomie [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) i wyżej
+* `ansibleforms.errors.<date>.log` : tylko błędy
+
+Konsola, czytana przez `docker logs` lub `kubectl logs`, ma własny poziom,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Oba domyślnie mają `notice`, co jest właściwe dla
+produkcji; używaj `info` lub `debug` tylko podczas diagnozowania problemów i zostaw
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) wyłączone. Poziomy można zmieniać na
+stronach ustawień bez restartu, a strona **Dziennik serwera** pokazuje dziennik użytkownikom z opcją `showLogs`.
+
+---
+
+## Wiersze JSON
+
+Dla kolektora logów takiego jak Loki, ELK czy Splunk ustaw [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) na `json`. Każdy
+wiersz, na konsoli i w plikach, jest wtedy jednym obiektem JSON zamiast `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Pole | Zawartość |
+|-------|---------|
+| `time` | Czas, w ISO 8601 UTC |
+| `level` | Poziom logowania |
+| `message` | Komunikat |
+| `requestId` | Żądanie, do którego należy wiersz, gdy został zapisany podczas jego obsługi |
+| `role` | Rola procesu, [`AF_ROLE`](scaling.html), lub `all`, gdy nie jest ustawiona |
+| `host` | Nazwa hosta maszyny lub kontenera, w którym działa proces |
+
+Każde żądanie dostaje identyfikator: nagłówek `X-Request-Id` wysłany przez reverse proxy albo nowy. Jest zwracany w nagłówku
+`X-Request-Id` odpowiedzi i niesiony przez każdy wiersz zapisany podczas obsługi żądania (jako `[req <id>]` w wierszach tekstowych),
+więc żądanie można prześledzić w dzienniku i dopasować do dziennika proxy. Zmiana na stronie ustawień działa od razu.
+
+---
+
+## Syslog
+
+Serwerami syslog zarządza się w **Ustawienia > Połączenia > Syslog**, dzięki czemu serwer syslog lub SIEM dostaje dziennik na bieżąco.
+Możesz dodać kilka serwerów, a każdy ma własne ustawienia:
+
+| Ustawienie | Co robi |
+|---------|--------------|
+| Włączony | Cokolwiek dostają tylko włączone serwery, więc serwer można wstrzymać bez usuwania; przełączają go też **Włącz** i **Wyłącz** w menu wiersza |
+| Protokół | `udp4` (domyślnie), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` lub `unix-connect` |
+| Host i port | Serwer docelowy, domyślnie port `514`; protokół `unix` przyjmuje zamiast tego ścieżkę gniazda |
+| Otrzymuje | Dziennik serwera, wpisy audytu lub oba (domyślnie dla nowego serwera) |
+| Poziom | Najniższy poziom dziennika serwera, który otrzymuje, domyślnie `info`; wpisy audytu są wysyłane zawsze |
+| Typ | `BSD` (RFC 3164, domyślnie) lub `RFC 5424` |
+
+Zmiana działa na każdym węźle bez restartu, a strona serwera ma przycisk, który wysyła do niego komunikat testowy.
+Nieosiągalny serwer nigdy nie zatrzymuje aplikacji: błąd jest zapisywany na konsoli.
+
+Od wersji 7.3.0 serwery syslog wymagają pełnych uprawnień do ustawień, czyli opcji roli [`showSettings`](../config/roles.html#role-options):
+sam dostęp do ustawień połączeń nie wystarcza, bo serwer syslog otrzymuje dziennik serwera i wpisy audytu.
+
+Zmienne `LOG_SYSLOG_*` z wcześniejszych wersji są przestarzałe od wersji 7. Pierwsze uruchomienie, które znajdzie ustawioną
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST), importuje je jednorazowo jako serwer `syslog`,
+który otrzymuje dziennik serwera jak wcześniej, i od tej pory je ignoruje. Po tym pierwszym uruchomieniu usuń je ze środowiska
+i zarządzaj serwerem na stronie ustawień.
+
+---
+
+## Ślad audytu
+
+Strona **Dziennik audytu** (w **Ustawienia > Dzienniki**) zapisuje, kto co zmienił, na co pliki dziennika słabo odpowiadają.
+Zapisuje:
+
+* każdą zmianę wykonaną przez API (`POST`, `PUT`, `PATCH`, `DELETE`), łącznie z próbami odrzuconymi kodem 401 lub 403
+* logowania, z nazwą użytkownika, której próbowano
+* zdarzenia samej aplikacji, takie jak nocne kopie zapasowe, usunięte kopie zapasowe, wyczyszczone zadania i zastosowania config seed
+
+Każdy wpis ma czas, wykonawcę (użytkownika lub samą aplikację dla jej własnych zadań), adres IP klienta,
+akcję, jej cel i wynik: `success`, `failure` lub `denied`. Strona filtruje po wykonawcy, akcji i
+wyniku, a otworzyć ją mogą użytkownicy z opcją roli `showSettings`.
+
+Adres IP to ten, który widzi AnsibleForms, czyli adres proxy, gdy aplikacja działa za proxy. Ustaw
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) na liczbę lub adresy swoich proxy, a AnsibleForms
+zapisze zamiast tego adres klienta, który proxy podaje w `X-Forwarded-For`; zobacz [Reverse proxy](reverse-proxy.html).
+
+Aby przechowywać ślad audytu poza instancją, dla SIEM, dodaj serwer syslog, który otrzymuje wpisy audytu (zobacz
+[Syslog](#syslog)). Każdy wpis jest wysyłany na bieżąco, jako jeden wiersz `audit {...}` z wpisem w JSON, niezależnie od
+poziomu serwera. Kopii w syslogu nie usuwa poniższa retencja ani nie zastępuje jej przywrócenie bazy danych.
+
+---
+
+## Retencja
+
+Dwa codzienne zadania z ustawieniem chronią bazę danych przed nieograniczonym rozrostem:
+
+| Zmienna | Domyślnie | Uruchamia się o | Usuwa |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | Wpisy audytu starsze niż ta wartość |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (zachowaj wszystko) | 2:30 | Zakończone zadania starsze niż ta wartość, z ich wynikiem |
+
+`0` zachowuje wszystko w obu przypadkach. Dwa kolejne codzienne zadania nie mają ustawienia: o 3:00 usuwane są zapisane tokeny odświeżania starsze niż 30 dni i
+wygasłe unieważnienia tokenów, a o 4:00 [zapisane zadania](../jobs/stored-jobs.html), których termin ważności minął.
+Godziny są w strefie czasowej [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), a uruchamia je worker.
+
+Wynik zadań to zwykle najszybciej rosnąca tabela: strona **Stan** raportuje jej rozmiar
+i ostrzega, gdy przekroczy 1 GB bez ustawionej retencji. Działające zadania i zadania czekające na zatwierdzenie nigdy nie są usuwane.
+Wybierz retencję zadań zgodną z wymaganiami audytu, a ślad audytu przechowuj co najmniej tak samo długo.
diff --git a/i18n/pl/_configure/production/monitoring.md b/i18n/pl/_configure/production/monitoring.md
new file mode 100644
index 0000000..44038e4
--- /dev/null
+++ b/i18n/pl/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Monitorowanie
+parent: Środowisko produkcyjne
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Monitorowanie
+{: .no_toc }
+
+Sondy stanu dla load balancera lub Kubernetes, metryki Prometheus i strona Stan
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sondy stanu
+
+Dwa endpointy mówią load balancerowi, healthcheckowi kontenera lub Kubernetes, czy proces może przyjmować ruch.
+Żaden nie wymaga logowania i żaden nie zwraca niczego o konfiguracji:
+
+| Endpoint | Odpowiada | Do czego go używać |
+|----------|---------|------------|
+| `/api/v2/live` | `200` z `{"status":"live"}`, dopóki proces działa | Sonda liveness: zrestartuj proces, gdy przestanie odpowiadać |
+| `/api/v2/ready` | `200` z `{"status":"ready"}` lub `503` z `{"status":"not ready","reason":"..."}` | Sonda readiness: kieruj ruch tylko do gotowych procesów |
+
+Proces jest gotowy, gdy spełnione są wszystkie te warunki:
+
+* nie jest w trakcie zamykania (`stopping`)
+* baza danych odpowiada (`database unreachable`)
+* schemat istnieje (`schema not provisioned`) i jest kompletny, z każdą tabelą, kolumną i indeksem tej wersji
+  (`schema not upgraded`); to ostatnie sprawdzenie jest buforowane przez 30 sekund, więc sonda co kilka sekund pozostaje tania
+
+Przy [`BASE_URL`](../customization/server.html#env_BASE_URL) ścieżki zaczynają się od niego, np.
+`/ansibleforms/api/v2/ready`. Środowisko uruchomieniowe (RTE) odpowiada na te same sondy pod `/live` i `/ready`, bez
+sprawdzania kompletności schematu; nie jest gotowe, gdy przy zamykaniu kończy swoje zadania, więc nie trafia do niego żadne nowe zadanie. RTE w trybie wychodzącym
+też nie jest gotowe (`not connected to the app`), dopóki jego gniazdo do aplikacji nie jest otwarte.
+Proces uruchomiony z `AF_ROLE=worker` nie ma interfejsu WWW: odpowiada tylko na `/api/v2/version` i `/health` dla
+healthchecku swojego kontenera. Role opisuje strona [Skalowanie](scaling.html).
+
+---
+
+## Metryki Prometheus
+
+Ustaw [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) na długi losowy ciąg, aby udostępniać metryki Prometheus.
+Proces obsługujący aplikację WWW odpowiada pod `/api/v2/metrics`, RTE pod `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Bez `METRICS_TOKEN` endpointy odpowiadają `404`, jakby nie istniały, a żądanie bez właściwego nagłówka
+`Authorization: Bearer <token>` dostaje `401`. Każdy proces raportuje własne wartości, więc zbieraj metryki z każdego:
+
+| Metryka | Co mierzy |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | Proces: CPU, pamięć, opóźnienie pętli zdarzeń, odśmiecanie pamięci |
+| `af_http_requests_total{route,method,status}` | Obsłużone żądania |
+| `af_http_request_duration_seconds{route}` | Jak długo trwały |
+| `af_jobs{status}` | Zadania, które teraz działają (`running`) lub czekają na zatwierdzenie (`approve`) |
+| `af_jobs_ended_24h{status}` | Zadania zakończone w ciągu ostatnich 24 godzin, według statusu |
+| `af_nodes{role,alive}` | Procesy zarejestrowane w bazie danych, według roli, żywe lub nie |
+| `af_login_failures_total`, `af_login_lockouts_total` | Nieudane logowania i blokady kont |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Na RTE: playbooki, które teraz uruchamia, i ile może uruchamiać naraz |
+| `af_rte_socket_connected` | Na RTE w trybie gniazda: `1`, gdy jego gniazdo do aplikacji jest otwarte, `0`, gdy nie |
+
+Wartości zadań i węzłów są odczytywane z bazy danych przy każdym zbieraniu. Gdy baza danych nie odpowiada, są one pomijane,
+a zbieranie i tak się udaje z pozostałymi metrykami.
+
+---
+
+## Strona Stan
+
+Strona **Stan**, w **Ustawienia > System**, pokazuje użytkownikom z opcją roli `showSettings`, w jakiej kondycji jest instancja.
+Tylko odczytuje, więc jej odświeżenie nigdy nie wysyła poczty ani nie uruchamia zadania. Ma dwie karty, a liczba problemów jest widoczna na etykiecie karty **Testy**.
+
+### Testy
+
+Każdy test jest zielony (w porządku), bursztynowy (wymaga uwagi) lub czerwony (problem), ze szczegółami po rozwinięciu wiersza:
+
+| Test | Co sprawdza |
+|-------|------------------|
+| Połączenie z bazą danych | Baza danych odpowiada |
+| Użytkownik bazy danych | Bursztynowy, gdy użytkownik ma uprawnienia do każdej bazy danych, jak `root`, zamiast tylko do `AnsibleForms.*` |
+| Schemat bazy danych | Każda tabela, kolumna i indeks tej wersji istnieje, a jeśli nie, która łatka się nie powiodła |
+| Harmonogram zadań | Worker uruchamia zadania systemowe i żadne z nich nie przestało być planowane |
+| Węzły | Procesy w bazie danych, bursztynowy, gdy działają w różnych wersjach |
+| Zadania | Działające zadania i zadania czekające na zatwierdzenie, bursztynowy, gdy zadanie działa dłużej niż 24 godziny |
+| Narzędzia kopii zapasowych | Polecenie zrzutu z [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) istnieje, i jego wersja |
+| Ostatnia kopia zapasowa | Bursztynowy, gdy nie ma żadnej lub najnowsza ma więcej niż dwa dni, czerwony, gdy nie ma użytecznego zrzutu |
+| Blokada projektanta | Kto trzyma blokadę projektanta, bursztynowy, gdy jest trzymana dłużej niż 8 godzin |
+| Repozytoria | Czerwony, gdy repozytorium się nie powiodło lub nie ma kopii roboczej na dysku |
+| Config seed | Plik [config seed](../seed/) jest czytelny i się parsuje, a jego ostatnie przeładowanie się udało |
+| Magazyny sekretów | Każdy magazyn sekretów odpowiada, bursztynowy, gdy token HashiCorp Vault wkrótce wygasa |
+| Runnery | Każdy runner odpowiada, bursztynowy, gdy nie ma żadnego lub nie ma domyślnego RTE |
+| Wyrażenia serwera | Bursztynowy, gdy [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) ma wartość `legacy` |
+| Sekrety | Bursztynowy, gdy `ENCRYPTION_SECRET` to publiczna wartość domyślna lub `ACCESS_TOKEN_SECRET` nie jest ustawione |
+| LDAP | Serwer LDAP jest osiągalny, a jego certyfikat TLS jest ważny, bez logowania się do niego |
+| Magazyn zadań | Rozmiar tabel zadań, bursztynowy powyżej 1 GB, gdy nie ustawiono retencji zadań |
+| Foldery z prawem zapisu | Do każdego skonfigurowanego folderu można zapisywać |
+| Miejsce na dysku | Dysk z kopiami zapasowymi, bursztynowy od 85% zajętości i czerwony od 95% |
+
+### Informacje
+
+Fakty o instancji, które nie mają oceny, czyli pierwsze rzeczy, o które pyta wsparcie: wersja AnsibleForms,
+bazowy URL, wersja i host bazy danych, źródło konfiguracji, config seed, ustawienia
+retencji, metody uwierzytelniania, serwer aktywnego [kanału pocztowego](../notification-channels.html), poziom
+i ścieżka dziennika, czas działania, strefa czasowa, wersja Node.js i platforma.
+
+Strona odczytuje `/api/v2/health`, co wymaga zalogowanego użytkownika z `showSettings`. W systemie monitorowania używaj zamiast tego
+powyższych sond i metryk.
diff --git a/i18n/pl/_configure/production/reverse-proxy.md b/i18n/pl/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..d232d04
--- /dev/null
+++ b/i18n/pl/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse proxy
+parent: Środowisko produkcyjne
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse proxy
+{: .no_toc }
+
+Publikuj AnsibleForms za Nginx, Traefik lub Apache, w katalogu głównym lub pod podścieżką
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Kiedy go używać
+
+AnsibleForms udostępnia interfejs, REST API i Swagger na jednym porcie; reverse proxy przed nim pozwala:
+
+* udostępniać go na porcie 443 z certyfikatem zarządzanym przez istniejące narzędzia (ACME, firmowe CA)
+* dzielić jedną nazwę hosta z innymi aplikacjami, publikując AnsibleForms pod podścieżką
+* trzymać port aplikacji i bazę danych poza siecią publiczną
+
+Proxy jest opcjonalne: aplikacja może sama obsługiwać HTTPS, zobacz [HTTPS](../security/https.html).
+
+---
+
+## Ustawienia, które mają znaczenie
+
+Tylko kilka ustawień wpływa na zachowanie AnsibleForms za proxy:
+
+| Ustawienie | Za proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | Port, na który przekazuje proxy, domyślnie `8000`. Projekt docker-compose ustawia go na `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0`, gdy proxy terminuje TLS i łączy się z aplikacją przez sieć prywatną, `1`, aby szyfrować także ten odcinek. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | Podścieżka, np. `/ansibleforms`. Zostaw `/`, gdy aplikacja ma własną nazwę hosta. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Które proxy mogą podawać adres klienta w `X-Forwarded-For`, zwykle `1`. Zobacz [Adresy klientów](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | Największe żądanie JSON, jakie przyjmuje aplikacja, domyślnie 50 MB. Proxy musi dopuszczać co najmniej tyle. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | Największy plik, jaki przyjmuje pole przesyłania formularza, domyślnie 10 GB. Proxy też musi na to pozwalać, inaczej przesyłanie zawiedzie na nim. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | Największy zestaw nagłówków żądania, jaki przyjmuje aplikacja, domyślnie 16 KB, od wersji 7.1.0. Zobacz [Rozmiar nagłówków żądania](#request-header-size). |
+| **Publiczny główny adres URL** | W **System > Ogólne**, na karcie **Serwer**: adres, pod którym wchodzą użytkownicy, łącznie z podścieżką. Z niego budowane są linki w wiadomościach z powiadomieniami, komunikatach kanałów i prośbach o zatwierdzenie. |
+
+Dla Entra ID lub OIDC zarejestruj publiczny adres jako identyfikator URI przekierowania, z podścieżką `BASE_URL`, jeśli jest ustawiona.
+
+---
+
+## Udostępnianie pod podścieżką
+
+`BASE_URL` montuje całą aplikację pod podścieżką; proxy musi przekazywać ścieżkę **bez zmian**.
+Przy `BASE_URL=/ansibleforms`:
+
+* interfejs, `/api/v2/...` i interfejs Swagger są udostępniane pod `/ansibleforms/`
+* `<base href>` interfejsu jest przepisywany przy starcie, więc zasoby i wywołania API rozwiązują się pod podścieżką
+* żądanie `/` lub `/ansibleforms` (bez końcowego ukośnika) jest przekierowywane na `/ansibleforms/`
+
+Zachowaj prefiks: bez `StripPrefix` w Traefik, bez URI w `proxy_pass` w Nginx, bo aplikacja go oczekuje.
+
+Strona **Stan** pokazuje obowiązujący bazowy URL.
+
+---
+
+## Limity czasu, przesyłanie plików i wynik na żywo
+
+Strona zadań i liczniki zadań dowiadują się o zmianach przez jeden długotrwały strumień server-sent events,
+[`/api/v2/events`](../api/events.html), otwarty dla każdej przeglądarki. Strumień wysyła nagłówki, które wyłączają buforowanie w proxy
+(`X-Accel-Buffering: no`), i wiersz keep-alive co 15 sekund, więc typowy 60-sekundowy limit czasu odczytu utrzymuje go otwartym;
+gdy proxy mimo to go zamknie, przeglądarka sama łączy się ponownie. Wynik pod formularzem, tuż po uruchomieniu, jest
+natomiast odczytywany co dwie sekundy. Uruchomienie zadania wraca, gdy tylko zadanie zostanie utworzone, więc długi playbook nie trzyma
+otwartego żądania.
+
+Żądania, które mogą trwać długo, to:
+
+* **tworzenie i przywracanie kopii zapasowych** ze strony **Kopie zapasowe**, które czekają na zakończenie polecenia zrzutu lub przywracania, do
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (domyślnie 3600)
+* **duże przesyłane pliki** przez pole pliku, które przesyłają cały plik w jednym żądaniu
+* **wiadomości czatu**, gdy [asystent czatu](../chat/) jest włączony, które czekają na odpowiedź dostawcy modelu
+
+Proxy często mają limit czasu 60 sekund i ograniczają rozmiar ciała żądania (Nginx domyślnie przyjmuje 1 MB). Zwiększ oba dla
+tras AnsibleForms, jak w poniższych przykładach.
+
+---
+
+## WebSockety runnerów
+
+Od wersji 7.3.0 [runner w trybie wychodzącym](../rte/modes.html#outbound) łączy się z aplikacją i utrzymuje jeden otwarty WebSocket na
+`<BASE_URL>/api/v2/rte/socket`. Proxy musi przekazywać upgrade, inaczej runner nigdy się nie połączy i będzie ciągle próbował:
+
+| Proxy | Czego potrzebuje WebSocket |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` i nagłówków `Upgrade` i `Connection`, których Nginx domyślnie nie przekazuje |
+| Traefik | Niczego: WebSockety przechodzą bez zmian |
+| Apache | `upgrade=websocket` w wierszu `ProxyPass` (2.4.47 i nowsze) lub `mod_proxy_wstunnel` we wcześniejszych wersjach |
+
+Obie strony wysyłają ping co 20 sekund, więc typowy 60-sekundowy limit czasu odczytu utrzymuje bezczynne gniazdo otwarte.
+
+---
+
+## Rozmiar nagłówków żądania
+
+Każde żądanie niesie token logowania w nagłówku `Authorization`, obok ciasteczek i nagłówków dodawanych przez proxy.
+Zarówno proxy, jak i aplikacja ograniczają rozmiar nagłówków żądania i odrzucają żądanie powyżej limitu, zanim
+AnsibleForms je zobaczy, więc nic nie trafia do dziennika serwera. Wartości domyślne:
+
+| Komponent | Limit | Domyślnie | Odrzucane z |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), wszystkie nagłówki razem | 16384 bajty | 431 |
+| Nginx | `large_client_header_buffers`, na pole nagłówka | `4 8k`: 8 KB na pole | 400 |
+| Traefik | `http.maxHeaderBytes` punktu wejścia, wszystkie nagłówki razem | 1 MB | 431 |
+| HAProxy | `tune.bufsize` w sekcji `global`, cały blok nagłówków, minus rezerwa `tune.maxrewrite` (1024 bajty) | 16384 bajty: 15360 bajtów nagłówków | 400 |
+| Apache | `LimitRequestFieldSize`, na pole nagłówka | 8190 bajtów | 400 |
+
+Do wersji 7.0.3 token logowania zawierał wszystkie grupy użytkownika logowania jednokrotnego i mógł przekroczyć te limity, zobacz
+[Puste formularze i zadania po logowaniu jednokrotnym](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+Od wersji 7.1.0 token pozostaje mały, a wartości domyślne wystarczają. Gdy nagłówki powiększa coś innego, np.
+ciasteczka innych aplikacji w tej samej domenie albo bramka logowania jednokrotnego przed aplikacją, zwiększ limity razem:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536`, a przed 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; oba są
+  odczytywane przy starcie, więc po zmianie uruchom aplikację ponownie
+* Nginx: `large_client_header_buffers 4 32k;` w bloku `http` lub `server`
+* HAProxy: `tune.bufsize 65536` w sekcji `global`; każdy strumień dostaje bufor tej wielkości, więc HAProxy zaleca
+  obniżenie globalnego `maxconn` o ten sam współczynnik, a HTTP/2 wymaga co najmniej domyślnych 16384
+* Apache: `LimitRequestFieldSize 32768` w konfiguracji serwera lub w wirtualnym hoście
+
+---
+
+## Adresy klientów
+
+Za proxy każde połączenie pochodzi od proxy. Bez [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY)
+ślad audytu zapisuje adres proxy przy każdej akcji, a
+[limity logowania](../security/hardening.html#sign-in-limits-and-passwords) na adres liczą wszystkich klientów jako jeden adres.
+`TRUST_PROXY` mówi, którym proxy aplikacja może wierzyć, gdy podają klienta w `X-Forwarded-For`:
+
+| Wartość | Adres klienta |
+|-------|----------------|
+| `0` (domyślnie) | Adres połączenia. `X-Forwarded-For` jest ignorowany; puste, `false`, `off` i `no` znaczą to samo. |
+| Liczba, np. `1` | Ufa tylu proxy przed aplikacją: `1` dla pojedynczego reverse proxy, `2` dla load balancera przed ingressem. |
+| Lista, np. `10.0.0.5,172.16.0.0/12` | Ufa proxy pod tymi adresami i w tych zakresach CIDR. Akceptowane są też predefiniowane `loopback`, `linklocal` i `uniquelocal`. |
+| `true` | Ufa każdemu przeskokowi: używany jest skrajnie lewy adres z `X-Forwarded-For`. |
+
+Aplikacja przechodzi `X-Forwarded-For` od prawej, pomija zaufane proxy i bierze pierwszy adres, który
+nie jest jednym z nich. Używaj dokładnej liczby proxy lub ich adresów:
+
+* `X-Forwarded-For` to zwykły nagłówek żądania, który może wysłać każdy klient. Zbyt duża liczba albo `true` pozwala
+  klientowi wybrać adres, który zapisuje ślad audytu. `true` jest bezpieczne tylko wtedy, gdy aplikacja jest osiągalna wyłącznie
+  przez proxy, a serwer zapisuje przy starcie ostrzeżenie `[SECURITY]`, gdy jest ustawione.
+* Proxy musi dodawać adres, z którego otrzymało połączenie, tak jak w poniższych przykładach
+  (`$proxy_add_x_forwarded_for` w Nginx; Traefik i Apache `mod_proxy` dodają go domyślnie).
+* Nieprawidłowa wartość jest odrzucana na stronie ustawień; ustawiona w środowisku jest zapisywana przy starcie jako błąd i
+  żadne proxy nie jest zaufane. Zmiana zapisana na stronie ustawień działa bez restartu.
+
+---
+
+## Przykłady
+
+Każdy przykład publikuje AnsibleForms pod `https://forms.example.com/ansibleforms/`, z TLS terminowanym przez proxy i
+aplikacją działającą z `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` i `TRUST_PROXY=1`:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` nie podaje URI, więc Nginx przekazuje ścieżkę tak, jak przyszła, łącznie z prefiksem. Blok `map` trafia do
+kontekstu `http` (plik w `conf.d/` jest tam włączany) i przekazuje upgrade WebSocket runnerów:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Bez podścieżki użyj `location /` i nie ustawiaj `BASE_URL`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Etykiety na usłudze `app` projektu docker-compose, z Traefik w tej samej sieci Docker. Usługa
+nie publikuje własnego portu, Traefik łączy się z nią przez sieć:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Brak middleware `StripPrefix` jest celowy. Traefik sam ustawia nagłówki `X-Forwarded-*` i nie ogranicza
+rozmiaru ciała żądania, ale sprawdź `respondingTimeouts` punktu wejścia, gdy kopie zapasowe lub przesyłanie plików trwają dłużej niż jego
+limit czasu odczytu. Bez podścieżki zostaw tylko część `Host(...)` reguły.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Wymaga `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl` oraz Apache 2.4.47 lub nowszego dla `upgrade=websocket` runnerów.
+Obie strony `ProxyPass` zawierają prefiks:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Bez podścieżki przekazuj `/` do `http://10.0.0.20:8000/` i nie ustawiaj `BASE_URL`.
+
+</div>
+</div>
+
+Aby szyfrować odcinek między proxy a aplikacją, uruchom aplikację z `HTTPS=1`, skieruj proxy na
+`https://` i daj aplikacji certyfikat, któremu proxy ufa, zobacz [HTTPS](../security/https.html).
diff --git a/i18n/pl/_configure/production/scaling.md b/i18n/pl/_configure/production/scaling.md
new file mode 100644
index 0000000..0b714ea
--- /dev/null
+++ b/i18n/pl/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Skalowanie
+parent: Środowisko produkcyjne
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Skalowanie
+{: .no_toc }
+
+AnsibleForms rozdzielony na kilka węzłów aplikacji i worker, obok jednego lub kilku RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Role
+
+Każdy kontener AnsibleForms uruchamia ten sam kod serwera, a [`AF_ROLE`](../customization/server.html#env_AF_ROLE) decyduje, co robi:
+
+| `AF_ROLE` | Obraz | Uruchamia | Ile |
+|---|---|---|---|
+| `all` (nieustawiona) | `ansibleforms` | Aplikację WWW i worker w jednym procesie: domyślnie | 1 |
+| `app` | `ansibleforms` | Interfejs WWW i API | Ile chcesz, za load balancerem |
+| `worker` | `ansibleforms` | Pracę w tle: schemat bazy danych i jego aktualizacje, config seed, harmonogramy, nocną kopię zapasową, synchronizacje repozytoriów i porządki | Jeden pracuje; kolejne czekają i przejmują pracę |
+| `rte` | `ansibleforms-rte-full` (lub `-rte-core`, `-rte-base`) | Playbooki | Ile chcesz |
+
+Najmniejsza instalacja to jeden kontener bez `AF_ROLE` obok jednego RTE: tak działają [projekt Docker Compose](../installation/docker-compose.html)
+i [chart Helm](../installation/kubernetes.html). Każda inna wartość `AF_ROLE` zatrzymuje proces przy starcie.
+
+---
+
+## RTE
+
+RTE, środowisko uruchomieniowe, które uruchamia playbooki, ma własną sekcję: [Środowiska uruchomieniowe](../rte/). Opisuje, jak RTE
+uruchamia zadanie, [jego obrazy](../rte/images.html), [jak je uruchomić](../rte/run.html), [kilka RTE](../rte/several.html) jako runnery lub
+repliki oraz [RTE w innym centrum danych](../rte/another-datacenter.html).
+
+---
+
+## Kilka węzłów aplikacji
+
+Aby obsłużyć więcej użytkowników albo przetrwać utratę jednego węzła, podziel aplikację na węzły `app` za load balancerem i `worker`.
+
+### Co współdzielą węzły
+{: .no_toc }
+
+Węzły uzgadniają się ze sobą przez bazę danych i współdzielony wolumen:
+
+* **Baza danych** : zadania, blokada workera, blokada projektanta, lista węzłów, dzierżawy runnerów (który węzeł aplikacji trzyma
+  gniazdo każdego RTE) i powiadomienia o zmianach, które utrzymują aktualność pamięci podręcznych każdego węzła. Poświadczenie, runner lub harmonogram edytowany
+  na jednym węźle obowiązuje na wszystkich w ciągu 5 sekund
+* **Wolumen trwały** (`/app/dist/persistent`) : formularze, konfiguracja, repozytoria, przesłane pliki, kopie zapasowe i zarządzany `.env`.
+  Każdy węzeł aplikacji i worker montują ten sam, do odczytu i zapisu
+* **Folder ssh** (`/home/node/.ssh`) : klucz i znane hosty dla gita przez ssh; worker tworzy klucz przy pierwszym starcie
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : taki sam na każdym węźle aplikacji, inaczej token podpisany
+  przez jeden węzeł zostanie odrzucony przez następny. Węzeł aplikacji odmawia startu bez niego
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : taki sam na każdym węźle aplikacji i workerze, inaczej
+  poświadczenia zapisanego przez jeden nie da się odczytać na innym. RTE w trybie gniazda nigdy go nie odczytuje; potrzebuje go tylko przestarzałe RTE w trybie bazy danych,
+  które samo się rejestruje
+
+Daj też każdemu kontenerowi tego samego użytkownika bazy danych: czekający worker może zakończyć sesję martwego tylko wtedy, gdy jest to jego własna sesja.
+
+### Blokada workera
+{: .no_toc }
+
+Naraz pracuje tylko jeden worker. Trzyma blokadę bazy danych `ansibleforms_worker`; gdy się zatrzyma, baza danych zwalnia blokadę, a
+czekający worker przejmuje ją w ciągu 10 sekund. Gdy host workera padnie bez pożegnania, baza danych mogłaby trzymać blokadę godzinami,
+więc czekający worker kończy tę sesję, gdy żaden worker nie zapisał sygnału życia przez dwie minuty, i przejmuje pracę.
+
+Worker, który straci blokadę na rzecz innego, zatrzymuje się, a jego kontener uruchamia się ponownie jako czekający. Worker, którego start się nie powiódł, też się zatrzymuje,
+więc nigdy nie trzyma blokady, nic nie robiąc. Galera i replikacja grupowa nie współdzielą blokady między węzłami bazy danych: skieruj każdy
+worker na ten sam węzeł bazy danych.
+
+### Zadania i węzły
+{: .no_toc }
+
+Każdy kontener nazywa się `<role>-<hostname>-<port>`, bez żadnych ustawień, a strona **Stan** wyświetla je wszystkie z ich rolą
+i wersją, informacją, który jest workerem, oraz ostrzeżeniem, gdy działają w różnych wersjach.
+
+Zadanie działające na RTE należy do tego RTE i trwa dalej, gdy węzeł aplikacji, który je uruchomił, zniknie. Każde inne zadanie (zadanie szablonu
+na AWX lub innym runnerze, zadanie workflow lub kroki przestarzałego formularza wieloetapowego) należy do węzła aplikacji, który je uruchomił. Kontener, który się restartuje, kończy własne niezakończone zadania, a
+worker kończy zadania kontenera, który przestał odpowiadać przez dwie minuty, np. zastąpionego poda.
+
+`SIGHUP` wysłany do dowolnego węzła ponownie stosuje [config seed](../seed/): węzeł aplikacji prosi o to worker.
+
+### Aktualizacja
+{: .no_toc }
+
+Aktualizuj **najpierw worker**, potem węzły aplikacji. Worker łata schemat, a węzeł aplikacji nowej wersji czeka, aż
+schemat zostanie załatany, i zapisuje w dzienniku, na co czeka. Węzły aplikacji zaktualizowane jako pierwsze pozostają niegotowe, dopóki worker ich nie dogoni, a stare nadal
+obsługują ruch. RTE mogą dołączyć w dowolnym momencie, o ile mówią tym samym kontraktem.
+
+### Ograniczenia
+{: .no_toc }
+
+Kilka rzeczy pozostaje przy jednym węźle:
+
+* **Asystent czatu** trzyma swoje rozmowy w pamięci jednego węzła aplikacji: użyj sticky sessions na load balancerze (nginx
+  `ip_hash`) albo jednego węzła aplikacji
+* **Dzienniki** zostają w każdym kontenerze. Ustaw [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) poza współdzielonym wolumenem, bo kilka
+  procesów rotujących jeden plik gubi wiersze. Przeglądarka dziennika pokazuje dziennik węzła, który odpowiada, więc zbieraj dzienniki centralnie
+* **Ustawienia** zmienione na stronach ustawień są zapisywane w zarządzanym `.env` na współdzielonym wolumenie i obowiązują na każdym węźle; te,
+  które wymagają restartu, wymagają go na każdym węźle
+
+---
+
+## Przykładowy układ
+
+Repozytorium aplikacji ma kompletny punkt wyjścia w [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Usługa | Obraz | Rola |
+|---|---|---|
+| `db` | `mariadb:11` | Baza danych, z użytkownikiem, który ma uprawnienia tylko do schematu `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, za load balancerem |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: drugi czeka i przejmuje pracę |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Uruchamia playbooki z `RTE_MODE=inbound` i `RTE_FILES=local`: aplikacja się z nim łączy |
+| `lb` | `nginx:stable` | Terminuje HTTPS na porcie 8443 i rozkłada przeglądarki na węzły aplikacji przez `ip_hash` |
+
+Runner `rte` tego RTE i poświadczenie, którym się loguje (jego adres `http://rte:8000` i `RTE_TOKEN`), są zadeklarowane w
+[config seed](../seed/) `seed.yaml`, który worker stosuje przy każdym starcie; RTE nie ustawia `RTE_URL` i nie jest publikowane na hoście.
+
+Węzły aplikacji i workery współdzielą jeden `.env`, z użytkownikiem bazy danych, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` za load balancerem i `LOG_PATH` poza współdzielonym wolumenem. RTE nie ma `env_file`: dostaje
+tylko `RTE_TOKEN` z `compose.yaml`, więc nie zna hasła do bazy danych. Węzły aplikacji, workery i RTE montują te same
+wolumeny trwały i ssh:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/pl/_configure/rte/another-datacenter.md b/i18n/pl/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..8fd460d
--- /dev/null
+++ b/i18n/pl/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Inne centrum danych
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# RTE w innym centrum danych
+{: .no_toc }
+
+Od pustego hosta w drugim centrum danych do RTE w trybie wychodzącym, które uruchamia swój pierwszy playbook
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Dla administratorów: gdy do zarządzanych hostów drugiego centrum danych trzeba docierać z RTE w tym centrum danych, a nie z pierwszego.
+
+{: .note }
+> **Prosta droga.** [Instalator](../installation/installer.html#a-runner) wykonuje wszystkie poniższe kroki na hoście RTE jednym poleceniem:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, z `--join afj_...`, żeby od razu go zatwierdzić.
+> Ten runbook robi to samo ręcznie, z Docker lub Podman, żeby można było zobaczyć i dostosować każdą część.
+
+---
+
+## Co otrzymasz na końcu
+
+Aplikacja, jej worker i jej baza danych zostają tam, gdzie są, w centrum danych 1. Centrum danych 2 dostaje host, na którym działa jeden kontener RTE w
+trybie wychodzącym ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), zobacz [Tryby](modes.html#outbound)): łączy się z aplikacją przez
+HTTPS i utrzymuje jeden otwarty WebSocket, dołącza jako osobny runner i uruchamia playbooki formularzy, które go wskazują, na zarządzanych
+hostach centrum danych 2.
+
+| Gdzie | Co tam działa | Z czym się komunikuje |
+|---|---|---|
+| Centrum danych 1 | Węzły aplikacji, worker, baza danych (jak dziś) | Nic nowego: przyjmuje gniazdo RTE pod swoim zwykłym adresem HTTPS |
+| Centrum danych 2, host RTE | Docker lub Podman i kontener RTE | Z aplikacją pod `APP_URL` przez HTTPS i z zarządzanymi hostami centrum danych 2 |
+
+RTE nie ma poświadczeń do bazy danych ani `ENCRYPTION_SECRET`, tylko własny token. Nic się z nim nie łączy, więc nie potrzebuje otwartego
+portu, nazwy DNS ani certyfikatu. Aplikacja wysyła playbooki i inwentarze z każdym zadaniem (`RTE_FILES=transfer`,
+domyślnie), więc RTE nie potrzebuje ich kopii ani współdzielonego dysku.
+
+Każde poniższe polecenie uruchamiasz w terminalu na hoście RTE, jako użytkownik z `sudo`, chyba że napisano inaczej. Zajmuje to około 20 minut,
+głównie na czekanie na obraz.
+
+---
+
+## 0. Zanim zaczniesz
+
+Zbierz te informacje:
+
+| Co | Skąd pochodzi |
+|---|---|
+| Adres aplikacji | `APP_URL`: adres, który ludzie otwierają w przeglądarce, np. `https://forms.example.com`, ze ścieżką bazową, jeśli ją ma |
+| Certyfikat aplikacji | Podpisany przez publiczne CA, prywatne CA (potrzebujesz jego certyfikatu, krok 6) lub samopodpisany |
+| Proxy | `HTTPS_PROXY`, którego to centrum danych używa, żeby dotrzeć do centrum danych 1, jeśli jest |
+| Nazwa RTE | Nazwa jego runnera w **Połączenia > Runnery**, którą formularze wskazują przez `runner:`, np. `rte-dc2`: litery, cyfry i `_ . : @ -` |
+| Token dołączenia | Opcjonalnie: [token dołączenia](../runners/registration.html#join-tokens) (`afj_...`) zatwierdza RTE od razu. Bez niego zatwierdza je admin (krok 8) |
+| Klucz ssh | Klucz prywatny, którym playbooki docierają do zarządzanych hostów, albo uprawnienie do utworzenia go |
+
+Aplikacja musi działać w wersji 7.3.0 lub nowszej. Aby utworzyć token dołączenia dla tego jednego RTE, admin raz wywołuje API (zobacz
+[Tokeny dołączenia](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Przygotuj host
+
+RTE to kontener, więc host potrzebuje silnika kontenerów i niczego więcej: Node.js, python i ansible są w obrazie.
+
+| Potrzeba | Dlaczego |
+|---|---|
+| Linux na **x86_64** (amd64) | Obrazy RTE są publikowane tylko dla amd64 |
+| 2 CPU i 4 GB pamięci lub więcej | Jedno RTE uruchamia naraz do [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooków (10), każdy z jego forkami: dobierz rozmiar pod nie |
+| 20 GB wolnego miejsca na dysku | Obraz `-rte-full` ma około 3,3 GB, do tego obraz w trakcie aktualizacji, pliki zadań wysyłane przez aplikację i pliki tymczasowe zadań |
+| Docker lub Podman z podman-compose | Do pobrania i uruchomienia obrazu |
+| Czas ustawiany przez NTP | Czasy zadań są porównywane z czasem aplikacji |
+
+**Docker**, na Ubuntu lub Debian (inne dystrybucje: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, na RHEL, Rocky lub Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Z Podman pisz `podman` zamiast `docker` i `podman-compose` zamiast `docker compose` w każdym poniższym poleceniu.
+
+---
+
+## 2. Sieć i zapora
+
+RTE samo otwiera każde połączenie. Nic nie dociera do niego z zewnątrz:
+
+| Skąd | Dokąd | Port | Dlaczego |
+|---|---|---|---|
+| Host RTE | Aplikacja, pod `APP_URL` (przez `HTTPS_PROXY`, jeśli ustawione) | Port aplikacji, `443` za większością proxy | Gniazdo, którym przechodzą zadania, ich pliki i ich wynik |
+| Host RTE | Zarządzane hosty centrum danych 2 | ssh (`22`), WinRM, ich API | Playbooki działają stąd |
+| Host RTE | `ghcr.io` | `443` | Do pobrania obrazu, chyba że pochodzi z własnego rejestru lub z pliku (krok 4) |
+
+Nie otwieraj żadnego portu przychodzącego dla RTE. Jego `PORT` (`8000`) udostępnia tylko `/live`, `/ready` i `/metrics`, dla sond na tym hoście.
+
+RTE łączy się z `APP_URL` z dopisanym `/api/v2/rte/socket`, jako WebSocket. Reverse proxy przed aplikacją musi przekazywać upgrade
+dla tej ścieżki (zobacz [WebSockety runnerów](../production/reverse-proxy.html#runner-websockets)). Sprawdź stąd, czy aplikacja odpowiada:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Foldery
+
+Wszystko znajduje się w `/opt/af-rte`. RTE działa jako użytkownik `node` (uid 1000), więc jego dane należą do tego uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Folder | W kontenerze | Zawiera |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | Spool (`rte-spool`: wynik i zakończenie każdego zadania, dopóki aplikacja ich nie zapisze), pliki zadań wysłane przez aplikację (`rte-files`), prywatne CA, biblioteki pythona instalowane przez playbook |
+| `data/ssh/` | `/home/node/.ssh` | Klucz ssh i `known_hosts` playbooków |
+| `data/ansible/` | `/etc/ansible/...` | `ansible.cfg`, własne role i kolekcje, montowane zamiast wbudowanych |
+
+Trzymaj `data/` na hoście: zrestartowane RTE nadal wysyła to, czego aplikacja nie zapisała, i zachowuje swoją pamięć podręczną plików zadań.
+
+**Klucz ssh.** Skopiuj klucz, którego playbooki używają w centrum danych 1, albo utwórz nowy dla tego centrum danych i przekaż jego publiczną część zarządzanym hostom:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Następnie przekaż wszystko uid 1000, z kluczem czytelnym tylko dla właściciela:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. Obraz
+
+Wybierz jedną z dwóch opcji.
+
+### Opcja A: oficjalny obraz
+{: .no_toc }
+
+Publikowane obrazy są w GitHub Container Registry, publiczne, bez logowania (trzy warstwy opisuje strona [Obrazy](images.html)).
+Weź tę samą warstwę co w centrum danych 1. `:7` podąża za najnowszym wydaniem 7, tak jak `:7` aplikacji:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Host bez dostępu do internetu dostaje obraz z takiego, który go ma:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Albo wypchnij go raz do własnego rejestru (`docker tag` i `docker push`) i używaj tej nazwy w kolejnych krokach.
+
+### Opcja B: własny obraz
+{: .no_toc }
+
+Gdy playbooki centrum danych 2 potrzebują kolekcji lub bibliotek pythona, których brakuje w oficjalnym obrazie (np. VMware dla vCenter
+tego centrum danych), buduj na `ansibleforms-rte-core`:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Przebudowuj go przy każdym nowym wydaniu aplikacji (zobacz [Zbuduj własne RTE](images.html#build-your-own-rte)). Przy kilku hostach RTE zbuduj
+raz i wypchnij do własnego rejestru. Offline użyj `docker save` i `docker load` dla zbudowanego obrazu, jak w opcji A.
+
+---
+
+## 5. Ustawienia
+
+Nowy, własny [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), co najmniej 16 znaków. To hasło tego RTE: aplikacja
+przechowuje je w poświadczeniu RTE runnera i pieczętuje nim sekrety każdego zadania.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Zmienna | Znaczenie |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: RTE łączy się z aplikacją. Bez niej RTE startuje w przestarzałym trybie bazy danych |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Adres aplikacji, `http://` lub `https://`, ze ścieżką bazową, jeśli jest |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Nazwa jego runnera. Nieustawiona: jego id węzła, `rte-<hostname>-<port>`, które zmienia się z kontenerem |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Jego własny token, co najmniej 16 znaków. Zachowaj go: od tej pory runner loguje się nim |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcjonalnie: token dołączenia, używany tylko wtedy, gdy jego runner jeszcze nie istnieje lub czeka na zatwierdzenie |
+
+Dodaj te zmienne, gdy wymaga tego sieć:
+
+| Zmienna | Kiedy |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | RTE dociera do aplikacji przez proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Z hostem wymienionym w `NO_PROXY` (oddzielane przecinkami, `.example.com` dla domeny) łączy się bezpośrednio |
+| `NODE_EXTRA_CA_CERTS` | Certyfikat aplikacji pochodzi z prywatnego CA: umieść certyfikat CA w `/opt/af-rte/data/certificates/ca.pem` i ustaw `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` akceptuje każdy certyfikat aplikacji, także samopodpisany. Tylko wewnątrz jednej zaufanej sieci: lepiej użyj `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (domyślnie) dostaje playbooki i inwentarze z każdym zadaniem. Zostaw tak, chyba że sam montujesz je na RTE (`local`) |
+
+Pozostałe ustawienia odczytywane przez RTE opisuje strona [Uruchamianie RTE](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` i
+`RTE_DRAIN_SECONDS` można też ustawić później na jego stronie runnera, która wygrywa ze zmienną (zobacz
+[Ustawienia RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Uruchom je
+
+Plik compose trzyma całą definicję w jednym miejscu, obok ustawień. W `image:` wpisz obraz z kroku 4:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+Docker uruchamia go ponownie po restarcie hosta (`unless-stopped`). Podman nie ma demona, który by to robił: włącz `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`) albo uruchom kontener jako usługę systemd z plikiem Quadlet. Na hoście z SELinux
+w trybie enforcing dodaj `:Z` do każdego wolumenu (`./data:/app/dist/persistent:Z`).
+
+Bez compose ten sam kontener jednym poleceniem:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Sprawdź je na hoście
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+Dziennik pokazuje, jak RTE startuje, łączy się z aplikacją i nawiązuje połączenie:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Bez tokenu dołączenia jeszcze jeden wiersz mówi, że czeka:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Zanotuj odcisk.
+
+`/ready` odpowiada `503` z `not connected to the app`, dopóki gniazdo nie jest otwarte. Healthcheck mówi tylko, że proces nasłuchuje.
+
+---
+
+## 8. Zatwierdź je
+
+Bez tokenu dołączenia RTE poprosiło o dołączenie: **Połączenia > Runnery** pokazuje nad listą pomarańczowe powiadomienie,
+**1 Runner czeka na zatwierdzenie**. Otwórz je, sprawdź, czy **Odcisk** jest tym z dziennika RTE, a **Tryb** mówi
+Wychodzący, a potem **Zatwierdź** (zobacz [Zatwierdzanie RTE](../runners/registration.html#approving-an-rte)). Zatwierdza tylko admin. Prośba,
+której nikt nie obsłuży w ciągu 24 godzin, jest usuwana, a RTE prosi ponownie przy następnym połączeniu z aplikacją.
+
+Z tokenem dołączenia runner jest zatwierdzany od razu, a jego opis wskazuje token dołączenia. W obu przypadkach aplikacja przechowuje token RTE
+w nowym poświadczeniu RTE, `rte-dc2-rte`, a RTE od tej pory loguje się własnym `RTE_TOKEN`: `RTE_JOIN_TOKEN` nie jest już
+używany i możesz go usunąć z `rte.env`.
+
+---
+
+## 9. Sprawdź je w AnsibleForms
+
+1. **Połączenia > Runnery** wyświetla runner `rte-dc2`, typ RTE. Włącz **Kolumny > Połączenie**, aby zobaczyć na liście **Połączony**
+2. Otwórz go. Jego karta **RTE** pokazuje **Tryb** Wychodzący i plakietkę **Połączenie** z **Połączony**; po najechaniu pokazuje węzeł aplikacji, który
+   trzyma gniazdo, wydanie RTE i ile jego zadań działa
+3. Kliknij **Testuj połączenie**: pokazuje **Runner connection is OK**. Niczego nie wywołuje: odczytuje, który węzeł aplikacji trzyma gniazdo RTE
+   (`runner_leases`), i sprawdza kontrakt, którym RTE mówiło przy połączeniu
+4. Nadaj mu opis, np. *Centrum danych 2*
+5. Zostaw **Domyślne** na runnerze centrum danych 1, chyba że każdy formularz playbooka bez `runner:` ma działać w centrum danych 2
+
+Strona **Stan** wyświetla nowe RTE z jego wersją, obok pozostałych.
+
+---
+
+## 10. Pierwsze zadanie
+
+Sprawdź całą ścieżkę playbookiem, który niczego nie zmienia. W playbookach aplikacji (jej folderze playbooków lub repozytorium, jak w
+centrum danych 1) dodaj `ping-dc2.yaml`:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Następnie dodaj w projektancie formularz, który wskazuje nowy runner:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Uruchom go. Aplikacja wysyła folder playbooków i inwentarz z zadaniem, a RTE przechowuje je według hasha, więc niezmieniony
+folder nigdy nie jest wysyłany dwa razy. Wynik zaczyna się od `Running on RTE rte-dc2 (outbound)`, pokazuje `pong` dla każdego hosta, a zadanie
+kończy się sukcesem. Folder większy niż [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (domyślnie 512) nie jest
+wysyłany: zadanie kończy się błędem i o tym informuje.
+
+---
+
+## 11. Kieruj do niego formularze
+
+Formularz działa na RTE, które wskazuje, więc dodaj ten sam wiersz do każdego formularza dla centrum danych 2:
+
+```yaml
+runner: rte-dc2
+```
+
+Domyślny runner i pozostałe typy runnerów opisuje strona [Runnery](../runners.html).
+
+---
+
+## Gdy coś zawiedzie
+
+RTE zapisuje do `docker logs` od poziomu `notice` w górę. Połączenie, które zawodzi, zanim gniazdo się otworzy (nazwa DNS, odrzucony port,
+certyfikat), widać tylko jako `RTE: dialing the app again in <n> seconds`, na poziomie `info`: ustaw
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) w `rte.env` i zrestartuj je, aby zobaczyć
+`RTE: socket to wss://...: <the error>`.
+
+| Co widzisz | Gdzie | Co zrobić |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | Brakuje `RTE_TOKEN` w `rte.env` lub jest za krótki |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Ustaw `APP_URL` w `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` musi zaczynać się od `https://` (lub `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | Brakuje `RTE_MODE=outbound` w `rte.env` |
+| Brak wiersza `connected to the app`, `/ready` pozostaje `503` | `docker logs`, `/ready` | Sieć z kroku 2: `curl` do aplikacji z tego hosta, proxy (`HTTPS_PROXY`, `NO_PROXY`), certyfikat aplikacji (`NODE_EXTRA_CA_CERTS`, krok 5). Ustaw `LOG_CONSOLE_LEVEL=debug`, aby zobaczyć błąd |
+| `the app refused the socket (404)` lub inny status niż 401, 403 i 409 | `docker logs` | Reverse proxy nie przepuszcza WebSocketu na `/api/v2/rte/socket` albo w `APP_URL` brakuje ścieżki bazowej aplikacji |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Istnieje runner `rte-dc2` z innym tokenem. Daj RTE ten token (hasło z poświadczenia runnera) albo usuń runner, żeby RTE poprosiło o dołączenie |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Utwórz nowy token dołączenia albo usuń `RTE_JOIN_TOKEN` i zatwierdź RTE (krok 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | RTE zostało zainstalowane ponownie z nowym tokenem: użyj tokenu z poświadczenia jego runnera albo poproś admina o jego zmianę |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Następuje po odmowie. Usuń jej przyczynę, a potem `docker restart af_rte_dc2` zamiast czekać |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Zatwierdź je (krok 8). Jest połączone, ale do tego czasu nie przyjmuje zadań |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | Aplikacja i RTE działają w wydaniach z innym [kontraktem](images.html#the-contract): zaktualizuj RTE do wydania aplikacji (zobacz Aktualizacja) |
+| **Niepołączony** albo **Testuj połączenie** mówi *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | Aplikacja | Żaden węzeł aplikacji nie trzyma jego gniazda: RTE jest zatrzymane lub nie może dotrzeć do aplikacji. Przeczytaj jego `docker logs` |
+| Zadanie czeka, a potem kończy się błędem *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | Wynik zadania | RTE nie było połączone, gdy zadanie czekało |
+| `Permission denied` przy kluczu ssh | Wynik zadania | Pliki w `data/` muszą należeć do uid 1000 (krok 3) |
+| `UNREACHABLE` dla zarządzanych hostów | Wynik zadania | ssh z tego hosta: klucz, `known_hosts` i zapora w stronę hostów |
+
+Po stronie aplikacji odrzucone RTE widać w dzienniku aplikacji jako `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Aktualizacja
+
+Gdy aplikacja przechodzi na nowe wydanie, zaktualizuj też ten host. RTE z tym samym kontraktem w międzyczasie działa dalej; gdy wydanie
+zmienia kontrakt, mówią o tym jego informacje o wydaniu (zobacz [Kontrakt](images.html#the-contract)). Z `:7` w `compose.yml` lub w
+`FROM` Twojego pliku Dockerfile:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Aktualizuj je, gdy nie działa na nim żaden playbook: zatrzymanie czeka `RTE_DRAIN_SECONDS` (25) na działające playbooki, a te, które nadal działają,
+kończą się wtedy jako porzucone. To, co wypisały przed zatrzymaniem, zostaje w spoolu i jest wysyłane, gdy RTE wróci. Offline wykonaj `docker load`
+nowego obrazu (krok 4) przed `docker compose up -d`.
+
+---
+
+## Wycofanie
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+Gniazdo się zamyka, a runner od razu pokazuje **Niepołączony**: żaden węzeł aplikacji nie trzyma już jego gniazda (`runner_leases`). Host,
+który znika, nie zamykając go, pokazuje **Niepołączony** w ciągu około minuty, gdy węzeł aplikacji przestanie cokolwiek słyszeć na gnieździe.
+Runner zostaje: runner, który dołączył przez gniazdo, nigdy nie jest usuwany samoczynnie. Usuń go w **Połączenia > Runnery**, a jego
+poświadczenie `rte-dc2-rte` w **Połączenia > Poświadczenia**. Najpierw usuń wiersz `runner:` z formularzy, które go wskazywały: do tego czasu
+ich zadania czekają na RTE, do `RTE_QUEUE_MINUTES`, i kończą się błędem.
+
+---
+
+## Więcej pojemności w centrum danych 2
+
+Powtórz kroki od 1 do 9 na kolejnych hostach centrum danych 2, każdy z własnym `RTE_NAME` i `RTE_TOKEN`, np. `rte-dc2-b`: każdy dołącza jako
+osobny runner i przyjmuje do [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooków. Formularz wybiera jeden przez
+`runner:`. Dwa RTE z tym samym `RTE_NAME` nie dzielą się pracą: drugie przejmuje gniazdo od pierwszego (zobacz
+[Kilka RTE](several.html#several-rtes)).
+
+---
+
+## RTE w trybie bazy danych
+
+Przed wersją 7.3.0 ten runbook konfigurował RTE w trybie bazy danych: miało poświadczenia bazy danych (`DB_*`, `ENCRYPTION_SECRET`), łączyło się
+z bazą danych centrum danych 1 przez port `3306`, a aplikacja wywoływała je na jego porcie `8000`. Ten tryb jest przestarzały od wersji 7.3.0 i
+zostanie usunięty w 8.0.0. Aby przenieść takie RTE do trybu wychodzącego bez nowego runnera, ustaw na nim `RTE_MODE=outbound`, `APP_URL` i `RTE_NAME` (nazwę
+jego runnera), zachowaj jego `RTE_TOKEN` i usuń `DB_*`, `ENCRYPTION_SECRET` oraz `RTE_REGISTER`: zobacz
+[Baza danych (przestarzały)](modes.html#database-deprecated). Następnie zamknij port `8000` i port bazy danych, których już nie potrzebuje.
diff --git a/i18n/pl/_configure/rte/images.md b/i18n/pl/_configure/rte/images.md
new file mode 100644
index 0000000..47c648c
--- /dev/null
+++ b/i18n/pl/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Obrazy
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# Obrazy RTE
+{: .no_toc }
+
+Trzy publikowane obrazy RTE i własne RTE z kolekcjami i bibliotekami, których używają Twoje playbooki
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Obrazy RTE
+
+RTE jest publikowane w trzech warstwach, z których każda jest zbudowana na poprzedniej, z tymi samymi tagami co aplikacja (zobacz [Tagi obrazów](../installation/#image-tags)):
+
+| Obraz | Co zawiera | Kiedy go używać |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js i serwer AnsibleForms, git, ssh i sshpass. Bez pythona i ansible, więc sam nie uruchamia żadnego playbooka | Do zbudowania RTE z własnymi wersjami pythona i ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | Warstwa bazowa plus python 3.14, ansible-core i kilka popularnych bibliotek (`jmespath`, `netaddr`, `requests`, `paramiko`). Bez kolekcji | Do zbudowania mniejszego RTE tylko z kolekcjami i bibliotekami, których używają Twoje playbooki |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Warstwa core plus pakiet `ansible` na tym samym ansible-core i to, co miał obraz AnsibleForms 6.5: kolekcje NetApp, AWS i community, `pandas`, `pyvmomi`, `boto3`, klient mariadb, ytt i kilka narzędzi systemowych | **Domyślny.** Uruchamiaj go bez zmian: playbooki z 6.5 znajdą to, czego używały |
+
+Tak jak obraz aplikacji, każda warstwa działa jako użytkownik `node` (uid 1000) i playbooki też działają jako ten użytkownik.
+
+---
+
+## Zbuduj własne RTE
+
+Buduj na `ansibleforms-rte-core` i dodaj kolekcje i biblioteki pythona, których używają Twoje playbooki. Ten przykład dla NetApp to jeden z
+plików Dockerfile w [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+Środowisko pythona i folder kolekcji należą do `node`, więc te instalacje nie wymagają roota. Warstwa, która instaluje pakiety
+systemowe, przełącza się na nie na `USER root`, a na końcu z powrotem na `USER node`. Aby użyć własnego pythona i ansible, buduj na
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` w tym samym folderze).
+
+Trzymaj obraz na wydaniu aplikacji: `:7` podąża za `:7` aplikacji. Kolekcje i role można też montować zamiast wbudowywać, w
+`/etc/ansible/collections` i `/etc/ansible/roles`. Wtedy żadna zmiana nie wymaga przebudowy, ale to, co działa, zależy od tego wolumenu;
+biblioteki pythona zawsze trafiają do obrazu. Wbudowanie wszystkiego jest powtarzalne i szybko startuje, dlatego to właściwa droga dla produkcji.
+
+---
+
+## Kontrakt
+
+To, co aplikacja i RTE muszą mieć wspólne, to ich kontrakt, liczba, którą oba raportują. RTE ze starszego wydania nadal działa z nowszą
+aplikacją, dopóki oba mówią tym samym kontraktem; gdy wydanie go zmienia, jego informacje o wydaniu mówią, że RTE trzeba zaktualizować. Każdy tryb
+ma własny:
+
+| Tryb | Kontrakt | Przy niezgodności |
+|---|---|---|
+| Wychodzący, przychodzący | 3, nowość w 7.3.0 | Aplikacja zamyka gniazdo RTE kodem `4409` i zapisuje w dzienniku *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. RTE w trybie wychodzącym zapisuje *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Zadanie wysłane z innym kontraktem jest odrzucane |
+| Baza danych (przestarzały) | 2, od 7.0.0 | RTE odrzuca zadania aplikacji |
+
+**Testuj połączenie** na runnerze mówi, którym kontraktem mówi RTE, a którego potrzebuje aplikacja (zobacz
+[Testuj połączenie](../runners/runner-page.html#test-connection)), a wiersz **Runnery** na stronie **Stan** wykonuje to samo sprawdzenie.
diff --git a/i18n/pl/_configure/rte/index.md b/i18n/pl/_configure/rte/index.md
new file mode 100644
index 0000000..35be0c6
--- /dev/null
+++ b/i18n/pl/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Środowiska uruchomieniowe (RTE)
+{: .no_toc }
+
+Czym jest RTE, jak uruchamia playbook i czego może dotykać
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: zrozum RTE, zanim je uruchomisz, dobierzesz jego rozmiar lub przeniesiesz do innej sieci.
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Obrazy](images.html) | Trzy obrazy RTE i budowanie własnego z kolekcjami, których używają Twoje playbooki |
+| [Tryby](modes.html) | Wychodzący, przychodzący lub bazy danych: kto otwiera połączenie, spool, pliki zadania |
+| [Uruchamianie RTE](run.html) | Ustawienia każdego trybu i przykład `docker run` dla każdego z nich |
+| [Kilka RTE](several.html) | Pojemność, repliki za jednym adresem i co się dzieje, gdy RTE się zatrzyma lub padnie |
+| [Inne centrum danych](another-datacenter.html) | Runbook: dodanie RTE w drugim centrum danych, od pustego hosta do pierwszego zadania |
+
+---
+
+## Czym jest RTE
+
+AnsibleForms 7 nie uruchamia żadnego playbooka w kontenerze aplikacji. Zadanie formularza `ansible` jest przekazywane do [runnera](../runners.html) typu
+`rte`, czyli środowiska uruchomieniowego: serwera AnsibleForms uruchomionego z `AF_ROLE=rte`, obok pythona i ansible, bez interfejsu
+WWW. Komunikuje się z aplikacją przez jeden WebSocket i nie ma żadnych poświadczeń do bazy danych
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` lub `inbound`, zobacz [Tryby](modes.html)): aplikacja wysyła mu zadanie,
+RTE uruchamia `ansible-playbook`, a aplikacja zapisuje wynik i końcowy status, które RTE odsyła, i stamtąd czyta je przeglądarka.
+
+Aplikacja rozwiązuje poświadczenia zadania i przekazuje je RTE zapieczętowane tylko dla tego RTE i tego zadania. RTE nigdy nie czyta
+tabeli poświadczeń ani magazynu sekretów, a playbook nie dziedziczy zmiennych środowiskowych samego AnsibleForms
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` i innych): przekaż taką wartość jako extravar lub poświadczenie. RTE z wersji 7.0 do 7.2,
+które samo czytało i zapisywało bazę danych, nadal działa w 7.x jako przestarzały tryb bazy danych (zobacz [Tryb bazy danych](#database-mode-deprecated)).
+
+---
+
+## Jak działa RTE
+
+RTE to kontener, który uruchamiasz sam, obok aplikacji lub w innej sieci: AnsibleForms nigdy go nie tworzy. Poniżej opisano,
+gdzie działa, co współdzieli z aplikacją i co dzieje się w nim od chwili uruchomienia formularza, aż proces playbooka
+zniknie:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Jak RTE uruchamia playbook</title>
+<desc id="afr-desc">Na hoście kontenerów lub w klastrze Kubernetes, oba zarządzane przez operatora, kontener aplikacji i jeden lub więcej kontenerów RTE utrzymują każdy po jednym WebSockecie między sobą, otwieranym przez aplikację (przychodzący) lub przez RTE (wychodzący). Tylko aplikacja rozmawia z bazą danych. 1: przeglądarka uruchamia formularz w aplikacji. 2: aplikacja zapisuje zadanie w bazie danych, wybiera runner i pieczętuje dla niego sekrety zadania. 3: aplikacja wysyła zadanie przez gniazdo. 4: RTE je przejmuje i pobiera pliki zadania, ze swojej pamięci podręcznej lub z aplikacji. 5: RTE uruchamia ansible-playbook jako proces potomny, jeden na zadanie, do RTE_MAX_JOBS. 6: playbook łączy się z zarządzanymi hostami. 7: RTE zapisuje wynik, zdarzenia i zakończenie w swoim spoolu i wysyła je przez gniazdo; aplikacja zapisuje je w bazie danych i potwierdza odbiór. 8: przeglądarka śledzi zadanie przez aplikację. Wolumen aplikacji jest montowany w RTE tylko przy RTE_FILES=local.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Host kontenerów lub klaster Kubernetes</text>
+<text class="afr-s" x="181" y="61">zarządzany przez Ciebie; wychodzące RTE może być w innej sieci</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Przeglądarka</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">formularze, zadanie</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">Kontener app</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">WWW, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runnery</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">pieczętują sekrety</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">Hub RTE</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">zapisuje, potwierdza</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">Kontener RTE</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">Pliki zadania</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">w cache wg hasha</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">do RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">do potwierdzenia</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">jeden</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Zarządzane hosty</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, API</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Wolumen aplikacji</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbooki, inwentarze</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">tylko RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">tylko dla aplikacji</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+Diagram pokazuje jedno gniazdo na RTE, niezależnie od tego, która strona je otworzyła: aplikacja łączy się z RTE w trybie przychodzącym, RTE w trybie wychodzącym łączy się z aplikacją (zobacz
+[Tryby](modes.html)). Gdy gniazdo jest otwarte, te same komunikaty płyną w obie strony, a bazę danych czyta i zapisuje tylko aplikacja.
+
+**Kto je uruchamia.** RTE to długo działający kontener, uruchamiany przez to, co uruchamia Twoje pozostałe kontenery. Czeka na zadania i działa
+dalej między nimi:
+
+| Jak uruchamiasz AnsibleForms | Kto uruchamia RTE |
+|---|---|
+| `docker run` lub `podman run` | Ty, poleceniem takim jak w [Uruchamianie RTE](run.html), na dowolnym hoście, który dociera do aplikacji albo do którego dociera aplikacja |
+| [Docker Compose](../installation/docker-compose.html) | Usługa `rte` w `docker-compose.yml`, obok `app` i `mysqldb`. Jej config seed deklaruje ją jako domyślny runner `rte`, w trybie przychodzącym, pod `http://rte:8000` |
+| [Chart Helm](../installation/kubernetes.html) | Kubernetes, jako drugi kontener o nazwie `rte` w podzie aplikacji (`containers.rte`). Aplikacja łączy się z nim na `127.0.0.1`, w trybie przychodzącym, a seed chartu deklaruje go jako domyślny runner |
+| [Instalator](../installation/installer.html) | Docker Compose lub chart Helm jak wyżej albo usługa systemd [bez kontenerów](../installation/native.html); własny runner, który prosi o dołączenie i czeka na zatwierdzenie przez admina |
+
+Silnik kontenerów należy do Ciebie: Docker lub Podman na hoście albo środowisko uruchomieniowe kontenerów Twojego klastra Kubernetes, instalowane i aktualizowane
+przez Ciebie. AnsibleForms nigdy się z nim nie komunikuje. Ani aplikacja, ani RTE nie wywołuje Dockera ani Podmana, nie montuje ich gniazda ani nie uruchamia
+kontenera: aplikacja komunikuje się z RTE tylko przez jego gniazdo.
+
+**Co jest w środku.** Jeden kontener, z tym, co potrzebne do uruchomienia playbooka, i niczym więcej:
+
+* **Serwer** : ten sam serwer Node.js co aplikacja, uruchomiony z `AF_ROLE=rte` (ustawionym w obrazie) pod `tini`
+* **Pominięte** : interfejs WWW, logowanie, harmonogram, worker i wszystkie moduły bazy danych, których ta rola nie ładuje
+* **Na czym nasłuchuje** : na swoim `PORT` (`8000`): `/live` i `/ready` dla sond oraz `/metrics` dla Prometheus, a w trybie przychodzącym gniazdo,
+  z którym łączy się aplikacja, `/rte/v1/socket`. RTE w trybie wychodzącym nie przyjmuje żadnego połączenia od aplikacji
+* **Python i ansible** : dostarczane przez wybraną warstwę obrazu (zobacz [Obrazy RTE](images.html))
+* **Użytkownik** : serwer i każdy playbook działają jako `node` (uid 1000), nigdy jako root
+
+**Co współdzieli z aplikacją.** Swój token, a przy `RTE_FILES=local` pliki aplikacji. Przy `RTE_FILES=transfer`, domyślnym,
+playbooki i inwentarze przychodzą z każdym zadaniem, a RTE nie potrzebuje współdzielonego dysku:
+
+| Współdzielone z aplikacją | Co RTE z tym robi |
+|---|---|
+| `RTE_TOKEN` | Przedstawia go, gdy łączy się z aplikacją (tryb wychodzący), lub sprawdza, gdy aplikacja łączy się z nim (tryb przychodzący). Aplikacja ma tę samą wartość w poświadczeniu RTE runnera, a sekrety zadania są nim pieczętowane |
+| Wolumen trwały, `/app/dist/persistent`, tylko przy `RTE_FILES=local` | Folder playbooków ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) lub repozytorium playbooków sklonowane przez worker w [`REPO_PATH`](../customization/paths.html#env_REPO_PATH), inwentarze ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) i repozytoria inwentarzy) oraz przesłane pliki. RTE zapisuje pliki extravars zadania w folderze playbooka, więc montuj go do odczytu i zapisu |
+| Folder ssh, `/home/node/.ssh` | Klucz prywatny i `known_hosts`, których używają połączenia ssh playbooka: zamontuj folder aplikacji, zarządzany na jej stronach ustawień, albo daj RTE własny |
+
+RTE niczego nie klonuje: repozytorium dociera do niego w plikach zadania lub na wolumenie współdzielonym z aplikacją. Kolekcje, role i
+`ansible.cfg` pochodzą z obrazu, z folderów `/etc/ansible/collections`, `/etc/ansible/roles` i z `/etc/ansible/ansible.cfg`, gdy
+je tam zamontujesz (projekt Docker Compose to robi), albo z `ansible.cfg` obok playbooków.
+
+**Życie zadania.** Poniższe numery to numery z diagramu, dla formularza playbooka uruchomionego z przeglądarki lub przez API:
+
+1. **Uruchomienie** : aplikacja sprawdza formularz i jego wartości, buduje extravars i zapisuje zadanie ze statusem `running`. Formularz z
+   [zatwierdzeniem](../forms/approval.html) zatrzymuje się tutaj, dopóki zatwierdzający go nie zaakceptuje, i wcześniej nie trafia do żadnego RTE
+2. **Wybór runnera** : aplikacja bierze RTE, które formularz wskazuje przez `runner: <name>`, a w przeciwnym razie domyślny runner typu RTE, i zapisuje jego
+   nazwę w zadaniu. Rozwiązuje poświadczenia zadania z bazy danych lub [magazynu sekretów](../secret-stores/), jego login ansible i
+   hasło vault, i pieczętuje je algorytmem AES-256-GCM kluczem wyprowadzonym z tokenu tego runnera i id zadania
+3. **Przekazanie** : węzeł aplikacji, który trzyma gniazdo RTE, wysyła mu zadanie: extravars, opcje formularza, zapieczętowane sekrety i
+   hashe plików zadania. Zadanie może uruchomić dowolny węzeł aplikacji; ten, który trzyma gniazdo, wysyła je w ciągu dwóch sekund. Pełne RTE
+   albo niepołączone sprawia, że zadanie czeka, do [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Przejęcie** : RTE odpowiada `claimed` albo `refused`, gdy jest pełne, się zatrzymuje, nie może otworzyć sekretów lub zadanie przychodzi z innym
+   [kontraktem](images.html#the-contract) niż jego własny. Przy `RTE_FILES=transfer` bierze playbooki i inwentarze ze swojej
+   pamięci podręcznej według hasha, prosi aplikację o hash, którego nie ma, i rozpakowuje je w osobnym folderze zadania
+5. **Start** : w folderze playbooka (plus `playbookSubPath` formularza, który musi istnieć) zapisuje dwa pliki: `extravars_<id>.json`
+   z wartościami formularza i poświadczeniami oraz ukryty plik z loginem ansible. Następnie uruchamia `ansible-playbook` jako własny proces
+   potomny, bez powłoki, we własnej grupie procesów, z `-e @` tymi plikami, jednym `-i` na każdy inwentarz oraz tagami, limitem, check,
+   diff i szczegółowością formularza. Hasło vault trafia przez stdin, nigdy do pliku ani do wiersza poleceń, a proces działa jako
+   `node` z odfiltrowanym środowiskiem (zobacz niżej)
+6. **Wykonanie** : playbook łączy się z zarządzanymi hostami z kontenera RTE, przez ssh z kluczem i `known_hosts` z
+   `/home/node/.ssh`, z `sshpass` dla logowania hasłem, albo przez API wywoływane przez jego moduły. To RTE, a nie aplikacja, musi do nich docierać
+7. **Wynik i zakończenie** : RTE grupuje stdout i stderr co pół sekundy lub co 64 KB, z zamaskowanymi poświadczeniami, i numeruje każdą
+   paczkę. Każdy element zapisuje w spoolu zadania na swoim dysku, zanim go wyśle: wynik, zdarzenia, dziennik zadania z
+   `.joblogs/job_log_<id>.log` (co 2 sekundy), start i zakończenie z końcowym statusem (`success`, `failed` lub `aborted`). Aplikacja
+   zapisuje każdy element raz i potwierdza go, a RTE usuwa spool, gdy zakończenie zostanie zapisane. Po przekroczeniu
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) bajtów na strumieniu (domyślnie 50 MB) nie wysyła już nic, a
+   playbook działa dalej. Następnie aplikacja wysyła [powiadomienia](../forms/notifications.html) formularza
+8. **Śledzenie** : przeglądarka nigdy nie komunikuje się z RTE: strona formularza co 2 sekundy ponownie odczytuje zadanie przez aplikację, a strona Zadania
+   śledzi je na żywo, w miarę jak aplikacja zapisuje kolejne elementy
+
+**Zerwane gniazdo.** Playbook działa dalej. RTE łączy się ponownie (tryb wychodzący) albo węzeł aplikacji łączy się z nim ponownie (tryb przychodzący) i wysyła ponownie to,
+czego aplikacja nie potwierdziła: aplikacja pomija to, co już zapisała, więc żaden wiersz nie ginie ani nie jest zapisany dwukrotnie. Działa to, dopóki gniazdo
+wróci w ciągu dwóch minut: aplikacja zapisuje sygnał życia RTE tylko wtedy, gdy jego gniazdo jest otwarte, a gdy ten sygnał ma dwie minuty,
+worker kończy działające zadania RTE jako porzucone, nawet jeśli ich playbooki nadal działają. Trzymaj spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) na wolumenie, żeby zrestartowane RTE nadal wysłało to, co zachowało.
+Playbook, który działał, gdy jego RTE się zrestartowało, nie może kontynuować: aplikacja kończy jego zadanie jako porzucone, gdy RTE wraca bez niego.
+
+**Przerwanie.** Przerwanie ustawia flagę przerwania zadania, a węzeł aplikacji, który trzyma gniazdo RTE, w ciągu dwóch sekund wysyła `cancel`. RTE
+wysyła `SIGTERM` do grupy procesów playbooka, więc `ansible-playbook` i każdy fork, który uruchomił, zatrzymują się razem, a zadanie kończy się jako
+`aborted`. Anulowanie, które dotrze przed swoim zadaniem, jest przechowywane przez minutę, a zadanie startuje wtedy już przerwane.
+
+**Sprzątanie.** Gdy tylko proces się zakończy, niezależnie od wyniku, RTE usuwa oba pliki extravars (formularz z `keepExtravars`
+zachowuje widoczny, nigdy ukryty), plik artefaktów w `/tmp`, plik dziennika zadania i osobny folder plików zadania. Zakończenie
+jest zapisywane raz: drugi zapisujący, np. aplikacja oznaczająca jako nieudane zadanie, które RTE już zakończyło, niczego nie zmienia.
+
+**Jeden proces na zadanie, a nie jeden kontener na zadanie.** AWX i AAP przy każdym zadaniu uruchamiają nowy pod lub kontener z obrazu
+execution environment. AnsibleForms niczego nie uruchamia: kontener RTE już działa, a każde zadanie jest w nim procesem potomnym. Zadanie startuje
+bez pobierania obrazu i planowania poda, a AnsibleForms nie potrzebuje żadnych uprawnień do Twojego silnika kontenerów ani klastra. W zamian
+playbooki działające na jednym RTE dzielą jego CPU, pamięć, `/tmp`, folder domowy i pythona: daj kontenerowi wystarczająco zasobów na
+`RTE_MAX_JOBS` playbooków z ich forkami. Aby zmienić to, czego może używać playbook, zmień obraz, a nie zadanie.
+
+---
+
+## Granica bezpieczeństwa
+
+RTE uruchamia kod napisany przez autorów formularzy, więc jest zbudowane tak, by przechowywać jak najmniej:
+
+* **Tylko jego token** : RTE nie ma poświadczeń do bazy danych ani `ENCRYPTION_SECRET`. Nie przyjmuje żadnych wywołań poza gniazdem aplikacji, z
+  jego tokenem, i nie ma użytkowników, logowania ani stron WWW. Przez gniazdo może tylko uruchamiać zadania, które wysyła mu aplikacja, raportować o nich i
+  prosić o ich pliki: nie może utworzyć zadania, odczytać innego zadania ani rozdawać poświadczeń
+* **Zapieczętowane sekrety** : aby uruchomić zadanie, RTE nigdy nie czyta tabeli poświadczeń ani magazynu sekretów. Dostaje sekrety zadań, które
+  uruchamia, zapieczętowane tylko dla swojego tokenu i id tego zadania, więc paczka przeznaczona dla innego RTE lub innego zadania się nie otwiera, a zmieniony bajt
+  jest odrzucany
+* **Sprawdzane połączenie** : w trybie wychodzącym RTE sprawdza certyfikat aplikacji. W trybie przychodzącym przez HTTPS aplikacja przypina własny certyfikat RTE,
+  gdy ono dołącza, i łączy się z nim tylko wtedy, gdy przedstawia właśnie ten (zobacz [Tryby](modes.html#inbound)). RTE w trybie przychodzącym przez zwykłe HTTP powinno być
+  w sieci prywatnej, takiej jak sieć projektu Docker Compose
+* **Bez dziedziczonego środowiska** : `ansible-playbook` dostaje środowisko RTE bez wszystkich zmiennych, które odczytuje sam AnsibleForms
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, zmienne `MYSQL_*` i inne), więc
+  `lookup('env', ...)` nie może do nich dotrzeć. To, co ustawisz dla playbooków (`PATH`, proxy, `ANSIBLE_*`), przechodzi bez zmian
+* **Bez szablonów od użytkowników** : {% raw %}wartość formularza, która zawiera `{{`, `{%` lub `{#`, trafia do playbooka jako niebezpieczny ciąg (unsafe){% endraw %},
+  którego ansible nigdy nie przetwarza jako szablonu, chyba że formularz ustawia `allowJinjaInExtravars`, a żadna powłoka nigdy nie uruchamia wiersza poleceń
+* **Nie jako root** : RTE i jego playbooki działają jako `node` (uid 1000), więc playbook może robić w kontenerze to, co może ten użytkownik, np.
+  czytać jego pliki i klucz ssh, i nic więcej
+
+Traktuj jego kontener, obraz i środowisko z taką samą starannością jak kontener aplikacji.
+
+---
+
+## Tryb bazy danych (przestarzały)
+
+RTE z wersji 7.0 do 7.2, bez `RTE_MODE`, działa przez całą serię 7.x i zostanie usunięte w 8.0.0. Różni się od powyższych kroków na cztery sposoby:
+
+* **Ma dostęp do bazy danych** : swoje ustawienia `DB_*` oraz `ENCRYPTION_SECRET`, gdy samo się rejestruje
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **Przekazanie to wywołanie HTTP** : aplikacja wywołuje `POST <address>/rte/v1/jobs` z tokenem i zapieczętowanymi sekretami, a RTE przejmuje
+  zadanie, zapisując w nim swoją nazwę w bazie danych (kroki 3 i 4)
+* **Samo zapisuje wynik** : w bazie danych, paczkami, bez spoola (krok 7). Przerwanie dociera do niego przez flagę przerwania zadania,
+  którą odczytuje co 2 sekundy, oraz przez wywołanie `/cancel`
+* **Czyta pliki z wolumenu aplikacji** : potrzebuje tego samego dysku co aplikacja, jak przy `RTE_FILES=local`
+
+Jego strona runnera nie ma żadnych [ustawień RTE](../runners/runner-page.html#an-rtes-settings): odczytuje własne zmienne. Aby przenieść je do
+trybu gniazda, zobacz [Tryby](modes.html#database-deprecated).
diff --git a/i18n/pl/_configure/rte/modes.md b/i18n/pl/_configure/rte/modes.md
new file mode 100644
index 0000000..663abe3
--- /dev/null
+++ b/i18n/pl/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Tryby
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Jak RTE komunikuje się z aplikacją
+{: .no_toc }
+
+Wychodzący, przychodzący lub bazy danych: kto otwiera połączenie i co nim przechodzi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: od wersji 7.3.0 RTE komunikuje się z aplikacją przez jeden WebSocket i nie ma poświadczeń do bazy danych. Wybierz tryb,
+który pasuje do sieci między nimi: kto może otworzyć połączenie do kogo i przez jakie proxy i zapory ono przechodzi.
+
+---
+
+## Trzy tryby
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) na RTE mówi, jak łączy się ono z aplikacją; jego runner ma ten sam **Tryb**:
+
+| Tryb | Kto otwiera połączenie | Co ma RTE | Dla |
+|---|---|---|---|
+| `outbound` | RTE łączy się z aplikacją pod [`APP_URL`](../customization/server.html#env_APP_URL) i utrzymuje jeden otwarty WebSocket | Swój `RTE_TOKEN`, bez poświadczeń do bazy danych | DMZ, NAT lub strefy, która nie dopuszcza połączeń przychodzących: nic nie dociera do RTE z zewnątrz |
+| `inbound` | Aplikacja łączy się z RTE pod adresem jego runnera i utrzymuje jeden otwarty WebSocket | Swój `RTE_TOKEN`, bez poświadczeń do bazy danych | Sieci, w której każde połączenie otwiera strona centralna, projektu compose, poda |
+| `database` (przestarzały) | Aplikacja wywołuje API RTE przez HTTP, a RTE samo czyta i zapisuje bazę danych aplikacji | Poświadczenia bazy danych (`DB_*`) i `ENCRYPTION_SECRET` | Zachowanie z wersji 7.0 do 7.2, usunięte w 8.0.0 |
+
+RTE bez `RTE_MODE` działa w trybie bazy danych przez całą serię 7.x i przy starcie zapisuje ostrzeżenie `[DEPRECATED] This RTE runs in database mode`.
+Runner dodany przed wersją 7.3.0 ma tryb **Baza danych (przestarzały)**; przy przenoszeniu ustaw go na tryb, w którym działa jego RTE.
+
+---
+
+## Wychodzący
+
+Połączenie otwiera RTE, więc działa to z sieci, która w ogóle nie przyjmuje połączeń przychodzących:
+
+* **Gniazdo** : RTE łączy się z `APP_URL` z dopisanym `/api/v2/rte/socket`, przez `wss://` (`ws://` dla adresu `http://`), ze swoim
+  `RTE_TOKEN` i nazwą swojego runnera, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Gdy gniazdo zostanie zerwane, łączy się ponownie
+* **Za pierwszym razem** : prosi o dołączenie, a jego runner czeka na zatwierdzenie przez admina w **Połączenia > Runnery**, połączony,
+  ale bez zadań (zobacz [Prośba o dołączenie](../runners/registration.html#asking-to-join)). Token dołączenia,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), zatwierdza go od razu. Od tej pory loguje się własnym tokenem
+* **Sieć** : tylko ze strefy RTE do aplikacji, na porcie aplikacji, przez proxy, gdy tak mówi `HTTPS_PROXY`. Reverse
+  proxy przed aplikacją musi przepuszczać WebSocket na tej ścieżce (zobacz [WebSockety runnerów](../production/reverse-proxy.html#runner-websockets))
+* **Certyfikat** : certyfikat aplikacji jest sprawdzany. Prywatne CA wskaż przez `NODE_EXTRA_CA_CERTS` albo, tylko wewnątrz jednej zaufanej sieci,
+  wyłącz sprawdzanie przez [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **Runner** : nie potrzebuje adresu, więc jego poświadczenie RTE zawiera tylko token
+* **Gotowość** : `/ready` odpowiada `503`, dopóki gniazdo do aplikacji nie jest otwarte
+
+Przy kilku węzłach aplikacji za load balancerem gniazdo trzyma ten węzeł, do którego dotrze RTE. Zadanie może uruchomić dowolny węzeł: węzeł, który trzyma
+gniazdo, wysyła je do RTE, w ciągu dwóch sekund, gdy zadanie uruchomiono na innym węźle.
+
+---
+
+## Przychodzący
+
+RTE nasłuchuje na swoim `PORT`, a aplikacja łączy się z nim pod adresem jego runnera, z dopisanym `/rte/v1/socket` i tokenem RTE. Przy
+kilku węzłach aplikacji gniazdo każdego runnera w trybie przychodzącym trzyma naraz jeden węzeł; gdy ten się zatrzyma, przejmuje je inny i łączy się ponownie.
+
+Aplikacja potrzebuje runnera RTE, zanim będzie mogła się z nim połączyć: typ RTE, tryb **Przychodzący** i poświadczenie RTE z adresem RTE i jego
+`RTE_TOKEN`. Trafia on tam na jeden z dwóch sposobów:
+
+| Jak | Co ustawić |
+|---|---|
+| RTE prosi o dołączenie | `APP_URL` i [`RTE_URL`](../customization/server.html#env_RTE_URL) (adres, pod który łączy się aplikacja). RTE wykonuje jedno wywołanie, `POST /api/v2/rte/register`, a jego runner czeka na zatwierdzenie przez admina: aplikacja łączy się z nim, gdy zostanie zatwierdzony (zobacz [Prośba o dołączenie](../runners/registration.html#asking-to-join)). Z `RTE_JOIN_TOKEN` jest zatwierdzany od razu. RTE w trybie przychodzącym z `APP_URL`, ale bez `RTE_URL` odmawia startu |
+| Ty dodajesz runner | Bez `APP_URL`: dodaj runner w **Połączenia > Runnery** lub w [config seed](../seed/), jak w [Uruchamianie RTE](run.html#start-it) |
+
+Projekt Docker Compose, chart Helm i kontroler instalatora uruchamiają w ten sposób własne RTE, w trybie przychodzącym, zadeklarowane przez seed.
+
+**Przez HTTPS.** Przy [`HTTPS=1`](../customization/server.html#env_HTTPS) RTE udostępnia swoje gniazdo przez TLS, z kluczem i certyfikatem
+z [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) i [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(domyślnie `key.pem` i `cert.pem` w jego folderze `certificates`). RTE z `RTE_URL` w postaci `https://` wysyła ten certyfikat, gdy
+prosi o dołączenie, a aplikacja go przypina: łączy się z RTE tylko wtedy, gdy przedstawia ono ten sam certyfikat, więc samopodpisany działa bez CA.
+RTE zapisuje przy starcie odcisk certyfikatu (pierwsze 8 cyfr szesnastkowych SHA-256 jego bajtów DER, jako `abcd-ef12`),
+a okno zatwierdzania pokazuje odcisk, który otrzymała aplikacja: sprawdź, czy się zgadzają, zanim zatwierdzisz.
+[Instalator](../installation/installer.html#a-runner) konfiguruje w ten sposób swoje runnery w trybie przychodzącym, z certyfikatem ich własnego adresu.
+
+---
+
+## Baza danych (przestarzały)
+
+RTE z wersji 7.0 do 7.2: aplikacja wywołuje jego API przez HTTP, a RTE przejmuje zadanie w bazie danych, zapisuje tam wynik i aktualizuje
+własny wiersz runnera, z [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Tryb bazy danych](./#database-mode-deprecated)
+opisuje, czym różnią się jego kroki. Nadal działa w 7.x, z ostrzeżeniem przy każdym starcie, i zostanie usunięty w 8.0.0.
+
+Aby przenieść takie RTE do trybu gniazda, zachowaj jego runner i token:
+
+1. Runner z [config seed](../seed/): najpierw ustaw dla niego w seedzie `rte_mode: outbound` lub `rte_mode: inbound` (przychodzący: z
+   adresem, pod który łączy się aplikacja, w `url` jego poświadczenia). RTE nie może samo przenieść runnera z seeda
+2. Na RTE ustaw `RTE_MODE=outbound` z `APP_URL` albo `RTE_MODE=inbound` (z `APP_URL` i `RTE_URL`, aby wykonało swoje jedno
+   wywołanie rejestracji) i ustaw [`RTE_NAME`](../customization/server.html#env_RTE_NAME) na nazwę, jaką ma jego runner w
+   **Połączenia > Runnery**. Zachowaj jego `RTE_TOKEN`
+3. Usuń `DB_*` i `ENCRYPTION_SECRET` z jego środowiska oraz `RTE_REGISTER`, które odczytuje tylko tryb bazy danych, a potem je zrestartuj
+
+Gdy zaktualizowane RTE zaloguje się nazwą runnera i własnym tokenem runnera, aplikacja od razu przenosi ten runner do trybu RTE,
+bez zatwierdzania, i zapisuje w dzienniku *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. Runner nie jest już wierszem zarejestrowanym przez swoje RTE, więc worker nigdy go nie usuwa, gdy stary kontener przestaje odpowiadać.
+Runner z config seed, który nadal jest w trybie bazy danych, jest natomiast odrzucany, z *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. Nie używaj do tego tokenu dołączenia: token dołączenia
+jest odrzucany dla runnera, który jest już zatwierdzony. RTE w trybie przychodzącym bez `APP_URL` nie wykonuje żadnego wywołania: ustaw zamiast tego **Tryb** jego runnera na
+**Przychodzący** w **Połączenia > Runnery**, a aplikacja się z nim połączy. [Instalator](../installation/installer.html#a-72-runner)
+aktualizuje w ten sposób runner z wersji 7.2.
+
+---
+
+## Co przechodzi przez gniazdo
+
+W obu trybach gniazda aplikacja wysyła RTE każde zadanie ze wszystkim, co RTE wcześniej czytało w bazie danych, i zapisuje to, co wraca:
+wynik, zdarzenia, dziennik zadania i zakończenie, dokładnie raz. Aplikacja wysyła też powiadomienia o zakończeniu.
+
+**Spool.** Każda paczka wyniku, paczka zdarzeń, dziennik, start i zakończenie są numerowane i zapisywane w pliku spoola zadania
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)), zanim zostaną wysłane, i przechowywane, dopóki aplikacja nie potwierdzi ich zapisania.
+Po ponownym połączeniu, z tym samym węzłem aplikacji lub innym, RTE wysyła ponownie to, co nie zostało potwierdzone, a aplikacja pomija to, co już
+zapisała: nic nie ginie i nic nie jest zapisane dwukrotnie. Trzymaj spool na wolumenie, żeby RTE, które się restartuje, nadal wysłało to, czego nie
+dostarczyło. Playbook, który działał, gdy RTE się zrestartowało, nie może kontynuować: jego zadanie kończy się jako porzucone.
+
+**Pojemność.** RTE uruchamia naraz do [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooków albo tyle, ile ustawiono
+na jego [stronie runnera](../runners/runner-page.html#an-rtes-settings), i co 20 sekund mówi aplikacji, ile ich działa. Zadanie dla pełnego
+RTE czeka, jak opisano w [Kilka RTE](several.html#several-jobs-on-one-rte).
+
+**Pliki zadania.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES) albo ustawienie **Pliki zadań** na stronie jego runnera mówi,
+skąd RTE bierze playbooki i inwentarze:
+
+| `RTE_FILES` | Skąd pochodzą pliki |
+|---|---|
+| `transfer` (domyślnie) | Aplikacja wysyła folder playbooków i inwentarze z zadaniem, każde spakowane i nazwane hashem swojej zawartości. RTE trzyma je spakowane w [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), ostatnio używane do [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (domyślnie 1024 MB), i prosi tylko o hash, którego nie ma: niezmieniony folder nigdy nie jest wysyłany dwa razy. RTE nie potrzebuje współdzielonego dysku ani dostępu do repozytoriów |
+| `local` | RTE działa z własnych folderów, jak RTE w trybie bazy danych: zamontuj na nim playbooki ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) i repozytoria ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) |
+
+Przy `transfer` każde zadanie rozpakowuje swoje pliki we własnym prywatnym folderze, usuwanym po zakończeniu zadania: żadne zadanie nie widzi tego, co zapisało inne,
+i żaden plik inwentarza ani extravars nie zostaje rozpakowany na dysku RTE. RTE mogą współdzielić jeden `RTE_CACHE_PATH`; każde trzyma swoje zadania w
+osobnym folderze, a folder RTE, które się zatrzymało (zabite w trakcie zadania lub odtworzone z inną nazwą hosta), pozostałe usuwają
+po 10 minutach. Folder większy niż [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (domyślnie 512, odczytywane przez
+aplikację, stosowane bez restartu) nie jest wysyłany: zadanie kończy się błędem z informacją, by zamiast tego zamontować folder na RTE. Folder ssh nigdy nie jest wysyłany: RTE trzyma własny
+klucz prywatny i `known_hosts` w `/home/node/.ssh`.
+
+**Hosty i zadania.** Od wersji 7.3.0 RTE w każdym trybie zapisuje strukturalne zdarzenia playbooka obok jego wyniku tekstowego: każdy play, task i
+wynik hosta oraz podsumowanie, zapisywane przez jego wtyczkę callback `af_events`. Strona zadania pokazuje je w **Hosty i zadania** (zobacz
+[Śledzenie zadania](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Sieć
+
+Co otworzyć między aplikacją, RTE i zarządzanymi hostami, w zależności od trybu:
+
+| Tryb | Skąd | Dokąd | Port |
+|---|---|---|---|
+| Wychodzący | RTE | Aplikacja, pod `APP_URL` | Port aplikacji (`443` za większością proxy) |
+| Przychodzący | Węzły aplikacji | RTE, pod adresem jego runnera | `PORT` RTE (`8000`) |
+| Baza danych (przestarzały) | RTE oraz węzły aplikacji i worker | Baza danych oraz RTE | `3306` i `PORT` RTE |
+| Każdy tryb | RTE | Zarządzane hosty | ssh (`22`), WinRM, ich API |
+
+W trybie gniazda RTE nigdy nie łączy się z bazą danych. Jego API odpowiada tylko gniazdu i sondom: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/pl/_configure/rte/run.md b/i18n/pl/_configure/rte/run.md
new file mode 100644
index 0000000..a325964
--- /dev/null
+++ b/i18n/pl/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Uruchamianie RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Uruchamianie RTE
+{: .no_toc }
+
+Ustawienia każdego trybu i jak uruchomić RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ustawienia
+
+To, czego potrzebuje RTE, zależy od jego trybu (zobacz [Tryby](modes.html)). Każde RTE odczytuje te zmienne:
+
+| Zmienna | Znaczenie |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Od wersji 7.3.0: `outbound` (łączy się z aplikacją), `inbound` (aplikacja łączy się z nim) lub `database` (przestarzały, domyślny w całej serii 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | Token między aplikacją a RTE, co najmniej 16 znaków; bez niego RTE odmawia startu |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Ile playbooków uruchamia naraz, domyślnie `10` (`0` oznacza brak limitu). Zadanie dla pełnego RTE czeka, aż jakiś playbook się zakończy |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Przy zatrzymaniu: jak długo czeka na działające playbooki, domyślnie `25`; te, które wtedy nadal działają, kończą się jako porzucone |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Odczytywane przez węzły aplikacji i worker, nie przez RTE: jak długo zadanie czeka na pełne lub zatrzymujące się RTE, domyślnie `60` |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | Folder playbooków i limit wyniku: odczytywane przez RTE, więc ustaw je w jego środowisku |
+| `LISTEN_HOST` | Od wersji 7.3.0: adres, na którym nasłuchuje, domyślnie każdy interfejs; `127.0.0.1`, gdy nic nie łączy się z nim z zewnątrz (RTE w trybie wychodzącym) |
+
+RTE w trybie gniazda, `outbound` lub `inbound`, odczytuje też te zmienne, a nie odczytuje żadnych `DB_*` ani `ENCRYPTION_SECRET`:
+
+| Zmienna | Znaczenie |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | Adres aplikacji, pod którym otwierają ją ludzie, np. `https://forms.example.com`. Wychodzący: adres, z którym się łączy. Przychodzący: adres jego jednego wywołania rejestracji |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (domyślnie): certyfikat aplikacji musi być ważny. `0` akceptuje każdy, tylko wewnątrz jednej zaufanej sieci |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | Nazwa jego runnera, którą formularze wskazują przez `runner:`. Nieustawiona: jego id węzła, `rte-<hostname>-<port>`, które zmienia się z kontenerem: ustaw ją w produkcji |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcjonalny, tylko za pierwszym razem: token dołączenia, utworzony przez API, który od razu zatwierdza jego runner, zamiast czekać na admina (zobacz [Tokeny dołączenia](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | W trybie przychodzącym, gdy prosi o dołączenie: adres, pod który łączy się aplikacja, np. `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (domyślnie): aplikacja wysyła playbooki i inwentarze z zadaniem. `local`: działa z własnych zamontowanych folderów |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Gdzie wynik, zdarzenia i zakończenie każdego zadania czekają, aż aplikacja je zapisze, domyślnie `<persistent>/rte-spool`: trzymaj to na wolumenie |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Przy `transfer`: gdzie przechowywane są foldery wysłane przez aplikację, domyślnie `<persistent>/rte-files` |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Przy `transfer`: ile mogą zajmować te foldery, domyślnie `1024`; najdawniej używane idą pierwsze, a `0` nie zachowuje żadnych |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Odczytywane przez aplikację, nie przez RTE: największy folder, jaki wysyła przy `transfer`, domyślnie `512` |
+
+Na RTE w trybie gniazda `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` i `RTE_CACHE_MB` można też ustawić na jego stronie runnera,
+na karcie RTE: wartość tam wygrywa ze zmienną, która wtedy wypełnia tylko pole pozostawione puste (zobacz
+[Ustawienia RTE](../runners/runner-page.html#an-rtes-settings)). Wartość spoza zakresu jest sprowadzana do swojego limitu, a RTE mówi o tym
+przy starcie.
+
+RTE w trybie bazy danych (przestarzałym) odczytuje zamiast tego ustawienia bazy danych i samo się rejestruje:
+
+| Zmienna | Znaczenie |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Te same wartości co w aplikacji: RTE czyta swoje zadania z bazy danych i zapisuje tam ich wynik |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Adres, pod którym aplikacja wywołuje RTE, np. `http://rte:8000`. Runner jest nazywany od swojego hosta (`rte`), więc formularze mogą używać `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Przestarzałe w 7.3.0, razem z trybem bazy danych: RTE w trybie gniazda dołącza zamiast tego tokenem dołączenia. `1` (domyślnie): RTE przy starcie dodaje się w **Połączenia > Runnery**, a pierwsze staje się domyślnym runnerem. `0`: dodaj je tam sam albo w [config seed](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Ta sama wartość co w aplikacji, potrzebna tylko do samodzielnej rejestracji (token runnera jest przechowywany w postaci zaszyfrowanej); pomiń ją przy `RTE_REGISTER=0` |
+
+W trybie bazy danych, bez `RTE_URL`, RTE rejestruje swój adres IP i port pod nazwą `rte-<hostname>-<port>`, które zmieniają się, gdy
+kontener zostanie odtworzony: ustaw `RTE_URL` w produkcji. Worker usuwa runner, który RTE samo zarejestrowało, 10 minut po
+ostatnim sygnale życia RTE.
+
+---
+
+## Uruchom je
+
+RTE uruchamia playbooki, więc potrzebuje swojego folderu ssh, z kluczem prywatnym i `known_hosts`, których używają playbooki, oraz trwałego
+folderu na swój spool i pliki wysyłane przez aplikację. Wybierz tryb:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Wychodzący</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Przychodzący</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Baza danych (przestarzały)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Uruchom RTE na dowolnym hoście, który dociera do aplikacji, z własnym tokenem i nazwą, którą dostanie jego runner:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Łączy się z aplikacją i prosi o dołączenie: **Połączenia > Runnery** pokazuje runner `rte-dmz` jako czekający na zatwierdzenie, a jego dziennik pokazuje
+odcisk jego tokenu. Sprawdź, czy rozpatrzenie pokazuje ten sam odcisk, a potem go **Zatwierdź** (zobacz
+[Zatwierdzanie RTE](../runners/registration.html#approving-an-rte)): od tej pory dostaje zadania, logując się własnym `RTE_TOKEN`.
+Dla startu bez nadzoru dodaj `-e RTE_JOIN_TOKEN=<a join token, afj_...>`, który od razu go zatwierdza. Nic nie musi docierać do tego
+hosta: nie publikuj żadnego portu. Na jego `PORT` nasłuchują tylko `/live`, `/ready` i `/metrics`, dla sond.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Uruchom RTE tam, gdzie dociera do niego aplikacja. To działa obok aplikacji i uruchamia playbooki z jej folderów (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Następnie daj aplikacji jego runner: w [config seed](../seed/) poświadczenie RTE i runner w trybie przychodzącym, który się nim loguje:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Albo dodaj te same dwa elementy ręcznie: poświadczenie w **Połączenia > Poświadczenia**, typ RTE, i runner w
+**Połączenia > Runnery**, typ RTE, tryb **Przychodzący**, z tym poświadczeniem. Aby zamiast tego RTE poprosiło o dołączenie, uruchom je z
+`APP_URL` i `RTE_URL` i zatwierdź je w **Połączenia > Runnery** (zobacz [Przychodzący](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Przestarzałe od wersji 7.3.0 i usunięte w 8.0.0. RTE uruchamia playbooki z własnego dysku, więc zamontuj na nim też trwały wolumen aplikacji
+(playbooki, repozytoria, przesłane pliki) i jej folder ssh. Przykład Docker, z aplikacją osiągalną jako `ansibleforms` w tej samej
+sieci:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Trzymaj RTE w trybie przychodzącym poza siecią publiczną: jego gniazdo odpowiada każdemu, kto ma token. `docker stop` czeka tylko 10 sekund, zanim
+zabije kontener, więc daj RTE dłuższy limit czasu zatrzymania (`--stop-timeout` lub `stop_grace_period` w compose) albo obniż
+`RTE_DRAIN_SECONDS`. Kubernetes domyślnie czeka 30 sekund.
+
+[Instalator](../installation/installer.html) konfiguruje RTE w trybie wychodzącym lub przychodzącym na osobnym serwerze, z Docker, Podman lub
+[bez kontenerów](../installation/native.html), i wypisuje odcisk, po którym należy je zatwierdzić. Aby ręcznie uruchomić RTE w innym centrum danych,
+postępuj zgodnie z [Inne centrum danych](another-datacenter.html).
diff --git a/i18n/pl/_configure/rte/several.md b/i18n/pl/_configure/rte/several.md
new file mode 100644
index 0000000..c8c4035
--- /dev/null
+++ b/i18n/pl/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Kilka RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Kilka RTE
+{: .no_toc }
+
+Ile playbooków uruchamia jedno RTE, kolejne RTE jako runnery lub repliki i co się dzieje, gdy któreś się zatrzyma lub padnie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Kilka zadań na jednym RTE
+
+Jedno RTE uruchamia obok siebie do [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooków, domyślnie 10
+(`0` oznacza brak limitu). Zadanie dla pełnego RTE nie zostaje przejęte. W trybie gniazda aplikacja go nie wysyła, dopóki ostatni
+raport stanu RTE nie pokazuje wolnego miejsca, a RTE, które jest pełne lub się zatrzymuje, odpowiada `refused` jako zajęte; w trybie bazy danych RTE odpowiada
+`503`. W obu przypadkach aplikacja zapisuje raz w wyniku `Waiting for a free slot on RTE <name>` i oferuje zadanie ponownie co 10 sekund,
+najwyżej przez [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) (domyślnie 60). Potem zadanie kończy się błędem
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Zadanie przerwane w trakcie oczekiwania kończy się jako `aborted`, nigdy nie
+docierając do RTE.
+
+---
+
+## Kilka RTE
+
+Aplikacja sama nie rozkłada zadań na runnery: każde zadanie trafia do jednego runnera, tego wskazanego przez formularz albo
+domyślnego. Więcej kontenerów RTE pomaga na dwa sposoby:
+
+* **Jako osobne runnery** : każde RTE ma własne `RTE_NAME` i dołącza jako osobny runner: prosi o dołączenie, a admin
+  je zatwierdza, albo przedstawia token dołączenia (zobacz [Rejestracja](../runners/registration.html)). Formularz wybiera jedno przez `runner: <name>`,
+  np. RTE z kolekcjami VMware albo RTE w innej strefie sieci; pozostałe działają na domyślnym RTE
+* **Jako repliki za jednym adresem** (tylko tryb bazy danych) : kilka kontenerów RTE z tym samym `RTE_URL` i tym samym `RTE_TOKEN`,
+  np. pody za Service Kubernetes, współdzieli jeden runner, a adres rozkłada na nie wywołania. Pełna replika odpowiada
+  `503`, a następna próba może trafić na inną. Aplikacja śledzi zadanie przez bazę danych, więc nie ma znaczenia, która replika
+  odpowiada na wywołania o jego status
+
+W trybie gniazda (zobacz [Tryby](modes.html)) runner trzyma jedno gniazdo do jednego RTE, a drugie RTE, które loguje się tym samym
+`RTE_NAME`, przejmuje gniazdo od pierwszego. Daj każdemu RTE własną nazwę i własny runner i pozwól formularzom wybierać między nimi przez
+`runner:`.
+
+Każde RTE w trybie bazy danych zapisuje sygnał życia w bazie danych co 10 sekund, a takie, które samo się rejestruje, sprawdza swój wiersz runnera co
+30 sekund. Dla RTE w trybie gniazda sygnał życia co 20 sekund zapisuje za nie węzeł aplikacji, który trzyma jego gniazdo, dopóki
+gniazdo jest otwarte. Strona **Stan** wyświetla każde RTE z jego wersją. Worker usuwa runner, który RTE w trybie bazy danych samo zarejestrowało,
+gdy to RTE nie zapisało sygnału życia przez 10 minut, a gdy domyślny runner jest takim wierszem, którego RTE się zatrzymało, następne RTE,
+które sprawdzi, przejmuje rolę domyślnego. Runner z config seed, dodany ręcznie lub dołączony przez gniazdo, nigdy nie jest usuwany w ten sposób.
+
+---
+
+## Gdy RTE się zatrzyma lub padnie
+
+**Gdy RTE się zatrzymuje.** Po `SIGTERM` (`docker stop`, aktualizacja krocząca, zmniejszenie skali) RTE przestaje przyjmować zadania: `/ready` odpowiada `503`,
+a nowe zadanie jest odrzucane jako zajęte (`503` w trybie bazy danych), więc aplikacja czeka albo, w trybie bazy danych, adres wysyła je do innej
+repliki. Działające playbooki dostają [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) na zakończenie, domyślnie 25,
+po czym RTE kończy działanie.
+
+**Gdy RTE pada.** Zabity kontener (brak pamięci, utracony węzeł, koniec limitu czasu zatrzymania) zabiera ze sobą swoje playbooki: nic
+nie przenosi ich do innego RTE i nic nie uruchamia ich ponownie. Ich zadania są kończone jako `abandoned`, przez samo RTE albo przez aplikację, gdy
+wraca pod tym samym id, które zrestartowany kontener zachowuje (`rte-<hostname>-<port>`), albo przez worker, gdy sygnał życia RTE
+ma dwie minuty. Zanim uruchomisz playbook ponownie, sprawdź na zarządzanych hostach, co zrobił.
+
+**Gdy RTE nie działa.** W trybie gniazda nowe zadanie dla niego czeka na jego gniazdo, do `RTE_QUEUE_MINUTES` i jeszcze jednej minuty, a potem
+kończy się błędem *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+W trybie bazy danych kończy się błędem od razu, z *the RTE at ... is unreachable*, chyba że pod jego adresem odpowie inna replika.
diff --git a/i18n/pl/_configure/runners.md b/i18n/pl/_configure/runners.md
new file mode 100644
index 0000000..113a8ce
--- /dev/null
+++ b/i18n/pl/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Runnery
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runnery
+{: .no_toc }
+
+Gdzie działają zadania: kontenery środowiska uruchomieniowego dla playbooków oraz AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins dla szablonów
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: dodaj runnery, na których działają Twoje zadania, wybierz domyślny dla każdego typu, zatwierdzaj RTE, które proszą o dołączenie, i testuj je.
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Strona runnerów](runners/list.html) | Lista runnerów, dodawanie runnera, włączanie i wyłączanie go oraz domyślny runner każdego typu |
+| [Typy runnerów](runners/types.html) | Produkty, którymi może być runner, ich adres i logowanie |
+| [Rejestracja](runners/registration.html) | Jak RTE prosi o dołączenie i jest zatwierdzane, tokeny dołączenia dla instalacji bez nadzoru oraz tryb bazy danych |
+| [Strona runnera](runners/runner-page.html) | Karty runnera, tryb i połączenie RTE oraz Testuj połączenie |
+| [Kto zarządza runnerami](runners/permissions.html) | Kto może dodawać, zmieniać i testować runnery |
+
+
+---
+
+## Jak to działa
+
+Od wersji 7 aplikacja sama niczego nie uruchamia: każde zadanie działa na **runnerze**, dodawanym w **Połączenia > Runnery**.
+Typ formularza decyduje, jakiego typu runnera potrzebuje:
+
+| Typ formularza | Działa na runnerze typu | Co jest uruchamiane |
+|---|---|---|
+| `ansible` | RTE | Playbook, w kontenerze środowiska uruchomieniowego |
+| `awx`, `aap`, `ascender` | AWX (odmiany AWX, AAP i Ascender) | Szablon zadania lub workflow |
+| `semaphore` | Semaphore | Szablon Semaphore UI |
+| `rundeck` | Rundeck | Zadanie Rundeck |
+| `jenkins` | Jenkins | Zadanie Jenkins |
+
+Formularz `workflow` lub `subform` nie ma własnego runnera: każdy węzeł [workflow](workflows/) wybiera własny. Węzeł
+z `runner:` działa na tym runnerze (RTE albo szablon lub zadanie na AWX, Semaphore, Rundeck lub Jenkins), każdy inny na
+domyślnym RTE, więc węzły jednego zadania mogą działać na różnych runnerach. Formularz `multistep`, przestarzały od wersji 7 i
+zastąpiony przez workflowy, działa tak samo: każdy jego krok działa na runnerze, którego potrzebuje jego własny typ.
+
+Formularz wybiera runner na jeden z dwóch sposobów:
+
+- **Po nazwie**: `runner: <name>` w formularzu, w węźle workflow lub w kroku przestarzałego formularza multistep (także w
+  ustawieniach formularza w projektancie). Runner musi być typu, którego potrzebuje formularz, inaczej zadanie kończy się błędem. Starsze `awx: <name>`
+  nadal działa, zapisuje w dzienniku ostrzeżenie o przestarzałości i zniknie w wersji 8.
+- **Jako domyślny**: formularz, który nie wskazuje runnera, działa na domyślnym runnerze swojego typu. Bez niego zadanie kończy się błędem
+  z komunikatem, który mówi, jakiego typu runner trzeba dodać.
+
+Runner wyłączony w **Połączenia > Runnery** nie dostaje żadnych zadań, ani po nazwie, ani jako domyślny: zadanie kończy się błędem z prośbą o jego włączenie
+lub wskazanie innego runnera (zobacz [Domyślny i Włączony](runners/list.html#default-and-enabled)).
+
diff --git a/i18n/pl/_configure/runners/list.md b/i18n/pl/_configure/runners/list.md
new file mode 100644
index 0000000..8d1e89b
--- /dev/null
+++ b/i18n/pl/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: Strona runnerów
+parent: Runnery
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# Strona runnerów
+{: .no_toc }
+
+Lista runnerów, dodawanie runnera, włączanie i wyłączanie go oraz domyślny runner każdego typu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lista
+
+Strona w **Połączenia > Runnery** wyświetla każdy runner z tymi kolumnami:
+
+| Kolumna | Znaczenie |
+|---|---|
+| Włączony | Czy przyjmuje zadania. Wyłączony runner nie dostaje żadnych zadań, nawet jako domyślny dla swojego typu. |
+| Nazwa | Jak odwołują się do niego formularze, przez `runner: <name>`. |
+| Typ | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck lub Jenkins. Domyślny runner swojego typu ma po nim pigułkę **Domyślne**. |
+| Opis | Do czego służy. |
+
+**Kolumny** dodaje dwie kolejne, domyślnie wyłączone: **Tryb**, czyli tryb RTE (Wychodzący, Przychodzący lub Baza danych (przestarzały), zobacz
+[Tryby](../rte/modes.html)), oraz **Połączenie**, czyli czy węzeł aplikacji trzyma gniazdo do RTE w trybie gniazda: **Połączony** lub
+**Niepołączony**.
+
+Od wersji 7.3.0 runnery czekające na zatwierdzenie nie są na liście, tylko w powiadomieniu nad nią, zobacz [Zatwierdzanie RTE](registration.html#approving-an-rte).
+**Dodaj runner** otwiera okno w krokach: **Runner** (nazwa i opis), **Typ** i **Poświadczenia**, z krokiem **Tryb** po
+**Typ** dla RTE (Wychodzący, domyślny dla nowego, Przychodzący lub Baza danych (przestarzały)): cztery kroki dla RTE, trzy dla
+pozostałych. W kroku **Typ** każdy produkt ma podpowiedź: podpowiedź RTE podaje jego pełną nazwę, *Środowisko uruchomieniowe*. Wiersz otwiera własną
+stronę runnera, a jego menu oferuje:
+
+| Akcja | Co robi |
+|---|---|
+| Edytuj | Otwiera jego stronę |
+| Testuj połączenie | Sprawdza, czy odpowiada i akceptuje swoje poświadczenie, zobacz [Testuj połączenie](runner-page.html#test-connection) |
+| Włącz, Wyłącz | Włącza go lub wyłącza, zależnie od stanu |
+| Zmień poświadczenia | Otwiera kartę Poświadczenia na jego stronie |
+| Usuń | Usuwa go |
+
+---
+
+## Domyślny i Włączony
+
+Domyślny runner każdego typu to miejsce, w którym działają formularze tego typu, gdy nie wskazują żadnego runnera:
+
+| Domyślny dla | Gdzie działają te formularze, gdy nie wskazują runnera |
+|---|---|
+| Formularze playbooków | Formularze `ansible`, na RTE |
+| Formularze AWX, AAP i Ascender | Formularze `awx`, `aap` i `ascender`, na runnerze AWX |
+| Formularze Semaphore | Formularze `semaphore` |
+| Formularze Rundeck | Formularze `rundeck` |
+| Formularze Jenkins | Formularze `jenkins` |
+
+Pierwszy runner danego typu staje się domyślnym, więc pojedynczy runner na typ nie wymaga dodatkowego kroku. Aby ustawić inny runner jako domyślny,
+włącz przełącznik **Domyślne** na jego stronie (zobacz [Strona runnera](runner-page.html)).
+
+Wyłączony runner zostaje na liście ze swoimi ustawieniami, ale nie trafia do niego żadne zadanie, także jako domyślnego dla swojego typu. Zadanie dla niego kończy się błędem
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Włączaj go i wyłączaj przez **Włącz** lub **Wyłącz** w menu jego wiersza albo przełącznikiem **Włączony** na jego stronie. Nowy runner jest włączony, a
+runnery istniejące przed wersją 7.3.0 są po aktualizacji włączone. [Config seed](../seed/example.html) może wyłączyć runner przez
+`enabled: false`.
diff --git a/i18n/pl/_configure/runners/permissions.md b/i18n/pl/_configure/runners/permissions.md
new file mode 100644
index 0000000..00c031a
--- /dev/null
+++ b/i18n/pl/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Kto zarządza runnerami
+parent: Runnery
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Kto zarządza runnerami
+{: .no_toc }
+
+Kto może dodawać, zmieniać i testować runnery
+{: .fs-6 .fw-300 }
+
+Runner otrzymuje poświadczenia każdego zadania, które uruchamia, więc tylko rola **admin** dodaje, zmienia, włącza, wyłącza i usuwa runnery
+oraz zatwierdza lub odrzuca RTE, które poprosiło o dołączenie. Użytkownicy z dostępem do ustawień je widzą i mogą je testować, ale nie mogą ich zmieniać.
+
+Runner zadeklarowany w [config seed](../seed/) jest na tej stronie tylko do odczytu: zmień go zamiast tego w pliku seed.
diff --git a/i18n/pl/_configure/runners/registration.md b/i18n/pl/_configure/runners/registration.md
new file mode 100644
index 0000000..af77610
--- /dev/null
+++ b/i18n/pl/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Rejestracja
+parent: Runnery
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Rejestracja
+{: .no_toc }
+
+Jak RTE prosi o dołączenie i jest zatwierdzane, tokeny dołączenia dla instalacji bez nadzoru oraz tryb bazy danych
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Prośba o dołączenie
+
+Od wersji 7.3.0 RTE w trybie gniazda (`outbound` lub `inbound`), którego aplikacja jeszcze nie zna, prosi o dołączenie, a admin je zatwierdza.
+Zgłasza się z własnym `RTE_TOKEN` i swoim `RTE_NAME`: RTE w trybie wychodzącym przy pierwszym połączeniu z aplikacją, w trybie przychodzącym w swoim jednym
+wywołaniu rejestracji. Bez tokenu dołączenia aplikacja wtedy:
+
+1. Zapisuje `RTE_TOKEN` tego RTE w nowym poświadczeniu typu RTE o nazwie `<name>-rte` (z dodaną liczbą, gdy ta nazwa jest zajęta), a
+   dla RTE w trybie przychodzącym także jego adres, `RTE_URL`
+2. Dodaje runner nazwany według `RTE_NAME`, typu RTE, w trybie tego RTE, logujący się tym poświadczeniem, oznaczony jako **Czeka na zatwierdzenie**
+   i wyłączony. Jego opis podaje host, z którego przyszła prośba
+
+RTE w trybie wychodzącym pozostaje połączone, gdy czeka, ale nie dostaje żadnych zadań. Aplikacja nie łączy się z RTE w trybie przychodzącym, dopóki nie zostanie ono zatwierdzone. Oba zapisują
+w dzienniku, że czekają na zatwierdzenie przez admina w **Połączenia > Runnery**, z odciskiem swojego tokenu.
+
+RTE w trybie przychodzącym z `RTE_URL` w postaci `https://` wysyła też swój certyfikat, gdy prosi o dołączenie, a aplikacja go przypina: od tej pory
+aplikacja łączy się z tym RTE tylko wtedy, gdy przedstawia ono ten sam certyfikat, więc samopodpisany działa bez CA (zobacz [Przychodzący](../rte/modes.html#inbound)).
+
+Naraz na zatwierdzenie może czekać najwyżej 20 RTE: kolejne są odrzucane, dopóki część nie zostanie zatwierdzona lub odrzucona. Prośbę, której nikt nie obsłuży w ciągu
+24 godzin, worker usuwa razem z jej poświadczeniem.
+
+RTE nazwane tak jak runner, który aplikacja już zna, ale z innym tokenem, jest odrzucane i nie prosi o dołączenie. Daj mu token tego runnera
+albo usuń runner, żeby RTE poprosiło o dołączenie. [Token dołączenia](#join-tokens) pomaga tylko wtedy, gdy ten runner nadal czeka na zatwierdzenie.
+
+---
+
+## Zatwierdzanie RTE
+
+Runnery czekające na zatwierdzenie znikają z listy w **Połączenia > Runnery** i trafiają do pomarańczowego powiadomienia nad nią, np.
+**2 Runnery czekają na zatwierdzenie**, z wierszem dla każdego runnera: jego nazwą, hostem, adresem IP, trybem, adresem i odciskiem.
+Dzwonek w nagłówku je liczy, dla użytkowników, którzy widzą runnery (zobacz [dzwonek](../jobs/#the-jobs-page)).
+
+Kliknięcie powiadomienia otwiera okno **Rozpatrz zatwierdzenie** dla każdego runnera po kolei; kliknięcie nazwy otwiera tylko ten jeden.
+Jego strona pokazuje te same informacje w żółtym polu, **Ten RTE poprosił o dołączenie**. Zanim go zatwierdzisz, sprawdź, czy to RTE, które sam uruchomiłeś:
+
+| Pole | Co pokazuje |
+|---|---|
+| Odcisk | Pierwsze 8 cyfr szesnastkowych SHA-256 jego `RTE_TOKEN`, jako `abcd-ef12`. RTE zapisuje go przy starcie, a [instalator](../installation/installer.html#a-runner) wypisuje go na końcu. Musi być taki sam |
+| Odcisk certyfikatu | W oknie, dla RTE w trybie przychodzącym przez HTTPS: pierwsze 8 cyfr szesnastkowych SHA-256 certyfikatu, który przypina aplikacja (jego bajtów DER), jako `abcd-ef12`. RTE zapisuje go przy starcie, a [instalator](../installation/installer.html#a-runner) wypisuje go na końcu. Musi być taki sam |
+| Host | Host, na którym działa |
+| Adres IP | Adres, z którego wywołało aplikację |
+| Tryb | Wychodzący lub Przychodzący |
+| Uri | Adres RTE w trybie przychodzącym, pod który łączy się aplikacja |
+| Wersja | Jego wydanie |
+| Poproszono | Kiedy poprosiło o dołączenie |
+
+**Zatwierdź** i **Odrzuć**, w oknie lub w polu na jego stronie, rozstrzygają:
+
+| Akcja | Co się dzieje |
+|---|---|
+| Zatwierdź | Runner jest włączany i od teraz przyjmuje zadania. Staje się domyślnym dla swojego typu, gdy takiego nie ma |
+| Odrzuć | Runner jest usuwany razem z poświadczeniem, a jego gniazdo jest zamykane. RTE może ponownie poprosić o dołączenie; wtedy znów czeka na zatwierdzenie |
+
+Tylko admin zatwierdza lub odrzuca RTE.
+
+---
+
+## Tokeny dołączenia
+
+Token dołączenia od razu zatwierdza RTE, dla instalacji bez nadzoru: RTE uruchomione z
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) albo runner zainstalowany z opcją `--join` instalatora przedstawia go raz
+i jego runner jest dodawany jako włączony, bez czekania. Tokeny dołączenia nie mają strony w interfejsie: admin tworzy je przez
+[REST API](../api/), pod `/api/v2/runner`:
+
+| Wywołanie | Co robi |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Tworzy token dołączenia. Ciało zawiera jego `name` i opcjonalnie `expiresInHours` (brak: nigdy nie wygasa) oraz `maxUses` (brak: dowolna liczba RTE) |
+| `GET /api/v2/runner/jointoken` | Wyświetla tokeny dołączenia, od najnowszego, z ich użyciami i informacją, czy nadal są ważne; nigdy samych tokenów |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Unieważnia go: nie dodaje już żadnego runnera i zostaje na liście |
+| `DELETE /api/v2/runner/jointoken/<id>` | Usuwa go |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+Odpowiedź zawiera token, który zaczyna się od `afj_`, ten jeden raz: przechowywany jest tylko jego SHA-256. RTE, które go przedstawi, dostaje to samo
+poświadczenie i runner co takie, które [prosi o dołączenie](#asking-to-join), włączony, a jego opis wskazuje token dołączenia. Od tej pory
+RTE loguje się własnym tokenem, więc token dołączenia może wygasnąć lub zostać unieważniony bez wpływu na nie. Unieważnienie lub usunięcie tokenu dołączenia
+zostawia runnery, które dodał.
+
+Token dołączenia nigdy nie daje zatwierdzonemu runnerowi nowego tokenu. Gdy runner RTE o tej nazwie już istnieje:
+
+| Runner | Co się dzieje |
+|---|---|
+| Czeka na zatwierdzenie | Dostaje nowy token w swoim poświadczeniu i nadal czeka na zatwierdzenie przez admina |
+| Jest zatwierdzony | Odrzucenie z `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. Token dołączenia nie zostaje zużyty |
+| Pochodzi z [config seed](../seed/) | Odrzucenie: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+RTE zainstalowane ponownie z nowym tokenem loguje się więc tokenem z poświadczenia swojego runnera albo admin zmienia ten token
+w **Połączenia > Poświadczenia**, albo usuwa runner, żeby RTE dołączyło jako nowe.
+
+---
+
+## Rejestracja w trybie bazy danych
+
+RTE w trybie bazy danych, przestarzałym od wersji 7.3.0, domyślnie samo się rejestruje, pod swoim `RTE_URL`, a w przeciwnym razie pod własnym adresem i portem.
+Worker usuwa taki runner, gdy jego RTE nie zapisało sygnału życia przez 10 minut. Runner dodany ręcznie, przez config seed lub przez
+RTE w trybie gniazda nigdy nie jest usuwany w ten sposób.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), który włącza lub wyłącza tę rejestrację, jest przestarzały w 7.3.0 razem z
+trybem bazy danych: RTE w trybie gniazda prosi o dołączenie albo dołącza tokenem dołączenia. Aby w międzyczasie samemu zarządzać takimi runnerami, uruchom
+RTE z `RTE_REGISTER=0` i dodaj je tutaj z typem RTE, trybem **Baza danych (przestarzały)** i poświadczeniem RTE z jego adresem i
+tym samym tokenem. Aby przenieść je do trybu gniazda, zobacz [Tryby](../rte/modes.html#database-deprecated).
diff --git a/i18n/pl/_configure/runners/runner-page.md b/i18n/pl/_configure/runners/runner-page.md
new file mode 100644
index 0000000..72a9f34
--- /dev/null
+++ b/i18n/pl/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "Strona runnera"
+parent: Runnery
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# Strona runnera
+{: .no_toc }
+
+Karty runnera, tryb, połączenie i ustawienia RTE oraz Testuj połączenie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Karty
+
+Strona runnera pokazuje kroki jego okna jako karty, a do tego to, co na nim działa:
+
+| Karta | Co zawiera |
+|---|---|
+| Szczegóły | Nazwę i opis, przełącznik **Domyślne** i przełącznik **Włączony**, takie same dla każdego typu runnera |
+| Typ | Produkt, jak w oknie. Dla RTE także jego **Tryb**: **Baza danych (przestarzały)**, **Przychodzący** lub **Wychodzący**, czyli `RTE_MODE`, z którym działa jego RTE (zobacz [Tryby](../rte/modes.html)) |
+| RTE | Tylko dla RTE: jego **Tryb** opisany słowami, a w trybie gniazda także jego **Połączenie** i ustawienia (zobacz [Ustawienia RTE](#an-rtes-settings)) |
+| Poświadczenia | **Poświadczenie**, którym się loguje, czyli poświadczenie z Połączenia > Poświadczenia typu runnera, które zawiera jego token lub login i adres jego serwera. Poświadczenie RTE zawiera jego `RTE_TOKEN` i adres RTE, chyba że jest w trybie wychodzącym. **Projekt** dla Semaphore, Rundeck i Jenkins |
+| Formularze | Formularze, które na nim działają, i w jaki sposób: **Wskazuje go** lub **Jako domyślny runner**. Wiersz otwiera formularz |
+| Zadania | Ostatnie 100 zadań, które na nim działały, z ich statusem, startem, końcem i czasem trwania. Wiersz otwiera zadanie |
+
+Każda karta ma własny adres, np. `/settings/runners/<id>/rte`, więc link lub zakładka ją otwiera. Runner bez danej karty otwiera się na
+Szczegóły.
+
+Oba przełączniki karty Szczegóły zapisują się od razu. **Domyślne** ustawia runner jako domyślny dla jego typu; wyłącza się go, ustawiając
+inny runner jako domyślny. **Włączony** włącza lub wyłącza runner: wyłączony nie dostaje żadnych zadań, także jako domyślny dla swojego typu (zobacz
+[Domyślny i Włączony](list.html#default-and-enabled)).
+
+RTE, które poprosiło o dołączenie, otwiera się z żółtym polem, **Ten RTE poprosił o dołączenie**, z jego odciskiem i tym, co o sobie podało, oraz z
+**Zatwierdź** i **Odrzuć** (zobacz [Zatwierdzanie RTE](registration.html#approving-an-rte)). Runner z [config seed](../seed/) informuje o tym
+u góry swojej strony i jest tylko do odczytu.
+
+---
+
+## Ustawienia RTE
+
+Karta RTE pozwala zarządzać RTE z aplikacji, bez edytowania jego środowiska na maszynie, na której działa.
+
+**Połączenie.** RTE w trybie gniazda pokazuje plakietkę: **Połączony** lub **Niepołączony**. Po najechaniu **Połączony** pokazuje węzeł aplikacji,
+który trzyma jego gniazdo, wydanie RTE i ile jego zadań działa. **Niepołączony** oznacza, że żaden węzeł aplikacji nie trzyma do niego gniazda:
+sprawdź, czy RTE działa, jego adres lub `APP_URL` oraz jego token.
+
+**Ustawienia.** RTE w trybie wychodzącym lub przychodzącym ma cztery ustawienia, domyślnie puste:
+
+| Ustawienie | Odpowiada | Co robi |
+|---|---|---|
+| Maks. równoczesnych zadań | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Ile playbooków uruchamia naraz, domyślnie `10`; `0` oznacza brak limitu |
+| Pamięć podręczna plików | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Ile plików zadań wysłanych przez aplikację przechowuje, w MB, domyślnie `1024`; `0` nie przechowuje żadnych |
+| Czas oczekiwania przy zatrzymaniu | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Jak długo zatrzymywane RTE czeka na działające playbooki, domyślnie `25` sekund |
+| Pliki zadań | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Transfer**: aplikacja wysyła pliki zadania razem z zadaniem. **Lokalnie**: działa z własnych zamontowanych folderów |
+
+**Która wartość wygrywa.** Wartość na stronie wygrywa z tą samą zmienną ustawioną na RTE. Pole pozostawione puste używa własnej zmiennej RTE,
+a w przeciwnym razie wartości domyślnej. Pod każdym polem strona mówi, która to: **Zastępuje RTE_MAX_JOBS ustawioną na RTE (3)** albo **Puste: RTE używa
+własnej RTE_MAX_JOBS, 3**; tekst zastępczy pokazuje wartość, którą oznacza puste pole.
+
+**Jak docierają do RTE.** Ustawienia są przechowywane razem z runnerem w bazie danych aplikacji. Aplikacja wysyła je przez gniazdo RTE,
+gdy się ono połączy i przy każdym ich zapisaniu, a RTE od razu je stosuje: mniejsza pamięć podręczna jest przycinana, nowy limit liczy się od
+następnego zadania. RTE trzyma je tylko w pamięci i nie zapisuje żadnego pliku: po restarcie dostaje je ponownie przy połączeniu, przed pierwszym zadaniem.
+
+RTE w trybie bazy danych (przestarzałym) nie ma gniazda: odczytuje te ustawienia z własnych zmiennych, o czym informuje karta.
+
+---
+
+## Testuj połączenie
+
+Przyciski w prawym górnym rogu działają na runnerze w zapisanej postaci.
+
+Obok **Zapisz** są **Testuj połączenie** i **Usuń**, a na karcie Poświadczenia **Dodaj poświadczenie**, które tworzy poświadczenie
+typu runnera i je wybiera. Token ani hasło po zapisaniu nigdy nie są już pokazywane: zmieniaj je w poświadczeniu.
+
+**Testuj połączenie** sprawdza, czy runner odpowiada i akceptuje swój token lub login, i mówi o tym w komunikacie: **Runner connection is
+OK** albo dlaczego się nie udało. Nie uruchamia żadnego zadania. Dla RTE sprawdza też kontrakt, którym mówi RTE (zobacz
+[Kontrakt](../rte/images.html#the-contract)):
+
+| RTE | Co odczytuje test | Kiedy się nie udaje |
+|---|---|---|
+| Wychodzący lub przychodzący | Kto trzyma jego gniazdo, według zapisu każdego węzła aplikacji, i co RTE podało przy połączeniu. Niczego nie wywołuje | Żaden węzeł aplikacji nie trzyma do niego gniazda: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, a dla RTE w trybie przychodzącym *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Albo RTE mówi innym kontraktem niż 3 |
+| Baza danych (przestarzały) | `/rte/v1/health` RTE, wywoływane z jego tokenem | RTE nie odpowiada pod swoim adresem, odrzuca token lub mówi innym kontraktem niż 2 |
+
+Plakietka **Połączenie** na karcie RTE pokazuje ten sam stan gniazda bez testu.
diff --git a/i18n/pl/_configure/runners/types.md b/i18n/pl/_configure/runners/types.md
new file mode 100644
index 0000000..de1d7c4
--- /dev/null
+++ b/i18n/pl/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Typy runnerów
+parent: Runnery
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Typy runnerów
+{: .no_toc }
+
+Produkty, którymi może być runner, ich adres i logowanie
+{: .fs-6 .fw-300 }
+
+Krok **Typ** oferuje jeden wybór na produkt, każdy z podpowiedzią; podpowiedź RTE rozwija jego nazwę, *Środowisko uruchomieniowe*. AAP i
+Ascender są zapisywane jako runner typu `awx` z odmianą (`aap` lub `ascender`), której używa też config seed:
+
+| Typ | Przykład Uri | Projekt | Uwierzytelnianie |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | `RTE_TOKEN` tego RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Token API lub użytkownik i hasło |
+| Ascender | `https://ascender.example.com/api/v2` | | Token API lub użytkownik i hasło |
+| AWX | `https://awx.example.com/api/v2` | | Token API lub użytkownik i hasło |
+| Jenkins | `https://jenkins.example.com` | Folder, w którym są zadania (opcjonalnie) | Użytkownik i token API tego użytkownika |
+| Rundeck | `https://rundeck.example.com` | Nazwa projektu | Token API użytkownika |
+| Semaphore | `https://semaphore.example.com` | Id projektu, liczba w `/project/<id>` | Token API użytkownika |
+
+Adres AWX, AAP lub Ascender zawiera ścieżkę API: `/api/v2` lub `/api/controller/v2` dla AAP 2.5 i nowszych.
+RTE to obraz AnsibleForms uruchomiony z `AF_ROLE=rte`; jak je uruchomić, opisuje strona
+[Środowiska uruchomieniowe](../rte/).
diff --git a/i18n/pl/_configure/secret-stores/cyberark.md b/i18n/pl/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..180084b
--- /dev/null
+++ b/i18n/pl/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Magazyny sekretów
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Odczytuj poświadczenia z CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Eksperymentalne.** Jeszcze nie przetestowane z działającą instalacją CyberArk; zgłoś swoje obserwacje.
+
+CCP to interfejs REST Application Access Manager firmy CyberArk.
+
+---
+
+## Pola magazynu
+
+Oprócz [pól, które ma każdy magazyn](./#adding-a-store), magazyn CyberArk ma te pola:
+
+| Pole | Znaczenie |
+|---|---|
+| Poświadczenie | Poświadczenie **CyberArk** z [Połączenia > Poświadczenia](../credentials.html): bazowy URL CCP, np. `https://ccp.example.com` (dopisywane jest `/AIMWebService/api/Accounts`), jego ustawienia TLS, jego AppID (aplikacja zdefiniowana dla AnsibleForms w CyberArk) oraz certyfikat klienta i klucz w PEM, tylko gdy AppID tego wymaga. |
+
+---
+
+## Odwołanie do sekretu
+
+Odwołanie do sekretu identyfikuje konto jako pary klucz-wartość oddzielone `;`:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Dozwolone klucze: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` przekazuje resztę odwołania jako natywne zapytanie CCP, z `QueryFormat=Exact`,
+  chyba że ustawisz inaczej.
+- `AppID` w odwołaniu jest ignorowany: zawsze używany jest AppID magazynu.
+- Hasło konta (`Content`) staje się hasłem; `UserName`, `Address`, `Port` i
+  `Database` wypełniają użytkownika, host, port i nazwę bazy danych.
+
+---
+
+## Dodatkowe opcje
+
+Dodatkowe opcje magazynu ustawia się jako obiekt JSON:
+
+| Klucz | Znaczenie |
+|---|---|
+| `reason` | Wysyłany jako `Reason`, gdy odwołanie go nie ma, dla audytu CyberArk. |
+| `check_ref` | Odwołanie, które **Testuj połączenie** faktycznie odczytuje. Bez niego test sprawdza tylko, czy CCP odpowiada i akceptuje AppID. |
+| `timeout_ms` | Limit czasu żądania, domyślnie 10000. |
+
+Na przykład, aby wysyłać przyczynę i pozwolić **Testuj połączenie** odczytać konto testowe:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/pl/_configure/secret-stores/hashicorp-vault.md b/i18n/pl/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..a18f52c
--- /dev/null
+++ b/i18n/pl/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Magazyny sekretów
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Odczytuj poświadczenia z HashiCorp Vault, z KV v1 lub v2 albo z silnika sekretów dynamicznych
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pola magazynu
+
+Oprócz [pól, które ma każdy magazyn](./#adding-a-store), magazyn HashiCorp Vault ma te pola:
+
+| Pole | Znaczenie |
+|---|---|
+| Poświadczenie | Poświadczenie **HashiCorp Vault** z [Połączenia > Poświadczenia](../credentials.html): adres Vault, jego ustawienia TLS i token jako hasło, z prawem odczytu ścieżek, których używają Twoje poświadczenia. **Dodaj poświadczenie** tworzy poświadczenie tego typu. AnsibleForms nie odnawia tokenu. |
+| Przestrzeń nazw | Przestrzeń nazw Vault Enterprise, wysyłana jako `X-Vault-Namespace`. Widoczna po włączeniu **Vault Enterprise** w kroku **Typ**. |
+| Wersja KV | `2` (domyślnie) lub `1`. |
+| Domyślny punkt montowania | Używany dla odwołania bez ukośnika, np. `myapp` staje się `secret/data/myapp`. |
+
+Odwołanie do sekretu to ścieżka, np. `secret/myapp/prod`. Dla KV v2 segment `/data/`
+jest wstawiany, gdy go pominiesz.
+
+---
+
+## Dynamiczne poświadczenia bazy danych
+
+Odwołanie w postaci `<mount>/creds/<role>`, np. `database/creds/readonly`, odczytuje z
+silnika sekretów dynamicznych, takiego jak silnik bazy danych Vault. Vault tworzy wtedy nowe konto bazy danych
+przy każdym odczycie, ważne przez czas dzierżawy (lease).
+
+- Konto jest ponownie używane przez 80% swojej dzierżawy, a nie przez czas pamięci podręcznej; przy pamięci podręcznej `0` każde zapytanie odczytuje nowe.
+- Vault zwraca tylko użytkownika i hasło: resztę połączenia umieść w wierszu poświadczenia.
+- Dzierżawa nigdy nie jest unieważniana przedwcześnie; konto wygasa, gdy Vault kończy dzierżawę.
diff --git a/i18n/pl/_configure/secret-stores/index.md b/i18n/pl/_configure/secret-stores/index.md
new file mode 100644
index 0000000..8d6a84e
--- /dev/null
+++ b/i18n/pl/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Magazyny sekretów
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Magazyny sekretów
+{: .no_toc }
+
+Odczytuj poświadczenia z menedżera sekretów zamiast przechowywać je w AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: podłącz menedżer sekretów i pozwól poświadczeniom odczytywać z niego użytkownika i hasło.
+
+---
+
+## Jak to działa
+
+**Magazyn sekretów** to połączenie z menedżerem sekretów, dodawane w
+**Połączenia > Magazyny sekretów**. **Poświadczenie** może wtedy wskazać magazyn i miejsce w nim
+(*odwołanie do sekretu*). Gdy formularz, playbook lub wyrażenie używa tego poświadczenia:
+
+- **użytkownik** i **hasło** są odczytywane z magazynu za każdym razem (w granicach czasu pamięci podręcznej magazynu);
+- **host**, **port** i **baza danych** pozostają te z wiersza poświadczenia. Gdy wiersz zostawia
+  któreś z nich puste, a sekret je zawiera, używana jest wartość z sekretu.
+
+Formularze nadal odwołują się do poświadczenia po nazwie, więc przeniesienie hasła do magazynu niczego
+nie zmienia w Twoich formularzach.
+
+| Typ magazynu | Status |
+|---|---|
+| HashiCorp Vault (KV v1 i v2, uwierzytelnianie tokenem) | dostępny |
+| Dynamiczne poświadczenia HashiCorp Vault (`<mount>/creds/<role>`) | eksperymentalny |
+| CyberArk Central Credential Provider (CCP) | eksperymentalny |
+
+---
+
+## Dodawanie magazynu
+
+Od wersji 7.3.0 tylko admin może dodać, zmienić lub usunąć magazyn, bo jego token lub klucz jest wysyłany na jego adres. Każdy magazyn ma te pola:
+
+| Pole | Znaczenie |
+|---|---|
+| Nazwa | Jak poświadczenia odwołują się do magazynu. |
+| Typ | Menedżer sekretów. |
+| Poświadczenie | Jak i gdzie loguje się magazyn: poświadczenie z [Połączenia > Poświadczenia](../credentials.html), w kroku **Poświadczenia**, typu **HashiCorp Vault** (jego token i adres) lub **CyberArk**. Zawiera bazowy URL, np. `https://vault.example.com:8200`, i ustawienia TLS: pominięcie weryfikacji certyfikatu albo pakiet CA w PEM dla prywatnego CA. Samo nie może odczytywać z magazynu sekretów. |
+| Pamięć podręczna (sekundy) | Jak długo odczytany sekret jest ponownie używany. `0` odczytuje go przy każdym użyciu. Domyślnie 60. |
+| Dodatkowe opcje (JSON) | Opcje specyficzne dla typu, jako obiekt JSON. |
+
+Do wersji 7.2.0 adres, token i ustawienia TLS były polami magazynu. Aktualizacja do 7.3.0 przenosi je do jego
+poświadczenia o nazwie `<store>-token` (lub `<store>-appid` dla CyberArk), zobacz [Adresy w poświadczeniach](../credentials/types.html#addresses-in-credentials).
+
+**Testuj połączenie** sprawdza dostęp bez odczytywania sekretu. Strona **Stan** sprawdza każdy magazyn i ostrzega 7 dni
+przed wygaśnięciem tokenu Vault.
+
+Każdy menedżer sekretów ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 i v2 z uwierzytelnianiem tokenem oraz dynamiczne poświadczenia bazy danych |
+| [CyberArk](cyberark.html) | Central Credential Provider (CCP) z Application Access Manager firmy CyberArk |
+
+---
+
+## Używanie magazynu
+
+### W poświadczeniu
+
+W **Połączenia > Poświadczenia**, w kroku **Magazyn** poświadczenia, wybierz **Magazyn sekretów**, a potem wskaż
+**Magazyn sekretów** i wypełnij **Odwołanie**. Użytkownik i hasło są wtedy odczytywane z magazynu, a nie wpisywane.
+
+### Bezpośrednio, bez wiersza poświadczenia
+
+Wszędzie tam, gdzie przyjmowana jest nazwa poświadczenia, możesz zamiast tego odwołać się bezpośrednio do magazynu (`fnCredentials`, `fnRestBasic`,
+`credentials:` formularza, `dbConfig` zapytania).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Bez wiersza poświadczenia sekret bazy danych potrzebuje co najmniej `db_type` i hosta, na przykład:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Bez `db_type` sekret jest zwykłym poświadczeniem (użytkownik, hasło i dowolne inne klucze), a zapytanie na nim zakłada `mysql`.
+
+### Nazwy kluczy
+
+Sekret jest mapowany na poświadczenie przez te aliasy. Pozostałe klucze są przekazywane dalej.
+
+| Pole poświadczenia | Akceptowane klucze w sekrecie |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | ta sama nazwa (tylko sekrety bezpośrednie) |
+
+Dla wiersza poświadczenia host, port i nazwa bazy danych z sekretu są używane tylko tam, gdzie
+wiersz zostawia je puste.
+
+Sekret o innej strukturze można przekształcić wyrażeniem `jq`, przekazanym jako trzeci argument
+`fnCredentials`:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## W config seed
+
+Magazyny można też deklarować w config seed, jak pozostałe obiekty administracyjne:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+Magazyn loguje się swoim poświadczeniem: poświadczenie `vault` zawiera adres Vault w `url` i token jako hasło, poświadczenie `cyberark`
+AppID i adres CCP. Bez poświadczenia używane są własne `url` i `token` magazynu.
+Szczegóły opisuje strona [Config seed](../seed).
+
+---
+
+## Aktualizacja ze zmiennych VAULT_*
+
+Przed wersją 7 jedynym magazynem był HashiCorp Vault konfigurowany zmiennymi środowiskowymi `VAULT_*`,
+a poświadczenie wskazywało na niego przez **Vault path**.
+
+- **Zmienne są importowane jednorazowo** jako magazyn o nazwie `vault`; potem je usuń.
+- **Poświadczenia z `vault_path`** używają teraz tego magazynu; `vault_path` zniknie w wersji 8.
diff --git a/i18n/pl/_configure/security/hardening.md b/i18n/pl/_configure/security/hardening.md
new file mode 100644
index 0000000..6d5e014
--- /dev/null
+++ b/i18n/pl/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Utwardzanie
+parent: Bezpieczeństwo
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Utwardzanie
+{: .no_toc }
+
+Konto admina, limity logowania, baza danych, wyrażenia, dane zadań, polityka przeglądarki, funkcje opcjonalne i opcje ról
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Konto admina
+
+Lokalne konto admina jest tworzone przy pierwszym uruchomieniu z [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+i [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), którego wartość domyślna to `AnsibleForms!123`.
+
+* Logowanie publicznym hasłem domyślnym `AnsibleForms!123` wymusza najpierw jego zmianę: do tego czasu serwer odpowiada
+  na każde żądanie poza zmianą hasła kodem `403` (kod `password_change_required`), a przeglądarka pokazuje
+  stronę zmiany hasła, której nie da się zamknąć. Nowe hasło nie może być ponownie domyślnym.
+* `ADMIN_PASSWORD` jest odczytywane tylko przy pierwszym tworzeniu konta: ustaw własną wartość przed pierwszym uruchomieniem.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` resetuje hasło do `ADMIN_PASSWORD` przy każdym
+  uruchomieniu. Używaj tego tylko do odzyskania utraconego hasła, potem usuń zmienną i uruchom ponownie.
+* Najpierw ustaw dwa główne sekrety: zobacz [Sekrety i szyfrowanie](secrets.html).
+* Gdy logowanie przez LDAP lub SSO działa, zostaw lokalnego admina tylko na sytuacje awaryjne, z długim hasłem przechowywanym w Twoim sejfie.
+
+---
+
+## Limity logowania i hasła
+
+Odgadywanie haseł spowalniają trzy limity. Niepowodzenia są liczone w bazie danych, więc każdy węzeł aplikacji widzi te
+same próby, a każdy limit działa bez restartu:
+
+| Zmienna | Domyślnie | Co robi |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Po tylu nieudanych logowaniach konto lokalne lub LDAP jest blokowane na `LOGIN_LOCKOUT_MINUTES`. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Adres z tyloma nieudanymi logowaniami w ciągu `LOGIN_LOCKOUT_MINUTES` jest wstrzymywany do końca tego okna: jeden adres próbujący wielu kont. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Jak długo konto pozostaje zablokowane i okno, w którym liczone są niepowodzenia. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Żądania na minutę z jednego adresu, na węzeł aplikacji, do logowania, wylogowania, odświeżania tokenu i wywołań zwrotnych logowania jednokrotnego. |
+
+Zablokowane konto lub wstrzymany adres dostaje `429` z nagłówkiem `Retry-After`, zanim jakiekolwiek hasło zostanie sprawdzone, i
+niezależnie od tego, czy konto istnieje; powyżej `AUTH_RATE_LIMIT` odpowiedzią też jest `429`. Udane logowanie zeruje
+licznik konta, podobnie jak ustawienie hasła użytkownika przez admina. `0` wyłącza limit; `LOGIN_LOCKOUT_MINUTES=0`
+wyłącza zarówno blokadę, jak i limit na adres.
+
+`LOGIN_MAX_FAILURES_PER_IP` i `AUTH_RATE_LIMIT` liczą na adres klienta: za reverse proxy ustaw `TRUST_PROXY`,
+żeby adres był adresem klienta, a nie proxy, zobacz [Adresy klientów](../production/reverse-proxy.html#client-addresses).
+
+Lokalne hasło ustawiane przez aplikację, dla nowego użytkownika, przez admina lub przez użytkowników zmieniających własne, musi mieć
+co najmniej [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) znaków (domyślnie `8`,
+`0` nie sprawdza długości). Nie może być nazwą użytkownika ani publicznym hasłem domyślnym. `ADMIN_PASSWORD` nie jest sprawdzane.
+
+---
+
+## Baza danych
+
+AnsibleForms przechowuje każde poświadczenie i zadanie w swojej bazie danych MySQL, więc trzymaj tę bazę danych poza siecią:
+
+* Projekt docker-compose publikuje MySQL na hoście (`MYSQLDB_LOCAL_PORT`, `3306`) i jest dostarczany z hasłem root
+  `AnsibleForms!123`. Usuń to mapowanie portu lub powiąż je z `127.0.0.1` i zmień hasło.
+* Łącz się dedykowanym kontem zamiast `root`, ustawionym w [`DB_USER`](../customization/server.html#env_DB_USER) i
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Potrzebuje ono uprawnień tylko do schematu `AnsibleForms`:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Obejmuje to tworzenie schematu (łącznie z `CREATE DATABASE`), łatanie go przy aktualizacjach oraz
+  [kopie zapasowe](../production/backups.html) i przywracanie, które działają jako ten sam użytkownik: zrzut jest wykonywany z
+  `--no-tablespaces`, więc żadne globalne uprawnienie, takie jak `PROCESS`, nie jest potrzebne. Tam, gdzie to możliwe, zastąp `%` adresem
+  aplikacji. Użytkownik z uprawnieniami do każdej bazy danych, jak `root`, zamienia lukę w aplikacji w
+  lukę w całym serwerze baz danych: strona **Stan** ostrzega o tym w teście **Użytkownik bazy danych**, a dziennik
+  przy każdym starcie.
+* Ustaw [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) na `0`, gdy schemat już istnieje.
+  Tworzenie schematu najpierw usuwa każdą tabelę; przy `0` nie może go uruchomić ani bootstrap przy starcie, ani endpoint
+  `/api/v2/schema`.
+
+---
+
+## Wyrażenia i wywołania wychodzące
+
+Wyrażenia serwerowe działają na serwerze dla każdego zalogowanego użytkownika, więc sanitizer i filtry wychodzące mają znaczenie:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` lub `paranoid`, nigdy `legacy`, które pozwala użytkownikom uruchamiać kod serwera.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : hosty, do których wyrażenia REST nie mogą docierać, np. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : gdy jest ustawiona, wyrażenia REST mogą docierać
+  tylko do tych hostów i zakresów. Lista zabronionych wygrywa z nią.
+
+Obie listy obejmują tylko funkcje pomocnicze REST samego AnsibleForms; playbooki działają poza nimi i nie są filtrowane.
+
+Od wersji 7.3.0 funkcje pomocnicze REST sprawdzają certyfikat endpointu, jak każde inne połączenie.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` wyłącza sprawdzanie: używaj tego tylko dla
+endpointów z certyfikatem samopodpisanym.
+
+---
+
+## Dane zadań
+
+Extravars i wynik zadań są przechowywane w bazie danych i pokazywane każdemu, kto widzi zadanie:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : extravars, których klucz pasuje, są
+  pokazywane jako `********`. Domyślnie `password|secret|token`; pola haseł są zawsze maskowane. Rozszerz je o
+  nazwy używane przez Twoje formularze, np. `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : przycina obiekt `ansibleforms_user`
+  wysyłany z każdym zadaniem, który w przeciwnym razie zawiera całe członkostwo użytkownika w grupach.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) ukrywa tylko hałaśliwe taski; sekrety ukrywaj przez `no_log`.
+
+---
+
+## Content-Security-Policy
+
+Interfejs jest udostępniany z nagłówkiem Content-Security-Policy, który ogranicza, co strona może wczytać i uruchomić w przeglądarce:
+
+* Skrypty pochodzą wyłącznie z samej aplikacji, więc skrypt wstrzyknięty do strony się nie uruchomi.
+* Żadna inna witryna nie może wyświetlać interfejsu w ramce.
+* Pozwala na to, czego potrzebuje aplikacja: lokalne wyrażenia formularzy obliczane w przeglądarce (`'unsafe-eval'`), style
+  inline, obrazy z dowolnego URL (obrazy formularzy i kategorii) oraz workery edytora kodu.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) domyślnie ma wartość `1` i tak powinno
+zostać. Przy `0` polityka jest wysyłana jako `Content-Security-Policy-Report-Only`: konsola przeglądarki wyświetla, co by
+zablokowała, i nic nie jest blokowane. Używaj `0` tylko dla konfiguracji, która jeszcze nie działa z polityką, np. reverse proxy,
+które wstrzykuje własny skrypt. Zmiana na stronie ustawień działa bez restartu.
+
+---
+
+## Strony ustawień i projektant
+
+Administratorzy mogą zmieniać dużą część konfiguracji z przeglądarki. Zawęź to, gdy konfiguracja jest przechowywana gdzie indziej:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : ustawienia tylko do odczytu, dla [zarządzanego środowiska](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : usuwa wbudowanego projektanta, gdy formularze
+  są utrzymywane w gicie.
+
+---
+
+## Funkcje opcjonalne
+
+Te funkcje są domyślnie wyłączone. Włączaj je tylko wtedy, gdy z nich korzystasz; zmiana na stronie ustawień działa bez restartu:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : udostępnia [serwer MCP](../mcp/) pod `/api/v2/mcp`,
+  dzięki czemu klienci MCP mogą uruchamiać formularze tokenem użytkownika.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : [asystent czatu](../chat/). Definicje formularzy
+  i wypełniane wartości są wysyłane do skonfigurowanego dostawcy modelu.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) działa odwrotnie: domyślnie ma wartość `enforce`,
+więc serwer odrzuca uruchomienie, którego wartości łamią reguły formularza, także uruchomienia przez REST API.
+Zostaw tak: `log` tylko zapisuje w dzienniku to, co zostałoby odrzucone, a `off` niczego nie sprawdza, zobacz [Walidacja uruchomień](../launch-validation/).
+
+---
+
+## Opcje ról
+
+Niektóre opcje ról w [config.yaml](../config/roles.html) dają więcej, niż sugeruje ich nazwa. Nadawaj je ostrożnie:
+
+| Opcja | Dlaczego ma znaczenie |
+|--------|----------------|
+| `allowScheduledJobs` | Użytkownik z tą opcją widzi i może zmieniać każdy harmonogram, a harmonogram działa z uprawnieniami admina, dla dowolnego formularza. Traktuj ją jak opcję na poziomie admina. |
+| `allowBackupOps` | Obejmuje **przywracanie**, które zastępuje całą bazę danych. |
+| `showSettings` | Otwiera strony administracyjne. Bez roli admin nie pozwala zmieniać kont i grup wskazanych przez rolę admin, zobacz [Użytkownicy i grupy](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Pokazuje dziennik serwera, który może zawierać nazwy hostów, nazwy użytkowników i szczegóły błędów. |
+| `showConnectionsSettings` | Otwiera strony połączeń: poświadczenia, runnery, kanały powiadomień i inne. Dodawanie, zmiana i usuwanie runnerów i magazynów sekretów pozostają w gestii admina, tak samo jak poświadczenia połączeń i logowań. W przypadku repozytorium dodawanie go lub usuwanie oraz zmiana jego adresu, gałęzi lub flag `use_for_*` pozostają w gestii admina. |
+| `showAllJobLogs` | Pokazuje zadania każdego użytkownika, nie tylko własne. |
+| `manageAllJobs` | Przerywa, usuwa i ponownie uruchamia zadania każdego użytkownika. |
+| `allowApiTokens` | Pozwala użytkownikowi tworzyć tokeny API, które żyją do [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (domyślnie 90). Wylogowanie tokenem lub jego unieważnienie go kończy, a zmiana hasła kończy wszystkie tokeny użytkownika, zobacz [Tokeny](secrets.html#tokens). |
+| `extendedTokenExpiration` | Z `allowApiTokens` pozwala też tworzyć tokeny API, które nigdy nie wygasają. |
+| `allowFileUploads` | Pozwala użytkownikowi przesyłać pliki przez pola plików formularza. Włączona dla każdego użytkownika, chyba że rola ją wyłącza. |
+| `allowChat`, `allowMcp` | Pozwalają użytkownikowi korzystać z asystenta czatu i serwera MCP, gdy są włączone. `allowChat` jest włączona dla każdego użytkownika, chyba że rola ją wyłącza, a `allowMcp` podąża za `allowChat`, chyba że rola ją ustawia. |
+
+Użytkownik bez roli `admin` nie dostaje żadnej z powyższych opcji na poziomie admina, chyba że da mu ją rola. Gdy rola `admin`
+nie ustawia żadnych opcji, jej użytkownicy dostają `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` i `allowScheduledJobs`. `allowApiTokens` i
+`extendedTokenExpiration` pozostają wyłączone nawet dla roli `admin`: ustaw je w rolach, które ich potrzebują.
+
+Gdy kilka ról użytkownika ustawia tę samą opcję, wygrywa `false`. Opcje roli `default` uzupełniają tylko opcje,
+których nie ustawia żadna z własnych ról użytkownika; nigdy ich nie unieważniają.
diff --git a/i18n/pl/_configure/security/https.md b/i18n/pl/_configure/security/https.md
new file mode 100644
index 0000000..0b15bbd
--- /dev/null
+++ b/i18n/pl/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Bezpieczeństwo
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+Udostępniaj HTTPS z samej aplikacji i zastąp przykładowy certyfikat
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gdzie kończy się TLS
+
+TLS może kończyć się w jednym z trzech miejsc, a tylko pierwsze dotyczy ustawień z tej strony:
+
+* **w AnsibleForms**, z `HTTPS=1` : HTTPS na [`PORT`](../customization/server.html#env_PORT) z poniższymi plikami, jak robi to docker-compose na porcie 443.
+* **w reverse proxy**, z `HTTPS=0` za nim : zobacz [Reverse proxy](../production/reverse-proxy.html).
+* **w ingressie Kubernetes** : zobacz kartę Ingress na stronie [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) i README chartu.
+
+Pierwsze możesz połączyć z dwoma pozostałymi, żeby szyfrować także odcinek między proxy a aplikacją.
+
+---
+
+## Ustawienia
+
+HTTPS w aplikacji kontrolują trzy zmienne:
+
+| Zmienna | Domyślnie | Znaczenie |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` udostępnia HTTPS, `0` zwykłe HTTP |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | Klucz prywatny, PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | Certyfikat serwera, PEM |
+
+W obrazie kontenera folder trwały to `/app/dist/persistent`, więc domyślne pliki to
+`/app/dist/persistent/certificates/key.pem` i `cert.pem`. W projekcie docker-compose jest to `data/certificates/`
+na hoście.
+
+---
+
+## Przykładowy certyfikat
+
+Gdy `HTTPS=1`, a przy starcie brakuje któregoś z plików, AnsibleForms zapisuje w dzienniku `httpsKey or httpsCert not found, copying from
+templates` i kopiuje przykładowy klucz i certyfikat z obrazu do skonfigurowanych ścieżek. Jeśli kopiowanie się nie uda,
+aplikacja się zatrzymuje.
+
+Ten certyfikat jest samopodpisany dla `CN=ansibleforms` i jest **taki sam w każdej instalacji**: jego klucz prywatny
+jest dostarczany w publicznym obrazie. Wystarczy do pierwszego zapoznania się, ale przeglądarki ostrzegają przed nim, a każdy może odszyfrować ruch
+nim chroniony. Zastąp go, zanim instancja będzie przechowywać prawdziwe poświadczenia.
+
+---
+
+## Zastąpienie certyfikatu
+
+Użyj certyfikatu wystawionego dla nazwy hosta, którą wpisują użytkownicy, przez Twoje CA lub klienta ACME, w formacie PEM.
+Plik certyfikatu może zawierać pełny łańcuch: najpierw certyfikat serwera, potem pośrednie.
+
+1. Skopiuj pliki do folderu trwałego lub w dowolne miejsce, z którego aplikacja może je odczytać:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Jeśli znajdują się gdzie indziej, ustaw `HTTPS_KEY` i `HTTPS_CERT` na ich ścieżki **wewnątrz kontenera**.
+
+3. Uruchom ponownie aplikację, która odczytuje oba pliki przy starcie.
+
+Szybki własny certyfikat samopodpisany (dla instancji testowej lub odcinka za proxy) tworzy `openssl`:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Odnawianie bez restartu
+
+Zmiana `HTTPS_KEY` lub `HTTPS_CERT` na stronach ustawień przeładowuje klucz i certyfikat w działającym serwerze.
+Nowe połączenia dostają nowy certyfikat, otwarte zachowują stary. Jeśli nowych plików nie da się odczytać lub nie tworzą prawidłowej
+pary, bieżący certyfikat zostaje, a w dzienniku pojawia się ostrzeżenie.
+
+Działa to tylko wtedy, gdy strony ustawień mogą zapisywać środowisko ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+ma wartość `1`), a zmienna nie jest ustawiona w rzeczywistym środowisku. Gdy odnowienie zastępuje pliki pod tymi samymi
+ścieżkami, uruchom aplikację ponownie.
diff --git a/i18n/pl/_configure/security/index.md b/i18n/pl/_configure/security/index.md
new file mode 100644
index 0000000..c03cf86
--- /dev/null
+++ b/i18n/pl/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Bezpieczeństwo
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Bezpieczeństwo
+{: .no_toc }
+
+Zabezpiecz instancję: konto admina, jej sekrety, HTTPS oraz to, co mogą robić użytkownicy i formularze
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów przygotowujących instancję do produkcji oraz do przeglądów bezpieczeństwa istniejącej instancji.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Utwardzanie](hardening.html) | Konto admina, limity logowania, baza danych, wyrażenia, dane zadań, polityka przeglądarki, funkcje opcjonalne i opcje ról |
+| [HTTPS](https.html) | Gdzie kończy się TLS, udostępnianie HTTPS z aplikacji i zastąpienie przykładowego certyfikatu |
+| [Sekrety i szyfrowanie](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET` i czasy życia tokenów |
+
+Powiązane strony: [Uwierzytelnianie](../authentication/) dla metod logowania, [Walidacja uruchomień](../launch-validation/) dla
+sprawdzeń każdego uruchomienia po stronie serwera oraz [Zmienne bezpieczeństwa](../customization/security.html).
diff --git a/i18n/pl/_configure/security/secrets.md b/i18n/pl/_configure/security/secrets.md
new file mode 100644
index 0000000..9e7a880
--- /dev/null
+++ b/i18n/pl/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Sekrety i szyfrowanie
+parent: Bezpieczeństwo
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Sekrety i szyfrowanie
+{: .no_toc }
+
+Dwa główne sekrety, co chronią i jak długo trwają sesje i tokeny
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dwa główne sekrety
+
+Dwa sekrety chronią wszystko inne. Ustaw oba, zanim instancja będzie przechowywać prawdziwe dane, przechowuj je poza instancją
+i nigdy nie zmieniaj ich bez potrzeby:
+
+| Sekret | Co chroni | Jeśli nie jest ustawiony | Jeśli zostanie utracony lub zmieniony |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Każde hasło i token zapisane w bazie danych: poświadczenia, hasło bind LDAP, tokeny runnerów, client secrets SSO, adresy webhooków Slack i Teams, klucz API czatu | Używany jest domyślny klucz, publicznie dostępny w kodzie źródłowym | Utracony: każdy zapisany sekret trzeba wprowadzić ponownie. Zmieniony: od wersji 7.3.0 każdy zapisany sekret jest ponownie szyfrowany, zobacz [niżej](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | Podpis tokenów dostępu i odświeżania, łącznie z długotrwałymi [tokenami API](../profile/api-token.html) | Przy każdym starcie generowany jest losowy sekret, więc każdy restart wylogowuje wszystkich | Każda sesja i każdy token API stają się nieważne |
+
+Dopóki ich brakuje, przy starcie oba są zgłaszane w dzienniku ostrzeżeniem `[SECURITY]`. Strony ustawień odmawiają ich edycji,
+API nigdy ich nie zwraca, a kopie zapasowe celowo je pomijają, więc utraconego `ENCRYPTION_SECRET` nie da się nigdzie
+odzyskać: trzymaj jego kopię w swoim menedżerze sekretów. Sekret szyfrowania jest używany jako klucz 32-znakowy; krótsza lub
+dłuższa wartość jest dopełniana lub obcinana.
+
+Zmiana `ACCESS_TOKEN_SECRET` od razu kończy każdą sesję i każdy token API. Aby zakończyć tokeny jednego użytkownika lub jednej
+sesji, użyj unieważnień opisanych w [Tokeny](#tokens).
+
+---
+
+## Zmiana sekretu szyfrowania
+
+Od wersji 7.3.0 ustawienie lub zmiana `ENCRYPTION_SECRET` nie powoduje już utraty zapisanych sekretów. Przy następnym starcie worker ponownie szyfruje
+każdy z nich nowym kluczem, w jednej transakcji bazy danych, zanim cokolwiek innego zapisze sekret:
+
+| Sytuacja | Co ustawić |
+|---|---|
+| Instancja działała bez `ENCRYPTION_SECRET`, na publicznym kluczu domyślnym | Tylko `ENCRYPTION_SECRET`: sekrety są ponownie szyfrowane z klucza domyślnego |
+| Instancja działała z własnym kluczem | `ENCRYPTION_SECRET` na nowy klucz i [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) na stary, na ten jeden start |
+
+Gdy zapisane sekrety zostały zaszyfrowane kluczem, który nie jest żadnym z nich, nic nie jest zmieniane, a aplikacja odmawia startu, dopóki
+`ENCRYPTION_SECRET_PREVIOUS` nie wskaże tego klucza. Usuń `ENCRYPTION_SECRET_PREVIOUS`, gdy start ponownie je zaszyfruje, i ustaw
+nowy `ENCRYPTION_SECRET` na każdym węźle aplikacji, workerze i każdym RTE w trybie bazy danych, które samo się rejestruje. Ta
+samodzielna rejestracja (`RTE_REGISTER`) jest przestarzała w 7.3.0: RTE, które dołącza tokenem dołączenia (`RTE_JOIN_TOKEN`) w trybie
+gniazda, nie potrzebuje `ENCRYPTION_SECRET`, zobacz [Tryby RTE](../rte/modes.html).
+
+---
+
+## Tokeny
+
+Logowanie zwraca krótkotrwały token dostępu i dłuższy token odświeżania, którym przeglądarka zdobywa nową parę:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : domyślnie `30m`. Krótszy czas
+  ogranicza użycie przechwyconego tokenu.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : domyślnie `24h`.
+  Tyle bezczynna przeglądarka pozostaje zalogowana.
+* Opcja roli `allowApiTokens` pozwala użytkownikowi zażądać tokenu API ważnego przez określoną liczbę dni, a
+  `extendedTokenExpiration` dodaje token, który nigdy nie wygasa. Nadawaj je tylko rolom, które potrzebują dostępu do API ze skryptów.
+  Na [stronie profilu](../profile/api-token.html) token tworzy się z sesji przeglądarki zalogowanej najwyżej 10 minut
+  temu, nigdy z innego tokenu API. Token, który nigdy nie wygasa, żyje 50 lat, a poniższe zdarzenia nadal go kończą.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : domyślnie `90`. Najdłuższy czas życia tokenu
+  API: dłuższe żądanie jest do niego przycinane.
+
+Token jest podpisanym JWT, ale serwer przechowuje też listę unieważnionych tokenów, współdzieloną przez wszystkie węzły aplikacji, więc token
+może się zakończyć przed wygaśnięciem:
+
+| Zdarzenie | Co się kończy |
+|-------|-----------|
+| Wylogowanie | Każdy token tego logowania: token dostępu, jego token odświeżania oraz token API, gdy wylogowanie go używa |
+| Zmiana hasła, przez użytkownika lub admina | Każdy token użytkownika wystawiony przed zmianą, łącznie z tokenami API, na każdym urządzeniu |
+| Wyłączenie przełącznika **Zezwól na logowanie** użytkownika (lokalnego, LDAP lub SSO) albo usunięcie lokalnego użytkownika | Każdy token użytkownika |
+| **Zakończ sesje** na stronie użytkownika LDAP lub SSO | Każdy token użytkownika; może zalogować się ponownie, chyba że jest zablokowany |
+| **Unieważnij** przy tokenie API, na stronie profilu lub na karcie **Tokeny API** użytkownika | Ten jeden token API, natychmiast |
+
+Skrypt kończy własny token API, wylogowując się nim: `POST /api/v2/auth/logout` z tokenem w nagłówku
+`Authorization`.
diff --git a/i18n/pl/_configure/seed/environment-and-audit.md b/i18n/pl/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..6107d02
--- /dev/null
+++ b/i18n/pl/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Edycja i audyt
+parent: Config seed
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Edycja i audyt
+{: .no_toc }
+
+Blokowanie stron ustawień i co zapisuje dziennik audytu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wyłączanie edycji środowiska
+
+`ALLOW_ENV_EDIT=0` czyni strony ustawień tylko do odczytu. Każda zmienna jest nadal pokazywana z
+obowiązującą wartością i powodem, dla którego nie można jej zmienić, a endpoint zapisu odpowiada
+403.
+
+Używaj tego zawsze, gdy środowisko jest zadeklarowane gdzie indziej. W przeciwnym razie strona ustawień zapisuje
+`persistent/.env`, który na efemerycznym wolumenie po cichu ginie przy następnym restarcie, a na
+trwałym rozjeżdża się z manifestem, który ma być źródłem prawdy.
+
+{: .note }
+> Kopie zapasowe zawierają `persistent/.env` jako `managed.env`, więc odbudowa odzyskuje ustawienia bazy danych
+> i ścieżek. **`ENCRYPTION_SECRET` i `ACCESS_TOKEN_SECRET` są z niego usuwane**:
+> zrzut obok zawiera każde zapisane poświadczenie jako szyfrogram AES, a zapisanie klucza, który
+> go odszyfrowuje, w tym samym folderze sprawiłoby, że skopiowana kopia zapasowa wystarczyłaby do odczytania ich wszystkich. Ustaw
+> te dwa na hoście docelowym; mówi o tym komentarz w pliku.
+>
+> To, co zostaje, może nadal zawierać poświadczenia (`DB_PASSWORD`, `METRICS_TOKEN`, stary `VAULT_TOKEN`), więc plik jest
+> zapisywany z uprawnieniami `0600`. Jego przywrócenie to osobny, dobrowolny krok, a nie część zwykłego przywracania,
+> bo host bazy danych i ścieżki w nim opisują maszynę, z której pochodzi kopia zapasowa. Okno
+> przywracania wymienia plik i oferuje osobny przycisk *Przywróć środowisko*
+> (`POST /api/v2/backup/:folder/restore-env`), który zachowuje poprzedni plik jako `.env.bak`.
+
+---
+
+## Co jest zapisywane
+
+Każde zastosowanie, które coś zmienia, zapisuje w dzienniku audytu jeden wpis `seed.apply`, wymieniający
+utworzone, zaktualizowane, zwolnione i wyczyszczone obiekty. Wartości nigdy nie są zapisywane, bo większość
+z nich to sekrety. Zastosowanie bez zmian niczego nie zapisuje, dzięki czemu ślad pozostaje znaczący.
+Odpytanie, które znajduje niezmieniony plik, jest zastosowaniem bez zmian, więc w śladzie nie przybywa wiersz co minutę.
+
+Zastosowanie zażądane przez endpoint jest celowo zapisywane dwukrotnie, a oba wiersze
+zapisują co innego: `config-seed.apply.create` to **kto** o nie poprosił, `seed.apply` to
+**co** zmieniło.
+
+Strona Stan raportuje seed dwukrotnie: **test**, czy plik jest nadal czytelny i się parsuje
+oraz czy ostatnie przeładowanie się udało, i wiersz **informacji** mówiący, ile rekordów
+obecnie przejmuje. Test to jedyne miejsce, które informuje, że plik na dysku i obowiązująca konfiguracja
+się rozjechały, bo nieudane przeładowanie zostawia instancję działającą.
diff --git a/i18n/pl/_configure/seed/example.md b/i18n/pl/_configure/seed/example.md
new file mode 100644
index 0000000..0c626b8
--- /dev/null
+++ b/i18n/pl/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Przykład
+parent: Config seed
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Przykład
+{: .no_toc }
+
+Kompletny plik seed, sekcja po sekcji
+{: .fs-6 .fw-300 }
+
+---
+
+Poniższy plik seed deklaruje każdą sekcję poza `oauth2` i przestarzałą `awx`; sekrety pochodzą ze zmiennych środowiskowych,
+takich jak `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` to jedno z:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : dowolny inny endpoint zgodny z OpenAI
+
+Tak jak `ldap`, sekcja `chat` to pojedynczy wiersz, więc każde pole jest wymagane poza
+opcjonalnymi; pominięte pole opcjonalne pozostaje bez zmian.
+
+Asystent czatu wymaga też `ENABLE_CHAT=1`; zobacz stronę [Asystent czatu](../chat).
+
+Od wersji 7.3.0 runner loguje się poświadczeniem swojego typu, które zawiera adres jego serwera w `url`. Runner z własnym `token`
+albo `username` i `password` nadal działa: seed zapisuje ostrzeżenie w dzienniku i zamienia je na takie poświadczenie, nazwane od runnera.
+Runner, który wskazuje poświadczenie `api` lub `userpass`, też nadal działa, z ostrzeżeniem: nadaj zamiast tego temu poświadczeniu typ runnera.
+Oba są przestarzałe od wersji 7.3.0 i zostaną usunięte w 8.0.0. Runner RTE bez `rte_mode` jest w trybie bazy danych, przestarzałym (zobacz
+[Tryby](../rte/modes.html)). Runner z `enabled: false` nie dostaje żadnych zadań, także jako domyślny dla swojego typu (zobacz
+[Domyślny i Włączony](../runners/list.html#default-and-enabled)); bez `enabled` seed zostawia go bez zmian.
+
+Element runnera przyjmuje te klucze oprócz `name`, `type`, `description`, `credential`, `is_default` i `enabled`:
+
+| Klucz | Co ustawia |
+|---|---|
+| `rte_mode` | Tryb RTE: `outbound`, `inbound` lub `database` (przestarzały, domyślny) |
+| `rte_max_jobs` | **Maks. równoczesnych zadań** RTE w trybie gniazda, od `0` do `10000` (`0`: brak limitu) |
+| `rte_cache_mb` | Jego **Pamięć podręczna plików** w MB, od `0` do `1048576` (`0` nie przechowuje żadnych) |
+| `rte_files` | Jego **Pliki zadań**: `transfer` lub `local` |
+| `rte_drain_seconds` | Jego **Czas oczekiwania przy zatrzymaniu** w sekundach, od `0` do `86400` |
+| `flavour` | Runner `awx`, który jest AAP lub Ascenderem: `aap` lub `ascender`; brak dla AWX |
+| `project` | Id projektu runnera Semaphore, nazwa projektu runnera Rundeck, folder runnera Jenkins |
+| `uri`, `ignore_certs`, `ca_bundle` | Własny adres i TLS runnera sprzed wersji 7.3.0: używane tylko, dopóki jego poświadczenie nie zawiera `url` |
+
+Cztery ustawienia `rte_*` to ustawienia karty RTE na stronie runnera (zobacz [Ustawienia RTE](../runners/runner-page.html#an-rtes-settings)):
+wygrywają z tymi samymi zmiennymi ustawionymi na RTE, a RTE w trybie bazy danych je ignoruje. Wartość spoza zakresu powoduje niepowodzenie
+walidacji seeda.
+
+RTE w trybie bazy danych może się samo zarejestrować, zanim seed zostanie zastosowany. Runner RTE z seeda, którego `uri` jest adresem, pod którym takie RTE
+się zarejestrowało, **przejmuje** ten wiersz: przyjmuje zadeklarowaną nazwę i pola, a worker przestaje go usuwać, gdy RTE przestaje
+odpowiadać, zamiast tworzyć drugi runner dla tego samego RTE.
diff --git a/i18n/pl/_configure/seed/index.md b/i18n/pl/_configure/seed/index.md
new file mode 100644
index 0000000..d541ed2
--- /dev/null
+++ b/i18n/pl/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Config seed
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Config seed
+{: .no_toc }
+
+Deklaruj obiekty administracyjne w pliku
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów, którzy wdrażają z gita: zadeklaruj obiekty administracyjne w pliku, żeby instancję dało się odbudować na pustej bazie danych.
+
+---
+
+## Co obejmuje
+
+Ustaw `CONFIG_SEED_PATH` na plik YAML, a AnsibleForms zastosuje go przy starcie. Plik
+deklaruje obiekty, które wcześniej istniały tylko w bazie danych:
+
+| Sekcja                  | Co deklaruje                                                        |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Gdzie działają zadania: RTE, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Magazyny sekretów (HashiCorp Vault, ...)                            |
+| `credentials`           | Poświadczenia                                                       |
+| `oauth2`                | Dostawców SSO: Entra ID i OIDC                                      |
+| `repositories`          | Repozytoria git                                                     |
+| `syslog_servers`        | Serwery syslog, które otrzymują dziennik serwera i wpisy audytu     |
+| `notification_channels` | Serwery poczty, Slack, Teams, Telegram i webhooki dla powiadomień   |
+| `labels`                | Etykiety obok logo w nagłówku, od wersji 7.3.0                      |
+| `ldap`                  | Konfigurację LDAP                                                   |
+| `settings`              | Publiczny URL i ustawienia poczty używane, gdy żaden kanał pocztowy nie jest aktywny |
+| `chat`                  | Dostawcę modelu asystenta czatu                                     |
+| `awx`                   | Przestarzałe od wersji 7, usunięte w 8: użyj `runners` z `type: awx` |
+
+Seed napisany przed wersją 7 nadal działa: każdy element jego sekcji `awx` jest stosowany jako runner typu `awx`, a dziennik
+ostrzega przy każdym zastosowaniu. Przed aktualizacją do 8 przenieś te elementy do `runners` z `type: awx`.
+
+Seed to **nie** to samo co `config.yaml`, który przechowuje kategorie, role i stałe
+i ma własne `CONFIG_PATH`. Oba są celowo rozdzielone:
+repozytorium, które *przechowuje* `config.yaml`, jest jednym z obiektów deklarowanych przez seed, więc seed
+nie może znajdować się w nim.
+
+Użytkownicy i grupy są pominięci: pochodzą z LDAP lub SSO, a pierwszy admin z `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Przykład](example.html) | Kompletny plik seed, sekcja po sekcji |
+| [Obiekty zarządzane](managed-objects.html) | Jak seed przejmuje obiekty, które wymienia, i jak trzyma sekrety poza plikiem |
+| [Przeładowanie i start](reloading.html) | Zmiana pliku bez restartu i co się dzieje przy starcie |
+| [Kubernetes](kubernetes.html) | Wdrażanie AnsibleForms z ConfigMap i Secrets |
+| [Edycja i audyt](environment-and-audit.html) | Blokowanie stron ustawień i co zapisuje dziennik audytu |
diff --git a/i18n/pl/_configure/seed/kubernetes.md b/i18n/pl/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..81a9e77
--- /dev/null
+++ b/i18n/pl/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Config seed
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+Wdrażanie AnsibleForms z ConfigMap i Secrets
+{: .fs-6 .fw-300 }
+
+---
+
+Zamontuj seed z `ConfigMap`, a jego sekrety z `Secret`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Jeden pod, z nieustawionym `AF_ROLE`.** Ten pod uruchamia aplikację WWW i worker w jednym procesie. Harmonogramy, nocna
+> kopia zapasowa i pozostała praca w tle działają tylko w procesie, który trzyma blokadę workera w bazie danych, blokada
+> projektanta to tabela w bazie danych, a playbooki działają na RTE, nie w tym podzie. Mimo to zachowaj `replicas: 1` ze strategią
+> `Recreate`: przy aktualizacji nowy pod czeka, aż worker załata schemat, a stary pod trzyma
+> blokadę workera, dopóki się nie zatrzyma. Aby uruchomić kilka węzłów WWW, podziel je na węzły `AF_ROLE=app` i worker, jak
+> opisuje strona [Skalowanie](../production/scaling.html).
+
+`ENCRYPTION_SECRET` musi być ustawiony, zanim zostanie wprowadzone jakiekolwiek poświadczenie. Gdy poświadczenia pochodzą
+z seeda, baza danych staje się w praktyce pamięcią podręczną, więc jej odtworzenie oznacza ponowne zastosowanie
+seeda zamiast ręcznego wprowadzania wszystkiego od nowa.
+
+Obie sondy nie wymagają logowania. Przy [`BASE_URL`](../customization/server.html#env_BASE_URL) ich ścieżki zaczynają się od niego, a
+strona [Monitorowanie](../production/monitoring.html) opisuje, co sprawdza każda z nich.
diff --git a/i18n/pl/_configure/seed/managed-objects.md b/i18n/pl/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..1a04ec0
--- /dev/null
+++ b/i18n/pl/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Obiekty zarządzane
+parent: Config seed
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Obiekty zarządzane
+{: .no_toc }
+
+Jak seed przejmuje obiekty, które wymienia, i jak trzyma sekrety poza plikiem
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sekcje jednowierszowe: wszystko albo nic
+
+`ldap`, `settings` i `chat` to każda **pojedynczy wiersz**, więc seed musi deklarować wszystkie ich pola; pozostałe sekcje są listami.
+
+Seed, który pomija pole, odmawia startu i podaje to pole:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Pustą wartość deklaruj jawnie przez `""` lub `false`. Kilka pól jest opcjonalnych, a pominięte pozostaje bez zmian:
+
+| Sekcja | Pola opcjonalne |
+|---|---|
+| `ldap` | `description`, `credential` (poświadczenie do bind) i `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` i `extra_headers` |
+| `settings` | Brak |
+
+`settings` obejmuje tylko pola poczty i URL; wszystkie pozostałe ustawienia można nadal edytować.
+
+---
+
+## Plik nie zawiera sekretów
+
+Każde `${VARIABLE}` jest zastępowane tą zmienną środowiskową (na Kubernetes z `Secret`), więc plik może być w gicie.
+
+Nieustawiona zmienna to **błąd krytyczny**, więc symbol zastępczy nigdy nie zostanie zapisany jako hasło.
+
+Poświadczenia mogą też używać [magazynu sekretów](../secret-stores) (`secret_store`, `secret_ref`); `vault_path` zniknie w wersji 8.
+
+---
+
+## Obiekty zarządzane
+
+Obiekt, który pochodzi z seeda, jest oznaczony jako **zarządzany**:
+
+- Jest wymuszany przy **każdym** starcie, więc plik pozostaje źródłem prawdy.
+- Jest tylko do odczytu: API odpowiada **403**, interfejs wyłącza Edytuj i Usuń, a jego własna strona mówi, że pochodzi z pliku config
+  seed i jest tylko do odczytu.
+- Tylko seed może ustawić lub usunąć to oznaczenie.
+
+Obiekty utworzone ręcznie **nigdy nie są ruszane**, chyba że seed deklaruje tę samą nazwę. Taki rekord zostaje wtedy **przejęty**:
+zadeklarowane pola są wymuszane, a rekord staje się tylko do odczytu. Przejęcie jest zapisywane w dzienniku jako ostrzeżenie i w śladzie audytu.
+
+Stosowanie seeda jest idempotentne: rekordy, które już pasują, zostają bez zmian, więc restart zwykle raportuje `0 updated`.
+
+Zadeklarowane repozytorium, którego kopii roboczej brakuje, jest **klonowane ponownie** przy każdym starcie, więc nieudane pierwsze klonowanie jest
+ponawiane. Wiersz *Repozytoria* na stronie Stan pokazuje każde repozytorium bez kopii roboczej.
+
+### Usuwanie obiektu
+
+Usunięcie obiektu z pliku go **zwalnia**: rekord zostaje i znów można go edytować. Usunięcie całej sekcji
+działa tak samo.
+
+Dodaj `prune: true` do sekcji listy, aby **usuwać** zarządzane rekordy, których plik już nie deklaruje:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` nigdy nie usuwa rekordu utworzonego ręcznie.
+
+### Wyłączanie seeda
+
+Usunięcie `CONFIG_SEED_PATH` **niczego** nie zwalnia: seed nie jest już stosowany, a rekordy, którymi zarządzał, pozostają zarządzane
+i tylko do odczytu. Aby znów je edytować, najpierw je zwolnij: skieruj `CONFIG_SEED_PATH` na plik bez nich (pusty plik niczego nie deklaruje
+i zwalnia każdy rekord), pozwól mu się zastosować przy starcie lub przeładowaniu, a potem usuń zmienną. Zwolnione rekordy zostają takie, jakie
+są, i można je edytować.
diff --git a/i18n/pl/_configure/seed/reloading.md b/i18n/pl/_configure/seed/reloading.md
new file mode 100644
index 0000000..37ab22b
--- /dev/null
+++ b/i18n/pl/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Przeładowanie i start
+parent: Config seed
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Przeładowanie i start
+{: .no_toc }
+
+Zmiana pliku bez restartu i co się dzieje przy starcie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Zmiana pliku bez restartu
+
+Seed jest ponownie odczytywany co `CONFIG_SEED_RELOAD_SECONDS` (domyślnie 60, `0` to wyłącza)
+i ponownie stosowany, gdy jego zawartość się zmieniła. Zmiana zatwierdzona w gicie trafia więc
+automatycznie do działającej instancji: na Kubernetes `ConfigMap` jest ponownie montowany w podzie w ciągu
+około minuty, a następne sprawdzenie go wychwytuje. Nie ma rolloutu ani restartu i żaden
+hook nie musi niczego wywoływać.
+
+Dla niezmienionego pliku odpytanie oblicza jeden hash i kończy, więc nigdy nie przepisuje wiersza, który już
+zastosowało.
+
+Aby zastosować plik od razu, zamiast czekać na następne sprawdzenie, użyj jednego z tych sposobów:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Oba **wymuszają** zastosowanie, nawet gdy plik się nie zmienił. Wymuszone zastosowanie przywraca
+zarządzany rekord, który edytowano bezpośrednio w bazie danych, i ponownie klonuje zadeklarowane repozytorium,
+którego kopii roboczej brakuje.
+
+{: .note }
+> Przeładowanie **nigdy nie jest krytyczne**, w przeciwieństwie do zastosowania przy starcie. Instancja, która już
+> obsługuje ruch, zachowuje bieżącą konfigurację, przyczyna trafia do dziennika, a wiersz *Config seed*
+> na stronie Stan robi się czerwony i ją podaje. Literówka wypchnięta do gita nie może położyć
+> działającej instancji bez żadnego działania operatora.
+>
+> Ta sama błędna zawartość nie jest też ponawiana przy każdym sprawdzeniu; inaczej jedna zła edycja
+> zapisywałaby ten sam błąd w dzienniku w nieskończoność. Popraw plik albo wywołaj endpoint, aby ponowić
+> od razu.
+
+---
+
+## Uszkodzony seed nie pozwala wystartować
+
+Nieczytelny plik, nieprawidłowy YAML, nieznane pole, zduplikowana nazwa lub nierozwiązane
+`${VARIABLE}` sprawia, że serwer **kończy działanie** zamiast wystartować. Dotyczy to tylko ścieżki **startu**:
+zobacz uwagę wyżej, co ten sam plik robi z instancją, która już działa.
+
+Jest to celowe. Kontynuowanie z poprzednią konfiguracją zostawiłoby instancję, której
+zachowanie nie odpowiada już manifestowi, który ma ją opisywać, i nic nie
+zgłaszałoby tej niezgodności. Przyczyna jest zapisywana na standardowe wyjście błędów i do pliku dziennika, więc
+pokazują ją `kubectl logs` i `docker logs`.
+
+Walidacja jest ścisła: nieznane pola są odrzucane, a nie ignorowane, a błąd podaje
+niewłaściwy klucz:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Pusta baza danych sama się przygotowuje
+
+Przy włączonym `ALLOW_SCHEMA_CREATION` (domyślnie) baza danych, która **w ogóle nie zawiera tabel
+AnsibleForms**, dostaje schemat utworzony przy starcie. Nowe wdrożenie startuje więc
+bez potrzeby ręcznego wywoływania endpointu `/schema`.
+
+Warunek wstępny jest celowo ścisły: tworzenie schematu **najpierw usuwa każdą tabelę**, więc
+uruchamia się tylko na całkowicie pustej bazie danych. Baza danych, której brakuje
+jednej kolumny albo która ma tabele, ale nie ma kont użytkowników, *nie* jest pusta i zostaje nietknięta;
+takie przypadki obsługują łatki schematu.
diff --git a/i18n/pl/_configure/users-and-groups.md b/i18n/pl/_configure/users-and-groups.md
new file mode 100644
index 0000000..4eb0578
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Użytkownicy i grupy
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Użytkownicy i grupy
+{: .no_toc }
+
+Lokalni użytkownicy i grupy, obok nich użytkownicy i grupy LDAP i logowania jednokrotnego oraz blokowanie logowania
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: zarządzaj tym, kto może się logować, w **Ustawienia > Dostęp > Użytkownicy** i **Grupy**, z opcją roli `showSettings`.
+
+Wbudowany admin, kolejność logowania i mapowanie ról kont lokalnych są opisane na stronie [Konta lokalne](authentication/local.html).
+
+---
+
+## W tej sekcji
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Użytkownik lokalny](users-and-groups/local-user.html) | Dodawanie użytkownika lokalnego i karty jego strony |
+| [Kilka grup](users-and-groups/several-groups.html) | Użytkownik lokalny w kilku grupach i jego role |
+| [Grupa lokalna](users-and-groups/local-group.html) | Strona grupy lokalnej i jej karty |
+| [Użytkownicy i grupy z katalogu](users-and-groups/directory.html) | Użytkownicy i grupy LDAP, Entra ID i OIDC, w postaci z ostatniego logowania |
+| [Blokowanie logowania](users-and-groups/blocking-a-sign-in.html) | Zezwól na logowanie: blokowanie użytkownika bez usuwania czegokolwiek |
+
+
+---
+
+## Listy
+
+Listy **Użytkownicy** i **Grupy** pokazują lokalnych użytkowników i grupy, a obok nich użytkowników i grupy LDAP i logowania jednokrotnego.
+
+Użytkownik lub grupa LDAP, Entra ID lub OIDC pojawia się na liście, gdy się zaloguje (lub zostanie zauważony przy logowaniu) albo gdy wskaże go rola.
+Kolumna **Źródło** mówi, skąd każdy pochodzi: lokalnie, LDAP, Microsoft Entra ID lub OIDC. Od wersji 7.3.0 lista **Użytkownicy** ma też
+kolumnę **Ostatnie logowanie**, która mówi, kiedy każdy użytkownik ostatnio się zalogował.
+
+Wiersz otwiera stronę swojego użytkownika lub grupy. **Dodaj użytkownika** i **Dodaj grupę** tworzą lokalnego użytkownika lub grupę.
+
+---
+
+## Konta, które dają uprawnienia admina
+
+Rola admin w config.yaml wskazuje lokalne grupy i użytkowników, więc tylko admin może zmieniać konta i grupy, które ona wskazuje.
+
+Użytkownik z `showSettings`, ale bez roli admin, nie może zmienić, zablokować, przenieść do innych grup, ustawić hasła ani usunąć
+lokalnego konta wskazanego przez rolę admin (bezpośrednio lub przez jedną z jego grup). Nie może też utworzyć, przemianować ani usunąć grupy
+wskazanej przez rolę admin ani dodać do niej użytkownika. To samo dotyczy użytkownika LDAP lub SSO, który mapuje się na rolę admin: jego blokowanie,
+kończenie jego sesji, zapominanie go i unieważnianie jego tokenów API należą do admina. Serwer odpowiada na takie żądanie `403`.
+
diff --git a/i18n/pl/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/pl/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..e9fc7fe
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Blokowanie logowania
+parent: Użytkownicy i grupy
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Blokowanie logowania
+{: .no_toc }
+
+Zezwól na logowanie: blokowanie użytkownika bez usuwania czegokolwiek
+{: .fs-6 .fw-300 }
+
+Przełącznik **Zezwól na logowanie** blokuje użytkownika, lokalnego lub z katalogu, bez usuwania czegokolwiek.
+
+Po wyłączeniu, i po potwierdzeniu, sesje użytkownika kończą się natychmiast, a każde logowanie jest odrzucane, dopóki ponownie go nie włączysz.
+Lista użytkowników ma w menu każdego wiersza **Zablokuj logowanie** i **Zezwól na logowanie**, które robią to samo.
+
+Nie możesz zablokować użytkownika `admin` ani własnego logowania.
diff --git a/i18n/pl/_configure/users-and-groups/directory.md b/i18n/pl/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..b0b4bd1
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Użytkownicy i grupy z katalogu
+parent: Użytkownicy i grupy
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Użytkownicy i grupy z katalogu
+{: .no_toc }
+
+Użytkownicy i grupy LDAP, Entra ID i OIDC, w postaci z ostatniego logowania
+{: .fs-6 .fw-300 }
+
+Użytkownik LDAP, Entra ID lub OIDC ma swoją stronę pod `/settings/users/<source>/<name>`, ze źródłem `ldap`, `azuread` lub `oidc`,
+np. `/settings/users/ldap/jdoe`. Pokazuje ona, tylko do odczytu, to, co zapisano przy ostatnim logowaniu użytkownika,
+bo to katalog lub dostawca tożsamości decyduje, kim jest użytkownik i jakie ma grupy.
+
+Jej karty są takie jak u użytkownika lokalnego. **Szczegóły** zawierają przełącznik **Zezwól na logowanie**, nazwę użytkownika, źródło, imię i nazwisko,
+e-mail, czas, kiedy użytkownik został pierwszy raz zauważony, i jego ostatnie logowanie. **Grupy** wyświetlają grupy z ostatniego logowania.
+**Tokeny API** wyświetlają tokeny API użytkownika, a **Unieważnij** od razu kończy jeden z nich.
+
+W prawym górnym rogu **Zakończ sesje** od razu wylogowuje użytkownika wszędzie. **Zapomnij** usuwa rekord, który wraca
+przy jego następnym logowaniu; jego zadania, zapisane zadania i harmonogramy zostają. Zablokowanego użytkownika nie można zapomnieć, bo
+pozwoliłoby mu to znów się zalogować: serwer odpowiada `409`, więc najpierw zezwól mu na logowanie.
+
+Grupy tego rekordu to też grupy, z którymi działa sesja użytkownika, odczytywane na bieżąco. Zapomnienie zalogowanego użytkownika
+zostawia go bez grup i bez ról, które te grupy dają, dopóki nie zaloguje się ponownie.
+
+Grupa z katalogu ma swoją stronę pod `/settings/groups/<source>/<name>`, tylko do odczytu, z kartami **Szczegóły**,
+**Użytkownicy** (użytkownicy zauważeni w niej przy ich ostatnim logowaniu), **Role** i **Formularze**.
diff --git a/i18n/pl/_configure/users-and-groups/local-group.md b/i18n/pl/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..c863267
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Grupa lokalna
+parent: Użytkownicy i grupy
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Grupa lokalna
+{: .no_toc }
+
+Strona grupy lokalnej i jej karty
+{: .fs-6 .fw-300 }
+
+Strona grupy, `/settings/groups/<id>`, ma te karty:
+
+| Karta | Co pokazuje |
+|---|---|
+| **Szczegóły** | Nazwę i opis |
+| **Użytkownicy** | Użytkowników w grupie; **Dodaj użytkownika** dodaje jednego, menu wiersza lub pola wyboru usuwają |
+| **Role** | Role, które wskazują grupę |
+| **Formularze** | Formularze, które otwierają te role |
+
+Grupy z użytkownikami nie można usunąć: najpierw usuń z niej użytkowników. Grupy `admins` nigdy nie można usunąć ani zmienić jej nazwy.
diff --git a/i18n/pl/_configure/users-and-groups/local-user.md b/i18n/pl/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..49d4772
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Użytkownik lokalny
+parent: Użytkownicy i grupy
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Użytkownik lokalny
+{: .no_toc }
+
+Dodawanie użytkownika lokalnego i karty jego strony
+{: .fs-6 .fw-300 }
+
+**Dodaj użytkownika** otwiera trzyetapowy kreator: **Użytkownik** (nazwa użytkownika, opis, e-mail), **Hasło** i **Grupa**.
+
+Strona użytkownika, `/settings/users/<id>`, ma te karty:
+
+| Karta | Co pokazuje |
+|---|---|
+| **Szczegóły** | Przełącznik **Zezwól na logowanie**, nazwę użytkownika, opis, e-mail oraz, od wersji 7.3.0, **Ostatnie logowanie** |
+| **Grupy** | Grupy, do których należy użytkownik |
+| **Role** | Role, które ma użytkownik, i co daje każdą z nich: **Bezpośrednio**, **Przez** grupę lub **Wszyscy** |
+| **Formularze** | Formularze, które otwierają te role |
+| **Zadania** | Zadania uruchomione przez użytkownika, od najnowszego |
+| **Zapisane zadania** | Wartości formularzy, które użytkownik zapisał, żeby uruchomić je ponownie |
+| **Harmonogramy** | Zadania, które użytkownik zaplanował przez Uruchom później |
+| **Aktywność** | Co dziennik audytu zapisał o działaniach użytkownika |
+| **Tokeny API** | Tokeny API użytkownika, z datą utworzenia, wygaśnięcia i ostatniego użycia każdego; **Unieważnij** od razu kończy jeden z nich |
+
+Od wersji 7.3.0 logowania użytkownika lokalnego są zapisywane, tak jak już wcześniej logowania użytkownika LDAP lub SSO: **Ostatnie logowanie** pokazuje najnowsze, a
+lista użytkowników ma sortowalną kolumnę **Ostatnie logowanie** dla każdego źródła, więc konto, którego nikt nie używa, rzuca się w oczy. Odrzucone logowanie nie jest
+zapisywane, a lokalny użytkownik, który nie logował się od aktualizacji, pokazuje `–`.
+
+**Zmień hasło** i **Usuń** są w prawym górnym rogu. Użytkownika `admin` nigdy nie można usunąć ani zmienić jego nazwy.
diff --git a/i18n/pl/_configure/users-and-groups/several-groups.md b/i18n/pl/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..e682da9
--- /dev/null
+++ b/i18n/pl/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Kilka grup
+parent: Użytkownicy i grupy
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Kilka grup
+{: .no_toc }
+
+Użytkownik lokalny w kilku grupach i jego role
+{: .fs-6 .fw-300 }
+
+Użytkownik lokalny może należeć do kilku grup i dostaje role każdej z nich: role wskazują grupę jako `local/<group>`.
+
+Na karcie **Grupy** **Dodaj grupę** dodaje użytkownika do kolejnej grupy, a menu wiersza lub pola wyboru go z niej usuwają.
+Użytkownik zachowuje co najmniej jedną grupę. Lista użytkowników ma w menu każdego wiersza **Dodaj do grupy**, które robi to samo.
diff --git a/i18n/pl/_get_started/first-form.md b/i18n/pl/_get_started/first-form.md
new file mode 100644
index 0000000..f696486
--- /dev/null
+++ b/i18n/pl/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: Twój pierwszy formularz
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# Twój pierwszy formularz
+{: .no_toc }
+
+Napisz playbook, zbuduj dla niego formularz w Projektancie, uruchom go i znajdź zadanie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Ten samouczek zaczyna się od świeżej instalacji, zobacz [Instalacja](installation/). Zajmuje około piętnastu minut.
+
+---
+
+## 1. Zaloguj się
+
+Otwórz AnsibleForms w przeglądarce i zaloguj się jako administrator.
+
+Domyślne konto to `admin` / `AnsibleForms!123` (lub Twoje wartości [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)); otwiera się strona **Formularze**:
+
+![Strona Formularze z przykładowymi formularzami](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Napisz playbook
+
+Formularz `ansible` uruchamia playbook z folderu playbooków, więc najpierw potrzebny jest playbook. Zapisz to jako `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+Playbook odczytuje cztery zmienne. Formularz, który zbudujesz w następnym kroku, wysyła je jako extravars, po jednej na pole.
+
+Umieść plik w folderze `playbooks` folderu trwałego
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); utwórz folder, jeśli jeszcze nie istnieje:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">Ze źródeł</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Folder zamontowany w `/app/dist/persistent`, w przykładzie instalacji `/srv/apps/ansibleforms/persistent`:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+Folder `data/playbooks` projektu docker-compose:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+Wolumen trwały, zamontowany w `/app/dist/persistent` w podzie AnsibleForms. Sprawdź nazwę poda, a potem skopiuj do niego plik:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+Folder `persistent/playbooks` serwera, w przykładzie instalacji `/srv/apps/ansibleforms/server`:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Gdy repozytorium git ma włączoną opcję **Używać do playbooków?**, playbooki są uruchamiane z tego repozytorium:
+> zatwierdź (commit) tam `hello.yaml`. Zobacz [Projektant i git](gui/designer-and-git.html).
+
+---
+
+## 3. Utwórz formularz
+
+Formularze to pliki YAML w folderze formularzy. Projektant edytuje je w przeglądarce i sprawdza przed zapisem.
+
+1. Kliknij **Projektant** w górnym menu, a potem **Formularze** w menu po lewej.
+2. Kliknij przełącznik w prawym górnym rogu (**Uruchom projektanta**). Blokuje on konfigurację, aby nikt inny nie edytował jej w tym samym
+   czasie, i wtedy pokazuje **Zablokowany przeze mnie**.
+3. Kliknij **Nowy plik**, pierwszy przycisk paska narzędzi, i wpisz nazwę pliku `hello-world.yaml`. Projektant dodaje do niego formularz
+   o nazwie `New Form`.
+4. Zastąp YAML w edytorze tym formularzem:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Kliknij **Weryfikuj** (znak zaznaczenia), a potem **Zapisz**. Zapis tworzy `hello-world.yaml` w folderze formularzy.
+6. Kliknij ponownie przełącznik, aby zwolnić blokadę.
+
+![Projektant podczas edycji formularza](assets/screenshots/designer.jpg)
+
+Formularz używa czterech typów pól:
+
+| Pole | Typ | Co robi |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Wymagane pole tekstowe |
+| `target_env` | [`enum`](formfields/enum.html) | Lista rozwijana ze stałą listą `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Lista rozwijana wypełniana przez lokalne [wyrażenie](expressions/local.html); `__auto__` wybiera pierwszą pozycję |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Pole wyboru, wysyłane jako `true` lub `false` |
+
+`vm_size` pokazuje obie kolumny, `size` i `cpus`, i wysyła `size`, pierwszą z nich; `valueColumn` wybiera inną.
+
+`roles: [default]` pozwala każdemu zalogowanemu użytkownikowi uruchomić formularz, a `categories: [Default]` umieszcza go w kategorii, którą definiuje domyślny
+`config.yaml`.
+
+{: .note }
+> Możesz też skopiować `hello-world.yaml` do [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) i [zweryfikować go w VS Code](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Uruchom go
+
+Otwórz formularz ze strony **Formularze**: kliknij **Formularze** w górnym menu i wybierz **Hello world** w kategorii **Default**.
+
+Wpisz swoje imię i, jeśli chcesz, zmień pozostałe pola. Kliknij **Pokaż extravars**, aby zobaczyć, co otrzyma
+playbook, a potem kliknij **Wyślij**:
+
+![Formularz](assets/screenshots/form.jpg)
+
+---
+
+## 5. Obserwuj wynik
+
+Zadanie rozpoczyna się od razu, a jego wynik pojawia się pod formularzem w trakcie działania i kończy się paskiem **Zakończone**:
+
+![Wynik zadania](assets/screenshots/run.jpg)
+
+Zadanie debug wypisuje Twoje wartości, na przykład `Hello Alice: a small machine in development (dry run: True)`.
+
+Ostrzeżenie o niejawnym localhost jest spodziewane, gdy nie ma inwentarza; prawdziwy formularz ustawia [`inventory`](forms/ansible.html).
+
+---
+
+## 6. Znajdź je w historii zadań
+
+Każde uruchomienie jest zapisywane jako zadanie. Kliknij **Zadania** w górnym menu: nowe zadanie jest na górze listy **Wszystkie zadania**.
+
+Kliknij zadanie, aby ponownie zobaczyć jego wynik, a **Pokaż extravars**, aby zobaczyć, co zostało wysłane. Ikony przed każdym zadaniem
+uruchamiają je ponownie lub je usuwają:
+
+![Historia zadań](assets/screenshots/job-output.jpg)
+
+---
+
+## Następne kroki
+
+Rozbuduj ten formularz, korzystając ze stron referencyjnych:
+
+* **[Formularze](forms/)** : każda właściwość formularza, szablony na runnerach, formularze workflow, punkty zatwierdzenia i powiadomienia
+* **[Pola formularzy](formfields/)** : wszystkie typy pól, z walidacją, zależnościami i układem
+* **[Wyrażenia](expressions/)** : wypełnianie pól z API REST, baz danych i plików
+* **[Role](config/roles.html)** i **[kategorie](config/categories.html)** w `config.yaml` : decydują, kto widzi który formularz
+* **[Jak to działa](how-it-works.html)** : co dzieje się za uruchomieniem i gdzie wszystko jest przechowywane
diff --git a/i18n/pl/_get_started/installation/docker-compose.md b/i18n/pl/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..28b3b54
--- /dev/null
+++ b/i18n/pl/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Instalacja
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Zainstaluj razem AnsibleForms, jego RTE i MySQL za pomocą docker-compose lub podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+[Projekt docker-compose](https://github.com/ansibleforms/docker) uruchamia trzy kontenery: MySQL, aplikację AnsibleForms i RTE
+(runtime environment), które uruchamia playbooki. Zawiera ich ustawienia, przykładowe formularze i playbooki, więc jedynym dodatkowym wymaganiem jest
+Docker lub Podman z narzędziem compose.
+
+[Instalator](installer.html) pobiera ten projekt, wypełnia jego ustawienia i sekrety i uruchamia go jednym poleceniem. Ta strona
+opisuje ręczną konfigurację.
+
+---
+
+## Wymagania wstępne
+
+Zanim zaczniesz, potrzebujesz:
+
+* **Maszyny z Linuksem** : dowolna dystrybucja, ze skromnymi zasobami CPU i pamięci
+* **Dostępu do GitHub** : aby pobrać lub sklonować projekt docker-compose z GitHub
+* **Docker lub Podman** : silnik kontenerów, instalowany poniżej
+* **Narzędzia compose** : Docker Compose lub podman-compose, aby uruchomić trzy kontenery z kilku plików konfiguracyjnych
+
+**WIDEO**: [Jak zainstalować AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Wybór miejsca instalacji
+
+Utwórz folder na projekt; przykłady używają `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Klonowanie projektu docker-compose
+
+Zainstaluj Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Następnie sklonuj projekt docker-compose do tego folderu:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Ustawienie właściwych uprawnień
+
+Aplikacja i RTE działają jako użytkownik `node` (uid 1000), więc przekaż temu użytkownikowi folder `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Przy przejściu z 6, której kontener działał jako root, uruchom raz to samo `chown` przed uruchomieniem 7. MySQL przy starcie sam przejmuje z powrotem swój folder.
+
+---
+
+## Instalacja silnika kontenerów
+
+Zainstaluj Docker lub Podman, każdy z jego narzędziem compose:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Zainstaluj Docker Engine z wtyczką Compose z repozytorium Dockera
+(zobacz [instrukcje instalacji Dockera](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Następnie umożliw rozwiązywanie nazw wewnątrz kontenerów i uruchom Docker jako usługę:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman nie wymaga usługi. Zainstaluj go razem z podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Dostosowanie
+
+Przejrzyj zmienne w plikach `.env` i `docker-compose.yml` i zmień każde hasło: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` i `RTE_TOKEN`. [Dowiedz się więcej o zmiennych środowiskowych](../customization)
+
+Aplikacja łączy się z MySQL jako `ansibleforms` (`MYSQLDB_USER`), z wszystkimi uprawnieniami do schematu `AnsibleForms` i żadnymi
+poza nim; root służy tylko samemu MySQL. MySQL tworzy tego użytkownika wyłącznie przy pierwszym uruchomieniu: instalacja, która dotąd łączyła się jako root,
+tworzy go raz, tak jak pokazuje [README](https://github.com/ansibleforms/docker#database) projektu.
+
+RTE nie jest publikowane na hoście. Od wersji 7.3.0 aplikacja łączy się z nim pod `http://rte:8000` z `RTE_TOKEN` i utrzymuje otwarty jeden WebSocket
+(`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)): RTE nie dostaje ustawień bazy danych ani `.env`, tylko swój token i kilka
+własnych ustawień w `docker-compose.yml`. Config seed `data/seed.yaml` deklaruje poświadczenie RTE z tokenem i tym
+adresem oraz domyślny runner `rte`, w trybie inbound, który się nim loguje. RTE uruchamia playbooki z tego samego folderu `data`
+(`RTE_FILES=local`). Gdy Twoje playbooki potrzebują więcej kolekcji lub bibliotek Pythona, zbuduj własne RTE
+i wskaż je w usłudze `rte` (zobacz [Budowanie własnego RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Uruchomienie projektu docker-compose
+
+Uruchom trzy kontenery w tle. Aplikacja czeka, aż MySQL będzie w dobrej kondycji, a potem łączy się z RTE:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Test aplikacji
+
+Gdy kontenery działają, otwórz AnsibleForms w przeglądarce:
+
+* Otwórz `https://your_ip` (port 443, zobacz `WEBAPP_LOCAL_PORT` w pliku .env)
+* Zaloguj się jako `admin` hasłem `ADMIN_PASSWORD` z pliku `.env`; dopóki jest to wciąż domyślne `AnsibleForms!123`, wybierz nowe hasło
+* Sprawdź w **Połączenia > Runnery**, czy RTE jest wymienione jako `rte`, domyślny runner, i czy jego strona pokazuje
+  **Połączenie** jako **Połączony**
+* Następne kroki:
+  * Twórz formularze, dodając pliki YAML do folderu data/forms/ lub korzystając z wbudowanego projektanta
+  * Dodaj swoje playbooki do folderu data/playbooks/
+  * Dodaj połączenie LDAP
+  * Dodaj użytkowników i grupy
+  * Dodaj runnery dla formularzy szablonów: AWX, AAP lub Ascender, Semaphore, Rundeck lub Jenkins
+  * Dodaj poświadczenia do połączeń zewnętrznych, na przykład z innymi serwerami MySQL lub API REST, albo do przekazywania do playbooków Ansible
+  * Podłącz repozytoria Git i wybierz, czy Twoje formularze i/lub playbooki mają być synchronizowane z repozytorium
+
+---
+
+## Struktura plików
+
+Projekt docker-compose ma następującą strukturę folderów:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/pl/_get_started/installation/docker.md b/i18n/pl/_get_started/installation/docker.md
new file mode 100644
index 0000000..8407dcd
--- /dev/null
+++ b/i18n/pl/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Instalacja
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Uruchom obrazy aplikacji AnsibleForms i RTE w Docker lub Podman, obok własnego serwera MySQL
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Możesz uruchomić AnsibleForms w Docker lub Podman jako dwa kontenery, aplikację i RTE, które uruchamia playbooki, połączone z bazą danych MySQL.
+
+---
+
+## Wymagania wstępne
+
+Zanim zaczniesz, potrzebujesz:
+
+* **Docker lub Podman** : jedno z nich zainstalowane i uruchomione
+* **MySQL** : zainstalowany i uruchomiony
+
+---
+
+## Instalacja MySQL
+
+Zainstaluj MySQL 8+ lub MariaDB na serwerze Linux, do którego kontener ma dostęp:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu dostarcza MySQL 8:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian dostarcza MariaDB zamiast MySQL, którą AnsibleForms również obsługuje:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 i nowsze oraz jego klony dostarczają MySQL 8 w AppStream:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms łączy się z bazą danych przez sieć, jako `DB_USER` z `DB_PASSWORD`. Daj mu osobnego użytkownika, z uprawnieniami tylko do
+schematu `AnsibleForms`, a nie roota:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+To wszystko, czego AnsibleForms potrzebuje: z tymi uprawnieniami tworzy i aktualizuje swój schemat oraz wykonuje kopie zapasowe. Strona **Stan** i dziennik
+ostrzegają, gdy użytkownik ma uprawnienia do wszystkich baz danych. Na Ubuntu i Debianie serwer nasłuchuje tylko na localhost: ustaw `bind-address` w jego
+konfiguracji, aby kontenery mogły się z nim połączyć.
+
+---
+
+## Przygotowanie folderów
+
+AnsibleForms 7 działa w dwóch kontenerach: aplikacji i RTE (runtime environment), które uruchamia playbooki. Oba montują folder na
+Twój `config.yaml`, formularze, playbooki, dzienniki i certyfikaty oraz folder na klucz SSH. Obrazy działają jako użytkownik `node` (uid 1000),
+więc przekaż temu użytkownikowi oba foldery:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Umieść ustawienia aplikacji w pliku środowiska: połączenie z bazą danych,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET), zanim zapiszesz jakiekolwiek poświadczenie, token współdzielony przez aplikację i
+RTE ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), co najmniej 16 znaków) oraz config seed, który deklaruje RTE:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+RTE dostaje własny plik, bez ustawień bazy danych: od wersji 7.3.0 aplikacja łączy się z nim i utrzymuje otwarty jeden WebSocket
+(`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)), a RTE uruchamia playbooki z tych samych folderów (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+[Config seed](../seed/) deklaruje poświadczenie RTE z adresem RTE i jego tokenem oraz domyślny runner `rte`, który się
+nim loguje:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Uruchomienie kontenerów
+
+Uruchom opublikowane obrazy z GitHub Container Registry (zobacz [Tagi obrazów](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) dla aplikacji i
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) dla RTE.
+
+Seed dodaje RTE w **Połączenia > Runnery** jako runner `rte`, domyślny, więc formularze playbooków działają na nim bez dalszej
+konfiguracji. Aplikacja tworzy schemat przy pierwszym uruchomieniu i łączy się z RTE, gdy oba działają (przykładowy `config.yaml` jest w
+[projekcie docker-compose](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Po uruchomieniu oba kontenery są widoczne na liście:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman przyjmuje te same opcje i nie wymaga usługi:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Po uruchomieniu oba kontenery są widoczne na liście:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+Aplikacja nasłuchuje na porcie `8000`, przez HTTP, chyba że ustawisz `HTTPS=1`. RTE nie jest publikowane na hoście: łączy się z nim tylko aplikacja, wewnątrz
+sieci. `--stop-timeout 30` daje RTE czas, aby przy zatrzymaniu pozwolić działającym playbookom się zakończyć (zobacz
+[Uruchamianie RTE](../rte/run.html), gdzie opisano ustawienia RTE i budowanie własnego RTE).
+
+---
+
+## Test aplikacji
+
+Gdy kontenery działają, otwórz AnsibleForms w przeglądarce:
+
+* Otwórz `http://your_ip:8000` (lub HTTPS, jeśli ustawiłeś `HTTPS=1`)
+* Zaloguj się jako `admin` / `AnsibleForms!123` (lub hasłem ustawionym przez `ADMIN_PASSWORD`) i wybierz nowe hasło
+* Sprawdź w **Połączenia > Runnery**, czy RTE jest wymienione jako `rte`, domyślny runner, i czy jego strona pokazuje
+  **Połączenie** jako **Połączony**
+* Następne kroki:
+  * Twórz formularze, dodając pliki YAML do folderu `forms` lub korzystając z wbudowanego projektanta
+  * Dodaj swoje playbooki do folderu `playbooks` w zamontowanym folderze trwałym
+  * Dodaj połączenie LDAP
+  * Dodaj użytkowników i grupy
+  * Dodaj runnery dla formularzy szablonów: AWX, AAP lub Ascender, Semaphore, Rundeck lub Jenkins
+  * Dodaj poświadczenia do połączeń zewnętrznych, na przykład z innymi serwerami MySQL lub API REST, albo do przekazywania do playbooków Ansible
diff --git a/i18n/pl/_get_started/installation/from-source.md b/i18n/pl/_get_started/installation/from-source.md
new file mode 100644
index 0000000..d671218
--- /dev/null
+++ b/i18n/pl/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: Ze źródeł
+parent: Instalacja
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# Ze źródeł
+{: .no_toc }
+
+Zbuduj AnsibleForms ze źródeł i uruchom go za pomocą Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Jak zorganizowany jest kod
+
+Repozytorium zawiera dwie aplikacje Node.js, a budowanie łączy je w jedną:
+
+* **client** : interfejs webowy, napisany w Vue 3 i budowany do plików statycznych za pomocą Vite
+* **server** : API, napisane w Express. Przekazuje zadania runnerom, łączy się z bazą danych i udostępnia zbudowanego klienta.
+  Uruchomiony z `AF_ROLE=rte`, ten sam serwer jest RTE (runtime environment), które uruchamia playbooki
+
+Budowany jest tylko klient; jego wynik trafia do folderu `views` serwera, tak jak w [obrazie Docker](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Wymagania wstępne
+
+Budowanie i uruchamianie ze źródeł wymaga solidnej znajomości Linuksa i pewnej wiedzy o Node.js. Każdy komponent instalujesz samodzielnie. Aby
+uruchomić AnsibleForms bez kontenerów i bez budowania, [instalacja natywna](native.html) instalatora zrobi to wszystko za Ciebie:
+
+* **Node.js 26** (wersja z `.nvmrc`; co najmniej 24), z npm
+* **Git**, aby pobrać kod i synchronizować repozytoria
+* **Klient OpenSSH**, dla git przez SSH, oraz **sshpass**, dla playbooków łączących się hasłem SSH
+* **Klient MariaDB** (`mariadb`, `mariadb-dump`), do kopii zapasowych i przywracania, także z serwerem MySQL
+* **MySQL 8+ lub MariaDB**, dostępny z serwera
+* **Ansible**, dla procesu RTE, który uruchamia playbooki (`ansible-playbook` w jego ścieżce). Sam proces aplikacji nie potrzebuje
+  Ansible ani Pythona, a mając tylko formularze szablonów (AWX, AAP, Ascender i pozostałe runnery), w ogóle nie potrzebujesz RTE
+
+Zainstaluj je dla swojej dystrybucji:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 pochodzi z repozytorium NodeSource, pozostałe narzędzia z samego Ubuntu:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 pochodzi z repozytorium NodeSource, pozostałe narzędzia z samego Debiana:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js pochodzi z NodeSource, a `sshpass` z EPEL (na samym RHEL włącz EPEL tak, jak opisuje to Red Hat):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Sprawdź `node --version` (26) i `ansible-playbook --version`; bazę danych i jej użytkownika opisuje [Instalacja MySQL](docker.html#install-mysql).
+
+---
+
+## Pobranie kodu
+
+Sklonuj repozytorium do wybranego folderu, którego właścicielem jest użytkownik uruchamiający aplikację. Przykłady używają `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Budowanie
+
+Zbuduj w trzech krokach, z folderu repozytorium. Najpierw zbuduj klienta:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Następnie zainstaluj zależności serwera:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Na koniec skopiuj zbudowanego klienta do folderu `views` serwera:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Konfiguracja
+
+Serwer odczytuje swoje ustawienia ze zmiennych środowiskowych oraz, w produkcji, także z `server/persistent/.env`, pliku,
+do którego zapisują strony ustawień.
+
+Zacznij od pliku przykładowego w katalogu głównym repozytorium i ustaw co najmniej połączenie z MySQL (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Wszystkie zmienne są opisane w [Zmienne środowiskowe](../customization). Wszystko inne jest domyślnie przechowywane w `server/persistent`:
+`config.yaml`, folder `forms` i certyfikaty samopodpisane są tam tworzone przy pierwszym uruchomieniu, obok dzienników.
+Umieść swoje playbooki w `server/persistent/playbooks` lub wskaż inne miejsce przez `ANSIBLE_PATH` w środowisku RTE, które je odczytuje.
+
+---
+
+## Uruchomienie
+
+Uruchom AnsibleForms w trybie produkcyjnym lub w trybie deweloperskim, aby pracować nad samym kodem:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Produkcja</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Rozwój</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Uruchom serwer w trybie produkcyjnym z folderu `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Aplikacja uruchomiona z wiersza poleceń zatrzymuje się po wylogowaniu. [PM2](https://pm2.keymetrics.io/) utrzymuje ją uruchomioną w
+tle, restartuje po awarii i uruchamia ponownie przy starcie systemu:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Playbooki działają na RTE: uruchom ten sam serwer drugi raz z `AF_ROLE=rte`, na własnym porcie. Aplikacja łączy się z nim i utrzymuje
+otwarty jeden WebSocket (`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)), a RTE uruchamia playbooki z tych samych folderów
+(`RTE_FILES=local`). Ono również odczytuje `persistent/.env`, ale nie używa żadnych ustawień bazy danych. Dodaj do `persistent/.env` token współdzielony przez aplikację i RTE,
+o długości co najmniej 16 znaków, oraz config seed, który deklaruje RTE:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+[Config seed](../seed/) deklaruje poświadczenie RTE z adresem RTE i jego tokenem oraz domyślny runner `rte`, który się
+nim loguje:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Bez seeda dodaj je w **Połączenia > Poświadczenia** (poświadczenie RTE z tym adresem i tokenem) oraz
+**Połączenia > Runnery** (typ RTE, **Tryb** **Przychodzący**). Następnie uruchom RTE, tylko na `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+Ustawienia RTE są opisane na stronie [Uruchamianie RTE](../rte/run.html). Sprawdź, czy PM2 wyświetla oba procesy:
+
+```bash
+pm2 status
+```
+
+Oba mają stan `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Aby pracować nad samym kodem, uruchom wszystko z katalogu głównego repozytorium z przeładowaniem na żywo: serwer na porcie 3001, RTE na porcie 8010
+i klienta pod `https://localhost:8443`. W tym trybie serwer i RTE odczytują zamiast tego `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+RTE (`npm run dev:rte`) wymaga `ansible-playbook` w ścieżce i dodaje się jako runner w trybie bazy danych, przestarzałym,
+wyłącznie na potrzeby rozwoju; `npm run dev:local` uruchamia klienta i serwer bez niego. [Przewodnik dla kontrybutorów](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) opisuje testy i sprawdzenia do uruchomienia.
+
+</div>
+</div>
+
+---
+
+## Pierwsze uruchomienie
+
+Otwórz serwer w przeglądarce (z przykładowym `.env`, `https://your_ip:8443`). Na pustej bazie danych schemat jest tworzony przy
+pierwszym uruchomieniu.
+
+Domyślne dane logowania administratora to:
+
+* nazwa użytkownika : `admin`
+* hasło : `AnsibleForms!123`
diff --git a/i18n/pl/_get_started/installation/index.md b/i18n/pl/_get_started/installation/index.md
new file mode 100644
index 0000000..5dcf716
--- /dev/null
+++ b/i18n/pl/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Instalacja
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Instalacja
+{: .no_toc }
+
+Wybierz metodę instalacji AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów konfigurujących nową instancję: wybierz metodę instalacji, a potem postępuj zgodnie z jej stroną.
+
+---
+
+## W tej sekcji
+
+AnsibleForms obsługuje kilka metod instalacji, każdą opisaną na osobnej stronie:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Instalator](installer.html) | Jedno polecenie, które instaluje kontroler lub Runner na Docker, Podman, Kubernetes lub natywnie, a potem go aktualizuje i tworzy jego kopie zapasowe |
+| [Natywnie](native.html) | Instalacja instalatorem bez kontenerów: Node.js, MariaDB i Ansible na serwerze, AnsibleForms jako usługi systemd |
+| [Docker](docker.html) | Zainstaluj MySQL i uruchom gotowy obraz Docker z wymaganymi zmiennymi środowiskowymi |
+| [Docker Compose](docker-compose.html) | Pobierz [projekt docker-compose](https://github.com/ansibleforms/docker) i użyj docker-compose, aby uruchomić zarówno MySQL, jak i AnsibleForms |
+| [Ze źródeł](from-source.html) | Zainstaluj ręcznie wszystkie zależności, a potem zbuduj i uruchom kod |
+| [Kubernetes](kubernetes.html) | Zainstaluj chart Helm i użyj Kubernetes, aby uruchomić AnsibleForms i jego bazę danych MySQL |
+
+{: .note }
+> **Zalecenie** Instalator, dostępny od wersji 7.3.0, to najszybsza droga do działającej instancji: na podstawie kilku pytań konfiguruje projekt Docker Compose na
+> Docker lub Podman albo jedną z pozostałych metod. Obrazy Docker zawierają wszystkie zależności.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Aby przenieść istniejącą instalację na nowsze wydanie, zobacz [Aktualizacja](../upgrading/).
+
+Każda metoda uruchamia jedno RTE obok aplikacji, czyli kontener (lub usługę), który uruchamia playbooki. Aby dodać kolejne, na innym hoście lub w innym
+centrum danych, zainstaluj Runner [instalatorem](installer.html#a-runner): łączy się on z AnsibleForms przez jeden WebSocket (wychodzący, zobacz
+[Tryby](../rte/modes.html)) i nie przechowuje poświadczeń do bazy danych. Zobacz też [Środowiska uruchomieniowe](../rte/) i ich runbook
+[RTE w innym centrum danych](../rte/another-datacenter.html).
+
+---
+
+## Tagi obrazów
+
+Obraz jest publikowany jako `ghcr.io/ansibleforms/ansibleforms` w GitHub Container Registry, który należy do
+projektu i nie ogranicza anonimowych pobrań. Każde wydanie od 7.0.0 jest publikowane wyłącznie tam, a wydania 6.x
+również tam są.
+
+Od wersji 7 playbooki działają na RTE, publikowanym w trzech warstwach obok aplikacji (zobacz [Obrazy RTE](../rte/images.html)):
+
+| Obraz | Czym jest |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | Aplikacja webowa i API, bez pythona i ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | RTE bez pythona i ansible: baza dla własnego obrazu |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | Baza z pythonem, ansible-core i kilkoma bibliotekami: ten, do którego dodajesz swoje kolekcje |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | Core z pakietem `ansible`, jego kolekcjami i bibliotekami: domyślne RTE |
+
+Cztery obrazy są budowane w tym samym przebiegu i mają te same tagi, więc tag RTE zawsze odpowiada tagowi aplikacji.
+
+Stare repozytorium Docker Hub, `ansibleguy/ansibleforms`, nie jest już aktualizowane. Zachowuje istniejące
+wydania, ale nie dostaje nowych wersji żadnej z linii. Jeśli pobierasz z niego obrazy, przejdź
+na `ghcr.io/ansibleforms/ansibleforms` z tym samym tagiem, aby nadal otrzymywać aktualizacje.
+
+Na każdym obrazie dostępne są następujące tagi; obrazy RTE zaczynają się od 7.0.0, więc nie mają tagów 6.x:
+
+| Tag | Wskazuje na |
+|---|---|
+| `latest` | najnowsze wydanie najnowszej wersji głównej |
+| `7`, `6` | najnowsze wydanie tej wersji głównej |
+| `7.0`, `6.5` | najnowsze wydanie tej wersji pomocniczej |
+| `7.0.0`, `6.5.5` | dokładnie to wydanie |
+| `latest-rc` | najnowszy kandydat do wydania albo najnowsze wydanie, jeśli jest nowsze; każdy kandydat ma też własny tag |
+
+`latest` przesuwa się tylko do przodu: poprawka dla starszej wersji głównej (na przykład 6.5.x wydana
+po 7.0.0) przesuwa `6` i `6.5`, ale nigdy `latest`.
+
+Aby pozostać na wersji głównej, używaj jej numeru (`6`) zamiast `latest`.
diff --git a/i18n/pl/_get_started/installation/installer.md b/i18n/pl/_get_started/installation/installer.md
new file mode 100644
index 0000000..a8fce96
--- /dev/null
+++ b/i18n/pl/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Instalator
+parent: Instalacja
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# Instalator
+{: .no_toc }
+
+Instaluj, aktualizuj i utrzymuj AnsibleForms na serwerze Linux jednym poleceniem
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów: najszybsza droga do działającej instancji lub do Runnera dla AnsibleForms zainstalowanego gdzie indziej. Od wersji 7.3.0.
+
+---
+
+## Co instaluje
+
+Instalator zadaje kilka pytań w pełnoekranowym kreatorze, pokazuje wszystkie odpowiedzi do przejrzenia i dopiero wtedy zmienia serwer.
+Instaluje jedną z dwóch ról, na jednym z czterech silników:
+
+| Rola | Czym jest |
+|---|---|
+| Kontroler | Pełna aplikacja: interfejs webowy, jego baza danych i własny Runner. Wybierz to przy pierwszej instalacji |
+| Runner | RTE, które uruchamia playbooki AnsibleForms zainstalowanego gdzie indziej, na przykład w innej sieci, w DMZ lub w innym centrum danych. Komunikuje się z AnsibleForms przez jeden WebSocket i nie przechowuje poświadczeń do bazy danych |
+
+Silniki, na których je instaluje:
+
+| Silnik | Jak działa |
+|---|---|
+| Docker | [Projekt Docker Compose](docker-compose.html), na Docker Engine z wtyczką compose. Kontenery restartują się razem z Dockerem |
+| Podman | Ten sam projekt na Podman, bez roota lub jako root, z podman-compose. Jednostka systemd uruchamia kontenery przy starcie systemu |
+| Kubernetes | [Chart Helm](kubernetes.html), na klastrze, do którego sięga `kubectl`. Kontroler jest udostępniany za ingress; Runner używa trybu runnera chartu |
+| Bezpośrednio na tym serwerze | Bez kontenerów: Node.js, MariaDB i Ansible na serwerze, a AnsibleForms jako usługi systemd. Zobacz [Instalacja natywna](native.html) |
+
+Po instalacji ten sam program aktualizuje instalację, tworzy jej kopie zapasowe, pokazuje jej stan i ją usuwa. Przejmuje też
+AnsibleForms, którego sam nie zainstalował, na przykład skonfigurowany ręcznie z projektu Docker Compose (zobacz [Istniejąca instalacja](#an-existing-installation)).
+
+---
+
+## Uruchomienie
+
+Skrypt instalacyjny pobiera instalator dla tego serwera i go uruchamia:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Typowe warianty: jako root, aby zainstalować Docker lub Podman, zainstalować bezpośrednio na serwerze lub w `/opt`; z poleceniem lub
+flagami (zobacz [Flagi](#flags)); oraz instalator konkretnego wydania zamiast najnowszego:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+Skrypt:
+
+1. Sprawdza, czy serwer działa pod Linuksem na amd64 lub arm64, i odnajduje `curl` lub `wget` oraz `sha256sum`
+2. Pobiera `ansibleforms-installer_linux_<arch>` z najnowszego wydania
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases) lub z wydania wskazanego przez `AF_INSTALLER_VERSION`
+3. Sprawdza go względem `checksums.txt` wydania i nie używa żadnego pobranego pliku, którego suma kontrolna się różni
+4. Zachowuje go jako `ansibleforms-installer`, w `/usr/local/bin` dla roota, a w pozostałych przypadkach w `~/.local/bin`, na potrzeby późniejszych aktualizacji i kopii zapasowych.
+   Przez sudo uruchamiaj go pełną ścieżką: `secure_path` sudo, tak jak w systemach Red Hat, często pomija `/usr/local/bin`
+5. Uruchamia go z podanymi flagami, odczytując klawiaturę z terminala, mimo że skrypt przyszedł przez potok
+
+Bez terminala, na przykład w zadaniu CI, instalator działa bez nadzoru (zobacz [Bez nadzoru](#unattended)).
+
+---
+
+## Kreator
+
+Kreator zadaje jedno pytanie naraz, a kroki są wymienione po lewej. **Esc** wraca do poprzedniego kroku, z zachowaną odpowiedzią:
+
+| Krok | O co pyta |
+|---|---|
+| Język | Język instalatora, domyślnie według ustawień regionalnych tego serwera: kataloński, niemiecki, angielski, hiszpański, francuski, włoski, japoński, niderlandzki, polski, portugalski lub chiński. Pytanie pada jako pierwsze, zanim instalator powie cokolwiek o znalezionej instalacji |
+| O wydaniu | Co nowego w instalowanej wersji, najpierw zmiany niezgodne wstecz, usunięcia i elementy przestarzałe |
+| Rola | Kontroler lub Runner |
+| Silnik | Docker, Podman, Kubernetes lub bezpośrednio na tym serwerze |
+| Folder | Folder instalacji i nazwa instancji |
+| Dołączenie, Aplikacja, Tryb | Tylko Runner: zobacz [Runner](#a-runner). Na Kubernetes bez trybu |
+| Sieć | Port interfejsu webowego lub Runnera. Nie na Kubernetes |
+| HTTPS | Jak przeglądarki łączą się z kontrolerem |
+| Administrator | Hasło pierwszego administratora, wpisywane dwukrotnie |
+| Klaster, Ingress, Storage | Tylko Kubernetes: przestrzeń nazw i wydanie, ingress (kontroler), klasa storage |
+| Przegląd | Wszystkie odpowiedzi: **Zainstaluj** lub **Zmień odpowiedzi** |
+
+**Silnik.** Lista pokazuje, co ma ten serwer. Silnik, którego brakuje, jest oferowany jako *Docker (niezainstalowany: instalator go zainstaluje)*
+lub analogicznie dla Podmana: po potwierdzeniu instalator instaluje Docker własnym skryptem Dockera (`get.docker.com`, łącznie z wtyczką
+compose) lub Podman z podman-compose z pakietów dystrybucji. Wymaga to uprawnień roota. Kubernetes jest oferowany, gdy `kubectl` i
+`helm` są zainstalowane i sięgają do klastra. *Bezpośrednio na tym serwerze* wymaga uprawnień roota i obsługiwanego Linuksa, a gdy jest wyszarzone, podaje przyczynę.
+
+**Folder.** Wartości domyślne:
+
+| | Kontroler | Runner |
+|---|---|---|
+| Folder, jako root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Folder, jako inny użytkownik | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Nazwa instancji, Docker lub Podman | `af` | `runner` |
+| Nazwa instancji, natywnie | `ansibleforms` | `ansibleforms-runner` |
+
+W przypadku Dockera lub Podmana folder zawiera plik compose i jego `.env` z sekretami oraz wszystkie dane: bazę danych, formularze, playbooki
+i dzienniki. Musi być pusty. Nazwa instancji, złożona z małych liter, cyfr i `-`, jest prefiksem kontenerów (`af_app`, `af_db`, `af_rte`), więc kilka
+instancji może współdzielić serwer. Nazwa instancji Runnera jest też nazwą jego runnera w **Połączenia > Runnery** (`RTE_NAME`).
+
+**Sieć.** Interfejs webowy kontrolera nasłuchuje na `443` lub kolejnym wolnym porcie. **HTTPS** oferuje wtedy:
+
+| Wybór | Co robi |
+|---|---|
+| HTTPS z certyfikatem samopodpisanym utworzonym dla tego serwera | Certyfikat dla nazw tego serwera, ważny przez dziesięć lat. Przeglądarki raz proszą o jego zaakceptowanie |
+| HTTPS z moim własnym certyfikatem i kluczem | Twój własny certyfikat i klucz, w formacie PEM, od Twojego CA lub z Let's Encrypt |
+| HTTP, a HTTPS obsługuje reverse proxy przed nim | Zwykły HTTP na porcie, dla nginx, Traefik lub load balancera, który obsługuje HTTPS |
+
+**Administrator.** Hasło użytkownika `admin`, wpisywane dwukrotnie, aby literówka Cię nie zablokowała. Gdy pozostanie puste, instalator generuje
+silne hasło.
+
+**Koniec.** Instalator generuje hasło do bazy danych i sekrety, uruchamia AnsibleForms i czeka, aż odpowie. Następnie
+pokazuje adres do otwarcia, użytkownika i hasło oraz folder. Runnery zainstalowane dla niego proszą o dołączenie, a administrator zatwierdza
+je w **Połączenia > Runnery** (zobacz [Runner](#a-runner)).
+
+---
+
+## Runner
+
+Runner to RTE dla AnsibleForms działającego gdzie indziej, w wersji 7.3.0 lub nowszej. Nie przechowuje poświadczeń do bazy danych: loguje się
+własnym tokenem, który AnsibleForms przechowuje w poświadczeniu RTE (zobacz [Tryby](../rte/modes.html)). Po folderze kreator
+pyta o trzy kolejne rzeczy:
+
+| Krok | O co pyta |
+|---|---|
+| Aplikacja | Adres AnsibleForms, dla którego pracuje ten Runner, ten, który ludzie otwierają w przeglądarce |
+| Tryb | **Wychodzący: Runner łączy się z AnsibleForms** (domyślnie) lub **Przychodzący: AnsibleForms łączy się z Runnerem** |
+| Sieć | Port Runnera, domyślnie `8000`. W trybie wychodzącym nasłuchują na nim tylko kontrole stanu, dostępne wyłącznie z tego serwera. W trybie przychodzącym także adres tego serwera, pod którym sięga do niego AnsibleForms |
+
+`--role runner` pomija pytanie o rolę, więc to polecenie, uruchomione na serwerze Runnera, zaczyna od pytań dla Runnera:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+Instalator łączy się następnie z AnsibleForms. Przy certyfikacie samopodpisanym lub wystawionym przez prywatne CA pyta **Zaufać temu certyfikatowi?**:
+tak ustawia [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) na Runnerze. Odczytuje wersję, na której działa AnsibleForms,
+odrzuca wersję starszą niż 7.3.0 i instaluje Runner w tej samej wersji, niezależnie od tego, jaką wersję zainstalowałby sam instalator.
+
+Wybierz tryb wychodzący dla DMZ, NAT lub strefy, która nie pozwala na połączenia przychodzące: tylko ruch z tego serwera do AnsibleForms, na jego
+porcie. Wybierz tryb przychodzący dla sieci, w których każde połączenie otwiera strona centralna.
+
+Przegląd pokazuje **Rejestracja: prosi o zatwierdzenie** albo **sam, tokenem dołączenia**, gdy podano go przez `--join`. Na koniec instalator
+pokazuje nazwę Runnera, jego tryb, aplikację oraz, w trybie przychodzącym, jego adres, a następnie informuje, że poprosił o dołączenie do AnsibleForms: zatwierdź go w
+**Połączenia > Runnery** po sprawdzeniu, że widoczny tam odcisk jest tym, który wypisuje:
+
+```
+Fingerprint: abcd-ef12
+```
+
+Odcisk to pierwsze 8 cyfr szesnastkowych SHA-256 tokenu Runnera, `RTE_TOKEN`, który jest przechowywany w pliku
+`.env` folderu (`rte.env` dla [instalacji natywnej](native.html)). Zobacz [Zatwierdzanie RTE](../runners/registration.html#approving-an-rte). Z `--join` Runner jest zatwierdzany od razu:
+zarejestrował się sam i jest widoczny jako połączony w **Połączenia > Runnery**.
+
+Przychodzący Runner udostępnia swoje gniazdo przez HTTPS. Instalator tworzy certyfikat samopodpisany dla adresu, pod którym sięga do niego AnsibleForms,
+ważny przez dziesięć lat, w `data/certificates` folderu, i ustawia `RTE_URL` na `https://<address>:<port>`.
+Runner wysyła certyfikat, gdy prosi o dołączenie, a AnsibleForms go przypina: łączy się z tym Runnerem tylko wtedy, gdy przedstawi
+ten sam certyfikat, więc żadne CA nie jest potrzebne. Instalator wypisuje odcisk certyfikatu pod odciskiem tokenu:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+To pierwsze 8 cyfr szesnastkowych SHA-256 bajtów DER certyfikatu, w postaci `xxxx-xxxx`. Zanim zatwierdzisz Runner,
+sprawdź, czy okno zatwierdzania pokazuje ten sam odcisk certyfikatu. Runner zarejestrowany z `--join` również go wypisuje.
+
+Na Kubernetes Runner to tryb runnera chartu Helm i zawsze jest wychodzący: kreator nie pyta o tryb ani o sieć, bo nic
+nie sięga do niego z zewnątrz (zobacz [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Dla kontrolera na Kubernetes instalator instaluje [chart Helm](kubernetes.html) na klastrze, do którego sięga `kubectl`:
+
+| Pytanie | Domyślnie |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nazwa wydania Helm | `ansibleforms` |
+| Nazwa hosta obsługiwana przez ingress | Brak: wymagana, na przykład `ansibleforms.example.com` |
+| Klasa ingress | Jedna z klas klastra, domyślnie `nginx` |
+| Udostępniać przez HTTPS (z certyfikatem ingressu)? | Tak |
+| Klasa storage dla woluminów | Domyślna klastra |
+
+Hasło administratora jest w Secrecie `<release>-secrets` tej przestrzeni nazw, pod kluczem `ADMIN_PASSWORD`. Instalator przechowuje
+wartości chartu w pliku obok swojego pliku stanu, `<release>-values.yaml`, i stosuje je ponownie przy aktualizacjach; `--values` dodaje własny plik. Chart danego wydania jest publikowany krótko po nim.
+
+Dla Runnera instalator instaluje ten sam chart w jego [trybie runnera](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): samo RTE,
+bez aplikacji, bazy danych i ingress, które łączy się z AnsibleForms (wychodzące). Po adresie aplikacji kreator pyta o:
+
+| Pytanie | Domyślnie |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nazwa wydania Helm | `ansibleforms-runner`, która jest też nazwą jego runnera w **Połączenia > Runnery** |
+| Klasa storage dla woluminów | Domyślna klastra |
+
+Instalator tworzy token Runnera i ustawia adres aplikacji, nazwę runnera oraz, gdy ufasz certyfikatowi aplikacji,
+`runner.appTlsVerify: false`. Z `--join` token dołączenia od razu zatwierdza Runner; bez niego Runner prosi o dołączenie, a
+instalator wypisuje jego odcisk do sprawdzenia przed zatwierdzeniem w **Połączenia > Runnery**.
+
+---
+
+## Polecenia
+
+Instalator przyjmuje polecenie, przed flagami lub po nich. Bez polecenia instaluje:
+
+| Polecenie | Co robi |
+|---|---|
+| `install` | Instaluje AnsibleForms, jako kontroler lub Runner (domyślnie). Na serwerze, który ma już instalację, własną lub znalezioną, proponuje jej aktualizację |
+| `upgrade` | Aktualizuje do nowszej wersji, najpierw pokazując informacje o wydaniu (zobacz [Aktualizacja](#upgrade)) |
+| `status` | Pokazuje instalację (jej rolę, silnik i wersję) oraz jej kontenery, pody lub usługi i to, czy odpowiada. Następnie wymienia inne AnsibleForms znalezione na serwerze |
+| `backup` | Od razu tworzy kopię zapasową bazy danych, w `installer-backups` w folderze instalacji (na Kubernetes w `backups` obok pliku stanu instalatora). Runner nie przechowuje danych do kopii zapasowej |
+| `release-notes` | Pokazuje informacje o wydaniu danej wersji, `--version` lub wersji tego instalatora, najpierw zmiany niezgodne wstecz |
+| `uninstall` | Usuwa instalację, a z `--purge` także jej dane |
+| `version` | Wypisuje wersję instalatora |
+
+Instalator zapamiętuje instalację w `/etc/ansibleforms/installer.json` dla roota lub w `~/.config/ansibleforms/installer.json`
+dla innego użytkownika, więc polecenia po `install` nie wymagają flag i same znajdują instalację. Ten folder nie zawiera pliku binarnego
+i istnieje dopiero wtedy, gdy instalator zainstalował AnsibleForms lub przejął istniejący:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` pyta **Usunąć też dane (baza danych, formularze, playbooki, logi)?**. Aby je usunąć, wpisz nazwę instancji (wydanie Helm
+na Kubernetes); w przeciwnym razie usuwa kontenery, pody lub usługi i zachowuje dane.
+
+---
+
+## Flagi
+
+Każda flaga odpowiada na pytanie, które kreator wtedy pomija. `ansibleforms-installer --help` je wymienia:
+
+| Flaga | Na co odpowiada |
+|---|---|
+| `--lang <code>` | Język: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` lub `zh` |
+| `--version <version>` | Wersja AnsibleForms do zainstalowania lub do aktualizacji; domyślnie wersja tego instalatora |
+| `--role <role>` | `controller` lub `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` lub `native` |
+| `--runtime <runtime>` | `docker` lub `podman` (compose) |
+| `--install-runtime` | Instaluje Docker lub Podman, gdy go brakuje, bez pytania |
+| `--dir <folder>` | Folder instalacji (compose) |
+| `--name <name>` | Nazwa instancji, prefiks jej kontenerów (compose, domyślnie `af`) |
+| `--port <port>` | Port na hoście: interfejsu webowego dla kontrolera, RTE dla Runnera |
+| `--tls <choice>` | `self`, `own` lub `off` (kontroler compose) |
+| `--cert <file>`, `--key <file>` | Pliki certyfikatu i klucza, z `--tls own` |
+| `--admin-password <password>` | Hasło pierwszego administratora; domyślnie generowane |
+| `--join <token>` | Token dołączenia (`afj_...`), utworzony przez API, który od razu zatwierdza Runner (Runner, bez nadzoru; zobacz [Tokeny dołączenia](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | Adres aplikacji, na przykład `https://forms.example.com` (Runner) |
+| `--runner-mode <mode>` | `outbound` (RTE łączy się z aplikacją) lub `inbound` (aplikacja łączy się z RTE) (Runner) |
+| `--host <address>` | Adres tego serwera, z którym łączy się aplikacja (przychodzący Runner) |
+| `--namespace <namespace>` | Przestrzeń nazw Kubernetes, domyślnie `ansibleforms` |
+| `--release <release>` | Wydanie Helm, domyślnie `ansibleforms` |
+| `--hostname <name>` | Nazwa hosta ingress (kubernetes) |
+| `--ingress-class <class>` | Klasa ingress (kubernetes) |
+| `--storage-class <class>` | Klasa storage (kubernetes) |
+| `--values <file>` | Dodatkowy plik wartości Helm (kubernetes) |
+| `--purge` | Z `uninstall`: usuwa też dane |
+| `--source <folder>` | Lokalna kopia repozytorium [ansibleforms/docker](https://github.com/ansibleforms/docker), z której ma nastąpić instalacja (bez dostępu do sieci) |
+| `--bundle <file>` | Paczka wydania, `ansibleforms-<version>-linux-<arch>.tar.gz`, z której ma nastąpić instalacja natywna (zobacz [Instalacja natywna](native.html#air-gapped)) |
+| `--yes` | Odpowiada na każde pytanie wartością domyślną (bez nadzoru) |
+| `--verbose` | Pokazuje każde uruchamiane polecenie |
+
+---
+
+## Bez nadzoru
+
+Z `--yes` lub bez terminala instalator o nic nie pyta: flagi odpowiadają na swoje pytania, a wartości domyślne na pozostałe.
+Pomija język, informacje o wydaniu, hasło administratora (generowane, chyba że podano je przez `--admin-password`) i przegląd, a zamiast tego wypisuje
+link do informacji o wydaniu. Brakujący Docker lub Podman instaluje tylko z `--install-runtime` lub `--yes`, a Runner
+wymaga `--app-url`. Bez `--join` Runner prosi o dołączenie i czeka na zatwierdzenie przez administratora; z nim jest zatwierdzany od razu.
+
+Kontroler na Dockerze, z instalacją Dockera, gdy go brakuje:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Przychodzący Runner na Podmanie, z którym aplikacja łączy się pod `rte-dmz.example.com:8000`:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Istniejąca instalacja
+
+Instalator zapamiętuje, co zainstalował, w `installer.json`. Bez tego pliku `install`, `upgrade` i `status` najpierw szukają
+AnsibleForms, który już jest na serwerze, niezależnie od tego, co go zainstalowało:
+
+| Znalezione | Jak jest znajdowane | Przejmowane, gdy |
+|---|---|---|
+| Docker lub Podman | Kontenery z obrazem aplikacji lub RTE, pogrupowane według projektu compose | Folder zawiera plik compose i `.env` z repozytorium [ansibleforms/docker](https://github.com/ansibleforms/docker): usługi `mysqldb`, `app` i `rte`, w kontenerach `<name>_db`, `<name>_app` i `<name>_rte` |
+| Runner 7.2 | Samo RTE w swoim projekcie compose, z `DB_*` aplikacji i bez `RTE_MODE` (tryb bazy danych) | Jego plik compose da się odczytać. Jego aktualizacja przenosi go do trybu gniazda (zobacz [Runner 7.2](#a-72-runner)) |
+| Kubernetes | Wydania Helm chartu `ansibleforms` oraz Deploymenty i StatefulSety jego obrazów | Jest to wydanie chartu: jego bieżące wartości stają się jego plikiem wartości |
+| Natywnie | Usługi systemd, które uruchamiają AnsibleForms z Node.js | Mają układ instalatora: `releases/`, `current`, `app.env` i `rte.env` (zobacz [Instalacja natywna](native.html#the-folder)) |
+| Bez silnika | Aplikacja lub RTE odpowiadające na typowym porcie: 443, 3000, 3001, 8000, 8001, 8010 lub 8443 | Nigdy: działa ze źródeł lub uruchomione ręcznie. Instalator tylko to zgłasza |
+
+Liczą się tylko obrazy aplikacji i RTE: kontener MySQL nazwany od AnsibleForms nie jest instalacją. Instalator wymienia to, co
+znalazł, po jednym wierszu, z przyczyną i z tym, co zrobić ręcznie w przypadku instalacji, której nie może przejąć: jej plik compose nie pochodzi z repozytorium,
+jej baza danych jest poza jej projektem compose, działa na Kubernetes bez chartu Helm, jest zarządzana przez Argo CD (aktualizuj ją tam,
+zmieniając wersję chartu w Application) albo nie da się odczytać jej wersji.
+
+Dla instalacji, którą może przejąć, `install` oferuje trzy opcje:
+
+| Wybór | Co robi |
+|---|---|
+| Przejmij i zaktualizuj | Pokazuje, co zapamięta, a po potwierdzeniu zapisuje `installer.json` i przechodzi do [aktualizacji](#upgrade) |
+| Mimo to zainstaluj nowy AnsibleForms obok | Druga instalacja, z własnym folderem, portami i bazą danych, po osobnym potwierdzeniu |
+| Zatrzymaj | Nic nie jest zmieniane |
+
+Dla instalacji, która już działa w wersji, jaką zainstalowałby instalator, pierwszą opcją jest zamiast tego **Przejmij**: instalator
+zapamiętuje, gdzie jest i jak działa, na potrzeby kopii zapasowych, stanu i kolejnych aktualizacji, a teraz nic nie jest zmieniane.
+
+`upgrade` oferuje to samo bez drugiej opcji i zatrzymuje się, gdy nie ma czego przejąć. Bez nadzoru `install` zatrzymuje się z komunikatem,
+a `upgrade --yes` przejmuje instalację tylko wtedy, gdy znajdzie dokładnie jedną, którą może przejąć. Bieżące wartości wydania Kubernetes są
+zapisywane obok `installer.json`, a aktualizacje stosują je ponownie z chartem nowej wersji.
+
+---
+
+## Aktualizacja
+
+`ansibleforms-installer upgrade` przenosi instalację na nowszą wersję w obrębie tej samej wersji głównej. Wymienia nowsze wersje,
+od najnowszej (bez nadzoru wybiera najnowszą), i pokazuje informacje o wydaniu każdej pomijanej wersji, najpierw zmiany niezgodne wstecz
+i usunięcia. Gdy zawierają zmiany niezgodne wstecz, prosi o potwierdzenie, że je przeczytałeś; bez nadzoru kontynuuje tylko z `--yes`.
+
+Instalator tworzy kopię zapasową bazy danych, zanim cokolwiek się zmieni. Gdy nowa wersja nie odpowiada, proponuje wycofanie: wraca poprzednia
+wersja, a jej baza danych jest przywracana z tej kopii zapasowej. Nie obniża wersji i nie przekracza wersji głównej: w tym celu postępuj zgodnie z
+[przewodnikiem aktualizacji](../upgrade-7.html), na przykład z 6.x do 7.x, z opisem tego, co zrobić na 6.5 przed aktualizacją.
+
+Na Dockerze lub Podmanie aktualizacja kontrolera doprowadza też jego pliki do stanu zgodnego z nową wersją repozytorium docker:
+
+| Plik | Co robi aktualizacja |
+|---|---|
+| `docker-compose.yml` | Zastępowany plikiem nowej wersji, po zapisaniu kopii w `installer-backups` |
+| `.env` | Każdy istniejący wiersz jest zachowywany, a klucze potrzebne nowej wersji są dodawane, z sekretami tworzonymi tak jak przy świeżej instalacji. Najpierw zapisywana jest kopia |
+| `data/seed.yaml` | Zastępowany, gdy jest to niezmieniony seed dostarczony z repozytorium docker. Plik zmieniony ręcznie zostaje zachowany, a nowy jest zapisywany obok niego |
+| `data/` | Nowe pliki, które przynosi wersja, na przykład nowy playbook, są dodawane. Każdy istniejący plik zostaje zachowany |
+
+Brakującego ustawienia bazy danych (`MYSQLDB_USER` lub hasła) nie da się wymyślić dla istniejącej bazy danych, więc aktualizacja zatrzymuje się wtedy przed
+jakąkolwiek zmianą. Wycofanie przywraca plik compose, `.env` i seed do poprzedniego stanu.
+
+Runner działa w tej samej wersji co jego AnsibleForms: najpierw zaktualizuj AnsibleForms, a potem jego Runnery. Aktualizacja Runnera przepisuje jego
+plik compose dla nowego obrazu RTE i zachowuje jego `.env` i dane bez zmian.
+
+---
+
+## Runner 7.2
+
+Runner 7.2 działa w trybie bazy danych, przestarzałym od wersji 7.3.0: jego RTE przechowuje ustawienia bazy danych AnsibleForms. Instalator go
+znajduje (zobacz [Istniejąca instalacja](#an-existing-installation)), a jego aktualizacja przenosi go do trybu gniazda pod tym samym runnerem:
+
+1. Odczytuje nazwę runnera (`RTE_NAME`) i token (`RTE_TOKEN`) ze starego kontenera RTE. Gdy RTE nie zarejestrowało się samo
+   (`RTE_REGISTER=0`), wpisujesz nazwę, którą jego runner ma w **Połączenia > Runnery**
+2. Pyta o adres aplikacji i tryb, domyślnie **wychodzący** lub przychodzący, a dla przychodzącego o port i adres tego serwera
+3. Pokazuje plan, a następnie tworzy kopię zapasową starego pliku compose i `.env` w `installer-backups`
+4. Zapisuje układ Runnera instalatora bez ustawień `DB_*`. Zachowuje `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` i `METRICS_TOKEN`, które RTE w trybie gniazda nadal odczytuje
+5. Uruchamia nowe RTE obok starego. Nowe RTE loguje się własnym tokenem runnera, a AnsibleForms samo przenosi runner do
+   nowego trybu, **bez zatwierdzania**: jego zadania i formularze, które go wskazują, pozostają bez zmian
+6. Gdy nowe RTE jest połączone, stary kontener jest zatrzymywany i usuwany
+
+Przychodzący Runner udostępnia HTTPS z przypiętym certyfikatem, tak jak nowy (zobacz [Runner](#a-runner)), a instalator wypisuje odcisk jego
+certyfikatu. Gdy stare RTE zajmuje port potrzebny nowemu, jest najpierw zatrzymywane, więc Runner jest niedostępny, dopóki
+nowe się nie połączy. Nowe RTE wychodzącego Runnera zajmuje wolny port na `127.0.0.1` i działa obok starego bez przerwy.
+
+Gdy instalator nie może odczytać tokenu ze starego RTE, wybierasz, jak nowe RTE ma się logować:
+
+| Wybór | Co dalej |
+|---|---|
+| Wpisz token runnera | Hasło poświadczenia RTE runnera w **Połączenia > Poświadczenia**. Runner zachowuje nazwę i zadania |
+| Dołącz jako nowy runner z tokenem dołączenia | [Token dołączenia](../runners/registration.html#join-tokens) dodaje nowy runner pod inną nazwą. Stary runner wycofaj ręcznie |
+
+Gdy nowe RTE się nie łączy, instalator proponuje przywrócenie starych plików i ponowne uruchomienie starego kontenera; jeśli AnsibleForms
+zdążyło już przenieść runner, ustaw z powrotem jego tryb na bazę danych w **Połączenia > Runnery**. Gdy nowe RTE jest połączone, nie ma
+odwrotu: stare pliki pozostają w `installer-backups`.
+
+Gdy AnsibleForms nie zna runnera o tej nazwie, nowe RTE zamiast tego prosi o dołączenie i czeka na zatwierdzenie. Odrzuć tę prośbę w
+**Połączenia > Runnery**, a potem uruchom aktualizację ponownie z nazwą, którą ma tam runner.
+
+---
+
+## Wersje
+
+Wersja instalatora podąża za wersją aplikacji: każde wydanie AnsibleForms ma instalator w tej samej wersji, wydany razem z nim, a
+ten instalator domyślnie instaluje tę wersję. `--version` instaluje inną. Każde wydanie na
+[stronie Releases instalatora](https://github.com/ansibleforms/installer/releases) zawiera pliki binarne dla Linuksa na amd64 i arm64, wraz z ich
+sumami kontrolnymi.
diff --git a/i18n/pl/_get_started/installation/kubernetes.md b/i18n/pl/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..e32eef8
--- /dev/null
+++ b/i18n/pl/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Instalacja
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Zainstaluj AnsibleForms i jego bazę danych MySQL za pomocą chartu Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Chart Helm wdraża AnsibleForms z MySQL i RTE, które uruchamia playbooki (zobacz [opis wartości](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+[Instalator](installer.html) również instaluje chart, na podstawie kilku pytań, i aktualizuje wydanie, którego sam nie zainstalował. Ten sam
+chart instaluje też samodzielny Runner, dla AnsibleForms działającego gdzie indziej (zobacz [Runner na Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Wymagania wstępne
+
+Zanim zaczniesz, potrzebujesz:
+
+* **Klastra Kubernetes** : ze skonfigurowanym `kubectl`, który ma do niego dostęp
+* **Helm 3** : do instalowania i aktualizowania chartu
+* **Pamięci masowej** : StorageClass do dynamicznego przydzielania lub wcześniej utworzonych PersistentVolumes
+* **Kontrolera ingress** : tylko jeśli chcesz udostępnić AnsibleForms przez ingress
+
+---
+
+## 1. Pobranie wartości chartu
+
+Pobierz domyślne wartości chartu do własnego pliku, z repozytorium chartów lub z rejestru OCI:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Repozytorium chartów</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">Rejestr OCI</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Nie trzeba dodawać repozytorium: chart jest pobierany z GitHub Container Registry.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Konfiguracja pamięci masowej
+
+Zarówno AnsibleForms, jak i MySQL przechowują dane na wolumenie trwałym. Ustaw StorageClass i rozmiar każdego z nich:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Pusty `className` używa domyślnej StorageClass klastra. Tryb dostępu ma domyślnie wartość `ReadWriteMany`, której wiele klas
+pamięci masowej nie oferuje; `ReadWriteOnce` wystarcza przy jednej replice. W przypadku wcześniej utworzonych PersistentVolumes zobacz
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) chartu.
+
+---
+
+## 3. Ustawienie poświadczeń
+
+AnsibleForms potrzebuje konta administratora, hasła do bazy danych i `ENCRYPTION_SECRET`, klucza, który szyfruje poświadczenia
+przechowywane w AnsibleForms. Aby później zmienić ten klucz, ustaw [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+na stary klucz na czas jednego uruchomienia: każdy zapisany sekret zostanie wtedy ponownie zaszyfrowany nowym kluczem. Podaj je na jeden z trzech sposobów:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">W pliku wartości</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Generowane przez chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Istniejący Secret</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Ustaw je w `my_values.yaml`. Chart przechowuje je w Secrecie o nazwie `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Pozwól chartowi wygenerować przy pierwszej instalacji wszystko, czego nie podasz. Zachowuje te same wartości przy każdej
+kolejnej aktualizacji:
+
+```bash
+--set secrets.generate=true
+```
+
+Nie działa to z Argo CD ani Flux, które renderują chart bez dostępu do klastra. Wygenerowany Secret
+przetrwa `helm uninstall`; zrób jego kopię zapasową, bo `ENCRYPTION_SECRET` nie da się odzyskać.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Wskaż chartowi Secret, którym zarządzasz, na przykład za pomocą External Secrets, Sealed Secrets lub SOPS. Chart
+nie tworzy wtedy żadnego:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+Secret musi zawierać `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` i `ADMIN_PASSWORD`.
+
+</div>
+</div>
+
+---
+
+## 4. Wybór obrazu RTE
+
+AnsibleForms 7 sam nie uruchamia żadnego playbooka: robi to RTE (runtime environment). Chart uruchamia je jako drugi kontener w
+podzie serwera, na tym samym wolumenie, i rejestruje je jako domyślny runner `rte`, więc formularze playbooków działają bez żadnej konfiguracji. Od wersji 7.3.0
+aplikacja łączy się z nim pod `127.0.0.1` i utrzymuje otwarty jeden WebSocket (`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)): RTE nie dostaje
+ustawień bazy danych ani klucza szyfrowania. Config seed chartu deklaruje poświadczenie RTE z tokenem i tym adresem oraz
+runner, w trybie inbound, który się nim loguje.
+
+Domyślny obraz, `ghcr.io/ansibleforms/ansibleforms-rte-full`, zawiera ansible z jego kolekcjami i biblioteki Pythona, które miał obraz 6.5.
+Jeśli potrzebujesz więcej lub mniej, zbuduj własny na jednej z trzech warstw RTE (`ansibleforms-rte-base`, `-rte-core` lub `-rte-full`, zobacz
+[Obrazy RTE](../rte/images.html)) i wskaż go chartowi:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+Token między aplikacją a RTE oraz klucz podpisujący sesje są generowane przy pierwszej instalacji do
+Secretu `<release>-keys` i zachowywane przy każdej aktualizacji. Przy własnym config seed dodaj do niego to poświadczenie i runner: uwagi, które Helm wypisuje po instalacji, pokazują, jak to zrobić
+(zobacz [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) chartu).
+
+---
+
+## 5. Instalacja chartu
+
+Zainstaluj chart we własnej przestrzeni nazw ze swoimi wartościami:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+W przypadku rejestru OCI użyj `oci://ghcr.io/ansibleforms/charts/ansibleforms` jako chartu. We wszystkim, co działa bez nadzoru,
+przypnij wersję chartu przez `--version`, aby nowe wydanie nigdy nie zainstalowało się samo.
+
+---
+
+## 6. Sprawdzenie instalacji
+
+Chart zawiera test, który sprawdza zarówno serwer webowy, jak i połączenie z bazą danych:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+Test kończy się wynikiem `OK`, gdy AnsibleForms odpowiada, a jego baza danych przyjmuje połączenia.
+
+---
+
+## 7. Otwarcie AnsibleForms
+
+Sposób dostępu do AnsibleForms zależy od tego, jak udostępniony jest serwer:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Przy domyślnej usłudze `ClusterIP` i bez ingress nic nie jest udostępniane poza klastrem. Przekieruj lokalny port, aby
+się rozejrzeć:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Następnie otwórz `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Ustaw `services.server.type: LoadBalancer` (opcjonalnie ze stałym adresem w `services.server.loadbalancer.ip`),
+a potem poczekaj, aż usługa otrzyma adres:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Włącz ingress i ustaw nazwę hosta, która kieruje do Twojego kontrolera ingress:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) chartu opisuje TLS za ingress, łącznie z ustawieniem backendu, którego wymaga HTTPS na
+serwerze.
+
+</div>
+</div>
+
+---
+
+## 8. Logowanie
+
+Zaloguj się jako użytkownik administrator, domyślnie `admin`. Aby odczytać hasło z Secretu:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Przy `secrets.existingSecret` odczytaj je zamiast tego z własnego Secretu.
+
+---
+
+## Runner na Kubernetes
+
+Przy `runner.enabled` chart instaluje tylko RTE: Runner dla AnsibleForms zainstalowanego gdzie indziej, w innej przestrzeni nazw, innym
+klastrze lub na maszynie wirtualnej. Łączy się on z aplikacją i utrzymuje otwarty jeden WebSocket (`RTE_MODE=outbound`, zobacz [Tryby](../rte/modes.html)), więc nie potrzebuje
+bazy danych, klucza szyfrowania ani portu przychodzącego. Nie renderuje aplikacji, MySQL, Service ani Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Wartość | Co robi |
+|---|---|
+| `runner.enabled` | Instaluje tylko Runner: bez aplikacji, MySQL, Service i Ingress |
+| `runner.appUrl` | Adres aplikacji, pod którym otwierają ją ludzie, z jej `BASE_URL`, jeśli jest. Wymagane |
+| `runner.name` | Nazwa runnera, pod którą dołącza (`RTE_NAME`). Puste: nazwa wydania |
+| `runner.joinToken` | [Token dołączenia](../runners/registration.html#join-tokens) utworzony w aplikacji, odczytywany przy pierwszym uruchomieniu, aby od razu zatwierdzić Runner |
+| `runner.appTlsVerify` | `false` akceptuje certyfikat samopodpisany aplikacji (`APP_TLS_VERIFY=0`), tylko wewnątrz jednej zaufanej sieci |
+
+Bez tokenu dołączenia Runner prosi o dołączenie i czeka, aż administrator go zatwierdzi w **Połączenia > Runnery**. Po zatwierdzeniu
+loguje się własnym `RTE_TOKEN`, przechowywanym w Secrecie `<release>-keys`: zachowaj ten Secret razem z wydaniem.
+[Instalator](installer.html#kubernetes) również instaluje ten tryb runnera, gdy wybierzesz rolę Runner i Kubernetes.
+
+---
+
+## Następne kroki
+
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) chartu opisuje resztę konfiguracji:
+
+* **Własna baza danych** : ustaw `mysql.enabled: false` i wskaż AnsibleForms istniejący serwer MySQL
+* **Formularze z ConfigMap** : dostarcz `config.yaml` i pliki formularzy przez ConfigMap
+* **HTTPS za ingress**, zasoby, rozmieszczenie na węzłach i prywatne rejestry
+* **RTE** : jego token, własny obraz RTE lub całkowity brak RTE
+
+Aby przejść na nowsze wydanie, zobacz [Aktualizacja na Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/pl/_get_started/installation/native.md b/i18n/pl/_get_started/installation/native.md
new file mode 100644
index 0000000..af22669
--- /dev/null
+++ b/i18n/pl/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Natywnie
+parent: Instalacja
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Instalacja natywna
+{: .no_toc }
+
+AnsibleForms bezpośrednio na serwerze, bez kontenerów, jako usługi systemd konfigurowane przez instalator
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów serwerów, na których kontenery są niedozwolone: [instalator](installer.html) instaluje wszystko, czego AnsibleForms potrzebuje,
+bezpośrednio na serwerze, a potem je aktualizuje i usuwa. Instaluje AnsibleForms 7.3.0 lub nowsze.
+
+---
+
+## Czego potrzebuje
+
+Wybierz **Bezpośrednio na tym serwerze, bez kontenerów** w kroku **Silnik** instalatora lub przekaż `--mode native`. Potrzebuje:
+
+* **Uprawnień roota** : uruchom instalator z `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : usługi działają jako jednostki systemd
+* **Obsługiwanego Linuksa** : Ubuntu, Debian, RHEL i jego klony, takie jak Rocky Linux i AlmaLinux, SUSE Linux Enterprise lub openSUSE
+* **amd64 lub arm64**
+* **Dostępu do internetu** : do repozytoriów dystrybucji, GitHub, nodejs.org oraz indeksów pakietów Pythona i Ansible (zobacz
+  [Bez dostępu do sieci](#air-gapped), aby dowiedzieć się, co zastępuje paczka wydania)
+
+Na serwerze, który tego nie spełnia, silnik jest wyświetlany jako *Bezpośrednio na tym serwerze (wymaga root: uruchom przez sudo)* lub
+*Bezpośrednio na tym serwerze (nieobsługiwane w tym Linuksie)*. W ten sposób instalują się obie role: kontroler i [Runner](installer.html#a-runner).
+
+---
+
+## Co instaluje
+
+Instalator instaluje z pakietów dystrybucji następujące elementy, dla obu ról:
+
+| Pakiet | Do czego |
+|---|---|
+| `git` | Repozytoria |
+| Klient ssh | Połączenia playbooków |
+| Klient MariaDB | Kopie zapasowe aplikacji: `app.env` ustawia [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) i [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) na znalezionego klienta, `mariadb-dump` i `mariadb` lub starsze `mysqldump` i `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | Pobieranie plików |
+| `libatomic` | Node.js jest z nią linkowany, a minimalnym serwerom jej brakuje |
+| `sshpass` | Playbooki, które logują się hasłem ssh. Na RHEL i jego klonach pochodzi z EPEL, który instalator próbuje włączyć przez `epel-release`; gdy nie da się go zainstalować, instalacja trwa dalej i to zgłasza |
+| Serwer MariaDB | Tylko kontroler: jego baza danych |
+
+Następnie do folderu instalacji, przy czym każdy pobrany plik jest sprawdzany względem opublikowanej sumy kontrolnej:
+
+* **AnsibleForms** : paczka wydania `ansibleforms-<version>-linux-<arch>.tar.gz` z wydania aplikacji na GitHub, czyli aplikacja zbudowana dla
+  Node.js. Wersja bez paczki zgłasza *Instalacja bez kontenerów wymaga AnsibleForms 7.3.0 lub nowszego.*
+* **Node.js** : najnowsze wydanie wersji głównej wskazanej przez paczkę, z nodejs.org
+* **Python i Ansible** : uv, a za jego pomocą Python z obrazów RTE i środowisko wirtualne z Ansible i bibliotekami
+  pełnego obrazu RTE, a następnie jego kolekcje Ansible (zobacz [Obrazy RTE](../rte/images.html)). Zajmuje to kilka minut
+* **Pliki startowe** : formularze, playbooki i ustawienia z folderu `data` [projektu docker-compose](https://github.com/ansibleforms/docker),
+  tak jak otrzymuje je nowa instalacja Docker Compose. Runner zachowuje tylko swoją konfigurację Ansible, ustawienia ssh i git
+
+Dla kontrolera tworzy następnie schemat `AnsibleForms` w MariaDB oraz użytkownika bazy danych nazwanego od instancji, z wszystkimi uprawnieniami do tego
+schematu i żadnymi poza nim, logującego się tylko z tego serwera.
+
+---
+
+## Folder
+
+Wszystko znajduje się w folderze instalacji, domyślnie `/opt/ansibleforms` (lub `/opt/ansibleforms-runner` dla Runnera):
+
+| Ścieżka | Co zawiera |
+|---|---|
+| `releases/<version>/` | Wydanie: paczkę, jej link do Node.js, jej środowisko wirtualne Pythona i jej kolekcje |
+| `current` | Link do działającego wydania; aktualizacja go przestawia, podobnie jak wycofanie |
+| `runtime/` | Node.js, uv i Python, współdzielone przez wydania |
+| `data/` | To, co kontenery montują jako `/app/dist/persistent`: formularze, playbooki, `config.yaml`, config seed, certyfikaty i dzienniki |
+| `home/` | Katalog domowy użytkownika systemowego: `.ssh` i `.gitconfig`, połączone z `data/ssh` i `data/git` |
+| `app.env`, `rte.env` | Ustawienia i sekrety usług, czytelne tylko dla roota i użytkownika systemowego. Plik RTE nie zawiera ustawień bazy danych |
+| `installer-backups/` | Kopie zapasowe bazy danych tworzone przez instalator, przed aktualizacją lub przez `backup` |
+
+Wydania i środowiska uruchomieniowe należą do roota, więc usługi nie mogą zmieniać własnego kodu; `data/` i `home/` należą do użytkownika systemowego.
+Same pliki bazy danych przechowuje MariaDB, poza tym folderem.
+
+---
+
+## Usługi
+
+Kontroler uruchamia dwie usługi systemd, Runner jedną. Każda działa jako użytkownik systemowy nazwany od instancji (domyślnie `ansibleforms`),
+z `current/server`, ze swoim plikiem ustawień:
+
+| Usługa | Co uruchamia | Ustawienia |
+|---|---|---|
+| `<name>` | Aplikację: interfejs webowy, API i workera. Tylko kontroler | `app.env` |
+| `<name>-rte` | RTE, które uruchamia playbooki | `rte.env` |
+
+RTE kontrolera jest `inbound`, na własnym porcie na `127.0.0.1` (`8001` lub kolejnym wolnym, z
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), uruchamia playbooki z folderów aplikacji (`RTE_FILES=local`)
+i jest deklarowane przez config seed `data/seed.yaml` jako domyślny runner.
+
+RTE Runnera dostaje tryb, `APP_URL`, `RTE_NAME` oraz, z `--join`, token dołączenia, a playbooki otrzymuje razem z każdym zadaniem (zobacz
+[Tryby](../rte/modes.html)). Wychodzące nie przyjmuje wywołań od aplikacji, więc nasłuchuje tylko na `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Przychodzące udostępnia HTTPS z własnym certyfikatem samopodpisanym dla swojego adresu w `data/certificates`, który AnsibleForms przypina.
+Bez tokenu dołączenia prosi o dołączenie, a administrator zatwierdza je w **Połączenia > Runnery**.
+
+Uruchamiają się przy starcie systemu i restartują po awarii. Zarządzaj nimi i czytaj ich dzienniki własnymi narzędziami systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+Aplikacja może nasłuchiwać na porcie poniżej 1024, na przykład `443`, bez uprawnień roota. RTE zachowuje prawo do używania `sudo`, którego potrzebują playbooki z
+`become` na tym serwerze, więc playbook może zarządzać serwerem, na którym działa RTE.
+
+---
+
+## Aktualizacja i wycofanie
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` aktualizuje instalację natywną tak samo jak pozostałe (zobacz [Aktualizacja](installer.html#upgrade)), w
+tej kolejności:
+
+1. Umieszcza nowe wydanie obok działającego: jego paczkę, Node.js, Python, Ansible i kolekcje. Działające
+   usługi nie są jeszcze ruszane
+2. Dodaje nowe pliki startowe, które przynosi wydanie, zachowując każdy istniejący plik
+3. Wykonuje kopię zapasową bazy danych (kontroler) do `installer-backups/`, z kopią `app.env` i `rte.env`
+4. Zatrzymuje usługi, przestawia `current` na nowe wydanie i uruchamia je ponownie
+5. Czeka, aż aplikacja odpowie nową wersją (Runner: aż jego RTE znów zacznie nasłuchiwać)
+
+Gdy nowa wersja nie odpowiada, instalator proponuje wycofanie: `current` znów wskazuje poprzednie wydanie,
+baza danych jest przywracana z kopii zapasowej, a usługi się uruchamiają. Zachowywane są tylko działające wydanie i poprzednie.
+
+Usługi natywne w układzie instalatora bez `installer.json` obok nich, na przykład po jego usunięciu, są wykrywane przez `install`
+i `upgrade`, które proponują ich przejęcie (zobacz [Istniejąca instalacja](installer.html#an-existing-installation)).
+
+---
+
+## Odinstalowanie
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` zatrzymuje i usuwa usługi. Zachowuje folder i bazę danych, chyba że zdecydujesz się usunąć
+dane (lub przekażesz `--purge`) i wpiszesz nazwę instancji, aby to potwierdzić. Wtedy usuwa też bazę danych i jej użytkownika (kontroler),
+usuwa folder i usuwa użytkownika systemowego.
+
+Pakiety pozostają zainstalowane, w tym MariaDB: może z nich korzystać inne oprogramowanie.
+
+---
+
+## Bez dostępu do sieci
+
+`--bundle` instaluje z paczki wydania skopiowanej na serwer, zamiast pobierać ją z GitHub. Weź plik dla
+swojej architektury, `ansibleforms-<version>-linux-amd64.tar.gz` lub `-arm64`, z [Releases](https://github.com/ansibleforms/ansibleforms/releases) aplikacji:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` robi to samo dla plików startowych, z lokalnej kopii repozytorium [ansibleforms/docker](https://github.com/ansibleforms/docker).
+Node.js, Python z jego pakietami i kolekcje Ansible są nadal pobierane podczas instalacji.
diff --git a/i18n/pl/_get_started/upgrade-7.md b/i18n/pl/_get_started/upgrade-7.md
new file mode 100644
index 0000000..02c1b6b
--- /dev/null
+++ b/i18n/pl/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Aktualizacja do v7
+parent: Aktualizacja
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Aktualizacja do v7
+{: .no_toc }
+
+Co zmienić, będąc jeszcze na 6.5, i co się zmienia po przejściu na wersję 7
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wersja 7 usuwa wszystko, co w 6.x było oznaczone jako przestarzałe; najpierw popraw to na 6.5, gdzie działa zarówno stare, jak i nowe, a dopiero potem aktualizuj.
+
+---
+
+## Przed aktualizacją (na 6.5)
+
+### Formularze we własnych plikach
+
+Formularze znajdują się wyłącznie w folderze formularzy (`FORMS_FOLDER_PATH`) lub w repozytorium formularzy; `config.yaml` zawiera kategorie, role i stałe.
+
+- **Plik `forms.yaml`:** zmień jego nazwę na `config.yaml`. Na 6.5 strona ustawień ma do tego przycisk
+  **Convert forms.yaml to config.yaml**.
+- **Sekcja `forms:` w konfiguracji bazowej:** wersja 7 ją odrzuca. Przenieś każdy formularz do osobnego pliku, na przykład
+  przeciągając go do pliku w projektancie 6.5.
+- **Zmienne środowiskowe:**
+
+  | Usunięte | Zamiast tego użyj |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` i `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### Pole `table`
+
+Wersja 7 odrzuca pola `table`, a razem z nimi ich właściwości (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`): użyj pola `list` z `subform` i zamień `from` każdej kolumny na wyrażenie
+na `__parent__` (zobacz [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Zmienione nazwy właściwości
+
+Każda usunięta właściwość ma bezpośredni zamiennik:
+
+| Usunięte | Zamiast tego użyj |
+|---|---|
+| `disableRelaunch: true` (formularz) | `allowRelaunch: false` |
+| `noOutput: true` (pole) | `output: false` |
+| `enableLogin` (opcja roli) | `allowLogin` |
+
+### Źródła danych i schematy danych
+
+Importy źródeł danych i ich strony administracyjne zostały usunięte, podobnie jak
+kolekcja Galaxy AnsibleForms, której moduły służyły tylko im.
+
+- Zaplanowane importy przestają działać, a tabele źródeł danych są usuwane: najpierw zanotuj to, czego potrzebujesz.
+- Schematy danych wypełniane przez import są osobnymi bazami danych i pozostają. Formularz, który
+  odpytuje je przez poświadczenie, nadal działa.
+- Aby te dane były aktualne, uruchamiaj import jako własny playbook, na przykład z
+  harmonogramu.
+
+### API v1
+
+`/api/v1/*` zostało usunięte; używaj `/api/v2/*` (interaktywna dokumentacja pod `/api/v2/docs`). Wywołania, których
+skrypty zwykle używają, to:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+v2 odpowiada kodami stanu HTTP (`400`, `403`, `404`, `422`) i zwykłą treścią JSON, a nie kopertą
+`{ status, message, data }` z v1.
+
+**Dotyczy to też callbacków jednokrotnego logowania.** Adres przekierowania z `/api/v1/` już nie odpowiada: logowanie wraca na
+stronę logowania, nie logując użytkownika. Zmień go na `/api/v2/` w dwóch miejscach, u dostawcy SSO w
+AnsibleForms i u dostawcy tożsamości (adresy przekierowania w rejestracji aplikacji Entra ID, prawidłowe adresy przekierowania
+klienta OIDC):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback` lub od wersji 7.3.0 `/api/v2/auth/entraid/callback`
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## Co się zmienia w 7
+
+Wersja 7 zmienia sposób uruchamiania playbooków i zaostrza kilka ustawień domyślnych. Sprawdź każdy z poniższych punktów przy przejściu z 6.5.
+
+### Playbooki działają na RTE
+
+Wersja 7 nie uruchamia już `ansible-playbook` w kontenerze AnsibleForms. Playbooki działają w środowisku uruchomieniowym (RTE),
+osobnym kontenerze, a obraz aplikacji nie zawiera już ansible ani pythona. Uruchom RTE obok aplikacji, z obrazu
+`ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Od wersji 7.3.0 aplikacja łączy się z RTE i utrzymuje otwarty jeden WebSocket (zobacz
+[Tryby](rte/modes.html)): RTE nie dostaje ustawień bazy danych ani `ENCRYPTION_SECRET`. Jego ustawienia:
+
+| Ustawienie | Wartość |
+|---|---|
+| `AF_ROLE` | `rte`. Obrazy RTE już to ustawiają. |
+| `RTE_MODE` | `inbound`: aplikacja łączy się z RTE. Runner w innej sieci używa `outbound` (zobacz [Tryby](rte/modes.html)). |
+| `RTE_TOKEN` | Token o długości co najmniej 16 znaków. Aplikacja loguje się nim do gniazda RTE, a RTE bez niego nie uruchomi się. |
+| `RTE_FILES` | `local`, gdy RTE montuje ten sam folder trwały co aplikacja, tak jak obok niej. |
+
+Następnie przenieś montowania ansible z kontenera aplikacji do RTE:
+
+- `ansible.cfg` w `/etc/ansible/ansible.cfg`, Twoje role w `/etc/ansible/roles`, a Twoje kolekcje w
+  `/etc/ansible/collections`.
+- Zamontuj w RTE także ten sam folder trwały co w aplikacji, aby znajdował playbooki i repozytoria.
+
+Następnie zadeklaruj RTE jako runner, w [config seed](seed/) tak jak robi to projekt Docker Compose, albo w **Połączenia → Runnery**:
+poświadczenie RTE z adresem RTE (na przykład `http://rte:8000`) i tym samym tokenem oraz runner typu RTE, w trybie inbound,
+który je wskazuje:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Seed odczytuje `RTE_TOKEN` ze środowiska aplikacji. Zobacz [Runnery](runners.html) i [Środowiska uruchomieniowe](rte/).
+
+{: .warning }
+> **Ten sam kontrakt dla aplikacji i RTE** Aplikacja rozwiązuje poświadczenia zadania i przekazuje je do RTE zaszyfrowane dla
+> tego RTE (kontrakt RTE 2, nowość w 7.0.0). RTE z innym kontraktem odrzuca zadania aplikacji: uruchamiaj obraz RTE z tego samego
+> wydania co aplikacja i aktualizuj oba razem. Późniejsze wydania 7 nadal współpracują ze starszym RTE 7, dopóki kontrakt
+> pozostaje ten sam (zobacz [Skalowanie](../rte/images.html#build-your-own-rte)).
+
+
+### Co zawiera obraz RTE
+
+RTE występuje w trzech warstwach, każda zbudowana na poprzedniej. Wybierz tę, która pasuje do Twoich playbooków:
+
+| Obraz | Zawartość |
+|---|---|
+| `ansibleforms-rte-full` | Domyślny. Ansible 14 z ansible-core 2.21 oraz kolekcje i biblioteki pythona, które miał obraz 6.5. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core i kilka popularnych bibliotek, bez kolekcji. Dodaj własne w obrazie zbudowanym na jego bazie. |
+| `ansibleforms-rte-base` | Sam serwer, bez pythona i ansible, do zbudowania RTE z własnymi wersjami. |
+
+Przejście z 6.5 (ansible 12 z ansible-core 2.19) zmienia też te rzeczy dla Twoich playbooków:
+
+- **ansible-core 2.21:** przeczytaj [porting guides](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  dla 2.20 i 2.21.
+- **Python 3.14:** warstwy RTE działają na pythonie 3.14.
+- **Koniec z `boto`:** stara biblioteka `boto` 2 zniknęła. Kolekcja `amazon.aws` używa `boto3`, która jest dołączona.
+
+Dwie zmienne środowiskowe należą teraz do RTE i nie są już odczytywane przez aplikację, więc ustaw je w kontenerze RTE:
+
+| Zmienna | Zmiana |
+|---|---|
+| `ANSIBLE_PATH` | Folder playbooków, na RTE. |
+| `PROCESS_MAX_BUFFER` | Teraz domyślnie 50 MB. Po jego przekroczeniu wynik zadania nie jest już zapisywany (zadanie o tym informuje), ale playbook działa dalej, zamiast zostać zatrzymany. |
+
+
+### Kontenery działają jako uid 1000
+
+Obrazy aplikacji i RTE działają jako użytkownik `node` (uid 1000) zamiast roota, a ich folder domowy to `/home/node`:
+
+- **Przekaż wolumeny uid 1000, jednorazowo.** Dla wolumenów persistent i ssh uruchom
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v`; dla folderu hosta `sudo chown -R 1000:1000 <folder>`.
+  Na Kubernetes ustaw `fsGroup: 1000`.
+- **Montuj folder ssh w `/home/node/.ssh`**, a nie w `/root/.ssh`. Jeśli ustawiłeś
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) na `/root`, usuń to ustawienie lub ustaw je na `/home/node`.
+- **Własny obraz RTE** zbudowany na warstwie RTE przełącza się na `USER root` na czas instalacji i z powrotem na `USER node` na końcu.
+
+
+### Walidacja przy uruchomieniu jest włączona
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) ma teraz domyślnie wartość `enforce` (6.5: `off`). Każde
+uruchomienie, z przeglądarki lub z `POST /api/v2/job`, jest sprawdzane pod kątem reguł formularza, a zadanie używa extravars i
+poświadczeń, które serwer buduje ze sprawdzonych wartości.
+
+- **Wywołujący REST muszą wysyłać `rawFormData`**, surowe wartości pól w takiej postaci, w jakiej wysyła je przeglądarka. Uruchomienie z samym
+  `extravars` jest odrzucane, bo nie da się sprawdzić jego wartości.
+- **Aby najpierw zobaczyć, co zostałoby odrzucone**, ustaw `LAUNCH_VALIDATION=log` i przeczytaj ostrzeżenia w dzienniku. `off` przywraca
+  zachowanie z 6.5.
+
+Szczegóły opisuje strona [Walidacja przy uruchomieniu](launch-validation/).
+
+
+### Playbooki nie widzą już ustawień aplikacji
+
+Playbook nie dziedziczy już zmiennych środowiskowych, które odczytuje samo AnsibleForms: `ENCRYPTION_SECRET`, ustawień `DB_*`,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, ustawień `VAULT_*`, wszystkich innych udokumentowanych zmiennych i wszystkich zmiennych `MYSQL_*`.
+Reszta środowiska RTE, na przykład `PATH`, proxy, ustawienia `ANSIBLE_*` i poświadczenia chmurowe, jest przekazywana jak dotąd.
+
+Playbook, który odczytywał jedną z nich przez `lookup('env', ...)`, musi uzyskać wartość w inny sposób: przekaż ją jako extravar lub
+poświadczenie albo ustaw ją w RTE pod inną nazwą.
+
+### Tylko rola admin zarządza runnerami i administratorami
+
+Użytkownik z dostępem do ustawień nie ma już pełnej kontroli nad tym, kto jest administratorem i dokąd trafiają poświadczenia:
+
+- **Runnery:** tylko rola admin dodaje, zmienia lub usuwa runner, ponieważ runner otrzymuje poświadczenia zadań,
+  które uruchamia. Użytkownicy z dostępem do ustawień nadal mogą przeglądać i testować runnery.
+- **Konta i grupy administratorów:** tylko rola admin nadaje uprawnienia administratora. Bez niej użytkownik nie może dodać konta do grupy, którą
+  wymienia rola admin, ani zmienić, zresetować lub usunąć konta administratora lub takiej grupy.
+- **Role:** projektant bez roli admin nie może zmieniać ról. Zapis lub przywrócenie, w którym role się różnią, jest odrzucane.
+
+Nadaj rolę admin temu, kto zarządza runnerami, administratorami i rolami.
+
+### Domyślne hasło trzeba zmienić
+
+Użytkownik, który loguje się publicznym hasłem domyślnym `AnsibleForms!123`, musi je najpierw zmienić. Do tego czasu każde inne wywołanie API
+odpowiada `403` z kodem `password_change_required`, a przeglądarka pokazuje stronę zmiany hasła.
+
+Zaloguj się raz i wybierz nowe hasło albo ustaw [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) przed
+pierwszym uruchomieniem. Skrypty logujące się hasłem domyślnym muszą używać innego.
+
+### Tokeny wygasają przy wylogowaniu i zmianie hasła
+
+Wylogowanie kończy teraz tokeny tej sesji, a zmiana hasła kończy wszystkie sesje tego użytkownika, więc po zmianie hasła
+zaloguj się ponownie.
+
+Token API zażądany z `?expiryDays=` żyje najwyżej [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) dni
+(domyślnie 90). Skrypty używające długoterminowych tokenów API muszą zażądać nowego, zanim stary wygaśnie.
+
+### Entra ID wymaga Twojego tenanta
+
+Logowanie przez Entra ID (Azure AD) używa teraz OpenID Connect wyłącznie z Twoim własnym tenantem, a użytkownik innego tenanta nie może się
+zalogować. Dostawca bez identyfikatora tenanta albo z `common`, `organizations` lub `consumers` jest odrzucany.
+
+- **Ustaw identyfikator tenanta** u dostawcy SSO: Directory (tenant) ID, czyli GUID, lub domenę tenanta.
+- **Nadaj uprawnienia Graph:** logowanie prosi o `openid profile email User.Read GroupMember.Read.All`. Nadaj rejestracji
+  aplikacji delegowane uprawnienia Microsoft Graph `User.Read` i `GroupMember.Read.All`, ze zgodą administratora.
+- **W rolach preferuj identyfikatory grup:** wskazuj grupę jako `azuread/<object id>` (od wersji 7.3.0 `entraid/<object id>`), a nie przez jej nazwę wyświetlaną.
+
+Konfigurację opisuje strona [Entra ID](authentication/entra-id.html).
+
+### Hasła mają minimalną długość
+
+Lokalne hasło ustawiane przez aplikację wymaga co najmniej
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) znaków (domyślnie 8) i nie może być nazwą użytkownika ani
+hasłem domyślnym. `PASSWORD_MIN_LENGTH=0` wyłącza sprawdzanie długości. Istniejące hasła nadal działają.
+
+### Uruchamiaj kontenery z polityką restartu
+
+Nieprzechwycony wyjątek kończy teraz proces, zapisany w dzienniku na poziomie `crit`, zamiast pozostawiać go działającego w nieznanym stanie. Uruchamiaj
+kontenery z polityką restartu, na przykład `--restart unless-stopped` w Dockerze (projekt docker-compose ją ustawia).
+Kubernetes sam restartuje pody.
+
+### Połączenia AWX i link strony głównej
+
+W 7 zniknęły jeszcze dwie rzeczy, bez konieczności robienia czegokolwiek na 6.5:
+
+- **Połączenia AWX i AAP:** tabela `awx`, `/api/v2/awx` i strona A.A.P. zniknęły. Aktualizacja przenosi każde połączenie AWX lub
+  AAP do **Połączenia → Runnery**, jako runner typu `awx`, a formularze z `awx:` nadal działają.
+- **`NAV_HOME_LABEL` i `NAV_HOME_ICON`:** nie są już odczytywane. Pierwszy link w nagłówku to zawsze Formularze.
+
+### Przestarzałe w 7, usunięte w 8
+
+Te elementy nadal działają w 7, ale każdy zapisuje ostrzeżenie w dzienniku, gdy jest używany. Przejdź na zamiennik przed wersją 8:
+
+| Przestarzałe | Zamiast tego użyj |
+|---|---|
+| Zmienne środowiskowe `VAULT_*` | Magazyn sekretów o nazwie `vault` (**Połączenia → Magazyny sekretów**). Pierwsze uruchomienie 7 importuje zmienne raz jako ten magazyn, a potem je ignoruje. |
+| Zmienne środowiskowe `LOG_SYSLOG_*` | Serwer syslog (**Połączenia → Syslog**). Gdy ustawione jest `LOG_SYSLOG_HOST`, pierwsze uruchomienie 7 importuje je raz jako serwer `syslog`, który otrzymuje dziennik serwera jak dotąd, a potem je ignoruje. Aby wysyłać też wpisy audytu, ustaw go tak, aby odbierał oba. |
+| `vault_path` w poświadczeniu (API, config seed) | `secret_store` i `secret_ref`. Zobacz [Magazyny sekretów](secret-stores/). |
+| Rola `public` w `config.yaml` | Rola `default`. Nazwa w pliku jest zmieniana przy wczytywaniu konfiguracji; w szablonie ytt zmień ją ręcznie. `public` w `roles:` formularza nadal pasuje. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` w formularzu lub kroku | `approval`. `hasApproval` nie ma żadnego efektu. |
+| `awx: <name>` w formularzu | `runner: <name>`. Połączenie AWX to runner typu `awx`. |
+| `type: multistep` w formularzu, z jego `steps` | `type: workflow`, z węzłami wskazującymi `runner`. Zobacz [Formularze workflow](forms/workflow.html). |
+| Sekcja `awx:` config seed | Pozycje `runners:` z `type: awx` |
+| `LOCK_PATH` | Nic: nie jest już odczytywana, blokada projektanta jest przechowywana w bazie danych. |
+| RTE w trybie bazy danych, od wersji 7.3.0: `RTE_MODE=database` lub brak `RTE_MODE`, z `DB_*` bazy danych i `ENCRYPTION_SECRET` na RTE | `RTE_MODE=outbound` lub `RTE_MODE=inbound`, bez `DB_*`. RTE dołącza raz z tokenem dołączenia (`RTE_JOIN_TOKEN`) albo jego runner jest ustawiany w tym trybie w **Połączenia → Runnery** lub w config seed (`rte_mode`). Zobacz [Tryby](rte/modes.html). |
+| `RTE_REGISTER`, od wersji 7.3.0 (tylko tryb bazy danych) | Token dołączenia (`RTE_JOIN_TOKEN`): RTE dodaje się jako runner, który loguje się poświadczeniem RTE. |
+| Poświadczenie `api` lub `userpass` w runnerze config seed, od wersji 7.3.0 | Poświadczenie rodzaju runnera (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` lub `jenkins`), z jego serwerem w `url`. |
+| Runner config seed z własnym `token` albo `username` i `password`, od wersji 7.3.0 | Poświadczenie rodzaju runnera w sekcji `credentials`, z jego serwerem w `url`, które runner wskazuje przez `credential:`. W międzyczasie seed tworzy jedno nazwane od runnera. |
+
+`ENABLE_SSO` i `SSO_AUTO_LOGIN` nie są odczytywane od wersji 7.3.0. Pierwsze uruchomienie 7.3 przenosi je raz: `ENABLE_SSO=0` wyłącza
+wszystkich dostawców SSO, a `SSO_AUTO_LOGIN=1` zaznacza **Pomiń stronę logowania** u jedynego włączonego dostawcy. Potem są ignorowane: każde uruchomienie
+zapisuje ostrzeżenie w dzienniku, dopóki są ustawione, a każdy dostawca ma **Włączony** i **Pomiń stronę logowania** w **Dostęp → SSO**.
+
+---
+
+## Tagi obrazów
+
+`latest` przechodzi na 7 wraz z 7.0.0. Aby pozostać na 6, używaj tagu `6` (lub `6.5`) zamiast `latest`.
+Wszystkie tagi są wymienione w [Tagi obrazów](installation/#image-tags).
+
+---
+
+## Wycofanie aktualizacji
+
+Przed aktualizacją wykonaj kopię zapasową (**Ustawienia → Kopie zapasowe**). 6.5 działa na bazie danych zaktualizowanej do 7, ale tylko
+kopia zapasowa przywraca usunięte definicje źródeł danych.
diff --git a/i18n/pl/_get_started/upgrading/docker-compose.md b/i18n/pl/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..5c13eb5
--- /dev/null
+++ b/i18n/pl/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Aktualizacja
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Aktualizacja instalacji wykonanej projektem docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Projekt docker-compose uruchamia trzy kontenery: MySQL (`mysqldb`), AnsibleForms (`app`) i RTE, które uruchamia
+playbooki (`rte`). AnsibleForms i RTE używają tagu obrazu `7`, który zawsze wskazuje najnowsze wydanie 7.x.
+Aktualizacja ponownie pobiera obrazy i tworzy od nowa kontenery, których obraz się zmienił. Wszystko, co musi przetrwać, jest przechowywane
+w folderze `data` i zostaje zachowane.
+
+---
+
+## Przed aktualizacją
+
+Przygotuj aktualizację tak, aby można było wrócić, jeśli coś pójdzie nie tak:
+
+* **Wykonaj kopię zapasową** w **Ustawienia → Kopie zapasowe**. Nowe wydanie aktualizuje schemat bazy danych przy pierwszym uruchomieniu.
+* **Przeczytaj [dziennik zmian](../changelog)** dla wydań między Twoją wersją a nową.
+* **Przechodzisz na nową wersję główną?** Najpierw postępuj zgodnie z [Aktualizacja do v7](../upgrade-7.html).
+* **Przechodzisz z 6.5?** Projekt 6.x, na gałęzi `v6`, nie ma kontenera `rte`. Zaktualizuj swoją kopię projektu do
+  gałęzi `main`, zachowując ustawienia `.env` i folder `data`, tak aby `docker-compose.yml` miał usługę `rte`.
+  Ten plik compose ustawia `CONFIG_SEED_PATH`, a folder `data` z 6.x nie ma `seed.yaml`: skopiuj `data/seed.yaml` z
+  repozytorium i dodaj `RTE_TOKEN` (co najmniej 16 znaków) do swojego `.env`, tak jak ma to `.env` repozytorium. Bez nich
+  aplikacja nie uruchomi się. Obrazy 7 działają jako uid 1000 zamiast roota: jednorazowo przekaż temu użytkownikowi folder `data`, zostawiając pliki
+  MySQL dla MySQL, poleceniem `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  Folder `data/ssh` jest teraz montowany w `/home/node/.ssh` zamiast w `/root/.ssh`.
+* **Przechodzisz z 7.2?** Zaktualizuj razem `docker-compose.yml` i `data/seed.yaml`: najpierw zobacz [Z 7.2 do 7.3](#from-72-to-73).
+
+---
+
+## Z 7.2 do 7.3
+
+Do wersji 7.2.0 usługa `rte` dostawała ustawienia bazy danych, a jej runner, zadeklarowany w `data/seed.yaml`, działał w trybie bazy danych,
+przestarzałym w 7.3.0 i usuniętym w 8.0.0. Od wersji 7.3.0 aplikacja łączy się z RTE pod `http://rte:8000` i utrzymuje otwarty jeden WebSocket
+(`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)), a RTE nie przechowuje ustawień bazy danych. Weź oba pliki z gałęzi
+`main` repozytorium, zachowując swój `.env`:
+
+| Plik | Co się zmienia |
+|---|---|
+| `docker-compose.yml` | Usługa `rte` nie odczytuje już `.env`: dostaje `RTE_MODE=inbound`, `RTE_TOKEN` i `RTE_FILES=local`, a nie dostaje `DB_*` |
+| `data/seed.yaml` | Poświadczenie RTE `rte`, z `url: http://rte:8000` i `password: ${RTE_TOKEN}`, oraz runner `rte` z `rte_mode: inbound` i `credential: rte` |
+
+Zmień oba. Przy samym nowym pliku compose seed pozostawia runner `rte` w trybie bazy danych: aplikacja wywołuje RTE jak RTE z 7.2,
+na co nowe RTE nie odpowiada, i żaden playbook się nie uruchamia. Seed zmieniony samodzielnie wymaga tego samego poświadczenia i `rte_mode`.
+
+Runner utworzony przez seed pozostaje zarządzany, tylko do odczytu w **Połączenia → Runnery**, nawet po usunięciu `CONFIG_SEED_PATH`: tylko
+zastosowany seed zwalnia runner, którego już nie deklaruje. Dlatego zachowaj seed i ustaw w nim `rte_mode`, zamiast usuwać
+`CONFIG_SEED_PATH`, aby zmienić runner ręcznie.
+
+[Instalator](../installation/installer.html#upgrade) robi to sam: jego aktualizacja zastępuje `docker-compose.yml`, a także `data/seed.yaml`,
+gdy jest to niezmieniony plik dostarczony z repozytorium. Plik zmieniony ręcznie zostaje zachowany, a nowy jest zapisywany obok niego.
+
+---
+
+## 1. Pobierz nowe obrazy
+
+Pobierz najnowsze obrazy dla tagów z `docker-compose.yml`:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Utwórz ponownie kontenery
+
+Uruchom projekt ponownie; kontenery, których obraz się zmienił, zostaną utworzone od nowa:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Sprawdź aktualizację
+
+Śledź dziennik AnsibleForms podczas uruchamiania. Pierwsze uruchomienie nowego wydania aktualizuje schemat bazy danych, a RTE
+uruchamia się, gdy AnsibleForms jest w dobrej kondycji:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+W AnsibleForms **Pomoc → O programie** pokazuje działającą wersję, a **Ustawienia → Stan** pokazuje kondycję
+bazy danych, schematu i innych systemów, od których zależy AnsibleForms.
+
+---
+
+## Wycofanie aktualizacji
+
+Aby wrócić do wydania, którego używałeś wcześniej, czyli wersji, którą **Pomoc → O programie** pokazywało przed aktualizacją, przypnij jej dokładny tag w
+`docker-compose.yml`, zarówno dla obrazu AnsibleForms, jak i RTE, zamiast `7`, i uruchom ponownie krok 2. Jeśli to wydanie
+nie uruchamia się na zaktualizowanej bazie danych, przywróć kopię zapasową wykonaną w **Ustawienia → Kopie zapasowe**. Ustaw z powrotem tagi na
+`7`, aby znów otrzymywać aktualizacje.
+
+**WIDEO**: [Jak zaktualizować AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/pl/_get_started/upgrading/docker.md b/i18n/pl/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..ed9bbce
--- /dev/null
+++ b/i18n/pl/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Aktualizacja
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Aktualizacja samodzielnego kontenera, bez docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Instalację samodzielną aktualizuje się, wymieniając jej kontenery: pobierz nowe obrazy, usuń stare kontenery i
+uruchom nowe tymi samymi poleceniami `run`. Od wersji 7 są dwa: AnsibleForms i RTE, które uruchamia
+playbooki, zawsze w tym samym wydaniu. Twoje pliki są przechowywane w zamontowanym folderze `/app/dist/persistent`, a dane w
+MySQL, więc jedno i drugie zostaje zachowane.
+
+---
+
+## Przed aktualizacją
+
+Przygotuj aktualizację tak, aby można było wrócić, jeśli coś pójdzie nie tak:
+
+* **Wykonaj kopię zapasową** w **Ustawienia → Kopie zapasowe**. Nowe wydanie aktualizuje schemat bazy danych przy pierwszym uruchomieniu.
+* **Przeczytaj [dziennik zmian](../changelog)** dla wydań między Twoją wersją a nową.
+* **Przechodzisz na nową wersję główną?** Najpierw postępuj zgodnie z [Aktualizacja do v7](../upgrade-7.html).
+* **Przechodzisz z 6.5?** Obrazy 7 działają jako uid 1000 zamiast roota: jednorazowo przekaż temu użytkownikowi montowane foldery, na
+  przykład `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Przechodzisz z 7.2?** RTE dostaje własny plik, a aplikacja łączy się z nim: najpierw zobacz [Z 7.2 do 7.3](#from-72-to-73).
+
+---
+
+## Z 7.2 do 7.3
+
+Do wersji 7.2.0 RTE odczytywało plik środowiska aplikacji, z ustawieniami bazy danych, i dodawało się jako runner na podstawie `RTE_URL`. To
+jest tryb bazy danych, przestarzały w 7.3.0 i usunięty w 8.0.0. Od wersji 7.3.0 aplikacja łączy się z RTE i utrzymuje otwarty jeden WebSocket
+(`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)), a RTE nie przechowuje ustawień bazy danych. Jednorazowo, przed krokiem 2:
+
+1. Utwórz `/srv/apps/ansibleforms/rte.env` tak jak przy [instalacji](../installation/docker.html#prepare-the-folders), z
+   `RTE_MODE=inbound`, tym samym `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` i `HTTPS=0`. Bez `DB_*`, bez `ENCRYPTION_SECRET`, bez `RTE_URL`
+2. Zadeklaruj runner w tym trybie. Albo dodaj [config seed](../seed/) z instalacji, `persistent/seed.yaml` z poświadczeniem RTE
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) i runnerem `rte` (`rte_mode: inbound`), oraz dodaj
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` do pliku środowiska aplikacji. Albo, bez seeda, otwórz runner w
+   **Połączenia → Runnery**, ustaw jego **Tryb** na **Przychodzący** i wybierz poświadczenie RTE, które zawiera `http://rte:8000` i token
+
+Przy użyciu seeda plik środowiska aplikacji również zawiera `RTE_TOKEN`, ten sam token, ponieważ seed odczytuje go stamtąd.
+
+---
+
+## 1. Pobierz nowe obrazy
+
+Pobierz najnowsze obrazy AnsibleForms i RTE dla używanego tagu:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Wymień kontenery
+
+Usuń stare kontenery i uruchom nowe poleceniami `run` z [instalacji](../installation/docker.html). Aplikacja
+odczytuje połączenie z bazą danych ze swojego pliku środowiska, z użytkownikiem bazy danych AnsibleForms (nie root). RTE odczytuje własny
+`rte.env`, bez ustawień bazy danych, a aplikacja łączy się z nim przez sieć wspólną dla obu kontenerów:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Przy przejściu z 6.5 nie ma jeszcze kontenera RTE: polecenia `stop` i `rm` znajdują tylko aplikację. Utwórz wspólną sieć
+jednorazowo poleceniem `docker network create ansibleforms` (lub `podman network create ansibleforms`). Tak jak przy
+[instalacji](../installation/docker.html#prepare-the-folders), umieść połączenie z bazą danych, `ENCRYPTION_SECRET`, `RTE_TOKEN`
+o długości co najmniej 16 znaków i `CONFIG_SEED_PATH` w pliku środowiska aplikacji oraz utwórz `rte.env` i config seed. Używaj własnych
+folderów tam, gdzie Twoja instalacja 6.5 montowała inne. Seed dodaje RTE w **Połączenia → Runnery** jako domyślny runner `rte`;
+zobacz [Aktualizacja do v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Sprawdź aktualizację
+
+Śledź dziennik AnsibleForms podczas uruchamiania. Pierwsze uruchomienie nowego wydania aktualizuje schemat bazy danych:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+RTE zapisuje własny dziennik, który pokazuje `docker logs rte`. W AnsibleForms **Pomoc → O programie** pokazuje działającą wersję, a **Ustawienia → Stan** pokazuje kondycję
+bazy danych, schematu i innych systemów, od których zależy AnsibleForms.
+
+---
+
+## Wycofanie aktualizacji
+
+Aby wrócić do wydania, którego używałeś wcześniej, czyli wersji, którą **Pomoc → O programie** pokazywało przed aktualizacją, uruchom ponownie krok 2 z
+jej dokładnym tagiem zamiast `7`, zarówno dla obrazu AnsibleForms, jak i RTE. Jeśli to wydanie nie uruchamia się na zaktualizowanej
+bazie danych, przywróć kopię zapasową wykonaną w **Ustawienia → Kopie zapasowe**.
diff --git a/i18n/pl/_get_started/upgrading/from-source.md b/i18n/pl/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..512d2ad
--- /dev/null
+++ b/i18n/pl/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Ze źródeł
+parent: Aktualizacja
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# Ze źródeł
+{: .no_toc }
+
+Aktualizacja instalacji zbudowanej ze źródeł
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Instalację zbudowaną ze źródeł aktualizuje się, przełączając się na nowe wydanie, budując je ponownie i uruchamiając ponownie
+aplikację. Twoje ustawienia, formularze, playbooki, certyfikaty i dzienniki są przechowywane w `server/persistent`, którego Git ani
+budowanie nie modyfikują.
+
+---
+
+## Przed aktualizacją
+
+Przygotuj aktualizację tak, aby można było wrócić, jeśli coś pójdzie nie tak:
+
+* **Wykonaj kopię zapasową** w **Ustawienia → Kopie zapasowe**. Nowe wydanie aktualizuje schemat bazy danych przy pierwszym uruchomieniu.
+* **Przeczytaj [dziennik zmian](../changelog)** dla wydań między Twoją wersją a nową.
+* **Przechodzisz na nową wersję główną?** Najpierw postępuj zgodnie z [Aktualizacja do v7](../upgrade-7.html).
+* **Sprawdź wersję Node.js** wymaganą przez nowe wydanie, w dzienniku zmian.
+
+---
+
+## 1. Pobierz nowe wydanie
+
+Pobierz tagi wydań i przełącz się na wybrane wydanie. Tagi wydań zawierają numer wersji, a `git tag` je
+wyświetla; gałąź `main` może zawierać zmiany, które nie zostały jeszcze wydane:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Zbuduj ponownie
+
+Zbuduj ponownie w tych samych trzech krokach co przy instalacji. Najpierw zbuduj ponownie klienta:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Następnie zaktualizuj zależności serwera:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Na koniec ponownie skopiuj przebudowanego klienta do folderu `views` serwera:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Porównaj `.env.example`, w katalogu głównym repozytorium, ze swoim `persistent/.env`, aby uwzględnić ustawienia dodane w wydaniu.
+
+---
+
+## 3. Uruchom ponownie
+
+Uruchom ponownie aplikację i jej RTE, aby wczytać nowy kod. Schemat bazy danych jest aktualizowany przy pierwszym uruchomieniu:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Przy przejściu z 7.2 RTE działało w trybie bazy danych, z ustawieniami bazy danych i `RTE_URL`, przestarzałym w 7.3.0 i usuniętym w 8.0.0.
+Uruchom je ponownie w trybie inbound i zadeklaruj jego runner z poświadczeniem RTE w seedzie lub w **Połączenia → Runnery**, tak jak
+pokazuje [instalacja](../installation/from-source.html#run): `pm2 delete ansibleforms-rte`, a potem jego polecenie `pm2 start`.
+
+Jeśli uruchamiasz aplikację bez PM2, zatrzymaj `npm run start` i uruchom go ponownie.
+
+---
+
+## 4. Sprawdź aktualizację
+
+Śledź dziennik aplikacji podczas uruchamiania:
+
+```bash
+pm2 logs ansibleforms
+```
+
+W AnsibleForms **Pomoc → O programie** pokazuje działającą wersję, a **Ustawienia → Stan** pokazuje kondycję
+bazy danych, schematu i innych systemów, od których zależy AnsibleForms.
+
+---
+
+## Wycofanie aktualizacji
+
+Aby wrócić do wydania, którego używałeś wcześniej, czyli wersji, którą **Pomoc → O programie** pokazywało przed aktualizacją, przełącz się na jej tag poleceniem
+`git checkout <version>`, a potem zbuduj ponownie i uruchom ponownie jak w krokach 2 i 3. Jeśli to wydanie nie uruchamia się na zaktualizowanej bazie danych, przywróć kopię zapasową wykonaną w
+**Ustawienia → Kopie zapasowe**.
diff --git a/i18n/pl/_get_started/upgrading/index.md b/i18n/pl/_get_started/upgrading/index.md
new file mode 100644
index 0000000..54f1670
--- /dev/null
+++ b/i18n/pl/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Aktualizacja
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Aktualizacja
+{: .no_toc }
+
+Przenieś AnsibleForms na nowsze wydanie
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów działającej instancji: przejdź na nowsze wydanie, tą samą metodą, którą zostało zainstalowane.
+
+---
+
+## W tej sekcji
+
+Procedura aktualizacji zależy od sposobu instalacji AnsibleForms. Każda metoda jest opisana na osobnej stronie:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Aktualizacja do v7](../upgrade-7.html) | Co zmienić, będąc jeszcze na 6.5, przed przejściem na 7 |
+| [Instalatorem](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, dla instalacji wykonanej instalatorem: kopia zapasowa, informacje o wydaniu i wycofanie |
+| [Docker](docker.html) | Pobierz nowy obraz i utwórz ponownie kontener z tymi samymi ustawieniami |
+| [Docker Compose](docker-compose.html) | Pobierz nowy obraz i uruchom ponownie projekt docker-compose |
+| [Ze źródeł](from-source.html) | Pobierz nowy kod, zbuduj go ponownie i uruchom ponownie aplikację |
+| [Kubernetes](kubernetes.html) | Odśwież repozytorium chartów i uruchom `helm upgrade` ze swoimi wartościami |
+
+{: .note }
+> **Najpierw kopia zapasowa** Przed aktualizacją wykonaj kopię zapasową (**Ustawienia → Kopie zapasowe**). Schemat bazy danych jest aktualizowany przy pierwszym
+> uruchomieniu nowego wydania, więc kopia zapasowa jest Twoim punktem powrotu, jeśli coś pójdzie nie tak. Od wersji 7.3.0 worker również sam
+> wykonuje kopię przed aktualizacją ze starszego wydania, nazwaną od wydania, chyba że
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) ma wartość `0`.
+
+Wydanie, które otrzymujesz, zależy od tagu obrazu, którego używasz: `latest` podąża za najnowszą wersją główną, a tag taki jak `7`
+pozostaje na tej wersji głównej. Wszystkie tagi są wymienione w [Tagi obrazów](../installation/#image-tags).
diff --git a/i18n/pl/_get_started/upgrading/kubernetes.md b/i18n/pl/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..2246820
--- /dev/null
+++ b/i18n/pl/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Aktualizacja
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Aktualizacja instalacji wykonanej chartem Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Każda wersja chartu wdraża jedno wydanie AnsibleForms. Aktualizacja instaluje nowszą wersję chartu z Twoimi istniejącymi wartościami;
+dane na wolumenach trwałych zostają zachowane. Aktualizacja, która niczego nie zmienia, nie rusza podów.
+
+---
+
+## Przed aktualizacją
+
+Przygotuj aktualizację tak, aby można było wrócić, jeśli coś pójdzie nie tak:
+
+* **Wykonaj kopię zapasową** w **Ustawienia → Kopie zapasowe**. Nowe wydanie aktualizuje schemat bazy danych przy pierwszym uruchomieniu.
+* **Przeczytaj [dziennik zmian](../changelog)** dla wydań między Twoją wersją a nową.
+* **Przechodzisz na nową wersję główną?** Najpierw postępuj zgodnie z [Aktualizacja do v7](../upgrade-7.html).
+* **Przeczytaj [dziennik zmian](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) chartu**, aby poznać zmiany w wartościach.
+* **Przy generowanych poświadczeniach** (`secrets.generate`) wykonaj kopię zapasową Secretu `<release>-secrets`: `ENCRYPTION_SECRET` nie da się odzyskać.
+* **Przechodzisz z 7.2?** RTE w podzie serwera zmienia tryb: zobacz [Z 7.2 do 7.3](#from-72-to-73).
+
+---
+
+## Z 7.2 do 7.3
+
+Chart 7.3.0 przenosi RTE działające obok aplikacji z trybu bazy danych, przestarzałego w 7.3.0 i usuniętego w 8.0.0. Aplikacja łączy się z nim pod
+`127.0.0.1` i utrzymuje otwarty jeden WebSocket (`RTE_MODE=inbound`, zobacz [Tryby](../rte/modes.html)):
+
+* Kontener RTE nie dostaje już `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` ani `RTE_URL`, a pliki zadania pobiera ze
+  współdzielonego wolumenu (`RTE_FILES=local`)
+* Config seed chartu deklaruje poświadczenie RTE z tokenem i adresem oraz runner, `rte_mode: inbound`, który się nim
+  loguje. Przy seedzie chartu nie trzeba nic robić
+* Przy `containers.rte.seedRunner: false` lub własnym config seed (`CONFIG_SEED_PATH`) RTE nie dodaje się już samo jako runner.
+  Zadeklaruj go samodzielnie, w swoim seedzie lub w **Połączenia → Runnery**: poświadczenie RTE z `http://127.0.0.1:<port>` i tokenem
+  oraz runner typu RTE z `rte_mode: inbound`, który je wskazuje. Uwagi, które Helm wypisuje po aktualizacji, pokazują, jak to zrobić
+
+Od wersji 7.3.0 chart instaluje też samodzielnie Runner, przez `runner.enabled` (zobacz
+[Runner na Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Znajdź nową wersję chartu
+
+Odśwież repozytorium chartów i wyświetl dostępne wersje chartu:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Zaktualizuj wydanie
+
+Uruchom to samo polecenie `helm upgrade` co przy instalacji, ze swoim plikiem wartości i nową wersją chartu:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+W przypadku rejestru OCI użyj `oci://ghcr.io/ansibleforms/charts/ansibleforms` jako chartu.
+
+---
+
+## 3. Sprawdź aktualizację
+
+Poczekaj na nowe pody, a potem uruchom test chartu, który sprawdza zarówno serwer webowy, jak i połączenie z bazą danych:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+W AnsibleForms **Pomoc → O programie** pokazuje działającą wersję, a **Ustawienia → Stan** pokazuje kondycję
+bazy danych, schematu i innych systemów, od których zależy AnsibleForms.
+
+---
+
+## Wycofanie aktualizacji
+
+Helm przechowuje historię wydania. Aby wrócić do poprzedniej rewizji:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Jeśli nie uruchamia się na zaktualizowanej bazie danych, przywróć kopię zapasową (zobacz [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) chartu).
diff --git a/i18n/pl/_integrate/api/authentication.md b/i18n/pl/_integrate/api/authentication.md
new file mode 100644
index 0000000..daf1104
--- /dev/null
+++ b/i18n/pl/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Uwierzytelnianie
+parent: API REST
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Uwierzytelnianie
+{: .no_toc }
+
+Logowanie, odświeżanie tokenu lub używanie tokenu długoterminowego
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Każde wywołanie wymaga tokenu dostępu w nagłówku `Authorization`. Token uzyskuje się przez zalogowanie, a odświeża
+za pomocą tokenu odświeżania (refresh token).
+
+---
+
+## Logowanie
+
+Zaloguj się uwierzytelnianiem basic, podając nazwę użytkownika i hasło:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+Odpowiedź zawiera dwa tokeny, token dostępu i token odświeżania:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Wywoływanie API
+
+Wysyłaj token dostępu jako token bearer przy każdym wywołaniu:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Odświeżanie tokenu
+
+Token dostępu wygasa (`ACCESS_TOKEN_EXPIRATION`, domyślnie 30 minut). Nowy uzyskasz tokenem odświeżania,
+bez hasła:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+Odpowiedź zawiera nową parę, w tej samej postaci co przy logowaniu. Token odświeżania działa raz: zachowaj nowy na następne odświeżenie.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Tokeny długoterminowe
+
+Skrypt działający bez nadzoru może używać tokenu, który żyje dłużej. Od wersji 7.3.0 wymaga to opcji roli `allowApiTokens`:
+
+* Utwórz go w [Profil > Tokeny API](../profile/api-token.html).
+* Albo zaloguj się z parametrem zapytania `expiryDays`, aby uzyskać token ważny przez podaną liczbę dni:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` jest odczytywany tylko z adresu URL, nigdy z treści żądania. Dla użytkownika, którego role nie mają `allowApiTokens`, jest ignorowany,
+a logowanie zwraca token o zwykłym czasie życia. `expiryDays=never` wymaga też `extendedTokenExpiration`. Dodaj parametr zapytania `name`
+(`?expiryDays=90&name=nightly-backup`), aby nadać tokenowi nazwę na liście tokenów użytkownika.
+
+Token długoterminowy żyje maksymalnie [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) dni, domyślnie
+90: dłuższy `expiryDays` jest do tej wartości przycinany, chyba że ma wartość `never`. Odświeżenie go zwraca zwykły token, więc gdy wygaśnie, zaloguj się ponownie.
+
+### Tokeny zalogowanego użytkownika
+
+Widok **Tokeny API** w profilu korzysta z tych endpointów, które działają dla każdego konta, także SSO, bo nie wymagają hasła:
+
+| Wywołanie | Co robi |
+|---|---|
+| `GET /api/v2/profile/tokens` | Wyświetla listę Twoich tokenów API, z ich `sid`, `name`, datą utworzenia, wygaśnięcia i ostatniego użycia |
+| `POST /api/v2/profile/tokens` | Tworzy token z Twojej sesji; treść zawiera `expiryDays` (liczbę lub `never`) i opcjonalnie `name` |
+| `DELETE /api/v2/profile/tokens/{sid}` | Unieważnia jeden z Twoich tokenów |
+
+`POST` odpowiada `403`, gdy zostanie wywołany tokenem API (token nie może utworzyć kolejnego), bez `allowApiTokens` lub gdy
+sesja zalogowała się ponad 10 minut temu (kod `sign_in_again`): najpierw zaloguj się ponownie. Czas życia powyżej maksimum daje odpowiedź `400`.
+
+---
+
+## Gdy token wygasa przedwcześnie
+
+Token, długoterminowy lub nie, przestaje działać przed wygaśnięciem, gdy zdarzy się jedna z tych rzeczy:
+
+* **Wylogowanie z jego sesji**: `POST /api/v2/auth/logout` z tym tokenem kończy tokeny tego logowania i tylko te.
+  Wylogowanie w przeglądarce nie kończy tokenu skryptu.
+* **Zmiana hasła**: użytkownik zmienia swoje hasło albo ustawia je administrator. Każdy wcześniej wydany token jest odrzucany.
+* **Użytkownik zostaje usunięty lub zablokowany**: usunięcie lokalnego użytkownika lub zablokowanie użytkownika kończy wszystkie jego tokeny. Administrator może też
+  zakończyć sesje użytkownika LDAP lub SSO.
+
+Odrzucony token daje odpowiedź `401`. Zaloguj się ponownie, nowym hasłem, jeśli zostało zmienione.
+
+---
+
+## Skrypty logujące się przy każdym uruchomieniu
+
+Endpointy logowania i tokenów są chronione przed zalewem żądań i odgadywaniem haseł, więc skrypt, który loguje się przy każdym uruchomieniu,
+powinien znać te limity:
+
+| Limit | Domyślnie | Co się dzieje |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 żądań na minutę z jednego adresu | Logowanie, wylogowanie, odświeżanie, endpointy SSO, `PUT /api/v2/profile` (zmiana hasła) oraz `POST` lub `DELETE /api/v2/profile/tokens` odpowiadają `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 nieudanych logowań z rzędu | Konto jest blokowane na [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), każde logowanie odpowiada `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 nieudanych logowań z jednego adresu | Każde logowanie z tego adresu odpowiada `429` aż do końca okna czasowego |
+
+Odpowiedź `429` zawiera nagłówek `Retry-After` z liczbą sekund do odczekania: zatrzymaj się i poczekaj, nie ponawiaj od razu. Zablokowane konto
+odrzuca nawet poprawne hasło do końca blokady, więc skrypt z błędnym hasłem blokuje swojego użytkownika dla wszystkich.
+Błędne bieżące hasło przy zmianie hasła (`PUT /api/v2/profile`) również liczy się jako nieudane logowanie, a zablokowane konto
+nie może zmienić hasła. Udane logowanie zeruje licznik konta, podobnie jak ustawienie hasła przez administratora.
+
+Aby nie trafiać na te limity, zaloguj się raz i używaj tego samego tokenu albo użyj tokenu długoterminowego, zamiast logować się przy
+każdym wywołaniu. Za reverse proxy ustaw [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY), aby serwer widział
+adres klienta, w przeciwnym razie wszyscy klienci liczą się jako jeden.
diff --git a/i18n/pl/_integrate/api/events.md b/i18n/pl/_integrate/api/events.md
new file mode 100644
index 0000000..48db256
--- /dev/null
+++ b/i18n/pl/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Zdarzenia na żywo
+parent: API REST
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Zdarzenia na żywo
+{: .no_toc }
+
+Informacje o zmianach zadań i ustawień zamiast odpytywania
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Serwer informuje swoich klientów o zmianach w chwili, gdy następują. Skrypt też może nasłuchiwać, zamiast odczytywać zadanie co kilka sekund.
+
+---
+
+## Strumień
+
+`GET /api/v2/events` to strumień [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events),
+który pozostaje otwarty. Może go otworzyć każdy zalogowany użytkownik, ze zwykłym tokenem bearer:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Gdy coś się zmienia, wysyła zdarzenie `changed` z nazwą tego, co się zmieniło:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Nazwy zdarzeń
+
+Zdarzenie zawiera tylko nazwę, nigdy dane, więc nie ujawnia niczego, czego użytkownik nie może zobaczyć. Wysyłane są te nazwy:
+
+| Nazwa | Co się zmieniło |
+|---|---|
+| `jobs` | Zadanie: uruchomione, zmiana jego stanu lub wyniku, usunięte |
+| `appearance` | Ustawienia widoczne w nagłówku: motyw, nazwa, ogłoszenie, zmienna środowiskowa |
+| `designer` | Blokada projektanta, założona lub zwolniona |
+| `runners` | Runner (od wersji 7.3.0): RTE połączyło się lub rozłączyło, poprosiło o dołączenie, zostało zatwierdzone lub odrzucone albo zmieniło tryb lub ustawienia |
+
+Po otrzymaniu nazwy odczytaj ponownie to, co wyświetlasz, przez zwykłe API (na przykład `GET /api/v2/job/42`), z własnymi
+uprawnieniami. Często zmieniająca się nazwa jest wysyłana najwyżej raz na sekundę.
+
+---
+
+## Utrzymywanie połączenia
+
+Strumień jest zbudowany tak, aby przetrwać proxy i load balancery, a klient sam łączy się ponownie:
+
+* Po połączeniu serwer wysyła zdarzenie `hello` i prosi klienta, aby przed ponownym połączeniem odczekał 3 sekundy.
+* Co 15 sekund wysyła wiersz komentarza (`: ping`), aby bezczynne połączenie nie zostało zamknięte. Ignoruj wiersze zaczynające się od `:`.
+* Zdarzenia z każdego węzła aplikacji trafiają do każdego strumienia, niezależnie od tego, z którym węzłem połączony jest klient.
+* Po ponownym połączeniu odczytaj jeszcze raz to, co wyświetlasz: zdarzenie wysłane, gdy strumień nie działał, nie jest wysyłane ponownie.
+
+---
+
+## Stan i metryki
+
+Sondy liveness i readiness (`/api/v2/live`, `/api/v2/ready`) oraz metryki Prometheus (`/api/v2/metrics`) są
+przeznaczone dla narzędzi monitorujących, a nie dla skryptów działających jako użytkownik. Zobacz [Monitorowanie](../production/monitoring.html).
diff --git a/i18n/pl/_integrate/api/index.md b/i18n/pl/_integrate/api/index.md
new file mode 100644
index 0000000..aa5f322
--- /dev/null
+++ b/i18n/pl/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: API REST
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# API REST
+{: .no_toc }
+
+Uruchamiaj formularze i zarządzaj AnsibleForms ze skryptów
+{: .fs-6 .fw-300 }
+
+---
+
+Dla programistów i inżynierów automatyzacji: uruchamiaj formularze i zarządzaj AnsibleForms ze skryptów.
+
+Wszystko, co robi interfejs webowy, przechodzi przez API REST, więc skrypty i inne narzędzia mogą robić to samo.
+
+---
+
+## Przegląd
+
+API jest udostępniane pod `/api/v2` na serwerze AnsibleForms:
+
+* **Pełna dokumentacja** : te strony opisują to, czego skrypty używają najczęściej. Każdy endpoint jest opisany i można go wypróbować na
+  wbudowanej stronie Swagger serwera, `https://<your server>/api/v2/docs`.
+* **Uprawnienia** : wywołanie działa jako użytkownik, którego token zawiera, z rolami tego użytkownika, tak jak w przeglądarce.
+* **Walidacja przy uruchomieniu** : zadania uruchamiane przez API mogą być sprawdzane tak samo jak uruchomienia z przeglądarki
+  (zobacz [Walidacja przy uruchomieniu](../launch-validation/)).
+* **Limity żądań** : ograniczone są tylko endpointy logowania, wylogowania, odświeżania tokenu i jednokrotnego logowania, zmiana hasła
+  (`PUT /api/v2/profile`) oraz endpointy tokenów API (`POST` i `DELETE /api/v2/profile/tokens`) (zobacz
+  [Uwierzytelnianie](authentication.html)). Pozostałe wywołania nie mają limitu (z wyjątkiem [asystenta czatu](../chat/), który ma własne
+  limity), więc skrypt powinien sam dbać o tempo, na przykład gdy śledzi zadanie.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Uwierzytelnianie](authentication.html) | Logowanie, odświeżanie tokenu lub używanie tokenu długoterminowego |
+| [Zadania](jobs.html) | Uruchamianie formularza, śledzenie zadania, przerywanie, ponowne uruchamianie lub zatwierdzanie go |
+| [Odpowiedzi i błędy](responses.html) | Struktura odpowiedzi i kody stanu |
+| [Zdarzenia na żywo](events.html) | Informacje o zmianach zadań i ustawień zamiast odpytywania |
diff --git a/i18n/pl/_integrate/api/jobs.md b/i18n/pl/_integrate/api/jobs.md
new file mode 100644
index 0000000..0a3885a
--- /dev/null
+++ b/i18n/pl/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Zadania
+parent: API REST
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Zadania
+{: .no_toc }
+
+Uruchamianie formularza, śledzenie zadania, przerywanie, ponowne uruchamianie lub zatwierdzanie go
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Zadanie to jedno uruchomienie formularza. Uruchom je, podając nazwę formularza i wartości, a potem śledź po jego ID.
+
+---
+
+## Uruchamianie formularza
+
+Wyślij nazwę formularza i jego wartości do `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+Żądanie przyjmuje te właściwości:
+
+| Właściwość | Znaczenie |
+|---|---|
+| `formName` | Nazwa formularza do uruchomienia. Wymagana. |
+| `extravars` | Dodatkowe zmienne zadania. `payload` jest akceptowany jako inna nazwa tej właściwości. |
+| `rawFormData` | Wartości pól formularza, tak jak przechowuje je przeglądarka. [Walidacja przy uruchomieniu](../launch-validation/) sprawdza je i buduje z nich extravars. |
+| `credentials` | Poświadczenia przekazywane do zadania, według nazwy. |
+| `files` | Pliki przesłane przez pola plików formularza (zobacz [Przesyłanie plików](../launch-validation/file-uploads.html)). |
+
+Odpowiedź zawiera ID nowego zadania:
+
+```json
+{ "id": 42 }
+```
+
+Aby uruchomić zadanie w trybie szczegółowym (verbose), dodaj `"__verbose__": true` do extravars. Wymaga to opcji roli `allowVerboseMode`,
+w przeciwnym razie uruchomienie odpowiada `403`.
+
+---
+
+## Przesyłanie pliku
+
+Formularz z polem pliku wymaga wcześniejszego przesłania pliku. Wyślij go jako część multipart `file` do `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+Odpowiedź opisuje zapisany plik:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Przekaż ją bez zmian w `files` uruchomienia, pod nazwą pola pliku: `"files": { "firmware": { ... } }`. Serwer
+sprawdza ją względem własnego dysku (zobacz [Przesyłanie plików](../launch-validation/file-uploads.html)).
+
+---
+
+## Śledzenie zadania
+
+Odczytaj zadanie po jego ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+Zadanie zawiera swój `status`, swoje `extravars` (także jako `payload`, ten sam obiekt), swoje `subjobs` i swój `output`.
+Wynik jest w HTML, z kolorami strony zadania; dodaj `?text=true`, aby uzyskać zwykły tekst, który lepiej pasuje do skryptu lub dziennika:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+Jego `status` to `running`, dopóki działa, i `approve`, gdy czeka na zatwierdzenie. Zadanie kończy się jednym z tych stanów:
+
+| Stan | Znaczenie |
+|---|---|
+| `success` | Zadanie zakończyło się bez błędów |
+| `failed` | Zadanie zakończyło się błędem |
+| `warning` | Zadanie wieloetapowe zakończyło się, ale po drodze nie powiódł się etap z ustawionym `continue` |
+| `aborted` | Zadanie zostało przerwane |
+| `rejected` | Zatwierdzenie zostało odrzucone, więc to, co na nie czekało, nie zostało uruchomione |
+| `abandoned` | Proces śledzący zadanie zatrzymał się (restart, wymiana kontenera) i zadanie zostało porzucone |
+
+Zadanie, które działało na runnerze w chwili porzucenia, może mimo to zakończyć się rzeczywistym wynikiem, jeśli ten runner je ostatecznie dokończy.
+
+---
+
+## Wyszukiwanie zadań
+
+`GET /api/v2/job` zwraca listę zadań, od najnowszych, jako `{ "count": ..., "records": [ ... ] }`. Te parametry zapytania ją zawężają:
+
+| Parametr | Znaczenie |
+|---|---|
+| `records` | Maksymalna liczba zadań. Domyślnie [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), a najwyżej 5000, chyba że `JOBS_LIST_SIZE` jest większe. |
+| `user`, `user_type` | Tylko zadania tego użytkownika. `user_type` ma wartość `local`, gdy zostanie pominięty (`ldap`, `azuread`, `oidc` dla pozostałych). |
+| `runner` | Tylko zadania, które działały na tym runnerze |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Użytkownik widzi własne zadania oraz zadania czekające na zatwierdzenie, którego może udzielić jedna z jego ról. Administrator lub rola z
+opcją `showAllJobLogs` albo `manageAllJobs` widzi wszystkie zadania. Rekord zawiera podsumowanie zadania (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); aby poznać
+jego extravars i wynik, odczytaj samo zadanie.
+
+`GET /api/v2/job/approvals` odpowiada liczbą: ile zadań czeka na zatwierdzenie, którego użytkownik może udzielić.
+
+---
+
+## Więcej o zadaniu
+
+Te endpointy odczytują więcej informacji o jednym zadaniu:
+
+| Wywołanie | Co zwraca |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | Wartości pól, z którymi zadanie zostało uruchomione, tak jak przechowywał je formularz. Obowiązują te same uprawnienia co przy ponownym uruchomieniu: Twoje własne zadanie (albo każde zadanie dla administratora lub roli z `manageAllJobs`), formularz, który pozwala na ponowne uruchomienie, oraz opcja roli `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Ustrukturyzowane zdarzenia zadania playbooka (od wersji 7.3.0, dla playbooka na RTE w wersji 7.3.0 lub nowszej): każdy play, task, wynik hosta i podsumowanie (recap), z ich `order`, `type`, `play`, `task`, `host`, `duration` i `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Jedno z tych zdarzeń z całym jego `result`, tak jak pokazuje je okno **Wynik zadania**; `400`, gdy `order` nie jest liczbą całkowitą, `404`, gdy zadanie nie ma takiego zdarzenia |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Jeden węzeł zadania workflow: `{ "node", "job", "extravars", "artifacts" }`, gdzie `job` to ID własnego zadania węzła albo `null`, gdy węzeł się nie uruchomił. |
+
+---
+
+## Inne akcje
+
+Te endpointy działają na istniejącym zadaniu:
+
+| Wywołanie | Akcja |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Przerwanie działającego zadania |
+| `POST /api/v2/job/{id}/relaunch` | Ponowne uruchomienie zadania, tak jak działało lub ze zmianami (zobacz [Ponowne uruchamianie](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Zatwierdzenie zadania czekającego na zatwierdzenie; Twoje własne zadanie odpowiada `403`, chyba że jego zatwierdzenie ustawia `allowSelf: true` lub jesteś administratorem |
+| `POST /api/v2/job/{id}/reject` | Odrzucenie zadania czekającego na zatwierdzenie |
+| `GET /api/v2/job/{id}/download` | Pobranie wyniku zadania |
+| `DELETE /api/v2/job/{id}` | Usunięcie zadania |
+
+Przerwanie, zatwierdzenie, odrzucenie i usunięcie odpowiadają komunikatem, a ponowne uruchomienie dodatkowo ID nowego zadania:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Dodaj `?verbose=true` do ponownego uruchomienia, aby nowe zadanie działało w trybie szczegółowym, z opcją roli `allowVerboseMode`. Zadanie, które
+jest w niewłaściwym stanie dla danej akcji, na przykład przerwanie zadania, które już się zakończyło, odpowiada `409`.
diff --git a/i18n/pl/_integrate/api/responses.md b/i18n/pl/_integrate/api/responses.md
new file mode 100644
index 0000000..e4a2c7e
--- /dev/null
+++ b/i18n/pl/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Odpowiedzi i błędy
+parent: API REST
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Odpowiedzi i błędy
+{: .no_toc }
+
+Struktura odpowiedzi i kody stanu
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Odpowiedzi są zwykłym JSON-em, a kod stanu HTTP informuje, czy wywołanie się powiodło.
+
+---
+
+## Odpowiedzi
+
+Udane wywołanie zwraca sam obiekt lub listę wraz z jej rozmiarem:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Błąd zwraca komunikat oraz szczegóły, jeśli są:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Kody stanu
+
+Kod stanu mówi, co poszło nie tak:
+
+| Kod | Znaczenie |
+|---|---|
+| `200` | Wywołanie się powiodło |
+| `400` | Żądanie jest nieprawidłowe, na przykład odświeżenie tokenu bez tokenu odświeżania lub przesłanie bez pliku |
+| `401` | Brak tokenu, token jest błędny lub wygasł: zaloguj się albo go odśwież |
+| `403` | Role użytkownika nie pozwalają na to wywołanie (łącznie z zatwierdzaniem własnego zadania, chyba że jego zatwierdzenie ustawia `allowSelf: true` lub jesteś administratorem) albo konto musi najpierw coś zrobić (zobacz niżej) |
+| `404` | Obiekt nie istnieje |
+| `409` | Żądanie jest niekompletne (uruchomienie bez danych) albo obiekt nie jest w stanie, który pozwala na tę akcję |
+| `422` | [Walidacja przy uruchomieniu](../launch-validation/) odrzuciła wartości formularza; `details` podaje powody |
+| `429` | Zbyt wiele żądań do endpointów logowania i tokenów albo zbyt wiele nieudanych logowań (zobacz [Uwierzytelnianie](authentication.html)) |
+| `500` | Błąd serwera; przyczyna jest w dzienniku serwera |
+
+W przypadku zadania `409` oznacza, że jest ono w niewłaściwym stanie dla danej akcji: przerwanie zadania, które nie działa (lub którego przerwanie już zlecono),
+ponowne uruchomienie zadania, które wciąż działa, albo zatwierdzenie lub odrzucenie zadania, które już nie czeka na zatwierdzenie.
+
+---
+
+## 403 z kodem
+
+Niektóre odpowiedzi `403` zawierają `code`, oznaczający coś, co użytkownik musi zrobić w przeglądarce, zanim zadziała jakiekolwiek inne wywołanie:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Kod | Co zrobić |
+|---|---|
+| `password_change_required` | Użytkownik zalogował się publicznym hasłem domyślnym: najpierw zmień je w profilu |
+| `disclaimer_required` | Zastrzeżenie jest włączone, a użytkownik nie zaakceptował jeszcze jego bieżącej wersji: zaakceptuj je w przeglądarce |
+
+Długoterminowy token API (zobacz [Uwierzytelnianie](authentication.html#long-lived-tokens)) nigdy nie jest blokowany przez zastrzeżenie.
diff --git a/i18n/pl/_integrate/chat/index.md b/i18n/pl/_integrate/chat/index.md
new file mode 100644
index 0000000..cd710f3
--- /dev/null
+++ b/i18n/pl/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Asystent czatu
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Asystent czatu
+{: .no_toc }
+
+Wypełniaj i uruchamiaj formularze w rozmowie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów, którzy go włączają, i użytkowników, którzy z nim rozmawiają: wypełniaj i uruchamiaj formularze w rozmowie.
+
+Przycisk czatu na każdej stronie otwiera
+asystenta, który znajduje właściwy formularz, pyta o brakujące informacje, oferuje własne opcje
+formularza jako przyciski i pokazuje podsumowanie z przyciskiem **Uruchom**. Zadanie rozpoczyna się dopiero wtedy, gdy użytkownik go kliknie.
+
+---
+
+## Jak to działa
+
+Asystent komunikuje się z modelem AI przez serwer, który odpowiada na żądania modelu za pomocą tego samego silnika formularzy co przeglądarka:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **Wywołania modelu pochodzą z serwera**, nigdy z przeglądarki, więc klucz API pozostaje na serwerze
+  (zobacz [Dostawcy](providers.html)).
+- **Model nie może niczego uruchomić.** Przygotowuje jednorazowe podsumowanie; przycisk Uruchom sprawdza je ponownie przed uruchomieniem.
+- **To użytkownik wybiera cele.** Opcje i wymagane nazwy pochodzą od użytkownika, nigdy od modelu.
+- **Wpisanie „tak” lub „uruchom” nic nie robi.** Zadanie uruchamia tylko przycisk.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Włączanie](switching-it-on.html) | Włączenie asystenta i udostępnienie w nim formularzy |
+| [Dostawcy](providers.html) | Model językowy stojący za asystentem oraz proxy |
+| [Prywatność i limity](privacy-and-limits.html) | Co opuszcza sieć i jakie są limity na użytkownika |
+| [Ponowne uruchamianie i audyt](relaunching-and-audit.html) | Ponowne uruchamianie z czatu, ślad audytu i ograniczenia |
diff --git a/i18n/pl/_integrate/chat/privacy-and-limits.md b/i18n/pl/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..b1f332e
--- /dev/null
+++ b/i18n/pl/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Prywatność i limity
+parent: Asystent czatu
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Prywatność i limity
+{: .no_toc }
+
+Co opuszcza sieć i jakie są limity na użytkownika
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Co opuszcza sieć
+
+Dla formularzy, które biorą udział w czacie, do dostawcy wysyłane są:
+
+- nazwy i opisy formularzy, etykiety pól, teksty pomocy, opcje do wyboru i wypełniane
+  wartości;
+- rozmowa.
+
+Nigdy nie są wysyłane do dostawcy, na stronę ani do dziennika:
+
+- hasła (użytkownik wpisuje je w przeglądarce), zapisane poświadczenia i klucz API;
+- wynik zadania i jego zapisane extravars (asystent odczytuje tylko stan zadania, i to tylko
+  wtedy, gdy w ustawieniach włączona jest opcja **Pozwól asystentowi śledzić jego joby**).
+
+Wszystko pod kluczem, który wygląda na sekret (`password`, `secret`, `token`, `api_key`, ...),
+jest maskowane, zanim zobaczy to model lub strona.
+
+Aby dane formularzy nie opuszczały firmy, używaj własnego tenanta (Azure OpenAI) lub lokalnego modelu (Ollama), a nie publicznego API.
+
+---
+
+## Limity
+
+Te limity ustawia się na stronie ustawień:
+
+- **Wiadomości na rozmowę** (20) - po ich wyczerpaniu użytkownik musi rozpocząć nową rozmowę.
+- **Rundy narzędzi na wiadomość** (6) - ile razy model może wywołać narzędzie, zanim odpowie.
+- **Limit czasu** (60 s) - na każde wywołanie dostawcy.
+
+Te limity są stałe: jedna wiadomość naraz w rozmowie, najwyżej 4000 znaków na wiadomość, 60 wiadomości na
+użytkownika na godzinę i 5 rozmów na użytkownika. Rozmowa jest odrzucana po 2 godzinach bez wiadomości.
+
+Karty podsumowania z przyciskiem **Uruchom** można użyć raz, a po 15 minutach wygasa: wtedy Uruchom odpowiada, że
+podsumowanie wygasło, i użytkownik prosi asystenta o nowe. Rozmowy i podsumowania są przechowywane w pamięci, więc po
+restarcie użytkownik musi rozpocząć nową rozmowę.
diff --git a/i18n/pl/_integrate/chat/providers.md b/i18n/pl/_integrate/chat/providers.md
new file mode 100644
index 0000000..752c356
--- /dev/null
+++ b/i18n/pl/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Dostawcy
+parent: Asystent czatu
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Dostawcy
+{: .no_toc }
+
+Model językowy stojący za asystentem oraz proxy
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Wybierz dostawcę na stronie ustawień. Wypełnia to bazowy adres URL, uwierzytelnianie i
+wersję API, a wszystkie te pola można dalej edytować. Puste pola przyjmują wartości domyślne dostawcy.
+
+| Dostawca | Protokół | Bazowy adres URL (domyślny) | Klucz wysyłany jako |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | wymagany: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, wersja API `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | brak |
+| **Inny zgodny z OpenAI** (LiteLLM, brama, vLLM, LM Studio, ...) | OpenAI | wymagany, zwykle zakończony na `/v1` | Bearer |
+
+ID modelu to identyfikator, którego używa dostawca lub proxy (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). Asystent wymaga modelu, który obsługuje **wywoływanie narzędzi** (tool calling); wśród
+małych modeli lokalnych obsługa bywa różna.
+
+Dla serwerów lokalnych i proxy, które nie wymagają klucza, wystarczy sam bazowy adres URL; nagłówek autoryzacji nie jest wtedy wysyłany.
+
+---
+
+## Klucz API
+
+Klucz pochodzi z poświadczenia, więc jest przechowywany i rotowany jak każdy inny sekret:
+
+* Utwórz poświadczenie typu **api** w **Ustawienia > Połączenia > Poświadczenia** (zobacz [Poświadczenia](../credentials.html)),
+  z kluczem jako hasłem. Może ono też odczytywać klucz z [magazynu sekretów](../secret-stores/).
+* Wybierz je w polu **Poświadczenie** w ustawieniach czatu. Klucz jest odczytywany przy każdej wiadomości, więc
+  zmienione hasło obowiązuje od następnej wiadomości.
+
+Klucz zapisany na stronie ustawień, zanim pojawiły się poświadczenia, nadal działa, dopóki nie wybrano żadnego poświadczenia.
+[Config seed](../seed/) ustawia sam klucz, jako `api_key`.
+
+---
+
+## Dla proxy
+
+Proxy lub brama przed modelem może wymagać tych ustawień:
+
+- **Uwierzytelnianie** - sposób wysyłania klucza: `Authorization: Bearer`, `api-key`, `x-api-key`
+  albo brak. Puste oznacza wartość domyślną dostawcy.
+- **Wersja API** - nagłówek `anthropic-version` albo `?api-version=` w adresie URL dla dostawców zgodnych z OpenAI (Azure).
+- **Użytkownik** - wysyłany przy każdym wywołaniu jako `user` (zgodne z OpenAI) lub `metadata.user_id`
+  (Anthropic). Niektóre proxy go wymagają. Puste nic nie wysyła.
+- **Ignoruj błędy certyfikatów** - niebezpieczne; zamiast tego zaufaj CA proxy przez `NODE_EXTRA_CA_CERTS`.
+- **Dodatkowe nagłówki** - obiekt JSON, np. `{"X-Org": "ops"}`. Jednowierszowe wartości tekstowe, najwyżej 20;
+  nagłówków klucza i treści nie można zastąpić.
+
+---
+
+## W kontenerze, za proxy
+
+Czat używa zwykłego wychodzącego HTTPS z kontenera serwera AnsibleForms. Za
+firmowym proxy wychodzącym ustaw `HTTPS_PROXY` **oraz** `NODE_USE_ENV_PROXY=1`; bez tego drugiego
+wbudowany klient HTTP Node ignoruje `HTTPS_PROXY`. Dostawca z certyfikatem wystawionym przez
+wewnętrzne CA wymaga, aby Node ufał temu CA (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Przy `NODE_USE_ENV_PROXY=1` model lub proxy wewnątrz sieci musi być wymieniony w
+`NO_PROXY`, w przeciwnym razie wywołanie trafia do proxy wychodzącego, które nie może do niego dotrzeć.
+
+Nieudany test połączenia podaje host i przyczynę (DNS, odrzucone połączenie lub niezaufany certyfikat).
diff --git a/i18n/pl/_integrate/chat/relaunching-and-audit.md b/i18n/pl/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..7af8356
--- /dev/null
+++ b/i18n/pl/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Ponowne uruchamianie i audyt
+parent: Asystent czatu
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Ponowne uruchamianie i audyt
+{: .no_toc }
+
+Ponowne uruchamianie z czatu, ślad audytu i ograniczenia
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ponowne uruchamianie
+
+Prośba typu „Uruchom ponownie zadanie 1234” (użytkownik musi wpisać ID zadania) pokazuje podgląd ponownego uruchomienia
+według tych samych zasad co `relaunch_job` serwera MCP, łącznie z zasadą dotyczącą haseł w
+[walidacji przy uruchomieniu](../launch-validation), i wyświetla podsumowanie **Uruchom ponownie**; przycisk
+uruchamia je raz. „Uruchom ponownie zadanie 1234 z serwerem web02” zmienia tylko to pole.
+
+---
+
+## Audyt
+
+Każde uruchomienie z czatu jest zapisywane jako **chat.launch** z użytkownikiem, zadaniem, formularzem,
+dostawcą i skrótem (hash) ładunku zatwierdzonego podsumowania. Zmiany w ustawieniach czatu są
+zapisywane tak jak każda inna zmiana ustawień.
+
+---
+
+## Ograniczenia
+
+Asystent czatu nie robi jeszcze wszystkiego, co przeglądarka:
+
+- **Formularze typu kreator** nie mogą brać udziału (`enableForChat` jest dla nich odrzucane), podobnie jak
+  pola, których asystent nie wypełnia: hasła i przesyłane pliki.
+- Odpowiedzi przychodzą w całości; strumieniowanie nie jest jeszcze obsługiwane.
+- Model może źle zrozumieć prośbę. Karta podsumowania pokazuje dokładnie, co zostanie wysłane;
+  przejrzyj ją, zanim klikniesz **Uruchom**.
diff --git a/i18n/pl/_integrate/chat/switching-it-on.md b/i18n/pl/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..a4b7d4d
--- /dev/null
+++ b/i18n/pl/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Włączanie
+parent: Asystent czatu
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Włączanie
+{: .no_toc }
+
+Włączenie asystenta i udostępnienie w nim formularzy
+{: .fs-6 .fw-300 }
+
+---
+
+Asystent wymaga spełnienia wszystkich czterech warunków:
+
+1. **`ENABLE_CHAT=1`** - zmienna środowiskowa. Zmieniona na stronie ustawień obowiązuje od razu, bez restartu; dopóki
+   jest wyłączona, endpointy czatu odpowiadają `404`. Zobacz [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Dostawca modelu** - Ustawienia -> Połączenia -> **Asystent czatu** (lub [config seed](../seed) na Kubernetes).
+3. **Formularze, które biorą udział** - `enableForChat: true` w każdym formularzu; asystent ignoruje wszystkie pozostałe.
+4. **Użytkownicy, którzy mogą z niego korzystać** - opcja roli `allowChat` (domyślnie: true). Ustaw
+   `allowChat: false` w roli, aby wykluczyć jej członków.
+
+Przycisk czatu pojawia się u użytkownika, gdy wszystkie cztery warunki są spełnione.
diff --git a/i18n/pl/_integrate/mcp/index.md b/i18n/pl/_integrate/mcp/index.md
new file mode 100644
index 0000000..d0d60f2
--- /dev/null
+++ b/i18n/pl/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Serwer MCP
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# Serwer MCP
+{: .no_toc }
+
+Pozwól agentom AI korzystać z Twoich formularzy przez Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla administratorów i integratorów: pozwól klientom MCP wyświetlać, wypełniać i uruchamiać formularze jako użytkownik, którego token posiadają.
+
+AnsibleForms może udostępniać serwer
+[Model Context Protocol](https://modelcontextprotocol.io), dzięki czemu klient MCP, na przykład
+backend czatu lub asystent w IDE, może wyświetlić formularze, z których użytkownik może korzystać, poznać ich pola,
+uruchamiać zadania i śledzić ich postęp.
+
+---
+
+## Czym jest, a czym nie jest
+
+Serwer MCP to techniczny interfejs do tego samego przepływu formularzy, którego używa przeglądarka. Działa
+**jako użytkownik, którego token otrzymuje**: te same role formularzy, ta sama widoczność zadań, te
+same kontrole zarezerwowanych extravars co przy wysłaniu z przeglądarki.
+
+Nie dodaje żadnej własnej polityki AI. To, czy agent musi prosić o potwierdzenie przed uruchomieniem,
+z których formularzy może korzystać i ile żądań może wysłać, zależy od klienta MCP. Narzędzie
+uruchamiania jest oznaczone jako destrukcyjne, więc dobrze zachowujący się klient najpierw prosi o potwierdzenie,
+ale serwer tego nie wymusza.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Konfiguracja](setup.html) | Włączenie serwera i uwierzytelnienie klienta |
+| [Narzędzia](tools.html) | Narzędzia, których agent używa do wypełniania, zatwierdzania i ponownego uruchamiania formularzy |
+| [Ograniczenia](limitations.html) | Wyrażenia wykonywane na serwerze i to, czego serwer MCP nie robi |
diff --git a/i18n/pl/_integrate/mcp/limitations.md b/i18n/pl/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..0b237c3
--- /dev/null
+++ b/i18n/pl/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Ograniczenia
+parent: Serwer MCP
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Ograniczenia
+{: .no_toc }
+
+Wyrażenia wykonywane na serwerze i to, czego serwer MCP nie robi
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wyrażenia runLocal
+
+Wyrażenia `runLocal`, pola `local` / `credential` / `html` i wartości domyślne `evalDefault` są
+obliczane na serwerze, w osobnym kontekście V8: bez `process`, `require`, sieci ani
+timerów, bez kompilowania ciągów znaków do kodu, z limitem czasu 2 sekund i tylko z funkcjami
+pomocniczymi, które oferuje przeglądarka (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Chroni to przed wadliwymi lub niekończącymi się wyrażeniami. Nie jest to piaskownica dla wrogiego kodu
+i nie musi nią być: kod pochodzi z definicji formularza, nigdy od wywołującego MCP,
+a każda wartość wysłana przez wywołującego jest podstawiana jako literał JavaScript.
+
+Wyrażenie, które korzysta z API przeglądarki (`window`, `document`, `fetch`), nie może tu działać i
+zwraca `status: error`.
+
+Wyrażenia po stronie serwera (bez `runLocal`) podlegają tym samym regułom
+[`EXPRESSION_SANITIZER`](../customization) co w przypadku przeglądarki.
+
+---
+
+## Ograniczenia
+
+Niektórych formularzy i pól nie można jeszcze używać przez serwer MCP:
+
+- **Formularzy typu kreator** nie można jeszcze uruchamiać. Ich kroki można rozwiązywać przez `subform`.
+- **Pól plików** nie można wypełniać; formularz, którego pole pliku ma wartość, jest odrzucany.
+- **Wiersze list** (oraz pole `yaml` z podformularzem, które jest jednym takim wierszem): każdy wysłany
+  wiersz, z wyjątkiem tego, który zawiera `deleteMarker` listy, jest rozwiązywany przez swój podformularz z
+  wartościami formularza jako `__parent__`, a następnie walidowany. Dotyczy to też list zagnieżdżonych, w których
+  `__parent__.__parent__` sięga formularza. Wysyłaj zwykłe wiersze, czyli surowe wartości pól
+  podformularza. Błędne wiersze są wymieniane dla każdego pola listy w `rowErrors`
+  (`vms[1].disks[0].size (missing)` w komunikacie). Przyjmowanych jest najwyżej 500 wierszy na wywołanie,
+  łącznie na wszystkich poziomach.
+- Enum pozostawiony na `__auto__` nigdy nie jest wypełniany pierwszą opcją; wywołujący musi wybrać.
+- Każde żądanie MCP tworzy jeden wpis w dzienniku audytu (akcja „Żądanie MCP (agent AI)”); samo
+  zadanie jest zapisywane pod użytkownikiem, jak każde inne uruchomienie.
diff --git a/i18n/pl/_integrate/mcp/setup.md b/i18n/pl/_integrate/mcp/setup.md
new file mode 100644
index 0000000..7a5e540
--- /dev/null
+++ b/i18n/pl/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Konfiguracja
+parent: Serwer MCP
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Konfiguracja
+{: .no_toc }
+
+Włączenie serwera i uwierzytelnienie klienta
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Włączanie
+
+Ustaw [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) na `1` albo włącz go w **Ustawienia > Połączenia > MCP**
+(zobacz [Strona MCP](#the-mcp-page)). Przełącznik zmieniony na stronie ustawień obowiązuje od razu, bez restartu. Dopóki jest
+wyłączony, endpoint odpowiada `404`. Endpoint to:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Używa bezstanowego Streamable HTTP ze zwykłymi odpowiedziami JSON, więc `GET` i `DELETE` zwracają 405.
+
+---
+
+## Ograniczanie tego, co mogą agenci
+
+Dwa kolejne przełączniki zawężają serwer MCP dla każdego klienta. Podobnie jak `ENABLE_MCP` obowiązują bez restartu:
+
+| Zmienna | Przy `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | Serwer nie oferuje żadnego z narzędzi, które uruchamiają, planują lub zmieniają (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), i odrzuca je. Agenci mogą wyświetlać, czytać i wypełniać formularze, czytać harmonogramy i zapisane zadania oraz śledzić zadania, ale niczego nie uruchamiają ani nie zmieniają: to bezpieczny sposób na wypróbowanie agenta. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Agenci widzą tylko formularze z ustawionym `enableForChat: true`, czyli tę samą listę co [asystent czatu](../chat/). Każdy inny formularz i każde jego zadanie odpowiada jak nieznalezione. |
+
+Oba są domyślnie wyłączone: agenci widzą każdy formularz, na który pozwalają role użytkownika, i mogą go uruchamiać.
+
+---
+
+## Strona MCP
+
+**Ustawienia > Połączenia > MCP** zawiera ustawienia serwera MCP w dwóch kartach.
+
+- **Ogólne** ma trzy przełączniki, `ENABLE_MCP`, `MCP_READ_ONLY` i `MCP_CHAT_FORMS_ONLY`, zapisywane przyciskiem **Zapisz**. Dwa
+  pozostałe można zmieniać tylko wtedy, gdy serwer MCP jest włączony.
+- **Konfiguracja klienta** pokazuje **Punkt końcowy**, z przyciskiem do skopiowania, oraz gotową konfigurację dla **Claude Code**
+  (`.mcp.json` lub polecenie `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, który pyta
+  o token przy pierwszym uruchomieniu serwera) i **Codex** (`~/.codex/config.toml`, z tokenem w zmiennej środowiskowej
+  `ANSIBLEFORMS_TOKEN`). Każda ma swój przycisk kopiowania; zastąp `<your-token>` własnym tokenem, utworzonym
+  przez link **Utwórz token**.
+
+Punkt końcowy jest budowany z adresu URL aplikacji (**Ustawienia > URL**), gdy jest ustawiony, a w przeciwnym razie z adresu przeglądarki.
+
+---
+
+## Uwierzytelnianie
+
+Każde żądanie wymaga tokenu dostępu AnsibleForms:
+
+```
+Authorization: Bearer <token>
+```
+
+Uzyskaj go w zwykły sposób (`POST /api/v2/auth/login` lub przepływy OIDC / Entra ID) i
+odświeżaj przez `POST /api/v2/token`. Celowo **nie ma narzędzia logowania**: hasło przekazane jako
+argument narzędzia trafiłoby do kontekstu modelu językowego i do historii czatu.
+
+Role użytkownika muszą też zezwalać na serwer MCP, przez [opcję roli](../config/roles.html) `allowMcp`. Gdy żadna rola
+użytkownika jej nie ustawia, przyjmuje wartość `allowChat`, która jest domyślnie włączona. Użytkownik, któremu odmówiono dostępu, dostaje `403` na każde żądanie.
+
+- **Backend czatu** sam loguje użytkownika, przechowuje token odświeżania i przekazuje token
+  dostępu przy każdym wywołaniu MCP.
+- **Klient IDE** potrzebuje tokenu, który żyje wystarczająco długo, aby skonfigurować go raz. Mając rolę
+  z opcją `allowApiTokens`, utwórz go w
+  [Profil > Tokeny API](../profile/api-token.html) albo zaloguj się z `?expiryDays=<n>` w
+  adresie URL logowania, aby uzyskać token ważny przez podaną liczbę dni.
+
+Aby połączyć agenta programistycznego za pomocą takiego tokenu:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Dodaj serwer z tokenem jako nagłówkiem:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Dodaj serwer do `~/.codex/config.toml`, z tokenem odczytywanym ze zmiennej środowiskowej:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Następnie ustaw zmienną przed uruchomieniem Codex:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/pl/_integrate/mcp/tools.md b/i18n/pl/_integrate/mcp/tools.md
new file mode 100644
index 0000000..c7069ef
--- /dev/null
+++ b/i18n/pl/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Narzędzia
+parent: Serwer MCP
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Narzędzia
+{: .no_toc }
+
+Narzędzia, których agent używa do wypełniania, zatwierdzania i ponownego uruchamiania formularzy
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Serwer MCP oferuje do 15 narzędzi. Sześć jest oferowanych każdemu użytkownikowi; pozostałe zależą od opcji ról użytkownika, więc użytkownik
+bez danej opcji w ogóle nie dostaje jej narzędzi:
+
+| Narzędzie | Co robi | Oferowane przy |
+|---|---|---|
+| `list_forms` | Formularze, z których użytkownik może korzystać: nazwa, opis, kategorie i `enableForChat` (czy asystent czatu go oferuje). | zawsze |
+| `get_form` | Pełna definicja jednego formularza. Każde pole zawiera też `dynamic` (obliczane z wyrażenia lub zapytania) i `dependsOn` (pola, które odczytuje). | zawsze |
+| `resolve_field` | Oblicza formularz dla dotychczas wypełnionych wartości. Zobacz niżej. | zawsze |
+| `launch_job` | Uruchamia formularz z podanymi wartościami, dokładnie tak jak wysłanie z przeglądarki. Zwraca id zadania. | zawsze |
+| `relaunch_job` | Uruchamia zadanie ponownie ze zmienionymi niektórymi polami. Zobacz niżej. | zawsze |
+| `get_job` | Stan i wynik zadania (`tail` ogranicza wynik do ostatnich wierszy). | zawsze |
+| `plan_job` | Uruchamia formularz raz, później, jako użytkownik: to, co robi **Uruchom później (jednorazowo)** w formularzu. | `allowPlannedJobs` |
+| `create_schedule` | Tworzy harmonogram, cykliczny (`cron`) lub jednorazowy (`run_at`), jak na stronie **Harmonogramy**. | `allowScheduledJobs` |
+| `list_schedules` | Harmonogramy, które użytkownik może widzieć: wszystkie przy `allowScheduledJobs`, w przeciwnym razie zaplanowane przez niego uruchomienia. | `allowPlannedJobs` lub `allowScheduledJobs` |
+| `get_schedule` | Jeden harmonogram, z jego extra vars (te wyglądające na sekrety są maskowane) i wynikiem ostatniego uruchomienia. | `allowPlannedJobs` lub `allowScheduledJobs` |
+| `delete_schedule` | Anuluje zaplanowane uruchomienie lub usuwa harmonogram, który użytkownik może widzieć. | `allowPlannedJobs` lub `allowScheduledJobs` |
+| `list_stored_jobs` | [Zapisane zadania](../jobs/stored-jobs.html), które użytkownik może widzieć, bez ich wartości. | `allowStoredJobs` |
+| `get_stored_job` | Jedno zapisane zadanie z jego wartościami, według `id` albo według `form` i `name` spośród własnych zadań użytkownika. | `allowStoredJobs` |
+| `store_job` | Zapisuje wartości formularza pod nazwą, tak jak robi to **Zapisz** w formularzu. | `allowStoredJobs` |
+| `delete_stored_job` | Usuwa zapisane zadanie, które użytkownik może widzieć. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` i `plan_job` przyjmują `verbose: true`, aby uruchomić zadanie w trybie szczegółowym, co wymaga
+opcji roli `allowVerboseMode`. Przy [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) narzędzia, które uruchamiają, planują lub
+zmieniają (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` i `delete_stored_job`),
+nie są oferowane.
+
+Nie ma narzędzia do uruchamiania dowolnego wyrażenia, zapytania, playbooka ani extravars. Wyrażenia
+i zapytania działają zawsze tylko tak, jak definiuje je formularz.
+
+[Asystent czatu](../chat) również korzysta z tych narzędzi, z przyciskiem **Uruchom** zamiast `launch_job`.
+
+---
+
+## Wypełnianie formularza
+
+Wywołaj `resolve_field` z nazwą formularza i dotychczasowymi wartościami, a potem ponownie po każdej odpowiedzi. Przechodzi ono przez
+pola w kolejności zależności i dla każdego podaje:
+
+- `status`: `resolved`, `waiting` (z `waitingFor`), `hidden` lub `error` (pole wraca do swojej wartości domyślnej);
+- `value`, `default` oraz, dla pól wyboru, `options` (najwyżej `maxOptions`, domyślnie 200);
+- `needsInput`: wymagane pole bez wartości lub pole wyboru wciąż na `__auto__`;
+- `validationErrors`: reguły, które wartość narusza, jako `[{type, description}]`, z komunikatem przeglądarki.
+
+Dla całego formularza `missing` i `invalid` wymieniają, co jeszcze trzeba poprawić; `launch_job` go odrzuca, dopóki `complete` nie ma wartości true.
+
+Walidacja to własny kod przeglądarki, wspólny z [walidacją przy uruchomieniu](../launch-validation). Pola ukryte nie są
+walidowane, a puste pole opcjonalne jest prawidłowe.
+
+---
+
+## Harmonogramy i zaplanowane uruchomienia
+
+`plan_job` przyjmuje te same `form`, `values` i `expectedPayloadHash` co `launch_job`, wraz z `name` dla uruchomienia i `run_at`, czyli
+czasem ISO 8601 z przesunięciem lub `Z` (`2026-10-15T22:00:00+02:00`); czas bez strefy jest odrzucany. Wartości są rozwiązywane
+i walidowane od razu, a następnie sprawdzane ponownie w chwili uruchomienia, tak jak w przypadku [zaplanowanego uruchomienia](../jobs/schedules.html#planned-runs) w
+przeglądarce. Odpowiedź podaje czas uruchomienia w UTC i według zegara aplikacji.
+
+`create_schedule` przyjmuje `form`, `name`, albo `cron` (pięć pól, na przykład `0 22 * * 1-5`), albo `run_at`, oraz
+`extraVars`, które otrzyma zadanie. Taki harmonogram działa jako `Schedule Service`, bez walidacji formularza; aby uruchomić formularz raz jako
+użytkownik, użyj `plan_job`. Nazwy harmonogramów są unikalne.
+
+---
+
+## Zapisane zadania
+
+Zapisane zadanie to wartości formularza zapisane pod nazwą; narzędzia działają na tych samych zapisanych zadaniach co przeglądarka.
+
+`list_stored_jobs` wyświetla własne zapisane zadania użytkownika albo zadania wszystkich dla użytkownika z `showSettings`, z ich nazwą, opisem,
+formularzem, datą utworzenia i wygaśnięcia. Zadanie oznaczone jako `usable` (własne zadanie użytkownika, z formularza, który może on uruchomić) można przekazać jako `storedJob`
+(`{ "id": 7 }` lub `{ "name": "..." }` spośród własnych zadań użytkownika z tego formularza) do `resolve_field`, `launch_job` lub `plan_job`: jego
+wartości są punktem wyjścia, a `values` są nakładane na nie. Pola haseł nie są zapisywane, więc podaj je w `values`.
+`launch_job` i `plan_job` z zapisanego zadania wymagają `expectedPayloadHash`, który zwróciło dla niego `resolve_field`, a
+`resolve_field` odrzuca `storedJob` razem z `subform`.
+
+`store_job` przyjmuje `form`, `name` unikalną wśród zapisanych zadań użytkownika z tego formularza, `values` oraz opcjonalnie
+`description` i `expires_at` (ISO 8601 z przesunięciem lub `Z`). Odpowiedź mówi, które pola haseł zostały pominięte.
+
+---
+
+## Przekazywanie wartości
+
+Przekaż `field`, aby rozwiązać tylko to pole i to, od czego zależy. Dla wiersza listy lub kroku kreatora przekaż `subform` (i
+opcjonalnie `parent`, wartości formularza nadrzędnego).
+
+Wysyłaj wartości tak, jak przechowuje je przeglądarka. Pole wyboru przyjmuje też częściowy rekord lub jego wartość `valueColumn`
+(`"vol1"`), a tablicę, gdy jest `multiple`. Pola obliczane ignorują wysłane wartości, chyba że są `editable`.
+
+---
+
+## Zatwierdzanie dokładnego ładunku
+
+Gdy formularz jest kompletny, `resolve_field` zwraca też to, co wyśle `launch_job`:
+
+- `modeledExtravars`: extravars po zastosowaniu `model`, `valueColumn` i `output`,
+  z zamaskowanymi polami haseł;
+- `credentials`: poświadczenia AnsibleForms, których użyje zadanie (nazwy, nie sekrety);
+- `payloadHash`: skrót SHA-256 nazwy formularza, rzeczywistych extravars i poświadczeń.
+
+Pokaż `modeledExtravars` operatorowi i przekaż zatwierdzony przez niego `payloadHash` do
+`launch_job` jako `expectedPayloadHash`. Uruchomienie ponownie rozwiązuje formularz i jest odrzucane,
+gdy ładunek się różni, na przykład dlatego, że zapytanie odpowiada teraz inaczej.
+`ansibleforms_user`, `__jobid__` i `__verbose__` są dodawane przy uruchomieniu i nie wchodzą do skrótu.
+
+`launch_job` sprawdza tylko ładunek. Edycja formularza, która nie zmienia ładunku, nie powoduje odrzucenia uruchomienia.
+Każda odpowiedź `resolve_field` zawiera też `formFingerprint`, skrót SHA-256 definicji formularza: aby odrzucić
+uruchomienie po jakiejkolwiek edycji formularza, porównaj go samodzielnie przed wywołaniem `launch_job`, tak jak robi to przycisk
+**Uruchom** asystenta czatu.
+
+---
+
+## Ponowne uruchamianie ze zmianami
+
+`relaunch_job` przyjmuje `id` zadania i `values`: tylko pola do zmiany, jako surowe wartości.
+`values` jest nakładane na wartości, z którymi zadanie zostało pierwotnie uruchomione, a wynik jest
+rozwiązywany i walidowany dokładnie tak jak przez `launch_job`, łącznie z wierszami list, a następnie uruchamiany jako
+nowe zadanie przez Ciebie (`ansibleforms_user` to Ty, a nie pierwotny zgłaszający). Pliki przesłane w
+pierwotnym zadaniu są używane ponownie.
+
+Bez `values` jest to ponowne uruchomienie **tak, jak zadanie działało**: jego zapisane extravars są odtwarzane na
+serwerze, łącznie z hasłami (podgląd je maskuje). Jeśli jednak formularz podlega walidacji przy uruchomieniu
+`enforce`, ponowne uruchomienie przechodzi tę samą kontrolę co ponowne uruchomienie ze
+zmianami.
+
+**Hasła nigdy nie są zapisywane razem z wartościami pól**, więc ponowne uruchomienie, które przechodzi
+kontrolę, jest odrzucane, gdy formularz pokazuje pole hasła, na najwyższym poziomie lub w wierszu listy
+(`unsupported`, z `passwordFields`). Pole hasła ukryte przez swoje zależności nie
+blokuje ponownego uruchomienia. Zobacz [Walidacja przy uruchomieniu](../launch-validation).
+
+Najpierw wywołaj je z `preview: true`: zwraca `modeledExtravars` (z zamaskowanymi hasłami),
+`credentials` i `payloadHash` bez uruchamiania. Potwierdź je z użytkownikiem, a potem wywołaj
+ponownie z `expectedPayloadHash`. Obowiązują te same uprawnienia co przy ponownym uruchomieniu w przeglądarce:
+formularz musi pozwalać na ponowne uruchomienie, a Twoje role potrzebują opcji `allowJobRelaunch`.
+Zadania bez zapisanych danych formularza (uruchomionego, zanim istniało ponowne uruchamianie) ani formularza typu kreator nie można
+uruchomić ponownie ze zmianami.
+
+API REST oferuje to samo przez `POST /api/v2/job/{id}/relaunch` z treścią
+`{ "values": { ... } }`; bez treści odtwarza zadanie tak, jak działało.
+
+---
+
+## Błędy
+
+Odrzucone wywołanie to błąd narzędzia, którego ustrukturyzowana zawartość zawiera `code` i szczegóły:
+
+| Kod | Kiedy |
+|---|---|
+| `form_incomplete` | `launch_job` lub `relaunch_job` na niekompletnym formularzu, z `missing`, `invalid`, `waiting`, `validationErrors` i `rowErrors` |
+| `payload_mismatch` | ładunek różni się od `expectedPayloadHash`, z oboma skrótami |
+| `access_denied` | role użytkownika nie dają dostępu do formularza, zadania, harmonogramu lub zapisanego zadania albo do trybu szczegółowego, lub serwer jest w trybie tylko do odczytu |
+| `not_found` | nie ma takiego formularza, podformularza ani zadania |
+| `unsupported` | formularz typu kreator, sam podformularz, pole pliku lub `relaunch_job`, które wymagałoby widocznego pola hasła |
+| `no_form_data` | `relaunch_job` ze zmianami dla zadania, które nie zapisało wartości formularza, na przykład uruchomionego przez harmonogram; zamiast tego uruchom je ponownie bez zmian |
+| `invalid_request` | żądanie, które serwer odrzuca jako nieprawidłowe |
+| `internal_error` | wszystko inne |
diff --git a/i18n/pl/_introduction/concepts.md b/i18n/pl/_introduction/concepts.md
new file mode 100644
index 0000000..094c1fc
--- /dev/null
+++ b/i18n/pl/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Pojęcia
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Pojęcia
+{: .no_toc }
+
+Terminy używane w tej dokumentacji, każdy z linkiem do swojej strony
+{: .fs-6 .fw-300 }
+
+---
+
+## Słowniczek
+
+Terminy używane w tej dokumentacji:
+
+| Termin | Znaczenie |
+|---|---|
+| **[Formularz](forms/)** | Definicja YAML, która zbiera dane wejściowe i uruchamia playbook, szablon lub workflow |
+| **[Pole formularza](formfields/)** | Jedno pole wejściowe formularza, na przykład `text`, `enum` lub `checkbox`; jego wartość staje się extravar |
+| **[Kategoria](config/categories.html)** | Grupa w drzewie formularzy wyświetlanym na stronie Formularze, zdefiniowana w `config.yaml` |
+| **[Rola](config/roles.html)** | Zbiór użytkowników i grup; formularz wymienia role, które mogą go widzieć i uruchamiać, `default` oznacza wszystkich |
+| **[Wyrażenie](expressions/)** | JavaScript, który oblicza wartość pola, w przeglądarce (`runLocal: true`) lub na serwerze |
+| **[Extravars](formfields/)** | Zmienne wysyłane do playbooka lub szablonu, budowane z wartości pól |
+| **[Poświadczenie](expressions/credentials.html)** | Zapisane dane logowania, zaszyfrowane kluczem `ENCRYPTION_SECRET`: użytkownik i hasło (oraz host, port, baza danych), a od wersji 7.3.0 także adres i sekrety katalogu LDAP, dostawcy SSO, runnera lub HashiCorp Vault |
+| **[Magazyn sekretów](secret-stores/)** | Połączenie z HashiCorp Vault lub CyberArk, które dostarcza użytkownika i hasło poświadczenia |
+| **[Zadanie](gui/forms-and-jobs.html)** | Jedno uruchomienie formularza, z jego stanem, extravars i wynikiem, przechowywane w historii zadań |
+| **[Runner](runners.html)** | Miejsce, w którym działa zadanie, dodawane w **Połączenia > Runnery**: `rte` dla playbooków, `awx` (AWX lub odmiana `aap` albo `ascender`), `semaphore`, `rundeck` lub `jenkins` dla szablonów i jobów. Formularz wybiera go przez `runner:` albo działa na domyślnym runnerze `rte` (playbooki) lub `awx` (szablony) |
+| **[RTE](rte/)** | Środowisko uruchomieniowe (runtime environment): serwer AnsibleForms uruchomiony z `AF_ROLE=rte` we własnym kontenerze, obok pythona i ansible, który uruchamia playbooki runnera typu `rte` |
+| **[Punkt zatwierdzenia](forms/approval.html)** | Wstrzymanie zadania do chwili, gdy użytkownik z rolą zatwierdzającą je zatwierdzi lub odrzuci |
+| **[Workflow](workflows/)** | Graf playbooków, zatwierdzeń i innych workflow połączonych przy sukcesie, przy błędzie lub zawsze, w składni AWX |
+| **[Formularz wieloetapowy](forms/multistep.html)** | Przestarzały od wersji 7: formularz, który uruchamia kolejno kilka playbooków lub szablonów; zastępuje go workflow |
+| **[Kanał powiadomień](notification-channels.html)** | Serwer pocztowy, webhook Slacka lub Teams, czat Telegrama albo webhook, do którego trafiają powiadomienia i prośby o zatwierdzenie |
+| **[Projektant](designer/)** | Edytor w przeglądarce dla formularzy, playbooków, inwentarzy i workflow, z którego korzysta jedna osoba naraz |
+| **[Podformularz](forms/subform.html)** | Zestaw pól wielokrotnego użytku, który opisuje wiersze pola `list` lub obiekt pola `yaml` |
+| **[config.yaml](config/)** | Plik z kategoriami, rolami i stałymi; formularze są we własnych plikach |
+| **[Config seed](seed/)** | Plik YAML (`CONFIG_SEED_PATH`), który deklaruje obiekty administracyjne, na przykład runnery i poświadczenia |
+| **[Folder trwały](customization/paths.html)** | Folder z plikami, które AnsibleForms musi zachować między restartami i aktualizacjami |
diff --git a/i18n/pl/_introduction/gui/administration.md b/i18n/pl/_introduction/gui/administration.md
new file mode 100644
index 0000000..3284a6f
--- /dev/null
+++ b/i18n/pl/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Administracja
+parent: Przegląd interfejsu
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Administracja
+{: .no_toc }
+
+Menu Ustawienia: system, wygląd, dostęp, połączenia i dzienniki
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Menu Ustawienia
+
+**Ustawienia** w nagłówku otwierają strony administracyjne, pogrupowane w menu po lewej w sekcjach **System**, **Wygląd**,
+**Dostęp**, **Połączenia** i **Dzienniki**. Każda pozycja jest widoczna tylko dla użytkownika z opcją roli, której wymaga jej strona:
+`allowBackupOps` dla **Kopie zapasowe**, `showLogs` dla **Dziennik serwera** i `showSettings` dla wszystkich pozostałych stron.
+Od wersji 7.3.0 trzy opcje otwierają część z nich bez reszty:
+
+| Opcja roli | Otwiera |
+|---|---|
+| `showAppearanceSettings` | Strony **Wygląd** |
+| `showConnectionsSettings` | Strony **Połączenia**, z wyjątkiem **Syslog**; repozytoria, magazyny sekretów i chronione poświadczenia może zmieniać tylko administrator |
+| `showAuditLog` | **Dziennik audytu** |
+
+Opcje ról opisuje strona [Role](../config/roles.html#role-options).
+
+---
+
+## Listy i strony rekordów
+
+Od wersji 7.3.0 listy ustawień i strony rekordów mają wspólny układ, z elementami sterującymi w osobnym wierszu pod tytułem:
+
+| Element | Jak działa |
+|---|---|
+| Pole wyszukiwania | Pierwsze w tym wierszu na każdej stronie ustawień i stronie rekordu. Słowo zawęża od razu wszystkie karty: pasujące pola, wiersze lub linie są pokazywane pod nazwą swojej karty |
+| Rozmiar strony | Tabela pokazuje tyle wierszy, ile mieści się na ekranie, dopóki nie zostanie wybrany rozmiar strony: 10, 20, 50 lub 100 |
+| Kolumny | Każda nazwana kolumna sortuje, a pusta komórka pokazuje `–` |
+| Pola wyboru | Wiersze mają je tylko tam, gdzie z zaznaczonymi wierszami można coś zrobić, a menu wiersza (⋮) oferuje tę samą akcję |
+| Menu wiersza | Krótkie etykiety, takie jak **Edytuj** i **Usuń**. Lista z kolumną **Włączony** ma ją na pierwszym miejscu i w menu każdego wiersza oferuje **Włącz** lub **Wyłącz**, w zależności od stanu |
+
+Listy z kolumną **Włączony** to dostawcy SSO, katalogi LDAP, runnery, harmonogramy, kanały
+powiadomień, serwery syslog, ogłoszenia, etykiety i wersje zastrzeżenia.
+
+---
+
+## System
+
+Sama instancja: jej ustawienia, jej stan i jej kopie zapasowe.
+
+| Strona | Do czego służy |
+|---|---|
+| **Ogólne** | Zmienne środowiskowe, w kartach od Konfiguracja do Rejestrowanie. Zobacz [Zmienne środowiskowe](../customization/). |
+| **Stan** | Kondycja instancji i systemów, od których zależy, w kartach Testy i Informacje. Zobacz [Monitorowanie](../production/monitoring.html). |
+| **Kopie zapasowe** | Tworzenie, przywracanie i usuwanie kopii zapasowych bazy danych, config.yaml i formularzy. Zobacz [Kopie zapasowe](../production/backups.html). |
+
+![Ustawienia > Ogólne, karta Konfiguracja](../assets/screenshots/settings.jpg)
+
+### Kopie zapasowe
+
+Lista kopii zapasowych, nocnych i ręcznych: **Dodaj kopię zapasową** tworzy ją od razu, a menu wiersza zawiera **Pokaż kopię zapasową**, **Przywróć** i **Usuń**.
+
+![Ustawienia > Kopie zapasowe](../assets/screenshots/backups.jpg)
+
+### Przywracanie
+
+**Przywróć** pokazuje, co zawiera kopia zapasowa, a następnie ją przywraca; opcja **Utwórz nową kopię zapasową przed przywróceniem (zalecane)** jest domyślnie zaznaczona.
+
+![Przywracanie kopii zapasowej](../assets/screenshots/restore.jpg)
+
+---
+
+## Wygląd
+
+Jak instancja wygląda dla wszystkich i jakie komunikaty wyświetla.
+
+| Strona | Do czego służy |
+|---|---|
+| **Wartości domyślne** | Motyw, język, widok formularzy, strefa czasowa i format daty użytkowników, którzy niczego nie wybrali. Zobacz [Wartości domyślne](../appearance/defaults.html). |
+| **Nazwa** | Nazwa na karcie przeglądarki i na stronie logowania. Zobacz [Nazwa](../appearance/name.html). |
+| **Logo** | Twoje własne logo w nagłówku. Zobacz [Logo](../appearance/logo.html). |
+| **Ikona** | Twoja własna ikona na karcie przeglądarki. Zobacz [Ikona](../appearance/icon.html). |
+| **Linki** | Link do Projektanta oraz Twoje własne linki i menu w nagłówku. Zobacz [Linki](../appearance/links.html). |
+| **Etykiety** | Etykiety obok logo, na przykład PRODUCTION i EU. Zobacz [Etykiety](../appearance/labels.html). |
+| **Ogłoszenia** | Komunikaty pod nagłówkiem, każdy od swojego początku do końca. Zobacz [Ogłoszenia](../announcements.html). |
+
+---
+
+## Dostęp
+
+Kto może się zalogować i co może robić po zalogowaniu.
+
+| Strona | Do czego służy |
+|---|---|
+| **Zastrzeżenie** | Warunki, które każdy użytkownik akceptuje raz, i kto zaakceptował którą wersję. Zobacz [Zastrzeżenie](../disclaimer.html). |
+| **Użytkownicy** | Użytkownicy lokalni oraz z LDAP i jednokrotnego logowania. Zobacz [Użytkownicy i grupy](../users-and-groups.html). |
+| **Grupy** | Grupy lokalne oraz z LDAP i jednokrotnego logowania. Zobacz [Użytkownicy i grupy](../users-and-groups/local-group.html). |
+| **Role** | Role z config.yaml: kto je ma i na co pozwalają. Zobacz [Role](../config/roles.html). |
+| **LDAP** | Logowanie przez katalog LDAP lub Active Directory. Zobacz [LDAP](../authentication/ldap.html). |
+| **SSO** | Jednokrotne logowanie przez dostawców Entra ID lub OpenID Connect. Zobacz [Uwierzytelnianie](../authentication/). |
+
+![Dostęp > LDAP, główny katalog](../assets/screenshots/ldap.jpg)
+
+---
+
+## Połączenia
+
+Systemy, z którymi łączy się AnsibleForms, i dane, którymi się w nich loguje.
+
+| Strona | Do czego służy |
+|---|---|
+| **Repozytoria** | Repozytoria git, z których pochodzą formularze i playbooki. Zobacz [Repozytoria git](../repositories/). |
+| **Poświadczenia** | Konta i sekrety, których używają formularze, playbooki i połączenia. Zobacz [Poświadczenia](../credentials.html). |
+| **Magazyny sekretów** | HashiCorp Vault i CyberArk, z których można odczytywać poświadczenia. Zobacz [Magazyny sekretów](../secret-stores/). |
+| **Runnery** | Miejsca, w których działają zadania: kontenery RTE dla playbooków oraz AWX i podobne dla szablonów. Zobacz [Runnery](../runners.html). |
+| **SSH** | Para kluczy, którą aplikacja łączy się z git, oraz znane hosty. Zobacz [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Powiadomienia** | Serwery SMTP, Slack, Microsoft Teams, Telegram i webhooki. Zobacz [Kanały powiadomień](../notification-channels.html). |
+| **Asystent czatu** | Dostawca AI asystenta czatu. Zobacz [Asystent czatu](../chat/). |
+| **MCP** | Serwer MCP dla agentów AI. Zobacz [MCP](../mcp/). |
+| **Syslog** | Serwery syslog, które odbierają dziennik serwera, dziennik audytu lub oba. Zobacz [Syslog](../production/logs.html#syslog). |
+
+![Połączenia > Poświadczenia, karta Połączenie poświadczenia](../assets/screenshots/credentials.jpg)
+
+---
+
+## Dzienniki
+
+Co wydarzyło się na instancji.
+
+| Strona | Do czego służy |
+|---|---|
+| **Dziennik audytu** | Kto co zmienił i czy było to dozwolone, z filtrowaniem według użytkownika, akcji i wyniku. Zobacz [Ślad audytu](../production/logs.html#audit-trail). |
+| **Dziennik serwera** | Własny dziennik serwera, do rozwiązywania problemów. Zobacz [Dzienniki](../production/logs.html). |
+
+### Dziennik serwera
+
+Ostatnie wiersze dziennika, najnowsze na dole, śledzone na bieżąco w miarę zapisywania. Pole wyszukiwania je filtruje (wyrażenie
+regularne), **Wyczyść** opróżnia widok, a nie dziennik, a **Pobierz** zapisuje cały dziennik.
+
+![Dzienniki > Dziennik serwera](../assets/screenshots/logs.jpg)
+
+---
+
+## Dokumentacja API
+
+**Dokumentacja API** w menu pomocy (znak zapytania w nagłówku) prowadzi do Swagger UI API REST pod adresem `/api/v2/docs`.
+Zobacz [API](../api/).
+
+![Interfejs Swagger](../assets/screenshots/swagger.jpg)
diff --git a/i18n/pl/_introduction/gui/designer-and-git.md b/i18n/pl/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..f5f24dc
--- /dev/null
+++ b/i18n/pl/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Projektant i git
+parent: Przegląd interfejsu
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Projektant i git
+{: .no_toc }
+
+Edycja formularzy i przechowywanie ich w git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Wbudowany Projektant
+
+Edytuj formularze, kategorie, stałe, pliki zmiennych, playbooki, inwentarze i workflow, każdy jako YAML, za pomocą pól (Visual)
+i jako podgląd. Strony [Projektanta](../designer/) opisują każdą sekcję.
+
+![Wbudowany Projektant](../assets/screenshots/designer.jpg)
+
+---
+
+## Repozytoria git
+
+Zintegruj repozytoria Git, aby objąć formularze i playbooki kontrolą wersji.
+
+![Repozytoria git](../assets/screenshots/git.jpg)
+
+---
+
+## Edytor repozytorium git
+
+Edytuj i konfiguruj ustawienia integracji z repozytorium Git.
+
+![Edytor repozytorium git](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/pl/_introduction/gui/forms-and-jobs.md b/i18n/pl/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..438b2bc
--- /dev/null
+++ b/i18n/pl/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formularze i zadania
+parent: Przegląd interfejsu
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formularze i zadania
+{: .no_toc }
+
+Logowanie, pulpit, wypełnianie formularza i śledzenie jego zadań
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Logowanie
+
+Strona uwierzytelniania użytkownika, z obsługą uwierzytelniania lokalnego, LDAP, Entra ID i OIDC.
+
+![Logowanie](../assets/screenshots/login.jpg)
+
+---
+
+## Pulpit
+
+Główny pulpit wyświetla wszystkie dostępne formularze uporządkowane według kategorii.
+
+![Pulpit](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Formularz
+
+Przykładowy formularz z zewnętrznymi źródłami danych i dynamicznymi polami.
+
+![Przykładowy formularz](../assets/screenshots/form.jpg)
+
+---
+
+## Podgląd JSON formularza
+
+Podejrzyj ładunek JSON i dodatkowe zmienne przekazywane do Ansible, zanim uruchomisz zadanie.
+
+![Podgląd JSON formularza](../assets/screenshots/form-json.jpg)
+
+---
+
+## Uruchomione zadanie
+
+Wykonywanie playbooka Ansible w czasie rzeczywistym, z wynikiem na żywo.
+
+![Uruchomione zadanie](../assets/screenshots/run.jpg)
+
+---
+
+## Wynik zadania
+
+Pełny wynik wykonanego playbooka Ansible.
+
+![Wynik zadania](../assets/screenshots/job-output.jpg)
+
+---
+
+## Dziennik zadań
+
+Wszystkie zadania z ich stanem i czasami, filtrowane według stanu w menu po lewej.
+
+![Dziennik zadań](../assets/screenshots/job-log.jpg)
+
+---
+
+## Wiele etapów
+
+Zadanie wieloetapowe, z wynikiem każdego etapu pod zadaniem głównym. Formularze wieloetapowe są przestarzałe od wersji 7:
+zamiast nich [workflow](../workflows/) łączy playbooki, szablony i zatwierdzenia.
+
+![Formularz wieloetapowy](../assets/screenshots/multistep.jpg)
+
+---
+
+## Harmonogramy
+
+Planuj uruchamianie formularzy o określonych godzinach lub w określonych odstępach czasu. [Przykłady cron](../faq.html#which-cron-expressions-can-i-use) zawierają typowe
+wyrażenia i wyjaśniają, w jakiej strefie czasowej działa harmonogram.
+
+![Harmonogramy](../assets/screenshots/schedules.jpg)
diff --git a/i18n/pl/_introduction/gui/index.md b/i18n/pl/_introduction/gui/index.md
new file mode 100644
index 0000000..d9b2f7e
--- /dev/null
+++ b/i18n/pl/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Przegląd interfejsu
+nav_order: 3
+has_children: true
+has_toc: false
+description: Zrzuty ekranu i przegląd graficznego interfejsu użytkownika
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Przegląd interfejsu
+{: .no_toc }
+
+Wizualny przegląd interfejsu webowego AnsibleForms, od pulpitu po zaawansowane funkcje administracyjne.
+{: .fs-6 .fw-300 }
+
+---
+
+Dla każdego użytkownika i administratora: widoki interfejsu webowego, pogrupowane według tego, co się w nich robi.
+
+---
+
+## W tej sekcji
+
+Każda grupa widoków ma własną stronę:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Formularze i zadania](forms-and-jobs.html) | Logowanie, pulpit, wypełnianie formularza i śledzenie jego zadań |
+| [Projektant i git](designer-and-git.html) | Edycja formularzy i przechowywanie ich w git |
+| [Administracja](administration.html) | Menu Ustawienia: system, wygląd, dostęp, połączenia i dzienniki |
+| [Ustawienia osobiste](personal-settings.html) | Twój profil i ciemny motyw |
diff --git a/i18n/pl/_introduction/gui/personal-settings.md b/i18n/pl/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..54652be
--- /dev/null
+++ b/i18n/pl/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Ustawienia osobiste
+parent: Przegląd interfejsu
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Ustawienia osobiste
+{: .no_toc }
+
+Twój profil i ciemny motyw
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Profil użytkownika
+
+Twoje konto, preferencje, hasło, uprawnienia i tokeny API.
+
+Zobacz [Twój profil](../profile).
+
+![Profil użytkownika](../assets/screenshots/profile.jpg)
+
+---
+
+## Tryb ciemny
+
+AnsibleForms obsługuje tryb ciemny, który mniej męczy wzrok.
+
+![Tryb ciemny](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/pl/_introduction/how-it-works.md b/i18n/pl/_introduction/how-it-works.md
new file mode 100644
index 0000000..11e42e0
--- /dev/null
+++ b/i18n/pl/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Jak to działa
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Jak to działa
+{: .no_toc }
+
+Elementy instalacji, co dzieje się przy uruchomieniu i gdzie przechowywane są dane
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Architektura
+
+AnsibleForms to serwer Node.js, który udostępnia aplikację webową i API REST, z bazą danych MySQL. Odczytuje formularze
+z plików YAML i sam niczego nie uruchamia: każde zadanie przekazuje do [runnera](runners.html). Playbook trafia do jednego z Twoich kontenerów RTE
+(runtime environment), który uruchamia `ansible-playbook`, a szablon lub job trafia do AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Architektura AnsibleForms</title>
+<desc id="afd-desc">Przeglądarka i opcjonalny klient MCP komunikują się z serwerem AnsibleForms. Serwer przechowuje dane w MySQL i w folderze trwałym oraz łączy się ze źródłami danych, magazynami sekretów, repozytoriami git, dostawcami logowania, kanałami powiadomień, serwerami syslog i opcjonalnym dostawcą modelu. Jego runnery przekazują każdy playbook do jednego z jednego lub kilku kontenerów RTE, każdy przez własny WebSocket; kontenery uruchamiają ansible-playbook i odsyłają wynik do serwera, a każdy szablon lub job trafia do AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Przeglądarka</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">formularze, projektant,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">zadania, czat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">Klient MCP</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">opcjonalny</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">Serwer AnsibleForms</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Aplikacja webowa i API REST</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formularze, wyrażenia</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflow, harmonogramy</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">Serwer MCP (opcjonalny)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runnery</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">przekazują zadania runnerowi</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Źródła danych</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">bazy danych, API, pliki</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Magazyny sekretów</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Repozytoria git</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">formularze, playbooki, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Dostawcy logowania</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Powiadomienia</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">poczta, Slack, Teams, webhooki</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Serwery syslog</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">dziennik, ślad audytu</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Dostawca modelu</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">opcjonalny, asystent czatu</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Folder trwały</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, formularze, playbooki</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">zadania, użytkownicy,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">poświadczenia</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">Kontenery RTE</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">uruchamiają ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbooki,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">szablony, joby</text>
+</svg>
+</div>
+
+Każdy z elementów na diagramie ma własną rolę:
+
+| Element | Rola |
+|---|---|
+| **Przeglądarka** | Aplikacja webowa w Vue: formularze, [Projektant](gui/designer-and-git.html), historia zadań i ustawienia |
+| **Serwer AnsibleForms** | Przetwarza formularze, zapisuje zadania, uruchamia workflow i harmonogramy, przekazuje każde zadanie jego runnerowi i śledzi je, a także udostępnia [API REST](api/) |
+| **Runnery** | Miejsca, w których działają zadania, dodawane w **Połączenia > Runnery**: formularz wskazuje jeden przez `runner: <name>` albo używa domyślnego runnera swojego typu (zobacz [Runnery](runners.html)) |
+| **Kontenery RTE** | Jeden lub kilka kontenerów środowiska uruchomieniowego, czyli ten sam serwer uruchomiony z `AF_ROLE=rte`: każdy uruchamia `ansible-playbook` dla [formularzy ansible](forms/ansible.html), z bibliotekami pythona i kolekcjami ze swojego obrazu, i odsyła wynik oraz stan końcowy do serwera przez jeden WebSocket, bez poświadczeń do bazy danych (zobacz [Jak działa RTE](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runnery dla szablonów i jobów: [formularze AWX](forms/awx.html) uruchamiają szablon joba lub workflow, formularze [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) i [Jenkins](forms/jenkins.html) uruchamiają jeden z ich jobów, a serwer śledzi jego wynik |
+| **MySQL / MariaDB** | Przechowuje zadania i ich wyniki, użytkowników, poświadczenia i połączenia; odczytuje ją i zapisuje tylko serwer |
+| **Folder trwały** | Przechowuje `config.yaml`, pliki formularzy, playbooki, dzienniki i kopie zapasowe |
+| **Źródła danych** | Wypełniają pola: [zapytania do bazy danych](formfields/enum.html), [API REST](expressions/rest-apis.html), pliki i [inne funkcje](expressions/remote.html) |
+| **Magazyny sekretów** | Dostarczają użytkownika i hasło poświadczenia w chwili użycia, zobacz [Magazyny sekretów](secret-stores/) |
+| **Repozytoria git** | Utrzymują formularze, playbooki i `config.yaml` pod kontrolą wersji |
+| **Dostawcy logowania** | Logują użytkowników: [LDAP, Entra ID i OIDC](authentication/), obok użytkowników lokalnych |
+| **Kanały powiadomień** | Przenoszą [powiadomienia](forms/notifications.html) i prośby o zatwierdzenie: [poczta, Slack, Microsoft Teams, Telegram lub webhook](notification-channels.html) |
+| **Serwery syslog** | Odbierają dziennik i ślad audytu na bieżąco, w miarę zapisywania, zobacz [Syslog](production/logs.html#syslog) |
+| **Klient MCP, czat** | Opcjonalne, oba domyślnie wyłączone: [serwer MCP](mcp/) i [asystent czatu](chat/), który wymaga dostawcy modelu |
+
+Domyślnie jeden kontener uruchamia razem serwer, aplikację webową i pracę w tle, obok jednego RTE. Jeśli chcesz mieć kilka węzłów aplikacji za
+load balancerem, workera wykonującego pracę w tle i więcej RTE, zobacz [Skalowanie](production/scaling.html).
+
+### Z czego jest zbudowany
+
+Serwer i interfejs webowy są zbudowane z tych komponentów:
+
+| Część | Technologia |
+|---|---|
+| **Serwer** | Node.js i Express |
+| **Baza danych** | MySQL lub MariaDB |
+| **Interfejs webowy** | Vue 3, z Bootstrap 5 i Font Awesome |
+
+---
+
+## Co się dzieje, gdy uruchamiasz formularz
+
+Uruchomienie przechodzi przez te same kroki, niezależnie od tego, czy pochodzi z przeglądarki, czy z [API REST](api/jobs.html):
+
+1. **Wczytanie** : serwer wysyła tylko formularze, na które pozwalają [role](config/roles.html) użytkownika, i oblicza wyrażenia serwerowe
+2. **Wysłanie** : przeglądarka zamienia wartości pól na extravars i wysyła je do `POST /api/v2/job`
+3. **Sprawdzenie** : serwer ponownie wczytuje formularz dla ról użytkownika i, gdy włączona jest [walidacja przy uruchomieniu](launch-validation/), sprawdza wartości
+4. **Zapis** : zadanie jest zapisywane ze stanem `running`, a jego id jest dodawane do extravars jako `__jobid__`
+5. **Zatwierdzenie** : formularz z punktem [`approval`](forms/approval.html) czeka, aż osoba zatwierdzająca zaakceptuje zadanie
+6. **Poświadczenia** : w przypadku playbooka aplikacja (nigdy RTE) odczytuje poświadczenia formularza z bazy danych lub z [magazynu sekretów](secret-stores/)
+7. **Uruchomienie** : zadanie trafia do swojego runnera, tego, którego formularz wskazuje przez `runner:`, lub domyślnego dla swojego typu. W przypadku playbooka aplikacja wysyła zadanie do
+   jego RTE przez WebSocket tego RTE, z poświadczeniami zaszyfrowanymi dla niego, a RTE uruchamia `ansible-playbook` (zobacz [Jak działa RTE](rte/#how-the-rte-runs)),
+   natomiast AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins uruchamia szablon lub job. [Workflow](workflows/) uruchamia swoje węzły, każdy jako
+   osobne zadanie na własnym runnerze
+8. **Śledzenie** : serwer zapisuje wynik w bazie danych w miarę jego napływania, wysyłany przez RTE przez gniazdo w przypadku playbooka lub odczytywany z
+   pozostałych runnerów. Strona formularza odczytuje zadanie co dwie sekundy, a strona Zadania śledzi je na żywo, gdy serwer
+   ogłasza każdą zmianę
+9. **Zakończenie** : zadanie otrzymuje stan końcowy, a jego [`notifications`](forms/notifications.html) są wysyłane pocztą i do jego
+   [kanałów powiadomień](notification-channels.html), gdy formularz o to prosi
+
+---
+
+## Gdzie wszystko jest przechowywane
+
+AnsibleForms przechowuje swój stan w dwóch miejscach: w bazie danych MySQL i w folderze trwałym. Twórz kopie zapasowe obu.
+
+### W bazie danych
+{: .no_toc }
+
+Baza danych `AnsibleForms` jest tworzona przy pierwszym uruchomieniu (chyba że `ALLOW_SCHEMA_CREATION` ma wartość `0`) i przechowuje:
+
+* zadania, ich extravars i wyniki, harmonogramy i zapisane zadania
+* użytkowników lokalnych, grupy i tokeny API
+* poświadczenia, zaszyfrowane kluczem `ENCRYPTION_SECRET`, oraz połączenia z magazynami sekretów
+* runnery, kanały powiadomień (łącznie z pocztą), serwery syslog oraz ustawienia LDAP, SSO, repozytoriów i asystenta czatu
+* dziennik audytu
+
+### W folderze trwałym
+{: .no_toc }
+
+To `/app/dist/persistent` w obrazie i `server/persistent` przy instalacji ze źródeł; każda ścieżka ma własną [zmienną](customization/paths.html):
+
+| Ścieżka domyślna | Zmienna | Zawartość |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | Kategorie, role i stałe |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | Pliki formularzy, `.yaml` lub `.yml`, w razie potrzeby w podfolderach |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | Playbooki formularzy `ansible` i ich katalog roboczy |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Klony repozytoriów git |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | Kopie, które Projektant tworzy przed zapisem |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | Kopie zapasowe bazy danych |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | Pliki przesłane przez pola `file` |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` i `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | Certyfikat i klucz, gdy `HTTPS` ma wartość `1` |
+| `.env` | | Zmienne środowiskowe zapisane ze stron ustawień (chyba że `ALLOW_ENV_EDIT` ma wartość `0`) |
+
+Wygenerowany klucz SSH znajduje się w [`HOME_PATH`](customization/paths.html#env_HOME_PATH), domyślnie poza folderem trwałym.
diff --git a/i18n/pl/_introduction/prerequisites.md b/i18n/pl/_introduction/prerequisites.md
new file mode 100644
index 0000000..70ff085
--- /dev/null
+++ b/i18n/pl/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Wymagania wstępne
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Wymagania wstępne
+{: .no_toc }
+
+Co jest potrzebne przed instalacją AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Środowisko uruchomieniowe
+
+AnsibleForms działa jako kontener, jako usługi systemd bezpośrednio na serwerze lub, dla tych, którzy budują go samodzielnie, jako aplikacja Node.js:
+
+| Instalacja | Czego potrzebujesz |
+|---|---|
+| [Instalator](installation/installer.html) | Linux na amd64 lub arm64, `curl` lub `wget` i `sha256sum` oraz to, czego wymaga silnik, na którym instaluje (poniżej) |
+| [Natywnie](installation/native.html) | Uprawnień roota, systemd i obsługiwanego Linuksa (Ubuntu, Debian, RHEL i jego klony, SUSE); resztę instaluje instalator |
+| [Docker](installation/docker.html) | Docker lub Podman oraz własnego serwera MySQL |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose lub podman-compose; projekt uruchamia też MySQL |
+| [Kubernetes](installation/kubernetes.html) | Klastra, Helm 3 i StorageClass (lub wcześniej utworzonych PersistentVolumes) |
+| [Ze źródeł](installation/from-source.html) | Node.js 26 (co najmniej 24) z npm, Git oraz Ansible dla procesu RTE, który uruchamia playbooki |
+
+Obraz aplikacji, `ghcr.io/ansibleforms/ansibleforms`, zawiera Node.js i narzędzia wywoływane przez serwer (git, ssh, klienta mariadb i
+ytt), ale nie zawiera Pythona ani Ansible. Playbooki działają na RTE (runtime environment), drugim kontenerze z
+`ghcr.io/ansibleforms/ansibleforms-rte-full` lub z obrazu, który budujesz na bazie `ansibleforms-rte-core` (zobacz [Skalowanie](rte/)).
+Formularze, które tylko uruchamiają szablony w AWX, AAP, Ascender, Semaphore, Rundeck lub Jenkins, nie potrzebują RTE.
+
+---
+
+## Baza danych
+
+AnsibleForms przechowuje swoje zadania, użytkowników, poświadczenia i połączenia w MySQL 8 lub nowszym albo w MariaDB.
+
+Przy pierwszym uruchomieniu samo tworzy schemat `AnsibleForms`. Daj mu osobnego użytkownika bazy danych, z uprawnieniami tylko do tego schematu,
+a nie roota:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+To wszystko, czego potrzebuje: tworzy i aktualizuje schemat, wykonuje kopie zapasowe i, przy kilku workerach, kończy sesję tego, który przestał działać.
+Strona **Stan** i dziennik ostrzegają, gdy użytkownik ma uprawnienia do wszystkich baz danych. Węzły aplikacji i workery łączą się z tym
+użytkownikiem. RTE w trybie gniazda (wychodzącym lub przychodzącym, zobacz [Tryby](rte/modes.html)) nie przechowuje poświadczeń do bazy danych: łączy się z nią tylko RTE w trybie
+bazy danych, przestarzałym od wersji 7.3.0. Aby samodzielnie utworzyć schemat, ustaw [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) na `0`.
+Projekt Docker Compose i chart Helm (który używa `mysql:8.4`) uruchamiają bazę danych za Ciebie.
+
+---
+
+## Wymiarowanie
+
+Nie ma zmierzonych wymagań: obciążenie zależy głównie od tego, ile zadań działa jednocześnie i ile wyniku zapisują.
+Domyślne zasoby chartu Helm są rozsądnym punktem wyjścia dla małego zespołu:
+
+| Komponent | Requests | Limits | Wolumen |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB pamięci | 4 CPU, 4 GiB pamięci | 10 GiB |
+| MySQL | 0.5 CPU, 512 MiB pamięci | 2 CPU, 2 GiB pamięci | 10 GiB |
+
+Kontener aplikacji nie uruchamia żadnego playbooka. Każdy playbook to proces `ansible-playbook`, ze swoimi forkami, na RTE: dobierz CPU i
+pamięć każdego RTE do playbooków, które uruchamia jednocześnie, maksymalnie [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (domyślnie `10`), i uruchom więcej
+RTE, aby uruchamiać więcej. Zadania działające w AWX, AAP, Ascender lub na innych runnerach szablonów niewiele kosztują AnsibleForms.
+
+Wynik zadań jest domyślnie przechowywany w bazie danych bezterminowo. Na mocno obciążonej instancji ustaw [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS),
+aby baza danych nie rosła bez ograniczeń.
+
+---
+
+## Sieć
+
+Aplikacja i każde RTE nasłuchują na własnym porcie i otwierają połączenia wychodzące do systemów, z których korzystają Twoje formularze i ustawienia.
+
+### Ruch przychodzący
+{: .no_toc }
+
+Serwer nasłuchuje na porcie `8000` ([`PORT`](customization/server.html#env_PORT)), przez HTTP lub, gdy
+[`HTTPS`](customization/server.html#env_HTTPS) ma wartość `1`, przez HTTPS. Projekt Docker Compose publikuje go na porcie 443,
+a chart Helm udostępnia go przez service lub ingress. RTE również nasłuchuje na własnym `PORT`, ale wywołuje go tylko aplikacja:
+nie wystawiaj go do sieci publicznej. Wychodzące RTE w ogóle nie potrzebuje portu przychodzącego: samo łączy się z aplikacją na porcie aplikacji.
+
+### Ruch wychodzący
+{: .no_toc }
+
+Otwórz połączenia z AnsibleForms do systemów, których używasz:
+
+| Cel | Do czego służy |
+|---|---|
+| MySQL / MariaDB | Baza danych AnsibleForms (`DB_HOST`, `DB_PORT`, domyślnie `3306`) |
+| RTE | Łączenie się z przychodzącym RTE pod adresem jego runnera przez jeden WebSocket albo wywoływanie RTE w trybie bazy danych pod jego [`RTE_URL`](customization/server.html#env_RTE_URL), które wtedy samo łączy się z MySQL; wychodzące RTE łączy się zamiast tego z aplikacją (zobacz [Tryby](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Uruchamianie i śledzenie szablonów i jobów na [runnerach](runners.html), przez ich API HTTP(S) |
+| Zarządzane hosty | Playbooki łączą się z nimi z RTE, na przykład przez SSH lub WinRM |
+| LDAP, Entra ID, OIDC | Logowanie kontami z katalogu lub z jednokrotnego logowania (SSO) |
+| Serwery Git | Klonowanie i pobieranie repozytoriów, przez HTTPS lub SSH |
+| API REST i bazy danych | Źródła danych wyrażeń i zapytań w Twoich formularzach |
+| HashiCorp Vault, CyberArk | Odczytywanie poświadczeń z [magazynu sekretów](secret-stores/) |
+| Serwery pocztowe, Slack, Teams, Telegram, webhooki | Powiadomienia o zadaniach i prośby o zatwierdzenie, przez [kanały powiadomień](notification-channels.html) |
+| Dostawca modelu | [Asystent czatu](chat/), tylko gdy jest włączony |
+
+Aby ograniczyć, które hosty mogą wywoływać funkcje REST w wyrażeniach, zobacz
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) i
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Przeglądarka
+
+Aplikacja webowa jest przeznaczona dla aktualnych przeglądarek: Chrome lub Edge 111, Firefox 114, Safari 16.4 lub nowszych.
+Starsze przeglądarki nie są obsługiwane.
+
+---
+
+## Skalowanie
+
+Domyślnie jeden kontener AnsibleForms uruchamia razem aplikację webową i pracę w tle, obok jednego RTE.
+
+Aby obsłużyć więcej użytkowników, uruchom kilka węzłów aplikacji za load balancerem (`AF_ROLE=app`) obok workera (`AF_ROLE=worker`), który uruchamia
+harmonogramy, kopie zapasowe i pozostałą pracę w tle; naraz pracuje tylko jeden worker, a drugi czeka, aby przejąć jego rolę. Współdzielą one
+bazę danych, folder trwały, `ACCESS_TOKEN_SECRET` i `ENCRYPTION_SECRET`. Zobacz [Skalowanie](production/scaling.html). Uruchom więcej
+RTE, aby uruchamiać więcej playbooków jednocześnie: zobacz [Kilka RTE](rte/several.html).
diff --git a/i18n/pl/_introduction/what-is-ansibleforms.md b/i18n/pl/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..62e8680
--- /dev/null
+++ b/i18n/pl/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Czym jest AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# Czym jest AnsibleForms
+{: .no_toc }
+
+Formularze samoobsługowe przed Ansible i AWX, i kiedy ich potrzebujesz
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Co robi
+
+AnsibleForms stawia formularz webowy przed playbookiem, workflow albo szablonem lub jobem w AWX, AAP, Ascender, Semaphore, Rundeck
+lub Jenkins, dzięki czemu ludzie mogą uruchamiać automatyzację bez wiersza poleceń.
+
+Formularz zbiera dane wejściowe, sprawdza je, przekształca w extravars i uruchamia zadanie. Dane w formularzu mogą pochodzić z baz danych,
+API REST, plików i innych pól, a każde uruchomienie jest zapisywane w historii zadań wraz z wynikiem.
+
+---
+
+## Typowe zastosowania
+
+Zespoły używają AnsibleForms, aby przekazać rutynową automatyzację osobom, które jej potrzebują:
+
+* **Żądania samoobsługowe** : maszyna wirtualna, wolumen pamięci masowej, udział sieciowy lub konto użytkownika, wypełniane przez zgłaszającego
+* **Operacje pod nadzorem** : akcje z punktami zatwierdzenia, tak aby druga osoba je zaakceptowała, zanim zadanie się uruchomi
+* **Wybory oparte na danych** : listy rozwijane wypełniane z CMDB, bazy danych lub API REST, kaskadowo od jednego pola do następnego
+* **Zadania cykliczne** : formularze uruchamiane później lub według harmonogramu cron, za każdym razem z tymi samymi sprawdzonymi danymi
+* **Automatyzacja dla narzędzi i agentów** : API REST, serwer MCP i asystent czatu uruchamiają te same formularze
+
+---
+
+## AnsibleForms czy ankiety AWX?
+
+AWX, AAP i Ascender mają własne ankiety (surveys). Która opcja pasuje, zależy od tego, czego potrzebują osoby uruchamiające zadania.
+
+**Ankieta** wystarczy, gdy:
+
+* pytania są stałe: tekst, liczby, hasła i wybór ze statycznej listy
+* użytkownicy już pracują w AWX, AAP lub Ascender, a jego uprawnienia im odpowiadają
+* nie chcesz uruchamiać i utrzymywać kolejnej aplikacji i bazy danych
+
+**AnsibleForms** pomaga, gdy:
+
+* opcje do wyboru pochodzą z innego miejsca: z bazy danych, API REST, pliku lub innego pola (kaskadowe listy rozwijane)
+* dane wejściowe wymagają walidacji, struktury (listy, zagnieżdżone obiekty) lub obliczonych wartości, zanim trafią do playbooka
+* zadania wymagają punktów zatwierdzenia, harmonogramów lub workflow, który z jednego formularza łączy playbooki, szablony i zatwierdzenia
+* użytkownicy w ogóle nie powinni widzieć AWX albo uruchamiasz też playbooki bez AWX
+
+AnsibleForms uruchamia szablony AWX, AAP i Ascender, więc oba narzędzia działają razem: formularze zbierają i przygotowują dane wejściowe, a
+AWX nadal uruchamia zadania.
+
+---
+
+## Co dalej
+
+Pozostała część tej sekcji objaśnia poszczególne elementy przed instalacją:
+
+| Strona | Co obejmuje |
+|---|---|
+| [Jak to działa](how-it-works.html) | Architekturę, kroki uruchomienia i miejsca przechowywania danych |
+| [Przegląd interfejsu](gui/) | Zrzuty ekranu każdego widoku, od logowania po strony administracyjne |
+| [Pojęcia](concepts.html) | Terminy używane w tej dokumentacji |
+| [Wymagania wstępne](prerequisites.html) | Co jest potrzebne przed instalacją |
diff --git a/i18n/pl/_reference/faq.md b/i18n/pl/_reference/faq.md
new file mode 100644
index 0000000..e8f9cc8
--- /dev/null
+++ b/i18n/pl/_reference/faq.md
@@ -0,0 +1,1279 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Najczęściej zadawane pytania
+{: .no_toc }
+
+Typowe pytania i odpowiedzi dotyczące AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pierwsze kroki
+
+### Topologia wdrożenia: jeden kontener czy kilka węzłów
+
+Domyślnie jeden kontener AnsibleForms uruchamia aplikację webową i pracę w tle w jednym procesie, obok kontenera RTE, który
+uruchamia playbooki. Uruchamiaj go z polityką restartu (na przykład `restart: unless-stopped` w Dockerze) i twórz kopie zapasowe zarówno bazy danych, jak i
+wolumenu trwałego.
+
+Aby uruchomić kilka replik za load balancerem, podziel proces za pomocą `AF_ROLE`:
+
+- węzły `app` obsługują interfejs webowy i API: uruchom ich tyle, ile chcesz, każdy z tym samym `ACCESS_TOKEN_SECRET`
+- `worker` wykonuje pracę w tle: schemat i jego aktualizacje, config seed, harmonogramy, nocną kopię zapasową, synchronizację
+  repozytoriów i porządki. Naraz pracuje jeden worker, trzymając blokadę w bazie danych; drugi czeka i przejmuje pracę, gdy pierwszy się zatrzyma
+- kontenery `rte` uruchamiają playbooki: uruchom ich więcej, aby uruchamiać więcej playbooków jednocześnie
+
+Węzły aplikacji i worker współdzielą bazę danych, wolumen trwały i `ENCRYPTION_SECRET`. RTE w trybie gniazda (wychodzącym lub
+przychodzącym, zobacz [Tryby](rte/modes.html)) nie potrzebuje ani bazy danych, ani `ENCRYPTION_SECRET`. Asystent czatu wymaga sesji sticky, a
+każdy węzeł prowadzi własny dziennik. Zobacz [Skalowanie](production/scaling.html) i konfigurację
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Zarządzanie formularzami z wielu repozytoriów
+
+Formularze z każdego repozytorium Git z włączoną opcją **Używać do formularzy?** są scalane automatycznie; przy powtarzających się nazwach formularzy wygrywa
+pierwszy, a w dzienniku zapisywane jest ostrzeżenie. Trzymaj `config.yaml` tylko w jednym repozytorium. Zobacz [Repozytoria git](repositories/).
+
+### O repozytoriach
+
+AnsibleForms klonuje i pobiera repozytoria Git w ścieżce repozytoriów (`REPO_PATH`), zarządzane w **Ustawienia > Repozytoria**.
+Przełączniki w każdym repozytorium określają, co ono zawiera: konfigurację, formularze, playbooki lub pliki zmiennych. Zobacz [Repozytoria git](repositories/).
+
+### Walidacja plików formularzy w VS Code
+
+Dodaj nagłówek schematu do plików YAML formularzy, aby uzyskać walidację na żywo i autouzupełnianie w VS Code.
+
+Zainstaluj [rozszerzenie YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) i dodaj ten komentarz jako **pierwszy wiersz** każdego pliku formularza:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Działa to zarówno dla plików z jednym formularzem (słownik YAML), jak i z wieloma formularzami (lista YAML):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code podczas pisania podświetla nieznane właściwości, brakujące wymagane pola i nieprawidłowe typy.
+
+---
+
+## Zarządzanie zadaniami
+
+### Ponowne uruchamianie zadania z wypełnionymi danymi
+
+Przycisk ponownego uruchomienia otwiera formularz wypełniony wartościami z wcześniejszego zadania; pola haseł nigdy nie są zapisywane.
+Wymaga opcji roli `allowJobRelaunch`, a formularz może to wyłączyć przez `allowRelaunch: false`. Zobacz [Ponowne uruchamianie zadania](jobs/actions.html#relaunch-a-job).
+
+### Plik dziennika zadania
+
+Śledzenie postępu przez plik dziennika danego zadania (v6.1.2).
+
+AnsibleForms może wyświetlać **plik dziennika danego zadania** obok wyniku Ansible. Pozwala to śledzić postęp długo działających modułów własnych, które w przeciwnym razie nie dawałyby podczas wykonywania żadnej widocznej informacji zwrotnej.
+
+{: .note }
+> Ta funkcja działa tylko dla playbooków uruchamianych na RTE. Szablony i joby w AWX, AAP, Ascender, Semaphore, Rundeck lub
+> Jenkins nie mają pliku dziennika.
+
+**Jak to działa:**
+- Podczas działania zadania RTE obserwuje plik dziennika w znanej ścieżce wewnątrz folderu playbooka
+- Co dwie sekundy, jeśli plik się zmienił, RTE kopiuje jego zawartość do zadania, i jeszcze raz, gdy playbook się kończy
+- Plik dziennika jest wyświetlany w sekcji **Plik dziennika** wyniku zadania, z numeracją jak wiersze wyniku: znacznik czasu i poziom wiersza dziennika (ERROR, WARNING, INFO, DEBUG) są odczytywane i kolorowane tak jak w wyniku, a kolory ANSI są obsługiwane
+
+**Konwencja ścieżki pliku dziennika:**
+
+Plik dziennika musi być zapisywany w tej ścieżce:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms automatycznie przekazuje `__jobid__`**, więc możesz złożyć ścieżkę w playbooku bez dodatkowej konfiguracji:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Przekaż tę zmienną do każdej roli lub modułu własnego, który ma zapisywać postęp do pliku.
+
+**Obowiązki twórcy playbooka / modułu:**
+- **Utworzyć** plik dziennika (i jego katalog `.joblogs/`) na początku operacji
+- **Zapisywać** sensowne komunikaty o postępie w miarę trwania operacji
+
+RTE usuwa plik, gdy playbook się kończy, a ostatnia zawartość zostaje zapisana w zadaniu.
+
+**Kolorowanie ANSI jest obsługiwane.**  
+Standardowe sekwencje ucieczki ANSI (na przykład `\033[92m` dla zielonego i `\033[91m` dla czerwonego) w komunikatach dziennika są wyświetlane w interfejsie jako kolory, więc stany sukcesu, ostrzeżenia i błędu można odróżnić na pierwszy rzut oka.
+
+**Typowy przypadek użycia:**  
+Własny moduł Ansible w Pythonie, który wykonuje długą sekwencję wywołań API lub operacji na danych (na przykład workflow DR SnapMirror), może dopisywać do pliku dziennika jeden wiersz na każdy krok. Operator obserwujący zadanie w AnsibleForms widzi wtedy postęp na żywo w sekcji Plik dziennika, ponieważ strona zadania je śledzi.
+
+### Jobid
+
+Przekazywanie ID bieżącego zadania.
+
+AnsibleForms automatycznie wysyła ID bieżącego zadania w extravars jako `__jobid__`; konfiguracja nie jest wymagana.
+
+### Informacje o użytkowniku
+
+Przekazywanie bieżącego użytkownika.
+
+AnsibleForms automatycznie wysyła informacje o użytkowniku w extravars jako `ansibleforms_user`; konfiguracja nie jest wymagana.
+
+Możesz wybrać, ile z tych informacji jest wysyłane. `EXTRAVARS_USER_FIELDS` przyjmuje listę kluczy najwyższego poziomu oddzielonych przecinkami
+(`username,email,type`) lub `none`, aby nic nie wysyłać; formularz może to nadpisać własną właściwością `userExtravars`.
+Domyślnie wysyłany jest cały obiekt, jak wcześniej. Opisany niżej `__user__` po stronie formularza pochodzi z tokenu logowania i nigdy nie podlega temu ustawieniu.
+
+### Informacje o użytkowniku w formularzu
+
+Dostęp do informacji o bieżącym użytkowniku w formularzu (v4.0.2).
+
+Pole `__user__` jest automatycznie dodawane do formularza i można się do niego odwoływać w wyrażeniach:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Pola formularzy
+
+### Kaskadowe listy rozwijane
+
+Tworzenie kaskadowych list rozwijanych.
+
+Pola `enum` (listy rozwijane) mogą zawierać symbole zastępcze we właściwości `query` lub `expression`, w formacie `$(another_field)` lub `$(another_field[0].name)`.  
+Gdy tylko pole, do którego się odwołują, się zmieni, pole odwołujące się jest ponownie obliczane, co daje dynamiczne, kaskadowe listy rozwijane.  
+Aplikacja webowa klienta ponownie oblicza pola co 100 ms; przy obecnych procesorach i silniku Chromium działa to zupełnie płynnie.
+
+{: .note }
+> Odwołanie do innego pola enum zwraca wybrane wartości, **a nie** całą listę rozwijaną. Użyj właściwości `placeholderColumn` lub notacji z kropką, na przykład `$(city.name)`.  
+> **Nowość w v4.0.20**: ustawienie placeholderColumn na "*" zwraca cały rekord zamiast jednej kolumny.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Symbole zastępcze pól
+
+Odwoływanie się do wartości innego pola.
+
+Symbole zastępcze to odwołania do innych pól formularza.  
+Symbol zastępczy ma zawsze format `$(reference)`, a symbole zastępcze mogą zawierać zarówno wyrażenia, jak i zapytania.  
+Symbol zastępczy wskazujący proste pole (text, number, password) zawiera wartość tego pola.  
+Symbol zastępczy wskazujący pole enum oparte na obiektach musi używać właściwości `placeholderColumn` lub notacji z kropką, na przykład `$(city.name)`.  
+Symbol zastępczy wskazujący pole expression zwraca cały obiekt; możesz też użyć zaawansowanego odwołania w stylu JavaScript, na przykład `$(myarray[0].name)`.
+
+{: .important }
+> Symbol zastępczy jest podstawiany **przed** obliczeniem wyrażenia. Jeśli wynik ma być ciągiem znaków, musisz ująć go w cudzysłowy.  
+> **Nowość w v4.0.20**: ustawienie placeholderColumn na "*" zwraca cały rekord zamiast jednej kolumny.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Ukrywanie pola
+
+Ukrycie pola.
+
+Ukryj pole właściwością pola `hide` albo pokazuj i ukrywaj je dynamicznie właściwościami pola `dependencies` i `dependencyFn`.
+
+### Grupowanie pól
+
+Grupowanie pól w bloku.
+
+Użyj właściwości pola `group`. Pola o tej samej nazwie grupy są grupowane w bloku.
+
+### Walidacja pola
+
+Walidacja pola.
+
+Użyj właściwości walidacji pola, takich jak `regex`, `minValue` i `notIn`.
+
+### Wartość domyślna w polu enum
+
+Wartość domyślna pola enum.
+
+Właściwość pola `default` ustawia wartość domyślną, a w polach `enum` możesz używać wartości takich jak `__auto__`, aby automatycznie wybrać pierwszą pozycję.
+
+Aby uzyskać dynamiczną wartość domyślną opartą na wyrażeniu, przenieś domyślną pozycję na początek listy, jak w poniższym przykładzie.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Wartość domyślna z wyrażenia
+
+Wartość domyślna z wyrażenia.
+
+Dla pól text, number lub date właściwość `default` ustawia statyczną wartość domyślną.
+
+Aby wartość domyślna była dynamiczna, oparta na wyrażeniu, użyj jednej z dwóch właściwości:
+* `editable`: użyj właściwości editable, aby pole expression było edytowalne
+* `evalDefault`: użyj właściwości evalDefault, aby wartość domyślna była obliczana jako wyrażenie
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Kreator i workflow
+
+### Czym różni się kreator (wizard) od workflow?
+
+**Kreator** (wizard) i **workflow** składają się z kroków, ale działają na różnych warstwach i można je łączyć.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Warstwa** | Wykonanie | Formularz / interfejs |
+| **Co dzieli** | Zadanie na węzły, które działają jeden po drugim lub równolegle | Dane wejściowe jednego formularza na wiele stron |
+| **Wynik** | 1 zadanie workflow, z zadaniem na każdy węzeł (każdy z własnym playbookiem lub szablonem) | Na końcu uruchamiane jest 1 zadanie |
+| **`type` formularza** | Musi być `workflow` | Działa z każdym typem formularza z wyjątkiem `subform` |
+| **Definiowany przez** | [Plik workflow](workflows/file.html) projektanta (`workflow:`) | Listę odwołań do [podformularzy](forms/subform.html) (`wizard:`) |
+| **Używaj, gdy** | „Zrób A, potem B, potem C jako osobne zadania” | „Mój formularz ma za dużo pól na jedną stronę” |
+
+**Najważniejsze:** workflow dotyczy tego, *co jest uruchamiane i w jakiej kolejności*; `wizard` dotyczy tego, *jak użytkownik wypełnia formularz*.
+
+{: .note }
+> Typ formularza `multistep`, z jego `steps`, realizował część wykonawczą przed wersją 7. Jest przestarzały od wersji 7 i zostanie usunięty w
+> 8: workflow robi wszystko, co multistep, zobacz [Formularze wieloetapowe](forms/multistep.html).
+
+#### Tylko workflow
+{: .no_toc }
+
+Formularz `type: workflow` uruchamia jeden z workflow projektanta. Użytkownik wypełnia jedną stronę pól i naciska Wyślij,
+a workflow uruchamia swoje węzły, każdy z wartościami formularza jako extra vars:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Tylko kreator
+{: .no_toc }
+
+Blok `wizard:` w formularzu rozkłada zbieranie danych na wiele stron. Na końcu uruchamiane jest tylko **jedno** zadanie: scalone extravars ze wszystkich stron są wysyłane do jednego playbooka, szablonu lub workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Strona przeglądu tylko do odczytu jest dołączana automatycznie jako ostatnia strona kreatora; nie deklarujesz jej w YAML.
+
+#### Połączenie (kreator nad workflow)
+{: .no_toc }
+
+Kreator można nałożyć na formularz workflow. Użytkownik wypełnia strony kreatora i naciska Wyślij, a **dopiero potem**
+uruchamia się workflow. Dopasowując `defaultModel` kroku kreatora do
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) węzła, możesz skierować **jedną stronę kreatora do jednego węzła**:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+A workflow `provision-host`, w pliku workflow projektanta:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` to wyszukiwanie jednopoziomowe, więc jeśli chcesz, aby się zgadzały, używaj płaskiej nazwy w `defaultModel` (na przykład `defaultModel: basics`, a nie `defaultModel: input.basics`).
+
+Pełny opis właściwości znajdziesz na [stronie kreatora](forms/wizard.html).
+
+### Jak warunkowo pokazywać lub pomijać kroki kreatora?
+
+Użyj `when:`, aby całkowicie **ukryć** krok, lub `optional: true`, aby pozwolić użytkownikowi **pominąć** widoczny krok. Te dwie opcje są niezależne i zasadniczo nie należy ich łączyć.
+
+#### `when:`: widoczność warunkowa
+{: .no_toc }
+
+Krok jest ukryty, gdy wyrażenie daje wartość fałszywą. Użytkownik nigdy go nie widzi, a jego wartości nie są zbierane. Wyrażenie może odczytywać wcześniejsze kroki przez `__parent__.<stepname>.<field>`:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Pokazywana jest tylko strona pasująca do wybranego `kind`. Kroki po ukrytym kroku są automatycznie przenumerowywane.
+
+#### `optional: true`: możliwość pominięcia widocznego kroku
+{: .no_toc }
+
+Krok jest **zawsze widoczny** w pasku kroków, ale użytkownik może nacisnąć **Dalej** bez jego wypełniania, a **Wyślij** jest dozwolone, nawet jeśli strona nie została odwiedzona ani ukończona:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+Użytkownik może otworzyć stronę Advanced, zostawić ją pustą, nacisnąć Dalej i przejść bezpośrednio do strony przeglądu.
+
+{: .note }
+> `when:` steruje *widocznością*; `optional:` steruje tym, *czy stronę trzeba ukończyć*. Nie łącz ich: aby strona zniknęła, użyj `when:`; aby pozostała widoczna, ale możliwa do pominięcia, użyj `optional:`.
+
+### Jak odwołać się do wartości z wcześniejszego kroku kreatora?
+
+Użyj `$(__parent__.<stepname>.<field>)` w dowolnym polu późniejszego kroku.
+
+`name` kroku kreatora (domyślnie nazwa jego `subform`) to przestrzeń nazw, pod którą jego wartości są udostępniane późniejszym krokom:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+To ten sam mechanizm `__parent__`, którego używają podformularze `list` i `yaml`; zobacz [Jak uzyskać dostęp do danych formularza nadrzędnego w podformularzu?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Bezpieczeństwo i poświadczenia
+
+### Poświadczenia
+
+Przekazywanie poświadczeń.
+
+Poświadczenia można przekazywać na kilka sposobów:
+* za pomocą właściwości pola `asCredential`  
+* za pomocą właściwości formularza `credentials` (pary klucz-wartość)
+* za pomocą extravar o nazwie `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Odzyskiwanie utraconego hasła administratora
+
+Jeśli utraciłeś hasło lokalnego konta `admin`, a żaden inny administrator nie jest dostępny, użyj opcji odzyskiwania `REINIT_ADMIN`. **Nie jest to obejście uwierzytelniania w czasie działania**: wymusza tylko jednorazowe zresetowanie lokalnego konta administratora przy uruchomieniu, po czym uwierzytelnianie działa normalnie.
+
+**Jak to działa**
+
+Gdy przy uruchomieniu ustawione jest `REINIT_ADMIN=1`, AnsibleForms:
+
+1. Upewnia się, że grupa `admins` istnieje (tworzy ją, jeśli jej brakuje).
+2. Wyszukuje lokalnego użytkownika administratora (domyślna nazwa `admin`, nadpisywana przez `ADMIN_USERNAME`).
+3. Jeśli istnieje, resetuje jego hasło na wartość `ADMIN_PASSWORD` i ponownie dołącza go do grupy `admins`.
+4. Jeśli nie istnieje, tworzy go (tak jak przy świeżej instalacji).
+5. Wyraźnie zapisuje tę akcję w dzienniku, aby była w nim widoczna.
+
+**Kroki**
+
+1. Zatrzymaj AnsibleForms.
+2. Ustaw zmienne środowiskowe (użyj silnego hasła):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   W Docker Compose dodaj je do bloku `environment:` usługi AnsibleForms.
+3. Uruchom AnsibleForms i obserwuj dziennik, czekając na wiersz taki jak:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Zaloguj się jako `admin` / `YourNewStrongPasswordHere`.
+5. **Usuń `REINIT_ADMIN` (lub ustaw go z powrotem na `0`)** i uruchom ponownie, aby kolejne restarty nie resetowały znowu hasła administratora.
+
+**Uwagi**
+
+- Jeśli straciłeś dostęp, ponieważ LDAP był jedyną skonfigurowaną metodą logowania i przestał działać, odzyskane lokalne konto `admin` zawsze korzysta z uwierzytelniania w lokalnej bazie danych, co wystarcza, aby się zalogować i naprawić LDAP.
+- Dawna zmienna środowiskowa `ENABLE_BYPASS` została usunięta. Pozwalała logować się jako administrator dowolnym hasłem, a pozostawienie jej włączonej było niebezpieczne. `REINIT_ADMIN` tylko resetuje hasło; potem obowiązuje normalne uwierzytelnianie.
+- `REINIT_ADMIN` nie unieważnia istniejących sesji ani tokenów; zmieniają się tylko skrót hasła i członkostwo w grupie.
+
+### Ograniczanie celów funkcji pomocniczych REST (listy dozwolonych i zabronionych)
+
+Funkcje pomocnicze `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` i `fn.fnRestJwtSecure` można wywoływać we właściwościach `expression` formularza, aby pobierać dane przez HTTP. Domyślnie autorzy wyrażeń mogą kierować je do **dowolnego** adresu URL, do którego ma dostęp host AnsibleForms, co w wrażliwej sieci warto ograniczyć.
+
+Dwie zmienne środowiskowe zapewniają listę dozwolonych i listę zabronionych:
+
+| Zmienna | Działanie |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Nazwy hostów lub CIDR oddzielone przecinkami. Gdy jest ustawiona, dozwolone są **tylko** te cele. |
+| `REST_DENIED_HOSTS` | Nazwy hostów lub CIDR oddzielone przecinkami. Zawsze blokowane. Ma pierwszeństwo przed listą dozwolonych. |
+
+Nazwy hostów są porównywane z hostem z adresu URL bez rozróżniania wielkości liter. CIDR są porównywane z każdym adresem IP, na który rozwiązuje się host, więc `10.0.0.0/8` blokuje każdą nazwę DNS rozwiązywaną do zakresu prywatnego.
+
+**Przykłady:**
+
+Pierwszy wiersz dopuszcza tylko dwa hosty; drugi blokuje określone cele:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Ta ochrona chroni tylko proces Node.js AnsibleForms.** Gdy playbook już działa, sam Ansible może sięgnąć z hosta do czegokolwiek, poza kontrolą AnsibleForms. Używaj tych list, aby autorzy formularzy nie zamieniali wyrażeń w proxy do usług metadanych lub wewnętrznych interfejsów; nie traktuj ich jak sieciowej zapory.
+
+Od wersji 7.3.0 funkcje pomocnicze REST sprawdzają certyfikat TLS punktu końcowego, tak jak każde inne połączenie, i rezygnują po
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (domyślnie `60`). Zaufaj prywatnemu CA przez
+`NODE_EXTRA_CA_CERTS` lub ustaw [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) na `1` tylko dla punktów końcowych z
+certyfikatem samopodpisanym.
+
+### Integracja z HashiCorp Vault
+
+Poświadczenia mogą odczytywać użytkownika i hasło z HashiCorp Vault, skonfigurowanego jako
+**magazyn sekretów**. Zobacz [Magazyny sekretów](secret-stores). Zmienne środowiskowe `VAULT_*`
+z wcześniejszych wersji są importowane raz jako magazyn `vault` przy pierwszym uruchomieniu 7.x.
+
+W przypadku sekretów używanych tylko w jednym playbooku możesz też użyć pluginu lookup `community.hashi_vault`,
+który odczytuje dane bezpośrednio z Vault, z pominięciem AnsibleForms.
+
+---
+
+## Integracja
+
+### Odpytywanie AWX/Tower/AAP
+
+Pobieranie informacji z AWX lub Ansible Automation Platform.
+
+Aby wypełniać listy rozwijane danymi z AWX lub Tower, użyj `fn.fnRestBasic` lub `fn.fnRestJwtSecure`. Od wersji 7.3.0 te funkcje sprawdzają
+certyfikat adresu AWX: przy certyfikacie samopodpisanym zaufaj jego CA przez `NODE_EXTRA_CA_CERTS` lub ustaw
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) na `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Dostosowywanie
+
+### Dostosowywanie
+
+Dostosowywanie AnsibleForms.
+
+AnsibleForms to aplikacja webowa. Gdy uruchamiasz ją natywnie w Node.js, możesz zastępować lub zmieniać jej pliki.  
+Zalecanym podejściem jest jednak uruchamianie jej jako obrazu Docker i dodawanie mapowań wolumenów lub plików. Projekty Docker Compose już mapują katalogi, aby baza danych, playbooki, dzienniki, certyfikaty i klucze SSH były trwałe, i możesz dodać kolejne mapowania. Własne logo przesyła się na stronie ustawień **Logo**.  
+Plik `custom.js` zawiera Twoje własne funkcje JavaScript do użycia w wyrażeniach. Funkcje wbudowane mają prefiks `fn.` (na przykład fn.fnRestBasic); funkcje własne mają prefiks `fnc.`.  
+W ten sam sposób możesz dodać własne definicje jq w pliku `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### Włączanie YTT
+
+Włączanie ytt.
+
+Aby używać ytt, ustaw `USE_YTT=1`.  
+Więcej informacji o ytt znajdziesz na https://carvel.dev/ytt/.
+
+{: .important }  
+> Ta funkcja nie została gruntownie przetestowana i od czasu dodania jej jako usprawnienia nie otrzymano żadnych opinii.  
+> Używając ytt, musisz wyłączyć projektanta: projektant konwertuje pliki YAML do pośredniego JSON i usuwa składnię ytt (która składa się z komentarzy YAML).
+
+W katalogu głównym musi istnieć katalog `lib`; jest on automatycznie dołączany do wywołania ytt.
+Dane można dostarczyć globalnie, ustawiając zmienne środowiskowe z prefiksem:  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Alternatywnie dostarcz pliki danych biblioteki:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**Biblioteka `demo` musi istnieć w kontekście ytt (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+Wczytanych danych można następnie użyć:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Kontrola dostępu
+
+### Jak ograniczyć, co mogą robić użytkownicy (opcje ról)?
+
+Poza ograniczaniem tego, które formularze widzi rola, `options` roli włączają lub wyłączają funkcje interfejsu dla jej członków.
+
+Wszystkie opcje, ich wartości domyślne i sposób łączenia opcji z różnych ról opisuje [Opcje ról](config/roles.html#role-options).
+
+### Jak zaimplementować własną logikę RBAC w playbookach lub formularzach?
+
+Tożsamość użytkownika jest dostępna zarówno we frontendzie, jak i w backendzie przy każdym wykonaniu.
+
+Przy każdym wysłaniu formularza AnsibleForms automatycznie wstawia pełną tożsamość bieżącego użytkownika do extravars wysyłanych do Ansible:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+Twój playbook lub dowolny własny moduł Ansible może więc bezpośrednio używać `ansibleforms_user` do szczegółowych decyzji, na przykład aby pozwolić tylko określonym grupom modyfikować inwentarz produkcyjny lub aby zapisywać ślad audytu z nazwą użytkownika zgłaszającego.
+
+We **frontendzie** ten sam obiekt jest dostępny przez specjalne pole `__user__`:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Typowe wzorce:**
+
+Tożsamość użytkownika umożliwia wzorce takie jak:
+
+- **Odwołanie do pliku konfiguracji RBAC lub bazy danych**: wczytaj plik YAML lub JSON (przez `fn.fnReadYamlFile` lub wyrażenie), który przypisuje grupom dozwolone zasoby, a następnie filtruj po `$(__user__.groups)`
+- **Ślad audytu**: przekaż `ansibleforms_user.username` jako dodatkową zmienną, aby zapisać, kto uruchomił zadanie
+- **Dynamiczne wartości pól**: pokazuj inny zestaw opcji enum, wypełniaj wstępnie pola lub ukrywaj sekcje w zależności od grup lub ról użytkownika
+- **Autoryzacja po stronie playbooka**: sprawdź, czy `ansibleforms_user.groups` zawiera wymaganą grupę, zanim playbook będzie kontynuował, jako dodatkową warstwę ochrony niezależną od listy `roles` formularza
+
+{: .note }
+> Powyższy obiekt jest wysyłany domyślnie. Jeśli instancja ustawia `EXTRAVARS_USER_FIELDS`
+> lub formularz ustawia `userExtravars`, wysyłane są tylko wymienione tam klucze, więc playbook, który
+> sprawdza `ansibleforms_user.groups`, wymaga, aby `groups` był jednym z nich. Pole frontendu
+> `__user__` pochodzi z tokenu logowania i nigdy nie jest przycinane przez żadne z tych ustawień.
+
+---
+
+## Planowanie zadań
+
+### Jak zaplanować automatyczne uruchamianie formularza?
+
+Otwórz listę rozwijaną obok **Wyślij** i wybierz **Harmonogram (cykliczny)** lub **Uruchom później (jednorazowo)**; wymagają one opcji
+roli `allowScheduledJobs` (na poziomie administratora) i `allowPlannedJobs`. Zobacz [Harmonogramy](jobs/schedules.html).
+
+### Jakich wyrażeń cron mogę używać?
+
+Harmonogram cykliczny przyjmuje standardowe 5-polowe wyrażenie cron (minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia).
+
+| Wyrażenie | Uruchamia się |
+|---|---|
+| `*/15 * * * *` | Co 15 minut |
+| `0 * * * *` | Co godzinę, o pełnej godzinie |
+| `0 */6 * * *` | Co 6 godzin, o 00:00, 06:00, 12:00 i 18:00 |
+| `0 2 * * *` | Codziennie o 02:00 |
+| `30 7 * * 1-5` | Od poniedziałku do piątku o 07:30 |
+| `0 8 * * MON` | W każdy poniedziałek o 08:00 (nazwy dni i miesięcy są akceptowane) |
+| `0 0 1 * *` | O północy pierwszego dnia każdego miesiąca |
+| `0 22 L * *` | O 22:00 ostatniego dnia każdego miesiąca |
+| `0 6 * * 1#1` | O 06:00 w pierwszy poniedziałek każdego miesiąca |
+| `*/30 * * * * *` | Co 30 sekund (opcjonalne szóste pole na początku to sekunda) |
+
+Gdy ustawione są zarówno dzień miesiąca, jak i dzień tygodnia, harmonogram uruchamia się, gdy pasuje którykolwiek z nich: `0 0 13 * 5` uruchamia się
+13. dnia miesiąca i w każdy piątek. Serwer odrzuca wyrażenie, którego nie potrafi wykonać, lub takie, które nigdy nie może wystąpić (`0 0 30 2 *`).
+
+Na stronie **Harmonogramy** edytor cron opisuje wyrażenie i pokazuje podgląd jego następnych uruchomień. Nie akceptuje skrótów
+takich jak `@daily`, symbolu wieloznacznego `?` ani modyfikatora `W` (najbliższy dzień roboczy), więc trzymaj się postaci z tabeli.
+
+{: .note }
+> **Strefa czasowa** Harmonogramy cron działają w strefie czasowej serwera, ustawianej przez [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (domyślnie `UTC`), a nie w strefie czasowej Twojego profilu lub przeglądarki. `0 2 * * *` z `LOG_TZ=Europe/Madrid` uruchamia się o 02:00
+> czasu madryckiego przez cały rok, z uwzględnieniem czasu letniego. Edytor cron pokazuje podgląd następnych uruchomień w tej samej strefie. Harmonogramy
+> pobierania repozytoriów używają tej samej strefy.
+
+---
+
+## Zapisywanie i wczytywanie danych formularza
+
+### Jak zapisać i ponownie wczytać dane formularza bez uruchamiania zadania?
+
+Wybierz **Zapisz** z listy rozwijanej obok **Wyślij**, aby zapisać wartości pól, a później **Wczytaj zapisany formularz**, aby je przywrócić.
+Pola haseł nigdy nie są zapisywane. Wymaga to opcji roli `allowStoredJobs`. Zobacz [Zapisane zadania](jobs/stored-jobs.html).
+
+---
+
+## Formularze zagnieżdżone i pola strukturalne
+
+### Jak zbierać w formularzu dane strukturalne lub powtarzające się?
+
+Użyj pól `list` i `yaml` z podformularzami (6.2.0+).
+
+Aby zbierać złożone dane strukturalne, na przykład listę serwerów, zestaw interfejsów sieciowych lub pojedynczy zagnieżdżony obiekt, użyj typu pola `list` lub `yaml` razem z `subform`.
+
+**Podformularz** to fragment formularza wielokrotnego użytku (definiowany przez `type: subform`), który nigdy nie jest pokazywany jako samodzielny kafelek. Istnieje wyłącznie po to, aby odwoływały się do niego pola innych formularzy. Pełny opis znajdziesz w [dokumentacji podformularzy](forms/subform.html).
+
+**Zbieranie listy wierszy strukturalnych: pole `list`:**
+
+Pole `list` otwiera wskazany podformularz raz dla każdego wiersza:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+Extravar `servers` wysyłany do Ansible to tablica obiektów: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Edycja pojedynczego obiektu strukturalnego: pole `yaml`:**
+
+Pole `yaml` ma trzy tryby:
+
+| Tryb | Jak | Działanie |
+|---|---|---|
+| **Edytor** | domyślnie | Pokazuje pełny edytor YAML z podświetlaniem składni, w którym użytkownik może pisać bezpośrednio |
+| **Tylko do odczytu** | `readonly: true` | Wyświetla wartość YAML jako sformatowany tekst tylko do odczytu, bez edycji |
+| **Podformularz** | `subform: MySubform` | Ukrywa surowy edytor; po kliknięciu otwiera podformularz jako edytor szczegółów |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Przesyłanie i pobieranie: pola `list` i `yaml`:**
+
+Oba typy pól obsługują przesyłanie plików po stronie klienta przez dwie opcjonalne właściwości:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> Pole `list` i typ formularza `subform` zastąpiły pole `table` i `tableFields`, które zostały usunięte w 7.0.0.
+
+### Jak uzyskać dostęp do danych formularza nadrzędnego w podformularzu?
+
+Odwoływanie się do wartości pól formularza nadrzędnego z poziomu podformularza przez `__parent__` (v6.3.0+).
+
+Gdy otwiera się podformularz, czy to z pola **`list`** (edytor każdego wiersza), czy z pola **`yaml`** w trybie podformularza, AnsibleForms automatycznie wstawia do podformularza specjalne pole tylko do odczytu o nazwie `__parent__`. Zawiera ono migawkę **wartości wszystkich pól formularza nadrzędnego w chwili otwarcia podformularza**, łącznie ze stałymi i zmiennymi.
+
+Dzięki temu pola podformularza mogą używać wyrażeń odwołujących się do danych formularza nadrzędnego bez dodatkowej konfiguracji.
+
+#### Co zawiera `__parent__`?
+{: .no_toc }
+
+`__parent__` to zwykły obiekt, którego klucze są nazwami pól formularza nadrzędnego:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` **nie jest wysyłany do Ansible**; podobnie jak `__user__` jest usuwany z extravars. To wyłącznie pomocnik frontendu dla wyrażeń w podformularzach.
+
+#### Dostęp do wartości nadrzędnych w wyrażeniach podformularza
+{: .no_toc }
+
+Odwołuj się do wartości nadrzędnych standardową składnią wyrażeń `$(...)`:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Zagnieżdżone podformularze
+{: .no_toc }
+
+`__parent__` zawsze odnosi się do **bezpośredniego** formularza nadrzędnego. Jeśli zagnieździsz `list` w podformularzu, który sam jest otwierany z formularza nadrzędnego, `__parent__` wewnętrznego podformularza zawiera dane środkowego podformularza. Aby sięgnąć dalszych poziomów, łącz odwołania, na przykład `$(__parent__.__parent__.someField)`, jeśli środkowy podformularz również przekazuje swój `__parent__`.
+
+### Jak przejść z `table` / `tableFields` na `list` / `subform`?
+
+Pole `table` i właściwość `tableFields` zostały oznaczone jako przestarzałe w 6.2.0 i usunięte w 7.0.0, a formularz, który nadal ich używa, nie przechodzi walidacji. Aby przeprowadzić migrację:
+
+1. Przenieś kolumny z `tableFields` do nowego formularza `type: subform` ze zwykłymi `formfields`
+2. Zastąp pole `table` polem `list`, które odwołuje się do podformularza przez `subform: MySubformName`
+
+**Przed:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Po:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### Migracja `from` z `tableFields` na wyrażenia `__parent__`
+{: .no_toc }
+
+Właściwość `from` kolumn enum w `tableFields` wypełniała opcje listy rozwijanej z innego pola formularza nadrzędnego. W `subform` zastępuje ją `expression`, które odczytuje tę samą wartość przez `__parent__`.
+
+**Przed: `tableFields` z `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Po: podformularz z wyrażeniem `__parent__`:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` zwraca **bieżącą wartość** tego pola, więc jeśli samo to pole jest dynamicznym polem expression, podformularz zawsze widzi najnowszy obliczony wynik z formularza nadrzędnego.
diff --git a/i18n/pl/_reference/getting-help.md b/i18n/pl/_reference/getting-help.md
new file mode 100644
index 0000000..8c39b01
--- /dev/null
+++ b/i18n/pl/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Uzyskiwanie pomocy
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Uzyskiwanie pomocy
+{: .no_toc }
+
+Gdzie zadać pytanie, zgłosić błąd lub problem z bezpieczeństwem i zaproponować usprawnienie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Zanim zapytasz
+
+Większość odpowiedzi jest już spisana; szybkie sprawdzenie często oszczędza wymiany wiadomości:
+
+1. Przeszukaj tę witrynę polem wyszukiwania na górze każdej strony.
+2. Wyszukaj dokładny komunikat błędu w [Rozwiązywaniu problemów](troubleshooting.html) i przejrzyj [FAQ](faq.html).
+3. Sprawdź dziennik serwera (**Ustawienia**, a potem **Dziennik serwera**) i stronę **Stan**, które zgłaszają większość problemów z konfiguracją.
+4. Sprawdź [Dziennik zmian](changelog.html): problem może być już naprawiony w nowszym wydaniu.
+
+---
+
+## Dokąd się udać
+
+Każdy rodzaj zgłoszenia ma swoje miejsce, wszystkie na GitHub:
+
+| Chcesz | Przejdź do |
+|---|---|
+| Zadać pytanie lub podzielić się pomysłem | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Zgłosić błąd | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Zaproponować funkcję | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Zgłosić problem z bezpieczeństwem | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), poufnie |
+| Poprawić lub ulepszyć tę dokumentację | **Edit this page on GitHub** na dole każdej strony lub [issue w repozytorium witryny](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Zgłaszanie błędu
+
+Najszybciej naprawiane jest zgłoszenie, które da się odtworzyć. Szablon zgłoszenia błędu prosi o następujące informacje:
+
+* **Wersja** : widoczna w **O programie** w menu pomocy (**?**) na górnym pasku
+* **Wdrożenie** : Docker, Docker Compose, Kubernetes, instalator (i jego silnik), instalacja natywna lub ze źródeł
+* **Kroki do odtworzenia** : co zrobiłeś, czego się spodziewałeś i co stało się zamiast tego
+* **Dowody** : odpowiednie wiersze dziennika serwera oraz zrzut ekranu, gdy problem jest widoczny
+
+W przypadku problemu z formularzem dołącz minimalną definicję formularza, która go pokazuje. Usuń hasła, tokeny, nazwy hostów i wszelkie
+inne prywatne dane z dzienników i formularzy, zanim je opublikujesz: zgłoszenia i dyskusje są publiczne.
+
+---
+
+## Zgłaszanie problemu z bezpieczeństwem
+
+**Nigdy nie otwieraj w tej sprawie publicznego zgłoszenia:** użyj [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), które widzą tylko opiekunowie projektu.
+
+[Polityka bezpieczeństwa](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) wymienia obsługiwane wersje i
+opisuje, co dzieje się po zgłoszeniu.
diff --git a/i18n/pl/_reference/troubleshooting.md b/i18n/pl/_reference/troubleshooting.md
new file mode 100644
index 0000000..e92e975
--- /dev/null
+++ b/i18n/pl/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Rozwiązywanie problemów
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Rozwiązywanie problemów
+{: .no_toc }
+
+Komunikaty błędów i objawy, dlaczego się pojawiają i jak je naprawić
+{: .fs-6 .fw-300 }
+
+---
+
+Każdy z poniższych problemów jest zatytułowany komunikatem lub objawem, który widzisz, a po nim następuje przyczyna i rozwiązanie. Komunikaty są cytowane
+dokładnie tak, jak zapisuje je AnsibleForms; `<name>` oznacza wartość, która różni się w zależności od przypadku. Większość z nich trafia do dziennika
+serwera, który możesz przeczytać w [Dzienniku serwera](gui/administration.html#server-log) lub przez `docker logs`.
+
+**Baza danych i uruchamianie**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Konfiguracja i formularze**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [Konfiguracja bazowa ma sekcję forms](#the-base-config-has-a-forms-section)
+* [Brak formularza na pulpicie](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Logowanie**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Uwierzytelnianie Azure AD lub OIDC nie powiodło się](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Wylogowanie po restarcie lub po jednym dniu](#logged-out-after-a-restart-or-after-a-day)
+* [Puste formularze i zadania po jednokrotnym logowaniu (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Zadania**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Zadanie ma stan abandoned](#a-job-shows-the-status-abandoned)
+* [RTE się nie łączy](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Repozytoria git i kopie zapasowe**
+
+* [Klonowanie lub pull repozytorium nie powiodło się](#a-repository-clone-or-pull-failed)
+* [Repozytorium formularzy nie jest jeszcze sklonowane](#the-forms-repository-is-not-cloned-yet)
+* [Kopia zapasowa nie powiodła się](#a-backup-failed)
+
+[FAQ](faq.html) szczegółowo opisuje dwa powiązane problemy:
+[utracone hasło administratora](faq.html#recovering-a-lost-admin-password) oraz
+[ograniczanie celów funkcji pomocniczych REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms się nie uruchamia, a dziennik co 5 sekund powtarza te wiersze:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Dlaczego tak się dzieje**
+
+Przy uruchamianiu AnsibleForms czeka, aż baza danych odpowie na zapytanie, i czeka tak długo, jak długo nie odpowiada.
+`<reason>` to komunikat samego sterownika bazy danych: odrzucone połączenie lub przekroczenie czasu wskazuje na host lub port,
+a komunikat o odmowie dostępu na nazwę użytkownika lub hasło.
+
+**Jak to naprawić**
+
+Sprawdź [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) i [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+Wewnątrz kontenera `localhost` to sam kontener, a nie host, na którym działa MySQL. Upewnij się, że MySQL nasłuchuje
+na adresie sieciowym i że użytkownik może łączyć się z hosta AnsibleForms. AnsibleForms samo kontynuuje, gdy tylko
+baza danych odpowie; restart nie jest potrzebny.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+Przeglądarka otwiera stronę bazy danych zamiast strony logowania, a dziennik pokazuje:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Dlaczego tak się dzieje**
+
+Schematu `AnsibleForms` brakuje lub jest niekompletny. *Pusta* baza danych jest przygotowywana automatycznie przy uruchamianiu, chyba że
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) ma wartość `0`. Jeśli to się nie uda, na przykład dlatego, że
+użytkownik bazy danych nie może tworzyć schematu, dziennik zawiera `Failed to create the schema automatically : <reason>`. Schemat,
+który istnieje, ale brakuje mu tabel (`Table '<name>' is not present`), nigdy nie jest odtwarzany automatycznie, ponieważ tworzenie
+schematu najpierw usuwa wszystkie tabele. Strona bazy danych pokazuje wtedy *It appears that you have an unuseable schema*.
+
+**Jak to naprawić**
+
+Przy świeżej instalacji nadaj użytkownikowi bazy danych prawo do tworzenia schematu `AnsibleForms` i uruchom ponownie albo naciśnij
+**Create** na stronie bazy danych. Przy częściowo istniejącym schemacie przywróć kopię zapasową lub usuń niekompletny schemat `AnsibleForms`,
+aby AnsibleForms mogło utworzyć go ponownie. Dziennik wymienia, które tabele i poprawki się nie powiodły.
+
+---
+
+## Schema creation is disabled
+
+Tworzenie schematu, ze strony bazy danych lub przez `POST /api/v2/schema`, kończy się błędem:
+
+```
+Schema creation is disabled
+```
+
+**Dlaczego tak się dzieje**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) ma wartość `0`, co wyłącza zarówno automatyczne
+tworzenie przy uruchamianiu, jak i endpoint. Na bazie danych, która ma już użytkowników, endpoint odrzuca też wywołujących, którzy nie są
+zalogowani jako administrator, komunikatem `Schema creation requires an authenticated administrator`.
+
+**Jak to naprawić**
+
+Utwórz schemat raz z `ALLOW_SCHEMA_CREATION=1` (to wartość domyślna) lub przywróć go z kopii zapasowej, a potem ustaw
+zmienną z powrotem na `0`. Na przygotowanej bazie danych zaloguj się jako administrator, zanim utworzysz schemat ponownie, i pamiętaj,
+że usuwa on i tworzy od nowa wszystkie tabele.
+
+---
+
+## Config seed failed, refusing to start
+
+Kontener kończy działanie zaraz po uruchomieniu, a jego wynik kończy się wierszem:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Dlaczego tak się dzieje**
+
+Pliku w [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) nie dało się zastosować: na przykład nie jest prawidłowym
+YAML lub narusza schemat seeda; `<reason>` mówi, co poszło nie tak. AnsibleForms odmawia uruchomienia, zamiast działać
+z połową zadeklarowanych obiektów. Przyczyna jest też zapisywana na standardowe wyjście błędów, więc pokazują ją `docker logs` i `kubectl logs`.
+
+**Jak to naprawić**
+
+Popraw to, co wskazuje `<reason>`, i uruchom ponownie. [Ponowne wczytywanie i uruchamianie](seed/reloading.html) opisuje, jak seed jest
+stosowany, a [Przykład](seed/example.html) pokazuje prawidłowy plik.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Każde uruchomienie zapisuje w dzienniku to ostrzeżenie:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Albo worker odmawia uruchomienia z komunikatem:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Dlaczego tak się dzieje**
+
+Zapisane sekrety są szyfrowane kluczem [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET): od wersji 7.3.0 znajdują się w
+poświadczeniach (między innymi hasła i tokeny katalogów LDAP, dostawców SSO, runnerów i magazynów sekretów), obok adresów webhooków Slack
+i Teams. Bez niego używany jest klucz, który jest publiczny w kodzie źródłowym. Od wersji 7.3.0 uruchomienie z nowym
+`ENCRYPTION_SECRET` ponownie szyfruje nim każdy zapisany sekret, w jednej transakcji: z klucza domyślnego, gdy jest ustawiany po raz pierwszy,
+lub z [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS), gdy się zmienia. Gdy
+zapisane sekrety nie zostały zaszyfrowane żadnym z nich, nic nie jest zmieniane, a AnsibleForms się nie uruchamia.
+
+**Jak to naprawić**
+
+Ustaw `ENCRYPTION_SECRET` i przechowuj go razem z innymi sekretami: kopie zapasowe nigdy go nie zawierają. Następne uruchomienie zapisze w dzienniku
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Aby zmienić go później, ustaw nową wartość w
+`ENCRYPTION_SECRET`, a starą w `ENCRYPTION_SECRET_PREVIOUS` na czas jednego uruchomienia, a potem usuń `ENCRYPTION_SECRET_PREVIOUS`. Gdy
+worker odmawia uruchomienia, ustaw `ENCRYPTION_SECRET_PREVIOUS` na klucz, którym zaszyfrowano sekrety, lub przywróć starą wartość.
+
+---
+
+## Could not load the forms
+
+Pulpit nie pokazuje żadnych formularzy i zgłasza:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Dlaczego tak się dzieje**
+
+Konfiguracji bazowej (`config.yaml`) nie dało się odczytać lub jest nieprawidłowa. `<reason>` mówi, co jest nie tak:
+
+| Przyczyna | Źródło problemu |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Błąd składni YAML |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Pusty plik lub plik zawierający tylko komentarze |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | Ta sama rola jest zdefiniowana dwa razy |
+| `There is no config.yaml nor could one be created from template.` | Brakuje `config.yaml`, a jego folder nie jest zapisywalny |
+| `There is no forms directory nor could there be one created from template.` | Brakuje folderu formularzy i nie da się go utworzyć |
+| Każdy inny wiersz | Konfiguracja narusza schemat, na przykład rola bez `groups` |
+
+**Jak to naprawić**
+
+Popraw plik wskazany przez [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) lub `config.yaml` w
+repozytorium używanym do konfiguracji. Gdy brakuje plików, skieruj [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) i
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) na zapisywalne, trwałe miejsce. Strukturę opisuje
+[config.yaml](config/).
+
+---
+
+## Konfiguracja bazowa ma sekcję forms
+
+Po aktualizacji z 6.x pulpit jest pusty, a panel ostrzeżeń pokazuje:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Dlaczego tak się dzieje**
+
+Od wersji 7.0.0 każdy formularz znajduje się we własnym pliku w folderze formularzy. Formularze, które nadal są wymienione w `config.yaml`, są
+ignorowane.
+
+**Jak to naprawić**
+
+Przenieś każdy formularz do osobnego pliku w [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Zobacz
+[Aktualizacja do 7.x](upgrade-7.html).
+
+---
+
+## Brak formularza na pulpicie
+
+Plik formularza istnieje, ale użytkownik nie widzi formularza na pulpicie.
+
+**Dlaczego tak się dzieje**
+
+Użytkownik widzi formularz tylko wtedy, gdy jedna z `roles` formularza jest jedną z ról użytkownika; administratorzy widzą wszystkie formularze. Każdy użytkownik ma
+rolę `default`, więc formularz z `roles: [default]` jest widoczny dla wszystkich. Role użytkownika pochodzą z grup i użytkowników
+wymienionych pod `roles` w `config.yaml`. Formularz bez `categories` pojawia się w kategorii **Default**, więc brakuje go w
+pozostałych kategoriach, choć nadal jest wymieniony w **Wszystkie formularze**. Wreszcie formularz, który nie przechodzi walidacji, jest pomijany.
+Pulpit pokazuje wtedy przycisk **Ta konfiguracja zawiera ostrzeżenia lub błędy**, który otwiera komunikaty takie jak:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Jak to naprawić**
+
+Otwórz panel ostrzeżeń i popraw to, co wymienia. Sprawdź role użytkownika w
+[Uprawnieniach](profile/permissions.html) w profilu oraz `roles` i `categories` formularza. Zobacz
+[Role](config/roles.html) i [Kategorie](config/categories.html). Gdy dwa pliki definiują tę samą nazwę formularza,
+wygrywa ten wczytany jako pierwszy.
+
+---
+
+## Could not save the forms
+
+Zapis w projektancie kończy się błędem:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Dlaczego tak się dzieje**
+
+Projektant waliduje każdy formularz względem schematu, zanim cokolwiek zapisze. Każdy wiersz `<messages>` wskazuje
+formularz i pole, które naruszają regułę. Opcje usunięte w 7.0.0 mają własny komunikat, na przykład
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Jak to naprawić**
+
+Popraw pola wskazane w komunikatach. W przypadku opcji usuniętych w 7.0.0 postępuj zgodnie z [Aktualizacja do 7.x](upgrade-7.html).
+Aby walidować pliki formularzy, zanim trafią do AnsibleForms, zobacz
+[Walidacja plików formularzy w VS Code](faq.html#vs-code-validation-for-form-files) w FAQ.
+
+---
+
+## The editor is read-only
+
+Projektant pokazuje **Zablokowane przez** z nazwą innego użytkownika, a zapis kończy się błędem:
+
+```
+The editor is read-only
+```
+
+**Dlaczego tak się dzieje**
+
+Formularze może edytować tylko jedna osoba naraz. Blokada jest zakładana, gdy ktoś uruchamia projektanta, i trwa, dopóki
+go nie zatrzyma, nawet jeśli zamknął przeglądarkę bez zatrzymania. API odrzuca zapis od kogokolwiek innego komunikatem
+`Designer is locked by <username>`.
+
+**Jak to naprawić**
+
+Poproś `<username>` o zatrzymanie projektanta. Jeśli to niemożliwe, użyj **Zwolnij** w projektancie. Osoba, która trzyma
+blokadę, traci niezapisane zmiany.
+
+---
+
+## Abuse attempt of eval function
+
+Pole z wyrażeniem pokazuje błąd, a dziennik zawiera wiersz taki jak:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Dlaczego tak się dzieje**
+
+Wyrażenia po stronie serwera są sprawdzane przed uruchomieniem. Mogą wywoływać tylko funkcje `fn.` i `fnc.`; wiele instrukcji,
+wiele wierszy, literały szablonowe, `process.env` i słowa takie jak `require` czy `constructor` są odrzucane. Komunikat
+mówi, która reguła została naruszona. Gdy [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) ma wartość
+`off`, każde wyrażenie serwerowe kończy się błędem
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Jak to naprawić**
+
+Przepisz wyrażenie jako pojedyncze wywołanie `fn.` lub zwykłą operację albo uruchom je w przeglądarce z `runLocal: true`. Zobacz
+[Wyrażenia](expressions/) i [Wyrażenia lokalne](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Pole, które wywołuje API REST, pozostaje puste, a dziennik pokazuje:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Dlaczego tak się dzieje**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) jest ustawione, a host z adresu URL nie jest w nim wymieniony.
+Host pasujący do [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) jest odrzucany komunikatem
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, a host, którego nazwy nie da się rozwiązać, komunikatem `cannot resolve <host>`.
+
+**Jak to naprawić**
+
+Dodaj nazwę hosta lub CIDR obejmujący jego adresy do `REST_ALLOWED_HOSTS` albo usuń wpis, który go blokuje, z
+`REST_DENIED_HOSTS`. Zobacz [Ograniczanie celów funkcji pomocniczych REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+Strona logowania odrzuca nazwę użytkownika i hasło komunikatem:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Dlaczego tak się dzieje**
+
+Strona logowania daje tę samą odpowiedź przy każdym niepowodzeniu, aby nie zdradzać, czy użytkownik istnieje. AnsibleForms
+najpierw sprawdza użytkowników lokalnych, a potem LDAP: przy kilku katalogach nazwa użytkownika jest wyszukiwana w ich kolejności z **Dostęp > LDAP**,
+chyba że wskazuje katalog (`corp\jane`) lub jedną z jego domen logowania (`jane@corp.example`). Rzeczywista przyczyna trafia do dziennika. Niepowodzenia LDAP
+są zapisywane jako `Error connecting to ldap: <reason>`, z przyczynami takimi jak `Wrong binding credentials` lub
+`Unable to verify the certificate`; kody Active Directory są tłumaczone na `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` lub `Password expired`.
+
+**Jak to naprawić**
+
+Przeczytaj przyczynę w dzienniku. Aby uzyskać pełną przyczynę każdego nieudanego logowania, ustaw
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) na `debug`, co zapisuje `Ldap authentication failed: <reason>`.
+Jeśli lokalne hasło administratora zostało utracone, zobacz [Odzyskiwanie utraconego hasła administratora](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Test katalogu LDAP w **Dostęp > LDAP** kończy się jednym z tych błędów:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Dlaczego tak się dzieje**
+
+Użytkownik powiązania (bind) lub jego hasło są błędne, serwer lub port są nieosiągalne albo, przy TLS, certyfikatu serwera nie da się
+zweryfikować względem pakietu CA. Od wersji 7.3.0 te dane są w poświadczeniu ldap katalogu, w **Połączenia > Poświadczenia**. Testowy użytkownik, który nie istnieje,
+nadal liczy się jako udany test, ponieważ połączenie i powiązanie zadziałały.
+
+**Jak to naprawić**
+
+Otwórz poświadczenie wskazane przez katalog (katalog domyślny to `main`) w **Połączenia > Poświadczenia** i popraw DN
+powiązania i jego hasło, serwery oraz port (zwykle 389 lub 636 dla LDAPS). W przypadku problemów z TLS wklej pakiet CA, który podpisał
+certyfikat serwera LDAP; pomijanie sprawdzania certyfikatu nie jest przeznaczone do produkcji. Zobacz [LDAP](authentication/ldap.html).
+
+---
+
+## Uwierzytelnianie Azure AD lub OIDC nie powiodło się
+
+Logowanie jednokrotne wraca na stronę logowania z komunikatem:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Dlaczego tak się dzieje**
+
+Dostawca tożsamości odesłał użytkownika, ale AnsibleForms nie mogło dokończyć logowania. Typowe przyczyny to
+`azuread login is not enabled` lub `oidc login is not enabled` (dostawca jest wyłączony) oraz `jwt expired`, ponieważ
+przekazanie od dostawcy jest ważne tylko przez 5 minut. Błąd podczas callbacku od dostawcy jest też pokazywany
+na stronie logowania i zapisywany w dzienniku.
+
+**Jak to naprawić**
+
+Włącz dostawcę w **Dostęp > SSO** i zarejestruj adres callbacku u dostawcy tożsamości dokładnie tak, jak
+używa go AnsibleForms: `https://<your host>/api/v2/auth/entraid/callback` dla Entra ID (od wersji 7.3.0; `azureadoauth2` nadal działa) lub
+`https://<your host>/api/v2/auth/oidc/callback` dla OIDC. Adres callbacku z `/api/v1/`, sprzed wersji 7 lub sprzed
+6.1.5, trzeba zaktualizować: strona logowania przeładowuje się wtedy bez zalogowania i bez błędu. Po wygaśnięciu przekazania
+spróbuj zalogować się ponownie.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Użytkownik z prawidłowym hasłem nie może się zalogować i dostaje:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Dlaczego tak się dzieje**
+
+Jedna z ról użytkownika ustawia opcję roli `allowLogin` na `false`. Dziennik zawiera
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Jak to naprawić**
+
+Usuń `allowLogin: false` z roli lub usuń użytkownika z tej roli. Zobacz [Role](config/roles.html).
+
+---
+
+## Wylogowanie po restarcie lub po jednym dniu
+
+Każdy użytkownik jest odsyłany na stronę logowania po restarcie AnsibleForms lub po dniu używania.
+
+**Dlaczego tak się dzieje**
+
+Gdy [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) nie jest ustawiony, każde uruchomienie generuje
+nowy klucz podpisujący i zapisuje w dzienniku
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Tokeny sprzed
+restartu nie są wtedy już akceptowane. Niezależnie od tego sesja kończy się, gdy wygaśnie jej token odświeżania
+(`Refresh token is expired`), po
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), domyślnie 24 godzinach.
+
+**Jak to naprawić**
+
+Ustaw `ACCESS_TOKEN_SECRET` na stałą, tajną wartość. Zwiększ `ACCESS_TOKEN_REFRESH_EXPIRATION`, jeśli dzień to za mało. Do
+długoterminowego dostępu do API użyj [tokenu API](profile/api-token.html).
+
+---
+
+## Puste formularze i zadania po jednokrotnym logowaniu (HTTP 431)
+
+Użytkownik loguje się przez Entra ID lub OIDC bez błędu, ale strony formularzy i zadań pozostają puste. Karta sieci
+przeglądarki pokazuje wywołania API z odpowiedzią:
+
+```
+431 Request Header Fields Too Large
+```
+
+Dziennik serwera nie pokazuje niczego dla tych wywołań, a ten sam użytkownik może bez problemu pracować z kontem LDAP lub lokalnym.
+
+**Dlaczego tak się dzieje**
+
+Przed wersją 7.1.0 token logowania zawierał wszystkie grupy użytkownika, a grupy Entra ID były w nim dwukrotnie, według identyfikatora obiektu
+i według nazwy. Przeglądarka wysyła ten token w nagłówku `Authorization` każdego żądania, więc użytkownik w około stu
+lub więcej grupach ma nagłówek znacznie większy niż 16 KB. Node.js odrzuca nagłówki żądania większe niż 16 KB kodem 431,
+zanim żądanie dotrze do AnsibleForms, dlatego nic nie jest zapisywane w dzienniku. Reverse proxy przed aplikacją może odrzucić
+żądanie jeszcze wcześniej: Nginx domyślnie pozwala na 8 KB na pole nagłówka
+(`large_client_header_buffers 4 8k`) i odpowiada wtedy kodem 400.
+
+**Jak to naprawić**
+
+Zaktualizuj do wersji 7.1.0 lub nowszej: token logowania nie zawiera już grup, więc jego rozmiar nie zależy już od liczby
+grup użytkownika, a interfejs informuje o odrzuceniu żądania kodem 431, zamiast pokazywać puste strony.
+Dopóki nie możesz zaktualizować, wybierz jedno z dwóch:
+
+* ustaw **Filtr grup** u dostawcy w **Dostęp > SSO**, wyrażenie regularne, które zachowuje tylko grupy używane przez Twoje
+  role, zobacz [Entra ID](authentication/entra-id.html) lub [OIDC](authentication/oidc.html); użytkownik loguje się ponownie,
+  aby dostać mniejszy token
+* albo zwiększ limit Node.js zmienną środowiskową `NODE_OPTIONS=--max-http-header-size=65536` i
+  uruchom ponownie AnsibleForms
+
+Od wersji 7.1.0 [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) ustawia ten sam limit, domyślnie 16384
+bajtów, odczytywany przy uruchomieniu, dla innych dużych nagłówków, na przykład dużych ciasteczek ustawianych przez bramę jednokrotnego logowania
+przed aplikacją. Zwiększ też limity nagłówków proxy, zobacz [Rozmiar nagłówka żądania](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Zadanie Ansible kończy się błędem, a ostatni wiersz jego wyniku to:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Dlaczego tak się dzieje**
+
+`ansible-playbook` zakończył działanie z niezerowym kodem. Wiersze powyżej zawierają własny błąd Ansible: nie znaleziono playbooka,
+host był nieosiągalny, zadanie się nie powiodło lub inwentarz jest błędny. Playbook jest szukany w repozytorium
+z włączoną opcją **Używać do playbooków?** lub w [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); wiersz dziennika
+`Running from directory : <path>` pokazuje użyty folder.
+
+**Jak to naprawić**
+
+Przeczytaj wynik zadania powyżej ostatniego wiersza. Gdy playbook nie zostaje znaleziony, porównaj `playbook` formularza z
+folderem w `Running from directory`. Zobacz [Formularze ansible](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Zadanie Ansible kończy się błędem z komunikatem:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Dlaczego tak się dzieje**
+
+Proces `ansible-playbook` na RTE został zakończony sygnałem, a nikt nie przerwał zadania. Od wersji 7.0.0 nie powoduje tego już rozmiar
+wyniku: po przekroczeniu [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (domyślnie 50 MB na strumień)
+reszta wyniku nie jest zapisywana, zadanie pokazuje
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+a playbook działa do końca. Obecnie zwykłą przyczyną jest pamięć: kontener RTE osiągnął limit pamięci, a
+jądro zabiło playbook, na przykład przy wielu forkach lub dużych faktach.
+
+**Jak to naprawić**
+
+Sprawdź pamięć kontenera RTE podczas działania playbooka (`docker stats`, `kubectl top pod`) i zwiększ jego limit albo zmniejsz
+zużycie pamięci przez playbook (mniej `forks`, bez niepotrzebnego zbierania faktów). Gdy widzisz tylko ostrzeżenie `PROCESS_MAX_BUFFER` i
+potrzebujesz całego wyniku, zwiększ `PROCESS_MAX_BUFFER` w środowisku kontenera RTE; odczytuje ją RTE, a nie aplikacja.
+---
+
+## Failed to launch awx template
+
+Zadanie AWX kończy się błędem, a jego wynik zaczyna się od:
+
+```
+failed to launch awx template <name>
+```
+
+**Dlaczego tak się dzieje**
+
+Następny wiersz podaje przyczynę. `Request failed with status code 401` oznacza, że token lub nazwa użytkownika i hasło w
+poświadczeniu runnera AWX są odrzucane. `could not find job template <name>` oznacza, że ani szablon joba, ani szablon workflow
+nie ma dokładnie takiej nazwy albo użytkownik połączenia go nie widzi. Błąd certyfikatu, taki jak
+`unable to verify the first certificate`, oznacza, że certyfikat AWX nie jest zaufany.
+
+**Jak to naprawić**
+
+Użyj **Testuj połączenie** na runnerze (**Połączenia > Runnery**), który odpowiada `Runner connection is OK`, gdy wszystko działa. Od
+wersji 7.3.0 token lub użytkownik i hasło, adres i **Pakiet CA** są w poświadczeniu runnera, w
+**Połączenia > Poświadczenia**: tam odnów token lub hasło, a w przypadku błędów certyfikatu wklej CA do jego **Pakiet CA**.
+Sprawdź nazwę szablonu i uprawnienia. Wpisz adres bez `/api/v2`: AnsibleForms samo dodaje
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX).
+Zobacz [Formularze AWX](forms/awx.html).
+
+---
+
+## Zadanie ma stan abandoned
+
+Zadanie, które działało, jest teraz oznaczone jako `abandoned`, a dziennik węzła lub RTE pokazuje jeden z komunikatów:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+RTE w trybie bazy danych, przestarzałym, zapisuje własne:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Dlaczego tak się dzieje**
+
+Zadanie należy do kontenera, który je uruchamia lub śledzi: playbook do swojego RTE, każde inne zadanie (zadanie AWX, kroki formularza
+wieloetapowego) do węzła aplikacji, który je uruchomił. Gdy ten kontener się restartuje, kończy swoje niedokończone zadania. Gdy znika, na przykład zastąpiony
+pod, worker kończy jego zadania, gdy ten nie odpowiada przez dwie minuty. Jeśli RTE w trybie gniazda wraca bez
+zadania, które uruchamiało, na przykład nowy kontener bez swojego spoola, to zadanie kończy się jako abandoned. Zatrzymywane RTE najpierw czeka
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) na swoje playbooki. Co godzinę zadania działające dłużej
+niż dzień są również oznaczane jako abandoned.
+
+Od wersji 7.3.0 zadanie w AWX, AAP lub Ascender trwa dalej na swoim runnerze: zaraz po tym, jak restart je porzuci, węzeł znów je śledzi,
+jeśli rozpoczęło się w ciągu ostatnich 24 godzin, i kończy się tym, co faktycznie się tam wydarzyło. Dziennik zawiera wtedy `Following <n> abandoned job(s) again on their runner`.
+
+**Jak to naprawić**
+
+Uruchom ponownie zadanie playbooka. Restartuj lub aktualizuj RTE i węzły aplikacji, gdy żadne zadanie nie działa, i dawaj zatrzymywanemu RTE wystarczająco dużo czasu
+(zobacz [Skalowanie](rte/run.html)). Przed ponownym uruchomieniem sprawdź, czy playbook naprawdę zakończył się na zarządzanych hostach,
+ponieważ mógł wykonać się częściowo.
+
+---
+
+## RTE się nie łączy
+
+**Testuj połączenie** na runnerze RTE (**Połączenia > Runnery**) kończy się błędem:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Dlaczego tak się dzieje**
+
+RTE w trybie gniazda komunikuje się z aplikacją przez jeden WebSocket: w trybie wychodzącym łączy się z aplikacją, w przychodzącym aplikacja łączy się z nim (zobacz
+[Tryby](rte/modes.html)). Dzienniki aplikacji i RTE mówią, dlaczego gniazdo nie jest otwarte:
+
+| Komunikat | Gdzie | Co oznacza |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | RTE (przychodzące) | Token poświadczenia RTE runnera nie jest `RTE_TOKEN` tego RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | Aplikacja (przychodzące) | To samo, z perspektywy aplikacji |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | Aplikacja oraz odrzucone RTE (`401`) | RTE loguje się innym tokenem niż ten, który aplikacja przechowuje dla jego runnera |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | RTE (wychodzące) | Poprosiło o dołączenie i czeka na zatwierdzenie |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | RTE (przychodzące, z `APP_URL`) | To samo, dla przychodzącego RTE |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | Aplikacja oraz odrzucone RTE (`409`) | Config seed deklaruje runner bez `rte_mode`, czyli w trybie bazy danych, a o jego trybie decyduje seed. Przychodzące RTE dostaje `rte_mode: inbound` i `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | RTE | Przychodzące RTE, które samo się rejestruje, potrzebuje adresu, pod którym łączy się z nim aplikacja |
+| `Runner '<name>': dialing <address>: <reason>` | Aplikacja, na poziomie `debug` | Aplikacja nie może otworzyć gniazda, na przykład dlatego, że certyfikat RTE nie jest tym przypiętym dla jego runnera |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | RTE | Działa w trybie bazy danych i w ogóle nie otwiera gniazda |
+
+**Jak to naprawić**
+
+* **Odrzucony token** : daj RTE token poświadczenia RTE jego runnera (**Połączenia > Poświadczenia**) lub odwrotnie
+* **Oczekiwanie na zatwierdzenie** : zatwierdź je w **Połączenia > Runnery** po sprawdzeniu, że widoczny tam odcisk jest tym z jego
+  dziennika (zobacz [Zatwierdzanie RTE](runners/registration.html#approving-an-rte))
+* **Zarządzane przez config seed w trybie bazy danych** : ustaw `rte_mode` dla runnera w seedzie, z poświadczeniem RTE (dla przychodzącego z jego
+  adresem), a potem uruchom ponownie RTE
+* **Przychodzące bez `RTE_URL`** : ustaw `RTE_URL` na adres, pod którym aplikacja sięga do RTE, albo pomiń `APP_URL` i zadeklaruj
+  runner w seedzie lub w **Połączenia > Runnery**
+* **Certyfikat, który nie jest przypięty** : przychodzące RTE przez HTTPS wysyła swój certyfikat przy rejestracji, a aplikacja łączy się
+  z nim tylko z tym certyfikatem. Po zmianie certyfikatu RTE wysyła go ponownie przy rejestracji; gdy pakiet CA poświadczenia został ustawiony
+  ręcznie, aplikacja go zachowuje i zapisuje w dzienniku
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **Ostrzeżenie [DEPRECATED]** : ustaw `RTE_MODE` na RTE, usuń `DB_*` z jego środowiska i ustaw jego runner w tym trybie (zobacz
+  [Tryby](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Przy walidacji przy uruchomieniu ustawionej na `enforce` uruchomienie jest odrzucane kodem `422` i komunikatem:
+
+```
+The form data is not valid
+```
+
+**Dlaczego tak się dzieje**
+
+Serwer sprawdził wartości pól względem reguł formularza i znalazł brakujące lub nieprawidłowe pola; odpowiedź wymienia
+je pod `details`. Uruchomienie bez `rawFormData` również jest odrzucane. Formularz, którego nie da się jeszcze sprawdzić, na przykład kreator,
+jest odrzucany komunikatem `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Jak to naprawić**
+
+Popraw pola wskazane w szczegółach albo reguły formularza, jeśli są zbyt rygorystyczne. Najpierw uruchom w trybie `log`: zapisuje on w dzienniku
+`Launch validation would refuse form '<name>' ...`, niczego nie odrzucając. Zobacz
+[Co robi enforce](launch-validation/log-and-enforce.html#what-enforce-does) i
+[Wdrażanie](launch-validation/rolling-it-out.html).
+
+---
+
+## Klonowanie lub pull repozytorium nie powiodło się
+
+Repozytorium pokazuje stan błędu, a jego wynik zawiera błąd git, albo dziennik pokazuje
+`Background clone of '<name>' failed : <reason>`.
+
+**Dlaczego tak się dzieje**
+
+Git nie mógł połączyć się ze zdalnym repozytorium lub się w nim uwierzytelnić. Dla adresów SSH (`git@host:path`) zdalne repozytorium musi akceptować klucz publiczny
+AnsibleForms; dla HTTPS nazwa użytkownika i token muszą być ważne. Pull jest też odrzucany, gdy drzewo robocze ma
+zmiany, komunikatem
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Jak to naprawić**
+
+Dla SSH skopiuj klucz publiczny z karty **Klucz** w **Połączenia > SSH** i dodaj go jako klucz wdrożeniowy (deploy key) lub do użytkownika z
+dostępem do repozytorium. AnsibleForms dodaje zdalny host do znanych hostów przy klonowaniu; dla innych hostów użyj
+karty **Znane hosty** na tej samej stronie. Dla
+HTTPS odnów token. Zobacz [Repozytoria git](gui/designer-and-git.html#git-repositories) i
+[O repozytoriach](faq.html#about-repositories).
+
+---
+
+## Repozytorium formularzy nie jest jeszcze sklonowane
+
+Zapis formularzy w projektancie kończy się błędem:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Dlaczego tak się dzieje**
+
+Repozytorium z włączoną opcją **Używać do formularzy?** nie ma jeszcze drzewa roboczego, ponieważ klonowanie się nie odbyło lub nie powiodło.
+
+**Jak to naprawić**
+
+Sklonuj repozytorium z ustawień repozytoriów. Jeśli klonowanie się nie powiedzie, zobacz
+[Klonowanie lub pull repozytorium nie powiodło się](#a-repository-clone-or-pull-failed).
+
+---
+
+## Kopia zapasowa nie powiodła się
+
+Tworzenie kopii zapasowej kończy się błędem i nic nie zostaje dodane do listy kopii zapasowych. Przyczyną jest jeden z komunikatów:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Dlaczego tak się dzieje**
+
+Polecenie zrzutu, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), nie jest zainstalowane, nie mogło się
+połączyć lub utworzyło pusty plik. Duża baza danych może też wymagać więcej czasu niż
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), domyślnie jedna godzina.
+Nieudana kopia zapasowa nie pozostawia folderu; dziennik zawiera `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Jak to naprawić**
+
+Zainstaluj narzędzia klienckie MySQL lub MariaDB albo ustaw `MYSQLDUMP_COMMAND` (i `MYSQL_COMMAND` do przywracania) na polecenie,
+które działa na tym hoście i z wersją Twojego serwera. Zwiększ `BACKUP_COMMAND_TIMEOUT_SECONDS` dla dużej bazy danych.
+Zobacz [Kopie zapasowe](gui/administration.html#backups).
diff --git a/i18n/pl/_security_assessment/security-assessment/advisories.md b/i18n/pl/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..b74044d
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Biuletyny bezpieczeństwa
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Biuletyny bezpieczeństwa
+{: .no_toc }
+
+Każda opublikowana podatność, jej istotność i poprawka
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Opublikowane biuletyny
+
+Pobierane z [karty Security repozytorium](https://github.com/ansibleforms/ansibleforms/security/advisories) przy każdym budowaniu tej strony:
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Biuletyn</th>
+      <th>Istotność</th>
+      <th>Słabość</th>
+      <th>Podatne wersje</th>
+      <th>Poprawione w</th>
+      <th>Opublikowano</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Nie opublikowano żadnego biuletynu.
+{% endif %}
+
+Każdy biuletyn na GitHubie podaje szczegóły: wpływ, warunki, wektor CVSS i poprawkę.
+
+---
+
+## Co to oznacza dla twojej wersji
+
+Biuletyn wymienia wersje, których dotyczy, i pierwszą wersję z poprawką. Poprawka trafia do wspieranych wydań,
+[7.x i 6.5.x](development.html#supported-versions), a starsze wydania nie są łatane: poprawką jest aktualizacja.
+
+Porównaj wersję instancji (**O programie** w menu pomocy lub `GET /api/v2/version`) z kolumną **Podatne wersje**.
+
+---
+
+## Powiadomienia o nowych biuletynach
+
+GitHub powiadamia obserwujących repozytorium, gdy biuletyn zostaje opublikowany:
+
+* Na [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) wybierz **Watch > Custom > Security alerts**.
+* [Dziennik zmian](../changelog.html) wymienia każdą poprawkę bezpieczeństwa pod wydaniem, które ją zawiera.
diff --git a/i18n/pl/_security_assessment/security-assessment/development.md b/i18n/pl/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..93c8987
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Bezpieczne wytwarzanie
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Bezpieczne wytwarzanie
+{: .no_toc }
+
+Jak zmiany są sprawdzane i wydawane oraz co jest wspierane
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Kod źródłowy
+
+AnsibleForms jest open source, więc wszystko na tej stronie można sprawdzić w samym repozytorium:
+
+* Kod, jego historia i potoki budowania są publiczne na [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* [Licencja](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) to GPL-3.0.
+* [Dziennik zmian](../changelog.html) wymienia każdą zmianę każdego wydania, łącznie z poprawkami bezpieczeństwa.
+
+---
+
+## Jak zmiana jest scalana
+
+Każda zmiana trafia do `main` przez pull request, w ramach zestawu reguł, którego nikt nie może ominąć:
+
+| Reguła | Co oznacza |
+|---|---|
+| Wymagany pull request | Nic nie jest wypychane bezpośrednio do `main` |
+| Wymagane sprawdzenia | Pull request zostaje scalony tylko wtedy, gdy przejdą wszystkie poniższe sprawdzenia |
+| Bez force push, bez usuwania | Historii `main` nie można przepisać ani usunąć |
+| Liniowa historia | Każdy pull request staje się jednym commitem, więc każdą zmianę można prześledzić i wycofać osobno |
+
+Sprawdzenia, które musi przejść pull request:
+
+| Sprawdzenie | Co robi |
+|---|---|
+| Client, Server | Testy jednostkowe interfejsu webowego i serwera |
+| CodeQL | Analiza statyczna GitHuba kodu JavaScript i TypeScript pod kątem wstrzyknięć, cross-site scripting i innych słabości |
+| Public schema is up to date | Schemat bazy danych, którego oczekuje kod, zgadza się z tym, który jest z nim dostarczany |
+| Title, Branch | Pull request przestrzega zasad nazewnictwa, dzięki czemu dziennik zmian pozostaje dokładny |
+
+Dwa kolejne działają przy każdym pull requeście i raportują na jego temat:
+
+* **Database** testuje serwer na MySQL i MariaDB, a **Browser** steruje interfejsem w przeglądarce.
+* **Dependency review** blokuje nową zależność ze znaną podatnością o wysokiej lub krytycznej istotności.
+
+---
+
+## Analiza kodu i zależności
+
+Kod i jego zależności są sprawdzane ponownie po scaleniu:
+
+* **CodeQL** analizuje też każdy push do `main` i do gałęzi wydań, a co tydzień cały kod:
+  nowa reguła CodeQL sprawdza wtedy również kod scalony przed jej pojawieniem się.
+* **Dependabot** otwiera pull request dla każdej nowej wersji zależności: pakietów npm serwera i
+  interfejsu, pakietów Pythona środowiska uruchomieniowego i GitHub Actions potoków co tydzień, a
+  obrazów bazowych kontenerów codziennie.
+* Obrazy bazowe są przypięte przez digest (`node:26-trixie-slim@sha256:...`), więc build używa dokładnie przejrzanego obrazu.
+  Dependabot przesuwa digest, gdy obraz zostanie przebudowany u źródła.
+
+---
+
+## Wydania i obrazy
+
+Wydanie jest budowane i publikowane wyłącznie przez GitHub Actions, nigdy z maszyny programisty:
+
+* Wydanie powstaje z `main` (lub `release/6.x`), z dziennikiem zmian zbudowanym z jego pull requestów.
+* Obrazy są budowane przez [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  i wypychane do GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, wraz z obrazami środowiska
+  uruchomieniowego. Workflow i jego logi są publiczne, więc każdy może zobaczyć, co trafiło do obrazu.
+* Obrazy aplikacji i środowiska uruchomieniowego działają jako nieuprzywilejowany użytkownik `node` (uid 1000), nigdy jako root.
+
+---
+
+## Wspierane wersje
+
+Poprawki bezpieczeństwa trafiają do najnowszego wydania każdej wspieranej linii:
+
+| Wersja | Otrzymuje poprawki bezpieczeństwa |
+|---|---|
+| 7.x | Tak |
+| 6.5.x | Tak |
+| Starsze niż 6.5 | Nie: poprawką jest aktualizacja |
+
+[Przewodnik aktualizacji](../upgrading/) opisuje przejście na nowsze wydanie, a [Aktualizacja do v7](../upgrade-7.html) przejście z 6.5.
diff --git a/i18n/pl/_security_assessment/security-assessment/faq.md b/i18n/pl/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..1e716e9
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: FAQ oceny
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# FAQ oceny
+{: .no_toc }
+
+Krótkie odpowiedzi na pytania, które najczęściej zadają kwestionariusze bezpieczeństwa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dane i hosting
+
+Gdzie znajdują się dane i kto ma do nich dostęp:
+
+| Pytanie | Odpowiedź |
+|---|---|
+| Gdzie przechowywane są nasze dane? | W bazie danych MySQL lub MariaDB, którą utrzymujesz, oraz w folderze trwałym twojej instancji. AnsibleForms jest hostowany samodzielnie i nie stoi za nim żadna usługa w chmurze. |
+| Czy wysyła dane swoim twórcom? | Nie. Nie ma telemetrii, raportowania użycia ani sprawdzania aktualizacji. |
+| Z czym się łączy? | Tylko z systemami skonfigurowanymi przez administratora: zobacz [Połączenia wychodzące](measures.html#outbound-connections). |
+| Czy używa AI lub wysyła dane do dostawcy modeli? | Tylko przy włączonym [asystencie czatu](../chat/), który domyślnie jest wyłączony. Wysyła wtedy definicje formularzy i wypełniane wartości do skonfigurowanego przez ciebie dostawcy. |
+| Czy może działać bez dostępu do internetu? | Tak. Aplikacja nie potrzebuje dostępu do internetu; playbooki potrzebują tego, do czego sięgają ich zadania. |
+
+---
+
+## Szyfrowanie
+
+Co jest szyfrowane i jakimi kluczami:
+
+| Pytanie | Odpowiedź |
+|---|---|
+| Czy dane są szyfrowane w trakcie przesyłania? | Przez [HTTPS](../security/https.html), obsługiwany przez aplikację lub twój reverse proxy, oraz `wss://` między aplikacją a jej środowiskami uruchomieniowymi. |
+| Czy dane są szyfrowane w spoczynku? | Każdy przechowywany sekret jest szyfrowany przez aplikację algorytmem AES-256. Zadania i ich wyniki są przechowywane bez zmian: użyj szyfrowania w spoczynku samej bazy danych. Zobacz [Przechowywane sekrety](measures.html#stored-secrets). |
+| Kto ma klucze? | Ty: [`ENCRYPTION_SECRET`](../security/secrets.html) ustawiasz sam, jest trzymany poza kopiami zapasowymi i można go rotować. |
+| Czy sekrety mogą zostać w naszym vaulcie? | Tak: [HashiCorp Vault i CyberArk](../secret-stores/) są odczytywane wtedy, gdy zadanie ich potrzebuje. |
+
+---
+
+## Dostęp i rozliczalność
+
+Kto może się zalogować, co może robić i co jest rejestrowane:
+
+| Pytanie | Odpowiedź |
+|---|---|
+| Czy obsługuje single sign-on? | Tak: LDAP / Active Directory, OpenID Connect i Entra ID. Zobacz [Uwierzytelnianie](../authentication/). |
+| Czy obsługuje uwierzytelnianie wieloskładnikowe? | Przez single sign-on: obowiązuje MFA twojego dostawcy tożsamości. Konta lokalne nie mają własnego. |
+| Jak zarządza się uprawnieniami? | Rolami mapowanymi na grupy, sprawdzanymi przez serwer przy każdym żądaniu. Zobacz [Uprawnienia](measures.html#permissions). |
+| Czy jest dziennik audytu? | Tak: każda zmiana i każda odrzucona próba, przechowywane domyślnie 365 dni, z możliwością przekazywania do syslog. Zobacz [Dziennik audytu](measures.html#audit-trail). |
+| Czy jest domyślne hasło? | Pierwsze konto administratora ma publiczne domyślne hasło, które trzeba zmienić przy pierwszym logowaniu. Zobacz [Konto administratora](../security/hardening.html#the-admin-account). |
+
+---
+
+## Podatności i aktualizacje
+
+Jak problemy są znajdowane, naprawiane i ogłaszane:
+
+| Pytanie | Odpowiedź |
+|---|---|
+| Czy znaleziono podatności? | Tak. Każda opublikowana jest wymieniona w [Biuletynach bezpieczeństwa](advisories.html), z wersją, która ją naprawiła. |
+| Jak zgłosić podatność? | Prywatnie, przez GitHub: zobacz [Zgłaszanie podatności](reporting.html). |
+| Jak sprawdzany jest kod? | Analiza statyczna CodeQL i dependency review przy każdym pull requeście, testy automatyczne i aktualizacje Dependabot. Zobacz [Bezpieczne wytwarzanie](development.html). |
+| Które wersje otrzymują poprawki bezpieczeństwa? | 7.x i 6.5.x. Zobacz [Wspierane wersje](development.html#supported-versions). |
+| Jak dowiedzieć się o nowym biuletynie? | Obserwuj alerty bezpieczeństwa repozytorium na GitHubie. Zobacz [Powiadomienia o nowych biuletynach](advisories.html#being-told-of-new-advisories). |
+| Czy przeprowadzono testy penetracyjne? | Nie opublikowano raportu z testów penetracyjnych przeprowadzonych przez stronę trzecią. Kod jest publiczny, więc twój zespół lub tester może go ocenić, a ustalenia zgłasza się jak wyżej. |
+
+---
+
+## Obrazy i łańcuch dostaw
+
+Skąd pochodzą obrazy i jak je sprawdzić:
+
+| Pytanie | Odpowiedź |
+|---|---|
+| Gdzie publikowane są obrazy? | W GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, budowane przez publiczne workflowy GitHub Actions. Zobacz [Wydania i obrazy](development.html#releases-and-images). |
+| Czy kontenery działają jako root? | Nie: jako nieuprzywilejowany użytkownik `node`. |
+| Czy obrazy są podpisane? | Jeszcze nie. Pobieraj je przez digest (`@sha256:...`), aby mieć pewność, że uruchamiasz przejrzany obraz. |
+| Czy jest SBOM? | Z obrazami nie jest jeszcze publikowany. Skaner taki jak Trivy lub Syft zbuduje go z obrazu. |
+| Czy obrazy są skanowane pod kątem podatności? | Nie w potoku wydań. Ich obrazy bazowe są przypięte przez digest i aktualizowane przez Dependabot; skanuj obrazy we własnym rejestrze, aby stosować własną politykę. |
+| Na jakiej licencji jest udostępniany? | GPL-3.0, open source, bez gwarancji. |
diff --git a/i18n/pl/_security_assessment/security-assessment/index.md b/i18n/pl/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..502d4f0
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Przegląd
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Ocena bezpieczeństwa
+{: .no_toc }
+
+Dla przeglądów bezpieczeństwa: zabezpieczenia, proces wytwarzania i biuletyny
+{: .fs-6 .fw-300 }
+
+---
+
+## W skrócie
+
+AnsibleForms uruchamia playbooki i przechowuje ich poświadczenia, więc jest częścią twojego łańcucha zaufania:
+
+* Jest **hostowany samodzielnie**: działa na twojej infrastrukturze, przechowuje dane w twojej bazie danych i niczego nie wysyła swoim twórcom.
+* Jest **open source** (GPL-3.0): kod, jego potoki i każdy biuletyn są publiczne.
+* Każdy przechowywany sekret jest **szyfrowany**, każda zmiana **audytowana**, a **role** sprawdzane przy każdym żądaniu.
+* Podatności są **zgłaszane prywatnie**, naprawiane w każdym wspieranym wydaniu i **publikowane**.
+
+---
+
+## W tej sekcji
+
+Strony odpowiadają na pytania przeglądu bezpieczeństwa, od architektury po listę CVE:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Zabezpieczenia](measures.html) | Logowanie, uprawnienia, przechowywane sekrety, dziennik audytu, przeglądarka, serwer, połączenia i kontenery |
+| [Bezpieczne wytwarzanie](development.html) | Jak zmiana jest przeglądana i testowana, analiza kodu i zależności, jak budowane są obrazy, wspierane wersje |
+| [Zgłaszanie podatności](reporting.html) | Jak prywatnie zgłosić problem i co dzieje się potem |
+| [Biuletyny bezpieczeństwa](advisories.html) | Każda opublikowana podatność, z jej CVE, istotnością i wersją z poprawką |
+| [FAQ oceny](faq.html) | Krótkie odpowiedzi na pytania, które najczęściej zadają kwestionariusze bezpieczeństwa |
+
+Aby zabezpieczyć instancję, a nie ją ocenić, zobacz [Bezpieczeństwo](../security/) w przewodniku administratora.
diff --git a/i18n/pl/_security_assessment/security-assessment/measures.md b/i18n/pl/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..8fa66ae
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Zabezpieczenia
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Zabezpieczenia
+{: .no_toc }
+
+Jak chronione są logowanie, uprawnienia, sekrety i połączenia
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Gdzie działa
+
+AnsibleForms jest hostowany samodzielnie, na twojej infrastrukturze, z danymi w utrzymywanej przez ciebie bazie danych.
+
+* Nie ma usługi chmurowej AnsibleForms ani serwera licencji, nie ma też telemetrii ani sprawdzania aktualizacji.
+* Interfejs jest serwowany przez samą aplikację i nie ładuje niczego z innych witryn.
+* Aplikacja łączy się tylko z systemami skonfigurowanymi przez administratora, wymienionymi w [Połączeniach wychodzących](#outbound-connections).
+
+Elementy i to, co każdy z nich przechowuje:
+
+| Element | Co robi | Co przechowuje |
+|---|---|---|
+| Aplikacja | Interfejs webowy, REST API, harmonogram | Żadnych własnych danych: wszystko jest w bazie danych |
+| MySQL lub MariaDB | Baza danych aplikacji | Użytkowników, grupy, poświadczenia (zaszyfrowane), zadania z ich extravars i wynikiem, dziennik audytu |
+| Środowisko uruchomieniowe (RTE) | Uruchamia playbooki, we własnym kontenerze | Pliki uruchamianych zadań, a sekrety zadania tylko w czasie jego działania |
+| Folder trwały | Konfiguracja, formularze, playbooki i przesłane pliki | Pliki używane przez formularze i playbooki |
+
+Pełny obraz znajdziesz w [Jak to działa](../how-it-works.html), a opis środowiska uruchomieniowego w [RTE](../rte/).
+
+---
+
+## Logowanie
+
+Każda strona i każde wywołanie API, które odczytuje lub zmienia dane, wymaga zalogowanego użytkownika. Nieliczne punkty końcowe dostępne bez logowania obsługują
+samo logowanie, wersję, nazwę i logo instancji, dokumentację API oraz konfigurację bazy danych przy pierwszym starcie,
+którą wyłącza [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0`:
+
+| Metoda | Jak działa |
+|---|---|
+| Konta lokalne | Hasła haszowane bcrypt, [minimalna długość](../security/hardening.html#sign-in-limits-and-passwords), a publiczne domyślne hasło administratora trzeba zmienić przy pierwszym logowaniu |
+| LDAP / Active Directory | Katalog sprawdza hasło, a jego grupy są mapowane na role. Zobacz [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Single sign-on przez twojego dostawcę tożsamości, który zapewnia też własne uwierzytelnianie wieloskładnikowe. Zobacz [Uwierzytelnianie](../authentication/) |
+
+* Nieudane logowania [blokują konto](../security/hardening.html#sign-in-limits-and-passwords), a logowanie ma limit częstotliwości.
+* Logowanie zwraca podpisany token dostępu ważny 30 minut i token odświeżania ważny 24 godziny.
+* Tokeny można unieważnić przed wygaśnięciem: wylogowanie, zmiana hasła, zablokowanie użytkownika i odwołanie tokenu API unieważniają je
+  na wszystkich węzłach jednocześnie, zobacz [Tokeny](../security/secrets.html#tokens).
+* AnsibleForms nie ma własnego uwierzytelniania wieloskładnikowego: tam, gdzie jest wymagane, używaj single sign-on.
+
+---
+
+## Uprawnienia
+
+To, co użytkownik może robić, wynika z ról jego grup i jest sprawdzane przez serwer przy każdym żądaniu:
+
+* Role definiuje się w [config.yaml](../config/roles.html): które formularze widzi użytkownik i jakie ma opcje,
+  takie jak projektant, strony ustawień czy zadania innych użytkowników.
+* Serwer sprawdza każde uruchomienie względem reguł formularza (jego pól, ich wartości i dostępu użytkownika), także
+  uruchomienia przez REST API, zobacz [Weryfikacja uruchomienia](../launch-validation/).
+* Rola administratora z założenia uruchamia dowolny playbook. Pozostałe role dostają tylko to, co zostało przyznane: użytkownik z kilkoma rolami otrzymuje
+  opcję tylko wtedy, gdy żadna z tych ról jej nie odmawia, więc jedna restrykcyjna rola wystarczy, by ją wstrzymać.
+
+---
+
+## Przechowywane sekrety
+
+Hasła, tokeny i klucze są szyfrowane przed zapisaniem do bazy danych:
+
+* Każdy przechowywany sekret, czyli poświadczenia, hasło powiązania LDAP, tokeny runnerów, sekrety klientów single sign-on, adresy
+  webhooków i klucze API, jest szyfrowany algorytmem AES-256 z losowym wektorem inicjalizującym dla każdej wartości, przy użyciu
+  ustawionego przez ciebie [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets).
+* Żadne wywołanie API ani strona ustawień nie pokazuje przechowywanego sekretu, a kopie zapasowe pomijają sekrety główne.
+* Sekrety mogą zostać w twoim vaulcie: [HashiCorp Vault i CyberArk](../secret-stores/) są odczytywane wtedy, gdy zadanie ich potrzebuje.
+* Sekrety zadania docierają do środowiska uruchomieniowego zapieczętowane AES-256-GCM, kluczem wyprowadzonym z jego tokenu.
+* Extravars, których nazwa wygląda na sekret, są maskowane w widoku zadania, a pola haseł zawsze, zobacz [Dane zadań](../security/hardening.html#job-data).
+
+Reszta bazy danych, czyli zadania, ich extravars i wyniki, jest przechowywana bez zmian: chroń ją szyfrowaniem w spoczynku i kontrolą dostępu
+samej bazy danych, zobacz [Baza danych](../security/hardening.html#the-database).
+
+---
+
+## Dziennik audytu
+
+Każda zmiana i każda odrzucona próba są rejestrowane:
+
+* Każde utworzenie, zmiana i usunięcie, przez interfejs lub API, trafia do dziennika audytu z użytkownikiem, jego
+  adresem, akcją, obiektem i wynikiem. Rejestrowane są też odmowy i logowania, łącznie z nieudanymi.
+* Wartości wyglądające na sekrety są redagowane przed zapisaniem.
+* Dziennik jest domyślnie przechowywany 365 dni i można go kopiować do syslog przez UDP, TCP lub TLS.
+
+---
+
+## W przeglądarce
+
+Interfejs jest chroniony przed kodem wstrzykniętym do strony:
+
+* [Content-Security-Policy](../security/hardening.html#the-content-security-policy) dopuszcza tylko własne skrypty i ramki aplikacji.
+* Każda odpowiedź zawiera nagłówki ochronne: nosniff, ochronę przed osadzaniem w ramkach i HSTS przez HTTPS.
+* HTML formularzy, teksty pomocy i odpowiedzi czatu są oczyszczane, a wynik zadań jest escapowany.
+
+---
+
+## Na serwerze
+
+Kod obsługujący dane od użytkownika unika klasycznych wstrzyknięć:
+
+* Zapytania do bazy danych przekazują wartości jako parametry, nigdy jako tekst wklejony w zapytanie.
+* Polecenia, łącznie z git, są uruchamiane z listy argumentów, nigdy przez powłokę, więc znaki powłoki nic nie robią.
+* Wyrażenia serwerowe przechodzą przez [sanitizer wyrażeń](../security/hardening.html#expressions-and-outbound-calls), a ich wywołania REST przez filtr hostów.
+* [Serwer MCP](../mcp/), [asystent czatu](../chat/) i punkt końcowy metryk są wyłączone, dopóki ich nie włączysz.
+
+---
+
+## Połączenia
+
+Ruch do i z AnsibleForms może być szyfrowany od końca do końca:
+
+* Aplikacja sama serwuje [HTTPS](../security/https.html) lub działa za twoim reverse proxy.
+* Środowisko uruchomieniowe komunikuje się z aplikacją przez WebSocket, `wss://` przy adresie HTTPS, a aplikacja
+  przypina certyfikat środowiska przychodzącego, zobacz [Tryby RTE](../rte/modes.html).
+* LDAP, single sign-on, runnery, git, magazyny sekretów i wywołania REST wyrażeń sprawdzają certyfikat
+  serwera, z którym się łączą, chyba że administrator wyłączy to sprawdzanie dla serwera z certyfikatem samopodpisanym.
+
+### Połączenia wychodzące
+
+AnsibleForms łączy się tylko z tym, co skonfiguruje administrator:
+
+| Połączenie | Kiedy |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (logowanie Microsoft i Graph) | Gdy skonfigurowano tę metodę logowania |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Gdy formularz działa na tym runnerze |
+| Serwery git | Gdy skonfigurowano repozytorium |
+| Serwer poczty, Slack, Teams, Telegram, webhooki | Gdy skonfigurowano kanał powiadomień |
+| HashiCorp Vault, CyberArk | Gdy skonfigurowano magazyn sekretów |
+| Dostawca modeli (Anthropic, OpenAI i inni) | Tylko przy włączonym [asystencie czatu](../chat/), który domyślnie jest wyłączony |
+| Hosty i API wskazane w formularzach | Gdy wywołują je wyrażenia formularza lub playbook |
+| Serwery syslog | Gdy skonfigurowano przekazywanie audytu lub logów |
+
+---
+
+## Kontenery
+
+Obrazy są budowane tak, aby działały z jak najmniejszymi uprawnieniami:
+
+* Aplikacja i środowisko uruchomieniowe działają jako nieuprzywilejowany użytkownik `node`, a nie jako root.
+* Są zbudowane na odchudzonych obrazach Debiana przypiętych przez digest, zobacz [Bezpieczne wytwarzanie](development.html#code-analysis-and-dependencies).
+* Aplikacja nasłuchuje na jednym porcie, 8000.
+
+Kroki zabezpieczania nowej instancji opisuje [Utwardzanie](../security/hardening.html).
diff --git a/i18n/pl/_security_assessment/security-assessment/reporting.md b/i18n/pl/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..8c9f793
--- /dev/null
+++ b/i18n/pl/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Zgłaszanie podatności
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Zgłaszanie podatności
+{: .no_toc }
+
+Jak prywatnie zgłosić problem z bezpieczeństwem i co dzieje się potem
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Zgłoś to prywatnie
+
+AnsibleForms przechowuje poświadczenia i tokeny vault, więc nigdy nie zgłaszaj problemu z bezpieczeństwem w publicznym issue:
+
+1. Otwórz **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: prywatny biuletyn widoczny tylko dla maintainerów.
+2. Jeśli ta strona nie jest dla ciebie dostępna, otwórz zwykłe issue, w którym napiszesz tylko, że masz zgłoszenie dotyczące bezpieczeństwa, i poprosisz
+   o prywatny kanał: bez szczegółów, bez sposobu odtworzenia, bez numerów wersji. Maintainer otworzy prywatny biuletyn i
+   zaprosi cię do niego.
+
+Pełna polityka to [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) repozytorium.
+
+---
+
+## Co zawrzeć
+
+Im więcej z tych informacji zawiera zgłoszenie, tym szybciej problem zostanie naprawiony:
+
+* Co zyskuje atakujący: dane innego użytkownika, playbook, którego nie może uruchamiać, hosta lub uprawnienia administratora.
+* Wersję i sposób wdrożenia: Docker, Kubernetes lub instalacja natywna.
+* Sposób odtworzenia lub żądanie, które wywołuje problem.
+* Czy wymaga zalogowanego użytkownika i z jakimi [opcjami ról](../config/roles.html).
+
+---
+
+## Co dzieje się potem
+
+Zgłoszenie przechodzi przez ten sam prywatny biuletyn od pierwszej wiadomości do publikacji:
+
+| Etap | Co otrzymujesz |
+|---|---|
+| Potwierdzenie | Potwierdzenie, że zgłoszenie dotarło, i informację, czy udało się je odtworzyć |
+| Przyjęte | Poprawkę w następnym wydaniu każdej [wspieranej wersji](development.html#supported-versions) i opublikowany biuletyn z podziękowaniem dla ciebie, chyba że wolisz nie być wymieniony |
+| Odrzucone | Uzasadnienie, zwykle takie, że dane zachowanie wymaga uprawnienia, które zgłaszający już miał |
+
+Po wydaniu poprawki biuletyn zostaje opublikowany i pojawia się w [Biuletynach bezpieczeństwa](advisories.html).
+
+---
+
+## Zakres
+
+Polityka wyznacza granicę tam, gdzie wyznacza ją model ról:
+
+| W zakresie | Poza zakresem |
+|---|---|
+| Wszystko, do czego zalogowany użytkownik może dotrzeć poza tym, na co pozwala mu rola | Ustalenia, które wymagają wcześniejszego przejęcia konta administratora: administrator uruchamiający dowolny playbook to sama istota produktu |
+| Wszystko, do czego można dotrzeć bez logowania | Raporty skanerów bez wykazanego wpływu |
+| Przechowywane poświadczenia, które stają się czytelne lub trafiają do logu | |
+| Wstrzyknięcie do powłoki, bazy danych lub przeglądarki | |
diff --git a/i18n/pl/_use/designer/index.md b/i18n/pl/_use/designer/index.md
new file mode 100644
index 0000000..5dc6592
--- /dev/null
+++ b/i18n/pl/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Projektant
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Projektant
+{: .no_toc }
+
+Edycja formularzy, playbooków, inwentarzy i workflowów w przeglądarce
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla autorów formularzy: sekcje projektanta i to, co pokazuje każda z ich kart.
+
+Projektant wymaga [opcji roli](../config/roles.html#role-options) `showDesigner`. Edytuje jeden element naraz,
+formularz, playbook lub plik workflow, a jego sekcje są w lewym menu. Każdy rodzaj pliku wymaga też własnej opcji, wszystkie
+domyślnie włączone: `allowPlaybookDesign` dla **Playbooki**, `allowWorkflowDesign` dla **Przepływy pracy**,
+`allowInventoryDesign` dla **Inwentarze** i `allowVarsFileDesign` dla **Pliki zmiennych**. Bez niej sekcja jest
+tylko do odczytu, a serwer odmawia zapisywania, tworzenia, usuwania i wypychania jej plików; formularze i workflowy nadal mogą je wybierać.
+**Formularze**, **Kategorie** i **Stałe** w ten sam sposób wymagają `allowFormDesign`: bez niej są tylko do odczytu, a serwer
+odmawia ich zapisywania, pobierania (pull) i wypychania (push). Edytować może tylko jedna osoba naraz: zobacz [Blokada projektanta](lock.html).
+
+---
+
+## Sekcje
+
+Każda sekcja edytuje jeden rodzaj pliku, przechowywany lokalnie lub w [repozytorium](../repositories/):
+
+| Sekcja | Co edytuje |
+|---|---|
+| **Formularze** | Pliki formularzy |
+| **Kategorie** | Kategorie z `config.yaml` |
+| **Stałe** | Stałe z `config.yaml` |
+| **Pliki zmiennych** | Pliki zmiennych ładowane przez formularze |
+| **Playbooki** | Playbooki uruchamiane przez formularze i workflowy |
+| **Inwentarze** | Inwentarze: `inventory.yaml`, `group_vars` i `host_vars` |
+| **Przepływy pracy** | Pliki [workflow](../workflows/) |
+
+Sekcje z plikami wyświetlają je w eksploratorze plików i otwierają pierwszy z nich; sekcja, która nie ma jeszcze plików, informuje o tym.
+Sekcja **Formularze** i każda sekcja plików mają na początku paska narzędzi przycisk **Nowy plik**: w Inwentarzach tworzy on nowy
+inwentarz, w Przepływach pracy nowy, pusty workflow. Lupa eksploratora otwiera pole, które filtruje jego pliki po nazwie.
+
+Pole wyszukiwania w wierszu tytułu znajduje tekst w otwartym YAML: zaznacza każde miejsce, w którym się pojawia. Działa na
+karcie **YAML**, gdy blokada projektanta należy do ciebie.
+
+---
+
+## Karty
+
+Każda sekcja ma te same trzy karty, wszystkie na tym samym YAML: zmiana w jednej jest widoczna w pozostałych, a **Zapisz** ją zapisuje.
+
+- **YAML** to plik w takiej postaci, w jakiej jest zapisany.
+- **Wizualny** edytuje go za pomocą pól. Zmieniają się tylko klucze, których dotyczy edycja, więc komentarze i reszta pozostają bez zmian.
+- **Podgląd** pokazuje, co plik robi, i niczego nie edytuje.
+
+Co pokazują karty Wizualny i Podgląd w poszczególnych sekcjach:
+
+| Sekcja | Wizualny | Podgląd |
+|---|---|---|
+| **Formularze** | Ustawienia formularza i jego pola, z listami playbooków, inwentarzy i workflowów projektanta | Formularz w obecnej postaci, łącznie z niezapisanymi zmianami; jego wysłanie niczego nie uruchamia |
+| **Kategorie** | Kategorie jako tabela, do edycji | Menu strony Formularze, zbudowane z nich |
+| **Stałe** | Stałe jako konspekt, do edycji (klucz przesuwa się klawiszami strzałek) | Każda stała z odwołaniem do niej, `$(NAME)`, do skopiowania, oraz formularze, które jej używają |
+| **Pliki zmiennych** | Zmienne, do edycji | Każda zmienna z odwołaniem do niej w playbooku, {% raw %}`{{ name }}`{% endraw %}, do skopiowania, oraz formularze, które ładują plik |
+| **Playbooki** | Play: nazwa, hosty, **Become**, **Zbieraj fakty** i role każdego play oraz jego zadania, każde z modułem i argumentami | Konspekt playbooka: jego play z hostami, rolami i zadaniami oraz importowane przez niego playbooki |
+| **Inwentarze** | Grupy, ich grupy podrzędne, ich hosty i zmienne ustawiane przez każde z nich | Inwentarz jako drzewo, z jego `group_vars` i `host_vars` |
+| **Przepływy pracy** | Graf workflow, do [edycji](../workflows/designer.html) | [Próbne uruchomienie](../workflows/designer.html#trying-it-out): kliknij węzeł, aby zakończył się błędem |
+
+Gdy YAML nie da się odczytać, karty Wizualny i Podgląd podają przyczynę, z przyciskiem **Pokaż w YAML**, który otwiera YAML w odpowiednim wierszu.
diff --git a/i18n/pl/_use/designer/lock.md b/i18n/pl/_use/designer/lock.md
new file mode 100644
index 0000000..e4c470a
--- /dev/null
+++ b/i18n/pl/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: Blokada projektanta
+parent: Projektant
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# Blokada projektanta
+{: .no_toc }
+
+Edytuje tylko jedna osoba naraz
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Przejęcie blokady
+
+Projektant jest wyłączony, dopóki go nie włączysz przełącznikiem w prawym górnym rogu projektanta. Włączenie go przejmuje
+blokadę: od tej chwili tylko ty możesz zapisywać, dopóki go znowu nie wyłączysz.
+
+Bez blokady projektant pokazuje **Projektant nie jest aktywny** i niczego nie można edytować.
+
+Zapisy nigdy się nie nakładają: od wersji 7.3.0, gdy trwa zapis, push lub ładowanie, drugie **Zapisz** (podwójne kliknięcie lub przytrzymane Ctrl+S) jest
+ignorowane, więc nie może zapisać drugiej kopii zapasowej ani drugiego commita, który ścigałby się z pierwszym.
+
+---
+
+## Gdy ma ją ktoś inny
+
+Gdy blokadę trzyma inny użytkownik, projektant pokazuje **Projektant jest używany przez** tego użytkownika i nic poza tym: żadnych sekcji,
+żadnych plików.
+
+Przełącznik jest włączony, ale wyszarzony, a obok niego widnieje **Zablokowane przez** z nazwą użytkownika. Blokadę możesz przejąć, gdy
+ten użytkownik wyłączy projektant. Każdy otwarty projektant od razu widzi przejęcie lub zwolnienie blokady, bez przeładowania.
+
+Gdy dwóch użytkowników włączy projektant w tej samej chwili, blokadę dostaje jeden z nich. Od wersji 7.3.0 drugi widzi, kto ją trzyma,
+a każdy edytor pozostaje tylko do odczytu, więc nie da się wpisać niczego, czego nie można by zapisać.
+
+---
+
+## Zwalnianie cudzej blokady
+
+Administrator może zwolnić blokadę trzymaną przez kogoś innego, na przykład gdy ten ktoś poszedł do domu z otwartym projektantem.
+
+**Zwolnij**, obok **Zablokowane przez**, widzą tylko administratorzy. Przed zwolnieniem pojawia się pytanie: niezapisane zmiany użytkownika przepadną.
+
+Od wersji 7.3.0 użytkownik, którego blokada została zwolniona, dostaje o tym informację wraz z tym, kto to zrobił: **Twoja blokada projektanta została zwolniona przez** z nazwą administratora,
+oraz **Niezapisanych zmian nie można już zapisać.** Jego projektant nie przejmuje blokady z powrotem sam; użytkownik włącza go ponownie,
+gdy chce kontynuować.
+
+---
+
+## Zapomniana blokada
+
+Nieużywana blokada zwalnia się sama, więc nikt nie czeka na projektant, którego nikt nie ma otwartego.
+
+Otwarty projektant posiadacza blokady stale informuje serwer, że nadal jest obecny. Gdy serwer nie dostanie od niego sygnału przez
+5 minut, bo przeglądarka została zamknięta, komputer wyłączony lub zniknęła sieć, blokada znów jest wolna. Gdy
+posiadacz wróci do projektanta, ponownie przejmuje blokadę, jeśli nikt inny jej nie ma. Wyjątkiem jest zwolnienie przez administratora: po nim
+blokada nie jest przejmowana z powrotem.
diff --git a/i18n/pl/_use/jobs/actions.md b/i18n/pl/_use/jobs/actions.md
new file mode 100644
index 0000000..8d175e5
--- /dev/null
+++ b/i18n/pl/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Akcje na zadaniach
+parent: Zadania
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Akcje na zadaniach
+{: .no_toc }
+
+Uruchamianie, przerywanie, ponowne uruchamianie, zatwierdzanie lub odrzucanie i usuwanie zadania
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Uruchamianie zadania
+
+Każde zadanie zaczyna się od formularza. Otwórz go ze strony **Formularze**, wypełnij pola i naciśnij **Wyślij**:
+
+1. Formularz jest walidowany w przeglądarce, a wartości pól są wysyłane do serwera.
+2. Serwer tworzy zadanie i zwraca jego numer; uruchamiają się akcje [`onSubmit`](../forms/job-status-action.html) formularza.
+3. Wynik zadania pojawia się pod formularzem i odświeża się co dwie sekundy, aż zadanie się zakończy.
+
+Zadanie pojawia się też na stronie **Zadania**, gdzie możesz je później śledzić.
+
+### Kto może uruchomić formularz
+
+Formularz jest wyświetlany i można go uruchomić dla użytkowników, którzy mają jedną z [ról](../config/roles.html) z jego listy `roles`.
+Rola `default`, którą ma każdy użytkownik, udostępnia formularz każdemu, kto może się zalogować.
+
+### Przed wysłaniem
+
+Pasek nad polami oferuje kilka narzędzi, każde widoczne tylko wtedy, gdy pozwala na to twoja rola:
+
+| Przycisk | Co robi | Opcja roli |
+|---|---|---|
+| **Pokaż extravars** | Podgląd extravars, które otrzyma zadanie, w trakcie wypełniania pól | `showExtraVars` |
+| **verbose** | Uruchamia zadanie w trybie verbose | `allowVerboseMode` |
+| **Wczytaj z zapisanych** | Wypełnia pola z [zapisanego zadania](stored-jobs.html) | `allowStoredJobs` |
+| **Przeładuj ten formularz** | Ponownie ładuje formularz z wartościami domyślnymi | brak |
+
+### Wybory przy uruchamianiu
+
+Formularz może pozwolić użytkownikom wybrać niektóre opcje Ansible przy uruchamianiu, deklarując pole o zastrzeżonej nazwie.
+Wartość pola nadpisuje wtedy własne ustawienie formularza:
+
+| Nazwa pola | Nadpisuje | Typowy typ pola |
+|---|---|---|
+| `__check__` | Tryb check, uruchomienie próbne, które niczego nie zmienia | `checkbox` |
+| `__diff__` | Tryb diff, który pokazuje, co by się zmieniło | `checkbox` |
+| `__limit__` | Hosty, na których działa playbook | `text` lub `enum` |
+| `__tags__` | Tagi do uruchomienia | `text` lub `enum` |
+| `__inventory__` | Inwentarz | `enum` |
+| `__playbook__`, `__template__` | Playbook lub szablon AWX / AAP | `enum` |
+
+Na przykład formularz, który oferuje uruchomienie próbne i ograniczenie hostów:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+Serwer akceptuje te nazwy tylko z formularza, który deklaruje je jako pola, więc uruchomienie przez API nie może dodać ich
+samodzielnie. Nadpisywane przez nie właściwości opisano przy [Formularzach Ansible](../forms/ansible.html) i [Formularzach AWX](../forms/awx.html).
+
+### Co może zatrzymać uruchomienie
+
+Uruchomienie nie zawsze od razu staje się działającym zadaniem:
+
+* **Nieprawidłowe pola** : formularz nie zostaje wysłany, a każde pole, które nie przeszło walidacji, pokazuje przyczynę.
+* **Weryfikacja uruchomienia** : gdy [weryfikacja uruchomienia](../launch-validation/) jest ustawiona na `enforce`, serwer ponownie sprawdza wartości
+  i odrzuca uruchomienie, które łamie reguły formularza.
+* **Zatwierdzenie** : formularz z [punktem zatwierdzenia](../forms/approval.html) tworzy zadanie, które następnie czeka w stanie
+  `approve`; zobacz [Zatwierdzanie lub odrzucanie zadania](#approve-or-reject-a-job).
+
+Gdy zadanie się kończy, [powiadomienia](../forms/notifications.html) formularza wysyłają swoje e-maile i wiadomości na kanały, a jego akcje
+stanu zadania się uruchamiają.
+
+### Inne sposoby uruchomienia zadania
+
+Formularz może też uruchomić zadanie bez naciskania **Wyślij** przez człowieka:
+
+| Uruchamiane przez | Jak | Strona |
+|---|---|---|
+| Uruchomienie później lub harmonogram cron | **Uruchom później (jednorazowo)** lub **Harmonogram (cykliczny)** obok **Wyślij** | [Harmonogramy](schedules.html) |
+| Skrypt lub potok | `POST /api/v2/job` z tokenem API | [Zadania w REST API](../api/jobs.html) |
+| Agent AI | Narzędzie `launch_job` serwera MCP | [Narzędzia MCP](../mcp/tools.html) |
+| Rozmowa | Asystent czatu wypełnia formularz i go uruchamia | [Asystent czatu](../chat/) |
+| Wcześniejsze zadanie | **Uruchom ponownie**, poniżej | [Ponowne uruchamianie zadania](#relaunch-a-job) |
+
+---
+
+## Przerywanie zadania
+
+**Przerwij** w menu wiersza (⋮) listy lub **Przerwij zadanie** na stronie zadania zatrzymuje zadanie o stanie `running`. Po potwierdzeniu
+AnsibleForms oznacza zadanie do przerwania:
+
+* **`ansible`**: RTE zatrzymuje proces playbooka (ze wszystkimi jego workerami), a zadanie kończy się jako `aborted` z
+  `... was aborted by the operator`. Zadanie, które wciąż czeka na wolne RTE, jest przerywane, zanim się uruchomi.
+* **Zadanie szablonu** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): AnsibleForms prosi runner o anulowanie lub zatrzymanie
+  zadania, a zadanie kończy się jako `aborted`. Gdy runner odmawia, wynik pokazuje `Abort request denied`, a po nim
+  `reverting abort request`, i zadanie działa dalej. Build Jenkins, który wciąż jest w kolejce, zostaje z niej usunięty.
+* **`workflow`**: działające zadania węzłów są przerywane i nic więcej się nie uruchamia (zobacz
+  [Uruchamianie workflow](../workflows/running.html#abort)).
+* **`multistep`**: kroki, które jeszcze się nie zaczęły, są pomijane (`skipping: [Abort is requested]`), a zadanie główne
+  kończy się jako `aborted`. Krok, który już działa, jest osobnym zadaniem: otwórz go i przerwij, aby też go zatrzymać.
+
+Możesz przerywać własne zadania; administrator lub, od wersji 7.3.0, użytkownik, którego rola ustawia `manageAllJobs`, może przerwać dowolne zadanie. `showAllJobLogs` pozwala
+użytkownikowi widzieć zadania innych użytkowników, ale nie przerywać ich.
+
+---
+
+## Ponowne uruchamianie zadania
+
+**Uruchom ponownie** w menu wiersza (⋮) listy lub **Uruchom zadanie ponownie** na stronie zadania uruchamia nowe zadanie na podstawie zakończonego. Jest dostępne dla każdego
+zadania, które nie ma stanu `running` ani nie czeka na zatwierdzenie, dla użytkowników, których rola ustawia opcję roli `allowJobRelaunch`.
+
+Okno dialogowe oferuje:
+
+* **Uruchom ponownie**: uruchamia zadanie ponownie z wartościami, z którymi działało, jako nowe zadanie w twoim imieniu.
+* **Tryb szczegółowy (verbose)**: uruchamia ponownie w trybie verbose; widoczne przy opcji roli `allowVerboseMode`.
+* **Edytuj wartości przed ponownym uruchomieniem**, a potem **Edytuj i uruchom ponownie**: otwiera formularz wstępnie wypełniony wartościami zadania, abyś mógł
+  je zmienić przed wysłaniem.
+
+Ponowne uruchomienie wymaga też, aby formularz na nie pozwalał (`allowRelaunch`, domyślnie true), a zadanie było **twoje własne**, chyba że
+jesteś administratorem lub, od wersji 7.3.0, masz `manageAllJobs`; `showAllJobLogs`, które do wersji 7.2 pozwalało ponownie uruchamiać dowolne zadanie, już tego nie robi. Jak ponowne uruchomienie jest sprawdzane względem reguł formularza i dlaczego formularz z
+polem hasła może je odrzucić, opisano w [Ponowne uruchamianie](../launch-validation/relaunching.html).
+
+### Ponowne uruchomienie ze wstępnie wypełnionymi danymi
+
+**Edytuj i uruchom ponownie** otwiera formularz z parametrem URL `prefillJobId`, którego możesz też użyć we własnym linku:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+Formularz ładuje wartości pól zapisane z zadaniem `61` i pokazuje `Formularz wypełniono danymi z poprzedniego zadania #61`.
+Wysłanie go uruchamia nowe zadanie, sprawdzane jak każde inne uruchomienie. Wstępne wypełnianie podlega tym samym zasadom co ponowne uruchomienie:
+
+* **Pola haseł nigdy nie są zapisywane**, więc nigdy nie są wstępnie wypełniane: wpisz je ponownie. Stałe również nie są zapisywane.
+* Wymagana jest opcja roli `allowJobRelaunch`, a zadanie musi być twoje (albo jesteś administratorem lub masz `manageAllJobs`).
+* Formularza z `allowRelaunch: false` nie można uruchomić ponownie ani wstępnie wypełnić:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Zadania sprzed wprowadzenia zapisywania wartości pól nie można wstępnie wypełnić, a formularz pokazuje zamiast tego błąd:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Zatwierdzanie lub odrzucanie zadania
+
+Zadanie z [punktem zatwierdzenia](../forms/approval.html) zatrzymuje się w stanie `approve` i czeka. Jest wyświetlane na stronie Zadania
+swoich zatwierdzających, czyli użytkowników z jedną z ról zatwierdzenia, aby mogli je znaleźć; od wersji 7.3.0 inni użytkownicy już go nie widzą.
+
+**Rozpatrz zatwierdzenie** jest dostępne dla administratorów i użytkowników, którzy mają jedną z ról zatwierdzenia: kliknięcie wiersza zadania,
+**Rozpatrz zatwierdzenie** w menu wiersza lub przycisk **Rozpatrz zatwierdzenie** na stronie zadania. Okno dialogowe pokazuje komunikat
+zatwierdzenia z wypełnionymi wartościami zadania (lub ogólny tekst, jeśli komunikatu nie ma) oraz formularz, id zadania, kto je uruchomił i
+kiedy, z linkiem do zadania; **Odrzuć** i **Zatwierdź** udzielają odpowiedzi:
+
+* **Zatwierdź**: zadanie jest kontynuowane, a jego stan wraca do `running`.
+* **Odrzuć**: zadanie kończy się jako `rejected`, a jego wynik zapisuje `rejected by <username>`.
+
+Zadania czekającego na zatwierdzenie nie można uruchomić ponownie ani usunąć ze strony Zadania; najpierw je zatwierdź lub odrzuć.
+
+Od wersji 7.3.0 użytkownik, który uruchomił zadanie, nie może go zatwierdzić, więc zawsze patrzy na nie druga osoba, choć nadal może je odrzucić,
+aby je wycofać. Administrator zawsze może zatwierdzać, łącznie z własnymi zadaniami. Formularz, którego punkt zatwierdzenia ustawia
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job), pozwala uruchamiającemu także zatwierdzić własne zadanie.
+
+---
+
+## Usuwanie zadania
+
+**Usuń** w menu wiersza (⋮) listy lub **Usuń zadanie** na stronie zadania usuwa zadanie wraz z jego wynikiem po potwierdzeniu.
+Usunięcie zadania wieloetapowego usuwa też jego kroki. Aby usunąć kilka zadań naraz, zaznacz je w pierwszej kolumnie listy i
+kliknij **Usuń (n)** nad nią.
+
+Możesz usuwać własne zadania. Administratorzy i, od wersji 7.3.0, użytkownicy z opcją roli `manageAllJobs` mogą usunąć dowolne zadanie; `showAllJobLogs`
+już na to nie pozwala. Rola, która ustawia `allowJobDeletion: false`, nie usuwa żadnego zadania, nawet własnego, więc historia zadań pozostaje kompletna. Na stronie
+zadania przycisk jest ukryty, gdy zadanie działa lub jest przerywane (z wyjątkiem administratorów i `manageAllJobs`) oraz gdy czeka na zatwierdzenie; na liście
+pozycja menu i pole wyboru są wyszarzone dla zadania, którego nie możesz usunąć.
diff --git a/i18n/pl/_use/jobs/cleanup.md b/i18n/pl/_use/jobs/cleanup.md
new file mode 100644
index 0000000..22ff953
--- /dev/null
+++ b/i18n/pl/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Czyszczenie
+parent: Zadania
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Czyszczenie
+{: .no_toc }
+
+Zadania przerwane przez restart i jak długo przechowywane są zakończone zadania
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Porzucone zadania
+
+Działające zadanie jest śledzone przez proces AnsibleForms, który je uruchomił. Gdy to śledzenie ustaje, zadanie zostaje oznaczone jako
+`abandoned`:
+
+* **Przy starcie** zadania, które ten proces śledził przed restartem, oraz zadania sprzed wersji 7, których nie śledzi żaden proces,
+  są oznaczane jako porzucone, jeśli nadal mają stan `running` lub są w trakcie przerywania; log pokazuje `Abandoned <n> jobs`. Zadanie, które
+  działa na RTE, nie jest ruszane: działa dalej bez procesu, który je uruchomił.
+* **Co minutę** zadania śledzone przez inny proces AnsibleForms (lub RTE), który przestał odpowiadać na 2 minuty, są
+  oznaczane jako porzucone; log pokazuje `Abandoned <n> jobs followed by a node that stopped answering`.
+* **Co godzinę** zadania, które wystartowały ponad dobę temu, nadal mają stan `running` i przez dobę nie zapisały żadnego wyniku, są oznaczane jako porzucone.
+  Zadanie działające na RTE również tu nie jest ruszane: RTE samo czyści swoje zadania przy restarcie.
+
+Od wersji 7.3.0 zadanie szablonu na AWX, AAP lub Ascender porzucone przez restart lub zatrzymany węzeł jest podejmowane ponownie, jeśli wystartowało
+w ciągu ostatnich 24 godzin: jeden proces AnsibleForms je przejmuje, znowu śledzi je na runnerze, a zadanie kończy się tym, co
+naprawdę się tam wydarzyło. Zadania na pozostałych runnerach, playbooki, workflowy i zadania wieloetapowe pozostają porzucone.
+
+Porzucony playbook mógł zostać wykonany częściowo. Sprawdź zarządzane hosty, zanim uruchomisz go ponownie; zobacz
+[Zadanie ma stan abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Przechowywanie zadań
+
+Zadania są przechowywane do czasu ich usunięcia, chyba że administrator ustawi okres przechowywania.
+
+Gdy ustawiono [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS), nocne zadanie (o 2:30) usuwa
+zakończone zadania, wraz z ich wynikiem i krokami, które zakończyły się dawniej niż podana liczba dni. Usuwa tylko zadania o
+stanie `success`, `failed`, `warning`, `aborted`, `rejected` lub `abandoned`, więc działające zadania i zadania czekające na
+zatwierdzenie są zachowywane bez względu na wiek. Wartość domyślna, `0`, zachowuje każde zadanie.
diff --git a/i18n/pl/_use/jobs/following.md b/i18n/pl/_use/jobs/following.md
new file mode 100644
index 0000000..0a6c8d3
--- /dev/null
+++ b/i18n/pl/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Śledzenie zadania
+parent: Zadania
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Śledzenie zadania
+{: .no_toc }
+
+Wynik na żywo, extravars, filtry i pobieranie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Śledzenie zadania
+
+Kliknięcie zadania otwiera jego stronę: formularz zadania jako tytuł, jego akcje w nagłówku i jego wynik poniżej.
+
+![Wynik zadania](../assets/screenshots/job-output.jpg)
+
+Od wersji 7.3.0 strona składa się z kart, a każdą można zwinąć pod jej nagłówkiem:
+
+| Karta | Co pokazuje |
+|---|---|
+| **Podsumowanie** | Nazwę, stan i typ zadania jako nagłówek, a pod nim informacje o zadaniu w siatce z trzema kolumnami (dwiema, a potem jedną na wąskiej stronie) |
+| **Workflow** | Dla zadania workflow, także zadania workflow AWX lub AAP, jego graf i liczbę węzłów (zobacz [Graf workflow](#the-workflow-graph)) |
+| **Wynik** | Wynik zadania i jego pasek narzędzi |
+
+Zadanie, które działało na AWX, AAP, Ascender, Jenkins, Semaphore lub Rundeck, pokazuje tam swój numer jako link do swojej strony w tym narzędziu, otwierany
+w nowej karcie. Link jest zapisany w zadaniu, więc działa nadal, gdy runner zostanie później przemianowany lub usunięty.
+
+Strona aktualizuje się na żywo: serwer wysyła zdarzenie za każdym razem, gdy zadanie zostaje uruchomione, zmienia stan, zapisuje wynik lub zostaje
+usunięte, a strona ponownie odczytuje zadanie, więc wynik rośnie w miarę jego zapisywania. Lista zadań aktualizuje się w ten sam sposób.
+**Odśwież** przeładowuje zadanie ręcznie.
+
+Gdy jesteś na końcu wyniku, strona przewija się za nim w dół, gdy przychodzą nowe wiersze. Przewiń w górę, aby przeczytać wcześniejszy wiersz,
+a strona zostanie tam, gdzie jesteś: nad dołem wyniku pojawi się wtedy **Przejdź do najnowszych**, które zmieni się w **Nowe wiersze**, gdy
+przyjdą kolejne. Kliknij je lub przewiń z powrotem na koniec, aby znów śledzić nowe wiersze. Wynik na stronie formularza po
+**Wyślij** i [log serwera](../production/logs.html) śledzą nowe wiersze w ten sam sposób.
+
+Pasek narzędzi wyniku zawiera:
+
+| Przycisk | Co robi |
+|---|---|
+| **Pokaż extravars** | Pokazuje extravars, z którymi działało zadanie, w panelu nad wynikiem, z przełącznikiem **JSON** / **YAML** i przyciskiem **Kopiuj** |
+| **Pokaż artefakty** | Pokazuje artefakty zadania w tym samym panelu (zobacz niżej) |
+| **Pokaż parametry** | Zastępuje **Pokaż extravars** dla zadania Jenkins: wartości, z którymi działało, czyli jego parametry builda |
+| **Pokaż payload** | Zastępuje **Pokaż extravars** dla zadania Rundeck: payload, który zostało mu wysłane |
+| **Hosty i zadania** | Pokazuje hosty i zadania playbooka nad jego wynikiem (zobacz [Hosty i zadania](#hosts-and-tasks)) |
+| **Odśwież** | Przeładowuje wynik |
+| **Zastosuj filtr** | Ukrywa zadania, których nazwa pasuje do filtra wyniku; **Usuń filtr** pokazuje je ponownie |
+| **Kopiuj wynik** | Kopiuje wynik jako zwykły tekst, z zastosowanym filtrem lub bez |
+| **Pobierz wynik** | Pobiera wynik jako `ansibleforms-job-<id>.txt` |
+
+**Pokaż artefakty** jest dostępne dla każdego zadania, które nie jest zadaniem szablonu, np. playbooka na RTE lub workflow (puste, gdy
+jego playbooki nie zebrały artefaktów przez `set_stats`), oraz dla zadania szablonu, które działało na AWX, AAP lub Ascender. Zadania Semaphore, Rundeck
+i Jenkins nie mają artefaktów, więc dla nich nigdy nie jest dostępne.
+
+Po lewej stronie paska narzędzi przycisk **Zwiń wszystko** zwija każdą sekcję wyniku (każdy play i każde zadanie) i zmienia się w
+**Rozwiń wszystko**, który ponownie je rozwija.
+
+**Pokaż extravars** wymaga opcji roli `showExtravars`, a **Pokaż artefakty** opcji roli `showArtifacts` (zobacz
+[opcje ról](../config/roles.html#role-options)). Wartości pól haseł i kluczy pasujących do
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) są maskowane.
+
+Filtr ustawia [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), domyślnie `\[low\]`.
+Dodaj `[low]` do nazwy hałaśliwego zadania, a **Zastosuj filtr** ukryje to zadanie i jego wiersze.
+
+Strona zadania wieloetapowego pokazuje każdy krok pod zadaniem głównym, jeden pod drugim, każdy pod paskiem tytułu, np.
+**Krok 1 · Prepare the server (id zadania 98)**, z jego stanem. Kliknij tytuł (lub naciśnij na nim Enter albo Spację), aby zwinąć ten wynik,
+i ponownie, aby go rozwinąć. Workflowy AWX/AAP pokazują też stan swoich węzłów.
+
+Zadania [workflow](../workflows/running.html#the-job) przechowują wynik każdego węzła we własnym wyniku, pod banerem `WORKFLOW NODE` dla każdego
+węzła; rysują swój graf na żywo, a kliknięcie węzła otwiera jego wynik.
+
+---
+
+## Wyszukiwanie tekstu w wyniku
+
+Od wersji 7.3.0 strona zadania ma pole wyszukiwania **Szukaj w wyniku** w wierszu tytułu, na lewo od akcji zadania.
+
+Każde miejsce, w którym tekst pojawia się w wyniku, jest podświetlane, bez względu na wielkość liter, a strona przechodzi do pierwszego z nich. **Enter** przechodzi
+do następnego, pokazanego mocniej, a pasek narzędzi podaje, które to z ilu (**2 z 4**), lub **Nie znaleziono**. Wyszukiwanie najpierw rozwija wynik i
+jego sekcje, a gdy zadanie działa, przeszukiwane są też nowe wiersze, bez przesuwania strony.
+
+---
+
+## Poruszanie się po długim wyniku
+
+Od wersji 7.3.0 długi wynik, na stronie zadania i pod formularzem po **Wyślij**, ma następujące sposoby nawigacji:
+
+| Element | Co robi |
+|---|---|
+| Przyklejone nagłówki | Nagłówek sekcji (węzła workflow, playbooka zadania, kroku zadania wieloetapowego) pozostaje na górze, gdy jej wiersze się przewijają |
+| **2 nieudane** | Liczy nieudane zadania, pomijając błędy, które Ansible miał zignorować; każde kliknięcie przechodzi do następnego, rozwiniętego i podświetlonego. Bez nieudanych zadań **1 błąd** liczy zamiast tego wiersze błędów |
+| Numery wierszy | Każdy numer wiersza jest linkiem do swojego wiersza, np. `#L45` w adresie: otwarcie tego adresu przewija do wiersza i go podświetla |
+| Przyciski w górę i w dół | Wyświetlane w prawym dolnym rogu po przewinięciu strony, aby wrócić na górę lub przejść na koniec |
+| **Uruchomione** i **Przerwij** | Gdy zadanie działa, pasek strony formularza jest przytrzymywany na dole okna, a **Przerwij** w nim od razu zatrzymuje zadanie |
+
+---
+
+## Wyniki zadań
+
+Od wersji 7.3.0 wiersz wyniku hosta w wyniku playbooka otwiera ten wynik w oknie dialogowym **Wynik zadania**, tak jak w AWX.
+
+Wiersz, treść wyniku po nim (`=> { ... }`) i błąd wypisany przed nieudanym wynikiem są podświetlane jako jeden blok po najechaniu, a
+kliknięcie otwiera okno dialogowe. Działa to na stronie zadania i pod formularzem po **Wyślij**, dla playbooka, który działał na RTE w wersji 7.3.0 lub
+nowszej, ponieważ wynik pochodzi z tych samych zdarzeń co [Hosty i zadania](#hosts-and-tasks). Okno dialogowe ma następujące karty:
+
+| Karta | Co pokazuje |
+|---|---|
+| **Szczegóły** | Stan, host, play, zadanie, moduł, element pętli, czas rozpoczęcia, czas trwania, kod powrotu i komunikat |
+| **JSON** i **YAML** | Cały wynik modułu, pokolorowany i z numerowanymi wierszami |
+| **Standardowe wyjście** i **Standardowy błąd** | `stdout` i `stderr` wyniku, jeśli je ma |
+
+Cały wynik, a wraz z nim karty **JSON**, **YAML** i karty wyjścia, jest zapisywany tylko wtedy, gdy zadanie działa w trybie verbose, ponieważ wynik
+również go wtedy pokazuje; w przeciwnym razie okno dialogowe pokazuje same szczegóły. Nawet w trybie verbose argumenty modułu (`invocation`) są
+pomijane, wartości kluczy wyglądających na sekret są maskowane, a wynik jest obcinany, gdy przekracza 64 KB JSON.
+
+---
+
+## Graf workflow
+
+Od wersji 7.3.0 graf działającego workflow przesuwa się tak, aby działający węzeł był widoczny.
+
+Jeśli przewiniesz graf w inne miejsce, zostanie tam, gdzie go zostawiłeś, z przyciskiem **Śledź działający węzeł**, aby znów go śledzić. Najechanie na węzeł
+pokazuje jego kartę z pełną nazwą i wyróżnia węzeł oraz jego połączenia, a reszta grafu jest przygaszona. Graf ma przyciski **Dopasuj do
+ekranu** i **Pełny ekran**, a pod formularzem po **Wyślij** kliknięcie węzła otwiera jego wynik tak jak na stronie zadania.
+
+---
+
+## Hosty i zadania
+
+Od wersji 7.3.0 zadanie playbooka, które działało na RTE w wersji 7.3.0 lub nowszej, zapisuje swoje zdarzenia strukturalne obok wyniku tekstowego: każdy play, zadanie
+i wynik hosta oraz podsumowanie. **Hosty i zadania** na pasku narzędzi wyniku pokazuje je w panelu nad wynikiem, na stronie zadania i
+pod formularzem po **Wyślij**. Przycisk jest dostępny, gdy zadanie ma zdarzenia, a panel jest odczytywany ponownie co kilka sekund, gdy zadanie działa:
+
+| Widok | Co pokazuje |
+|---|---|
+| **Siatka** | Podsumowanie dla każdego hosta (ok, changed, failed, unreachable, skipped, rescued, ignored), a potem siatkę hostów według zadań: każda komórka jest pokolorowana według wyniku hosta dla danego zadania, z komunikatem i czasem po najechaniu, albo *nie uruchomiono* |
+| **Oś czasu** | Każde zadanie jako pasek o długości odpowiadającej najwolniejszemu hostowi, z czasem w sekundach i sumą |
+
+Wynik tekstowy pozostaje bez zmian. Zdarzenia zapisuje własna wtyczka callback RTE `af_events`, więc playbook nie wymaga żadnych zmian.
diff --git a/i18n/pl/_use/jobs/index.md b/i18n/pl/_use/jobs/index.md
new file mode 100644
index 0000000..58cf7c6
--- /dev/null
+++ b/i18n/pl/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Zadania
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Zadania
+{: .no_toc }
+
+Śledzenie, przerywanie, ponowne uruchamianie, zatwierdzanie i usuwanie zadań, które uruchamiają twoje formularze
+{: .fs-6 .fw-300 }
+
+---
+
+Dla każdego, kto uruchamia formularze: czym jest zadanie, gdzie je znaleźć i kto może je widzieć.
+
+---
+
+## Czym jest zadanie
+
+Zadanie to jedno uruchomienie formularza: AnsibleForms rejestruje je wraz ze stanem, extravars i wynikiem, gdy tylko formularz zostanie wysłany.
+
+Każde zadanie przechowuje:
+
+* **formularz**, który uruchomiło, i **użytkownika**, który je uruchomił (z typem użytkownika, np. `local` lub `ldap`);
+* swój **typ zadania** i **stan** oraz **czas rozpoczęcia** i **czas zakończenia**;
+* swój **wynik**, extravars i poświadczenia, z którymi działało, oraz wartości pól wprowadzone w formularzu.
+
+Formularz wieloetapowy tworzy jedno zadanie dla formularza i po jednym zadaniu na każdy krok. Kroki są powiązane z zadaniem głównym i wyświetlane pod nim.
+
+Tymi samymi zadaniami można uruchamiać, śledzić i zarządzać przez [REST API](../api/jobs.html).
+
+---
+
+## Strona Zadania
+
+Link **Zadania** w nagłówku otwiera listę wszystkich zadań, od najnowszych (`/jobs/all`). Strona i jej link są widoczne dla użytkowników,
+których rola ustawia [opcję roli](../config/roles.html#role-options) `showJobs`.
+
+![Lista zadań](../assets/screenshots/job-log.jpg)
+
+Lewe menu porządkuje zadania w czasie, z liczbą zadań przy każdej pozycji; pozycja stanu filtruje listę według tego stanu:
+
+| Sekcja | Pozycja menu | Pokazuje |
+|---|---|---|
+| **Przeszłe** | **Zakończone powodzeniem** | Zadania o stanie `success` |
+| | **Nieudane** | Zadania o stanie `failed` |
+| | **Przerwane** | Zadania o stanie `aborted` |
+| | **Odrzucone** | Zadania o stanie `rejected` |
+| | **Porzucone** | Zadania o stanie `abandoned` |
+| **Bieżące** | **Uruchomione** | Zadania o stanie `running` |
+| | **Oczekuje na zatwierdzenie** | Zadania o stanie `approve`; licznik zmienia kolor na pomarańczowy, gdy któreś czeka |
+| **Przyszłe** | **Zaplanowane** | Strona [Harmonogramy](schedules.html) (opcja roli `allowScheduledJobs`) |
+| | **Zapisane** | Strona [Zapisane zadania](stored-jobs.html) (opcja roli `allowStoredJobs`) |
+
+Menu nie ma pozycji dla wszystkich zadań: link **Zadania** w nagłówku pokazuje je wszystkie, łącznie z zadaniami `warning`.
+
+Nad tabelą, w wierszu tytułu:
+
+* **pole wyszukiwania** zostawia zadania, których widoczne kolumny zawierają tekst (bez rozróżniania wielkości liter) lub których jeden z kroków ma go jako id
+  albo cel;
+* **Usuń** (z liczbą zaznaczonych zadań) usuwa razem zadania zaznaczone w pierwszej kolumnie;
+* **Kolumny** pokazuje lub ukrywa kolumny `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` i `user`;
+  czas trwania działającego zadania odlicza się na bieżąco;
+* **Odśwież** przeładowuje listę.
+
+Lista ładuje najnowsze zadania, tyle, ile określa ustawienie [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)
+(**Ustawienia > System > Ogólne**, karta **Zadania**, domyślnie `1000`); jej strony, wyszukiwanie i filtry obejmują te zadania.
+
+Każdą kolumnę można sortować i każda ma własne pole filtra. Zadanie wieloetapowe ma strzałkę tuż przed swoim `form`, która rozwija
+jego kroki; kliknięcie w pozostałą część wiersza otwiera zadanie.
+
+Dzwonek w nagłówku liczy zadania czekające na twoje zatwierdzenie i otwiera listę na **Oczekuje na zatwierdzenie**. Dla użytkowników, którzy widzą
+runnery, liczy także [runnery czekające na zatwierdzenie](../runners/registration.html#approving-an-rte), czyli RTE, które poprosiły o dołączenie,
+i otwiera **Połączenia > Runnery**, gdy czekają tylko runnery. Gdy czekają jedne i drugie, otwiera menu z pozycjami **Zadania czekające na zatwierdzenie** i
+**Runnery czekające na zatwierdzenie**, każda z licznikiem.
+
+---
+
+## Kto widzi które zadania
+
+Zadania widoczne dla użytkownika zależą od jego ról:
+
+| Użytkownik | Widzi |
+|---|---|
+| Administrator (rola `admin`) | Każde zadanie |
+| Opcja roli `showAllJobLogs` | Każde zadanie |
+| Opcja roli `manageAllJobs` (od 7.3.0) | Każde zadanie i może je przerwać, usunąć i uruchomić ponownie |
+| Każdy inny użytkownik | Własne zadania oraz zadania czekające na zatwierdzenie, które wskazuje jedną z jego ról |
+
+Do wersji 7.2 każdy użytkownik mógł otworzyć dowolne zadanie czekające na zatwierdzenie, łącznie z jego extravars i wynikiem; od wersji 7.3.0 mogą to tylko jego właściciel i
+zatwierdzający. Widzenie zadania nie daje prawa do każdej akcji na nim: przerwanie, usunięcie i ponowne uruchomienie zadania innego użytkownika wymaga administratora lub
+`manageAllJobs`, a `showAllJobLogs` tylko pokazuje zadania. Usuwanie wymaga też `allowJobDeletion`, a ponowne uruchamianie `allowJobRelaunch`.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Stany i typy](statuses.html) | Każdy stan, jaki może mieć zadanie, i rodzaje zadań |
+| [Śledzenie zadania](following.html) | Wynik na żywo, extravars, filtry i pobieranie |
+| [Akcje na zadaniach](actions.html) | Uruchamianie, przerywanie, ponowne uruchamianie, zatwierdzanie lub odrzucanie i usuwanie zadania |
+| [Harmonogramy](schedules.html) | Uruchamianie formularza później lub według harmonogramu cron i zarządzanie wszystkimi harmonogramami |
+| [Zapisane zadania](stored-jobs.html) | Przechowywanie danych formularza, aby wczytać je później |
+| [Czyszczenie](cleanup.html) | Zadania przerwane przez restart i jak długo przechowywane są zakończone zadania |
diff --git a/i18n/pl/_use/jobs/schedules.md b/i18n/pl/_use/jobs/schedules.md
new file mode 100644
index 0000000..1d5259d
--- /dev/null
+++ b/i18n/pl/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Harmonogramy
+parent: Zadania
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Harmonogramy
+{: .no_toc }
+
+Uruchamianie formularza później lub według harmonogramu cron i zarządzanie wszystkimi harmonogramami
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Akcje formularza
+
+Formularz może zrobić więcej niż natychmiastowe uruchomienie: lista rozwijana obok jego przycisku **Wyślij** zawiera trzy kolejne akcje.
+
+| Akcja | Co robi | Opcja roli |
+|---|---|---|
+| **Harmonogram (cykliczny)** | Tworzy harmonogram, który uruchamia formularz według wyrażenia cron | `allowScheduledJobs` |
+| **Uruchom później (jednorazowo)** | Tworzy harmonogram, który uruchamia formularz raz, w wybranym dniu i o wybranej godzinie | `allowPlannedJobs` |
+| **Zapisz** | Zapisuje wartości pól, aby można je było później ponownie wczytać do formularza | `allowStoredJobs` |
+
+Akcja, której opcja roli jest wyłączona, nie jest wyświetlana. Przed każdą z nich formularz jest walidowany, tak jak przy **Wyślij**. Obie
+akcje harmonogramu tworzą wpis na stronie **Harmonogramy**; **Zapisz** tworzy wpis na stronie **Zapisane zadania**.
+Pasek boczny strony [Zadania](./) otwiera je w sekcji **Przyszłe** jako **Zaplanowane** i **Zapisane**. Opcje ról opisano
+w [Opcje ról](../config/roles.html#role-options).
+
+{: .warning }
+> Traktuj `allowScheduledJobs` jako opcję na poziomie administratora. Jej harmonogramy nie należą do użytkownika, który je utworzył: każdy użytkownik
+> z tą opcją widzi wszystkie harmonogramy i może je zmieniać. Taki harmonogram działa też z uprawnieniami administratora, dla dowolnego formularza, niezależnie od
+> dostępu samego twórcy. Przyznawaj ją tylko rolom, którym zaufałbyś jak administratorom.
+
+{: .note }
+> **Uruchom później (jednorazowo)** wymaga tylko `allowPlannedJobs`. Dla użytkownika bez `allowScheduledJobs` planuje uruchomienie **jako ten
+> użytkownik**: serwer sprawdza, czy użytkownik może uruchomić formularz, a zadanie działa jako on i należy do niego, gdy nadejdzie jego czas
+> (zobacz [Zaplanowane uruchomienia](#planned-runs)).
+
+---
+
+## Planowanie formularza
+
+Wypełnij formularz, a następnie otwórz listę rozwijaną obok **Wyślij** i wybierz jedną z akcji harmonogramu.
+
+- **Harmonogram (cykliczny)** otwiera **Utwórz harmonogram**: wpisz **Nazwa** i **Wyrażenie cron** (domyślne `0 0 * * *`
+  uruchamia codziennie o północy), a następnie wybierz **Utwórz harmonogram**.
+- **Uruchom później (jednorazowo)** otwiera **Uruchom później**: wpisz **Nazwa** i wybierz datę i godzinę **Uruchom o**, a następnie wybierz
+  **Zaplanuj zadanie**.
+
+Nazwa musi być unikalna wśród wszystkich harmonogramów. Harmonogram zachowuje nazwę formularza i kopię extravars, które formularz wygenerował
+w tym momencie, zapisaną jako YAML; każde uruchomienie używa tej kopii, więc edytuj ją na stronie **Harmonogramy**, aby zmienić to, co otrzymuje zadanie.
+
+![Harmonogramy](../assets/screenshots/schedules.jpg)
+
+---
+
+## Strona Harmonogramy
+
+Strona **Harmonogramy** wyświetla każdy harmonogram, od wersji 7.3.0 z kolumną **Włączony**, i wymaga `allowScheduledJobs`. Menu każdego wiersza oferuje:
+
+| Akcja | Co robi |
+|---|---|
+| **Edytuj** | Zmienia nazwę, typ, wyrażenie cron lub czas uruchomienia, formularz i extra vars |
+| **Uruchom teraz** | Uruchamia harmonogram teraz, bez czekania na jego wyrażenie cron lub czas uruchomienia |
+| **Włącz** lub **Wyłącz** | Włącza lub wyłącza harmonogram, zależnie od tego, co pokazuje jego kolumna **Włączony** (od wersji 7.3.0) |
+| **Usuń** | Usuwa harmonogram; od razu przestaje się uruchamiać |
+| **Ostatni wynik** | Na stronie harmonogramu to, co zgłosiło ostatnie uruchomienie, np. numer uruchomionego zadania |
+
+Harmonogram można też utworzyć tutaj od zera. Wybierz **Formularz**, a następnie zaznacz **Jednorazowe uruchomienie** i ustaw
+**Uruchom o** albo zostaw je niezaznaczone i ustaw **Harmonogram cron**. **Extra vars** to YAML bez formularza, który by go wypełnił, więc sam dodaj
+wartości potrzebne playbookowi, jako słownik (pary klucz: wartość).
+
+Pole **Harmonogram cron** to edytor cron: opisuje wyrażenie słowami, oferuje gotowe ustawienia i pokazuje podgląd następnych
+uruchomień. Serwer odrzuca wyrażenie, którego nie potrafi wykonać, lub takie, które nigdy nie może wystąpić.
+
+Od wersji 7.3.0 każdy harmonogram ma przełącznik **Włączony**, aby wstrzymać go bez usuwania. Wyłączony harmonogram pozostaje na stronie
+ze swoimi ustawieniami, ale nie uruchamia się sam: cykliczny pomija swoje takty cron, a jednorazowy czeka po swoim
+**Uruchom o**, aż zostanie ponownie włączony. **Uruchom teraz** nadal uruchamia go na żądanie. Nowy harmonogram jest włączony, a harmonogramy
+istniejące przed wersją 7.3.0 są włączone po aktualizacji.
+
+---
+
+## Wyrażenia cron i strefa czasowa
+
+Harmonogram cykliczny przyjmuje standardowe 5-polowe wyrażenie cron: minuta, godzina, dzień miesiąca, miesiąc i dzień tygodnia.
+
+| Wyrażenie | Uruchamia się |
+|---|---|
+| `*/15 * * * *` | Co 15 minut |
+| `0 2 * * *` | Codziennie o 02:00 |
+| `30 7 * * 1-5` | Od poniedziałku do piątku o 07:30 |
+| `0 0 1 * *` | O północy pierwszego dnia każdego miesiąca |
+
+Więcej przykładów i funkcje cron, których edytor nie akceptuje, znajdziesz w FAQ w
+[Jakich wyrażeń cron mogę używać?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Harmonogramy cron działają w strefie czasowej serwera, ustawianej przez [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (domyślnie `UTC`),
+> a nie w strefie czasowej twojego profilu czy przeglądarki. Edytor cron pokazuje podgląd następnych uruchomień w tej samej strefie.
+
+---
+
+## Jak działa harmonogram
+
+Gdy nadchodzi termin harmonogramu, trafia on do kolejki, a serwer uruchamia harmonogramy z kolejki po jednym, sprawdzając kolejkę co 10 sekund.
+
+- Harmonogramy **cykliczne** pomijają takt, gdy poprzednie uruchomienie wciąż jest w kolejce lub działa, więc uruchomienia nigdy się nie nakładają.
+- Harmonogramy **jednorazowe** uruchamiają się w ciągu minuty od **Uruchom o**, a następnie są usuwane, także gdy zostały uruchomione przez **Uruchom teraz**.
+- **Stan** ma wartość `success`, gdy zadanie zostało uruchomione, i `failed`, gdy nie dało się go uruchomić. `success` mówi tylko, że zadanie zostało
+  uruchomione: otwórz zadanie, aby zobaczyć, jak się zakończyło.
+
+Harmonogram utworzony z `allowScheduledJobs` działa jako wbudowany użytkownik `Schedule Service` (typ `schedule`) z rolą
+`admin`. Może uruchomić dowolny formularz, niezależnie od dostępu osoby, która utworzyła harmonogram, a `ansibleforms_user` w
+jego extravars opisuje tego użytkownika. [Zaplanowane uruchomienie](#planned-runs) działa natomiast jako użytkownik, który je zaplanował.
+
+Zadanie otrzymuje też obiekt `schedule` (z jego `id`, `name` i `form`), dzięki czemu playbook wie, że uruchomił go harmonogram:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Zaplanowane uruchomienia
+
+**Uruchom później (jednorazowo)** wybrane przez użytkownika bez `allowScheduledJobs` tworzy zaplanowane uruchomienie: jednorazowy harmonogram powiązany z tym użytkownikiem.
+
+- **Przy planowaniu** serwer sprawdza, czy użytkownik może uruchomić formularz (jego `roles`), a tryb verbose wymaga
+  `allowVerboseMode`. Zaplanowane uruchomienie jest zawsze jednorazowe; wyrażenie cron jest odrzucane.
+- **Przy weryfikacji uruchomienia `enforce`** wartości pól są sprawdzane podczas planowania, więc uruchomienie, które zostałoby odrzucone, jest
+  odrzucane, gdy użytkownik wciąż na nie patrzy.
+- **Gdy się uruchamia**, zadanie działa jako ten użytkownik i należy do niego, przechodząc te same sprawdzenia co uruchomienie z przeglądarki:
+  role formularza w ich ówczesnej postaci, usunięcie zastrzeżonych extravars i weryfikacja uruchomienia. `ansibleforms_user` opisuje tego użytkownika.
+
+Planujący nie widzi strony **Harmonogramy**, która wymaga `allowScheduledJobs`; zadanie pojawia się w jego własnej historii zadań.
+
+---
+
+## Gdy formularz się zmienia
+
+Harmonogram odwołuje się do formularza po nazwie i uruchamia go w postaci zdefiniowanej w chwili każdego uruchomienia.
+
+- **Formularz zostaje zmieniony**: następne uruchomienie używa nowej definicji (playbook, szablon, inwentarz) z extravars zapisanymi w
+  harmonogramie. Formularz nie jest renderowany, więc żadne pole nie jest przeliczane; dostosuj extra vars harmonogramu.
+- **Formularz zostaje przemianowany lub usunięty**: uruchomienie kończy się błędem, **Stan** zmienia się na `failed`, a **Ostatni wynik** brzmi
+  `Failed to launch : No such form '<name>'`. Edytuj harmonogram i wybierz właściwy formularz albo go usuń.
+
+---
+
+## Zaplanowane zadania w historii zadań
+
+Każde uruchomienie harmonogramu tworzy zwykłe zadanie, wyświetlane na stronie [Zadania](./) z `Schedule Service` jako użytkownikiem lub,
+w przypadku zaplanowanego uruchomienia, z użytkownikiem, który je zaplanował.
+
+Zadanie `Schedule Service` nie należy do osoby, która utworzyła harmonogram, więc widzą je tylko administratorzy i
+użytkownicy z `showAllJobLogs`; zadanie zaplanowanego uruchomienia widzi też jego użytkownik. **Ostatni wynik** harmonogramu wskazuje uruchomione zadanie, więc możesz je znaleźć na liście.
diff --git a/i18n/pl/_use/jobs/statuses.md b/i18n/pl/_use/jobs/statuses.md
new file mode 100644
index 0000000..eeb01c8
--- /dev/null
+++ b/i18n/pl/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Stany i typy
+parent: Zadania
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Stany i typy
+{: .no_toc }
+
+Każdy stan, jaki może mieć zadanie, i rodzaje zadań
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Stany zadań
+
+AnsibleForms ustawia na zadaniu następujące stany. Lista pokazuje każdy stan jako kolorową etykietę:
+
+| Stan | Znaczenie | Co możesz zrobić |
+|---|---|---|
+| `running` | Zadanie działa lub zatwierdzone zadanie zostało wznowione | Śledzić jego wynik, przerwać je |
+| `approve` | Zadanie czeka w [punkcie zatwierdzenia](../forms/approval.html), zanim się uruchomi (lub zanim uruchomi się krok formularza wieloetapowego) | Zatwierdzić je lub odrzucić, jeśli jedna z twoich ról jest zatwierdzająca |
+| `success` | Playbook, szablon lub każdy krok zakończył się bez błędów | Wyświetlić wynik, uruchomić ponownie, usunąć |
+| `failed` | Zadanie zakończyło się błędem lub samo uruchomienie się nie powiodło | Wyświetlić wynik, aby sprawdzić przyczynę, uruchomić ponownie, usunąć |
+| `warning` | Formularz wieloetapowy się zakończył, ale krok z ustawionym `continue` zakończył się błędem | Wyświetlić wynik, uruchomić ponownie, usunąć |
+| `aborted` | Zadanie zostało przerwane z AnsibleForms lub zadanie AWX / AAP zostało anulowane | Wyświetlić wynik, uruchomić ponownie, usunąć |
+| `rejected` | Zatwierdzający odrzucił zadanie; nigdy się nie uruchomiło | Wyświetlić wynik, uruchomić ponownie, usunąć |
+| `abandoned` | AnsibleForms przestał śledzić zadanie (zobacz [Porzucone zadania](cleanup.html#abandoned-jobs)) | Sprawdzić zarządzane hosty, uruchomić ponownie, usunąć |
+
+`running` jest niebieski, `success` zielony i brzmi **Zakończone powodzeniem**, a `failed` czerwony. `approve` jest pomarańczowy i brzmi **Oczekuje na zatwierdzenie**,
+więc zadanie czekające na człowieka odróżnia się od zatrzymanych; `warning`, `aborted` i `rejected` są bursztynowe. `abandoned` jest
+szary: nikt go nie zatrzymał, ale to, co je uruchamiało, zniknęło.
+
+---
+
+## Typy zadań
+
+Typ zadania wynika z `type` formularza, który uruchomił zadanie, tak jak pokazuje go lista i strona zadania:
+
+| Wyświetlany typ | Co działa |
+|---|---|
+| `ansible` | Playbook Ansible uruchamiany na RTE |
+| `awx`, `aap`, `ascender` | Szablon zadania lub szablon workflow na AWX, AAP lub Ascender |
+| `semaphore` | Szablon na Semaphore UI |
+| `rundeck`, `jenkins` | Zadanie na Rundeck lub Jenkins |
+| `workflow` | [Workflow](../workflows/), którego węzły playbooków działają pod nim jako osobne zadania |
+| `multistep` | Przestarzały, używaj `workflow`: sekwencja kroków, z których każdy jest rejestrowany jako osobne zadanie pod zadaniem głównym |
+
+Zadanie szablonu jest zapisywane jako zadanie `awx` (także w REST API) i wyświetlane z rodzajem runnera, na którym działało, niezależnie od tego,
+jak nazwał je formularz: formularz typu `awx`, który działa na runnerze AAP, pokazuje `aap`.
+
+Stronę formularzy opisują [Formularze Ansible](../forms/ansible.html), [Formularze AWX](../forms/awx.html), [Formularze workflow](../forms/workflow.html) i
+[Formularze wieloetapowe](../forms/multistep.html).
diff --git a/i18n/pl/_use/jobs/stored-jobs.md b/i18n/pl/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..f9f6317
--- /dev/null
+++ b/i18n/pl/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Zapisane zadania
+parent: Zadania
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Zapisane zadania
+{: .no_toc }
+
+Przechowywanie danych formularza, aby wczytać je później
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Zapisane zadania
+
+Zapisane zadania przechowują wartości formularza, abyś mógł wczytać je ponownie zamiast za każdym razem wypełniać te same pola.
+
+Aby zapisać, wypełnij formularz, otwórz listę rozwijaną obok **Wyślij** i wybierz **Zapisz**. W **Zapisz dane formularza** wpisz
+**Nazwa**, opcjonalny **Opis** i datę **Wygasa (opcjonalnie)**, a następnie zapisz. Pola haseł i stałych nigdy
+nie są zapisywane. Podformularz ma tę samą akcję **Zapisz** obok swojego przycisku **Zapisz** i przechowuje niedokończone wartości bez
+ich walidacji.
+
+Aby wczytać, wybierz **Wczytaj z zapisanych** na górze formularza. **Wczytaj zapisany formularz** wyświetla twoje zapisane zadania dla tego formularza, z
+datami ich utworzenia i wygaśnięcia; wybierz jedno, aby wypełnić formularz jego wartościami. Nic się nie uruchamia, dopóki nie wyślesz formularza.
+
+Zapisane zadania są przechowywane w bazie danych AnsibleForms (tabela `stored_jobs`), z nazwą formularza, twoim użytkownikiem jako
+`<type>/<username>` (na przykład `local/admin`) i wartościami jako JSON. Nazwa musi być unikalna dla użytkownika i formularza; zapisanie
+drugiego z tą samą nazwą kończy się błędem „Zapisany formularz o tej nazwie już istnieje”.
+
+---
+
+## Zarządzanie zapisanymi zadaniami
+
+Strona **Zapisane zadania** wyświetla zapisane zadania z ich formularzem, użytkownikiem, datą utworzenia i wygaśnięcia i wymaga `allowStoredJobs`.
+
+- **Edytuj** otwiera własną stronę zapisanego zadania: jego **Szczegóły** (nazwa, formularz, wygaśnięcie) i **Wartości**, czyli zapisane
+  wartości pól jako YAML, które można tam zmienić i zapisać.
+- **Otwórz w formularzu** otwiera jego formularz z wypełnionymi zapisanymi wartościami; nic się nie uruchamia, dopóki nie wyślesz formularza.
+- **Usuń** je usuwa. Możesz usuwać własne zapisane zadania; użytkownicy z `showSettings` mogą usuwać dowolne.
+- Zapisane zadania z datą **Wygasa** w przeszłości są usuwane automatycznie codziennie o 04:00 (w `LOG_TZ`).
diff --git a/i18n/pl/_use/profile/account.md b/i18n/pl/_use/profile/account.md
new file mode 100644
index 0000000..b8f9b94
--- /dev/null
+++ b/i18n/pl/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Konto
+parent: Twój profil
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Konto
+{: .no_toc }
+
+Jako kto jesteś zalogowany
+{: .fs-6 .fw-300 }
+
+---
+
+Widok Konto pokazuje, jako kto jesteś zalogowany i co decyduje o twoim dostępie:
+
+- **Nazwa użytkownika** i **Typ logowania**: konto lokalne, LDAP, Microsoft Entra ID lub OpenID Connect.
+- **Grupy**: grupy, które przychodzą z twoim logowaniem, takie jak `local/admins` czy `ldap/Domain Admins`.
+- **Role**: role z `config.yaml` pasujące do tych grup i do twojego użytkownika. Decydują one o tym,
+  które formularze widzisz i jakie masz opcje.
diff --git a/i18n/pl/_use/profile/api-token.md b/i18n/pl/_use/profile/api-token.md
new file mode 100644
index 0000000..adbd30a
--- /dev/null
+++ b/i18n/pl/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Token API
+parent: Twój profil
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# Token API
+{: .no_toc }
+
+Tworzenie tokenu dla skryptów i agentów AI
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Kto może go utworzyć
+
+Długotrwały token pozwala skryptom wywoływać API bez twojego hasła. Od wersji 7.3.0 wymaga opcji roli `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Do wersji 7.2.0 wystarczała sama opcja `extendedTokenExpiration`. Rola sprzed wersji 7.3.0, która ustawia tylko tę opcję, otrzymuje
+`allowApiTokens`, więc zachowuje swoje tokeny; z obiema można też utworzyć token, który nigdy nie wygasa. Zobacz [Opcje ról](../config/roles.html#role-options).
+
+---
+
+## Tworzenie tokenu
+
+**Nowy token**, w wierszu tytułu **Profil > Tokeny API**, otwiera kreator w trzech krokach:
+
+1. **Szczegóły**: nazwa, po której rozpoznasz token na liście, i czas ważności. Do wyboru jest 30, 90, 180
+   lub 365 dni, do [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (domyślnie 90), samo
+   to maksimum oraz **Nigdy nie wygasa** przy `extendedTokenExpiration`. Wybierz najkrótszy okres, jakiego potrzebuje twój skrypt.
+2. **Potwierdź**: konto lokalne lub LDAP wpisuje hasło, które nie jest zapisywane w tokenie. Konto Microsoft Entra ID lub
+   OIDC nie ma tu hasła: jego token powstaje z sesji, w której logowanie musiało nastąpić najwyżej 10 minut
+   wcześniej, więc dostawca może najpierw poprosić o ponowne zalogowanie.
+3. **Kopiuj**: token, pokazywany **tylko raz**. Skopiuj go przyciskiem **Kopiuj** i chroń go tak jak hasło.
+
+Wysyłaj token w nagłówku `Authorization` każdego wywołania API:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Tokenem API nie można utworzyć kolejnego tokenu. Token konta SSO niesie role z jego ostatniego logowania: zmiana grupy u
+dostawcy tożsamości dociera do niego dopiero wtedy, gdy zalogujesz się ponownie i utworzysz nowy token.
+
+---
+
+## Twoje tokeny
+
+Utworzone przez ciebie tokeny są wyświetlane z nazwą oraz datą utworzenia, wygaśnięcia i ostatniego użycia; **Unieważnij** w menu wiersza kończy token.
+Administrator widzi je i unieważnia także na twojej stronie w **Ustawienia > Użytkownicy**. Token kończy się po wygaśnięciu lub wcześniej:
+
+- **po unieważnieniu**, z listy;
+- **po wylogowaniu tym tokenem** (`POST /api/v2/auth/logout` z tokenem w nagłówku `Authorization`), co kończy go razem
+  z sesją, w której został utworzony;
+- **po zmianie hasła**, co kończy wszystkie tokeny i sesje twojego konta utworzone przed nią, oraz po zablokowaniu twojego konta.
+
+Token, który nigdy nie wygasa, również kończy się w tych przypadkach. Skrypt może też sam zażądać tokenu przez API logowania i
+jego parametr `expiryDays` (`POST /api/v2/auth/login?expiryDays=90` lub `expiryDays=never`); dłuższe `expiryDays` jest skracane
+do `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/pl/_use/profile/index.md b/i18n/pl/_use/profile/index.md
new file mode 100644
index 0000000..8e466e4
--- /dev/null
+++ b/i18n/pl/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: Twój profil
+nav_order: 4
+description: Twoje konto, preferencje, hasło, uprawnienia i tokeny API
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# Twój profil
+{: .no_toc }
+
+Twoje konto, preferencje, hasło, uprawnienia i tokeny API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Dla każdego użytkownika: twoje własne konto, preferencje, hasło, uprawnienia i tokeny API.
+
+Profil otwierasz z awatara w prawym górnym rogu: **Profil**.
+
+---
+
+## Otwieranie widoku
+
+Lewe menu wymienia widoki profilu w kolejności alfabetycznej. Każdy widok ma własny adres,
+więc możesz linkować do niego bezpośrednio:
+
+| Widok | Adres |
+|---|---|
+| Konto | `/profile/account` |
+| Tokeny API | `/profile/token` |
+| Hasło | `/profile/password` |
+| Uprawnienia | `/profile/permissions` |
+| Preferencje | `/profile/preferences` |
+
+Sam `/profile` otwiera pierwszy widok menu. Widoki, na które nie pozwalają twoje role, są ukryte; ich adres otwiera wtedy pierwszy
+widok. **Tokeny API** są widoczne tylko wtedy, gdy jedna z twoich ról ma opcję roli `allowApiTokens`.
+
+---
+
+## W tej sekcji
+
+Każdy temat jest opisany na osobnej stronie:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Konto](account.html) | Jako kto jesteś zalogowany |
+| [Preferencje](preferences.html) | Język, motyw, strefa czasowa, format daty i powiadomienia na pulpicie |
+| [Hasło](password.html) | Zmiana hasła konta lokalnego |
+| [Uprawnienia](permissions.html) | Co pozwalają ci robić twoje role |
+| [Tokeny API](api-token.html) | Tworzenie tokenu dla skryptów i agentów AI |
diff --git a/i18n/pl/_use/profile/password.md b/i18n/pl/_use/profile/password.md
new file mode 100644
index 0000000..2975c35
--- /dev/null
+++ b/i18n/pl/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Hasło
+parent: Twój profil
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Hasło
+{: .no_toc }
+
+Zmiana hasła konta lokalnego
+{: .fs-6 .fw-300 }
+
+---
+
+Wpisz obecne hasło i dwukrotnie nowe, a następnie kliknij **Zmień hasło**.
+
+Konta LDAP, Entra ID i OpenID Connect zmieniają hasło u swojego dostawcy.
diff --git a/i18n/pl/_use/profile/permissions.md b/i18n/pl/_use/profile/permissions.md
new file mode 100644
index 0000000..dc9b9e3
--- /dev/null
+++ b/i18n/pl/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Uprawnienia
+parent: Twój profil
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Uprawnienia
+{: .no_toc }
+
+Co pozwalają ci robić twoje role
+{: .fs-6 .fw-300 }
+
+---
+
+Opcje ról są pogrupowane w karty, a każda karta pokazuje, ile jej opcji masz, np. `5/8`:
+
+| Karta | Opcje dotyczące |
+|---|---|
+| **Dostęp i integracje** | Logowania, asystenta czatu, serwera MCP, przesyłania plików i tokenów API |
+| **Projektant** | Otwierania projektanta oraz edycji formularzy, playbooków, workflowów, inwentarzy i plików zmiennych |
+| **Zadania** | Wyświetlania zadań i ich extravars lub artefaktów, ponownego uruchamiania, usuwania, planowania i zapisywania zadań |
+| **Ustawienia** | Stron ustawień, logów, dziennika audytu i kopii zapasowych |
+| **Inne** | Opcja ustawiona w roli ręcznie, która nie należy do żadnej innej karty; zawsze ostatnia karta |
+
+Pozostałe karty są w kolejności alfabetycznej. Każda karta to tabela z kolumnami **Ustawienie** (opcja), **Opis**
+(co robi) i **Twój dostęp**: **Dozwolone** lub **Niedozwolone**. Opcja, która obowiązuje z powodu innej, informuje o tym
+pod swoim opisem: **Zawarte w** opcji, którą masz, włącza ją, a **Wymaga** opcji, której nie masz, utrzymuje ją wyłączoną.
+
+Opcje pochodzą z `options` twoich ról w `config.yaml`; strona [Role](../config/roles.html) wyjaśnia, jak
+się łączą.
diff --git a/i18n/pl/_use/profile/preferences.md b/i18n/pl/_use/profile/preferences.md
new file mode 100644
index 0000000..470fa90
--- /dev/null
+++ b/i18n/pl/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Preferencje
+parent: Twój profil
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Preferencje
+{: .no_toc }
+
+Język, motyw, strefa czasowa, format daty i powiadomienia na pulpicie
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Preferencje
+
+Widok Preferencje zmienia to, jak AnsibleForms wygląda dla ciebie. Każdy wybór jest zapisywany w przeglądarce,
+w której go dokonujesz, więc inna przeglądarka lub komputer zaczyna od ustawień domyślnych.
+
+| Ustawienie | Opcje | Można ustawić także |
+|---|---|---|
+| Język | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (japoński), 简体中文 (chiński uproszczony) | flagą w nagłówku |
+| Motyw | Zgodnie z przeglądarką, Jasny, Ciemny lub Kolor (nagłówek w wybranym przez ciebie kolorze) | ikoną słońca w nagłówku |
+| Widok formularzy | Kafelki lub Lista | przyciskiem na stronie Formularze |
+| Strefa czasowa | UTC, strefa tej przeglądarki lub dowolna strefa według nazwy | tylko tutaj |
+| Format daty | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` lub `DD.MM.YYYY` | tylko tutaj |
+| Powiadomienia na pulpicie | Włączone lub wyłączone | tylko tutaj |
+
+Od wersji 7.3.0 widok jest podzielony na karty, każda pod własnym adresem (`/profile/preferences/<tab>`): **Wygląd** (język, motyw i widok
+formularzy), **Data i godzina** (strefa czasowa i format daty) oraz **Powiadomienia**. Pole wyszukiwania nad nimi wyświetla pasujące ustawienia
+pod nazwą ich karty. Wybór pozostaje szkicem do kliknięcia **Zapisz**, a opuszczenie widoku z niezapisaną zmianą wywołuje pytanie.
+
+**Zgodnie z przeglądarką** przełącza motyw na jasny lub ciemny tak jak przeglądarka i zmienia się razem z nią. Od wersji 7.3.0 jest to motyw domyślny, chyba że
+administrator wybierze inny. Najechanie na kolor motywu **Kolor**, tutaj lub w menu motywu w nagłówku, pokazuje podgląd aplikacji w tym
+kolorze, a poprzedni motyw wraca, gdy wskaźnik opuści paletę; nic się nie zmienia aż do kliknięcia.
+
+---
+
+## Powiadomienia na pulpicie
+
+Od wersji 7.3.0 karta **Powiadomienia** włącza powiadomienia na pulpicie w tej przeglądarce, dla użytkowników, których rola ustawia `showJobs`.
+
+Za pierwszym razem przeglądarka prosi o zgodę. Gdy blokuje powiadomienia dla tej witryny, przełącznik pozostaje wyłączony i podpowiada, jak
+je dopuścić, a witryna na zwykłym `http` w ogóle nie może ich wyświetlać. Po włączeniu powiadomienie pojawia się:
+
+| Kiedy | Treść | Kliknięcie w nie |
+|---|---|---|
+| Kończy się zadanie, które uruchomiłeś | Formularz i jego wynik, np. *Patch Linux servers: Zakończone powodzeniem*, z numerem zadania i czasem trwania | Przenosi kartę na wierzch, na to zadanie |
+| Zadanie czeka na twoje zatwierdzenie | Formularz, numer zadania i kto je uruchomił, z przyciskami **Zatwierdź** i **Odrzuć** | Otwiera zadania czekające na zatwierdzenie |
+
+Przyciski **Zatwierdź** i **Odrzuć** pojawiają się w Chrome i Edge; Firefox i Safari pokazują powiadomienie bez nich, podobnie jak
+witryna z certyfikatem samopodpisanym, ponieważ przyciski wymagają service workera. Powiadomienia przychodzą tylko wtedy, gdy otwarta jest karta AnsibleForms,
+nawet w tle: po zamknięciu wszystkich kart nic nie jest wysyłane. Każde pojawia się raz, niezależnie od liczby otwartych kart, a kroki
+zadania wieloetapowego i zadanie, które właśnie oglądasz, nie generują powiadomień.
+
+---
+
+## Strefa czasowa
+
+Daty i godziny w całym AnsibleForms są wyświetlane w wybranej przez ciebie strefie czasowej. Dotyczy to czasu rozpoczęcia
+i zakończenia zadań, dziennika audytu, strony stanu, kopii zapasowych, zapisanych zadań i wygaśnięcia tokenu
+API. Zmiana strefy czasowej od razu aktualizuje każdą stronę, bez przeładowania.
+
+Dopóki jej nie wybierzesz, obowiązuje strefa czasowa ustawiona przez administratora dla wszystkich (**Ustawienia > Wygląd > Wartości domyślne**, zobacz
+[Wygląd](../appearance.html)), czyli **UTC**, jeśli jej nie zmieniono. **Ta przeglądarka** podąża za strefą czasową twojego komputera, a
+lista zawiera każdą strefę według nazwy, np. `Europe/Madrid`. Karta pokazuje bieżący czas w wybranej strefie i formacie.
+
+---
+
+## Format daty
+
+Format daty określa, jak wygląda część daty w każdej dacie; każda opcja jest pokazana z dzisiejszą datą: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` lub `DD.MM.YYYY`. Dopóki go nie wybierzesz, obowiązuje domyślny format daty administratora,
+czyli `YYYY-MM-DD`, jeśli go nie zmieniono. Podobnie jak pozostałe ustawienia jest przechowywany w tej przeglądarce.
+
+---
+
+## Co zachowuje czas serwera
+
+Dwa wyjątki zachowują własny czas serwera:
+
+- **Log serwera i wynik zadań** to tekst zawierający czasy, które zapisał w nich serwer.
+- **Czasy wprowadzane przez ciebie**, np. kiedy ma się uruchomić zaplanowane zadanie, oraz harmonogramy cron działają tak jak
+  dotąd.
diff --git a/i18n/pl/_use/repositories/adding.md b/i18n/pl/_use/repositories/adding.md
new file mode 100644
index 0000000..f2142f9
--- /dev/null
+++ b/i18n/pl/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Dodawanie repozytorium
+parent: Repozytoria git
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Dodawanie repozytorium
+{: .no_toc }
+
+Strona Repozytoria, każde pole repozytorium i deklarowanie go w config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Strona Repozytoria
+
+Repozytoriami zarządza się w **Ustawienia > Połączenia > Repozytoria**, co wymaga [opcji roli](../config/roles.html#role-options) `showSettings` lub, od wersji 7.3.0,
+`showConnectionsSettings`. Niektóre zmiany może wprowadzać tylko administrator, zobacz [niżej](#who-may-change-a-repository).
+
+![Repozytoria](../assets/screenshots/git.jpg)
+
+Lista pokazuje **Nazwa**, **Opis**, **Gałąź**, **Head** (skrócony hash wybranego commita), **Pull** i
+**Push**. Karta **Szczegóły** repozytorium pokazuje te same odznaki Pull i Push nad jego head:
+
+| Kolumna | Co oznacza |
+|---|---|
+| **Pull** | Ostatnie klonowanie, pull lub reset: **Uruchomione**, gdy git pracuje, potem **Zakończone powodzeniem** lub **Nieudane**; myślnik przed pierwszym |
+| **Push** | **Nieudane**, gdy ostatni push się nie powiódł; **Oczekujące zmiany**, gdy zmiany zapisane tutaj, przez projektanta, nie zostały jeszcze wypchnięte do repozytorium zdalnego; **Zakończone powodzeniem**, gdy nic nie czeka; myślnik przed pierwszym pushem |
+
+**Zakończone powodzeniem** w kolumnie Push oznacza tylko, że nic nie czeka na wypchnięcie: repozytorium zdalne może nadal zawierać nowsze commity, które
+przyniesie pull. Menu każdego wiersza zawiera następujące akcje:
+
+| Akcja | Co robi |
+|---|---|
+| **Edytuj** | Zmiana poniższych pól |
+| **Pull** | Klonuje repozytorium lub wykonuje pull, gdy kopia robocza już istnieje |
+| **Push** | Commituje i wypycha kopię roboczą; tylko w repozytoriach używanych do formularzy, konfiguracji, playbooków, workflowów lub inwentarzy i aktywne tylko wtedy, gdy są jeszcze niewypchnięte zmiany |
+| **Resetuj** | Usuwa kopię roboczą i klonuje ją ponownie, co odrzuca lokalne zmiany |
+| **Zmień poświadczenia** | Otwiera kartę **Poświadczenia** repozytorium, aby wybrać poświadczenie używane przez git |
+| **Pokaż wynik ostatniego pull** | Pokazuje wynik git z ostatniego klonowania, pull lub resetu, z zamaskowanym hasłem |
+| **Pokaż wynik ostatniego push** | Pokazuje wynik git z ostatniego pushu, z zamaskowanym hasłem |
+| **Usuń** | Usuwa rekord i jego kopię roboczą w `REPO_PATH`; tylko administrator |
+
+**Pull wszystkich** nad listą wykonuje pull wszystkich repozytoriów naraz.
+
+Na repozytorium działa naraz tylko jedna operacja git. Druga jest odrzucana z komunikatem
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Dodawanie repozytorium
+
+Kliknij **Dodaj repozytorium**: kreator prosi o pola w czterech krokach (**Repozytorium**, **Poświadczenia**, **Zastosowanie**, **Harmonogram
+pull**), a AnsibleForms rozpoczyna klonowanie w tle, gdy tylko zapiszesz.
+
+![Edycja repozytorium](../assets/screenshots/git-edit.jpg)
+
+| Pole | Wymagane | Znaczenie |
+|---|---|---|
+| **Nazwa** | tak | Nazwa folderu w `REPO_PATH`; litery, cyfry, myślnik, podkreślenie i kropka |
+| **Gałąź** | tak | Gałąź do klonowania, pull i push, na przykład `main`; wymagana od wersji 7.3.0. Tylko repozytorium z config seed może ją pominąć, aby sklonować domyślną gałąź repozytorium zdalnego |
+| **Poświadczenie** | nie | Poświadczenie z [Połączenia > Poświadczenia](../credentials.html) z użytkownikiem i hasłem lub tokenem, których używa git; **Dodaj poświadczenie** tworzy nowe |
+| **Uri** | tak | Repozytorium zdalne, `https://...` lub SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Włącz zaplanowany pull** | nie | Wykonuje pull repozytorium według harmonogramu |
+| **Harmonogram pull** | nie | Kiedy wykonywać pull, jako wyrażenie cron; widoczne po włączeniu zaplanowanego pull |
+| **Opis** | tak | Dowolny opis tekstowy |
+| **Używać do konfiguracji?** ... **Używać do inwentarzy?** | nie | Co zawiera repozytorium, zobacz [wyżej](./#what-a-repository-is-for) |
+| **Pull przy starcie aplikacji** | nie | Klonuje repozytorium lub wykonuje jego pull przy każdym starcie AnsibleForms |
+
+Zmiana nazwy repozytorium przenosi jego kopię roboczą do nowego folderu, a razem z nią jego harmonogram pull. Repozytorium sprzed
+wersji 7, które nadal ma własnego użytkownika, informuje o tym na swojej karcie **Poświadczenia**: wybierz poświadczenie, które go zastąpi.
+
+---
+
+## Kto może zmieniać repozytorium
+
+Zawartość repozytorium staje się tym, co AnsibleForms ładuje i uruchamia, więc od wersji 7.3.0 użytkownik bez roli `admin` nie może już:
+
+- dodawać ani usuwać repozytorium;
+- zmieniać jego **Uri** ani **Gałąź**;
+- włączać ani wyłączać żadnego z jego przełączników **Używać do**.
+
+Nadal może zmieniać jego opis, harmonogram pull i poświadczenie oraz wykonywać jego pull, push lub reset. Poświadczenia używanego przez runner,
+połączenie lub logowanie nie może wybrać; odmowa wskazuje je z nazwy i nie mówi nic o jego zawartości.
+
+---
+
+## Deklarowanie repozytoriów w config seed
+
+Repozytoria można też zadeklarować w [config seed](../seed/), aby nowa instancja sklonowała je przy pierwszym starcie.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+Pola są takie same jak na stronie, łącznie z `credential` (poświadczenie z seed lub z aplikacji), `rebase_on_start` (**Pull przy starcie
+aplikacji**) i `cron` (harmonogram pull); `user` i `password` są nadal akceptowane zamiast poświadczenia.
+Repozytorium z seed jest w interfejsie tylko do odczytu i jest ponownie klonowane przy starcie, gdy brakuje jego kopii roboczej; zobacz
+[Obiekty zarządzane](../seed/managed-objects.html).
diff --git a/i18n/pl/_use/repositories/authentication.md b/i18n/pl/_use/repositories/authentication.md
new file mode 100644
index 0000000..a44b16a
--- /dev/null
+++ b/i18n/pl/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Uwierzytelnianie
+parent: Repozytoria git
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Uwierzytelnianie
+{: .no_toc }
+
+HTTPS z tokenem, SSH z wygenerowanym kluczem i własne polecenia git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Uwierzytelnianie
+
+Sposób uwierzytelniania AnsibleForms zależy od postaci **Uri**.
+
+### HTTPS z tokenem
+
+Dla prywatnego repozytorium zdalnego HTTPS wybierz **Poświadczenie**, którego użytkownik jest użytkownikiem git, a hasło osobistym tokenem dostępu
+(lub hasłem).
+
+Od wersji 7.3.0 git loguje się przez `GIT_ASKPASS`: użytkownik i token trafiają do każdego polecenia git, które komunikuje się z serwerem, nigdy do
+URL, więc nie są przechowywane w `.git/config` klonu, a zmieniony token jest używany przy następnym pull lub push. Token potrzebuje
+uprawnień do odczytu, aby wykonać pull, i do zapisu, aby wykonać push. Publiczne repozytorium zdalne nie wymaga poświadczenia.
+
+Do wersji 7.2.0 oba były wstawiane do URL, jako `https://<user>:<token>@git.example.com/team/forms.git`. Klon utworzony w tamtym czasie zachowuje
+ten URL do następnego pull lub push, który przywraca jego remote do własnego **Uri** repozytorium.
+
+### SSH z wygenerowanym kluczem
+
+Dla repozytorium zdalnego SSH AnsibleForms uwierzytelnia się własną parą kluczy, którą generuje przy pierwszym starcie.
+
+1. Otwórz **Ustawienia > Połączenia > SSH**, na karcie **Klucz**, i skopiuj **Klucz publiczny**.
+2. Dodaj go na serwerze git jako klucz wdrożeniowy repozytorium (z uprawnieniem do zapisu, jeśli wykonujesz push) lub do użytkownika z dostępem.
+3. Dodaj repozytorium z **Uri** SSH, na przykład `git@git.example.com:team/forms.git`, i nie wybieraj żadnego poświadczenia.
+
+Para kluczy znajduje się w `.ssh/id_rsa` w [`HOME_PATH`](../customization/paths.html#env_HOME_PATH), więc trzymaj ten folder na
+pamięci trwałej, w przeciwnym razie klucz zmieni się przy ponownym utworzeniu kontenera.
+
+Przy klonowaniu z Uri w postaci `user@host:path` AnsibleForms najpierw uruchamia `ssh-keyscan` na hoście i dodaje jego klucz do
+znanych hostów. Dla innych repozytoriów zdalnych dodaj host na karcie **Znane hosty** w **Ustawienia > Połączenia > SSH** przed
+pierwszym klonowaniem.
+
+### Własne polecenia git
+
+Polecenia clone, pull i push można zastąpić, na przykład aby dodać opcje git, trzema ustawieniami.
+
+| Ustawienie | Domyślnie | Co dodaje AnsibleForms |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, Uri i nazwę |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+Od wersji 7.3.0 te polecenia działają bez powłoki: cudzysłowy działają, ale operator powłoki, taki jak `;`, `|`, `&&` czy `>`, jest odrzucany.
diff --git a/i18n/pl/_use/repositories/designer.md b/i18n/pl/_use/repositories/designer.md
new file mode 100644
index 0000000..c2e8990
--- /dev/null
+++ b/i18n/pl/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Projektant i push
+parent: Repozytoria git
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Projektant i push
+{: .no_toc }
+
+Edycja formularzy w projektancie i wypychanie ich do repozytorium
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Edycja i push z projektanta
+
+Przy repozytorium używanym do formularzy projektant edytuje pliki w jego kopii roboczej i wypycha je z powrotem do repozytorium zdalnego.
+
+| Przycisk | Co robi |
+|---|---|
+| **Zapisz (lokalnie)** | Zapisuje formularze i `config.yaml` w kopiach roboczych, bez commitowania |
+| **Zapisz (repozytorium)** | Commituje i wypycha zapisane zmiany; aktywny, gdy są niewypchnięte zmiany |
+| **Wczytaj (repozytorium)** | Wykonuje pull repozytoriów formularzy i przeładowuje projektant, po potwierdzeniu, jeśli są niezapisane zmiany |
+
+Formularze pozostają w swoim repozytorium; nowe czekają, już gotowe do użycia, w [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH), aż wykonasz push.
+Formularz zapisany w podfolderze zachowuje swoją ścieżkę względną: `team/deploy.yaml` jest wypychany do `team/deploy.yaml` w folderze formularzy
+repozytorium. Nowy formularz, którego ścieżka już tam istnieje, nie jest nadpisywany; pozostaje w folderze przejściowym, więc zmień jego nazwę.
+Przy kilku repozytoriach formularzy **Zapisz (repozytorium)** i **Wczytaj (repozytorium)** pytają, którego użyć, domyślnie tego z `config.yaml`.
+
+Push dodaje wszystkie zmiany do stage, commituje je jako `AnsibleForms` z komunikatem `Forms sync by <user>`, a następnie wykonuje fetch, rebase na
+repozytorium zdalnym i push, ponawiając do pięciu razy. Konflikt rebase jest przerywany, a pliki z konfliktem są wymieniane;
+napraw je w repozytorium zdalnym lub użyj **Resetuj** na stronie Repozytoria. **Push** na stronie Repozytoria robi to samo.
+
+Gdy jedyne repozytorium formularzy zostanie sklonowane jako puste, AnsibleForms kopiuje lokalny `config.yaml` i formularze do jego kopii
+roboczej, więc push (**Zapisz (repozytorium)** lub **Push** na stronie Repozytoria) je publikuje. Więcej o projektancie w [Projektant i git](../gui/designer-and-git.html).
diff --git a/i18n/pl/_use/repositories/index.md b/i18n/pl/_use/repositories/index.md
new file mode 100644
index 0000000..518fcec
--- /dev/null
+++ b/i18n/pl/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Repozytoria git
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Repozytoria git
+{: .no_toc }
+
+Przechowywanie formularzy, plików zmiennych, konfiguracji i playbooków w git
+{: .fs-6 .fw-300 }
+
+---
+
+Dla administratorów, którzy przechowują formularze, konfigurację i playbooki w git: co może zawierać repozytorium i które źródło wygrywa.
+
+---
+
+## Do czego służy repozytorium
+
+Repozytorium to zdalne repozytorium git, które AnsibleForms klonuje i aktualizuje, a każde z nich ma przełączniki określające, co zawiera:
+
+| Przełącznik | Co AnsibleForms z niego odczytuje | Folder w repozytorium |
+|---|---|---|
+| **Używać do konfiguracji?** | `config.yaml` z kategoriami, rolami i stałymi | katalog główny |
+| **Używać do formularzy?** | Pliki formularzy, które projektant również do niego zapisuje, i ich pliki zmiennych | `forms` lub katalog główny; pliki zmiennych w `vars` |
+| **Używać do playbooków?** | Playbooki Ansible uruchamiane przez zadania | `playbooks` lub katalog główny |
+| **Używać do workflowów?** | Pliki [workflow](../workflows/), które projektant również do niego zapisuje | dowolny folder |
+| **Używać do inwentarzy?** | Jeden inwentarz nazwany tak jak repozytorium, który formularz wskazuje przez `inventory:` | katalog główny: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Bez podfolderu używany jest katalog główny repozytorium. Jedno repozytorium może zawierać wszystko; jeśli je rozdzielisz, tylko **Używać do
+formularzy**, **Używać do workflowów** i **Używać do inwentarzy** mogą być włączone w kilku: pozostałe przełączniki biorą pierwsze repozytorium
+i zapisują ostrzeżenie w logu.
+
+Każde repozytorium jest klonowane do podfolderu nazwanego tak jak ono, w [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Jedno repozytorium na wszystko
+
+Jedno repozytorium może zawierać formularze, pliki zmiennych, konfigurację i playbooki, z włączonymi przełącznikami i jednym podfolderem na każdy rodzaj.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Jedno repozytorium na każde przeznaczenie
+
+Osobne repozytoria pozwalają zespołom zarządzać własną częścią, z jednym przełącznikiem w każdym i plikami bezpośrednio w katalogu głównym.
+
+| Repozytorium | Przełącznik | Zawartość w katalogu głównym |
+|---|---|---|
+| `af-config` | **Używać do konfiguracji?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Używać do formularzy?** | Pliki formularzy każdego zespołu, scalone w jedną listę |
+| `af-playbooks` | **Używać do playbooków?** | Playbooki i role |
+
+Tylko formularze mogą pochodzić z kilku repozytoriów; konfiguracja i playbooki pochodzą każde z jednego. Pliki zmiennych pochodzą z folderu `vars`
+pierwszego repozytorium formularzy, które go ma.
+
+---
+
+## Jak repozytoria łączą się z folderami lokalnymi
+
+Zawartość repozytorium zastępuje odpowiedni folder lokalny; ta tabela podsumowuje, skąd odczytywany jest każdy rodzaj pliku.
+
+| Zawartość | Odczytywana z, wygrywa pierwsze dopasowanie |
+|---|---|
+| Konfiguracja | 1. bazy danych, gdy konfiguracja jest tam przechowywana ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. `config.yaml` repozytorium **Używać do konfiguracji** <br> 3. `config.yaml` repozytorium **Używać do formularzy**, gdy żadne repozytorium nie jest używane do konfiguracji <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formularze | Każde repozytorium **Używać do formularzy** plus `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) tylko wtedy, gdy nie ma żadnego |
+| Playbooki | Repozytorium **Używać do playbooków**, w przeciwnym razie [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Pliki zmiennych | Folder `vars` pierwszego repozytorium **Używać do formularzy**, które go ma, w przeciwnym razie [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflowy | Każde repozytorium **Używać do workflowów** plus [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), razem |
+
+Formularze z kilku repozytoriów są scalane w jedną listę. Gdy dwa z nich zawierają formularz o tej samej nazwie, zachowywany jest ten
+załadowany jako pierwszy, a w logu pojawia się ostrzeżenie `skipping duplicate form <name>`, więc nazwy formularzy muszą być unikalne we wszystkich repozytoriach.
+
+---
+
+## Rozwiązywanie problemów
+
+Większość problemów widać w kolumnie **Pull** oraz w **Pokaż wynik ostatniego pull** (lub **Pokaż wynik ostatniego push**), które zawierają
+własny komunikat błędu git.
+
+- [Klonowanie lub pull repozytorium nie powiodło się](../troubleshooting.html#a-repository-clone-or-pull-failed): uwierzytelnianie, znane
+  hosty i lokalne zmiany.
+- [Repozytorium formularzy nie zostało jeszcze sklonowane](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): projektant
+  nie może zapisywać przed pierwszym klonowaniem.
+- Repozytorium, które utknęło w stanie `running`, jest resetowane do `failed`: po restarcie przy następnym starcie; w ciągu minuty, gdy węzeł,
+  który wykonuje jego operację git, przestanie odpowiadać na 2 minuty; a w każdym przypadku po 2 godzinach. Uruchom **Pull** ponownie.
+
+---
+
+## W tej sekcji
+
+Każdy temat ma własną stronę:
+
+| Strona | Czego dotyczy |
+|---|---|
+| [Dodawanie repozytorium](adding.html) | Strona Repozytoria, każde pole repozytorium i deklarowanie go w config seed |
+| [Uwierzytelnianie](authentication.html) | HTTPS z tokenem, SSH z wygenerowanym kluczem i własne polecenia git |
+| [Pobieranie zmian](pulling.html) | Pull zaplanowany, ręczny i przez API oraz zmiany lokalne |
+| [Projektant i push](designer.html) | Edycja formularzy w projektancie i wypychanie ich do repozytorium |
diff --git a/i18n/pl/_use/repositories/pulling.md b/i18n/pl/_use/repositories/pulling.md
new file mode 100644
index 0000000..7a9f772
--- /dev/null
+++ b/i18n/pl/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Pobieranie zmian
+parent: Repozytoria git
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Pobieranie zmian
+{: .no_toc }
+
+Pull zaplanowany, ręczny i przez API oraz zmiany lokalne
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pobieranie zmian
+
+Pull repozytorium jest wykonywany według jego harmonogramu, przy starcie, ze strony lub przez API; nie ma punktu końcowego webhooka.
+
+| Wyzwalacz | Jak |
+|---|---|
+| Harmonogram | **Włącz zaplanowany pull** i **Harmonogram pull**, na przykład `0 * * * *` co godzinę |
+| Start | **Pull przy starcie aplikacji** klonuje repozytorium lub wykonuje jego pull, gdy jest już sklonowane |
+| Strona ustawień | **Pull** w menu wiersza lub **Pull wszystkich** nad listą |
+| Projektant | **Wczytaj (repozytorium)**, które wykonuje pull repozytoriów formularzy i przeładowuje projektant; przejęcie blokady projektanta również najpierw wykonuje pull każdego repozytorium formularzy |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` lub `showConnectionsSettings`) lub `POST /api/v2/forms-repos/pull/<name>` (zobacz niżej) |
+
+### Pull z potoku lub webhooka
+
+AnsibleForms nie ma dedykowanego odbiornika webhooków, ale zadanie CI lub webhook serwera git może wywołać punkt końcowy pull.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Utwórz token zgodnie z opisem w [Tokeny API](../profile/api-token.html), dla użytkownika, którego rola ma `showSettings` lub
+`showConnectionsSettings`. `/api/v2/forms-repos/pull/<name>` wymaga zamiast tego `showDesigner` i `allowFormDesign`, przy włączonym
+projektancie ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` zwraca
+`head`, `status` i `output`, więc potok może sprawdzić, na którym commicie działa instancja po pull.
+
+### Zmiany lokalne
+
+Pull nigdy nie nadpisuje pracy, która nie została jeszcze wypchnięta, więc zaplanowany pull sprawdza kopię roboczą przed uruchomieniem.
+
+Zaplanowany pull jest pomijany, gdy kopia robocza ma niezatwierdzone zmiany lub niewypchnięte commity, oraz gdy projektant
+trzyma blokadę projektanta. Ręczny pull kopii roboczej ze zmianami powodującymi konflikt kończy się błędem:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Wypchnij zmiany lub odrzuć je przez **Resetuj** w menu wiersza, co usuwa kopię roboczą i klonuje ją ponownie.
diff --git a/i18n/pl/index.md b/i18n/pl/index.md
new file mode 100644
index 0000000..539967b
--- /dev/null
+++ b/i18n/pl/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Strona główna
+nav_order: 1
+description: "AnsibleForms: twórz dynamiczne formularze oparte na danych do automatyzacji z Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Formularze samoobsługowe dla <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      Ansible to potężne narzędzie do automatyzacji, ale pozostaje aplikacją wiersza poleceń, a AWX/AAP/Ascender nie ma
+      formularzy, które zbierają dane z wielu źródeł. AnsibleForms pozwala budować dynamiczne formularze oparte na danych, generować extravars,
+      wysyłać je do Ansible, AWX/AAP/Ascender, Semaphore, Rundeck lub Jenkins i uruchamiać tam szablony.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">Zainstaluj AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">Zbuduj swój pierwszy formularz</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="Pulpit AnsibleForms">
+  </div>
+</div>
+
+## Możliwości
+
+Co AnsibleForms wnosi do twojego środowiska Ansible i co potrafi pojedynczy formularz:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Aplikacja</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Platformy automatyzacji</strong><span>Playbooki na RTE, szablony na Ascender, Semaphore i nie tylko</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Kontrola dostępu</strong><span>Role i opcje ról, z logowaniem lokalnym, LDAP, Entra ID i OIDC</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Planowanie</strong><span>Uruchamianie formularza później lub według harmonogramu cron</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Historia zadań</strong><span>Śledzenie, przerywanie i ponowne uruchamianie zadań</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Poświadczenia i sekrety</strong><span>Przechowywanie poświadczeń lub odczyt z Vault albo CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Repozytoria git</strong><span>Formularze, playbooki i konfiguracja w Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Projektant</strong><span>Edycja formularzy jako YAML, z walidacją</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP i czat</strong><span>Uruchamianie formularzy ze skryptów, agentów AI lub czatu</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formularze</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Kaskadowe listy rozwijane</strong><span>Listy rozwijane reagujące na inne pola</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Wyrażenia i źródła danych</strong><span>Wypełnianie pól z baz danych, REST API, plików i JavaScriptu</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Zależności pól</strong><span>Pokazywanie lub ukrywanie pól na podstawie innych pól</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Walidacja</strong><span>Min, max, regex i inne, opcjonalnie sprawdzane na serwerze</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflowy i formularze kreatora</strong><span>Łączenie playbooków i zatwierdzeń w łańcuch lub podział danych na strony</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Pola strukturalne</strong><span>Listy i obiekty oparte na podformularzach wielokrotnego użytku</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Punkty zatwierdzenia</strong><span>Wstrzymanie zadania, dopóki ktoś go nie zatwierdzi</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Powiadomienia</strong><span>Poczta, Slack, Teams, Telegram lub webhook przy zdarzeniach zadań</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Potrzebujesz pomocy?
+
+Pytania, błędy i zgłoszenia bezpieczeństwa mają każde swoje miejsce:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Rozwiązywanie problemów</strong>
+    <span>Wyszukaj komunikat błędu i sposób jego naprawy</span>
+    <span class="af-card-more">Rozwiązywanie problemów &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Zadaj pytanie</strong>
+    <span>Zapytaj społeczność i maintainerów</span>
+    <span class="af-card-more">Dyskusje &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Zgłoś błąd</strong>
+    <span>Otwórz issue z krokami pozwalającymi go odtworzyć</span>
+    <span class="af-card-more">Nowe issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Uzyskiwanie pomocy</strong>
+    <span>Co zawrzeć i jak zgłosić problem z bezpieczeństwem</span>
+    <span class="af-card-more">Uzyskiwanie pomocy &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/pt.yml b/i18n/pt.yml
new file mode 100644
index 0000000..81a86ba
--- /dev/null
+++ b/i18n/pt.yml
@@ -0,0 +1,42 @@
+# The Portuguese docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: pt
+docs_language: "pt"
+
+title: "Documentação do AnsibleForms"
+description: "Documentação técnica do AnsibleForms"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. Todos os direitos reservados."
+
+# "Edit this page on GitHub" opens the Portuguese page's source
+gh_edit_link_text: "Editar esta página no GitHub"
+gh_edit_source: i18n/pt
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "Introdução"
+    get_started:
+      name: "Primeiros passos"
+    configure:
+      name: "Configurar"
+    build_forms:
+      name: "Criar formulários"
+    use:
+      name: "Guia do utilizador"
+    integrate:
+      name: "Integrar"
+    security_assessment:
+      name: "Segurança"
+    reference:
+      name: "Referência"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x (mais recente)"
+    url: "/pt/"
+  - name: "6"
+    title: "6.x (em inglês)"
+    url: "/v6/"
diff --git a/i18n/pt/_build_forms/expressions/credentials.md b/i18n/pt/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..becf947
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Credenciais
+parent: Expressões
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# Credenciais
+{: .no_toc }
+
+Ler uma credencial guardada numa expressão
+{: .fs-6 .fw-300 }
+
+---
+
+Leia uma credencial guardada pelo nome ou por expressão regular, com uma alternativa:
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+Primeiro tenta-se o nome exato. Quando nenhuma credencial tem esse nome, o nome é usado como expressão regular e, a seguir, tenta-se a alternativa.
+
+#### Limitado por função
+
+Quando uma das funções do utilizador enumera `credentials` no `config.yaml`, `fn.fnCredentials` só devolve uma credencial que essa função
+permita: os padrões da função são comparados com o nome da credencial encontrada (pelo nome, por expressão regular ou pela alternativa),
+e qualquer outra é recusada. As funções sem essa lista não a limitam, e um administrador nunca é limitado.
+
+#### Credenciais de um cofre de segredos
+
+Uma credencial que indica um [cofre de segredos](../secret-stores) obtém o seu `user` e a sua `password`
+desse cofre em tempo de execução. `fn.fnCredentials('myapp')` continua a funcionar sem alterações.
+
+Também é possível ler um segredo sem uma linha de credencial, em qualquer sítio onde se aceite um nome de credencial
+(incluindo `fnRestBasic`, `fnRestJwtSecure` e as substituições de cabeçalhos de `fnRestAdvanced`):
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+As chaves do segredo são mapeadas como se descreve em [Nomes das chaves](../secret-stores#key-names).
+Um segredo com outra forma é remodelado com uma expressão `jq` como terceiro argumento:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/pt/_build_forms/expressions/index.md b/i18n/pt/_build_forms/expressions/index.md
new file mode 100644
index 0000000..9a80d29
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: Expressões
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# Expressões
+{: .no_toc }
+
+Calcular valores de campos com JavaScript, no navegador ou no servidor
+{: .fs-6 .fw-300 }
+
+---
+
+Para autores de formulários: preencha campos de forma dinâmica com JavaScript, calculados no navegador ou obtidos no servidor.
+
+O atributo `expression` de um campo de formulário permite criar formulários dinâmicos com expressões JavaScript.
+
+---
+
+## Introdução
+
+O atributo `expression` está disponível em vários tipos de campo:
+- campo `enum` - para preencher as opções da lista pendente de forma dinâmica
+- campo `expression` - para obter ou gerar qualquer tipo de dados
+- campo `html` - para construir o seu conteúdo HTML
+- campos `yaml` e `list` - para preencher os seus dados
+
+As expressões JavaScript são avaliadas no **lado do servidor** (predefinição) ou no **lado do cliente**, conforme a propriedade do campo `runLocal`.
+Um campo `html`, e os tipos de campo `local`, `local_out` e `credential`, executam sempre a sua expressão no navegador, independentemente
+do que diga `runLocal`.
+
+- **No lado do servidor** (`runLocal: false`, a predefinição) - funções predefinidas que obtêm dados de APIs, ficheiros e bases de dados.
+- **No lado do cliente** (`runLocal: true`) - O código tira partido de todo o motor JavaScript na sandbox do navegador para cálculos, transformações e manipulações.
+
+---
+
+## Questões de segurança
+
+Como as expressões são avaliadas com a função JavaScript `eval`, a injeção de código é uma preocupação a ter em conta:
+
+- **As expressões do lado do servidor** passam primeiro por um sanitizador: cada chamada tem de ser uma função `fn.` ou `fnc.`, e são recusadas as várias linhas,
+  `;`, os template literals, `process.env` e as formas de escapar de `eval` (`import`, `require`, `constructor`, ...).
+- **As expressões do lado do cliente** são avaliadas na sandbox do navegador e podem ser consideradas seguras.
+
+O rigor do sanitizador depende de
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER):
+
+| Valor | Expressões do lado do servidor |
+|---|---|
+| `strict` (predefinição) | chamadas `fn.` e `fnc.`, e métodos sobre o seu resultado, como `fn.fnTime().format('YYYY')` |
+| `paranoid` | só chamadas diretas `fn.` e `fnc.`, sem métodos sobre o seu resultado |
+| `off` | todas as expressões do lado do servidor são recusadas; só funcionam as expressões `runLocal` |
+| `legacy` | as regras da 6.2.1, que permitiam a qualquer utilizador autenticado executar código no servidor; só para uma atualização, e só no ambiente real (não a partir da página de definições) |
+
+Um valor vazio ou desconhecido equivale a `strict`. Uma alteração aplica-se à expressão seguinte, sem reiniciar.
+
+---
+
+## Nesta secção
+
+Cada tema tem a sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Marcadores](placeholders.html) | Referir outro campo, uma constante ou o utilizador com `$(...)` |
+| [Expressões locais](local.html) | JavaScript que é executado na sandbox do navegador |
+| [Expressões remotas](remote.html) | Funções do lado do servidor para datas, redes, ficheiros, SSH e nomes numerados |
+| [APIs REST](rest-apis.html) | Chamar APIs REST com autenticação básica, por token ou personalizada |
+| [Credenciais](credentials.html) | Ler uma credencial guardada |
+| [Ordenação](sorting.html) | Ordenar arrays com um objeto de ordenação |
+| [Consultas jq](jq.html) | Remodelar dados com jq |
diff --git a/i18n/pt/_build_forms/expressions/jq.md b/i18n/pt/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..72950be
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Consultas jq
+parent: Expressões
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# Consultas jq
+{: .no_toc }
+
+Remodelar dados com jq, incluindo as funções incorporadas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Executar uma consulta JSON (jq) sobre um objeto
+
+Remodele um objeto, por exemplo o valor de outro campo, com uma expressão jq:
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+A partir da 7.3.0, um filtro jq é executado no máximo durante [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS) (30 por predefinição)
+antes de ser parado, e o seu resultado está limitado a 64 MB. Isto aplica-se a `fn.fnJq` e à expressão jq das funções de REST, ficheiro,
+credencial e consulta à base de dados.
+
+---
+
+## Funções jq incorporadas
+
+Todas as funções que obtêm dados aceitam uma consulta JSON (jq), uma linguagem para manipular objetos e arrays de dados.  
+Ao manipular dados, pode ser necessário converter bytes em KB, MB ou GB, ou arredondar números.  
+Para isso, o AnsibleForms inclui algumas funções jq personalizadas:
+
+- **fn2KB**: Bytes para KB
+- **fn2MB**: Bytes para MB
+- **fn2GB**: Bytes para GB
+- **fnRound0**: Arredondar com 0 casas decimais
+- **fnRound1**: Arredondar com 1 casa decimal
+- **fnRound2**: Arredondar com 2 casas decimais
+- **fnRound**: Arredondar com 2 casas decimais
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/pt/_build_forms/expressions/local.md b/i18n/pt/_build_forms/expressions/local.md
new file mode 100644
index 0000000..023a121
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: Expressões locais
+parent: Expressões
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# Expressões locais
+{: .no_toc }
+
+JavaScript que é executado na sandbox do navegador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Os exemplos seguintes são executados com a propriedade do campo `runLocal: true`.  
+São executados na sandbox do navegador e podem tirar partido de todo o motor JavaScript.
+
+{: .note }
+> **Dica**: Use o tipo `local` como alias de `type: expression, runLocal: true, hide: true, output: false`  
+> **Dica**: Use o tipo `local_out` como alias de `type: expression, runLocal: true, hide: true`  
+
+---
+
+## Convenção de nomes
+
+Use manipulações de strings para aplicar convenções de nomes.
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## Cálculo
+
+Use a matemática para fazer cálculos.
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## Conversões
+
+Converta bytes em gigabytes.
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## Converter um array de objetos numa tabela HTML
+
+Transforme um array de objetos, por exemplo vindo de outro campo, numa tabela HTML para um campo `html`:
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## Obter um nome com numeração incremental
+
+Com a numeração automática, pode ser necessário encontrar o nome seguinte num array de strings numeradas.  
+Esta função também está disponível como expressão do lado do servidor (com o prefixo `fn.`).
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+Quando o primeiro argumento não é um array, a função local devolve o valor predefinido. A função do servidor `fn.fnGetNumberedName`,
+pelo contrário, falha com um erro.
+
+---
+
+## Manipulação de arrays de objetos
+
+Os arrays de objetos precisam muitas vezes de ser filtrados, alterados e ordenados.  
+O AnsibleForms inclui um auxiliar próprio que mantém este código conciso.
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## Manipulação de arrays de objetos com JavaScript simples
+
+Todos os métodos padrão de arrays de JavaScript continuam disponíveis para filtrar e alterar os seus dados, como `map`, `forEach`, `find`, `filter` e `reduce`.
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/pt/_build_forms/expressions/placeholders.md b/i18n/pt/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..0a10270
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Marcadores
+parent: Expressões
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# Marcadores
+{: .no_toc }
+
+Referir outro campo, uma constante ou o utilizador atual com `$(...)`
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O que é um marcador
+
+Um marcador é uma referência escrita como `$(reference)`. É substituído por um valor antes de o texto que o contém ser usado.
+
+Os marcadores funcionam no `expression`, no `query` e no `default` (avaliado com `evalDefault`) de um campo, e no seu `label`,
+`help` e `placeholder`. Um campo que contém um marcador depende do campo que este indica: espera até esse campo ter um
+valor e é avaliado de novo sempre que esse valor muda. É assim que se constroem as listas pendentes em cascata.
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## O que um marcador pode referir
+
+Um marcador indica um campo do formulário, ou um destes, que todos os formulários têm:
+
+| Referência | O que contém |
+|---|---|
+| `$(field)` | o valor de outro campo do formulário |
+| `$(name)`, uma constante | uma [constante](../config/constants.html) do `config.yaml`, ou um valor dos `varsFiles` do formulário |
+| `$(__user__)` | o utilizador com sessão iniciada: `username`, `type`, `groups`, `roles` |
+| `$(__parent__.field)` | num [subformulário](../forms/subform.html) (uma linha de lista, um passo de um wizard), um valor do formulário pai |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## Aceder a uma parte de um valor
+
+A notação de ponto e de índice lê uma parte de um valor, desde que o caminho só contenha letras, dígitos, `_`, `-`, `.` e `[n]`:
+
+| Marcador | Sobre | Devolve |
+|---|---|---|
+| `$(field)` | um campo text, number ou password | o valor |
+| `$(field)` | um enum de registos | a `placeholderColumn` do registo selecionado, ou então a sua primeira coluna |
+| `$(field.col)` | um enum de registos | essa coluna do registo selecionado |
+| `$(field)` | um enum com `multiple: true` | a coluna escolhida de cada registo selecionado, como array |
+| `$(field)` | uma expression, list ou constante | o valor completo (uma lista devolve as suas linhas) |
+| `$(field.a.b)`, `$(f[0].x)` | uma expression, list ou constante | essa parte do objeto ou do array |
+
+Definir `placeholderColumn: "*"` num enum faz com que `$(field)` devolva o registo selecionado completo em vez de uma coluna.
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## Como o valor é inserido
+
+A forma como um valor é inserido no texto depende do sítio onde está o marcador.
+
+| Onde | Exemplo | Passa a ser |
+|---|---|---|
+| uma expressão, fora de aspas | `$(count) + 1` | um literal JavaScript: um número continua a ser um número, um texto passa a ser uma string entre aspas, um objeto ou array um literal |
+| uma expressão, a totalidade de uma string entre aspas | `fn.fnLs('$(dir)')` | o mesmo literal, aspas incluídas, para que um valor com uma aspa não consiga escapar |
+| uma expressão, dentro de uma string mais longa | `'$(dir)/vars'` | o texto, escapado para essa string |
+| uma consulta, uma etiqueta, um texto de ajuda | `where city='$(city)'` | o texto |
+
+Um campo cujos marcadores ainda não possam ser todos resolvidos não é avaliado; com `ignoreIncomplete: true`, um valor em falta é
+inserido como `undefined`.
+
+### Backticks e `${` num valor
+
+A partir da 7.3.0, o valor de um campo não pode ser executado como código quando o servidor o insere numa expressão (expressões remotas, validação
+no lançamento, MCP e chat). Um backtick ou `${` no valor é escrito como um escape unicode (`\u0060`, `\u0024{`), pelo que continua a ser
+texto mesmo dentro de um template literal. As expressões do lado do servidor recusam por completo os template literals; para esses use `runLocal`.
+
+Uma expressão `runLocal` avaliada no navegador insere o valor como diz a tabela acima, sem esse escape, por isso não coloque
+aí um marcador dentro de um template literal.
+
+---
+
+## Ver também
+
+Páginas e entradas das FAQ relacionadas:
+
+- [Expressões locais](local.html) e [Expressões remotas](remote.html): onde se usa a maioria dos marcadores
+- [FAQ: Listas pendentes em cascata](../faq.html#cascaded-dropdowns) e [Marcadores de campos](../faq.html#field-placeholders): mais exemplos
+- [FAQ: Como acedo aos dados do formulário pai dentro de um subformulário?](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/pt/_build_forms/expressions/remote.md b/i18n/pt/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..e181880
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: Expressões remotas
+parent: Expressões
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# Expressões remotas
+{: .no_toc }
+
+Funções do lado do servidor para datas, redes, ficheiros, SSH e nomes numerados
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Os exemplos seguintes são executados com a propriedade do campo `runLocal: false` (predefinição).  
+São avaliados no lado do servidor.
+
+Como avaliar código no servidor é um risco de segurança, a expressão é sanitizada e limitada às funções que
+vêm com o AnsibleForms e às [funções que acrescentar](#your-own-functions).  
+As expressões do lado do servidor destinam-se a obter informação de fontes de dados como ficheiros, APIs REST e comandos SSH.
+
+{: .important }
+As funções incorporadas do lado do servidor têm o prefixo `fn.` (por exemplo, `fn.fnRestBasic`), as suas têm o prefixo `fnc.`.
+
+---
+
+## Manipular data e hora
+
+Trabalhe com datas e horas através do [Day.js](https://day.js.org):
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## Obter informação CIDR a partir de um IP
+
+Obtenha a sub-rede de um endereço IP e máscara de rede, e verifique que endereços lhe pertencem:
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## Obter o resultado de SSH
+
+Execute um comando num host remoto por SSH e use o seu resultado:
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## Listar os ficheiros de um diretório
+
+Liste os ficheiros de um diretório no servidor do AnsibleForms, opcionalmente de forma recursiva e filtrada:
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## Analisar uma página HTML
+
+Obtenha uma página HTML e extraia as partes que correspondem a uma expressão regular:
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+A página é obtida sob [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) e
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS), tal como as funções REST. Ao contrário delas, ignora
+`REST_IGNORE_CERTS` e `REST_TIMEOUT_SECONDS`: verifica sempre o certificado e espera no máximo 30 segundos.
+
+---
+
+## Obter informação DNS
+
+Resolva um registo DNS de um domínio:
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## Ler um ficheiro JSON
+
+Leia um ficheiro JSON no servidor, opcionalmente filtrado com jq:
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Ler um ficheiro YAML
+
+Leia um ficheiro YAML no servidor, opcionalmente filtrado com jq:
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## Obter um nome com numeração incremental
+
+Num array de strings com números incrementais (server001, server002, ...), pode ser necessário encontrar o nome seguinte disponível.  
+Esta função também está disponível como expressão local (sem o prefixo `fn.`).
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+No servidor, `fn.fnGetNumberedName` falha com um erro quando o primeiro argumento não é um array. A expressão local
+(sem `fn.`), pelo contrário, devolve o valor predefinido.
+
+---
+
+## As suas próprias funções
+
+Acrescente as suas próprias funções JavaScript ao `custom.js` e chame-as numa expressão do servidor com o prefixo `fnc.`.
+
+O ficheiro exporta um objeto de funções. O que vem com a imagem contém dois exemplos:
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+Da mesma forma, `jq.custom.definitions` contém as suas próprias definições jq. São colocadas antes de cada consulta jq que o
+servidor executa, pelo que as [consultas jq](jq.html) de todas as funções as podem usar.
+
+Num contentor, mapeie ambos os ficheiros por cima dos da imagem e reinicie; são lidos quando o servidor arranca:
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> Uma função personalizada é executada dentro do processo do servidor, com os seus privilégios, sempre que uma expressão a chama. O
+> [sanitizador](index.html#security-concerns) verifica que a expressão só chama funções `fn.` e `fnc.`; o que uma
+> função faz com os seus argumentos é da sua responsabilidade.
diff --git a/i18n/pt/_build_forms/expressions/rest-apis.md b/i18n/pt/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..a4dbb89
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: APIs REST
+parent: Expressões
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# APIs REST
+{: .no_toc }
+
+Chamar APIs REST com autenticação básica, por token ou personalizada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## API REST com autenticação básica
+
+Chame uma API REST com o utilizador e a palavra-passe de uma credencial guardada:
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## API REST com autenticação por token
+
+Chame uma API REST com um bearer token escrito na expressão:
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST com autenticação por token protegido
+
+Chame uma API REST com um bearer token obtido de uma credencial guardada, para que nunca apareça no formulário:
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## API REST com cabeçalhos personalizados
+
+Chame uma API REST com os seus próprios cabeçalhos, para qualquer outro tipo de autenticação:
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## Certificados e tempos limite
+
+A partir da 7.3.0, todas as funções auxiliares REST (`fnRestBasic`, `fnRestAdvanced`, `fnRestJwt`, `fnRestJwtSecure`) verificam o certificado TLS
+do endpoint e deixam de esperar ao fim de um tempo definido:
+
+| Definição | O que altera |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` salta a verificação do certificado. Até à 7.2.0 nunca era verificado; mantenha-o a `0` e, em vez disso, confie numa CA privada com `NODE_EXTRA_CA_CERTS` |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | Quanto tempo uma chamada espera por uma resposta, 60 segundos por predefinição; um endpoint que nunca responde faz então falhar o campo em vez de o reter |
+
+A partir da 7.3.0, um campo cujo endpoint tenha um certificado autoassinado falha com um erro de certificado até que uma das duas esteja definida.
+[Chamadas REST e jq](../customization/security.html#rest-calls-and-jq) descreve ambas, e como confiar numa CA privada para todas as chamadas REST de uma só vez.
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) não é uma função auxiliar REST: ignora ambas as definições, verifica sempre o
+certificado e espera no máximo 30 segundos.
diff --git a/i18n/pt/_build_forms/expressions/sorting.md b/i18n/pt/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..05a8145
--- /dev/null
+++ b/i18n/pt/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Ordenação
+parent: Expressões
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# Ordenação
+{: .no_toc }
+
+Ordenar arrays com um objeto de ordenação
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ordenar um array
+
+Ordene um array vindo de uma expressão, de uma API REST ou de uma base de dados com um objeto de ordenação:
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## O objeto de ordenação
+
+As funções REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) aceitam este objeto de ordenação
+como argumento. Para qualquer outro resultado, como `fn.fnJq` ou a leitura de um ficheiro, envolva-o em `fn.fnSort`.
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/pt/_build_forms/formfields/checkbox.md b/i18n/pt/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..c4507e1
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: Campos de formulário
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Campo Checkbox
+{: .no_toc }
+
+Um valor verdadeiro ou falso, para ativar uma opção ou definir um indicador
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `checkbox`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `checkbox`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/datetime.md b/i18n/pt/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..e917317
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: Campos de formulário
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Campo Datetime
+{: .no_toc }
+
+Um seletor de data, hora, semana, mês ou ano
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `datetime`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `datetime`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/enum.md b/i18n/pt/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..75eacf3
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: Campos de formulário
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Campo Enum
+{: .no_toc }
+
+Uma lista pendente com pesquisa, para uma ou várias opções
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `enum`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `enum`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/expression.md b/i18n/pt/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..7732ad8
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: Campos de formulário
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Campo Expression
+{: .no_toc }
+
+Um valor calculado com JavaScript, no navegador ou no servidor
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `expression`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `expression`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/file.md b/i18n/pt/_build_forms/formfields/file.md
new file mode 100644
index 0000000..4685fc1
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: Campos de formulário
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# Campo File
+{: .no_toc }
+
+Carregue ficheiros, como ficheiros de configuração ou certificados
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `file`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `file`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/html.md b/i18n/pt/_build_forms/formfields/html.md
new file mode 100644
index 0000000..0755e06
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: Campos de formulário
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Campo Html
+{: .no_toc }
+
+Conteúdo HTML formatado dentro de um formulário
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `html`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `html`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/index.md b/i18n/pt/_build_forms/formfields/index.md
new file mode 100644
index 0000000..105aec0
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Campos de formulário
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# Campos de formulário
+{: .no_toc }
+
+Os controlos de entrada de um formulário
+{: .fs-6 .fw-300 }
+
+---
+
+Para autores de formulários: os tipos de campo que um formulário pode conter e as propriedades que cada um suporta.
+
+Os campos de formulário definem os controlos de entrada de um formulário. Cada tipo de campo tem as suas próprias propriedades e comportamento para recolher um tipo de dados concreto.
+
+Escolha o tipo de campo que corresponde aos dados a recolher, desde texto simples até listas estruturadas.
+
+---
+
+## Propriedades comuns
+
+Todos os campos de formulário partilham duas propriedades fundamentais:
+
+- **name** (string, obrigatório): o identificador único do campo
+- **type** (string, obrigatório): o tipo de campo, que determina a página abaixo que descreve as propriedades disponíveis
+
+Cada tipo de campo acrescenta propriedades próprias da sua função. Selecione um tipo de campo na barra lateral de navegação ou na tabela abaixo para abrir a referência completa das suas propriedades:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">Tipo de campo</th>
+      <th>Descrição</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/pt/_build_forms/formfields/list.md b/i18n/pt/_build_forms/formfields/list.md
new file mode 100644
index 0000000..172455f
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: Campos de formulário
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# Campo List
+{: .no_toc }
+
+Uma tabela de linhas, cada uma editada num subformulário
+{: .fs-6 .fw-300 }
+
+---
+
+Um campo list mostra uma tabela de linhas, cada uma criada e editada num painel próprio de **subformulário** (um padrão de drilldown). Substitui o campo `table`, que foi removido na 7.0.0.
+
+---
+
+## Funcionalidades principais
+
+O campo list oferece as seguintes capacidades:
+
+- Cada linha é editada num subformulário em ecrã inteiro, com acesso a todos os tipos de campo, incluindo listas aninhadas.
+- O subformulário é um formulário próprio, do tipo `subform`, e pode ser **reutilizado em vários campos list** de formulários diferentes (por exemplo, um único subformulário `Address` partilhado por clientes, fornecedores, encomendas…).
+- As propriedades de marcação (`insertMarker`, `updateMarker`, `deleteMarker`) suportam padrões de playbook idempotentes.
+- Com `allowDelete: false`, as linhas pré-existentes ficam protegidas; só as linhas adicionadas na sessão atual (que levam o `insertMarker`) podem ser eliminadas.
+- A propriedade `columns` controla que campos do subformulário aparecem como colunas na tabela de resumo.
+- O resultado é sempre um array de objetos. `model`, `output`, `outputObject` e `valueColumn` declarados nos campos do subformulário são respeitados quando as extravars são geradas.
+
+---
+
+## Declaração do subformulário
+
+Um subformulário é um formulário próprio com `type: subform`, num ficheiro da pasta de formulários como qualquer outro formulário. Aceita o mesmo array `fields` que qualquer outro formulário, mas nunca aparece na lista de mosaicos de formulários e nunca é submetido diretamente.
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `list`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>Exemplos</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## Exemplos
+
+### Subformulário de morada partilhado
+
+Um subformulário `Address` reutilizado por dois campos list do mesmo formulário:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### Seguimento com marcadores (com idempotência)
+
+As linhas pré-carregadas ficam protegidas, e os marcadores indicam ao playbook que linhas são novas, alteradas ou removidas:
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### Preencher linhas antecipadamente
+
+Uma lista pode ser preenchida antecipadamente a partir de três fontes. Em todos os casos, as linhas resultantes têm de ser objetos cujas chaves correspondem aos nomes dos campos do subformulário referido.
+
+#### `default` estático
+
+Linhas escritas no próprio formulário:
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### A partir de uma API REST (`expression`)
+
+Linhas carregadas de uma API REST por uma expressão do lado do servidor:
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### A partir de uma consulta à base de dados (`dbConfig` + `query`)
+
+Linhas carregadas a partir de uma consulta à base de dados:
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### A partir de uma expressão local (`runLocal`)
+
+Linhas calculadas no navegador por uma expressão local:
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### Listas aninhadas
+
+Um subformulário pode conter o seu próprio campo list, para ter uma lista dentro de cada linha:
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### Aceder aos dados do formulário pai através de `__parent__`
+
+Quando o editor de uma linha do subformulário abre, o AnsibleForms injeta uma variável `__parent__` no subformulário. Esta contém uma fotografia de **todos os valores dos campos do formulário pai**, incluindo constantes e vars.
+
+Refira-a com a sintaxe de expressões habitual `$(...)` nas definições dos campos do subformulário:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` é um auxiliar **exclusivo do frontend**. É retirado das extravars do Ansible e nunca é enviado para o playbook.
+
diff --git a/i18n/pt/_build_forms/formfields/number.md b/i18n/pt/_build_forms/formfields/number.md
new file mode 100644
index 0000000..49177bb
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: Campos de formulário
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Campo Number
+{: .no_toc }
+
+Um valor inteiro ou decimal, como uma porta ou uma quantidade
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `number`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `number`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/password.md b/i18n/pt/_build_forms/formfields/password.md
new file mode 100644
index 0000000..673a075
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: Campos de formulário
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Campo Password
+{: .no_toc }
+
+Um valor oculto, para palavras-passe, segredos e tokens
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `password`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `password`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/radio.md b/i18n/pt/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..f288426
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: Campos de formulário
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Campo Radio
+{: .no_toc }
+
+Uma escolha de entre um conjunto de opções mutuamente exclusivas
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `radio`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `radio`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/text.md b/i18n/pt/_build_forms/formfields/text.md
new file mode 100644
index 0000000..f91b339
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: Campos de formulário
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Campo Text
+{: .no_toc }
+
+Uma única linha de texto, como um nome ou um nome de host
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `text`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `text`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/textarea.md b/i18n/pt/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..a023fb7
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: Campos de formulário
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Campo Textarea
+{: .no_toc }
+
+Texto em várias linhas, como uma descrição ou um excerto de configuração
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `textarea`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `textarea`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/pt/_build_forms/formfields/yaml.md b/i18n/pt/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..0399bfb
--- /dev/null
+++ b/i18n/pt/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: Campos de formulário
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# Campo YAML
+{: .no_toc }
+
+Dados estruturados num editor YAML, com validação e importação de ficheiros
+{: .fs-6 .fw-300 }
+
+---
+
+## Propriedades
+
+As propriedades disponíveis para um campo `yaml`, agrupadas por finalidade:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>Valor:</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de campos `yaml`, em YAML:
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição do campo, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## Aceder aos dados do formulário pai através de `__parent__`
+
+Quando um campo `yaml` usa o modo `subform`, o AnsibleForms injeta uma variável `__parent__` no subformulário. Esta contém uma fotografia de **todos os valores dos campos do formulário pai** no momento em que o editor abre, incluindo constantes e vars.
+
+Refira-a com a sintaxe de expressões habitual `$(...)` nas definições dos campos do subformulário:
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` é um auxiliar **exclusivo do frontend**. É retirado das extravars do Ansible e nunca é enviado para o playbook.
diff --git a/i18n/pt/_build_forms/forms/ansible.md b/i18n/pt/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..1f70d39
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulários de Ansible
+parent: Formulários
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Formulários de Ansible
+{: .no_toc }
+
+Formulários que executam um playbook de Ansible local
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: ansible`, além das [propriedades comuns dos formulários](common.html).
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/approval.md b/i18n/pt/_build_forms/forms/approval.md
new file mode 100644
index 0000000..9ca6086
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: Pontos de aprovação
+parent: Formulários
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# Pontos de aprovação
+{: .no_toc }
+
+Colocar uma tarefa em pausa até alguém a aprovar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Como funciona
+
+Um ponto de aprovação coloca a tarefa em pausa no sítio onde está no formulário, até um aprovador lhe responder:
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## Aprovar a sua própria tarefa
+
+A partir da 7.3.0, o utilizador que lançou uma tarefa não a pode aprovar, mesmo que tenha uma das funções da aprovação, pelo que é precisa uma segunda pessoa; um administrador pode sempre aprovar, incluindo as suas próprias tarefas.
+Quem lançou a tarefa pode ainda assim rejeitá-la (retirá-la). Defina `allowSelf: true` quando essa pessoa também a puder aprovar, por exemplo num formulário de teste:
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## Atributos
+
+Os atributos de um ponto de aprovação:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de pontos de aprovação, em YAML:
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/awx.md b/i18n/pt/_build_forms/forms/awx.md
new file mode 100644
index 0000000..2be7b0f
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulários de AWX
+parent: Formulários
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# Formulários de AWX
+{: .no_toc }
+
+Formulários que lançam um job template de AWX, AAP ou Ascender
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: awx`, além das [propriedades comuns dos formulários](common.html).
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/common.md b/i18n/pt/_build_forms/forms/common.md
new file mode 100644
index 0000000..73ef03d
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: Propriedades comuns
+parent: Formulários
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# Propriedades comuns dos formulários
+{: .no_toc }
+
+Propriedades partilhadas por todos os tipos de formulário
+{: .fs-6 .fw-300 }
+
+---
+
+Estas propriedades aplicam-se a **todos os tipos de formulário**: `ansible`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`,
+`workflow`, `multistep` (obsoleto) e `subform`.
+
+Todas as outras propriedades são específicas de cada tipo e estão documentadas na página do respetivo tipo de formulário.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## Propriedades
+
+As propriedades partilhadas por todos os tipos de formulário:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/pt/_build_forms/forms/index.md b/i18n/pt/_build_forms/forms/index.md
new file mode 100644
index 0000000..a84bd53
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Formulários
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# Formulários
+{: .no_toc }
+
+Definir os formulários que os seus utilizadores preenchem
+{: .fs-6 .fw-300 }
+
+---
+
+Para autores de formulários: como se escrevem os formulários em YAML, de onde são carregados e as propriedades de cada tipo de formulário.
+
+Os formulários são o núcleo do AnsibleForms. Cada formulário é uma interface web que recolhe dados do utilizador e, com esses dados, executa um
+playbook de Ansible, um template de AWX, AAP ou Ascender, um template de Semaphore, um job de Rundeck ou Jenkins, ou um
+[workflow](../workflows/).
+
+Os formulários são definidos em ficheiros YAML na pasta de formulários. Cada ficheiro YAML contém um único formulário ou uma lista de formulários, e podem usar-se subpastas para os organizar.
+
+**VÍDEO**: [Crie o seu primeiro formulário](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## Compreender a estrutura de um formulário
+
+Cada formulário do AnsibleForms é configurado com um conjunto de propriedades. **[Propriedades comuns](common.html)** enumera as propriedades que se aplicam a todos os tipos de formulário; as páginas de cada tipo descrevem as restantes.
+
+---
+
+## Como os formulários são carregados
+
+O AnsibleForms carrega os formulários a partir das seguintes localizações:
+
+1. **A PARTIR DE REPOSITÓRIOS** : todos os repositórios com o interruptor "Usar para formulários" ativado (são suportados vários repositórios)
+   - Os formulários de todos os repositórios ativados são juntados automaticamente.
+   - Em cada repositório procura-se primeiro uma subpasta `forms/`.
+   - Se não existir nenhuma subpasta `forms/`, usa-se a raiz do repositório.
+   - Os formulários criados no designer e ainda não enviados (push) são mantidos numa pasta de preparação
+     ([`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH)) e carregados juntamente com eles.
+
+2. **A PARTIR DA PASTA LOCAL** : a pasta local `forms/`
+   ([`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH)), quando nenhum repositório tem "Usar para formulários" ativado
+
+{: .warning }
+> **Nota:** Quando "Usar para formulários" está ativado em vários repositórios, todos os seus formulários são juntados. Os nomes dos formulários têm de ser únicos entre repositórios para evitar conflitos.
+
+---
+
+## Onde um formulário é executado
+
+O tipo de um formulário decide o tipo de [runner](../runners.html) em que a sua tarefa é executada: um RTE para `ansible`, um runner AWX para `awx`,
+`aap` e `ascender`, e um runner do seu próprio tipo para `semaphore`, `rundeck` e `jenkins`.
+
+- `runner: <name>` no formulário escolhe um runner desse tipo pelo nome; sem ele, a tarefa é executada no runner predefinido do tipo.
+- Um runner desativado em **Ligações > Runners** faz falhar a tarefa, quer o formulário o indique, quer seja o predefinido. A tarefa
+  nunca recorre a outro runner.
+- Quando uma das funções do utilizador enumera `runners` no `config.yaml`, a tarefa só pode ser executada num runner que essa função enumere, caso contrário é
+  recusada. As funções sem essa lista não a limitam, e um administrador nunca é limitado.
+
+---
+
+## Nesta secção
+
+As páginas seguintes descrevem em detalhe as propriedades dos formulários:
+
+| Página | O que abrange |
+|---|---|
+| [Propriedades comuns](common.html) | Propriedades que se aplicam a todos os tipos de formulário (`name`, `description`, `help`, `type`, `fields`) |
+| [Formulários de Ansible](ansible.html) | Propriedades específicas de `type: ansible` |
+| [Formulários de AWX](awx.html) | Propriedades específicas de `type: awx` |
+| [Formulários de Semaphore](semaphore.html) | Propriedades específicas de `type: semaphore`, que executa um template de Semaphore |
+| [Formulários de Rundeck](rundeck.html) | Propriedades específicas de `type: rundeck`, que executa um job de Rundeck |
+| [Formulários de Jenkins](jenkins.html) | Propriedades específicas de `type: jenkins`, que executa um build de um job de Jenkins |
+| [Formulários de vários passos](multistep.html) | Propriedades específicas de `type: multistep`, obsoleto em favor de `workflow` |
+| [Formulários de workflow](workflow.html) | Propriedades específicas de `type: workflow`, que executa um [workflow](../workflows/) |
+| [Assistente](wizard.html) | Dividir os dados de um formulário por várias páginas (funciona sobre qualquer tipo de formulário executável) |
+| [Subform](subform.html) | Os subformulários só usam as propriedades comuns |
+| [Pontos de aprovação](approval.html) | Colocar uma tarefa em pausa até ser aprovada (`approval`) |
+| [Notificações](notifications.html) | Enviar emails e mensagens para canais conforme o estado ou os eventos da tarefa (`notifications`) |
+| [Ações conforme o estado da tarefa](job-status-action.html) | Atuar sobre o formulário quando uma tarefa muda de estado (`onSubmit`, `onSuccess`, ...) |
diff --git a/i18n/pt/_build_forms/forms/jenkins.md b/i18n/pt/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..b167ee0
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulários de Jenkins
+parent: Formulários
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Formulários de Jenkins
+{: .no_toc }
+
+Formulários que executam um build de um job de Jenkins
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: jenkins`, além das [propriedades comuns dos formulários](common.html).
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/job-status-action.md b/i18n/pt/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..8cab413
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: Ações conforme o estado da tarefa
+parent: Formulários
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# Ações conforme o estado da tarefa
+{: .no_toc }
+
+Atuar sobre o formulário quando a sua tarefa é submetida, é bem-sucedida, falha ou termina
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+Estão disponíveis os seguintes hooks:
+
+- `onSubmit` - disparado quando o formulário é submetido
+- `onSuccess` - disparado quando a tarefa termina com sucesso
+- `onFailure` - disparado quando a tarefa falha
+- `onFinish` - disparado quando a tarefa termina, seja qual for o seu estado
+- `onAbort` - disparado quando a tarefa é interrompida
+
+---
+
+## Atributos
+
+Os atributos de uma ação conforme o estado da tarefa:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de ações conforme o estado da tarefa, em YAML:
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/multistep.md b/i18n/pt/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..55a9b0d
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: Formulários de vários passos
+parent: Formulários
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# Formulários de vários passos
+{: .no_toc }
+
+Executar vários playbooks ou templates em sequência a partir de um só formulário
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` está obsoleto desde a 7 e é removido na 8: use antes um [workflow](workflow.html). Um workflow faz tudo o que
+> um multistep faz, com condições, valores próprios por nó, nós de aprovação e ramos que correm lado a lado.
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedade ao nível do formulário
+
+Um formulário de vários passos define os seus passos numa única propriedade ao nível do formulário:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / obrigatório</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+Além de `steps`, um formulário de vários passos aceita estas propriedades ao nível do formulário, documentadas na página [Formulários de Ansible](ansible.html):
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %} (obrigatória){% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## Propriedades dos passos
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">Só disponível com os tipos:</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Adicionado</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        Exemplos
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Exemplo
+
+Um formulário de vários passos executa várias tarefas em sequência, e cada passo lança o seu próprio playbook ou template de AWX. Todos os passos partilham os campos do formulário: por predefinição, cada passo recebe as extravars completas, e a `key` de um passo limita-o a essa parte delas.
+
+### Criar e configurar um servidor
+
+Cada passo recebe a sua própria parte das extravars: um passo de AWX cria o servidor, um passo de Ansible configura a sua rede e um último passo envia sempre um relatório:
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/pt/_build_forms/forms/notifications.md b/i18n/pt/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..bfd1597
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: Notificações
+parent: Formulários
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# Notificações
+{: .no_toc }
+
+Enviar um email ou uma mensagem para um canal quando uma tarefa termina ou quando lhe acontece algo
+{: .fs-6 .fw-300 }
+
+---
+
+As `notifications` de um formulário dizem quem fica a saber das suas tarefas, e quando:
+
+- **Quem**: `recipients`, endereços de email, e `channels`, os nomes de
+  [canais de notificação](../notification-channels.html) (mail, Slack, Microsoft Teams, Telegram, um webhook). É obrigatório
+  pelo menos um dos dois.
+- **Quando**: `onStatus`, quando uma tarefa termina (`success`, `failed`, `aborted`, `warning` ou `any`), e `onEvent`, quando
+  acontece algo a uma tarefa (`launch`, `relaunch`, `delete`, `approve`, `reject` ou `any`).
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## Atributos
+
+Os atributos do objeto `notifications`:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## Exemplos
+
+Exemplos de notificações, em YAML:
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}A definição, em YAML:{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/rundeck.md b/i18n/pt/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..e695bec
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulários de Rundeck
+parent: Formulários
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Formulários de Rundeck
+{: .no_toc }
+
+Formulários que executam um job de Rundeck
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: rundeck`, além das [propriedades comuns dos formulários](common.html).
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/semaphore.md b/i18n/pt/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..c2eec32
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Formulários de Semaphore
+parent: Formulários
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Formulários de Semaphore
+{: .no_toc }
+
+Formulários que executam um template do Semaphore UI
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: semaphore`, além das [propriedades comuns dos formulários](common.html).
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/forms/subform.md b/i18n/pt/_build_forms/forms/subform.md
new file mode 100644
index 0000000..32c9844
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Subform
+parent: Formulários
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# Subform
+{: .no_toc }
+
+Um fragmento de formulário reutilizável para campos list, campos yaml e páginas de assistente
+{: .fs-6 .fw-300 }
+
+---
+
+Um subformulário é um fragmento de formulário reutilizável. Não aparece na vista de mosaicos e não pode ser submetido diretamente. Em vez disso, é referido por:
+
+- Um campo [`list`](../formfields/list.html): abre o subformulário como editor de drilldown para cada linha
+- Um campo [`yaml`](../formfields/yaml.html) com a propriedade `subform`: abre o subformulário como editor de drilldown para um único objeto
+- Um passo de [`wizard`](wizard.html): mostra o subformulário como uma página do assistente
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Os subformulários **não têm propriedades específicas do tipo**. Só usam as [propriedades comuns dos formulários](common.html): `name`, `description`, `help`, `type` e `fields`.
+
+Quando um subformulário serve de página de um assistente, o seu `description` e o seu `help` fornecem os valores predefinidos do `title` e do `help` do passo. Também pode definir `showHelp` para expandir essa ajuda quando a página carrega.
+
+As propriedades de execução (`playbook`, `template`, `roles`, `inventory`, etc.) não se aplicam aos subformulários, porque um subformulário nunca é submetido diretamente.
+
diff --git a/i18n/pt/_build_forms/forms/wizard.md b/i18n/pt/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..5fac799
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: Assistente
+parent: Formulários
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# Assistente
+{: .no_toc }
+
+Dividir os dados de um formulário por páginas com Voltar e Seguinte
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## O que é um assistente?
+
+Um **assistente** (wizard) transforma um único formulário numa sequência de páginas. Cada página é construída a partir de um [`subform`](subform.html) e o utilizador navega com os botões **Voltar** e **Seguinte**. A validação é aplicada página a página: o utilizador não pode avançar enquanto o passo atual não for válido, a menos que o passo esteja marcado como `optional`.
+
+No fim de cada assistente é acrescentada automaticamente uma **página de revisão** só de leitura. Enumera cada passo com os valores recolhidos, para que o utilizador os possa confirmar antes de submeter. A página de revisão **não** é declarada em YAML; o seu título vem do idioma ativo.
+
+Ao submeter, os **valores recolhidos em todos os passos são juntados num único conjunto de extravars** e enviados para o playbook, template ou workflow subjacente, exatamente como se o utilizador tivesse preenchido um único formulário grande.
+
+Um formulário com `wizard` não precisa dos seus próprios `fields`, mas não pode definir `enableForChat`, e um `subform` não pode ter ele próprio um `wizard`. A [validação no lançamento](../launch-validation/rolling-it-out.html#wizard-forms) verifica o lançamento de um assistente passo a passo.
+
+{: .note }
+> Para saber como um `wizard` difere de um workflow e como os dois se combinam, consulte a entrada das FAQ [Qual é a diferença entre um assistente e um workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow).
+
+---
+
+## Propriedade ao nível do formulário
+
+Um assistente ativa-se com uma única propriedade ao nível do formulário:
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">adicionado na versão {{ wizard_prop.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**Exemplos:**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades dos passos do assistente
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / único</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{var.version}}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">Adicionado</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        Exemplos
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## Combinar um assistente com um workflow
+
+Um assistente pode ser colocado por cima de um formulário de [workflow](workflow.html). Quando o `defaultModel` de cada passo do assistente corresponde ao [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) do nó de workflow correspondente, cada playbook ou template recebe só os valores da sua própria página do assistente.
+
+As FAQ contêm um exemplo completo e a estrutura das extravars juntadas: [Qual é a diferença entre um assistente e um workflow?](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow) (secção *Combinados (assistente por cima de um workflow)*).
+
+Um assistente num formulário [`multistep`](multistep.html), que está obsoleto, funciona da mesma forma, com a [`key`](multistep.html#step_key) do passo em vez de `extra_vars_key`.
+
+---
+
+## Ver também
+
+Páginas e entradas das FAQ relacionadas:
+
+- [Subform](subform.html): as páginas do assistente são construídas a partir de subformulários
+- [Formulários de workflow](workflow.html): o equivalente do assistente na camada de execução
+- [`__parent__` nos subformulários](../faq.html#how-do-i-access-parent-form-data-inside-a-subform): como referir passos anteriores do assistente a partir de um passo posterior
diff --git a/i18n/pt/_build_forms/forms/workflow.md b/i18n/pt/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..df5553c
--- /dev/null
+++ b/i18n/pt/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Formulários de workflow
+parent: Formulários
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# Formulários de workflow
+{: .no_toc }
+
+Formulários que executam um dos workflows do designer
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## Propriedades
+
+Propriedades específicas de `type: workflow`, além das [propriedades comuns dos formulários](common.html). A
+secção [Workflows](../workflows/) descreve os próprios ficheiros de workflow.
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>Atributo</th>
+      <th>Comentários</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / obrigatório</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">adicionado na versão {{ var.version }}</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>Opções:</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }} (predefinido)</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>Predefinição:</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>Exemplos:</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/pt/_build_forms/launch-validation/file-uploads.md b/i18n/pt/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..d651a3d
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Carregamento de ficheiros
+parent: Validação no lançamento
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# Carregamento de ficheiros
+{: .no_toc }
+
+Como são validados os campos de ficheiro
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Um campo de ficheiro nunca confia no que o pedido de lançamento diz sobre um ficheiro. A validação no lançamento verifica o próprio ficheiro, no
+disco do servidor.
+
+---
+
+## Como um ficheiro carregado chega a uma tarefa
+
+Um ficheiro é carregado antes de o formulário ser lançado, em dois passos:
+
+1. O navegador carrega o ficheiro com `POST /api/v2/job/upload`. O servidor guarda-o em `UPLOAD_PATH`.
+2. O pedido de lançamento descreve esse carregamento na sua parte `files`.
+
+A validação no lançamento compara depois a descrição com o disco:
+
+* O ficheiro tem de existir dentro de `UPLOAD_PATH`.
+* O seu caminho e o seu tamanho são lidos do disco, nunca do pedido.
+
+---
+
+## O que é aceite
+
+Um campo de ficheiro só recebe um valor de um carregamento verificado. Tudo o resto é descartado:
+
+* Um caminho que quem chama escreva em `rawFormData` ou `extravars` é ignorado.
+* Um campo de ficheiro obrigatório sem um carregamento real é reportado como `missing`.
+
+---
+
+## Regras dos ficheiros
+
+As regras de um campo de ficheiro são verificadas sobre o ficheiro realmente carregado, com os tamanhos em bytes:
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` e `maxSize` comparam o tamanho real do ficheiro, e `regex` o seu nome. Independentemente de qualquer formulário,
+`UPLOAD_MAX_GB` limita o tamanho de um único carregamento (10 GB por predefinição).
diff --git a/i18n/pt/_build_forms/launch-validation/index.md b/i18n/pt/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..0793e84
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Validação no lançamento
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# Validação no lançamento
+{: .no_toc }
+
+Verificar no servidor cada lançamento de um formulário
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores e autores de formulários: faça com que o servidor verifique cada lançamento, as suas regras e as suas extravars, seja quem for que o envie.
+
+A verificação aplica-se independentemente de quem ou do que lança o formulário: o navegador, um script que chama a API REST,
+ou um agente de IA através do servidor MCP.
+
+---
+
+## Porque existe
+
+As regras de um formulário (`required`, `regex`, `minValue`, `sameAs`, ...) sempre foram verificadas
+no navegador. Depois, o navegador envia duas coisas para `POST /api/v2/job`:
+
+- `rawFormData`: os valores dos campos tal como o utilizador os preencheu;
+- `extravars`: o que o playbook recebe, construído a partir desses valores no navegador.
+
+Sem validação no lançamento, o servidor confia em ambos. Qualquer pessoa com um token válido pode chamar esse
+endpoint diretamente e enviar quaisquer extravars, sem que se aplique nenhuma regex, campo obrigatório ou regra
+de lista. Para um formulário que só é usado no navegador, isso pode ser aceitável; para um
+formulário que outros sistemas lançam por REST, significa que as regras do formulário não são aplicadas de todo.
+
+Além disso, o servidor não tem forma de distinguir um pedido do navegador de um enviado por um
+script: ambos usam o mesmo endpoint, o mesmo token e o mesmo corpo, e os utilizadores podem modificar
+qualquer pedido que o seu próprio navegador envie. Só se pode confiar numa verificação feita no servidor, e a validação
+no lançamento é essa verificação.
+
+---
+
+## As três vias de entrada
+
+A forma como um lançamento é validado depende de como chega e do modo de validação no lançamento:
+
+| Lançado por | Validado | Extravars com que a tarefa é executada |
+|---|---|---|
+| **Servidor MCP** (agente de IA) | sempre, no servidor | construídas sempre pelo servidor |
+| **Navegador** ou **API REST**, validação no lançamento `off` | só no navegador | as que o navegador (ou quem chama) enviou |
+| **Navegador** ou **API REST**, validação no lançamento `log` | no servidor, recusas apenas registadas | as enviadas; diferenças registadas |
+| **Navegador** ou **API REST**, validação no lançamento `enforce` | no servidor, recusado quando inválido | **construídas pelo servidor** |
+
+O navegador, o servidor MCP e a validação no lançamento usam o mesmo código para as regras (o
+motor de formulários partilhado): as mesmas regras, pela mesma ordem, com as mesmas mensagens. Um erro que o
+navegador mostra é recusado pelo servidor com o mesmo texto.
+
+---
+
+## Nesta secção
+
+Cada tema tem a sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Ativá-la](switching-it-on.html) | Para toda a instância, ou para um formulário |
+| [Registar e impor](log-and-enforce.html) | O que cada modo faz com um lançamento que viola as regras |
+| [Linhas de listas](list-rows-and-subforms.html) | Como são validadas as linhas dos campos list |
+| [Carregamento de ficheiros](file-uploads.html) | Como são validados os campos de ficheiro |
+| [Palavras-passe](passwords.html) | Como os campos de palavra-passe são validados e mantidos fora das APIs |
+| [Relançar](relaunching.html) | Como é validada uma tarefa relançada |
+| [Implementação gradual](rolling-it-out.html) | Passar uma instância para enforce, e as limitações conhecidas |
diff --git a/i18n/pt/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/pt/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..619f708
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Linhas de listas
+parent: Validação no lançamento
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# Linhas de listas
+{: .no_toc }
+
+Como são validadas as linhas dos campos list
+{: .fs-6 .fw-300 }
+
+---
+
+Um campo `list` contém linhas; cada linha é uma instância do seu subformulário, preenchida através do editor
+de linhas. Um campo `yaml` com um `subform` é uma dessas linhas. O servidor trata-as da mesma forma
+que o editor de linhas do navegador: cada linha é resolvida através do seu subformulário, com os valores do formulário
+como `__parent__`, as suas regras verificadas e os seus campos calculados avaliados. As listas aninhadas funcionam da
+mesma forma: na própria lista de uma linha, `$(__parent__.__parent__.x)` chega ao formulário.
+
+As linhas são verificadas da seguinte forma:
+
+- **Uma linha que o utilizador acrescentou ou editou** no editor é resolvida e validada.
+- **Uma linha em que ninguém mexeu**, produzida pelo próprio default, expressão ou consulta da lista
+  (como as entradas existentes de uma lista de ACL), passa **exatamente como veio**, tal como no
+  navegador: não é revalidada e não se lhe acrescenta nada. Uma entrada existente que viole uma regra
+  escrita mais tarde não impede o lançamento.
+- **Uma linha marcada como eliminada** (o `deleteMarker` da lista) é mantida tal como está e não é validada.
+
+Para distinguir estas linhas sem confiar no pedido, o servidor volta a executar a própria
+fonte da lista (o seu default, ou então a sua expressão ou consulta) sob a validação no lançamento. Uma linha
+que não passou pelo editor só passa sem alterações **quando é uma das linhas que essa
+fonte produz**. Qualquer outra linha, como uma inventada por quem chama a API REST, é resolvida e
+validada como uma linha editada. Assim, uma linha simples não consegue contornar as verificações, enquanto as
+linhas do navegador em que ninguém mexeu continuam a passar sem alterações.
+
+Um utilizador do navegador só nota isto num caso: os dados da fonte mudaram entre a abertura do
+formulário e o seu lançamento (uma entrada foi alterada ou removida entretanto), **e** essa linha
+viola uma regra do seu subformulário. A linha deixa então de contar como uma das linhas da fonte, pelo que
+é validada, e o lançamento é recusado com a linha indicada, por exemplo
+`acls[2].user_or_group (regex)`.
+
+As linhas que falham aparecem em `rowErrors` com o seu `index` (um campo `yaml` não tem) e no registo como
+`disks[1].size (maxValue)`.
+
+Um lançamento pode conter no máximo **500 linhas** em todos os níveis de aninhamento, já que cada linha executa as consultas do seu subformulário.
+
+---
+
+## Marcadores de linhas
+
+Os marcadores que uma lista coloca nas suas linhas (`insertMarker`, `updateMarker` e `deleteMarker`; sem
+`insertMarker`, as linhas novas recebem `__inserted__` quando a lista define `allowDelete: false`, um `deleteMarker` ou um `updateMarker`)
+chegam ao playbook em todas as linhas que tenham um. Uma linha removida é enviada com o seu marcador de
+eliminação, para que o playbook a possa remover. Antes da 6.4.1, uma linha de lista só levava um marcador quando o seu
+subformulário o declarava como campo (oculto).
diff --git a/i18n/pt/_build_forms/launch-validation/log-and-enforce.md b/i18n/pt/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..5772778
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Registar e impor
+parent: Validação no lançamento
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# Registar e impor
+{: .no_toc }
+
+O que cada modo faz com um lançamento que viola as regras
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O que faz `log`
+
+Cada lançamento é verificado, mas para o utilizador nada muda. É escrito um aviso no registo quando:
+
+- o lançamento **seria recusado**, com o motivo (só nomes de campos e tipos de regras, nunca
+  valores):
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- as extravars que o cliente enviou **diferem** das que o servidor constrói, com as
+  chaves de primeiro nível que diferem:
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+Execute primeiro `log` durante algum tempo numa instância real. Mostra que formulários seriam recusados e
+quais calculam valores de forma diferente no servidor, antes de alguém ser afetado.
+
+---
+
+## O que faz `enforce`
+
+Com `enforce`, um lançamento inválido é recusado, e um válido é executado com as extravars que o servidor
+constrói.
+
+### Um lançamento que viola as regras é recusado
+
+`POST /api/v2/job` responde `422` com os campos que falham:
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing` - campos obrigatórios sem valor;
+- `invalid` - campos que violam uma regra, escolhas que não são uma das opções, e campos
+  list com uma linha que falha;
+- `waiting` - campos que não puderam ser avaliados (um campo de que precisam nunca recebeu valor);
+- `validationErrors` - por campo, cada regra que falha com a mensagem que o navegador mostra;
+- `rowErrors` - por campo list, as linhas que falham (ver [Linhas de listas](list-rows-and-subforms.html));
+- `uploads` - campos de ficheiro cujo carregamento não pôde ser verificado.
+
+Um lançamento **sem `rawFormData`** também é recusado: os seus valores não podem ser verificados.
+
+### Um lançamento válido é executado com as extravars do servidor
+
+A tarefa não é executada com as extravars que o cliente enviou. O servidor constrói-as a partir dos valores
+verificados, com o mesmo código do navegador, e executa essas. Quem chama e envia `rawFormData` válido
+juntamente com `extravars` diferentes recebe as extravars que correspondem aos valores, não
+as que enviou.
+
+Do pedido, o servidor mantém `__verbose__` (só para utilizadores autorizados a usar o modo verbose). As
+chaves reservadas (`__playbook__`, `__inventory__`, ...) vêm do formulário, como sempre, e
+`ansibleforms_user` é o utilizador que lança.
+
+### O que o utilizador viu nem sempre é o que é executado
+
+Construir as extravars significa avaliar de novo o formulário: cada expressão e cada consulta é executada
+mais uma vez no servidor, um momento depois de o navegador a ter executado, como o utilizador que lança. Um valor
+que dependa de **quando** ou **onde** é avaliado pode diferir e, nesse caso, usa-se o
+valor do servidor:
+
+| O quê | Porque pode diferir | Em que medida |
+|---|---|---|
+| `fn.fnTime()`, um carimbo temporal, um nome construído a partir da hora | avaliado de novo, alguns segundos depois | só importa na fronteira de um segundo ou de uma data. `fnTime` também já é executado no servidor no fluxo do navegador, com o mesmo fuso horário (o `TZ` do contentor) |
+| uma consulta, `fnRestAdvanced`, `fnSsh`, `fnDnsResolve`, a leitura de um ficheiro | os dados externos mudaram entretanto | só quando mudaram |
+| uma expressão `runLocal` que use `new Date()`, `toLocaleString`, `Intl` | o navegador usa o fuso horário e o idioma do utilizador, o servidor os seus | só essas expressões |
+
+O mesmo se aplica à **validação**: uma regra que lê um desses campos (`notIn` contra o resultado de uma
+consulta, `validIf` sobre um indicador calculado) é verificada com o valor do servidor. Os formulários cujas
+extravars diferem aparecem nos avisos de `log` descritos acima; reveja-os antes de impor.
diff --git a/i18n/pt/_build_forms/launch-validation/passwords.md b/i18n/pt/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..4359dd1
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Palavras-passe
+parent: Validação no lançamento
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# Palavras-passe
+{: .no_toc }
+
+Como os campos de palavra-passe são validados, guardados e mantidos fora das APIs
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Um campo de palavra-passe é validado como qualquer outro campo. O seu valor, no entanto, fica no servidor e nunca é devolvido a
+um cliente.
+
+---
+
+## Onde fica uma palavra-passe
+
+O servidor guarda a palavra-passe com a tarefa, nas suas extravars:
+
+* Uma **aprovação** pode então continuar a tarefa com a palavra-passe que o utilizador introduziu.
+* Um **relançamento tal como foi executado** pode reutilizá-la, quando a validação no lançamento não é `enforce`.
+
+A palavra-passe guardada só é usada no servidor.
+
+---
+
+## O que as APIs devolvem
+
+Nenhuma API devolve alguma vez uma palavra-passe:
+
+* Uma tarefa lida através da API REST ou do `get_job` do servidor MCP oculta todos os campos `password` do seu formulário, também dentro
+  de linhas de listas e de subformulários YAML.
+* `MASK_EXTRAVARS_REGEX` (predefinição `password|secret|token`) oculta também todas as extravars cujo nome corresponda, para
+  segredos que não são campos de palavra-passe.
+
+---
+
+## O que um relançamento recebe
+
+Para preencher antecipadamente um relançamento, o navegador recebe os dados em bruto do formulário da tarefa. Esses dados nunca contêm uma palavra-passe, nem sequer dentro
+de linhas de listas ou de subformulários YAML, pelo que o utilizador introduz de novo a palavra-passe.
+
+Um campo de palavra-passe que as dependências do formulário ocultem não é necessário e não tem de ser introduzido de novo.
diff --git a/i18n/pt/_build_forms/launch-validation/relaunching.md b/i18n/pt/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..ab65e2d
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: Relançar
+parent: Validação no lançamento
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# Relançar
+{: .no_toc }
+
+Como é validada uma tarefa relançada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Uma tarefa pode ser relançada de duas formas. A forma como o relançamento é verificado depende de qual delas, e do modo de validação
+no lançamento.
+
+---
+
+## Dois tipos de relançamento
+
+Os dois tipos diferem em se quem chama envia ou não valores novos:
+
+* **Tal como foi executada**: o botão Relançar, `POST /api/v2/job/{id}/relaunch` sem corpo, ou `relaunch_job` sem
+  `values`.
+* **Com alterações**: as mesmas chamadas com valores novos, aplicados por cima dos valores dos campos guardados da tarefa:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## Como cada um é verificado
+
+O modo de validação no lançamento decide se um relançamento é repetido tal como estava ou verificado de novo:
+
+| Relançamento | `off` / `log` | `enforce` |
+|---|---|---|
+| **Tal como foi executada** | repete as extravars guardadas da tarefa, palavras-passe incluídas | a verificação completa, a partir dos valores dos campos guardados |
+| **Com alterações** | a verificação completa, sobre os valores guardados com as alterações aplicadas por cima | a verificação completa, da mesma forma |
+
+Uma exceção com `enforce`: uma tarefa lançada por um agendamento de nível de administrador não tem valores de campos próprios, por isso relançá-la tal como foi executada
+repete as extravars guardadas do agendamento, para um administrador ou para um utilizador com a opção de função `allowScheduledJobs`.
+
+Um relançamento verificado (ver [Registar e impor](log-and-enforce.html)) inicia uma nova tarefa em nome de quem chama.
+
+---
+
+## Campos de palavra-passe
+
+Os valores dos campos guardados não contêm palavras-passe, pelo que um relançamento verificado não tem nenhuma para um **campo de palavra-passe visível**:
+
+* O relançamento é recusado como `unsupported`, com os `passwordFields` que lhe faltam.
+* Lance de novo o formulário e introduza a palavra-passe.
+* Um campo de palavra-passe que as dependências do formulário **ocultam** não é necessário e não bloqueia o relançamento.
+
+Com `enforce`, isto aplica-se também ao botão Relançar.
+
+---
+
+## Quem pode relançar
+
+Ambos os tipos de relançamento exigem:
+
+* que o formulário permita relançar (`allowRelaunch`, verdadeiro por predefinição);
+* a opção de função `allowJobRelaunch`;
+* que o utilizador seja **o dono da tarefa**, um administrador, ou um utilizador com a opção de função `manageAllJobs`.
+
+Ver todas as tarefas (`showAllJobLogs`) não chega para relançar a tarefa de outro utilizador. Os aprovadores podem ver uma tarefa que aguarda a sua
+aprovação, mas também não a podem relançar.
diff --git a/i18n/pt/_build_forms/launch-validation/rolling-it-out.md b/i18n/pt/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..5a7b30d
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Implementação gradual
+parent: Validação no lançamento
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# Implementação gradual
+{: .no_toc }
+
+Passar uma instância para enforce, e as limitações conhecidas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Implementação gradual
+
+`enforce` é a predefinição. Numa instância com scripts ou outros sistemas que lançam formulários por
+REST, chegue lá por passos, observando o registo antes de recusar seja o que for:
+
+1. Defina `LAUNCH_VALIDATION=log` para toda a instância (antes de atualizar, numa atualização).
+2. Funcione neste modo durante algum tempo e reveja o registo: os avisos `would refuse` indicam lançamentos
+   que violam as regras; os avisos `extravars differ` indicam formulários que calculam algo
+   de forma diferente no servidor (um carimbo temporal, dados externos). Decida para cada formulário se isso
+   importa.
+3. Mude esses formulários para `launchValidation: enforce`. Quem chamava com valores inválidos ou
+   extravars inventadas recebe agora um `422` com o motivo.
+4. Quando todos os formulários se comportarem como esperado, remova `LAUNCH_VALIDATION` (ou defina-a como `enforce`) para toda a instância.
+
+---
+
+## Limitações
+
+A validação no lançamento ainda não abrange tudo:
+
+- **Os formulários com assistente** não podem ser relançados com alterações, e uma tarefa de assistente lançada antes da 7.0
+  não pode ser relançada com `enforce` (não guardava os valores dos seus passos). O servidor MCP
+  não pode lançar formulários com assistente.
+- **A resolução de marcadores** no navegador ainda usa a sua própria cópia do código do servidor; em
+  casos-limite raros (`__undefined__`, aspas dentro de expressões) os dois podem resolver um
+  marcador de forma diferente. `log` revela essas diferenças.
+- **As expressões `runLocal`** são executadas no motor JavaScript do navegador, no navegador, e numa
+  sandbox no servidor; o mesmo código produz o mesmo resultado, exceto quando depende
+  do fuso horário ou do idioma do navegador.
+
+---
+
+## Formulários com assistente
+
+Um [assistente](../forms/wizard.html) é verificado passo a passo: o navegador envia os valores de
+cada passo, e o servidor verifica cada passo que o utilizador submeteria com o seu próprio subformulário.
+
+- Um passo é deixado de fora quando é `optional` e o utilizador o saltou, ou quando o seu `when` é falso.
+- Um passo lê os passos anteriores através de `$(__parent__.<step>.<field>)`, com os seus valores verificados.
+- Os erros indicam o passo e o campo, como `<step>.<field>`.
+- Com `enforce`, as extravars são construídas no servidor, cada passo sob o seu `defaultModel`.
+- Os campos de ficheiro não são suportados num assistente.
diff --git a/i18n/pt/_build_forms/launch-validation/switching-it-on.md b/i18n/pt/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..57c4e93
--- /dev/null
+++ b/i18n/pt/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Ativá-la
+parent: Validação no lançamento
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# Ativá-la
+{: .no_toc }
+
+Para toda a instância, ou para um formulário
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+A validação no lançamento tem duas definições. **Aplica-se a mais rigorosa das duas.**
+
+---
+
+## Para toda a instância: `LAUNCH_VALIDATION`
+
+A variável de ambiente [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) aplica-se a todos os formulários:
+
+- `off` - sem verificação no servidor: a tarefa é executada com as extravars que o navegador ou quem chama enviou.
+- `log` - cada lançamento é verificado; o que seria recusado é escrito no registo como
+  aviso, e o lançamento continua a ser executado como antes.
+- `enforce` (predefinição) - um lançamento inválido é recusado, e um válido é executado com as extravars que o
+  servidor constrói.
+
+Um valor vazio ou desconhecido também equivale a `enforce`. As alterações têm efeito sem reiniciar.
+
+{: .warning }
+> **A atualização muda o comportamento.** Uma instância que não define `LAUNCH_VALIDATION` impõe
+> a validação a todos os lançamentos depois da atualização. Os scripts que chamam `POST /api/v2/job` sem `rawFormData`,
+> ou com valores que violam as regras de um formulário, são recusados com um `422`. Defina
+> `LAUNCH_VALIDATION=log` antes de atualizar para ver o que seria recusado, ou `off` para manter o
+> comportamento antigo (ver [Implementação gradual](rolling-it-out.html)).
+
+---
+
+## Para um formulário: `launchValidation`
+
+Um formulário pode definir o seu próprio nível:
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+Use esta definição numa instância que funciona com `off` ou `log`, para um formulário que sabe que vai ser
+lançado por REST: esse formulário fica sob enforce, enquanto o resto da instância não. Também pode ser definida no designer, nas
+definições do formulário.
+
+**Um formulário pode ser tornado mais rigoroso do que a instância, nunca mais permissivo.** Com `LAUNCH_VALIDATION`
+em `enforce`, o `launchValidation: off` de um formulário não tem efeito: um formulário não pode sobrepor-se
+à decisão de um operador.
+
+Os formulários com assistente também a usam: o lançamento de um assistente é verificado passo a passo, cada passo com o seu próprio
+subformulário (ver [Formulários com assistente](rolling-it-out.html#wizard-forms)).
diff --git a/i18n/pt/_build_forms/workflows/designer.md b/i18n/pt/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..c2bd9b0
--- /dev/null
+++ b/i18n/pt/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: Editar no designer
+parent: Workflows
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# Editar no designer
+{: .no_toc }
+
+Desenhar um workflow e experimentá-lo sem executar nada
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A secção Fluxos de trabalho
+
+**Designer > Fluxos de trabalho** lista os ficheiros de workflow num explorador de ficheiros, com os separadores YAML, Visual e Pré-visualização de todas as
+secções do [designer](../designer/).
+
+- **O botão `+`** da barra de ferramentas cria um ficheiro de workflow, com um workflow vazio para começar.
+- **YAML** mostra o ficheiro tal como está escrito. Os comentários e a ordem das chaves também são mantidos pelos outros separadores.
+- **Visual** desenha cada workflow do ficheiro como um grafo, com o seu nome e descrição por cima. Um ficheiro com dois workflows
+  mostra ambos, um por baixo do outro.
+- **Pré-visualização** é um ensaio do workflow: ver [Experimentá-lo](#trying-it-out).
+
+Os problemas são listados por cima do grafo, cada um com uma ligação que abre o YAML na sua linha: uma ligação a um nó que não
+existe, um ciclo, um playbook, inventário, credencial, runner ou repositório que o designer não conhece.
+
+---
+
+## O grafo
+
+O grafo lê-se da esquerda para a direita, de **START** até aos últimos nós. Cada nó mostra o seu identificador e, por baixo, o que
+executa; as ligações têm a cor do que as faz disparar, como diz a legenda dentro do grafo: em caso de sucesso, em caso de falha,
+sempre.
+
+- **Clique em START** para adicionar um primeiro nó: um nó sem pai, que corre assim que o workflow arranca.
+- **Clique num nó** para o editar.
+- **Clique numa ligação** para mudar o que a faz disparar, ou para a remover.
+
+---
+
+## Adicionar um nó
+
+Um nó novo é adicionado com um assistente: **Novo nó em caso de sucesso**, **Novo nó em caso de falha** ou **Novo nó sempre** num nó
+existente, ou START para um primeiro.
+
+1. **O que executa**: o identificador do nó, **Executa** (que tipo de nó é e, para um nó de playbook, onde corre)
+   e o que executa: um playbook ou um modelo ou job, um workflow, o nome e o tempo limite de uma aprovação, ou um repositório. Ver
+   [Onde corre um nó](#where-a-node-runs).
+2. **Como corre**: as definições de execução: o inventário, as credenciais, o limite, as etiquetas, a verbosidade,
+   o modo check e o modo diff, a condição (**Corre quando**) e **Valores de** (ver [o ficheiro do workflow](file.html#run-settings)).
+3. **Para onde vai**: o nó depois do qual corre, e em que caso.
+
+**Criar** adiciona o nó ao YAML.
+
+---
+
+## Onde corre um nó
+
+**Executa** diz o que um nó executa e onde, numa só lista: **Playbook no RTE**, **Modelo no AWX**, **Modelo no
+Semaphore**, **Job no Rundeck**, **Job no Jenkins** e depois **Workflow**, **Aprovação** e **Pull de repositório**.
+
+| Executa | O campo por baixo | Runner |
+|---|---|---|
+| **Playbook no RTE** | **Playbook**: um playbook do designer | **O RTE predefinido**, ou um runner RTE pelo nome |
+| **Modelo no AWX** (incluindo AAP e Ascender) | **Modelo**: o nome do modelo, escrito à mão | os runners AWX, cada um com a sua variante |
+| **Modelo no Semaphore** | **Modelo**: o nome do modelo, escrito à mão | os runners Semaphore |
+| **Job no Rundeck** ou **Job no Jenkins** | **Job**: o nome do job, escrito à mão | os runners Rundeck ou Jenkins |
+
+- **Playbook no RTE** é sempre oferecido; os outros só quando a instância tem um [runner](../runners.html) desse tipo.
+- **Runner** lista só os runners desse tipo, com o predefinido marcado e pré-selecionado (ou o primeiro por nome).
+- Escolher outro sítio limpa o que o nó executa, para que seja escolhido de novo.
+- Um nó cujo runner o designer não conhece mostra **Modelo ou job em** esse runner.
+
+O ficheiro do workflow não muda: um nó destes é um nó `job_template` com um `runner:` (ver
+[o ficheiro do workflow](file.html#run-settings)).
+
+---
+
+## Editar um nó
+
+Clicar num nó abre o seu diálogo, em quatro separadores:
+
+| Separador | O que contém |
+|---|---|
+| **O que executa** | O identificador, **Executa**, o que executa e, para um nó de playbook, o runner |
+| **Como corre** | As definições de execução; as credenciais escolhem-se de uma lista, cada uma adicionada com `+` |
+| **Corre depois de** | As ligações para o nó, e **Todos os pais têm de convergir** |
+| **Executa a seguir** | As ligações que saem dele, com **Ligar a um nó existente:** e **Ligar a um novo nó:** |
+
+**Ver em YAML** abre o YAML no nó, e **Remover nó** remove-o com as suas ligações. Cada alteração é escrita no
+YAML de imediato; **Guardar** guarda o ficheiro.
+
+---
+
+## Experimentá-lo
+
+O separador **Pré-visualização** percorre o workflow sem lançar nada, segundo as regras do AWX.
+
+Todos os nós começam como sucesso. Clique num nó para o fazer falhar, e clique de novo para o fazer ter sucesso; o grafo mostra então
+que nós correriam, quais não correriam e se o workflow falharia. **Repor** faz com que todos os nós voltem a ter sucesso.
diff --git a/i18n/pt/_build_forms/workflows/file.md b/i18n/pt/_build_forms/workflows/file.md
new file mode 100644
index 0000000..c10fefc
--- /dev/null
+++ b/i18n/pt/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: O ficheiro do workflow
+parent: Workflows
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# O ficheiro do workflow
+{: .no_toc }
+
+A sintaxe do workflow, os tipos de nó e as definições de execução de cada nó
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Onde ficam os ficheiros de workflow
+
+Os ficheiros de workflow são ficheiros YAML na pasta local de workflows e em todos os repositórios usados para workflows.
+
+- **A pasta local** é [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), por predefinição `workflows` dentro da
+  pasta persistente.
+- **Um repositório** com **Usar para workflows?** ligado é lido por inteiro, pelo que os seus ficheiros de workflow podem estar em qualquer pasta. O
+  designer guarda-os de volta no repositório, e **Push** envia-os para o remoto.
+
+É lido todo o ficheiro YAML que contenha `workflow_job_templates`, até seis pastas de profundidade, e um ficheiro pode conter vários
+workflows. Um formulário indica um workflow pelo seu `name`, por isso mantenha os nomes únicos: quando dois workflows partilham um nome, uma tarefa que
+o execute falha e pede para mudar o nome de um deles.
+
+---
+
+## A sintaxe
+
+Um ficheiro de workflow é escrito na sintaxe de uma exportação do AWX, com os nós em `related.workflow_nodes`:
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+A forma da coleção `awx.awx` também é lida: `workflow_nodes` diretamente sob o workflow, e nomes escritos como
+strings simples (`inventory: staging`) em vez de mapas (`inventory: {name: staging}`).
+
+### O workflow
+
+Uma entrada de workflow tem algumas chaves próprias, ao lado dos seus nós:
+
+| Chave | O que é |
+|---|---|
+| `name` | O nome do workflow, que o `workflow:` de um formulário indica |
+| `description` | Para que serve, mostrado no designer |
+| `extra_vars` | Variáveis que todos os nós recebem; os valores do formulário prevalecem sobre elas |
+| `related.workflow_nodes` | Os nós |
+
+### Um nó
+
+Cada nó tem um identificador, o que executa e as suas ligações:
+
+| Chave | O que é |
+|---|---|
+| `identifier` | O id do nó: letras, dígitos, pontos, hífenes, dois pontos e underscores, único no workflow |
+| `unified_job_template.type` | O que o nó executa: ver [tipos de nó](#node-types) |
+| `unified_job_template.name` | O playbook, workflow, aprovação ou repositório que executa |
+| `related.success_nodes` | Os nós que correm quando este tem sucesso |
+| `related.failure_nodes` | Os nós que correm quando este falha |
+| `related.always_nodes` | Os nós que correm quando este terminou, seja como for |
+| `all_parents_must_converge` | `true`: o nó espera que todas as ligações para ele disparem, não só uma |
+
+As ligações têm de seguir para a frente: um workflow cujas ligações formem um ciclo não corre.
+
+---
+
+## Tipos de nó
+
+Um nó executa uma de quatro coisas, com os nomes que o AWX lhes dá:
+
+| Tipo | O que o nó executa |
+|---|---|
+| `job_template` | Um dos playbooks do designer, como tarefa própria no RTE; ou, com `runner:`, o modelo ou job desse runner |
+| `workflow_job_template` | Outro workflow, como tarefa de workflow filha; os workflows aninham-se até cinco níveis |
+| `workflow_approval_template` | Uma aprovação: a tarefa do workflow espera até alguém a aprovar ou rejeitar |
+| `project` | Um pull do repositório que indica (a atualização de projeto do AWX) |
+
+O `unified_job_template.timeout` de um nó de aprovação é em segundos. Quando passa sem resposta, o nó falha; `0` ou sem
+tempo limite, espera por uma resposta o tempo que for preciso. Uma aprovação rejeitada faz falhar o nó, e o workflow continua pelas suas
+ligações.
+
+---
+
+## Definições de execução
+
+Um nó `job_template` aceita as definições de um nó do AWX, no próprio nó:
+
+| Chave | O que faz |
+|---|---|
+| `inventory` | O inventário sobre o qual o playbook corre, pelo seu nome, como o `inventory:` de um formulário |
+| `related.credentials` | As credenciais: cada uma chega ao playbook com o seu próprio nome, e a primeira *SSH* é também o login com que o ansible se liga. Uma de vault só abre os vaults |
+| `limit` | Corre apenas nestes hosts (`--limit`) |
+| `job_tags` | Corre apenas as tarefas com estas etiquetas (`--tags`) |
+| `skip_tags` | Salta as tarefas com estas etiquetas (`--skip-tags`) |
+| `verbosity` | `0` a `5`: o número de `-v` |
+| `diff_mode` | `true`: mostra as alterações (`--diff`) |
+| `job_type` | `check`: um ensaio (`--check`); `run` ou nenhum: uma execução real |
+| `extra_data` | Variáveis que este nó recebe, abaixo das `extra_vars` do workflow e dos valores do formulário |
+
+A tarefa do nó recebe os valores do formulário como extra vars. Os valores do formulário prevalecem sobre as `extra_vars` do workflow, que prevalecem
+sobre o `extra_data` do nó, tal como fazem as respostas de um survey no AWX.
+
+---
+
+## Chaves próprias do AnsibleForms
+
+Três chaves de um nó são próprias do AnsibleForms, e o AWX ignora-as, para que um workflow possa fazer o que faz um formulário multistep:
+
+| Chave | O que faz |
+|---|---|
+| `runner` | Num nó `job_template`, executa o modelo ou job desse runner em vez de um playbook do designer: AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins. Um runner RTE executa aí o playbook do nó. Um mesmo workflow pode misturá-los. |
+| `if_extra_var` | O nó só corre quando esta extra var é `true`, como o `ifExtraVar` de um passo multistep. Se não se cumprir, o nó é saltado, e o que vem a seguir corre como depois de um sucesso. Não se aplica a um nó de aprovação, que corre sempre. |
+| `extra_vars_key` | O nó recebe só esta chave das extra vars, com o utilizador copiado, como a `key` de um passo multistep |
+
+Num runner de modelos, `unified_job_template.name` é o modelo ou job a executar, e o `limit`, os `job_tags`, o modo check
+e o modo diff do nó são passados como os passaria um formulário do tipo desse runner. Uma `verbosity` acima de `0` ativa o
+`verbose` do formulário, e `skip_tags` não é passado. Só um runner AWX (AWX, AAP ou Ascender) recebe o inventário do nó, e as
+credenciais como as suas credenciais AWX; Semaphore, Rundeck e Jenkins recebem as credenciais como as `credentials` de um formulário.
diff --git a/i18n/pt/_build_forms/workflows/index.md b/i18n/pt/_build_forms/workflows/index.md
new file mode 100644
index 0000000..f05fdfb
--- /dev/null
+++ b/i18n/pt/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: Workflows
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# Workflows
+{: .no_toc }
+
+Encadear playbooks, aprovações e outros workflows, como faz o AWX
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para autores de formulários: o que é um workflow, como correm os seus nós e onde continuar a ler.
+
+Um workflow é um grafo de nós. Cada nó executa algo: um dos playbooks do designer, outro workflow, uma aprovação
+ou um pull de repositório. As ligações entre os nós dizem o que corre a seguir, em caso de sucesso, em caso de falha ou sempre. Um formulário
+do [tipo `workflow`](../forms/workflow.html) lança-o, e a página de tarefas desenha-o em direto enquanto corre.
+
+Os workflows seguem a sintaxe e as regras do AWX, pelo que um workflow exportado do AWX lê-se da mesma forma no AnsibleForms. Correm
+no RTE, sem AWX: um nó de playbook é uma tarefa própria, com o inventário, as credenciais, o limite e as etiquetas do nó.
+
+---
+
+## Como corre um workflow
+
+Os nós correm segundo as regras do AWX, e os ramos que não dependem uns dos outros correm lado a lado.
+
+- **Um nó sem pai arranca de imediato**, quando o workflow arranca.
+- **Uma ligação dispara quando o seu nó terminou**: uma ligação *em caso de sucesso* depois de um sucesso, uma ligação *em caso de falha* depois de uma falha,
+  uma ligação *sempre* depois de qualquer um dos dois. Um nó cancelado não dispara nenhuma das suas ligações.
+- **Um nó arranca assim que uma ligação para ele dispara.** Com **Todos os pais têm de convergir** ligado, espera até que todas as ligações
+  para ele tenham disparado.
+- **Um nó que já não pode arrancar é marcado como *não corre***, tal como os nós que só ele podia arrancar.
+- **O workflow falha quando um nó falhou e nada trata dessa falha**: esse nó não tem nenhuma ligação *em caso de falha* nem *sempre*.
+  Uma falha que uma ligação trata não faz falhar o workflow.
+
+Um nó com uma condição (`if_extra_var`) que não se cumpre é saltado. O que vem a seguir corre como depois de um sucesso. Um nó de
+aprovação não aceita condição: espera sempre por uma resposta.
+
+---
+
+## Passar dados entre nós
+
+O que o playbook de um nó recolhe com `set_stats` chega aos nós seguintes como extra vars, da mesma forma que o AWX passa os
+artefactos de uma tarefa. Um nó recebe os dados de cada pai cuja ligação para ele disparou, juntados pela ordem em que os pais estão
+escritos, e passa adiante o que recebeu mais os dados da sua própria tarefa, ganhando os seus quando ambos definem a mesma chave.
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+Um nó seguinte lê então {% raw %}`{{ version }}` e `{{ build_id }}`{% endraw %} como qualquer outra extra var.
+
+As extra vars de um nó vêm de quatro sítios. Um deles, `extra_data`, são as variáveis próprias do nó: o nome que o AWX lhes dá,
+definidas no nó no [ficheiro do workflow](file.html#run-settings). Quando dois definem a mesma chave, a ordem de precedência é
+a do AWX, da mais baixa para a mais alta:
+
+| Origem | Prevalece sobre |
+|---|---|
+| as variáveis próprias do nó (`extra_data`) | nada |
+| os dados passados com `set_stats` | o `extra_data` do nó |
+| as `extra_vars` do workflow | os dados passados |
+| os valores do formulário | tudo |
+
+- Só são passados os dados de todo o playbook: `set_stats` com `per_host: false`, a sua predefinição.
+- Um nó de aprovação, um nó saltado e um nó de projeto passam adiante o que lhes chegou.
+- O resultado de um nó termina com as chaves que passou adiante, só pelo nome, pois os seus valores podem ser secretos.
+- A tarefa do nó guarda os seus dados como artefactos (**Mostrar artefactos** na sua página), e a tarefa do workflow guarda os dados de todos os seus
+  nós, pelo que um workflow aninhado também os passa aos nós que vêm depois dele.
+- Um nó que corre num runner AWX passa adiante os artefactos da sua tarefa AWX da mesma forma.
+---
+
+## Nesta secção
+
+As páginas seguintes descrevem os workflows em detalhe:
+
+| Página | O que abrange |
+|---|---|
+| [O ficheiro do workflow](file.html) | A sintaxe do ficheiro, os tipos de nó e as definições de execução de cada nó |
+| [Editar no designer](designer.html) | A secção Fluxos de trabalho do designer: o grafo, os diálogos de nó e de ligação e o ensaio |
+| [Executar um workflow](running.html) | O formulário que o lança, a página da tarefa, os resultados dos nós, as aprovações e a interrupção |
diff --git a/i18n/pt/_build_forms/workflows/running.md b/i18n/pt/_build_forms/workflows/running.md
new file mode 100644
index 0000000..97bd8ce
--- /dev/null
+++ b/i18n/pt/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: Executar um workflow
+parent: Workflows
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# Executar um workflow
+{: .no_toc }
+
+Lançar um workflow a partir de um formulário e acompanhá-lo na página de tarefas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O formulário
+
+Um formulário do [tipo `workflow`](../forms/workflow.html) lança um workflow, indicado com `workflow:` tal como se faz com um playbook: pelo
+seu **ficheiro** na pasta de workflows, com as suas subpastas (`team/deploy-app.yml`), ou pelo **nome** do workflow dentro
+do ficheiro (`deploy-app`):
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+Os campos do formulário chegam a todos os nós como extra vars, e o mesmo acontece com as suas [`credentials`](../forms/workflow.html#workflow_credentials), com os nomes
+que o formulário lhes dá, tal como as de um formulário multistep chegam aos seus passos:
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+As credenciais próprias de um nó, definidas no ficheiro do workflow, chegam ao seu playbook com o seu próprio nome e prevalecem quando ambos usam o mesmo nome. No separador Visual de um formulário no designer, **Workflow** é uma lista dos
+ficheiros de workflow do designer.
+
+Um nome de ficheiro sozinho também é encontrado numa subpasta, quando só um ficheiro o tem. Dois workflows com o mesmo nome travam um formulário que
+o indique pelo nome, e o designer avisa quando guarda o segundo: mude o nome de um deles, ou indique o seu ficheiro. Um workflow que não pode ser
+encontrado termina a tarefa como falhada, com o motivo no seu resultado.
+
+---
+
+## A tarefa
+
+Uma tarefa de workflow corre no servidor do AnsibleForms, e cada nó de playbook corre como uma tarefa própria, filha da tarefa
+do workflow, tal como os passos de um formulário multistep: um playbook do designer no RTE ou, para um nó com `runner:`, o
+modelo ou job desse runner em AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins (ver [Onde corre um nó](designer.html#where-a-node-runs)).
+
+A página da tarefa desenha o workflow em direto: cada nó com a cor do seu estado, as ligações que dispararam e os nós que não
+vão correr. Os dados no topo indicam o workflow em vez de um playbook.
+
+- **Clique num nó** que terminou para abrir o seu resultado num diálogo.
+- **O resultado** contém o resultado de cada nó sob um cabeçalho `WORKFLOW NODE [identifier] (status)`, pela ordem em que os nós
+  terminaram.
+- **Mostrar extravars** e **Mostrar artefactos**, no cabeçalho de cada nó no resultado e no diálogo aberto a partir do grafo,
+  mostram as extravars e os artefactos próprios desse nó (`{}` quando não tem nenhum), em JSON ou YAML, com um botão Copiar.
+
+As extravars de um nó contêm o que os nós anteriores lhe passaram, e os seus artefactos o que o seu playbook recolheu com
+`set_stats`. Os dois botões seguem as [opções de função](../config/roles.html#role-options) `showExtravars` e
+`showArtifacts`. Os mesmos dados vêm de `GET /api/v2/job/{id}/node/{nodeId}`, para quem possa ver a tarefa.
+
+A tarefa falha quando um nó falhou e nada tratou essa falha, segundo a regra do AWX; caso contrário, tem sucesso.
+
+---
+
+## Aprovações
+
+Um nó de aprovação retém a tarefa do workflow até alguém lhe responder.
+
+Quando o workflow chega a um nó de aprovação, o estado da tarefa passa a **À espera de aprovação**: aparece no sino e na
+página da tarefa, como um [ponto de aprovação](../forms/approval.html) de um formulário. O nome do nó é o título da aprovação e a sua descrição
+a mensagem; o resto vem do `approval` do formulário:
+
+- os seus `roles` decidem quem a pode aprovar ou rejeitar, e `allowSelf` se quem lançou também a pode aprovar;
+- o pedido é enviado para as suas `notifications` e os seus `channels`.
+
+Um formulário de workflow sem `approval` também retém a tarefa num nó de aprovação, mas aí só um administrador a pode aprovar.
+
+- **Aprovada**, o nó tem sucesso e o workflow continua pelas suas ligações *em caso de sucesso*.
+- **Rejeitada**, o nó falha e o workflow continua pelas suas ligações *em caso de falha*.
+- **Expirada**, depois do tempo limite do nó sem resposta, o nó também falha.
+
+---
+
+## Interromper
+
+**Interromper** numa tarefa de workflow em execução para-a: as tarefas dos nós em execução são interrompidas, não arranca mais nada, e uma aprovação de que
+esteja à espera é cancelada. Uma tarefa de workflow à espera de uma aprovação também pode ser interrompida.
diff --git a/i18n/pt/_configure/announcements.md b/i18n/pt/_configure/announcements.md
new file mode 100644
index 0000000..4a5e558
--- /dev/null
+++ b/i18n/pt/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Anúncios
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# Anúncios
+{: .no_toc }
+
+Mensagens sob o cabeçalho para todos, como uma janela de manutenção, cada uma visível do seu início ao seu fim
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: informe todos os utilizadores de uma janela de manutenção ou de um incidente, em **Definições > Aparência > Anúncios**.
+
+A página precisa da opção de função `showSettings` ou `showAppearanceSettings`. A partir da 7.3.0 é uma só lista, e cada anúncio
+tem a sua própria página e o seu interruptor Ativado.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Geral](announcements/general.html) | O interruptor Ativado de cada anúncio, que substituiu o interruptor de todos eles |
+| [Lista](announcements/list.html) | Os anúncios que ainda não terminaram, as suas colunas e a página de um anúncio |
+| [Adicionar um](announcements/adding-one.html) | O assistente de dois passos: a mensagem e, depois, quando aparece |
+
+
+---
+
+## Onde aparecem
+
+Os anúncios aparecem como uma linha sob o cabeçalho de todas as páginas, para todos os utilizadores com sessão iniciada, cada um na cor do seu tipo.
+
+Podem aparecer vários ativados ao mesmo tempo, o mais recente primeiro. A página de início de sessão e um formulário incorporado noutro site não mostram nenhum.
+
+Cada um tem um botão de fechar. Um anúncio fechado continua fechado nesse separador do navegador até o separador ser fechado, ou
+até a sua mensagem ou a sua data de fim mudarem. Um anúncio guardado chega de imediato a todos os navegadores abertos; um que
+atinge a sua data de início ou de fim aparece ou desaparece neles em menos de um minuto.
diff --git a/i18n/pt/_configure/announcements/adding-one.md b/i18n/pt/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..72165fb
--- /dev/null
+++ b/i18n/pt/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Adicionar um
+parent: Anúncios
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# Adicionar um
+{: .no_toc }
+
+O assistente de dois passos: a mensagem e, depois, quando aparece
+{: .fs-6 .fw-300 }
+
+**Adicionar anúncio** abre um assistente de dois passos. **Mensagem** pergunta o que diz:
+
+| Campo | Significado |
+|---|---|
+| **Mensagem** | O texto, no máximo 500 caracteres. Obrigatório. |
+| **Tipo** | A sua cor e o seu ícone: azul para Informação (o predefinido), âmbar para Aviso, vermelho para Perigo |
+
+**Quando** pergunta quando aparece:
+
+| Campo | Significado |
+|---|---|
+| **Data de início** | Aparece a partir deste momento. Deixe-a vazia para o mostrar de imediato. |
+| **Data de fim** | Neste momento é ocultado e eliminado. Deixe-a vazia para o manter até o eliminar. |
+
+A data de fim tem de ser posterior à data de início e estar no futuro.
diff --git a/i18n/pt/_configure/announcements/general.md b/i18n/pt/_configure/announcements/general.md
new file mode 100644
index 0000000..43930c1
--- /dev/null
+++ b/i18n/pt/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Geral
+parent: Anúncios
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# Geral
+{: .no_toc }
+
+O interruptor Ativado de cada anúncio, que substituiu o interruptor de todos eles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ativar ou desativar um anúncio
+
+A partir da 7.3.0, cada anúncio é ativado ou desativado individualmente, com o seu interruptor **Ativado**.
+
+Um anúncio novo fica ativado. **Desativar** no menu da sua linha, ou o interruptor **Ativado** na sua página, oculta-o sob o cabeçalho e mantém-no
+na lista, e **Ativar** volta a mostrá-lo desde a sua data de início até à sua data de fim. O interruptor é guardado de imediato.
+
+---
+
+## O interruptor Mostrar anúncios da 7.2
+
+Até à 7.2, um separador **Geral** tinha um interruptor **Mostrar anúncios** que os ativava ou desativava todos de uma vez.
+
+A partir da 7.3.0 esse interruptor deixou de existir. Se estava desligado, a atualização desativa todos os anúncios, para que nenhum comece a aparecer: volte a ativar os que pretender.
diff --git a/i18n/pt/_configure/announcements/list.md b/i18n/pt/_configure/announcements/list.md
new file mode 100644
index 0000000..1a7b888
--- /dev/null
+++ b/i18n/pt/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: Lista
+parent: Anúncios
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# Lista
+{: .no_toc }
+
+Os anúncios que ainda não terminaram, as suas colunas e a página de um anúncio
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A lista
+
+**Definições > Aparência > Anúncios** lista todos os anúncios que ainda não terminaram, com estas colunas:
+
+| Coluna | Significado |
+|---|---|
+| **Ativado** | Se aparece sob o cabeçalho desde o seu início até ao seu fim (a partir da 7.3.0) |
+| **Mensagem** | O texto sob o cabeçalho |
+| **Tipo** | Informação, Aviso ou Perigo |
+| **Data de início** | Quando começa a aparecer; `–` quando aparece de imediato |
+| **Data de fim** | Quando termina; `–` quando aparece até ser eliminado |
+| **Criado por** | Quem o adicionou |
+
+Um clique numa linha, ou **Editar** no menu da sua linha, abre a página do anúncio. O menu tem também **Ativar** ou **Desativar**, e **Eliminar**.
+
+Quando a sua data de fim passa, o anúncio é eliminado: a lista só guarda os que estão para vir e os que estão a aparecer.
+
+---
+
+## A página de um anúncio
+
+A partir da 7.3.0, cada anúncio abre na sua própria página, em `/settings/announcements/<id>`, com um separador, **Detalhes**.
+
+Contém a mensagem, o tipo, as datas de início e de fim e o interruptor **Ativado**, que é guardado de imediato; os outros campos são guardados
+com **Guardar**, e **Eliminar** remove o anúncio. O título da página identifica-o pelos primeiros caracteres da sua mensagem.
diff --git a/i18n/pt/_configure/appearance.md b/i18n/pt/_configure/appearance.md
new file mode 100644
index 0000000..4b994f6
--- /dev/null
+++ b/i18n/pt/_configure/appearance.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Aparência
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# Aparência
+{: .no_toc }
+
+As predefinições, o nome, o logótipo, o ícone do navegador, as ligações do cabeçalho e as etiquetas ao lado do logótipo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: dê à instância o aspeto da sua organização, em **Definições > Aparência**, com a opção de função `showSettings`.
+A opção de função `showAppearanceSettings` sozinha também abre estas páginas, anúncios incluídos, sem o resto das definições.
+
+As páginas deste grupo são **Predefinições**, **Nome**, **Logótipo**, **Ícone**, **Ligações**, **Etiquetas** e **Anúncios**;
+os anúncios têm uma página própria, [Anúncios](announcements.html). Uma predefinição, um nome, uma ligação ou uma etiqueta guardados
+aparecem de imediato em todos os navegadores abertos.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Predefinições](appearance/defaults.html) | O tema, o idioma, o fuso horário e o formato de data para os utilizadores que não escolheram nenhum |
+| [Nome](appearance/name.html) | O nome da aplicação no separador do navegador e na página de início de sessão |
+| [Logótipo](appearance/logo.html) | O seu próprio logótipo no cabeçalho |
+| [Ícone](appearance/icon.html) | O seu próprio ícone no separador do navegador e nos marcadores |
+| [Ligações](appearance/links.html) | As ligações do cabeçalho, as integradas e as suas |
+| [Etiquetas](appearance/labels.html) | Etiquetas ao lado do logótipo que dizem que instância é esta; uma única etiqueta Ambiente até à 7.2 |
diff --git a/i18n/pt/_configure/appearance/defaults.md b/i18n/pt/_configure/appearance/defaults.md
new file mode 100644
index 0000000..25f2c90
--- /dev/null
+++ b/i18n/pt/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Predefinições
+parent: Aparência
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# Predefinições
+{: .no_toc }
+
+O tema, o idioma, o fuso horário e o formato de data para os utilizadores que não escolheram nenhum
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## As predefinições
+
+**Predefinições** define o aspeto da aplicação para um utilizador que não fez uma escolha própria nas suas
+[preferências](../profile/preferences.html); a escolha do próprio utilizador prevalece sempre:
+
+| Campo | Opções | Sem escolha |
+|---|---|---|
+| **Tema predefinido** | Seguir o navegador, Claro, Escuro ou Cor, com uma de 12 cores para Cor | Seguir o navegador (Claro até à 7.2) |
+| **Idioma predefinido** | Os idiomas da aplicação, guardado em [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) | Inglês |
+| **Vista de formulários predefinida** | Mosaicos ou Lista, para a página de formulários | Mosaicos |
+| **Fuso horário predefinido** | UTC, o navegador de cada utilizador, ou qualquer fuso pelo nome | UTC |
+| **Formato de data predefinido** | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY`, mostrado com a data de hoje | `YYYY-MM-DD` |
+
+O idioma é uma variável de ambiente e aplica-se sem reiniciar. Com
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) a `0`, a página mostra-o só de leitura.
+
+A partir da 7.3.0, a página está organizada nos dois separadores das preferências do perfil, **Aparência** (tema, idioma e vista de formulários) e **Data e
+hora** (fuso horário e formato de data, com uma pré-visualização da hora atual), e a sua caixa de pesquisa lista as correspondências sob o nome de cada separador.
+
+---
+
+## Seguir o navegador
+
+A partir da 7.3.0, **Seguir o navegador** mostra a cada utilizador o tema claro ou escuro que o seu navegador pede, e muda com ele.
+
+É a predefinição quando não se escolhe nenhum tema predefinido, por isso uma instalação nova segue o navegador. Passar o ponteiro por uma das cores de
+**Cor** pré-visualiza a aplicação nessa cor; o tema que tinha volta quando o ponteiro sai, e nada é guardado até clicar em **Guardar**.
diff --git a/i18n/pt/_configure/appearance/icon.md b/i18n/pt/_configure/appearance/icon.md
new file mode 100644
index 0000000..0b81465
--- /dev/null
+++ b/i18n/pt/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: Ícone
+parent: Aparência
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# Ícone
+{: .no_toc }
+
+O seu próprio ícone no separador do navegador e nos marcadores
+{: .fs-6 .fw-300 }
+
+**Ícone** substitui o ícone do AnsibleForms no separador do navegador e nos marcadores:
+
+| Regra | Valor |
+|---|---|
+| Tipos | PNG, ICO, SVG, WEBP, GIF e JPEG |
+| Tamanho máximo do ficheiro | 256 KB |
+| Melhor resultado | Uma imagem quadrada de pelo menos 64 × 64 px, ou um SVG |
+
+Escolha um ficheiro em **Novo ícone** e clique em **Carregar**; **Remover o ícone personalizado** repõe o ícone predefinido.
diff --git a/i18n/pt/_configure/appearance/labels.md b/i18n/pt/_configure/appearance/labels.md
new file mode 100644
index 0000000..d43c67e
--- /dev/null
+++ b/i18n/pt/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: Etiquetas
+parent: Aparência
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# Etiquetas
+{: .no_toc }
+
+Etiquetas ao lado do logótipo que dizem que instância é esta
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A lista
+
+A partir da 7.3.0, **Definições > Aparência > Etiquetas** guarda várias etiquetas ao lado do logótipo do cabeçalho, como PRODUCTION e EU:
+
+| Coluna | Significado |
+|---|---|
+| **Ativado** | Se a etiqueta aparece ao lado do logótipo e na página de início de sessão |
+| **Etiqueta** | O seu texto, mostrado como a pílula colorida que o cabeçalho apresenta |
+
+As linhas estão pela ordem do cabeçalho. Um clique numa linha, ou **Editar** no menu da sua linha, abre a página da etiqueta; o menu da linha tem também
+**Ativar** ou **Desativar**, conforme o caso, **Mover para cima** e **Mover para baixo** para alterar a ordem, e **Eliminar**.
+
+O cabeçalho e a página de início de sessão mostram as etiquetas ativadas pela sua ordem. A partir de três, um **+N** cinzento guarda as restantes na sua dica,
+e um telemóvel mostra a primeira etiqueta e o **+N**. Uma etiqueta guardada aparece de imediato em todos os navegadores abertos.
+
+---
+
+## Adicionar uma etiqueta
+
+**Adicionar etiqueta** abre uma caixa de diálogo com os dois campos da etiqueta, ambos obrigatórios:
+
+| Campo | Significado |
+|---|---|
+| **Etiqueta** | O texto da etiqueta, como PRODUCTION |
+| **Cor** | Azul, verde, âmbar, laranja, vermelho ou cinzento, como amostras redondas; vermelho de início |
+
+Uma pré-visualização mostra o cabeçalho com todas as etiquetas ativadas e a nova à medida que é escrita. Uma etiqueta nova fica ativada e vem depois das
+outras. A sua página tem um separador, **Detalhes**, com os mesmos campos, o interruptor **Ativado**, que é guardado de imediato, e a pré-visualização.
+
+---
+
+## A etiqueta de ambiente da 7.2
+
+Até à 7.2, **Definições > Aparência > Ambiente** definia uma única etiqueta ao lado do logótipo.
+
+Com uma só etiqueta, PRODUCTION EU e PRODUCTION US ficavam ambas como PRODUCTION quando várias instâncias estavam abertas lado a lado. A partir da 7.3.0,
+a atualização faz dessa etiqueta a primeira da lista, com o seu texto, a sua cor e se aparecia ou não, e o antigo endereço **Ambiente**
+abre a lista.
+
+---
+
+## Etiquetas no config seed
+
+A partir da 7.3.0, o [config seed](../seed/) declara etiquetas na sua secção `labels`, cada uma com o seu texto e, opcionalmente, a sua cor:
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` é um de `blue`, `green`, `amber`, `orange`, `red` ou `grey`, e `position` ordena-as, a mais baixa primeiro. Uma etiqueta declarada
+no seed fica só de leitura na sua página, como qualquer [objeto gerido](../seed/managed-objects.html).
diff --git a/i18n/pt/_configure/appearance/links.md b/i18n/pt/_configure/appearance/links.md
new file mode 100644
index 0000000..0d015df
--- /dev/null
+++ b/i18n/pt/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Ligações
+parent: Aparência
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# Ligações
+{: .no_toc }
+
+As ligações do cabeçalho, as integradas e as suas
+{: .fs-6 .fw-300 }
+
+**Ligações** define as ligações do cabeçalho, para todos os utilizadores com sessão iniciada, em dois separadores.
+
+**Integradas** tem o interruptor **Designer**, guardado em [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) e aplicado
+sem reiniciar. Desligado, o designer desaparece para todos: a sua ligação, a sua página e a sua API.
+
+**Personalizadas** guarda as suas próprias ligações, como uma wiki, um runbook ou um portal de suporte. **Adicionar ligação** adiciona uma linha com estes campos:
+
+| Campo | Significado |
+|---|---|
+| **Ícone** | O ícone antes da etiqueta, escolhido de uma lista |
+| **Etiqueta** | O texto da ligação |
+| **Endereço** | Um site (`https://…`) ou uma página da aplicação (`/forms/all`) |
+| **Novo separador** | Abre a ligação num novo separador do navegador |
+
+Os botões de uma linha movem-na: **→** coloca a ligação dentro da ligação acima dela, que passa a abrir como um menu no cabeçalho,
+**←** volta a tirá-la para o cabeçalho, e as setas para cima e para baixo movem-na (um menu com as ligações que tem dentro).
+Um menu não precisa de endereço próprio.
+
+O cabeçalho comporta no máximo 5 das suas ligações depois das integradas, e no máximo 10 dentro de cada menu.
diff --git a/i18n/pt/_configure/appearance/logo.md b/i18n/pt/_configure/appearance/logo.md
new file mode 100644
index 0000000..ac6806f
--- /dev/null
+++ b/i18n/pt/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Logótipo
+parent: Aparência
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# Logótipo
+{: .no_toc }
+
+O seu próprio logótipo no cabeçalho
+{: .fs-6 .fw-300 }
+
+**Logótipo** substitui o logótipo do AnsibleForms no cabeçalho por uma imagem sua, mostrada em todos os temas:
+
+| Regra | Valor |
+|---|---|
+| Tipos | PNG, JPEG, WEBP, GIF e SVG |
+| Tamanho máximo do ficheiro | 900 KB |
+| Tamanho no cabeçalho | No máximo 200 × 33 px, mantendo as proporções |
+
+Escolha um ficheiro em **Novo logótipo** para o pré-visualizar e clique em **Carregar**. **Logótipo atual** mostra o logótipo em uso e o tamanho
+com que o cabeçalho o apresenta. **Remover logótipo personalizado** repõe o logótipo predefinido, que acompanha o tema.
diff --git a/i18n/pt/_configure/appearance/name.md b/i18n/pt/_configure/appearance/name.md
new file mode 100644
index 0000000..4ef5205
--- /dev/null
+++ b/i18n/pt/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: Nome
+parent: Aparência
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# Nome
+{: .no_toc }
+
+O nome da aplicação no separador do navegador e na página de início de sessão
+{: .fs-6 .fw-300 }
+
+**Nome** guarda o **Nome da aplicação**, mostrado no separador do navegador e na página de início de sessão. Vazio, o separador do navegador mostra
+`AnsibleForms` e a página de início de sessão não mostra nenhum nome.
diff --git a/i18n/pt/_configure/authentication/entra-id.md b/i18n/pt/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..54f5766
--- /dev/null
+++ b/i18n/pt/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: Autenticação
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+Início de sessão único com o Microsoft Entra ID (Azure AD), com funções a partir dos grupos do Entra ID do utilizador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Como funciona
+
+Com um fornecedor Entra ID ativado, a página de início de sessão mostra um botão Entra ID por baixo de **Iniciar sessão**. Um início de sessão decorre então assim:
+
+1. O botão envia o navegador para `/api/v2/auth/entraid`, que o redireciona para a Microsoft.
+2. O utilizador inicia sessão na Microsoft, que redireciona de volta para o **URL de redirecionamento** com um código de autorização. O servidor
+   troca esse código com a Microsoft pelo ID token e por um access token para o Microsoft Graph.
+3. O servidor lê os grupos do utilizador no Microsoft Graph (`/v1.0/me/transitiveMemberOf`), por isso os grupos aninhados também contam.
+4. Os grupos são filtrados com o **Filtro de grupos** pelo seu nome de apresentação, e cada grupo que fica é guardado duas vezes,
+   como `azuread/<object id>` e como `azuread/<display name>`.
+
+O nome de utilizador é a claim `upn` do token, ex. `jdoe@example.com`, ou a claim `preferred_username` quando o token
+não tem `upn`; numa conta profissional ambas contêm o mesmo valor.
+
+---
+
+## Registar a aplicação
+
+O AnsibleForms precisa de um registo de aplicação no Entra admin center, em **App registrations > New registration**:
+
+1. Dê-lhe um nome, escolha **Accounts in this organizational directory only** como tipos de conta suportados e adicione um
+   URI de redirecionamento do tipo **Web**: `https://af.example.com/api/v2/auth/entraid/callback`.
+2. Em **Certificates & secrets**, crie um client secret e copie o seu valor; só é mostrado uma vez.
+3. Em **API permissions**, adicione as permissões **delegated** do Microsoft Graph `User.Read` e `GroupMember.Read.All`,
+   e conceda-lhes o consentimento de administrador.
+4. Na página **Overview**, anote o **Application (client) ID** e o **Directory (tenant) ID**.
+
+O URI de redirecionamento é o endereço em que os utilizadores chegam ao AnsibleForms, seguido de `/api/v2/auth/entraid/callback`.
+Com [`BASE_URL`](../customization/server.html#env_BASE_URL) `/forms`, passa a ser
+`https://af.example.com/forms/api/v2/auth/entraid/callback`. Tem de corresponder exatamente ao **URI de redirecionamento** da
+credencial do fornecedor.
+
+Até à 7.2.0 o caminho era `/api/v2/auth/azureadoauth2/callback`. Continua a funcionar a partir da 7.3.0, por isso um registo existente
+não precisa de alterações; uma credencial com o **URI de redirecionamento** vazio usa o novo caminho, por isso adicione-o então ao registo.
+
+O AnsibleForms lê os grupos do Graph e não usa uma claim de grupos no token, por isso não é preciso configurar nenhuma claim de grupos
+no registo.
+
+---
+
+## Adicionar o fornecedor
+
+Adicione o fornecedor em **Acesso > SSO**: um assistente pede os seus campos em quatro passos, com **Microsoft Entra ID** no passo **Tipo**:
+
+| Passo | Campo | Significado |
+|---|---|---|
+| Detalhes | Nome, Descrição | Um nome único para o fornecedor, e uma descrição opcional |
+| Tipo | Fornecedor | **Microsoft Entra ID**; definido na criação, não muda |
+| Credenciais | Credencial | Uma credencial **Microsoft Entra ID** de [Ligações > Credenciais](../credentials.html), ver abaixo |
+| Grupos | Filtro de grupos | Expressão regular; só ficam os grupos cujo nome de apresentação corresponde. Vazio mantém todos os grupos |
+
+A credencial contém o registo da aplicação, por isso só um admin a pode adicionar ou alterar:
+
+| Campo | Significado |
+|---|---|
+| Tenant ID | Obrigatório. O Directory (tenant) ID, um GUID, ou um dos domínios do tenant. Só os utilizadores desse tenant podem iniciar sessão |
+| Client ID | O Application (client) ID |
+| Client secret | O valor do client secret, guardado cifrado ou lido de um [cofre de segredos](../secret-stores/) |
+| URI de redirecionamento | Tal como registado, ex. `https://af.example.com/api/v2/auth/entraid/callback`. Vazio: o URL da aplicação e o caminho de callback |
+
+Uma credencial com o tenant ID vazio é recusada ao ser guardada. Os endpoints multi-tenant `common`, `organizations`
+e `consumers` são recusados quando se guarda o fornecedor que nomeia a credencial, porque deixariam iniciar sessão utilizadores de qualquer
+tenant da Microsoft. No início de sessão, o servidor verifica também que o token vem do tenant configurado. Um fornecedor
+guardado anteriormente sem tenant ID não deixa ninguém iniciar sessão: até o tenant ID ser preenchido, o servidor regista
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`.
+
+Até à 7.2.0, o tenant, o client ID, o secret e o URL de redirecionamento eram campos do fornecedor. A atualização para a 7.3.0 move-os para uma
+credencial chamada `<provider>-sso`, consulte [Endereços nas credenciais](../credentials/types.html#addresses-in-credentials).
+Escolha uma credencial para cada fornecedor novo: o servidor continua a aceitar um fornecedor com o seu próprio client ID e secret de
+antes da 7.3.0, que inicia sessão com eles até ser escolhida uma credencial.
+
+Só um fornecedor Entra ID está ativado de cada vez, aquele com que o botão Entra ID inicia sessão. **Ativar** no menu da linha de outro,
+ou o seu interruptor **Ativado**, desativa os outros do mesmo tipo; a coluna **Ativado** da lista mostra qual está em uso. Um fornecedor
+pode também saltar a página de início de sessão, consulte [Alternar o início de sessão único](./#switching-single-sign-on). Guardar aplica-o de imediato, sem reiniciar.
+
+---
+
+## Mapeamento para funções
+
+No config.yaml, um grupo do Entra ID é `entraid/<object id>` ou `entraid/<display name>`, e um utilizador é `entraid/<upn>`.
+O object id é único no tenant, por isso é a escolha mais segura; um nome de apresentação é mais fácil de ler:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+Até à 7.2.0 o prefixo era `azuread/`. Numa função continua a corresponder aos mesmos membros a partir da 7.3.0 e será removido na 8.0; o
+editor de funções escreve `entraid/`. Só as funções aceitam `entraid/`: os grupos do utilizador são guardados como `azuread/<object id>` e
+`azuread/<display name>`, e a página de perfil e o extravar `ansibleforms_user` mostram-nos assim. Um **Filtro de grupos** como `^AF-` mantém só os grupos que as suas funções usam; consulte [Funções](../config/roles.html). A partir da 7.1.0
+o token de início de sessão deixou de transportar os grupos, por isso o seu tamanho já não cresce com eles. O filtro continua a ser importante para
+utilizadores em muitos grupos: em cada início de sessão são comparados menos grupos com as funções, e o
+[registo de diretório](../users-and-groups/directory.html) do utilizador lista só os grupos que contam. Antes da 7.1.0,
+um utilizador em cem grupos ou mais precisa dele para ver qualquer formulário, consulte
+[Formulários e tarefas vazios depois de um início de sessão único](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+
+---
+
+## Endpoint do Microsoft Graph
+
+O servidor inicia a sessão dos utilizadores em `https://login.microsoftonline.com` e chama o Microsoft Graph em `https://graph.microsoft.com` por predefinição:
+
+| Variável | O que altera |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | A autoridade de início de sessão, para uma cloud nacional como `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | O endpoint do Graph de onde são lidos os grupos, como `https://graph.microsoft.us` |
+
+Ambas recebem um URI base sem barra final, e são novas na 7.3.0. `AZURE_AUTHORITY_URI` e `AZURE_GRAPH_URI` continuam a ser lidas
+quando aquelas não estão definidas, com um aviso no registo, e serão removidas na 8.0. O servidor tem de chegar ao Graph: um início de sessão falha quando os grupos não podem ser lidos.
+
+---
+
+## Limitações
+
+Os utilizadores do Entra ID iniciam sessão com a Microsoft, por isso algumas coisas funcionam de forma diferente das contas locais e LDAP:
+
+- Não têm palavra-passe no AnsibleForms, por isso não a podem alterar lá; um [token de API](../profile/api-token.html) é criado a partir da sua sessão.
+- Os nomes de apresentação não são únicos no Entra ID: dois grupos com o mesmo nome correspondem à mesma função. Nomeie o grupo pelo seu
+  object id na função, `entraid/<object id>`, para corresponder só a esse grupo.
diff --git a/i18n/pt/_configure/authentication/index.md b/i18n/pt/_configure/authentication/index.md
new file mode 100644
index 0000000..28ba57a
--- /dev/null
+++ b/i18n/pt/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Autenticação
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# Autenticação
+{: .no_toc }
+
+Escolha como os utilizadores iniciam sessão, e como a sua conta e os seus grupos levam a funções
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Métodos de início de sessão
+
+O AnsibleForms suporta quatro métodos de início de sessão, e vários podem estar ativos ao mesmo tempo:
+
+| Método | Quando usar | Página |
+|---|---|---|
+| Contas locais | O admin integrado, contas de serviço, equipas pequenas, ou uma alternativa quando o diretório está em baixo. | [Contas locais](local.html) |
+| LDAP | Os utilizadores e grupos vivem no Active Directory, no OpenLDAP ou noutro diretório LDAP. | [LDAP](ldap.html) |
+| Entra ID | Os utilizadores iniciam sessão com a sua conta Microsoft 365 / Entra ID (início de sessão único). | [Entra ID](entra-id.html) |
+| OIDC | Início de sessão único através de outro fornecedor OpenID Connect, como o Keycloak. | [OIDC](oidc.html) |
+
+As contas locais e o LDAP configuram-se em **Acesso > Utilizadores**, **Grupos** e **LDAP**; o Entra ID e o OIDC em
+**Acesso > SSO**.
+
+---
+
+## Como um início de sessão escolhe o método
+
+A página de início de sessão tem um formulário de nome de utilizador e palavra-passe, mais um botão por cada fornecedor de início de sessão único ativado:
+
+- **O nome de utilizador e a palavra-passe** são verificados primeiro contra os utilizadores locais. Só quando nenhum utilizador local tem esse nome, e o LDAP
+  está ativado, se tenta o diretório. Um utilizador local com uma palavra-passe errada é recusado sem consultar o LDAP.
+- **Os botões Entra ID e OpenID** aparecem por baixo de **Iniciar sessão** quando um fornecedor desse tipo está ativado. Enviam o navegador para
+  o fornecedor e de volta; nenhuma palavra-passe chega ao AnsibleForms.
+
+Só um fornecedor Entra ID e um fornecedor OIDC estão ativados de cada vez: ativar um desativa os outros do mesmo tipo.
+Um início de sessão falhado com nome de utilizador e palavra-passe mostra sempre a mesma mensagem genérica; o motivo está no registo do servidor e no registo de auditoria.
+
+---
+
+## Alternar o início de sessão único
+
+A partir da 7.3.0, cada fornecedor em **Acesso > SSO** tem dois interruptores próprios, que se aplicam sem reiniciar:
+
+| Interruptor | Efeito |
+|---|---|
+| **Ativado** | Mostra o botão do fornecedor na página de início de sessão e aceita o seu início de sessão. Ligá-lo desliga os outros fornecedores do mesmo tipo. |
+| **Saltar a página de início de sessão** | Os utilizadores vão diretamente para este fornecedor, sem a página de início de sessão, enquanto o fornecedor estiver ativado. Ligá-lo num fornecedor desliga-o nos outros; fica a cinzento num fornecedor desativado. |
+
+O formulário de nome de utilizador e palavra-passe continua acessível em `/login?local`, para o admin local ou quando o fornecedor falha,
+e é mostrado depois de terminar sessão e quando um início de sessão único volta com um erro.
+
+As variáveis `ENABLE_SSO` e `SSO_AUTO_LOGIN` foram removidas na 7.3.0. O primeiro arranque da 7.3.0 lê-as uma vez, e
+regista um aviso em cada arranque enquanto continuarem definidas, por isso remova-as do ambiente depois da atualização:
+
+| Variável antes da 7.3.0 | O que faz a atualização |
+|---|---|
+| `ENABLE_SSO=0` | Desativa todos os fornecedores: os fornecedores continuam configurados, sem botão na página de início de sessão |
+| `SSO_AUTO_LOGIN=1` | Liga **Saltar a página de início de sessão** no fornecedor ativado, quando há exatamente um ativado e `ENABLE_SSO` não é `0` |
+
+---
+
+## Do utilizador às funções
+
+Cada início de sessão produz um utilizador com um **tipo** (`local`, `ldap`, `azuread` ou `oidc`), um nome de utilizador e uma lista de grupos.
+Cada grupo recebe o prefixo do seu tipo, por isso um grupo do Entra ID é guardado e mostrado como `azuread/...`:
+
+| Método de início de sessão | Nome de utilizador | Grupos |
+|---|---|---|
+| Local | o nome de utilizador local | `local/<group>`, um por cada grupo local do utilizador |
+| LDAP, diretório `main` | o valor do Atributo do nome de utilizador | `ldap/<cn>`, o CN de cada grupo que o diretório devolve |
+| LDAP, outro diretório | `<directory>/<username>` | `ldap/<directory>/<cn>`, consulte [Vários diretórios](ldap.html#several-directories) |
+| Entra ID | a claim `upn`, ou `preferred_username` quando o token não tem `upn` | `azuread/<object id>` e `azuread/<display name>` de cada grupo, lidos do Microsoft Graph |
+| OIDC | a claim `preferred_username` | `oidc/<name>`, da claim `groups` do ID token |
+
+As [funções](../config/roles.html) no config.yaml correspondem depois a estes valores: uma função aplica-se quando um dos seus `groups` é um
+dos grupos do utilizador, ou quando os seus `users` contêm `<type>/<username>`. Todos os utilizadores recebem também a função `default`. A partir da 7.3.0, uma
+função nomeia um membro do Entra ID como `entraid/<group>` ou `entraid/<upn>`, que corresponde ao valor `azuread/` guardado; `azuread/`
+numa função continua a funcionar e será removido na 8.0. O perfil e os extravars da tarefa continuam a mostrar `azuread/`.
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+A página de **perfil** de um utilizador lista o tipo de início de sessão, os grupos e as funções, que é a forma mais rápida de verificar um mapeamento.
+A opção de função `allowLogin` pode recusar o início de sessão de utilizadores que não correspondem a nenhuma função: defina-a como `false` em `default` e como
+`true` nas funções que podem iniciar sessão.
diff --git a/i18n/pt/_configure/authentication/ldap.md b/i18n/pt/_configure/authentication/ldap.md
new file mode 100644
index 0000000..82d2e53
--- /dev/null
+++ b/i18n/pt/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: Autenticação
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+Deixe os utilizadores do diretório iniciar sessão com a sua própria palavra-passe, e dê-lhes funções através dos seus grupos do diretório
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Como funciona
+
+O AnsibleForms liga-se ao diretório com uma conta de bind, procura o utilizador e depois faz bind como esse utilizador para verificar
+a palavra-passe:
+
+1. O utilizador inicia sessão com nome de utilizador e palavra-passe. Quando nenhum utilizador **local** tem esse nome, tenta-se o LDAP.
+2. O AnsibleForms faz bind com a conta de bind da credencial do diretório, e procura em **Base de pesquisa** uma entrada cujo
+   **Atributo do nome de utilizador** seja igual ao nome de utilizador.
+3. Faz bind como a entrada encontrada, com a palavra-passe que foi escrita.
+4. Os grupos são lidos da entrada (ou de uma pesquisa de grupos), filtrados e prefixados com `ldap/`.
+
+Um nome de utilizador em formato UPN (`jdoe@example.com`) que não encontra nenhum utilizador é tentado de novo uma vez com a parte antes do `@`, para que os utilizadores
+possam iniciar sessão com qualquer das formas, mesmo quando o Atributo do nome de utilizador contém o nome curto. Uma palavra-passe errada nunca é tentada de novo.
+
+Um único conjunto de definições serve o Active Directory, o OpenLDAP e outros; a partir da 7.3.0 pode haver [vários diretórios](#several-directories).
+
+---
+
+## Definições
+
+A partir da 7.3.0, as definições são por diretório. **Acesso > LDAP** lista os diretórios, pela ordem em que um nome de utilizador simples é procurado:
+
+![Acesso > LDAP](../assets/screenshots/ldap.jpg)
+
+| Menu da linha | O que faz |
+|---|---|
+| Editar | Abre a página do diretório |
+| Testar ligação | Tenta um início de sessão com um nome de utilizador e uma palavra-passe de teste, consulte [Testar a ligação](#testing-the-connection) |
+| Ativar, Desativar | Liga ou desliga o diretório; `main` é desativado em vez de eliminado |
+| Mover para cima, Mover para baixo | Altera a sua posição na ordem de procura |
+| Eliminar | Remove o diretório; aparece mas fica desativado em `main` |
+
+Adicionar um diretório pede os seus campos em quatro passos, os separadores da sua página. **Detalhes** contém **Ativado**, o **Nome** e uma **Descrição**:
+
+| Separador | Definição | Significado |
+|---|---|---|
+| Credenciais | Credencial | Obrigatória. Uma credencial `ldap` de [Ligações > Credenciais](../credentials.html), que contém a ligação, ver abaixo |
+| Utilizadores | Base de pesquisa | DN onde começa a pesquisa de utilizadores, ex. `OU=Users,DC=example,DC=com`. As subárvores também são pesquisadas |
+| Utilizadores | Atributo do nome de utilizador | Atributo comparado com o nome de início de sessão: `sAMAccountName` no AD (a predefinição), `uid` no OpenLDAP |
+| Utilizadores | Atributo de email | Atributo que contém o endereço de email, normalmente `mail` |
+| Utilizadores | Domínios de início de sessão | Domínios cujos inícios de sessão `user@domain` vão diretamente para este diretório, consulte [Vários diretórios](#several-directories) |
+| Grupos | Atributo de grupos | Atributo da entrada do utilizador que contém os grupos (`memberOf`, a predefinição), ou `groups` com uma pesquisa de grupos |
+| Grupos | Base de pesquisa de grupos | DN onde começa a pesquisa de grupos |
+| Grupos | Classe de grupo | objectClass dos grupos, ex. `group`, `groupOfNames` ou `posixGroup` |
+| Grupos | Atributo de membro do grupo | Atributo de um grupo que lista os seus membros, ex. `member`, `uniqueMember` ou `memberUid`; predefinição `member` |
+| Grupos | Atributo de Utilizador do Membro do Grupo | Atributo do utilizador que esses valores de membro contêm, ex. `dn` ou `uid`; predefinição `dn` |
+| Grupos | Filtro de grupos | Expressão regular; só ficam os grupos cujo nome corresponde. Vazio mantém todos os grupos |
+
+As predefinições dos três últimos campos de grupos só se aplicam quando se usa a pesquisa de grupos, consulte a secção seguinte.
+
+A credencial `ldap` contém como se chega ao diretório e com que conta se pesquisa:
+
+| Campo | Significado |
+|---|---|
+| Servidores | Um por campo, como `host`, `host:port` ou `ldaps://host:port`, tentados por esta ordem: quando um não está acessível, tenta-se o seguinte |
+| Porta | `389` para LDAP simples, `636` para LDAPS |
+| Ativar TLS | Ligar com LDAPS (`ldaps://`). O StartTLS na porta 389 não é suportado |
+| Ignorar certificados | Ignorar a validação do certificado do servidor. Só aparece com **Ativar TLS** |
+| Certificado | O certificado de cliente que o AnsibleForms apresenta aos servidores, em PEM, quando os certificados são verificados |
+| CA bundle | O ou os certificados de CA que assinaram o certificado do servidor, em PEM, quando os certificados são verificados |
+| DN do utilizador de bind | O DN da conta de serviço que pesquisa o diretório |
+| Palavra-passe do utilizador de bind | A sua palavra-passe, guardada cifrada ou lida de um [cofre de segredos](../secret-stores/) |
+
+Só um admin pode adicionar ou alterar uma credencial `ldap`, consulte [Quem pode alterar uma credencial](../credentials.html#who-may-change-a-credential).
+Até à 7.2.0, os servidores, o TLS e a conta de bind eram campos das definições LDAP. A atualização para a 7.3.0 move-os para uma credencial,
+consulte [Endereços nas credenciais](../credentials/types.html#addresses-in-credentials):
+
+| O diretório antes da atualização | Para onde vão os seus servidores |
+|---|---|
+| O seu próprio DN e palavra-passe de bind, sem credencial | Uma nova credencial `ldap` chamada `<directory>-ldap`, como `main-ldap` |
+| Uma credencial sem servidores | Para essa credencial |
+| Uma credencial que já contém outros servidores | Uma cópia da credencial chamada `<credential>-<directory>`, que o diretório passa a nomear |
+
+Um nome já ocupado recebe `-2`, `-3` e assim sucessivamente. Um diretório do config seed fica como está: o seed é o seu dono.
+
+---
+
+## Grupos
+
+Os grupos vêm de um de dois sítios, e o **Atributo de grupos** decide qual se usa:
+
+- **Um atributo da entrada do utilizador**, normalmente `memberOf`. É a configuração habitual no Active Directory, e no
+  OpenLDAP com o overlay `memberof`.
+- **Uma pesquisa de grupos**, para diretórios sem `memberOf`. Só corre quando **Base de pesquisa de grupos** e **Classe de grupo**
+  estão ambos definidos: o AnsibleForms procura então grupos dessa classe cujo **Atributo de membro do grupo** contém o
+  **Atributo de Utilizador do Membro do Grupo** do utilizador, e guarda o resultado no atributo `groups`. Defina **Atributo de grupos** como `groups`
+  para a usar.
+
+{: .note }
+> Com **Atributo de grupos** `memberOf`, uma pesquisa de grupos configurada corre, mas o seu resultado não é usado para as funções.
+
+Cada grupo é um DN, e o AnsibleForms fica com o seu primeiro CN: `CN=AF-Admins,OU=Groups,DC=example,DC=com` passa a `AF-Admins`.
+O **Filtro de grupos** aplica-se depois a esse nome, e os grupos que restam recebem o prefixo `ldap/`: `ldap/AF-Admins`.
+
+Em diretórios grandes, o filtro mantém pequenos os tokens e as tarefas; uma expressão regular inválida mantém todos os grupos e fica registada.
+
+---
+
+## Mapeamento para funções
+
+No config.yaml, um grupo LDAP é `ldap/<group CN>` e um utilizador LDAP é `ldap/<username>`, ambos sensíveis a maiúsculas e minúsculas:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+O nome de utilizador é o valor do **Atributo do nome de utilizador** tal como o diretório o devolve, não como o utilizador o escreveu.
+Consulte [Funções](../config/roles.html) para as opções de função.
+
+---
+
+## Vários diretórios
+
+A partir da 7.3.0 pode haver vários diretórios, cada um com os seus servidores, utilizadores e grupos. Os seus nomes distinguem os seus membros:
+
+| Diretório | Nome de utilizador | Grupos | Numa função |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`, `ldap/AF-Admins` |
+| Qualquer outro, como `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`, `ldap/corp/AF-Admins` |
+
+Um utilizador nomeia o diretório ao iniciar sessão como `corp\jdoe` ou `corp/jdoe`, ou inicia sessão com um endereço de um domínio que o diretório
+detém. Um nome de utilizador simples é tentado em todos os diretórios ativados, pela sua ordem, tal como um nome como `other\jdoe` quando nenhum
+diretório se chama `other`: nesse caso é procurado tal como foi escrito.
+
+O primeiro diretório que conhece o utilizador decide: uma palavra-passe errada aí é a resposta, e o diretório seguinte não é
+tentado, já que pode conter outra pessoa com esse nome. Um diretório que não está acessível é ignorado.
+
+O diretório chamado `default` até à 7.2.0 chama-se `main` a partir da 7.3.0: a atualização renomeia-o, e uma instalação nova começa
+com `main`. Os seus membros mantêm os nomes curtos, por isso as funções que os nomeiam não precisam de alterações. O diretório `main` não pode ser
+renomeado, e um nome de diretório só contém letras, dígitos, `-` e `_`.
+
+---
+
+## Testar a ligação
+
+**Testar ligação** pede um nome de utilizador e uma palavra-passe de teste, e tenta um início de sessão com as definições que estão no ecrã, guardadas ou não.
+Se correr bem, mostra a entrada do utilizador no diretório, que indica os nomes exatos dos atributos e os DN dos grupos a usar.
+
+Um utilizador de teste que não existe também dá sucesso: a ligação e a conta de bind funcionam, só o utilizador não é
+encontrado. Erros típicos:
+
+| Mensagem | Causa |
+|---|---|
+| `Bad server or port (connection failed)` | O nome do host não resolve ou a porta não está acessível. |
+| `Wrong binding credentials` | O DN ou a palavra-passe de bind da credencial do diretório estão errados. |
+| `Unable to verify the certificate` | O certificado do servidor não está assinado pelo CA bundle da credencial. |
+| `Certificate is not valid` | O Certificado ou o CA bundle da credencial não contêm um certificado PEM válido. |
+
+---
+
+## Exemplo de Active Directory
+
+Este exemplo liga-se a dois controladores de domínio por LDAPS e mantém só os grupos cujo nome começa por `AF-`:
+
+| Definição | Valor |
+|---|---|
+| Credencial > Servidores | `dc01.example.com`, depois `dc02.example.com` |
+| Credencial > Porta | `636` |
+| Credencial > Ativar TLS | ligado |
+| Credencial > Ignorar certificados | desligado, com um certificado de cliente e a cadeia de CA da CA empresarial |
+| Credencial > DN do utilizador de bind | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| Base de pesquisa | `OU=Users,DC=example,DC=com` |
+| Atributo de email | `mail` |
+| Atributo do nome de utilizador | `sAMAccountName` |
+| Atributo de grupos | `memberOf` |
+| Filtro de grupos | `^AF-` |
+
+Os membros de `CN=AF-Operators,…` correspondem a funções com `ldap/AF-Operators`, e iniciam sessão como `jdoe` ou `jdoe@example.com`.
+
+---
+
+## Exemplo de OpenLDAP
+
+Este exemplo usa uma pesquisa de grupos em entradas `groupOfNames`, por isso funciona sem o overlay `memberof`:
+
+| Definição | Valor |
+|---|---|
+| Credencial > Servidores | `ldap.example.com` |
+| Credencial > Porta | `636` |
+| Credencial > Ativar TLS | ligado |
+| Credencial > DN do utilizador de bind | `cn=readonly,dc=example,dc=com` |
+| Base de pesquisa | `ou=people,dc=example,dc=com` |
+| Atributo de email | `mail` |
+| Atributo do nome de utilizador | `uid` |
+| Atributo de grupos | `groups` |
+| Base de pesquisa de grupos | `ou=groups,dc=example,dc=com` |
+| Classe de grupo | `groupOfNames` |
+| Atributo de membro do grupo | `member` |
+| Atributo de Utilizador do Membro do Grupo | `dn` |
+
+Um utilizador listado em `cn=af-admins,ou=groups,dc=example,dc=com` recebe o grupo `ldap/af-admins`. Para grupos `posixGroup`,
+use **Atributo de membro do grupo** `memberUid` e **Atributo de Utilizador do Membro do Grupo** `uid`.
+
+Com o overlay `memberof`, deixe vazios os campos da pesquisa de grupos e defina **Atributo de grupos** como `memberOf`.
+
+---
+
+## Problemas comuns
+
+A maior parte dos problemas de LDAP reduz-se a um destes:
+
+- **Um utilizador local com o mesmo nome.** Os utilizadores locais são verificados primeiro, por isso o diretório nunca é consultado para esse nome.
+- **Sem grupos, ou com os errados.** O Atributo de grupos tem de existir (`groups` com uma pesquisa de grupos); `memberOf` ignora o aninhamento.
+- **Nomes de grupo que não correspondem.** Use `ldap/<CN>` com as mesmas maiúsculas e minúsculas, e verifique se o Filtro de grupos mantém o grupo.
+- **DN de grupos que não começam por um CN.** Só o primeiro valor `CN=` é usado como nome do grupo, por isso todos os DN de grupo
+  têm de começar por `CN=` (ou `cn=`).
+- **Certificados.** O TLS precisa dos dois campos de certificado da credencial e de um nome de servidor que corresponda; Ignorar certificados é só para testes.
+- **Definições que não podem ser guardadas.** Quando um diretório vem do [config seed](../seed/managed-objects.html), a sua página
+  é só de leitura: altere antes o ficheiro de seed.
+
+Um início de sessão falhado mostra uma mensagem genérica. O motivo é registado pelo servidor e guardado no registo de auditoria, e no Active
+Directory é traduzido a partir do código do diretório, ex. `Wrong password`, `Account locked` ou `Password expired`.
diff --git a/i18n/pt/_configure/authentication/local.md b/i18n/pt/_configure/authentication/local.md
new file mode 100644
index 0000000..1acdd20
--- /dev/null
+++ b/i18n/pt/_configure/authentication/local.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: Contas locais
+parent: Autenticação
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# Contas locais
+{: .no_toc }
+
+O admin integrado, e os utilizadores e grupos guardados na base de dados do AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O admin integrado
+
+Cada arranque cria o grupo local `admins` e o utilizador admin se não existirem; três variáveis controlam o admin:
+
+| Variável | Predefinição | Significado |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | Nome de utilizador do admin, criado no grupo `admins` quando nenhum utilizador tem esse nome. |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | Palavra-passe dada ao admin quando é criado (ou reposto). |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | `1` repõe a palavra-passe do admin para `ADMIN_PASSWORD` e volta a colocá-lo em `admins`. |
+
+`ADMIN_PASSWORD` só é usada quando o utilizador é criado ou reposto: alterá-la mais tarde não faz nada por si só.
+
+Um utilizador local que inicia sessão com a palavra-passe predefinida pública `AnsibleForms!123` só pode alterá-la. O navegador abre uma
+página de alteração de palavra-passe que não pode ser fechada, e o servidor responde a qualquer outro pedido com `403` (código
+`password_change_required`) até a palavra-passe ser alterada. A nova palavra-passe tem de ser diferente da predefinida; depois da
+alteração, o utilizador inicia sessão de novo com ela. Defina `ADMIN_PASSWORD` com o seu próprio valor antes do primeiro arranque para saltar este passo.
+
+Alterar `ADMIN_USERNAME` depois do primeiro arranque cria um segundo utilizador admin com esse nome; o antigo é mantido.
+
+{: .warning }
+> `REINIT_ADMIN=1` repõe a palavra-passe em **cada** arranque enquanto estiver definida. Use-a para recuperar uma palavra-passe de admin perdida,
+> depois remova-a e reinicie.
+
+---
+
+## Utilizadores e grupos
+
+Os utilizadores e grupos locais gerem-se em **Acesso > Utilizadores** e **Acesso > Grupos**. Um utilizador tem estes campos:
+
+| Campo | Significado |
+|---|---|
+| Nome de utilizador | O nome de início de sessão. Tem de ser único. |
+| Descrição | Opcional. |
+| Palavra-passe | Guardada como hash. Altere-a mais tarde com a ação **Alterar palavra-passe**. |
+| Email | Opcional. |
+| Grupo | O primeiro grupo local do utilizador. Adicione mais no separador **Grupos** da página do utilizador. |
+
+Os utilizadores locais alteram a sua própria palavra-passe no seu perfil; os outros utilizadores fazem-no no seu diretório ou fornecedor de identidade.
+
+Um utilizador pode pertencer a vários grupos, e recebe as funções de todos eles. O separador **Grupos** da página de um utilizador adiciona e
+remove grupos, tal como o separador **Utilizadores** da página de um grupo. Um utilizador mantém pelo menos um grupo: o último não pode
+ser removido.
+
+Um grupo que ainda tem utilizadores não pode ser eliminado: remova primeiro os seus utilizadores. O grupo `admins` nunca pode ser eliminado nem
+renomeado, e o utilizador `admin` nunca pode ser eliminado.
+
+---
+
+## Permitir o início de sessão
+
+O separador **Detalhes** da página de um utilizador tem um interruptor **Permitir início de sessão**, também disponível como **Bloquear início de sessão** e **Permitir
+início de sessão** no menu de linha da lista de utilizadores. Existe tanto para os utilizadores locais como para os utilizadores LDAP e SSO:
+
+- **Ligado**: o utilizador inicia sessão normalmente.
+- **Desligado**: as sessões do utilizador terminam de imediato e todos os inícios de sessão são recusados, até um admin voltar a ligá-lo. A página
+  pede confirmação antes.
+
+O interruptor não pode ser desligado para o utilizador `admin`, a forma de voltar a entrar, nem por um admin para a sua própria conta. A página de
+um utilizador LDAP ou SSO tem também **Terminar sessões**, que termina a sessão do utilizador em todo o lado sem o bloquear.
+
+---
+
+## Mapeamento para funções
+
+As funções nomeiam os grupos locais como `local/<group>` e os utilizadores como `local/<user>`; por predefinição, `admins` recebe `admin`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+Mantenha `local/admins` na função `admin`, para que o admin integrado possa sempre iniciar sessão, mesmo quando o diretório ou o
+fornecedor de identidade não estão disponíveis. Quando o config.yaml não pode ser carregado de todo, os membros de `local/admins` continuam a receber a
+função `admin`, para que possa iniciar sessão e corrigi-lo. Consulte [Funções](../config/roles.html) para as opções de função.
+
+---
+
+## Contas locais e LDAP
+
+Um início de sessão com nome de utilizador e palavra-passe verifica os utilizadores locais antes do LDAP. Quando um utilizador local tem o mesmo nome que um utilizador
+do diretório, a conta local ganha sempre e a palavra-passe do diretório não funciona para esse nome. Dê às contas locais nomes
+que não possam coincidir com contas do diretório, por exemplo com um prefixo `svc-`.
diff --git a/i18n/pt/_configure/authentication/oidc.md b/i18n/pt/_configure/authentication/oidc.md
new file mode 100644
index 0000000..dc4f333
--- /dev/null
+++ b/i18n/pt/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: Autenticação
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+Início de sessão único com um fornecedor OpenID Connect como o Keycloak, com funções a partir de uma claim de grupos
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Como funciona
+
+Com um fornecedor OIDC ativado, a página de início de sessão mostra um botão OpenID por baixo de **Iniciar sessão**. Um início de sessão decorre então assim:
+
+1. O botão envia o navegador para `/api/v2/auth/oidc`, que o redireciona para o fornecedor (fluxo de código de autorização
+   com PKCE).
+2. O utilizador inicia sessão no fornecedor, que redireciona de volta para o **URL de redirecionamento**.
+3. O servidor troca o código por tokens e lê as claims do ID token.
+4. O nome de utilizador é a claim `preferred_username`, e cada valor da claim `groups` que passa o
+   **Filtro de grupos** torna-se um grupo `oidc/<value>`.
+
+O AnsibleForms pede os âmbitos `openid profile email`; os âmbitos não são configuráveis. Terminar sessão no AnsibleForms
+envia também o navegador para o endpoint de fim de sessão do fornecedor, quando o fornecedor publica um.
+
+{: .note }
+> O OIDC foi testado com o Keycloak. Outros fornecedores funcionam quando cumprem os requisitos abaixo.
+
+---
+
+## Requisitos do fornecedor
+
+O fornecedor tem de oferecer OpenID Connect discovery, e um cliente confidencial para o AnsibleForms:
+
+- **Discovery**: o AnsibleForms lê `<issuer>/.well-known/openid-configuration`, por isso o emissor tem de estar acessível a partir
+  do servidor do AnsibleForms, por HTTPS.
+- **Um cliente confidencial** com o fluxo de código de autorização, um client ID e um client secret.
+- **O URI de redirecionamento** `https://af.example.com/api/v2/auth/oidc/callback`, ou seja, o endereço em que os utilizadores chegam ao
+  AnsibleForms seguido de `/api/v2/auth/oidc/callback`. Com [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  `/forms`, passa a ser `https://af.example.com/forms/api/v2/auth/oidc/callback`.
+- **Uma claim `groups` no ID token**, com uma lista de nomes de grupos. Sem ela, o utilizador não recebe grupos OIDC.
+- **Uma claim `preferred_username`**, que se torna o nome de utilizador.
+
+---
+
+## Exemplo com Keycloak
+
+Este exemplo usa um realm `example` em `https://keycloak.example.com`; o emissor é então
+`https://keycloak.example.com/realms/example`. Nesse realm:
+
+1. Em **Clients**, crie um cliente OpenID Connect com o client ID `ansibleforms`. Ligue **Client authentication**,
+   mantenha **Standard flow**, e defina **Valid redirect URIs** como `https://af.example.com/api/v2/auth/oidc/callback`.
+2. No separador **Credentials** do cliente, copie o **Client secret**.
+3. No separador **Client scopes**, abra `ansibleforms-dedicated` e adicione um mapper **By configuration > Group Membership**,
+   com **Token Claim Name** `groups`, **Full group path** desligado e **Add to ID token** ligado.
+
+Com **Full group path** ligado, a claim contém caminhos como `/af-admins`, e a função tem então de usar `oidc//af-admins`.
+
+---
+
+## Adicionar o fornecedor
+
+Adicione o fornecedor em **Acesso > SSO**: um assistente pede os seus campos em quatro passos, com **Open ID** no passo **Tipo**:
+
+| Passo | Campo | Significado |
+|---|---|---|
+| Detalhes | Nome, Descrição | Um nome único para o fornecedor, e uma descrição opcional |
+| Tipo | Fornecedor | **Open ID**; definido na criação, não muda |
+| Credenciais | Credencial | Uma credencial **Open ID** de [Ligações > Credenciais](../credentials.html), ver abaixo |
+| Grupos | Filtro de grupos | Expressão regular; só ficam os valores da claim `groups` que correspondem. Vazio mantém todos os grupos |
+
+A credencial contém o cliente, por isso só um admin a pode adicionar ou alterar:
+
+| Campo | Significado |
+|---|---|
+| Emissor | Obrigatório. O URL do emissor, ex. `https://keycloak.example.com/realms/example` |
+| Client ID | O client ID no fornecedor, ex. `ansibleforms` |
+| Client secret | O client secret, guardado cifrado ou lido de um [cofre de segredos](../secret-stores/) |
+| URI de redirecionamento | Tal como registado, ex. `https://af.example.com/api/v2/auth/oidc/callback`. Vazio: o URL da aplicação e o caminho de callback |
+
+Até à 7.2.0, o emissor, o client ID, o secret e o URL de redirecionamento eram campos do fornecedor. A atualização para a 7.3.0 move-os para uma
+credencial chamada `<provider>-sso`, consulte [Endereços nas credenciais](../credentials/types.html#addresses-in-credentials).
+Escolha uma credencial para cada fornecedor novo: o servidor continua a aceitar um fornecedor com o seu próprio client ID e secret de
+antes da 7.3.0, que inicia sessão com eles até ser escolhida uma credencial.
+
+Só um fornecedor OIDC está ativado de cada vez, aquele com que o botão OpenID inicia sessão. **Ativar** no menu da linha de outro,
+ou o seu interruptor **Ativado**, desativa os outros do mesmo tipo; a coluna **Ativado** da lista mostra qual está em uso.
+Um fornecedor pode também saltar a página de início de sessão, consulte [Alternar o início de sessão único](./#switching-single-sign-on).
+
+Guardar o fornecedor aplica-o de imediato. Quando o emissor não está acessível, o servidor regista
+`Failed to initialize OIDC strategy` e os inícios de sessão OIDC falham até o fornecedor ser guardado de novo ou o servidor reiniciar.
+
+---
+
+## Mapeamento para funções
+
+No config.yaml, um grupo OIDC é `oidc/<group>` e um utilizador é `oidc/<preferred_username>`:
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+Os valores correspondem exatamente, incluindo maiúsculas e minúsculas. Consulte [Funções](../config/roles.html) para as opções de função.
+
+---
+
+## Limitações
+
+Os utilizadores OIDC iniciam sessão no fornecedor, por isso algumas coisas funcionam de forma diferente das contas locais e LDAP:
+
+- Não têm palavra-passe no AnsibleForms, por isso não a podem alterar lá; a partir da 7.2.0 um [token de API](../profile/api-token.html)
+  é criado a partir da sua sessão.
+- Mantenha curta a claim `groups`: envie só os grupos que interessam ao AnsibleForms, por exemplo com um client scope
+  dedicado ou uma estrutura de grupos no fornecedor, ou filtre-os com o **Filtro de grupos**. A partir da 7.1.0 o token de
+  início de sessão do AnsibleForms deixou de transportar os grupos; antes, um utilizador em cem grupos ou mais podia não ver nenhum formulário, consulte
+  [Formulários e tarefas vazios depois de um início de sessão único](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
diff --git a/i18n/pt/_configure/config/categories.md b/i18n/pt/_configure/config/categories.md
new file mode 100644
index 0000000..9247049
--- /dev/null
+++ b/i18n/pt/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Categorias
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# Categorias
+{: .no_toc }
+
+Agrupar os formulários no painel.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O atributo categories
+
+A lista `categories` de topo do config.yaml:
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Objeto Category
+
+Cada entrada da lista `categories`:
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/pt/_configure/config/constants.md b/i18n/pt/_configure/config/constants.md
new file mode 100644
index 0000000..2553f38
--- /dev/null
+++ b/i18n/pt/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Constantes
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# Constantes
+{: .no_toc }
+
+Objetos livres que qualquer formulário pode reutilizar.
+{: .fs-6 .fw-300 }
+
+---
+
+## O atributo constants
+
+O objeto `constants` de topo do config.yaml:
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/pt/_configure/config/index.md b/i18n/pt/_configure/config/index.md
new file mode 100644
index 0000000..c7b30a5
--- /dev/null
+++ b/i18n/pt/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+Categorias, funções e constantes para todos os formulários
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores: o ficheiro config.yaml que contém as categorias, funções e constantes partilhadas por todos os formulários.
+
+O AnsibleForms usa um ficheiro config.yaml para configurar categorias, funções e constantes. Se não for fornecido nenhum ficheiro, é gerado um com uma configuração mínima. A configuração pode também ser importada para a base de dados, o que dispensa o ficheiro config.yaml.
+
+---
+
+## Visão geral
+
+O ficheiro config.yaml contém a configuração das categorias, funções e constantes usadas pelo AnsibleForms.
+
+**VÍDEO**: [Crie o seu primeiro formulário](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+O config.yaml mínimo seguinte serve de ponto de partida. Contém só a categoria `Default` obrigatória e as funções `admin` e `default` obrigatórias.
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## Prioridade de carregamento da configuração
+
+O AnsibleForms carrega o ficheiro config.yaml pela ordem seguinte (a primeira correspondência ganha):
+
+1. **DA BASE DE DADOS** : a configuração importada para a base de dados, só quando `ENABLE_CONFIG_IN_DATABASE=1`, ou quando essa
+   variável não está definida e a origem da configuração guardada na base de dados é `database` (uma cópia vazia recorre ao ficheiro)
+2. **DE UM REPOSITÓRIO (use_for_config)** : o repositório com o interruptor "use for config" ativado (novo na 6.1.0)
+3. **DE UM REPOSITÓRIO (use_for_forms)** : o repositório com o interruptor "use for forms" ativado (alternativa por compatibilidade com versões anteriores)
+4. **DO FICHEIRO LOCAL** : o ficheiro `config.yaml` local (variável de ambiente CONFIG_PATH)
+
+{: .warning }
+> **Nota:** Ative "use for config" num só repositório. Se vários o tiverem ativado, é registado um aviso e usa-se o primeiro.
+
+---
+
+## Nesta secção
+
+O ficheiro tem três atributos de topo, e cada um tem a sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Categorias](categories.html) | Agrupar os formulários no painel numa árvore de categorias com ícones |
+| [Funções](roles.html) | Mapear utilizadores e grupos para funções, e definir o que cada função pode fazer |
+| [Constantes](constants.html) | Objetos livres que qualquer formulário pode reutilizar |
diff --git a/i18n/pt/_configure/config/roles.md b/i18n/pt/_configure/config/roles.md
new file mode 100644
index 0000000..e80a9b0
--- /dev/null
+++ b/i18n/pt/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: Funções
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# Funções
+{: .no_toc }
+
+Mapear utilizadores e grupos para funções, e definir o que cada função pode fazer.
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O atributo roles
+
+A lista `roles` de topo do config.yaml:
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## A função default
+
+Todos os utilizadores com sessão iniciada têm a função `default`, por isso um formulário com `roles: [default]` está aberto a todos os que podem iniciar sessão. Não
+há acesso anónimo: ninguém recebe esta função sem iniciar sessão.
+
+A função não contém grupos nem utilizadores, já que se aplica a todos. As suas `options` são as predefinições de todos, tal como
+descrito em [Opções de função](#role-options) abaixo. O `config.yaml` tem de ter uma função `admin` e uma função `default`, e a
+página de funções mostra ambas como **Obrigatório**.
+
+`default` chamava-se `public` antes da 7.0.0, e o nome antigo continua a funcionar:
+
+- **Num formulário**, `roles: [public]` continua a corresponder a todos os utilizadores, por isso os formulários nos seus repositórios não precisam de alterações.
+- **No `config.yaml`**, uma função chamada `public` é renomeada para `default` no ficheiro quando a configuração é carregada. Só o nome
+  muda, é feita antes uma cópia de segurança da configuração, e uma configuração mantida num repositório fica então com uma alteração para enviar (push).
+- **Num template ytt**, o template não é reescrito: a configuração que produz é renomeada, e um aviso no registo pede-lhe
+  que renomeie também a função no template. A versão 8 recusa aí uma função `public`.
+
+Uma configuração com uma função `default` e uma função `public` é recusada, porque são a mesma função.
+
+---
+
+## Objeto Role
+
+Cada entrada da lista `roles`:
+
+{% include config_object.html name="Role" %}
+
+---
+
+## Opções de função
+
+As `options` de uma função ligam ou desligam funcionalidades para os seus membros. A partir da 7.3.0, a página da função mostra-as em quatro grupos,
+cada opção com um (i) que diz o que concede, o mesmo texto que a vista **Permissões** do perfil mostra:
+
+| Opção | Permite ao utilizador | Predefinição |
+|---|---|---|
+| **Definições** | | |
+| `showSettings` | Ver e alterar todas as páginas de definições; o registo do servidor e as cópias de segurança têm as suas próprias opções | Só admins |
+| `showAppearanceSettings` | Alterar as definições de aparência, sem as outras definições (a partir da 7.3.0) | Desligado |
+| `showConnectionsSettings` | Gerir as definições de ligações (credenciais, runners e mais), sem as outras definições (a partir da 7.3.0) | Desligado |
+| `showLogs` | Ver o registo do servidor | Só admins |
+| `showAuditLog` | Ver o registo de auditoria, sem as outras definições (a partir da 7.3.0) | Só admins |
+| `allowBackupOps` | Fazer cópias de segurança e restaurar a base de dados | Só admins |
+| **Designer** | | |
+| `showDesigner` | Ver e usar o designer | Só admins |
+| `allowFormDesign` | Editar a configuração dos formulários no designer: categorias, constantes e formulários. Sem ela, só leitura (a partir da 7.3.0) | Ligado |
+| `allowPlaybookDesign` | Editar os playbooks no designer: guardá-los, criá-los, removê-los e enviá-los (push). Sem ela, só leitura | Ligado |
+| `allowWorkflowDesign` | Editar os workflows no designer: guardá-los, criá-los, removê-los e enviá-los (push). Sem ela, só leitura | Ligado |
+| `allowInventoryDesign` | Editar os inventários no designer: guardá-los, criá-los, removê-los e enviá-los (push). Sem ela, só leitura | Ligado |
+| `allowVarsFileDesign` | Editar os ficheiros de variáveis no designer: guardá-los, criá-los, removê-los e enviá-los (push). Sem ela, só leitura | Ligado |
+| **Tarefas** | | |
+| `showJobs` | Ver a página de tarefas | Ligado |
+| `showAllJobLogs` | Ver as tarefas de todos os utilizadores, não só as suas | Só admins |
+| `manageAllJobs` | Abortar, eliminar e relançar as tarefas de todos os utilizadores; eliminar e relançar também precisam das duas opções abaixo (a partir da 7.3.0) | Só admins |
+| `showExtravars` | Ver os extravars de um formulário e de uma tarefa | Ligado |
+| `showDebugButtons` | Ver os botões de depuração num formulário | Ligado |
+| `showArtifacts` | Ver os artefactos de uma tarefa: o que uma tarefa do AWX devolve, ou o que um playbook recolheu com `set_stats` | Ligado |
+| `allowVerboseMode` | Executar tarefas em modo verboso | Ligado |
+| `allowJobRelaunch` | Relançar uma tarefa com os dados do formulário de uma execução anterior | Só admins |
+| `allowJobDeletion` | Eliminar tarefas: as próprias, ou as de todos os utilizadores com `manageAllJobs`. Sem ela, o histórico de tarefas fica completo (a partir da 7.3.0) | Ligado |
+| `allowScheduledJobs` | Criar e gerir agendamentos recorrentes e únicos, na página **Agendamentos** (consulte o aviso abaixo) | Só admins |
+| `allowPlannedJobs` | Planear uma tarefa para correr uma vez a uma hora definida (**Executar mais tarde**) | Ligado |
+| `allowStoredJobs` | Guardar os dados de um formulário e voltar a carregá-los mais tarde | Ligado |
+| **Acesso e integrações** | | |
+| `allowLogin` | Iniciar sessão no AnsibleForms | Ligado |
+| `allowChat` | Usar o [assistente de chat](../chat/), quando está ativado | Ligado |
+| `allowMcp` | Usar o [servidor MCP](../mcp/) a partir de um agente de IA, quando está ativado | O `allowChat` da função |
+| `allowFileUploads` | Carregar ficheiros pelos campos de ficheiro de um formulário (a partir da 7.3.0) | Ligado |
+| `allowApiTokens` | Criar [tokens de API](../profile/api-token.html) para scripts, até à duração máxima que a instância permite (a partir da 7.3.0) | Desligado |
+| `extendedTokenExpiration` | Criar também tokens de API que nunca expiram; precisa de `allowApiTokens` | Desligado |
+
+Algumas opções incluem outras, e a página da função mostra as incluídas ligadas e a cinzento:
+
+- **`showSettings`** concede também `showAppearanceSettings`, `showConnectionsSettings` e `showAuditLog`.
+- **`manageAllJobs`** concede também `showAllJobLogs`, já que atuar sobre as tarefas de todos os utilizadores implica vê-las.
+- **As opções de design** só contam com `showDesigner`, e `extendedTokenExpiration` só com `allowApiTokens`.
+
+Até à 7.2.0, `showAllJobLogs` também deixava um utilizador abortar e eliminar as tarefas que mostrava; a partir da 7.3.0 isso requer `manageAllJobs`.
+Uma função de antes da 7.3.0 com `extendedTokenExpiration` e sem `allowApiTokens` recebe `allowApiTokens`, para manter os seus tokens.
+
+**Só admins** significa ligado para os utilizadores que têm a função `admin`, e desligado para todos os outros. Quando um utilizador corresponde a várias funções,
+as opções combinam-se assim:
+
+- **Entre as funções do utilizador**, uma opção só fica ligada quando todas as funções que a definem concordam: um `false` explícito ganha.
+- **A função `default`** preenche as opções que nenhuma das outras funções do utilizador define, por isso pode conter predefinições para todos.
+- **As opções não definidas em lado nenhum** recebem a predefinição da tabela.
+
+`showExtraVars`, com V maiúsculo, é aceite como outra grafia de `showExtravars`; quando qualquer das grafias é `false`, a
+opção fica desligada.
+
+{: .warning }
+> Trate `allowScheduledJobs` como uma opção de nível de admin. Os agendamentos não pertencem ao utilizador que os criou: todos os utilizadores com
+> a opção veem e podem alterar todos os agendamentos. Um agendamento também corre com direitos de admin, para qualquer formulário, seja qual for o
+> acesso do seu criador. Conceda-a só a funções em que confiaria como admins.
+
+{: .warning }
+> `allowLogin: false` na função `default` bloqueia todos os utilizadores cujas outras funções não definam `allowLogin: true`, incluindo
+> os admins. Volte a concedê-la nas funções que têm de iniciar sessão antes de guardar.
diff --git a/i18n/pt/_configure/credentials.md b/i18n/pt/_configure/credentials.md
new file mode 100644
index 0000000..38cd189
--- /dev/null
+++ b/i18n/pt/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Credenciais
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# Credenciais
+{: .no_toc }
+
+Guarde os acessos com que se ligam os formulários, os repositórios, os cofres de segredos e os canais de notificação
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: adicione os utilizadores, palavras-passe e tokens com que o AnsibleForms se liga, guardados cifrados ou lidos de um cofre de segredos.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Tipos de credencial](credentials/types.html) | O que cada tipo contém, e onde pode ser escolhido |
+| [A página de credenciais](credentials/list.html) | A lista de credenciais, e a caixa de diálogo que adiciona uma |
+| [A página de uma credencial](credentials/credential-page.html) | Os separadores de uma credencial, e o que a usa |
+
+---
+
+## Como funciona
+
+Uma **credencial** é um acesso com nome, adicionado em **Ligações > Credenciais**. Os formulários e os outros objetos de administração referem-se
+a ela pelo seu nome, por isso a palavra-passe propriamente dita nunca aparece num formulário. O seu utilizador e a sua palavra-passe são guardados na
+base de dados do AnsibleForms, cifrados com `ENCRYPTION_SECRET`, ou lidos de um [cofre de segredos](secret-stores/) cada vez que a
+credencial é usada.
+
+---
+
+## Quem pode alterar uma credencial
+
+A partir da 7.3.0, uma credencial de que depende uma ligação ou um início de sessão só pode ser adicionada, alterada ou eliminada por um admin:
+
+| Credenciais | Porquê |
+|---|---|
+| Tipos de ligação: `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins`, `vault` e `cyberark` | Um runner ou um cofre de segredos obtém dela o seu endereço e o seu segredo |
+| Tipos de início de sessão: `oidc`, `entraid` e `ldap` | Um fornecedor SSO ou um diretório LDAP inicia a sessão dos utilizadores com ela |
+| Qualquer credencial que um runner nomeie | O runner inicia sessão com ela, e uma alteração do próprio runner também precisa de um admin |
+
+Os outros utilizadores com acesso às credenciais veem estas só de leitura. Um utilizador que pudesse apontar uma credencial destas para outro
+servidor receberia todos os segredos enviados através dela, e é por isso que a regra segue a dos runners. Mais três regras
+mantêm esses utilizadores afastados de segredos que de outra forma não poderiam ler:
+
+- **Nomear uma credencial protegida**: só um admin pode nomear uma destas credenciais noutro sítio, como num repositório,
+  num canal de notificação ou nas definições do assistente de chat. Uma credencial que lê a sua palavra-passe de um cofre de segredos fica
+  protegida da mesma forma, seja qual for o seu tipo.
+- **Escolher um cofre de segredos**: só um admin pode apontar uma credencial para um [cofre de segredos](secret-stores/), ou alterar o
+  cofre ou a referência que lê; outro utilizador pode mesmo assim devolvê-los sem alterações, ou esvaziá-los todos.
+- **Mover uma credencial**: quando outro utilizador altera onde uma credencial inicia sessão (o seu host, porta, emissor, tenant ou
+  endereço do servidor) sem voltar a escrever a sua palavra-passe, a palavra-passe guardada é apagada, tal como a referência ao cofre de segredos
+  que lê, para que o segredo antigo nunca vá para o novo destino.
+
+---
+
+## Credenciais em uso
+
+Uma credencial que ainda é nomeada por registos não pode ser eliminada nem renomeada, porque estes ficariam a apontar para nada.
+A recusa indica quantos registos a usam; o separador **Usado por** da [sua página](credentials/credential-page.html) lista-os.
+Aponte-os primeiro para outra credencial e depois elimine-a ou renomeie-a.
diff --git a/i18n/pt/_configure/credentials/credential-page.md b/i18n/pt/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..8599efd
--- /dev/null
+++ b/i18n/pt/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: "A página de uma credencial"
+parent: Credenciais
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# A página de uma credencial
+{: .no_toc }
+
+Os separadores de uma credencial, e o que a usa
+{: .fs-6 .fw-300 }
+
+A página de uma credencial mostra os passos da sua caixa de diálogo como separadores, mais o que a usa:
+
+| Separador | O que contém |
+|---|---|
+| Detalhes | Nome e descrição. |
+| Tipo | Para que serve a credencial. |
+| Acesso | Todos os campos do seu tipo, como no passo **Acesso** da caixa de diálogo: o utilizador, a palavra-passe e onde inicia sessão (host e porta, a base de dados, o servidor de correio, os servidores do diretório, o tenant ou o emissor, o endereço do servidor e o seu TLS). O AppID, o certificado de cliente e a chave de uma credencial CyberArk. |
+| Armazenamento | Base de dados ou Cofre de segredos, e o cofre e a referência. Não existe para CyberArk nem para HashiCorp Vault. |
+| Usado por | Tudo o que nomeia esta credencial: cofres de segredos, canais de notificação, repositórios, diretórios LDAP, fornecedores SSO, runners, o assistente de chat, formulários e os workflows do designer. Uma linha abre-o. |
+
+A palavra-passe é escrita no separador **Acesso**, e nunca volta a ser mostrada depois de guardada: deixada vazia, a guardada mantém-se. Numa credencial
+CyberArk, deixe a chave de cliente vazia para manter a guardada. No canto superior direito estão **Testar ligação** (só para credenciais de base de dados),
+**Eliminar** e **Guardar**.
+
+A partir da 7.3.0, **Eliminar** e um nome novo são recusados enquanto **Usado por** listar alguma coisa, consulte [Credenciais em uso](../credentials.html#credentials-in-use).
+
+Uma credencial declarada no [config seed](../seed/) é só de leitura nesta página: altere-a antes no ficheiro de seed.
diff --git a/i18n/pt/_configure/credentials/list.md b/i18n/pt/_configure/credentials/list.md
new file mode 100644
index 0000000..f64c62d
--- /dev/null
+++ b/i18n/pt/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: A página de credenciais
+parent: Credenciais
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# A página de credenciais
+{: .no_toc }
+
+A lista de credenciais, e a caixa de diálogo que adiciona uma
+{: .fs-6 .fw-300 }
+
+A página em **Ligações > Credenciais** lista todas as credenciais com o seu **Nome**, **Tipo**, **Descrição** e **Usado por**, o
+número de registos, formulários e workflows que a nomeiam (consulte [Credenciais em uso](../credentials.html#credentials-in-use)).
+
+**Adicionar credencial** abre uma caixa de diálogo em passos:
+
+| Passo | Campos |
+|---|---|
+| Credencial | Nome e descrição, ambos obrigatórios. |
+| Tipo | Um de 18 tipos, ver abaixo. |
+| Acesso | Com que e onde o tipo inicia sessão, ver abaixo. |
+| Armazenamento | Onde ficam o utilizador e a palavra-passe: **Base de dados** (cifrados na base de dados do AnsibleForms) ou **Cofre de segredos**, com o cofre e a **Referência** nele. Não existe para CyberArk nem para HashiCorp Vault, com os quais um cofre de segredos inicia sessão. |
+
+O passo **Tipo** lista os tipos pelo nome: AAP, API, Ascender, AWX, CyberArk, Base de dados, Git, HashiCorp Vault, Jenkins, LDAP,
+Microsoft Entra ID, Open ID, RTE, Rundeck, Semaphore, SMTP, SSH, e Utilizador e palavra-passe (consulte [Tipos de credencial](types.html)).
+
+O passo **Acesso** contém todos os campos do tipo, incluindo o endereço; não há um passo de ligação separado:
+
+| Tipos | Campos do passo Acesso |
+|---|---|
+| Todos os tipos exceto CyberArk | A palavra-passe, ou o que a substitui: a palavra-passe de bind do LDAP, o client secret do Entra ID e do Open ID, o token do HashiCorp Vault, o token do RTE, o token de API do Semaphore, do Rundeck e do Jenkins, um token ou palavra-passe para AWX, AAP e Ascender |
+| Todos os tipos exceto HashiCorp Vault, RTE, Semaphore e Rundeck | O utilizador: o AppID do CyberArk, o bind DN do LDAP, o client ID do Entra ID e do Open ID, opcional para AWX, AAP e Ascender |
+| SSH, Base de dados | **Host** e **Porta**; para uma base de dados também o **Tipo de base de dados** e a **Base de dados** |
+| SMTP | **Servidor de correio** (obrigatório), a sua **Porta** e **Usar TLS** |
+| LDAP | Os **Servidores** do diretório (obrigatório), a sua **Porta** e **Ativar TLS**; com TLS, **Ignorar certificados**, o **CA bundle** e um **Certificado de cliente** |
+| Microsoft Entra ID | **Tenant ID** (obrigatório) e **URI de redirecionamento** |
+| Open ID | **Emissor** (obrigatório) e **URI de redirecionamento** |
+| HashiCorp Vault, CyberArk, RTE, AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | **Servidor**, o endereço em que inicia sessão, obrigatório, com **Ignorar a verificação do certificado** e o **CA bundle** |
+| CyberArk | **Certificado de cliente** e **Chave de cliente** |
+
+Uma linha abre a página própria da credencial. O seu menu oferece **Editar**, **Testar ligação** (só para credenciais de base de dados) e **Eliminar**. A
+palavra-passe altera-se na página da credencial, no seu separador **Acesso**.
diff --git a/i18n/pt/_configure/credentials/types.md b/i18n/pt/_configure/credentials/types.md
new file mode 100644
index 0000000..14a8739
--- /dev/null
+++ b/i18n/pt/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: Tipos de credencial
+parent: Credenciais
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# Tipos de credencial
+{: .no_toc }
+
+O que cada tipo contém, e onde pode ser escolhido
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Os tipos
+
+O tipo diz para que serve uma credencial. Decide que campos a caixa de diálogo pede, e onde pode ser escolhida:
+
+| Tipo | O que contém | Usado por |
+|---|---|---|
+| Utilizador e palavra-passe | Um utilizador e uma palavra-passe para qualquer acesso: uma API REST com basic auth, um serviço e mais. A predefinição | Playbooks, através das `credentials` de um formulário ou de um campo de credencial; [expressões REST](../expressions/credentials.html) |
+| SSH | Um utilizador e uma palavra-passe para SSH a um servidor, com o seu host e porta | Playbooks, através das `credentials` ou `ansibleCredentials` de um formulário ou de um campo de credencial, e o acesso de um nó de workflow |
+| Git | Um utilizador e uma palavra-passe ou um token para repositórios git | [Repositórios](../repositories/authentication.html) |
+| API | Um utilizador e uma palavra-passe ou um token para uma API REST | [Expressões REST](../expressions/credentials.html), o token de um bot do Telegram, o bearer token de um webhook, a chave de API do assistente de chat |
+| Base de dados | Um acesso a uma base de dados, com o seu tipo, host, porta e nome da base de dados | Consultas de formulários (`dbConfig`) e `fnCredentials`; pode ser testado |
+| CyberArk | O endereço do CyberArk Central Credential Provider (CCP) e o seu TLS, e o AppID, o certificado de cliente e a chave com que um cofre CyberArk inicia sessão | Um cofre de segredos [CyberArk](../secret-stores/cyberark.html) |
+| SMTP | Um servidor de correio, a sua porta e TLS, e o seu acesso (nenhum para um relay) | Um [canal de notificação](../notification-channels.html) de correio |
+| LDAP | Os servidores, a porta, o TLS e os certificados de um diretório, e o seu bind DN e palavra-passe | Um [diretório LDAP](../authentication/ldap.html) |
+| Microsoft Entra ID | O registo de aplicação de um fornecedor: o seu tenant ID, client ID, client secret e URI de redirecionamento | Um [fornecedor Entra ID](../authentication/entra-id.html) |
+| Open ID | O cliente de um fornecedor: o seu emissor, client ID, client secret e URI de redirecionamento | Um [fornecedor OIDC](../authentication/oidc.html) |
+| RTE | O token (`RTE_TOKEN`) e o endereço de um RTE | Um [runner](../runners.html) RTE |
+| AWX, AAP, Ascender | O token ou o acesso, e o endereço, dessa plataforma | Um runner desse tipo |
+| Semaphore, Rundeck | O token de API e o endereço desse produto | Um runner desse tipo |
+| Jenkins | Um utilizador, o seu token de API e o endereço de um Jenkins | Um runner Jenkins |
+| HashiCorp Vault | O token e o endereço com que um cofre Vault inicia sessão | Um cofre de segredos [HashiCorp Vault](../secret-stores/hashicorp-vault.html) |
+
+Uma credencial de base de dados pode ser do tipo MySQL, MSSQL, PostgreSQL, Oracle ou MongoDB.
+
+Na API e no [config seed](../seed/), os tipos são `userpass`, `ssh`, `git`, `api`, `database`, `cyberark`, `smtp`,
+`ldap`, `entraid`, `oidc`, `rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck`, `jenkins` e `vault`. A atualização a partir da 6
+dá a todas as credenciais o tipo `userpass`, ou `database` para uma de base de dados: um formulário usa-a como na 6. Altere-o para SSH num
+acesso com que se liga o playbook de um nó de workflow, ou para API numa API REST.
+
+---
+
+## Endereços nas credenciais
+
+A partir da 7.3.0, um acesso que funciona num servidor transporta esse servidor, por isso o registo que o usa só nomeia a credencial:
+
+| Registo | O que passou para a sua credencial |
+|---|---|
+| Um diretório LDAP | Os seus servidores, porta, TLS, certificados e conta de bind, para uma credencial `ldap` chamada `<directory>-ldap` |
+| Um fornecedor SSO | O seu client ID e secret, tenant ou emissor, e URI de redirecionamento, para uma credencial `entraid` ou `oidc` chamada `<provider>-sso` |
+| Um runner | O seu endereço e TLS, e o seu token ou acesso, para uma credencial do seu tipo, `<runner>-token` ou `<runner>-login` |
+| Um cofre de segredos | O seu endereço e TLS, e o seu token (`<store>-token`) ou o AppID e o certificado do CyberArk (`<store>-appid`) |
+| Um canal de correio | O seu servidor, porta e TLS, para a sua credencial `smtp`, ou uma nova chamada `<channel>-smtp` |
+
+A atualização para a 7.3.0 faz estas mudanças uma vez. Um registo que já nomeava uma credencial mantém-na, e recebe uma cópia dela quando
+outro registo usava o mesmo acesso com outro servidor. Os registos declarados no [config seed](../seed/) ficam como o seed os tem.
+As credenciais das ligações e dos inícios de sessão só podem ser alteradas por um admin, consulte [Quem pode alterar uma credencial](../credentials.html#who-may-change-a-credential).
diff --git a/i18n/pt/_configure/customization/configuration.md b/i18n/pt/_configure/customization/configuration.md
new file mode 100644
index 0000000..4bc0933
--- /dev/null
+++ b/i18n/pt/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: Configuração
+parent: Variáveis de ambiente
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# Configuração
+{: .no_toc }
+
+O config seed, onde a configuração é guardada, git e ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para decidir de onde vem a configuração: um config seed, a base de dados, git ou templates ytt.
+
+---
+
+## Exemplo
+
+Aplicar um config seed montado, verificá-lo a cada cinco minutos e manter o `config.yaml` na base de dados. No `docker-compose.yml`:
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+Um seed inválido impede o servidor de arrancar. Consulte [Config seed](../seed/) para o formato do ficheiro.
+
+---
+
+## De onde é lido o config.yaml
+
+As categorias, funções e constantes vêm do `config.yaml` em disco ou da sua cópia na base de dados, decidido por esta ordem:
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE), quando está definida, no ambiente ou no
+   separador **Configuração** da página de definições: `1` lê a base de dados, `0` lê o ficheiro.
+2. Caso contrário, a origem da configuração guardada na base de dados (`file` ou `database`), que as instâncias configuradas
+   antes da 6.3.0 escolheram na página de definições.
+3. Caso contrário, o ficheiro: o `config.yaml` do repositório com **Usar para a configuração** ativado, senão o de um repositório com
+   **Usar para formulários** ativado, senão o que está em [`CONFIG_PATH`](paths.html#env_CONFIG_PATH).
+
+Uma `ENABLE_CONFIG_IN_DATABASE` definida explicitamente ganha sempre, até `0` sobre um `database` guardado. É lida cada vez que a
+configuração é carregada, por isso uma alteração aplica-se sem reiniciar. A página **Estado** mostra a origem em uso no seu separador **Informação**.
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/pt/_configure/customization/features.md b/i18n/pt/_configure/customization/features.md
new file mode 100644
index 0000000..4a87b77
--- /dev/null
+++ b/i18n/pt/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Funcionalidades
+parent: Variáveis de ambiente
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# Funcionalidades
+{: .no_toc }
+
+O designer, MCP, chat, a validação no lançamento, a lista de tarefas, métricas, a API do AWX e o registo de consultas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para ligar ou desligar partes opcionais da aplicação.
+
+---
+
+## Exemplo
+
+Servir o servidor MCP para agentes de IA e impor as regras de validação dos formulários em cada lançamento. No `.env` do projeto compose:
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` e `ENABLE_CHAT` aplicam-se sem reiniciar: são lidas em cada pedido, por isso pode ligá-las na
+página de definições. Enquanto uma está desligada, o seu endpoint (`/api/v2/mcp` ou `/api/v2/chat`) responde `404`.
+
+Corra primeiro `LAUNCH_VALIDATION=log` durante algum tempo: regista o que `enforce` recusaria sem o recusar. Consulte [MCP](../mcp/)
+e [Registar e impor](../launch-validation/log-and-enforce.html).
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/pt/_configure/customization/index.md b/i18n/pt/_configure/customization/index.md
new file mode 100644
index 0000000..b4b22cd
--- /dev/null
+++ b/i18n/pt/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: Variáveis de ambiente
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# Variáveis de ambiente
+{: .no_toc }
+
+Configure o AnsibleForms com variáveis de ambiente
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores que implementam o AnsibleForms: as variáveis de ambiente que o servidor lê, agrupadas por tema.
+
+O AnsibleForms ajusta-se com variáveis de ambiente, quer corra com Docker Compose, no Kubernetes ou a partir do código-fonte.
+
+---
+
+## De onde vêm os valores
+
+O servidor lê cada variável da primeira destas origens que a define, por isso um valor mais acima na lista ganha sempre:
+
+1. **O ambiente do processo**: `environment:` e `env_file:` no docker-compose (o `.env` do projeto é passado desta forma),
+   `env` e `envFrom` no Kubernetes, ou a shell que arranca o `node`.
+2. **`persistent/.env`**, o ficheiro que as páginas de definições escrevem (`data/.env` no projeto docker-compose, outro caminho com
+   `MANAGED_ENV_PATH`). É lido em cada arranque, também em produção, e nunca se sobrepõe a uma variável que já esteja definida.
+3. **`server/.env.<NODE_ENV>`**, por exemplo `.env.development`. Só é lido quando `NODE_ENV` não é `production` (ou com
+   `FORCE_DOTENV=1`), na prática ao correr [a partir do código-fonte](../installation/from-source.html) em modo de desenvolvimento.
+4. **A predefinição integrada**, mostrada nas tabelas de cada grupo.
+
+As páginas de definições, em **Definições > Geral**, mostram o valor em vigor e guardam as alterações em `persistent/.env`. Muitas variáveis
+aplicam-se assim que são guardadas; as outras são guardadas mas precisam de um reinício, e a página lista-as depois de guardar. Uma variável definida
+no ambiente do processo não pode ser alterada aí: a página mostra-a como *Definido no ambiente, por isso não pode ser alterado aqui.*
+Algumas variáveis, como `ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET`, nunca podem ser alteradas a partir da página.
+
+As variáveis que um RTE lê, como `AF_ROLE`, `RTE_MODE`, `APP_URL` ou `RTE_MAX_JOBS`, não estão de todo nas páginas de definições: a
+aplicação não as usa, por isso defina-as no ambiente onde o RTE corre. As variáveis `RTE_*` que a própria aplicação lê,
+`RTE_QUEUE_MINUTES` e `RTE_FILES_MAX_MB`, são a exceção e ficam nas páginas. Quatro variáveis do RTE, `RTE_MAX_JOBS`,
+`RTE_CACHE_MB`, `RTE_FILES` e `RTE_DRAIN_SECONDS`, podem em alternativa ser definidas por RTE na sua página de runner, onde um valor prevalece sobre a
+variável (consulte [As definições de um RTE](../runners/runner-page.html#an-rtes-settings)).
+
+Com [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0`, as páginas só mostram os valores e a gravação é recusada. Use-o
+quando o ambiente está declarado num manifesto, como descrito em [Edição e auditoria](../seed/environment-and-audit.html).
+
+O [config seed](../seed/) não define variáveis de ambiente. Declara objetos que são guardados na base de dados, e as
+referências `${ENV_VAR}` que contém são resolvidas a partir do ambiente do servidor em execução.
+
+Algumas variáveis são lidas só do ambiente e não estão nas tabelas: `MANAGED_ENV_PATH` e `FORCE_DOTENV`, descritas
+acima, e as variáveis de proxy do sistema `HTTPS_PROXY` e `NO_PROXY` (também lidas em minúsculas). Um RTE de saída liga-se à aplicação através de
+`HTTPS_PROXY`, e um RTE de entrada envia por ele a sua chamada de registo, a menos que o host da aplicação esteja em `NO_PROXY` (nomes de host,
+sufixos `.domain`, ou `*` para todos os hosts).
+
+As variáveis marcadas como <span class="af-badge af-badge-secret">Secreto</span> contêm uma palavra-passe, um token ou uma chave: mantenha-as fora do controlo
+de versões, por exemplo num Secret do Kubernetes ou num ficheiro `.env` que não é enviado para o repositório.
+
+---
+
+## Nesta secção
+
+As variáveis estão agrupadas por tema, com uma página por grupo:
+
+| Página | O que abrange |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## Outras variáveis
+
+As variáveis seguintes ainda não estão atribuídas a nenhum grupo:
+
+{{ other }}
+{% endif %}
diff --git a/i18n/pt/_configure/customization/logging.md b/i18n/pt/_configure/customization/logging.md
new file mode 100644
index 0000000..122edbd
--- /dev/null
+++ b/i18n/pt/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Registo
+parent: Variáveis de ambiente
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# Registo
+{: .no_toc }
+
+Níveis de registo, ficheiros, syslog e cores da consola
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para ajustar quanto se regista, para onde vão os ficheiros de registo, ou para mostrar as horas no seu próprio fuso horário.
+
+---
+
+## Exemplo
+
+Registar mais nos ficheiros do que na consola, e mostrar as horas do registo e das tarefas na hora de Amesterdão.
+No `.env` do projeto compose:
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Os servidores syslog já não se configuram aqui: adicione-os em **Definições > Ligações > Syslog**, consulte [Registos](../production/logs.html#syslog).
+As variáveis `LOG_SYSLOG_*` abaixo estão obsoletas desde a 7. O primeiro arranque que encontra `LOG_SYSLOG_HOST` definida importa-as
+uma vez como o servidor syslog `syslog`, que recebe o registo do servidor, e a partir daí ignora-as.
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/pt/_configure/customization/paths.md b/i18n/pt/_configure/customization/paths.md
new file mode 100644
index 0000000..e550f71
--- /dev/null
+++ b/i18n/pt/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Caminhos
+parent: Variáveis de ambiente
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# Caminhos
+{: .no_toc }
+
+Onde ficam a configuração, os formulários, os playbooks, os ficheiros carregados e as cópias de segurança
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para manter parte dos dados noutro volume, por exemplo as cópias de segurança e os ficheiros carregados num armazenamento maior ou mais barato.
+
+---
+
+## Exemplo
+
+Cópias de segurança e ficheiros carregados num volume separado, o resto dos dados na pasta persistente habitual. No `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+Um caminho novo aplica-se só a ficheiros novos: o que já está na pasta antiga não é movido, por isso copie-o você mesmo.
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/pt/_configure/customization/retention.md b/i18n/pt/_configure/customization/retention.md
new file mode 100644
index 0000000..085f55c
--- /dev/null
+++ b/i18n/pt/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: Cópias de segurança e retenção
+parent: Variáveis de ambiente
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# Cópias de segurança e retenção
+{: .no_toc }
+
+Os comandos de cópia de segurança, e durante quanto tempo se mantêm as cópias de segurança, as tarefas e os registos de auditoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para controlar quanto histórico a base de dados mantém, e quantas cópias de segurança ficam em disco.
+
+---
+
+## Exemplo
+
+Manter as tarefas terminadas durante 90 dias e o registo de auditoria durante dois anos. No `.env` do projeto compose:
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+Uma tarefa diária remove as tarefas terminadas mais antigas do que isto às 2:30 e as entradas de auditoria às 3:30. Uma tarefa em execução, ou uma que aguarda
+aprovação, nunca é removida. Ambas as variáveis se aplicam sem reiniciar quando são alteradas na página de definições.
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/pt/_configure/customization/security.md b/i18n/pt/_configure/customization/security.md
new file mode 100644
index 0000000..09bee18
--- /dev/null
+++ b/i18n/pt/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Variáveis de segurança
+parent: Variáveis de ambiente
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# Variáveis de segurança
+{: .no_toc }
+
+Tokens, cifragem, hosts REST de saída, mascaramento e as antigas definições VAULT_*
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas para definir os seus próprios segredos de token e de cifragem, e para limitar o que os formulários podem chamar e mostrar.
+
+---
+
+## Exemplo
+
+Os seus próprios segredos, chamadas REST limitadas a uma API e a uma rede interna, e mais uma chave mascarada. No `.env` do projeto compose:
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+Defina `ENCRYPTION_SECRET` antes de guardar a primeira credencial. A partir da 7.3.0, defini-la ou alterá-la volta a cifrar todos os segredos
+guardados no arranque seguinte, com `ENCRYPTION_SECRET_PREVIOUS` a indicar a chave antiga quando era sua, consulte
+[Alterar o segredo de cifragem](../security/secrets.html#changing-the-encryption-secret).
+
+---
+
+## Chamadas REST e jq
+
+A partir da 7.3.0, as funções auxiliares REST (`fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt`, `fn.fnRestJwtSecure`) verificam o
+certificado do endpoint que chamam, como qualquer outra ligação; até à 7.2.0 nunca o faziam. Aplicam-se-lhes três definições:
+
+| Variável | Predefinição | Efeito |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` salta a verificação do certificado: só para endpoints com um certificado autoassinado |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | Quanto tempo uma chamada REST espera por uma resposta antes de falhar por tempo limite |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | Quanto tempo um filtro jq pode correr antes de ser parado; a saída do jq também está limitada a 64 MB |
+
+As três produzem efeito ao serem guardadas, sem reiniciar. Para um endpoint cujo certificado está assinado por uma CA privada, mantenha a verificação ligada
+e dê antes essa CA ao Node.js: defina `NODE_EXTRA_CA_CERTS` com um ficheiro PEM que a contenha no ambiente da aplicação, e depois reinicie a aplicação.
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/pt/_configure/customization/server.md b/i18n/pt/_configure/customization/server.md
new file mode 100644
index 0000000..3c2cf13
--- /dev/null
+++ b/i18n/pt/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Servidor e base de dados
+parent: Variáveis de ambiente
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# Servidor e base de dados
+{: .no_toc }
+
+O servidor web, a ligação ao MySQL, a conta de admin, e o que cada processo corre (AF_ROLE e as variáveis RTE_*)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Altere estas quando a aplicação corre atrás de um reverse proxy, noutra porta, ou contra uma base de dados fora do projeto compose.
+
+---
+
+## Exemplo
+
+Atrás de um reverse proxy que termina o TLS, em `/ansibleforms`, com um MySQL externo. No `docker-compose.yml`:
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+Estas substituem as linhas `DB_*` e `PORT` que o ficheiro compose já tem aí, que prevalecem sobre os mesmos nomes no `.env`. Remova
+o serviço `mysqldb` e o `depends_on` que espera por ele, e mapeie a porta 8000 em `ports`. O lado do proxy está descrito na página
+[Reverse proxy](../production/reverse-proxy.html).
+
+---
+
+## Variáveis
+
+Todas as variáveis deste grupo, com o seu tipo, predefinição e descrição:
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/pt/_configure/disclaimer.md b/i18n/pt/_configure/disclaimer.md
new file mode 100644
index 0000000..78b81ac
--- /dev/null
+++ b/i18n/pt/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Aviso legal
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# Aviso legal
+{: .no_toc }
+
+Condições que cada utilizador aceita uma vez antes de usar a aplicação, registadas com quem aceitou que versão e quando
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: peça a todos os utilizadores que aceitem condições de utilização, em **Definições > Acesso > Aviso legal**, com a opção de função `showSettings`.
+
+A partir da 7.3.0, a página lista todas as versões do aviso legal, e cada versão abre numa página própria com as suas aceitações.
+Até à 7.2, a página tinha em vez disso três separadores (**Geral**, **Versões** e **Aceitações**); a atualização mantém todas as versões.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Geral](disclaimer/general.html) | A lista de versões, adicionar uma, e ativar a que os utilizadores aceitam |
+| [Versões](disclaimer/versions.html) | A página de uma versão, e alterar o seu texto como correção ou para todos de novo |
+| [Aceitações](disclaimer/acceptances.html) | Quem aceitou que versão, e pedir de novo a utilizadores escolhidos |
+
+
+---
+
+## O que os utilizadores veem
+
+Com uma versão ativada, todos os utilizadores que iniciam sessão recebem-na numa caixa de diálogo antes de qualquer outra coisa, admins incluídos:
+
+1. Leem o seu título e o seu texto.
+2. Marcam a caixa de verificação e clicam em **Aceitar**. **Recusar**, a vermelho, termina-lhes a sessão.
+
+A partir da 7.3.0, a página por trás da caixa de diálogo fica desfocada até responderem.
+
+Um utilizador aceita cada versão uma vez: não lhe é pedido de novo no início de sessão seguinte, só quando chega uma versão nova, quando
+um admin guarda um texto alterado com [Pedir de novo a todos](disclaimer/versions.html#changing-the-text), ou quando um admin usa
+[Pedir novamente](disclaimer/acceptances.html#asking-users-again) na sua aceitação.
+
+Até aceitarem, a API responde a todas as chamadas da sua sessão com o estado `403` e o código `disclaimer_required`,
+exceto as chamadas em `/api/v2/disclaimer` e `/api/v2/profile`, e os eventos em direto que o navegador acompanha.
+Um [token de API](profile/api-token.html) nunca é solicitado, já que um script não tem ninguém que clique.
+
diff --git a/i18n/pt/_configure/disclaimer/acceptances.md b/i18n/pt/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..efafc01
--- /dev/null
+++ b/i18n/pt/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Aceitações
+parent: Aviso legal
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# Aceitações
+{: .no_toc }
+
+Quem aceitou que versão, e pedir de novo a utilizadores escolhidos
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quem aceitou
+
+Cada aceitação fica registada para o utilizador e a versão, e o separador **Aceitações** da página de uma versão lista-as, a mais recente primeiro:
+
+| Coluna | Significado |
+|---|---|
+| **Utilizador** | O nome de utilizador |
+| **Início de sessão** | Como iniciou sessão: Local, LDAP, Microsoft Entra ID ou OpenID Connect |
+| **Aceite** | Quando |
+| **Endereço IP** | De onde |
+| **Navegador** | O seu navegador |
+
+---
+
+## Pedir de novo aos utilizadores
+
+A partir da 7.3.0, pode pedir-se a utilizadores escolhidos que aceitem uma versão de novo, sem pedir a todos.
+
+**Pedir novamente** no menu de uma linha, ou nas linhas marcadas na lista, apaga essas aceitações depois de uma confirmação: esses utilizadores recebem o
+aviso legal de novo no seu pedido seguinte, sem voltar a iniciar sessão. A lista também pode ser exportada, como qualquer tabela.
+
+O [registo de auditoria](../production/logs.html#audit-trail) também regista cada aceitação, cada recusa e cada alteração do aviso legal.
diff --git a/i18n/pt/_configure/disclaimer/general.md b/i18n/pt/_configure/disclaimer/general.md
new file mode 100644
index 0000000..2ab708b
--- /dev/null
+++ b/i18n/pt/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Geral
+parent: Aviso legal
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# Geral
+{: .no_toc }
+
+A lista de versões, adicionar uma, e ativar a que os utilizadores aceitam
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A lista
+
+A partir da 7.3.0, **Definições > Acesso > Aviso legal** é uma lista das versões do aviso legal, uma por cada texto tal como foi aceite:
+
+| Coluna | Significado |
+|---|---|
+| **Ativada** | Se esta é a versão que os utilizadores aceitam; no máximo uma está ativada |
+| **Versão** | O seu número, contado a partir de 1 |
+| **Título** | O título da sua caixa de diálogo |
+| **Publicado por** | Quem a adicionou |
+| **Publicado** | Quando |
+| **Aceitações** | Quantos utilizadores a aceitaram |
+
+Um clique numa linha, ou **Editar** no menu da sua linha, abre a [página da versão](versions.html). O menu tem também **Ativar** ou **Desativar**, e **Eliminar**.
+
+---
+
+## Adicionar uma versão
+
+**Adicionar aviso** abre uma caixa de diálogo para uma versão nova, com o número seguinte, que não fica ativada até a ativar:
+
+| Campo | Significado |
+|---|---|
+| **Título** | O título da caixa de diálogo, como Termos de utilização |
+| **Texto** | Aquilo com que os utilizadores concordam, no máximo 20000 caracteres. Texto simples: as quebras de linha são mantidas. |
+| **Caixa** | O que os utilizadores marcam antes de poderem aceitar, de início "Li e aceito estes termos." |
+
+Os três são obrigatórios. A versão ativada até então continua a ser a que os utilizadores aceitam, por isso um texto novo pode ser preparado com antecedência.
+
+---
+
+## Ativar uma versão
+
+**Ativar** no menu de uma linha, ou o interruptor **Ativada** na página da versão, faz dessa versão a que os utilizadores aceitam e desliga as
+outras.
+
+Os utilizadores que já aceitaram essa versão não voltam a ser solicitados, por isso uma versão anterior pode ser ativada de novo sem pedir a todos.
+**Desativar** na versão ativada desliga o aviso legal até uma versão ser ativada de novo; as versões e as aceitações mantêm-se.
+Eliminar uma versão elimina também as suas aceitações, e eliminar a ativada desliga o aviso legal.
diff --git a/i18n/pt/_configure/disclaimer/versions.md b/i18n/pt/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..01e9fde
--- /dev/null
+++ b/i18n/pt/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Versões
+parent: Aviso legal
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# Versões
+{: .no_toc }
+
+A página de uma versão, e alterar o seu texto como correção ou para todos de novo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A página de uma versão
+
+A partir da 7.3.0, cada versão tem uma página própria, em `/settings/disclaimer/<version>`, com dois separadores:
+
+| Separador | O que contém |
+|---|---|
+| **Detalhes** | O título, o texto e o texto da caixa, e o interruptor **Ativada**, que é guardado de imediato |
+| **Aceitações** | Quem aceitou esta versão, consulte [Aceitações](acceptances.html) |
+
+**Pré-visualizar** mostra a caixa de diálogo tal como os utilizadores a verão, e **Eliminar** remove a versão com as suas aceitações. A caixa de pesquisa acima dos
+separadores pesquisa em ambos ao mesmo tempo: os campos correspondentes em **Detalhes** e as linhas correspondentes em **Aceitações**.
+
+---
+
+## Alterar o texto
+
+**Guardar** num título, texto ou texto da caixa alterado que os utilizadores já aceitaram pergunta **Pedir de novo a todos?**:
+
+| Resposta | O que acontece |
+|---|---|
+| **Pedir de novo a todos** | As aceitações desta versão são apagadas, e todos os utilizadores a aceitam de novo no seu pedido seguinte |
+| **Manter como correção** | O texto é reescrito, por exemplo por causa de uma gralha, e as aceitações continuam a contar: ninguém é solicitado de novo |
+
+Uma versão que ninguém aceitou ainda é guardada sem perguntar. Para manter o texto aceite, [adicione uma versão nova](general.html#adding-a-version) e ative-a.
diff --git a/i18n/pt/_configure/notification-channels.md b/i18n/pt/_configure/notification-channels.md
new file mode 100644
index 0000000..1f0f0f5
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Canais de notificação
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# Canais de notificação
+{: .no_toc }
+
+Envie pedidos de aprovação e notificações de tarefas por email, para o Slack, o Microsoft Teams, o Telegram ou qualquer webhook
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: adicione os servidores de correio e os canais de chat para onde os formulários enviam as suas notificações e aprovações.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Email](notification-channels/mail.html) | Servidores SMTP, o predefinido, e o seu acesso |
+| [Slack e Microsoft Teams](notification-channels/slack-and-teams.html) | Um webhook de canal do Slack ou do Teams |
+| [Telegram](notification-channels/telegram.html) | Um bot que publica num chat do Telegram |
+| [Webhook](notification-channels/webhook.html) | Um pedido JSON para qualquer endpoint HTTP |
+| [Usar canais num formulário](notification-channels/in-a-form.html) | Nomear canais nas notificações e aprovações |
+| [Testar um canal](notification-channels/testing.html) | Enviar teste, e o que prova |
+
+
+---
+
+## Como funciona
+
+Um **canal de notificação** é um sítio para onde vão as notificações, adicionado em **Ligações > Notificações**. Cada canal tem
+um destes tipos:
+
+| Tipo | O que envia |
+|---|---|
+| Email | Email através de um servidor SMTP: pedidos de aprovação e notificações de tarefas. |
+| Slack | Uma mensagem num canal do Slack, através do seu webhook de entrada, com um botão para a tarefa. |
+| Microsoft Teams | Um cartão num canal do Teams, através de um webhook do Workflows, com um botão para a tarefa. |
+| Telegram | Uma mensagem de um bot num chat do Telegram, com uma ligação para a tarefa. |
+| Webhook | Um pedido JSON para qualquer endpoint HTTP, construído a partir de um template. |
+
+Um formulário nomeia os seus canais nas suas [notificações](forms/notifications.html) e na sua [aprovação](forms/approval.html),
+com `channels:`. Uma notificação que não pode ser enviada fica escrita no registo; nunca faz falhar a tarefa nem a aprovação.
+
+---
+
+## A página de notificações
+
+A página em **Ligações > Notificações** lista todos os canais com estas colunas:
+
+| Coluna | Significado |
+|---|---|
+| Ativado | Se lhe são enviadas notificações, consulte [Usar canais num formulário](notification-channels/in-a-form.html). |
+| Nome | Como os formulários se referem a ele em `channels:`. |
+| Tipo | Email, Slack, Microsoft Teams, Telegram ou Webhook. O canal de email predefinido mostra uma pílula **Predefinido** depois do seu tipo. |
+| Descrição | Para que serve o canal. |
+
+**Adicionar canal de notificação** abre uma caixa de diálogo: **Canal** (nome e descrição), **Tipo**, e depois os passos do tipo
+escolhido. O tipo é definido quando o canal é criado e não muda. Uma linha abre a página própria do canal, com os mesmos passos como
+separadores depois de **Detalhes**, e **Enviar teste**, **Eliminar** e **Guardar** no canto superior direito. O menu da linha oferece
+**Editar**, **Ativar** ou **Desativar** (conforme o caso), **Tornar predefinido** (email), **Enviar teste** e **Eliminar**.
+
+O separador **Detalhes** da página de um canal contém o interruptor **Ativado**, que é guardado de imediato, e no email o interruptor **Predefinido**,
+que é guardado com **Guardar**.
+
+Um utilizador que abre estas páginas com `showConnectionsSettings` mas sem a função admin não pode escolher uma credencial que só
+um admin pode nomear, consulte [Quem pode alterar uma credencial](credentials.html#who-may-change-a-credential). Quando um utilizador destes altera
+para onde um canal envia (o url de um webhook ou a sua verificação de certificado, o endereço da Bot API do Telegram), o canal perde a
+credencial que nomeava, a menos que escolha uma na mesma alteração.
+
+Um canal declarado no [config seed](seed/) é só de leitura nesta página, e continua a poder ser testado.
+
diff --git a/i18n/pt/_configure/notification-channels/in-a-form.md b/i18n/pt/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..39396d5
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Usar canais num formulário
+parent: Canais de notificação
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# Usar canais num formulário
+{: .no_toc }
+
+Nomear canais nas notificações e aprovações
+{: .fs-6 .fw-300 }
+
+Os formulários nomeiam os canais pelo seu nome, em `notifications` para o estado e os eventos da tarefa, e em `approval`:
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- Os canais de chat e de webhook recebem uma mensagem curta (o formulário, a tarefa, o que aconteceu) com uma ligação para a tarefa; numa
+  aprovação, a página da tarefa é onde ela é aprovada ou rejeitada.
+- Um canal de **email** na lista envia o email habitual para `recipients` (os endereços de `notifications` de uma aprovação) através
+  desse servidor em vez do predefinido.
+- Um nome que não existe, ou um canal de chat ou de webhook que está desligado, é ignorado e isso fica no registo.
+- Um canal de **email** que está desligado não é ignorado: o email segue em vez disso pelo canal de email predefinido, e o
+  registo indica-o.
diff --git a/i18n/pt/_configure/notification-channels/mail.md b/i18n/pt/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..f424e2e
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Email
+parent: Canais de notificação
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# Email
+{: .no_toc }
+
+Servidores SMTP, o predefinido, e o seu acesso
+{: .fs-6 .fw-300 }
+
+Um canal de email é um servidor SMTP. Pode manter vários; o marcado como **Predefinido** é o servidor com que a aplicação envia o seu
+email quando um formulário não nomeia nenhum canal de email. O primeiro canal de email torna-se o predefinido, e **Tornar predefinido** muda-o.
+
+| Passo | Campo | Significado |
+|---|---|---|
+| Credenciais | Credencial | Obrigatória. Uma credencial **smtp** de [Ligações > Credenciais](../credentials.html): o servidor de correio, a sua porta e TLS, e o acesso. Para um relay sem acesso, uma credencial smtp sem utilizador. |
+| Remetente | Remetente | O endereço do remetente que os destinatários veem. |
+
+O interruptor **Predefinido** no separador **Detalhes** da página de um canal de email torna-o o predefinido, tal como **Tornar predefinido**.
+As definições de email do config seed são usadas enquanto nenhum canal de email for o predefinido, ou enquanto o predefinido estiver desligado.
diff --git a/i18n/pt/_configure/notification-channels/slack-and-teams.md b/i18n/pt/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..a2b26d5
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack e Microsoft Teams
+parent: Canais de notificação
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack e Microsoft Teams
+{: .no_toc }
+
+Um webhook de canal do Slack ou do Teams
+{: .fs-6 .fw-300 }
+
+Os canais do Slack e do Teams só precisam do endereço do webhook do canal:
+
+| Tipo | Endereço do webhook |
+|---|---|
+| Slack | O webhook de entrada do canal (Slack app > Incoming Webhooks). |
+| Microsoft Teams | O webhook do Workflows do canal ("post to a channel when a webhook request is received"). |
+
+O endereço é o segredo que permite a qualquer pessoa publicar no canal: é guardado cifrado e nunca volta a ser mostrado depois de guardado.
diff --git a/i18n/pt/_configure/notification-channels/telegram.md b/i18n/pt/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..ce2235d
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: Canais de notificação
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+Um bot que publica num chat do Telegram
+{: .fs-6 .fw-300 }
+
+Um canal do Telegram é um bot que publica num chat. O seu passo **Credenciais** contém o **Token do bot**, o seu passo **Bot** o resto:
+
+| Campo | Significado |
+|---|---|
+| Token do bot | Uma credencial **api** de [Ligações > Credenciais](../credentials.html) cuja palavra-passe é o token do bot obtido no BotFather. |
+| Id do chat | O chat, grupo ou canal onde o bot publica; um número negativo para um grupo ou um canal. |
+| Endereço da Bot API | Um servidor Bot API próprio; vazio para `api.telegram.org`. |
diff --git a/i18n/pt/_configure/notification-channels/testing.md b/i18n/pt/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..62cf71b
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Testar um canal
+parent: Canais de notificação
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# Testar um canal
+{: .no_toc }
+
+Enviar teste, e o que prova
+{: .fs-6 .fw-300 }
+
+**Enviar teste** envia uma notificação de teste através do canal tal como está guardado, por isso guarde primeiro as suas alterações. Também funciona num canal
+que está desligado. Num canal de email,
+a caixa de diálogo pede o endereço para onde enviar; os outros publicam no seu próprio canal. A caixa de diálogo mostra se funcionou,
+e o motivo quando não funcionou.
diff --git a/i18n/pt/_configure/notification-channels/webhook.md b/i18n/pt/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..d36fa2c
--- /dev/null
+++ b/i18n/pt/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: Canais de notificação
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+Um pedido JSON para qualquer endpoint HTTP
+{: .fs-6 .fw-300 }
+
+Um canal de webhook envia um pedido JSON para qualquer endpoint HTTP. O seu passo **Endpoint** diz para onde e como, e o seu passo
+**Credenciais** contém o **Token bearer**:
+
+| Campo | Significado |
+|---|---|
+| Url | O endereço para onde o pedido é enviado. |
+| Método | `POST` (predefinição) ou `PUT`. |
+| Token bearer | Uma credencial **api** de [Ligações > Credenciais](../credentials.html) cuja palavra-passe é enviada como `Authorization: Bearer <password>`. Vazio: sem token. |
+| Verificar o certificado TLS | Ligado por predefinição; desligue-o só para um endpoint com um certificado autoassinado. |
+
+{% raw %}
+O seu passo **Conteúdo** contém **Cabeçalhos**, cabeçalhos adicionais como um objeto JSON, por exemplo `{ "X-Source": "ansibleforms" }`, e o
+**Conteúdo**, o template JSON do corpo. Estes marcadores são preenchidos:
+
+| Marcador | Valor |
+|---|---|
+| `{{title}}` | O título da notificação |
+| `{{text}}` | O seu texto |
+| `{{status}}` | O estado da tarefa |
+| `{{event}}` | O evento da tarefa |
+| `{{jobId}}` | O id da tarefa |
+| `{{form}}` | O nome do formulário |
+| `{{user}}` | O utilizador que iniciou a tarefa |
+| `{{link}}` | A ligação para a tarefa |
+
+Um marcador que é uma string JSON inteira (`"{{text}}"`) é substituído pelo valor como JSON; dentro de uma string mais longa, o seu
+texto é escapado para JSON. Um marcador desconhecido fica como está escrito. Um conteúdo vazio envia este template:
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/pt/_configure/production/backups.md b/i18n/pt/_configure/production/backups.md
new file mode 100644
index 0000000..bb0ce79
--- /dev/null
+++ b/i18n/pt/_configure/production/backups.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: Cópias de segurança
+parent: Em produção
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# Cópias de segurança
+{: .no_toc }
+
+Cópias de segurança noturnas, o que contêm, restauros, e o que mais guardar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Cópias de segurança noturnas
+
+O AnsibleForms faz uma cópia de segurança de si próprio todas as noites à meia-noite, no fuso horário de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ)
+(UTC por predefinição). Estas definições controlam-na:
+
+| Variável | Predefinição | Significado |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | Onde são escritas as cópias de segurança, cada uma numa pasta com data e hora |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | Quantas cópias de segurança noturnas se mantêm, `0` mantém-nas todas |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | O comando que faz o dump da base de dados |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | O comando que reproduz um dump no restauro |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | Quanto tempo podem correr o dump e o restauro |
+
+Os utilizadores com a opção de função `allowBackupOps` também podem fazer uma cópia de segurança a qualquer momento na página **Cópias de segurança**. Só as cópias de segurança
+noturnas são removidas pela retenção, e só as cópias com um dump utilizável contam para ela, por isso uma série de noites falhadas
+nunca empurra para fora a última cópia boa.
+
+Antes de uma atualização alterar a base de dados, o worker faz primeiro uma cópia de segurança normal, uma vez por versão, chamada *Before the upgrade to
+&lt;version&gt;*. Aparece na página **Cópias de segurança** e nunca é removida pela retenção noturna. Se falhar (sem ferramenta de dump,
+`BACKUP_PATH` sem permissão de escrita), a atualização para e diz porquê, para que a aplicação nunca arranque sobre uma base de dados meio atualizada.
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` atualiza sem cópia de segurança.
+
+Os comandos podem ser wrappers como `docker exec <container> mysqldump`, se a sua primeira palavra existir localmente. A partir da 7.3.0 correm
+sem shell: as aspas e `$NAME` do ambiente do comando funcionam, mas `;`, `|`, `&&`, `>` e `<` são recusados.
+
+---
+
+## Permissões na base de dados
+
+O dump corre como [`DB_USER`](../customization/server.html#env_DB_USER), e não precisa de mais permissões do que as que a própria aplicação precisa:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+O dump é feito com `--no-tablespaces`, por isso não é necessária a permissão `PROCESS` ao nível do servidor, e salta as tabelas
+que descrevem os processos em execução (`nodes`, `cache_epochs`, `designer_lock`, `runner_leases`). O restauro reprodu-lo com o mesmo utilizador.
+A página **Estado** mostra um aviso na sua verificação **Utilizador da base de dados** quando o utilizador tem permissões em todas as bases de dados, como tem o `root`.
+
+---
+
+## O que contém uma cópia de segurança
+
+Cada cópia de segurança é uma pasta em `BACKUP_PATH`, com o nome da sua data e hora UTC (`YYYYMMDDHHmmss`), que contém:
+
+| Ficheiro | Conteúdo |
+|------|---------|
+| `ansibleforms.sql` | O dump da base de dados `AnsibleForms`: utilizadores, grupos, credenciais, tarefas, definições, o registo de auditoria |
+| `config.yaml` | O ficheiro em [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| `forms/` | A pasta em [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| `managed.env` | O ficheiro de ambiente que as páginas de definições escrevem, sem `ENCRYPTION_SECRET`, `ENCRYPTION_SECRET_PREVIOUS` e `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | A descrição da cópia de segurança |
+
+Uma cópia de segurança cujo dump falha é removida de novo e registada como erro. A página **Estado** avisa quando não há nenhuma cópia de segurança,
+quando a mais recente tem mais de dois dias, ou quando não tem um dump utilizável, e verifica que a ferramenta de dump existe.
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) mantém por sua vez os pontos de restauro do designer (60 dias por predefinição).
+
+---
+
+## Restaurar uma cópia de segurança
+
+Restaure a partir da [página **Cópias de segurança**](../gui/administration.html#restore), com **Criar uma nova cópia de segurança antes de restaurar** marcado. Um restauro:
+
+* reproduz `ansibleforms.sql`, que substitui toda a base de dados; a partir da 7.3.0, uma cópia de segurança de uma versão anterior é depois atualizada
+  de novo, como no arranque de uma versão nova, e um patch que falhe é reportado
+* volta a copiar o `config.yaml`, e substitui a pasta `forms/` pela da cópia de segurança: a partir da 7.3.0 os formulários que não estão na cópia são
+  removidos em vez de mantidos, as ligações e o modo da pasta mantêm-se, e uma cópia falhada repõe a pasta
+* **não** restaura o `managed.env`, porque descreve o host de onde veio a cópia de segurança. O botão **Restaurar ambiente**
+  repõe-no a pedido, guarda o ficheiro atual como `.env.bak`, e precisa de um reinício.
+
+Uma cópia de segurança sem um dump utilizável é recusada; depois de um restauro interrompido, corrija a causa e restaure de novo.
+
+Num host novo, defina o mesmo `ENCRYPTION_SECRET` antes de restaurar, ou as credenciais guardadas não poderão ser decifradas.
+
+---
+
+## O que mais guardar
+
+A cópia de segurança noturna cobre a base de dados, a configuração e os formulários, mas nada mais da pasta persistente:
+
+* **`ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET`** : nunca numa cópia de segurança, por desenho. Guarde-os no seu gestor de segredos;
+  sem o segredo de cifragem, um dump da base de dados é inútil para as credenciais.
+* **as próprias cópias de segurança** : ficam no mesmo volume que a instância. Copie `BACKUP_PATH` para outro host.
+* **o resto da pasta persistente** : playbooks, ficheiros carregados, ficheiros de variáveis, repositórios clonados, certificados e registos.
+  Com o projeto docker-compose, faça cópia de segurança de toda a pasta `data/`, que contém também a chave SSH, as funções
+  personalizadas e os roles e collections do Ansible.
+
+O conteúdo que vem do git (repositórios, formulários num repositório) pode ser clonado de novo, por isso a sua cópia de segurança importa menos.
diff --git a/i18n/pt/_configure/production/index.md b/i18n/pt/_configure/production/index.md
new file mode 100644
index 0000000..6264d7e
--- /dev/null
+++ b/i18n/pt/_configure/production/index.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Em produção
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# Em produção
+{: .no_toc }
+
+Publique, faça cópias de segurança e monitorize uma instância de que as pessoas dependem
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Antes de entrar em produção
+
+As predefinições põem uma instância a funcionar rapidamente, mas várias delas servem apenas para uma primeira experiência. O AnsibleForms
+regista um aviso `[SECURITY]` no arranque quando `ENCRYPTION_SECRET` ou `ACCESS_TOKEN_SECRET` não estão definidas, e a
+página **Estado** informa sobre as cópias de segurança, as definições de retenção e o sanitizador de expressões.
+
+---
+
+## Lista de verificação para produção
+
+Percorra estes itens uma vez antes de os utilizadores dependerem da instância, e de novo depois de uma atualização importante:
+
+| Item | O que fazer | Detalhes |
+|------|------------|---------|
+| Palavra-passe do admin | Altere a palavra-passe da conta de admin local | [Endurecimento](../security/hardening.html#the-admin-account) |
+| Segredo de cifragem | Defina [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) antes de guardar qualquer credencial | [Segredos e cifragem](../security/secrets.html#the-two-master-secrets) |
+| Segredo dos tokens | Defina [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET), para que as sessões sobrevivam a um reinício | [Segredos e cifragem](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | Termine o TLS com o seu próprio certificado, não com o de exemplo | [HTTPS](../security/https.html) |
+| Reverse proxy | Publique a instância atrás de um proxy, opcionalmente em [`BASE_URL`](../customization/server.html#env_BASE_URL) | [Reverse proxy](reverse-proxy.html) |
+| Endpoint do esquema | Defina [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) como `0` quando o esquema já existir | [Endurecimento](../security/hardening.html#the-database) |
+| Chamadas de saída | Restrinja as expressões REST com [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) | [Endurecimento](../security/hardening.html#expressions-and-outbound-calls) |
+| Funcionalidades opcionais | Deixe o MCP e o assistente de chat desligados a menos que os use | [Endurecimento](../security/hardening.html#optional-features) |
+| Cópias de segurança | Verifique que a cópia de segurança noturna funciona, e copie-a para fora do host | [Cópias de segurança](backups.html) |
+| Retenção | Decida durante quanto tempo se mantêm as tarefas e as entradas de auditoria | [Registos](logs.html#retention) |
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria; a proteção da instância é tratada em [Segurança](../security/):
+
+| Página | O que abrange |
+|---|---|
+| [Reverse proxy](reverse-proxy.html) | Publicar o AnsibleForms atrás de Nginx, Traefik ou Apache, na raiz ou num subcaminho |
+| [Cópias de segurança](backups.html) | Cópias de segurança noturnas, o que contêm, restauros, e o que mais guardar |
+| [Registos](logs.html) | Ficheiros de registo, syslog, o registo de auditoria, e a retenção de tarefas e entradas de auditoria |
+| [Escalabilidade](scaling.html) | Vários nós da aplicação com um worker; o RTE tem a sua própria secção, [Ambientes de execução](../rte/) |
+| [Monitorização](monitoring.html) | Sondas de saúde, métricas do Prometheus e a página Estado |
diff --git a/i18n/pt/_configure/production/logs.md b/i18n/pt/_configure/production/logs.md
new file mode 100644
index 0000000..ec3575c
--- /dev/null
+++ b/i18n/pt/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: Registos
+parent: Em produção
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# Registos
+{: .no_toc }
+
+Ficheiros de registo, syslog, o registo de auditoria, e durante quanto tempo se mantêm as tarefas e as entradas de auditoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ficheiros de registo
+
+O AnsibleForms escreve dois registos com rotação diária em [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+(`%PERSISTENT_FOLDER%/logs`), comprime os dias anteriores e mantém-nos durante [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS)
+(30 por predefinição, `0` mantém todos os ficheiros; uma alteração na página de definições aplica-se de imediato):
+
+* `ansibleforms.<date>.log` : tudo a partir de [`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL)
+* `ansibleforms.errors.<date>.log` : só erros
+
+A consola, lida com `docker logs` ou `kubectl logs`, tem o seu próprio nível,
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL). Ambos são `notice` por predefinição, o adequado para
+produção; use `info` ou `debug` só enquanto investiga um problema, e deixe
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) desligada. Os níveis podem ser alterados
+nas páginas de definições sem reiniciar, e a página **Registo do servidor** mostra o registo aos utilizadores com a opção `showLogs`.
+
+---
+
+## Linhas JSON
+
+Para um coletor de registos como Loki, ELK ou Splunk, defina [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) como `json`. Cada
+linha, na consola e nos ficheiros, passa então a ser um objeto JSON em vez de `<time> <level>: <message>`:
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| Campo | Conteúdo |
+|-------|---------|
+| `time` | A hora, em ISO 8601 UTC |
+| `level` | O nível de registo |
+| `message` | A mensagem |
+| `requestId` | O pedido a que a linha pertence, quando foi escrita enquanto servia um |
+| `role` | A função do processo, [`AF_ROLE`](scaling.html), ou `all` quando não está definida |
+| `host` | O nome do host da máquina ou do contentor onde o processo corre |
+
+Cada pedido recebe um id: o cabeçalho `X-Request-Id` que um reverse proxy enviou, ou um novo. É devolvido no cabeçalho
+`X-Request-Id` da resposta e incluído em cada linha escrita enquanto o pedido é servido (como `[req <id>]` nas linhas de texto),
+para que um pedido possa ser seguido pelo registo e associado ao do proxy. Uma alteração na página de definições aplica-se de imediato.
+
+---
+
+## Syslog
+
+Os servidores syslog gerem-se em **Definições > Ligações > Syslog**, para que um servidor syslog ou um SIEM receba o registo à medida que é escrito.
+Pode adicionar vários servidores, e cada um tem as suas próprias definições:
+
+| Definição | O que faz |
+|---------|--------------|
+| Ativado | Só os servidores ativados recebem algo, por isso um servidor pode ser pausado sem o eliminar; **Ativar** e **Desativar** no menu da sua linha também o alternam |
+| Protocolo | `udp4` (predefinição), `udp6`, `tcp4`, `tcp6`, `tls4`, `tls6`, `unix` ou `unix-connect` |
+| Host e porta | O servidor para onde enviar, porta `514` por predefinição; um protocolo `unix` recebe em vez disso um caminho de socket |
+| Recebe | O registo do servidor, as entradas de auditoria, ou ambos (a predefinição para um servidor novo) |
+| Nível | O nível mais baixo do registo do servidor que recebe, `info` por predefinição; as entradas de auditoria são sempre enviadas |
+| Formato | `BSD` (RFC 3164, a predefinição) ou `RFC 5424` |
+
+Uma alteração aplica-se em todos os nós sem reiniciar, e a página do servidor tem um botão que lhe envia uma mensagem de teste.
+Um servidor que não está acessível nunca para a aplicação: o erro é escrito na consola.
+
+A partir da 7.3.0, os servidores syslog precisam dos direitos completos de definições, a opção de função [`showSettings`](../config/roles.html#role-options):
+o acesso só às definições de ligações não chega, já que um servidor syslog recebe o registo do servidor e as entradas de auditoria.
+
+As variáveis `LOG_SYSLOG_*` de versões anteriores estão obsoletas desde a 7. O primeiro arranque que encontra
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST) definida importa-as uma vez como o servidor `syslog`,
+que recebe o registo do servidor como antes, e a partir daí ignora-as. Remova-as do ambiente depois desse primeiro
+arranque, e gira o servidor na página de definições.
+
+---
+
+## Registo de auditoria
+
+A página **Registo de auditoria** (em **Definições > Registos**) regista quem alterou o quê, algo a que os ficheiros de registo não respondem bem.
+Regista:
+
+* todas as alterações feitas através da API (`POST`, `PUT`, `PATCH`, `DELETE`), incluindo tentativas recusadas com 401 ou 403
+* inícios de sessão, com o nome de utilizador tentado
+* eventos da própria aplicação, como cópias de segurança noturnas, cópias de segurança removidas, tarefas purgadas e aplicações do config seed
+
+Cada entrada tem a sua hora, o ator (um utilizador, ou a própria aplicação nas suas próprias tarefas), o endereço IP do cliente,
+a ação, o seu alvo e o seu resultado: `success`, `failure` ou `denied`. A página filtra pelo ator, pela ação e
+pelo resultado, e os utilizadores com a opção de função `showSettings` podem abri-la.
+
+O endereço IP é o que o AnsibleForms vê, que é o do proxy quando corre atrás de um. Defina
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) com o número ou os endereços dos seus proxies, e o AnsibleForms
+regista em vez disso o endereço do cliente que o proxy indica em `X-Forwarded-For`; consulte [Reverse proxy](reverse-proxy.html).
+
+Para manter o registo de auditoria fora da instância, para um SIEM, adicione um servidor syslog que receba as entradas de auditoria (consulte
+[Syslog](#syslog)). Cada entrada é enviada no momento em que acontece, como uma linha `audit {...}` com a entrada em JSON, seja qual for o
+nível do servidor. A cópia no syslog não é removida pela retenção abaixo, nem substituída por um restauro da base de dados.
+
+---
+
+## Retenção
+
+Duas tarefas diárias com uma definição impedem a base de dados de crescer sem limite:
+
+| Variável | Predefinição | Corre às | Remove |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | As entradas de auditoria mais antigas do que isto |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0` (manter tudo) | 2:30 | As tarefas terminadas mais antigas do que isto, com a sua saída |
+
+`0` mantém tudo em ambos. Mais duas tarefas diárias não têm definição: às 3:00 são removidos os refresh tokens guardados com mais de 30 dias e
+as revogações de tokens expiradas, e às 4:00 as [tarefas guardadas](../jobs/stored-jobs.html) cuja validade já passou.
+As horas estão no fuso horário de [`LOG_TZ`](../customization/logging.html#env_LOG_TZ), e é o worker que as executa.
+
+A saída das tarefas é normalmente a tabela que mais cresce: a página **Estado** indica o seu tamanho
+e avisa quando passa de 1 GB sem retenção definida. As tarefas em execução e as que aguardam aprovação nunca são removidas.
+Escolha uma retenção de tarefas que corresponda aos seus requisitos de auditoria, e mantenha o registo de auditoria pelo menos durante o mesmo tempo.
diff --git a/i18n/pt/_configure/production/monitoring.md b/i18n/pt/_configure/production/monitoring.md
new file mode 100644
index 0000000..371171e
--- /dev/null
+++ b/i18n/pt/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: Monitorização
+parent: Em produção
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# Monitorização
+{: .no_toc }
+
+Sondas de saúde para um balanceador de carga ou para o Kubernetes, métricas do Prometheus, e a página Estado
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Sondas de saúde
+
+Dois endpoints dizem a um balanceador de carga, a um healthcheck de contentor ou ao Kubernetes se um processo pode receber tráfego.
+Nenhum precisa de início de sessão, e nenhum devolve nada sobre a configuração:
+
+| Endpoint | Responde | Use-o para |
+|----------|---------|------------|
+| `/api/v2/live` | `200` com `{"status":"live"}` enquanto o processo estiver a correr | Uma sonda de liveness: reinicie o processo quando deixar de responder |
+| `/api/v2/ready` | `200` com `{"status":"ready"}`, ou `503` com `{"status":"not ready","reason":"..."}` | Uma sonda de readiness: envie tráfego só para processos prontos |
+
+Um processo está pronto quando se verifica tudo isto:
+
+* não está a encerrar (`stopping`)
+* a base de dados responde (`database unreachable`)
+* o esquema existe (`schema not provisioned`) e está completo, com todas as tabelas, colunas e índices desta versão
+  (`schema not upgraded`); esta última verificação fica em cache durante 30 segundos, por isso uma sonda a cada poucos segundos continua barata
+
+Com um [`BASE_URL`](../customization/server.html#env_BASE_URL), os caminhos começam por ele, por exemplo
+`/ansibleforms/api/v2/ready`. Um ambiente de execução (RTE) responde às mesmas sondas em `/live` e `/ready`, sem a
+verificação de esquema completo; não está pronto enquanto esvazia as suas tarefas no encerramento, para que não lhe seja enviada nenhuma tarefa nova. Um RTE de saída
+também não está pronto (`not connected to the app`) até o seu socket para a aplicação estar aberto.
+Um processo iniciado com `AF_ROLE=worker` não tem interface web: responde só a `/api/v2/version` e `/health` para o
+healthcheck do seu contentor. Consulte [Escalabilidade](scaling.html) para as funções.
+
+---
+
+## Métricas do Prometheus
+
+Defina [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) com uma string aleatória longa para servir métricas do Prometheus.
+Um processo que serve a aplicação web responde em `/api/v2/metrics`, um RTE em `/metrics`:
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+Sem `METRICS_TOKEN` os endpoints respondem `404`, como se não existissem, e um pedido sem o cabeçalho
+`Authorization: Bearer <token>` correto recebe `401`. Cada processo reporta os seus próprios valores, por isso recolha cada um:
+
+| Métrica | O que mede |
+|--------|------------------|
+| `af_process_*`, `af_nodejs_*` | O processo: CPU, memória, atraso do event loop, recolha de lixo |
+| `af_http_requests_total{route,method,status}` | Os pedidos servidos |
+| `af_http_request_duration_seconds{route}` | Quanto tempo demoraram |
+| `af_jobs{status}` | Tarefas em execução (`running`) ou a aguardar aprovação (`approve`) neste momento |
+| `af_jobs_ended_24h{status}` | Tarefas que terminaram nas últimas 24 horas, por estado |
+| `af_nodes{role,alive}` | Os processos registados na base de dados, por função, vivos ou não |
+| `af_login_failures_total`, `af_login_lockouts_total` | Inícios de sessão falhados e bloqueios de conta |
+| `af_rte_running_jobs`, `af_rte_max_jobs` | Num RTE: os playbooks que corre agora, e quantos pode correr ao mesmo tempo |
+| `af_rte_socket_connected` | Num RTE em modo socket: `1` enquanto o seu socket para a aplicação está aberto, `0` quando não está |
+
+Os valores das tarefas e dos nós são lidos da base de dados em cada recolha. Quando a base de dados não responde ficam
+de fora, e a recolha continua a ter sucesso com as outras métricas.
+
+---
+
+## A página Estado
+
+A página **Estado**, em **Definições > Sistema**, mostra aos utilizadores com a opção de função `showSettings` como está a instância.
+Só lê, por isso atualizá-la nunca envia emails nem lança uma tarefa. Tem dois separadores, e o número de problemas aparece na etiqueta do separador **Verificações**.
+
+### Verificações
+
+Cada verificação está verde (saudável), âmbar (requer atenção) ou vermelha (um problema), com os seus detalhes ao expandir a linha:
+
+| Verificação | O que analisa |
+|-------|------------------|
+| Ligação à base de dados | A base de dados responde |
+| Utilizador da base de dados | Âmbar quando o utilizador tem permissões em todas as bases de dados, como o `root`, em vez de só em `AnsibleForms.*` |
+| Esquema da base de dados | Existem todas as tabelas, colunas e índices desta versão, e qual o patch que falhou quando não é o caso |
+| Agendador | Um worker corre as tarefas de sistema, e nenhuma deixou de ser agendada |
+| Nós | Os processos na base de dados, âmbar quando correm versões diferentes |
+| Tarefas | Tarefas em execução e tarefas a aguardar aprovação, âmbar quando uma tarefa está a correr há mais de 24 horas |
+| Ferramentas de cópia de segurança | O comando de dump de [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) existe, e a sua versão |
+| Última cópia de segurança | Âmbar quando não há nenhuma ou a mais recente tem mais de dois dias, vermelho quando não tem um dump utilizável |
+| Bloqueio do designer | Quem tem o bloqueio do designer, âmbar quando está mantido há mais de 8 horas |
+| Repositórios | Vermelho quando um repositório falhou ou não tem working tree em disco |
+| Config seed | O ficheiro do [config seed](../seed/) é legível e válido, e o seu último recarregamento funcionou |
+| Cofres de segredos | Todos os cofres de segredos respondem, âmbar quando o token de um HashiCorp Vault expira em breve |
+| Runners | Todos os runners respondem, âmbar quando não há nenhum ou não há um RTE predefinido |
+| Expressões do servidor | Âmbar quando [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) é `legacy` |
+| Segredos | Âmbar quando `ENCRYPTION_SECRET` é a predefinição pública ou `ACCESS_TOKEN_SECRET` não está definida |
+| LDAP | O servidor LDAP está acessível e o seu certificado TLS é válido, sem iniciar sessão nele |
+| Armazenamento de tarefas | O tamanho das tabelas de tarefas, âmbar acima de 1 GB quando não há retenção de tarefas definida |
+| Pastas com permissão de escrita | Todas as pastas configuradas podem ser escritas |
+| Espaço em disco | O disco que contém as cópias de segurança, âmbar a partir de 85% de uso e vermelho a partir de 95% |
+
+### Informação
+
+Factos sobre a instância que não têm veredicto, as primeiras coisas que se pedem num pedido de suporte: a versão do
+AnsibleForms, o URL base, a versão e o host da base de dados, a origem da configuração, o config seed, as definições de
+retenção, os métodos de autenticação, o servidor do [canal de email](../notification-channels.html) ativo, o nível e o caminho
+do registo, o tempo de atividade, o fuso horário, a versão do Node.js e a plataforma.
+
+A página lê `/api/v2/health`, que precisa de um utilizador com sessão iniciada e `showSettings`. Para um sistema de monitorização, use em vez disso as
+sondas e as métricas acima.
diff --git a/i18n/pt/_configure/production/reverse-proxy.md b/i18n/pt/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..36c50bd
--- /dev/null
+++ b/i18n/pt/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: Reverse proxy
+parent: Em produção
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# Reverse proxy
+{: .no_toc }
+
+Publique o AnsibleForms atrás de Nginx, Traefik ou Apache, na raiz ou num subcaminho
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quando usar um
+
+O AnsibleForms serve a interface, a API REST e o Swagger numa só porta; um reverse proxy à frente permite-lhe:
+
+* servi-lo na porta 443 com um certificado gerido pelas suas ferramentas existentes (ACME, uma CA empresarial)
+* partilhar um nome de host com outras aplicações, publicando o AnsibleForms num subcaminho
+* manter a porta da aplicação e a base de dados fora da rede pública
+
+Um proxy é opcional: a aplicação pode servir HTTPS por si própria, consulte [HTTPS](../security/https.html).
+
+---
+
+## As definições que importam
+
+Só algumas definições afetam o comportamento do AnsibleForms atrás de um proxy:
+
+| Definição | Atrás de um proxy |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | A porta para onde o proxy reencaminha, `8000` por predefinição. O projeto docker-compose define-a como `443`. |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` quando o proxy termina o TLS e chega à aplicação por uma rede privada, `1` para cifrar também esse troço. |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | O subcaminho, por exemplo `/ansibleforms`. Deixe-o em `/` quando a aplicação tem um nome de host próprio. |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | Que proxies podem indicar o endereço do cliente em `X-Forwarded-For`, normalmente `1`. Consulte [Endereços dos clientes](#client-addresses). |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | O maior pedido JSON que a aplicação aceita, 50 MB por predefinição. O proxy tem de permitir pelo menos isto. |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | O maior ficheiro que um campo de carregamento de um formulário aceita, 10 GB por predefinição. O proxy também tem de o permitir, ou os carregamentos falham aí. |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | O maior conjunto de cabeçalhos de pedido que a aplicação aceita, 16 KB por predefinição, a partir da 7.1.0. Consulte [Tamanho dos cabeçalhos do pedido](#request-header-size). |
+| **URL raiz público** | Em **Sistema > Geral**, no separador **Servidor**: o endereço a que os utilizadores chegam, subcaminho incluído. Constrói as ligações nos emails de notificação, nas mensagens dos canais e nos pedidos de aprovação. |
+
+Para o Entra ID ou o OIDC, registe o endereço público como URI de redirecionamento, com o subcaminho de `BASE_URL` se estiver definido.
+
+---
+
+## Servir num subcaminho
+
+`BASE_URL` monta toda a aplicação no subcaminho; o proxy tem de reencaminhar o caminho **sem alterações**.
+Com `BASE_URL=/ansibleforms`:
+
+* a interface, `/api/v2/...` e a interface Swagger são todas servidas em `/ansibleforms/`
+* o `<base href>` da interface é reescrito no arranque, para que os recursos e as chamadas à API se resolvam no subcaminho
+* um pedido para `/` ou para `/ansibleforms` (sem barra final) é redirecionado para `/ansibleforms/`
+
+Mantenha o prefixo: nada de `StripPrefix` no Traefik, nada de URI no `proxy_pass` do Nginx, porque a aplicação conta com ele.
+
+A página **Estado** mostra o URL base em vigor.
+
+---
+
+## Tempos limite, carregamentos e saída em direto
+
+A página de tarefas e os contadores de tarefas sabem das alterações através de um único fluxo de longa duração de server-sent events,
+[`/api/v2/events`](../api/events.html), mantido aberto por navegador. O fluxo envia cabeçalhos que desligam o buffering do proxy
+(`X-Accel-Buffering: no`) e uma linha de keep-alive a cada 15 segundos, por isso o tempo limite de leitura habitual de 60 segundos mantém-no aberto;
+quando um proxy o fecha mesmo assim, o navegador volta a ligar-se sozinho. A saída por baixo de um formulário, logo após um lançamento, é
+lida em vez disso a cada dois segundos. Um lançamento de tarefa regressa assim que a tarefa é criada, por isso um playbook longo não mantém
+um pedido aberto.
+
+Os pedidos que podem demorar são:
+
+* **cópia de segurança e restauro** a partir da página **Cópias de segurança**, que esperam que o comando de dump ou de restauro termine, até
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) (3600 por predefinição)
+* **carregamentos grandes** através de um campo de ficheiro, que transmitem o ficheiro inteiro num só pedido
+* **mensagens de chat**, quando o [assistente de chat](../chat/) está ativado, que esperam pela resposta do fornecedor do modelo
+
+Os proxies muitas vezes dão tempo limite ao fim de 60 segundos e limitam o corpo dos pedidos (o Nginx aceita 1 MB por predefinição). Aumente ambos para
+as rotas do AnsibleForms, como nos exemplos abaixo.
+
+---
+
+## WebSockets dos runners
+
+A partir da 7.3.0, um [Runner de saída](../rte/modes.html#outbound) liga-se à aplicação e mantém um WebSocket aberto em
+`<BASE_URL>/api/v2/rte/socket`. O proxy tem de deixar passar o upgrade, ou o Runner nunca se liga e continua a tentar:
+
+| Proxy | O que o WebSocket precisa |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` e os cabeçalhos `Upgrade` e `Connection`, que o Nginx não reencaminha por predefinição |
+| Traefik | Nada: os WebSockets passam tal como estão |
+| Apache | `upgrade=websocket` na linha `ProxyPass` (2.4.47 e posteriores), ou `mod_proxy_wstunnel` antes disso |
+
+Ambos os lados enviam um ping a cada 20 segundos, por isso o tempo limite de leitura habitual de 60 segundos mantém aberto um socket inativo.
+
+---
+
+## Tamanho dos cabeçalhos do pedido
+
+Cada pedido leva o token de início de sessão no seu cabeçalho `Authorization`, ao lado dos cookies e dos cabeçalhos que o proxy adiciona.
+Tanto o proxy como a aplicação limitam o tamanho dos cabeçalhos do pedido, e recusam um pedido acima do limite antes de o
+AnsibleForms o ver, por isso nada chega ao registo do servidor. As predefinições:
+
+| Componente | Limite | Predefinição | Recusado com |
+|-----------|-------|---------|--------------|
+| AnsibleForms (Node.js) | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE), todos os cabeçalhos juntos | 16384 bytes | 431 |
+| Nginx | `large_client_header_buffers`, por campo de cabeçalho | `4 8k`: 8 KB por campo | 400 |
+| Traefik | `http.maxHeaderBytes` do entry point, todos os cabeçalhos juntos | 1 MB | 431 |
+| HAProxy | `tune.bufsize` na secção `global`, o bloco de cabeçalhos inteiro, menos a reserva de `tune.maxrewrite` (1024 bytes) | 16384 bytes: 15360 bytes de cabeçalhos | 400 |
+| Apache | `LimitRequestFieldSize`, por campo de cabeçalho | 8190 bytes | 400 |
+
+Até à 7.0.3, o token de início de sessão levava todos os grupos de um utilizador de início de sessão único, e podia ultrapassar estes limites, consulte
+[Formulários e tarefas vazios depois de um início de sessão único](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431).
+A partir da 7.1.0 o token mantém-se pequeno, e as predefinições chegam. Quando outra coisa torna os cabeçalhos grandes, como
+cookies de outras aplicações no mesmo domínio ou um gateway de início de sessão único à frente, aumente os limites em conjunto:
+
+* AnsibleForms: `MAX_HTTP_HEADER_SIZE=65536`, ou antes da 7.1.0 `NODE_OPTIONS=--max-http-header-size=65536`; ambos são
+  lidos no arranque, por isso reinicie a aplicação depois de uma alteração
+* Nginx: `large_client_header_buffers 4 32k;` no bloco `http` ou `server`
+* HAProxy: `tune.bufsize 65536` na secção `global`; cada fluxo recebe um buffer desse tamanho, por isso o HAProxy aconselha
+  baixar o `maxconn` global no mesmo fator, e o HTTP/2 precisa de pelo menos os 16384 predefinidos
+* Apache: `LimitRequestFieldSize 32768` na configuração do servidor ou no virtual host
+
+---
+
+## Endereços dos clientes
+
+Atrás de um proxy, todas as ligações vêm do proxy. Sem [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY),
+o registo de auditoria regista o endereço do proxy em todas as ações, e os
+[limites de início de sessão](../security/hardening.html#sign-in-limits-and-passwords) por endereço contam todos os clientes como um só endereço.
+`TRUST_PROXY` diz em que proxies a aplicação pode acreditar quando indicam o cliente em `X-Forwarded-For`:
+
+| Valor | Endereço do cliente |
+|-------|----------------|
+| `0` (predefinição) | O endereço da ligação. `X-Forwarded-For` é ignorado; vazio, `false`, `off` e `no` significam o mesmo. |
+| Um número, ex. `1` | Confia em tantos proxies à frente da aplicação: `1` para um único reverse proxy, `2` para um balanceador de carga à frente de um ingress. |
+| Uma lista, ex. `10.0.0.5,172.16.0.0/12` | Confia nos proxies nestes endereços e intervalos CIDR. Também são aceites os presets `loopback`, `linklocal` e `uniquelocal`. |
+| `true` | Confia em todos os saltos: é usado o endereço mais à esquerda de `X-Forwarded-For`. |
+
+A aplicação percorre `X-Forwarded-For` a partir da direita, salta os proxies de confiança, e fica com o primeiro endereço que
+não é um deles. Use o número exato de proxies, ou os seus endereços:
+
+* `X-Forwarded-For` é um simples cabeçalho de pedido que qualquer cliente pode enviar. Um número demasiado alto, ou `true`, deixa um
+  cliente escolher o endereço que o registo de auditoria regista. `true` só é seguro quando a aplicação só pode ser alcançada através
+  do proxy, e o servidor regista um aviso `[SECURITY]` no arranque quando está definido.
+* O proxy tem de adicionar o endereço de onde recebeu a ligação, como fazem os exemplos abaixo
+  (`$proxy_add_x_forwarded_for` no Nginx; o Traefik e o `mod_proxy` do Apache adicionam-no por predefinição).
+* Um valor inválido é recusado na página de definições; definido no ambiente, é registado como erro no arranque e
+  não se confia em nenhum proxy. Uma alteração guardada na página de definições aplica-se sem reiniciar.
+
+---
+
+## Exemplos
+
+Cada exemplo publica o AnsibleForms em `https://forms.example.com/ansibleforms/`, com o TLS terminado pelo proxy e
+a aplicação a correr com `HTTPS=0`, `PORT=8000`, `BASE_URL=/ansibleforms` e `TRUST_PROXY=1`:
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` não nomeia nenhum URI, por isso o Nginx reencaminha o caminho tal como chegou, prefixo incluído. O bloco `map` vai no
+contexto `http` (um ficheiro em `conf.d/` é incluído aí), e deixa passar o upgrade WebSocket dos Runners:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+Sem subcaminho, use `location /` e deixe `BASE_URL` por definir.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+Labels no serviço `app` do projeto docker-compose, com o Traefik na mesma rede Docker. O serviço
+não publica nenhuma porta própria, o Traefik chega a ele pela rede:
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+Não há middleware `StripPrefix` de propósito. O Traefik define ele próprio os cabeçalhos `X-Forwarded-*` e não limita
+o tamanho do corpo, mas verifique os `respondingTimeouts` do entry point quando as cópias de segurança ou os carregamentos demoram mais do que o seu
+tempo limite de leitura. Sem subcaminho, mantenha só a parte `Host(...)` da regra.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+Precisa de `mod_proxy`, `mod_proxy_http`, `mod_headers`, `mod_ssl`, e do Apache 2.4.47 ou posterior para o `upgrade=websocket` dos Runners.
+Ambos os lados de `ProxyPass` levam o prefixo:
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+Sem subcaminho, faça proxy de `/` para `http://10.0.0.20:8000/` e deixe `BASE_URL` por definir.
+
+</div>
+</div>
+
+Para manter cifrado o troço entre o proxy e a aplicação, corra a aplicação com `HTTPS=1`, aponte o proxy para
+`https://`, e dê à aplicação um certificado em que o proxy confie, consulte [HTTPS](../security/https.html).
diff --git a/i18n/pt/_configure/production/scaling.md b/i18n/pt/_configure/production/scaling.md
new file mode 100644
index 0000000..bfd2148
--- /dev/null
+++ b/i18n/pt/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Escalabilidade
+parent: Em produção
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# Escalabilidade
+{: .no_toc }
+
+O AnsibleForms dividido por vários nós da aplicação e um worker, ao lado de um ou mais RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Funções
+
+Todos os contentores do AnsibleForms correm o mesmo código de servidor, e [`AF_ROLE`](../customization/server.html#env_AF_ROLE) decide o que fazem:
+
+| `AF_ROLE` | Imagem | Corre | Quantos |
+|---|---|---|---|
+| `all` (não definida) | `ansibleforms` | A aplicação web e o worker num só processo: a predefinição | 1 |
+| `app` | `ansibleforms` | A interface web e a API | Tantos quantos quiser, atrás de um balanceador de carga |
+| `worker` | `ansibleforms` | O trabalho em segundo plano: o esquema da base de dados e as suas atualizações, o config seed, os agendamentos, a cópia de segurança noturna, as sincronizações de repositórios e as limpezas | Um a trabalhar; os outros esperam e assumem |
+| `rte` | `ansibleforms-rte-full` (ou `-rte-core`, `-rte-base`) | Os playbooks | Tantos quantos quiser |
+
+A instalação mais pequena é um contentor sem `AF_ROLE` ao lado de um RTE: é o que correm o [projeto Docker Compose](../installation/docker-compose.html)
+e o [Helm chart](../installation/kubernetes.html). Qualquer outro valor de `AF_ROLE` para o processo no seu arranque.
+
+---
+
+## O RTE
+
+O RTE, o ambiente de execução que corre os playbooks, tem a sua própria secção: [Ambientes de execução](../rte/). Abrange como um RTE
+corre uma tarefa, [as suas imagens](../rte/images.html), [como correr um](../rte/run.html), [vários RTE](../rte/several.html) como runners ou
+réplicas, e [um RTE noutro centro de dados](../rte/another-datacenter.html).
+
+---
+
+## Vários nós da aplicação
+
+Para servir mais utilizadores, ou para sobreviver à perda de um nó, divida a aplicação em nós `app` atrás de um balanceador de carga e um `worker`.
+
+### O que os nós partilham
+{: .no_toc }
+
+Os nós entendem-se entre si através da base de dados e de um volume partilhado:
+
+* **A base de dados** : as tarefas, o bloqueio do worker, o bloqueio do designer, a lista de nós, as leases dos runners (que nó da aplicação tem o
+  socket de cada RTE) e os avisos de alteração que mantêm atualizadas as caches de todos os nós. Uma credencial, um runner ou um agendamento editado
+  num nó fica em vigor em todos eles em 5 segundos
+* **O volume persistente** (`/app/dist/persistent`) : formulários, a configuração, repositórios, ficheiros carregados, cópias de segurança e o `.env` gerido.
+  Todos os nós da aplicação e o worker montam o mesmo, em leitura e escrita
+* **A pasta ssh** (`/home/node/.ssh`) : a chave e os hosts conhecidos para git por ssh; o worker cria a chave no seu primeiro arranque
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)** : o mesmo em todos os nós da aplicação, ou um token assinado
+  por um nó é recusado pelo seguinte. Um nó da aplicação recusa-se a arrancar sem ele
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)** : o mesmo em todos os nós da aplicação e no worker, ou uma
+  credencial guardada por um não pode ser lida por outro. Um RTE em modo socket nunca o lê; só um RTE obsoleto em modo base de dados
+  que se regista a si próprio precisa dele
+
+Dê também o mesmo utilizador de base de dados a todos os contentores: um worker em espera só pode terminar a sessão de um que morreu quando é a sua.
+
+### O bloqueio do worker
+{: .no_toc }
+
+Só um worker trabalha de cada vez. Detém o bloqueio de base de dados `ansibleforms_worker`; quando para, a base de dados liberta o bloqueio e um
+worker em espera fica com ele em 10 segundos. Quando o host do worker morre sem se despedir, a base de dados podia manter o bloqueio durante horas,
+por isso um worker em espera termina essa sessão quando nenhum worker escreveu um heartbeat durante dois minutos, e assume.
+
+Um worker que perde o bloqueio para outro para, e o seu contentor reinicia como o que está em espera. Um worker cujo arranque falha também
+para, para nunca manter o bloqueio sem fazer nada. O Galera e a group replication não partilham o bloqueio entre nós da base de dados: aponte todos os
+workers para o mesmo nó da base de dados.
+
+### Tarefas e nós
+{: .no_toc }
+
+Cada contentor dá a si próprio o nome `<role>-<hostname>-<port>`, sem nada a definir, e a página **Estado** lista-os todos com a sua função
+e versão, qual é o worker, e um aviso quando correm versões diferentes.
+
+Uma tarefa a correr num RTE pertence a esse RTE, e continua quando o nó da aplicação que a iniciou desaparece. Qualquer outra tarefa (uma tarefa de template
+no AWX ou noutro runner, uma tarefa de workflow, ou os passos de um formulário multistep obsoleto) pertence ao nó da aplicação que a iniciou. Um contentor que reinicia termina as suas próprias tarefas por acabar, e o
+worker termina as tarefas de um contentor que deixou de responder durante dois minutos, como um pod substituído.
+
+Um `SIGHUP` enviado a qualquer nó volta a aplicar o [config seed](../seed/): um nó da aplicação pede ao worker que o faça.
+
+### Atualizar
+{: .no_toc }
+
+Atualize **primeiro o worker**, depois os nós da aplicação. O worker aplica os patches ao esquema, e um nó da aplicação da versão nova espera até o
+esquema estar atualizado e regista aquilo de que está à espera. Os nós da aplicação atualizados primeiro ficam não prontos até o worker os seguir, enquanto os antigos continuam
+a servir. Os RTE podem seguir a qualquer momento, desde que falem o mesmo contrato.
+
+### Limites
+{: .no_toc }
+
+Algumas coisas ficam presas a um nó:
+
+* **O assistente de chat** mantém as suas conversas na memória de um nó da aplicação: use sticky sessions no balanceador de carga (nginx
+  `ip_hash`), ou um único nó da aplicação
+* **Os registos** ficam em cada contentor. Defina [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) fora do volume partilhado, porque vários
+  processos a rodar o mesmo ficheiro perdem linhas. O visualizador de registos mostra o registo do nó que responde, por isso recolha os registos centralmente
+* **As definições** alteradas nas páginas de definições são escritas no `.env` gerido do volume partilhado e aplicam-se em todos os nós; as que
+  precisam de reinício precisam dele em todos os nós
+
+---
+
+## Exemplo de disposição
+
+O repositório da aplicação tem um ponto de partida completo em [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale):
+
+| Serviço | Imagem | Função |
+|---|---|---|
+| `db` | `mariadb:11` | A base de dados, com um utilizador que só tem permissões no esquema `AnsibleForms` |
+| `app1`, `app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`, atrás do balanceador de carga |
+| `worker1`, `worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`: o segundo espera e assume |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | Corre os playbooks com `RTE_MODE=inbound` e `RTE_FILES=local`: a aplicação liga-se a ele |
+| `lb` | `nginx:stable` | Termina o HTTPS na porta 8443 e distribui os navegadores pelos nós da aplicação com `ip_hash` |
+
+O runner `rte` do RTE e a credencial com que inicia sessão (o seu endereço `http://rte:8000` e `RTE_TOKEN`) estão declarados no
+[config seed](../seed/) `seed.yaml`, que o worker aplica em cada arranque; o RTE não define `RTE_URL` e não é publicado no host.
+
+Os nós da aplicação e os workers partilham um `.env`, com o utilizador da base de dados, `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, `RTE_TOKEN`,
+`CONFIG_SEED_PATH`, `HTTPS=0` atrás do balanceador de carga e um `LOG_PATH` fora do volume partilhado. O RTE não tem `env_file`: recebe
+só `RTE_TOKEN` do `compose.yaml`, por isso não contém nenhuma palavra-passe da base de dados. Os nós da aplicação, os workers e o RTE montam os mesmos
+volumes persistente e ssh:
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/pt/_configure/rte/another-datacenter.md b/i18n/pt/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..3cb09bc
--- /dev/null
+++ b/i18n/pt/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: Outro centro de dados
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# Um RTE noutro centro de dados
+{: .no_toc }
+
+De um host vazio num segundo centro de dados a um RTE de saída a correr o seu primeiro playbook
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+Para administradores: quando os hosts geridos de um segundo centro de dados devem ser alcançados a partir de um RTE nesse centro de dados, e não a partir do primeiro.
+
+{: .note }
+> **O caminho fácil.** O [instalador](../installation/installer.html#a-runner) faz todos os passos abaixo no host do RTE num só comando:
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`, com `--join afj_...` para que seja aprovado de imediato.
+> Este runbook faz o mesmo à mão, com Docker ou Podman, para que possa ver e adaptar cada parte.
+
+---
+
+## Com o que fica
+
+A aplicação, o seu worker e a sua base de dados ficam onde estão, no centro de dados 1. O centro de dados 2 recebe um host que corre um contentor RTE em
+modo de saída ([`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE), consulte [Modos](modes.html#outbound)): liga-se à aplicação por
+HTTPS e mantém um WebSocket aberto, adere como runner próprio, e corre os playbooks dos formulários que o nomeiam contra os hosts geridos
+do centro de dados 2.
+
+| Onde | O que corre lá | Fala com |
+|---|---|---|
+| Centro de dados 1 | Os nós da aplicação, o worker, a base de dados (como hoje) | Nada de novo: recebe o socket do RTE no seu endereço HTTPS habitual |
+| Centro de dados 2, o host do RTE | Docker ou Podman, e o contentor RTE | A aplicação em `APP_URL` por HTTPS, e os hosts geridos do centro de dados 2 |
+
+O RTE não tem credenciais da base de dados nem `ENCRYPTION_SECRET`, só um token próprio. Nada se liga a ele, por isso não precisa de nenhuma porta
+aberta, nenhum nome DNS nem nenhum certificado. A aplicação envia os playbooks e os inventários com cada tarefa (`RTE_FILES=transfer`, a
+predefinição), por isso o RTE não precisa de uma cópia deles nem de disco partilhado.
+
+Todos os comandos abaixo correm num terminal no host do RTE, como um utilizador com `sudo`, salvo indicação em contrário. Demora cerca de 20 minutos,
+a maior parte à espera da imagem.
+
+---
+
+## 0. Antes de começar
+
+Reúna o seguinte:
+
+| O quê | De onde vem |
+|---|---|
+| O endereço da aplicação | `APP_URL`: o endereço que as pessoas abrem num navegador, como `https://forms.example.com`, com o seu caminho base se tiver um |
+| O certificado da aplicação | Assinado por uma CA pública, por uma CA privada (precisa do certificado dela, passo 6), ou autoassinado |
+| Um proxy | O `HTTPS_PROXY` que este centro de dados usa para chegar ao centro de dados 1, se houver |
+| O nome do RTE | O nome do seu runner em **Ligações > Runners**, que os formulários nomeiam com `runner:`, como `rte-dc2`: letras, dígitos e `_ . : @ -` |
+| Um join token | Opcional: um [join token](../runners/registration.html#join-tokens) (`afj_...`) aprova o RTE de imediato. Sem ele, um admin aprova-o (passo 8) |
+| A chave ssh | A chave privada que os playbooks usam para chegar aos hosts geridos, ou o direito de criar uma |
+
+A aplicação tem de correr a 7.3.0 ou posterior. Para criar um join token para este RTE, um admin chama a API uma vez (consulte
+[Join tokens](../runners/registration.html#join-tokens)):
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. Preparar o host
+
+O RTE é um contentor, por isso o host precisa de um motor de contentores e de nada mais: o Node.js, o python e o ansible estão na imagem.
+
+| Necessidade | Porquê |
+|---|---|
+| Linux em **x86_64** (amd64) | As imagens do RTE só são publicadas para amd64 |
+| 2 CPU e 4 GB de memória, ou mais | Um RTE corre até [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks ao mesmo tempo (10), cada um com os seus forks: dimensione-o para eles |
+| 20 GB de disco livre | A imagem `-rte-full` tem cerca de 3,3 GB, mais uma imagem durante as atualizações, os ficheiros das tarefas que a aplicação envia e os ficheiros temporários das tarefas |
+| Docker, ou Podman com podman-compose | Para descarregar e correr a imagem |
+| A hora definida por NTP | As horas das tarefas são comparadas com as da aplicação |
+
+**Docker**, em Ubuntu ou Debian (outras distribuições: [docs.docker.com/engine/install](https://docs.docker.com/engine/install/)):
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**, em RHEL, Rocky ou Alma Linux:
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+Com Podman, escreva `podman` em vez de `docker` e `podman-compose` em vez de `docker compose` em todos os comandos abaixo.
+
+---
+
+## 2. Rede e firewall
+
+O RTE abre ele próprio todas as ligações. Nada lhe chega de fora:
+
+| De | Para | Porta | Porquê |
+|---|---|---|---|
+| O host do RTE | A aplicação, em `APP_URL` (através de `HTTPS_PROXY` se estiver definido) | A porta da aplicação, `443` atrás da maioria dos proxies | O socket por onde passam as tarefas, os seus ficheiros e a sua saída |
+| O host do RTE | Os hosts geridos do centro de dados 2 | ssh (`22`), WinRM, as suas APIs | Os playbooks correm a partir daqui |
+| O host do RTE | `ghcr.io` | `443` | Para descarregar a imagem, a menos que venha do seu próprio registo ou de um ficheiro (passo 4) |
+
+Não abra nenhuma porta de entrada para o RTE. A sua `PORT` (`8000`) serve só `/live`, `/ready` e `/metrics`, para as sondas neste host.
+
+O RTE liga-se a `APP_URL` com `/api/v2/rte/socket` acrescentado, como WebSocket. Um reverse proxy à frente da aplicação tem de deixar passar o upgrade
+nesse caminho (consulte [WebSockets dos runners](../production/reverse-proxy.html#runner-websockets)). Verifique a partir daqui que a aplicação responde:
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. Pastas
+
+Tudo fica em `/opt/af-rte`. O RTE corre como o utilizador `node` (uid 1000), por isso os seus dados pertencem a esse uid:
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| Pasta | No contentor | Contém |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | O spool (`rte-spool`: a saída e o fim de cada tarefa até a aplicação os guardar), os ficheiros das tarefas que a aplicação enviou (`rte-files`), uma CA privada, as bibliotecas python que um playbook instala |
+| `data/ssh/` | `/home/node/.ssh` | A chave ssh e o `known_hosts` dos playbooks |
+| `data/ansible/` | `/etc/ansible/...` | Um `ansible.cfg`, roles e collections seus, montados em vez de incluídos na imagem |
+
+Mantenha `data/` no host: um RTE reiniciado continua a enviar o que a aplicação ainda não tinha guardado, e mantém a sua cache de ficheiros das tarefas.
+
+**Chave ssh.** Copie a chave que os playbooks usam no centro de dados 1, ou crie uma para este centro de dados e dê a sua metade pública aos hosts geridos:
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+Depois dê tudo ao uid 1000, com a chave legível só pelo seu dono:
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. A imagem
+
+Escolha uma das duas.
+
+### Opção A: a imagem oficial
+{: .no_toc }
+
+As imagens publicadas estão no GitHub Container Registry, públicas, sem necessidade de início de sessão (consulte [Imagens](images.html) para as três camadas).
+Use a mesma camada que no centro de dados 1. `:7` acompanha a última versão 7, tal como o `:7` da aplicação:
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Um host sem acesso à internet obtém a imagem a partir de um que tenha:
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+Ou envie-a uma vez para o seu próprio registo (`docker tag` e `docker push`), e use esse nome nos passos seguintes.
+
+### Opção B: a sua própria imagem
+{: .no_toc }
+
+Quando os playbooks do centro de dados 2 precisam de collections ou bibliotecas python que a imagem oficial não tem (as da VMware para o vCenter deste
+centro de dados, por exemplo), construa sobre `ansibleforms-rte-core`:
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+Reconstrua-a a cada nova versão da aplicação (consulte [Construir o seu próprio RTE](images.html#build-your-own-rte)). Com vários hosts RTE, construa
+uma vez e envie para o seu próprio registo. Sem ligação, faça `docker save` e `docker load` da imagem construída como na opção A.
+
+---
+
+## 5. Definições
+
+Um novo [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) próprio, com pelo menos 16 caracteres. É a palavra-passe deste RTE: a aplicação
+guarda-o na credencial RTE do runner, e sela com ele os segredos de cada tarefa.
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| Variável | Significado |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`: o RTE liga-se à aplicação. Sem ela, o RTE arranca no modo base de dados obsoleto |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | O endereço da aplicação, `http://` ou `https://`, com o seu caminho base se houver |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | O nome do seu runner. Não definida: o seu id de nó, `rte-<hostname>-<port>`, que muda com o contentor |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | O seu próprio token, com pelo menos 16 caracteres. Guarde-o: o runner inicia sessão com ele a partir de agora |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcional: um join token, usado só enquanto o seu runner ainda não existe ou aguarda aprovação |
+
+Adicione estas quando a rede precisar delas:
+
+| Variável | Quando |
+|---|---|
+| `HTTPS_PROXY`, `NO_PROXY` | O RTE chega à aplicação através de um proxy: `HTTPS_PROXY=http://proxy.dc2.example.com:3128`. Um host listado em `NO_PROXY` (separados por vírgulas, `.example.com` para um domínio) é contactado diretamente |
+| `NODE_EXTRA_CA_CERTS` | O certificado da aplicação vem de uma CA privada: coloque o certificado da CA em `/opt/af-rte/data/certificates/ca.pem` e defina `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` aceita qualquer certificado da aplicação, um autoassinado incluído. Só dentro de uma rede de confiança: prefira `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predefinição) recebe os playbooks e os inventários com cada tarefa. Deixe-o assim, a menos que os monte você mesmo no RTE (`local`) |
+
+As outras definições que um RTE lê estão em [Correr um RTE](run.html#settings). `RTE_MAX_JOBS`, `RTE_CACHE_MB`, `RTE_FILES` e
+`RTE_DRAIN_SECONDS` também podem ser definidas mais tarde na sua página de runner, que prevalece sobre a variável (consulte
+[As definições de um RTE](../runners/runner-page.html#an-rtes-settings)).
+
+---
+
+## 6. Arrancá-lo
+
+Um ficheiro compose mantém toda a definição num só sítio, ao lado das definições. Coloque a imagem do passo 4 em `image:`:
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+O Docker volta a arrancá-lo depois de um reinício (`unless-stopped`). O Podman não tem nenhum daemon que o faça: ative `podman-restart.service`
+(`sudo systemctl enable --now podman-restart`), ou corra o contentor como serviço systemd com um ficheiro Quadlet. Num host com SELinux
+em modo enforcing, acrescente `:Z` a cada volume (`./data:/app/dist/persistent:Z`).
+
+Sem compose, o mesmo contentor num só comando:
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. Verificá-lo no host
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+O registo mostra o RTE a arrancar, a ligar-se à aplicação e a ficar ligado:
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+Sem join token, mais uma linha diz que está à espera:
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`. Anote a impressão digital.
+
+`/ready` responde `503` com `not connected to the app` até o socket estar aberto. O healthcheck só diz que o processo está à escuta.
+
+---
+
+## 8. Aprová-lo
+
+Sem join token, o RTE pediu para aderir: **Ligações > Runners** mostra um aviso laranja acima da lista,
+**1 Runner aguarda aprovação**. Abra-o, verifique que a **Impressão digital** é a do registo do RTE e que **Modo** diz
+Saída, e depois clique em **Aprovar** (consulte [Aprovar um RTE](../runners/registration.html#approving-an-rte)). Só um admin aprova. Um pedido
+que ninguém trate em 24 horas é removido, e o RTE volta a pedir da próxima vez que se ligar à aplicação.
+
+Com um join token, o runner é aprovado de imediato e a sua descrição nomeia o join token. Em ambos os casos, a aplicação guarda o token do RTE
+numa nova credencial RTE, `rte-dc2-rte`, e o RTE inicia sessão com o seu próprio `RTE_TOKEN` a partir daí: `RTE_JOIN_TOKEN` deixa de ser
+usado, e pode removê-lo do `rte.env`.
+
+---
+
+## 9. Verificá-lo no AnsibleForms
+
+1. **Ligações > Runners** lista o runner `rte-dc2`, tipo RTE. Ligue **Colunas > Ligação** para ver **Ligado** na lista
+2. Abra-o. O seu separador **RTE** mostra **Modo** Saída e o distintivo **Ligação** **Ligado**; ao passar o ponteiro nomeia o nó da aplicação que
+   tem o socket, a versão do RTE e quantas das suas tarefas estão a correr
+3. Clique em **Testar ligação**: diz **Runner connection is OK**. Não chama nada: lê que nó da aplicação tem o socket do RTE
+   (`runner_leases`) e verifica o contrato que o RTE falou quando se ligou
+4. Dê-lhe uma descrição, como *Centro de dados 2*
+5. Deixe **Predefinido** no runner do centro de dados 1, a menos que todos os formulários de playbook sem `runner:` devam correr no centro de dados 2
+
+A página **Estado** lista o novo RTE com a sua versão, ao lado dos outros.
+
+---
+
+## 10. Uma primeira tarefa
+
+Prove todo o caminho com um playbook que não altera nada. Nos playbooks da aplicação (a sua pasta de playbooks ou o seu repositório, como no
+centro de dados 1), adicione `ping-dc2.yaml`:
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+Depois adicione no designer um formulário que nomeie o novo runner:
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+Lance-o. A aplicação envia a pasta dos playbooks e o inventário com a tarefa, e o RTE guarda-os pelo seu hash, por isso uma pasta inalterada
+nunca é enviada duas vezes. A saída começa por `Running on RTE rte-dc2 (outbound)`, mostra `pong` para cada host, e a tarefa
+termina com sucesso. Uma pasta maior do que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 por predefinição) não é
+enviada: a tarefa falha e indica-o.
+
+---
+
+## 11. Enviar-lhe os formulários
+
+Um formulário corre no RTE que nomeia, por isso acrescente a mesma linha a todos os formulários do centro de dados 2:
+
+```yaml
+runner: rte-dc2
+```
+
+Consulte [Runners](../runners.html) para o runner predefinido e os outros tipos de runner.
+
+---
+
+## Quando algo falha
+
+O RTE escreve em `docker logs` a partir de `notice`. Uma ligação que falha antes de o socket abrir (um nome DNS, uma porta recusada, um
+certificado) só aparece como `RTE: dialing the app again in <n> seconds`, em `info`: defina
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) no `rte.env` e reinicie-o para ver
+`RTE: socket to wss://...: <the error>`.
+
+| O que vê | Onde | O que fazer |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `RTE_TOKEN` falta ou é demasiado curto no `rte.env` |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | Defina `APP_URL` no `rte.env` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` tem de começar por `https://` (ou `http://`) |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | Falta `RTE_MODE=outbound` no `rte.env` |
+| Nenhuma linha `connected to the app`, `/ready` fica em `503` | `docker logs`, `/ready` | A rede do passo 2: faça `curl` à aplicação a partir deste host, o proxy (`HTTPS_PROXY`, `NO_PROXY`), o certificado da aplicação (`NODE_EXTRA_CA_CERTS`, passo 5). Defina `LOG_CONSOLE_LEVEL=debug` para ver o erro |
+| `the app refused the socket (404)` ou outro estado que não 401, 403 e 409 | `docker logs` | Um reverse proxy não deixa passar o WebSocket em `/api/v2/rte/socket`, ou falta a `APP_URL` o caminho base da aplicação |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | Existe um runner `rte-dc2` com outro token. Dê ao RTE esse token (a palavra-passe da credencial do runner), ou elimine o runner para que ele peça para aderir |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | Crie um novo join token, ou remova `RTE_JOIN_TOKEN` e aprove o RTE (passo 8) |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | O RTE foi instalado de novo com um token novo: use o token da credencial do seu runner, ou peça a um admin que o altere |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | Segue-se a uma recusa. Corrija a sua causa, e depois faça `docker restart af_rte_dc2` em vez de esperar |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | Aprove-o (passo 8). Está ligado, mas não recebe tarefas até lá |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | A aplicação e o RTE correm versões de outro [contrato](images.html#the-contract): atualize o RTE para a versão da aplicação (consulte Atualizá-lo) |
+| **Não ligado**, ou **Testar ligação** diz *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | A aplicação | Nenhum nó da aplicação tem o seu socket: o RTE está parado, ou não chega à aplicação. Leia os seus `docker logs` |
+| Uma tarefa espera e depois falha com *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | A saída da tarefa | O RTE não estava ligado enquanto a tarefa esperava |
+| `Permission denied` na chave ssh | A saída da tarefa | Os ficheiros de `data/` têm de pertencer ao uid 1000 (passo 3) |
+| `UNREACHABLE` nos hosts geridos | A saída da tarefa | O ssh a partir deste host: a chave, o `known_hosts`, e a firewall em direção aos hosts |
+
+Do lado da aplicação, um RTE recusado aparece no registo da aplicação como `Refused an RTE socket from <address>: <why>`.
+
+---
+
+## Atualizá-lo
+
+Quando a aplicação passa para uma versão nova, acompanhe-a também neste host. Um RTE do mesmo contrato continua a funcionar entretanto; quando uma versão
+altera o contrato, as suas notas de versão indicam-no (consulte [O contrato](images.html#the-contract)). Com `:7` no `compose.yml`, ou no
+`FROM` do seu Dockerfile:
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+Atualize-o quando nenhum playbook estiver a correr nele: uma paragem espera `RTE_DRAIN_SECONDS` (25) pelos playbooks em execução, e os que ainda estiverem a correr
+terminam então como abandonados. O que imprimiram antes da paragem fica no spool e é enviado quando o RTE voltar. Sem ligação, faça `docker load`
+da imagem nova (passo 4) antes de `docker compose up -d`.
+
+---
+
+## Reverter
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+O socket fecha, e o runner mostra **Não ligado** de imediato: nenhum nó da aplicação tem já o seu socket (`runner_leases`). Um host
+que desaparece sem o fechar mostra **Não ligado** em cerca de um minuto, quando o nó da aplicação deixa de ouvir algo no socket. O
+runner fica: um runner que aderiu por um socket nunca é removido sozinho. Elimine-o em **Ligações > Runners**, e a sua
+credencial `rte-dc2-rte` em **Ligações > Credenciais**. Remova primeiro a linha `runner:` dos formulários que o nomeavam: até
+lá as suas tarefas esperam pelo RTE, até `RTE_QUEUE_MINUTES`, e falham.
+
+---
+
+## Mais capacidade no centro de dados 2
+
+Repita os passos 1 a 9 em mais hosts do centro de dados 2, cada um com o seu próprio `RTE_NAME` e `RTE_TOKEN`, como `rte-dc2-b`: cada um adere como
+runner próprio e recebe até [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks. Um formulário escolhe um com
+`runner:`. Dois RTE com o mesmo `RTE_NAME` não partilham o trabalho: o segundo fica com o socket do primeiro (consulte
+[Vários RTE](several.html#several-rtes)).
+
+---
+
+## Um RTE em modo base de dados
+
+Antes da 7.3.0, este runbook configurava um RTE em modo base de dados: tinha as credenciais da base de dados (`DB_*`, `ENCRYPTION_SECRET`), ligava-se
+à base de dados do centro de dados 1 pela porta `3306`, e a aplicação chamava-o na sua porta `8000`. Esse modo está obsoleto desde a 7.3.0 e
+é removido na 8.0.0. Para passar um RTE destes para saída sem um runner novo, defina nele `RTE_MODE=outbound`, `APP_URL` e `RTE_NAME` (o nome do
+seu runner), mantenha o seu `RTE_TOKEN`, e remova `DB_*`, `ENCRYPTION_SECRET` e `RTE_REGISTER`: consulte
+[Base de dados (obsoleto)](modes.html#database-deprecated). Depois feche a porta `8000` e a porta da base de dados de que já não precisa.
diff --git a/i18n/pt/_configure/rte/images.md b/i18n/pt/_configure/rte/images.md
new file mode 100644
index 0000000..ff7d0fc
--- /dev/null
+++ b/i18n/pt/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Imagens
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# Imagens do RTE
+{: .no_toc }
+
+As três imagens publicadas do RTE, e um RTE seu com as collections e bibliotecas que os seus playbooks usam
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## As imagens do RTE
+
+O RTE é publicado em três camadas, cada uma construída sobre a anterior, com as mesmas tags que a aplicação (consulte [Tags das imagens](../installation/#image-tags)):
+
+| Imagem | O que contém | Use-a |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js e o servidor do AnsibleForms, git, ssh e sshpass. Sem python e sem ansible, por isso não corre nenhum playbook sozinha | Para construir um RTE com as suas próprias versões de python e ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | A base, mais python 3.14, ansible-core e algumas bibliotecas comuns (`jmespath`, `netaddr`, `requests`, `paramiko`). Sem collections | Para construir um RTE mais pequeno só com as collections e bibliotecas que os seus playbooks usam |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | A core, mais o pacote `ansible` sobre o mesmo ansible-core, e o que a imagem do AnsibleForms 6.5 tinha: as collections da NetApp, da AWS e da comunidade, `pandas`, `pyvmomi`, `boto3`, o cliente mariadb, ytt e algumas ferramentas do sistema operativo | **A predefinição.** Corra-a tal como está: os playbooks da 6.5 encontram o que usavam |
+
+Tal como a imagem da aplicação, todas as camadas correm como o utilizador `node` (uid 1000), e os playbooks também correm como esse utilizador.
+
+---
+
+## Construir o seu próprio RTE
+
+Construa sobre `ansibleforms-rte-core` e adicione as collections e as bibliotecas python que os seus playbooks usam. Este exemplo da NetApp é um dos
+Dockerfiles de [examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte):
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+O ambiente python e a pasta das collections pertencem a `node`, por isso estas instalações não precisam de root. Uma camada que instala pacotes
+do sistema operativo muda para `USER root` para eles e volta a `USER node` no fim. Para trazer o seu próprio python e ansible, construa sobre
+`ansibleforms-rte-base` (`Dockerfile.own-ansible` na mesma pasta).
+
+Mantenha a imagem na versão da aplicação: `:7` acompanha o `:7` da aplicação. As collections e os roles também podem ser montados em vez de incluídos na imagem, em
+`/etc/ansible/collections` e `/etc/ansible/roles`. Assim não é preciso reconstruir a cada alteração, mas o que corre depende desse volume;
+as bibliotecas python vão sempre para a imagem. Incluir tudo na imagem é reprodutível e arranca depressa, o que faz disso o caminho para produção.
+
+---
+
+## O contrato
+
+O que a aplicação e um RTE têm de partilhar é o seu contrato, um número que ambos indicam. Um RTE de uma versão anterior continua a funcionar com uma
+aplicação mais recente desde que ambos falem o mesmo contrato; quando uma versão o altera, as suas notas de versão dizem que os RTE têm de ser atualizados. Cada modo
+tem o seu:
+
+| Modo | Contrato | Numa incompatibilidade |
+|---|---|---|
+| Saída, Entrada | 3, novo na 7.3.0 | A aplicação fecha o socket do RTE com o código `4409` e regista *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*. Um RTE de saída regista *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*. Uma tarefa enviada com outro contrato é recusada |
+| Base de dados (obsoleto) | 2, desde a 7.0.0 | O RTE recusa as tarefas da aplicação |
+
+**Testar ligação** no runner diz que contrato o RTE fala e qual a aplicação precisa (consulte
+[Testar ligação](../runners/runner-page.html#test-connection)), e a linha **Runners** da página **Estado** faz a mesma verificação.
diff --git a/i18n/pt/_configure/rte/index.md b/i18n/pt/_configure/rte/index.md
new file mode 100644
index 0000000..7efa1dc
--- /dev/null
+++ b/i18n/pt/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# Ambientes de execução (RTE)
+{: .no_toc }
+
+O que é um RTE, como corre um playbook, e em que pode tocar
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: perceba o RTE antes de correr um, de o dimensionar, ou de o mudar para outra rede.
+
+| Página | O que abrange |
+|---|---|
+| [Imagens](images.html) | As três imagens do RTE, e construir a sua com as collections que os seus playbooks usam |
+| [Modos](modes.html) | Saída, entrada ou base de dados: quem abre a ligação, o spool, os ficheiros da tarefa |
+| [Correr um RTE](run.html) | As definições de cada modo, e um exemplo `docker run` de cada um |
+| [Vários RTE](several.html) | Capacidade, réplicas atrás de um endereço, e o que acontece quando um RTE para ou morre |
+| [Outro centro de dados](another-datacenter.html) | Um runbook: adicionar um RTE num segundo centro de dados, de um host vazio até à sua primeira tarefa |
+
+---
+
+## O que é um RTE
+
+O AnsibleForms 7 não corre nenhum playbook no contentor da aplicação. A tarefa de um formulário `ansible` é entregue a um [runner](../runners.html) do tipo
+`rte`, um ambiente de execução: o servidor do AnsibleForms arrancado com `AF_ROLE=rte`, ao lado de python e ansible, sem
+interface web. Fala com a aplicação por um WebSocket e não tem credenciais da base de dados
+([`RTE_MODE`](../customization/server.html#env_RTE_MODE) `outbound` ou `inbound`, consulte [Modos](modes.html)): a aplicação envia-lhe a tarefa,
+o RTE corre `ansible-playbook`, e a aplicação guarda a saída e o estado final que ele devolve, onde o navegador os lê.
+
+A aplicação resolve as credenciais da tarefa e entrega-as ao RTE seladas só para esse RTE e essa tarefa. O RTE nunca lê a
+tabela de credenciais nem um cofre de segredos, e um playbook não herda as variáveis de ambiente do próprio AnsibleForms
+(`ENCRYPTION_SECRET`, `DB_*`, `RTE_TOKEN` e as outras): passe um valor desses como extravar ou como credencial. O RTE da 7.0 à 7.2,
+que lia e escrevia ele próprio na base de dados, continua a correr na 7.x como o modo base de dados obsoleto (consulte [Modo base de dados](#database-mode-deprecated)).
+
+---
+
+## Como o RTE corre
+
+O RTE é um contentor que corre você mesmo, ao lado da aplicação ou noutra rede: o AnsibleForms nunca cria nenhum. Isto percorre
+onde corre, o que partilha com a aplicação, e o que acontece dentro dele desde o momento em que um formulário é lançado até o processo do playbook
+desaparecer:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">Como o RTE corre um playbook</title>
+<desc id="afr-desc">Num host de contentores ou num cluster Kubernetes, ambos geridos pelo operador, o contentor da aplicação e um ou mais contentores RTE mantêm cada um um WebSocket entre eles, aberto pela aplicação (entrada) ou pelo RTE (saída). Só a aplicação fala com a base de dados. 1: o navegador lança um formulário na aplicação. 2: a aplicação guarda a tarefa na base de dados, escolhe o runner e sela para ele os segredos da tarefa. 3: a aplicação envia a tarefa pelo socket. 4: o RTE reclama-a e obtém os ficheiros da tarefa, da sua cache ou da aplicação. 5: o RTE arranca o ansible-playbook como processo filho, um por tarefa, até RTE_MAX_JOBS. 6: o playbook chega aos hosts geridos. 7: o RTE escreve a saída, os eventos e o fim no seu spool e envia-os pelo socket; a aplicação guarda-os na base de dados e confirma a sua receção. 8: o navegador acompanha a tarefa através da aplicação. O volume da aplicação só é montado no RTE com RTE_FILES=local.</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">Host de contentores ou cluster Kubernetes</text>
+<text class="afr-s" x="181" y="61">gerido por si; um RTE de saída pode estar noutra rede</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">Navegador</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">formulários, tarefa</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">Contentor da app</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">web, API, worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">Runners</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">selam os segredos</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">Hub do RTE</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">guarda e confirma</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">Contentor RTE</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="477" y="160" text-anchor="middle">Ficheiros da tarefa</text>
+<text class="afr-s" x="477" y="174" text-anchor="middle">em cache por hash</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">até RTE_MAX_JOBS</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">até à confirmação</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">um</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">Hosts geridos</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">Volume da app</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbooks, inventários</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">só RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">só da app</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+O diagrama mostra um socket por RTE, seja qual for o lado que o abriu: a aplicação liga-se a um RTE de entrada, um RTE de saída liga-se à aplicação (consulte
+[Modos](modes.html)). As mesmas mensagens circulam nos dois sentidos depois de aberto, e só a aplicação lê e escreve na base de dados.
+
+**Quem o arranca.** Um RTE é um contentor de longa duração, arrancado pelo que quer que corra os seus outros contentores. Espera por tarefas e continua
+a correr entre elas:
+
+| Como corre o AnsibleForms | Quem arranca o RTE |
+|---|---|
+| `docker run` ou `podman run` | Você, com um comando como o de [Correr um RTE](run.html), em qualquer host que chegue à aplicação, ou a que a aplicação chegue |
+| [Docker Compose](../installation/docker-compose.html) | O serviço `rte` do `docker-compose.yml`, ao lado de `app` e `mysqldb`. O seu config seed declara-o como o runner predefinido `rte`, de entrada, em `http://rte:8000` |
+| [Helm chart](../installation/kubernetes.html) | O Kubernetes, como um segundo contentor chamado `rte` no pod da aplicação (`containers.rte`). A aplicação liga-se a ele em `127.0.0.1`, de entrada, e o seed do chart declara-o como o runner predefinido |
+| [O instalador](../installation/installer.html) | O Docker Compose ou o Helm chart como acima, ou um serviço systemd [sem contentores](../installation/native.html); um Runner próprio, que pede para aderir e espera pela aprovação de um admin |
+
+O motor de contentores é seu: Docker ou Podman no host, ou o runtime de contentores do seu cluster Kubernetes, instalado e mantido
+atualizado por si. O AnsibleForms nunca fala com ele. Nem a aplicação nem o RTE chamam o Docker ou o Podman, montam o seu socket, ou arrancam um
+contentor: a aplicação só fala com o RTE pelo socket dele.
+
+**O que tem dentro.** Um contentor, com o necessário para correr um playbook e nada mais:
+
+* **O servidor** : o mesmo servidor Node.js que a aplicação, arrancado com `AF_ROLE=rte` (definido na imagem) sob `tini`
+* **O que fica de fora** : a interface web, o início de sessão, o agendador, o worker e todos os módulos de base de dados, que esta função não carrega
+* **Onde está à escuta** : a sua `PORT` (`8000`): `/live` e `/ready` para as sondas e `/metrics` para o Prometheus, e, em modo de entrada, o socket
+  a que a aplicação se liga, `/rte/v1/socket`. Um RTE de saída não aceita nenhuma ligação da aplicação
+* **Python e ansible** : trazidos pela camada de imagem que escolher (consulte [As imagens do RTE](images.html))
+* **O utilizador** : o servidor e todos os playbooks correm como `node` (uid 1000), nunca como root
+
+**O que partilha com a aplicação.** O seu token, e com `RTE_FILES=local` os ficheiros da aplicação. Com `RTE_FILES=transfer`, a predefinição, os
+playbooks e os inventários chegam com cada tarefa, e o RTE não precisa de disco partilhado:
+
+| Partilhado com a aplicação | O que o RTE faz com isso |
+|---|---|
+| `RTE_TOKEN` | Apresenta-o quando se liga à aplicação (saída), ou verifica-o quando a aplicação se liga a ele (entrada). A aplicação tem o mesmo valor na credencial RTE do runner, e os segredos da tarefa são selados com ele |
+| O volume persistente, `/app/dist/persistent`, só com `RTE_FILES=local` | A pasta dos playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)), ou o repositório de playbooks que o worker clonou em [`REPO_PATH`](../customization/paths.html#env_REPO_PATH), os inventários ([`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) e os repositórios de inventário) e os ficheiros carregados. O RTE escreve os ficheiros de extravars da tarefa na pasta do playbook, por isso monte-a em leitura e escrita |
+| A pasta ssh, `/home/node/.ssh` | A chave privada e o `known_hosts` que as ligações ssh do playbook usam: monte a da aplicação, gerida nas suas páginas de definições, ou dê ao RTE a sua própria |
+
+O RTE não clona nada: um repositório chega-lhe nos ficheiros de uma tarefa, ou no volume que partilha com a aplicação. As collections, os roles e o
+`ansible.cfg` vêm da imagem, das pastas `/etc/ansible/collections`, `/etc/ansible/roles` e `/etc/ansible/ansible.cfg` quando
+os monta aí (o projeto Docker Compose fá-lo), ou de um `ansible.cfg` ao lado dos playbooks.
+
+**A vida de uma tarefa.** Os números abaixo são os números do diagrama, para um formulário de playbook lançado a partir do navegador ou da API:
+
+1. **Lançamento** : a aplicação verifica o formulário e os seus valores, constrói os extravars e guarda a tarefa com o estado `running`. Um formulário com uma
+   [aprovação](../forms/approval.html) para aqui até um aprovador a aceitar, e não chega a nenhum RTE antes disso
+2. **Escolher o runner** : a aplicação fica com o RTE que o formulário nomeia com `runner: <name>`, senão com o runner predefinido do tipo RTE, e guarda o seu
+   nome na tarefa. Resolve as credenciais da tarefa a partir da base de dados ou de um [cofre de segredos](../secret-stores/), o seu acesso ansible e a sua
+   palavra-passe de vault, e sela-os com AES-256-GCM sob uma chave derivada do token desse runner e do id da tarefa
+3. **Entrega** : o nó da aplicação que tem o socket do RTE envia-lhe a tarefa: os extravars, as opções do formulário, os segredos selados e
+   os hashes dos ficheiros da tarefa. Qualquer nó da aplicação pode lançar a tarefa; o que tem o socket envia-a em dois segundos. Um RTE cheio,
+   ou um que não está ligado, faz a tarefa esperar, até [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **Reclamação** : o RTE responde `claimed`, ou `refused` quando está cheio, a parar, não consegue abrir os segredos, ou a tarefa chega com outro
+   [contrato](images.html#the-contract) que não o seu. Com `RTE_FILES=transfer` vai buscar os playbooks e os inventários à sua
+   cache pelo seu hash, pede à aplicação um hash que não tem, e desempacota-os numa pasta própria da tarefa
+5. **Arranque** : na pasta do playbook (mais o `playbookSubPath` do formulário, que tem de existir) escreve dois ficheiros: `extravars_<id>.json`
+   com os valores do formulário e as credenciais, e um oculto com o acesso ansible. Depois arranca `ansible-playbook` como seu próprio processo
+   filho, sem shell, num grupo de processos próprio, com `-e @` esses ficheiros, um `-i` por inventário, e as tags, o limit, o check,
+   o diff e a verbosidade do formulário. A palavra-passe de vault entra por stdin, nunca num ficheiro nem na linha de comandos, e o processo corre como
+   `node` com um ambiente filtrado (ver abaixo)
+6. **Execução** : o playbook liga-se aos hosts geridos a partir do contentor do RTE, por ssh com a chave e o `known_hosts` de
+   `/home/node/.ssh`, com `sshpass` para um acesso por palavra-passe, ou pelas APIs que os seus módulos chamam. É o RTE, não a aplicação, que precisa de chegar a eles
+7. **Saída e fim** : o RTE agrupa o stdout e o stderr a cada meio segundo ou 64 KB, com as credenciais mascaradas, e numera cada
+   lote. Escreve cada item no spool da tarefa no seu disco antes de o enviar: a saída, os eventos, o registo da tarefa de
+   `.joblogs/job_log_<id>.log` (a cada 2 segundos), o início e o fim com o estado final (`success`, `failed` ou `aborted`). A aplicação
+   guarda cada item uma vez e confirma a sua receção, e o RTE descarta o spool quando o fim fica guardado. Para além de
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) bytes num fluxo (50 MB por predefinição) não envia mais, e
+   o playbook continua. A aplicação envia depois as [notificações](../forms/notifications.html) do formulário
+8. **Acompanhamento** : o navegador nunca fala com o RTE: a página do formulário volta a ler a tarefa através da aplicação a cada 2 segundos, e a página Tarefas
+   acompanha-a em direto à medida que a aplicação guarda cada item
+
+**Um socket que cai.** O playbook continua. O RTE volta a ligar-se (saída), ou um nó da aplicação liga-se de novo a ele (entrada), e reenvia o que
+a aplicação ainda não tinha confirmado: a aplicação salta o que já guardou, por isso nenhuma linha se perde nem é guardada duas vezes. Isto vale enquanto o socket
+voltar em dois minutos: a aplicação só escreve o heartbeat do RTE enquanto o seu socket está aberto, e quando esse heartbeat tem dois minutos
+o worker termina as tarefas em execução do RTE como abandonadas, mesmo que os seus playbooks continuem a correr. Mantenha o spool
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) num volume, para que um RTE reiniciado continue a enviar o que tinha guardado. Um
+playbook que estava a correr quando o seu RTE reiniciou não pode continuar: a aplicação termina a sua tarefa como abandonada quando o RTE volta sem ela.
+
+**Abortar.** Abortar marca a tarefa como abortada, e o nó da aplicação que tem o socket do RTE envia `cancel` em dois segundos. O RTE
+envia `SIGTERM` ao grupo de processos do playbook, por isso o `ansible-playbook` e todos os forks que arrancou param juntos, e a tarefa termina
+`aborted`. Um cancel que chega antes da sua tarefa é guardado durante um minuto, e a tarefa arranca então já abortada.
+
+**Limpeza.** Assim que o processo termina, seja qual for o resultado, o RTE remove os dois ficheiros de extravars (um formulário com `keepExtravars`
+mantém o visível, nunca o oculto), o ficheiro de artefactos em `/tmp`, o ficheiro de registo da tarefa e a pasta de ficheiros da própria tarefa. O
+fim é guardado uma vez: um segundo escritor, como a aplicação a falhar uma tarefa que o RTE já terminou, não altera nada.
+
+**Um processo por tarefa, não um contentor por tarefa.** O AWX e o AAP arrancam um pod ou contentor novo a partir de uma imagem de execution environment para
+cada tarefa. O AnsibleForms não arranca nada: o contentor do RTE já está a correr, e cada tarefa é um processo filho dentro dele. Uma tarefa arranca
+sem descarregar uma imagem nem agendar um pod, e o AnsibleForms não precisa de direitos no seu motor de contentores nem no seu cluster. Em troca, os
+playbooks que correm num RTE partilham o seu CPU, a sua memória, `/tmp`, a pasta pessoal e o python: dê ao contentor recursos suficientes para
+`RTE_MAX_JOBS` playbooks com os seus forks. Para mudar o que um playbook pode usar, mude a imagem, não a tarefa.
+
+---
+
+## A fronteira de segurança
+
+O RTE corre código escrito pelos autores dos formulários, por isso foi construído para conter o mínimo possível:
+
+* **Só o seu token** : o RTE não tem credenciais da base de dados nem `ENCRYPTION_SECRET`. Não aceita nenhuma chamada além do socket da aplicação, com
+  o seu token, e não tem utilizadores, nem início de sessão, nem páginas web. Pelo socket só pode correr as tarefas que a aplicação lhe envia, informar sobre elas e
+  pedir os seus ficheiros: não pode criar uma tarefa, ler outra tarefa nem distribuir credenciais
+* **Segredos selados** : para correr uma tarefa, o RTE nunca lê a tabela de credenciais nem um cofre de segredos. Recebe os segredos das tarefas que
+  corre, selados só para o seu token e para esse id de tarefa, por isso um pacote destinado a outro RTE ou a outra tarefa não abre, e um byte alterado
+  é recusado
+* **Uma ligação verificada** : em modo de saída, o RTE verifica o certificado da aplicação. Em modo de entrada por HTTPS, a aplicação fixa o próprio certificado do RTE
+  quando este adere, e só se liga a ele quando apresenta esse certificado (consulte [Modos](modes.html#inbound)). Um RTE de entrada por HTTP simples deve estar
+  numa rede privada, como a do projeto Docker Compose
+* **Nenhum ambiente herdado** : `ansible-playbook` recebe o ambiente do RTE sem nenhuma das variáveis que o próprio AnsibleForms lê
+  (`ENCRYPTION_SECRET`, `DB_PASSWORD`, `RTE_TOKEN`, `VAULT_TOKEN`, `ACCESS_TOKEN_SECRET`, as `MYSQL_*` e as outras), por isso
+  `lookup('env', ...)` não lhes chega. O que definir para os playbooks (`PATH`, proxies, `ANSIBLE_*`) passa tal como está
+* **Nenhum template dos utilizadores** : {% raw %}um valor de formulário que contenha `{{`, `{%` ou `{#` chega ao playbook como uma string unsafe{% endraw %}
+  que o ansible nunca processa como template, a menos que o formulário defina `allowJinjaInExtravars`, e nenhuma shell corre alguma vez a linha de comandos
+* **Não é root** : o RTE e os seus playbooks correm como `node` (uid 1000), por isso um playbook pode fazer o que esse utilizador pode no contentor, como
+  ler os seus ficheiros e a chave ssh, e nada mais
+
+Trate o seu contentor, a sua imagem e o seu ambiente com o mesmo cuidado que os da aplicação.
+
+---
+
+## Modo base de dados (obsoleto)
+
+O RTE da 7.0 à 7.2, sem `RTE_MODE`, corre durante toda a 7.x e é removido na 8.0.0. Difere dos passos acima em quatro aspetos:
+
+* **Tem acesso à base de dados** : as suas definições `DB_*`, e `ENCRYPTION_SECRET` quando se regista a si próprio
+  ([`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER))
+* **A entrega é uma chamada HTTP** : a aplicação chama `POST <address>/rte/v1/jobs` com o token e os segredos selados, e o RTE reclama
+  a tarefa escrevendo nela o seu nome na base de dados (passos 3 e 4)
+* **Escreve ele próprio a saída** : na base de dados, em lotes, sem spool (passo 7). Um abortar chega-lhe pela marca de abortar da tarefa,
+  que lê a cada 2 segundos, e por uma chamada `/cancel`
+* **Lê os ficheiros do volume da aplicação** : precisa do mesmo disco que a aplicação, como com `RTE_FILES=local`
+
+A sua página de runner não tem nenhuma das [definições do RTE](../runners/runner-page.html#an-rtes-settings): lê as suas próprias variáveis. Para o passar para um
+modo socket, consulte [Modos](modes.html#database-deprecated).
diff --git a/i18n/pt/_configure/rte/modes.md b/i18n/pt/_configure/rte/modes.md
new file mode 100644
index 0000000..0cb6dec
--- /dev/null
+++ b/i18n/pt/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: Modos
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# Como um RTE fala com a aplicação
+{: .no_toc }
+
+Saída, entrada ou base de dados: quem abre a ligação, e o que passa por ela
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: desde a 7.3.0, um RTE fala com a aplicação por um WebSocket e não tem credenciais da base de dados. Escolha o modo
+que se adequa à rede entre eles: quem pode abrir uma ligação para quem, e por que proxies e firewalls passa.
+
+---
+
+## Os três modos
+
+[`RTE_MODE`](../customization/server.html#env_RTE_MODE) no RTE diz como chega à aplicação; o seu runner tem o mesmo **Modo**:
+
+| Modo | Quem abre a ligação | O que o RTE contém | Para |
+|---|---|---|---|
+| `outbound` | O RTE liga-se à aplicação em [`APP_URL`](../customization/server.html#env_APP_URL) e mantém um WebSocket aberto | O seu `RTE_TOKEN`, sem credenciais da base de dados | Uma DMZ, NAT, ou uma zona que não permite ligações de entrada: nada chega ao RTE de fora |
+| `inbound` | A aplicação liga-se ao RTE no endereço do seu runner e mantém um WebSocket aberto | O seu `RTE_TOKEN`, sem credenciais da base de dados | Uma rede onde é o lado central que abre todas as ligações, um projeto compose, um pod |
+| `database` (obsoleto) | A aplicação chama a API do RTE por HTTP, e o RTE lê e escreve ele próprio na base de dados da aplicação | As credenciais da base de dados (`DB_*`) e `ENCRYPTION_SECRET` | O comportamento da 7.0 à 7.2, removido na 8.0.0 |
+
+Um RTE sem `RTE_MODE` corre em modo base de dados durante toda a 7.x, e regista um aviso `[DEPRECATED] This RTE runs in database mode` no
+seu arranque. Um runner adicionado antes da 7.3.0 tem o modo **Base de dados (obsoleto)**; defina-o com o modo em que o seu RTE corre quando o migrar.
+
+---
+
+## Saída
+
+O RTE abre a ligação, por isso funciona a partir de uma rede que não aceita nenhuma ligação de entrada:
+
+* **O socket** : o RTE liga-se a `APP_URL` com `/api/v2/rte/socket` acrescentado, por `wss://` (`ws://` para um endereço `http://`), com o seu
+  `RTE_TOKEN` e o nome do seu runner, [`RTE_NAME`](../customization/server.html#env_RTE_NAME). Volta a ligar-se quando o socket cai
+* **A primeira vez** : pede para aderir, e o seu runner espera pela aprovação de um admin em **Ligações > Runners**, ligado
+  mas sem tarefas (consulte [Pedir para aderir](../runners/registration.html#asking-to-join)). Um join token,
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), aprova-o de imediato. A partir daí inicia sessão com o seu próprio token
+* **A rede** : só da zona do RTE para a aplicação, na porta da aplicação, através de um proxy quando `HTTPS_PROXY` o indica. Um reverse
+  proxy à frente da aplicação tem de deixar passar o WebSocket nesse caminho (consulte [WebSockets dos runners](../production/reverse-proxy.html#runner-websockets))
+* **O certificado** : o certificado da aplicação é verificado. Indique uma CA privada com `NODE_EXTRA_CA_CERTS`, ou, só dentro de uma rede
+  de confiança, desligue a verificação com [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)
+* **O runner** : não precisa de endereço, por isso a sua credencial RTE contém só o token
+* **Pronto** : `/ready` responde `503` até o socket para a aplicação estar aberto
+
+Com vários nós da aplicação atrás de um balanceador de carga, o nó a que o RTE chega fica com o seu socket. Qualquer nó pode lançar uma tarefa: o nó que tem
+o socket envia-a ao RTE, em dois segundos quando a tarefa foi lançada noutro nó.
+
+---
+
+## Entrada
+
+O RTE escuta na sua `PORT`, e a aplicação liga-se a ele no endereço do seu runner, com `/rte/v1/socket` acrescentado e o token do RTE. Com
+vários nós da aplicação, um de cada vez tem o socket de cada runner de entrada; quando esse nó para, outro assume e volta a ligar-se.
+
+A aplicação precisa do runner do RTE antes de se poder ligar a ele: tipo RTE, modo **Entrada**, e uma credencial RTE com o endereço do RTE e o seu
+`RTE_TOKEN`. Chega lá de uma de duas formas:
+
+| Como | O que definir |
+|---|---|
+| O RTE pede para aderir | `APP_URL` e [`RTE_URL`](../customization/server.html#env_RTE_URL) (o endereço a que a aplicação se liga). O RTE faz uma chamada, `POST /api/v2/rte/register`, e o seu runner espera pela aprovação de um admin: a aplicação liga-se a ele depois de aprovado (consulte [Pedir para aderir](../runners/registration.html#asking-to-join)). Com `RTE_JOIN_TOKEN` é aprovado de imediato. Um RTE de entrada com `APP_URL` mas sem `RTE_URL` recusa-se a arrancar |
+| Você adiciona o runner | Sem `APP_URL`: adicione o runner em **Ligações > Runners**, ou no [config seed](../seed/), como em [Correr um RTE](run.html#start-it) |
+
+O projeto Docker Compose, o Helm chart e o controlador do instalador correm o seu próprio RTE desta forma, de entrada, declarado pelo seed.
+
+**Por HTTPS.** Com [`HTTPS=1`](../customization/server.html#env_HTTPS) o RTE serve o seu socket por TLS, com a chave e o certificado
+de [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) e [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT)
+(`key.pem` e `cert.pem` na sua pasta `certificates` por predefinição). Um RTE com um `RTE_URL` `https://` envia esse certificado quando
+pede para aderir, e a aplicação fixa-o: só se liga ao RTE quando este apresenta o mesmo certificado, por isso um autoassinado funciona sem CA.
+O RTE regista a impressão digital do certificado no seu arranque (os primeiros 8 dígitos hexadecimais do SHA-256 dos seus bytes DER, como `abcd-ef12`),
+e a caixa de diálogo de aprovação mostra a que a aplicação recebeu: verifique que coincidem antes de o aprovar.
+O [instalador](../installation/installer.html#a-runner) configura os seus Runners de entrada desta forma, com um certificado do seu próprio endereço.
+
+---
+
+## Base de dados (obsoleto)
+
+O RTE da 7.0 à 7.2: a aplicação chama a sua API por HTTP, e o RTE reclama a tarefa na base de dados, escreve lá a saída e mantém atualizada a sua
+própria linha de runner, com [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER). [Modo base de dados](./#database-mode-deprecated)
+diz em que diferem os seus passos. Continua a funcionar na 7.x, com um aviso em cada arranque, e é removido na 8.0.0.
+
+Para passar um RTE destes para um modo socket, mantenha o seu runner e o seu token:
+
+1. Um runner do [config seed](../seed/): defina primeiro `rte_mode: outbound` ou `rte_mode: inbound` para ele no seed (entrada: com
+   o endereço a que a aplicação se liga no `url` da sua credencial). O RTE não pode migrar ele próprio um runner do seed
+2. No RTE, defina `RTE_MODE=outbound` com `APP_URL`, ou `RTE_MODE=inbound` (com `APP_URL` e `RTE_URL` para fazer a sua única
+   chamada de registo), e defina [`RTE_NAME`](../customization/server.html#env_RTE_NAME) com o nome que o seu runner tem em
+   **Ligações > Runners**. Mantenha o seu `RTE_TOKEN`
+3. Remova `DB_*` e `ENCRYPTION_SECRET` do seu ambiente, e `RTE_REGISTER`, que só o modo base de dados lê, e depois reinicie-o
+
+Quando o RTE atualizado inicia sessão com o nome do runner e o próprio token do runner, a aplicação passa esse runner para o modo do RTE de
+imediato, sem aprovação, e regista *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*. O runner deixa de ser uma linha que o seu RTE registou, por isso o worker nunca o remove quando o contentor antigo deixa de responder. Um
+runner do config seed ainda em modo base de dados é em vez disso recusado, com *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*. Não use um join token para isto: um join
+token é recusado para um runner que já está aprovado. Um RTE de entrada sem `APP_URL` não faz nenhuma chamada: defina antes o **Modo** do seu runner como
+**Entrada** em **Ligações > Runners**, e a aplicação liga-se a ele. O [instalador](../installation/installer.html#a-72-runner)
+atualiza um Runner da 7.2 desta forma.
+
+---
+
+## O que passa pelo socket
+
+Em ambos os modos socket, a aplicação envia ao RTE cada tarefa com tudo o que o RTE costumava ler da base de dados, e guarda o que volta,
+a saída, os eventos, o registo da tarefa e o fim, exatamente uma vez. A aplicação envia também as notificações de fim.
+
+**O spool.** Cada lote de saída, lote de eventos, registo, início e fim é numerado e escrito no ficheiro de spool da tarefa
+([`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)) antes de ser enviado, e guardado até a aplicação dizer que o guardou.
+Depois de voltar a ligar-se, ao mesmo nó da aplicação ou a outro, o RTE reenvia o que não foi confirmado, e a aplicação salta o que já
+guardou: nada se perde, e nada é guardado duas vezes. Mantenha o spool num volume, para que um RTE que reinicia continue a enviar o que ainda não tinha
+entregado. Um playbook que estava a correr quando o RTE reiniciou não pode continuar: a sua tarefa termina como abandonada.
+
+**Capacidade.** O RTE corre até [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks ao mesmo tempo, ou o valor definido
+na sua [página de runner](../runners/runner-page.html#an-rtes-settings), e diz à aplicação a cada 20 segundos quantos estão a correr. Uma tarefa para um RTE
+cheio espera, como descrito em [Vários RTE](several.html#several-jobs-on-one-rte).
+
+**Os ficheiros da tarefa.** [`RTE_FILES`](../customization/server.html#env_RTE_FILES), ou a definição **Ficheiros de trabalho** da sua página de runner, diz
+onde o RTE obtém os playbooks e os inventários:
+
+| `RTE_FILES` | De onde vêm os ficheiros |
+|---|---|
+| `transfer` (predefinição) | A aplicação envia a pasta dos playbooks e os inventários com a tarefa, cada um empacotado e com o nome de um hash do seu conteúdo. O RTE guarda-os empacotados em [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH), os usados mais recentemente até [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) (1024 MB por predefinição), e só pede um hash que não tem: uma pasta inalterada nunca é enviada duas vezes. O RTE não precisa de disco partilhado nem de acesso aos repositórios |
+| `local` | O RTE corre a partir das suas próprias pastas, como um RTE em modo base de dados: monte nele os playbooks ([`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)) e os repositórios ([`REPO_PATH`](../customization/paths.html#env_REPO_PATH)) |
+
+Com `transfer`, cada tarefa desempacota os seus ficheiros numa pasta privada própria, removida quando a tarefa termina: nenhuma tarefa vê o que outra
+escreveu, e nenhum ficheiro de inventário ou de extravars fica desempacotado no disco do RTE. Vários RTE podem partilhar um `RTE_CACHE_PATH`; cada um guarda as suas tarefas numa
+pasta própria, e a pasta de um RTE que parou (morto a meio de uma tarefa, ou recriado com outro hostname) é removida pelos outros
+ao fim de 10 minutos. Uma pasta maior do que [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) (512 por predefinição, lida pela
+aplicação, aplicada sem reiniciar) não é enviada: a tarefa falha e diz para montar antes a pasta no RTE. A pasta ssh nunca é enviada: o RTE mantém a sua própria
+chave privada e o seu `known_hosts` em `/home/node/.ssh`.
+
+**Hosts e tarefas.** Desde a 7.3.0, um RTE em qualquer modo regista os eventos estruturados de um playbook ao lado da sua saída de texto: cada play, task e
+resultado de host, e o resumo final, escritos pelo seu plugin de callback `af_events`. A página da tarefa mostra-os em **Hosts e tarefas** (consulte
+[Acompanhar uma tarefa](../jobs/following.html#hosts-and-tasks)).
+
+---
+
+## Rede
+
+O que abrir entre a aplicação, o RTE e os hosts geridos, por modo:
+
+| Modo | De | Para | Porta |
+|---|---|---|---|
+| Saída | O RTE | A aplicação, em `APP_URL` | A porta da aplicação (`443` atrás da maioria dos proxies) |
+| Entrada | Os nós da aplicação | O RTE, no endereço do seu runner | A `PORT` do RTE (`8000`) |
+| Base de dados (obsoleto) | O RTE, e os nós da aplicação e o worker | A base de dados, e o RTE | `3306`, e a `PORT` do RTE |
+| Todos os modos | O RTE | Os hosts geridos | ssh (`22`), WinRM, as suas APIs |
+
+Num modo socket, o RTE nunca se liga à base de dados. A sua API só responde ao socket e às sondas: `/live`, `/ready`, `/metrics`.
diff --git a/i18n/pt/_configure/rte/run.md b/i18n/pt/_configure/rte/run.md
new file mode 100644
index 0000000..c6df4a3
--- /dev/null
+++ b/i18n/pt/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Correr um RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# Correr um RTE
+{: .no_toc }
+
+As definições de cada modo, e como arrancar um RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Definições
+
+O que um RTE precisa depende do seu modo (consulte [Modos](modes.html)). Todos os RTE leem estas:
+
+| Variável | Significado |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | Desde a 7.3.0: `outbound` (liga-se à aplicação), `inbound` (a aplicação liga-se a ele) ou `database` (obsoleto, a predefinição em toda a 7.x) |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | O token entre a aplicação e o RTE, com pelo menos 16 caracteres; o RTE recusa-se a arrancar sem ele |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quantos playbooks corre ao mesmo tempo, `10` por predefinição (`0` significa sem limite). Uma tarefa para um RTE cheio espera até um playbook terminar |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Ao parar, quanto tempo espera pelos seus playbooks em execução, `25` por predefinição; os que ainda estiverem a correr terminam então como abandonados |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | Lida pelos nós da aplicação e pelo worker, não pelo RTE: quanto tempo uma tarefa espera por um RTE cheio ou a parar, `60` por predefinição |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH), `PROCESS_MAX_BUFFER` | A pasta dos playbooks e o limite de saída: lidas pelo RTE, por isso defina-as no seu ambiente |
+| `LISTEN_HOST` | Desde a 7.3.0: o endereço onde os seus listeners escutam, todas as interfaces por predefinição; `127.0.0.1` quando nada se liga a ele de fora (um RTE de saída) |
+
+Um RTE num modo socket, `outbound` ou `inbound`, lê também estas, e nenhuma `DB_*` nem `ENCRYPTION_SECRET`:
+
+| Variável | Significado |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | O endereço da aplicação tal como as pessoas a abrem, como `https://forms.example.com`. Saída: o endereço a que se liga. Entrada: o endereço da sua única chamada de registo |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1` (predefinição): o certificado da aplicação tem de ser válido. `0` aceita qualquer um, só dentro de uma rede de confiança |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | O nome do seu runner, que os formulários nomeiam com `runner:`. Não definida: o seu id de nó, `rte-<hostname>-<port>`, que muda com o contentor: defina-a em produção |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | Opcional, só da primeira vez: um join token, criado através da API, que aprova o seu runner de imediato em vez de esperar por um admin (consulte [Join tokens](../runners/registration.html#join-tokens)) |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | Entrada, quando pede para aderir: o endereço a que a aplicação se liga, como `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer` (predefinição): a aplicação envia os playbooks e os inventários com a tarefa. `local`: corre a partir das suas próprias pastas montadas |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | Onde a saída, os eventos e o fim de cada tarefa esperam até a aplicação os guardar, `<persistent>/rte-spool` por predefinição: mantenha-o num volume |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | Com `transfer`: onde se guardam as pastas que a aplicação enviou, `<persistent>/rte-files` por predefinição |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Com `transfer`: quanto podem ocupar essas pastas, `1024` por predefinição; as usadas há mais tempo saem primeiro, e `0` não guarda nenhuma |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | Lida pela aplicação, não pelo RTE: a maior pasta que envia com `transfer`, `512` por predefinição |
+
+Num RTE em modo socket, `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`, `RTE_FILES` e `RTE_CACHE_MB` também podem ser definidas na sua página de runner,
+no separador RTE: um valor aí prevalece sobre a variável, que então só preenche um campo deixado vazio (consulte
+[As definições de um RTE](../runners/runner-page.html#an-rtes-settings)). Um valor fora do intervalo é levado ao seu limite, e o RTE indica-o
+quando arranca.
+
+Um RTE em modo base de dados (obsoleto) lê em vez disso as definições da base de dados, e regista-se a si próprio:
+
+| Variável | Significado |
+|---|---|
+| `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD` | Os próprios valores da aplicação: o RTE lê as suas tarefas da base de dados e escreve lá a sua saída |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | O endereço em que a aplicação chama o RTE, como `http://rte:8000`. O runner recebe o nome do seu host (`rte`), por isso os formulários podem usar `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | Obsoleta na 7.3.0, com o modo base de dados: um RTE em modo socket adere com um join token em vez disso. `1` (predefinição): o RTE adiciona-se a si próprio em **Ligações > Runners** no seu arranque, e o primeiro torna-se o runner predefinido. `0`: adicione-o lá você mesmo, ou no [config seed](../seed/) |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | O próprio valor da aplicação, necessário só para se registar (o token do runner é guardado cifrado); deixe-a de fora com `RTE_REGISTER=0` |
+
+Em modo base de dados, sem `RTE_URL` o RTE regista o seu endereço IP e a sua porta com o nome `rte-<hostname>-<port>`, que mudam quando
+o contentor é recriado: defina `RTE_URL` em produção. O worker remove um runner que o RTE registou ele próprio 10 minutos depois do
+último heartbeat do RTE.
+
+---
+
+## Arrancá-lo
+
+O RTE corre os playbooks, por isso precisa da sua pasta ssh, com a chave privada e o `known_hosts` que os playbooks usam, e de uma pasta persistente
+para o seu spool e para os ficheiros que a aplicação envia. Escolha o modo:
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">Saída</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">Entrada</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">Base de dados (obsoleto)</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+Arranque o RTE em qualquer host que chegue à aplicação, com o seu próprio token e o nome que o seu runner recebe:
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Liga-se à aplicação e pede para aderir: **Ligações > Runners** mostra o runner `rte-dmz` como a aguardar aprovação, e o seu registo mostra
+a impressão digital do seu token. Verifique que a sua revisão mostra a mesma impressão digital, e depois clique em **Aprovar** (consulte
+[Aprovar um RTE](../runners/registration.html#approving-an-rte)): passa a receber tarefas, iniciando sessão com o seu próprio `RTE_TOKEN`.
+Para um arranque sem intervenção, adicione `-e RTE_JOIN_TOKEN=<a join token, afj_...>`, que o aprova de imediato. Nada precisa de chegar a este
+host: não publique nenhuma porta. Só `/live`, `/ready` e `/metrics` escutam na sua `PORT`, para as sondas.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+Arranque o RTE onde a aplicação chega a ele. Este corre ao lado da aplicação e corre os playbooks a partir das pastas dela (`RTE_FILES=local`):
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Depois dê à aplicação o seu runner: no [config seed](../seed/), uma credencial RTE e um runner de entrada que inicia sessão com ela:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+Ou adicione os mesmos dois à mão: a credencial em **Ligações > Credenciais**, tipo RTE, e o runner em
+**Ligações > Runners**, tipo RTE, modo **Entrada**, com essa credencial. Para deixar antes o RTE pedir para aderir, arranque-o com
+`APP_URL` e `RTE_URL`, e aprove-o em **Ligações > Runners** (consulte [Entrada](modes.html#inbound)).
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+Obsoleto desde a 7.3.0 e removido na 8.0.0. O RTE corre os playbooks a partir do seu próprio disco, por isso monte nele também o volume persistente da aplicação
+(playbooks, repositórios, ficheiros carregados) e a sua pasta ssh. Um exemplo Docker, com a aplicação acessível como `ansibleforms` na
+mesma rede:
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Mantenha um RTE de entrada fora da rede pública: o seu socket responde a qualquer chamador que tenha o token. `docker stop` só espera 10 segundos antes de
+matar um contentor, por isso dê ao RTE um tempo de paragem mais longo (`--stop-timeout`, ou `stop_grace_period` no compose) ou baixe
+`RTE_DRAIN_SECONDS`. O Kubernetes espera 30 segundos por predefinição.
+
+O [instalador](../installation/installer.html) configura um RTE de saída ou de entrada num servidor próprio, com Docker, Podman ou
+[sem contentores](../installation/native.html), e mostra a impressão digital para o aprovar. Para correr um RTE noutro centro de dados
+à mão, siga [Outro centro de dados](another-datacenter.html).
diff --git a/i18n/pt/_configure/rte/several.md b/i18n/pt/_configure/rte/several.md
new file mode 100644
index 0000000..04e7f96
--- /dev/null
+++ b/i18n/pt/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: Vários RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# Vários RTE
+{: .no_toc }
+
+Quantos playbooks corre um RTE, mais RTE como runners ou réplicas, e o que acontece quando um para ou morre
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Várias tarefas num RTE
+
+Um RTE corre até [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) playbooks lado a lado, 10 por
+predefinição (`0` significa sem limite). Uma tarefa para um RTE cheio não é reclamada. Num modo socket, a aplicação não a envia enquanto o último
+relatório de saúde do RTE não mostrar nenhuma vaga livre, e um RTE que está cheio ou a parar responde `refused` por estar ocupado; em modo base de dados o RTE responde
+`503`. Em ambos os casos, a aplicação escreve `Waiting for a free slot on RTE <name>` uma vez na saída e volta a oferecer a tarefa a cada 10 segundos,
+durante no máximo [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) (60 por predefinição). Depois a tarefa falha com
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*. Uma tarefa abortada enquanto espera termina `aborted` sem nunca
+chegar ao RTE.
+
+---
+
+## Vários RTE
+
+A aplicação não distribui tarefas pelos runners por si só: cada tarefa vai para um runner, o que o formulário nomeia ou o
+predefinido. Mais contentores RTE ajudam de duas formas:
+
+* **Como runners próprios** : cada RTE tem o seu próprio `RTE_NAME` e adere como runner próprio: pede para aderir e um admin
+  aprova-o, ou apresenta um join token (consulte [Registo](../runners/registration.html)). Um formulário escolhe um com `runner: <name>`,
+  por exemplo um RTE com as collections da VMware, ou um noutra zona de rede; os outros correm no RTE predefinido
+* **Como réplicas atrás de um endereço** (só em modo base de dados) : vários contentores RTE com o mesmo `RTE_URL` e o mesmo `RTE_TOKEN`,
+  como os pods atrás de um Service do Kubernetes, partilham um runner, e o endereço distribui as chamadas por eles. Uma réplica cheia responde
+  `503`, e a tentativa seguinte pode ir parar a outra. A aplicação acompanha uma tarefa pela base de dados, por isso não importa que réplica
+  responde às suas chamadas de estado
+
+Num modo socket (consulte [Modos](modes.html)), um runner tem um socket para um RTE, e um segundo RTE que inicia sessão com o mesmo
+`RTE_NAME` fica com o socket do primeiro. Dê a cada RTE um nome e um runner próprios, e deixe os formulários escolher entre eles com
+`runner:`.
+
+Cada RTE em modo base de dados escreve um heartbeat na base de dados a cada 10 segundos, e um que se regista a si próprio verifica a sua linha de runner a cada
+30 segundos. Para um RTE num modo socket, o nó da aplicação que tem o seu socket escreve o heartbeat por ele a cada 20 segundos, enquanto o
+socket está aberto. A página **Estado** lista todos os RTE com a sua versão. O worker remove um runner que um RTE em modo base de dados registou
+ele próprio quando esse RTE não escreveu nenhum heartbeat durante 10 minutos, e quando o runner predefinido é uma linha dessas cujo RTE parou, o RTE seguinte
+que verifica fica com a predefinição. Um runner do config seed, adicionado à mão ou que aderiu por um socket nunca é removido dessa forma.
+
+---
+
+## Quando um RTE para ou morre
+
+**Quando um RTE para.** Com `SIGTERM` (`docker stop`, uma atualização gradual, uma redução de escala) o RTE deixa de aceitar tarefas: `/ready` responde `503`,
+e uma tarefa nova é recusada por estar ocupado (`503` em modo base de dados), por isso a aplicação espera, ou em modo base de dados o endereço envia-a para outra
+réplica. Os playbooks em execução têm [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) para terminar, 25 por predefinição,
+e depois o RTE sai.
+
+**Quando um RTE morre.** Um contentor morto (sem memória, um nó perdido, o fim do tempo de paragem) leva consigo os seus playbooks: nada
+os passa para outro RTE, e nada os volta a correr. As suas tarefas terminam como `abandoned`, pelo próprio RTE ou pela aplicação quando ele
+volta com o mesmo id, que um contentor reiniciado mantém (`rte-<hostname>-<port>`), ou pelo worker, quando o heartbeat do RTE
+tem dois minutos. Verifique nos hosts geridos o que o playbook fez antes de o lançar de novo.
+
+**Enquanto um RTE está em baixo.** Num modo socket, uma tarefa nova para ele espera pelo seu socket, até `RTE_QUEUE_MINUTES` e mais um minuto, e depois
+falha com *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*.
+Em modo base de dados falha de imediato com *the RTE at ... is unreachable*, a menos que outra réplica responda no seu endereço.
diff --git a/i18n/pt/_configure/runners.md b/i18n/pt/_configure/runners.md
new file mode 100644
index 0000000..639e113
--- /dev/null
+++ b/i18n/pt/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: Runners
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# Runners
+{: .no_toc }
+
+Onde as tarefas correm: contentores de ambiente de execução para playbooks, e AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins para templates
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: adicione os runners onde as suas tarefas correm, escolha o predefinido de cada tipo, aprove os RTE que pedem para aderir, e teste-os.
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [A página de runners](runners/list.html) | A lista de runners, adicionar um, ativar ou desativar um, e o predefinido de cada tipo |
+| [Tipos de runner](runners/types.html) | Os produtos que um runner pode ser, o seu endereço e o seu acesso |
+| [Registo](runners/registration.html) | Como um RTE pede para aderir e é aprovado, join tokens para instalações sem intervenção, e o modo base de dados |
+| [A página de um runner](runners/runner-page.html) | Os separadores de um runner, o modo e a ligação de um RTE, e Testar ligação |
+| [Quem gere os runners](runners/permissions.html) | Quem pode adicionar, alterar e testar runners |
+
+
+---
+
+## Como funciona
+
+Desde a versão 7, a aplicação não corre nada ela própria: cada tarefa corre num **runner**, adicionado em **Ligações > Runners**.
+O tipo de um formulário decide de que tipo de runner precisa:
+
+| Tipo de formulário | Corre num runner do tipo | O que corre |
+|---|---|---|
+| `ansible` | RTE | Um playbook, num contentor de ambiente de execução |
+| `awx`, `aap`, `ascender` | AWX (as variantes AWX, AAP e Ascender) | Um job template ou workflow template |
+| `semaphore` | Semaphore | Um template do Semaphore UI |
+| `rundeck` | Rundeck | Um job do Rundeck |
+| `jenkins` | Jenkins | Um job do Jenkins |
+
+Um formulário `workflow` ou `subform` não tem runner próprio: cada nó de um [workflow](workflows/) escolhe o seu. Um nó
+com um `runner:` corre nesse runner (um RTE, ou um template ou job no AWX, Semaphore, Rundeck ou Jenkins), qualquer outro no
+RTE predefinido, por isso os nós de uma tarefa podem correr em runners diferentes. O formulário `multistep`, obsoleto desde a 7 e
+substituído pelos workflows, funciona da mesma forma: cada um dos seus passos corre no runner de que o seu próprio tipo precisa.
+
+Um formulário escolhe o seu runner de uma de duas formas:
+
+- **Pelo nome**: `runner: <name>` no formulário, num nó de workflow, ou num passo de um multistep obsoleto (também nas
+  definições do formulário no designer). O runner tem de ser do tipo de que o formulário precisa, ou a tarefa falha. O antigo `awx: <name>`
+  continua a funcionar, regista um aviso de obsolescência, e desaparece na 8.
+- **Como predefinido**: um formulário que não nomeia nenhum runner corre no runner predefinido do seu tipo. Sem nenhum, a tarefa falha
+  com uma mensagem que diz que tipo de runner adicionar.
+
+Um runner desativado em **Ligações > Runners** não recebe nenhuma tarefa, nem pelo nome nem como predefinido: a tarefa falha e diz para o ativar
+ou para nomear outro runner (consulte [Predefinido e Ativado](runners/list.html#default-and-enabled)).
+
diff --git a/i18n/pt/_configure/runners/list.md b/i18n/pt/_configure/runners/list.md
new file mode 100644
index 0000000..f0e87c6
--- /dev/null
+++ b/i18n/pt/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: A página de runners
+parent: Runners
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# A página de runners
+{: .no_toc }
+
+A lista de runners, adicionar um, ativar ou desativar um, e o predefinido de cada tipo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A lista
+
+A página em **Ligações > Runners** lista todos os runners com estas colunas:
+
+| Coluna | Significado |
+|---|---|
+| Ativado | Se recebe tarefas. Um runner desativado não recebe nenhuma tarefa, mesmo sendo o predefinido do seu tipo. |
+| Nome | Como os formulários se referem a ele, com `runner: <name>`. |
+| Tipo | RTE, AWX, Ansible Automation Platform, Ascender, Semaphore UI, Rundeck ou Jenkins. O runner predefinido do seu tipo tem uma pílula **Predefinido** a seguir. |
+| Descrição | Para que serve. |
+
+**Colunas** acrescenta mais duas, desligadas por predefinição: **Modo**, o modo de um RTE (Saída, Entrada ou Base de dados (obsoleto), consulte
+[Modos](../rte/modes.html)), e **Ligação**, se um nó da aplicação tem um socket para um RTE num modo socket: **Ligado** ou
+**Não ligado**.
+
+A partir da 7.3.0, os runners a aguardar aprovação não estão na lista mas num aviso acima dela, consulte [Aprovar um RTE](registration.html#approving-an-rte).
+**Adicionar runner** abre uma caixa de diálogo em passos: **Runner** (nome e descrição), **Tipo** e **Credenciais**, com um passo **Modo** depois de
+**Tipo** para um RTE (Saída, a predefinição para um novo, Entrada ou Base de dados (obsoleto)): quatro passos para um RTE, três para os
+outros. No passo **Tipo**, cada produto tem uma dica: a do RTE dá o seu nome completo, *Ambiente de execução*. Uma linha abre a página
+própria do runner, e o seu menu oferece:
+
+| Ação | O que faz |
+|---|---|
+| Editar | Abre a sua página |
+| Testar ligação | Verifica que responde e aceita a sua credencial, consulte [Testar ligação](runner-page.html#test-connection) |
+| Ativar, Desativar | Ativa-o ou desativa-o, conforme não esteja |
+| Alterar credenciais | Abre o separador Credenciais da sua página |
+| Eliminar | Remove-o |
+
+---
+
+## Predefinido e Ativado
+
+O predefinido de cada tipo é onde correm os formulários desse tipo quando não nomeiam nenhum runner:
+
+| Predefinido para | Onde correm estes formulários quando não nomeiam nenhum runner |
+|---|---|
+| Formulários de playbook | Formulários `ansible`, num RTE |
+| Formulários AWX, AAP e Ascender | Formulários `awx`, `aap` e `ascender`, num runner AWX |
+| Formulários Semaphore | Formulários `semaphore` |
+| Formulários Rundeck | Formulários `rundeck` |
+| Formulários Jenkins | Formulários `jenkins` |
+
+O primeiro runner de um tipo torna-se o seu predefinido, por isso um único runner por tipo não precisa de nenhum passo extra. Para tornar outro runner o predefinido,
+ligue o interruptor **É predefinido** na sua página (consulte [A página de um runner](runner-page.html)).
+
+Um runner desativado continua listado com as suas definições, mas nenhuma tarefa vai para ele, nem como predefinido do seu tipo. Uma tarefa para ele falha com
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*.
+Ative-o ou desative-o com **Ativar** ou **Desativar** no menu da sua linha, ou com o interruptor **Ativado** na sua página. Um runner novo fica ativado, e os
+runners que existiam antes da 7.3.0 ficam ativados depois da atualização. O [config seed](../seed/example.html) pode desativar um com
+`enabled: false`.
diff --git a/i18n/pt/_configure/runners/permissions.md b/i18n/pt/_configure/runners/permissions.md
new file mode 100644
index 0000000..111c2af
--- /dev/null
+++ b/i18n/pt/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Quem gere os runners
+parent: Runners
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# Quem gere os runners
+{: .no_toc }
+
+Quem pode adicionar, alterar e testar runners
+{: .fs-6 .fw-300 }
+
+Um runner recebe as credenciais de todas as tarefas que corre, por isso só a função **admin** adiciona, altera, ativa ou desativa e elimina runners,
+e aprova ou rejeita um RTE que pediu para aderir. Os utilizadores com acesso às definições veem-nos e podem testá-los, mas não os podem alterar.
+
+Um runner declarado no [config seed](../seed/) é só de leitura nesta página: altere-o antes no ficheiro de seed.
diff --git a/i18n/pt/_configure/runners/registration.md b/i18n/pt/_configure/runners/registration.md
new file mode 100644
index 0000000..7d68813
--- /dev/null
+++ b/i18n/pt/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: Registo
+parent: Runners
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# Registo
+{: .no_toc }
+
+Como um RTE pede para aderir e é aprovado, join tokens para instalações sem intervenção, e o modo base de dados
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Pedir para aderir
+
+Desde a 7.3.0, um RTE num modo socket (`outbound` ou `inbound`) que a aplicação ainda não conhece pede para aderir, e um admin aprova-o.
+Contacta a aplicação com o seu próprio `RTE_TOKEN` e o seu `RTE_NAME`: um RTE de saída quando se liga à aplicação pela primeira vez, um de entrada na sua única
+chamada de registo. Sem join token, a aplicação então:
+
+1. Guarda o `RTE_TOKEN` do RTE numa nova credencial do tipo RTE chamada `<name>-rte` (com um número acrescentado quando esse nome está ocupado), e
+   para um RTE de entrada o seu endereço, `RTE_URL`
+2. Adiciona um runner com o nome de `RTE_NAME`, tipo RTE, no modo do RTE, que inicia sessão com essa credencial, marcado como **A aguardar aprovação**
+   e desativado. A sua descrição indica o host de onde fez o pedido
+
+Um RTE de saída fica ligado enquanto espera, mas não recebe nenhuma tarefa. A aplicação não se liga a um de entrada até ele ser aprovado. Ambos registam
+que esperam que um admin os aprove em **Ligações > Runners**, com a impressão digital do seu token.
+
+Um RTE de entrada com um `RTE_URL` `https://` envia também o seu certificado quando pede para aderir, e a aplicação fixa-o: a partir daí a
+aplicação só se liga a esse RTE quando ele apresenta o mesmo certificado, por isso um autoassinado funciona sem CA (consulte [Entrada](../rte/modes.html#inbound)).
+
+No máximo 20 RTE aguardam aprovação ao mesmo tempo: os seguintes são recusados até alguns serem aprovados ou rejeitados. Um pedido que ninguém trate em
+24 horas é removido pelo worker, com a sua credencial.
+
+Um RTE com o nome de um runner que a aplicação já conhece, mas com outro token, é recusado e não pede para aderir. Dê-lhe o token desse runner,
+ou elimine o runner para que ele peça para aderir. Um [join token](#join-tokens) só ajuda enquanto esse runner ainda aguarda aprovação.
+
+---
+
+## Aprovar um RTE
+
+Os runners a aguardar aprovação saem da lista de **Ligações > Runners** para um aviso laranja acima dela, como
+**2 Runners aguardam aprovação**, com uma linha por runner: o seu nome, host, endereço IP, modo, endereço e impressão digital.
+O sino do cabeçalho conta-os, para os utilizadores que podem ver os runners (consulte [o sino](../jobs/#the-jobs-page)).
+
+Um clique no aviso abre a caixa de diálogo **Rever aprovação** para cada runner, um após o outro; um clique num nome abre só esse.
+A sua página mostra os mesmos factos numa caixa amarela, **Este RTE pediu para aderir**. Verifique que é um que você arrancou antes de o aprovar:
+
+| Campo | O que mostra |
+|---|---|
+| Impressão digital | Os primeiros 8 dígitos hexadecimais do SHA-256 do seu `RTE_TOKEN`, como `abcd-ef12`. O RTE regista-a no seu arranque, e o [instalador](../installation/installer.html#a-runner) mostra-a no fim. Tem de ser a mesma |
+| Impressão digital do certificado | Na caixa de diálogo, para um RTE de entrada por HTTPS: os primeiros 8 dígitos hexadecimais do SHA-256 do certificado que a aplicação fixa (os seus bytes DER), como `abcd-ef12`. O RTE regista-a no seu arranque e o [instalador](../installation/installer.html#a-runner) mostra-a no fim. Tem de ser a mesma |
+| Host | O host onde corre |
+| Endereço IP | O endereço a partir do qual contactou a aplicação |
+| Modo | Saída ou Entrada |
+| Uri | O endereço de um RTE de entrada, onde a aplicação se liga a ele |
+| Versão | A sua versão |
+| Pedido em | Quando pediu para aderir |
+
+**Aprovar** e **Rejeitar**, na caixa de diálogo ou na caixa da sua página, decidem:
+
+| Ação | O que acontece |
+|---|---|
+| Aprovar | O runner é ativado e recebe tarefas a partir de agora. Torna-se o predefinido do seu tipo quando não há nenhum |
+| Rejeitar | O runner é removido com a sua credencial, e o seu socket é fechado. O RTE pode pedir para aderir de novo; fica então outra vez a aguardar aprovação |
+
+Só um admin aprova ou rejeita um RTE.
+
+---
+
+## Join tokens
+
+Um join token aprova um RTE de imediato, para instalações sem intervenção: um RTE arrancado com
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN), ou um Runner instalado com o `--join` do instalador, apresenta-o uma vez
+e o seu runner é adicionado já ativado, sem esperar. Os join tokens não têm página na interface: um admin cria-os através da
+[API REST](../api/), em `/api/v2/runner`:
+
+| Chamada | O que faz |
+|---|---|
+| `POST /api/v2/runner/jointoken` | Cria um join token. O corpo contém o seu `name`, e opcionalmente `expiresInHours` (nenhum: nunca expira) e `maxUses` (nenhum: qualquer número de RTE) |
+| `GET /api/v2/runner/jointoken` | Lista os join tokens, os mais recentes primeiro, com as suas utilizações e se ainda podem ser usados; nunca os próprios tokens |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | Revoga-o: deixa de adicionar runners, e continua na lista |
+| `DELETE /api/v2/runner/jointoken/<id>` | Elimina-o |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+A resposta contém o token, que começa por `afj_`, só desta vez: só o seu SHA-256 é guardado. Um RTE que o apresenta recebe a mesma
+credencial e o mesmo runner que um que [pede para aderir](#asking-to-join), já ativado, e a sua descrição nomeia o join token. A partir daí o
+RTE inicia sessão com o seu próprio token, por isso o join token pode expirar ou ser revogado sem o afetar. Revogar ou eliminar um join token
+mantém os runners que adicionou.
+
+Um join token nunca dá um token novo a um runner aprovado. Quando já existe um runner RTE com esse nome:
+
+| O runner | O que acontece |
+|---|---|
+| Aguarda aprovação | Recebe o token novo na sua credencial, e continua a aguardar a aprovação de um admin |
+| Está aprovado | Recusado com `409`: *runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*. O join token não é consumido |
+| Vem do [config seed](../seed/) | Recusado: *runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+Um RTE instalado de novo com um token novo inicia portanto sessão com o token da credencial do seu runner, ou um admin altera esse token
+em **Ligações > Credenciais**, ou elimina o runner para que o RTE adira como novo.
+
+---
+
+## Registo em modo base de dados
+
+Um RTE em modo base de dados, obsoleto desde a 7.3.0, regista-se a si próprio por predefinição, no seu `RTE_URL` ou então no seu próprio endereço e porta. O
+worker remove um runner destes quando o seu RTE não escreveu nenhum heartbeat durante 10 minutos. Um runner adicionado à mão, pelo config seed ou por um
+RTE num modo socket nunca é removido dessa forma.
+
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER), que liga ou desliga este registo, está obsoleta na 7.3.0 com o
+modo base de dados: um RTE num modo socket pede para aderir, ou adere com um join token. Para gerir esses runners você mesmo entretanto, arranque o
+RTE com `RTE_REGISTER=0` e adicione-o aqui com tipo RTE, modo **Base de dados (obsoleto)**, e uma credencial RTE com o seu endereço e o
+mesmo token. Para o passar para um modo socket, consulte [Modos](../rte/modes.html#database-deprecated).
diff --git a/i18n/pt/_configure/runners/runner-page.md b/i18n/pt/_configure/runners/runner-page.md
new file mode 100644
index 0000000..369a4b0
--- /dev/null
+++ b/i18n/pt/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: "A página de um runner"
+parent: Runners
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# A página de um runner
+{: .no_toc }
+
+Os separadores de um runner, o modo, a ligação e as definições de um RTE, e Testar ligação
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Separadores
+
+A página de um runner mostra os passos da sua caixa de diálogo como separadores, mais o que corre nele:
+
+| Separador | O que contém |
+|---|---|
+| Detalhes | O nome e a descrição, o interruptor **É predefinido** e o interruptor **Ativado**, iguais para todos os tipos de runner |
+| Tipo | O produto, como na caixa de diálogo. Para um RTE também o seu **Modo**: **Base de dados (obsoleto)**, **Entrada** ou **Saída**, o `RTE_MODE` com que o seu RTE corre (consulte [Modos](../rte/modes.html)) |
+| RTE | Só de um RTE: o seu **Modo** por extenso e, num modo socket, a sua **Ligação** e as suas definições (consulte [As definições de um RTE](#an-rtes-settings)) |
+| Credenciais | A **Credencial** com que inicia sessão, uma credencial de Ligações > Credenciais do tipo do runner, que contém o seu token ou acesso e o endereço do seu servidor. A de um RTE contém o seu `RTE_TOKEN`, e o endereço do RTE a menos que seja de saída. **Projeto** para Semaphore, Rundeck e Jenkins |
+| Formulários | Os formulários que correm nele, e como: **Nomeia-o** ou **Como runner predefinido**. Uma linha abre o formulário |
+| Trabalhos | As últimas 100 tarefas que correram nele, com o seu estado, início, fim e duração. Uma linha abre a tarefa |
+
+Cada separador tem o seu próprio endereço, como `/settings/runners/<id>/rte`, por isso uma ligação ou um marcador abre-o. Um runner sem esse separador abre em
+Detalhes.
+
+Os dois interruptores do separador Detalhes são guardados de imediato. **É predefinido** torna o runner o predefinido do seu tipo; é desligado tornando
+outro runner o predefinido. **Ativado** ativa ou desativa o runner: desativado, nenhuma tarefa vai para ele, nem como predefinido do seu tipo (consulte
+[Predefinido e Ativado](list.html#default-and-enabled)).
+
+Um RTE que pediu para aderir abre com uma caixa amarela, **Este RTE pediu para aderir**, com a sua impressão digital e o que disse de si próprio, e
+**Aprovar** e **Rejeitar** (consulte [Aprovar um RTE](registration.html#approving-an-rte)). Um runner do [config seed](../seed/) indica-o
+no topo da sua página, e é só de leitura.
+
+---
+
+## As definições de um RTE
+
+O separador RTE gere um RTE a partir da aplicação, sem editar o seu ambiente na máquina onde corre.
+
+**Ligação.** Um RTE num modo socket mostra um distintivo: **Ligado** ou **Não ligado**. Ao passar o ponteiro, **Ligado** mostra o nó da aplicação
+que tem o seu socket, a versão do RTE, e quantas das suas tarefas estão a correr. **Não ligado** significa que nenhum nó da aplicação tem um socket para ele:
+verifique se o RTE está a correr, o seu endereço ou `APP_URL`, e o seu token.
+
+**Definições.** Um RTE em modo de saída ou de entrada tem quatro definições, cada uma vazia por predefinição:
+
+| Definição | Equivale a | O que faz |
+|---|---|---|
+| Máximo de trabalhos em simultâneo | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | Quantos playbooks corre ao mesmo tempo, `10` por predefinição; `0` significa sem limite |
+| Cache de ficheiros | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | Quanto dos ficheiros de tarefas que a aplicação lhe enviou guarda, em MB, `1024` por predefinição; `0` não guarda nada |
+| Tempo de espera ao parar | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | Quanto tempo um RTE a parar espera pelos seus playbooks em execução, `25` segundos por predefinição |
+| Ficheiros de trabalho | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **Transferência**: a aplicação envia os ficheiros de uma tarefa com a tarefa. **Local**: corre a partir das suas próprias pastas montadas |
+
+**Que valor prevalece.** Um valor na página prevalece sobre a mesma variável definida no RTE. Um campo deixado vazio usa a variável própria do RTE,
+senão a predefinição. Por baixo de cada campo a página diz qual: **Substitui RTE_MAX_JOBS definida no RTE (3).**, ou **Vazio: o RTE usa a sua
+própria RTE_MAX_JOBS, 3.**; o texto de exemplo mostra o valor que um campo vazio representa.
+
+**Como chegam ao RTE.** As definições são guardadas com o runner na base de dados da aplicação. A aplicação envia-as pelo socket do RTE
+quando ele se liga e sempre que são guardadas, e o RTE aplica-as de imediato: uma cache mais pequena é reduzida, um novo limite conta a partir da
+tarefa seguinte. O RTE guarda-as só em memória e não escreve nenhum ficheiro: depois de um reinício recebe-as de novo ao ligar-se, antes da sua primeira tarefa.
+
+Um RTE em modo base de dados (obsoleto) não tem socket: lê estas definições das suas próprias variáveis, e o separador indica-o.
+
+---
+
+## Testar ligação
+
+Os botões no canto superior direito atuam sobre o runner tal como está guardado.
+
+Ao lado de **Guardar** estão **Testar ligação** e **Eliminar**, e no separador Credenciais **Adicionar credencial**, que cria uma credencial do
+tipo do runner e a escolhe. Um token ou uma palavra-passe nunca voltam a ser mostrados depois de guardados: altere-os na credencial.
+
+**Testar ligação** verifica que o runner responde e aceita o seu token ou acesso, e indica-o numa mensagem: **Runner connection is
+OK**, ou porque falhou. Não corre nenhuma tarefa. Para um RTE verifica também o contrato que o RTE fala (consulte
+[O contrato](../rte/images.html#the-contract)):
+
+| RTE | O que o teste lê | Quando falha |
+|---|---|---|
+| Saída ou Entrada | Quem tem o seu socket, tal como cada nó da aplicação o regista, e o que o RTE disse quando se ligou. Não chama nada | Nenhum nó da aplicação tem um socket para ele: *the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*, ou para um de entrada, *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*. Ou o RTE fala outro contrato que não o 3 |
+| Base de dados (obsoleto) | O `/rte/v1/health` do RTE, chamado com o seu token | O RTE não responde no seu endereço, recusa o token, ou fala outro contrato que não o 2 |
+
+O distintivo **Ligação** do separador RTE mostra o mesmo estado do socket sem um teste.
diff --git a/i18n/pt/_configure/runners/types.md b/i18n/pt/_configure/runners/types.md
new file mode 100644
index 0000000..00dcb94
--- /dev/null
+++ b/i18n/pt/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: Tipos de runner
+parent: Runners
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# Tipos de runner
+{: .no_toc }
+
+Os produtos que um runner pode ser, o seu endereço e o seu acesso
+{: .fs-6 .fw-300 }
+
+O passo **Tipo** oferece uma opção por produto, cada uma com uma dica; a do RTE escreve o seu nome por extenso, *Ambiente de execução*. O AAP e o
+Ascender são guardados como um runner do tipo `awx` com uma variante (`aap` ou `ascender`), que é também o que o config seed usa:
+
+| Tipo | Exemplo de Uri | Projeto | Autenticação |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | O `RTE_TOKEN` do RTE |
+| AAP | `https://aap.example.com/api/controller/v2` | | Um token de API, ou um utilizador e uma palavra-passe |
+| Ascender | `https://ascender.example.com/api/v2` | | Um token de API, ou um utilizador e uma palavra-passe |
+| AWX | `https://awx.example.com/api/v2` | | Um token de API, ou um utilizador e uma palavra-passe |
+| Jenkins | `https://jenkins.example.com` | A pasta onde estão os jobs (opcional) | Um utilizador e o token de API desse utilizador |
+| Rundeck | `https://rundeck.example.com` | O nome do projeto | O token de API de um utilizador |
+| Semaphore | `https://semaphore.example.com` | O id do projeto, o número em `/project/<id>` | O token de API de um utilizador |
+
+Um endereço de AWX, AAP ou Ascender leva o seu caminho de API: `/api/v2`, ou `/api/controller/v2` para o AAP 2.5 e posteriores.
+Um RTE é a imagem do AnsibleForms arrancada com `AF_ROLE=rte`; como correr um está descrito em
+[Ambientes de execução](../rte/).
diff --git a/i18n/pt/_configure/secret-stores/cyberark.md b/i18n/pt/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..d3ce165
--- /dev/null
+++ b/i18n/pt/_configure/secret-stores/cyberark.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: CyberArk
+parent: Cofres de segredos
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+Leia as credenciais do CyberArk Central Credential Provider (CCP)
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **Experimental.** Ainda não foi testado contra uma instalação real da CyberArk; por favor, partilhe o que descobrir.
+
+O CCP é a interface REST do Application Access Manager da CyberArk.
+
+---
+
+## Campos do cofre
+
+Além dos [campos que todos os cofres têm](./#adding-a-store), um cofre CyberArk tem estes campos:
+
+| Campo | Significado |
+|---|---|
+| Credencial | Uma credencial **CyberArk** de [Ligações > Credenciais](../credentials.html): o URL base do CCP, ex. `https://ccp.example.com` (é acrescentado `/AIMWebService/api/Accounts`), as suas definições de TLS, o seu AppID (a aplicação definida para o AnsibleForms na CyberArk), e um certificado e uma chave de cliente em PEM, só quando o AppID os exige. |
+
+---
+
+## Referência do segredo
+
+A referência do segredo identifica a conta como pares chave-valor separados por `;`:
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- Chaves permitidas: `Safe`, `Folder`, `Object`, `UserName`, `Address`, `Database`, `PolicyID`,
+  `Reason`, `Query`, `QueryFormat`, `ConnectionTimeout`, `FailRequestOnPasswordChange`.
+- `Query=` passa o resto da referência como uma consulta nativa do CCP, com `QueryFormat=Exact`
+  a menos que defina outra coisa.
+- Um `AppID` na referência é ignorado: é sempre usado o AppID do cofre.
+- A palavra-passe da conta (`Content`) torna-se a palavra-passe; `UserName`, `Address`, `Port` e
+  `Database` preenchem o utilizador, o host, a porta e o nome da base de dados.
+
+---
+
+## Opções extra
+
+As opções extra do cofre definem-se como um objeto JSON:
+
+| Chave | Significado |
+|---|---|
+| `reason` | Enviada como `Reason` quando a referência não tem nenhuma, para a auditoria da CyberArk. |
+| `check_ref` | Uma referência que **Testar ligação** lê de facto. Sem ela, o teste só verifica que o CCP responde e aceita o AppID. |
+| `timeout_ms` | Tempo limite do pedido, predefinição 10000. |
+
+Por exemplo, para enviar um motivo e deixar **Testar ligação** ler uma conta de teste:
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/pt/_configure/secret-stores/hashicorp-vault.md b/i18n/pt/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..33a319a
--- /dev/null
+++ b/i18n/pt/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: Cofres de segredos
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+Leia as credenciais do HashiCorp Vault, de KV v1 ou v2 ou de um motor de segredos dinâmicos
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Campos do cofre
+
+Além dos [campos que todos os cofres têm](./#adding-a-store), um cofre HashiCorp Vault tem estes campos:
+
+| Campo | Significado |
+|---|---|
+| Credencial | Uma credencial **HashiCorp Vault** de [Ligações > Credenciais](../credentials.html): o endereço do Vault, as suas definições de TLS, e o token como palavra-passe, com acesso de leitura aos caminhos que as suas credenciais usam. **Adicionar credencial** cria uma desse tipo. O AnsibleForms não renova o token. |
+| Namespace | O namespace do Vault Enterprise, enviado como `X-Vault-Namespace`. Aparece quando **Vault Enterprise** está ligado, no passo **Tipo**. |
+| Versão KV | `2` (predefinição) ou `1`. |
+| Mount predefinido | Usado para uma referência sem barra, ex. `myapp` passa a `secret/data/myapp`. |
+
+A referência do segredo é o caminho, ex. `secret/myapp/prod`. Para KV v2, o segmento `/data/`
+é inserido quando o omite.
+
+---
+
+## Credenciais dinâmicas de base de dados
+
+Uma referência da forma `<mount>/creds/<role>`, ex. `database/creds/readonly`, lê de um
+motor de segredos dinâmicos como o motor de base de dados do Vault. O Vault cria então uma nova conta
+de base de dados em cada leitura, válida durante a lease.
+
+- Uma conta é reutilizada durante 80% da sua lease, não o tempo de cache; com cache `0`, cada consulta lê uma nova.
+- O Vault só devolve um utilizador e uma palavra-passe: coloque o resto da ligação na linha da credencial.
+- A lease nunca é revogada antecipadamente; a conta expira quando o Vault termina a lease.
diff --git a/i18n/pt/_configure/secret-stores/index.md b/i18n/pt/_configure/secret-stores/index.md
new file mode 100644
index 0000000..24b5b98
--- /dev/null
+++ b/i18n/pt/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: Cofres de segredos
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# Cofres de segredos
+{: .no_toc }
+
+Leia as credenciais de um gestor de segredos em vez de as guardar no AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: ligue um gestor de segredos, e deixe as credenciais ler dele o seu utilizador e a sua palavra-passe.
+
+---
+
+## Como funciona
+
+Um **cofre de segredos** é uma ligação a um gestor de segredos, adicionada em
+**Ligações > Cofres de segredos**. Uma **credencial** pode então nomear um cofre e um sítio dentro dele
+(a *referência do segredo*). Quando um formulário, um playbook ou uma expressão usa essa credencial:
+
+- o **utilizador** e a **palavra-passe** são lidos do cofre, sempre (dentro do tempo de cache do cofre);
+- o **host**, a **porta** e a **base de dados** continuam a ser os da linha da credencial. Quando a linha deixa
+  um deles vazio e o segredo o contém, é usado o valor do segredo.
+
+Os formulários continuam a referir-se à credencial pelo nome, por isso mover uma palavra-passe para um cofre não altera
+nada nos seus formulários.
+
+| Tipo de cofre | Estado |
+|---|---|
+| HashiCorp Vault (KV v1 e v2, autenticação por token) | disponível |
+| Credenciais dinâmicas do HashiCorp Vault (`<mount>/creds/<role>`) | experimental |
+| CyberArk Central Credential Provider (CCP) | experimental |
+
+---
+
+## Adicionar um cofre
+
+A partir da 7.3.0, só um admin pode adicionar, alterar ou eliminar um cofre, já que o seu token ou a sua chave são enviados para o seu endereço. Todos os cofres têm estes campos:
+
+| Campo | Significado |
+|---|---|
+| Nome | Como as credenciais se referem ao cofre. |
+| Tipo | O gestor de segredos. |
+| Credencial | Como e onde o cofre inicia sessão: uma credencial de [Ligações > Credenciais](../credentials.html), no passo **Credenciais**, do tipo **HashiCorp Vault** (o seu token e endereço) ou **CyberArk**. Contém o URL base, ex. `https://vault.example.com:8200`, e as definições de TLS: ignorar a verificação do certificado, ou um CA bundle em PEM para uma CA privada. Ela própria não pode ler de um cofre de segredos. |
+| Cache (segundos) | Durante quanto tempo um segredo lido é reutilizado. `0` lê-o em cada utilização. Predefinição 60. |
+| Opções extra (JSON) | Opções específicas do tipo, como objeto JSON. |
+
+Até à 7.2.0, o endereço, o token e as definições de TLS eram campos do cofre. A atualização para a 7.3.0 move-os para a sua
+credencial, chamada `<store>-token` (ou `<store>-appid` para CyberArk), consulte [Endereços nas credenciais](../credentials/types.html#addresses-in-credentials).
+
+**Testar ligação** verifica o acesso sem ler nenhum segredo. A página **Estado** verifica todos os cofres, e avisa 7 dias
+antes de um token do Vault expirar.
+
+Cada gestor de segredos tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | KV v1 e v2 com autenticação por token, e credenciais dinâmicas de base de dados |
+| [CyberArk](cyberark.html) | O Central Credential Provider (CCP) do Application Access Manager da CyberArk |
+
+---
+
+## Usar um cofre
+
+### Numa credencial
+
+Em **Ligações > Credenciais**, no passo **Armazenamento** da credencial, escolha **Cofre de segredos**, depois escolha o
+**Cofre de segredos** e preencha a **Referência**. O utilizador e a palavra-passe passam então a ser lidos do cofre, não escritos.
+
+### Diretamente, sem linha de credencial
+
+Em qualquer sítio onde é aceite um nome de credencial, pode em vez disso referir-se diretamente a um cofre (`fnCredentials`, `fnRestBasic`,
+as `credentials:` de um formulário, o `dbConfig` de uma consulta).
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+Sem linha de credencial, um segredo de base de dados precisa de pelo menos um `db_type` e um host, por exemplo:
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+Sem `db_type`, o segredo é uma credencial simples (utilizador, palavra-passe e quaisquer outras chaves), e uma consulta sobre ele assume `mysql`.
+
+### Nomes das chaves
+
+Um segredo é mapeado para uma credencial com estes aliases. As outras chaves passam tal como estão.
+
+| Campo da credencial | Chaves aceites no segredo |
+|---|---|
+| `user` | `user`, `username`, `login` |
+| `password` | `password`, `token`, `api_key`, `apikey`, `secret` |
+| `host` | `host`, `address` |
+| `port` | `port` |
+| `db_name` | `db_name`, `database` |
+| `db_type`, `secure` | o mesmo nome (só segredos diretos) |
+
+Para uma linha de credencial, o host, a porta e o nome da base de dados do segredo só são usados onde a
+linha os deixa vazios.
+
+Um segredo com uma estrutura diferente pode ser remodelado com uma expressão `jq`, passada como terceiro argumento de
+`fnCredentials`:
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## No config seed
+
+Os cofres também podem ser declarados no config seed, como os outros objetos de administração:
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+O cofre inicia sessão com a sua credencial: uma `vault` contém o endereço do Vault em `url` e o token como palavra-passe, uma `cyberark`
+o AppID e o endereço do CCP. Sem credencial, são usados o `url` e o `token` próprios do cofre.
+Para mais detalhes, consulte [Config seed](../seed).
+
+---
+
+## Atualizar a partir das variáveis VAULT_*
+
+Antes da 7, o único cofre era um HashiCorp Vault configurado com variáveis de ambiente
+`VAULT_*`, e uma credencial apontava para ele com **Vault path**.
+
+- **As variáveis são importadas uma vez** como um cofre chamado `vault`; remova-as depois.
+- **As credenciais com um `vault_path`** passam a usar esse cofre; `vault_path` desaparece na 8.
diff --git a/i18n/pt/_configure/security/hardening.md b/i18n/pt/_configure/security/hardening.md
new file mode 100644
index 0000000..be1cd05
--- /dev/null
+++ b/i18n/pt/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: Endurecimento
+parent: Segurança
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# Endurecimento
+{: .no_toc }
+
+A conta de admin, os limites de início de sessão, a base de dados, as expressões, os dados das tarefas, a política do navegador, as funcionalidades opcionais e as opções de função
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A conta de admin
+
+A conta de admin local é criada no primeiro arranque a partir de [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+e [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD), cuja predefinição é `AnsibleForms!123`.
+
+* Um início de sessão com a palavra-passe predefinida pública `AnsibleForms!123` tem de a alterar primeiro: até lá o servidor responde
+  a todos os pedidos exceto à alteração da palavra-passe com `403` (código `password_change_required`), e o navegador mostra uma
+  página de alteração de palavra-passe que não pode ser fechada. A nova palavra-passe não pode voltar a ser a predefinida.
+* `ADMIN_PASSWORD` só é lida quando a conta é criada pela primeira vez: defina o seu próprio valor antes do primeiro arranque.
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` repõe a palavra-passe para `ADMIN_PASSWORD` em cada
+  arranque. Use-a só para recuperar uma palavra-passe perdida, depois retire-a e reinicie.
+* Defina primeiro os dois segredos mestres: consulte [Segredos e cifragem](secrets.html).
+* Quando o início de sessão por LDAP ou SSO estiver a funcionar, mantenha o admin local só para emergências, com uma palavra-passe longa guardada no seu cofre.
+
+---
+
+## Limites de início de sessão e palavras-passe
+
+A adivinhação de palavras-passe é travada por três limites. As falhas são contadas na base de dados, por isso todos os nós da aplicação veem as
+mesmas tentativas, e todos os limites se aplicam sem reiniciar:
+
+| Variável | Predefinição | O que faz |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | Depois deste número de inícios de sessão falhados, uma conta local ou LDAP fica bloqueada durante `LOGIN_LOCKOUT_MINUTES`. |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | Um endereço com este número de inícios de sessão falhados dentro de `LOGIN_LOCKOUT_MINUTES` fica retido até essa janela terminar: um endereço que tenta muitas contas. |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | Durante quanto tempo uma conta fica bloqueada, e a janela em que as falhas são contadas. |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | Pedidos por minuto de um endereço, por nó da aplicação, no início de sessão, no fim de sessão, na renovação do token e nos callbacks de início de sessão único. |
+
+Uma conta bloqueada ou um endereço retido recebe `429` com um cabeçalho `Retry-After`, antes de qualquer palavra-passe ser verificada e
+quer a conta exista quer não; acima de `AUTH_RATE_LIMIT` a resposta também é `429`. Um início de sessão bem-sucedido limpa a
+contagem da conta, tal como um admin a definir a palavra-passe do utilizador. `0` desliga um limite; `LOGIN_LOCKOUT_MINUTES=0`
+desliga tanto o bloqueio como o limite por endereço.
+
+`LOGIN_MAX_FAILURES_PER_IP` e `AUTH_RATE_LIMIT` contam por endereço do cliente: atrás de um reverse proxy, defina `TRUST_PROXY`
+para que o endereço seja o do cliente e não o do proxy, consulte [Endereços dos clientes](../production/reverse-proxy.html#client-addresses).
+
+Uma palavra-passe local definida através da aplicação, para um utilizador novo, por um admin ou pelos utilizadores ao alterarem a sua, tem de ter
+pelo menos [`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) caracteres (`8` por predefinição,
+`0` não verifica o comprimento). Não pode ser o nome de utilizador nem a palavra-passe predefinida pública. `ADMIN_PASSWORD` não é verificada.
+
+---
+
+## A base de dados
+
+O AnsibleForms guarda todas as credenciais e tarefas na sua base de dados MySQL, por isso mantenha essa base de dados fora da rede:
+
+* O projeto docker-compose publica o MySQL no host (`MYSQLDB_LOCAL_PORT`, `3306`) e vem com a palavra-passe de root
+  `AnsibleForms!123`. Remova esse mapeamento de porta, ou associe-o a `127.0.0.1`, e altere a palavra-passe.
+* Ligue-se com uma conta dedicada em vez de `root`, definida em [`DB_USER`](../customization/server.html#env_DB_USER) e
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD). Só precisa de permissões no esquema `AnsibleForms`:
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  Isso cobre a criação do esquema (incluindo o `CREATE DATABASE`), a sua atualização com patches nas atualizações, e as
+  [cópias de segurança](../production/backups.html) e os restauros, que correm com o mesmo utilizador: o dump é feito com
+  `--no-tablespaces`, por isso não é necessária nenhuma permissão ao nível do servidor como `PROCESS`. Substitua `%` pelo endereço da
+  aplicação sempre que puder. Um utilizador com permissões em todas as bases de dados, como tem o `root`, transforma uma falha na aplicação numa
+  falha em todo o servidor de base de dados: a página **Estado** avisa disso na sua verificação **Utilizador da base de dados**, e o registo
+  em cada arranque.
+* Defina [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) como `0` quando o esquema já existir.
+  Criar o esquema elimina primeiro todas as tabelas; com `0`, nem o arranque inicial nem o endpoint `/api/v2/schema`
+  o podem executar.
+
+---
+
+## Expressões e chamadas de saída
+
+As expressões do servidor correm no servidor para qualquer utilizador com sessão iniciada, por isso o sanitizador e os filtros de saída importam:
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) : `strict` ou `paranoid`, nunca `legacy`, que deixa os utilizadores correr código no servidor.
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) : hosts a que as expressões REST não podem chegar, ex. `169.254.169.254,127.0.0.0/8`.
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) : quando definida, as expressões REST só podem chegar
+  a estes hosts e intervalos. A lista de negados prevalece sobre ela.
+
+Ambas as listas cobrem só as funções auxiliares REST do próprio AnsibleForms; os playbooks correm fora delas e não são filtrados.
+
+A partir da 7.3.0, as funções auxiliares REST verificam o certificado do endpoint, como fazem todas as outras ligações.
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` desliga a verificação: use-a só para
+endpoints com um certificado autoassinado.
+
+---
+
+## Dados das tarefas
+
+Os extravars e a saída das tarefas são guardados na base de dados e mostrados a todos os que podem ver a tarefa:
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) : os extravars cuja chave corresponde são
+  mostrados como `********`. A predefinição é `password|secret|token`; os campos de palavra-passe são sempre mascarados. Alargue-a com
+  os nomes que os seus formulários usam, por exemplo `password|secret|token|apikey|passphrase`.
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS) : reduz o objeto `ansibleforms_user`
+  enviado com cada tarefa, que de outra forma contém todos os grupos a que o utilizador pertence.
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) só esconde tarefas ruidosas; esconda os segredos com `no_log`.
+
+---
+
+## A Content-Security-Policy
+
+A interface é servida com um cabeçalho Content-Security-Policy, que limita o que uma página pode carregar e correr no navegador:
+
+* Os scripts vêm só da própria aplicação, por isso um script injetado numa página não corre.
+* Nenhum outro site pode mostrar a interface numa frame.
+* Permite o que a aplicação precisa: expressões locais dos formulários avaliadas no navegador (`'unsafe-eval'`), estilos
+  inline, imagens de qualquer URL (imagens de formulários e de categorias), e os workers do editor de código.
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) é `1` por predefinição e deve
+continuar assim. Com `0`, a política é enviada como `Content-Security-Policy-Report-Only`: a consola do navegador lista o que
+bloquearia, e nada é bloqueado. Use `0` só numa configuração que ainda não funciona com a política, como um reverse proxy
+que injeta um script próprio. Uma alteração na página de definições aplica-se sem reiniciar.
+
+---
+
+## As páginas de definições e o designer
+
+Os administradores podem alterar grande parte da configuração a partir do navegador. Restrinja isso onde a configuração vive noutro sítio:
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0` : definições só de leitura, para um [ambiente gerido](../seed/environment-and-audit.html).
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0` : remove o designer integrado quando os formulários
+  são mantidos em git.
+
+---
+
+## Funcionalidades opcionais
+
+Estas funcionalidades estão desligadas por predefinição. Ligue-as só quando as usar; uma alteração na página de definições aplica-se sem reiniciar:
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) : serve o [servidor MCP](../mcp/) em `/api/v2/mcp`,
+  para que os clientes MCP possam lançar formulários com o token de um utilizador.
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT) : o [assistente de chat](../chat/). As definições dos formulários
+  e os valores a ser preenchidos são enviados para o fornecedor de modelo configurado.
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) funciona ao contrário: é `enforce`
+por predefinição, por isso o servidor recusa um lançamento cujos valores violem as regras do formulário, incluindo os lançamentos através da API REST.
+Mantenha-a assim: `log` só regista o que seria recusado e `off` não verifica nada, consulte [Validação no lançamento](../launch-validation/).
+
+---
+
+## Opções de função
+
+Algumas opções de função no [config.yaml](../config/roles.html) dão mais do que o seu nome sugere. Conceda-as com cuidado:
+
+| Opção | Porque importa |
+|--------|----------------|
+| `allowScheduledJobs` | Um utilizador com ela vê e pode alterar todos os agendamentos, e um agendamento corre com direitos de admin, para qualquer formulário. Trate-a como uma opção de nível de admin. |
+| `allowBackupOps` | Inclui o **restauro**, que substitui toda a base de dados. |
+| `showSettings` | Abre as páginas de administração. Sem a função admin, não pode alterar as contas e os grupos que a função admin nomeia, consulte [Utilizadores e grupos](../users-and-groups.html#accounts-that-grant-admin). |
+| `showLogs` | Mostra o registo do servidor, que pode conter nomes de host, nomes de utilizador e detalhes de erros. |
+| `showConnectionsSettings` | Abre as páginas de ligações: credenciais, runners, canais de notificação e mais. Adicionar, alterar e eliminar runners e cofres de segredos continua a caber a um admin, tal como as credenciais das ligações e dos inícios de sessão. Num repositório, adicioná-lo ou eliminá-lo e alterar o seu endereço, ramo ou flags `use_for_*` continua a caber a um admin. |
+| `showAllJobLogs` | Mostra as tarefas de todos os utilizadores, não só as do próprio utilizador. |
+| `manageAllJobs` | Aborta, elimina e relança as tarefas de todos os utilizadores. |
+| `allowApiTokens` | Deixa o utilizador criar tokens de API que duram até [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 por predefinição). Terminar sessão com um token ou revogá-lo termina-o, e uma alteração de palavra-passe termina todos os tokens do utilizador, consulte [Tokens](secrets.html#tokens). |
+| `extendedTokenExpiration` | Com `allowApiTokens`, deixa também o utilizador criar tokens de API que nunca expiram. |
+| `allowFileUploads` | Deixa o utilizador carregar ficheiros pelos campos de ficheiro de um formulário. Ligada para todos os utilizadores a menos que uma função a desligue. |
+| `allowChat`, `allowMcp` | Deixam o utilizador usar o assistente de chat e o servidor MCP, quando estão ligados. `allowChat` está ligada para todos os utilizadores a menos que uma função a desligue, e `allowMcp` segue `allowChat` a menos que uma função a defina. |
+
+Um utilizador sem a função `admin` não recebe nenhuma das opções de nível de admin acima a menos que uma função lha dê. Quando a função `admin`
+não define opções, os seus utilizadores recebem `showSettings`, `showDesigner`, `showLogs`, `showAuditLog`, `allowBackupOps`,
+`allowJobRelaunch`, `showAllJobLogs`, `manageAllJobs` e `allowScheduledJobs`. `allowApiTokens` e
+`extendedTokenExpiration` ficam desligadas mesmo para a função `admin`: defina-as nas funções que precisam delas.
+
+Quando várias funções de um utilizador definem a mesma opção, `false` ganha. As opções da função `default` só preenchem as opções
+que nenhuma das funções próprias do utilizador define; nunca se sobrepõem a elas.
diff --git a/i18n/pt/_configure/security/https.md b/i18n/pt/_configure/security/https.md
new file mode 100644
index 0000000..4df71ec
--- /dev/null
+++ b/i18n/pt/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: Segurança
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+Sirva HTTPS a partir da própria aplicação, e substitua o certificado de exemplo
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Onde termina o TLS
+
+O TLS pode terminar num de três sítios, e só o primeiro envolve as definições desta página:
+
+* **no AnsibleForms**, com `HTTPS=1` : HTTPS na [`PORT`](../customization/server.html#env_PORT) com os ficheiros abaixo, como o docker-compose faz na 443.
+* **num reverse proxy**, com `HTTPS=0` atrás dele : consulte [Reverse proxy](../production/reverse-proxy.html).
+* **num ingress do Kubernetes** : consulte o separador Ingress de [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) e o README do chart.
+
+Pode combinar o primeiro com os outros dois para cifrar também o troço entre o proxy e a aplicação.
+
+---
+
+## As definições
+
+Três variáveis controlam o HTTPS na aplicação:
+
+| Variável | Predefinição | Significado |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` serve HTTPS, `0` HTTP simples |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | A chave privada, PEM |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | O certificado do servidor, PEM |
+
+Na imagem do contentor, a pasta persistente é `/app/dist/persistent`, por isso os ficheiros predefinidos são
+`/app/dist/persistent/certificates/key.pem` e `cert.pem`. Com o projeto docker-compose, isso corresponde a `data/certificates/`
+no host.
+
+---
+
+## O certificado de exemplo
+
+Quando `HTTPS=1` e um dos ficheiros falta no arranque, o AnsibleForms regista `httpsKey or httpsCert not found, copying from
+templates` e copia uma chave e um certificado de exemplo da imagem para os caminhos configurados. Se essa cópia falhar, a
+aplicação para.
+
+Esse certificado é autoassinado para `CN=ansibleforms`, e é **o mesmo em todas as instalações**: a sua chave privada
+vem dentro da imagem pública. Serve para uma primeira experiência, mas os navegadores avisam sobre ele e qualquer pessoa pode decifrar o tráfego
+que ele protege. Substitua-o antes de a instância conter credenciais reais.
+
+---
+
+## Substituir o certificado
+
+Use um certificado emitido para o nome de host que os utilizadores escrevem, pela sua CA ou por um cliente ACME, em formato PEM.
+O ficheiro do certificado pode conter a cadeia completa: o certificado do servidor primeiro, depois os intermédios.
+
+1. Copie os ficheiros para a pasta persistente, ou para qualquer sítio onde a aplicação os possa ler:
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. Se estiverem noutro sítio, defina `HTTPS_KEY` e `HTTPS_CERT` com os seus caminhos **dentro do contentor**.
+
+3. Reinicie a aplicação, que lê ambos os ficheiros no arranque.
+
+Para um certificado autoassinado rápido seu (uma instância de teste, ou o troço atrás de um proxy), o `openssl` cria um:
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## Renovar sem reiniciar
+
+Alterar `HTTPS_KEY` ou `HTTPS_CERT` nas páginas de definições recarrega a chave e o certificado no servidor em execução.
+As ligações novas recebem o certificado novo, as abertas mantêm o antigo. Se os ficheiros novos não puderem ser lidos ou não formarem um par
+válido, o certificado atual mantém-se e é registado um aviso.
+
+Isto só funciona quando as páginas de definições podem escrever o ambiente ([`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+é `1`) e a variável não está definida no ambiente real. Quando uma renovação substitui os ficheiros nos mesmos
+caminhos, reinicie a aplicação.
diff --git a/i18n/pt/_configure/security/index.md b/i18n/pt/_configure/security/index.md
new file mode 100644
index 0000000..a66ee79
--- /dev/null
+++ b/i18n/pt/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: Segurança
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# Segurança
+{: .no_toc }
+
+Proteja uma instância: a conta de admin, os seus segredos, o HTTPS e o que os utilizadores e os formulários podem fazer
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores que preparam uma instância para produção, e para revisões de segurança de uma instância existente.
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Endurecimento](hardening.html) | A conta de admin, os limites de início de sessão, a base de dados, as expressões, os dados das tarefas, a política do navegador, as funcionalidades opcionais e as opções de função |
+| [HTTPS](https.html) | Onde termina o TLS, servir HTTPS a partir da aplicação, e substituir o certificado de exemplo |
+| [Segredos e cifragem](secrets.html) | `ENCRYPTION_SECRET`, `ACCESS_TOKEN_SECRET`, e a duração dos tokens |
+
+Páginas relacionadas: [Autenticação](../authentication/) para os métodos de início de sessão, [Validação no lançamento](../launch-validation/) para as
+verificações do lado do servidor em cada lançamento, e as [Variáveis de segurança](../customization/security.html).
diff --git a/i18n/pt/_configure/security/secrets.md b/i18n/pt/_configure/security/secrets.md
new file mode 100644
index 0000000..5de6f93
--- /dev/null
+++ b/i18n/pt/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: Segredos e cifragem
+parent: Segurança
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# Segredos e cifragem
+{: .no_toc }
+
+Os dois segredos mestres, o que protegem, e quanto tempo duram as sessões e os tokens
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Os dois segredos mestres
+
+Dois segredos protegem tudo o resto. Defina ambos antes de a instância conter dados reais, guarde-os fora da instância,
+e nunca os altere de ânimo leve:
+
+| Segredo | O que protege | Se não estiver definido | Se se perder ou for alterado |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | Todas as palavras-passe e tokens guardados na base de dados: credenciais, a palavra-passe de bind do LDAP, tokens dos runners, client secrets do SSO, endereços de webhooks do Slack e do Teams, a chave de API do chat | É usada uma chave predefinida, que é pública no código-fonte | Perdido: todos os segredos guardados têm de ser introduzidos de novo. Alterado: a partir da 7.3.0 todos os segredos guardados são cifrados de novo, consulte [abaixo](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | A assinatura dos access tokens e refresh tokens, incluindo os [tokens de API](../profile/api-token.html) de longa duração | É gerado um segredo aleatório em cada arranque, por isso cada reinício termina a sessão de todos | Todas as sessões e todos os tokens de API deixam de ser válidos |
+
+Ambos são registados como um aviso `[SECURITY]` no arranque enquanto faltarem. As páginas de definições recusam-se a editá-los,
+a API nunca os devolve, e as cópias de segurança deixam-nos de fora de propósito, por isso um `ENCRYPTION_SECRET` perdido não pode ser recuperado
+de lado nenhum: guarde uma cópia no seu gestor de segredos. O segredo de cifragem é usado como uma chave de 32 caracteres; um valor mais curto ou
+mais longo é preenchido ou cortado.
+
+Alterar `ACCESS_TOKEN_SECRET` termina de imediato todas as sessões e todos os tokens de API. Para terminar os tokens de um utilizador ou de uma
+sessão, use as revogações descritas em [Tokens](#tokens).
+
+---
+
+## Alterar o segredo de cifragem
+
+A partir da 7.3.0, definir ou alterar `ENCRYPTION_SECRET` já não faz perder os segredos guardados. No arranque seguinte, o worker volta a cifrar
+cada um deles com a chave nova, numa só transação da base de dados, antes de qualquer outra coisa escrever um segredo:
+
+| Situação | O que definir |
+|---|---|
+| A instância correu sem `ENCRYPTION_SECRET`, com a chave predefinida pública | Só `ENCRYPTION_SECRET`: os segredos são cifrados de novo a partir da chave predefinida |
+| A instância correu com uma chave sua | `ENCRYPTION_SECRET` com a chave nova e [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) com a antiga, para esse arranque |
+
+Quando os segredos guardados foram cifrados com uma chave que não é nenhuma das duas, nada é alterado e a aplicação recusa-se a arrancar até
+`ENCRYPTION_SECRET_PREVIOUS` indicar essa chave. Remova `ENCRYPTION_SECRET_PREVIOUS` depois de o arranque os ter cifrado de novo, e defina o
+novo `ENCRYPTION_SECRET` em todos os nós da aplicação, no worker e em todos os RTE em modo base de dados que se registam a si próprios. Esse
+autorregisto (`RTE_REGISTER`) está obsoleto na 7.3.0: um RTE que adere com um join token (`RTE_JOIN_TOKEN`) em modo
+socket não precisa de `ENCRYPTION_SECRET`, consulte [Modos do RTE](../rte/modes.html).
+
+---
+
+## Tokens
+
+Um início de sessão devolve um access token de curta duração e um refresh token mais longo, que o navegador usa para obter um novo par:
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION) : `30m` por predefinição. Mais curto
+  limita o uso de um token intercetado.
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) : `24h` por
+  predefinição. É quanto tempo um navegador inativo fica com sessão iniciada.
+* A opção de função `allowApiTokens` deixa um utilizador pedir um token de API válido durante um número de dias, e
+  `extendedTokenExpiration` acrescenta um que nunca expira. Conceda-as só a funções que precisem de acesso à API a partir de scripts.
+  Na [página de perfil](../profile/api-token.html), um token é criado a partir de uma sessão de navegador que iniciou sessão há no máximo 10 minutos,
+  e nunca a partir de outro token de API. Um token que nunca expira dura 50 anos, e os eventos abaixo continuam a terminá-lo.
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) : `90` por predefinição. O máximo que um token de API
+  dura: um pedido mais longo é reduzido a este valor.
+
+Um token é um JWT assinado, mas o servidor mantém também uma lista de tokens revogados, partilhada por todos os nós da aplicação, para que um token
+possa terminar antes de expirar:
+
+| Evento | O que termina |
+|-------|-----------|
+| Terminar sessão | Todos os tokens desse início de sessão: o access token, o seu refresh token, e um token de API quando é usado para terminar sessão |
+| Uma alteração de palavra-passe, pelo utilizador ou por um admin | Todos os tokens do utilizador emitidos antes da alteração, tokens de API incluídos, em todos os dispositivos |
+| O interruptor **Permitir início de sessão** de um utilizador desligado (utilizador local, LDAP ou SSO), ou um utilizador local eliminado | Todos os tokens do utilizador |
+| **Terminar sessões** na página de um utilizador LDAP ou SSO | Todos os tokens do utilizador; pode voltar a iniciar sessão a menos que esteja bloqueado |
+| **Revogar** num token de API, na página de perfil ou no separador **Tokens de API** do utilizador | Esse token de API, de imediato |
+
+Um script termina o seu próprio token de API terminando sessão com ele: `POST /api/v2/auth/logout` com o token no
+cabeçalho `Authorization`.
diff --git a/i18n/pt/_configure/seed/environment-and-audit.md b/i18n/pt/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..69e9e01
--- /dev/null
+++ b/i18n/pt/_configure/seed/environment-and-audit.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: Edição e auditoria
+parent: Config seed
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# Edição e auditoria
+{: .no_toc }
+
+Bloquear as páginas de definições, e o que o registo de auditoria regista
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Desligar a edição do ambiente
+
+`ALLOW_ENV_EDIT=0` torna as páginas de definições só de leitura. Todas as variáveis continuam a ser mostradas com
+o valor em vigor e o motivo por que não podem ser alteradas, e o endpoint de gravação responde com
+403.
+
+Use-o sempre que o ambiente estiver declarado noutro sítio. Caso contrário, a página de definições escreve
+`persistent/.env`, que num volume efémero se perde silenciosamente no reinício seguinte, e num
+volume duradouro se afasta do manifesto que deveria ser a referência.
+
+{: .note }
+> As cópias de segurança incluem `persistent/.env` como `managed.env`, para que uma reconstrução recupere as definições da base de dados e
+> dos caminhos. **`ENCRYPTION_SECRET` e `ACCESS_TOKEN_SECRET` são retiradas**:
+> o dump ao lado contém todas as credenciais guardadas como texto cifrado AES, e escrever a chave que
+> o decifra na mesma pasta faria com que bastasse uma cópia da cópia de segurança para as ler todas. Defina
+> essas duas no host de destino; um comentário no ficheiro indica-o.
+>
+> O que resta pode ainda conter credenciais (`DB_PASSWORD`, `METRICS_TOKEN`, um `VAULT_TOKEN` antigo), por isso o ficheiro é
+> escrito com `0600`. Restaurá-lo é um passo opcional à parte e não faz parte de um restauro normal,
+> porque o host da base de dados e os caminhos que contém descrevem a máquina de onde veio a cópia de segurança. A
+> caixa de diálogo de restauro lista o ficheiro e oferece o seu próprio botão *Restaurar ambiente*
+> (`POST /api/v2/backup/:folder/restore-env`), que guarda o ficheiro anterior como `.env.bak`.
+
+---
+
+## O que fica registado
+
+Cada aplicação que altera alguma coisa escreve uma entrada `seed.apply` no registo de auditoria, que nomeia
+os objetos criados, atualizados, libertados e purgados. Os valores nunca são registados, porque a maioria
+deles são segredos. Uma aplicação sem efeito não escreve nada, o que mantém o registo significativo. Uma
+verificação periódica que encontra o ficheiro inalterado não tem efeito, por isso o registo não ganha uma linha a cada minuto.
+
+Uma aplicação pedida através do endpoint é registada duas vezes de propósito, e as duas linhas
+registam coisas diferentes: `config-seed.apply.create` é **quem** a pediu, `seed.apply` é
+**o que** alterou.
+
+A página Estado mostra o seed duas vezes: uma **verificação** de que o ficheiro continua legível e válido,
+e de que o último recarregamento teve sucesso, e uma linha de **informação** que diz quantos registos
+possui atualmente. A verificação é o único sítio que indica quando o ficheiro em disco e a configuração
+em vigor divergiram, porque um recarregamento falhado deixa a instância a correr.
diff --git a/i18n/pt/_configure/seed/example.md b/i18n/pt/_configure/seed/example.md
new file mode 100644
index 0000000..0a86d4b
--- /dev/null
+++ b/i18n/pt/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Exemplo
+parent: Config seed
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# Exemplo
+{: .no_toc }
+
+Um ficheiro de seed completo, secção a secção
+{: .fs-6 .fw-300 }
+
+---
+
+O ficheiro de seed seguinte declara todas as secções exceto `oauth2` e a obsoleta `awx`; os segredos vêm de variáveis de
+ambiente como `${SEED_AWX_TOKEN}`:
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` é um de:
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom` : qualquer outro endpoint compatível com OpenAI
+
+Tal como `ldap`, a secção `chat` é uma linha única, por isso todos os campos são obrigatórios exceto os
+opcionais; um campo opcional omitido fica sem alterações.
+
+O assistente de chat precisa também de `ENABLE_CHAT=1`; consulte a página [Assistente de chat](../chat).
+
+Desde a 7.3.0, um runner inicia sessão com uma credencial do seu tipo, que contém o endereço do seu servidor em `url`. Um runner com o seu próprio `token`,
+ou `username` e `password`, continua a funcionar: o seed regista um aviso e transforma-os numa credencial dessas, com o nome do runner. Um
+runner que nomeia uma credencial `api` ou `userpass` também continua a funcionar, com um aviso: dê antes a essa credencial o tipo do runner.
+Ambos estão obsoletos desde a 7.3.0 e são removidos na 8.0.0. Um runner RTE sem `rte_mode` está em modo base de dados, obsoleto (consulte
+[Modos](../rte/modes.html)). Um runner com `enabled: false` não recebe nenhuma tarefa, nem como predefinido do seu tipo (consulte
+[Predefinido e Ativado](../runners/list.html#default-and-enabled)); sem `enabled`, o seed deixa-o como está.
+
+Um item de runner aceita estas chaves além de `name`, `type`, `description`, `credential`, `is_default` e `enabled`:
+
+| Chave | O que define |
+|---|---|
+| `rte_mode` | O modo de um RTE: `outbound`, `inbound` ou `database` (obsoleto, a predefinição) |
+| `rte_max_jobs` | O **Máximo de trabalhos em simultâneo** de um RTE em modo socket, de `0` a `10000` (`0`: sem limite) |
+| `rte_cache_mb` | A sua **Cache de ficheiros** em MB, de `0` a `1048576` (`0` não guarda nada) |
+| `rte_files` | Os seus **Ficheiros de trabalho**: `transfer` ou `local` |
+| `rte_drain_seconds` | O seu **Tempo de espera ao parar** em segundos, de `0` a `86400` |
+| `flavour` | Um runner `awx` que é um AAP ou um Ascender: `aap` ou `ascender`; nenhum para o AWX |
+| `project` | O id do projeto de um runner Semaphore, o nome do projeto de um runner Rundeck, a pasta de um runner Jenkins |
+| `uri`, `ignore_certs`, `ca_bundle` | O endereço e o TLS próprios do runner, de antes da 7.3.0: usados só enquanto a sua credencial não tiver `url` |
+
+As quatro definições `rte_*` são as do separador RTE da página do runner (consulte [As definições de um RTE](../runners/runner-page.html#an-rtes-settings)):
+prevalecem sobre as mesmas variáveis definidas no RTE, e um RTE em modo base de dados ignora-as. Um valor fora do seu intervalo faz falhar a
+validação do seed.
+
+Um RTE em modo base de dados pode registar-se a si próprio antes de o seed ser aplicado. Um runner RTE do seed cujo `uri` é o endereço em que um RTE destes
+se registou **adota** essa linha: fica com o nome e os campos declarados, e o worker deixa de o remover quando o RTE deixa de
+responder, em vez de haver um segundo runner para o mesmo RTE.
diff --git a/i18n/pt/_configure/seed/index.md b/i18n/pt/_configure/seed/index.md
new file mode 100644
index 0000000..07d6fec
--- /dev/null
+++ b/i18n/pt/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: Config seed
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# Config seed
+{: .no_toc }
+
+Declare os objetos de administração num ficheiro
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores que fazem o aprovisionamento a partir do git: declare os objetos de administração num ficheiro, para que uma instância possa ser reconstruída sobre uma base de dados vazia.
+
+---
+
+## O que abrange
+
+Defina `CONFIG_SEED_PATH` com um ficheiro YAML, e o AnsibleForms aplica-o no arranque. O ficheiro
+declara objetos que antes só existiam na base de dados:
+
+| Secção                  | O que declara                                                       |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | Onde as tarefas correm: RTE, AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins |
+| `secret_stores`         | Cofres de segredos (HashiCorp Vault, ...)                           |
+| `credentials`           | Credenciais                                                         |
+| `oauth2`                | Fornecedores SSO: Entra ID e OIDC                                   |
+| `repositories`          | Repositórios git                                                    |
+| `syslog_servers`        | Os servidores syslog que recebem o registo do servidor e as entradas de auditoria |
+| `notification_channels` | Servidores de correio, Slack, Teams, Telegram e webhooks para as notificações |
+| `labels`                | As etiquetas ao lado do logótipo do cabeçalho, a partir da 7.3.0    |
+| `ldap`                  | A configuração LDAP                                                 |
+| `settings`              | O URL público, e as definições de email usadas quando nenhum canal de email está ativo |
+| `chat`                  | O fornecedor de modelo do assistente de chat                        |
+| `awx`                   | Obsoleta desde a 7, removida na 8: use `runners` com `type: awx`    |
+
+Um seed escrito antes da 7 continua a funcionar: cada item da sua secção `awx` é aplicado como um runner do tipo `awx`, e o registo
+avisa em cada aplicação. Mova esses itens para `runners` com `type: awx` antes de atualizar para a 8.
+
+O seed **não** é o mesmo que o `config.yaml`, que contém as categorias, funções e constantes
+e tem o seu próprio `CONFIG_PATH`. Os dois são mantidos separados de propósito: o
+repositório que *contém* o `config.yaml` é um dos objetos que o seed declara, por isso o seed
+não pode viver dentro dele.
+
+Os utilizadores e os grupos ficam de fora: vêm do LDAP ou do SSO, e o primeiro admin de `ADMIN_USERNAME` / `ADMIN_PASSWORD`.
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Exemplo](example.html) | Um ficheiro de seed completo, secção a secção |
+| [Objetos geridos](managed-objects.html) | Como o seed é dono dos objetos que lista, e como mantém os segredos de fora |
+| [Recarregamento e arranque](reloading.html) | Alterar o ficheiro sem reiniciar, e o que acontece no arranque |
+| [Kubernetes](kubernetes.html) | Aprovisionar o AnsibleForms a partir de um ConfigMap e de Secrets |
+| [Edição e auditoria](environment-and-audit.html) | Bloquear as páginas de definições, e o que o registo de auditoria regista |
diff --git a/i18n/pt/_configure/seed/kubernetes.md b/i18n/pt/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..d00ecee
--- /dev/null
+++ b/i18n/pt/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: Config seed
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+Aprovisionar o AnsibleForms a partir de um ConfigMap e de Secrets
+{: .fs-6 .fw-300 }
+
+---
+
+Monte o seed a partir de um `ConfigMap` e os seus segredos a partir de um `Secret`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **Um pod, com `AF_ROLE` por definir.** Este pod corre a aplicação web e o worker num só processo. Os agendamentos, a cópia de segurança
+> noturna e o resto do trabalho em segundo plano só correm no processo que detém o bloqueio do worker na base de dados, o bloqueio do designer
+> é uma tabela da base de dados, e os playbooks correm num RTE, não neste pod. Mantenha mesmo assim `replicas: 1` com a estratégia
+> `Recreate`: numa atualização, o pod novo espera que o worker atualize o esquema, e o pod antigo mantém o
+> bloqueio do worker até parar. Para correr vários nós web, divida-os em nós `AF_ROLE=app` e um worker, como descreve
+> [Escalabilidade](../production/scaling.html).
+
+`ENCRYPTION_SECRET` tem de estar definida antes de qualquer credencial ser introduzida. Quando as credenciais vêm
+do seed, a base de dados passa na prática a ser uma cache, por isso rodá-la significa voltar a aplicar o
+seed em vez de voltar a introduzir tudo à mão.
+
+As duas sondas não precisam de início de sessão. Com um [`BASE_URL`](../customization/server.html#env_BASE_URL), os seus caminhos começam por ele, e
+[Monitorização](../production/monitoring.html) descreve o que cada uma verifica.
diff --git a/i18n/pt/_configure/seed/managed-objects.md b/i18n/pt/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..70e7e8e
--- /dev/null
+++ b/i18n/pt/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: Objetos geridos
+parent: Config seed
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# Objetos geridos
+{: .no_toc }
+
+Como o seed é dono dos objetos que lista, e como mantém os segredos de fora
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## As secções de linha única são tudo ou nada
+
+`ldap`, `settings` e `chat` são cada uma uma **linha única**, por isso o seed tem de declarar todos os seus campos; as outras secções são listas.
+
+Um seed que omite um campo recusa-se a arrancar e indica-o:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+Declare um valor vazio explicitamente com `""` ou `false`. Alguns campos são opcionais, e um que seja omitido fica sem alterações:
+
+| Secção | Campos opcionais |
+|---|---|
+| `ldap` | `description`, `credential` (uma credencial com que fazer bind) e `groupfilter` |
+| `chat` | `auth_type`, `api_version`, `request_user`, `ignore_certs` e `extra_headers` |
+| `settings` | Nenhum |
+
+`settings` cobre só os campos de email e o URL; todas as outras definições continuam editáveis.
+
+---
+
+## O ficheiro não contém segredos
+
+Cada `${VARIABLE}` é substituída por essa variável de ambiente (no Kubernetes, a partir de um `Secret`), por isso o ficheiro pode viver no Git.
+
+Uma variável não definida é um **erro fatal**, para que um marcador nunca possa acabar guardado como palavra-passe.
+
+As credenciais também podem usar um [cofre de segredos](../secret-stores) (`secret_store`, `secret_ref`); `vault_path` desaparece na 8.
+
+---
+
+## Objetos geridos
+
+Um objeto que vem do seed fica marcado como **gerido**:
+
+- É imposto em **cada** arranque, para que o ficheiro continue a ser a referência.
+- É só de leitura: a API responde **403**, a interface desativa Editar e Eliminar, e a sua própria página diz que vem do ficheiro de config
+  seed e é só de leitura.
+- Só o seed pode definir ou retirar a marca.
+
+Os objetos criados à mão **nunca são tocados**, a menos que o seed declare o mesmo nome. Esse registo é então **adotado**:
+os campos declarados são impostos e passa a ser só de leitura. A adoção é registada como aviso e no registo de auditoria.
+
+Aplicar o seed é idempotente: os registos que já correspondem ficam como estão, por isso um reinício normalmente indica `0 updated`.
+
+Um repositório declarado cuja working tree falta é **clonado de novo** em cada arranque, por isso um primeiro clone falhado é
+tentado de novo. A linha *Repositórios* da página Estado mostra qualquer repositório sem working tree.
+
+### Remover um objeto
+
+Remover um objeto do ficheiro **liberta-o**: o registo fica e volta a ser editável. Eliminar uma secção inteira
+faz o mesmo.
+
+Acrescente `prune: true` a uma secção de lista para **eliminar** os registos geridos que o ficheiro já não declara:
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` nunca elimina um registo criado à mão.
+
+### Desligar o seed
+
+Retirar `CONFIG_SEED_PATH` **não** liberta nada: o seed deixa de ser aplicado, e os registos que geria continuam geridos
+e só de leitura. Para os voltar a editar, liberte-os primeiro: aponte `CONFIG_SEED_PATH` para um ficheiro sem eles (um ficheiro vazio não declara
+nada e liberta todos os registos), deixe-o aplicar num arranque ou num recarregamento, e depois retire a variável. Os registos libertados ficam como
+estão, e passam a ser editáveis.
diff --git a/i18n/pt/_configure/seed/reloading.md b/i18n/pt/_configure/seed/reloading.md
new file mode 100644
index 0000000..6439075
--- /dev/null
+++ b/i18n/pt/_configure/seed/reloading.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Recarregamento e arranque
+parent: Config seed
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# Recarregamento e arranque
+{: .no_toc }
+
+Alterar o ficheiro sem reiniciar, e o que acontece no arranque
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Alterar o ficheiro sem reiniciar
+
+O seed é lido de novo a cada `CONFIG_SEED_RELOAD_SECONDS` (60 por predefinição, `0` desliga-o)
+e aplicado de novo quando o seu conteúdo mudou. Uma alteração enviada para o git chega assim
+automaticamente a uma instância em execução: no Kubernetes, um `ConfigMap` é montado de novo no pod em
+cerca de um minuto, e a verificação seguinte apanha-o. Não há rollout nem reinício, e nenhum
+hook precisa de chamar nada.
+
+Para um ficheiro inalterado, a verificação calcula um hash e para, por isso nunca reescreve uma linha que já
+aplicou.
+
+Para aplicar o ficheiro de imediato em vez de esperar pela verificação seguinte, use uma destas formas:
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+Ambas **forçam** uma aplicação mesmo quando o ficheiro não mudou. Uma aplicação forçada volta a impor um
+registo gerido que foi editado diretamente na base de dados, e volta a clonar um repositório declarado
+cuja working tree falta.
+
+{: .note }
+> Um recarregamento **nunca é fatal**, ao contrário da aplicação no arranque. Uma instância que já está
+> a servir mantém a sua configuração atual, o motivo é registado, e a linha *Config seed*
+> da página Estado fica vermelha e indica-o. Um erro de escrita enviado para o git não pode deitar
+> abaixo uma instância em execução sem nenhuma ação de um operador.
+>
+> O mesmo conteúdo com erros também não é tentado de novo em cada verificação; caso contrário, uma edição errada
+> escreveria o mesmo erro no registo indefinidamente. Corrija o ficheiro, ou chame o endpoint para tentar de novo
+> de imediato.
+
+---
+
+## Um seed com erros recusa-se a arrancar
+
+Um ficheiro ilegível, YAML inválido, um campo desconhecido, um nome duplicado ou uma
+`${VARIABLE}` por resolver fazem o servidor **sair** em vez de arrancar. Isto vale só para o caminho do
+**arranque**: consulte a nota acima para o que o mesmo ficheiro faz a uma instância que já está a correr.
+
+É intencional. Continuar com a configuração anterior deixaria uma instância cujo
+comportamento já não corresponde ao manifesto que supostamente a descreve, sem nada
+a assinalar a diferença. O motivo é escrito no erro padrão e também no ficheiro de registo, por isso
+`kubectl logs` e `docker logs` mostram-no.
+
+A validação é estrita: os campos desconhecidos são rejeitados em vez de ignorados, e o erro indica
+a chave em causa:
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## Uma base de dados vazia aprovisiona-se sozinha
+
+Com `ALLOW_SCHEMA_CREATION` ligada (a predefinição), uma base de dados que não contém **nenhuma tabela
+do AnsibleForms** recebe o seu esquema criado no arranque. Uma implementação nova arranca assim
+sem que ninguém tenha de chamar o endpoint `/schema` manualmente.
+
+A condição prévia é estrita de propósito: criar o esquema **elimina primeiro todas as tabelas**, por isso
+só corre contra uma base de dados completamente vazia. Uma base de dados a que falta
+uma coluna, ou que tem tabelas mas nenhuma conta de utilizador, *não* está vazia e fica intacta;
+os patches do esquema tratam desses casos.
diff --git a/i18n/pt/_configure/users-and-groups.md b/i18n/pt/_configure/users-and-groups.md
new file mode 100644
index 0000000..2b9134c
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Utilizadores e grupos
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# Utilizadores e grupos
+{: .no_toc }
+
+Os utilizadores e grupos locais, os de LDAP e de início de sessão único ao lado deles, e bloquear um início de sessão
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: gira quem pode iniciar sessão em **Definições > Acesso > Utilizadores** e **Grupos**, com a opção de função `showSettings`.
+
+O admin integrado, a ordem de início de sessão e o mapeamento para funções das contas locais estão em [Contas locais](authentication/local.html).
+
+---
+
+## Nesta secção
+
+| Página | O que abrange |
+|---|---|
+| [Um utilizador local](users-and-groups/local-user.html) | Adicionar um utilizador local, e os separadores da sua página |
+| [Vários grupos](users-and-groups/several-groups.html) | Um utilizador local em vários grupos, e as suas funções |
+| [Um grupo local](users-and-groups/local-group.html) | A página de um grupo local e os seus separadores |
+| [Utilizadores e grupos de diretório](users-and-groups/directory.html) | Utilizadores e grupos de LDAP, Entra ID e OIDC, tal como foram vistos pela última vez |
+| [Bloquear um início de sessão](users-and-groups/blocking-a-sign-in.html) | Permitir início de sessão: bloquear um utilizador sem eliminar nada |
+
+
+---
+
+## As listas
+
+As listas **Utilizadores** e **Grupos** mostram os utilizadores e grupos locais e, ao lado deles, os de LDAP e de início de sessão único.
+
+Um utilizador ou grupo de LDAP, Entra ID ou OIDC aparece na lista depois de ter iniciado sessão (ou de ter sido visto num início de sessão), ou quando uma função o nomeia.
+A coluna **Origem** diz de onde vem cada um: Local, LDAP, Microsoft Entra ID ou OIDC. A partir da 7.3.0, a lista **Utilizadores** tem também
+uma coluna **Último início de sessão**, que diz quando cada utilizador iniciou sessão pela última vez.
+
+Uma linha abre a página do seu utilizador ou grupo. **Adicionar utilizador** e **Adicionar grupo** criam um local.
+
+---
+
+## Contas que concedem admin
+
+A função admin no config.yaml nomeia grupos e utilizadores locais, por isso só um admin pode alterar as contas e os grupos que ela nomeia.
+
+Um utilizador com `showSettings` mas sem a função admin não pode alterar, bloquear, mudar de grupo, definir a palavra-passe nem eliminar uma
+conta local que a função admin nomeia (diretamente ou através de um dos seus grupos). Também não pode criar, renomear nem eliminar um grupo
+que a função admin nomeia, nem colocar um utilizador num deles. O mesmo vale para um utilizador LDAP ou SSO que corresponde à função admin: bloqueá-lo,
+terminar as suas sessões, esquecê-lo e revogar os seus tokens de API cabem a um admin. O servidor responde a um pedido destes com `403`.
+
diff --git a/i18n/pt/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/pt/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..e4ea810
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: Bloquear um início de sessão
+parent: Utilizadores e grupos
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# Bloquear um início de sessão
+{: .no_toc }
+
+Permitir início de sessão: bloquear um utilizador sem eliminar nada
+{: .fs-6 .fw-300 }
+
+O interruptor **Permitir início de sessão** bloqueia um utilizador, local ou de um diretório, sem eliminar nada.
+
+Desligado, depois de uma confirmação, as sessões do utilizador terminam de imediato e todos os inícios de sessão são recusados até o voltar a ligar.
+A lista de utilizadores tem **Bloquear início de sessão** e **Permitir início de sessão** no menu de cada linha para o mesmo efeito.
+
+Não pode bloquear o utilizador `admin`, nem o seu próprio início de sessão.
diff --git a/i18n/pt/_configure/users-and-groups/directory.md b/i18n/pt/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..88bee39
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Utilizadores e grupos de diretório
+parent: Utilizadores e grupos
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# Utilizadores e grupos de diretório
+{: .no_toc }
+
+Utilizadores e grupos de LDAP, Entra ID e OIDC, tal como foram vistos pela última vez
+{: .fs-6 .fw-300 }
+
+Um utilizador de LDAP, Entra ID ou OIDC tem a sua página em `/settings/users/<source>/<name>`, com `ldap`, `azuread` ou `oidc`
+como origem, como `/settings/users/ldap/jdoe`. Mostra o que foi registado no último início de sessão do utilizador, só de leitura,
+já que é o diretório ou o fornecedor de identidade que define quem o utilizador é e os seus grupos.
+
+Os seus separadores são os de um utilizador local. **Detalhes** tem o interruptor **Permitir início de sessão**, o nome de utilizador, a origem, o nome,
+o email, quando o utilizador foi visto pela primeira vez e o seu último início de sessão. **Grupos** lista os grupos do último início de sessão.
+**Tokens de API** lista os tokens de API do utilizador, e **Revogar** termina um de imediato.
+
+No canto superior direito, **Terminar sessões** termina a sessão do utilizador em todo o lado, agora. **Esquecer** remove o registo, que volta
+no seu início de sessão seguinte; as suas tarefas, tarefas guardadas e agendamentos ficam. Um utilizador bloqueado não pode ser esquecido, já que isso
+o deixaria entrar de novo: o servidor responde `409`, por isso permita primeiro o seu início de sessão.
+
+Os grupos deste registo são também os grupos com que a sessão do utilizador trabalha, lidos em direto. Esquecer um utilizador com sessão
+iniciada deixa-o sem grupos, e sem as funções que esses grupos dão, até voltar a iniciar sessão.
+
+Um grupo de diretório tem a sua página em `/settings/groups/<source>/<name>`, só de leitura, com os separadores **Detalhes**,
+**Utilizadores** (os utilizadores vistos nele no seu último início de sessão), **Funções** e **Formulários**.
diff --git a/i18n/pt/_configure/users-and-groups/local-group.md b/i18n/pt/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..e20a4c0
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: Um grupo local
+parent: Utilizadores e grupos
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# Um grupo local
+{: .no_toc }
+
+A página de um grupo local e os seus separadores
+{: .fs-6 .fw-300 }
+
+A página de um grupo, `/settings/groups/<id>`, tem estes separadores:
+
+| Separador | O que mostra |
+|---|---|
+| **Detalhes** | O nome e a descrição |
+| **Utilizadores** | Os utilizadores do grupo; **Adicionar utilizador** adiciona um, o menu de uma linha ou as caixas de verificação removem um |
+| **Funções** | As funções que nomeiam o grupo |
+| **Formulários** | Os formulários que essas funções abrem |
+
+Um grupo com utilizadores não pode ser eliminado: remova primeiro os seus utilizadores. O grupo `admins` nunca pode ser eliminado nem renomeado.
diff --git a/i18n/pt/_configure/users-and-groups/local-user.md b/i18n/pt/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..bdc73d4
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: Um utilizador local
+parent: Utilizadores e grupos
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# Um utilizador local
+{: .no_toc }
+
+Adicionar um utilizador local, e os separadores da sua página
+{: .fs-6 .fw-300 }
+
+**Adicionar utilizador** abre um assistente em três passos: **Utilizador** (nome de utilizador, descrição, email), **Palavra-passe** e **Grupo**.
+
+A página de um utilizador, `/settings/users/<id>`, tem estes separadores:
+
+| Separador | O que mostra |
+|---|---|
+| **Detalhes** | O interruptor **Permitir início de sessão**, o nome de utilizador, a descrição, o email e, a partir da 7.3.0, o **Último início de sessão** |
+| **Grupos** | Os grupos a que o utilizador pertence |
+| **Funções** | As funções que o utilizador tem, e o que dá cada uma: **Diretamente**, **Através de** um grupo, ou **Todos** |
+| **Formulários** | Os formulários que essas funções abrem |
+| **Trabalhos** | As tarefas que o utilizador lançou, as mais recentes primeiro |
+| **Tarefas guardadas** | Os valores de formulário que o utilizador guardou para voltar a executar |
+| **Agendamentos** | As tarefas que o utilizador planeou com Executar mais tarde |
+| **Atividade** | O que o registo de auditoria registou que o utilizador fez |
+| **Tokens de API** | Os tokens de API do utilizador, com quando cada um foi criado, quando expira e quando foi usado pela última vez; **Revogar** termina um de imediato |
+
+A partir da 7.3.0, os inícios de sessão de um utilizador local são registados, como já eram os de um utilizador LDAP ou SSO: **Último início de sessão** mostra o mais recente, e
+a lista de utilizadores tem uma coluna ordenável **Último início de sessão** para todas as origens, por isso uma conta que ninguém usa salta à vista. Um início de sessão recusado não é
+registado, e um utilizador local que não iniciou sessão desde a atualização mostra `–`.
+
+**Alterar palavra-passe** e **Eliminar** estão no canto superior direito. O utilizador `admin` nunca pode ser eliminado nem renomeado.
diff --git a/i18n/pt/_configure/users-and-groups/several-groups.md b/i18n/pt/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..c46919a
--- /dev/null
+++ b/i18n/pt/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: Vários grupos
+parent: Utilizadores e grupos
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# Vários grupos
+{: .no_toc }
+
+Um utilizador local em vários grupos, e as suas funções
+{: .fs-6 .fw-300 }
+
+Um utilizador local pode pertencer a vários grupos, e recebe as funções de todos eles: as funções nomeiam um grupo como `local/<group>`.
+
+No separador **Grupos**, **Adicionar grupo** adiciona o utilizador a outro grupo, e o menu de uma linha ou as caixas de verificação removem um.
+Um utilizador mantém pelo menos um grupo. A lista de utilizadores tem **Adicionar a um grupo** no menu de cada linha para o mesmo efeito.
diff --git a/i18n/pt/_get_started/first-form.md b/i18n/pt/_get_started/first-form.md
new file mode 100644
index 0000000..3aec367
--- /dev/null
+++ b/i18n/pt/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: O seu primeiro formulário
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# O seu primeiro formulário
+{: .no_toc }
+
+Escreva um playbook, crie um formulário para ele no Designer, lance-o e encontre a tarefa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Este tutorial parte de uma instalação nova, consulte [Instalação](installation/). Demora cerca de quinze minutos.
+
+---
+
+## 1. Inicie sessão
+
+Abra o AnsibleForms num navegador e inicie sessão como administrador.
+
+A conta predefinida é `admin` / `AnsibleForms!123` (ou os seus valores de [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME)); abre-se a página **Formulários**:
+
+![A página Formulários, com formulários de exemplo](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. Escreva o playbook
+
+Um formulário `ansible` executa um playbook da pasta de playbooks, por isso o playbook vem primeiro. Guarde isto como `hello.yaml`:
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+O playbook lê quatro variáveis. O formulário que vai criar a seguir envia-lhas como extravars, uma por campo.
+
+Coloque o ficheiro na pasta `playbooks` da pasta persistente
+([`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)); crie a pasta se ainda não existir:
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">A partir do código-fonte</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+A pasta que montou em `/app/dist/persistent`, `/srv/apps/ansibleforms/persistent` no exemplo de instalação:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+A pasta `data/playbooks` do projeto docker-compose:
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+O volume persistente, montado em `/app/dist/persistent` no pod do AnsibleForms. Procure o nome do pod e copie o ficheiro para dentro dele:
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+A pasta `persistent/playbooks` do servidor, `/srv/apps/ansibleforms/server` no exemplo de instalação:
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> Quando um repositório git tem **Usar para playbooks ?** ativado, os playbooks são executados a partir desse repositório:
+> faça commit de `hello.yaml` nesse repositório. Consulte [Designer e git](gui/designer-and-git.html).
+
+---
+
+## 3. Crie o formulário
+
+Os formulários são ficheiros YAML na pasta de formulários. O Designer edita-os no navegador e verifica-os antes de guardar.
+
+1. Clique em **Designer** no menu superior e depois em **Formulários** no menu da esquerda.
+2. Clique no interruptor no canto superior direito (**Iniciar designer**). Bloqueia a configuração para que mais ninguém a edite ao
+   mesmo tempo e passa a mostrar **Bloqueado por mim**.
+3. Clique em **Novo ficheiro**, o primeiro botão da barra de ferramentas, e introduza o nome de ficheiro `hello-world.yaml`. O Designer adiciona-lhe
+   um formulário chamado `New Form`.
+4. Substitua o YAML no editor por este formulário:
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. Clique em **Validar** (o visto) e depois em **Guardar**. Guardar escreve `hello-world.yaml` na pasta de formulários.
+6. Clique novamente no interruptor para libertar o bloqueio.
+
+![O Designer, a editar um formulário](assets/screenshots/designer.jpg)
+
+O formulário usa quatro tipos de campo:
+
+| Campo | Tipo | O que faz |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | Uma caixa de texto obrigatória |
+| `target_env` | [`enum`](formfields/enum.html) | Uma lista pendente com uma lista fixa de `values` |
+| `vm_size` | [`enum`](formfields/enum.html) | Uma lista pendente preenchida por uma [expressão](expressions/local.html) local; `__auto__` seleciona o primeiro item |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | Uma caixa de verificação, enviada como `true` ou `false` |
+
+`vm_size` mostra as duas colunas, `size` e `cpus`, e envia `size`, a primeira; `valueColumn` escolhe outra.
+
+`roles: [default]` permite que qualquer utilizador com sessão iniciada execute o formulário, e `categories: [Default]` coloca-o na categoria que o
+`config.yaml` predefinido define.
+
+{: .note }
+> Também pode copiar `hello-world.yaml` para [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) e [validá-lo no VS Code](faq.html#vs-code-validation-for-form-files).
+
+---
+
+## 4. Lance-o
+
+Abra o formulário a partir da página **Formulários**: clique em **Formulários** no menu superior e escolha **Hello world** na categoria **Default**.
+
+Preencha o seu nome e altere os outros campos, se quiser. Clique em **Mostrar extravars** para ver o que o playbook vai
+receber e depois clique em **Submeter**:
+
+![Um formulário](assets/screenshots/form.jpg)
+
+---
+
+## 5. Acompanhe a saída
+
+A tarefa começa de imediato e a sua saída aparece por baixo do formulário enquanto é executada, terminando com uma barra **Terminada**:
+
+![A saída de uma tarefa](assets/screenshots/run.jpg)
+
+A tarefa de debug mostra os seus valores, por exemplo `Hello Alice: a small machine in development (dry run: True)`.
+
+O aviso sobre o localhost implícito é normal sem um inventário; um formulário real define [`inventory`](forms/ansible.html).
+
+---
+
+## 6. Encontre-a no histórico de tarefas
+
+Cada lançamento é guardado como uma tarefa. Clique em **Tarefas** no menu superior: a nova tarefa está no topo de **Todas as tarefas**.
+
+Clique na tarefa para voltar a ver a sua saída, e em **Mostrar extravars** para ver o que foi enviado. Os ícones à frente de cada tarefa
+relançam-na ou eliminam-na:
+
+![O histórico de tarefas](assets/screenshots/job-output.jpg)
+
+---
+
+## Próximos passos
+
+Desenvolva este formulário com as páginas de referência:
+
+* **[Formulários](forms/)** : todas as propriedades de um formulário, templates em runners, formulários de workflow, pontos de aprovação e notificações
+* **[Campos de formulário](formfields/)** : todos os tipos de campo, com validação, dependências e disposição
+* **[Expressões](expressions/)** : preencha campos a partir de APIs REST, bases de dados e ficheiros
+* **[Funções](config/roles.html)** e **[categorias](config/categories.html)** em `config.yaml` : decida quem vê cada formulário
+* **[Como funciona](how-it-works.html)** : o que acontece por trás de um lançamento e onde tudo fica guardado
diff --git a/i18n/pt/_get_started/installation/docker-compose.md b/i18n/pt/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..6949fab
--- /dev/null
+++ b/i18n/pt/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: Instalação
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+Instale o AnsibleForms, o seu RTE e o MySQL em conjunto com docker-compose ou podman-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+O [projeto docker-compose](https://github.com/ansibleforms/docker) executa três contentores: MySQL, a aplicação AnsibleForms e o RTE
+(ambiente de execução) que executa os playbooks. Contém as respetivas definições, formulários e playbooks de exemplo, por isso o único outro requisito é
+o Docker ou o Podman com a sua ferramenta de compose.
+
+O [instalador](installer.html) descarrega este projeto, preenche as suas definições e segredos e inicia-o com um único comando. Esta página
+configura-o à mão.
+
+---
+
+## Pré-requisitos
+
+Antes de começar, precisa de:
+
+* **Máquina Linux** : qualquer distribuição, com CPU e memória modestos
+* **Acesso ao GitHub** : para descarregar ou clonar o projeto docker-compose a partir do GitHub
+* **Docker ou Podman** : um motor de contentores, instalado mais abaixo
+* **Uma ferramenta de compose** : Docker Compose ou podman-compose, para iniciar os três contentores a partir de alguns ficheiros de configuração
+
+**VÍDEO**: [Como instalar o AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## Escolha um local de instalação
+
+Crie uma pasta para o projeto; os exemplos usam `/srv/apps`:
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## Clone o projeto docker-compose
+
+Instale o Git:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+Depois clone o projeto docker-compose para essa pasta:
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## Defina as permissões corretas
+
+A aplicação e o RTE são executados como o utilizador `node` (uid 1000), por isso dê a esse utilizador a pasta `data`:
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+Se vem da 6, cujo contentor era executado como root, execute o mesmo `chown` uma vez antes de iniciar a 7. O MySQL recupera a sua própria pasta quando arranca.
+
+---
+
+## Instale um motor de contentores
+
+Instale o Docker ou o Podman, cada um com a sua ferramenta de compose:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+Instale o Docker Engine com o plugin Compose a partir do repositório do Docker
+(consulte os [manuais de instalação do Docker](https://docs.docker.com/engine/install)):
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+Depois permita a resolução de nomes dentro dos contentores e inicie o Docker como serviço:
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+O Podman não precisa de um serviço. Instale-o juntamente com o podman-compose:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## Personalize
+
+Reveja as variáveis nos ficheiros `.env` e `docker-compose.yml` e altere todas as palavras-passe: `MYSQLDB_ROOT_PASSWORD`,
+`MYSQLDB_PASSWORD`, `ADMIN_PASSWORD` e `RTE_TOKEN`. [Saiba mais sobre as variáveis de ambiente](../customization)
+
+A aplicação liga-se ao MySQL como `ansibleforms` (`MYSQLDB_USER`), com todos os direitos sobre o esquema `AnsibleForms` e nenhum
+noutro sítio; o root serve apenas para o próprio MySQL. O MySQL cria esse utilizador apenas no primeiro arranque: uma instalação que até agora se ligava como root
+cria-o uma vez, como mostra o [README](https://github.com/ansibleforms/docker#database) do projeto.
+
+O RTE não é publicado no host. Desde a 7.3.0, a aplicação liga-se a ele em `http://rte:8000` com `RTE_TOKEN` e mantém um WebSocket aberto
+(`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)): o RTE não recebe definições da base de dados nem o `.env`, apenas o seu token e algumas
+definições próprias no `docker-compose.yml`. O config seed `data/seed.yaml` declara uma credencial de RTE com o token e esse
+endereço, e o runner predefinido `rte`, em modo inbound, que inicia sessão com ela. O RTE executa os playbooks a partir da mesma pasta `data`
+(`RTE_FILES=local`). Quando os seus playbooks precisarem de mais coleções ou bibliotecas Python, construa um RTE próprio
+e aponte o serviço `rte` para ele (consulte [Construir o seu próprio RTE](../rte/images.html#build-your-own-rte)).
+
+---
+
+## Inicie o projeto docker-compose
+
+Inicie os três contentores em segundo plano. A aplicação espera até o MySQL estar saudável e depois liga-se ao RTE:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## Teste a aplicação
+
+Quando os contentores estiverem a funcionar, abra o AnsibleForms num navegador:
+
+* Abra `https://your_ip` (porta 443, consulte `WEBAPP_LOCAL_PORT` no ficheiro .env)
+* Inicie sessão como `admin` com a `ADMIN_PASSWORD` do ficheiro `.env`; enquanto ainda for a predefinida `AnsibleForms!123`, escolha uma nova palavra-passe
+* Verifique em **Ligações > Runners** que o RTE aparece como `rte`, o runner predefinido, e que a sua página mostra a
+  **Ligação** como **Ligado**
+* Próximos passos:
+  * Crie formulários adicionando ficheiros YAML à pasta data/forms/ ou usando o designer incorporado
+  * Adicione os seus playbooks à pasta data/playbooks/
+  * Adicione uma ligação LDAP
+  * Adicione utilizadores e grupos
+  * Adicione runners para formulários de template: AWX, AAP ou Ascender, Semaphore, Rundeck ou Jenkins
+  * Adicione credenciais para ligações externas, como outros servidores MySQL ou APIs REST, ou para passar a playbooks Ansible
+  * Ligue repositórios Git e escolha se os seus formulários e/ou playbooks se sincronizam com um repositório
+
+---
+
+## Estrutura de ficheiros
+
+O projeto docker-compose tem a seguinte estrutura de pastas:
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/pt/_get_started/installation/docker.md b/i18n/pt/_get_started/installation/docker.md
new file mode 100644
index 0000000..74c0dbe
--- /dev/null
+++ b/i18n/pt/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: Instalação
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+Execute as imagens da aplicação AnsibleForms e do RTE com Docker ou Podman, ao lado de um servidor MySQL próprio
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Pode executar o AnsibleForms com Docker ou Podman como dois contentores, a aplicação e o RTE que executa os playbooks, ligados a uma base de dados MySQL.
+
+---
+
+## Pré-requisitos
+
+Antes de começar, precisa de:
+
+* **Docker ou Podman** : um deles instalado e em execução
+* **MySQL** : instalado e em execução
+
+---
+
+## Instale o MySQL
+
+Instale o MySQL 8+, ou o MariaDB, num servidor Linux que o contentor consiga alcançar:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+O Ubuntu inclui o MySQL 8:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+O Debian inclui o MariaDB em vez do MySQL, que o AnsibleForms também suporta:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+O RHEL 8 e posteriores, e as suas recompilações, incluem o MySQL 8 no AppStream:
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+O AnsibleForms liga-se à base de dados pela rede, como `DB_USER` com `DB_PASSWORD`. Dê-lhe um utilizador próprio, com direitos apenas sobre
+o esquema `AnsibleForms`, e não o root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+É tudo o que o AnsibleForms precisa: com isso, cria e atualiza o seu esquema e faz as suas cópias de segurança. A página **Estado** e o registo
+avisam quando o utilizador tem direitos sobre todas as bases de dados. No Ubuntu e no Debian o servidor escuta apenas em localhost: defina `bind-address` na sua
+configuração para que os contentores o consigam alcançar.
+
+---
+
+## Prepare as pastas
+
+O AnsibleForms 7 é executado em dois contentores: a aplicação e o RTE (ambiente de execução) que executa os playbooks. Ambos montam uma pasta para
+o seu `config.yaml`, formulários, playbooks, registos e certificados, e uma pasta para a chave SSH. As imagens são executadas como o utilizador `node` (uid 1000),
+por isso dê a esse utilizador as duas pastas:
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+Coloque as definições da aplicação num ficheiro de ambiente: a ligação à base de dados,
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) antes de guardar qualquer credencial, o token que a aplicação e o
+RTE partilham ([`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN), com pelo menos 16 caracteres) e o config seed que declara o RTE:
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+O RTE recebe um ficheiro próprio, sem as definições da base de dados: desde a 7.3.0 a aplicação liga-se a ele e mantém um WebSocket aberto
+(`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)), e ele executa os playbooks a partir das mesmas pastas (`RTE_FILES=local`):
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+O [config seed](../seed/) declara uma credencial de RTE com o endereço do RTE e o seu token, e o runner predefinido `rte` que inicia
+sessão com ela:
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## Inicie os contentores
+
+Execute as imagens publicadas no GitHub Container Registry (consulte [Tags da imagem](./#image-tags)):
+[`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms) para a aplicação e
+[`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full) para o RTE.
+
+O seed adiciona o RTE em **Ligações > Runners** como o runner `rte`, o predefinido, por isso os formulários de playbook são executados nele sem mais
+configuração. A aplicação cria o esquema no primeiro arranque e liga-se ao RTE assim que ambos estiverem em execução (há um `config.yaml` de exemplo no
+[projeto docker-compose](https://github.com/ansibleforms/docker/blob/main/data/config.yaml)):
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Depois de iniciados, os dois contentores aparecem na lista:
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+O Podman aceita as mesmas opções e não precisa de um serviço:
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+Depois de iniciados, os dois contentores aparecem na lista:
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+A aplicação escuta na porta `8000`, por HTTP, a menos que defina `HTTPS=1`. O RTE não é publicado no host: só a aplicação se liga a ele, dentro
+da rede. `--stop-timeout 30` dá ao RTE tempo para deixar terminar os playbooks em curso numa paragem (consulte
+[Executar um RTE](../rte/run.html) para as definições do RTE e para construir um RTE próprio).
+
+---
+
+## Teste a aplicação
+
+Quando os contentores estiverem a funcionar, abra o AnsibleForms num navegador:
+
+* Abra `http://your_ip:8000` (ou HTTPS, se definiu `HTTPS=1`)
+* Inicie sessão como `admin` / `AnsibleForms!123` (ou com a palavra-passe que definiu com `ADMIN_PASSWORD`) e escolha uma nova palavra-passe
+* Verifique em **Ligações > Runners** que o RTE aparece como `rte`, o runner predefinido, e que a sua página mostra a
+  **Ligação** como **Ligado**
+* Próximos passos:
+  * Crie formulários adicionando ficheiros YAML à pasta `forms` ou usando o designer incorporado
+  * Adicione os seus playbooks à pasta `playbooks` da pasta persistente montada
+  * Adicione uma ligação LDAP
+  * Adicione utilizadores e grupos
+  * Adicione runners para formulários de template: AWX, AAP ou Ascender, Semaphore, Rundeck ou Jenkins
+  * Adicione credenciais para ligações externas, como outros servidores MySQL ou APIs REST, ou para passar a playbooks Ansible
diff --git a/i18n/pt/_get_started/installation/from-source.md b/i18n/pt/_get_started/installation/from-source.md
new file mode 100644
index 0000000..09daae2
--- /dev/null
+++ b/i18n/pt/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: A partir do código-fonte
+parent: Instalação
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# A partir do código-fonte
+{: .no_toc }
+
+Compile o AnsibleForms a partir do código-fonte e execute-o com Node.js
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Como o código está organizado
+
+O repositório contém duas aplicações Node.js, e uma compilação junta-as numa só:
+
+* **client** : a interface web, escrita em Vue 3 e compilada em ficheiros estáticos com Vite
+* **server** : a API, escrita em Express. Entrega as tarefas aos runners, liga-se à base de dados e serve o client compilado.
+  Iniciado com `AF_ROLE=rte`, o mesmo servidor é o RTE (ambiente de execução) que executa os playbooks
+
+Só o client é compilado; o resultado vai para a pasta `views` do servidor, tal como na [imagem Docker](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile).
+
+---
+
+## Pré-requisitos
+
+Compilar e executar a partir do código-fonte exige bons conhecimentos de Linux e algum conhecimento de Node.js. Instala cada componente por si. Para
+executar o AnsibleForms sem contentores e sem o compilar, a [instalação nativa](native.html) do instalador faz tudo isto por si:
+
+* **Node.js 26** (a versão em `.nvmrc`; no mínimo a 24), com npm
+* **Git**, para obter o código e sincronizar repositórios
+* **Cliente OpenSSH**, para git por SSH, e **sshpass**, para playbooks que se ligam com uma palavra-passe SSH
+* **Cliente MariaDB** (`mariadb`, `mariadb-dump`), para cópias de segurança e restauros, também com um servidor MySQL
+* **MySQL 8+ ou MariaDB**, acessível a partir do servidor
+* **Ansible**, para o processo RTE que executa os playbooks (`ansible-playbook` no seu path). O próprio processo da aplicação não precisa de
+  Ansible nem de Python, e só com formulários de template (AWX, AAP, Ascender e os outros runners) não precisa de nenhum RTE
+
+Instale-os para a sua distribuição:
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+O Node.js 26 vem do repositório NodeSource, as outras ferramentas do próprio Ubuntu:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+O Node.js 26 vem do repositório NodeSource, as outras ferramentas do próprio Debian:
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+O Node.js vem do NodeSource e o `sshpass` do EPEL (no próprio RHEL, ative o EPEL como a Red Hat documenta):
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+Verifique `node --version` (26) e `ansible-playbook --version`; para a base de dados e o seu utilizador, consulte [Instale o MySQL](docker.html#install-mysql).
+
+---
+
+## Obtenha o código
+
+Clone o repositório para uma pasta à sua escolha, pertencente ao utilizador que vai executar a aplicação. Os exemplos usam `/srv/apps/ansibleforms`:
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## Compile
+
+Compile em três passos, a partir da pasta do repositório. Primeiro compile o client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Depois instale as dependências do servidor:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Por fim copie o client compilado para a pasta `views` do servidor:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## Configure
+
+O servidor lê as suas definições a partir de variáveis de ambiente e, em produção, também de `server/persistent/.env`, o ficheiro
+onde as páginas de definições escrevem.
+
+Parta do ficheiro de exemplo na raiz do repositório e defina pelo menos a ligação ao MySQL (`DB_HOST`, `DB_PORT`, `DB_USER`,
+`DB_PASSWORD`):
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+Todas as variáveis estão descritas em [Variáveis de ambiente](../customization). Tudo o resto é guardado em `server/persistent` por predefinição:
+`config.yaml`, a pasta `forms` e os certificados autoassinados são criados aí no primeiro arranque, junto com os registos.
+Coloque os seus playbooks em `server/persistent/playbooks`, ou aponte `ANSIBLE_PATH` para outro sítio no ambiente do RTE, que é quem o lê.
+
+---
+
+## Execute
+
+Execute o AnsibleForms em produção, ou em modo de desenvolvimento para trabalhar no próprio código:
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">Produção</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">Desenvolvimento</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+Inicie o servidor em modo de produção a partir da pasta `server`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+Uma aplicação iniciada a partir da linha de comandos para quando termina a sessão. O [PM2](https://pm2.keymetrics.io/) mantém-na em execução em
+segundo plano, reinicia-a após uma falha e volta a iniciá-la no arranque:
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+Os playbooks são executados num RTE: inicie o mesmo servidor uma segunda vez com `AF_ROLE=rte`, numa porta própria. A aplicação liga-se a ele e mantém
+um WebSocket aberto (`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)), e ele executa os playbooks a partir das mesmas pastas
+(`RTE_FILES=local`). Também lê `persistent/.env`, mas não usa nenhuma das suas definições da base de dados. Adicione a `persistent/.env` o token que a aplicação e o RTE partilham,
+com pelo menos 16 caracteres, e o config seed que declara o RTE:
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+O [config seed](../seed/) declara uma credencial de RTE com o endereço do RTE e o seu token, e o runner predefinido `rte` que inicia
+sessão com ela:
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+Sem um seed, adicione-os em **Ligações > Credenciais** (uma credencial de RTE com esse endereço e o token) e
+**Ligações > Runners** (tipo RTE, **Modo** **Entrada**). Depois inicie o RTE, apenas em `127.0.0.1`:
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+As definições do RTE estão descritas na página [Executar um RTE](../rte/run.html). Verifique que o PM2 lista os dois processos:
+
+```bash
+pm2 status
+```
+
+Ambos estão `online`:
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+Para trabalhar no próprio código, inicie tudo a partir da raiz do repositório com recarregamento automático: o servidor na porta 3001, um RTE na porta 8010
+e o client em `https://localhost:8443`. Neste modo, o servidor e o RTE leem antes `server/.env.development`:
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+O RTE (`npm run dev:rte`) precisa de `ansible-playbook` no path, e adiciona-se a si próprio como runner em modo base de dados, obsoleto, apenas para
+desenvolvimento; `npm run dev:local` inicia o client e o servidor sem ele. O [guia de contribuição](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) descreve os testes e as verificações a executar.
+
+</div>
+</div>
+
+---
+
+## Primeira execução
+
+Abra o servidor num navegador (com o `.env` de exemplo, `https://your_ip:8443`). Numa base de dados vazia, o esquema é criado no
+primeiro arranque.
+
+As credenciais de administrador predefinidas são:
+
+* nome de utilizador : `admin`
+* palavra-passe : `AnsibleForms!123`
diff --git a/i18n/pt/_get_started/installation/index.md b/i18n/pt/_get_started/installation/index.md
new file mode 100644
index 0000000..ba8f0d7
--- /dev/null
+++ b/i18n/pt/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: Instalação
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# Instalação
+{: .no_toc }
+
+Escolha um método de instalação para o AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores que estão a configurar uma nova instância: escolha um método de instalação e siga a respetiva página.
+
+---
+
+## Nesta secção
+
+O AnsibleForms suporta vários métodos de instalação, cada um descrito na sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Instalador](installer.html) | Um único comando que instala um controlador ou um Runner em Docker, Podman, Kubernetes ou de forma nativa, e que depois o atualiza e faz cópias de segurança |
+| [Nativa](native.html) | A instalação do instalador sem contentores: Node.js, MariaDB e Ansible no servidor, AnsibleForms como serviços systemd |
+| [Docker](docker.html) | Instale o MySQL e execute a imagem Docker pré-construída com as variáveis de ambiente necessárias |
+| [Docker Compose](docker-compose.html) | Descarregue o [projeto docker-compose](https://github.com/ansibleforms/docker) e use o docker-compose para iniciar o MySQL e o AnsibleForms |
+| [A partir do código-fonte](from-source.html) | Instale todas as dependências manualmente e depois compile e inicie o código |
+| [Kubernetes](kubernetes.html) | Instale o chart de Helm e use o Kubernetes para iniciar o AnsibleForms e a sua base de dados MySQL |
+
+{: .note }
+> **Recomendação** O instalador, desde a 7.3.0, é o caminho mais rápido para uma instância a funcionar: configura o projeto Docker Compose em
+> Docker ou Podman, ou um dos outros métodos, a partir de algumas perguntas. As imagens Docker incluem todas as dependências.
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+Para passar uma instalação existente para uma versão mais recente, consulte [Atualizar](../upgrading/).
+
+Todos os métodos executam um RTE ao lado da aplicação, o contentor (ou serviço) que executa os playbooks. Para adicionar outro, noutro host ou noutro
+centro de dados, instale um Runner com o [instalador](installer.html#a-runner): liga-se ao AnsibleForms através de um WebSocket (de saída, consulte
+[Modos](../rte/modes.html)) e não guarda credenciais da base de dados. Consulte também [Ambientes de execução](../rte/) e o seu runbook
+[Um RTE noutro centro de dados](../rte/another-datacenter.html).
+
+---
+
+## Tags da imagem
+
+A imagem é publicada como `ghcr.io/ansibleforms/ansibleforms` no GitHub Container Registry, que pertence ao
+projeto e não limita os pulls anónimos. Todas as versões a partir da 7.0.0 são publicadas apenas aí, e as versões 6.x
+também lá estão.
+
+Desde a 7, os playbooks são executados num RTE, publicado em três camadas ao lado da aplicação (consulte [As imagens do RTE](../rte/images.html)):
+
+| Imagem | O que é |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | A aplicação web e a API, sem python nem ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | O RTE sem python nem ansible: a base para o seu próprio |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | A base com python, ansible-core e algumas bibliotecas: aquela a que adiciona as suas coleções |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | A core com o pacote `ansible`, as suas coleções e bibliotecas: o RTE predefinido |
+
+As quatro imagens são construídas na mesma execução e têm as mesmas tags, por isso uma tag do RTE corresponde sempre à da aplicação.
+
+O antigo repositório do Docker Hub, `ansibleguy/ansibleforms`, já não é atualizado. Mantém as versões
+existentes, mas não recebe novas versões de nenhuma das linhas. Se faz pull a partir dele, mude
+para `ghcr.io/ansibleforms/ansibleforms` com a mesma tag para continuar a receber atualizações.
+
+As seguintes tags estão disponíveis em cada imagem; as imagens do RTE começam na 7.0.0, por isso não têm tags 6.x:
+
+| Tag | Aponta para |
+|---|---|
+| `latest` | a versão mais recente da versão principal mais recente |
+| `7`, `6` | a versão mais recente dessa versão principal |
+| `7.0`, `6.5` | a versão mais recente dessa versão secundária |
+| `7.0.0`, `6.5.5` | exatamente essa versão |
+| `latest-rc` | a release candidate mais recente, ou a versão mais recente quando esta for mais nova; cada candidata tem também a sua própria tag |
+
+`latest` só avança: uma correção para uma versão principal mais antiga (por exemplo uma 6.5.x lançada
+depois da 7.0.0) move `6` e `6.5`, mas nunca `latest`.
+
+Para se manter numa versão principal, use o seu número (`6`) em vez de `latest`.
diff --git a/i18n/pt/_get_started/installation/installer.md b/i18n/pt/_get_started/installation/installer.md
new file mode 100644
index 0000000..5b2a607
--- /dev/null
+++ b/i18n/pt/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: Instalador
+parent: Instalação
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# O instalador
+{: .no_toc }
+
+Instale, atualize e cuide do AnsibleForms num servidor Linux, com um único comando
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores: o caminho mais rápido para uma instância a funcionar, ou para um Runner de um AnsibleForms instalado noutro sítio. Desde a 7.3.0.
+
+---
+
+## O que instala
+
+O instalador faz algumas perguntas num assistente em ecrã inteiro, mostra todas as respostas para revisão e só então altera o servidor.
+Instala uma de duas funções, num de quatro motores:
+
+| Função | O que é |
+|---|---|
+| Controlador | A aplicação completa: a interface web, a sua base de dados e o seu próprio Runner. Escolha esta opção numa primeira instalação |
+| Runner | Um RTE que executa os playbooks de um AnsibleForms instalado noutro sítio, por exemplo noutra rede, numa DMZ ou noutro centro de dados. Comunica com o AnsibleForms através de um único WebSocket e não guarda credenciais da base de dados |
+
+Os motores em que as instala:
+
+| Motor | Como é executado |
+|---|---|
+| Docker | O [projeto Docker Compose](docker-compose.html), no Docker Engine com o seu plugin de compose. Os contentores reiniciam juntamente com o Docker |
+| Podman | O mesmo projeto no Podman, rootless ou como root, com podman-compose. Uma unidade systemd inicia os contentores no arranque |
+| Kubernetes | O [chart de Helm](kubernetes.html), no cluster a que o `kubectl` chega. Um controlador é servido por trás de um ingress; um Runner usa o modo runner do chart |
+| Diretamente neste servidor | Sem contentores: Node.js, MariaDB e Ansible no servidor, e o AnsibleForms como serviços systemd. Consulte [Instalação nativa](native.html) |
+
+Depois da instalação, o mesmo programa atualiza a instalação, faz cópias de segurança, mostra o seu estado e remove-a. Também assume um
+AnsibleForms que não instalou, como um configurado à mão a partir do projeto Docker Compose (consulte [Uma instalação existente](#an-existing-installation)).
+
+---
+
+## Execute-o
+
+O script de instalação descarrega o instalador para este servidor e inicia-o:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+As variantes habituais: como root, para instalar o Docker ou o Podman, para instalar diretamente no servidor ou em `/opt`; com um comando ou
+flags (consulte [Flags](#flags)); e um instalador de uma versão concreta em vez da mais recente:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+O script:
+
+1. Verifica que o servidor corre Linux em amd64 ou arm64, e encontra `curl` ou `wget` e `sha256sum`
+2. Descarrega `ansibleforms-installer_linux_<arch>` da versão mais recente de
+   [ansibleforms/installer](https://github.com/ansibleforms/installer/releases), ou da versão indicada em `AF_INSTALLER_VERSION`
+3. Verifica-o contra o `checksums.txt` da versão, e não usa nenhuma transferência cujo checksum seja diferente
+4. Guarda-o como `ansibleforms-installer`, em `/usr/local/bin` para o root e em `~/.local/bin` caso contrário, para as atualizações e cópias de segurança posteriores.
+   Através do sudo, execute-o pelo caminho completo: o `secure_path` do sudo, como nos sistemas Red Hat, muitas vezes não inclui `/usr/local/bin`
+5. Inicia-o com as flags indicadas, lendo o teclado a partir do terminal, mesmo que o script tenha chegado através de um pipe
+
+Sem um terminal, como numa tarefa de CI, o instalador corre sem intervenção (consulte [Sem intervenção](#unattended)).
+
+---
+
+## O assistente
+
+O assistente faz uma pergunta de cada vez, com os passos listados à esquerda. **Esc** volta ao passo anterior, mantendo a sua resposta:
+
+| Passo | O que pergunta |
+|---|---|
+| Idioma | O idioma do instalador, por predefinição o da locale deste servidor: catalão, alemão, inglês, espanhol, francês, italiano, japonês, neerlandês, polaco, português ou chinês. É perguntado primeiro, antes de o instalador dizer algo sobre uma instalação que tenha encontrado |
+| Notas | O que há de novo na versão que instala, com as alterações incompatíveis, as remoções e as descontinuações primeiro |
+| Função | Controlador ou Runner |
+| Motor | Docker, Podman, Kubernetes ou diretamente neste servidor |
+| Pasta | A pasta de instalação e o nome da instância |
+| Adesão, Aplicação, Modo | Apenas num Runner: consulte [Um Runner](#a-runner). O modo não é perguntado em Kubernetes |
+| Rede | A porta da interface web, ou do Runner. Não em Kubernetes |
+| HTTPS | Como os navegadores se ligam a um controlador |
+| Admin | A palavra-passe do primeiro administrador, escrita duas vezes |
+| Cluster, Ingress, Armazenamento | Apenas em Kubernetes: o namespace e a release, o ingress (num controlador), a classe de armazenamento |
+| Revisão | Todas as respostas: **Instalar**, ou **Alterar respostas** |
+
+**Motor.** A lista mostra o que este servidor tem. Um motor que falte é oferecido como *Docker (não instalado: o instalador instala-o)*
+ou o mesmo para o Podman: depois de confirmar, o instalador instala o Docker com o script do próprio Docker (`get.docker.com`, com o plugin de compose
+incluído) ou o Podman com o podman-compose a partir dos pacotes da distribuição. Isso exige root. O Kubernetes é oferecido quando o `kubectl` e o
+`helm` estão instalados e chegam a um cluster. *Diretamente neste servidor* exige root e um Linux suportado, e diz porquê quando aparece desativado.
+
+**Pasta.** As predefinições:
+
+| | Controlador | Runner |
+|---|---|---|
+| Pasta, como root | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| Pasta, como outro utilizador | `~/ansibleforms` | `~/ansibleforms-runner` |
+| Nome da instância, Docker ou Podman | `af` | `runner` |
+| Nome da instância, nativa | `ansibleforms` | `ansibleforms-runner` |
+
+Com Docker ou Podman, a pasta contém o ficheiro de compose e o seu `.env` com os segredos, e todos os dados: base de dados, formulários, playbooks
+e registos. Tem de estar vazia. O nome da instância, com letras minúsculas, dígitos e `-`, serve de prefixo aos contentores (`af_app`, `af_db`, `af_rte`), para que várias
+instâncias possam partilhar um servidor. O nome da instância de um Runner é também o nome do seu runner em **Ligações > Runners** (`RTE_NAME`).
+
+**Rede.** A interface web de um controlador escuta na `443`, ou na porta livre seguinte. **HTTPS** oferece então:
+
+| Opção | O que faz |
+|---|---|
+| HTTPS com um certificado autoassinado criado para este servidor | Um certificado para os nomes deste servidor, válido durante dez anos. Os navegadores pedem-lhe que o aceite uma vez |
+| HTTPS com o meu próprio certificado e chave | O seu próprio certificado e chave, em formato PEM, da sua CA ou do Let's Encrypt |
+| HTTP, com o HTTPS tratado por um reverse proxy à frente | HTTP simples na porta, para nginx, Traefik ou um balanceador de carga que trate do HTTPS |
+
+**Admin.** A palavra-passe do utilizador `admin`, escrita duas vezes para que um erro de digitação não o deixe de fora. Se ficar vazia, o instalador gera
+uma forte.
+
+**O fim.** O instalador gera a palavra-passe da base de dados e os segredos, inicia o AnsibleForms e espera até que responda. Depois
+mostra o endereço a abrir, o utilizador e a palavra-passe, e a pasta. Os Runners instalados para ele pedem para aderir, e um administrador aprova-os
+em **Ligações > Runners** (consulte [Um Runner](#a-runner)).
+
+---
+
+## Um Runner
+
+Um Runner é um RTE para um AnsibleForms que corre noutro sítio, na versão 7.3.0 ou posterior. Não guarda credenciais da base de dados: inicia sessão
+com um token próprio, que o AnsibleForms guarda numa credencial de RTE (consulte [Modos](../rte/modes.html)). Depois da pasta, o assistente
+pergunta mais três coisas:
+
+| Passo | O que pergunta |
+|---|---|
+| Aplicação | O endereço do AnsibleForms para o qual este Runner trabalha, o que as pessoas abrem num navegador |
+| Modo | **Saída: o Runner liga-se ao AnsibleForms** (a predefinição), ou **Entrada: o AnsibleForms liga-se ao Runner** |
+| Rede | A porta do Runner, `8000` por predefinição. Em saída, só as verificações de saúde escutam nela, acessíveis apenas a partir deste servidor. Em entrada, também o endereço deste servidor tal como o AnsibleForms o alcança |
+
+`--role runner` salta a pergunta da função, por isso este comando, executado no servidor do Runner, começa com as perguntas de um Runner:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+O instalador liga-se então ao AnsibleForms. Um certificado autoassinado, ou de uma CA privada, pergunta **Confiar neste certificado?**:
+sim define [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) no Runner. Lê a versão que o AnsibleForms executa,
+recusa uma anterior à 7.3.0 e instala o Runner com essa mesma versão, seja qual for a versão que o próprio instalador instalaria.
+
+Escolha saída para uma DMZ, NAT ou uma zona que não permite ligações de entrada: apenas tráfego deste servidor para o AnsibleForms, na sua
+porta. Escolha entrada para redes em que o lado central abre todas as ligações.
+
+A revisão mostra **Registo: pede aprovação**, ou **sozinho, com um token de adesão** quando `--join` indicou um. No fim, o instalador
+mostra o nome do Runner, o seu modo, a aplicação e, em entrada, o seu endereço, e depois diz que pediu para aderir ao AnsibleForms: aprove-o em
+**Ligações > Runners**, depois de verificar que a impressão digital mostrada aí é a que ele imprime:
+
+```
+Fingerprint: abcd-ef12
+```
+
+A impressão digital são os primeiros 8 dígitos hexadecimais do SHA-256 do token do Runner, `RTE_TOKEN`, que fica guardado no ficheiro
+`.env` da pasta (`rte.env` numa [instalação nativa](native.html)). Consulte [Aprovar um RTE](../runners/registration.html#approving-an-rte). Com `--join`, o Runner é aprovado de imediato:
+registou-se a si próprio e aparece como ligado em **Ligações > Runners**.
+
+Um Runner de entrada serve o seu socket por HTTPS. O instalador cria um certificado autoassinado para o endereço em que o AnsibleForms
+o alcança, válido durante dez anos, em `data/certificates` da pasta, e define `RTE_URL` como `https://<address>:<port>`.
+O Runner envia o certificado quando pede para aderir, e o AnsibleForms fixa-o: só se liga a esse Runner quando ele apresenta
+esse mesmo certificado, por isso não é necessária nenhuma CA. O instalador imprime a impressão digital do certificado por baixo da do token:
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+São os primeiros 8 dígitos hexadecimais do SHA-256 dos bytes DER do certificado, como `xxxx-xxxx`. Antes de aprovar o Runner,
+verifique que a janela de aprovação mostra a mesma impressão digital do certificado. Um Runner registado com `--join` também a imprime.
+
+Em Kubernetes, um Runner é o modo runner do chart de Helm, e é sempre de saída: o assistente não pergunta o modo nem a rede, pois nada
+o alcança a partir de fora (consulte [Kubernetes](#kubernetes)).
+
+---
+
+## Kubernetes
+
+Para um controlador em Kubernetes, o instalador instala o [chart de Helm](kubernetes.html) no cluster a que o `kubectl` chega:
+
+| Pergunta | Predefinição |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nome da release Helm | `ansibleforms` |
+| Nome de anfitrião servido pelo ingress | Nenhum: obrigatório, como `ansibleforms.example.com` |
+| Classe de ingress | Uma das do cluster, `nginx` por predefinição |
+| Servir por HTTPS (com o certificado do ingress)? | Sim |
+| Classe de armazenamento para os volumes | A predefinida do cluster |
+
+A palavra-passe de administrador está no Secret `<release>-secrets` desse namespace, na chave `ADMIN_PASSWORD`. O instalador guarda os
+valores do chart num ficheiro ao lado do seu ficheiro de estado, `<release>-values.yaml`, e volta a aplicá-lo nas atualizações; `--values` acrescenta um ficheiro seu. O chart de uma versão é publicado pouco depois dela.
+
+Para um Runner, o instalador instala o mesmo chart no seu [modo runner](kubernetes.html#a-runner-on-kubernetes) (`runner.enabled`): um RTE
+sozinho, sem aplicação, sem base de dados e sem ingress, que se liga ao AnsibleForms (saída). Depois do endereço da aplicação, o assistente pergunta:
+
+| Pergunta | Predefinição |
+|---|---|
+| Namespace | `ansibleforms` |
+| Nome da release Helm | `ansibleforms-runner`, que é também o nome do seu runner em **Ligações > Runners** |
+| Classe de armazenamento para os volumes | A predefinida do cluster |
+
+O instalador cria o token do Runner e define o endereço da aplicação, o nome do runner e, quando confia no certificado da aplicação,
+`runner.appTlsVerify: false`. Com `--join`, o token de adesão aprova o Runner de imediato; sem ele, o Runner pede para aderir, e o
+instalador imprime a sua impressão digital para a verificar antes de o aprovar em **Ligações > Runners**.
+
+---
+
+## Comandos
+
+O instalador aceita um comando, antes ou depois das suas flags. Sem nenhum, instala:
+
+| Comando | O que faz |
+|---|---|
+| `install` | Instala o AnsibleForms, como controlador ou como Runner (a predefinição). Num servidor que já tem uma instalação, própria ou que encontre, oferece-se para a atualizar |
+| `upgrade` | Atualiza para uma versão mais recente, mostrando primeiro as suas notas de versão (consulte [Atualizar](#upgrade)) |
+| `status` | Mostra a instalação (a sua função, motor e versão) e os seus contentores, pods ou serviços, e se responde. Depois lista qualquer outro AnsibleForms que encontre no servidor |
+| `backup` | Faz agora uma cópia de segurança da base de dados, para `installer-backups` na pasta de instalação (em Kubernetes, `backups` ao lado do ficheiro de estado do instalador). Um Runner não tem dados para copiar |
+| `release-notes` | Mostra as notas de versão de uma versão, `--version` ou a deste instalador, com as alterações incompatíveis primeiro |
+| `uninstall` | Remove a instalação, e com `--purge` os seus dados |
+| `version` | Imprime a versão do instalador |
+
+O instalador lembra-se da instalação em `/etc/ansibleforms/installer.json` para o root, ou em `~/.config/ansibleforms/installer.json`
+para outro utilizador, por isso os comandos depois de `install` não precisam de flags e encontram a instalação sozinhos. Essa pasta não contém nenhum binário,
+e só existe depois de o instalador ter instalado ou assumido um AnsibleForms:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` pergunta **Eliminar também os dados (BD, formulários, playbooks, registos)?**. Para os eliminar, escreva o nome da instância (a release de Helm
+em Kubernetes); caso contrário, remove os contentores, pods ou serviços e mantém os dados.
+
+---
+
+## Flags
+
+Cada flag responde a uma pergunta, que o assistente depois salta. `ansibleforms-installer --help` lista-as:
+
+| Flag | O que responde |
+|---|---|
+| `--lang <code>` | O idioma: `ca`, `de`, `en`, `es`, `fr`, `it`, `ja`, `nl`, `pl`, `pt` ou `zh` |
+| `--version <version>` | A versão do AnsibleForms a instalar ou para a qual atualizar; por predefinição a deste instalador |
+| `--role <role>` | `controller` ou `runner` |
+| `--mode <mode>` | `compose`, `kubernetes` ou `native` |
+| `--runtime <runtime>` | `docker` ou `podman` (compose) |
+| `--install-runtime` | Instala o Docker ou o Podman quando faltam, sem perguntar |
+| `--dir <folder>` | A pasta de instalação (compose) |
+| `--name <name>` | O nome da instância, o prefixo dos seus contentores (compose, `af` por predefinição) |
+| `--port <port>` | A porta no host: a interface web num controlador, o RTE num Runner |
+| `--tls <choice>` | `self`, `own` ou `off` (um controlador compose) |
+| `--cert <file>`, `--key <file>` | Os ficheiros do certificado e da chave, com `--tls own` |
+| `--admin-password <password>` | A palavra-passe do primeiro administrador; gerada por predefinição |
+| `--join <token>` | Um token de adesão (`afj_...`), criado através da API, que aprova o Runner de imediato (um Runner, sem intervenção; consulte [Tokens de adesão](../runners/registration.html#join-tokens)) |
+| `--app-url <address>` | O endereço da aplicação, como `https://forms.example.com` (um Runner) |
+| `--runner-mode <mode>` | `outbound` (o RTE liga-se à aplicação) ou `inbound` (a aplicação liga-se ao RTE) (um Runner) |
+| `--host <address>` | O endereço deste servidor, ao qual a aplicação se liga (um Runner de entrada) |
+| `--namespace <namespace>` | O namespace de Kubernetes, `ansibleforms` por predefinição |
+| `--release <release>` | A release de Helm, `ansibleforms` por predefinição |
+| `--hostname <name>` | O nome de anfitrião do ingress (kubernetes) |
+| `--ingress-class <class>` | A classe de ingress (kubernetes) |
+| `--storage-class <class>` | A classe de armazenamento (kubernetes) |
+| `--values <file>` | Um ficheiro de valores de Helm adicional (kubernetes) |
+| `--purge` | Com `uninstall`: elimina também os dados |
+| `--source <folder>` | Uma cópia local do repositório [ansibleforms/docker](https://github.com/ansibleforms/docker) a partir da qual instalar (air-gapped) |
+| `--bundle <file>` | Um pacote de versão, `ansibleforms-<version>-linux-<arch>.tar.gz`, a partir do qual instalar de forma nativa (consulte [Instalação nativa](native.html#air-gapped)) |
+| `--yes` | Responde a todas as perguntas com a predefinição (sem intervenção) |
+| `--verbose` | Mostra todos os comandos que executa |
+
+---
+
+## Sem intervenção
+
+Com `--yes`, ou sem um terminal, o instalador não pergunta nada: as flags respondem às suas perguntas e as predefinições respondem ao resto. Salta
+o idioma, as notas de versão, a palavra-passe de administrador (gerada, a menos que `--admin-password` indique uma) e a revisão, e imprime
+em vez disso a ligação para as notas de versão. Só instala um Docker ou Podman em falta com `--install-runtime` ou `--yes`, e um Runner
+precisa de `--app-url`. Sem `--join`, o Runner pede para aderir e espera pela aprovação de um administrador; com ele, é aprovado de imediato.
+
+Um controlador em Docker, instalando o Docker quando falta:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+Um Runner de entrada em Podman, ao qual a aplicação se liga em `rte-dmz.example.com:8000`:
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## Uma instalação existente
+
+O instalador lembra-se do que instalou em `installer.json`. Sem esse ficheiro, `install`, `upgrade` e `status` procuram primeiro um
+AnsibleForms que já esteja no servidor, seja o que for que o tenha instalado:
+
+| Encontrado | Como é encontrado | Assumido quando |
+|---|---|---|
+| Docker ou Podman | Contentores da imagem da aplicação ou do RTE, agrupados por projeto compose | A pasta contém o ficheiro de compose e o `.env` do repositório [ansibleforms/docker](https://github.com/ansibleforms/docker): os serviços `mysqldb`, `app` e `rte`, nos contentores `<name>_db`, `<name>_app` e `<name>_rte` |
+| Um Runner 7.2 | Um RTE sozinho no seu projeto compose, com os `DB_*` da aplicação e sem `RTE_MODE` (modo base de dados) | O seu ficheiro de compose é legível. A sua atualização passa-o para um modo socket (consulte [Um Runner 7.2](#a-72-runner)) |
+| Kubernetes | Releases de Helm do chart `ansibleforms`, e Deployments e StatefulSets das suas imagens | É uma release do chart: os seus valores atuais tornam-se o seu ficheiro de valores |
+| Nativa | Serviços systemd que executam o AnsibleForms com Node.js | Seguem a estrutura do instalador: `releases/`, `current`, `app.env` e `rte.env` (consulte [Instalação nativa](native.html#the-folder)) |
+| Sem motor | A aplicação ou um RTE a responder numa porta habitual: 443, 3000, 3001, 8000, 8001, 8010 ou 8443 | Nunca: é executado a partir do código-fonte ou à mão. O instalador apenas o comunica |
+
+Só contam as imagens da aplicação e do RTE: um contentor MySQL com o nome do AnsibleForms não é uma instalação. O instalador lista o que
+encontrou, uma linha por cada, com o motivo e o que fazer à mão para uma que não consegue assumir: o seu ficheiro de compose não é o do repositório,
+a sua base de dados está fora do seu projeto compose, corre em Kubernetes sem o chart de Helm, é gerida pelo Argo CD (atualize-a aí,
+alterando a versão do chart da Application), ou não é possível ler a sua versão.
+
+Para uma instalação que consegue assumir, `install` oferece três opções:
+
+| Opção | O que faz |
+|---|---|
+| Assumir e atualizar | Mostra o que vai memorizar, depois escreve `installer.json` assim que confirmar, e continua com a [atualização](#upgrade) |
+| Instalar mesmo assim um novo AnsibleForms ao lado | Uma segunda instalação, com a sua própria pasta, portas e base de dados, depois de uma confirmação própria |
+| Parar | Nada é alterado |
+
+Para uma instalação que já executa a versão que o instalador instalaria, a primeira opção passa a ser **Assumir**: o instalador
+memoriza onde está e como é executada, para as suas cópias de segurança, estado e próximas atualizações, e nada é alterado agora.
+
+`upgrade` oferece o mesmo sem a segunda opção, e para quando não há nada para assumir. Sem intervenção, `install` para com uma mensagem,
+e `upgrade --yes` só assume uma instalação quando encontra exatamente uma que consiga assumir. Os valores atuais de uma release de Kubernetes são
+guardados ao lado de `installer.json`, e as atualizações voltam a aplicá-los com o chart da nova versão.
+
+---
+
+## Atualizar
+
+`ansibleforms-installer upgrade` passa a instalação para uma versão mais recente da mesma versão principal. Lista as versões mais recentes,
+a mais nova primeiro (sem intervenção, escolhe a mais nova), e mostra as notas de versão de todas as versões que ultrapassa, com as alterações incompatíveis
+e as remoções primeiro. Quando contêm alterações incompatíveis, pede-lhe que confirme que as leu; sem intervenção, só `--yes` continua.
+
+O instalador faz uma cópia de segurança da base de dados antes de alterar seja o que for. Quando a nova versão não responde, oferece-se para reverter: a versão
+anterior volta, e a sua base de dados é restaurada a partir dessa cópia de segurança. Não faz downgrade, e não atravessa uma versão principal: siga
+o [guia de atualização](../upgrade-7.html) para isso, por exemplo da 6.x para a 7.x, com o que fazer na 6.5 antes de atualizar.
+
+Em Docker ou Podman, a atualização de um controlador também atualiza os seus ficheiros para a nova versão do repositório docker:
+
+| Ficheiro | O que a atualização faz |
+|---|---|
+| `docker-compose.yml` | Substituído pelo da nova versão, depois de guardar uma cópia em `installer-backups` |
+| `.env` | Todas as linhas existentes são mantidas, e são adicionadas as chaves de que a nova versão precisa, com segredos criados tal como numa instalação nova. É guardada primeiro uma cópia |
+| `data/seed.yaml` | Substituído quando é um seed fornecido pelo repositório docker, sem alterações. Um alterado à mão é mantido, e o novo é guardado ao lado |
+| `data/` | São adicionados os ficheiros novos que a versão traz, como um novo playbook. Todos os ficheiros existentes são mantidos |
+
+Uma definição da base de dados em falta (`MYSQLDB_USER` ou uma palavra-passe) não pode ser inventada para uma base de dados que já existe, por isso a atualização para antes
+de qualquer alteração. Uma reversão repõe o ficheiro de compose, o `.env` e o seed tal como estavam.
+
+Um Runner executa a mesma versão que o seu AnsibleForms: atualize primeiro o AnsibleForms e depois os seus Runners. A atualização de um Runner reescreve o seu
+ficheiro de compose para a nova imagem do RTE e mantém o seu `.env` e os seus dados como estão.
+
+---
+
+## Um Runner 7.2
+
+Um Runner da 7.2 corre em modo base de dados, obsoleto desde a 7.3.0: o seu RTE guarda as definições da base de dados do AnsibleForms. O instalador encontra-o
+(consulte [Uma instalação existente](#an-existing-installation)), e a sua atualização passa-o para um modo socket sob o mesmo runner:
+
+1. Lê o nome do runner (`RTE_NAME`) e o token (`RTE_TOKEN`) do contentor RTE antigo. Quando o RTE não se registou a si próprio
+   (`RTE_REGISTER=0`), escreve o nome que o seu runner tem em **Ligações > Runners**
+2. Pergunta o endereço da aplicação e o modo, **saída** por predefinição ou entrada, e em entrada a porta e o endereço deste servidor
+3. Mostra o plano e depois faz uma cópia de segurança do ficheiro de compose antigo e do `.env` para `installer-backups`
+4. Escreve a estrutura de Runner do instalador sem as definições `DB_*`. Mantém `RTE_MAX_JOBS`, `RTE_DRAIN_SECONDS`,
+   `PROCESS_MAX_BUFFER` e `METRICS_TOKEN`, que um RTE em modo socket continua a ler
+5. Inicia o novo RTE ao lado do antigo. O novo RTE inicia sessão com o token do próprio runner, e o AnsibleForms passa o runner para o
+   novo modo sozinho, **sem aprovação**: as suas tarefas e os formulários que o indicam não mudam
+6. Assim que o novo RTE estiver ligado, o contentor antigo é parado e removido
+
+Um Runner de entrada serve HTTPS com um certificado fixado, tal como um novo (consulte [Um Runner](#a-runner)), e o instalador imprime a
+impressão digital do seu certificado. Quando o RTE antigo ocupa a porta de que o novo precisa, é parado primeiro, por isso o Runner fica offline até o
+novo se ligar. O novo RTE de um Runner de saída usa uma porta livre em `127.0.0.1` e corre ao lado do antigo sem interrupção.
+
+Quando o instalador não consegue ler um token do RTE antigo, escolhe como o novo RTE inicia sessão:
+
+| Opção | O que se segue |
+|---|---|
+| Escrever o token do runner | A palavra-passe da credencial de RTE do runner em **Ligações > Credenciais**. O runner mantém o seu nome e as suas tarefas |
+| Aderir como runner novo com um token de adesão | Um [token de adesão](../runners/registration.html#join-tokens) adiciona um novo runner com outro nome. Retire o runner antigo à mão |
+
+Quando o novo RTE não se liga, o instalador oferece-se para repor os ficheiros antigos e voltar a iniciar o contentor antigo; se o AnsibleForms
+já tinha passado o runner para o novo modo, volte a colocar o seu modo em base de dados em **Ligações > Runners**. Assim que o novo RTE estiver ligado, não há
+volta atrás: os ficheiros antigos ficam em `installer-backups`.
+
+Quando o AnsibleForms não conhece nenhum runner com esse nome, o novo RTE pede antes para aderir e espera por uma aprovação. Rejeite esse pedido em
+**Ligações > Runners** e depois execute novamente a atualização com o nome que o runner tem lá.
+
+---
+
+## Versões
+
+A versão do instalador acompanha a da aplicação: cada versão do AnsibleForms vem com um instalador da mesma versão, lançado com ela, e
+esse instalador instala essa versão por predefinição. `--version` instala outra. Cada versão na
+[página de Releases do instalador](https://github.com/ansibleforms/installer/releases) tem binários para Linux em amd64 e arm64, com os seus
+checksums.
diff --git a/i18n/pt/_get_started/installation/kubernetes.md b/i18n/pt/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..0cc6404
--- /dev/null
+++ b/i18n/pt/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: Instalação
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+Instale o AnsibleForms e a sua base de dados MySQL com o chart de Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+O chart de Helm implementa o AnsibleForms com o MySQL e o RTE que executa os playbooks (consulte a [referência de valores](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)).
+O [instalador](installer.html) também instala o chart, a partir de algumas perguntas, e atualiza uma release que não instalou. O mesmo
+chart também instala um Runner sozinho, para um AnsibleForms que corre noutro sítio (consulte [Um Runner em Kubernetes](#a-runner-on-kubernetes)).
+
+---
+
+## Pré-requisitos
+
+Antes de começar, precisa de:
+
+* **Cluster Kubernetes** : com o `kubectl` configurado para lhe chegar
+* **Helm 3** : para instalar e atualizar o chart
+* **Armazenamento** : uma StorageClass para aprovisionamento dinâmico, ou PersistentVolumes criados previamente
+* **Ingress controller** : apenas se quiser expor o AnsibleForms através de um ingress
+
+---
+
+## 1. Obtenha os valores do chart
+
+Obtenha os valores predefinidos do chart para um ficheiro seu, a partir do repositório de charts ou do registo OCI:
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Repositório de charts</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">Registo OCI</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+Não há repositório a adicionar: o chart é obtido do GitHub Container Registry.
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. Configure o armazenamento
+
+Tanto o AnsibleForms como o MySQL guardam os seus dados num volume persistente. Defina a StorageClass e o tamanho de cada um:
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+Um `className` vazio usa a StorageClass predefinida do cluster. O modo de acesso é por predefinição `ReadWriteMany`, que muitas classes de
+armazenamento não oferecem; `ReadWriteOnce` serve bem com uma única réplica. Para PersistentVolumes criados previamente, consulte o
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) do chart.
+
+---
+
+## 3. Defina as credenciais
+
+O AnsibleForms precisa de uma conta de administrador, de uma palavra-passe da base de dados e de um `ENCRYPTION_SECRET`, a chave que cifra as credenciais
+guardadas no AnsibleForms. Para alterar essa chave mais tarde, defina [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+com a antiga durante um arranque: todos os segredos guardados são então cifrados de novo com a nova chave. Forneça-os de uma de três formas:
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">No ficheiro de valores</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">Gerados pelo chart</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">Secret existente</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+Defina-os em `my_values.yaml`. O chart guarda-os num Secret chamado `<release>-secrets`:
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+Deixe o chart gerar tudo o que não fornecer, na primeira instalação. Depois mantém os mesmos valores em todas as
+atualizações:
+
+```bash
+--set secrets.generate=true
+```
+
+Isto não funciona com o Argo CD nem com o Flux, que renderizam o chart sem acesso ao cluster. O Secret gerado
+sobrevive a `helm uninstall`; faça uma cópia de segurança dele, porque o `ENCRYPTION_SECRET` não pode ser recuperado.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+Aponte o chart para um Secret gerido por si, por exemplo com External Secrets, Sealed Secrets ou SOPS. O chart
+não cria então nenhum:
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+O Secret tem de conter `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET`, `ADMIN_USERNAME` e `ADMIN_PASSWORD`.
+
+</div>
+</div>
+
+---
+
+## 4. Escolha a imagem do RTE
+
+O AnsibleForms 7 não executa nenhum playbook por si: quem o faz é o RTE (ambiente de execução). O chart executa-o como um segundo contentor no
+pod do servidor, no mesmo volume, e regista-o como o runner predefinido `rte`, para que os formulários de playbook funcionem sem qualquer configuração. Desde a 7.3.0
+a aplicação liga-se a ele em `127.0.0.1` e mantém um WebSocket aberto (`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)): o RTE não recebe
+definições da base de dados nem a chave de cifragem. O config seed do chart declara uma credencial de RTE com o token e esse endereço, e
+o runner, em modo inbound, que inicia sessão com ela.
+
+A imagem predefinida, `ghcr.io/ansibleforms/ansibleforms-rte-full`, contém o ansible com as suas coleções e as bibliotecas Python que a imagem 6.5 tinha.
+Para mais, ou para menos, construa a sua própria sobre uma das três camadas do RTE (`ansibleforms-rte-base`, `-rte-core` ou `-rte-full`, consulte
+[As imagens do RTE](../rte/images.html)) e aponte o chart para ela:
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+O token entre a aplicação e o RTE, e a chave que assina as sessões, são gerados na primeira instalação no
+Secret `<release>-keys` e mantidos em todas as atualizações. Com um config seed seu, adicione-lhe essa credencial e esse runner: as notas que o Helm imprime depois da instalação mostram como
+(consulte o [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) do chart).
+
+---
+
+## 5. Instale o chart
+
+Instale o chart no seu próprio namespace com os seus valores:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+Com o registo OCI, use `oci://ghcr.io/ansibleforms/charts/ansibleforms` como chart. Em tudo o que corra sem intervenção,
+fixe a versão do chart com `--version`, para que uma nova versão nunca seja instalada sozinha.
+
+---
+
+## 6. Verifique a instalação
+
+O chart inclui um teste que verifica tanto o servidor web como a ligação à base de dados:
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+O teste termina com `OK` quando o AnsibleForms responde e a sua base de dados aceita ligações.
+
+---
+
+## 7. Abra o AnsibleForms
+
+A forma de chegar ao AnsibleForms depende de como o servidor está exposto:
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">Port forward</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+Com o serviço `ClusterIP` predefinido e sem ingress, nada fica exposto fora do cluster. Reencaminhe uma porta local para
+dar uma vista de olhos:
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+Depois abra `http://127.0.0.1:8080/`.
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+Defina `services.server.type: LoadBalancer` (opcionalmente com um endereço fixo em `services.server.loadbalancer.ip`)
+e depois espere que o serviço obtenha o seu endereço:
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+Ative o ingress e defina o nome de anfitrião que encaminha para o seu ingress controller:
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+O [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) do chart trata do TLS por trás de um ingress, incluindo a definição de backend de que o HTTPS no
+servidor precisa.
+
+</div>
+</div>
+
+---
+
+## 8. Inicie sessão
+
+Inicie sessão como o utilizador administrador, `admin` por predefinição. Para ler a palavra-passe do Secret:
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+Com `secrets.existingSecret`, leia-a antes do seu próprio Secret.
+
+---
+
+## Um Runner em Kubernetes
+
+Com `runner.enabled`, o chart instala apenas um RTE: um Runner para um AnsibleForms instalado noutro sítio, noutro namespace, noutro
+cluster ou numa VM. Liga-se à aplicação e mantém um WebSocket aberto (`RTE_MODE=outbound`, consulte [Modos](../rte/modes.html)), por isso não precisa
+de base de dados, de chave de cifragem nem de porta de entrada. Não renderiza aplicação, MySQL, Service nem Ingress:
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| Valor | O que faz |
+|---|---|
+| `runner.enabled` | Instala apenas o Runner: sem aplicação, sem MySQL, sem Service, sem Ingress |
+| `runner.appUrl` | O endereço da aplicação tal como as pessoas o abrem, com o seu `BASE_URL`, se existir. Obrigatório |
+| `runner.name` | O nome de runner com que adere (`RTE_NAME`). Vazio: o nome da release |
+| `runner.joinToken` | Um [token de adesão](../runners/registration.html#join-tokens) criado na aplicação, lido no primeiro arranque para aprovar o Runner de imediato |
+| `runner.appTlsVerify` | `false` aceita o certificado autoassinado da aplicação (`APP_TLS_VERIFY=0`), apenas dentro de uma rede de confiança |
+
+Sem um token de adesão, o Runner pede para aderir e espera até que um administrador o aprove em **Ligações > Runners**. Depois de aprovado,
+inicia sessão com o seu próprio `RTE_TOKEN`, guardado no Secret `<release>-keys`: mantenha esse Secret com a release. O
+[instalador](installer.html#kubernetes) também instala este modo runner, quando escolhe a função Runner e Kubernetes.
+
+---
+
+## Próximos passos
+
+O [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) do chart trata do resto da configuração:
+
+* **A sua própria base de dados** : defina `mysql.enabled: false` e aponte o AnsibleForms para um servidor MySQL existente
+* **Formulários a partir de ConfigMaps** : forneça o `config.yaml` e os ficheiros de formulário através de ConfigMaps
+* **HTTPS por trás de um ingress**, recursos, colocação nos nós e registos privados
+* **O RTE** : o seu token, uma imagem de RTE própria, ou nenhum RTE
+
+Para passar para uma versão mais recente, consulte [Atualizar em Kubernetes](../upgrading/kubernetes.html).
diff --git a/i18n/pt/_get_started/installation/native.md b/i18n/pt/_get_started/installation/native.md
new file mode 100644
index 0000000..f218211
--- /dev/null
+++ b/i18n/pt/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: Nativa
+parent: Instalação
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# Instalação nativa
+{: .no_toc }
+
+O AnsibleForms diretamente no servidor, sem contentores, como serviços systemd configurados pelo instalador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores de servidores onde os contentores não são permitidos: o [instalador](installer.html) instala tudo o que o AnsibleForms precisa
+no próprio servidor, e depois atualiza-o e remove-o. Instala o AnsibleForms 7.3.0 ou posterior.
+
+---
+
+## Do que precisa
+
+Escolha **Diretamente neste servidor, sem contentores** no passo **Motor** do instalador, ou passe `--mode native`. Precisa de:
+
+* **Root** : execute o instalador com `sudo` (`curl -fsSL https://ansibleforms.com/install | sudo sh`)
+* **systemd** : os serviços correm como unidades systemd
+* **Um Linux suportado** : Ubuntu, Debian, RHEL e as suas recompilações como Rocky Linux e AlmaLinux, SUSE Linux Enterprise ou openSUSE
+* **amd64 ou arm64**
+* **Acesso à Internet** : aos repositórios da distribuição, ao GitHub, ao nodejs.org e aos índices de pacotes de Python e Ansible (consulte
+  [Air-gapped](#air-gapped) para saber o que um pacote de versão substitui)
+
+Num servidor que não cumpra isto, o motor aparece como *Diretamente neste servidor (requer root: execute o instalador com sudo)* ou
+*Diretamente neste servidor (não suportado neste Linux)*. As duas funções instalam-se desta forma: um controlador e um [Runner](installer.html#a-runner).
+
+---
+
+## O que instala
+
+O instalador instala o seguinte a partir dos pacotes da distribuição, para as duas funções:
+
+| Pacote | Porquê |
+|---|---|
+| `git` | Os repositórios |
+| O cliente ssh | As ligações dos playbooks |
+| O cliente MariaDB | As cópias de segurança da aplicação: `app.env` define [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) e [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) com o cliente encontrado, `mariadb-dump` e `mariadb` ou os mais antigos `mysqldump` e `mysql` |
+| `ca-certificates`, `curl`, `tar`, `gzip` | As transferências |
+| `libatomic` | O Node.js liga-se a ela, e os servidores mínimos não a têm |
+| `sshpass` | Playbooks que iniciam sessão com uma palavra-passe ssh. No RHEL e nas suas recompilações vem do EPEL, que o instalador tenta ativar com `epel-release`; quando não pode ser instalado, a instalação continua e avisa |
+| O servidor MariaDB | Apenas num controlador: a sua base de dados |
+
+Depois, para a pasta de instalação, com cada transferência verificada contra o seu checksum publicado:
+
+* **AnsibleForms** : o pacote de versão `ansibleforms-<version>-linux-<arch>.tar.gz` da release da aplicação no GitHub, a aplicação compilada para
+  Node.js. Uma versão sem pacote mostra *Instalar sem contentores requer o AnsibleForms 7.3.0 ou posterior.*
+* **Node.js** : a versão mais recente da versão principal indicada pelo pacote, a partir do nodejs.org
+* **Python e Ansible** : o uv, e depois com ele o Python das imagens do RTE e um ambiente virtual com o Ansible e as bibliotecas da
+  imagem RTE full, e depois as suas coleções Ansible (consulte [As imagens do RTE](../rte/images.html)). Isto demora alguns minutos
+* **Os ficheiros iniciais** : os formulários, playbooks e definições da pasta `data` do
+  [projeto docker-compose](https://github.com/ansibleforms/docker), tal como uma nova instalação Docker Compose os recebe. Um Runner mantém apenas a sua configuração do Ansible, ssh e git
+
+Para um controlador, cria depois o esquema `AnsibleForms` no MariaDB, e um utilizador da base de dados com o nome da instância, com todos os direitos sobre esse
+esquema e nenhum noutro sítio, que inicia sessão apenas a partir deste servidor.
+
+---
+
+## A pasta
+
+Tudo fica na pasta de instalação, `/opt/ansibleforms` (ou `/opt/ansibleforms-runner` num Runner) por predefinição:
+
+| Caminho | O que contém |
+|---|---|
+| `releases/<version>/` | Uma versão: o pacote, a sua ligação ao Node.js, o seu ambiente virtual Python e as suas coleções |
+| `current` | A ligação para a versão em execução; uma atualização move-a, e uma reversão também |
+| `runtime/` | Node.js, uv e Python, partilhados pelas versões |
+| `data/` | O que os contentores montam como `/app/dist/persistent`: formulários, playbooks, `config.yaml`, o config seed, certificados e registos |
+| `home/` | A pasta pessoal do utilizador de sistema: `.ssh` e `.gitconfig`, ligados a `data/ssh` e `data/git` |
+| `app.env`, `rte.env` | As definições e os segredos dos serviços, legíveis apenas pelo root e pelo utilizador de sistema. O do RTE não contém definições da base de dados |
+| `installer-backups/` | As cópias de segurança da base de dados que o instalador faz, antes de uma atualização ou com `backup` |
+
+As versões e os runtimes pertencem ao root, para que os serviços não possam alterar o seu próprio código; `data/` e `home/` pertencem ao utilizador de sistema.
+Os ficheiros da base de dados propriamente ditos são guardados pelo MariaDB, fora da pasta.
+
+---
+
+## Os serviços
+
+Um controlador executa dois serviços systemd, um Runner executa um. Cada um corre como um utilizador de sistema com o nome da instância (`ansibleforms` por predefinição),
+a partir de `current/server`, com o seu ficheiro de definições:
+
+| Serviço | O que executa | Definições |
+|---|---|---|
+| `<name>` | A aplicação: a interface web, a API e o worker. Apenas num controlador | `app.env` |
+| `<name>-rte` | O RTE que executa os playbooks | `rte.env` |
+
+O RTE de um controlador é `inbound` numa porta própria em `127.0.0.1` (`8001`, ou a livre seguinte, com
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`), executa os playbooks a partir das pastas da aplicação (`RTE_FILES=local`),
+e é declarado pelo config seed `data/seed.yaml` como o runner predefinido.
+
+O RTE de um Runner recebe o modo, `APP_URL`, `RTE_NAME` e, com `--join`, o token de adesão, e recebe os playbooks com cada tarefa (consulte
+[Modos](../rte/modes.html)). Um de saída não recebe chamadas da aplicação, por isso escuta apenas em `127.0.0.1` (`LISTEN_HOST=127.0.0.1`).
+Um de entrada serve HTTPS com um certificado autoassinado do seu próprio endereço em `data/certificates`, que o AnsibleForms fixa.
+Sem um token de adesão, pede para aderir, e um administrador aprova-o em **Ligações > Runners**.
+
+Iniciam no arranque e reiniciam após uma falha. Faça a sua gestão e leia os seus registos com as próprias ferramentas do systemd:
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+A aplicação pode escutar numa porta abaixo de 1024, como a `443`, sem root. O RTE mantém o direito de usar `sudo`, de que os playbooks com
+`become` precisam neste servidor, para que um playbook possa gerir o servidor onde o RTE corre.
+
+---
+
+## Atualizar e reverter
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` atualiza uma instalação nativa tal como as outras (consulte [Atualizar](installer.html#upgrade)), por
+esta ordem:
+
+1. Coloca a nova versão ao lado da que está em execução: o seu pacote, Node.js, Python, Ansible e as coleções. Os serviços em execução
+   ainda não são tocados
+2. Adiciona os novos ficheiros iniciais que a versão traz, mantendo todos os ficheiros existentes
+3. Faz uma cópia de segurança da base de dados (num controlador) para `installer-backups/`, com uma cópia de `app.env` e `rte.env`
+4. Para os serviços, aponta `current` para a nova versão e volta a iniciá-los
+5. Espera que a aplicação responda com a nova versão (num Runner: que o seu RTE volte a escutar)
+
+Quando a nova versão não responde, o instalador oferece-se para reverter: `current` volta a apontar para a versão anterior, a
+base de dados é restaurada a partir da cópia de segurança, e os serviços iniciam. Só se mantêm a versão em execução e a anterior.
+
+Serviços nativos com a estrutura do instalador sem nenhum `installer.json` ao lado, por exemplo depois de ter sido eliminado, são encontrados por `install`
+e `upgrade`, que se oferecem para os assumir (consulte [Uma instalação existente](installer.html#an-existing-installation)).
+
+---
+
+## Desinstalar
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` para e remove os serviços. Mantém a pasta e a base de dados, a menos que opte por eliminar
+os dados (ou passe `--purge`) e escreva o nome da instância para confirmar. Nesse caso também elimina a base de dados e o seu utilizador (num controlador),
+apaga a pasta e remove o utilizador de sistema.
+
+Os pacotes continuam instalados, incluindo o MariaDB: outro software pode usá-los.
+
+---
+
+## Air-gapped
+
+`--bundle` instala a partir de um pacote de versão que copiou para o servidor, em vez de o descarregar do GitHub. Use o ficheiro da sua
+arquitetura, `ansibleforms-<version>-linux-amd64.tar.gz` ou `-arm64`, das [Releases](https://github.com/ansibleforms/ansibleforms/releases) da aplicação:
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` faz o mesmo para os ficheiros iniciais, a partir de uma cópia local do repositório [ansibleforms/docker](https://github.com/ansibleforms/docker).
+O Node.js, o Python com os seus pacotes e as coleções Ansible continuam a ser descarregados durante a instalação.
diff --git a/i18n/pt/_get_started/upgrade-7.md b/i18n/pt/_get_started/upgrade-7.md
new file mode 100644
index 0000000..0397618
--- /dev/null
+++ b/i18n/pt/_get_started/upgrade-7.md
@@ -0,0 +1,302 @@
+---
+layout: default
+title: Atualizar para a v7
+parent: Atualizar
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# Atualizar para a v7
+{: .no_toc }
+
+O que alterar enquanto ainda está na 6.5, e o que muda quando passa para a versão 7
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+A versão 7 remove tudo o que a 6.x tinha descontinuado; corrija-o primeiro na 6.5, onde o antigo e o novo funcionam, e depois atualize.
+
+---
+
+## Antes de atualizar (na 6.5)
+
+### Os formulários vivem nos seus próprios ficheiros
+
+Os formulários vivem apenas na pasta de formulários (`FORMS_FOLDER_PATH`) ou num repositório de formulários; o `config.yaml` guarda as categorias, as funções e as constantes.
+
+- **Um ficheiro `forms.yaml`:** mude-lhe o nome para `config.yaml`. Na 6.5, a página de definições tem um
+  botão **Convert forms.yaml to config.yaml** para isso.
+- **Uma secção `forms:` na configuração base:** a versão 7 rejeita-a. Mova cada formulário para o seu próprio ficheiro, por exemplo
+  arrastando-o para um ficheiro no designer da 6.5.
+- **Variáveis de ambiente:**
+
+  | Removida | Use em vez disso |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` e `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### O campo `table`
+
+A versão 7 rejeita os campos `table`, e as suas propriedades (`tableFields`, `insertColumns`, `readonlyColumns`,
+`tableTitleAdd`, `tableTitleEdit`) vão com eles: use um campo `list` com um `subform`, e transforme o `from` de cada coluna numa expressão
+sobre `__parent__` (consulte as [FAQ](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)).
+
+### Propriedades com novo nome
+
+Cada propriedade removida tem uma substituição direta:
+
+| Removida | Use em vez disso |
+|---|---|
+| `disableRelaunch: true` (formulário) | `allowRelaunch: false` |
+| `noOutput: true` (campo) | `output: false` |
+| `enableLogin` (opção de função) | `allowLogin` |
+
+### Datasources e esquemas de dados
+
+As importações de datasources e as suas páginas de administração foram removidas, tal como a
+coleção AnsibleForms do Galaxy, cujos módulos só serviam para elas.
+
+- As importações agendadas param e as tabelas de datasources são eliminadas: anote primeiro o que precisa.
+- Os esquemas de dados que uma importação preenchia são bases de dados próprias e mantêm-se. Um formulário que
+  os consulta através de uma credencial continua a funcionar.
+- Para manter esses dados atualizados, execute a importação como um playbook seu, por exemplo a partir de um
+  agendamento.
+
+### API v1
+
+`/api/v1/*` foi removida; use `/api/v2/*` (documentação interativa em `/api/v2/docs`). As chamadas que os
+scripts costumam usar são:
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+A v2 responde com códigos de estado HTTP (`400`, `403`, `404`, `422`) e um corpo JSON simples, e não com o envelope
+`{ status, message, data }` da v1.
+
+**Também as callbacks de início de sessão único.** Um URL de redirecionamento com `/api/v1/` deixa de responder: o início de sessão volta à
+página de início de sessão sem iniciar sessão. Altere-o para `/api/v2/` em dois sítios, no fornecedor de SSO no
+AnsibleForms e no fornecedor de identidade (os URIs de redirecionamento do registo da aplicação no Entra ID, os URIs de redirecionamento válidos do
+cliente OIDC):
+
+- Entra ID: `https://<your host>/api/v2/auth/azureadoauth2/callback`, ou `/api/v2/auth/entraid/callback` a partir da 7.3.0
+- OIDC: `https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## O que muda na 7
+
+A versão 7 muda a forma como os playbooks são executados e torna várias predefinições mais restritas. Verifique cada ponto abaixo quando passar da 6.5.
+
+### Os playbooks são executados num RTE
+
+A versão 7 deixa de executar `ansible-playbook` no contentor do AnsibleForms. Os playbooks são executados num ambiente de execução (RTE),
+um contentor próprio, e a imagem da aplicação já não contém ansible nem python. Inicie um RTE ao lado da aplicação, a partir da
+imagem `ghcr.io/ansibleforms/ansibleforms-rte-full:7`. Desde a 7.3.0, a aplicação liga-se ao RTE e mantém um WebSocket aberto (consulte
+[Modos](rte/modes.html)): o RTE não recebe definições da base de dados nem o `ENCRYPTION_SECRET`. As suas definições:
+
+| Definição | Valor |
+|---|---|
+| `AF_ROLE` | `rte`. As imagens do RTE já a definem. |
+| `RTE_MODE` | `inbound`: a aplicação liga-se ao RTE. Um Runner noutra rede usa `outbound` (consulte [Modos](rte/modes.html)). |
+| `RTE_TOKEN` | Um token com pelo menos 16 caracteres. A aplicação inicia sessão no socket do RTE com ele, e o RTE recusa-se a arrancar sem um. |
+| `RTE_FILES` | `local` quando o RTE monta a mesma pasta persistente que a aplicação, como ao lado dela. |
+
+Depois mova as montagens do ansible do contentor da aplicação para o RTE:
+
+- `ansible.cfg` em `/etc/ansible/ansible.cfg`, as suas roles em `/etc/ansible/roles` e as suas coleções em
+  `/etc/ansible/collections`.
+- Monte também no RTE a mesma pasta persistente que na aplicação, para que encontre os playbooks e os repositórios.
+
+Depois declare o RTE como runner, no [config seed](seed/) como faz o projeto Docker Compose, ou em **Ligações → Runners**:
+uma credencial de RTE com o endereço do RTE (por exemplo `http://rte:8000`) e o mesmo token, e um runner do tipo RTE, em modo inbound,
+que a indica:
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+O seed lê `RTE_TOKEN` do ambiente da aplicação. Consulte [Runners](runners.html) e [Ambientes de execução](rte/).
+
+{: .warning }
+> **O mesmo contrato para a aplicação e para o RTE** A aplicação resolve as credenciais de uma tarefa e entrega-as ao RTE seladas para
+> esse RTE (contrato RTE 2, novo na 7.0.0). Um RTE de outro contrato recusa as tarefas da aplicação: execute a imagem do RTE da mesma
+> versão que a aplicação, e atualize as duas em conjunto. As versões 7 posteriores continuam a funcionar com um RTE 7 mais antigo desde que o contrato
+> se mantenha (consulte [Escalar](../rte/images.html#build-your-own-rte)).
+
+
+### O que contém a imagem do RTE
+
+O RTE existe em três camadas, cada uma construída sobre a anterior. Escolha a que se adequa aos seus playbooks:
+
+| Imagem | Conteúdo |
+|---|---|
+| `ansibleforms-rte-full` | A predefinida. Ansible 14 com ansible-core 2.21, e as coleções e bibliotecas python que a imagem 6.5 tinha. |
+| `ansibleforms-rte-core` | Python 3.14, ansible-core e algumas bibliotecas comuns, sem coleções. Adicione as suas numa imagem construída sobre ela. |
+| `ansibleforms-rte-base` | Apenas o servidor, sem python nem ansible, para construir um RTE com as suas próprias versões. |
+
+Passar da 6.5 (ansible 12 com ansible-core 2.19) também muda o seguinte para os seus playbooks:
+
+- **ansible-core 2.21:** leia os [guias de migração](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)
+  da 2.20 e da 2.21.
+- **Python 3.14:** as camadas do RTE correm em python 3.14.
+- **Já não há `boto`:** a antiga biblioteca `boto` 2 desapareceu. A coleção `amazon.aws` usa `boto3`, que está incluída.
+
+Duas variáveis de ambiente pertencem agora ao RTE e já não são lidas pela aplicação, por isso defina-as no contentor do RTE:
+
+| Variável | Alteração |
+|---|---|
+| `ANSIBLE_PATH` | A pasta de playbooks, no RTE. |
+| `PROCESS_MAX_BUFFER` | Agora 50 MB por predefinição. Acima disso, a saída da tarefa deixa de ser guardada (a tarefa indica-o), mas o playbook continua em vez de ser parado. |
+
+
+### Os contentores correm com o uid 1000
+
+As imagens da aplicação e do RTE correm como o utilizador `node` (uid 1000) em vez de root, e a sua pasta pessoal é `/home/node`:
+
+- **Dê os volumes ao uid 1000, uma vez.** Para os volumes persistente e ssh, execute
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v`; para uma pasta do host, `sudo chown -R 1000:1000 <folder>`.
+  Em Kubernetes, defina `fsGroup: 1000`.
+- **Monte a pasta ssh em `/home/node/.ssh`**, e não em `/root/.ssh`. Se definiu
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) como `/root`, remova-a ou defina-a como `/home/node`.
+- **A sua própria imagem de RTE** construída sobre uma camada do RTE muda para `USER root` para as suas instalações e volta a `USER node` no fim.
+
+
+### A validação do lançamento está ativa
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) passa a ter `enforce` como predefinição (6.5: `off`). Cada
+lançamento, a partir do navegador ou de `POST /api/v2/job`, é verificado contra as regras do formulário, e a tarefa executa as extravars e as
+credenciais que o servidor constrói a partir dos valores verificados.
+
+- **Quem chama a API REST tem de enviar `rawFormData`**, os valores brutos dos campos tal como o navegador os envia. Um lançamento só com
+  `extravars` é recusado, porque os seus valores não podem ser verificados.
+- **Para ver primeiro o que seria recusado**, defina `LAUNCH_VALIDATION=log` e leia os avisos no registo. `off` repõe o
+  comportamento da 6.5.
+
+Consulte [Validação do lançamento](launch-validation/) para os detalhes.
+
+
+### Os playbooks já não veem as definições da aplicação
+
+Um playbook já não herda as variáveis de ambiente que o próprio AnsibleForms lê: `ENCRYPTION_SECRET`, as definições `DB_*`,
+`ACCESS_TOKEN_SECRET`, `RTE_TOKEN`, as definições `VAULT_*`, todas as outras variáveis documentadas e todas as variáveis `MYSQL_*`.
+O resto do ambiente do RTE, como `PATH`, proxies, definições `ANSIBLE_*` e credenciais de cloud, é passado como antes.
+
+Um playbook que lia uma destas com `lookup('env', ...)` tem de obter o valor de outra forma: passe-o como extravar ou como
+credencial, ou defina-o no RTE com outro nome.
+
+### Só a função admin gere runners e administradores
+
+Um utilizador com acesso às definições deixa de ter controlo total sobre quem é administrador e para onde vão as credenciais:
+
+- **Runners:** só a função admin adiciona, altera ou elimina um runner, porque um runner recebe as credenciais das tarefas
+  que executa. Os utilizadores com acesso às definições continuam a poder ver e testar runners.
+- **Contas e grupos de administrador:** só a função admin concede admin. Sem ela, um utilizador não pode colocar uma conta num grupo que a
+  função admin indique, nem alterar, repor ou eliminar uma conta de administrador ou um grupo desses.
+- **Funções:** um designer sem a função admin não pode alterar as funções. Uma gravação ou um restauro cujas funções sejam diferentes é recusado.
+
+Dê a função admin a quem gere runners, administradores e funções.
+
+### A palavra-passe predefinida tem de ser alterada
+
+Um utilizador que inicia sessão com a palavra-passe predefinida pública `AnsibleForms!123` tem de a alterar primeiro. Até lá, todas as outras chamadas
+à API respondem `403` com o código `password_change_required`, e o navegador mostra a página de alteração da palavra-passe.
+
+Inicie sessão uma vez e escolha uma nova palavra-passe, ou defina [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD) antes do
+primeiro arranque. Os scripts que iniciam sessão com a palavra-passe predefinida têm de usar outra.
+
+### Os tokens terminam ao terminar sessão e ao alterar a palavra-passe
+
+Terminar sessão passa a terminar os tokens dessa sessão, e alterar a palavra-passe termina todas as sessões desse utilizador, por isso inicie sessão novamente depois de
+alterar uma palavra-passe.
+
+Um token de API pedido com `?expiryDays=` dura no máximo [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) dias
+(90 por predefinição). Os scripts que usam tokens de API de longa duração têm de pedir um novo antes de expirar.
+
+### O Entra ID precisa do seu tenant
+
+O início de sessão com Entra ID (Azure AD) passa a usar OpenID Connect apenas contra o seu próprio tenant, e um utilizador de outro tenant não pode iniciar
+sessão. Um fornecedor sem ID de tenant, ou com `common`, `organizations` ou `consumers`, é recusado.
+
+- **Defina o ID do tenant** no fornecedor de SSO: o ID de diretório (tenant), um GUID, ou o domínio do tenant.
+- **Conceda as permissões do Graph:** o início de sessão pede `openid profile email User.Read GroupMember.Read.All`. Dê ao registo da
+  aplicação as permissões delegadas do Microsoft Graph `User.Read` e `GroupMember.Read.All`, com consentimento de administrador.
+- **Prefira IDs de grupo nas funções:** indique um grupo como `azuread/<object id>` (`entraid/<object id>` a partir da 7.3.0) em vez de pelo seu nome a apresentar.
+
+Consulte [Entra ID](authentication/entra-id.html) para a configuração.
+
+### As palavras-passe têm um comprimento mínimo
+
+Uma palavra-passe local definida através da aplicação precisa de pelo menos
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) caracteres (8 por predefinição), e não pode ser o nome de utilizador nem a
+palavra-passe predefinida. `PASSWORD_MIN_LENGTH=0` desativa a verificação do comprimento. As palavras-passe existentes continuam a funcionar.
+
+### Execute os contentores com uma política de reinício
+
+Uma exceção não tratada passa a terminar o processo, registada com o nível `crit`, em vez de o deixar a correr num estado desconhecido. Execute
+os contentores com uma política de reinício, como `--restart unless-stopped` com Docker (o projeto docker-compose define-a).
+O Kubernetes reinicia os pods sozinho.
+
+### Ligações AWX e a ligação de início
+
+Mais duas coisas desaparecem na 7, sem nada a fazer na 6.5:
+
+- **Ligações AWX e AAP:** a tabela `awx`, `/api/v2/awx` e a página A.A.P. desapareceram. A atualização move cada ligação AWX ou
+  AAP para **Ligações → Runners**, como um runner do tipo `awx`, e os formulários com `awx:` continuam a funcionar.
+- **`NAV_HOME_LABEL` e `NAV_HOME_ICON`:** deixam de ser lidas. A primeira ligação do cabeçalho é sempre Formulários.
+
+### Descontinuado na 7, removido na 8
+
+Estes ainda funcionam na 7, mas cada um regista um aviso quando é usado. Passe para a substituição antes da versão 8:
+
+| Descontinuado | Use em vez disso |
+|---|---|
+| Variáveis de ambiente `VAULT_*` | Um cofre de segredos chamado `vault` (**Ligações → Cofres de segredos**). O primeiro arranque da 7 importa as variáveis uma vez como esse cofre e depois ignora-as. |
+| Variáveis de ambiente `LOG_SYSLOG_*` | Um servidor syslog (**Ligações → Syslog**). Quando `LOG_SYSLOG_HOST` está definida, o primeiro arranque da 7 importa-as uma vez como o servidor `syslog`, que recebe o registo do servidor como antes, e depois ignora-as. Para enviar também as entradas de auditoria, configure-o para receber ambos. |
+| `vault_path` numa credencial (API, config seed) | `secret_store` e `secret_ref`. Consulte [Cofres de segredos](secret-stores/). |
+| A função `public` em `config.yaml` | A função `default`. O ficheiro é alterado quando a configuração é carregada; altere à mão um template ytt. `public` no `roles:` de um formulário continua a corresponder. |
+| `POST /api/v2/config/vault/check`, `GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`, `GET /api/v2/secretstore/{id}/mounts` |
+| `hasApproval` num formulário ou num passo | `approval`. `hasApproval` não tem efeito. |
+| `awx: <name>` num formulário | `runner: <name>`. Uma ligação AWX é um runner do tipo `awx`. |
+| `type: multistep` num formulário, com os seus `steps` | `type: workflow`, com nós que indicam um `runner`. Consulte [Formulários de workflow](forms/workflow.html). |
+| A secção `awx:` do config seed | Itens `runners:` com `type: awx` |
+| `LOCK_PATH` | Nada: deixa de ser lida, o bloqueio do designer é guardado na base de dados. |
+| Um RTE em modo base de dados, desde a 7.3.0: `RTE_MODE=database` ou sem `RTE_MODE`, com os `DB_*` da base de dados e o `ENCRYPTION_SECRET` no RTE | `RTE_MODE=outbound` ou `RTE_MODE=inbound`, sem `DB_*`. O RTE adere uma vez com um token de adesão (`RTE_JOIN_TOKEN`), ou o seu runner é definido com esse modo em **Ligações → Runners** ou no config seed (`rte_mode`). Consulte [Modos](rte/modes.html). |
+| `RTE_REGISTER`, desde a 7.3.0 (apenas modo base de dados) | Um token de adesão (`RTE_JOIN_TOKEN`): o RTE adiciona-se a si próprio como um runner que inicia sessão com uma credencial de RTE. |
+| Uma credencial `api` ou `userpass` num runner do config seed, desde a 7.3.0 | Uma credencial do tipo do runner (`credential_type: rte`, `awx`, `aap`, `ascender`, `semaphore`, `rundeck` ou `jenkins`), com o seu servidor em `url`. |
+| Um runner do config seed com o seu próprio `token`, ou `username` e `password`, desde a 7.3.0 | Uma credencial do tipo do runner na secção `credentials`, com o seu servidor em `url`, que o runner indica com `credential:`. Entretanto, o seed cria uma com o nome do runner. |
+
+`ENABLE_SSO` e `SSO_AUTO_LOGIN` deixaram de ser lidas desde a 7.3.0. O primeiro arranque da 7.3 transporta-as uma vez: `ENABLE_SSO=0` desativa
+todos os fornecedores de SSO, e `SSO_AUTO_LOGIN=1` marca **Saltar a página de início de sessão** no único fornecedor ativado. Depois são ignoradas: cada arranque
+regista um aviso enquanto estiverem definidas, e cada fornecedor tem **Ativado** e **Saltar a página de início de sessão** em **Acesso → SSO**.
+
+---
+
+## Tags da imagem
+
+`latest` passa para a 7 com a 7.0.0. Para ficar na 6, use a tag `6` (ou `6.5`) em vez de `latest`.
+Todas as tags estão listadas em [Tags da imagem](installation/#image-tags).
+
+---
+
+## Reverter
+
+Faça uma cópia de segurança antes de atualizar (**Definições → Cópias de segurança**). A 6.5 corre numa base de dados atualizada para a 7, mas só
+a cópia de segurança restaura as definições de datasources eliminadas.
diff --git a/i18n/pt/_get_started/upgrading/docker-compose.md b/i18n/pt/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..99444c7
--- /dev/null
+++ b/i18n/pt/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: Atualizar
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+Atualize uma instalação feita com o projeto docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+O projeto docker-compose executa três contentores: MySQL (`mysqldb`), AnsibleForms (`app`) e o RTE que executa os
+playbooks (`rte`). O AnsibleForms e o RTE usam a tag de imagem `7`, que aponta sempre para a versão 7.x mais recente. Uma
+atualização volta a obter as imagens e recria os contentores cuja imagem mudou. Tudo o que tem de persistir é guardado
+na pasta `data` e é preservado.
+
+---
+
+## Antes de atualizar
+
+Prepare a atualização para poder voltar atrás se algo correr mal:
+
+* **Faça uma cópia de segurança** em **Definições → Cópias de segurança**. A nova versão atualiza o esquema da base de dados no primeiro arranque.
+* **Leia o [registo de alterações](../changelog)** das versões entre a sua e a nova.
+* **Vai passar para uma nova versão principal?** Siga primeiro [Atualizar para a v7](../upgrade-7.html).
+* **Vem da 6.5?** O projeto 6.x, no seu ramo `v6`, não tem contentor `rte`. Atualize a sua cópia do projeto para
+  o ramo `main`, mantendo as suas definições do `.env` e a sua pasta `data`, para que o `docker-compose.yml` tenha o serviço `rte`.
+  Esse ficheiro de compose define `CONFIG_SEED_PATH`, e uma pasta `data` da 6.x não tem `seed.yaml`: copie `data/seed.yaml` do
+  repositório e adicione `RTE_TOKEN` (com pelo menos 16 caracteres) ao seu `.env`, como o `.env` do repositório o tem. Sem eles a
+  aplicação recusa-se a arrancar. As imagens da 7 correm com o uid 1000 em vez de root: dê a esse utilizador a pasta `data` uma vez, deixando os ficheiros
+  do MySQL ao MySQL, com `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`.
+  A pasta `data/ssh` passa a ser montada em `/home/node/.ssh` em vez de `/root/.ssh`.
+* **Vem da 7.2?** Atualize `docker-compose.yml` e `data/seed.yaml` em conjunto: consulte primeiro [Da 7.2 para a 7.3](#from-72-to-73).
+
+---
+
+## Da 7.2 para a 7.3
+
+Até à 7.2.0 o serviço `rte` recebia as definições da base de dados e o seu runner, declarado em `data/seed.yaml`, corria em modo base de dados,
+descontinuado na 7.3.0 e removido na 8.0.0. Desde a 7.3.0 a aplicação liga-se ao RTE em `http://rte:8000` e mantém um WebSocket aberto
+(`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)), e o RTE não guarda definições da base de dados. Obtenha os dois ficheiros do ramo
+`main` do repositório, mantendo o seu `.env`:
+
+| Ficheiro | O que muda |
+|---|---|
+| `docker-compose.yml` | O serviço `rte` deixa de ler o `.env`: recebe `RTE_MODE=inbound`, `RTE_TOKEN` e `RTE_FILES=local`, e nenhum `DB_*` |
+| `data/seed.yaml` | Uma credencial de RTE `rte`, com `url: http://rte:8000` e `password: ${RTE_TOKEN}`, e o runner `rte` com `rte_mode: inbound` e `credential: rte` |
+
+Altere os dois. Só com o novo ficheiro de compose, o seed mantém o runner `rte` em modo base de dados: a aplicação chama o RTE como se fosse um da 7.2,
+ao que o novo RTE não responde, e nenhum playbook é executado. Um seed que alterou por si precisa da mesma credencial e do mesmo `rte_mode`.
+
+Um runner que o seed criou continua gerido, só de leitura em **Ligações → Runners**, mesmo depois de remover `CONFIG_SEED_PATH`: só um
+seed aplicado liberta um runner que já não declara. Por isso mantenha o seed e defina aí o `rte_mode`, em vez de remover
+`CONFIG_SEED_PATH` para alterar o runner à mão.
+
+O [instalador](../installation/installer.html#upgrade) faz isto sozinho: a sua atualização substitui `docker-compose.yml`, e `data/seed.yaml`
+quando é um fornecido pelo repositório, sem alterações. Um alterado à mão é mantido, e o novo é guardado ao lado.
+
+---
+
+## 1. Obtenha as novas imagens
+
+Descarregue as imagens mais recentes das tags em `docker-compose.yml`:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. Recrie os contentores
+
+Inicie novamente o projeto; os contentores cuja imagem mudou são recriados:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. Verifique a atualização
+
+Acompanhe o registo do AnsibleForms enquanto arranca. O primeiro arranque de uma nova versão atualiza o esquema da base de dados, e o RTE
+arranca assim que o AnsibleForms estiver saudável:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+No AnsibleForms, **Ajuda → Acerca de** mostra a versão em execução, e **Definições → Estado** mostra a saúde da
+base de dados, do esquema e dos outros sistemas de que o AnsibleForms depende.
+
+---
+
+## Reverter
+
+Para voltar à versão que executava antes, a que **Ajuda → Acerca de** mostrava antes da atualização, fixe a sua tag exata em
+`docker-compose.yml` na imagem do AnsibleForms e na do RTE, em vez de `7`, e execute novamente o passo 2. Se essa versão
+não arrancar na base de dados atualizada, restaure a cópia de segurança que fez em **Definições → Cópias de segurança**. Volte a colocar as tags em
+`7` para voltar a receber atualizações.
+
+**VÍDEO**: [Como atualizar o AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/pt/_get_started/upgrading/docker.md b/i18n/pt/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..0a06ce1
--- /dev/null
+++ b/i18n/pt/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: Atualizar
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+Atualize um contentor autónomo, sem docker-compose
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Uma instalação autónoma é atualizada substituindo os seus contentores: obtenha as novas imagens, remova os contentores antigos e
+inicie novos com os mesmos comandos `run`. Desde a versão 7 existem dois: o AnsibleForms e o RTE que executa os
+playbooks, sempre na mesma versão. Os seus ficheiros ficam guardados na pasta montada `/app/dist/persistent` e os seus dados no
+MySQL, por isso ambos são preservados.
+
+---
+
+## Antes de atualizar
+
+Prepare a atualização para poder voltar atrás se algo correr mal:
+
+* **Faça uma cópia de segurança** em **Definições → Cópias de segurança**. A nova versão atualiza o esquema da base de dados no primeiro arranque.
+* **Leia o [registo de alterações](../changelog)** das versões entre a sua e a nova.
+* **Vai passar para uma nova versão principal?** Siga primeiro [Atualizar para a v7](../upgrade-7.html).
+* **Vem da 6.5?** As imagens da 7 correm com o uid 1000 em vez de root: dê a esse utilizador as pastas que monta, uma vez, por
+  exemplo `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`.
+* **Vem da 7.2?** O RTE recebe um ficheiro próprio e a aplicação liga-se a ele: consulte primeiro [Da 7.2 para a 7.3](#from-72-to-73).
+
+---
+
+## Da 7.2 para a 7.3
+
+Até à 7.2.0 o RTE lia o ficheiro de ambiente da aplicação, com as definições da base de dados, e adicionava-se a si próprio como runner a partir de `RTE_URL`. Isso
+é o modo base de dados, descontinuado na 7.3.0 e removido na 8.0.0. Desde a 7.3.0 a aplicação liga-se ao RTE e mantém um WebSocket aberto
+(`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)), e o RTE não guarda definições da base de dados. Uma vez, antes do passo 2:
+
+1. Crie `/srv/apps/ansibleforms/rte.env` como faz a [instalação](../installation/docker.html#prepare-the-folders), com
+   `RTE_MODE=inbound`, o mesmo `RTE_TOKEN`, `RTE_FILES=local`, `PORT=8000` e `HTTPS=0`. Sem `DB_*`, sem `ENCRYPTION_SECRET`, sem `RTE_URL`
+2. Declare o runner nesse modo. Ou adicione o [config seed](../seed/) da instalação, `persistent/seed.yaml` com a credencial de RTE
+   (`url: http://rte:8000`, `password: ${RTE_TOKEN}`) e o runner `rte` (`rte_mode: inbound`), e adicione
+   `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml` ao ficheiro de ambiente da aplicação. Ou, sem seed, abra o runner em
+   **Ligações → Runners**, defina o seu **Modo** como **Entrada** e escolha uma credencial de RTE que contenha `http://rte:8000` e o token
+
+Com o seed, o ficheiro de ambiente da aplicação também contém `RTE_TOKEN`, o mesmo token, já que o seed o lê daí.
+
+---
+
+## 1. Obtenha as novas imagens
+
+Descarregue as imagens mais recentes do AnsibleForms e do RTE da tag que executa:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. Substitua os contentores
+
+Remova os contentores antigos e inicie novos com os comandos `run` da [instalação](../installation/docker.html). A aplicação
+lê a ligação à base de dados do seu ficheiro de ambiente, com o utilizador de base de dados do AnsibleForms (não o root). O RTE lê o seu próprio
+`rte.env`, sem as definições da base de dados, e a aplicação liga-se a ele através de uma rede que os dois contentores partilham:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+Se vem da 6.5, ainda não existe contentor RTE: os comandos `stop` e `rm` só encontram a aplicação. Crie a rede partilhada
+uma vez com `docker network create ansibleforms` (ou `podman network create ansibleforms`). Tal como faz a
+[instalação](../installation/docker.html#prepare-the-folders), coloque a ligação à base de dados, o `ENCRYPTION_SECRET`, um `RTE_TOKEN`
+com pelo menos 16 caracteres e `CONFIG_SEED_PATH` no ficheiro de ambiente da aplicação, e crie o `rte.env` e o config seed. Use as suas próprias
+pastas onde a sua instalação 6.5 montava outras. O seed adiciona o RTE em **Ligações → Runners** como o runner predefinido `rte`;
+consulte [Atualizar para a v7](../upgrade-7.html#playbooks-run-on-an-rte).
+
+---
+
+## 3. Verifique a atualização
+
+Acompanhe o registo do AnsibleForms enquanto arranca. O primeiro arranque de uma nova versão atualiza o esquema da base de dados:
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+O RTE escreve o seu próprio registo, que `docker logs rte` mostra. No AnsibleForms, **Ajuda → Acerca de** mostra a versão em execução, e **Definições → Estado** mostra a saúde da
+base de dados, do esquema e dos outros sistemas de que o AnsibleForms depende.
+
+---
+
+## Reverter
+
+Para voltar à versão que executava antes, a que **Ajuda → Acerca de** mostrava antes da atualização, execute novamente o passo 2 com
+a sua tag exata em vez de `7`, na imagem do AnsibleForms e na do RTE. Se essa versão não arrancar na base de dados
+atualizada, restaure a cópia de segurança que fez em **Definições → Cópias de segurança**.
diff --git a/i18n/pt/_get_started/upgrading/from-source.md b/i18n/pt/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..2272c38
--- /dev/null
+++ b/i18n/pt/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: A partir do código-fonte
+parent: Atualizar
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# A partir do código-fonte
+{: .no_toc }
+
+Atualize uma instalação compilada a partir do código-fonte
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Uma instalação compilada a partir do código-fonte é atualizada fazendo checkout da nova versão, compilando-a novamente e reiniciando a
+aplicação. As suas definições, formulários, playbooks, certificados e registos ficam guardados em `server/persistent`, que o Git e a
+compilação não alteram.
+
+---
+
+## Antes de atualizar
+
+Prepare a atualização para poder voltar atrás se algo correr mal:
+
+* **Faça uma cópia de segurança** em **Definições → Cópias de segurança**. A nova versão atualiza o esquema da base de dados no primeiro arranque.
+* **Leia o [registo de alterações](../changelog)** das versões entre a sua e a nova.
+* **Vai passar para uma nova versão principal?** Siga primeiro [Atualizar para a v7](../upgrade-7.html).
+* **Verifique a versão do Node.js** que a nova versão exige, no registo de alterações.
+
+---
+
+## 1. Obtenha a nova versão
+
+Obtenha as tags das versões e faça checkout da versão que pretende. As tags das versões têm o número da versão, e `git tag` lista-as;
+o ramo `main` pode conter alterações ainda não lançadas:
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. Compile novamente
+
+Compile novamente nos mesmos três passos que na instalação. Primeiro compile o client:
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+Depois atualize as dependências do servidor:
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+Por fim copie novamente o client compilado para a pasta `views` do servidor:
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+Compare o `.env.example`, na raiz do repositório, com o seu `persistent/.env` para incluir as definições que a versão acrescente.
+
+---
+
+## 3. Reinicie
+
+Reinicie a aplicação e o seu RTE para carregar o novo código. O esquema da base de dados é atualizado no primeiro arranque:
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+Se vem da 7.2, o RTE corria em modo base de dados, com as definições da base de dados e `RTE_URL`, descontinuado na 7.3.0 e removido na 8.0.0.
+Inicie-o novamente em modo inbound e declare o seu runner com uma credencial de RTE no seed ou em **Ligações → Runners**, como mostra a
+[instalação](../installation/from-source.html#run): `pm2 delete ansibleforms-rte`, e depois o seu comando `pm2 start`.
+
+Se executa a aplicação sem PM2, pare o `npm run start` e volte a iniciá-lo.
+
+---
+
+## 4. Verifique a atualização
+
+Acompanhe o registo da aplicação enquanto arranca:
+
+```bash
+pm2 logs ansibleforms
+```
+
+No AnsibleForms, **Ajuda → Acerca de** mostra a versão em execução, e **Definições → Estado** mostra a saúde da
+base de dados, do esquema e dos outros sistemas de que o AnsibleForms depende.
+
+---
+
+## Reverter
+
+Para voltar à versão que executava antes, a que **Ajuda → Acerca de** mostrava antes da atualização, faça checkout da sua tag com
+`git checkout <version>`, e depois compile e reinicie como nos passos 2 e 3. Se essa versão não arrancar na base de dados atualizada, restaure a cópia de segurança que fez em
+**Definições → Cópias de segurança**.
diff --git a/i18n/pt/_get_started/upgrading/index.md b/i18n/pt/_get_started/upgrading/index.md
new file mode 100644
index 0000000..3e121c4
--- /dev/null
+++ b/i18n/pt/_get_started/upgrading/index.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: Atualizar
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# Atualizar
+{: .no_toc }
+
+Passe o AnsibleForms para uma versão mais recente
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores de uma instância em execução: passe para uma versão mais recente, com o método com que a instalou.
+
+---
+
+## Nesta secção
+
+O procedimento de atualização depende da forma como instalou o AnsibleForms. Cada método é descrito na sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Atualizar para a v7](../upgrade-7.html) | O que alterar enquanto ainda está na 6.5, antes de passar para a 7 |
+| [Com o instalador](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`, para uma instalação feita pelo instalador: cópia de segurança, notas de versão e reversão |
+| [Docker](docker.html) | Obtenha a nova imagem e recrie o contentor com as mesmas definições |
+| [Docker Compose](docker-compose.html) | Obtenha a nova imagem e reinicie o projeto docker-compose |
+| [A partir do código-fonte](from-source.html) | Obtenha o novo código, compile-o novamente e reinicie a aplicação |
+| [Kubernetes](kubernetes.html) | Atualize o repositório de charts e execute `helm upgrade` com os seus valores |
+
+{: .note }
+> **Primeiro a cópia de segurança** Faça uma cópia de segurança antes de atualizar (**Definições → Cópias de segurança**). O esquema da base de dados é atualizado no primeiro
+> arranque da nova versão, por isso a cópia de segurança é o seu ponto de reversão se algo correr mal. A partir da 7.3.0 o worker também faz
+> uma sozinho antes de atualizar a partir de uma versão mais antiga, com o nome da versão, a menos que
+> [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) seja `0`.
+
+A versão que recebe depende da tag de imagem que executa: `latest` segue a versão principal mais recente, enquanto uma tag como `7`
+se mantém nessa versão principal. Todas as tags estão listadas em [Tags da imagem](../installation/#image-tags).
diff --git a/i18n/pt/_get_started/upgrading/kubernetes.md b/i18n/pt/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..7e31e6f
--- /dev/null
+++ b/i18n/pt/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: Atualizar
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+Atualize uma instalação feita com o chart de Helm
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Cada versão do chart implementa uma versão do AnsibleForms. Uma atualização instala uma versão mais recente do chart com os seus valores existentes;
+os dados nos volumes persistentes são preservados. Uma atualização que não altera nada deixa os pods intactos.
+
+---
+
+## Antes de atualizar
+
+Prepare a atualização para poder voltar atrás se algo correr mal:
+
+* **Faça uma cópia de segurança** em **Definições → Cópias de segurança**. A nova versão atualiza o esquema da base de dados no primeiro arranque.
+* **Leia o [registo de alterações](../changelog)** das versões entre a sua e a nova.
+* **Vai passar para uma nova versão principal?** Siga primeiro [Atualizar para a v7](../upgrade-7.html).
+* **Leia o [registo de alterações](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md) do chart** para ver as alterações aos valores.
+* **Com credenciais geradas** (`secrets.generate`), faça uma cópia de segurança do Secret `<release>-secrets`: o `ENCRYPTION_SECRET` não pode ser recuperado.
+* **Vem da 7.2?** O RTE no pod do servidor muda de modo: consulte [Da 7.2 para a 7.3](#from-72-to-73).
+
+---
+
+## Da 7.2 para a 7.3
+
+O chart 7.3.0 tira o RTE ao lado da aplicação do modo base de dados, descontinuado na 7.3.0 e removido na 8.0.0. A aplicação liga-se a ele em
+`127.0.0.1` e mantém um WebSocket aberto (`RTE_MODE=inbound`, consulte [Modos](../rte/modes.html)):
+
+* O contentor do RTE deixa de receber `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `ENCRYPTION_SECRET` ou `RTE_URL`, e obtém os ficheiros da tarefa a partir
+  do volume partilhado (`RTE_FILES=local`)
+* O config seed do chart declara uma credencial de RTE com o token e o endereço, e o runner, `rte_mode: inbound`, que inicia
+  sessão com ela. Com o seed do chart, não há nada a fazer
+* Com `containers.rte.seedRunner: false`, ou um config seed seu (`CONFIG_SEED_PATH`), o RTE deixa de se adicionar a si próprio como runner.
+  Declare-o por si, no seu seed ou em **Ligações → Runners**: uma credencial de RTE com `http://127.0.0.1:<port>` e o token,
+  e um runner do tipo RTE com `rte_mode: inbound` que a indique. As notas que o Helm imprime depois da atualização mostram como
+
+Desde a 7.3.0 o chart também instala um Runner sozinho, com `runner.enabled` (consulte
+[Um Runner em Kubernetes](../installation/kubernetes.html#a-runner-on-kubernetes)).
+
+---
+
+## 1. Encontre a nova versão do chart
+
+Atualize o repositório de charts e liste as versões do chart disponíveis:
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. Atualize a release
+
+Execute o mesmo comando `helm upgrade` que na instalação, com o seu ficheiro de valores e a nova versão do chart:
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+Com o registo OCI, use `oci://ghcr.io/ansibleforms/charts/ansibleforms` como chart.
+
+---
+
+## 3. Verifique a atualização
+
+Espere pelos novos pods e depois execute o teste do chart, que verifica tanto o servidor web como a ligação à base de dados:
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+No AnsibleForms, **Ajuda → Acerca de** mostra a versão em execução, e **Definições → Estado** mostra a saúde da
+base de dados, do esquema e dos outros sistemas de que o AnsibleForms depende.
+
+---
+
+## Reverter
+
+O Helm guarda o histórico da release. Para voltar à revisão anterior:
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+Se não arrancar na base de dados atualizada, restaure a sua cópia de segurança (consulte o [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) do chart).
diff --git a/i18n/pt/_integrate/api/authentication.md b/i18n/pt/_integrate/api/authentication.md
new file mode 100644
index 0000000..dd3ccee
--- /dev/null
+++ b/i18n/pt/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: Autenticação
+parent: API REST
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# Autenticação
+{: .no_toc }
+
+Inicie sessão, renove o token ou use um token de longa duração
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Todas as chamadas precisam de um token de acesso no cabeçalho `Authorization`. Um token obtém-se iniciando sessão, e mantém-se válido com
+o refresh token.
+
+---
+
+## Inicie sessão
+
+Inicie sessão com autenticação básica, com o nome e a palavra-passe do utilizador:
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+A resposta contém dois tokens, o token de acesso e o refresh token:
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Chame a API
+
+Envie o token de acesso como bearer token em todas as chamadas:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## Renove o token
+
+O token de acesso expira (`ACCESS_TOKEN_EXPIRATION`, 30 minutos por predefinição). Obtenha um novo com o refresh token,
+sem a palavra-passe:
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+A resposta contém um novo par, com o mesmo formato que o do início de sessão. Um refresh token funciona uma vez: guarde o novo para a renovação seguinte.
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## Tokens de longa duração
+
+Um script que corre sem intervenção pode usar um token que dura mais tempo. A partir da 7.3.0 precisa da opção de função `allowApiTokens`:
+
+* Crie um em [Perfil > Tokens de API](../profile/api-token.html).
+* Ou inicie sessão com o parâmetro de consulta `expiryDays`, para um token válido durante esse número de dias:
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` só é lido do URL, nunca do corpo. Para um utilizador cujas funções não tenham `allowApiTokens`, é ignorado,
+e o início de sessão devolve um token com a duração habitual. `expiryDays=never` também precisa de `extendedTokenExpiration`. Adicione o parâmetro de consulta `name`
+(`?expiryDays=90&name=nightly-backup`) para dar nome ao token na lista de tokens do utilizador.
+
+Um token de longa duração dura no máximo [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) dias, 90 por
+predefinição: um `expiryDays` maior é reduzido a esse valor, a menos que seja `never`. Renová-lo devolve um token normal, por isso inicie sessão novamente quando expirar.
+
+### Tokens do utilizador com sessão iniciada
+
+A vista **Tokens de API** do perfil usa estes endpoints, que funcionam para qualquer conta, SSO incluído, pois não precisam de palavra-passe:
+
+| Chamada | O que faz |
+|---|---|
+| `GET /api/v2/profile/tokens` | Lista os seus tokens de API, com o seu `sid`, `name`, criação, expiração e última utilização |
+| `POST /api/v2/profile/tokens` | Cria um token a partir da sua sessão; o corpo contém `expiryDays` (um número, ou `never`) e um `name` opcional |
+| `DELETE /api/v2/profile/tokens/{sid}` | Revoga um dos seus tokens |
+
+`POST` responde `403` quando é chamado com um token de API (um token não pode criar outro), sem `allowApiTokens`, ou quando a
+sessão foi iniciada há mais de 10 minutos (código `sign_in_again`): inicie sessão novamente primeiro. Uma duração acima do máximo responde `400`.
+
+---
+
+## Quando um token termina antes do tempo
+
+Um token, de longa duração ou não, deixa de funcionar antes de expirar quando acontece uma destas situações:
+
+* **Um fim de sessão da sua sessão**: `POST /api/v2/auth/logout` com o token termina os tokens desse início de sessão, e apenas esses. Um
+  fim de sessão no navegador não termina o token de um script.
+* **Uma alteração da palavra-passe**: o utilizador altera a sua palavra-passe, ou um administrador define-a. Todos os tokens emitidos antes são recusados.
+* **O utilizador é removido ou bloqueado**: eliminar um utilizador local, ou bloquear um utilizador, termina todos os seus tokens. Um administrador também pode
+  terminar as sessões de um utilizador LDAP ou SSO.
+
+Um token recusado responde `401`. Inicie sessão novamente, com a nova palavra-passe se tiver mudado.
+
+---
+
+## Scripts que iniciam sessão em cada execução
+
+Os endpoints de início de sessão e de token estão protegidos contra inundações de pedidos e adivinhação de palavras-passe, por isso um script que inicia sessão sempre que corre
+deve conhecer estes limites:
+
+| Limite | Predefinição | O que acontece |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 120 pedidos por minuto a partir de um endereço | O início de sessão, o fim de sessão, a renovação, os endpoints de SSO, `PUT /api/v2/profile` (alteração da palavra-passe) e `POST` ou `DELETE /api/v2/profile/tokens` respondem `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 5 inícios de sessão falhados seguidos | A conta fica bloqueada durante [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) (15), e todos os inícios de sessão respondem `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 30 inícios de sessão falhados a partir de um endereço | Todos os inícios de sessão a partir desse endereço respondem `429` até a janela terminar |
+
+Um `429` traz um cabeçalho `Retry-After` com os segundos a aguardar: pare e espere, não volte a tentar de imediato. Uma conta bloqueada
+recusa até a palavra-passe correta até o bloqueio terminar, por isso um script com uma palavra-passe errada bloqueia o seu utilizador para toda a gente.
+Uma palavra-passe atual errada numa alteração de palavra-passe (`PUT /api/v2/profile`) também conta como início de sessão falhado, e uma conta bloqueada
+não pode alterar a sua palavra-passe. Um início de sessão bem-sucedido limpa a contagem da conta, e o mesmo acontece quando um administrador define a palavra-passe.
+
+Para se manter longe destes limites, inicie sessão uma vez e reutilize o token, ou use um token de longa duração, em vez de iniciar sessão em
+cada chamada. Por trás de um reverse proxy, defina [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) para que o servidor veja
+o endereço do cliente, caso contrário todos os clientes contam como um só.
diff --git a/i18n/pt/_integrate/api/events.md b/i18n/pt/_integrate/api/events.md
new file mode 100644
index 0000000..bc6461c
--- /dev/null
+++ b/i18n/pt/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: Eventos em direto
+parent: API REST
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# Eventos em direto
+{: .no_toc }
+
+Saiba quando as tarefas e as definições mudam, em vez de fazer polling
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+O servidor informa os seus clientes do que muda, à medida que muda. Um script também pode ficar à escuta, em vez de ler uma tarefa a cada poucos segundos.
+
+---
+
+## O stream
+
+`GET /api/v2/events` é um stream de [server-sent events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+que se mantém aberto. Qualquer utilizador com sessão iniciada o pode abrir, com o bearer token habitual:
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+Quando algo muda, envia um evento `changed` com o nome do que mudou:
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## Nomes dos eventos
+
+Um evento transporta apenas um nome, nunca dados, por isso não revela nada que o utilizador não possa ver. São enviados estes nomes:
+
+| Nome | O que mudou |
+|---|---|
+| `jobs` | Uma tarefa: lançada, o seu estado ou saída, eliminada |
+| `appearance` | As definições que o cabeçalho mostra: o tema, o nome, um anúncio, uma variável de ambiente |
+| `designer` | Um bloqueio do designer, obtido ou libertado |
+| `runners` | Um runner (a partir da 7.3.0): um RTE ligou-se ou desligou-se, pediu para aderir, foi aprovado ou rejeitado, ou alterou o seu modo ou as suas definições |
+
+Ao receber um nome, volte a ler o que mostra através da API normal (por exemplo `GET /api/v2/job/42`), com as suas próprias
+permissões. Um nome muito ativo é enviado no máximo uma vez por segundo.
+
+---
+
+## Mantê-lo aberto
+
+O stream foi feito para sobreviver a proxies e balanceadores de carga, e um cliente volta a ligar-se sozinho:
+
+* Ao ligar-se, o servidor envia um evento `hello`, e pede ao cliente que aguarde 3 segundos antes de voltar a ligar-se.
+* A cada 15 segundos envia uma linha de comentário (`: ping`), para que uma ligação inativa não seja fechada. Ignore as linhas que começam por `:`.
+* Os eventos de todos os nós da aplicação chegam a todos os streams, seja qual for o nó a que o cliente está ligado.
+* Depois de voltar a ligar-se, volte a ler o que mostra: um evento enviado enquanto o stream estava em baixo não é enviado novamente.
+
+---
+
+## Saúde e métricas
+
+As sondas de liveness e readiness (`/api/v2/live`, `/api/v2/ready`) e as métricas Prometheus (`/api/v2/metrics`) destinam-se
+a ferramentas de monitorização e não a scripts que atuam como um utilizador. Consulte [Monitorização](../production/monitoring.html).
diff --git a/i18n/pt/_integrate/api/index.md b/i18n/pt/_integrate/api/index.md
new file mode 100644
index 0000000..08d8a83
--- /dev/null
+++ b/i18n/pt/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: API REST
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# API REST
+{: .no_toc }
+
+Lance formulários e faça a gestão do AnsibleForms a partir de scripts
+{: .fs-6 .fw-300 }
+
+---
+
+Para programadores e engenheiros de automação: lance formulários e faça a gestão do AnsibleForms a partir de scripts.
+
+Tudo o que a interface web faz passa pela API REST, por isso os scripts e outras ferramentas podem fazer o mesmo.
+
+---
+
+## Visão geral
+
+A API é servida em `/api/v2` no servidor do AnsibleForms:
+
+* **Referência completa** : estas páginas tratam do que os scripts mais usam. Todos os endpoints estão descritos, e podem ser experimentados, na
+  página Swagger incorporada no servidor, `https://<your server>/api/v2/docs`.
+* **Permissões** : uma chamada é executada como o utilizador cujo token transporta, com as funções desse utilizador, tal como no navegador.
+* **Validação do lançamento** : as tarefas lançadas através da API podem ser verificadas tal como os lançamentos no navegador
+  (consulte [Validação do lançamento](../launch-validation/)).
+* **Limites de pedidos** : só os endpoints de início de sessão, de fim de sessão, de renovação do token e de início de sessão único, a alteração da palavra-passe
+  (`PUT /api/v2/profile`) e os endpoints de tokens de API (`POST` e `DELETE /api/v2/profile/tokens`) estão limitados (consulte
+  [Autenticação](authentication.html)). As outras chamadas não têm limite de pedidos (o [assistente de chat](../chat/) tem limites
+  próprios), por isso um script deve controlar o seu próprio ritmo, por exemplo quando acompanha uma tarefa.
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Autenticação](authentication.html) | Iniciar sessão, renovar o token ou usar um token de longa duração |
+| [Tarefas](jobs.html) | Lançar um formulário, acompanhar a tarefa, abortá-la, relançá-la ou aprová-la |
+| [Respostas e erros](responses.html) | O formato de uma resposta e os códigos de estado |
+| [Eventos em direto](events.html) | Saber quando as tarefas e as definições mudam, em vez de fazer polling |
diff --git a/i18n/pt/_integrate/api/jobs.md b/i18n/pt/_integrate/api/jobs.md
new file mode 100644
index 0000000..84429be
--- /dev/null
+++ b/i18n/pt/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: Tarefas
+parent: API REST
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# Tarefas
+{: .no_toc }
+
+Lance um formulário, acompanhe a tarefa, aborte-a, relance-a ou aprove-a
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Uma tarefa é uma execução de um formulário. Lance-a com o nome e os valores do formulário, e depois acompanhe-a pelo seu ID.
+
+---
+
+## Lance um formulário
+
+Envie o nome do formulário e os seus valores para `POST /api/v2/job`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+O pedido aceita estas propriedades:
+
+| Propriedade | Significado |
+|---|---|
+| `formName` | O nome do formulário a lançar. Obrigatório. |
+| `extravars` | As variáveis extra da tarefa. `payload` é aceite como outro nome para ela. |
+| `rawFormData` | Os valores dos campos do formulário, tal como o navegador os guarda. A [validação do lançamento](../launch-validation/) verifica-os e constrói as extravars a partir deles. |
+| `credentials` | Credenciais a passar à tarefa, pelo nome. |
+| `files` | Os carregamentos dos campos de ficheiro do formulário (consulte [Carregamento de ficheiros](../launch-validation/file-uploads.html)). |
+
+A resposta contém o ID da nova tarefa:
+
+```json
+{ "id": 42 }
+```
+
+Para executar a tarefa em modo detalhado, adicione `"__verbose__": true` às extravars. Precisa da opção de função `allowVerboseMode`,
+caso contrário o lançamento responde `403`.
+
+---
+
+## Carregue um ficheiro
+
+Um formulário com um campo de ficheiro precisa que o ficheiro seja carregado primeiro. Envie-o como a parte multipart `file` para `POST /api/v2/job/upload`:
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+A resposta descreve o carregamento guardado:
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+Passe-o sem alterações nos `files` do lançamento, com o nome do campo de ficheiro: `"files": { "firmware": { ... } }`. O servidor
+verifica-o contra o seu próprio disco (consulte [Carregamento de ficheiros](../launch-validation/file-uploads.html)).
+
+---
+
+## Acompanhe a tarefa
+
+Leia a tarefa pelo seu ID:
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+A tarefa contém o seu `status`, as suas `extravars` (também como `payload`, o mesmo objeto), os seus `subjobs` e o seu `output`. A
+saída é HTML com as cores da página da tarefa; adicione `?text=true` para texto simples, mais adequado a um script ou a um registo:
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+O seu `status` é `running` enquanto está em execução, e `approve` enquanto aguarda uma aprovação. Uma tarefa termina com um destes:
+
+| Estado | Significado |
+|---|---|
+| `success` | A tarefa terminou sem erros |
+| `failed` | A tarefa falhou |
+| `warning` | Uma tarefa multistep terminou, mas um passo com `continue` definido falhou pelo caminho |
+| `aborted` | A tarefa foi abortada |
+| `rejected` | A aprovação foi recusada, por isso o que estava à espera dela não foi executado |
+| `abandoned` | O processo que acompanhava a tarefa parou (um reinício, um contentor substituído) e a tarefa foi abandonada |
+
+Uma tarefa em execução num runner quando foi abandonada pode ainda terminar com o seu resultado real, se esse runner acabar por a concluir.
+
+---
+
+## Encontre tarefas
+
+`GET /api/v2/job` lista primeiro as tarefas mais recentes, como `{ "count": ..., "records": [ ... ] }`. Estes parâmetros de consulta restringem a lista:
+
+| Parâmetro | Significado |
+|---|---|
+| `records` | Quantas tarefas, no máximo. A predefinição é [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) (1000), e 5000 no máximo, a menos que `JOBS_LIST_SIZE` seja maior. |
+| `user`, `user_type` | Apenas as tarefas deste utilizador. `user_type` é `local` quando omitido (`ldap`, `azuread`, `oidc` para os outros). |
+| `runner` | Apenas as tarefas executadas neste runner |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+Um utilizador vê as suas próprias tarefas e as tarefas que aguardam uma aprovação que uma das suas funções pode dar. Um administrador, ou uma função com a
+opção `showAllJobLogs` ou `manageAllJobs`, vê todas as tarefas. Um registo contém o resumo da tarefa (`id`, `form`, `status`, `start`, `end`, `user`, `runner`, ...); leia
+a própria tarefa para obter as suas extravars e a sua saída.
+
+`GET /api/v2/job/approvals` responde com um número: quantas tarefas aguardam uma aprovação que o utilizador pode dar.
+
+---
+
+## Mais sobre uma tarefa
+
+Estes endpoints leem mais informação de uma tarefa:
+
+| Chamada | O que devolve |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | Os valores dos campos com que a tarefa foi lançada, tal como o formulário os guardava. Aplicam-se as mesmas permissões que num relançamento: a sua própria tarefa (ou todas as tarefas para um administrador ou uma função com `manageAllJobs`), um formulário que permita o relançamento, e a opção de função `allowJobRelaunch`. |
+| `GET /api/v2/job/{id}/events` | Os eventos estruturados de uma tarefa de playbook (a partir da 7.3.0, para um playbook num RTE da 7.3.0 ou posterior): cada play, tarefa, resultado por host e o recap, com o seu `order`, `type`, `play`, `task`, `host`, `duration` e `time` |
+| `GET /api/v2/job/{id}/events/{order}` | Um desses eventos com o seu `result` completo, tal como a janela **Resultado da tarefa** o mostra; `400` quando `order` não é um número inteiro, `404` quando a tarefa não tem esse evento |
+| `GET /api/v2/job/{id}/node/{nodeId}` | Um nó de uma tarefa de workflow: `{ "node", "job", "extravars", "artifacts" }`, em que `job` é o ID da tarefa própria do nó, ou `null` quando o nó não foi executado. |
+
+---
+
+## Outras ações
+
+Estes endpoints atuam sobre uma tarefa existente:
+
+| Chamada | Ação |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | Abortar uma tarefa em execução |
+| `POST /api/v2/job/{id}/relaunch` | Relançar uma tarefa, tal como foi executada ou com alterações (consulte [Relançar](../launch-validation/relaunching.html)) |
+| `POST /api/v2/job/{id}/approve` | Aprovar uma tarefa que aguarda aprovação; a sua própria tarefa responde `403`, a menos que a sua aprovação defina `allowSelf: true` ou que seja administrador |
+| `POST /api/v2/job/{id}/reject` | Rejeitar uma tarefa que aguarda aprovação |
+| `GET /api/v2/job/{id}/download` | Descarregar a saída da tarefa |
+| `DELETE /api/v2/job/{id}` | Eliminar uma tarefa |
+
+Abortar, aprovar, rejeitar e eliminar respondem com uma mensagem, e um relançamento também com o ID da nova tarefa:
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+Adicione `?verbose=true` a um relançamento para executar a nova tarefa em modo detalhado, com a opção de função `allowVerboseMode`. Uma tarefa que
+esteja no estado errado para a ação, por exemplo abortar uma tarefa que já terminou, responde `409`.
diff --git a/i18n/pt/_integrate/api/responses.md b/i18n/pt/_integrate/api/responses.md
new file mode 100644
index 0000000..1c433bb
--- /dev/null
+++ b/i18n/pt/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Respostas e erros
+parent: API REST
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# Respostas e erros
+{: .no_toc }
+
+O formato de uma resposta e os códigos de estado
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+As respostas são JSON simples, e o código de estado HTTP indica se uma chamada teve sucesso.
+
+---
+
+## Respostas
+
+Uma chamada bem-sucedida devolve o próprio objeto, ou uma lista com o seu tamanho:
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+Um erro devolve uma mensagem, e detalhes quando existem:
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## Códigos de estado
+
+O código de estado indica o que correu mal:
+
+| Código | Significado |
+|---|---|
+| `200` | A chamada teve sucesso |
+| `400` | O pedido está mal formado, por exemplo uma renovação de token sem refresh token, ou um carregamento sem ficheiro |
+| `401` | O token falta, está errado ou expirou: inicie sessão ou renove-o |
+| `403` | As funções do utilizador não permitem a chamada (incluindo aprovar a sua própria tarefa, a menos que a sua aprovação defina `allowSelf: true` ou que seja administrador), ou a conta tem primeiro de fazer algo (ver abaixo) |
+| `404` | O objeto não existe |
+| `409` | O pedido está incompleto (um lançamento sem dados), ou o objeto não está num estado que permita a ação |
+| `422` | A [validação do lançamento](../launch-validation/) recusou os valores do formulário; `details` indica porquê |
+| `429` | Demasiados pedidos aos endpoints de início de sessão e de token, ou demasiados inícios de sessão falhados (consulte [Autenticação](authentication.html)) |
+| `500` | O servidor falhou; o registo do servidor tem o motivo |
+
+Numa tarefa, um `409` significa que está no estado errado para a ação: abortar uma tarefa que não está em execução (ou cujo abortar já foi pedido),
+relançar uma tarefa que ainda está em execução, ou aprovar ou rejeitar uma tarefa que já não aguarda uma aprovação.
+
+---
+
+## Um 403 com um código
+
+Algumas respostas `403` trazem um `code`, para algo que o utilizador tem de fazer no navegador antes de qualquer outra chamada funcionar:
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| Código | O que fazer |
+|---|---|
+| `password_change_required` | O utilizador iniciou sessão com a palavra-passe predefinida pública: altere-a primeiro no perfil |
+| `disclaimer_required` | O aviso legal está ativado e o utilizador ainda não aceitou a sua versão atual: aceite-o no navegador |
+
+Um token de API de longa duração (consulte [Autenticação](authentication.html#long-lived-tokens)) nunca é retido pelo aviso legal.
diff --git a/i18n/pt/_integrate/chat/index.md b/i18n/pt/_integrate/chat/index.md
new file mode 100644
index 0000000..c4604a1
--- /dev/null
+++ b/i18n/pt/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Assistente de chat
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# Assistente de chat
+{: .no_toc }
+
+Preencha e lance formulários através de uma conversa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para os administradores que o ativam, e para os utilizadores que conversam com ele: preencha e lance formulários através de uma conversa.
+
+Um botão de chat em todas as páginas abre um
+assistente que encontra o formulário certo, pede a informação em falta, oferece as próprias
+opções do formulário como botões e mostra um resumo com um botão **Iniciar**. Uma tarefa só começa quando o utilizador clica nele.
+
+---
+
+## Como funciona
+
+O assistente comunica com o modelo de IA através do servidor, que responde aos pedidos do modelo usando o mesmo motor de formulários que o navegador:
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **As chamadas ao modelo partem do servidor**, nunca do navegador, por isso a chave de API fica no servidor
+  (consulte [Fornecedores](providers.html)).
+- **O modelo não pode lançar nada.** Prepara um resumo de utilização única; Iniciar volta a verificá-lo antes de o executar.
+- **O utilizador escolhe os alvos.** As opções e os nomes obrigatórios vêm do utilizador, nunca do modelo.
+- **Escrever "sim" ou "lançar" não faz nada.** Só o botão lança uma tarefa.
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Ativá-lo](switching-it-on.html) | Ativar o assistente e disponibilizar formulários nele |
+| [Fornecedores](providers.html) | O modelo de linguagem por trás do assistente, e proxies |
+| [Privacidade e limites](privacy-and-limits.html) | O que sai da rede, e os limites por utilizador |
+| [Relançamento e auditoria](relaunching-and-audit.html) | Relançar a partir do chat, o registo de auditoria e as limitações |
diff --git a/i18n/pt/_integrate/chat/privacy-and-limits.md b/i18n/pt/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..d441574
--- /dev/null
+++ b/i18n/pt/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Privacidade e limites
+parent: Assistente de chat
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# Privacidade e limites
+{: .no_toc }
+
+O que sai da rede, e os limites por utilizador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O que sai da rede
+
+Para os formulários que participam, é enviado o seguinte ao fornecedor:
+
+- os nomes e as descrições dos formulários, as etiquetas dos campos, os textos de ajuda, as opções e os valores que estão a ser
+  preenchidos;
+- a conversa.
+
+O seguinte nunca é enviado ao fornecedor, à página nem ao registo:
+
+- palavras-passe (o utilizador introdu-las no navegador), credenciais guardadas e a chave de API;
+- a saída de uma tarefa, e as suas extravars guardadas (o assistente lê apenas o estado de uma tarefa, e só
+  quando **Deixar o assistente acompanhar os seus jobs** está ativado nas definições).
+
+Tudo o que esteja sob uma chave que pareça um segredo (`password`, `secret`, `token`, `api_key`, ...)
+é mascarado antes de o modelo ou a página o verem.
+
+Para manter os dados dos formulários dentro de casa, use o seu próprio tenant (Azure OpenAI) ou um modelo local (Ollama), e não uma API pública.
+
+---
+
+## Limites
+
+Os seguintes limites são definidos na página de definições:
+
+- **Mensagens por conversa** (20) - depois disso o utilizador tem de começar uma nova conversa.
+- **Rondas de ferramentas por mensagem** (6) - quantas vezes o modelo pode chamar uma ferramenta antes de responder.
+- **Tempo limite** (60 s) - por chamada ao fornecedor.
+
+Os seguintes limites são fixos: uma mensagem de cada vez por conversa, no máximo 4000 caracteres por mensagem, 60 mensagens por
+utilizador por hora, e 5 conversas por utilizador. Uma conversa é descartada após 2 horas sem mensagens.
+
+Um cartão de resumo com um botão **Iniciar** pode ser usado uma vez, e expira ao fim de 15 minutos: Iniciar responde então que o
+resumo expirou, e o utilizador pede ao assistente um novo. As conversas e os resumos são guardados em memória, por isso depois de
+um reinício o utilizador tem de começar uma nova conversa.
diff --git a/i18n/pt/_integrate/chat/providers.md b/i18n/pt/_integrate/chat/providers.md
new file mode 100644
index 0000000..5e53b59
--- /dev/null
+++ b/i18n/pt/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: Fornecedores
+parent: Assistente de chat
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# Fornecedores
+{: .no_toc }
+
+O modelo de linguagem por trás do assistente, e proxies
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Selecione o fornecedor na página de definições. Isto preenche o URL base, a autenticação e
+a versão da API, que continuam todos editáveis. Os campos vazios usam as predefinições do fornecedor.
+
+| Fornecedor | Protocolo | URL base (predefinido) | Chave enviada como |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | obrigatório: `https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`, versão da API `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | nenhuma |
+| **Outro compatível com OpenAI** (LiteLLM, um gateway, vLLM, LM Studio, ...) | OpenAI | obrigatório, normalmente a terminar em `/v1` | Bearer |
+
+O ID do modelo é o que o fornecedor ou o proxy usa (`claude-opus-5-5`, `gpt-5`, `llama3.3`,
+...). O assistente exige um modelo que suporte **chamada de ferramentas**; o suporte varia entre
+os modelos locais pequenos.
+
+Para servidores locais e proxies que não precisam de chave, basta um URL base; não é enviado nenhum cabeçalho de autorização.
+
+---
+
+## A chave de API
+
+A chave vem de uma credencial, por isso é guardada e rodada como qualquer outro segredo:
+
+* Crie uma credencial do tipo **api** em **Definições > Ligações > Credenciais** (consulte [Credenciais](../credentials.html)),
+  com a chave como palavra-passe. Também pode ler a chave a partir de um [cofre de segredos](../secret-stores/).
+* Escolha-a no campo **Credencial** das definições do chat. A chave é lida em cada mensagem, por isso uma
+  palavra-passe alterada aplica-se à mensagem seguinte.
+
+Uma chave guardada na página de definições antes de existirem credenciais continua a funcionar enquanto não for escolhida nenhuma credencial. O
+[config seed](../seed/) define a própria chave, como `api_key`.
+
+---
+
+## Para um proxy
+
+Um proxy ou gateway à frente do modelo pode precisar destas definições:
+
+- **Autenticação** - como a chave é enviada: `Authorization: Bearer`, `api-key`, `x-api-key`,
+  ou nenhuma. Vazio usa a predefinição do fornecedor.
+- **Versão da API** - o cabeçalho `anthropic-version`, ou `?api-version=` no URL para compatível com OpenAI (Azure).
+- **Utilizador** - enviado em cada chamada como `user` (compatível com OpenAI) ou `metadata.user_id`
+  (Anthropic). Alguns proxies exigem-no. Vazio não envia nada.
+- **Ignorar erros de certificado** - inseguro; em vez disso, confie na CA do proxy com `NODE_EXTRA_CA_CERTS`.
+- **Cabeçalhos extra** - um objeto JSON, p. ex. `{"X-Org": "ops"}`. Valores de texto de uma linha, no máximo 20;
+  os cabeçalhos da chave e do conteúdo não podem ser substituídos.
+
+---
+
+## Num contentor, por trás de um proxy
+
+O chat usa HTTPS de saída simples a partir do contentor do servidor AnsibleForms. Por trás de um
+proxy de saída empresarial, defina `HTTPS_PROXY` **e** `NODE_USE_ENV_PROXY=1`; sem a segunda,
+o cliente HTTP incorporado do Node ignora `HTTPS_PROXY`. Um fornecedor com um certificado de uma
+CA interna exige que o Node confie nessa CA (`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`).
+Com `NODE_USE_ENV_PROXY=1`, um modelo ou proxy dentro da rede tem de constar em
+`NO_PROXY`, caso contrário a chamada vai para o proxy de saída, que não o consegue alcançar.
+
+Um teste de ligação falhado indica o host e o motivo (DNS, ligação recusada ou certificado não fidedigno).
diff --git a/i18n/pt/_integrate/chat/relaunching-and-audit.md b/i18n/pt/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..0b7f53c
--- /dev/null
+++ b/i18n/pt/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Relançamento e auditoria
+parent: Assistente de chat
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# Relançamento e auditoria
+{: .no_toc }
+
+Relançar a partir do chat, o registo de auditoria e as limitações
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Relançamento
+
+Um pedido como "Executa novamente a tarefa 1234" (o utilizador tem de escrever o ID da tarefa) pré-visualiza um relançamento
+com as mesmas regras que o `relaunch_job` do servidor MCP, incluindo a regra das palavras-passe da
+[validação do lançamento](../launch-validation), e mostra um resumo **Relançar**; o botão
+lança-o uma vez. "Executa novamente a tarefa 1234 com o servidor web02" altera apenas esse campo.
+
+---
+
+## Auditoria
+
+Cada lançamento a partir do chat é registado como **chat.launch** com o utilizador, a tarefa, o formulário,
+o fornecedor e o hash do payload do resumo que foi aprovado. As alterações às definições do chat são
+registadas como qualquer outra alteração de definições.
+
+---
+
+## Limitações
+
+O assistente de chat ainda não faz tudo o que um navegador faz:
+
+- Os **formulários wizard** não podem participar (`enableForChat` é recusado neles), nem os
+  campos que o assistente não preenche: palavras-passe e carregamentos de ficheiros.
+- As respostas chegam de uma só vez; o streaming ainda não é suportado.
+- O modelo pode compreender mal um pedido. O cartão de resumo mostra exatamente o que vai ser enviado;
+  reveja-o antes de clicar em **Iniciar**.
diff --git a/i18n/pt/_integrate/chat/switching-it-on.md b/i18n/pt/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..7b6c201
--- /dev/null
+++ b/i18n/pt/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Ativá-lo
+parent: Assistente de chat
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# Ativá-lo
+{: .no_toc }
+
+Ative o assistente e disponibilize formulários nele
+{: .fs-6 .fw-300 }
+
+---
+
+O assistente exige as quatro condições seguintes:
+
+1. **`ENABLE_CHAT=1`** - a variável de ambiente. Alterada na página de definições, aplica-se de imediato, sem reinício; enquanto
+   estiver desligada, os endpoints do chat respondem `404`. Consulte [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT).
+2. **Um fornecedor de modelo** - Definições -> Ligações -> **Assistente de chat** (ou o [config seed](../seed) em Kubernetes).
+3. **Formulários que participam** - `enableForChat: true` em cada formulário; o assistente ignora todos os outros.
+4. **Utilizadores que o podem usar** - a opção de função `allowChat` (predefinição: true). Defina
+   `allowChat: false` numa função para excluir os seus membros.
+
+O botão de chat aparece para um utilizador assim que as quatro condições estão cumpridas.
diff --git a/i18n/pt/_integrate/mcp/index.md b/i18n/pt/_integrate/mcp/index.md
new file mode 100644
index 0000000..723fb47
--- /dev/null
+++ b/i18n/pt/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Servidor MCP
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# Servidor MCP
+{: .no_toc }
+
+Deixe os agentes de IA usar os seus formulários através do Model Context Protocol
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para administradores e integradores: deixe os clientes MCP listar, preencher e lançar formulários como o utilizador cujo token possuem.
+
+O AnsibleForms pode servir um
+servidor [Model Context Protocol](https://modelcontextprotocol.io), para que um cliente MCP, como
+um backend de chat ou um assistente de IDE, possa listar os formulários que um utilizador pode usar, determinar os seus campos,
+lançar tarefas e acompanhar o seu progresso.
+
+---
+
+## O que é, e o que não é
+
+O servidor MCP é uma interface técnica para o mesmo fluxo de formulários que o navegador usa. É executado
+**como o utilizador cujo token recebe**: as mesmas funções nos formulários, a mesma visibilidade das tarefas, as
+mesmas verificações das extravars reservadas que numa submissão a partir do navegador.
+
+Não acrescenta nenhuma política de IA própria. Se um agente tem de pedir confirmação antes de um lançamento,
+que formulários pode usar ou quantos pedidos pode fazer, cabe ao cliente MCP decidir. A
+ferramenta de lançamento está marcada como destrutiva, por isso um cliente bem comportado pede confirmação primeiro,
+mas o servidor não o impõe.
+
+---
+
+## Nesta secção
+
+Cada tema tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Configuração](setup.html) | Ativar o servidor e autenticar o cliente |
+| [Ferramentas](tools.html) | As ferramentas que um agente usa para preencher, aprovar e relançar formulários |
+| [Limitações](limitations.html) | As expressões executadas no servidor, e o que o servidor MCP não faz |
diff --git a/i18n/pt/_integrate/mcp/limitations.md b/i18n/pt/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..a96324a
--- /dev/null
+++ b/i18n/pt/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: Limitações
+parent: Servidor MCP
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# Limitações
+{: .no_toc }
+
+As expressões executadas no servidor, e o que o servidor MCP não faz
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Expressões runLocal
+
+As expressões `runLocal`, os campos `local` / `credential` / `html` e as predefinições `evalDefault` são
+avaliados no servidor, num contexto V8 separado: sem `process`, `require`, rede nem
+temporizadores, sem compilação de strings em código, com um limite de tempo de 2 segundos, e apenas com as funções
+auxiliares que o navegador oferece (`fnArray`, `fnGetNumberedName`, `fnToTable`, ...).
+
+Isto protege contra expressões com erros ou descontroladas. Não é uma sandbox para código hostil,
+nem precisa de ser: o código vem da definição do formulário, nunca de quem chama o MCP,
+e cada valor que quem chama envia é substituído como um literal JavaScript.
+
+Uma expressão que usa uma API do navegador (`window`, `document`, `fetch`) não pode ser executada aqui e
+devolve `status: error`.
+
+As expressões do lado do servidor (sem `runLocal`) passam pelas mesmas
+regras de [`EXPRESSION_SANITIZER`](../customization) que no navegador.
+
+---
+
+## Limitações
+
+Alguns formulários e campos ainda não podem ser usados através do servidor MCP:
+
+- Os **formulários wizard** ainda não podem ser lançados. Os seus passos podem ser resolvidos com `subform`.
+- Os **campos de ficheiro** não podem ser preenchidos; um formulário cujo campo de ficheiro tenha um valor é recusado.
+- **Linhas de lista** (e um campo `yaml` com um subform, que é uma dessas linhas): cada linha que
+  envia, exceto uma que tenha o `deleteMarker` da lista, é resolvida através do seu subform com
+  os valores do formulário como `__parent__` e depois validada. Isto inclui listas aninhadas, onde
+  `__parent__.__parent__` chega ao formulário. Envie linhas simples, ou seja, os valores brutos dos campos do
+  subform. As linhas que falham são listadas por campo de lista em `rowErrors`
+  (`vms[1].disks[0].size (missing)` na mensagem). São aceites no máximo 500 linhas por chamada,
+  somando todos os níveis.
+- Um enum deixado em `__auto__` nunca é preenchido com a sua primeira opção; quem chama tem de escolher.
+- Cada pedido MCP cria uma entrada no registo de auditoria (ação "Pedido MCP (agente de IA)"); a
+  tarefa propriamente dita é registada em nome do utilizador, como em qualquer outro lançamento.
diff --git a/i18n/pt/_integrate/mcp/setup.md b/i18n/pt/_integrate/mcp/setup.md
new file mode 100644
index 0000000..92b4f00
--- /dev/null
+++ b/i18n/pt/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: Configuração
+parent: Servidor MCP
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# Configuração
+{: .no_toc }
+
+Ative o servidor e autentique o cliente
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ativá-lo
+
+Defina [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) como `1`, ou ative-o em **Definições > Ligações > MCP**
+(consulte [A página MCP](#the-mcp-page)). Alterado na página de definições, o interruptor aplica-se de imediato, sem reinício. Enquanto estiver
+desligado, o endpoint responde `404`. O endpoint é:
+
+```
+POST <your url>/api/v2/mcp
+```
+
+Usa Streamable HTTP sem estado com respostas JSON simples, por isso `GET` e `DELETE` devolvem 405.
+
+---
+
+## Limitar o que os agentes podem fazer
+
+Mais dois interruptores restringem o servidor MCP para todos os clientes. Tal como `ENABLE_MCP`, aplicam-se sem reinício:
+
+| Variável | Com `1` |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | O servidor não oferece nenhuma das ferramentas que lançam, planeiam ou alteram (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job`, `delete_stored_job`), e recusa-as. Os agentes podem listar, ler e preencher formulários, ler agendamentos e tarefas guardadas, e acompanhar tarefas, mas não lançam nem alteram nada: uma forma segura de experimentar um agente. |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | Os agentes só veem os formulários que definem `enableForChat: true`, a mesma lista que o [assistente de chat](../chat/). Qualquer outro formulário, e qualquer tarefa de um deles, responde como não encontrado. |
+
+Ambos estão desligados por predefinição: os agentes veem todos os formulários que as funções do utilizador permitem, e podem lançá-los.
+
+---
+
+## A página MCP
+
+**Definições > Ligações > MCP** contém as definições do servidor MCP em dois separadores.
+
+- **Geral** tem os três interruptores, `ENABLE_MCP`, `MCP_READ_ONLY` e `MCP_CHAT_FORMS_ONLY`, guardados com **Guardar**. Os outros
+  dois só podem ser alterados enquanto o servidor MCP estiver ligado.
+- **Configuração do cliente** mostra o **Endpoint**, com um botão para o copiar, e uma configuração pronta para **Claude Code**
+  (`.mcp.json`, ou um comando `claude mcp add`), **Cursor** (`~/.cursor/mcp.json`), **VS Code** (`.vscode/mcp.json`, que pede
+  o token quando o servidor arranca pela primeira vez) e **Codex** (`~/.codex/config.toml`, com o token na
+  variável de ambiente `ANSIBLEFORMS_TOKEN`). Cada um tem o seu botão de cópia; substitua `<your-token>` por um token seu, criado
+  com a ligação **Criar um token**.
+
+O endpoint é construído a partir do URL da aplicação (**Definições > URL**) quando está definido, caso contrário a partir do endereço do navegador.
+
+---
+
+## Autenticação
+
+Todos os pedidos precisam de um token de acesso do AnsibleForms:
+
+```
+Authorization: Bearer <token>
+```
+
+Obtenha um da forma habitual (`POST /api/v2/auth/login`, ou os fluxos OIDC / Entra ID) e
+renove-o com `POST /api/v2/token`. Propositadamente, **não há nenhuma ferramenta de início de sessão**: uma palavra-passe passada como
+argumento de uma ferramenta acabaria no contexto do modelo de linguagem e no seu histórico de chat.
+
+As funções do utilizador também têm de permitir o servidor MCP, através da [opção de função](../config/roles.html) `allowMcp`. Quando nenhuma função
+do utilizador a define, segue `allowChat`, que está ativada por predefinição. Um utilizador a quem é negado recebe `403` em todos os pedidos.
+
+- **Um backend de chat** inicia ele próprio a sessão do utilizador, guarda o refresh token e passa o token de acesso
+  em cada chamada MCP.
+- **Um cliente de IDE** precisa de um token que dure o suficiente para ser configurado uma vez. Com uma função
+  que tenha a opção `allowApiTokens`, crie um em
+  [Perfil > Tokens de API](../profile/api-token.html), ou inicie sessão com `?expiryDays=<n>` no
+  URL de início de sessão para um token válido durante esse número de dias.
+
+Para ligar um agente de programação com um token desses:
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+Adicione o servidor com o token como cabeçalho:
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+Adicione o servidor a `~/.codex/config.toml`, com o token lido de uma variável de ambiente:
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+Depois defina a variável antes de iniciar o Codex:
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/pt/_integrate/mcp/tools.md b/i18n/pt/_integrate/mcp/tools.md
new file mode 100644
index 0000000..2cc6011
--- /dev/null
+++ b/i18n/pt/_integrate/mcp/tools.md
@@ -0,0 +1,173 @@
+---
+layout: default
+title: Ferramentas
+parent: Servidor MCP
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# Ferramentas
+{: .no_toc }
+
+As ferramentas que um agente usa para preencher, aprovar e relançar formulários
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+O servidor MCP oferece até 15 ferramentas. Seis são oferecidas a todos os utilizadores; as outras dependem das opções de função do utilizador, por isso a um utilizador
+sem uma opção não são sequer oferecidas as respetivas ferramentas:
+
+| Ferramenta | O que faz | Oferecida com |
+|---|---|---|
+| `list_forms` | Os formulários que o utilizador pode usar: nome, descrição, categorias e `enableForChat` (se o assistente de chat o disponibiliza). | sempre |
+| `get_form` | A definição completa de um formulário. Cada campo traz também `dynamic` (avaliado a partir de uma expressão ou consulta) e `dependsOn` (os campos que lê). | sempre |
+| `resolve_field` | Avalia o formulário com os valores preenchidos até ao momento. Ver abaixo. | sempre |
+| `launch_job` | Lança o formulário com os valores indicados, exatamente como uma submissão a partir do navegador. Devolve o ID da tarefa. | sempre |
+| `relaunch_job` | Lança novamente uma tarefa com alguns campos alterados. Ver abaixo. | sempre |
+| `get_job` | Estado e saída de uma tarefa (`tail` limita a saída às últimas linhas). | sempre |
+| `plan_job` | Executa o formulário uma vez, mais tarde, como o utilizador: o que **Executar mais tarde (única)** faz no formulário. | `allowPlannedJobs` |
+| `create_schedule` | Cria um agendamento, recorrente (`cron`) ou único (`run_at`), como na página **Agendamentos**. | `allowScheduledJobs` |
+| `list_schedules` | Os agendamentos que o utilizador pode ver: todos com `allowScheduledJobs`, caso contrário as execuções que planeou. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `get_schedule` | Um agendamento, com as suas extra vars (as que parecem segredos ficam mascaradas) e a saída da sua última execução. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `delete_schedule` | Cancela uma execução planeada ou elimina um agendamento que o utilizador pode ver. | `allowPlannedJobs` ou `allowScheduledJobs` |
+| `list_stored_jobs` | As [tarefas guardadas](../jobs/stored-jobs.html) que o utilizador pode ver, sem os seus valores. | `allowStoredJobs` |
+| `get_stored_job` | Uma tarefa guardada com os seus valores, por `id`, ou por `form` e `name` entre as do próprio utilizador. | `allowStoredJobs` |
+| `store_job` | Guarda valores de um formulário com um nome, como faz **Guardar** no formulário. | `allowStoredJobs` |
+| `delete_stored_job` | Elimina uma tarefa guardada que o utilizador pode ver. | `allowStoredJobs` |
+
+`launch_job`, `relaunch_job` e `plan_job` aceitam `verbose: true` para executar a tarefa em modo detalhado, o que exige a
+opção de função `allowVerboseMode`. Com [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do), as ferramentas que lançam, planeiam ou
+alteram (`launch_job`, `relaunch_job`, `plan_job`, `create_schedule`, `delete_schedule`, `store_job` e `delete_stored_job`)
+não são oferecidas.
+
+Não existe nenhuma ferramenta para executar uma expressão, consulta, playbook ou extravars arbitrários. As expressões
+e as consultas só são executadas tal como o formulário as define.
+
+O [Assistente de chat](../chat) também usa estas ferramentas, com um botão **Iniciar** em vez de `launch_job`.
+
+---
+
+## Preencher um formulário
+
+Chame `resolve_field` com o nome do formulário e os valores que tem até ao momento, e novamente depois de cada resposta. Percorre
+os campos por ordem de dependência e indica para cada um:
+
+- `status`: `resolved`, `waiting` (com `waitingFor`), `hidden`, ou `error` (o campo recorre à sua predefinição);
+- `value`, `default` e, para campos de escolha, `options` (no máximo `maxOptions`, por predefinição 200);
+- `needsInput`: um campo obrigatório sem valor, ou uma escolha ainda em `__auto__`;
+- `validationErrors`: as regras que o valor viola, como `[{type, description}]`, com a mensagem do navegador.
+
+Para o formulário completo, `missing` e `invalid` listam o que ainda é preciso corrigir; `launch_job` recusa-o até `complete` ser true.
+
+A validação é o próprio código do navegador, partilhado com a [validação do lançamento](../launch-validation). Os campos ocultos não são
+validados, e um campo opcional vazio é válido.
+
+---
+
+## Agendamentos e execuções planeadas
+
+`plan_job` aceita o mesmo `form`, `values` e `expectedPayloadHash` que `launch_job`, com um `name` para a execução e `run_at`, uma
+hora ISO 8601 com o seu desvio ou `Z` (`2026-10-15T22:00:00+02:00`); uma hora sem fuso horário é recusada. Os valores são resolvidos
+e validados agora, e verificados novamente quando a execução dispara, tal como numa [execução planeada](../jobs/schedules.html#planned-runs) no
+navegador. A resposta indica a hora da execução em UTC e no relógio da aplicação.
+
+`create_schedule` aceita um `form`, um `name`, ou `cron` (cinco campos, como `0 22 * * 1-5`) ou `run_at`, e as
+`extraVars` que a tarefa recebe. Um agendamento destes é executado como o `Schedule Service`, sem a validação do formulário; para executar um formulário uma vez como
+o utilizador, use `plan_job`. Os nomes dos agendamentos são únicos.
+
+---
+
+## Tarefas guardadas
+
+Uma tarefa guardada são os valores de um formulário guardados com um nome; as ferramentas trabalham sobre as mesmas tarefas guardadas que o navegador.
+
+`list_stored_jobs` lista as tarefas guardadas do próprio utilizador, ou as de toda a gente para um utilizador com `showSettings`, com o seu nome, descrição,
+formulário, criação e expiração. Uma marcada como `usable` (do próprio utilizador, de um formulário que pode lançar) pode ser passada como `storedJob`
+(`{ "id": 7 }`, ou `{ "name": "..." }` entre as do próprio utilizador desse formulário) a `resolve_field`, `launch_job` ou `plan_job`: os seus
+valores são o ponto de partida e os `values` são sobrepostos. Os campos de palavra-passe não são guardados, por isso forneça-os em `values`.
+`launch_job` e `plan_job` a partir de uma tarefa guardada precisam do `expectedPayloadHash` que `resolve_field` devolveu para ela, e
+`resolve_field` recusa `storedJob` em conjunto com `subform`.
+
+`store_job` aceita o `form`, um `name` único entre as tarefas guardadas do utilizador para esse formulário, os `values` e, opcionalmente, uma
+`description` e `expires_at` (ISO 8601 com o seu desvio ou `Z`). A sua resposta indica que campos de palavra-passe ficaram de fora.
+
+---
+
+## Passar valores
+
+Passe `field` para resolver apenas esse campo e aquilo de que depende. Para uma linha de lista ou um passo de wizard, passe `subform` (e
+opcionalmente `parent`, os valores do formulário pai).
+
+Envie os valores tal como o navegador os guarda. Um campo de escolha também aceita um registo parcial ou o seu valor de `valueColumn`
+(`"vol1"`), e um array quando é `multiple`. Os campos calculados ignoram os valores enviados, a menos que sejam `editable`.
+
+---
+
+## Aprovar o payload exato
+
+Quando o formulário está completo, `resolve_field` devolve também o que `launch_job` vai submeter:
+
+- `modeledExtravars`: as extravars depois de aplicados `model`, `valueColumn` e `output`,
+  com os campos de palavra-passe mascarados;
+- `credentials`: as credenciais do AnsibleForms que a tarefa vai usar (nomes, não segredos);
+- `payloadHash`: um hash SHA-256 do nome do formulário, das extravars reais e das credenciais.
+
+Mostre `modeledExtravars` ao operador, e passe o `payloadHash` que ele aprovou a
+`launch_job` como `expectedPayloadHash`. O lançamento resolve o formulário novamente e é recusado
+quando o payload difere, por exemplo porque uma consulta responde agora de forma diferente.
+`ansibleforms_user`, `__jobid__` e `__verbose__` são adicionados no lançamento e não fazem parte do hash.
+
+`launch_job` verifica apenas o payload. Uma edição do formulário que deixe o payload igual não recusa o lançamento.
+Cada resposta de `resolve_field` traz também um `formFingerprint`, um hash SHA-256 da definição do formulário: para recusar um
+lançamento depois de qualquer edição do formulário, compare-o por si antes de chamar `launch_job`, como faz o botão
+**Iniciar** do assistente de chat.
+
+---
+
+## Relançar com alterações
+
+`relaunch_job` aceita um `id` de tarefa e `values`: apenas os campos a alterar, como valores brutos.
+`values` é sobreposto aos valores com que a tarefa foi originalmente lançada, e o resultado é
+resolvido e validado exatamente como por `launch_job`, incluindo as linhas de lista, e depois lançado como uma
+nova tarefa por si (`ansibleforms_user` é você, e não quem a submeteu originalmente). Os carregamentos de ficheiros da
+tarefa original são reutilizados.
+
+Sem `values`, é um relançamento **tal como a tarefa foi executada**: as suas extravars guardadas são repetidas no
+servidor, incluindo as palavras-passe (a pré-visualização mascara-as). No entanto, se o formulário estiver sob a validação do lançamento
+`enforce`, o relançamento passa pela mesma verificação que um relançamento com
+alterações.
+
+**As palavras-passe nunca são guardadas com os valores dos campos**, por isso um relançamento que passa pela
+verificação é recusado quando o formulário mostra um campo de palavra-passe, no nível de topo ou numa linha de lista
+(`unsupported`, com os `passwordFields`). Um campo de palavra-passe oculto pelas suas dependências
+não bloqueia o relançamento. Consulte [Validação do lançamento](../launch-validation).
+
+Chame-a primeiro com `preview: true`: devolve `modeledExtravars` (palavras-passe mascaradas),
+`credentials` e um `payloadHash` sem lançar. Confirme-os com o utilizador e depois chame-a
+novamente com `expectedPayloadHash`. Aplicam-se as mesmas permissões que num relançamento no navegador:
+o formulário tem de permitir o relançamento e as suas funções precisam da opção `allowJobRelaunch`. Uma
+tarefa sem dados de formulário guardados (lançada antes de existir o relançamento) e um formulário wizard não podem ser
+relançados com alterações.
+
+A API REST oferece o mesmo através de `POST /api/v2/job/{id}/relaunch` com o corpo
+`{ "values": { ... } }`; sem corpo, repete a tarefa tal como foi executada.
+
+---
+
+## Erros
+
+Uma chamada recusada é um erro de ferramenta cujo conteúdo estruturado traz um `code` e os detalhes:
+
+| Código | Quando |
+|---|---|
+| `form_incomplete` | `launch_job` ou `relaunch_job` num formulário que não está completo, com `missing`, `invalid`, `waiting`, `validationErrors` e `rowErrors` |
+| `payload_mismatch` | o payload difere de `expectedPayloadHash`, com os dois hashes |
+| `access_denied` | as funções do utilizador não concedem o formulário, a tarefa, o agendamento ou a tarefa guardada, ou o modo detalhado, ou o servidor é só de leitura |
+| `not_found` | não existe esse formulário, subform ou tarefa |
+| `unsupported` | um formulário wizard, um subform isolado, um campo de ficheiro, ou um `relaunch_job` que precisaria de um campo de palavra-passe visível |
+| `no_form_data` | `relaunch_job` com alterações para uma tarefa que não guardou valores do formulário, como uma lançada por um agendamento; relance-a antes sem alterações |
+| `invalid_request` | um pedido que o servidor recusa por estar mal formado |
+| `internal_error` | qualquer outra situação |
diff --git a/i18n/pt/_introduction/concepts.md b/i18n/pt/_introduction/concepts.md
new file mode 100644
index 0000000..484ca4f
--- /dev/null
+++ b/i18n/pt/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Conceitos
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# Conceitos
+{: .no_toc }
+
+Os termos usados ao longo desta documentação, cada um com ligação para a sua página
+{: .fs-6 .fw-300 }
+
+---
+
+## Glossário
+
+Os termos usados ao longo desta documentação:
+
+| Termo | Significado |
+|---|---|
+| **[Formulário](forms/)** | Uma definição YAML que recolhe dados e executa um playbook, um template ou um workflow |
+| **[Campo de formulário](formfields/)** | Uma entrada de um formulário, como `text`, `enum` ou `checkbox`; o seu valor torna-se uma extravar |
+| **[Categoria](config/categories.html)** | Um grupo na árvore de formulários mostrada na página Formulários, definido em `config.yaml` |
+| **[Função](config/roles.html)** | Um conjunto de utilizadores e grupos; um formulário lista as funções que o podem ver e executar, `default` para toda a gente |
+| **[Expressão](expressions/)** | JavaScript que calcula o valor de um campo, no navegador (`runLocal: true`) ou no servidor |
+| **[Extravars](formfields/)** | As variáveis enviadas ao playbook ou ao template, construídas a partir dos valores dos campos |
+| **[Credencial](expressions/credentials.html)** | Um início de sessão guardado, cifrado com `ENCRYPTION_SECRET`: um utilizador e uma palavra-passe (e host, porta, base de dados), ou desde a 7.3.0 o endereço e os segredos de um diretório LDAP, de um fornecedor de SSO, de um runner ou de um HashiCorp Vault |
+| **[Cofre de segredos](secret-stores/)** | Uma ligação ao HashiCorp Vault ou ao CyberArk que fornece o utilizador e a palavra-passe de uma credencial |
+| **[Tarefa](gui/forms-and-jobs.html)** | Uma execução de um formulário, com o seu estado, extravars e saída, guardada no histórico de tarefas |
+| **[Runner](runners.html)** | Onde uma tarefa é executada, adicionado em **Ligações > Runners**: `rte` para playbooks, `awx` (AWX, ou as variantes `aap` ou `ascender`), `semaphore`, `rundeck` ou `jenkins` para templates e jobs. Um formulário escolhe um com `runner:`, ou é executado no runner predefinido `rte` (playbooks) ou `awx` (templates) |
+| **[RTE](rte/)** | Um ambiente de execução: o servidor AnsibleForms iniciado com `AF_ROLE=rte` no seu próprio contentor, ao lado de python e ansible, que executa os playbooks de um runner do tipo `rte` |
+| **[Ponto de aprovação](forms/approval.html)** | Uma pausa numa tarefa até que um utilizador com uma função de aprovação a aprove ou rejeite |
+| **[Workflow](workflows/)** | Um grafo de playbooks, aprovações e outros workflows ligados em caso de sucesso, de falha ou sempre, com a sintaxe do AWX |
+| **[Formulário multistep](forms/multistep.html)** | Descontinuado desde a 7: um formulário que executa vários playbooks ou templates em sequência; um workflow substitui-o |
+| **[Canal de notificação](notification-channels.html)** | Um servidor de email, um webhook do Slack ou do Teams, um chat do Telegram ou um webhook para onde vão as notificações e os pedidos de aprovação |
+| **[Designer](designer/)** | O editor no navegador para formulários, playbooks, inventários e workflows, usado por uma pessoa de cada vez |
+| **[Subform](forms/subform.html)** | Um conjunto reutilizável de campos que descreve as linhas de um campo `list` ou o objeto de um campo `yaml` |
+| **[config.yaml](config/)** | O ficheiro com as categorias, as funções e as constantes; os formulários vivem nos seus próprios ficheiros |
+| **[Config seed](seed/)** | Um ficheiro YAML (`CONFIG_SEED_PATH`) que declara os objetos de administração, como runners e credenciais |
+| **[Pasta persistente](customization/paths.html)** | A pasta que contém os ficheiros que o AnsibleForms tem de manter entre reinícios e atualizações |
diff --git a/i18n/pt/_introduction/gui/administration.md b/i18n/pt/_introduction/gui/administration.md
new file mode 100644
index 0000000..9bf997d
--- /dev/null
+++ b/i18n/pt/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Administração
+parent: Visita à interface
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# Administração
+{: .no_toc }
+
+O menu Definições: o sistema, a sua aparência, o acesso, as ligações e os registos
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O menu Definições
+
+**Definições** no cabeçalho abre as páginas de administração, agrupadas no menu da esquerda em **Sistema**, **Aparência**,
+**Acesso**, **Ligações** e **Registos**. Cada entrada só aparece a um utilizador com a opção de função de que a sua página precisa:
+`allowBackupOps` para **Cópias de segurança**, `showLogs` para **Registo do servidor** e `showSettings` para todas as outras páginas.
+A partir da 7.3.0, três opções abrem uma parte delas sem o resto:
+
+| Opção de função | Abre |
+|---|---|
+| `showAppearanceSettings` | As páginas de **Aparência** |
+| `showConnectionsSettings` | As páginas de **Ligações**, exceto **Syslog**; os repositórios, os cofres de segredos e as credenciais protegidas continuam a ser alterados apenas por um administrador |
+| `showAuditLog` | O **Registo de auditoria** |
+
+Consulte [Funções](../config/roles.html#role-options) para as opções de função.
+
+---
+
+## Listas e páginas de registo
+
+A partir da 7.3.0, as listas das definições e as páginas de registo partilham uma única disposição, com os seus controlos numa linha própria por baixo do título:
+
+| Parte | Como funciona |
+|---|---|
+| Caixa de pesquisa | A primeira dessa linha em todas as páginas de definições e de registo. Uma palavra restringe todos os separadores de uma vez: os campos, as linhas ou as entradas correspondentes aparecem sob o nome do seu separador |
+| Tamanho da página | Uma tabela mostra tantas linhas quantas cabem no ecrã até ser escolhido um tamanho de página: 10, 20, 50 ou 100 |
+| Colunas | Todas as colunas com nome permitem ordenar, e uma célula vazia mostra `–` |
+| Caixas de verificação | As linhas só as têm quando há algo a fazer com as linhas marcadas, e o menu da linha (⋮) oferece a mesma ação |
+| Menu da linha | Etiquetas curtas, como **Editar** e **Eliminar**. Uma lista com uma coluna **Ativado** tem-na em primeiro lugar, e oferece **Ativar** ou **Desativar** no menu de cada linha, consoante o caso |
+
+As listas com uma coluna **Ativado** são os fornecedores de SSO, os diretórios LDAP, os runners, os agendamentos, os canais de
+notificação, os servidores syslog, os anúncios, as etiquetas e as versões do aviso legal.
+
+---
+
+## Sistema
+
+A própria instância: as suas definições, a sua saúde e as suas cópias de segurança.
+
+| Página | Para que serve |
+|---|---|
+| **Geral** | As variáveis de ambiente, em separadores de Configuração a Registo. Consulte [Variáveis de ambiente](../customization/). |
+| **Estado** | A saúde da instância e dos sistemas de que depende, nos separadores Verificações e Informação. Consulte [Monitorização](../production/monitoring.html). |
+| **Cópias de segurança** | Fazer, restaurar e eliminar cópias de segurança da base de dados, do config.yaml e dos formulários. Consulte [Cópias de segurança](../production/backups.html). |
+
+![Definições > Geral, o separador Configuração](../assets/screenshots/settings.jpg)
+
+### Cópias de segurança
+
+A lista de cópias de segurança, noturnas e manuais: **Adicionar cópia de segurança** faz uma agora, e o menu de uma linha tem **Mostrar cópia de segurança**, **Restaurar** e **Eliminar**.
+
+![Definições > Cópias de segurança](../assets/screenshots/backups.jpg)
+
+### Restaurar
+
+**Restaurar** mostra o que a cópia de segurança contém e depois restaura-a; **Criar uma nova cópia de segurança antes de restaurar (recomendado)** está marcado por predefinição.
+
+![Restaurar uma cópia de segurança](../assets/screenshots/restore.jpg)
+
+---
+
+## Aparência
+
+O aspeto da instância para toda a gente, e as mensagens que mostra.
+
+| Página | Para que serve |
+|---|---|
+| **Predefinições** | O tema, o idioma, a vista dos formulários, o fuso horário e o formato de data dos utilizadores que não escolheram nenhum. Consulte [Predefinições](../appearance/defaults.html). |
+| **Nome** | O nome no separador do navegador e na página de início de sessão. Consulte [Nome](../appearance/name.html). |
+| **Logótipo** | O seu próprio logótipo no cabeçalho. Consulte [Logótipo](../appearance/logo.html). |
+| **Ícone** | O seu próprio ícone no separador do navegador. Consulte [Ícone](../appearance/icon.html). |
+| **Ligações** | A ligação para o Designer, e as suas próprias ligações e menus no cabeçalho. Consulte [Ligações](../appearance/links.html). |
+| **Etiquetas** | Etiquetas ao lado do logótipo, como PRODUCTION e EU. Consulte [Etiquetas](../appearance/labels.html). |
+| **Anúncios** | Mensagens por baixo do cabeçalho, cada uma do seu início até ao seu fim. Consulte [Anúncios](../announcements.html). |
+
+---
+
+## Acesso
+
+Quem pode iniciar sessão, e o que pode fazer depois de entrar.
+
+| Página | Para que serve |
+|---|---|
+| **Aviso legal** | Termos que cada utilizador aceita uma vez, e quem aceitou que versão. Consulte [Aviso legal](../disclaimer.html). |
+| **Utilizadores** | Os utilizadores locais, e os de LDAP e de início de sessão único. Consulte [Utilizadores e grupos](../users-and-groups.html). |
+| **Grupos** | Os grupos locais, e os de LDAP e de início de sessão único. Consulte [Utilizadores e grupos](../users-and-groups/local-group.html). |
+| **Funções** | As funções do config.yaml: quem as tem e o que permitem. Consulte [Funções](../config/roles.html). |
+| **LDAP** | Início de sessão com um diretório LDAP ou Active Directory. Consulte [LDAP](../authentication/ldap.html). |
+| **SSO** | Início de sessão único com fornecedores Entra ID ou OpenID Connect. Consulte [Autenticação](../authentication/). |
+
+![Acesso > LDAP, o diretório principal](../assets/screenshots/ldap.jpg)
+
+---
+
+## Ligações
+
+Os sistemas a que o AnsibleForms chega, e com o que inicia sessão neles.
+
+| Página | Para que serve |
+|---|---|
+| **Repositórios** | Os repositórios git de onde vêm os formulários e os playbooks. Consulte [Repositórios git](../repositories/). |
+| **Credenciais** | As contas e os segredos que os formulários, os playbooks e as ligações usam. Consulte [Credenciais](../credentials.html). |
+| **Cofres de segredos** | HashiCorp Vault e CyberArk, de onde as credenciais podem ser lidas. Consulte [Cofres de segredos](../secret-stores/). |
+| **Runners** | Onde as tarefas são executadas: contentores RTE para playbooks, e AWX e afins para templates. Consulte [Runners](../runners.html). |
+| **SSH** | O par de chaves com que a aplicação se liga ao git, e os hosts conhecidos. Consulte [SSH](../repositories/authentication.html#ssh-with-the-generated-key). |
+| **Notificações** | Servidores SMTP, Slack, Microsoft Teams, Telegram e webhooks. Consulte [Canais de notificação](../notification-channels.html). |
+| **Assistente de chat** | O fornecedor de IA do assistente de chat. Consulte [Assistente de chat](../chat/). |
+| **MCP** | O servidor MCP para agentes de IA. Consulte [MCP](../mcp/). |
+| **Syslog** | Servidores syslog que recebem o registo do servidor, o registo de auditoria, ou ambos. Consulte [Syslog](../production/logs.html#syslog). |
+
+![Ligações > Credenciais, o separador Ligação de uma credencial](../assets/screenshots/credentials.jpg)
+
+---
+
+## Registos
+
+O que aconteceu na instância.
+
+| Página | Para que serve |
+|---|---|
+| **Registo de auditoria** | Quem alterou o quê, e se foi permitido, filtrado por utilizador, ação e resultado. Consulte [Registo de auditoria](../production/logs.html#audit-trail). |
+| **Registo do servidor** | O próprio registo do servidor, para resolução de problemas. Consulte [Registos](../production/logs.html). |
+
+### Registo do servidor
+
+As últimas linhas do registo, as mais recentes em baixo, acompanhadas à medida que são escritas. A caixa de pesquisa filtra-as (uma expressão
+regular), **Limpar** esvazia a vista, não o registo, e **Transferir** guarda o registo completo.
+
+![Registos > Registo do servidor](../assets/screenshots/logs.jpg)
+
+---
+
+## Documentação da API
+
+**Documentação da API** no menu de ajuda (o ponto de interrogação no cabeçalho) liga ao Swagger UI da API REST em `/api/v2/docs`.
+Consulte [API](../api/).
+
+![Interface Swagger](../assets/screenshots/swagger.jpg)
diff --git a/i18n/pt/_introduction/gui/designer-and-git.md b/i18n/pt/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..c8a40c0
--- /dev/null
+++ b/i18n/pt/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: Designer e git
+parent: Visita à interface
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# Designer e git
+{: .no_toc }
+
+Editar formulários e mantê-los em git
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Designer incorporado
+
+Edite formulários, categorias, constantes, ficheiros de variáveis, playbooks, inventários e workflows, cada um como YAML, com campos (Visual)
+e como pré-visualização. As páginas do [Designer](../designer/) descrevem cada secção.
+
+![Designer incorporado](../assets/screenshots/designer.jpg)
+
+---
+
+## Repositórios Git
+
+Integre com repositórios Git para colocar os seus formulários e playbooks sob controlo de versões.
+
+![Repositórios Git](../assets/screenshots/git.jpg)
+
+---
+
+## Editor de repositórios Git
+
+Edite e configure as definições de integração com repositórios Git.
+
+![Editor de repositórios Git](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/pt/_introduction/gui/forms-and-jobs.md b/i18n/pt/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..72b0a4e
--- /dev/null
+++ b/i18n/pt/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: Formulários e tarefas
+parent: Visita à interface
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# Formulários e tarefas
+{: .no_toc }
+
+Iniciar sessão, o painel, preencher um formulário e acompanhar as suas tarefas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Início de sessão
+
+A página de autenticação do utilizador, com suporte para autenticação local, LDAP, Entra ID e OIDC.
+
+![Início de sessão](../assets/screenshots/login.jpg)
+
+---
+
+## O painel
+
+O painel principal mostra todos os formulários disponíveis organizados por categoria.
+
+![Painel](../assets/screenshots/dashboard.jpg)
+
+---
+
+## Um formulário
+
+Um exemplo de um formulário com fontes de dados externas e campos dinâmicos.
+
+![Exemplo de formulário](../assets/screenshots/form.jpg)
+
+---
+
+## Pré-visualização JSON do formulário
+
+Pré-visualize o payload JSON e as variáveis extra passadas ao Ansible antes de executar a tarefa.
+
+![Pré-visualização JSON do formulário](../assets/screenshots/form-json.jpg)
+
+---
+
+## Tarefa em execução
+
+Execução em tempo real de um playbook Ansible com a saída em direto.
+
+![Tarefa em execução](../assets/screenshots/run.jpg)
+
+---
+
+## Saída da tarefa
+
+A saída completa de um playbook Ansible executado.
+
+![Saída da tarefa](../assets/screenshots/job-output.jpg)
+
+---
+
+## Registos de tarefas
+
+Todas as tarefas com o seu estado e as suas horas, filtradas por estado a partir do menu da esquerda.
+
+![Registos de tarefas](../assets/screenshots/job-log.jpg)
+
+---
+
+## Multistep
+
+Uma tarefa multistep, com a saída de cada passo por baixo da tarefa principal. Os formulários multistep estão descontinuados desde a 7: um
+[workflow](../workflows/) encadeia playbooks, templates e aprovações em vez disso.
+
+![Formulário multistep](../assets/screenshots/multistep.jpg)
+
+---
+
+## Agendamentos
+
+Agende formulários para serem executados a horas ou intervalos específicos. Os [exemplos de cron](../faq.html#which-cron-expressions-can-i-use) listam expressões
+comuns, e explicam em que fuso horário um agendamento é executado.
+
+![Agendamentos](../assets/screenshots/schedules.jpg)
diff --git a/i18n/pt/_introduction/gui/index.md b/i18n/pt/_introduction/gui/index.md
new file mode 100644
index 0000000..1fcb103
--- /dev/null
+++ b/i18n/pt/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: Visita à interface
+nav_order: 3
+has_children: true
+has_toc: false
+description: Capturas de ecrã e visita à interface gráfica
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# Visita à interface
+{: .no_toc }
+
+Uma visita visual à interface web do AnsibleForms, desde o painel até às funcionalidades avançadas de administração.
+{: .fs-6 .fw-300 }
+
+---
+
+Para todos os utilizadores e administradores: os ecrãs da interface web, agrupados pelo que faz com eles.
+
+---
+
+## Nesta secção
+
+Cada grupo de ecrãs tem uma página própria:
+
+| Página | O que abrange |
+|---|---|
+| [Formulários e tarefas](forms-and-jobs.html) | Iniciar sessão, o painel, preencher um formulário e acompanhar as suas tarefas |
+| [Designer e git](designer-and-git.html) | Editar formulários e mantê-los em git |
+| [Administração](administration.html) | O menu Definições: o sistema, a sua aparência, o acesso, as ligações e os registos |
+| [Definições pessoais](personal-settings.html) | O seu perfil e o tema escuro |
diff --git a/i18n/pt/_introduction/gui/personal-settings.md b/i18n/pt/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..9b6f05d
--- /dev/null
+++ b/i18n/pt/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Definições pessoais
+parent: Visita à interface
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# Definições pessoais
+{: .no_toc }
+
+O seu perfil e o tema escuro
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Perfil do utilizador
+
+A sua conta, preferências, palavra-passe, permissões e tokens de API.
+
+Consulte [O seu perfil](../profile).
+
+![Perfil do utilizador](../assets/screenshots/profile.jpg)
+
+---
+
+## Modo escuro
+
+O AnsibleForms suporta o modo escuro para reduzir o cansaço visual.
+
+![Modo escuro](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/pt/_introduction/how-it-works.md b/i18n/pt/_introduction/how-it-works.md
new file mode 100644
index 0000000..1a3d950
--- /dev/null
+++ b/i18n/pt/_introduction/how-it-works.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: Como funciona
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# Como funciona
+{: .no_toc }
+
+As partes de uma instalação, o que acontece num lançamento, e onde os dados são guardados
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Arquitetura
+
+O AnsibleForms é um servidor Node.js que serve a aplicação web e uma API REST, apoiado por uma base de dados MySQL. Lê os formulários
+de ficheiros YAML e não executa nada por si: entrega cada tarefa a um [runner](runners.html). Um playbook vai para um dos seus contentores RTE
+(ambiente de execução), que executa `ansible-playbook`, e um template ou job vai para o AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins:
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">Arquitetura do AnsibleForms</title>
+<desc id="afd-desc">O navegador e um cliente MCP opcional comunicam com o servidor AnsibleForms. O servidor guarda os seus dados no MySQL e na pasta persistente, e liga-se a fontes de dados, cofres de segredos, repositórios git, fornecedores de início de sessão, canais de notificação, servidores syslog e um fornecedor de modelos opcional. Os seus runners entregam cada playbook a um de um ou mais contentores RTE, cada um através de um WebSocket, que executam o ansible-playbook e devolvem a saída ao servidor, e cada template ou job ao AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins.</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="94" text-anchor="middle">Navegador</text>
+<text class="afd-s" x="105" y="112" text-anchor="middle">formulários, designer,</text>
+<text class="afd-s" x="105" y="127" text-anchor="middle">tarefas, chat</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">Cliente MCP</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">opcional</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">Servidor AnsibleForms</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Aplicação web e API REST</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">Formulários, expressões</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">Workflows, agendamentos</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">Servidor MCP (opcional)</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">Runners</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">entregam as tarefas ao runner</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">Fontes de dados</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">BD, APIs REST, ficheiros</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">Cofres de segredos</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Repositórios git</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">formulários, playbooks, config</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">Fornecedores de login</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">Notificações</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">email, Slack, Teams, webhooks</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Servidores syslog</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">o registo, a auditoria</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">Fornecedor de modelos</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">opcional, assistente de chat</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">Pasta persistente</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">config, formulários, playbooks</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="441" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="458" text-anchor="middle">tarefas, utilizadores,</text>
+<text class="afd-s" x="285" y="472" text-anchor="middle">credenciais</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">Contentores RTE</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">executam ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbooks,</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">templates, jobs</text>
+</svg>
+</div>
+
+Os componentes do diagrama têm cada um a sua função:
+
+| Componente | Função |
+|---|---|
+| **Navegador** | A aplicação web em Vue: os formulários, o [Designer](gui/designer-and-git.html), o histórico de tarefas e as definições |
+| **Servidor AnsibleForms** | Avalia os formulários, regista as tarefas, executa os workflows e os agendamentos, entrega cada tarefa ao seu runner e acompanha-a, e serve a [API REST](api/) |
+| **Runners** | Onde as tarefas são executadas, adicionados em **Ligações > Runners**: um formulário indica um com `runner: <name>`, ou usa o runner predefinido do seu tipo (consulte [Runners](runners.html)) |
+| **Contentores RTE** | Um ou mais contentores de ambiente de execução, o mesmo servidor iniciado com `AF_ROLE=rte`: cada um executa `ansible-playbook` para os [formulários ansible](forms/ansible.html), com as bibliotecas python e as coleções da sua imagem, e devolve a saída e o estado final ao servidor através de um WebSocket, sem credenciais da base de dados (consulte [Como o RTE é executado](rte/#how-the-rte-runs)) |
+| **AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins** | Runners para templates e jobs: os [formulários AWX](forms/awx.html) lançam um job template ou um workflow template, os formulários [Semaphore](forms/semaphore.html), [Rundeck](forms/rundeck.html) e [Jenkins](forms/jenkins.html) lançam um dos seus jobs, e o servidor acompanha a sua saída |
+| **MySQL / MariaDB** | Contém as tarefas e a sua saída, os utilizadores, as credenciais e as ligações; só o servidor a lê e escreve |
+| **Pasta persistente** | Contém o `config.yaml`, os ficheiros de formulários, os playbooks, os registos e as cópias de segurança |
+| **Fontes de dados** | Preenchem os campos: [consultas a bases de dados](formfields/enum.html), [APIs REST](expressions/rest-apis.html), ficheiros e [outras funções](expressions/remote.html) |
+| **Cofres de segredos** | Fornecem o utilizador e a palavra-passe de uma credencial no momento da utilização, consulte [Cofres de segredos](secret-stores/) |
+| **Repositórios git** | Mantêm os formulários, os playbooks e o `config.yaml` sob controlo de versões |
+| **Fornecedores de login** | Iniciam a sessão dos utilizadores: [LDAP, Entra ID e OIDC](authentication/), ao lado dos utilizadores locais |
+| **Canais de notificação** | Transportam as [notificações](forms/notifications.html) e os pedidos de aprovação: [email, Slack, Microsoft Teams, Telegram ou um webhook](notification-channels.html) |
+| **Servidores syslog** | Recebem o registo e o registo de auditoria à medida que são escritos, consulte [Syslog](production/logs.html#syslog) |
+| **Cliente MCP, chat** | Opcionais, ambos desligados por predefinição: o [servidor MCP](mcp/) e o [assistente de chat](chat/), que precisa de um fornecedor de modelos |
+
+Por predefinição, um contentor executa o servidor, a aplicação web e o trabalho em segundo plano em conjunto, ao lado de um RTE. Para vários nós da aplicação por trás de um
+balanceador de carga, um worker que executa o trabalho em segundo plano, e mais RTEs, consulte [Escalar](production/scaling.html).
+
+### Construído com
+
+O servidor e a interface web assentam nestes componentes:
+
+| Parte | Tecnologia |
+|---|---|
+| **Servidor** | Node.js e Express |
+| **Base de dados** | MySQL ou MariaDB |
+| **Interface web** | Vue 3, com Bootstrap 5 e Font Awesome |
+
+---
+
+## O que acontece quando lança um formulário
+
+Um lançamento passa pelos mesmos passos, venha do navegador ou da [API REST](api/jobs.html):
+
+1. **Carregar** : o servidor envia apenas os formulários que as [funções](config/roles.html) do utilizador permitem, e avalia as expressões do servidor
+2. **Submeter** : o navegador transforma os valores dos campos em extravars e envia-os para `POST /api/v2/job`
+3. **Verificar** : o servidor volta a carregar o formulário para as funções do utilizador e, com a [validação do lançamento](launch-validation/) ativa, verifica os valores
+4. **Registar** : a tarefa é guardada com o estado `running`, e o seu ID é adicionado às extravars como `__jobid__`
+5. **Aprovar** : um formulário com um ponto de [`approval`](forms/approval.html) espera até que um aprovador aceite a tarefa
+6. **Credenciais** : para um playbook, a aplicação (nunca o RTE) lê as credenciais do formulário a partir da base de dados ou de um [cofre de segredos](secret-stores/)
+7. **Executar** : a tarefa vai para o seu runner, aquele que o formulário indica com `runner:` ou o predefinido do seu tipo. Para um playbook, a aplicação envia a tarefa ao seu
+   RTE através do WebSocket do RTE, com as credenciais seladas para ele, e o RTE executa `ansible-playbook` (consulte [Como o RTE é executado](rte/#how-the-rte-runs)),
+   e o AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins executa um template ou um job. Um [workflow](workflows/) executa os seus nós, cada um como uma
+   tarefa própria no seu próprio runner
+8. **Acompanhar** : o servidor guarda a saída na base de dados à medida que chega, enviada pelo RTE através do seu socket no caso de um playbook, ou lida a partir dos
+   outros runners. A página do formulário volta a ler a tarefa a cada dois segundos, e a página Tarefas acompanha-a em direto à medida que o servidor
+   anuncia cada alteração
+9. **Terminar** : a tarefa recebe o seu estado final, e as suas [`notifications`](forms/notifications.html) são enviadas por email e para os seus
+   [canais de notificação](notification-channels.html) quando o formulário as pede
+
+---
+
+## Onde as coisas são guardadas
+
+O AnsibleForms guarda o seu estado em dois sítios: a base de dados MySQL e a pasta persistente. Faça cópias de segurança de ambos.
+
+### Na base de dados
+{: .no_toc }
+
+A base de dados, `AnsibleForms`, é criada no primeiro arranque (a menos que `ALLOW_SCHEMA_CREATION` seja `0`) e contém:
+
+* as tarefas, as suas extravars e a sua saída, os agendamentos e as tarefas guardadas
+* os utilizadores locais, os grupos e os tokens de API
+* as credenciais, cifradas com `ENCRYPTION_SECRET`, e as ligações aos cofres de segredos
+* os runners, os canais de notificação (incluindo o email), os servidores syslog, e as definições de LDAP, SSO, repositórios e do assistente de chat
+* o registo de auditoria
+
+### Na pasta persistente
+{: .no_toc }
+
+É `/app/dist/persistent` na imagem e `server/persistent` a partir do código-fonte; cada caminho tem a sua própria [variável](customization/paths.html):
+
+| Caminho predefinido | Variável | Conteúdo |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | As categorias, as funções e as constantes |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | Os ficheiros de formulários, `.yaml` ou `.yml`, em subpastas se quiser |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | Os playbooks dos formulários `ansible`, e o seu diretório de trabalho |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | Os clones dos repositórios git |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | As cópias que o Designer faz antes de guardar |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | As cópias de segurança da base de dados |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | Os ficheiros carregados através de campos `file` |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` e `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | O certificado e a chave, quando `HTTPS` é `1` |
+| `.env` | | As variáveis de ambiente guardadas a partir das páginas de definições (a menos que `ALLOW_ENV_EDIT` seja `0`) |
+
+A chave SSH gerada fica em [`HOME_PATH`](customization/paths.html#env_HOME_PATH), fora da pasta persistente por predefinição.
diff --git a/i18n/pt/_introduction/prerequisites.md b/i18n/pt/_introduction/prerequisites.md
new file mode 100644
index 0000000..87d1c5d
--- /dev/null
+++ b/i18n/pt/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: Pré-requisitos
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# Pré-requisitos
+{: .no_toc }
+
+O que precisa antes de instalar o AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Ambiente de execução
+
+O AnsibleForms corre como um contentor, como serviços systemd no próprio servidor ou, para quem o compila, como uma aplicação Node.js:
+
+| Instalação | Precisa de |
+|---|---|
+| [Instalador](installation/installer.html) | Linux em amd64 ou arm64, `curl` ou `wget` e `sha256sum`, e os requisitos do motor em que instala (abaixo) |
+| [Nativa](installation/native.html) | Root, systemd e um Linux suportado (Ubuntu, Debian, RHEL e as suas recompilações, SUSE); o instalador instala o resto |
+| [Docker](installation/docker.html) | Docker ou Podman, e um servidor MySQL próprio |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose ou podman-compose; o projeto também inicia o MySQL |
+| [Kubernetes](installation/kubernetes.html) | Um cluster, Helm 3 e uma StorageClass (ou PersistentVolumes criados previamente) |
+| [A partir do código-fonte](installation/from-source.html) | Node.js 26 (no mínimo a 24) com npm, Git, e Ansible para o processo RTE que executa os playbooks |
+
+A imagem da aplicação, `ghcr.io/ansibleforms/ansibleforms`, contém o Node.js e as ferramentas que o servidor chama (git, ssh, o cliente mariadb e
+ytt), mas não contém Python nem Ansible. Os playbooks são executados num RTE (ambiente de execução), um segundo contentor a partir de
+`ghcr.io/ansibleforms/ansibleforms-rte-full`, ou de uma imagem que construa sobre `ansibleforms-rte-core` (consulte [Escalar](rte/)).
+Os formulários que apenas lançam templates no AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins não precisam de RTE.
+
+---
+
+## Base de dados
+
+O AnsibleForms guarda as suas tarefas, utilizadores, credenciais e ligações no MySQL 8 ou posterior, ou no MariaDB.
+
+No primeiro arranque cria ele próprio o esquema `AnsibleForms`. Dê-lhe um utilizador de base de dados próprio, com direitos apenas sobre esse esquema,
+e não o root:
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+É tudo o que precisa: cria e atualiza o esquema, faz as suas cópias de segurança e, com vários workers, termina a sessão de um que tenha morrido.
+A página **Estado** e o registo avisam quando o utilizador tem direitos sobre todas as bases de dados. Os nós da aplicação e os workers ligam-se com este
+utilizador. Um RTE num modo socket (outbound ou inbound, consulte [Modos](rte/modes.html)) não guarda credenciais da base de dados: só um em modo base de dados,
+descontinuado desde a 7.3.0, também se liga. Para criar o esquema por si, defina [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) como `0`.
+O projeto Docker Compose e o chart de Helm (que usa `mysql:8.4`) iniciam uma base de dados por si.
+
+---
+
+## Dimensionamento
+
+Não há requisitos medidos: a carga depende sobretudo de quantas tarefas são executadas ao mesmo tempo e de quanta saída escrevem.
+Os recursos predefinidos do chart de Helm são um ponto de partida razoável para uma equipa pequena:
+
+| Componente | Pedidos | Limites | Volume |
+|---|---|---|---|
+| AnsibleForms | 1 CPU, 1 GiB de memória | 4 CPU, 4 GiB de memória | 10 GiB |
+| MySQL | 0,5 CPU, 512 MiB de memória | 2 CPU, 2 GiB de memória | 10 GiB |
+
+O contentor da aplicação não executa nenhum playbook. Cada playbook é um processo `ansible-playbook`, com os seus forks, num RTE: dimensione o CPU e a
+memória de cada RTE para os playbooks que executa em simultâneo, no máximo [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) (`10` por predefinição), e execute mais
+RTEs para executar mais. As tarefas executadas no AWX, AAP, Ascender ou nos outros runners de templates custam pouco ao AnsibleForms.
+
+A saída das tarefas é guardada na base de dados para sempre por predefinição. Defina [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)
+numa instância com muita atividade para evitar que a base de dados cresça sem limite.
+
+---
+
+## Rede
+
+A aplicação e cada RTE escutam numa porta própria, e abrem ligações de saída para os sistemas que os seus formulários e definições usam.
+
+### Entrada
+{: .no_toc }
+
+O servidor escuta na porta `8000` ([`PORT`](customization/server.html#env_PORT)), por HTTP ou, com
+[`HTTPS`](customization/server.html#env_HTTPS) definido como `1`, por HTTPS. O projeto Docker Compose publica-o na porta 443,
+e o chart de Helm expõe-no através de um serviço ou de um ingress. Um RTE também escuta no seu próprio `PORT`, mas só a aplicação o chama:
+mantenha-o fora da rede pública. Um RTE de saída não precisa de nenhuma porta de entrada: liga-se à aplicação na porta da aplicação.
+
+### Saída
+{: .no_toc }
+
+Abra as ligações do AnsibleForms para os sistemas que usa:
+
+| Destino | Usado para |
+|---|---|
+| MySQL / MariaDB | A base de dados do AnsibleForms (`DB_HOST`, `DB_PORT`, por predefinição `3306`) |
+| O RTE | Ligar-se a um RTE de entrada no endereço do seu runner através de um WebSocket, ou chamar um em modo base de dados no seu [`RTE_URL`](customization/server.html#env_RTE_URL), que depois se liga ele próprio ao MySQL; um RTE de saída é que se liga à aplicação (consulte [Modos](rte/modes.html)) |
+| AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins | Lançar e acompanhar templates e jobs em [runners](runners.html), através da sua API HTTP(S) |
+| Os hosts geridos | Os playbooks ligam-se a eles a partir do RTE, por exemplo por SSH ou WinRM |
+| LDAP, Entra ID, OIDC | Iniciar sessão com contas de diretório ou de início de sessão único |
+| Servidores Git | Clonar e atualizar repositórios, por HTTPS ou SSH |
+| APIs REST e bases de dados | As fontes de dados das expressões e das consultas dos seus formulários |
+| HashiCorp Vault, CyberArk | Ler credenciais a partir de um [cofre de segredos](secret-stores/) |
+| Servidores de email, Slack, Teams, Telegram, webhooks | Notificações de tarefas e pedidos de aprovação, através dos [canais de notificação](notification-channels.html) |
+| Fornecedor de modelos | O [assistente de chat](chat/), apenas quando está ativado |
+
+Para limitar os hosts que as funções REST das expressões podem chamar, consulte
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) e
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS).
+
+---
+
+## Navegador
+
+A aplicação web foi feita para navegadores atuais: Chrome ou Edge 111, Firefox 114, Safari 16.4 ou mais recentes.
+Os navegadores mais antigos não são suportados.
+
+---
+
+## Escalar
+
+Por predefinição, um contentor AnsibleForms executa a aplicação web e o trabalho em segundo plano em conjunto, ao lado de um RTE.
+
+Para servir mais utilizadores, execute vários nós da aplicação por trás de um balanceador de carga (`AF_ROLE=app`) ao lado de um worker (`AF_ROLE=worker`), que executa os
+agendamentos, as cópias de segurança e o restante trabalho em segundo plano; só um worker trabalha de cada vez, e um segundo espera para assumir. Partilham
+a base de dados, a pasta persistente, `ACCESS_TOKEN_SECRET` e `ENCRYPTION_SECRET`. Consulte [Escalar](production/scaling.html). Execute mais
+RTEs para executar mais playbooks em simultâneo: consulte [Vários RTEs](rte/several.html).
diff --git a/i18n/pt/_introduction/what-is-ansibleforms.md b/i18n/pt/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..3e38e09
--- /dev/null
+++ b/i18n/pt/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: O que é o AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# O que é o AnsibleForms
+{: .no_toc }
+
+Formulários self-service à frente do Ansible e do AWX, e quando precisa deles
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O que faz
+
+O AnsibleForms coloca um formulário web à frente de um playbook, de um workflow, ou de um template ou job no AWX, AAP, Ascender, Semaphore, Rundeck
+ou Jenkins, para que as pessoas possam executar automação sem a linha de comandos.
+
+Um formulário recolhe os dados, verifica-os, transforma-os em extravars e lança a tarefa. Os dados de um formulário podem vir de bases de dados,
+APIs REST, ficheiros e outros campos, e cada lançamento fica registado no histórico de tarefas com a sua saída.
+
+---
+
+## Utilizações típicas
+
+As equipas usam o AnsibleForms para entregar a automação de rotina às pessoas que a pedem:
+
+* **Pedidos self-service** : uma máquina virtual, um volume de armazenamento, uma partilha ou uma conta de utilizador, preenchidos por quem os pede
+* **Operações protegidas** : ações com pontos de aprovação, para que uma segunda pessoa dê o aval antes de a tarefa ser executada
+* **Escolhas orientadas por dados** : listas pendentes preenchidas a partir de uma CMDB, de uma base de dados ou de uma API REST, encadeadas de um campo para o seguinte
+* **Tarefas recorrentes** : formulários executados mais tarde ou num agendamento cron, sempre com os mesmos dados validados
+* **Automação para ferramentas e agentes** : a API REST, o servidor MCP e o assistente de chat lançam os mesmos formulários
+
+---
+
+## AnsibleForms ou surveys do AWX?
+
+O AWX, o AAP e o Ascender têm surveys próprios. Qual se adequa depende do que as pessoas que lançam as tarefas precisam.
+
+Um **survey** é suficiente quando:
+
+* as perguntas são fixas: texto, números, palavras-passe e opções de uma lista estática
+* os utilizadores já trabalham no AWX, AAP ou Ascender, e as suas permissões servem-lhes
+* não quer executar e manter outra aplicação e outra base de dados
+
+O **AnsibleForms** ajuda quando:
+
+* as opções vêm de outro sítio: uma base de dados, uma API REST, um ficheiro ou outro campo (listas pendentes encadeadas)
+* os dados precisam de validação, de estrutura (listas, objetos aninhados) ou de valores calculados antes de chegarem ao playbook
+* as tarefas precisam de pontos de aprovação, de agendamento ou de um workflow que encadeie playbooks, templates e aprovações a partir de um formulário
+* os utilizadores não devem ver o AWX de todo, ou também executa playbooks sem o AWX
+
+O AnsibleForms lança templates do AWX, AAP e Ascender, por isso os dois funcionam em conjunto: os formulários recolhem e moldam os dados, e
+o AWX continua a executar as tarefas.
+
+---
+
+## Por onde continuar
+
+O resto desta secção explica as peças antes de instalar:
+
+| Página | O que abrange |
+|---|---|
+| [Como funciona](how-it-works.html) | A arquitetura, os passos de um lançamento e onde os dados são guardados |
+| [Visita à interface](gui/) | Capturas de ecrã de todos os ecrãs, desde o início de sessão até às páginas de administração |
+| [Conceitos](concepts.html) | Os termos usados ao longo desta documentação |
+| [Pré-requisitos](prerequisites.html) | O que precisa antes de instalar |
diff --git a/i18n/pt/_reference/faq.md b/i18n/pt/_reference/faq.md
new file mode 100644
index 0000000..bd92a9c
--- /dev/null
+++ b/i18n/pt/_reference/faq.md
@@ -0,0 +1,1278 @@
+---
+layout: default
+title: FAQ
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# Perguntas frequentes
+{: .no_toc }
+
+Perguntas e respostas comuns sobre o AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Primeiros passos
+
+### Topologia da implementação: um contentor ou vários nós
+
+Por predefinição, um contentor AnsibleForms executa a aplicação web e o trabalho em segundo plano num único processo, ao lado de um contentor RTE que
+executa os playbooks. Execute-o com uma política de reinício (por exemplo `restart: unless-stopped` no Docker), e faça cópias de segurança tanto da base de dados como
+do volume persistente.
+
+Para executar várias réplicas por trás de um balanceador de carga, divida o processo com `AF_ROLE`:
+
+- os nós `app` servem a interface web e a API: execute quantos quiser, cada um com o mesmo `ACCESS_TOKEN_SECRET`
+- um `worker` executa o trabalho em segundo plano: o esquema e as suas atualizações, o config seed, os agendamentos, a cópia de segurança noturna, as sincronizações
+  dos repositórios e as limpezas. Trabalha um worker de cada vez, que detém um bloqueio na base de dados; um segundo espera e assume quando o primeiro para
+- os contentores `rte` executam os playbooks: execute mais para executar mais playbooks em simultâneo
+
+Os nós da aplicação e o worker partilham a base de dados, o volume persistente e o `ENCRYPTION_SECRET`. Um RTE num modo socket (outbound ou
+inbound, consulte [Modos](rte/modes.html)) não precisa nem da base de dados nem do `ENCRYPTION_SECRET`. O assistente de chat precisa de sessões persistentes (sticky sessions), e
+cada nó mantém o seu próprio registo. Consulte [Escalar](production/scaling.html) e a configuração
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale).
+
+### Gestão de formulários em vários repositórios
+
+Os formulários de todos os repositórios Git com **Usar para formulários ?** ativado são juntados automaticamente; em caso de nomes de formulários duplicados, o primeiro
+ganha e é registado um aviso. Mantenha o `config.yaml` num único repositório. Consulte [Repositórios git](repositories/).
+
+### Sobre os repositórios
+
+O AnsibleForms clona e atualiza repositórios Git no caminho dos repositórios (`REPO_PATH`), geridos em **Definições > Repositórios**.
+Os interruptores de cada repositório definem o que ele contém: configuração, formulários, playbooks ou ficheiros de variáveis. Consulte [Repositórios git](repositories/).
+
+### Validação no VS Code para ficheiros de formulários
+
+Adicione um cabeçalho de esquema aos seus ficheiros YAML de formulários para obter validação em direto e preenchimento automático no VS Code.
+
+Instale a [extensão YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) e adicione este comentário como **primeira linha** de qualquer ficheiro de formulário:
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+Isto funciona tanto para ficheiros com um único formulário (um dicionário YAML) como para ficheiros com vários formulários (uma lista YAML):
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+O VS Code realça as propriedades desconhecidas, os campos obrigatórios em falta e os tipos incorretos à medida que escreve.
+
+---
+
+## Gestão de tarefas
+
+### Relançar uma tarefa com os dados preenchidos
+
+O botão de relançar abre o formulário preenchido com os valores da tarefa anterior; os campos de palavra-passe nunca são guardados.
+Exige a opção de função `allowJobRelaunch`, e um formulário pode desativá-lo com `allowRelaunch: false`. Consulte [Relançar uma tarefa](jobs/actions.html#relaunch-a-job).
+
+### Ficheiro de registo da tarefa
+
+Acompanhe o progresso através de um ficheiro de registo específico da tarefa (v6.1.2).
+
+O AnsibleForms pode mostrar um **ficheiro de registo específico da tarefa** ao lado da saída do Ansible. Isto permite acompanhar o progresso de módulos personalizados de longa duração que, de outra forma, não dariam nenhum retorno visível durante a execução.
+
+{: .note }
+> Esta funcionalidade só funciona para playbooks executados num RTE. Os templates e jobs no AWX, AAP, Ascender, Semaphore, Rundeck ou
+> Jenkins não têm ficheiro de registo.
+
+**Como funciona:**
+- Durante a execução de uma tarefa, o RTE vigia um ficheiro de registo num caminho conhecido dentro da pasta do playbook
+- A cada dois segundos, quando o ficheiro mudou, o RTE copia o seu conteúdo para a tarefa, e uma vez mais quando o playbook termina
+- O ficheiro de registo é mostrado numa secção **Arquivo de log** da saída da tarefa, numerado como as linhas da saída: a data e hora e o nível de uma linha do registo (ERROR, WARNING, INFO, DEBUG) são lidos e coloridos como na saída, e as cores ANSI são suportadas
+
+**Convenção do caminho do ficheiro de registo:**
+
+O ficheiro de registo tem de ser escrito neste caminho:
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**O AnsibleForms passa `__jobid__` automaticamente**, por isso pode montar o caminho no seu playbook sem qualquer configuração adicional:
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+Passe esta variável a qualquer role ou módulo personalizado que deva escrever o progresso no ficheiro.
+
+**Responsabilidades de quem desenvolve o playbook / módulo:**
+- **Criar** o ficheiro de registo (e o seu diretório `.joblogs/`) no início da operação
+- **Escrever** mensagens de progresso com significado à medida que a operação avança
+
+O RTE elimina o ficheiro assim que o playbook termina e o último conteúdo fica guardado na tarefa.
+
+**A codificação de cores ANSI é suportada.**  
+Os códigos de escape ANSI padrão (por exemplo, `\033[92m` para verde e `\033[91m` para vermelho) nas suas mensagens de registo são apresentados como cores na interface, para que os estados de sucesso, aviso e erro se distingam num relance.
+
+**Caso de utilização típico:**  
+Um módulo Ansible personalizado em Python que executa uma longa sequência de chamadas à API ou de operações sobre dados (por exemplo, um workflow de DR com SnapMirror) pode acrescentar uma linha por passo ao ficheiro de registo. Um operador que acompanhe a tarefa no AnsibleForms vê então o progresso em direto na secção Arquivo de log, à medida que a página da tarefa a acompanha.
+
+### Jobid
+
+Passe o ID da tarefa atual.
+
+O AnsibleForms envia automaticamente o ID da tarefa atual nas extravars como `__jobid__`; não é necessária nenhuma configuração.
+
+### Informação do utilizador
+
+Passe o utilizador atual.
+
+O AnsibleForms envia automaticamente a informação do utilizador nas extravars como `ansibleforms_user`; não é necessária nenhuma configuração.
+
+Pode escolher quanta informação é enviada. `EXTRAVARS_USER_FIELDS` aceita uma lista de chaves de nível superior separadas por vírgulas
+(`username,email,type`), ou `none` para não enviar nada; um formulário pode substituí-la com a sua própria propriedade `userExtravars`.
+A predefinição é o objeto completo, como antes. O `__user__` do lado do formulário, descrito abaixo, vem do token de início de sessão e nunca é afetado.
+
+### Informação do utilizador no formulário
+
+Aceda à informação do utilizador atual no formulário (v4.0.2).
+
+O campo `__user__` é adicionado automaticamente ao formulário e pode ser referenciado nas expressões:
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## Campos de formulário
+
+### Listas pendentes encadeadas
+
+Crie listas pendentes encadeadas.
+
+Os campos `enum` (listas pendentes) podem conter placeholders na sua propriedade `query` ou `expression`, no formato `$(another_field)` ou `$(another_field[0].name)`.  
+Assim que o campo referenciado muda, o campo que o referencia é avaliado novamente, o que resulta em listas pendentes dinâmicas e encadeadas.  
+A aplicação web do cliente reavalia os campos a cada 100 ms; com os processadores atuais e o motor Chromium, a experiência é fluida.
+
+{: .note }
+> Uma referência a outro campo enum devolve os valores selecionados, **e não** a lista pendente completa. Use a propriedade `placeholderColumn` ou a notação de ponto, como `$(city.name)`.  
+> **Novo na v4.0.20**: definir placeholderColumn como "*" devolve o registo completo em vez de uma única coluna.
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### Placeholders de campos
+
+Referencie o valor de outro campo.
+
+Os placeholders são referências a outros campos do formulário.  
+Um placeholder tem sempre o formato `$(reference)`, e tanto as expressões como as consultas podem conter placeholders.  
+Um placeholder que aponta para um campo simples (text, number, password) contém o valor desse campo.  
+Um placeholder que aponta para um campo enum baseado em objetos tem de usar a propriedade `placeholderColumn` ou a notação de ponto, como `$(city.name)`.  
+Um placeholder que aponta para um campo de expressão devolve o objeto completo, ou pode usar uma referência avançada, ao estilo de JavaScript, como `$(myarray[0].name)`.
+
+{: .important }
+> O placeholder é substituído **antes** de a expressão ser avaliada. Se espera que o resultado seja uma string, tem de o envolver em aspas.  
+> **Novo na v4.0.20**: definir placeholderColumn como "*" devolve o registo completo em vez de uma única coluna.
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### Ocultar um campo
+
+Oculte um campo.
+
+Oculte um campo com a propriedade de campo `hide`, ou mostre-o e oculte-o dinamicamente com as propriedades de campo `dependencies` e `dependencyFn`.
+
+### Agrupar campos
+
+Agrupe campos num bloco.
+
+Use a propriedade de campo `group`. Os campos com o mesmo nome de grupo ficam agrupados num bloco.
+
+### Validação de campos
+
+Valide um campo.
+
+Use as propriedades de validação do campo, como `regex`, `minValue` e `notIn`.
+
+### Valor predefinido num enum
+
+Valor predefinido de um enum.
+
+A propriedade de campo `default` define um valor predefinido, e nos campos `enum` pode usar valores como `__auto__` para selecionar automaticamente o primeiro item.
+
+Para uma predefinição dinâmica baseada numa expressão, mova o item predefinido para o topo da lista, como no exemplo seguinte.
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### Valor predefinido com uma expressão
+
+Valor predefinido a partir de uma expressão.
+
+Para campos de texto, número ou data, a propriedade `default` define um valor predefinido estático.
+
+Para tornar a predefinição dinâmica, baseada numa expressão, use uma de duas propriedades:
+* `editable`: use a propriedade editable para tornar editável um campo de expressão
+* `evalDefault`: use a propriedade evalDefault para avaliar a predefinição como uma expressão
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## Wizard e workflows
+
+### Qual é a diferença entre um wizard e um workflow?
+
+Um **wizard** e um **workflow** funcionam ambos por passos, mas atuam em camadas diferentes e podem ser combinados.
+
+| | [`workflow`](forms/workflow.html) (Workflow) | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **Camada** | Execução | Formulário / interface |
+| **O que divide** | A tarefa em nós que correm uns a seguir aos outros, ou lado a lado | Os dados de um formulário em várias páginas |
+| **Resultado** | 1 tarefa de workflow, com uma tarefa por nó (cada uma com o seu próprio playbook ou template) | 1 tarefa é executada no fim |
+| **`type` do formulário** | Tem de ser `workflow` | Funciona com todos os tipos de formulário exceto `subform` |
+| **Definido por** | Um [ficheiro de workflow](workflows/file.html) do designer (`workflow:`) | Uma lista de referências a [subforms](forms/subform.html) (`wizard:`) |
+| **Use-o quando** | "Faz A, depois B, depois C como tarefas separadas" | "O meu formulário tem demasiados campos para uma página" |
+
+**Ideia principal:** um workflow trata de *o que é executado e por que ordem*; `wizard` trata de *como o utilizador preenche o formulário*.
+
+{: .note }
+> O tipo de formulário `multistep`, com os seus `steps`, fazia a parte da execução antes da 7. Está descontinuado desde a 7 e é removido na
+> 8: um workflow faz tudo o que um multistep faz, consulte [Formulários multistep](forms/multistep.html).
+
+#### Só workflow
+{: .no_toc }
+
+Um formulário `type: workflow` executa um dos workflows do designer. O utilizador preenche uma única página de campos e carrega em Submeter,
+e o workflow executa os seus nós, cada um com os valores do formulário como extra vars:
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### Só wizard
+{: .no_toc }
+
+Um bloco `wizard:` num formulário distribui a recolha de dados por várias páginas. Só **uma** tarefa é executada no fim: as extravars juntadas de todas as páginas são enviadas para um único playbook, template ou workflow.
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+Uma página de revisão só de leitura é acrescentada automaticamente como última página do wizard; não a declara no YAML.
+
+#### Combinados (wizard sobre um workflow)
+{: .no_toc }
+
+Um wizard pode ser colocado por cima de um formulário de workflow. O utilizador preenche as páginas do wizard e carrega em Submeter, e **só então** o
+workflow começa. Fazendo corresponder o `defaultModel` de um passo do wizard com o
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) de um nó, pode encaminhar **uma página do wizard para um nó**:
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+E o workflow `provision-host`, num ficheiro de workflow do designer:
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` é uma procura de um só nível, por isso use um nome simples em `defaultModel` (por exemplo, `defaultModel: basics`, e não `defaultModel: input.basics`) quando quiser que correspondam.
+
+Consulte a [página Wizard](forms/wizard.html) para a referência completa das propriedades.
+
+### Como mostro ou salto passos do wizard consoante uma condição?
+
+Use `when:` para **ocultar** um passo por completo, ou `optional: true` para deixar o utilizador **saltar** um passo visível. Os dois são independentes e, em geral, não devem ser combinados.
+
+#### `when:`: visibilidade condicional
+{: .no_toc }
+
+O passo fica oculto quando a expressão dá um valor falso. O utilizador nunca o vê, e os seus valores não são recolhidos. A expressão pode ler os passos anteriores através de `__parent__.<stepname>.<field>`:
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+Só é mostrada a página que corresponde ao `kind` escolhido. Os passos a seguir a um oculto são renumerados automaticamente.
+
+#### `optional: true`: permitir saltar um passo visível
+{: .no_toc }
+
+O passo é **sempre mostrado** no indicador de passos, mas o utilizador pode carregar em **Seguinte** sem o preencher, e **Submeter** é permitido mesmo que a página nunca tenha sido visitada ou concluída:
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+O utilizador pode abrir a página Advanced, deixá-la vazia, carregar em Seguinte e passar diretamente para a página de revisão.
+
+{: .note }
+> `when:` controla a *visibilidade*; `optional:` controla *se a página tem de ser concluída*. Não os combine: para fazer desaparecer uma página, use `when:`; para a manter visível mas dispensável, use `optional:`.
+
+### Como faço referência a valores de um passo anterior do wizard?
+
+Use `$(__parent__.<stepname>.<field>)` dentro de qualquer campo de um passo posterior.
+
+O `name` de um passo do wizard (por predefinição o nome do seu `subform`) é o espaço de nomes sob o qual os seus valores são expostos aos passos seguintes:
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+É o mesmo mecanismo `__parent__` que os subforms de `list` e `yaml` usam; consulte [Como acedo aos dados do formulário pai dentro de um subform?](#how-do-i-access-parent-form-data-inside-a-subform).
+
+---
+
+## Segurança e credenciais
+
+### Credenciais
+
+Passe credenciais.
+
+As credenciais podem ser passadas de várias formas:
+* usando a propriedade de campo `asCredential`  
+* usando a propriedade de formulário `credentials` (pares chave-valor)
+* usando uma extravar chamada `__credentials__`
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### Recuperar uma palavra-passe de administrador perdida
+
+Se perdeu a palavra-passe da conta local `admin` e não há outro utilizador administrador disponível, use a opção de recuperação `REINIT_ADMIN`. **Isto não é um bypass da autenticação em tempo de execução**: apenas força uma reposição única da conta de administrador local no arranque, após a qual a autenticação normal continua.
+
+**Como funciona**
+
+Quando `REINIT_ADMIN=1` está definido no arranque, o AnsibleForms:
+
+1. Garante que o grupo `admins` existe (criando-o se faltar).
+2. Procura o utilizador administrador local (nome de utilizador predefinido `admin`, substituído por `ADMIN_USERNAME`).
+3. Se existir, repõe a sua palavra-passe com o valor de `ADMIN_PASSWORD` e volta a associá-lo ao grupo `admins`.
+4. Se não existir, cria-o (como numa instalação nova).
+5. Regista a ação de forma bem visível para que apareça nos registos.
+
+**Passos**
+
+1. Pare o AnsibleForms.
+2. Defina as variáveis de ambiente (use uma palavra-passe forte):
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   No Docker Compose, adicione-as ao bloco `environment:` do serviço do AnsibleForms.
+3. Inicie o AnsibleForms e procure nos registos uma linha como:
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. Inicie sessão com `admin` / `YourNewStrongPasswordHere`.
+5. **Remova `REINIT_ADMIN` (ou volte a defini-la como `0`)** e reinicie, para que os reinícios futuros não voltem a repor a palavra-passe do administrador.
+
+**Notas**
+
+- Se ficou sem acesso porque o LDAP era o único método de início de sessão configurado e falhou, a conta local `admin` recuperada recorre sempre à autenticação pela base de dados local, o que basta para iniciar sessão e corrigir o LDAP.
+- A antiga variável de ambiente `ENABLE_BYPASS` foi removida. Permitia iniciar sessão como admin com qualquer palavra-passe e não era seguro deixá-la ativada. `REINIT_ADMIN` apenas repõe a palavra-passe; a autenticação normal aplica-se depois.
+- `REINIT_ADMIN` não invalida as sessões nem os tokens existentes; só mudam o hash da palavra-passe e a pertença ao grupo.
+
+### Restringir os destinos dos auxiliares REST (listas de permissão e de bloqueio)
+
+Os auxiliares `fn.fnRestBasic`, `fn.fnRestAdvanced`, `fn.fnRestJwt` e `fn.fnRestJwtSecure` podem ser chamados a partir das propriedades `expression` dos formulários para obter dados por HTTP. Por predefinição, quem escreve as expressões pode apontar para **qualquer** URL que o host do AnsibleForms consiga alcançar, o que pode querer limitar numa rede sensível.
+
+Duas variáveis de ambiente fornecem uma lista de permissão e uma lista de bloqueio:
+
+| Variável | Comportamento |
+|---|---|
+| `REST_ALLOWED_HOSTS` | Nomes de host ou CIDRs separados por vírgulas. Quando definida, **só** estes destinos são permitidos. |
+| `REST_DENIED_HOSTS` | Nomes de host ou CIDRs separados por vírgulas. Sempre bloqueados. Tem precedência sobre a lista de permissão. |
+
+Os nomes de host são comparados com o host do URL sem distinguir maiúsculas de minúsculas. Os CIDRs são comparados com todos os IPs para que o host resolve, por isso `10.0.0.0/8` bloqueia qualquer nome DNS que resolva para o intervalo privado.
+
+**Exemplos:**
+
+A primeira linha permite apenas dois hosts; a segunda bloqueia destinos específicos:
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **Esta proteção só protege o processo Node.js do AnsibleForms.** Assim que um playbook é executado, o próprio Ansible pode chegar a qualquer coisa a partir do host, fora do controlo do AnsibleForms. Use estas listas para impedir que quem escreve formulários transforme as expressões num proxy para serviços de metadados ou interfaces internas; não conte com elas como firewall de rede.
+
+Desde a 7.3.0 os auxiliares REST verificam o certificado TLS do endpoint, tal como todas as outras ligações, e desistem ao fim de
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS) (`60` por predefinição). Confie numa CA privada com
+`NODE_EXTRA_CA_CERTS`, ou defina [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) como `1` apenas para endpoints com um
+certificado autoassinado.
+
+### Integração com o HashiCorp Vault
+
+As credenciais podem ler o seu utilizador e a sua palavra-passe a partir do HashiCorp Vault, configurado como
+**cofre de segredos**. Consulte [Cofres de segredos](secret-stores). As variáveis de ambiente `VAULT_*`
+das versões anteriores são importadas uma vez como o cofre `vault` no primeiro arranque da 7.x.
+
+Para segredos usados apenas dentro de um playbook, também pode usar o plugin de lookup `community.hashi_vault`,
+que lê diretamente do Vault e contorna o AnsibleForms.
+
+---
+
+## Integração
+
+### Consultar o AWX/Tower/AAP
+
+Consulte informação do AWX ou do Ansible Automation Platform.
+
+Para preencher listas pendentes com dados do AWX ou do Tower, use `fn.fnRestBasic` ou `fn.fnRestJwtSecure`. Desde a 7.3.0 estes auxiliares verificam
+o certificado do endereço do AWX: com um autoassinado, confie na sua CA com `NODE_EXTRA_CA_CERTS`, ou defina
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) como `1`.
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## Personalização
+
+### Personalização
+
+Personalize o AnsibleForms.
+
+O AnsibleForms é uma aplicação web. Quando o executa de forma nativa em Node.js, pode substituir ou alterar os seus ficheiros.  
+A abordagem recomendada, no entanto, é executá-lo como imagem Docker e adicionar mapeamentos de volumes ou de ficheiros. Os projetos Docker Compose já mapeiam diretórios para manter persistentes a base de dados, os playbooks, os registos, os certificados e as chaves SSH, e pode adicionar mais mapeamentos. Um logótipo personalizado é carregado na página de definições **Logótipo**.  
+O ficheiro `custom.js` contém as suas próprias funções JavaScript para usar nas expressões. As funções incorporadas usam o prefixo `fn.` (por exemplo, fn.fnRestBasic); as funções personalizadas usam o prefixo `fnc.`.  
+Da mesma forma, pode adicionar as suas próprias definições jq no ficheiro `jq.custom.definitions`.
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### Ativar o YTT
+
+Ative o ytt.
+
+Para usar o ytt, defina `USE_YTT=1`.  
+Para mais informação sobre o ytt, consulte https://carvel.dev/ytt/.
+
+{: .important }  
+> Esta funcionalidade não foi testada de forma extensiva, e não foi recebido nenhum feedback desde que foi adicionada como melhoria.  
+> Ao usar o ytt, tem de desativar o designer: o designer converte os ficheiros YAML em JSON intermédio e descarta a sintaxe do ytt (que consiste em comentários YAML).
+
+Tem de existir um diretório `lib` no diretório raiz; é incluído automaticamente na chamada ao ytt.
+Os dados podem ser fornecidos globalmente definindo variáveis de ambiente com prefixo:  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+Em alternativa, forneça ficheiros de dados de bibliotecas:
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**A biblioteca `demo` tem de existir no contexto do ytt (lib/_ytt_lib/demo/values.yml)**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+Os dados carregados podem então ser usados:
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## Controlo de acesso
+
+### Como restrinjo o que os utilizadores podem fazer (opções de função)?
+
+Para além de restringir que formulários uma função pode ver, as `options` de uma função ativam ou desativam funcionalidades da interface para os seus membros.
+Consulte [Opções de função](config/roles.html#role-options) para conhecer cada opção, a sua predefinição e a forma como as opções se combinam entre funções.
+
+### Como implemento uma lógica RBAC própria nos meus playbooks ou formulários?
+
+A identidade do utilizador está disponível tanto no frontend como no backend em cada execução.
+
+Em cada submissão de um formulário, o AnsibleForms injeta automaticamente a identidade completa do utilizador atual nas extravars enviadas ao Ansible:
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+O seu playbook ou qualquer módulo Ansible personalizado pode portanto usar `ansibleforms_user` diretamente para decisões detalhadas, por exemplo para permitir apenas a certos grupos alterar o inventário de produção, ou para escrever um registo de auditoria com o nome de utilizador de quem submeteu.
+
+No **frontend**, o mesmo objeto está disponível através do campo especial `__user__`:
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**Padrões típicos:**
+
+A identidade do utilizador suporta padrões como os seguintes:
+
+- **Cruzar com um ficheiro de configuração ou uma base de dados de RBAC**: carregue um ficheiro YAML ou JSON (com `fn.fnReadYamlFile` ou uma expressão) que associe grupos aos recursos permitidos, e depois filtre por `$(__user__.groups)`
+- **Registo de auditoria**: passe `ansibleforms_user.username` como variável extra para registar quem desencadeou a tarefa
+- **Valores de campos dinâmicos**: mostre um conjunto diferente de opções de enum, preencha campos, ou oculte secções com base nos grupos ou funções do utilizador
+- **Autorização do lado do playbook**: verifique que `ansibleforms_user.groups` contém um grupo obrigatório antes de o playbook continuar, como verificação de defesa em profundidade independente da lista `roles` do formulário
+
+{: .note }
+> O objeto acima é o que é enviado por predefinição. Se a instância definir `EXTRAVARS_USER_FIELDS`,
+> ou o formulário definir `userExtravars`, só são enviadas as chaves aí indicadas, por isso um playbook que
+> verifica `ansibleforms_user.groups` exige que `groups` seja uma delas. O campo `__user__` do
+> frontend vem do token de início de sessão e nunca é reduzido por nenhuma das definições.
+
+---
+
+## Agendamento de tarefas
+
+### Como agendo um formulário para ser executado automaticamente?
+
+Abra a lista pendente ao lado de **Submeter** e escolha **Agendar (recorrente)** ou **Executar mais tarde (única)**; exigem as opções de função
+`allowScheduledJobs` (nível de administrador) e `allowPlannedJobs`. Consulte [Agendamentos](jobs/schedules.html).
+
+### Que expressões cron posso usar?
+
+Um agendamento recorrente aceita uma expressão cron padrão de 5 campos (minuto, hora, dia do mês, mês, dia da semana).
+
+| Expressão | Executa |
+|---|---|
+| `*/15 * * * *` | A cada 15 minutos |
+| `0 * * * *` | A cada hora, à hora certa |
+| `0 */6 * * *` | A cada 6 horas, às 00:00, 06:00, 12:00 e 18:00 |
+| `0 2 * * *` | Todos os dias às 02:00 |
+| `30 7 * * 1-5` | De segunda a sexta-feira às 07:30 |
+| `0 8 * * MON` | Todas as segundas-feiras às 08:00 (são aceites nomes de dias e de meses) |
+| `0 0 1 * *` | À meia-noite do primeiro dia de cada mês |
+| `0 22 L * *` | Às 22:00 do último dia de cada mês |
+| `0 6 * * 1#1` | Às 06:00 da primeira segunda-feira de cada mês |
+| `*/30 * * * * *` | A cada 30 segundos (um sexto campo opcional à frente corresponde aos segundos) |
+
+Quando tanto o dia do mês como o dia da semana estão definidos, o agendamento é executado quando qualquer um deles corresponde: `0 0 13 * 5` é executado
+no dia 13 e em todas as sextas-feiras. O servidor recusa uma expressão que não consegue executar, ou uma que nunca pode ocorrer (`0 0 30 2 *`).
+
+Na página **Agendamentos**, o editor de cron descreve a expressão e pré-visualiza as suas próximas execuções. Não aceita alcunhas
+como `@daily`, o caráter universal `?` nem o modificador `W` (dia útil mais próximo), por isso mantenha-se nas formas da tabela.
+
+{: .note }
+> **Fuso horário** Os agendamentos cron são executados no fuso horário do servidor, definido com [`LOG_TZ`](customization/logging.html#env_LOG_TZ)
+> (predefinição `UTC`), e não no fuso horário do seu perfil ou do seu navegador. `0 2 * * *` com `LOG_TZ=Europe/Madrid` é executado às 02:00
+> hora de Madrid durante todo o ano, acompanhando a hora de verão. O editor de cron pré-visualiza as próximas execuções nesse mesmo fuso. Os agendamentos de
+> pull dos repositórios usam o mesmo fuso.
+
+---
+
+## Guardar e carregar dados de formulários
+
+### Como guardo e volto a carregar os dados de um formulário sem executar uma tarefa?
+
+Selecione **Guardar** na lista pendente ao lado de **Submeter** para guardar os valores dos campos, e depois **Carregar dos guardados** para os restaurar mais tarde.
+Os campos de palavra-passe nunca são guardados. Exige a opção de função `allowStoredJobs`. Consulte [Tarefas guardadas](jobs/stored-jobs.html).
+
+---
+
+## Formulários aninhados e campos estruturados
+
+### Como recolho dados estruturados ou repetidos num formulário?
+
+Use campos `list` e `yaml` com subforms (6.2.0+).
+
+Para recolher dados estruturados complexos, como uma lista de servidores, um conjunto de interfaces de rede ou um único objeto aninhado, use o tipo de campo `list` ou `yaml` em conjunto com um `subform`.
+
+Um **subform** é um fragmento de formulário reutilizável (definido com `type: subform`) que nunca é mostrado como mosaico autónomo. Existe apenas para ser referenciado por campos de outros formulários. Consulte a [documentação de Subform](forms/subform.html) para a referência completa.
+
+**Recolher uma lista de linhas estruturadas: campo `list`:**
+
+Um campo `list` abre o subform referenciado uma vez por linha:
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+A extravar `servers` enviada ao Ansible é um array de objetos: `[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**Editar um único objeto estruturado: campo `yaml`:**
+
+O campo `yaml` tem três modos:
+
+| Modo | Como | Comportamento |
+|---|---|---|
+| **Editor** | predefinido | Mostra um editor YAML completo com realce de sintaxe, onde o utilizador pode escrever diretamente |
+| **Só de leitura** | `readonly: true` | Apresenta o valor YAML como texto formatado só de leitura, sem edição |
+| **Subform** | `subform: MySubform` | Oculta o editor em bruto; abre o subform como editor de detalhe ao clicar |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**Carregar e transferir: campos `list` e `yaml`:**
+
+Os dois tipos de campo suportam a transferência de ficheiros do lado do cliente através de duas propriedades opcionais:
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> O campo `list` e o tipo de formulário `subform` substituíram o campo `table` e `tableFields`, que foram removidos na 7.0.0.
+
+### Como acedo aos dados do formulário pai dentro de um subform?
+
+Referencie os valores dos campos do pai a partir de um subform através de `__parent__` (v6.3.0+).
+
+Quando um subform abre, seja a partir de um campo **`list`** (o editor de cada linha) ou de um campo **`yaml`** em modo subform, o AnsibleForms injeta automaticamente no subform um campo especial só de leitura chamado `__parent__`. Contém uma fotografia de **todos os valores dos campos do formulário pai no momento em que o subform foi aberto**, incluindo constantes e vars.
+
+Isto permite que os campos do subform usem expressões que referenciam dados do pai sem qualquer configuração adicional.
+
+#### O que há em `__parent__`?
+{: .no_toc }
+
+`__parent__` é um objeto simples cujas chaves são os nomes dos campos do formulário pai:
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` **não é enviado ao Ansible**; tal como `__user__`, é retirado das extravars. É apenas um auxiliar do frontend para as expressões dentro dos subforms.
+
+#### Aceder aos valores do pai nas expressões de um subform
+{: .no_toc }
+
+Referencie os valores do pai com a sintaxe de expressão padrão `$(...)`:
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### Subforms aninhados
+{: .no_toc }
+
+`__parent__` refere-se sempre ao formulário **pai imediato**. Se aninhar uma `list` dentro de um subform que é ele próprio aberto a partir de um formulário pai, o `__parent__` do subform interior contém os dados do subform do meio. Para chegar a níveis mais acima, encadeie referências como `$(__parent__.__parent__.someField)`, se o subform do meio também propagar o seu próprio `__parent__`.
+
+### Como migro de `table` / `tableFields` para `list` / `subform`?
+
+O campo `table` e a propriedade `tableFields` foram descontinuados na 6.2.0 e removidos na 7.0.0, e um formulário que ainda os use falha a validação. Para migrar:
+
+1. Extraia as colunas de `tableFields` para um novo formulário `type: subform` com `formfields` normais
+2. Substitua o campo `table` por um campo `list` que referencie o subform através de `subform: MySubformName`
+
+**Antes:**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**Depois:**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### Migrar `from` de `tableFields` para expressões com `__parent__`
+{: .no_toc }
+
+A propriedade `from` das colunas enum de `tableFields` preenchia as opções das listas pendentes a partir de outro campo do formulário pai. Num `subform`, é substituída por uma `expression` que lê o mesmo valor através de `__parent__`.
+
+**Antes: `tableFields` com `from`:**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**Depois: subform com uma expressão `__parent__`:**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` devolve o **valor atual** desse campo, por isso, se esse campo for ele próprio um campo de expressão dinâmico, o subform vê sempre o resultado mais recente avaliado no pai.
diff --git a/i18n/pt/_reference/getting-help.md b/i18n/pt/_reference/getting-help.md
new file mode 100644
index 0000000..953ed1d
--- /dev/null
+++ b/i18n/pt/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: Obter ajuda
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# Obter ajuda
+{: .no_toc }
+
+Onde fazer uma pergunta, comunicar um erro ou um problema de segurança, e sugerir uma melhoria
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Antes de perguntar
+
+A maior parte das respostas já está escrita; uma pesquisa rápida poupa muitas vezes uma ida e volta:
+
+1. Pesquise neste site com a caixa de pesquisa no topo de cada página.
+2. Procure a mensagem de erro exata em [Resolução de problemas](troubleshooting.html), e dê uma vista de olhos às [FAQ](faq.html).
+3. Verifique o registo do servidor (**Definições** e depois **Registo do servidor**) e a página **Estado**, que indicam a maior parte dos problemas de configuração.
+4. Verifique o [Registo de alterações](changelog.html): o problema pode já estar corrigido numa versão mais recente.
+
+---
+
+## Onde ir
+
+Cada tipo de pedido tem o seu próprio sítio, todos no GitHub:
+
+| Pretende | Vá a |
+|---|---|
+| Fazer uma pergunta ou partilhar uma ideia | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| Comunicar um erro | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Sugerir uma funcionalidade | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| Comunicar um problema de segurança | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), em privado |
+| Corrigir ou melhorar esta documentação | **Editar esta página no GitHub** no fundo de qualquer página, ou uma [issue no site](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## Comunicar um erro
+
+Um relatório que possa ser reproduzido é corrigido mais depressa. O modelo de relatório de erro pede o seguinte:
+
+* **Versão** : mostrada em **Acerca de** no menu de ajuda (**?**) da barra superior
+* **Implementação** : Docker, Docker Compose, Kubernetes, o instalador (e o seu motor), uma instalação nativa ou a partir do código-fonte
+* **Passos para reproduzir** : o que fez, o que esperava e o que aconteceu em vez disso
+* **Evidências** : as linhas relevantes do registo do servidor, e uma captura de ecrã quando o problema é visível
+
+Para um problema com um formulário, inclua uma definição de formulário mínima que o mostre. Retire as palavras-passe, os tokens, os nomes de hosts e quaisquer
+outros dados privados dos registos e dos formulários antes de os publicar: as issues e as discussões são públicas.
+
+---
+
+## Comunicar um problema de segurança
+
+**Nunca abra uma issue pública para isso:** use [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new), que só os maintainers veem.
+
+A [política de segurança](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) lista as versões suportadas e
+o que acontece depois de comunicar.
diff --git a/i18n/pt/_reference/troubleshooting.md b/i18n/pt/_reference/troubleshooting.md
new file mode 100644
index 0000000..09538cb
--- /dev/null
+++ b/i18n/pt/_reference/troubleshooting.md
@@ -0,0 +1,760 @@
+---
+layout: default
+title: Resolução de problemas
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# Resolução de problemas
+{: .no_toc }
+
+Mensagens de erro e sintomas, porque acontecem e como os corrigir
+{: .fs-6 .fw-300 }
+
+---
+
+Cada problema abaixo tem como título a mensagem ou o sintoma que vê, seguido da causa e da correção. As mensagens são citadas
+exatamente como o AnsibleForms as escreve; `<name>` representa um valor que muda de caso para caso. A maior parte delas aparece no registo
+do servidor, que pode ler em [Registo do servidor](gui/administration.html#server-log) ou com `docker logs`.
+
+**Base de dados e arranque**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**Configuração e formulários**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [A configuração base tem uma secção forms](#the-base-config-has-a-forms-section)
+* [Falta um formulário no painel](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**Início de sessão**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Falha na autenticação Azure AD ou OIDC](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [Sessão terminada depois de um reinício ou ao fim de um dia](#logged-out-after-a-restart-or-after-a-day)
+* [Formulários e tarefas vazios depois de um início de sessão único (HTTP 431)](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**Tarefas**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [Uma tarefa mostra o estado abandoned](#a-job-shows-the-status-abandoned)
+* [Um RTE não se liga](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Repositórios git e cópias de segurança**
+
+* [Falha ao clonar ou fazer pull de um repositório](#a-repository-clone-or-pull-failed)
+* [O repositório de formulários ainda não foi clonado](#the-forms-repository-is-not-cloned-yet)
+* [Falha numa cópia de segurança](#a-backup-failed)
+
+As [FAQ](faq.html) tratam em detalhe de dois problemas relacionados: uma
+[palavra-passe de administrador perdida](faq.html#recovering-a-lost-admin-password) e
+[restringir os destinos dos auxiliares REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Mysql not ready yet
+
+O AnsibleForms não arranca, e o registo repete estas linhas a cada 5 segundos:
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**Porque acontece**
+
+No arranque, o AnsibleForms espera até que a base de dados responda a uma consulta, e continua à espera enquanto isso não acontecer.
+O `<reason>` é a própria mensagem do driver da base de dados: uma ligação recusada ou que expirou aponta para o host ou a porta,
+uma mensagem de acesso negado para o nome de utilizador ou a palavra-passe.
+
+**Como corrigir**
+
+Verifique [`DB_HOST`](customization/server.html#env_DB_HOST), [`DB_PORT`](customization/server.html#env_DB_PORT),
+[`DB_USER`](customization/server.html#env_DB_USER) e [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD).
+De dentro de um contentor, `localhost` é o próprio contentor, e não o host que executa o MySQL. Certifique-se de que o MySQL escuta
+num endereço de rede e de que o utilizador se pode ligar a partir do host do AnsibleForms. O AnsibleForms continua sozinho assim
+que a base de dados responder; não é necessário reiniciar.
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+O navegador abre uma página da base de dados em vez da página de início de sessão, e o registo mostra:
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**Porque acontece**
+
+O esquema `AnsibleForms` falta ou está incompleto. Uma base de dados *vazia* é aprovisionada automaticamente no arranque, a menos que
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) seja `0`. Se isso falhar, por exemplo porque
+o utilizador da base de dados não pode criar um esquema, o registo diz `Failed to create the schema automatically : <reason>`. Um esquema
+que existe mas a que faltam tabelas (`Table '<name>' is not present`) nunca é recriado automaticamente, porque criar o
+esquema elimina primeiro todas as tabelas. A página da base de dados diz então *It appears that you have an unuseable schema*.
+
+**Como corrigir**
+
+Numa instalação nova, dê ao utilizador da base de dados o direito de criar o esquema `AnsibleForms` e reinicie, ou carregue em
+**Criar** na página da base de dados. Num esquema parcialmente presente, restaure uma cópia de segurança ou remova o esquema `AnsibleForms`
+incompleto para que o AnsibleForms o possa criar de novo. O registo lista as tabelas e os patches que falharam.
+
+---
+
+## Schema creation is disabled
+
+Criar o esquema, a partir da página da base de dados ou com `POST /api/v2/schema`, falha com:
+
+```
+Schema creation is disabled
+```
+
+**Porque acontece**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) é `0`, o que desativa tanto a criação
+automática no arranque como o endpoint. Numa base de dados que já tem utilizadores, o endpoint também recusa quem não tenha
+sessão iniciada como administrador, com `Schema creation requires an authenticated administrator`.
+
+**Como corrigir**
+
+Crie o esquema uma vez com `ALLOW_SCHEMA_CREATION=1` (é a predefinição), ou restaure-o a partir de uma cópia de segurança, e depois volte a colocar a
+variável em `0`. Numa base de dados aprovisionada, inicie sessão como administrador antes de recriar o esquema, e lembre-se
+de que isso elimina e recria todas as tabelas.
+
+---
+
+## Config seed failed, refusing to start
+
+O contentor termina logo depois do arranque, e a sua saída acaba com:
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**Porque acontece**
+
+O ficheiro em [`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) não pôde ser aplicado: não é YAML
+válido ou viola o esquema do seed, por exemplo; `<reason>` diz o que correu mal. O AnsibleForms recusa-se a arrancar em vez de
+funcionar com metade dos seus objetos declarados. O motivo também é escrito na saída de erro padrão, por isso `docker logs` e `kubectl logs` mostram-no.
+
+**Como corrigir**
+
+Corrija o que `<reason>` indica e inicie novamente. Consulte [Recarregamento e arranque](seed/reloading.html) para saber como o seed é
+aplicado, e [Exemplo](seed/example.html) para um ficheiro válido.
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+Cada arranque regista este aviso:
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+Ou o worker recusa-se a arrancar com:
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**Porque acontece**
+
+Os segredos guardados são cifrados com [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET): desde a 7.3.0 vivem em
+credenciais (as palavras-passe e os tokens dos diretórios LDAP, dos fornecedores de SSO, dos runners e dos cofres de segredos, entre outros), ao lado dos endereços de webhook do Slack
+e do Teams. Sem ela, é usada uma chave que é pública no código-fonte. Desde a 7.3.0, um arranque com um novo
+`ENCRYPTION_SECRET` volta a cifrar todos os segredos guardados com ele, numa única transação: a partir da chave predefinida quando é definido pela primeira
+vez, ou a partir de [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) quando muda. Quando os
+segredos guardados não foram cifrados com nenhuma das duas, nada é alterado e o AnsibleForms não arranca.
+
+**Como corrigir**
+
+Defina `ENCRYPTION_SECRET`, e guarde-o com os seus outros segredos: as cópias de segurança nunca o contêm. O arranque seguinte regista
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`. Para o alterar mais tarde, defina o novo valor em
+`ENCRYPTION_SECRET` e o antigo em `ENCRYPTION_SECRET_PREVIOUS` durante um arranque, e depois remova `ENCRYPTION_SECRET_PREVIOUS`. Quando o
+worker se recusa a arrancar, defina `ENCRYPTION_SECRET_PREVIOUS` com a chave com que os segredos foram cifrados, ou volte a colocar o valor antigo.
+
+---
+
+## Could not load the forms
+
+O painel não mostra formulários e indica:
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**Porque acontece**
+
+A configuração base (`config.yaml`) não pôde ser lida ou não é válida. O `<reason>` diz qual o caso:
+
+| Motivo | Causa |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | Um erro de sintaxe YAML |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | Um ficheiro vazio, ou só com comentários |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | A mesma função está definida duas vezes |
+| `There is no config.yaml nor could one be created from template.` | Falta o `config.yaml` e a sua pasta não permite escrita |
+| `There is no forms directory nor could there be one created from template.` | Falta a pasta de formulários e não pode ser criada |
+| Qualquer outra linha | A configuração viola o esquema, por exemplo uma função sem `groups` |
+
+**Como corrigir**
+
+Corrija o ficheiro indicado por [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH), ou o `config.yaml` no
+repositório usado para a configuração. Quando faltam ficheiros, faça com que [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) e
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) apontem para um local persistente com permissão de escrita. Consulte
+[config.yaml](config/) para a estrutura.
+
+---
+
+## A configuração base tem uma secção forms
+
+Depois de uma atualização a partir da 6.x o painel fica vazio, e o painel de avisos mostra:
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**Porque acontece**
+
+Desde a 7.0.0, cada formulário vive no seu próprio ficheiro na pasta de formulários. Os formulários que ainda estão listados em `config.yaml` são
+ignorados.
+
+**Como corrigir**
+
+Mova cada formulário para o seu próprio ficheiro em [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH). Consulte
+[Atualizar para a 7.x](upgrade-7.html).
+
+---
+
+## Falta um formulário no painel
+
+Existe um ficheiro de formulário, mas um utilizador não vê o formulário no painel.
+
+**Porque acontece**
+
+Um utilizador só vê um formulário quando uma das `roles` do formulário é uma das funções do utilizador; os administradores veem todos os formulários. Todos os utilizadores têm
+a função `default`, por isso um formulário com `roles: [default]` é visível para todos. As funções de um utilizador vêm dos grupos e dos utilizadores
+listados em `roles` no `config.yaml`. Um formulário sem `categories` aparece em **Default**, por isso falta nas
+outras categorias, embora continue listado em **Todos os formulários**. Por fim, um formulário que falha a validação é ignorado. O
+painel mostra então um botão **This config has Warnings or Errors**, que abre mensagens como:
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**Como corrigir**
+
+Abra o painel de avisos e corrija o que lá está listado. Verifique as funções do utilizador em
+[Permissões](profile/permissions.html) no perfil, e as `roles` e `categories` do formulário. Consulte
+[Funções](config/roles.html) e [Categorias](config/categories.html). Quando dois ficheiros definem o mesmo nome de formulário,
+ganha o primeiro que for carregado.
+
+---
+
+## Could not save the forms
+
+Guardar no designer falha com:
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**Porque acontece**
+
+O designer valida todos os formulários contra o esquema antes de escrever o que quer que seja. Cada linha de `<messages>` indica o
+formulário e o campo que violam uma regra. As opções removidas na 7.0.0 têm uma mensagem própria, por exemplo
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`.
+
+**Como corrigir**
+
+Corrija os campos que as mensagens indicam. Para as opções que a 7.0.0 removeu, siga [Atualizar para a 7.x](upgrade-7.html).
+Para validar os ficheiros de formulários antes de chegarem ao AnsibleForms, consulte
+[Validação no VS Code para ficheiros de formulários](faq.html#vs-code-validation-for-form-files) nas FAQ.
+
+---
+
+## The editor is read-only
+
+O designer mostra **Bloqueado** com o nome de outro utilizador, e guardar falha com:
+
+```
+The editor is read-only
+```
+
+**Porque acontece**
+
+Só uma pessoa de cada vez pode editar os formulários. O bloqueio é obtido quando alguém inicia o designer, e mantém-se até que
+o pare, mesmo que tenha fechado o navegador sem o parar. A API recusa uma gravação de qualquer outra pessoa com
+`Designer is locked by <username>`.
+
+**Como corrigir**
+
+Peça a `<username>` que pare o designer. Se isso não for possível, use **Force Unlock** no designer. Quem detém o
+bloqueio perde as alterações que ainda não guardou.
+
+---
+
+## Abuse attempt of eval function
+
+Um campo de expressão mostra um erro, e o registo tem uma linha como:
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**Porque acontece**
+
+As expressões do lado do servidor são verificadas antes de serem executadas. Só podem chamar funções `fn.` e `fnc.`; várias instruções,
+várias linhas, template literals, `process.env` e palavras como `require` ou `constructor` são recusadas. A mensagem
+diz que regra foi violada. Com [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) definido como
+`off`, todas as expressões do servidor falham com
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`.
+
+**Como corrigir**
+
+Reescreva a expressão como uma única chamada `fn.` ou uma operação simples, ou execute-a no navegador com `runLocal: true`. Consulte
+[Expressões](expressions/) e [Expressões locais](expressions/local.html).
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+Um campo que chama uma API REST fica vazio, e o registo mostra:
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**Porque acontece**
+
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) está definido, e o host do URL não consta dele.
+Um host que corresponda a [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) é recusado com
+`blocked by REST_DENIED_HOSTS entry "<entry>"`, e um host que não resolve com `cannot resolve <host>`.
+
+**Como corrigir**
+
+Adicione o nome do host, ou um CIDR que abranja os seus endereços, a `REST_ALLOWED_HOSTS`, ou remova de
+`REST_DENIED_HOSTS` a entrada que o bloqueia. Consulte [Restringir os destinos dos auxiliares REST](faq.html#restricting-rest-helper-destinations-allowdeny-lists).
+
+---
+
+## Authentication failed: Invalid credentials
+
+A página de início de sessão recusa um nome de utilizador e uma palavra-passe com:
+
+```
+Authentication failed: Invalid credentials
+```
+
+**Porque acontece**
+
+A página de início de sessão dá a mesma resposta para todas as falhas, para não revelar se um utilizador existe. O AnsibleForms
+tenta primeiro os utilizadores locais e depois o LDAP: com vários diretórios, um nome de utilizador é procurado pela sua ordem em **Acesso > LDAP**,
+a menos que indique um diretório (`corp\jane`) ou um dos seus domínios de início de sessão (`jane@corp.example`). O motivo real vai para o registo. As falhas
+de LDAP são registadas como `Error connecting to ldap: <reason>`, com motivos como `Wrong binding credentials` ou
+`Unable to verify the certificate`; os códigos do Active Directory são traduzidos para `Wrong password`, `User not found`,
+`Account disabled`, `Account locked` ou `Password expired`.
+
+**Como corrigir**
+
+Leia o motivo no registo. Para o motivo completo de cada início de sessão falhado, defina
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) como `debug`, que regista `Ldap authentication failed: <reason>`.
+Se a palavra-passe do administrador local se perdeu, consulte [Recuperar uma palavra-passe de administrador perdida](faq.html#recovering-a-lost-admin-password).
+
+---
+
+## LDAP check failed
+
+Testar um diretório LDAP em **Acesso > LDAP** falha com uma destas mensagens:
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**Porque acontece**
+
+O utilizador de bind ou a sua palavra-passe estão errados, o servidor ou a porta não estão acessíveis, ou, com TLS, o certificado do servidor não pode ser
+verificado contra o CA bundle. Desde a 7.3.0 estes dados estão na credencial ldap do diretório, em **Ligações > Credenciais**. Um utilizador de teste que não existe
+continua a contar como um teste bem-sucedido, porque a ligação e o bind funcionaram.
+
+**Como corrigir**
+
+Abra a credencial que o diretório indica (o diretório predefinido é `main`) em **Ligações > Credenciais**, e corrija o DN de bind
+e a sua palavra-passe, os servidores e a porta (normalmente 389, ou 636 para LDAPS). Para problemas de TLS, cole o CA bundle que assinou o
+certificado do servidor LDAP; ignorar a verificação do certificado não é para produção. Consulte [LDAP](authentication/ldap.html).
+
+---
+
+## Falha na autenticação Azure AD ou OIDC
+
+Um início de sessão único volta à página de início de sessão com:
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**Porque acontece**
+
+O fornecedor de identidade devolveu o utilizador, mas o AnsibleForms não conseguiu concluir o início de sessão. Os motivos comuns são
+`azuread login is not enabled` ou `oidc login is not enabled` (o fornecedor está desativado), e `jwt expired`, porque
+a passagem a partir do fornecedor só é válida durante 5 minutos. Um erro durante a callback do fornecedor também é mostrado
+na página de início de sessão, e registado.
+
+**Como corrigir**
+
+Ative o fornecedor em **Acesso > SSO**, e registe o URL de callback no fornecedor de identidade exatamente como
+o AnsibleForms o usa: `https://<your host>/api/v2/auth/entraid/callback` para o Entra ID (a partir da 7.3.0; `azureadoauth2` continua a funcionar), ou
+`https://<your host>/api/v2/auth/oidc/callback` para OIDC. Um URL de callback com `/api/v1/`, de antes da 7 ou de antes da
+6.1.5, tem de ser atualizado: a página de início de sessão volta então a carregar sem iniciar sessão e sem erro. Tente novamente o início de sessão depois de
+uma passagem expirada.
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+Um utilizador com uma palavra-passe válida não consegue iniciar sessão, e recebe:
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**Porque acontece**
+
+Uma das funções do utilizador define a opção de função `allowLogin` como `false`. O registo diz
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`.
+
+**Como corrigir**
+
+Remova `allowLogin: false` da função, ou retire o utilizador dessa função. Consulte [Funções](config/roles.html).
+
+---
+
+## Sessão terminada depois de um reinício ou ao fim de um dia
+
+Todos os utilizadores são enviados de volta para a página de início de sessão depois de o AnsibleForms reiniciar, ou ao fim de um dia de utilização.
+
+**Porque acontece**
+
+Quando [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) não está definido, cada arranque gera uma
+nova chave de assinatura, e regista
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+Os tokens de antes do
+reinício deixam então de ser aceites. Independentemente disso, uma sessão termina quando o seu refresh token expira
+(`Refresh token is expired`), ao fim de
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION), 24 horas por predefinição.
+
+**Como corrigir**
+
+Defina `ACCESS_TOKEN_SECRET` com um valor fixo e secreto. Aumente `ACCESS_TOKEN_REFRESH_EXPIRATION` se um dia for pouco. Para
+acesso à API de longa duração, use um [token de API](profile/api-token.html).
+
+---
+
+## Formulários e tarefas vazios depois de um início de sessão único (HTTP 431)
+
+Um utilizador inicia sessão com Entra ID ou OIDC sem erro, mas as páginas de formulários e de tarefas ficam vazias. O separador de rede
+do navegador mostra as chamadas à API respondidas com:
+
+```
+431 Request Header Fields Too Large
+```
+
+O registo do servidor não mostra nada para estas chamadas, e o mesmo utilizador pode funcionar bem com uma conta LDAP ou local.
+
+**Porque acontece**
+
+Antes da 7.1.0, o token de início de sessão transportava todos os grupos do utilizador, e os grupos do Entra ID apareciam nele duas vezes, pelo ID do objeto
+e pelo nome. O navegador envia esse token no cabeçalho `Authorization` de cada pedido, por isso um utilizador em cerca de cem
+grupos ou mais acaba com um cabeçalho bem acima dos 16 KB. O Node.js recusa cabeçalhos de pedido maiores do que 16 KB com um 431,
+antes de o pedido chegar ao AnsibleForms, e é por isso que nada é registado. Um reverse proxy à frente pode recusar o
+pedido ainda antes: o Nginx permite 8 KB por campo de cabeçalho por predefinição
+(`large_client_header_buffers 4 8k`), e responde 400 em vez disso.
+
+**Como corrigir**
+
+Atualize para a 7.1.0 ou posterior: o token de início de sessão deixa de transportar os grupos, por isso o seu tamanho deixa de depender de quantos
+grupos um utilizador tem, e a interface indica-o quando um pedido é recusado com 431 em vez de mostrar páginas vazias.
+Até poder atualizar, faça uma destas coisas:
+
+* defina um **Filtro de grupos** no fornecedor em **Acesso > SSO**, uma expressão regular que mantenha apenas os grupos que as suas
+  funções usam, consulte [Entra ID](authentication/entra-id.html) ou [OIDC](authentication/oidc.html); o utilizador inicia sessão novamente
+  para obter um token mais pequeno
+* ou aumente o limite do Node.js com a variável de ambiente `NODE_OPTIONS=--max-http-header-size=65536`, e
+  reinicie o AnsibleForms
+
+A partir da 7.1.0, [`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) define o mesmo limite, 16384
+bytes por predefinição e lido no arranque, para outros cabeçalhos grandes, como cookies grandes definidos por um gateway de início de sessão único à
+frente. Aumente também os limites de cabeçalhos do proxy, consulte [Tamanho dos cabeçalhos do pedido](production/reverse-proxy.html#request-header-size).
+
+---
+
+## Playbook failed with status
+
+Uma tarefa Ansible termina como falhada, e a última linha da sua saída é:
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**Porque acontece**
+
+O `ansible-playbook` terminou com um código diferente de zero. As linhas acima contêm o próprio erro do Ansible: o playbook não foi
+encontrado, um host estava inacessível, uma tarefa falhou, ou o inventário está errado. O playbook é procurado no repositório
+com **Usar para playbooks ?** ativado, ou em [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH); a linha do registo
+`Running from directory : <path>` mostra a pasta que foi usada.
+
+**Como corrigir**
+
+Leia a saída da tarefa acima da última linha. Quando o playbook não é encontrado, compare o `playbook` do formulário com a
+pasta em `Running from directory`. Consulte [Formulários Ansible](forms/ansible.html).
+
+---
+
+## Playbook was aborted by the main process
+
+Uma tarefa Ansible termina como falhada com:
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**Porque acontece**
+
+O processo `ansible-playbook` no RTE foi terminado por um sinal, e ninguém abortou a tarefa. Desde a 7.0.0 o tamanho da
+saída já não provoca isto: acima de [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER) (50 MB por stream
+por predefinição) o resto da saída não é guardado, a tarefa mostra
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`,
+e o playbook corre até ao fim. A causa habitual agora é a memória: o contentor do RTE atingiu o seu limite de memória e o
+kernel matou o playbook, por exemplo com muitos forks ou facts grandes.
+
+**Como corrigir**
+
+Verifique a memória do contentor do RTE enquanto o playbook corre (`docker stats`, `kubectl top pod`) e aumente o seu limite, ou reduza
+o uso de memória do playbook (menos `forks`, sem recolha de facts desnecessária). Quando só vê o aviso de `PROCESS_MAX_BUFFER` e
+precisa da saída completa, aumente `PROCESS_MAX_BUFFER` no ambiente do contentor do RTE; é lido pelo RTE, e não pela aplicação.
+---
+
+## Failed to launch awx template
+
+Uma tarefa AWX termina como falhada, com uma saída que começa por:
+
+```
+failed to launch awx template <name>
+```
+
+**Porque acontece**
+
+A linha seguinte dá o motivo. `Request failed with status code 401` significa que o token ou o nome de utilizador e a palavra-passe na
+credencial do runner AWX são recusados. `could not find job template <name>` significa que nem um job template nem um workflow job template
+têm exatamente esse nome, ou que o utilizador da ligação não o consegue ver. Um erro de certificado, como
+`unable to verify the first certificate`, significa que o certificado do AWX não é fidedigno.
+
+**Como corrigir**
+
+Use **Testar ligação** no runner (**Ligações > Runners**), que responde `Runner connection is OK` quando funciona. Desde a
+7.3.0 o token ou o utilizador e a palavra-passe, o endereço e o **CA bundle** estão na credencial do runner, em
+**Ligações > Credenciais**: renove aí o token ou a palavra-passe, e para erros de certificado cole a CA no seu **CA bundle**.
+Verifique o nome e as permissões do template. Introduza o endereço sem `/api/v2`: o AnsibleForms acrescenta ele próprio
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX).
+Consulte [Formulários AWX](forms/awx.html).
+
+---
+
+## Uma tarefa mostra o estado abandoned
+
+Uma tarefa que estava em execução está agora marcada como `abandoned`, e o registo de um nó ou de um RTE mostra uma destas linhas:
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+Um RTE em modo base de dados, obsoleto, regista as suas próprias:
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**Porque acontece**
+
+Uma tarefa pertence ao contentor que a executa ou acompanha: um playbook ao seu RTE, qualquer outra tarefa (uma tarefa AWX, os passos de um formulário
+multistep) ao nó da aplicação que a iniciou. Quando esse contentor reinicia, termina as suas próprias tarefas por concluir. Quando desaparece, um pod
+substituído por exemplo, o worker termina as suas tarefas assim que deixa de responder durante dois minutos. Um RTE num modo socket que volta sem
+uma tarefa que estava a executar, um contentor novo sem o seu spool por exemplo, faz com que essa tarefa termine como abandonada. Um RTE que está a parar espera
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) pelos seus playbooks primeiro. A cada hora, as tarefas que estão em execução há mais
+de um dia também são marcadas como abandonadas.
+
+Desde a 7.3.0 uma tarefa no AWX, AAP ou Ascender continua no seu runner: logo depois de um reinício a abandonar, um nó volta a acompanhá-la,
+se tiver começado nas últimas 24 horas, e termina com o que realmente aconteceu lá. O registo diz então `Following <n> abandoned job(s) again on their runner`.
+
+**Como corrigir**
+
+Relance uma tarefa de playbook. Reinicie ou atualize os RTEs e os nós da aplicação quando não houver nenhuma tarefa em execução, e dê a um RTE que está a parar tempo suficiente
+(consulte [Escalar](rte/run.html)). Verifique se o playbook terminou realmente nos hosts geridos antes de
+relançar, porque pode ter sido executado parcialmente.
+
+---
+
+## Um RTE não se liga
+
+**Testar ligação** num runner RTE (**Ligações > Runners**) falha com:
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**Porque acontece**
+
+Um RTE num modo socket comunica com a aplicação através de um WebSocket: em saída liga-se à aplicação, em entrada é a aplicação que se liga a ele (consulte
+[Modos](rte/modes.html)). Os registos da aplicação e do RTE dizem porque é que o socket não está aberto:
+
+| Mensagem | Onde | O que significa |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | O RTE (entrada) | O token da credencial de RTE do runner não é o `RTE_TOKEN` do RTE |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | A aplicação (entrada) | O mesmo, visto a partir da aplicação |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | A aplicação, e o RTE que é recusado (`401`) | O RTE inicia sessão com um token diferente do que a aplicação guarda para o seu runner |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | O RTE (saída) | Pediu para aderir e aguarda uma aprovação |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | O RTE (entrada, com `APP_URL`) | O mesmo, para um RTE de entrada |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | A aplicação, e o RTE que é recusado (`409`) | O config seed declara o runner sem `rte_mode`, portanto em modo base de dados, e é o seed que decide o seu modo. Um RTE de entrada recebe `rte_mode: inbound` e `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | O RTE | Um RTE de entrada que se regista a si próprio precisa do endereço em que a aplicação se liga a ele |
+| `Runner '<name>': dialing <address>: <reason>` | A aplicação, no nível `debug` | A aplicação não consegue abrir o socket, por exemplo porque o certificado do RTE não é o fixado para o seu runner |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | O RTE | Corre em modo base de dados, e não abre nenhum socket |
+
+**Como corrigir**
+
+* **Um token recusado** : dê ao RTE o token da credencial de RTE do seu runner (**Ligações > Credenciais**), ou o contrário
+* **À espera de aprovação** : aprove-o em **Ligações > Runners**, depois de verificar que a impressão digital mostrada aí é a que está no seu
+  registo (consulte [Aprovar um RTE](runners/registration.html#approving-an-rte))
+* **Gerido pelo config seed em modo base de dados** : defina `rte_mode` no runner no seed, com uma credencial de RTE (para entrada, o seu
+  endereço), e depois reinicie o RTE
+* **Entrada sem `RTE_URL`** : defina `RTE_URL` com o endereço em que a aplicação chega ao RTE, ou omita `APP_URL` e declare o
+  runner no seed ou em **Ligações > Runners**
+* **Um certificado que não é o fixado** : um RTE de entrada por HTTPS envia o seu certificado quando se regista, e a aplicação só se liga
+  a ele com esse. Depois de um certificado novo, o RTE volta a enviá-lo quando se regista; quando o CA bundle da credencial foi definido
+  à mão, a aplicação mantém-no e regista
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **O aviso [DEPRECATED]** : defina `RTE_MODE` no RTE, remova `DB_*` do seu ambiente, e defina o seu runner com esse modo (consulte
+  [Modos](rte/modes.html))
+
+---
+
+## The form data is not valid
+
+Com a validação do lançamento em `enforce`, um lançamento é recusado com `422` e:
+
+```
+The form data is not valid
+```
+
+**Porque acontece**
+
+O servidor verificou os valores dos campos contra as regras do formulário e encontrou campos em falta ou inválidos; a resposta lista-os
+em `details`. Um lançamento sem `rawFormData` também é recusado. Um formulário que ainda não pode ser verificado, como um wizard,
+é recusado com `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`.
+
+**Como corrigir**
+
+Corrija os campos que os detalhes indicam, ou as regras do formulário se forem demasiado restritivas. Execute primeiro com `log`: regista
+`Launch validation would refuse form '<name>' ...` sem recusar nada. Consulte
+[O que faz o enforce](launch-validation/log-and-enforce.html#what-enforce-does) e
+[Implementá-la](launch-validation/rolling-it-out.html).
+
+---
+
+## Falha ao clonar ou fazer pull de um repositório
+
+Um repositório mostra um estado de falha, e a sua saída contém o erro do git, ou o registo mostra
+`Background clone of '<name>' failed : <reason>`.
+
+**Porque acontece**
+
+O git não conseguiu chegar ao remoto ou autenticar-se nele. Para URLs SSH (`git@host:path`), o remoto tem de aceitar a chave
+pública do AnsibleForms; para HTTPS, o nome de utilizador e o token têm de ser válidos. Um pull também é recusado quando a árvore de trabalho tem
+alterações, com
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**Como corrigir**
+
+Para SSH, copie a chave pública do separador **Chave** de **Ligações > SSH** e adicione-a como deploy key, ou a um utilizador com
+acesso ao repositório. O AnsibleForms adiciona o host remoto aos hosts conhecidos num clone; para outros hosts, use o
+separador **Hosts conhecidos** da mesma página. Para
+HTTPS, renove o token. Consulte [Repositórios Git](gui/designer-and-git.html#git-repositories) e
+[Sobre os repositórios](faq.html#about-repositories).
+
+---
+
+## O repositório de formulários ainda não foi clonado
+
+Guardar formulários no designer falha com:
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**Porque acontece**
+
+Um repositório com **Usar para formulários ?** ativado ainda não tem árvore de trabalho, porque o clone não foi executado ou falhou.
+
+**Como corrigir**
+
+Clone o repositório a partir das definições de repositórios. Se o clone falhar, consulte
+[Falha ao clonar ou fazer pull de um repositório](#a-repository-clone-or-pull-failed).
+
+---
+
+## Falha numa cópia de segurança
+
+Uma cópia de segurança falha, e nada é adicionado à lista de cópias de segurança. O motivo é um destes:
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**Porque acontece**
+
+O comando de dump, [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND), não está instalado, não conseguiu
+ligar-se, ou produziu um ficheiro vazio. Uma base de dados grande também pode demorar mais do que
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS), uma hora por predefinição.
+Uma cópia de segurança falhada não deixa nenhuma pasta para trás; o registo diz `Backup failed, removing the incomplete folder '<folder>' : <reason>`.
+
+**Como corrigir**
+
+Instale as ferramentas de cliente do MySQL ou do MariaDB, ou defina `MYSQLDUMP_COMMAND` (e `MYSQL_COMMAND` para os restauros) com um comando
+que funcione neste host e contra a versão do seu servidor. Aumente `BACKUP_COMMAND_TIMEOUT_SECONDS` para uma base de dados grande.
+Consulte [Cópias de segurança](gui/administration.html#backups).
diff --git a/i18n/pt/_security_assessment/security-assessment/advisories.md b/i18n/pt/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..7d0e01e
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: Avisos de segurança
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# Avisos de segurança
+{: .no_toc }
+
+Todas as vulnerabilidades publicadas, a sua gravidade e a sua correção
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Avisos publicados
+
+Lidos do [separador Security do repositório](https://github.com/ansibleforms/ansibleforms/security/advisories) em cada build deste site:
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>Aviso</th>
+      <th>Gravidade</th>
+      <th>Fragilidade</th>
+      <th>Afetadas</th>
+      <th>Corrigido em</th>
+      <th>Publicado</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+Ainda não foi publicado nenhum aviso.
+{% endif %}
+
+Cada aviso no GitHub dá os detalhes: o impacto, as condições, o vetor CVSS e a correção.
+
+---
+
+## O que isto significa para a sua versão
+
+Um aviso indica as versões que afeta e a primeira versão corrigida. A correção chega às versões suportadas,
+[7.x e 6.5.x](development.html#supported-versions), e as versões mais antigas não são corrigidas: a correção é atualizar.
+
+Compare a versão de uma instância (**Acerca de** no menu de ajuda, ou `GET /api/v2/version`) com **Afetadas**.
+
+---
+
+## Ser avisado dos novos avisos
+
+O GitHub notifica quem segue o repositório quando um aviso é publicado:
+
+* Em [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), escolha **Watch > Custom > Security alerts**.
+* O [registo de alterações](../changelog.html) enumera cada correção de segurança na versão que a inclui.
diff --git a/i18n/pt/_security_assessment/security-assessment/development.md b/i18n/pt/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..1b99d4b
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: Desenvolvimento seguro
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# Desenvolvimento seguro
+{: .no_toc }
+
+Como as alterações são verificadas e publicadas, e o que é suportado
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## O código-fonte
+
+O AnsibleForms é open source, por isso tudo o que está nesta página pode ser verificado no próprio repositório:
+
+* O código, o seu histórico e os seus pipelines de build são públicos em [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms).
+* A [licença](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) é GPL-3.0.
+* O [registo de alterações](../changelog.html) enumera todas as alterações de cada versão, incluindo as correções de segurança.
+
+---
+
+## Como uma alteração é integrada
+
+Todas as alterações chegam a `main` através de um pull request, sob um conjunto de regras que ninguém pode contornar:
+
+| Regra | O que significa |
+|---|---|
+| Pull request obrigatório | Nada é enviado diretamente para `main` |
+| Verificações obrigatórias | O pull request só é integrado quando passam todas as verificações abaixo |
+| Sem force push, sem eliminação | O histórico de `main` não pode ser reescrito nem removido |
+| Histórico linear | Cada pull request torna-se um commit, para que cada alteração possa ser rastreada e revertida por si só |
+
+As verificações que um pull request tem de passar:
+
+| Verificação | O que faz |
+|---|---|
+| Client, Server | Os testes unitários da interface web e do servidor |
+| CodeQL | A análise estática do GitHub ao código JavaScript e TypeScript, à procura de injeção, cross-site scripting e outras fragilidades |
+| Public schema is up to date | O esquema da base de dados que o código espera corresponde ao que inclui |
+| Title, Branch | O pull request segue as regras de nomes, para que o registo de alterações se mantenha exato |
+
+Há mais duas que correm em cada pull request e reportam sobre ele:
+
+* **Database** testa o servidor em MySQL e MariaDB, e **Browser** conduz a interface num navegador.
+* **Dependency review** bloqueia uma dependência nova com uma vulnerabilidade conhecida alta ou crítica.
+
+---
+
+## Análise de código e dependências
+
+O código e aquilo de que depende são verificados de novo depois de integrados:
+
+* O **CodeQL** também analisa cada push para `main` e para os ramos de versão, e todo o código base todas as semanas:
+  uma regra nova do CodeQL verifica assim também o código integrado antes dela.
+* O **Dependabot** abre um pull request para cada nova versão de uma dependência: os pacotes npm do servidor e da
+  interface, os pacotes Python do ambiente de execução e as GitHub Actions dos pipelines todas as semanas, e
+  as imagens base dos contentores todos os dias.
+* As imagens base são fixadas por digest (`node:26-trixie-slim@sha256:...`), para que um build use exatamente a imagem revista.
+  O Dependabot atualiza o digest quando a imagem é reconstruída a montante.
+
+---
+
+## Versões e imagens
+
+Uma versão é construída e publicada apenas pelo GitHub Actions, nunca a partir da máquina de um programador:
+
+* Uma versão é criada a partir de `main` (ou de `release/6.x`), com um registo de alterações construído a partir dos seus pull requests.
+* As imagens são construídas pelo [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)
+  e enviadas para o GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, com as imagens do ambiente de execução
+  ao lado. O workflow e os seus registos são públicos, pelo que qualquer pessoa pode ver o que entrou numa imagem.
+* As imagens da aplicação e do ambiente de execução correm como o utilizador sem privilégios `node` (uid 1000), nunca como root.
+
+---
+
+## Versões suportadas
+
+As correções de segurança entram na versão mais recente de cada linha suportada:
+
+| Versão | Recebe correções de segurança |
+|---|---|
+| 7.x | Sim |
+| 6.5.x | Sim |
+| Anterior à 6.5 | Não: a correção é atualizar |
+
+O [guia de atualização](../upgrading/) explica como passar para uma versão mais recente, e [Atualizar para a v7](../upgrade-7.html) a passagem a partir da 6.5.
diff --git a/i18n/pt/_security_assessment/security-assessment/faq.md b/i18n/pt/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..19ef80b
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: FAQ da avaliação
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# FAQ da avaliação
+{: .no_toc }
+
+Respostas curtas às perguntas que os questionários de segurança mais fazem
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Dados e alojamento
+
+Onde ficam os dados, e quem lhes pode aceder:
+
+| Pergunta | Resposta |
+|---|---|
+| Onde são guardados os nossos dados? | Na base de dados MySQL ou MariaDB que gere, e na pasta persistente da sua instância. O AnsibleForms é auto-alojado, sem nenhum serviço na nuvem por trás. |
+| Envia dados a quem o faz? | Não. Não há telemetria, nem relatórios de utilização, nem verificação de atualizações. |
+| A que se liga? | Só aos sistemas que um administrador configura: ver [Ligações de saída](measures.html#outbound-connections). |
+| Usa IA ou envia dados a um fornecedor de modelos? | Só com o [assistente de chat](../chat/) ligado, que está desligado por predefinição. Nesse caso, envia as definições dos formulários e os valores a ser preenchidos ao fornecedor que configurar. |
+| Pode funcionar sem acesso à internet? | Sim. A aplicação não precisa de acesso à internet; os playbooks precisam daquilo a que as suas tarefas acedem. |
+
+---
+
+## Cifragem
+
+O que é cifrado, e com que chaves:
+
+| Pergunta | Resposta |
+|---|---|
+| Os dados são cifrados em trânsito? | Com [HTTPS](../security/https.html), servido pela aplicação ou pelo seu proxy inverso, e `wss://` entre a aplicação e os seus ambientes de execução. |
+| Os dados são cifrados em repouso? | Todos os segredos guardados são cifrados pela aplicação com AES-256. As tarefas e o seu resultado são guardados tal como são: use a cifragem em repouso da própria base de dados. Ver [Segredos guardados](measures.html#stored-secrets). |
+| Quem tem as chaves? | O utilizador: o [`ENCRYPTION_SECRET`](../security/secrets.html) é definido por si, fica fora das cópias de segurança e pode ser rodado. |
+| Os segredos podem ficar no nosso cofre? | Sim: o [HashiCorp Vault e o CyberArk](../secret-stores/) são lidos quando uma tarefa precisa deles. |
+
+---
+
+## Acesso e responsabilização
+
+Quem pode iniciar sessão, o que pode fazer e o que fica registado:
+
+| Pergunta | Resposta |
+|---|---|
+| Suporta início de sessão único? | Sim: LDAP / Active Directory, OpenID Connect e Entra ID. Ver [Autenticação](../authentication/). |
+| Suporta autenticação multifator? | Através do início de sessão único: aplica-se o MFA do seu fornecedor de identidade. As contas locais não têm nenhum próprio. |
+| Como são geridas as permissões? | Com funções associadas a grupos, verificadas pelo servidor em cada pedido. Ver [Permissões](measures.html#permissions). |
+| Há um registo de auditoria? | Sim: todas as alterações e todas as tentativas recusadas, guardadas 365 dias por predefinição e reencaminháveis para syslog. Ver [Registo de auditoria](measures.html#audit-trail). |
+| Há uma palavra-passe predefinida? | A primeira conta de administrador tem uma palavra-passe predefinida pública, que tem de ser alterada no primeiro início de sessão. Ver [A conta de administrador](../security/hardening.html#the-admin-account). |
+
+---
+
+## Vulnerabilidades e atualizações
+
+Como os problemas são encontrados, corrigidos e anunciados:
+
+| Pergunta | Resposta |
+|---|---|
+| Foram encontradas vulnerabilidades? | Sim. Todas as publicadas estão enumeradas em [Avisos de segurança](advisories.html), com a versão que as corrigiu. |
+| Como reportamos uma? | Em privado, através do GitHub: ver [Reportar uma vulnerabilidade](reporting.html). |
+| Como é verificado o código? | Análise estática CodeQL e revisão de dependências em cada pull request, testes automáticos e atualizações do Dependabot. Ver [Desenvolvimento seguro](development.html). |
+| Que versões recebem correções de segurança? | 7.x e 6.5.x. Ver [Versões suportadas](development.html#supported-versions). |
+| Como ficamos a saber de um aviso novo? | Siga os alertas de segurança do repositório no GitHub. Ver [Ser avisado dos novos avisos](advisories.html#being-told-of-new-advisories). |
+| Foi alvo de testes de intrusão? | Não está publicado nenhum relatório de testes de intrusão de terceiros. O código é público, pelo que a sua própria equipa ou o seu auditor o pode avaliar, e as conclusões reportam-se como acima. |
+
+---
+
+## Imagens e cadeia de fornecimento
+
+De onde vêm as imagens, e como verificá-las:
+
+| Pergunta | Resposta |
+|---|---|
+| Onde são publicadas as imagens? | No GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, construídas por workflows públicos do GitHub Actions. Ver [Versões e imagens](development.html#releases-and-images). |
+| Os contentores correm como root? | Não: como o utilizador sem privilégios `node`. |
+| As imagens são assinadas? | Ainda não. Faça pull delas por digest (`@sha256:...`) para ter a certeza de que corre a imagem que reviu. |
+| Há um SBOM? | Ainda não é publicado nenhum com as imagens. Um scanner como o Trivy ou o Syft constrói um a partir da imagem. |
+| As imagens são analisadas à procura de vulnerabilidades? | Não no pipeline de publicação. As suas imagens base estão fixadas por digest e são mantidas atualizadas pelo Dependabot; analise as imagens no seu próprio registo para aplicar a sua própria política. |
+| Sob que licença está? | GPL-3.0, open source, sem garantia. |
diff --git a/i18n/pt/_security_assessment/security-assessment/index.md b/i18n/pt/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..53c5776
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Visão geral
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# Avaliação de segurança
+{: .no_toc }
+
+Para revisões de segurança: medidas, desenvolvimento e avisos
+{: .fs-6 .fw-300 }
+
+---
+
+## Em resumo
+
+O AnsibleForms executa playbooks e guarda as respetivas credenciais, pelo que faz parte da sua cadeia de confiança:
+
+* É **auto-alojado**: corre na sua infraestrutura, guarda os seus dados na sua base de dados e não envia nada a quem o faz.
+* É **open source** (GPL-3.0): o código, os seus pipelines e todos os avisos são públicos.
+* Todos os segredos guardados são **cifrados**, todas as alterações **auditadas**, e as **funções** são verificadas em cada pedido.
+* As vulnerabilidades são **reportadas em privado**, corrigidas em todas as versões suportadas e **publicadas**.
+
+---
+
+## Nesta secção
+
+As páginas respondem às perguntas de uma revisão de segurança, desde o desenho até à lista de CVE:
+
+| Página | O que abrange |
+|---|---|
+| [Medidas de segurança](measures.html) | Início de sessão, permissões, segredos guardados, o registo de auditoria, o navegador, o servidor, as ligações e os contentores |
+| [Desenvolvimento seguro](development.html) | Como uma alteração é revista e testada, a análise de código e de dependências, como são construídas as imagens, as versões suportadas |
+| [Reportar uma vulnerabilidade](reporting.html) | Como reportar um problema em privado, e o que acontece a seguir |
+| [Avisos de segurança](advisories.html) | Todas as vulnerabilidades publicadas, com o seu CVE, gravidade e versão corrigida |
+| [FAQ da avaliação](faq.html) | Respostas curtas às perguntas que os questionários de segurança mais fazem |
+
+Para proteger uma instância em vez de a avaliar, consulte [Segurança](../security/) no guia do administrador.
diff --git a/i18n/pt/_security_assessment/security-assessment/measures.md b/i18n/pt/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..bca0e41
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: Medidas de segurança
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# Medidas de segurança
+{: .no_toc }
+
+Como são protegidos o início de sessão, as permissões, os segredos e as ligações
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Onde corre
+
+O AnsibleForms é auto-alojado, na sua infraestrutura, com os seus dados numa base de dados que gere.
+
+* Não há nenhum serviço na nuvem nem servidor de licenças do AnsibleForms, nem telemetria ou verificação de atualizações.
+* A interface é servida pela própria aplicação e não carrega nada de outro site.
+* A aplicação só se liga aos sistemas que um administrador configura, enumerados em [Ligações de saída](#outbound-connections).
+
+As partes e o que cada uma contém:
+
+| Parte | O que faz | O que contém |
+|---|---|---|
+| Aplicação | A interface web, a API REST, o agendador | Nenhum dado próprio: está tudo na base de dados |
+| MySQL ou MariaDB | A base de dados da aplicação | Utilizadores, grupos, credenciais (cifradas), tarefas com as suas extravars e resultado, o registo de auditoria |
+| Ambiente de execução (RTE) | Executa os playbooks, no seu próprio contentor | Os ficheiros das tarefas que executa, e os segredos de uma tarefa só enquanto essa tarefa corre |
+| Pasta persistente | A configuração, os formulários, os playbooks e os ficheiros carregados | Os ficheiros que os formulários e os playbooks usam |
+
+Consulte [Como funciona](../how-it-works.html) para ter a visão completa, e [RTE](../rte/) para o ambiente de execução.
+
+---
+
+## Início de sessão
+
+Todas as páginas e chamadas à API que leem ou alteram dados precisam de um utilizador com sessão iniciada. Os poucos endpoints abertos sem sessão servem o
+próprio início de sessão, a versão, o nome e o logótipo da instância, a documentação da API e a configuração da base de dados de um primeiro arranque,
+que [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` fecha:
+
+| Método | Como funciona |
+|---|---|
+| Contas locais | Palavras-passe com hash bcrypt, um [comprimento mínimo](../security/hardening.html#sign-in-limits-and-passwords), e a palavra-passe predefinida pública do administrador tem de ser alterada no primeiro início de sessão |
+| LDAP / Active Directory | O diretório verifica a palavra-passe, e os seus grupos correspondem a funções. Ver [LDAP](../authentication/ldap.html) |
+| OpenID Connect, Entra ID | Início de sessão único através do seu fornecedor de identidade, que traz também a sua própria autenticação multifator. Ver [Autenticação](../authentication/) |
+
+* Os inícios de sessão falhados [bloqueiam a conta](../security/hardening.html#sign-in-limits-and-passwords), e o início de sessão tem limite de pedidos.
+* Um início de sessão devolve um token de acesso assinado válido 30 minutos e um token de atualização válido 24 horas.
+* Os tokens podem ser terminados antes de expirarem: terminar sessão, uma alteração de palavra-passe, um utilizador bloqueado e um token de API revogado terminam-nos
+  em todos os nós ao mesmo tempo, ver [Tokens](../security/secrets.html#tokens).
+* O AnsibleForms não tem autenticação multifator própria: use o início de sessão único quando for exigida.
+
+---
+
+## Permissões
+
+O que um utilizador pode fazer vem das funções dos seus grupos, verificadas pelo servidor em cada pedido:
+
+* As funções são definidas no [config.yaml](../config/roles.html): que formulários um utilizador vê e que opções tem,
+  como o designer, as páginas de definições ou as tarefas de outros utilizadores.
+* O servidor verifica cada lançamento com as regras do formulário (os seus campos, os seus valores e o acesso do utilizador), incluindo
+  os lançamentos através da API REST, ver [Validação no lançamento](../launch-validation/).
+* A função de administrador executa qualquer playbook por definição. As outras funções só recebem o que lhes é concedido: um utilizador com várias funções só recebe uma
+  opção quando nenhuma dessas funções a recusa, pelo que basta uma função restritiva para a negar.
+
+---
+
+## Segredos guardados
+
+As palavras-passe, os tokens e as chaves são cifrados antes de serem escritos na base de dados:
+
+* Todos os segredos guardados, as credenciais, a palavra-passe de bind do LDAP, os tokens dos runners, os segredos de cliente do início de sessão único, os endereços de webhook
+  e as chaves de API, são cifrados com AES-256 e um vetor de inicialização aleatório por valor, sob o
+  [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) que definir.
+* Nenhuma chamada à API nem página de definições mostra um segredo guardado, e as cópias de segurança omitem os segredos mestres.
+* Os segredos podem ficar no seu cofre: o [HashiCorp Vault e o CyberArk](../secret-stores/) são lidos quando uma tarefa precisa deles.
+* Os segredos de uma tarefa chegam ao ambiente de execução selados com AES-256-GCM, sob uma chave derivada do seu token.
+* As extravars cujo nome se parece com um segredo são ocultadas na vista da tarefa, e os campos de palavra-passe são-no sempre, ver [Dados das tarefas](../security/hardening.html#job-data).
+
+O resto da base de dados, as tarefas, as suas extravars e o seu resultado, é guardado tal como é: proteja-o com a cifragem em repouso e o controlo de acesso
+da própria base de dados, ver [A base de dados](../security/hardening.html#the-database).
+
+---
+
+## Registo de auditoria
+
+Todas as alterações, e todas as tentativas recusadas, ficam registadas:
+
+* Cada criação, alteração e eliminação, através da interface ou da API, é escrita no registo de auditoria com o utilizador, o seu
+  endereço, a ação, o objeto e o resultado. As recusas e os inícios de sessão também ficam registados, incluindo os falhados.
+* Os valores que se parecem com segredos são ocultados antes de serem escritos.
+* O registo é guardado 365 dias por predefinição, e pode ser copiado para syslog por UDP, TCP ou TLS.
+
+---
+
+## No navegador
+
+A interface está protegida contra código injetado numa página:
+
+* Uma [Content-Security-Policy](../security/hardening.html#the-content-security-policy) só permite os scripts e frames da própria aplicação.
+* Todas as respostas levam cabeçalhos de proteção: nosniff, proteção contra frames e HSTS sobre HTTPS.
+* O HTML dos formulários, dos textos de ajuda e das respostas do chat é sanitizado, e o resultado das tarefas é escapado.
+
+---
+
+## No servidor
+
+O código que trata os dados introduzidos pelo utilizador evita as injeções clássicas:
+
+* As consultas à base de dados passam os seus valores como parâmetros, nunca como texto colado na consulta.
+* Os comandos, incluindo o git, correm a partir de uma lista de argumentos, nunca de uma shell, pelo que os caracteres de shell não fazem nada.
+* As expressões do servidor passam por um [sanitizador de expressões](../security/hardening.html#expressions-and-outbound-calls), e as suas chamadas REST por um filtro de hosts.
+* O [servidor MCP](../mcp/), o [assistente de chat](../chat/) e o endpoint de métricas estão desligados até os ligar.
+
+---
+
+## Ligações
+
+O tráfego de e para o AnsibleForms pode ser cifrado de ponta a ponta:
+
+* A aplicação serve ela própria [HTTPS](../security/https.html), ou fica por trás do seu proxy inverso.
+* Um ambiente de execução fala com a aplicação através de um WebSocket, `wss://` com um endereço HTTPS, e a aplicação
+  fixa o certificado de um que chegue de fora, ver [Modos do RTE](../rte/modes.html).
+* O LDAP, o início de sessão único, os runners, o git, os cofres de segredos e as chamadas REST das expressões verificam o certificado do
+  servidor a que se ligam, a menos que um administrador desligue a verificação para um servidor com um certificado autoassinado.
+
+### Ligações de saída
+
+O AnsibleForms só se liga ao que um administrador configura:
+
+| Ligação | Quando |
+|---|---|
+| LDAP, OpenID Connect, Entra ID (início de sessão Microsoft e Graph) | Quando esse método de início de sessão está configurado |
+| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Quando um formulário corre nesse runner |
+| Servidores git | Quando um repositório está configurado |
+| Servidor de correio, Slack, Teams, Telegram, webhooks | Quando um canal de notificação está configurado |
+| HashiCorp Vault, CyberArk | Quando um cofre de segredos está configurado |
+| Um fornecedor de modelos (Anthropic, OpenAI e outros) | Só com o [assistente de chat](../chat/) ligado, que está desligado por predefinição |
+| Hosts e APIs indicados nos formulários | Quando as expressões de um formulário ou um playbook os chamam |
+| Servidores syslog | Quando o reencaminhamento de auditoria ou de registos está configurado |
+
+---
+
+## Os contentores
+
+As imagens são construídas para correr com o mínimo de privilégios possível:
+
+* A aplicação e o ambiente de execução correm como o utilizador sem privilégios `node`, não como root.
+* São construídas sobre imagens Debian slim fixadas por digest, ver [Desenvolvimento seguro](development.html#code-analysis-and-dependencies).
+* A aplicação escuta numa única porta, a 8000.
+
+Para os passos que protegem uma instância nova, siga [Reforço da segurança](../security/hardening.html).
diff --git a/i18n/pt/_security_assessment/security-assessment/reporting.md b/i18n/pt/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..8a540f1
--- /dev/null
+++ b/i18n/pt/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: Reportar uma vulnerabilidade
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# Reportar uma vulnerabilidade
+{: .no_toc }
+
+Como reportar um problema de segurança em privado, e o que acontece a seguir
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Reporte-o em privado
+
+O AnsibleForms guarda credenciais e tokens de cofres, por isso nunca reporte um problema de segurança numa issue pública:
+
+1. Abra **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: um aviso privado que só os maintainers veem.
+2. Se essa página não estiver disponível para si, abra uma issue normal que diga apenas que tem um relatório de segurança e peça
+   um canal privado: sem detalhes, sem forma de reproduzir, sem números de versão. Um maintainer abre um aviso privado e
+   convida-o para ele.
+
+A política completa é o [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) do repositório.
+
+---
+
+## O que incluir
+
+Quanto mais disto um relatório trouxer, mais depressa é corrigido:
+
+* O que um atacante ganha: os dados de outro utilizador, um playbook que não pode executar, o host ou direitos de administrador.
+* A versão, e como está implementado: Docker, Kubernetes ou instalado de forma nativa.
+* Uma forma de reproduzir, ou o pedido que o provoca.
+* Se precisa de um utilizador com sessão iniciada, e com que [opções de função](../config/roles.html).
+
+---
+
+## O que acontece a seguir
+
+Um relatório passa pelo mesmo aviso privado desde a primeira mensagem até à publicação:
+
+| Passo | O que recebe |
+|---|---|
+| Receção | A confirmação de que o relatório chegou, e se se reproduz |
+| Aceite | Uma correção na próxima versão de cada [versão suportada](development.html#supported-versions), e um aviso publicado que lhe dá o crédito, a não ser que prefira não ser nomeado |
+| Recusado | A justificação, normalmente que o comportamento precisa de uma permissão que quem reportou já tinha |
+
+Depois de a correção ser publicada, o aviso é publicado e aparece em [Avisos de segurança](advisories.html).
+
+---
+
+## Âmbito
+
+A política traça a linha onde o modelo de funções a traça:
+
+| Dentro do âmbito | Fora do âmbito |
+|---|---|
+| Tudo aquilo a que um utilizador com sessão iniciada consegue aceder para além do que a sua função lhe concede | Descobertas que exigem que a conta de administrador já esteja comprometida: um administrador a executar qualquer playbook é o próprio produto |
+| Tudo aquilo a que se consegue aceder sem iniciar sessão | Relatórios de scanners sem impacto demonstrado |
+| Credenciais guardadas que se tornam legíveis, ou que são escritas num registo | |
+| Injeção na shell, na base de dados ou no navegador | |
diff --git a/i18n/pt/_use/designer/index.md b/i18n/pt/_use/designer/index.md
new file mode 100644
index 0000000..b02c083
--- /dev/null
+++ b/i18n/pt/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: Designer
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# Designer
+{: .no_toc }
+
+Editar formulários, playbooks, inventários e workflows no navegador
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para autores de formulários: as secções do designer, e o que mostra cada um dos seus separadores.
+
+O designer precisa da [opção de função](../config/roles.html#role-options) `showDesigner`. Edita um item de cada vez, um
+formulário, um playbook ou um ficheiro de workflow, com as suas secções no menu da esquerda. Cada tipo de ficheiro precisa também da sua própria opção, todas
+ligadas por predefinição: `allowPlaybookDesign` para os **Playbooks**, `allowWorkflowDesign` para os **Fluxos de trabalho**,
+`allowInventoryDesign` para os **Inventários** e `allowVarsFileDesign` para os **Ficheiros de variáveis**. Sem uma delas, a sua secção fica
+só de leitura e o servidor recusa-se a guardar, criar, remover ou enviar (push) os seus ficheiros; os formulários e os workflows continuam a poder escolhê-los. Os
+**Formulários**, as **Categorias** e as **Constantes** precisam de `allowFormDesign` da mesma forma: sem ela ficam só de leitura, e o servidor
+recusa-se a guardá-los, a fazer pull ou a enviá-los. Só uma pessoa edita de cada vez: ver [O bloqueio do designer](lock.html).
+
+---
+
+## As suas secções
+
+Cada secção edita um tipo de ficheiro, guardado localmente ou num [repositório](../repositories/):
+
+| Secção | O que edita |
+|---|---|
+| **Formulários** | Os ficheiros de formulários |
+| **Categorias** | As categorias do `config.yaml` |
+| **Constantes** | As constantes do `config.yaml` |
+| **Ficheiros de variáveis** | Os ficheiros de variáveis que os formulários carregam |
+| **Playbooks** | Os playbooks que os formulários e os workflows executam |
+| **Inventários** | Os inventários: `inventory.yaml`, `group_vars` e `host_vars` |
+| **Fluxos de trabalho** | Os ficheiros de [workflow](../workflows/) |
+
+As secções com ficheiros listam-nos num explorador de ficheiros e abrem o primeiro; uma secção ainda sem ficheiros indica-o. A
+secção **Formulários** e todas as secções de ficheiros têm um botão **Novo ficheiro** em primeiro lugar na sua barra de ferramentas: nos Inventários cria um novo
+inventário, nos Fluxos de trabalho um workflow novo e vazio. A lupa do explorador abre uma caixa que filtra os seus ficheiros pelo nome.
+
+A caixa de pesquisa na linha do título encontra um texto no YAML que está aberto: marca todos os sítios onde aparece. Funciona no
+separador **YAML**, depois de o bloqueio do designer ser seu.
+
+---
+
+## Os seus separadores
+
+Todas as secções têm os mesmos três separadores, todos sobre o mesmo YAML: uma edição num aparece nos outros, e **Guardar** guarda-a.
+
+- **YAML** é o ficheiro tal como está escrito.
+- **Visual** edita-o com campos. Só mudam as chaves em que uma edição toca, pelo que os comentários e o resto ficam como estavam escritos.
+- **Pré-visualização** mostra o que faz, e não edita nada.
+
+O que mostram os separadores Visual e Pré-visualização, secção a secção:
+
+| Secção | Visual | Pré-visualização |
+|---|---|---|
+| **Formulários** | As definições do formulário e os seus campos, com listas dos playbooks, inventários e workflows do designer | O formulário tal como está agora, incluindo as edições não guardadas; o seu envio não executa nada |
+| **Categorias** | As categorias como tabela, editadas | O menu da página Formulários, construído a partir delas |
+| **Constantes** | As constantes como estrutura em árvore, editadas (uma chave move-se com as teclas de seta) | Cada constante com a sua referência, `$(NAME)`, para copiar, e os formulários que a usam |
+| **Ficheiros de variáveis** | As variáveis, editadas | Cada variável com a sua referência num playbook, {% raw %}`{{ name }}`{% endraw %}, para copiar, e os formulários que carregam o ficheiro |
+| **Playbooks** | Os plays: o nome, os hosts, **Become**, **Recolher facts** e as roles de cada play, e as suas tarefas, cada uma com o seu módulo e argumentos | A estrutura do playbook: os seus plays, com os seus hosts, roles e tarefas, e os playbooks que importa |
+| **Inventários** | Os grupos, os seus grupos filhos, os seus hosts e as variáveis que cada um define | O inventário como árvore, com os seus `group_vars` e `host_vars` |
+| **Fluxos de trabalho** | O grafo do workflow, para o [editar](../workflows/designer.html) | Um [ensaio](../workflows/designer.html#trying-it-out): clique num nó para o fazer falhar |
+
+Quando o YAML não pode ser lido, os separadores Visual e Pré-visualização dizem porquê, com **Ver em YAML** para abrir o YAML na linha.
diff --git a/i18n/pt/_use/designer/lock.md b/i18n/pt/_use/designer/lock.md
new file mode 100644
index 0000000..9a1a42f
--- /dev/null
+++ b/i18n/pt/_use/designer/lock.md
@@ -0,0 +1,64 @@
+---
+layout: default
+title: O bloqueio do designer
+parent: Designer
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# O bloqueio do designer
+{: .no_toc }
+
+Uma pessoa edita de cada vez
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Obter o bloqueio
+
+O designer está desligado até o ligar, com o interruptor no canto superior direito do designer. Ligá-lo obtém o
+bloqueio: a partir daí é o único que pode guardar, até o desligar de novo.
+
+Sem o bloqueio, o designer mostra **O designer não está ativo**, e não se pode editar nada.
+
+As gravações nunca se sobrepõem: a partir da 7.3.0, enquanto decorre uma gravação, um push ou um carregamento, um segundo **Guardar** (um duplo clique, ou Ctrl+S mantido) é
+ignorado, para que não possa escrever uma segunda cópia de segurança ou um segundo commit em concorrência com o primeiro.
+
+---
+
+## Quando outra pessoa o tem
+
+Enquanto outro utilizador tem o bloqueio, o designer mostra **O designer está a ser usado por** esse utilizador, e mais nada: nem secções,
+nem ficheiros.
+
+O interruptor aparece ligado mas a cinzento, com **Bloqueado por** e o nome do utilizador ao lado. Pode obter o bloqueio quando ele
+desligar o designer. Todos os designers abertos veem de imediato quando o bloqueio é obtido ou libertado, sem recarregar.
+
+Quando dois utilizadores ligam o designer no mesmo instante, um deles obtém o bloqueio. A partir da 7.3.0, o outro vê quem o tem
+e todos os editores ficam só de leitura, para que não se possa escrever nada que não possa ser guardado.
+
+---
+
+## Libertar o bloqueio de outra pessoa
+
+Um administrador pode libertar um bloqueio que outra pessoa tem, por exemplo quando foi para casa com o designer aberto.
+
+**Libertar**, ao lado de **Bloqueado por**, só aparece para administradores. Pede confirmação primeiro: as alterações do utilizador que não foram guardadas perdem-se.
+
+A partir da 7.3.0, o utilizador cujo bloqueio foi libertado é avisado disso, e por quem: **O seu bloqueio do designer foi libertado por** e o nome do administrador,
+com **As alterações não guardadas já não podem ser guardadas.** O seu designer não volta a obter o bloqueio sozinho; o utilizador liga-o de novo
+quando quiser continuar.
+
+---
+
+## Um bloqueio esquecido
+
+Um bloqueio que ninguém usa liberta-se sozinho, para que ninguém fique à espera de um designer que ninguém tem aberto.
+
+O designer aberto de quem tem o bloqueio continua a dizer ao servidor que ainda está lá. Quando o servidor não tem notícias dele durante
+5 minutos, porque o navegador foi fechado, o computador foi desligado ou a rede caiu, o bloqueio fica de novo livre. Quando
+quem o tinha volta ao designer, este obtém de novo o bloqueio se mais ninguém o tiver. A libertação por um administrador é a exceção: depois dela, o
+bloqueio não volta a ser obtido.
diff --git a/i18n/pt/_use/jobs/actions.md b/i18n/pt/_use/jobs/actions.md
new file mode 100644
index 0000000..89113ec
--- /dev/null
+++ b/i18n/pt/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: Ações sobre tarefas
+parent: Tarefas
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# Ações sobre tarefas
+{: .no_toc }
+
+Lançar, interromper, relançar, aprovar ou rejeitar, e eliminar uma tarefa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Lançar uma tarefa
+
+Todas as tarefas começam num formulário. Abra-o a partir da página **Formulários**, preencha os campos e carregue em **Submeter**:
+
+1. O formulário é validado no navegador, e os valores dos campos são enviados para o servidor.
+2. O servidor cria a tarefa e devolve o seu número; as ações [`onSubmit`](../forms/job-status-action.html) do formulário são executadas.
+3. O resultado da tarefa aparece por baixo do formulário e atualiza-se a cada dois segundos até a tarefa terminar.
+
+A tarefa aparece também na página **Tarefas**, onde a pode acompanhar mais tarde.
+
+### Quem pode lançar um formulário
+
+Um formulário é listado, e pode ser lançado, para os utilizadores que têm uma das [funções](../config/roles.html) da sua lista `roles`.
+A função `default`, que todos os utilizadores têm, torna um formulário disponível para todos os que podem iniciar sessão.
+
+### Antes de submeter
+
+A barra por cima dos campos oferece algumas ferramentas, cada uma mostrada só quando a sua função o permite:
+
+| Botão | O que faz | Opção de função |
+|---|---|---|
+| **Mostrar extravars** | Pré-visualiza as extravars que a tarefa vai receber, à medida que preenche os campos | `showExtraVars` |
+| **verbose** | Executa a tarefa em modo verbose | `allowVerboseMode` |
+| **Carregar dos guardados** | Preenche os campos a partir de uma [tarefa guardada](stored-jobs.html) | `allowStoredJobs` |
+| **Recarregar este formulário** | Carrega de novo o formulário, com os seus valores predefinidos | nenhuma |
+
+### Escolhas no momento do lançamento
+
+Um formulário pode deixar os seus utilizadores escolher algumas opções do Ansible quando o lançam, declarando um campo com um nome reservado. O
+valor do campo sobrepõe-se então à definição do próprio formulário:
+
+| Nome do campo | Sobrepõe-se a | Tipo de campo habitual |
+|---|---|---|
+| `__check__` | Modo check, um ensaio que não altera nada | `checkbox` |
+| `__diff__` | Modo diff, que mostra o que mudaria | `checkbox` |
+| `__limit__` | Os hosts em que o playbook corre | `text` ou `enum` |
+| `__tags__` | As etiquetas a executar | `text` ou `enum` |
+| `__inventory__` | O inventário | `enum` |
+| `__playbook__`, `__template__` | O playbook, ou o template de AWX / AAP | `enum` |
+
+Por exemplo, um formulário que oferece um ensaio e um limite de hosts:
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+O servidor só aceita estes nomes de um formulário que os declare como campos, pelo que um lançamento a partir da API não os pode acrescentar
+por si. As propriedades a que se sobrepõem estão descritas em [Formulários de Ansible](../forms/ansible.html) e [Formulários de AWX](../forms/awx.html).
+
+### O que pode travar um lançamento
+
+Um lançamento nem sempre se torna de imediato uma tarefa em execução:
+
+* **Campos inválidos** : o formulário não é submetido, e cada campo que falha a sua validação mostra porquê.
+* **Validação no lançamento** : com a [validação no lançamento](../launch-validation/) definida como `enforce`, o servidor verifica os valores
+  de novo e recusa um lançamento que viole as regras do formulário.
+* **Aprovação** : um formulário com um [ponto de aprovação](../forms/approval.html) cria a tarefa, que fica depois à espera no estado
+  `approve`; ver [Aprovar ou rejeitar uma tarefa](#approve-or-reject-a-job).
+
+Quando a tarefa termina, as [notificações](../forms/notifications.html) do formulário enviam os seus emails e mensagens para canais, e as suas
+ações conforme o estado da tarefa são executadas.
+
+### Outras formas de iniciar uma tarefa
+
+Um formulário também pode iniciar uma tarefa sem que uma pessoa carregue em **Submeter**:
+
+| Iniciada por | Como | Página |
+|---|---|---|
+| Executar mais tarde ou um agendamento cron | **Executar mais tarde (única)** ou **Agendar (recorrente)** ao lado de **Submeter** | [Agendamentos](schedules.html) |
+| Um script ou um pipeline | `POST /api/v2/job` com um token de API | [Tarefas na API REST](../api/jobs.html) |
+| Um agente de IA | A ferramenta `launch_job` do servidor MCP | [Ferramentas MCP](../mcp/tools.html) |
+| Uma conversa | O assistente de chat preenche o formulário e lança-o | [Assistente de chat](../chat/) |
+| Uma tarefa anterior | **Relançar**, abaixo | [Relançar uma tarefa](#relaunch-a-job) |
+
+---
+
+## Interromper uma tarefa
+
+**Interromper** no menu da linha (⋮) da lista, ou **Interromper tarefa** na página da tarefa, para uma tarefa com o estado `running`. Depois de confirmar,
+o AnsibleForms marca a tarefa para interrupção:
+
+* **`ansible`**: o RTE para o processo do playbook (com todos os seus workers), e a tarefa termina como `aborted` com
+  `... was aborted by the operator`. Uma tarefa ainda à espera de um RTE livre é interrompida antes de arrancar.
+* **Uma tarefa de template** (AWX, AAP, Ascender, Semaphore, Rundeck, Jenkins): o AnsibleForms pede ao runner que cancele ou pare
+  a tarefa, e a tarefa termina como `aborted`. Quando o runner recusa, o resultado mostra `Abort request denied`, seguido de
+  `reverting abort request`, e a tarefa continua em execução. Um build de Jenkins ainda na fila é retirado dela.
+* **`workflow`**: as tarefas dos nós em execução são interrompidas e não arranca mais nada (ver
+  [Executar um workflow](../workflows/running.html#abort)).
+* **`multistep`**: os passos que ainda não arrancaram são saltados (`skipping: [Abort is requested]`), e a tarefa principal
+  termina como `aborted`. Um passo que já está em execução é uma tarefa própria: abra-o e interrompa-o para o parar também.
+
+Pode interromper as suas próprias tarefas; um administrador, ou a partir da 7.3.0 um utilizador cuja função defina `manageAllJobs`, pode interromper qualquer tarefa. `showAllJobLogs` permite a um
+utilizador ver as tarefas de outros utilizadores, não interrompê-las.
+
+---
+
+## Relançar uma tarefa
+
+**Relançar** no menu da linha (⋮) da lista, ou **Relançar tarefa** na página da tarefa, inicia uma nova tarefa a partir de uma terminada. É oferecido em qualquer
+tarefa que não esteja `running` nem à espera de aprovação, aos utilizadores cuja função defina a opção de função `allowJobRelaunch`.
+
+O diálogo oferece:
+
+* **Relançar**: executa a tarefa de novo com os valores com que foi executada, como uma nova tarefa em seu nome.
+* **Modo detalhado**: relança em modo verbose; mostrado com a opção de função `allowVerboseMode`.
+* **Editar os valores antes de relançar**, e depois **Editar e relançar**: abre o formulário preenchido com os valores da tarefa, para que
+  os possa alterar antes de submeter.
+
+Um relançamento exige também que o formulário o permita (`allowRelaunch`, verdadeiro por predefinição) e que a tarefa seja **sua**, a menos que
+seja administrador ou, a partir da 7.3.0, tenha `manageAllJobs`; `showAllJobLogs`, que até à 7.2 relançava qualquer tarefa, já não o faz. A forma como um relançamento é verificado com as regras do formulário, e porque é que um formulário com um
+campo de palavra-passe o pode recusar, está descrita em [Relançar](../launch-validation/relaunching.html).
+
+### Relançar com dados preenchidos
+
+**Editar e relançar** abre o formulário com o parâmetro de URL `prefillJobId`, que também pode usar numa ligação sua:
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+O formulário carrega os valores dos campos guardados com a tarefa `61` e mostra `Formulário preenchido com os dados do trabalho anterior #61`.
+Submetê-lo inicia uma nova tarefa, verificada como qualquer outro lançamento. O preenchimento segue as mesmas regras de um relançamento:
+
+* **Os campos de palavra-passe nunca são guardados**, por isso nunca são preenchidos: introduza-os de novo. As constantes também não são guardadas.
+* É necessária a opção de função `allowJobRelaunch`, e a tarefa tem de ser sua (ou tem de ser administrador ou ter `manageAllJobs`).
+* Um formulário com `allowRelaunch: false` não pode ser relançado nem preenchido:
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+Uma tarefa de antes de os valores dos campos serem guardados não pode ser preenchida, e o formulário mostra antes um erro:
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## Aprovar ou rejeitar uma tarefa
+
+Uma tarefa com um [ponto de aprovação](../forms/approval.html) para no estado `approve` e espera. É listada na página Tarefas dos
+seus aprovadores, os utilizadores com uma das funções da aprovação, para que a possam encontrar; a partir da 7.3.0 os outros utilizadores deixam de a ver.
+
+**Rever aprovação** é oferecido aos administradores e aos utilizadores que têm uma das funções da aprovação: um clique na linha da tarefa,
+**Rever aprovação** no menu da linha, ou o botão **Rever aprovação** na página da tarefa. O diálogo mostra a mensagem
+da aprovação, com os valores da tarefa preenchidos (ou uma linha genérica se não tiver mensagem), e o formulário, o id da tarefa, quem a lançou e
+quando, com uma ligação para a tarefa; **Rejeitar** e **Aprovar** respondem-lhe:
+
+* **Aprovar**: a tarefa continua e o seu estado volta a `running`.
+* **Rejeitar**: a tarefa termina como `rejected`, e o seu resultado regista `rejected by <username>`.
+
+Uma tarefa à espera de aprovação não pode ser relançada nem eliminada a partir da página Tarefas; aprove-a ou rejeite-a primeiro.
+
+A partir da 7.3.0, o utilizador que lançou uma tarefa não a pode aprovar, para que uma segunda pessoa a veja sempre, embora possa ainda rejeitá-la para
+a retirar. Um administrador pode sempre aprovar, incluindo as suas próprias tarefas. Um formulário cujo ponto de aprovação defina
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) permite a quem o lança aprovar também a sua própria tarefa.
+
+---
+
+## Eliminar uma tarefa
+
+**Eliminar** no menu da linha (⋮) da lista, ou **Eliminar tarefa** na página da tarefa, elimina uma tarefa com o seu resultado depois de confirmar.
+Eliminar uma tarefa multistep elimina também os seus passos. Para eliminar várias tarefas de uma vez, marque-as na primeira coluna da lista e
+clique em **Eliminar (n)** por cima dela.
+
+Pode eliminar as suas próprias tarefas. Os administradores e, a partir da 7.3.0, os utilizadores com a opção de função `manageAllJobs` podem eliminar qualquer tarefa; `showAllJobLogs`
+já não pode. Uma função que defina `allowJobDeletion: false` não elimina nenhuma tarefa, nem sequer as suas, para que o histórico de tarefas fique completo. Na página
+da tarefa, o botão fica oculto enquanto a tarefa está em execução ou a ser interrompida (exceto para administradores e `manageAllJobs`) e enquanto aguarda aprovação; na lista, a
+entrada do menu e a caixa de seleção ficam a cinzento para uma tarefa que não pode eliminar.
diff --git a/i18n/pt/_use/jobs/cleanup.md b/i18n/pt/_use/jobs/cleanup.md
new file mode 100644
index 0000000..89ec2d7
--- /dev/null
+++ b/i18n/pt/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: Limpeza
+parent: Tarefas
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# Limpeza
+{: .no_toc }
+
+Tarefas interrompidas por um reinício, e durante quanto tempo se guardam as tarefas terminadas
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tarefas abandonadas
+
+Uma tarefa em execução é seguida pelo processo do AnsibleForms que a iniciou. Quando esse seguimento para, a tarefa é marcada como
+`abandoned`:
+
+* **No arranque**, as tarefas que este processo seguia antes de reiniciar, e as tarefas de antes da 7 que nenhum processo
+  segue, são marcadas como abandonadas se ainda estiverem `running` ou a ser interrompidas; o registo mostra `Abandoned <n> jobs`. Uma tarefa que
+  corre num RTE não é tocada: continua sem o processo que a iniciou.
+* **A cada minuto**, as tarefas seguidas por outro processo do AnsibleForms (ou RTE) que deixou de responder durante 2 minutos são
+  marcadas como abandonadas; o registo mostra `Abandoned <n> jobs followed by a node that stopped answering`.
+* **A cada hora**, as tarefas que começaram há mais de um dia, ainda estão `running` e não escreveram resultado durante um dia são marcadas como abandonadas.
+  Uma tarefa que corre num RTE também é deixada em paz aqui: o RTE limpa as suas próprias tarefas quando reinicia.
+
+A partir da 7.3.0, uma tarefa de template em AWX, AAP ou Ascender que um reinício ou um nó parado abandonou é retomada, se tiver começado
+nas últimas 24 horas: um processo do AnsibleForms assume-a, volta a segui-la no runner, e a tarefa termina com o que
+realmente aconteceu lá. As tarefas nos outros runners, os playbooks, os workflows e as tarefas multistep continuam abandonados.
+
+Um playbook abandonado pode ter sido executado em parte. Verifique os hosts geridos antes de o relançar; ver
+[Uma tarefa mostra o estado abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned).
+
+---
+
+## Retenção de tarefas
+
+As tarefas são guardadas até serem eliminadas, a não ser que o administrador defina um período de retenção.
+
+Com [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) definida, uma tarefa noturna (às 2:30) elimina
+as tarefas terminadas, com o seu resultado e os seus passos, que terminaram há mais desse número de dias. Só remove tarefas com o
+estado `success`, `failed`, `warning`, `aborted`, `rejected` ou `abandoned`, pelo que as tarefas em execução e as tarefas à espera de
+aprovação são mantidas, por mais antigas que sejam. A predefinição, `0`, guarda todas as tarefas.
diff --git a/i18n/pt/_use/jobs/following.md b/i18n/pt/_use/jobs/following.md
new file mode 100644
index 0000000..faa0a08
--- /dev/null
+++ b/i18n/pt/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: Acompanhar uma tarefa
+parent: Tarefas
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# Acompanhar uma tarefa
+{: .no_toc }
+
+Resultado em direto, extravars, filtros e transferências
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Acompanhar uma tarefa
+
+Clicar numa tarefa abre a sua página: o formulário da tarefa como título, as suas ações no cabeçalho e o seu resultado por baixo.
+
+![O resultado de uma tarefa](../assets/screenshots/job-output.jpg)
+
+A partir da 7.3.0, a página é feita de cartões, e cada um recolhe-se sob o seu cabeçalho:
+
+| Cartão | O que mostra |
+|---|---|
+| **Resumo** | O nome, o estado e o tipo da tarefa como cabeçalho, e os seus dados por baixo numa grelha de três colunas (duas, e depois uma, numa página estreita) |
+| **Fluxo de trabalho** | Para uma tarefa de workflow, e também uma tarefa de workflow de AWX ou AAP, o seu grafo e o seu número de nós (ver [O grafo do workflow](#the-workflow-graph)) |
+| **Saída** | O resultado da tarefa e a sua barra de ferramentas |
+
+Uma tarefa que correu em AWX, AAP, Ascender, Jenkins, Semaphore ou Rundeck mostra aí o seu número como uma ligação para a sua página nessa ferramenta, aberta
+num novo separador. A ligação fica guardada na tarefa, pelo que continua a funcionar quando o runner é renomeado ou removido mais tarde.
+
+A página atualiza-se em direto: o servidor envia um evento sempre que uma tarefa é lançada, muda de estado, escreve resultado ou é
+eliminada, e a página lê de novo a tarefa, pelo que o resultado cresce à medida que a tarefa o escreve. A lista de tarefas atualiza-se da mesma forma.
+**Atualizar** recarrega a tarefa manualmente.
+
+Enquanto estiver no fim do resultado, a página acompanha-o para baixo à medida que chegam novas linhas. Desloque-se para cima para ler uma linha anterior
+e a página fica onde está: aparece então **Ir para as mais recentes** sobre o fundo do resultado, que passa a **Linhas novas** quando
+chegarem mais. Clique nele, ou desloque-se de novo até ao fim, para voltar a acompanhar as linhas novas. O resultado na página do formulário, depois de
+**Submeter**, e o [registo do servidor](../production/logs.html) acompanham as suas linhas novas da mesma forma.
+
+A barra de ferramentas do resultado tem:
+
+| Botão | O que faz |
+|---|---|
+| **Mostrar extravars** | Mostra as extravars com que a tarefa correu num painel sobre o resultado, com um seletor **JSON** / **YAML** e **Copiar** |
+| **Mostrar artefactos** | Mostra os artefactos da tarefa no mesmo painel (ver abaixo) |
+| **Mostrar parâmetros** | Ocupa o lugar de **Mostrar extravars** numa tarefa de Jenkins: os valores com que correu, os seus parâmetros de build |
+| **Mostrar payload** | Ocupa o lugar de **Mostrar extravars** numa tarefa de Rundeck: o payload que lhe foi enviado |
+| **Hosts e tarefas** | Mostra os hosts e as tarefas de um playbook sobre o seu resultado (ver [Hosts e tarefas](#hosts-and-tasks)) |
+| **Atualizar** | Recarrega o resultado |
+| **Aplicar filtro** | Oculta as tarefas cujo nome corresponde ao filtro do resultado; **Remover filtro** volta a mostrá-las |
+| **Copiar resultado** | Copia o resultado como texto simples, com ou sem o filtro aplicado |
+| **Transferir resultado** | Transfere o resultado como `ansibleforms-job-<id>.txt` |
+
+**Mostrar artefactos** é oferecido para todas as tarefas que não sejam de template, como um playbook no RTE ou um workflow (vazio quando
+os seus playbooks não recolheram artefactos com `set_stats`), e para uma tarefa de template que correu em AWX, AAP ou Ascender. As tarefas de Semaphore, Rundeck
+e Jenkins não têm artefactos, por isso nunca é oferecido para elas.
+
+À esquerda da barra de ferramentas, o botão **Recolher tudo** recolhe todas as secções do resultado (cada play e cada tarefa) e passa a
+**Expandir tudo**, que as volta a expandir.
+
+**Mostrar extravars** exige a opção de função `showExtravars` e **Mostrar artefactos** a opção de função `showArtifacts` (ver
+[opções de função](../config/roles.html#role-options)). Os valores dos campos de palavra-passe e das chaves que correspondem a
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) são ocultados.
+
+O filtro é definido por [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT), `\[low\]` por
+predefinição. Ponha `[low]` no nome de uma tarefa ruidosa, e **Aplicar filtro** oculta essa tarefa e as suas linhas.
+
+A página de uma tarefa multistep mostra todos os passos por baixo da tarefa principal, um por baixo do outro, cada um sob uma barra de título como
+**Passo 1 · Prepare the server (id da tarefa 98)** com o seu estado. Clique num título (ou carregue em Enter ou Espaço sobre ele) para recolher esse resultado,
+e de novo para o expandir. Os workflows de AWX/AAP mostram também o estado dos seus nós.
+
+As tarefas de [workflow](../workflows/running.html#the-job) guardam o resultado de cada nó no seu próprio, sob um cabeçalho `WORKFLOW NODE` por
+nó; desenham o seu grafo, em direto, e um clique num nó abre o seu resultado.
+
+---
+
+## Procurar um texto no resultado
+
+A partir da 7.3.0, a página da tarefa tem uma caixa de pesquisa, **Procurar na saída**, na sua linha de título, à esquerda das ações da tarefa.
+
+Cada sítio onde o texto aparece no resultado é destacado, sem distinguir maiúsculas de minúsculas, e a página desloca-se até ao primeiro. **Enter** vai para
+o seguinte, mostrado com mais destaque, e a barra de ferramentas diz qual de quantos (**2 de 4**), ou **Não encontrado**. A pesquisa expande primeiro o resultado e
+as suas secções, e enquanto a tarefa corre as linhas novas também são pesquisadas, sem deslocar a página.
+
+---
+
+## Percorrer um resultado longo
+
+A partir da 7.3.0, um resultado longo, na página da tarefa e por baixo de um formulário depois de **Submeter**, tem estas formas de o percorrer:
+
+| Controlo | O que faz |
+|---|---|
+| Cabeçalhos fixos | O cabeçalho de uma secção (um nó de workflow, o playbook da tarefa, o passo de uma tarefa multistep) fica no topo enquanto as suas linhas passam |
+| **2 falhadas** | Conta as tarefas falhadas, deixando de fora as falhas que o Ansible foi instruído a ignorar; cada clique vai para a seguinte, expandida e destacada. Sem tarefas falhadas, **1 erro** conta antes as linhas de erro |
+| Números de linha | Cada número de linha é uma ligação para a sua linha, como `#L45` no endereço: abrir esse endereço desloca até à linha e destaca-a |
+| Botões para cima e para baixo | Mostrados no canto inferior direito depois de a página ser deslocada, para voltar ao topo ou ir para o fim |
+| **Em execução** e **Interromper** | Enquanto a tarefa corre, a barra da página do formulário fica presa ao fundo da janela, e **Interromper** aí para a tarefa de imediato |
+
+---
+
+## Resultados das tarefas
+
+A partir da 7.3.0, a linha de resultado de um host no resultado de um playbook abre esse resultado num diálogo **Resultado da tarefa**, como faz o AWX.
+
+A linha, o corpo do resultado a seguir a ela (`=> { ... }`) e o erro escrito antes de um resultado falhado destacam-se como um só bloco ao passar o rato, e um
+clique abre o diálogo. Funciona na página da tarefa e por baixo de um formulário depois de **Submeter**, para um playbook que correu num RTE da 7.3.0 ou
+posterior, já que o resultado vem dos mesmos eventos que [Hosts e tarefas](#hosts-and-tasks). O diálogo tem estes separadores:
+
+| Separador | O que mostra |
+|---|---|
+| **Detalhes** | O estado, o host, o play, a tarefa, o módulo, o item do ciclo, a hora de início, a duração, o código de retorno e a mensagem |
+| **JSON** e **YAML** | O resultado completo do módulo, colorido e com as linhas numeradas |
+| **Saída padrão** e **Erro padrão** | O `stdout` e o `stderr` do resultado, quando os tem |
+
+O resultado completo, e com ele os separadores **JSON**, **YAML** e de saída, só é guardado quando a tarefa corre em modo verbose, já que o resultado
+também o mostra nesse caso; caso contrário, o diálogo mostra só os detalhes. Mesmo em modo verbose, os argumentos do módulo (`invocation`) ficam
+de fora, os valores das chaves que se parecem com um segredo são ocultados, e um resultado é cortado quando ultrapassa 64 KB de JSON.
+
+---
+
+## O grafo do workflow
+
+A partir da 7.3.0, o grafo de um workflow em execução desliza para manter à vista o nó em execução.
+
+Desloque o grafo para outro lado e ele fica onde o deixou, com um botão **Seguir o nó em execução** para o voltar a seguir. Passar o rato sobre um nó
+mostra o seu cartão com o nome completo e coloca em foco o nó e as suas ligações, com o resto do grafo esbatido. O grafo tem os botões **Ajustar ao
+ecrã** e **Ecrã inteiro**, e por baixo de um formulário depois de **Submeter** um clique num nó abre o seu resultado tal como na página da tarefa.
+
+---
+
+## Hosts e tarefas
+
+Desde a 7.3.0, uma tarefa de playbook que correu num RTE da 7.3.0 ou posterior regista os seus eventos estruturados ao lado do seu resultado em texto: cada play, tarefa
+e resultado de host, e o resumo final. **Hosts e tarefas**, na barra de ferramentas do resultado, mostra-os num painel sobre o resultado, na página da tarefa e
+por baixo de um formulário depois de **Submeter**. É oferecido assim que a tarefa tem eventos, e o painel é lido de novo a cada poucos segundos enquanto a tarefa corre:
+
+| Vista | O que mostra |
+|---|---|
+| **Grelha** | O resumo por host (ok, alterados, falhados, inacessíveis, saltados, recuperados, ignorados), e depois uma grelha de hosts por tarefas: cada célula tem a cor do resultado do host nessa tarefa, com a sua mensagem e tempo ao passar o rato, ou *não executada* |
+| **Cronologia** | Cada tarefa como uma barra, tão longa quanto demorou o seu host mais lento, com o seu tempo em segundos e o total |
+
+O resultado em texto fica como está. Os eventos são escritos pelo próprio plugin de callback `af_events` do RTE, pelo que o playbook não precisa de nenhuma alteração.
diff --git a/i18n/pt/_use/jobs/index.md b/i18n/pt/_use/jobs/index.md
new file mode 100644
index 0000000..70467bd
--- /dev/null
+++ b/i18n/pt/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Tarefas
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# Tarefas
+{: .no_toc }
+
+Acompanhar, interromper, relançar, aprovar e eliminar as tarefas que os seus formulários iniciam
+{: .fs-6 .fw-300 }
+
+---
+
+Para todos os que lançam formulários: o que é uma tarefa, onde a encontrar e quem a pode ver.
+
+---
+
+## O que é uma tarefa
+
+Uma tarefa é uma execução de um formulário: o AnsibleForms regista-a com o seu estado, extravars e resultado assim que o formulário é submetido.
+
+Cada tarefa guarda:
+
+* o **formulário** que executou e o **utilizador** que a lançou (com o tipo de utilizador, como `local` ou `ldap`);
+* o seu **tipo de tarefa** e **estado**, e a sua **hora de início** e **hora de fim**;
+* o seu **resultado**, as extravars e as credenciais com que foi executada, e os valores dos campos introduzidos no formulário.
+
+Um formulário multistep cria uma tarefa para o formulário e uma tarefa por passo. Os passos estão ligados à tarefa principal e são listados por baixo dela.
+
+As mesmas tarefas podem ser lançadas, acompanhadas e geridas através da [API REST](../api/jobs.html).
+
+---
+
+## A página Tarefas
+
+A ligação **Tarefas** no cabeçalho abre a lista de todas as tarefas, das mais recentes para as mais antigas (`/jobs/all`). A página e a sua ligação são mostradas aos utilizadores
+cuja função define a [opção de função](../config/roles.html#role-options) `showJobs`.
+
+![A lista de tarefas](../assets/screenshots/job-log.jpg)
+
+O menu da esquerda organiza as tarefas no tempo, com o número de tarefas em cada entrada; uma entrada de estado filtra a lista por esse estado:
+
+| Secção | Entrada do menu | Mostra |
+|---|---|---|
+| **Passado** | **Bem-sucedidas** | Tarefas com o estado `success` |
+| | **Falhadas** | Tarefas com o estado `failed` |
+| | **Interrompidas** | Tarefas com o estado `aborted` |
+| | **Rejeitado** | Tarefas com o estado `rejected` |
+| | **Abandonado** | Tarefas com o estado `abandoned` |
+| **Presente** | **Em execução** | Tarefas com o estado `running` |
+| | **À espera de aprovação** | Tarefas com o estado `approve`; a contagem fica laranja quando há uma à espera |
+| **Futuro** | **Agendados** | A página [Agendamentos](schedules.html) (opção de função `allowScheduledJobs`) |
+| | **Guardados** | A página [Tarefas guardadas](stored-jobs.html) (opção de função `allowStoredJobs`) |
+
+O menu não tem nenhuma entrada para todas as tarefas: a ligação **Tarefas** do cabeçalho mostra-as todas, incluindo as tarefas `warning`.
+
+Por cima da tabela, na linha do título:
+
+* a **caixa de pesquisa** mantém as tarefas cujas colunas visíveis contêm o texto (sem distinguir maiúsculas de minúsculas), ou que tenham um passo com esse texto como id
+  ou destino;
+* **Eliminar** (com o número de tarefas marcadas) elimina em conjunto as tarefas marcadas na primeira coluna;
+* **Colunas** mostra ou oculta as colunas `id`, `form`, `job type`, `status`, `start time`, `end time`, `duration` e `user`;
+  a duração de uma tarefa em execução vai aumentando;
+* **Atualizar** recarrega a lista.
+
+A lista carrega as tarefas mais recentes, tantas quantas indica a definição [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)
+(**Definições > Sistema > Geral**, separador **Tarefas**, `1000` por predefinição); as suas páginas, a pesquisa e os filtros abrangem essas tarefas.
+
+Cada coluna pode ser ordenada e tem o seu próprio campo de filtro. Uma tarefa multistep tem uma seta mesmo antes do seu `form` que expande
+os seus passos; um clique no resto de uma linha abre a tarefa.
+
+O sino do cabeçalho conta as tarefas que aguardam a sua aprovação e abre a lista em **À espera de aprovação**. Para os utilizadores que podem ver
+os runners, conta também os [runners a aguardar aprovação](../runners/registration.html#approving-an-rte), RTE que pediram para se juntar,
+e abre **Ligações > Runners** quando só há runners à espera. Com ambos à espera, abre um menu, **Trabalhos a aguardar aprovação** e
+**Runners a aguardar aprovação**, cada um com a sua contagem.
+
+---
+
+## Quem vê que tarefas
+
+As tarefas que um utilizador vê dependem das suas funções:
+
+| Utilizador | Vê |
+|---|---|
+| Administrador (função `admin`) | Todas as tarefas |
+| Opção de função `showAllJobLogs` | Todas as tarefas |
+| Opção de função `manageAllJobs` (a partir da 7.3.0) | Todas as tarefas, e pode interrompê-las, eliminá-las e relançá-las |
+| Qualquer outro utilizador | As suas próprias tarefas, e as tarefas que aguardam uma aprovação que indique uma das suas funções |
+
+Até à 7.2, qualquer utilizador podia abrir qualquer tarefa à espera de aprovação, incluindo as suas extravars e o seu resultado; a partir da 7.3.0 só o seu dono e os seus
+aprovadores o podem fazer. Ver uma tarefa não concede todas as ações sobre ela: interromper, eliminar e relançar a tarefa de outro utilizador exige ser administrador ou
+ter `manageAllJobs`, e `showAllJobLogs` só mostra as tarefas. Eliminar também precisa de `allowJobDeletion` e relançar de `allowJobRelaunch`.
+
+---
+
+## Nesta secção
+
+Cada tema tem a sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Estados e tipos](statuses.html) | Todos os estados que uma tarefa pode ter, e os tipos de tarefa |
+| [Acompanhar uma tarefa](following.html) | Resultado em direto, extravars, filtros e transferências |
+| [Ações sobre tarefas](actions.html) | Lançar, interromper, relançar, aprovar ou rejeitar, e eliminar uma tarefa |
+| [Agendamentos](schedules.html) | Executar um formulário mais tarde ou segundo um agendamento cron, e gerir todos os agendamentos |
+| [Tarefas guardadas](stored-jobs.html) | Guardar os dados de um formulário para os carregar de novo mais tarde |
+| [Limpeza](cleanup.html) | Tarefas interrompidas por um reinício, e durante quanto tempo se guardam as tarefas terminadas |
diff --git a/i18n/pt/_use/jobs/schedules.md b/i18n/pt/_use/jobs/schedules.md
new file mode 100644
index 0000000..a05a455
--- /dev/null
+++ b/i18n/pt/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: Agendamentos
+parent: Tarefas
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# Agendamentos
+{: .no_toc }
+
+Executar um formulário mais tarde ou segundo um agendamento cron, e gerir todos os agendamentos
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## As ações do formulário
+
+Um formulário pode fazer mais do que executar de imediato: a lista pendente ao lado do seu botão **Submeter** contém mais três ações.
+
+| Ação | O que faz | Opção de função |
+|---|---|---|
+| **Agendar (recorrente)** | Cria um agendamento que executa o formulário segundo uma expressão cron | `allowScheduledJobs` |
+| **Executar mais tarde (única)** | Cria um agendamento que executa o formulário uma vez, numa data e hora que escolher | `allowPlannedJobs` |
+| **Guardar** | Guarda os valores dos campos, para os carregar de novo no formulário mais tarde | `allowStoredJobs` |
+
+Uma ação cuja opção de função esteja desligada não é mostrada. O formulário é validado antes de qualquer uma delas, tal como para **Submeter**. Ambas
+as ações de agendamento criam uma entrada na página **Agendamentos**; **Guardar** cria uma entrada na página **Tarefas guardadas**. A
+barra lateral da página [Tarefas](./) abre-as em **Futuro**, como **Agendados** e **Guardados**. As opções de função estão descritas
+em [Opções de função](../config/roles.html#role-options).
+
+{: .warning }
+> Trate `allowScheduledJobs` como uma opção de nível de administrador. Os seus agendamentos não pertencem ao utilizador que os criou: todos os utilizadores
+> com a opção veem e podem alterar todos os agendamentos. Um agendamento destes também corre com direitos de administrador, para qualquer formulário, seja qual for
+> o acesso próprio de quem o criou. Conceda-a apenas a funções em que confiaria como administradores.
+
+{: .note }
+> **Executar mais tarde (única)** só precisa de `allowPlannedJobs`. Para um utilizador sem `allowScheduledJobs`, planeia uma execução **como esse
+> utilizador**: o servidor verifica que o utilizador pode executar o formulário, e a tarefa corre como ele, pertencendo-lhe, quando chegar a hora
+> (ver [Execuções planeadas](#planned-runs)).
+
+---
+
+## Agendar um formulário
+
+Preencha o formulário, abra a lista pendente ao lado de **Submeter** e escolha uma das ações de agendamento.
+
+- **Agendar (recorrente)** abre **Criar agendamento**: introduza um **Nome** e uma **Expressão Cron** (a predefinição, `0 0 * * *`,
+  executa diariamente à meia-noite), e selecione **Criar agendamento**.
+- **Executar mais tarde (única)** abre **Executar mais tarde**: introduza um **Nome** e escolha a data e hora em **Executar em**, e selecione
+  **Agendar tarefa**.
+
+O nome tem de ser único entre todos os agendamentos. O agendamento guarda o nome do formulário e uma cópia das extravars que o formulário produziu
+nesse momento, escritas em YAML; cada execução usa essa cópia, por isso edite-a na página **Agendamentos** para mudar o que a tarefa recebe.
+
+![Agendamentos](../assets/screenshots/schedules.jpg)
+
+---
+
+## A página Agendamentos
+
+A página **Agendamentos** lista todos os agendamentos, com a sua coluna **Ativado** a partir da 7.3.0, e precisa de `allowScheduledJobs`. O menu de cada linha oferece:
+
+| Ação | O que faz |
+|---|---|
+| **Editar** | Altera o nome, o tipo, a expressão cron ou a hora de execução, o formulário e as extra vars |
+| **Executar agora** | Executa o agendamento agora, sem esperar pela sua expressão cron ou hora de execução |
+| **Ativar** ou **Desativar** | Liga ou desliga o agendamento, conforme o caso, como mostra a sua coluna **Ativado** (a partir da 7.3.0) |
+| **Eliminar** | Remove o agendamento; deixa de correr de imediato |
+| **Último resultado** | Na página do agendamento, o que a última execução reportou, como o número da tarefa que iniciou |
+
+Também se pode criar aqui um agendamento de raiz. Escolha o **Formulário** e depois marque **Execução única** e defina
+**Executar em**, ou deixe-a desmarcada e defina um **Agendamento cron**. **Extra vars** é YAML sem formulário que o preencha, por isso acrescente
+você mesmo os valores de que o playbook precisa, como um dicionário (pares chave: valor).
+
+O campo **Agendamento cron** é um editor de cron: descreve a expressão por palavras, oferece predefinições e pré-visualiza as próximas
+execuções. O servidor recusa uma expressão que não consiga executar, ou uma que nunca possa ocorrer.
+
+A partir da 7.3.0, cada agendamento tem um interruptor **Ativado**, para o pausar sem o eliminar. Um agendamento desligado continua na página
+com as suas definições, mas não corre sozinho: um recorrente salta os seus disparos cron, e um único espera para além do seu
+**Executar em** até ser ligado de novo. **Executar agora** continua a executá-lo a pedido. Um agendamento novo está ligado, e os agendamentos
+que existiam antes da 7.3.0 ficam ligados depois da atualização.
+
+---
+
+## Expressões cron e fuso horário
+
+Um agendamento recorrente aceita uma expressão cron padrão de 5 campos: minuto, hora, dia do mês, mês e dia da semana.
+
+| Expressão | Executa |
+|---|---|
+| `*/15 * * * *` | A cada 15 minutos |
+| `0 2 * * *` | Todos os dias às 02:00 |
+| `30 7 * * 1-5` | De segunda a sexta às 07:30 |
+| `0 0 1 * *` | À meia-noite do primeiro dia de cada mês |
+
+Mais exemplos, e as funcionalidades de cron que o editor não aceita, estão nas FAQ em
+[Que expressões cron posso usar?](../faq.html#which-cron-expressions-can-i-use).
+
+{: .note }
+> Os agendamentos cron correm no fuso horário do servidor, definido com [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) (predefinição `UTC`),
+> não no fuso horário do seu perfil nem do seu navegador. O editor de cron pré-visualiza as próximas execuções nesse mesmo fuso.
+
+---
+
+## Como corre um agendamento
+
+Quando um agendamento chega à hora, é colocado em fila, e o servidor inicia os agendamentos em fila um de cada vez, verificando a fila a cada 10 segundos.
+
+- **Os agendamentos recorrentes** saltam um disparo enquanto a execução anterior ainda está em fila ou em execução, pelo que as execuções nunca se sobrepõem.
+- **Os agendamentos únicos** correm no minuto seguinte a **Executar em**, e depois são eliminados, também quando iniciados com **Executar agora**.
+- **Estado** é `success` quando a tarefa foi iniciada e `failed` quando não pôde ser. Um `success` só diz que a tarefa foi
+  lançada: abra a tarefa para ver como terminou.
+
+Um agendamento criado com `allowScheduledJobs` corre como o utilizador incorporado `Schedule Service` (tipo `schedule`) com a
+função `admin`. Pode executar qualquer formulário, seja qual for o acesso da pessoa que criou o agendamento, e `ansibleforms_user` nas
+suas extravars descreve esse utilizador. Uma [execução planeada](#planned-runs), pelo contrário, corre como o utilizador que a planeou.
+
+A tarefa recebe também um objeto `schedule` (com o seu `id`, `name` e `form`), para que um playbook saiba que foi um agendamento que o iniciou:
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## Execuções planeadas
+
+**Executar mais tarde (única)** por um utilizador sem `allowScheduledJobs` cria uma execução planeada: um agendamento único ligado a esse utilizador.
+
+- **Quando é planeada**, o servidor verifica que o utilizador pode executar o formulário (os seus `roles`), e o modo verbose precisa de
+  `allowVerboseMode`. Uma execução planeada é sempre única; uma expressão cron é recusada.
+- **Com a validação no lançamento em `enforce`**, os valores dos campos são verificados quando é planeada, para que uma execução que seria recusada seja
+  recusada enquanto o utilizador ainda está a olhar.
+- **Quando corre**, a tarefa corre como esse utilizador, pertencendo-lhe, passando pelas mesmas verificações que um lançamento a partir do navegador: as
+  funções do formulário tal como estão nesse momento, as extravars reservadas retiradas, e a validação no lançamento. `ansibleforms_user` descreve-o.
+
+Quem planeia não vê a página **Agendamentos**, que precisa de `allowScheduledJobs`; a tarefa aparece no seu próprio histórico de tarefas.
+
+---
+
+## Quando o formulário muda
+
+Um agendamento refere-se ao seu formulário pelo nome e executa-o tal como está definido no momento de cada execução.
+
+- **O formulário é editado**: a execução seguinte usa a nova definição (playbook, template, inventário) com as extravars guardadas
+  no agendamento. O formulário não é construído, pelo que nenhum campo é recalculado; edite as extra vars do agendamento para corresponderem.
+- **O formulário é renomeado ou removido**: a execução falha, **Estado** passa a `failed` e **Último resultado** diz
+  `Failed to launch : No such form '<name>'`. Edite o agendamento e escolha o formulário certo, ou elimine-o.
+
+---
+
+## Tarefas agendadas no histórico de tarefas
+
+Cada execução de um agendamento cria uma tarefa normal, listada na página [Tarefas](./) com `Schedule Service` como utilizador ou,
+numa execução planeada, com o utilizador que a planeou.
+
+Uma tarefa de `Schedule Service` não pertence à pessoa que criou o agendamento, pelo que só é visível para os administradores e para
+os utilizadores com `showAllJobLogs`; a tarefa de uma execução planeada também é visível para o seu utilizador. O **Último resultado** do agendamento indica a tarefa que iniciou, para que a possa encontrar na lista.
diff --git a/i18n/pt/_use/jobs/statuses.md b/i18n/pt/_use/jobs/statuses.md
new file mode 100644
index 0000000..54601a1
--- /dev/null
+++ b/i18n/pt/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: Estados e tipos
+parent: Tarefas
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# Estados e tipos
+{: .no_toc }
+
+Todos os estados que uma tarefa pode ter, e os tipos de tarefa
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Estados das tarefas
+
+O AnsibleForms define os seguintes estados numa tarefa. A lista mostra cada estado como uma etiqueta colorida:
+
+| Estado | Significado | O que pode fazer |
+|---|---|---|
+| `running` | A tarefa está em execução, ou uma tarefa aprovada foi retomada | Acompanhar o seu resultado, interrompê-la |
+| `approve` | A tarefa espera num [ponto de aprovação](../forms/approval.html) antes de correr (ou antes de correr um passo de um multistep) | Aprová-la ou rejeitá-la, se uma das suas funções for aprovadora |
+| `success` | O playbook, o template ou todos os passos terminaram sem erros | Ver o resultado, relançar, eliminar |
+| `failed` | A tarefa terminou com um erro, ou o próprio lançamento falhou | Ver o resultado para saber porquê, relançar, eliminar |
+| `warning` | Um multistep terminou, mas falhou um passo que tem `continue` definido | Ver o resultado, relançar, eliminar |
+| `aborted` | A tarefa foi interrompida a partir do AnsibleForms, ou a tarefa de AWX / AAP foi cancelada | Ver o resultado, relançar, eliminar |
+| `rejected` | Um aprovador rejeitou a tarefa; nunca chegou a correr | Ver o resultado, relançar, eliminar |
+| `abandoned` | O AnsibleForms deixou de seguir a tarefa (ver [Tarefas abandonadas](cleanup.html#abandoned-jobs)) | Verificar os hosts geridos, relançar, eliminar |
+
+`running` é azul, `success` verde e lê-se **Bem-sucedidas**, e `failed` vermelho. `approve` é laranja e lê-se **À espera de aprovação**,
+para que uma tarefa à espera de uma pessoa se distinga das paradas; `warning`, `aborted` e `rejected` são âmbar. `abandoned` é
+cinzento: ninguém a parou, o que a executava desapareceu.
+
+---
+
+## Tipos de tarefa
+
+O tipo de tarefa segue o `type` do formulário que iniciou a tarefa, tal como a lista e a página da tarefa o mostram:
+
+| Tipo mostrado | O que corre |
+|---|---|
+| `ansible` | Um playbook de Ansible, executado num RTE |
+| `awx`, `aap`, `ascender` | Um job template ou workflow template em AWX, AAP ou Ascender |
+| `semaphore` | Um template no Semaphore UI |
+| `rundeck`, `jenkins` | Um job em Rundeck ou Jenkins |
+| `workflow` | Um [workflow](../workflows/), cujos nós de playbook correm como tarefas próprias por baixo dele |
+| `multistep` | Obsoleto, use `workflow`: uma sequência de passos, cada um registado como uma tarefa própria por baixo da tarefa principal |
+
+Uma tarefa de template é guardada como tarefa `awx` (também na API REST) e mostrada com o tipo de runner em que correu, independentemente
+de como o formulário lhe chamou: um formulário do tipo `awx` que corre num runner AAP mostra `aap`.
+
+Ver [Formulários de Ansible](../forms/ansible.html), [Formulários de AWX](../forms/awx.html), [Formulários de workflow](../forms/workflow.html) e
+[Formulários de vários passos](../forms/multistep.html) para o lado do formulário.
diff --git a/i18n/pt/_use/jobs/stored-jobs.md b/i18n/pt/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..8891d93
--- /dev/null
+++ b/i18n/pt/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Tarefas guardadas
+parent: Tarefas
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# Tarefas guardadas
+{: .no_toc }
+
+Guardar os dados de um formulário para os carregar de novo mais tarde
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Tarefas guardadas
+
+As tarefas guardadas mantêm os valores de um formulário para que os possa carregar de novo, em vez de preencher sempre os mesmos campos.
+
+Para guardar, preencha o formulário, abra a lista pendente ao lado de **Submeter** e escolha **Guardar**. Em **Guardar dados do formulário**, introduza um
+**Nome**, uma **Descrição** opcional e uma data em **Expira em (opcional)**, e guarde. Os campos de palavra-passe e de constantes
+nunca são guardados. Um subformulário tem a mesma ação **Guardar** ao lado do seu botão **Guardar**, e mantém valores inacabados sem
+os validar.
+
+Para carregar, selecione **Carregar dos guardados** no topo do formulário. **Carregar formulário guardado** lista as suas tarefas guardadas para esse formulário, com
+as suas datas de criação e de expiração; selecione uma para preencher o formulário com os seus valores. Nada corre até submeter.
+
+As tarefas guardadas ficam na base de dados do AnsibleForms (tabela `stored_jobs`), com o nome do formulário, o seu utilizador como
+`<type>/<username>` (por exemplo `local/admin`) e os valores em JSON. Um nome tem de ser único por utilizador e formulário; guardar
+uma segunda com o mesmo nome falha com "Já existe um formulário guardado com este nome".
+
+---
+
+## Gerir as tarefas guardadas
+
+A página **Tarefas guardadas** lista as tarefas guardadas com o seu formulário, utilizador e datas de criação e de expiração, e precisa de `allowStoredJobs`.
+
+- **Editar** abre a página própria da tarefa guardada: os seus **Detalhes** (nome, formulário, expiração) e os seus **Valores**, os
+  valores dos campos guardados em YAML, que aí podem ser alterados e guardados.
+- **Abrir no formulário** abre o seu formulário com os valores guardados preenchidos; nada corre até submeter.
+- **Eliminar** remove-a. Pode eliminar as suas próprias tarefas guardadas; os utilizadores com `showSettings` podem eliminar qualquer uma.
+- As tarefas guardadas com uma data em **Expira em** no passado são eliminadas automaticamente todos os dias às 04:00 (em `LOG_TZ`).
diff --git a/i18n/pt/_use/profile/account.md b/i18n/pt/_use/profile/account.md
new file mode 100644
index 0000000..e333bb2
--- /dev/null
+++ b/i18n/pt/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Conta
+parent: O seu perfil
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# Conta
+{: .no_toc }
+
+Com que utilizador iniciou sessão
+{: .fs-6 .fw-300 }
+
+---
+
+A vista Conta mostra com que utilizador iniciou sessão e o que determina o seu acesso:
+
+- **Nome de utilizador** e **Tipo de início de sessão**: uma conta local, LDAP, Microsoft Entra ID ou OpenID Connect.
+- **Grupos**: os grupos que vêm com o seu início de sessão, como `local/admins` ou `ldap/Domain Admins`.
+- **Funções**: as funções do `config.yaml` que correspondem a esses grupos e ao seu utilizador. Determinam
+  que formulários vê e que opções tem.
diff --git a/i18n/pt/_use/profile/api-token.md b/i18n/pt/_use/profile/api-token.md
new file mode 100644
index 0000000..13cb363
--- /dev/null
+++ b/i18n/pt/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Token de API
+parent: O seu perfil
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# Token de API
+{: .no_toc }
+
+Criar um token para scripts e agentes de IA
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Quem pode criar um
+
+Um token de longa duração permite que os scripts chamem a API sem a sua palavra-passe. A partir da 7.3.0 precisa da opção de função `allowApiTokens`:
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+Até à 7.2.0, a opção era só `extendedTokenExpiration`. Uma função de antes da 7.3.0 que defina só essa opção recebe
+`allowApiTokens`, para manter os seus tokens; com ambas, também se pode criar um token que nunca expira. Ver [Opções de função](../config/roles.html#role-options).
+
+---
+
+## Criar um token
+
+**Novo token**, na linha de título de **Perfil > Tokens de API**, abre um assistente em três passos:
+
+1. **Detalhes**: um nome, para reconhecer o token na lista, e durante quanto tempo se mantém válido. As opções são 30, 90, 180
+   ou 365 dias até [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) (90 por predefinição), esse
+   próprio máximo, e **Nunca expira** com `extendedTokenExpiration`. Escolha o período mais curto de que o seu script precisa.
+2. **Confirmar**: uma conta local ou LDAP introduz a sua palavra-passe, que não é guardada no token. Uma conta Microsoft Entra ID ou
+   OIDC não tem aqui palavra-passe: o seu token é criado a partir da sua sessão, que tem de ter iniciado sessão no máximo 10 minutos
+   antes, pelo que o fornecedor pode pedir-lhe primeiro que inicie sessão de novo.
+3. **Copiar**: o token, mostrado **só uma vez**. Copie-o com **Copiar** e guarde-o com o mesmo cuidado que uma palavra-passe.
+
+Envie o token no cabeçalho `Authorization` de cada chamada à API:
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+Um token de API não pode criar outro. O token de uma conta SSO leva as funções do seu último início de sessão: uma mudança de grupo no
+fornecedor de identidade só lhe chega quando iniciar sessão de novo e criar um novo token.
+
+---
+
+## Os seus tokens
+
+Os tokens que criou são listados com o seu nome e quando cada um foi criado, expira e foi usado pela última vez; **Revogar** no menu de uma linha termina-o.
+Um administrador também os vê e revoga na sua página em **Definições > Utilizadores**. Um token termina na sua data de expiração, ou antes:
+
+- **uma revogação**, a partir da lista;
+- **um fim de sessão com o token** (`POST /api/v2/auth/logout` com o token no cabeçalho `Authorization`), que o termina juntamente com
+  a sessão em que foi criado;
+- **uma alteração da palavra-passe**, que termina todos os tokens e sessões da sua conta criados antes dela, e um bloqueio da sua conta.
+
+Um token que nunca expira também termina nestes casos. Um script também pode pedir ele próprio um token através da API de início de sessão e do
+seu parâmetro `expiryDays` (`POST /api/v2/auth/login?expiryDays=90`, ou `expiryDays=never`); um `expiryDays` mais longo é reduzido
+a `API_TOKEN_MAX_DAYS`.
diff --git a/i18n/pt/_use/profile/index.md b/i18n/pt/_use/profile/index.md
new file mode 100644
index 0000000..a4877f4
--- /dev/null
+++ b/i18n/pt/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: O seu perfil
+nav_order: 4
+description: A sua conta, preferências, palavra-passe, permissões e tokens de API
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# O seu perfil
+{: .no_toc }
+
+A sua conta, preferências, palavra-passe, permissões e tokens de API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Para todos os utilizadores: a sua própria conta, preferências, palavra-passe, permissões e tokens de API.
+
+Abra o seu perfil a partir do avatar no canto superior direito: **Perfil**.
+
+---
+
+## Abrir uma vista
+
+O menu da esquerda lista as vistas do perfil por ordem alfabética. Cada vista tem o seu próprio endereço,
+pelo que pode ligar diretamente para ela:
+
+| Vista | Endereço |
+|---|---|
+| Conta | `/profile/account` |
+| Tokens de API | `/profile/token` |
+| Palavra-passe | `/profile/password` |
+| Permissões | `/profile/permissions` |
+| Preferências | `/profile/preferences` |
+
+`/profile` sozinho abre a primeira vista do menu. As vistas que as suas funções não permitem ficam ocultas; o seu endereço abre antes a primeira
+vista. **Tokens de API** só é mostrado quando uma das suas funções tem a opção de função `allowApiTokens`.
+
+---
+
+## Nesta secção
+
+Cada tema está descrito na sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Conta](account.html) | Com que utilizador iniciou sessão |
+| [Preferências](preferences.html) | Idioma, tema, fuso horário, formato de data e notificações no ambiente de trabalho |
+| [Palavra-passe](password.html) | Alterar a palavra-passe de uma conta local |
+| [Permissões](permissions.html) | O que as suas funções lhe permitem fazer |
+| [Tokens de API](api-token.html) | Criar um token para scripts e agentes de IA |
diff --git a/i18n/pt/_use/profile/password.md b/i18n/pt/_use/profile/password.md
new file mode 100644
index 0000000..dbc5440
--- /dev/null
+++ b/i18n/pt/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: Palavra-passe
+parent: O seu perfil
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# Palavra-passe
+{: .no_toc }
+
+Alterar a palavra-passe de uma conta local
+{: .fs-6 .fw-300 }
+
+---
+
+Introduza a sua palavra-passe atual e a nova duas vezes, e clique em **Alterar palavra-passe**.
+
+As contas LDAP, Entra ID e OpenID Connect alteram antes a sua palavra-passe junto desse fornecedor.
diff --git a/i18n/pt/_use/profile/permissions.md b/i18n/pt/_use/profile/permissions.md
new file mode 100644
index 0000000..10bf660
--- /dev/null
+++ b/i18n/pt/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: Permissões
+parent: O seu perfil
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# Permissões
+{: .no_toc }
+
+O que as suas funções lhe permitem fazer
+{: .fs-6 .fw-300 }
+
+---
+
+As opções de função estão agrupadas em separadores, cada um com quantas das suas opções tem, como `5/8`:
+
+| Separador | Opções sobre |
+|---|---|
+| **Acesso e integrações** | Início de sessão, o assistente de chat, o servidor MCP, o carregamento de ficheiros e os tokens de API |
+| **Designer** | Abrir o designer, e editar formulários, playbooks, workflows, inventários e ficheiros de variáveis |
+| **Tarefas** | Ver as tarefas e as suas extravars ou artefactos, relançar, eliminar, agendar e guardar tarefas |
+| **Definições** | As páginas de definições, os registos, o registo de auditoria e as cópias de segurança |
+| **Outros** | Uma opção definida à mão numa função que não está em nenhum outro separador; sempre o último separador |
+
+Os outros separadores estão por ordem alfabética. Cada separador é uma tabela com as colunas **Definição** (a opção), **Descrição**
+(o que faz) e **O seu acesso**: **Permitido** ou **Não permitido**. Uma opção que se aplica por causa de outra indica-o
+por baixo da sua descrição: **Incluído em** uma opção que tem liga-a, e **Precisa de** uma opção que não tem mantém-na desligada.
+
+As opções vêm das `options` das suas funções no `config.yaml`; a página [Funções](../config/roles.html) explica como
+se combinam.
diff --git a/i18n/pt/_use/profile/preferences.md b/i18n/pt/_use/profile/preferences.md
new file mode 100644
index 0000000..88cd56c
--- /dev/null
+++ b/i18n/pt/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Preferências
+parent: O seu perfil
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# Preferências
+{: .no_toc }
+
+Idioma, tema, fuso horário, formato de data e notificações no ambiente de trabalho
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## As preferências
+
+A vista Preferências muda o aspeto do AnsibleForms para si. Cada escolha é guardada no navegador
+onde a faz, pelo que outro navegador ou computador começa com as predefinições.
+
+| Definição | Opções | Também definida a partir de |
+|---|---|---|
+| Idioma | Català, Deutsch, English, Español, Français, Italiano, Nederlands, Polski, Português, 日本語 (japonês), 简体中文 (chinês simplificado) | a bandeira no cabeçalho |
+| Tema | Seguir o navegador, Claro, Escuro, ou Cor (um cabeçalho numa cor que escolher) | o ícone do sol no cabeçalho |
+| Vista de formulários | Mosaicos ou Lista | o botão na página Formulários |
+| Fuso horário | UTC, o fuso deste navegador, ou qualquer fuso pelo nome | só aqui |
+| Formato de data | `YYYY-MM-DD`, `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY` | só aqui |
+| Notificações no ambiente de trabalho | Ligadas ou desligadas | só aqui |
+
+A partir da 7.3.0, a vista está em separadores, cada um no seu próprio endereço (`/profile/preferences/<tab>`): **Aparência** (idioma, tema e vista
+de formulários), **Data e hora** (fuso horário e formato de data) e **Notificações**. A caixa de pesquisa por cima deles lista as definições que correspondem
+sob o nome do seu separador. Uma escolha é um rascunho até **Guardar**, e sair da vista com uma alteração por guardar pede confirmação primeiro.
+
+**Seguir o navegador** passa a claro ou escuro como o navegador, e muda com ele. É o tema predefinido a partir da 7.3.0, a menos que o seu
+administrador escolha outro. Passar o rato sobre uma cor do tema **Cor**, aqui ou no menu de temas do cabeçalho, pré-visualiza a aplicação nessa
+cor, e o tema anterior volta quando o ponteiro sai da paleta; nada muda até um clique.
+
+---
+
+## Notificações no ambiente de trabalho
+
+A partir da 7.3.0, o separador **Notificações** liga as notificações no ambiente de trabalho neste navegador, para os utilizadores cuja função define `showJobs`.
+
+O navegador pede a sua autorização da primeira vez. Quando bloqueia as notificações do site, o interruptor fica desligado e diz como
+as permitir, e um site em `http` simples não as pode mostrar de todo. Depois de ligadas, chega uma notificação:
+
+| Quando | O que diz | Um clique nela |
+|---|---|---|
+| Uma tarefa que lançou termina | O formulário e o seu resultado, como *Patch Linux servers: Bem-sucedidas*, com o número e a duração da tarefa | Traz o separador para a frente nessa tarefa |
+| Uma tarefa aguarda a sua aprovação | O formulário, o número da tarefa e quem a lançou, com os botões **Aprovar** e **Rejeitar** | Abre as tarefas à espera de aprovação |
+
+Os botões **Aprovar** e **Rejeitar** aparecem no Chrome e no Edge; o Firefox e o Safari mostram a notificação sem eles, tal como um
+site com um certificado autoassinado, já que os botões precisam de um service worker. As notificações só chegam enquanto houver um separador do AnsibleForms aberto,
+mesmo em segundo plano: não é enviado nada depois de todos os separadores estarem fechados. Cada uma aparece uma vez, por muitos separadores que estejam abertos, e os passos de uma
+tarefa multistep e a tarefa que está a ver ficam em silêncio.
+
+---
+
+## Fuso horário
+
+As datas e horas em todo o AnsibleForms são mostradas no fuso horário que selecionar. Isto inclui as horas de início
+e de fim das tarefas, o registo de auditoria, a página de estado, as cópias de segurança, as tarefas guardadas e a expiração de um token
+de API. Mudar o fuso horário atualiza de imediato todas as páginas, sem recarregar.
+
+Até escolher um, aplica-se o fuso horário que o seu administrador definiu para todos (**Definições > Aparência > Predefinições**, ver
+[Aparência](../appearance.html)), **UTC** se não tiver sido alterado. **Este navegador** segue o fuso horário do seu computador, e a
+lista contém todos os fusos pelo nome, como `Europe/Madrid`. O cartão mostra a hora atual no fuso e formato selecionados.
+
+---
+
+## Formato de data
+
+O formato de data define como se lê a parte da data de cada data, com cada opção mostrada com a data de hoje: `YYYY-MM-DD`
+(2026-10-12), `DD/MM/YYYY`, `MM/DD/YYYY` ou `DD.MM.YYYY`. Até escolher um, aplica-se o formato de data predefinido do seu administrador,
+`YYYY-MM-DD` se não tiver sido alterado. Tal como as outras escolhas, fica guardado neste navegador.
+
+---
+
+## O que mantém as horas do servidor
+
+Há duas exceções que mantêm as horas do próprio servidor:
+
+- **O registo do servidor e o resultado das tarefas** são texto que contém as horas que o servidor lá escreveu.
+- **As horas que introduz**, como quando uma tarefa planeada deve correr, e os agendamentos cron, funcionam como
+  antes.
diff --git a/i18n/pt/_use/repositories/adding.md b/i18n/pt/_use/repositories/adding.md
new file mode 100644
index 0000000..98838c0
--- /dev/null
+++ b/i18n/pt/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: Adicionar um repositório
+parent: Repositórios git
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# Adicionar um repositório
+{: .no_toc }
+
+A página Repositórios, todos os campos de um repositório, e como declarar um no config seed
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## A página Repositórios
+
+Os repositórios gerem-se em **Definições > Ligações > Repositórios**, que precisa da [opção de função](../config/roles.html#role-options) `showSettings` ou, a partir da 7.3.0,
+`showConnectionsSettings`. Algumas alterações são exclusivas de um administrador, ver [abaixo](#who-may-change-a-repository).
+
+![Repositórios](../assets/screenshots/git.jpg)
+
+A lista mostra o **Nome**, a **Descrição**, o **Ramo**, a **Head** (o hash curto do commit em uso), **Pull** e
+**Push**. O separador **Detalhes** de um repositório mostra as mesmas etiquetas de Pull e Push por cima da sua head:
+
+| Coluna | O que diz |
+|---|---|
+| **Pull** | O último clone, pull ou reposição: **Em execução** enquanto o git trabalha, e depois **Bem-sucedido** ou **Falhado**; um traço antes do primeiro |
+| **Push** | **Falhado** quando o último push falhou; **Alterações pendentes** quando há alterações guardadas aqui, pelo designer, ainda não enviadas para o remoto; **Bem-sucedido** quando nada está à espera; um traço antes do primeiro push |
+
+**Bem-sucedido** na coluna Push só significa que nada está à espera de ser enviado: o remoto pode ainda ter commits mais recentes que um
+pull traz. O menu de cada linha contém estas ações:
+
+| Ação | O que faz |
+|---|---|
+| **Editar** | Alterar os campos abaixo |
+| **Pull** | Clonar o repositório, ou fazer pull quando a cópia de trabalho já existe |
+| **Push** | Fazer commit e push da cópia de trabalho; só nos repositórios usados para formulários, configuração, playbooks, workflows ou inventários, e ativo só enquanto há alterações por enviar |
+| **Repor** | Eliminar a cópia de trabalho e cloná-la de novo, o que descarta as alterações locais |
+| **Alterar credenciais** | Abrir o separador **Credenciais** do repositório, para escolher a credencial que o git usa |
+| **Mostrar saída do último pull** | Mostrar a saída do git do último clone, pull ou reposição, com a palavra-passe oculta |
+| **Mostrar saída do último push** | Mostrar a saída do git do último push, com a palavra-passe oculta |
+| **Eliminar** | Remover o registo e a sua cópia de trabalho em `REPO_PATH`; exclusivo de um administrador |
+
+**Pull de todos**, por cima da lista, faz pull de todos os repositórios de uma vez.
+
+Só corre uma operação git de cada vez num repositório. Uma segunda é recusada com
+`Repository '<name>' not found or already running, try again later`.
+
+---
+
+## Adicionar um repositório
+
+Clique em **Adicionar repositório**: um assistente pede os campos em quatro passos (**Repositório**, **Credenciais**, **Utilização**, **Agendamento
+do pull**), e o AnsibleForms inicia o clone em segundo plano assim que guardar.
+
+![Editar repositório](../assets/screenshots/git-edit.jpg)
+
+| Campo | Obrigatório | Significado |
+|---|---|---|
+| **Nome** | sim | O nome da pasta em `REPO_PATH`; letras, dígitos, hífen, underscore e ponto |
+| **Ramo** | sim | O ramo a clonar, a puxar e a enviar, por exemplo `main`; obrigatório a partir da 7.3.0. Só um repositório do config seed o pode omitir, para clonar o ramo predefinido do remoto |
+| **Credencial** | não | Uma credencial de [Ligações > Credenciais](../credentials.html) com o utilizador e a palavra-passe ou o token que o git usa; **Adicionar credencial** cria uma |
+| **Uri** | sim | O remoto, `https://...` ou SSH (`git@git.example.com:team/forms.git`, `ssh://...`) |
+| **Ativar o pull agendado** | não | Fazer pull do repositório segundo um agendamento |
+| **Agendamento do pull** | não | Quando fazer pull, como expressão cron; mostrado depois de o pull agendado ser ativado |
+| **Descrição** | sim | Uma descrição em texto livre |
+| **Usar para a configuração ?** ... **Usar para inventários?** | não | O que o repositório contém, ver [acima](./#what-a-repository-is-for) |
+| **Fazer pull ao iniciar a aplicação** | não | Clonar o repositório, ou fazer pull, sempre que o AnsibleForms arranca |
+
+Mudar o nome de um repositório move a sua cópia de trabalho para a nova pasta e leva consigo o seu agendamento de pull. Um repositório de
+antes da 7 que ainda tenha o seu próprio utilizador indica-o no seu separador **Credenciais**: escolha uma credencial para o substituir.
+
+---
+
+## Quem pode alterar um repositório
+
+O conteúdo de um repositório passa a ser o que o AnsibleForms carrega e executa, por isso a partir da 7.3.0 um utilizador sem a função `admin` já não pode:
+
+- adicionar ou eliminar um repositório;
+- alterar o seu **Uri** ou o seu **Ramo**;
+- ligar ou desligar qualquer uma das suas opções **Usar para**.
+
+Pode ainda alterar a sua descrição, o agendamento do pull e a credencial, e fazer pull, push ou repô-lo. Não pode escolher uma credencial que um runner,
+uma ligação ou um início de sessão use; a recusa indica-a, e não diz nada sobre o que contém.
+
+---
+
+## Declarar repositórios no config seed
+
+Os repositórios também podem ser declarados no [config seed](../seed/), para que uma instância nova os clone no seu primeiro arranque.
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+Os campos são os da página, incluindo `credential` (uma credencial do seed ou da aplicação), `rebase_on_start` (**Fazer pull ao iniciar
+a aplicação**) e `cron` (o agendamento do pull); `user` e `password` continuam a ser aceites em vez de uma credencial. Um
+repositório do seed é só de leitura na interface, e é clonado de novo no arranque quando falta a sua cópia de trabalho; ver
+[Objetos geridos](../seed/managed-objects.html).
diff --git a/i18n/pt/_use/repositories/authentication.md b/i18n/pt/_use/repositories/authentication.md
new file mode 100644
index 0000000..6c2127b
--- /dev/null
+++ b/i18n/pt/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: Autenticação
+parent: Repositórios git
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# Autenticação
+{: .no_toc }
+
+HTTPS com um token, SSH com a chave gerada, e comandos git personalizados
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Autenticação
+
+A forma como o AnsibleForms se autentica depende da forma do **Uri**.
+
+### HTTPS com um token
+
+Para um remoto HTTPS privado, escolha uma **Credencial** cujo utilizador seja o utilizador git e cuja palavra-passe seja um token de acesso pessoal
+(ou a palavra-passe).
+
+A partir da 7.3.0, o git inicia sessão através de `GIT_ASKPASS`: o utilizador e o token vão para cada comando git que fala com o servidor, nunca para
+o URL, pelo que não ficam guardados no `.git/config` do clone e um token alterado é usado no pull ou push seguinte. O token precisa de
+acesso de leitura para fazer pull, e de acesso de escrita para fazer push. Um remoto público não precisa de credencial.
+
+Até à 7.2.0, ambos eram inseridos no URL, como `https://<user>:<token>@git.example.com/team/forms.git`. Um clone feito nessa altura mantém
+esse URL até ao seu pull ou push seguinte, que repõe o seu remoto no próprio **Uri** do repositório.
+
+### SSH com a chave gerada
+
+Para um remoto SSH, o AnsibleForms autentica-se com o seu próprio par de chaves, que gera no primeiro arranque.
+
+1. Abra **Definições > Ligações > SSH**, no separador **Chave**, e copie a **Chave pública**.
+2. Acrescente-a no servidor git, como deploy key do repositório (com acesso de escrita se fizer push), ou a um utilizador com acesso.
+3. Acrescente o repositório com um **Uri** SSH, por exemplo `git@git.example.com:team/forms.git`, e não escolha nenhuma credencial.
+
+O par de chaves fica em `.ssh/id_rsa` dentro de [`HOME_PATH`](../customization/paths.html#env_HOME_PATH), por isso mantenha essa pasta em
+armazenamento persistente, ou a chave muda quando o contentor é recriado.
+
+Num clone com um Uri `user@host:path`, o AnsibleForms executa primeiro `ssh-keyscan` sobre o host e acrescenta a sua chave aos
+hosts conhecidos. Para outros remotos, acrescente o host no separador **Hosts conhecidos** de **Definições > Ligações > SSH** antes do
+primeiro clone.
+
+### Comandos git personalizados
+
+Os comandos de clone, pull e push podem ser substituídos, por exemplo para acrescentar opções do git, com três definições.
+
+| Definição | Predefinição | O que o AnsibleForms acrescenta |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>`, `--verbose`, o Uri e o nome |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+A partir da 7.3.0, estes comandos correm sem shell: as aspas funcionam, mas um operador de shell como `;`, `|`, `&&` ou `>` é recusado.
diff --git a/i18n/pt/_use/repositories/designer.md b/i18n/pt/_use/repositories/designer.md
new file mode 100644
index 0000000..afd58f2
--- /dev/null
+++ b/i18n/pt/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: Designer e push
+parent: Repositórios git
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# Designer e push
+{: .no_toc }
+
+Editar formulários no designer e enviá-los (push) para o repositório
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Editar e enviar a partir do designer
+
+Com um repositório usado para formulários, o designer edita os ficheiros da sua cópia de trabalho e envia-os de volta para o remoto.
+
+| Botão | O que faz |
+|---|---|
+| **Guardar (local)** | Escreve os formulários e o `config.yaml` nas cópias de trabalho, sem fazer commit |
+| **Guardar (repositório)** | Faz commit e push das alterações guardadas; ativo quando há alterações por enviar |
+| **Carregar (repositório)** | Faz pull dos repositórios de formulários e recarrega o designer, depois de uma confirmação se houver edições por guardar |
+
+Os formulários ficam no seu repositório; os novos esperam, já utilizáveis, em [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) até fazer push.
+Um formulário guardado numa subpasta mantém o seu caminho relativo: `team/deploy.yaml` é enviado para `team/deploy.yaml` dentro da pasta de formulários
+do repositório. Um formulário novo cujo caminho já existe lá não é substituído; fica na preparação, por isso mude-lhe o nome.
+Com vários repositórios de formulários, **Guardar (repositório)** e **Carregar (repositório)** perguntam qual, sendo predefinido o do `config.yaml`.
+
+Um push prepara todas as alterações, faz commit delas como `AnsibleForms` com a mensagem `Forms sync by <user>`, e depois faz fetch, rebase sobre
+o remoto e push, tentando até cinco vezes. Um conflito de rebase é abortado e os ficheiros em conflito são listados;
+corrija-os no remoto, ou use **Repor** na página Repositórios. **Push** na página Repositórios faz o mesmo.
+
+Quando um único repositório de formulários é clonado vazio, o AnsibleForms copia o `config.yaml` local e os formulários para a sua cópia
+de trabalho, para que um push (**Guardar (repositório)**, ou **Push** na página Repositórios) os publique. Há mais sobre o designer em [Designer e git](../gui/designer-and-git.html).
diff --git a/i18n/pt/_use/repositories/index.md b/i18n/pt/_use/repositories/index.md
new file mode 100644
index 0000000..e770d4e
--- /dev/null
+++ b/i18n/pt/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Repositórios git
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Repositórios git
+{: .no_toc }
+
+Manter formulários, ficheiros de variáveis, configuração e playbooks em git
+{: .fs-6 .fw-300 }
+
+---
+
+Para administradores que mantêm formulários, configuração e playbooks em git: o que um repositório pode conter e que origem prevalece.
+
+---
+
+## Para que serve um repositório
+
+Um repositório é um remoto git que o AnsibleForms clona e mantém atualizado, e cada um tem interruptores que dizem o que contém:
+
+| Interruptor | O que o AnsibleForms lê dele | Pasta no repositório |
+|---|---|---|
+| **Usar para a configuração ?** | `config.yaml` com as categorias, funções e constantes | a raiz |
+| **Usar para formulários ?** | Os ficheiros de formulários, que o designer também guarda de volta nele, e os seus ficheiros de variáveis | `forms`, ou a raiz; ficheiros de variáveis em `vars` |
+| **Usar para playbooks ?** | Os playbooks Ansible que as tarefas executam | `playbooks`, ou a raiz |
+| **Usar para workflows?** | Os ficheiros de [workflow](../workflows/), que o designer também guarda de volta nele | qualquer pasta |
+| **Usar para inventários?** | Um inventário, com o nome do repositório, que um formulário indica com `inventory:` | a raiz: `inventory.yaml`, `group_vars`, `host_vars` |
+
+Sem a subpasta, usa-se a raiz do repositório. Um só repositório pode conter tudo; se os separar, só **Usar para
+formulários**, **Usar para workflows** e **Usar para inventários** podem estar ligados em vários: os outros interruptores ficam com o primeiro repositório
+e registam um aviso.
+
+Cada repositório é clonado numa subpasta com o seu nome, dentro de [`REPO_PATH`](../customization/paths.html#env_REPO_PATH).
+
+### Um repositório para tudo
+
+Um único repositório pode conter formulários, ficheiros de variáveis, configuração e playbooks, com os interruptores ligados e uma subpasta por tipo.
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### Um repositório por finalidade
+
+Repositórios separados permitem que cada equipa seja dona da sua parte, com um interruptor cada e os ficheiros diretamente na raiz.
+
+| Repositório | Interruptor | Conteúdo na raiz |
+|---|---|---|
+| `af-config` | **Usar para a configuração ?** | `config.yaml` |
+| `af-forms-network`, `af-forms-storage` | **Usar para formulários ?** | Os ficheiros de formulários de cada equipa, juntados numa só lista |
+| `af-playbooks` | **Usar para playbooks ?** | Os playbooks e as roles |
+
+Só os formulários podem vir de vários repositórios; a configuração e os playbooks vêm cada um de um só. Os ficheiros de variáveis vêm da pasta `vars`
+do primeiro repositório de formulários que tenha uma.
+
+---
+
+## Como os repositórios se combinam com as pastas locais
+
+O conteúdo de um repositório substitui a pasta local correspondente; esta tabela resume de onde é lido cada tipo de ficheiro.
+
+| Conteúdo | Lido de, prevalece a primeira correspondência |
+|---|---|
+| Configuração | 1. a base de dados, quando a configuração é guardada lá ([`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE)) <br> 2. o `config.yaml` do repositório **Usar para a configuração** <br> 3. o `config.yaml` de um repositório **Usar para formulários**, quando nenhum repositório é usado para a configuração <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| Formulários | Todos os repositórios **Usar para formulários** mais `FORMS_STAGING_PATH`; [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) só quando não há nenhum |
+| Playbooks | O repositório **Usar para playbooks**, caso contrário [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| Ficheiros de variáveis | A pasta `vars` do primeiro repositório **Usar para formulários** que tenha uma, caso contrário [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| Workflows | Todos os repositórios **Usar para workflows** mais [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH), em conjunto |
+
+Os formulários de vários repositórios são juntados numa só lista. Quando dois deles contêm um formulário com o mesmo nome, fica o primeiro
+carregado e é registado o aviso `skipping duplicate form <name>`, por isso mantenha os nomes dos formulários únicos entre repositórios.
+
+---
+
+## Resolução de problemas
+
+A maioria dos problemas aparece na coluna **Pull** e em **Mostrar saída do último pull** (ou **Mostrar saída do último push**), que contêm a própria
+mensagem de erro do git.
+
+- [O clone ou pull de um repositório falhou](../troubleshooting.html#a-repository-clone-or-pull-failed): autenticação, hosts
+  conhecidos e alterações locais.
+- [O repositório de formulários ainda não está clonado](../troubleshooting.html#the-forms-repository-is-not-cloned-yet): o designer
+  não pode guardar antes do primeiro clone.
+- Um repositório preso em `running` é reposto como `failed`: depois de um reinício, no arranque seguinte; no espaço de um minuto quando o nó
+  que executa a sua operação git deixa de responder durante 2 minutos; e, em qualquer caso, ao fim de 2 horas. Faça **Pull** de novo.
+
+---
+
+## Nesta secção
+
+Cada tema tem a sua própria página:
+
+| Página | O que abrange |
+|---|---|
+| [Adicionar um repositório](adding.html) | A página Repositórios, todos os campos de um repositório, e como declarar um no config seed |
+| [Autenticação](authentication.html) | HTTPS com um token, SSH com a chave gerada, e comandos git personalizados |
+| [Fazer pull das alterações](pulling.html) | Pulls agendados, manuais e pela API, e alterações locais |
+| [Designer e push](designer.html) | Editar formulários no designer e enviá-los (push) para o repositório |
diff --git a/i18n/pt/_use/repositories/pulling.md b/i18n/pt/_use/repositories/pulling.md
new file mode 100644
index 0000000..c05e1bb
--- /dev/null
+++ b/i18n/pt/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: Fazer pull das alterações
+parent: Repositórios git
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# Fazer pull das alterações
+{: .no_toc }
+
+Pulls agendados, manuais e pela API, e alterações locais
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## Fazer pull das alterações
+
+Faz-se pull de um repositório segundo o seu agendamento, no arranque, a partir da página ou através da API; não há nenhum endpoint de webhook.
+
+| Gatilho | Como |
+|---|---|
+| Agendamento | **Ativar o pull agendado** e um **Agendamento do pull**, por exemplo `0 * * * *` para cada hora |
+| Arranque | **Fazer pull ao iniciar a aplicação** clona o repositório, ou faz pull quando já está clonado |
+| Página de definições | **Pull** no menu da linha, ou **Pull de todos** por cima da lista |
+| Designer | **Carregar (repositório)**, que faz pull dos repositórios de formulários e recarrega o designer; obter o bloqueio do designer também faz primeiro pull de todos os repositórios de formulários |
+| API | `POST /api/v2/repository/<name>/pull` (`showSettings` ou `showConnectionsSettings`) ou `POST /api/v2/forms-repos/pull/<name>` (ver abaixo) |
+
+### Pull a partir de um pipeline ou de um webhook
+
+O AnsibleForms não tem nenhum recetor de webhooks dedicado, mas uma tarefa de CI ou um webhook do servidor git pode chamar o endpoint de pull.
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+Crie o token como descrito em [Tokens de API](../profile/api-token.html), para um utilizador cuja função tenha `showSettings` ou
+`showConnectionsSettings`. `/api/v2/forms-repos/pull/<name>` precisa antes de `showDesigner` e `allowFormDesign`, com o designer
+ligado ([`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)). `GET /api/v2/repository/<name>` devolve a
+`head`, o `status` e o `output`, para que um pipeline possa verificar que commit a instância está a usar depois de um pull.
+
+### Alterações locais
+
+Um pull nunca substitui trabalho que ainda não foi enviado, por isso um pull agendado verifica a cópia de trabalho antes de correr.
+
+Um pull agendado é saltado enquanto a cópia de trabalho tem alterações sem commit ou commits por enviar, e enquanto um designer
+tem o bloqueio do designer. Um pull manual de uma cópia de trabalho com alterações em conflito falha com:
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+Envie as alterações, ou descarte-as com **Repor** no menu da linha, que elimina a cópia de trabalho e a clona de novo.
diff --git a/i18n/pt/index.md b/i18n/pt/index.md
new file mode 100644
index 0000000..82db9df
--- /dev/null
+++ b/i18n/pt/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: Início
+nav_order: 1
+description: "AnsibleForms: crie formulários dinâmicos baseados em dados para a automação com Ansible"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">Formulários self-service para <span>Ansible</span></h1>
+    <p class="af-hero-lead">
+      O Ansible é uma ferramenta de automação poderosa, mas continua a ser uma aplicação de linha de comandos, e ao AWX/AAP/Ascender faltam
+      formulários que recolham dados de várias fontes. O AnsibleForms permite criar formulários dinâmicos baseados em dados, gerar extravars
+      e enviá-las para Ansible, AWX/AAP/Ascender, Semaphore, Rundeck ou Jenkins e aí executar templates.
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">Instalar o AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">Crie o seu primeiro formulário</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="O painel do AnsibleForms">
+  </div>
+</div>
+
+## Capacidades
+
+O que o AnsibleForms traz ao seu ambiente Ansible, e o que um só formulário consegue fazer:
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>Aplicação</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Plataformas de automação</strong><span>Playbooks em RTE, templates no Ascender, no Semaphore e noutros</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Controlo de acesso</strong><span>Funções e opções de função, com inícios de sessão locais, LDAP, Entra ID e OIDC</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Agendamento</strong><span>Executar um formulário mais tarde, ou segundo um agendamento cron</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Histórico de tarefas</strong><span>Acompanhar, interromper e relançar tarefas</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Credenciais e segredos</strong><span>Guardar credenciais, ou lê-las do Vault ou do CyberArk</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Repositórios git</strong><span>Manter formulários, playbooks e configuração em Git</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Designer</strong><span>Editar formulários em YAML, com validação</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API, MCP e chat</strong><span>Lançar formulários a partir de scripts, agentes de IA ou de um chat</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>Formulários</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Listas pendentes em cascata</strong><span>Listas pendentes que reagem a outros campos</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Expressões e fontes de dados</strong><span>Preencher campos a partir de bases de dados, APIs REST, ficheiros e JavaScript</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Dependências entre campos</strong><span>Mostrar ou ocultar campos conforme outros campos</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Validação</strong><span>Mínimo, máximo, regex e mais, opcionalmente verificados no servidor</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Workflows e assistentes</strong><span>Encadear playbooks e aprovações, ou dividir os dados por páginas</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Campos estruturados</strong><span>Listas e objetos baseados em subformulários reutilizáveis</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Pontos de aprovação</strong><span>Colocar uma tarefa em pausa até alguém a aprovar</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Notificações</strong><span>Email, Slack, Teams, Telegram ou um webhook nos eventos das tarefas</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## Precisa de ajuda?
+
+As perguntas, os erros e os relatórios de segurança têm cada um o seu lugar:
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>Resolução de problemas</strong>
+    <span>Procurar uma mensagem de erro e como a resolver</span>
+    <span class="af-card-more">Resolução de problemas &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>Fazer uma pergunta</strong>
+    <span>Perguntar à comunidade e aos maintainers</span>
+    <span class="af-card-more">Discussões &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>Reportar um erro</strong>
+    <span>Abrir uma issue com os passos para o reproduzir</span>
+    <span class="af-card-more">Nova issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>Obter ajuda</strong>
+    <span>O que incluir, e como reportar um problema de segurança</span>
+    <span class="af-card-more">Obter ajuda &rarr;</span>
+  </a>
+</div>
+
diff --git a/i18n/zh.yml b/i18n/zh.yml
new file mode 100644
index 0000000..cd114ee
--- /dev/null
+++ b/i18n/zh.yml
@@ -0,0 +1,46 @@
+# The Simplified Chinese docs : read after source/_config.yml by scripts/build-language.sh, so only what
+# differs from the English site is set here. Jekyll merges the two, nested keys included.
+
+lang: zh
+docs_language: "zh"
+
+title: "AnsibleForms 文档"
+description: "AnsibleForms 技术文档"
+
+footer_content: "Copyright &copy; 2023-2026 AnsibleForms. 保留所有权利。"
+
+# "Edit this page on GitHub" opens the Simplified Chinese page's source
+gh_edit_link_text: "在 GitHub 上编辑此页"
+gh_edit_source: i18n/zh
+
+just_the_docs:
+  collections:
+    introduction:
+      name: "简介"
+    get_started:
+      name: "快速入门"
+    configure:
+      name: "配置"
+    build_forms:
+      name: "构建表单"
+    use:
+      name: "用户指南"
+    integrate:
+      name: "集成"
+    security_assessment:
+      name: "安全"
+    reference:
+      name: "参考"
+
+# The version selector (_includes/version_select.html) : a list is replaced, not merged
+docs_versions:
+  - name: "7"
+    title: "7.x（最新）"
+    url: "/zh/"
+  - name: "6"
+    title: "6.x（英文）"
+    url: "/v6/"
+
+# Search : full-width punctuation separates words too (the CJK pairing is in _includes/lunr/custom-index.js)
+search:
+  tokenizer_separator: /[\s/、。，．：；！？「」『』（）【】・]+/
diff --git a/i18n/zh/_build_forms/expressions/credentials.md b/i18n/zh/_build_forms/expressions/credentials.md
new file mode 100644
index 0000000..be610d7
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/credentials.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: 凭据
+parent: 表达式
+nav_order: 4
+translated_from: bfa50c90495c68300d189f9a0eb38e25df9e7c8e
+---
+
+# 凭据
+{: .no_toc }
+
+在表达式中读取已保存的凭据
+{: .fs-6 .fw-300 }
+
+---
+
+按名称或正则表达式读取已保存的凭据，并可指定备用凭据：
+
+```javascript
+fn.fnCredentials('credentialname_or_regex','fallback_credentialname_or_regex')
+
+// Try to use `fnRestBasic` and `fnRestJwtSecure` if possible, this avoids passwords and tokens going over the network.
+
+// output : a credential object with all properties (user, password, host, port)
+```
+
+首先尝试精确名称。如果没有凭据使用该名称，就把该名称当作正则表达式匹配，最后再尝试备用凭据。
+
+#### 受角色限制
+
+当用户的某个角色在 `config.yaml` 中列出了 `credentials` 时，`fn.fnCredentials` 只返回该角色
+允许的凭据：用角色的模式去匹配找到的凭据名称（无论是按名称、正则表达式还是备用凭据找到的），
+其他凭据一律拒绝。没有该列表的角色不做限制，管理员也从不受限。
+
+#### 来自密钥库的凭据
+
+指定了[密钥库](../secret-stores)的凭据，会在运行时从该密钥库获取其 `user` 和 `password` 。
+`fn.fnCredentials('myapp')` 照常可用，无需任何改动。
+
+在任何接受凭据名称的地方，也可以不经凭据行直接读取密钥
+（包括 `fnRestBasic` 、 `fnRestJwtSecure` 以及 `fnRestAdvanced` 的请求头替换）：
+
+```javascript
+fn.fnCredentials('secret:vault:secret/ontap')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/ontap')          // the store named `vault`
+```
+
+密钥中的键按[键名](../secret-stores#key-names)中的说明进行映射。
+结构不同的密钥，可以用作为第三个参数的 `jq` 表达式重新整形：
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird','','.creds | { user: .u, password: .p }')
+```
diff --git a/i18n/zh/_build_forms/expressions/index.md b/i18n/zh/_build_forms/expressions/index.md
new file mode 100644
index 0000000..dbc84d7
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/index.md
@@ -0,0 +1,76 @@
+---
+layout: default
+title: 表达式
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /expressions/
+translated_from: 52d74e32540fba4dfa5078c8976147b39a2ad2cf
+---
+
+# 表达式
+{: .no_toc }
+
+用 JavaScript 计算字段值，可在浏览器中，也可在服务器上
+{: .fs-6 .fw-300 }
+
+---
+
+面向表单作者：用 JavaScript 动态填充字段，可在浏览器中计算，也可在服务器上获取。
+
+表单字段的 `expression` 属性让您可以用 JavaScript 表达式构建动态表单。
+
+---
+
+## 简介
+
+`expression` 属性可用于多种字段类型：
+- `enum` 字段：动态填充下拉选项
+- `expression` 字段：获取或生成任意形式的数据
+- `html` 字段：构建其 HTML 内容
+- `yaml` 和 `list` 字段：填充其数据
+
+JavaScript 表达式要么在**服务器端**（默认）求值，要么在**客户端**求值，由字段属性 `runLocal` 决定。
+`html` 字段，以及 `local` 、 `local_out` 和 `credential` 字段类型，无论
+`runLocal` 如何设置，始终在浏览器中运行其表达式。
+
+- **服务器端**（ `runLocal: false` ，默认值）：预定义函数，从 API、文件和数据库获取数据。
+- **客户端**（ `runLocal: true` ）：代码可以在浏览器沙箱中使用完整的 JavaScript 引擎进行计算、转换和处理。
+
+---
+
+## 安全注意事项
+
+由于表达式通过 JavaScript 的 `eval` 函数求值，代码注入是一个潜在风险：
+
+- **服务器端表达式**会先经过清理器：每个调用都必须是 `fn.` 或 `fnc.` 函数，多行代码、
+  `;` 、模板字符串、 `process.env` 以及逃出 `eval` 的方式（ `import` 、 `require` 、 `constructor` ……）都会被拒绝。
+- **客户端表达式**在浏览器沙箱中求值，可以认为是安全的。
+
+清理器的严格程度取决于
+[`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER)：
+
+| 值 | 服务器端表达式 |
+|---|---|
+| `strict` （默认） | `fn.` 和 `fnc.` 调用，以及对其结果调用的方法，例如 `fn.fnTime().format('YYYY')` |
+| `paranoid` | 只允许直接的 `fn.` 和 `fnc.` 调用，不允许对其结果调用方法 |
+| `off` | 拒绝所有服务器端表达式，只有 `runLocal` 表达式可用 |
+| `legacy` | 6.2.1 的规则，允许任何已认证用户在服务器上运行代码；仅用于升级过渡，且只能在真实环境中设置（不能在设置页面中设置） |
+
+值为空或无法识别时视为 `strict` 。修改会在下一个表达式生效，无需重启。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [占位符](placeholders.html) | 用 `$(...)` 引用其他字段、常量或用户 |
+| [本地表达式](local.html) | 在浏览器沙箱中运行的 JavaScript |
+| [远程表达式](remote.html) | 用于日期、网络、文件、SSH 和编号名称的服务器端函数 |
+| [REST API](rest-apis.html) | 通过基本认证、令牌或自定义认证调用 REST API |
+| [凭据](credentials.html) | 读取已保存的凭据 |
+| [排序](sorting.html) | 用排序对象对数组排序 |
+| [jq 查询](jq.html) | 用 jq 重新整形数据 |
diff --git a/i18n/zh/_build_forms/expressions/jq.md b/i18n/zh/_build_forms/expressions/jq.md
new file mode 100644
index 0000000..c1e4b8c
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/jq.md
@@ -0,0 +1,59 @@
+---
+layout: default
+title: jq 查询
+parent: 表达式
+nav_order: 6
+translated_from: b34dbbec6c5d115f9bb41450962c3fce9606035f
+---
+
+# jq 查询
+{: .no_toc }
+
+用 jq 重新整形数据，包括内置函数
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 对对象运行 JSON 查询（jq）
+
+用 jq 表达式重新整形一个对象，例如另一个字段的值：
+
+```javascript
+fn.fnJq($(settings),'.mapping | keys')
+
+// output : a full json object taken from another field called "settings", converted by jq
+
+// fn.fnJq(object, jq)
+// - object, for example read from rest or yaml file
+// - jq-expression : a jq-expression (https://jqplay.org)
+// - wrap the result in fn.fnSort to order it
+```
+
+从 7.3.0 起，jq 过滤器最多运行 [`JQ_TIMEOUT_SECONDS`](../customization/security.html#env_JQ_TIMEOUT_SECONDS)（默认 30）秒，
+超时即被终止，其输出上限为 64 MB。这适用于 `fn.fnJq` ，也适用于 REST、文件、
+凭据和数据库查询函数中的 jq 表达式。
+
+---
+
+## 内置 JQ 函数
+
+所有获取数据的函数都接受 JSON 查询（jq），这是一种处理数据对象和数组的语言。  
+处理数据时，您可能需要把字节转换为 KB、MB 或 GB，或者对数字取整。  
+为此，AnsibleForms 提供了几个自定义 jq 函数：
+
+- **fn2KB**：字节转 KB
+- **fn2MB**：字节转 MB
+- **fn2GB**：字节转 GB
+- **fnRound0**：保留 0 位小数取整
+- **fnRound1**：保留 1 位小数取整
+- **fnRound2**：保留 2 位小数取整
+- **fnRound**：保留 2 位小数取整
+
+```javascript
+fn.fnRestBasic('get','https://youruri','','CREDS',
+  '[.records[] | {"Available Capacity":.storage_capacity.available | fn2GB | fnRound }]')
+// note you need to pipe into the functions
+```
diff --git a/i18n/zh/_build_forms/expressions/local.md b/i18n/zh/_build_forms/expressions/local.md
new file mode 100644
index 0000000..9ae9005
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/local.md
@@ -0,0 +1,232 @@
+---
+layout: default
+title: 本地表达式
+parent: 表达式
+nav_order: 1
+translated_from: 77a88157a129701065cf770bf1005b4391140aa1
+---
+
+# 本地表达式
+{: .no_toc }
+
+在浏览器沙箱中运行的 JavaScript
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+以下示例使用字段属性 `runLocal: true` 运行。  
+它们在浏览器沙箱中执行，可以使用完整的 JavaScript 引擎。
+
+{: .note }
+> **提示**：类型 `local` 可作为 `type: expression, runLocal: true, hide: true, output: false` 的别名  
+> **提示**：类型 `local_out` 可作为 `type: expression, runLocal: true, hide: true` 的别名  
+
+---
+
+## 命名规范
+
+用字符串操作来套用命名规范。
+
+```javascript
+'$(field1) $(field2)'.replace('-','_').toUpperCase()
+```
+
+---
+
+## 计算
+
+用数学运算进行计算。
+
+```javascript
+Math.round($(field1)*$(field2)*Math.PI)   // Math.round and Math.PI are native javascript
+```
+
+---
+
+## 转换
+
+把字节转换为 GB。
+
+```javascript
+($(size_bytes)/1024/1024/1024).toFixed(2)  // toFixed is native javascript method
+```
+
+---
+
+## 把对象数组转换为 HTML 表格
+
+把对象数组（例如来自另一个字段）转换成 HTML 表格，供 `html` 字段使用：
+
+```javascript
+fnToTable($(my_array_field),{
+  tableClass: '',
+  escapeHtml: true,
+  emptyCell: '',
+  includeHeader: true
+})
+
+// output : an html-table representation of the array of objects taken from another field called "my_array_field"
+// tip : add tableClass: 'table table-striped table-bordered' for bootstrap styling
+```
+
+---
+
+## 获取带递增编号的名称
+
+使用自动编号时，您可能需要在一组带编号的字符串中找出下一个名称。  
+此函数也可作为服务器端表达式使用（加前缀 `fn.` ）。
+
+```javascript
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+当第一个参数不是数组时，本地函数返回默认值。而服务器函数 `fn.fnGetNumberedName`
+则会报错失败。
+
+---
+
+## 对象数组处理
+
+对象数组经常需要筛选、修改和排序。  
+AnsibleForms 提供了一个自定义辅助工具，让这类代码保持简洁。
+
+```javascript
+/* 
+  fnArray.from($(your_array_field))                               // custom helper library
+      .filterBy({property1:'value1',property2:'value2', ...})     // filters by property value (a string, * wildcards allowed)
+      .regexBy({property1:'regex1',property2:'regex2', ...})      // filters the array by property matched against regex
+      .distinctBy('property1','property2', ...)                   // will make the array entries unique by property
+      .selectAttr({prop1:'property1',prop2:'property2'})          // only selects a certain property, and you can relabel them
+      .sortBy('property1','-property2', ...)                      // will order the array.  To have descending add a "-" (minus) before the property
+
+  mylist:
+  [
+    {
+      name:'Spiderman',
+      has_ability: true,
+      ability: 'Can do whatever a spider can'
+    },
+    {
+      name:'Superman',
+      has_ability: true,
+      ability: 'Superstrong,Flying,Laserbeams'
+    },     
+    {
+      name:'FamilyGuy',
+      has_ability: false
+    },    
+    {
+      name:'Wolverine',
+      has_ability: true,
+      ability: 'Enhanced healing'
+    }                                                  
+  ]
+*/
+
+fnArray.from($(mylist))         // take data from another field 'mylist'
+.regexBy({name:'.*man$'})       // name must end with 'man'
+.filterBy({has_ability:'true'}) // must have abilities (a string: 'true', not true)
+.selectAttr({name:'name',ability:'ability'})   // only take properties name and ability
+.sortBy('-name')                // sort by name descending
+
+/*
+  result : 
+  [
+    {name:'Superman',ability:'Superstrong,Flying,Laserbeams'},
+    {name:'Spiderman',ability:'Can do whatever a spider can'}
+  ]
+*/
+```
+
+---
+
+## 用原生 JavaScript 处理对象数组
+
+所有标准 JavaScript 数组方法仍然可用于筛选和修改数据，例如 `map` 、 `forEach` 、 `find` 、 `filter` 和 `reduce` 。
+
+```javascript
+// source : https://medium.com/@jeff_long/understanding-foreach-map-filter-and-find-in-javascript-f91da93b9f2c
+
+mylist=
+  [
+    {
+      name:'Bob',
+      age: 5
+    },
+    {
+      name:'Tom',
+      age: 10
+    },     
+    {
+      name:'Paul',
+      age: 30
+    },    
+    {
+      name:'Tom',
+      age: 40
+    }                                                  
+  ]
+
+// simple filter
+$(mylist).filter((x) => x.age<=20) // filter age<=20
+/* result:
+[
+  {name:'Bob',age:5},
+  {name:'Tom',age:10}
+]
+*/
+
+// filter and addition
+$(mylist)
+  .filter((x) => x.age<=20)   // filter age<=20
+  .map((x) => { return {...x,diff:20-x.age} }) // add new property diff
+/* result:
+[
+  {name:'Bob',age:5,diff:15},
+  {name:'Tom',age:10,diff:10}
+] 
+*/
+
+// find
+$(mylist).find((x) => x.name=='Tom').age  // find age of first Tom
+// result: 10
+
+// make sum with reduce
+$(mylist).reduce((sum,x) => sum+x.age,0) // calculate sum of ages
+// result: 85
+
+// make temp function
+((arr,min)=>{
+  return arr
+    .filter(x => x.age>=min)  // filter
+    .map(x => {
+      var preview=`${x.name} (${x.age})`; // make preview string
+      return {...x,preview:preview} })    // add new preview property
+})($(mylist),20)                          // feed function with mylist and 20       
+/* result:
+[
+  {name:'Paul',age:30,preview:'Paul (30)'},
+  {name:'Tom',age:40,preview:'Tom (40)'}
+] 
+*/
+```
+
+---
diff --git a/i18n/zh/_build_forms/expressions/placeholders.md b/i18n/zh/_build_forms/expressions/placeholders.md
new file mode 100644
index 0000000..3826b75
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/placeholders.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: 占位符
+parent: 表达式
+nav_order: 0.5
+translated_from: bd63e437a4f77c707a1bf8d8ee99b1516063b62a
+---
+
+# 占位符
+{: .no_toc }
+
+用 `$(...)` 引用其他字段、常量或当前用户
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 什么是占位符
+
+占位符是写成 `$(reference)` 形式的引用。在使用包含它的文本之前，它会被替换成一个值。
+
+占位符可用于字段的 `expression` 、 `query` 和 `default` （通过 `evalDefault` 求值），也可用于其 `label` 、
+`help` 和 `placeholder` 。包含占位符的字段依赖于它所引用的字段：它会等到那个字段有了
+值才求值，并且每次那个值变化时都会重新求值。级联下拉框就是这样构建的。
+
+```yaml
+- name: city
+  type: enum
+  values: [Amsterdam, Brussels]
+- name: datacenter
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select name from cmdb.datacenter where city='$(city)'
+```
+
+---
+
+## 占位符可以引用什么
+
+占位符可以引用表单中的某个字段，或者以下每个表单都有的引用之一：
+
+| 引用 | 内容 |
+|---|---|
+| `$(field)` | 表单中另一个字段的值 |
+| `$(name)` ，常量 | `config.yaml` 中的[常量](../config/constants.html)，或表单 `varsFiles` 中的值 |
+| `$(__user__)` | 已登录用户： `username` 、 `type` 、 `groups` 、 `roles` |
+| `$(__parent__.field)` | 在[子表单](../forms/subform.html)中（列表行、向导步骤），父表单的某个值 |
+
+```yaml
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+```
+
+---
+
+## 深入读取值的一部分
+
+只要路径中只包含字母、数字、 `_` 、 `-` 、 `.` 和 `[n]` ，就可以用点号和下标表示法读取值的一部分：
+
+| 占位符 | 用于 | 得到 |
+|---|---|---|
+| `$(field)` | 文本、数字或密码字段 | 该值 |
+| `$(field)` | 记录型 enum | 所选记录的 `placeholderColumn` ，否则为其第一列 |
+| `$(field.col)` | 记录型 enum | 所选记录的该列 |
+| `$(field)` | 带 `multiple: true` 的 enum | 每条所选记录的选定列，以数组形式给出 |
+| `$(field)` | 表达式、列表或常量 | 整个值（列表给出其所有行） |
+| `$(field.a.b)` 、 `$(f[0].x)` | 表达式、列表或常量 | 对象或数组的那一部分 |
+
+在 enum 上设置 `placeholderColumn: "*"` ，会让 `$(field)` 给出整条所选记录，而不是某一列。
+
+```yaml
+- name: city
+  type: enum
+  dbConfig: { name: CMDB, type: mysql }
+  query: select id, name from cmdb.city
+  valueColumn: name
+  placeholderColumn: id        # $(city) gives the id; $(city.name) still gives the name
+- name: servers
+  type: expression
+  expression: "[{name: 'web1'}, {name: 'web2'}]"
+  runLocal: true
+- name: first_server
+  type: expression
+  expression: $(servers[0].name)   # 'web1'
+  runLocal: true
+```
+
+---
+
+## 值如何写入
+
+值如何写入文本，取决于占位符所在的位置。
+
+| 位置 | 示例 | 变为 |
+|---|---|---|
+| 表达式中，引号之外 | `$(count) + 1` | JavaScript 字面量：数字仍是数字，文本变成带引号的字符串，对象或数组变成字面量 |
+| 表达式中，构成整个带引号的字符串 | `fn.fnLs('$(dir)')` | 同样的字面量，连同引号一起，因此值中含有引号也无法逃逸 |
+| 表达式中，位于更长的字符串内 | `'$(dir)/vars'` | 文本，并按该字符串进行转义 |
+| 查询、标签、帮助文本 | `where city='$(city)'` | 文本 |
+
+如果字段中的占位符尚未全部解析，该字段不会被求值；设置 `ignoreIncomplete: true` 后，缺失的值会
+以 `undefined` 写入。
+
+### 值中的反引号和 `${`
+
+从 7.3.0 起，服务器把字段值写入表达式时（远程表达式、运行
+验证、MCP 和聊天），该值不能作为代码执行。值中的反引号或 `${` 会写成 unicode 转义（ `\u0060` 、 `\u0024{` ），因此即使在模板字符串中也仍然是
+文本。服务器端表达式完全拒绝模板字符串；需要时请使用 `runLocal` 。
+
+在浏览器中求值的 `runLocal` 表达式按上表写入值，不做这种转义，所以在那里不要把
+占位符放进模板字符串中。
+
+---
+
+## 另请参阅
+
+相关页面和常见问题条目：
+
+- [本地表达式](local.html)和[远程表达式](remote.html)：大多数占位符的使用场景
+- [常见问题：级联下拉框](../faq.html#cascaded-dropdowns)和[字段占位符](../faq.html#field-placeholders)：更多示例
+- [常见问题：如何在子表单中访问父表单的数据？](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)
diff --git a/i18n/zh/_build_forms/expressions/remote.md b/i18n/zh/_build_forms/expressions/remote.md
new file mode 100644
index 0000000..56278e8
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/remote.md
@@ -0,0 +1,252 @@
+---
+layout: default
+title: 远程表达式
+parent: 表达式
+nav_order: 2
+translated_from: 8d0f7560216da4a428e1935ac2b6de7b5428c243
+---
+
+# 远程表达式
+{: .no_toc }
+
+用于日期、网络、文件、SSH 和编号名称的服务器端函数
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+以下示例使用字段属性 `runLocal: false` （默认）运行。  
+它们在服务器端求值。
+
+由于在服务器上执行代码存在安全风险，表达式会经过清理，并且只能使用
+AnsibleForms 自带的函数以及[您自己添加的函数](#your-own-functions)。  
+服务器端表达式用于从文件、REST API 和 SSH 命令等数据源获取信息。
+
+{: .important }
+内置的服务器端函数以 `fn.` 为前缀（例如 `fn.fnRestBasic` ），您自己的函数以 `fnc.` 为前缀。
+
+---
+
+## 处理日期和时间
+
+通过 [Day.js](https://day.js.org) 处理日期和时间：
+
+```javascript
+fn.fnTime().diff(fn.fnTime('2019-10-01'),'day') // number of days between now and 2019-10-01
+
+// This is the core implementation of https://day.js.org
+```
+
+---
+
+## 从 IP 获取 CIDR 信息
+
+获取某个 IP 地址和子网掩码所在的子网，并检查哪些地址属于该子网：
+
+```javascript
+fn.fnCidr('172.16.0.1','255.255.0.0')
+
+// fn.fnCidr(ip,netmask)
+// - ip : an ip address
+// - netmask : a netmask
+//  
+// it will return the Cidr subnet information as well as expose a `contains` method to check whether an ip is part of this subnet.
+// {
+//   "networkAddress":"172.16.0.0",
+//   "firstAddress":"172.16.0.1",
+//   "lastAddress":"172.16.255.254",
+//   "broadcastAddress":"172.16.255.255",
+//   "subnetMask":"255.255.0.0",
+//   "subnetMaskLength":16,
+//   "numHosts":65534,
+//   "length":65536,
+//   "contains":(ip)=>{return ...}
+// }
+```
+
+---
+
+## 获取 SSH 输出
+
+通过 SSH 在远程主机上运行命令并使用其输出：
+
+```javascript
+fn.fnSsh('root','172.16.0.1','ls -la')
+
+// fn.fnSsh(user,host,command,jq-expression,timeoutSeconds)
+// - user : the ssh user
+// - host : the host
+// - command : the command to trigger by ssh, as the remote host's shell reads it
+// - jq-expression : an optional jq-expression (https://jqplay.org), applied to the output lines
+// - timeoutSeconds : an optional time limit, 60 seconds by default; running out of time is an error
+//
+// it returns the output lines (stdout and stderr) and a last line exit(<code>) with the exit code.
+// ssh itself is started without a local shell, so the user and host can never become a second local command.
+//
+// You must use 'known_hosts' and 'public-key' to setup non-interactive password-less authentication.
+// In the settings you can find the public-key and add your target-host to known_hosts
+```
+
+---
+
+## 列出目录中的文件
+
+列出 AnsibleForms 服务器上某个目录中的文件，可选择递归并进行筛选：
+
+```javascript
+fn.fnLs('/tmp',{ recursive: true, regex: '.*\\.log$', metadata: true })
+
+// fn.fnLs(path,options)
+// - path : path to directory
+// - options : recursive:boolean, regex:string ,metadata:boolean
+//   - recursive : whether to list files recursively
+//   - regex : a regular expression, matched against the path relative to the listed directory
+//   - metadata : whether to return objects with file metadata (path, name, type, size, created, modified, ...)
+//
+// directories are always listed too, with a trailing / (such as 'logs/'), and the regex sees that slash as well
+```
+
+---
+
+## 解析 HTML 页面
+
+获取一个 HTML 页面，并提取与正则表达式匹配的部分：
+
+```javascript
+fn.fnParseHtmlWithRegex('https://ansibleguy.com','<h2.*?>(.*?)</h2>','g')
+
+// fn.fnParseHtmlWithRegex(url,regex,flags,credential)
+// - url : url to html page
+// - regex : a regular expression, groups ( ) are optional
+// - flags : regex flags (such as g,i,m), defaults to 'g'; without g only the first match is returned
+// - credential : an optional credential name, used for basic authentication
+//                (a credential without both a user and a password is ignored, the page is fetched without authentication)
+//
+// it will grab the html source and return an array with one object per match, at most 10000 :
+// { fullMatch, groups (the numbered group matches), namedGroups }
+```
+
+页面的获取受 [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS) 和
+[`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) 约束，与 REST 函数相同。但与它们不同的是，它忽略
+`REST_IGNORE_CERTS` 和 `REST_TIMEOUT_SECONDS` ：它始终校验证书，最多等待 30 秒。
+
+---
+
+## 获取 DNS 信息
+
+解析某个域名的 DNS 记录：
+
+```javascript
+fn.fnDnsResolve('ansibleguy.com','A')
+
+// fn.fnDnsResolve(fqdn,type)
+// - fqdn : a fully qualified domain name
+// - type : the type of dns record (A,AAAA,MX,NS,CNAME,TXT,SRV,PTR)
+```
+
+---
+
+## 读取 JSON 文件
+
+读取服务器上的 JSON 文件，可选择用 jq 筛选：
+
+```javascript
+fn.fnReadJsonFile('/tmp/file.json','.[].name')
+
+// fn.fnReadJsonFile(path,jq-expression)
+// - path : path to json file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## 读取 YAML 文件
+
+读取服务器上的 YAML 文件，可选择用 jq 筛选：
+
+```javascript
+fn.fnReadYamlFile('/tmp/file.yaml','.[].name')
+
+// fn.fnReadYamlFile(path,jq-expression)
+// - path : path to yaml file
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+```
+
+---
+
+## 获取带递增编号的名称
+
+在一组带递增编号的字符串中（server001、server002……），您可能需要找出下一个可用的名称。  
+此函数也可作为本地表达式使用（不带 `fn.` 前缀）。
+
+```javascript
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',false)
+// result : "server006"
+
+fn.fnGetNumberedName(['server001','server002','server005'],'server###','server001',true)
+// result : "server003"
+
+fn.fnGetNumberedName($(fieldlist),'server###','server001',true)
+// use another expression field as input for the array
+
+// fn.fnGetNumberedName(array,pattern,default,fillgaps)
+// This function searches for a numbered pattern in a list of string, 
+// increases the highest number and returns a name like the pattern
+// - array : an array object, you can use a placeholder to an expression where you know it's an array
+// - pattern : a string that hold the # as a digit
+// - default : if no value is found, return this default
+// - fillgaps : a boolean to indicate it can fill gaps in the numbers, 1,2,3,6 => 4
+```
+
+在服务器上，当第一个参数不是数组时， `fn.fnGetNumberedName` 会报错失败。而本地表达式
+（不带 `fn.` ）则返回默认值。
+
+---
+
+## 您自己的函数
+
+把您自己的 JavaScript 函数添加到 `custom.js` 中，然后在服务器表达式中用前缀 `fnc.` 调用它们。
+
+该文件导出一个由函数组成的对象。镜像自带的文件包含两个示例：
+
+```javascript
+import logger from "../lib/logger.js";
+
+const fnSum = function(a,b) {
+  logger.debug("[fnSum] sum is happening")
+  return a+b
+};
+const fnMultiply = function(a,b) {
+  logger.debug("[fnMultiply] multiply is happening")
+  return a*b
+};
+
+export default {
+  fnSum,
+  fnMultiply
+};
+```
+
+```yaml
+- name: total
+  type: expression
+  expression: fnc.fnSum($(disk_count), 10)
+```
+
+同样， `jq.custom.definitions` 存放您自己的 jq 定义。服务器运行的每个 jq 查询前面都会加上这些定义，
+因此每个函数的 [jq 查询](jq.html)都可以使用它们。
+
+在容器中，把这两个文件映射覆盖镜像中的同名文件，然后重启；服务器启动时会读取它们：
+
+```yaml
+volumes:
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+```
+
+{: .warning }
+> 每当表达式调用自定义函数时，它都会在服务器进程内以该进程的权限运行。
+> [清理器](index.html#security-concerns)只检查表达式是否只调用了 `fn.` 和 `fnc.` 函数；至于
+> 函数如何处理其参数，则由您负责。
diff --git a/i18n/zh/_build_forms/expressions/rest-apis.md b/i18n/zh/_build_forms/expressions/rest-apis.md
new file mode 100644
index 0000000..7d8b914
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/rest-apis.md
@@ -0,0 +1,158 @@
+---
+layout: default
+title: REST API
+parent: 表达式
+nav_order: 3
+translated_from: e4ceac62125b53a88d479bf7f2a0e7230edce2b2
+---
+
+# REST API
+{: .no_toc }
+
+通过基本认证、令牌或自定义认证调用 REST API
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 使用基本认证的 REST API
+
+使用已保存凭据的用户名和密码调用 REST API：
+
+```javascript
+fn.fnRestBasic(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, email:.email, spouse:.relations.spouse}]',
+  'name',
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted and transformed by javascript.
+
+// fn.fnRestBasic(method,url,body,credentialname,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential-name : it will lookup the credentials as you have saved in the gui
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort object : a sort object to order the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+```
+
+---
+
+## 使用令牌认证的 REST API
+
+使用写在表达式中的 bearer 令牌调用 REST API：
+
+```javascript
+fn.fnRestJwt(
+  'get',
+  'https://resturl/api/',
+  '',
+  'your_jwt_token_in_text',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwt(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - token : it will be add as a Bearer Authorization header
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## 使用安全令牌认证的 REST API
+
+使用从已保存凭据中获取的 bearer 令牌调用 REST API，这样令牌永远不会出现在表单中：
+
+```javascript
+fn.fnRestJwtSecure(
+  'get',
+  'https://resturl/api/',
+  '',
+  'name_of_credential_in_database',
+  '[.records[] | {name:.name, age:.age}]',
+  ['age','name'],
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted, first by age, then by name
+
+// fn.fnRestJwtSecure(method,url,body,token,jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - credential_name : Encrypted credential will be looked up.  The password will be the token.
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sort object to sort the result   
+// - hasBigInt : a boolean indicating if it should convert Int64 to string 
+// - tokenPrefix : a prefix, defaults to 'Bearer' (v5.0.0)
+```
+
+---
+
+## 使用自定义请求头的 REST API
+
+使用您自己的请求头调用 REST API，适用于其他任何认证方式：
+
+```javascript
+fn.fnRestAdvanced(
+  'get',
+  'https://resturl/api/',
+  '',
+  {'a_custom_http_header':'your_value','Authorization':'basic base64(my_rest_credential)'},
+  '.records[].name',
+  {name:{ignoreCase:true,direction:'desc'}},
+  false,
+  false
+)
+
+// output : a full json object coming from rest, json transformed with jq, result sorted descending by name
+
+// fn.fnRestAdvanced(method,url,body,{myheader:'value'},jq-expression,sort-object)
+// - method : get,post,put,delete
+// - url : url to restapi (can for example contain a placeholder like 'https://$(serverfield.fqdn)/api/'
+// - body : in case of post and put
+// - headers: an object of headers
+// - jq-expression : an optional jq-expression (https://jqplay.org)
+// - sort-object : a sorting object to order the results
+// - hasBigInt : a boolean indicating if it should convert Int64 to string
+// - raw : return data and response_headers  
+  
+// 3 function-placeholders are allowed in the headers:
+// - base64(credential_name) : will create a base64 encoded "username:password".  prefix with "basic" if required
+// - username(credential_name) : will add the username of the credential
+// - password(credential_name) : will add the password of the credential
+```
+
+---
+
+## 证书和超时
+
+从 7.3.0 起，每个 REST 辅助函数（ `fnRestBasic` 、 `fnRestAdvanced` 、 `fnRestJwt` 、 `fnRestJwtSecure` ）都会校验端点的 TLS
+证书，并在设定时间后停止等待：
+
+| 设置 | 作用 |
+|---|---|
+| [`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS) | `1` 跳过证书校验。在 7.2.0 及之前从不校验证书；请保持为 `0` ，改用 `NODE_EXTRA_CA_CERTS` 信任私有 CA |
+| [`REST_TIMEOUT_SECONDS`](../customization/security.html#env_REST_TIMEOUT_SECONDS) | 调用等待响应的时长，默认 60 秒；端点一直不响应时，字段会失败，而不是一直挂起 |
+
+从 7.3.0 起，如果字段的端点使用自签名证书，在设置这两项之一之前，该字段会因证书错误而失败。
+[REST 调用和 jq](../customization/security.html#rest-calls-and-jq) 介绍了这两项设置，以及如何一次性让所有 REST 调用信任私有 CA。
+[`fn.fnParseHtmlWithRegex`](remote.html#parse-html-page) 不是 REST 辅助函数：它忽略这两项设置，始终校验
+证书，最多等待 30 秒。
diff --git a/i18n/zh/_build_forms/expressions/sorting.md b/i18n/zh/_build_forms/expressions/sorting.md
new file mode 100644
index 0000000..43b0e9b
--- /dev/null
+++ b/i18n/zh/_build_forms/expressions/sorting.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: 排序
+parent: 表达式
+nav_order: 5
+translated_from: 56b0801754aa08a0a6c4941b373bb43d10982b98
+---
+
+# 排序
+{: .no_toc }
+
+用排序对象对数组排序
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 对数组排序
+
+用排序对象对来自表达式、REST API 或数据库的数组进行排序：
+
+```javascript
+fn.fnSort(['a','b','z','q','c'],{'':{direction:'asc'}})
+
+// output : sorts the flat array
+
+// fn.fnSort(arrayinput,sort-object)
+// - array, coming from expression or rest or database
+// - sort-object : a sorting object to order the results
+```
+
+---
+
+## 排序对象
+
+REST 函数（ `fn.fnRestBasic` 、 `fn.fnRestAdvanced` 、 `fn.fnRestJwt` 、 `fn.fnRestJwtSecure` ）接受这个排序对象
+作为参数。对于其他任何结果，例如 `fn.fnJq` 或读取文件的结果，请用 `fn.fnSort` 包裹。
+
+```javascript
+// The sorting object can have multiple forms, for example :
+
+'name' // will sort ascending on property name
+['name','email'] // will first sort on name, then on email
+{name:{direction:'desc'}} // will sort on name descending
+{name:{ignoreCase:true}} // will sort on name ascending, ignoring case
+['name',{email:{ignoreCase:true,direction:'asc'}}] // will sort on name first, then on email, ignoring case
+{'':{}} // a special case for sorting a flat array which has no headername (properties)
+{'':{direction:'desc'}} // sort a flat array descending
+```
diff --git a/i18n/zh/_build_forms/formfields/checkbox.md b/i18n/zh/_build_forms/formfields/checkbox.md
new file mode 100644
index 0000000..e3909b8
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/checkbox.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Checkbox
+parent: 表单字段
+nav_order: 8
+translated_from: 6dac54ad9b2bf8aed718b116f4a9d9be4a8184e6
+---
+
+# Checkbox 字段
+{: .no_toc }
+
+表示真或假的值，用于启用某个选项或设置标志
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`checkbox` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "checkbox" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`checkbox` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign checkbox_type = type_choice.choices | where: "name", "checkbox" | first %}
+  {%- if checkbox_type.examples %}
+    {%- for example in checkbox_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/datetime.md b/i18n/zh/_build_forms/formfields/datetime.md
new file mode 100644
index 0000000..7e5e632
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/datetime.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Datetime
+parent: 表单字段
+nav_order: 3
+translated_from: be604f929c562ff048c03f1c17e1201a053179b4
+---
+
+# Datetime 字段
+{: .no_toc }
+
+日期、时间、周、月或年份选择器
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`datetime` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "datetime" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`datetime` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign datetime_type = type_choice.choices | where: "name", "datetime" | first %}
+  {%- if datetime_type.examples %}
+    {%- for example in datetime_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/enum.md b/i18n/zh/_build_forms/formfields/enum.md
new file mode 100644
index 0000000..ea63e45
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/enum.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Enum
+parent: 表单字段
+nav_order: 10
+translated_from: 011ba48e2eebc9a26159fdf981d89b86b43de630
+---
+
+# Enum 字段
+{: .no_toc }
+
+带搜索功能的下拉框，支持单选或多选
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`enum` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "enum" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`enum` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign enum_type = type_choice.choices | where: "name", "enum" | first %}
+  {%- if enum_type.examples %}
+    {%- for example in enum_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/expression.md b/i18n/zh/_build_forms/formfields/expression.md
new file mode 100644
index 0000000..e3c44bc
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/expression.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Expression
+parent: 表单字段
+nav_order: 11
+translated_from: 30a3e37e27e9bc9e8472a027b6eb90c3260e8248
+---
+
+# Expression 字段
+{: .no_toc }
+
+由 JavaScript 计算得出的值，可在浏览器中，也可在服务器上计算
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`expression` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "expression" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`expression` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign expression_type = type_choice.choices | where: "name", "expression" | first %}
+  {%- if expression_type.examples %}
+    {%- for example in expression_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/file.md b/i18n/zh/_build_forms/formfields/file.md
new file mode 100644
index 0000000..2248bbd
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/file.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: File
+parent: 表单字段
+nav_order: 5
+translated_from: 664227c4b88ae49a9a43d37b5c0f3ce1b50d3b40
+---
+
+# File 字段
+{: .no_toc }
+
+上传文件，例如配置文件或证书
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`file` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "file" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`file` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign file_type = type_choice.choices | where: "name", "file" | first %}
+  {%- if file_type.examples %}
+    {%- for example in file_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/html.md b/i18n/zh/_build_forms/formfields/html.md
new file mode 100644
index 0000000..aae7737
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/html.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Html
+parent: 表单字段
+nav_order: 4
+translated_from: 473e446a98ddcabefb726ff75033eb3ad7135fc4
+---
+
+# Html 字段
+{: .no_toc }
+
+表单中的富 HTML 内容
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`html` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "html" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`html` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign html_type = type_choice.choices | where: "name", "html" | first %}
+  {%- if html_type.examples %}
+    {%- for example in html_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/index.md b/i18n/zh/_build_forms/formfields/index.md
new file mode 100644
index 0000000..f41b498
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/index.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: 表单字段
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /formfields/
+translated_from: f87478aaaa3db6bc7523c8f49e4aea097b90b003
+---
+
+# 表单字段
+{: .no_toc }
+
+表单的输入控件
+{: .fs-6 .fw-300 }
+
+---
+
+面向表单作者：表单可以包含的字段类型，以及每种类型支持的属性。
+
+表单字段定义了表单的输入控件。每种字段类型都有自己的属性和行为，用于收集某一类数据。
+
+根据要收集的数据选择合适的字段类型，从纯文本到结构化列表都有。
+
+---
+
+## 通用属性
+
+所有表单字段都有两个基本属性：
+
+- **name** （string，必填）：字段的唯一标识符
+- **type** （string，必填）：字段类型，决定了下面哪个页面描述其可用属性
+
+每种字段类型还会增加与其功能相关的属性。在导航侧栏或下表中选择一种字段类型，即可打开其完整的属性参考：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield = form_object.help | where: "name", "Formfield" | first %}
+{% assign formfile = formfield.items | where: "name", "type" | first %}
+
+<table>
+  <thead>
+    <tr>
+      <th style="width: 25%;">字段类型</th>
+      <th>描述</th>
+    </tr>
+  </thead>
+  <tbody>
+{% for type in formfile.choices %}
+    <tr>
+      <td><strong><a href="{{ type.name }}.html">{{ type.name }}</a></strong></td>
+      <!-- markdownify, not the raw value : a description carries markdown (`code`
+           spans) AND html-looking text. The `html` type documents that `<script>` is
+           stripped, and unfiltered that opened a real script element which swallowed
+           every row after it - the page stopped at `html`, hiding 10 of the 14 types.
+           Kramdown escapes it inside the code span. -->
+      <td>{{ type.description | markdownify }}</td>
+    </tr>
+{% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/zh/_build_forms/formfields/list.md b/i18n/zh/_build_forms/formfields/list.md
new file mode 100644
index 0000000..81615c3
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/list.md
@@ -0,0 +1,396 @@
+---
+layout: default
+title: List
+parent: 表单字段
+nav_order: 13
+translated_from: b6209effaf1cc9783a27c36669004a239751fb3e
+---
+
+# List 字段
+{: .no_toc }
+
+由多行组成的表格，每一行都在子表单中编辑
+{: .fs-6 .fw-300 }
+
+---
+
+list 字段显示一个由多行组成的表格，每一行都在专用的**子表单**面板中创建和编辑（下钻模式）。它取代了在 7.0.0 中移除的 `table` 字段。
+
+---
+
+## 主要功能
+
+list 字段提供以下功能：
+
+- 每一行都在全屏子表单中编辑，可以使用所有字段类型，包括嵌套列表。
+- 子表单本身就是一个类型为 `subform` 的独立表单，可以在不同表单的**多个 list 字段中复用**（例如客户、供应商、订单……共用同一个 `Address` 子表单）。
+- 标记属性（ `insertMarker` 、 `updateMarker` 、 `deleteMarker` ）支持幂等的 playbook 模式。
+- 当 `allowDelete: false` 时，已有的行受到保护；只有在当前会话中添加的行（带有 `insertMarker` ）才能删除。
+- `columns` 属性控制哪些子表单字段作为列显示在汇总表格中。
+- 输出始终是一个对象数组。生成 extravars 时，会遵循子表单字段上声明的 `model` 、 `output` 、 `outputObject` 和 `valueColumn` 。
+
+---
+
+## 子表单声明
+
+子表单是一个带有 `type: subform` 的独立表单，和其他表单一样放在 forms 文件夹的某个文件中。它接受与其他表单相同的 `fields` 数组，但从不出现在表单磁贴列表中，也从不直接提交。
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+```
+
+---
+
+## 属性
+
+`list` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    {% assign has_list_props = false %}
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- if var.with_types == nil or item_types contains "list" %}
+        {%- assign has_list_props = true %}
+      {%- endif %}
+    {% endfor %}
+    {% if has_list_props %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "list" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>list</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples.size > 0 %}
+        <details>
+          <summary>示例</summary>
+          {% for ex in var.examples %}
+          <p><strong>{{ ex.name }}</strong></p>
+          <pre><code class="language-yaml">{{ ex.code }}</code></pre>
+          {% endfor %}
+        </details>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endif %}
+    {% endfor %}
+  </tbody>
+</table>
+
+{%- endif %}
+
+---
+
+## 示例
+
+### 共享的地址子表单
+
+同一个表单中的两个 list 字段复用一个 `Address` 子表单：
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+      required: true
+    - name: city
+      type: text
+      label: City
+      required: true
+    - name: country
+      type: text
+      label: Country
+
+- name: Create customer
+  type: ansible
+  playbook: customer.yaml
+  roles: [default]
+  fields:
+    - name: name
+      type: text
+      label: Customer name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - city
+        - country
+      titleAdd: Add address
+      titleEdit: Edit address
+      allowInsert: true
+      allowDelete: true
+```
+
+### 标记跟踪（支持幂等）
+
+预加载的行受到保护，标记会告诉 playbook 哪些行是新增、修改或删除的：
+
+```yaml
+- name: people
+  type: list
+  label: People
+  subform: Person
+  allowDelete: false       # preloaded rows are protected
+  insertMarker: added      # session-added rows remain removable
+  updateMarker: updated
+  deleteMarker: removed
+  columns:
+    - name
+    - email
+```
+
+### 预填充行
+
+列表可以从三种来源预先填充。无论哪种情况，得到的行都必须是对象，其键与所引用子表单的字段名一致。
+
+#### 静态 `default`
+
+直接写在表单中的行：
+
+```yaml
+- name: addresses
+  type: list
+  label: Addresses
+  subform: Address
+  columns:
+    - city
+    - country
+  default:
+    - street: Main 1
+      city: Brussels
+      country: BE
+    - street: Side 22
+      city: Paris
+      country: FR
+```
+
+#### 来自 REST API（ `expression` ）
+
+由服务器端表达式从 REST API 加载的行：
+
+```yaml
+- name: users
+  type: list
+  label: Users
+  subform: User
+  columns:
+    - username
+    - email
+  expression: fn.fnRestBasic('get','https://api.example.com/users','','my_api_cred','')
+```
+
+#### 来自数据库查询（ `dbConfig` + `query` ）
+
+从数据库查询加载的行：
+
+```yaml
+- name: servers
+  type: list
+  label: Servers
+  subform: Server
+  columns:
+    - hostname
+    - role
+  dbConfig: CMDB_CONN
+  query: SELECT hostname, role FROM servers WHERE active = 1
+```
+
+#### 来自本地表达式（ `runLocal` ）
+
+由本地表达式在浏览器中计算出的行：
+
+```yaml
+- name: ports
+  type: list
+  label: Open ports
+  subform: Port
+  columns:
+    - port
+    - protocol
+  runLocal: true
+  expression: |
+    [
+      { port: 22,  protocol: 'tcp' },
+      { port: 80,  protocol: 'tcp' },
+      { port: 443, protocol: 'tcp' }
+    ]
+```
+
+### 嵌套列表
+
+子表单本身也可以包含 list 字段，从而在每一行中再嵌套一个列表：
+
+```yaml
+- name: Address
+  type: subform
+  fields:
+    - name: street
+      type: text
+      label: Street
+    - name: city
+      type: text
+      label: City
+
+- name: Person
+  type: subform
+  fields:
+    - name: name
+      type: text
+      label: Name
+      required: true
+    - name: addresses
+      type: list
+      label: Addresses
+      subform: Address
+      columns:
+        - street
+        - city
+
+- name: My Form
+  type: ansible
+  playbook: people.yaml
+  roles: [default]
+  fields:
+    - name: people
+      type: list
+      label: People
+      subform: Person
+      columns:
+        - name
+        - addresses
+```
+
+### 通过 `__parent__` 访问父表单数据
+
+子表单行编辑器打开时，AnsibleForms 会向子表单注入一个 `__parent__` 变量。它保存了**父表单所有字段值**的快照，包括常量和 vars。
+
+在子表单的字段定义中，用标准的 `$(...)` 表达式语法引用它：
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: node_type
+      type: enum
+      # only offer gpu in production environments (parent field)
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  playbook: deploy.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+      required: true
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+{: .note }
+> `__parent__` 是一个**仅限前端**的辅助变量。它会从 Ansible extravars 中移除，永远不会发送给 playbook。
+
diff --git a/i18n/zh/_build_forms/formfields/number.md b/i18n/zh/_build_forms/formfields/number.md
new file mode 100644
index 0000000..3eb368b
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/number.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Number
+parent: 表单字段
+nav_order: 6
+translated_from: d9e124b198b3304f9f9894919421d7f938676e75
+---
+
+# Number 字段
+{: .no_toc }
+
+整数或小数值，例如端口或数量
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`number` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "number" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`number` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign number_type = type_choice.choices | where: "name", "number" | first %}
+  {%- if number_type.examples %}
+    {%- for example in number_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/password.md b/i18n/zh/_build_forms/formfields/password.md
new file mode 100644
index 0000000..c46de27
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/password.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Password
+parent: 表单字段
+nav_order: 7
+translated_from: 2fa25c0e69e736fb4edc9a31a8c88e3020294fa6
+---
+
+# Password 字段
+{: .no_toc }
+
+掩码显示的值，用于密码、密钥和令牌
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`password` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "password" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`password` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign password_type = type_choice.choices | where: "name", "password" | first %}
+  {%- if password_type.examples %}
+    {%- for example in password_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/radio.md b/i18n/zh/_build_forms/formfields/radio.md
new file mode 100644
index 0000000..def1e0c
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/radio.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Radio
+parent: 表单字段
+nav_order: 9
+translated_from: b1deb8f285c46f2be77ed0f920710248c998d6f2
+---
+
+# Radio 字段
+{: .no_toc }
+
+从一组互斥选项中选择一项
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`radio` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "radio" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`radio` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign radio_type = type_choice.choices | where: "name", "radio" | first %}
+  {%- if radio_type.examples %}
+    {%- for example in radio_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/text.md b/i18n/zh/_build_forms/formfields/text.md
new file mode 100644
index 0000000..0b80442
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/text.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Text
+parent: 表单字段
+nav_order: 1
+translated_from: fa7de095c8a640826ee0825522ce2249ace822f0
+---
+
+# Text 字段
+{: .no_toc }
+
+单行文本，例如名称或主机名
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`text` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "text" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`text` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign text_type = type_choice.choices | where: "name", "text" | first %}
+  {%- if text_type.examples %}
+    {%- for example in text_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/textarea.md b/i18n/zh/_build_forms/formfields/textarea.md
new file mode 100644
index 0000000..3bf5e10
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/textarea.md
@@ -0,0 +1,131 @@
+---
+layout: default
+title: Textarea
+parent: 表单字段
+nav_order: 2
+translated_from: 9ce412065c2c12d9f6b76219033303d20447167e
+---
+
+# Textarea 字段
+{: .no_toc }
+
+多行文本，例如描述或一段配置
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`textarea` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "textarea" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`textarea` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign textarea_type = type_choice.choices | where: "name", "textarea" | first %}
+  {%- if textarea_type.examples %}
+    {%- for example in textarea_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
diff --git a/i18n/zh/_build_forms/formfields/yaml.md b/i18n/zh/_build_forms/formfields/yaml.md
new file mode 100644
index 0000000..d81c764
--- /dev/null
+++ b/i18n/zh/_build_forms/formfields/yaml.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: YAML
+parent: 表单字段
+nav_order: 14
+translated_from: c7439c165a54cf525a91d0458a268a66ee8a136f
+---
+
+# YAML 字段
+{: .no_toc }
+
+在 YAML 编辑器中编辑的结构化数据，支持校验和文件导入
+{: .fs-6 .fw-300 }
+
+---
+
+## 属性
+
+`yaml` 字段可用的属性，按用途分组：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign formfield_object = form_object.help | where: "name", "Formfield" | first %}
+
+{%- if formfield_object and formfield_object.items %}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = formfield_object.items | map: "group" | compact | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = formfield_object.items | where: "group", group %}
+    <tr>
+      <th id="formfield_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% for var in group_properties %}
+      {%- assign item_types = var.with_types | split: ", " %}
+      {%- assign type_match = false %}
+      {%- if var.with_types %}
+        {%- if item_types contains "yaml" %}
+          {%- assign type_match = true %}
+        {%- endif %}
+      {%- else %}
+        {%- assign type_match = true %}
+      {%- endif %}
+      {%- if type_match %}
+    <tr>
+      <td>
+        <span id="formfield_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.name == "type" %}
+        <div>
+          <strong>值：</strong><br>
+          <span>{{ page.title | downcase }}</span>
+        </div>
+        {% elsif var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+      </td>
+    </tr>
+      {%- endif %}
+    {% endfor %}
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+`yaml` 字段示例（YAML）：
+
+{%- assign type_choice = formfield_object.items | where: "name", "type" | first %}
+{%- if type_choice.choices %}
+  {%- assign yaml_type = type_choice.choices | where: "name", "yaml" | first %}
+  {%- if yaml_type.examples %}
+    {%- for example in yaml_type.examples %}
+
+### {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}字段定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+    {%- endfor %}
+  {%- endif %}
+{%- endif %}
+
+{%- endif %}
+
+---
+
+## 通过 `__parent__` 访问父表单数据
+
+当 `yaml` 字段使用 `subform` 模式时，AnsibleForms 会向子表单注入一个 `__parent__` 变量。它保存了编辑器打开那一刻**父表单所有字段值**的快照，包括常量和 vars。
+
+在子表单的字段定义中，用标准的 `$(...)` 表达式语法引用它：
+
+```yaml
+- name: NetworkConfig
+  type: subform
+  fields:
+    - name: interface
+      type: text
+      label: Interface
+      required: true
+
+    - name: vlan
+      type: enum
+      label: VLAN
+      # filter available VLANs based on the parent's selected region
+      query: "select id,name from vlans where region='$(__parent__.region)'"
+      dbConfig:
+        name: MYDB
+        type: mysql
+      valueColumn: id
+      placeholderColumn: name
+
+    - name: mtu
+      type: number
+      label: MTU
+      # default to 9000 in production, 1500 elsewhere
+      default: "'$(__parent__.environment)' === 'production' ? 9000 : 1500"
+      evalDefault: true
+
+- name: Configure server
+  type: ansible
+  playbook: configure.yml
+  roles: [default]
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: region
+      type: enum
+      values: [eu-west-1, us-east-1, ap-southeast-1]
+
+    - name: nic
+      type: yaml
+      label: Network interface
+      subform: NetworkConfig
+```
+
+{: .note }
+> `__parent__` 是一个**仅限前端**的辅助变量。它会从 Ansible extravars 中移除，永远不会发送给 playbook。
diff --git a/i18n/zh/_build_forms/forms/ansible.md b/i18n/zh/_build_forms/forms/ansible.md
new file mode 100644
index 0000000..2a23bae
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/ansible.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Ansible 表单
+parent: 表单
+nav_order: 2
+translated_from: 804c2e6a40f7cec1287a7aa1df63085190c4ac36
+---
+
+# Ansible 表单
+{: .no_toc }
+
+运行本地 Ansible playbook 的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign ansible_choice = type_prop.choices | where: "name", "ansible" | first %}
+
+{{ ansible_choice.description | markdownify }}
+
+{% if ansible_choice.examples.size > 0 %}
+{% for e in ansible_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: ansible` 特有的属性，是对[通用表单属性](common.html)的补充。
+
+{% assign ansible_props = form_object.items | where_exp: "p", "p.with_types contains 'ansible'" %}
+{% assign ansible_groups = ansible_props | map: "group" | uniq | sort_natural %}
+{% for group in ansible_groups %}
+{% assign group_props = ansible_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="ansible_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/approval.md b/i18n/zh/_build_forms/forms/approval.md
new file mode 100644
index 0000000..cf78268
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/approval.md
@@ -0,0 +1,101 @@
+---
+layout: default
+title: 审批点
+parent: 表单
+nav_order: 8
+translated_from: c2784dd4ac7ac41ef7f18fafdc4a6c468575c405
+---
+
+# 审批点
+{: .no_toc }
+
+暂停作业，直到有人批准
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作原理
+
+审批点会让作业在表单中它所在的位置暂停，直到审批人作出回应：
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign approval_object = form_object.help | where: "name", "Approval point" | first %}
+
+{{ approval_object.description | markdownify }}
+
+---
+
+## 批准自己的作业
+
+从 7.3.0 起，运行作业的用户不能批准该作业，即使拥有该审批的某个角色也不行，因此需要第二个人；管理员始终可以批准，包括自己的作业。
+运行者仍然可以拒绝（撤回）自己的作业。如果也允许运行者批准，请设置 `allowSelf: true` ，例如在测试表单中：
+
+```yaml
+approval:
+  title: Approve the change
+  message: Please approve this change
+  roles:
+    - approvers
+  allowSelf: true
+```
+
+---
+
+## 属性
+
+审批点的属性：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in approval_object.items %}
+    <tr>
+      <td>
+        <span id="approval_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{var.version}} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+审批点示例（YAML）：
+
+{% for example in approval_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/awx.md b/i18n/zh/_build_forms/forms/awx.md
new file mode 100644
index 0000000..4656127
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/awx.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: AWX 表单
+parent: 表单
+nav_order: 3
+translated_from: f5e3e7166f35525eb66bcbd7e085776f44d37c33
+---
+
+# AWX 表单
+{: .no_toc }
+
+运行 AWX、AAP 或 Ascender 作业模板的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign awx_choice = type_prop.choices | where: "name", "awx" | first %}
+
+{{ awx_choice.description | markdownify }}
+
+{% if awx_choice.examples.size > 0 %}
+{% for e in awx_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: awx` 特有的属性，是对[通用表单属性](common.html)的补充。
+
+{% assign awx_props = form_object.items | where_exp: "p", "p.with_types contains 'awx'" %}
+{% assign awx_groups = awx_props | map: "group" | uniq | sort_natural %}
+{% for group in awx_groups %}
+{% assign group_props = awx_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="awx_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/common.md b/i18n/zh/_build_forms/forms/common.md
new file mode 100644
index 0000000..fb96b94
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/common.md
@@ -0,0 +1,104 @@
+---
+layout: default
+title: 通用属性
+parent: 表单
+nav_order: 1
+translated_from: ce05875209a1cab9ae70d0168723f3aa615e6635
+---
+
+# 通用表单属性
+{: .no_toc }
+
+所有表单类型共有的属性
+{: .fs-6 .fw-300 }
+
+---
+
+这些属性适用于**所有表单类型**： `ansible` 、 `awx` 、 `aap` 、 `ascender` 、 `semaphore` 、 `rundeck` 、 `jenkins` 、
+`workflow` 、 `multistep` （已弃用）和 `subform` 。
+
+其他所有属性都是特定于类型的，记录在相应表单类型的页面中。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign common_props = form_object.items | where_exp: "p", "p.with_types == nil" %}
+
+{{ form_object.description | markdownify }}
+
+---
+
+## 属性
+
+所有表单类型共有的属性：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in common_props %}
+    <tr>
+      <td>
+        <span id="common_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique == true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.docsObjectLink %}
+          {% assign link_start = var.docsObjectLink | slice: 0 %}
+          <a href="{% if link_start == '/' %}{{ var.docsObjectLink | relative_url }}{% else %}{{ var.docsObjectLink }}{% endif %}">🔗 
+          {% endif %}
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+          {% if var.docsObjectLink %}
+          </a>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
diff --git a/i18n/zh/_build_forms/forms/index.md b/i18n/zh/_build_forms/forms/index.md
new file mode 100644
index 0000000..e461fcb
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: 表单
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /forms/
+translated_from: 8cf41438dcd6f75b145856a890b8bbbcd674c9fc
+---
+
+# 表单
+{: .no_toc }
+
+定义用户要填写的表单
+{: .fs-6 .fw-300 }
+
+---
+
+面向表单作者：表单如何用 YAML 编写、从哪里加载，以及每种表单类型的属性。
+
+表单是 AnsibleForms 的核心。每个表单都是一个网页界面，用于收集用户输入，并利用这些数据运行
+Ansible playbook、AWX、AAP 或 Ascender 模板、Semaphore 模板、Rundeck 或 Jenkins 作业，或者一个
+[工作流](../workflows/)。
+
+表单定义在 forms 文件夹中的 YAML 文件里。每个 YAML 文件包含一个表单或一个表单列表，并且可以用子文件夹来组织它们。
+
+**视频**：[创建您的第一个表单](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+---
+
+## 了解表单结构
+
+AnsibleForms 中的每个表单都通过一组属性来配置。**[通用属性](common.html)** 列出了适用于所有表单类型的属性；各类型专属页面介绍其余的属性。
+
+---
+
+## 表单的加载方式
+
+AnsibleForms 从以下位置加载表单：
+
+1. **从仓库加载**：所有开启了“用于表单”开关的仓库（支持多个仓库）
+   - 所有已启用仓库中的表单会自动合并。
+   - 每个仓库首先检查是否有 `forms/` 子文件夹。
+   - 如果没有 `forms/` 子文件夹，则使用仓库根目录。
+   - 在设计器中创建但尚未推送的表单保存在暂存文件夹中
+     （ [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) ），并与它们一起加载。
+
+2. **从本地文件夹加载**：当没有仓库开启“用于表单”时，使用本地 `forms/` 文件夹
+   （ [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) ）
+
+{: .warning }
+> **注意：** 在多个仓库上开启“用于表单”时，它们的所有表单都会合并。表单名称在各仓库之间必须唯一，以避免冲突。
+
+---
+
+## 表单在哪里运行
+
+表单的类型决定了其作业在哪类[运行器](../runners.html)上运行： `ansible` 使用 RTE， `awx` 、
+`aap` 和 `ascender` 使用 AWX 运行器， `semaphore` 、 `rundeck` 和 `jenkins` 则使用各自类型的运行器。
+
+- 在表单上设置 `runner: <name>` ，可按名称选择该类型的某个运行器；不设置时，作业在该类型的默认运行器上运行。
+- 如果运行器在**连接 > 运行器**中被禁用，作业就会失败，无论是表单指定了它，还是它是默认运行器。作业
+  永远不会退回到其他运行器。
+- 当用户的某个角色在 `config.yaml` 中列出了 `runners` 时，作业只能在这类角色所列的运行器上运行，否则会被
+  拒绝。没有该列表的角色不做限制，管理员也从不受限。
+
+---
+
+## 本节内容
+
+以下页面详细介绍表单属性：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [通用属性](common.html) | 适用于所有表单类型的属性（ `name` 、 `description` 、 `help` 、 `type` 、 `fields` ） |
+| [Ansible 表单](ansible.html) | `type: ansible` 特有的属性 |
+| [AWX 表单](awx.html) | `type: awx` 特有的属性 |
+| [Semaphore 表单](semaphore.html) | `type: semaphore` 特有的属性，用于运行 Semaphore 模板 |
+| [Rundeck 表单](rundeck.html) | `type: rundeck` 特有的属性，用于运行 Rundeck 作业 |
+| [Jenkins 表单](jenkins.html) | `type: jenkins` 特有的属性，用于构建 Jenkins 作业 |
+| [多步骤表单](multistep.html) | `type: multistep` 特有的属性，已弃用，建议改用 `workflow` |
+| [工作流表单](workflow.html) | `type: workflow` 特有的属性，用于运行[工作流](../workflows/) |
+| [向导](wizard.html) | 把表单的输入拆分到多个页面（适用于任何可执行的表单类型） |
+| [子表单](subform.html) | 子表单只使用通用属性 |
+| [审批点](approval.html) | 暂停作业，直到获得批准（ `approval` ） |
+| [通知](notifications.html) | 在作业状态变化或发生事件时发送邮件和通道消息（ `notifications` ） |
+| [作业状态动作](job-status-action.html) | 在作业状态变化时对表单执行操作（ `onSubmit` 、 `onSuccess` ……） |
diff --git a/i18n/zh/_build_forms/forms/jenkins.md b/i18n/zh/_build_forms/forms/jenkins.md
new file mode 100644
index 0000000..2a29ee0
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/jenkins.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Jenkins 表单
+parent: 表单
+nav_order: 3.3
+translated_from: ff34be9b166e1c7956605787e9e6addc03bc2c57
+---
+
+# Jenkins 表单
+{: .no_toc }
+
+构建 Jenkins 作业的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign jenkins_choice = type_prop.choices | where: "name", "jenkins" | first %}
+
+{{ jenkins_choice.description | markdownify }}
+
+{% if jenkins_choice.examples.size > 0 %}
+{% for e in jenkins_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: jenkins` 特有的属性，是对[通用表单属性](common.html)的补充。
+
+{% assign jenkins_props = form_object.items | where_exp: "p", "p.with_types contains 'jenkins'" %}
+{% assign jenkins_groups = jenkins_props | map: "group" | uniq | sort_natural %}
+{% for group in jenkins_groups %}
+{% assign group_props = jenkins_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="jenkins_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/job-status-action.md b/i18n/zh/_build_forms/forms/job-status-action.md
new file mode 100644
index 0000000..66197ce
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/job-status-action.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: 作业状态动作
+parent: 表单
+nav_order: 10
+translated_from: c374578652c98b4c2c68f068809f16c22e304147
+---
+
+# 作业状态动作
+{: .no_toc }
+
+在作业提交、成功、失败或结束时对表单执行操作
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign jobstatus_object = form_object.help | where: "name", "Job Status Action" | first %}
+
+{{ jobstatus_object.description | markdownify }}
+
+可用的钩子如下：
+
+- `onSubmit` ：表单提交时触发
+- `onSuccess` ：作业成功完成时触发
+- `onFailure` ：作业失败时触发
+- `onFinish` ：作业结束时触发，无论其状态如何
+- `onAbort` ：作业被中止时触发
+
+---
+
+## 属性
+
+作业状态动作的属性：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in jobstatus_object.items %}
+    <tr>
+      <td>
+        <span id="jobstatus_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{var.version}} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+作业状态动作示例（YAML）：
+
+{% for example in jobstatus_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/multistep.md b/i18n/zh/_build_forms/forms/multistep.md
new file mode 100644
index 0000000..eaa20b8
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/multistep.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: 多步骤表单
+parent: 表单
+nav_order: 5
+translated_from: b509f2f7365a2066cabfe1061fdb48c12c33ccbd
+---
+
+# 多步骤表单
+{: .no_toc }
+
+在一个表单中按顺序运行多个 playbook 或模板
+{: .fs-6 .fw-300 }
+
+---
+
+{: .warning }
+> `multistep` 自 7 起已弃用，并将在 8 中移除：请改用[工作流](workflow.html)。multistep 能做的事，工作流
+> 都能做，而且还支持条件、每个节点各自的值、审批节点以及并行运行的分支。
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign multistep_choice = type_prop.choices | where: "name", "multistep" | first %}
+{% assign step_object = form_object.help | where: "name", "Step" | first %}
+{% assign steps_prop = form_object.items | where: "name", "steps" | first %}
+
+{{ multistep_choice.description | markdownify }}
+
+{% if multistep_choice.examples.size > 0 %}
+{% for e in multistep_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 表单级属性
+
+多步骤表单在一个表单级属性中定义其所有步骤：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ steps_prop.name }}</strong><br>
+        <span class="af-type">{{ steps_prop.type }}</span><span class="af-required"> / 必填</span>
+      </td>
+      <td>
+        <p><strong>{{ steps_prop.short }}</strong></p>
+        {{ steps_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% assign multistep_props = form_object.items | where_exp: "p", "p.with_types contains 'multistep'" %}
+
+除 `steps` 之外，多步骤表单还接受以下表单级属性，它们记录在 [Ansible 表单](ansible.html)页面中：
+{% for p in multistep_props %}{% if p.name != "steps" %}[`{{ p.name }}`](ansible.html#ansible_{{ p.name }}){% if p.required == true %}（必填）{% endif %}{% unless forloop.last %}, {% endunless %}{% endif %}{% endfor %}.
+
+---
+
+## 步骤属性
+
+{{ step_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = step_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = step_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="step_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="step_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{var.version}} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}   
+        {% if var.with_types!=nil %}
+        <div>
+          <strong class="af-with-types">仅适用于以下类型：</strong><br>
+          <span>{{ var.with_types }}</span>
+          <br><br>
+        </div>
+        {% endif %}                          
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">新增</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if step_object.examples %}          
+    <tr>
+      <th id="step_examples" colspan="2">
+        示例
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in step_object.examples %}
+        <div>
+          <p id="step_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}            
+      </td>
+    </tr>      
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+多步骤表单按顺序运行多个作业，每个步骤运行自己的 playbook 或 AWX 模板。所有步骤共享表单的字段：默认情况下，每个步骤都会收到完整的 extravars，而步骤的 `key` 会把它限制为其中的那一部分。
+
+### 创建并配置服务器
+
+每个步骤收到 extravars 中属于自己的部分：一个 AWX 步骤创建服务器，一个 Ansible 步骤配置其网络，最后一个步骤总是发送报告：
+
+```yaml
+name: Server Provisioning
+type: multistep
+roles:
+  - default
+categories:
+  - Setup
+steps:
+  - name: Create server
+    type: awx
+    template: Create VM
+    key: server              # receives only the `server` part of the extravars
+  - name: Configure network
+    type: ansible
+    playbook: configure_network.yml
+    key: network             # receives only the `network` part of the extravars
+  - name: Send report
+    type: ansible
+    playbook: email.yml
+    always: true             # runs even when an earlier step failed
+fields:
+  - name: server_name
+    type: text
+    model: server.name
+  - name: environment
+    type: enum
+    values:
+      - dev
+      - prod
+    model: server.environment
+  - name: ip_address
+    type: text
+    model: network.ip
+  - name: gateway
+    type: text
+    model: network.gateway
+```
diff --git a/i18n/zh/_build_forms/forms/notifications.md b/i18n/zh/_build_forms/forms/notifications.md
new file mode 100644
index 0000000..f79f5fe
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/notifications.md
@@ -0,0 +1,120 @@
+---
+layout: default
+title: 通知
+parent: 表单
+nav_order: 9
+translated_from: 3c44a310353f7884a0d2d1e3a827f8a757f7d25d
+---
+
+# 通知
+{: .no_toc }
+
+在作业结束或发生某些事情时发送邮件或通道消息
+{: .fs-6 .fw-300 }
+
+---
+
+表单的 `notifications` 规定了谁会收到其作业的消息，以及何时收到：
+
+- **谁**： `recipients` ，即邮件地址；以及 `channels` ，即
+  [通知通道](../notification-channels.html)的名称（邮件、Slack、Microsoft Teams、Telegram、webhook）。两者
+  至少需要其一。
+- **何时**： `onStatus` ，在作业结束时（ `success` 、 `failed` 、 `aborted` 、 `warning` 或 `any` ）；以及 `onEvent` ，在
+  作业发生某些事情时（ `launch` 、 `relaunch` 、 `delete` 、 `approve` 、 `reject` 或 `any` ）。
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-teams
+  onStatus:
+    - failed
+  onEvent:
+    - approve
+    - reject
+```
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign notifications_object = form_object.help | where: "name", "Notifications" | first %}
+
+{{ notifications_object.description | markdownify }}
+
+---
+
+## 属性
+
+`notifications` 对象的属性：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in notifications_object.items %}
+    <tr>
+      <td>
+        <span id="{{notifications_object.name}}_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{var.version}} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}               
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>   
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+
+---
+
+## 示例
+
+通知示例（YAML）：
+
+{% for example in notifications_object.examples %}
+### {{ forloop.index }}) {{ example.name }}
+
+{% if example.description %}{{ example.description | markdownify }}{% elsif example.short %}{{ example.short }}{% else %}定义（YAML）：{% endif %}
+
+```yaml
+{{ example.code }}
+```
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/rundeck.md b/i18n/zh/_build_forms/forms/rundeck.md
new file mode 100644
index 0000000..327a49a
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/rundeck.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Rundeck 表单
+parent: 表单
+nav_order: 3.2
+translated_from: 2ea4d32ab60fa14c631358d16bc118485437ecb1
+---
+
+# Rundeck 表单
+{: .no_toc }
+
+运行 Rundeck 作业的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign rundeck_choice = type_prop.choices | where: "name", "rundeck" | first %}
+
+{{ rundeck_choice.description | markdownify }}
+
+{% if rundeck_choice.examples.size > 0 %}
+{% for e in rundeck_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: rundeck` 特有的属性，是对[通用表单属性](common.html)的补充。
+
+{% assign rundeck_props = form_object.items | where_exp: "p", "p.with_types contains 'rundeck'" %}
+{% assign rundeck_groups = rundeck_props | map: "group" | uniq | sort_natural %}
+{% for group in rundeck_groups %}
+{% assign group_props = rundeck_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="rundeck_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/semaphore.md b/i18n/zh/_build_forms/forms/semaphore.md
new file mode 100644
index 0000000..1118578
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/semaphore.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Semaphore 表单
+parent: 表单
+nav_order: 3.1
+translated_from: 34f55c2309cb70bf641b642cafc27b0e703c89e6
+---
+
+# Semaphore 表单
+{: .no_toc }
+
+运行 Semaphore UI 模板的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign semaphore_choice = type_prop.choices | where: "name", "semaphore" | first %}
+
+{{ semaphore_choice.description | markdownify }}
+
+{% if semaphore_choice.examples.size > 0 %}
+{% for e in semaphore_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: semaphore` 特有的属性，是对[通用表单属性](common.html)的补充。
+
+{% assign semaphore_props = form_object.items | where_exp: "p", "p.with_types contains 'semaphore'" %}
+{% assign semaphore_groups = semaphore_props | map: "group" | uniq | sort_natural %}
+{% for group in semaphore_groups %}
+{% assign group_props = semaphore_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="semaphore_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/forms/subform.md b/i18n/zh/_build_forms/forms/subform.md
new file mode 100644
index 0000000..7cde915
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/subform.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: 子表单
+parent: 表单
+nav_order: 4
+translated_from: 25524e14dc072b76c778d7f92adbfbc5f82d3519
+---
+
+# 子表单
+{: .no_toc }
+
+可复用的表单片段，用于 list 字段、yaml 字段和向导页面
+{: .fs-6 .fw-300 }
+
+---
+
+子表单是一个可复用的表单片段。它不会出现在磁贴视图中，也不能直接提交。它由以下方式引用：
+
+- [`list`](../formfields/list.html) 字段：为每一行打开子表单作为下钻编辑器
+- 带有 `subform` 属性的 [`yaml`](../formfields/yaml.html) 字段：为单个对象打开子表单作为下钻编辑器
+- [`wizard`](wizard.html) 步骤：把子表单渲染为向导的一个页面
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign subform_choice = type_prop.choices | where: "name", "subform" | first %}
+
+{{ subform_choice.description | markdownify }}
+
+{% if subform_choice.examples.size > 0 %}
+{% for e in subform_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+子表单**没有特定于类型的属性**。它们只使用[通用表单属性](common.html)： `name` 、 `description` 、 `help` 、 `type` 和 `fields` 。
+
+当子表单用作向导页面时，它的 `description` 和 `help` 为该步骤的 `title` 和 `help` 提供默认值。它还可以设置 `showHelp` ，在页面加载时展开该帮助。
+
+执行相关的属性（ `playbook` 、 `template` 、 `roles` 、 `inventory` 等）不适用于子表单，因为子表单从不直接提交。
+
diff --git a/i18n/zh/_build_forms/forms/wizard.md b/i18n/zh/_build_forms/forms/wizard.md
new file mode 100644
index 0000000..b8eb739
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/wizard.md
@@ -0,0 +1,210 @@
+---
+layout: default
+title: 向导
+parent: 表单
+nav_order: 7
+translated_from: aec059391571165259ed43449b0450d0ef7f6cf2
+---
+
+# 向导
+{: .no_toc }
+
+用“返回”和“下一步”把表单输入拆分到多个页面
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign wizard_prop = form_object.items | where: "name", "wizard" | first %}
+{% assign wizard_object = form_object.help | where: "name", "Wizard step" | first %}
+
+---
+
+## 什么是向导？
+
+**向导**把单个表单变成一系列页面。每个页面都由一个 [`subform`](subform.html) 渲染，用户通过**返回**和**下一步**按钮浏览。校验按页面执行：在当前步骤有效之前，用户无法继续前进，除非该步骤标记为 `optional` 。
+
+每个向导的末尾都会自动追加一个只读的**审阅页面**。它列出每个步骤及其收集到的值，方便用户在提交前确认。审阅页面**不**在 YAML 中声明；其标题取自当前使用的语言。
+
+提交时，**所有步骤收集到的值会合并成一份 extravars**，发送给底层的 playbook、模板或工作流，效果与用户填写了一个大表单完全相同。
+
+带有 `wizard` 的表单不需要自己的 `fields` ，但不能设置 `enableForChat` ，而且 `subform` 本身不能有 `wizard` 。[运行验证](../launch-validation/rolling-it-out.html#wizard-forms)会逐个步骤检查向导的运行。
+
+{: .note }
+> 关于 `wizard` 与工作流有何不同，以及二者如何结合，请参阅常见问题条目[向导和工作流有什么区别？](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow)。
+
+---
+
+## 表单级属性
+
+向导通过一个表单级属性启用：
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>
+        <strong>{{ wizard_prop.name }}</strong><br>
+        <span class="af-type">{{ wizard_prop.type }}</span>
+        {% if wizard_prop.version %}<br><span class="af-version">在版本 {{ wizard_prop.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p><strong>{{ wizard_prop.short }}</strong></p>
+        {{ wizard_prop.description | markdownify }}
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+{% if wizard_prop.examples %}
+**示例：**
+{% for e in wizard_prop.examples %}
+
+*{{ forloop.index }}) {{ e.name }}*
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 向导步骤属性
+
+{{ wizard_object.description | markdownify }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% assign groups = wizard_object.items | map: "group" | uniq | sort_natural %}
+    {% for group in groups %}
+    {% assign group_properties = wizard_object.items  | where: "group",group %}
+    {% if group %}
+    <tr>
+      <th id="wizard_{{ group }}_group" colspan="2" class="af-group-header">
+        {{ group }}
+      </th>
+    </tr>
+    {% endif %}
+    {% for var in group_properties %}
+    <tr>
+      <td>
+        <span id="wizard_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type}}</span>
+        {% if var.required==true %}<span class="af-required"> / 必填</span>{% endif %}
+        {% if var.unique==true %}<span class="af-unique"> / 唯一</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{var.version}} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{var.short}}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>
+          {{ var.description | markdownify }}
+        </p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong><br>
+          <span>{{ var.default }}</span>
+        </div>
+        {% endif %}
+        {% for c in var.changelog %}
+        <div class="af-changelog">
+          {% if c.type == "added" %}
+          <div class="af-changelog-header">
+            <span class="af-badge af-badge-added">新增</span>
+            <span class="af-badge af-badge-version">{{ c.version }}</span>
+          </div>
+          {% endif %}
+          <p>
+            {{ c.description | markdownify }}
+          </p>
+        </div>
+        {% endfor %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% endif %}
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endfor %}
+    {% endfor %}
+    {% if wizard_object.examples %}
+    <tr>
+      <th id="wizard_examples" colspan="2">
+        示例
+      </th>
+    </tr>
+    <tr>
+      <td colspan="2">
+        {% for e in wizard_object.examples %}
+        <div>
+          <p id="wizard_examples_{{ forloop.index }}"><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+      </td>
+    </tr>
+    {% endif %}
+  </tbody>
+</table>
+
+---
+
+## 将向导与工作流结合
+
+向导可以叠加在[工作流](workflow.html)表单之上。当每个向导步骤的 `defaultModel` 与对应工作流节点的 [`extra_vars_key`](../workflows/file.html#ansibleforms-own-keys) 一致时，每个 playbook 或模板只会收到来自其对应向导页面的值。
+
+常见问题中有一个完整示例，以及合并后 extravars 的结构：[向导和工作流有什么区别？](../faq.html#what-is-the-difference-between-a-wizard-and-a-workflow)（ *组合使用（在工作流之上叠加向导）* 一节）。
+
+在已弃用的 [`multistep`](multistep.html) 表单上使用向导也是同样的方式，只是用步骤的 [`key`](multistep.html#step_key) 代替 `extra_vars_key` 。
+
+---
+
+## 另请参阅
+
+相关页面和常见问题条目：
+
+- [子表单](subform.html)：向导页面由子表单渲染
+- [工作流表单](workflow.html)：在执行层面与向导相对应的功能
+- [子表单中的 `__parent__`](../faq.html#how-do-i-access-parent-form-data-inside-a-subform)：如何在后面的步骤中引用前面的向导步骤
diff --git a/i18n/zh/_build_forms/forms/workflow.md b/i18n/zh/_build_forms/forms/workflow.md
new file mode 100644
index 0000000..efe71e1
--- /dev/null
+++ b/i18n/zh/_build_forms/forms/workflow.md
@@ -0,0 +1,111 @@
+---
+layout: default
+title: 工作流表单
+parent: 表单
+nav_order: 6
+translated_from: 84ff9fbe71945ce4437cf82034f80a6bfa8b3691
+---
+
+# 工作流表单
+{: .no_toc }
+
+运行设计器中某个工作流的表单
+{: .fs-6 .fw-300 }
+
+---
+
+{% assign help = site.data.help %}
+{% assign formsyaml = help | where: "link", "forms" | first %}
+{% assign form_object = formsyaml.help | where: "name", "Form" | first %}
+{% assign type_prop = form_object.items | where: "name", "type" | first %}
+{% assign workflow_choice = type_prop.choices | where: "name", "workflow" | first %}
+
+{{ workflow_choice.description | markdownify }}
+
+{% if workflow_choice.examples.size > 0 %}
+{% for e in workflow_choice.examples %}
+**{{ e.name }}**
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+{% endfor %}
+{% endif %}
+
+---
+
+## 属性
+
+`type: workflow` 特有的属性，是对[通用表单属性](common.html)的补充。
+[工作流](../workflows/)一节介绍工作流文件本身。
+
+{% assign workflow_props = form_object.items | where_exp: "p", "p.with_types contains 'workflow'" %}
+{% assign workflow_groups = workflow_props | map: "group" | uniq | sort_natural %}
+{% for group in workflow_groups %}
+{% assign group_props = workflow_props | where: "group", group %}
+
+---
+
+## {{ group | capitalize }}
+
+<table>
+  <thead>
+    <tr>
+      <th>属性</th>
+      <th>说明</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for var in group_props %}
+    <tr>
+      <td>
+        <span id="workflow_{{ var.name }}"><strong>{{ var.name }}</strong></span><br>
+        <span class="af-type">{{ var.type }}</span>
+        {% if var.required == true %}<span class="af-required"> / 必填</span>{% endif %}
+        <br>
+        {% if var.version %}<span class="af-version">在版本 {{ var.version }} 中添加</span>{% endif %}
+      </td>
+      <td>
+        <p>
+          <strong>{{ var.short }}</strong><br>
+          {% if var.allowed != nil %}
+          <span class="af-type">{{ var.allowed }}</span>
+          {% endif %}
+        </p>
+        <p>{{ var.description | markdownify }}</p>
+        {% if var.choices.size > 0 %}
+        <div>
+          <strong>选项：</strong><br>
+          <ul class="af-choices-list">
+            {% for c in var.choices %}
+            <li>
+              {% if c.name == var.default %}
+              <span title="{{ c.description }}" class="af-default-choice">{{ c.name }}（默认）</span>
+              {% else %}
+              <span title="{{ c.description }}">{{ c.name }}</span>
+              {% endif %}
+            </li>
+            {% endfor %}
+          </ul>
+        </div>
+        {% elsif var.default != nil %}
+        <div>
+          <strong>默认值：</strong> {{ var.default }}
+        </div>
+        {% endif %}
+        {% if var.examples %}
+        <p><strong>示例：</strong></p>
+        {% for e in var.examples %}
+        <div>
+          <p><strong>{{ forloop.index }}) {{ e.name }}</strong></p>
+{% highlight yaml %}
+{{ e.code }}
+{% endhighlight %}
+        </div>
+        {% endfor %}
+        {% endif %}
+      </td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% endfor %}
diff --git a/i18n/zh/_build_forms/launch-validation/file-uploads.md b/i18n/zh/_build_forms/launch-validation/file-uploads.md
new file mode 100644
index 0000000..71328ac
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/file-uploads.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: 文件上传
+parent: 运行验证
+nav_order: 4
+translated_from: 5756d90b62ddac51996f0bdb05befd6bf5589e0d
+---
+
+# 文件上传
+{: .no_toc }
+
+文件字段如何验证
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+文件字段从不相信运行请求中关于文件的描述。运行验证会检查文件本身，即服务器
+磁盘上的文件。
+
+---
+
+## 上传的文件如何到达作业
+
+文件在表单运行之前上传，分两步：
+
+1. 浏览器通过 `POST /api/v2/job/upload` 上传文件。服务器把它保存在 `UPLOAD_PATH` 中。
+2. 运行请求在其 `files` 部分描述这次上传。
+
+随后运行验证会将该描述与磁盘进行核对：
+
+* 文件必须存在于 `UPLOAD_PATH` 之内。
+* 其路径和大小从磁盘读取，从不取自请求。
+
+---
+
+## 接受什么
+
+文件字段只从经过核实的上传中获取值。其他一切都会被丢弃：
+
+* 调用方写入 `rawFormData` 或 `extravars` 的路径会被忽略。
+* 没有真实上传的必填文件字段会报告为 `missing` 。
+
+---
+
+## 文件规则
+
+文件字段的规则会针对真实上传的文件检查，大小以字节为单位：
+
+```yaml
+- name: firmware
+  type: file
+  required: true
+  maxSize: 104857600        # 100 MB
+  regex:
+    expression: '\.bin$'
+    description: Upload a .bin firmware image
+```
+
+`minSize` 和 `maxSize` 比较文件的真实大小， `regex` 比较其文件名。与任何表单无关，
+`UPLOAD_MAX_GB` 限制单次上传的大小（默认 10 GB）。
diff --git a/i18n/zh/_build_forms/launch-validation/index.md b/i18n/zh/_build_forms/launch-validation/index.md
new file mode 100644
index 0000000..5597b3b
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/index.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: 运行验证
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /launch-validation/
+translated_from: 6b86704480781edc0ab1c24c25993fc2e220abf3
+---
+
+# 运行验证
+{: .no_toc }
+
+在服务器上检查表单的每一次运行
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员和表单作者：让服务器检查每一次运行、其规则和 extravars，无论运行请求来自谁。
+
+无论是谁或什么运行表单，这项检查都适用：浏览器、调用 REST API 的脚本，
+或者通过 MCP 服务器的 AI 代理。
+
+---
+
+## 为什么需要它
+
+表单的规则（ `required` 、 `regex` 、 `minValue` 、 `sameAs` ……）一直都是在
+浏览器中检查的。随后浏览器向 `POST /api/v2/job` 发送两样东西：
+
+- `rawFormData` ：用户填写的字段值；
+- `extravars` ：playbook 收到的内容，由浏览器根据这些值构建。
+
+没有运行验证时，服务器两者都信任。任何持有有效令牌的人都可以直接调用该
+端点，发送任意 extravars，不受任何 regex、必填字段或列表规则的约束。
+对于只在浏览器中使用的表单，这也许可以接受；但对于
+由其他系统通过 REST 运行的表单，这意味着表单的规则根本没有得到执行。
+
+服务器也无法区分来自浏览器的请求和脚本发送的请求：
+两者使用相同的端点、相同的令牌和相同的请求体，而且用户可以修改
+自己浏览器发出的任何请求。只有在服务器上做的检查才可信，运行
+验证正是这样的检查。
+
+---
+
+## 三种运行途径
+
+运行如何验证，取决于它的来源以及运行验证模式：
+
+| 运行方 | 验证方式 | 作业使用的 extravars |
+|---|---|---|
+| **MCP 服务器**（AI 代理） | 始终在服务器上验证 | 始终由服务器构建 |
+| **浏览器**或 **REST API**，运行验证为 `off` | 仅在浏览器中验证 | 浏览器（或调用方）发送的内容 |
+| **浏览器**或 **REST API**，运行验证为 `log` | 在服务器上验证，拒绝只记录日志 | 发送的内容；差异记录日志 |
+| **浏览器**或 **REST API**，运行验证为 `enforce` | 在服务器上验证，无效时拒绝 | **由服务器构建** |
+
+浏览器、MCP 服务器和运行验证使用同一套规则代码（共享的
+表单引擎）：相同的规则、相同的顺序、相同的消息。浏览器显示的错误，
+服务器会以相同的文本拒绝。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [启用](switching-it-on.html) | 为整个实例启用，或为单个表单启用 |
+| [记录与强制](log-and-enforce.html) | 每种模式如何处理违反规则的运行 |
+| [列表行](list-rows-and-subforms.html) | list 字段的行如何验证 |
+| [文件上传](file-uploads.html) | 文件字段如何验证 |
+| [密码](passwords.html) | 密码字段如何验证，以及如何不出现在 API 中 |
+| [重新运行](relaunching.html) | 重新运行的作业如何验证 |
+| [推广上线](rolling-it-out.html) | 把实例切换到 enforce，以及已知限制 |
diff --git a/i18n/zh/_build_forms/launch-validation/list-rows-and-subforms.md b/i18n/zh/_build_forms/launch-validation/list-rows-and-subforms.md
new file mode 100644
index 0000000..04cd044
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/list-rows-and-subforms.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: 列表行
+parent: 运行验证
+nav_order: 3
+translated_from: 2f28c42b47c253f87a9be9d5b1bd8638f7dca685
+---
+
+# 列表行
+{: .no_toc }
+
+list 字段的行如何验证
+{: .fs-6 .fw-300 }
+
+---
+
+`list` 字段包含多行；每一行都是其子表单的一个实例，通过行
+编辑器填写。带有 `subform` 的 `yaml` 字段就相当于这样的一行。服务器处理它们的方式
+与浏览器的行编辑器相同：每一行都通过其子表单解析，表单的值
+作为 `__parent__` ，检查其规则，并对其计算字段求值。嵌套列表的处理方式
+也一样：在某一行自己的列表中， `$(__parent__.__parent__.x)` 可以访问到表单。
+
+行的检查方式如下：
+
+- **用户在编辑器中添加或编辑的行**会被解析和验证。
+- **没有人动过的行**，即由列表自身的默认值、表达式或查询生成的行
+  （例如 ACL 列表中已有的条目），会**原样通过**，与浏览器中
+  一样：不会重新验证，也不会添加任何内容。已有条目即使违反了
+  后来编写的规则，也不会阻止运行。
+- **标记为已删除的行**（列表的 `deleteMarker` ）保持原样，不做验证。
+
+为了在不信任请求的前提下区分这些行，服务器会在运行验证中再次运行列表自身的
+数据来源（其默认值，否则是其表达式或查询）。没有经过编辑器的行
+**只有在属于该数据来源所生成的行时**才会原样通过。其他任何行，例如 REST 调用方凭空编造的行，都会像
+编辑过的行一样被解析和验证。因此普通的行无法绕过检查，而
+浏览器中未改动的行仍然会原样通过。
+
+浏览器用户只会在一种情况下注意到这一点：在打开表单到运行表单之间，数据来源的数据发生了变化
+（期间某个条目被修改或删除），**并且**该行
+违反了其子表单的某条规则。这时该行不再算作数据来源中的行，因此
+会被验证，运行会被拒绝，并指出该行，例如
+`acls[2].user_or_group (regex)` 。
+
+验证失败的行会出现在 `rowErrors` 中，带有其 `index` （ `yaml` 字段没有），并在日志中显示为
+`disks[1].size (maxValue)` 。
+
+一次运行在所有嵌套层级中最多可包含 **500 行**，因为每一行都会运行其子表单的查询。
+
+---
+
+## 行标记
+
+列表在其行上设置的标记（ `insertMarker` 、 `updateMarker` 和 `deleteMarker` ；如果没有
+`insertMarker` ，当列表设置了 `allowDelete: false` 、 `deleteMarker` 或 `updateMarker` 时，新行会得到 `__inserted__` ）
+会随每个带标记的行传给 playbook。被移除的行会带着其删除
+标记发送，这样 playbook 就可以删除它。在 6.4.1 之前，只有当子表单把标记声明为（隐藏）字段时，
+列表行才会带有该标记。
diff --git a/i18n/zh/_build_forms/launch-validation/log-and-enforce.md b/i18n/zh/_build_forms/launch-validation/log-and-enforce.md
new file mode 100644
index 0000000..b32c06b
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/log-and-enforce.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: 记录与强制
+parent: 运行验证
+nav_order: 2
+translated_from: 10a187b350155ce68bfc50e379e1b6b8637df57a
+---
+
+# 记录与强制
+{: .no_toc }
+
+每种模式如何处理违反规则的运行
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## `log` 的作用
+
+每次运行都会被检查，但对用户来说没有任何变化。在以下情况下会向日志写入警告：
+
+- 该运行**本应被拒绝**时，附带原因（只有字段名和规则类型，从不包含
+  值）：
+
+  ```
+  Launch validation would refuse form 'Create VM' for alice (launch validation 'log') :
+  failing rules : hostname (regex) ; failing rows : disks[1].size (maxValue)
+  ```
+
+- 客户端发送的 extravars 与服务器构建的**不同**时，附带
+  不同的顶层键：
+
+  ```
+  Launch of form 'Create VM' : the extravars differ from the ones the server builds for
+  created_at, vm (launch validation 'log' ; 'enforce' would run the server's)
+  ```
+
+先在真实实例上运行一段时间的 `log` 。它会在影响任何人之前，显示哪些表单会被拒绝，
+以及哪些表单在服务器上计算出的值不同。
+
+---
+
+## `enforce` 的作用
+
+在 `enforce` 模式下，无效的运行会被拒绝，有效的运行则使用服务器
+构建的 extravars。
+
+### 违反规则的运行会被拒绝
+
+`POST /api/v2/job` 返回 `422` 以及失败的字段：
+
+```json
+{
+  "error": "The form data is not valid",
+  "details": {
+    "missing": ["owner"],
+    "invalid": ["hostname", "disks"],
+    "waiting": [],
+    "validationErrors": {
+      "hostname": [{ "type": "regex", "description": "Must start with prod-" }]
+    },
+    "rowErrors": {
+      "disks": [{ "index": 1, "invalid": ["size"],
+                  "validationErrors": { "size": [{ "type": "maxValue", "description": "size must be at most 500" }] } }]
+    }
+  }
+}
+```
+
+- `missing` ：没有值的必填字段；
+- `invalid` ：违反规则的字段、不属于可选项的选择，以及包含失败行的
+  list 字段；
+- `waiting` ：无法求值的字段（它们所需的某个字段始终没有得到值）；
+- `validationErrors` ：按字段列出每条失败的规则，以及浏览器显示的消息；
+- `rowErrors` ：按 list 字段列出失败的行（参见[列表行](list-rows-and-subforms.html)）；
+- `uploads` ：无法核实其上传的文件字段。
+
+**没有 `rawFormData`** 的运行同样会被拒绝：它的值无法检查。
+
+### 有效的运行使用服务器的 extravars
+
+作业不会使用客户端发送的 extravars。服务器根据经过检查的
+值，使用与浏览器相同的代码构建 extravars，并使用这些 extravars 运行。如果调用方发送了有效的
+`rawFormData` ，同时附带不一样的 `extravars` ，得到的是与这些值相符的 extravars，而不是
+它发送的那些。
+
+服务器会保留请求中的 `__verbose__` （仅限允许使用详细模式的用户）。
+保留键（ `__playbook__` 、 `__inventory__` ……）照常来自表单，
+`ansibleforms_user` 则是运行该作业的用户。
+
+### 用户看到的并不总是实际运行的
+
+构建 extravars 意味着再次对表单求值：每个表达式和查询都会在服务器上
+再运行一次，比浏览器运行时晚一会儿，并以运行作业的用户身份执行。依赖于求值**时间**或**位置**的值
+可能会不同，这种情况下使用
+服务器的值：
+
+| 内容 | 为什么可能不同 | 影响程度 |
+|---|---|---|
+| `fn.fnTime()` 、时间戳、基于时间生成的名称 | 再次求值，晚了几秒 | 只在跨秒或跨日期时才有影响。在浏览器流程中 `fnTime` 本来就在服务器上运行，使用相同的时区（容器的 `TZ` ） |
+| 查询、 `fnRestAdvanced` 、 `fnSsh` 、 `fnDnsResolve` 、文件读取 | 期间外部数据发生了变化 | 只在数据变化时 |
+| 使用 `new Date()` 、 `toLocaleString` 、 `Intl` 的 `runLocal` 表达式 | 浏览器使用用户的时区和语言区域，服务器使用自己的 | 仅限这类表达式 |
+
+**验证**也是如此：读取这类字段的规则（针对查询结果的 `notIn` ，
+针对计算标志的 `validIf` ）会根据服务器的值进行检查。extravars
+不同的表单会出现在上面介绍的 `log` 警告中；在启用强制之前请先审查它们。
diff --git a/i18n/zh/_build_forms/launch-validation/passwords.md b/i18n/zh/_build_forms/launch-validation/passwords.md
new file mode 100644
index 0000000..2d74970
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/passwords.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: 密码
+parent: 运行验证
+nav_order: 5
+translated_from: 2fc2d2e8cdd997efaf221bd8e0114df2a4ee873e
+---
+
+# 密码
+{: .no_toc }
+
+密码字段如何验证、存储以及如何不出现在 API 中
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+密码字段的验证方式与其他字段相同。但它的值保存在服务器上，从不交还给
+客户端。
+
+---
+
+## 密码保存在哪里
+
+服务器把密码与作业一起保存在其 extravars 中：
+
+* 这样**审批**就可以用用户输入的密码继续执行作业。
+* 当运行验证不是 `enforce` 时，**按原样重新运行**可以重放该密码。
+
+保存的密码只在服务器上使用。
+
+---
+
+## API 返回什么
+
+任何 API 都不会返回密码：
+
+* 通过 REST API 或 MCP 服务器的 `get_job` 读取作业时，其表单中的每个 `password` 字段都会被掩码，包括
+  列表行和 YAML 子表单中的字段。
+* `MASK_EXTRAVARS_REGEX` （默认 `password|secret|token` ）还会掩码名称匹配的每个 extravar，用于
+  那些不是密码字段的机密。
+
+---
+
+## 重新运行时收到什么
+
+为了预填重新运行的表单，浏览器会收到作业的原始表单数据。这些数据从不包含密码，即使在
+列表行或 YAML 子表单中也没有，因此用户需要重新输入密码。
+
+被表单依赖关系隐藏的密码字段不需要填写，也就不必重新输入。
diff --git a/i18n/zh/_build_forms/launch-validation/relaunching.md b/i18n/zh/_build_forms/launch-validation/relaunching.md
new file mode 100644
index 0000000..35584df
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/relaunching.md
@@ -0,0 +1,78 @@
+---
+layout: default
+title: 重新运行
+parent: 运行验证
+nav_order: 6
+translated_from: 9f52ec39fd40e3d617d9537c5f7d356033bc9d49
+---
+
+# 重新运行
+{: .no_toc }
+
+重新运行的作业如何验证
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+作业可以通过两种方式重新运行。重新运行如何检查，取决于采用哪一种方式，以及运行验证
+模式。
+
+---
+
+## 两种重新运行
+
+这两种方式的区别在于调用方是否发送新的值：
+
+* **按原样**：“重新运行”按钮、不带请求体的 `POST /api/v2/job/{id}/relaunch` ，或者不带
+  `values` 的 `relaunch_job` 。
+* **带修改**：同样的调用，但附带新的值，叠加在作业已保存的字段值之上：
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/42/relaunch \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "values": { "vm_size": "large" } }'
+```
+
+---
+
+## 各自如何检查
+
+运行验证模式决定了重新运行是重放还是重新检查：
+
+| 重新运行 | `off` / `log` | `enforce` |
+|---|---|---|
+| **按原样** | 重放作业已保存的 extravars，包括密码 | 根据已保存的字段值进行完整检查 |
+| **带修改** | 在叠加了修改的已保存值上进行完整检查 | 同样进行完整检查 |
+
+`enforce` 下有一个例外：由管理员级调度运行的作业没有自己的字段值，因此按原样重新运行时，
+会为管理员或拥有 `allowScheduledJobs` 角色选项的用户重放该调度已保存的 extravars。
+
+经过检查的重新运行（参见[记录与强制](log-and-enforce.html)）会以调用方的名义启动一个新作业。
+
+---
+
+## 密码字段
+
+已保存的字段值不包含密码，因此经过检查的重新运行对于**可见的密码字段**没有值：
+
+* 重新运行会以 `unsupported` 被拒绝，并列出所缺的 `passwordFields` 。
+* 请重新运行表单并输入密码。
+* 被表单依赖关系**隐藏**的密码字段不需要填写，也不会阻止重新运行。
+
+在 `enforce` 下，这同样适用于“重新运行”按钮。
+
+---
+
+## 谁可以重新运行
+
+两种重新运行都要求：
+
+* 表单允许重新运行（ `allowRelaunch` ，默认为 true）；
+* 拥有 `allowJobRelaunch` 角色选项；
+* 用户是**作业的所有者**、管理员，或拥有 `manageAllJobs` 角色选项的用户。
+
+能看到所有作业（ `showAllJobLogs` ）并不足以重新运行其他用户的作业。审批人可以看到等待其
+审批的作业，但同样不能重新运行它。
diff --git a/i18n/zh/_build_forms/launch-validation/rolling-it-out.md b/i18n/zh/_build_forms/launch-validation/rolling-it-out.md
new file mode 100644
index 0000000..4e29003
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/rolling-it-out.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: 推广上线
+parent: 运行验证
+nav_order: 7
+translated_from: 399d39dbea694518926bcc20099d19438cbbac29
+---
+
+# 推广上线
+{: .no_toc }
+
+把实例切换到 enforce，以及已知限制
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 推广上线
+
+`enforce` 是默认值。如果实例上有通过 REST 运行表单的脚本或其他系统，
+请分步骤切换，在拒绝任何运行之前先观察日志：
+
+1. 为整个实例设置 `LAUNCH_VALIDATION=log` （如果是升级，在升级之前设置）。
+2. 在此模式下运行一段时间并审查日志： `would refuse` 警告表示违反规则的
+   运行； `extravars differ` 警告表示某些表单在服务器上的计算结果
+   不同（时间戳、外部数据）。针对每个表单判断这是否
+   重要。
+3. 把这些表单切换为 `launchValidation: enforce` 。发送无效值或
+   编造 extravars 的调用方现在会收到 `422` 以及原因。
+4. 当每个表单都按预期工作后，为整个实例移除 `LAUNCH_VALIDATION` （或将其设为 `enforce` ）。
+
+---
+
+## 限制
+
+运行验证目前还不能覆盖所有情况：
+
+- **向导表单**不能带修改重新运行，并且在 7.0 之前运行的向导作业
+  不能在 `enforce` 下重新运行（它没有保存各步骤的值）。MCP 服务器
+  不能运行向导表单。
+- 浏览器中的**占位符解析**仍然使用其自己的一份服务器代码副本；在
+  极少数边缘情况下（ `__undefined__` 、表达式中的引号），两者对某个
+  占位符的解析结果可能不同。 `log` 能揭示这类差异。
+- **`runLocal`** 表达式在浏览器中运行于浏览器的 JavaScript 引擎，在服务器上则运行于
+  沙箱；同样的代码产生同样的结果，除非它依赖于
+  浏览器的时区或语言区域。
+
+---
+
+## 向导表单
+
+[向导](../forms/wizard.html)会逐个步骤检查：浏览器发送
+每个步骤的值，服务器则用每个步骤自己的子表单检查用户将要提交的每个步骤。
+
+- 如果某个步骤是 `optional` 且用户跳过了它，或者其 `when` 为 false，则该步骤不计入。
+- 步骤通过 `$(__parent__.<step>.<field>)` 读取前面的步骤，使用的是经过检查的值。
+- 错误会以 `<step>.<field>` 的形式指出步骤和字段。
+- 在 `enforce` 下，extravars 在服务器上构建，每个步骤位于其 `defaultModel` 之下。
+- 向导中不支持文件字段。
diff --git a/i18n/zh/_build_forms/launch-validation/switching-it-on.md b/i18n/zh/_build_forms/launch-validation/switching-it-on.md
new file mode 100644
index 0000000..a79a3e1
--- /dev/null
+++ b/i18n/zh/_build_forms/launch-validation/switching-it-on.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: 启用
+parent: 运行验证
+nav_order: 1
+translated_from: 2e5de5654a03389c7c8a7c05179e9dd79456b50b
+---
+
+# 启用
+{: .no_toc }
+
+为整个实例启用，或为单个表单启用
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+运行验证有两个设置。**以二者中更严格的为准。**
+
+---
+
+## 针对整个实例： `LAUNCH_VALIDATION`
+
+环境变量 [`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) 适用于所有表单：
+
+- `off` ：不在服务器端检查：作业使用浏览器或调用方发送的 extravars。
+- `log` ：检查每次运行；本应拒绝的内容会以警告写入日志，
+  运行仍照常进行。
+- `enforce` （默认）：拒绝无效的运行，有效的运行则使用
+  服务器构建的 extravars。
+
+值为空或无法识别时同样视为 `enforce` 。修改无需重启即可生效。
+
+{: .warning }
+> **升级会改变行为。** 没有设置 `LAUNCH_VALIDATION` 的实例在升级后会对
+> 每次运行进行强制验证。调用 `POST /api/v2/job` 时不带 `rawFormData` ，
+> 或者所带的值违反表单规则的脚本，会以 `422` 被拒绝。请在升级前设置
+> `LAUNCH_VALIDATION=log` 以查看哪些会被拒绝，或者设置 `off` 保留
+> 旧的行为（参见[推广上线](rolling-it-out.html)）。
+
+---
+
+## 针对单个表单： `launchValidation`
+
+表单可以设置自己的级别：
+
+```yaml
+- name: Create VM
+  type: ansible
+  roles:
+    - default
+  playbook: vm.yml
+  launchValidation: enforce   # off | log | enforce
+  fields:
+    - name: vm_name
+      type: text
+      required: true
+```
+
+在以 `off` 或 `log` 运行的实例上，对于您知道会通过 REST 运行的表单，请使用此设置：
+该表单会被强制验证，而实例的其余部分则不会。也可以在设计器的
+表单设置中设置它。
+
+**表单只能比实例更严格，永远不能更宽松。** 当 `LAUNCH_VALIDATION`
+为 `enforce` 时，表单的 `launchValidation: off` 不起作用：表单不能推翻
+运维人员的决定。
+
+向导表单也使用它：向导的运行会逐个步骤检查，每个步骤都根据其自己的
+子表单检查（参见[向导表单](rolling-it-out.html#wizard-forms)）。
diff --git a/i18n/zh/_build_forms/workflows/designer.md b/i18n/zh/_build_forms/workflows/designer.md
new file mode 100644
index 0000000..fed108e
--- /dev/null
+++ b/i18n/zh/_build_forms/workflows/designer.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: 在设计器中编辑
+parent: 工作流
+nav_order: 2
+translated_from: dd4e281ec223f5c4995d804e774ac49e4d5934da
+---
+
+# 在设计器中编辑
+{: .no_toc }
+
+绘制工作流，并在不运行任何内容的情况下试用
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作流部分
+
+**设计器 > 工作流**在文件浏览器中列出工作流文件，并带有每个
+[设计器](../designer/)部分都有的 YAML、可视化和预览选项卡。
+
+- 工具栏中的 **`+` 按钮**会创建一个工作流文件，其中带有一个空工作流供您起步。
+- **YAML** 按文件的原样显示它。其他选项卡也会保留注释和键的顺序。
+- **可视化**把文件中的每个工作流绘制成一张图，名称和描述显示在图的上方。包含两个工作流的文件
+  会把两者上下排列显示。
+- **预览**是工作流的试运行：参见[试用](#trying-it-out)。
+
+问题会列在图的上方，每个问题都带有一个链接，可在 YAML 中打开对应的行：指向不存在节点的链接、
+循环，以及设计器不认识的 playbook、清单、凭据、运行器或仓库。
+
+---
+
+## 图
+
+图从左向右阅读，从 **START** 到最后的节点。每个节点显示其标识符，并在下方显示
+它运行的内容；连接按触发条件着色，如图内图例所示：成功时、失败时、
+始终。
+
+- **点击 START** 添加第一个节点：没有父节点的节点，工作流一开始就会运行。
+- **点击节点**进行编辑。
+- **点击连接**可以更改其触发条件，或者将其移除。
+
+---
+
+## 添加节点
+
+新节点通过向导添加：在已有节点上选择**成功时新建节点**、**失败时新建节点**或**始终新建节点**，
+或者点击 START 添加第一个节点。
+
+1. **运行什么**：节点的标识符、**运行**（节点的类型，对于 playbook 节点还包括它在哪里运行）
+   以及它运行的内容：playbook、模板或作业、工作流、审批的名称和超时，或者仓库。参见
+   [节点在哪里运行](#where-a-node-runs)。
+2. **如何运行**：运行设置：清单、凭据、限制、标签、详细程度、
+   检查模式和差异模式、条件（**运行条件**）以及**取值自**（参见[工作流文件](file.html#run-settings)）。
+3. **去向**：它在哪个节点之后运行，以及在什么条件下运行。
+
+**创建**会把该节点添加到 YAML 中。
+
+---
+
+## 节点在哪里运行
+
+**运行**在一个列表中说明节点运行什么以及在哪里运行：**RTE 上的 playbook**、**AWX 上的模板**、**Semaphore 上的
+模板**、**Rundeck 上的作业**、**Jenkins 上的作业**，然后是**工作流**、**审批**和**仓库拉取**。
+
+| 运行 | 其下方的字段 | 运行器 |
+|---|---|---|
+| **RTE 上的 playbook** | **Playbook**：设计器中的某个 playbook | **默认 RTE**，或按名称指定的 RTE 运行器 |
+| **AWX 上的模板**（包括 AAP 和 Ascender） | **模板**：手动输入的模板名称 | AWX 运行器，各自带有其类型 |
+| **Semaphore 上的模板** | **模板**：手动输入的模板名称 | Semaphore 运行器 |
+| **Rundeck 上的作业**或 **Jenkins 上的作业** | **作业**：手动输入的作业名称 | Rundeck 或 Jenkins 运行器 |
+
+- **RTE 上的 playbook** 始终可选；其他选项只有在实例拥有该类型的[运行器](../runners.html)时才会出现。
+- **运行器**只列出该类型的运行器，默认运行器会被标记并预先选中（没有默认时选中名称排在最前的）。
+- 选择另一个运行位置会清空节点运行的内容，需要重新选择。
+- 如果设计器不认识节点的运行器，节点会显示 **该运行器上的模板或作业**。
+
+工作流文件不会改变：这样的节点是一个带有 `runner:` 的 `job_template` 节点（参见
+[工作流文件](file.html#run-settings)）。
+
+---
+
+## 编辑节点
+
+点击节点会打开其对话框，包含四个选项卡：
+
+| 选项卡 | 内容 |
+|---|---|
+| **运行什么** | 标识符、**运行**、运行的内容，对于 playbook 节点还有运行器 |
+| **如何运行** | 运行设置；凭据从列表中选择，每个都用 `+` 添加 |
+| **在其后运行** | 指向该节点的连接，以及**所有父节点必须汇合** |
+| **之后运行** | 从该节点出发的连接，以及**连接到已有节点：** 和**连接到新节点：** |
+
+**在 YAML 中显示**会在 YAML 中打开该节点，**移除节点**会将其连同连接一起移除。每次修改都会立即写入
+YAML；**保存**会保存文件。
+
+---
+
+## 试用
+
+**预览**选项卡会按照 AWX 的规则把工作流完整演练一遍，而不运行任何内容。
+
+每个节点一开始都是成功。点击某个节点让它失败，再次点击让它成功；图随后会显示
+哪些节点会运行、哪些不会运行，以及工作流是否会失败。**重置**会让所有节点重新变为成功。
diff --git a/i18n/zh/_build_forms/workflows/file.md b/i18n/zh/_build_forms/workflows/file.md
new file mode 100644
index 0000000..0a3a85c
--- /dev/null
+++ b/i18n/zh/_build_forms/workflows/file.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: 工作流文件
+parent: 工作流
+nav_order: 1
+translated_from: bb4d3027e33a5bfd11443369b621eb34c4af2f68
+---
+
+# 工作流文件
+{: .no_toc }
+
+工作流语法、节点类型以及每个节点的运行设置
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作流文件存放在哪里
+
+工作流文件是位于本地 workflows 文件夹以及每个用于工作流的仓库中的 YAML 文件。
+
+- **本地文件夹**是 [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH) ，默认为持久化文件夹下的
+  `workflows` 。
+- 开启了**用于工作流?** 的**仓库**会被整体读取，因此其工作流文件可以放在任意文件夹中。
+  设计器会把它们保存回该仓库，**推送**则把它们发送到远程仓库。
+
+每个包含 `workflow_job_templates` 的 YAML 文件都会被读取，最深可达六层文件夹，并且一个文件可以包含多个
+工作流。表单通过 `name` 引用工作流，因此请保持名称唯一：当两个工作流同名时，运行它的作业
+会失败，并提示您重命名其中一个。
+
+---
+
+## 语法
+
+工作流文件采用 AWX 导出的语法编写，节点位于 `related.workflow_nodes` 之下：
+
+```yaml
+workflow_job_templates:
+  - name: deploy-app
+    description: Builds, approves and deploys the application
+    extra_vars:
+      app_name: orders-api
+    related:
+      workflow_nodes:
+        - identifier: build
+          unified_job_template:
+            name: build.yaml
+            type: job_template
+          inventory:
+            name: staging
+          related:
+            credentials:
+              - name: deploy-ssh
+            success_nodes:
+              - identifier: approve
+            failure_nodes:
+              - identifier: notify
+        - identifier: approve
+          unified_job_template:
+            name: Approve the deploy
+            type: workflow_approval_template
+            timeout: 3600
+          related:
+            success_nodes:
+              - identifier: deploy
+        - identifier: deploy
+          unified_job_template:
+            name: deploy.yaml
+            type: job_template
+          inventory:
+            name: production
+          limit: web
+          job_tags: deploy
+        - identifier: notify
+          unified_job_template:
+            name: notify.yaml
+            type: job_template
+```
+
+`awx.awx` 集合的格式同样可以读取：直接位于工作流之下的 `workflow_nodes` ，以及以普通字符串
+（ `inventory: staging` ）而不是映射（ `inventory: {name: staging}` ）书写的名称。
+
+### 工作流
+
+除了节点之外，工作流条目还有几个自己的键：
+
+| 键 | 含义 |
+|---|---|
+| `name` | 工作流的名称，即表单的 `workflow:` 所引用的名称 |
+| `description` | 它的用途，在设计器中显示 |
+| `extra_vars` | 每个节点都会收到的变量；表单的值优先于它们 |
+| `related.workflow_nodes` | 节点 |
+
+### 节点
+
+每个节点都有一个标识符、它运行的内容以及它的连接：
+
+| 键 | 含义 |
+|---|---|
+| `identifier` | 节点的 ID：字母、数字、点、短横线、冒号和下划线，在工作流中唯一 |
+| `unified_job_template.type` | 节点运行的内容：参见[节点类型](#node-types) |
+| `unified_job_template.name` | 它运行的 playbook、工作流、审批或仓库 |
+| `related.success_nodes` | 当该节点成功时运行的节点 |
+| `related.failure_nodes` | 当该节点失败时运行的节点 |
+| `related.always_nodes` | 当该节点结束时运行的节点，无论成功与否 |
+| `all_parents_must_converge` | `true` ：节点等待所有指向它的连接都触发，而不只是其中一个 |
+
+连接必须向前：连接形成循环的工作流不会运行。
+
+---
+
+## 节点类型
+
+节点运行以下四种内容之一，名称与 AWX 中的一致：
+
+| 类型 | 节点运行的内容 |
+|---|---|
+| `job_template` | 设计器中的某个 playbook，作为 RTE 上的独立作业运行；或者在带有 `runner:` 时，运行该运行器的模板或作业 |
+| `workflow_job_template` | 另一个工作流，作为子工作流作业运行；工作流最多可嵌套五层 |
+| `workflow_approval_template` | 审批：工作流作业会等待，直到有人批准或拒绝 |
+| `project` | 拉取它所指定的仓库（即 AWX 的项目更新） |
+
+审批节点的 `unified_job_template.timeout` 以秒为单位。超时仍无人回应时，节点失败； `0` 或不设
+超时则无论多久都会等待回应。被拒绝的审批会使节点失败，工作流随后沿着其
+连接继续执行。
+
+---
+
+## 运行设置
+
+`job_template` 节点直接在节点上接受 AWX 节点的设置：
+
+| 键 | 作用 |
+|---|---|
+| `inventory` | playbook 针对其运行的清单，按名称指定，与表单的 `inventory:` 相同 |
+| `related.credentials` | 凭据：每个凭据都以其自己的名称传给 playbook，第一个 *SSH* 凭据同时也是 ansible 连接时使用的登录凭据。vault 凭据只用于打开 vault |
+| `limit` | 只在这些主机上运行（ `--limit` ） |
+| `job_tags` | 只运行带有这些标签的任务（ `--tags` ） |
+| `skip_tags` | 跳过带有这些标签的任务（ `--skip-tags` ） |
+| `verbosity` | `0` 到 `5` ： `-v` 的个数 |
+| `diff_mode` | `true` ：显示变更（ `--diff` ） |
+| `job_type` | `check` ：试运行（ `--check` ）； `run` 或不设置：真实运行 |
+| `extra_data` | 该节点收到的变量，优先级低于工作流的 `extra_vars` 和表单的值 |
+
+节点的作业会把表单的值作为 extra vars 收到。表单的值优先于工作流的 `extra_vars` ，而后者又优先于
+节点的 `extra_data` ，就像 AWX 中调查问卷的回答一样。
+
+---
+
+## AnsibleForms 专有的键
+
+节点有三个键是 AnsibleForms 专有的，AWX 会忽略它们，因此工作流可以做到多步骤表单能做的事：
+
+| 键 | 作用 |
+|---|---|
+| `runner` | 在 `job_template` 节点上，运行该运行器的模板或作业，而不是设计器中的 playbook：AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins。RTE 运行器则在该处运行节点的 playbook。一个工作流可以混用它们。 |
+| `if_extra_var` | 只有当此 extra var 为 `true` 时节点才运行，与多步骤表单步骤的 `ifExtraVar` 相同。条件不满足时，节点被跳过，其后的内容按成功后的情况运行。不适用于审批节点，审批节点始终运行。 |
+| `extra_vars_key` | 节点只收到 extra vars 中的这个键，并复制进用户信息，与多步骤表单步骤的 `key` 相同 |
+
+在模板运行器上， `unified_job_template.name` 是要运行的模板或作业，节点的 `limit` 、 `job_tags` 、检查
+模式和差异模式会像该运行器类型的表单那样传递。大于 `0` 的 `verbosity` 会开启表单的
+`verbose` ，而 `skip_tags` 不会传递。只有 AWX 运行器（AWX、AAP 或 Ascender）会收到节点的清单，并把
+凭据作为其 AWX 凭据；Semaphore、Rundeck 和 Jenkins 则把凭据作为表单的 `credentials` 收到。
diff --git a/i18n/zh/_build_forms/workflows/index.md b/i18n/zh/_build_forms/workflows/index.md
new file mode 100644
index 0000000..ad7f7d9
--- /dev/null
+++ b/i18n/zh/_build_forms/workflows/index.md
@@ -0,0 +1,99 @@
+---
+layout: default
+title: 工作流
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /workflows/
+translated_from: e6133a683d5bc1d0ba822dd52b4fed99028ea63c
+---
+
+# 工作流
+{: .no_toc }
+
+像 AWX 一样串联 playbook、审批和其他工作流
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向表单作者：什么是工作流、其节点如何运行，以及接下来该读什么。
+
+工作流是由节点组成的图。每个节点运行某样东西：设计器中的某个 playbook、另一个工作流、一个审批，
+或者一次仓库拉取。节点之间的连接说明接下来运行什么：成功时、失败时或始终。由
+[类型为 `workflow`](../forms/workflow.html) 的表单运行它，作业页面会在运行期间实时绘制它。
+
+工作流遵循 AWX 的语法和 AWX 的规则，因此从 AWX 导出的工作流在 AnsibleForms 中读起来完全一样。它们在
+RTE 上运行，不需要 AWX：playbook 节点是一个独立的作业，使用节点的清单、凭据、限制和标签。
+
+---
+
+## 工作流如何运行
+
+节点按照 AWX 的规则运行，互不依赖的分支并行运行。
+
+- **没有父节点的节点会立即开始**，即在工作流开始时。
+- **连接在其节点结束时触发**：*成功时*连接在成功后触发，*失败时*连接在失败后触发，
+  *始终*连接在两种情况下都触发。被取消的节点不会触发任何连接。
+- **只要有一个指向某节点的连接触发，该节点就会开始。** 开启**所有父节点必须汇合**后，它会等到所有
+  指向它的连接都触发。
+- **不再可能开始的节点会被标记为*不运行***，只能由它启动的节点也是如此。
+- **当某个节点失败且没有任何处理时，工作流失败**：即该节点既没有*失败时*连接，也没有*始终*连接。
+  被连接处理了的失败不会使工作流失败。
+
+带有条件（ `if_extra_var` ）且条件不满足的节点会被跳过。其后的内容按成功后的情况运行。审批
+节点不接受条件：它总是等待回应。
+
+---
+
+## 在节点之间传递数据
+
+节点的 playbook 用 `set_stats` 收集的内容，会作为 extra vars 传给它之后的节点，就像 AWX 传递作业的
+工件一样。节点会获得每个指向它且已触发的父节点的数据，按父节点书写的顺序合并，
+并把收到的数据连同其自身作业的数据一起往下传，二者都设置了同一个键时以其自身的为准。
+
+```yaml
+# build.yaml, the first node : its version and build id go to the nodes after it
+- name: Build
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Pass the build on
+      ansible.builtin.set_stats:
+        data:
+          version: "2.4.1"
+          build_id: 42
+```
+
+之后的节点就可以像读取其他 extra var 一样读取 {% raw %}`{{ version }}` 和 `{{ build_id }}`{% endraw %} 。
+
+节点的 extra vars 来自四个地方。其中之一 `extra_data` 是节点自己的变量：这是 AWX 对它们的叫法，
+在[工作流文件](file.html#run-settings)中设置在节点上。当两个来源设置了同一个键时，优先级顺序与
+AWX 相同，从低到高：
+
+| 来源 | 优先于 |
+|---|---|
+| 节点自己的变量（ `extra_data` ） | 无 |
+| 通过 `set_stats` 传递的数据 | 节点的 `extra_data` |
+| 工作流的 `extra_vars` | 传递的数据 |
+| 表单的值 | 所有其他来源 |
+
+- 只有 playbook 范围的数据会被传递：即 `per_host: false` （默认值）的 `set_stats` 。
+- 审批节点、被跳过的节点和项目节点会把收到的数据原样往下传。
+- 节点输出的末尾会列出它传递的键，只列名称，因为其值可能是机密。
+- 节点的作业会把其数据保存为工件（在其页面上点击**显示工件**），工作流作业则保存其所有
+  节点的数据，因此嵌套的工作流也会把数据传给其后的节点。
+- 在 AWX 运行器上运行的节点，会以同样的方式传递其 AWX 作业的工件。
+---
+
+## 本节内容
+
+以下页面详细介绍工作流：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [工作流文件](file.html) | 文件的语法、节点类型以及每个节点的运行设置 |
+| [在设计器中编辑](designer.html) | 设计器的工作流部分：图、节点和连接对话框以及试运行 |
+| [运行工作流](running.html) | 运行它的表单、作业页面、节点输出、审批和中止 |
diff --git a/i18n/zh/_build_forms/workflows/running.md b/i18n/zh/_build_forms/workflows/running.md
new file mode 100644
index 0000000..06990e0
--- /dev/null
+++ b/i18n/zh/_build_forms/workflows/running.md
@@ -0,0 +1,103 @@
+---
+layout: default
+title: 运行工作流
+parent: 工作流
+nav_order: 3
+translated_from: 1883c268cde716170bdb84c7f2df49e9122dc55d
+---
+
+# 运行工作流
+{: .no_toc }
+
+从表单运行工作流，并在作业页面上跟踪它
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 表单
+
+[类型为 `workflow`](../forms/workflow.html) 的表单运行工作流，像指定 playbook 一样用 `workflow:` 指定：可以用
+workflows 文件夹中的**文件**，包括其子文件夹（ `team/deploy-app.yml` ），也可以用文件中工作流的**名称**
+（ `deploy-app` ）：
+
+```yaml
+- name: Deploy the app
+  type: workflow
+  workflow: team/deploy-app.yml
+  roles:
+    - admin
+  fields:
+    - name: app_name
+      type: text
+      default: orders-api
+```
+
+表单的字段会作为 extra vars 传给每个节点，其 [`credentials`](../forms/workflow.html#workflow_credentials) 也一样，使用表单
+为它们指定的名称，就像多步骤表单的字段传给其各个步骤一样：
+
+```yaml
+- name: Provision NAS storage
+  type: workflow
+  workflow: nas.yml
+  credentials:
+    ontap: ontap_automation   # every node's playbook gets `ontap`
+```
+
+节点自己的凭据在工作流文件中设置，会以其自己的名称传给其 playbook，二者使用同一名称时以节点的为准。在表单的设计器可视化选项卡中，**工作流**是
+设计器中工作流文件的列表。
+
+只写文件名时，如果只有一个文件叫这个名字，也能在子文件夹中找到它。如果有两个同名的工作流，按名称引用它的表单
+将无法运行，设计器会在您保存第二个时发出警告：请重命名其中一个，或者改用其文件名。找不到的工作流
+会使作业以失败结束，原因写在其输出中。
+
+---
+
+## 作业
+
+工作流作业在 AnsibleForms 服务器上运行，每个 playbook 节点作为一个独立的作业运行，是工作流
+作业的子作业，就像多步骤表单的各个步骤一样：在 RTE 上运行设计器中的 playbook；对于带有 `runner:` 的节点，则运行该运行器在
+AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins 上的模板或作业（参见[节点在哪里运行](designer.html#where-a-node-runs)）。
+
+作业页面会实时绘制工作流：每个节点按其状态着色，显示已触发的连接以及不会
+运行的节点。顶部的信息会显示工作流名称，而不是 playbook。
+
+- **点击已结束的节点**，可在对话框中打开其输出。
+- **输出**包含每个节点的输出，每段都以 `WORKFLOW NODE [identifier] (status)` 横幅开头，按节点
+  结束的顺序排列。
+- 输出中每个节点的标题上，以及从图中打开的对话框中，都有**显示 Extravars** 和**显示工件**，
+  用于以 JSON 或 YAML 显示该节点自己的 extravars 和工件（没有时显示 `{}` ），并带有“复制”按钮。
+
+节点的 extravars 包含其之前的节点传下来的内容，其工件则是其 playbook 用
+`set_stats` 收集的内容。这两个按钮遵循[角色选项](../config/roles.html#role-options) `showExtravars` 和
+`showArtifacts` 。同样的数据也可以通过 `GET /api/v2/job/{id}/node/{nodeId}` 获取，任何有权查看该作业的人都可以。
+
+按照 AWX 的规则，当某个节点失败且没有任何处理时，作业失败；否则作业成功。
+
+---
+
+## 审批
+
+审批节点会让工作流作业暂停，直到有人回应。
+
+当工作流到达审批节点时，作业的状态会变为**需要审批**：它会显示在铃铛图标中以及
+作业页面上，与表单的[审批点](../forms/approval.html)相同。节点的名称就是审批的标题，其描述
+就是消息；其余部分来自表单的 `approval` ：
+
+- 其 `roles` 决定谁可以批准或拒绝它， `allowSelf` 决定运行者是否也可以批准它；
+- 请求会发送到其 `notifications` 和 `channels` 。
+
+没有 `approval` 的工作流表单仍会让作业在审批节点处暂停，但这时只有管理员才能批准。
+
+- **批准**后，节点成功，工作流沿其*成功时*连接继续。
+- **拒绝**后，节点失败，工作流沿其*失败时*连接继续。
+- **超时**，即超过节点的超时时间仍无人回应时，节点同样失败。
+
+---
+
+## 中止
+
+对正在运行的工作流作业点击**中止**会将其停止：正在运行的节点作业会被中止，不再启动任何内容，它
+正在等待的审批也会被取消。正在等待审批的工作流作业同样可以中止。
diff --git a/i18n/zh/_configure/announcements.md b/i18n/zh/_configure/announcements.md
new file mode 100644
index 0000000..f7808c6
--- /dev/null
+++ b/i18n/zh/_configure/announcements.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: 公告
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /announcements.html
+translated_from: 9569cbdaa1c1d1d215f521f21023566e3a4df572
+---
+
+# 公告
+{: .no_toc }
+
+显示在页眉下方、面向所有人的消息，例如维护窗口，每条消息从开始时间显示到结束时间
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：在 **设置 > 外观 > 公告** 中，向每位用户通知维护窗口或故障事件。
+
+该页面需要 `showSettings` 或 `showAppearanceSettings` 角色选项。从 7.3.0 起，公告是一个列表，每条公告都有自己的页面和
+**已启用** 开关。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [常规](announcements/general.html) | 每条公告的已启用开关，它取代了控制全部公告的开关 |
+| [列表](announcements/list.html) | 尚未结束的公告、列表的各列，以及公告的页面 |
+| [添加公告](announcements/adding-one.html) | 两步向导：先填写消息，再设置显示时间 |
+
+
+---
+
+## 显示位置
+
+公告以一行文字的形式显示在每个页面的页眉下方，面向所有已登录的用户，并按其类型显示对应的颜色。
+
+多条已启用的公告可以同时显示，最新的排在最前。登录页面和嵌入在其他网站中的表单不显示任何公告。
+
+每条公告都有一个关闭按钮。关闭的公告在该浏览器标签页中保持关闭，直到标签页被关闭，或者
+其消息或结束日期发生变化。保存后的公告会立即推送到所有已打开的浏览器；到达开始日期或结束日期的公告
+会在一分钟内在这些浏览器中显示或隐藏。
diff --git a/i18n/zh/_configure/announcements/adding-one.md b/i18n/zh/_configure/announcements/adding-one.md
new file mode 100644
index 0000000..daf85dd
--- /dev/null
+++ b/i18n/zh/_configure/announcements/adding-one.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: 添加公告
+parent: 公告
+nav_order: 3
+translated_from: 0391ac4a8ba2f25d94a030831cc1a421d70ea0ba
+---
+
+# 添加公告
+{: .no_toc }
+
+两步向导：先填写消息，再设置显示时间
+{: .fs-6 .fw-300 }
+
+**添加公告** 会打开一个两步向导。**消息** 一步询问公告的内容：
+
+| 字段 | 含义 |
+|---|---|
+| **消息** | 公告文本，最多 500 个字符。必填。 |
+| **类型** | 公告的颜色和图标：蓝色表示信息（默认），琥珀色表示警告，红色表示危险 |
+
+**时间** 一步询问公告何时显示：
+
+| 字段 | 含义 |
+|---|---|
+| **开始日期** | 从此时刻开始显示。留空则立即显示。 |
+| **结束日期** | 到此时刻隐藏并被删除。留空则一直保留，直到您将其删除。 |
+
+结束日期必须晚于开始日期，并且必须是将来的时间。
diff --git a/i18n/zh/_configure/announcements/general.md b/i18n/zh/_configure/announcements/general.md
new file mode 100644
index 0000000..dc6752f
--- /dev/null
+++ b/i18n/zh/_configure/announcements/general.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: 常规
+parent: 公告
+nav_order: 1
+translated_from: e5c14d608eacfef0f3aa1a322d0ac0275b55f91e
+---
+
+# 常规
+{: .no_toc }
+
+每条公告的已启用开关，它取代了控制全部公告的开关
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 启用或停用公告
+
+从 7.3.0 起，每条公告都通过自己的 **已启用** 开关单独启用或停用。
+
+新建的公告默认为已启用。行菜单中的 **停用**，或公告页面上的 **已启用** 开关，会使其不再显示在页眉下方，但仍保留在列表中；
+**启用** 则使其重新从开始日期显示到结束日期。开关会立即保存。
+
+---
+
+## 7.2 中的“显示公告”开关
+
+在 7.2 及更早版本中，**常规** 选项卡有一个 **显示公告** 开关，可一次性启用或停用全部公告。
+
+从 7.3.0 起，该开关已移除。如果升级前它处于关闭状态，升级会停用所有公告，因此不会有任何公告开始显示：请重新启用您需要的公告。
diff --git a/i18n/zh/_configure/announcements/list.md b/i18n/zh/_configure/announcements/list.md
new file mode 100644
index 0000000..b6d8e5c
--- /dev/null
+++ b/i18n/zh/_configure/announcements/list.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: 列表
+parent: 公告
+nav_order: 2
+translated_from: 3bbe4ccb28f9305a450ac85b7d99531ce28a84cd
+---
+
+# 列表
+{: .no_toc }
+
+尚未结束的公告、列表的各列，以及公告的页面
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 列表
+
+**设置 > 外观 > 公告** 列出所有尚未结束的公告，包含以下各列：
+
+| 列 | 含义 |
+|---|---|
+| **已启用** | 公告是否从开始时间到结束时间显示在页眉下方（从 7.3.0 起） |
+| **消息** | 显示在页眉下方的文本 |
+| **类型** | 信息、警告或危险 |
+| **开始日期** | 开始显示的时间；立即显示时为 `–` |
+| **结束日期** | 结束的时间；一直显示到被删除时为 `–` |
+| **创建者** | 添加该公告的人 |
+
+点击某一行，或行菜单中的 **编辑**，会打开该公告的页面。菜单中还有 **启用** 或 **停用**，以及 **删除**。
+
+结束日期一过，公告即被删除：列表中只保留即将显示和正在显示的公告。
+
+---
+
+## 公告的页面
+
+从 7.3.0 起，每条公告都在自己的页面 `/settings/announcements/<id>` 中打开，页面只有一个选项卡：**详情**。
+
+页面包含消息、类型、开始和结束日期，以及会立即保存的 **已启用** 开关；其他字段通过 **保存** 保存，
+**删除** 则删除该公告。页面标题以消息的前几个字符来命名该公告。
diff --git a/i18n/zh/_configure/appearance.md b/i18n/zh/_configure/appearance.md
new file mode 100644
index 0000000..42d4717
--- /dev/null
+++ b/i18n/zh/_configure/appearance.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: 外观
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /appearance.html
+translated_from: 8dacce30ad7f7530858b04514b1edbbf19ea73d2
+---
+
+# 外观
+{: .no_toc }
+
+默认值、名称、徽标、浏览器图标、页眉链接以及徽标旁的标签
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：在 **设置 > 外观** 中让实例呈现您自己的样式，需要 `showSettings` 角色选项。
+仅有 `showAppearanceSettings` 角色选项也可以打开这些页面（包括公告），但不能打开其余设置。
+
+这一组页面包括 **默认值**、**名称**、**徽标**、**图标**、**链接**、**标签** 和 **公告**；
+公告有自己单独的页面，见 [公告](announcements.html)。保存后的默认值、名称、链接或标签
+会立即在所有已打开的浏览器中生效。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [默认值](appearance/defaults.html) | 为未作选择的用户设定的主题、语言、时区和日期格式 |
+| [名称](appearance/name.html) | 浏览器标签页和登录页面上显示的应用名称 |
+| [徽标](appearance/logo.html) | 页眉中您自己的徽标 |
+| [图标](appearance/icon.html) | 浏览器标签页和书签中您自己的图标 |
+| [链接](appearance/links.html) | 页眉中的链接，包括内置链接和您自己的链接 |
+| [标签](appearance/labels.html) | 徽标旁标明当前实例的标签；7.2 及更早版本中只有一个“环境”标签 |
diff --git a/i18n/zh/_configure/appearance/defaults.md b/i18n/zh/_configure/appearance/defaults.md
new file mode 100644
index 0000000..4006816
--- /dev/null
+++ b/i18n/zh/_configure/appearance/defaults.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: 默认值
+parent: 外观
+nav_order: 1
+translated_from: 2974af3a3fc29115349fad94498cac9ecd8c6123
+---
+
+# 默认值
+{: .no_toc }
+
+为未作选择的用户设定的主题、语言、时区和日期格式
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 默认值
+
+**默认值** 设定应用对尚未在自己的
+[偏好设置](../profile/preferences.html) 中作出选择的用户呈现的样式；用户自己的选择始终优先：
+
+| 字段 | 可选项 | 未选择时 |
+|---|---|---|
+| **默认主题** | 跟随浏览器、浅色、深色或颜色，选择颜色时可从 12 种颜色中选一种 | 跟随浏览器（7.2 及更早版本为浅色） |
+| **默认语言** | 应用支持的语言，保存在 [`DEFAULT_LANGUAGE`](../customization/server.html#env_DEFAULT_LANGUAGE) 中 | 英语 |
+| **默认表单视图** | 表单页面使用磁贴或列表 | 磁贴 |
+| **默认时区** | UTC、每个用户的浏览器时区，或按名称指定的任意时区 | UTC |
+| **默认日期格式** | `YYYY-MM-DD`、`DD/MM/YYYY`、`MM/DD/YYYY` 或 `DD.MM.YYYY`，并以今天的日期展示 | `YYYY-MM-DD` |
+
+语言是一个环境变量，无需重启即可生效。当
+[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT) 设为 `0` 时，页面以只读方式显示它。
+
+从 7.3.0 起，该页面与个人资料的偏好设置一样分为两个选项卡：**外观**（主题、语言和表单视图）和 **日期和时间**
+（时区和日期格式，并预览当前时间）；页面的搜索框会按选项卡名称分组列出匹配项。
+
+---
+
+## 跟随浏览器
+
+从 7.3.0 起，**跟随浏览器** 会为每位用户显示其浏览器所要求的浅色或深色主题，并随浏览器设置变化。
+
+未选择默认主题时，它就是默认值，因此新安装的实例会跟随浏览器。将鼠标悬停在 **颜色** 的某种颜色上，
+可以预览应用在该颜色下的效果；指针移开后会恢复原来的主题，在点击 **保存** 之前不会保留任何更改。
diff --git a/i18n/zh/_configure/appearance/icon.md b/i18n/zh/_configure/appearance/icon.md
new file mode 100644
index 0000000..71db592
--- /dev/null
+++ b/i18n/zh/_configure/appearance/icon.md
@@ -0,0 +1,23 @@
+---
+layout: default
+title: 图标
+parent: 外观
+nav_order: 4
+translated_from: b469d0e284d78450ebfac22e9e596c9808e1fc16
+---
+
+# 图标
+{: .no_toc }
+
+浏览器标签页和书签中您自己的图标
+{: .fs-6 .fw-300 }
+
+**图标** 用于替换浏览器标签页和书签中的 AnsibleForms 图标：
+
+| 规则 | 值 |
+|---|---|
+| 类型 | PNG、ICO、SVG、WEBP、GIF 和 JPEG |
+| 文件大小上限 | 256 KB |
+| 最佳效果 | 至少 64 × 64 px 的正方形图片，或 SVG |
+
+在 **新图标** 下选择一个文件，然后点击 **上传**；**删除自定义图标** 会恢复默认图标。
diff --git a/i18n/zh/_configure/appearance/labels.md b/i18n/zh/_configure/appearance/labels.md
new file mode 100644
index 0000000..2b69067
--- /dev/null
+++ b/i18n/zh/_configure/appearance/labels.md
@@ -0,0 +1,79 @@
+---
+layout: default
+title: 标签
+parent: 外观
+nav_order: 6
+redirect_from:
+  - /appearance/environment.html
+translated_from: 2b439f61976fc2cc161250c82c629ec40713ef2c
+---
+
+# 标签
+{: .no_toc }
+
+徽标旁标明当前实例的标签
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 列表
+
+从 7.3.0 起，**设置 > 外观 > 标签** 可以在页眉徽标旁放置多个标签，例如 PRODUCTION 和 EU：
+
+| 列 | 含义 |
+|---|---|
+| **已启用** | 标签是否显示在徽标旁和登录页面上 |
+| **标签** | 标签的文本，以页眉中显示的彩色胶囊样式呈现 |
+
+各行的顺序就是页眉中的顺序。点击某一行，或行菜单中的 **编辑**，会打开该标签的页面；行菜单中还有
+**启用** 或 **停用**（视当前状态而定）、用于调整顺序的 **上移** 和 **下移**，以及 **删除**。
+
+页眉和登录页面按顺序显示已启用的标签。超过三个时，其余标签会收进一个灰色的 **+N** 中，悬停即可在提示中看到；
+在手机上则只显示第一个标签和 **+N**。保存后的标签会立即在所有已打开的浏览器中显示。
+
+---
+
+## 添加标签
+
+**添加标签** 会打开一个对话框，包含标签的两个字段，均为必填：
+
+| 字段 | 含义 |
+|---|---|
+| **标签** | 标签的文本，例如 PRODUCTION |
+| **颜色** | 蓝色、绿色、琥珀色、橙色、红色或灰色，以圆形色块显示；初始为红色 |
+
+预览区会显示页眉，其中包括所有已启用的标签，以及正在输入的新标签。新标签默认为已启用，并排在其他标签之后。
+标签的页面只有一个选项卡：**详情**，包含相同的字段、会立即保存的 **已启用** 开关以及预览。
+
+---
+
+## 7.2 中的环境标签
+
+在 7.2 及更早版本中，**设置 > 外观 > 环境** 只能在徽标旁设置一个标签。
+
+只有一个标签时，若同时打开多个实例，PRODUCTION EU 和 PRODUCTION US 都只显示为 PRODUCTION。从 7.3.0 起，
+升级会把该标签作为列表中的第一个标签，保留其文本、颜色以及是否显示，旧的 **环境**
+地址会打开该列表。
+
+---
+
+## 配置种子中的标签
+
+从 7.3.0 起，[配置种子](../seed/) 在其 `labels` 部分声明标签，每个标签包含文本，并可选择指定颜色：
+
+```yaml
+labels:
+  items:
+    - name: PRODUCTION
+      color: red
+    - name: EU
+      color: blue
+      enabled: true
+      position: 2
+```
+
+`color` 取值为 `blue`、`green`、`amber`、`orange`、`red` 或 `grey` 之一，`position` 决定顺序，数值小的排在前面。
+与所有 [托管对象](../seed/managed-objects.html) 一样，在种子中声明的标签在其页面上为只读。
diff --git a/i18n/zh/_configure/appearance/links.md b/i18n/zh/_configure/appearance/links.md
new file mode 100644
index 0000000..17782c4
--- /dev/null
+++ b/i18n/zh/_configure/appearance/links.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: 链接
+parent: 外观
+nav_order: 5
+translated_from: b17adbc1210baac2cf6786f7b0cef5e18fea8ae1
+---
+
+# 链接
+{: .no_toc }
+
+页眉中的链接，包括内置链接和您自己的链接
+{: .fs-6 .fw-300 }
+
+**链接** 为所有已登录的用户设置页眉中的链接，分为两个选项卡。
+
+**内置** 中有 **设计器** 开关，保存在 [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) 中，
+无需重启即可生效。关闭后，所有人都无法使用设计器：它的链接、页面和 API 都会消失。
+
+**自定义** 中保存您自己的链接，例如 wiki、运维手册或支持门户。**添加链接** 会添加一行，包含以下字段：
+
+| 字段 | 含义 |
+|---|---|
+| **图标** | 显示在标签前的图标，从列表中选择 |
+| **标签** | 链接的文本 |
+| **地址** | 一个网站（`https://…`）或应用中的一个页面（`/forms/all`） |
+| **新标签页** | 在新的浏览器标签页中打开链接 |
+
+每行的按钮用于移动它：**→** 把该链接放进上方的链接中，上方的链接随后在页眉中以菜单形式打开，
+**←** 把它移回页眉，上下箭头则上下移动它（若是菜单，则连同其中的链接一起移动）。
+菜单本身不需要地址。
+
+在内置链接之后，页眉最多容纳 5 个您自己的链接，每个菜单中最多 10 个。
diff --git a/i18n/zh/_configure/appearance/logo.md b/i18n/zh/_configure/appearance/logo.md
new file mode 100644
index 0000000..644377c
--- /dev/null
+++ b/i18n/zh/_configure/appearance/logo.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: 徽标
+parent: 外观
+nav_order: 3
+translated_from: 758fef67f2f704714e58065380b77f000000317f
+---
+
+# 徽标
+{: .no_toc }
+
+页眉中您自己的徽标
+{: .fs-6 .fw-300 }
+
+**徽标** 用您自己的图片替换页眉中的 AnsibleForms 徽标，在所有主题下都会显示：
+
+| 规则 | 值 |
+|---|---|
+| 类型 | PNG、JPEG、WEBP、GIF 和 SVG |
+| 文件大小上限 | 900 KB |
+| 在页眉中的尺寸 | 最大 200 × 33 px，保持原有比例 |
+
+在 **新徽标** 下选择一个文件进行预览，然后点击 **上传**。**当前徽标** 显示正在使用的徽标及其在页眉中显示的尺寸。
+**移除自定义徽标** 会恢复默认徽标，默认徽标会随主题变化。
diff --git a/i18n/zh/_configure/appearance/name.md b/i18n/zh/_configure/appearance/name.md
new file mode 100644
index 0000000..1319a69
--- /dev/null
+++ b/i18n/zh/_configure/appearance/name.md
@@ -0,0 +1,16 @@
+---
+layout: default
+title: 名称
+parent: 外观
+nav_order: 2
+translated_from: fa9f4116c202b7a476161e4881208eacfaadbc45
+---
+
+# 名称
+{: .no_toc }
+
+浏览器标签页和登录页面上显示的应用名称
+{: .fs-6 .fw-300 }
+
+**名称** 中保存 **应用名称**，显示在浏览器标签页和登录页面上。留空时，浏览器标签页显示
+`AnsibleForms`，登录页面则不显示名称。
diff --git a/i18n/zh/_configure/authentication/entra-id.md b/i18n/zh/_configure/authentication/entra-id.md
new file mode 100644
index 0000000..0c1631c
--- /dev/null
+++ b/i18n/zh/_configure/authentication/entra-id.md
@@ -0,0 +1,146 @@
+---
+layout: default
+title: Entra ID
+parent: 身份验证
+nav_order: 3
+translated_from: c5dad595f7df36cfd31a902ad0a44c7b5bb02f4e
+---
+
+# Entra ID
+{: .no_toc }
+
+使用 Microsoft Entra ID（Azure AD）进行单点登录，角色来自用户所属的 Entra ID 组
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作原理
+
+启用 Entra ID 提供商后，登录页面会在 **登录** 下方显示一个 Entra ID 按钮。登录过程如下：
+
+1. 按钮把浏览器发送到 `/api/v2/auth/entraid`，再由它重定向到 Microsoft。
+2. 用户在 Microsoft 登录，Microsoft 携带授权码重定向回 **重定向 URL**。服务器
+   用该授权码向 Microsoft 换取 ID 令牌和用于 Microsoft Graph 的访问令牌。
+3. 服务器从 Microsoft Graph（`/v1.0/me/transitiveMemberOf`）读取用户所属的组，因此嵌套组也会计算在内。
+4. 这些组按其显示名称用 **组筛选** 进行筛选，保留下来的每个组都保存两次，
+   分别为 `azuread/<object id>` 和 `azuread/<display name>`。
+
+用户名是令牌的 `upn` 声明，例如 `jdoe@example.com`；令牌中没有 `upn` 时使用 `preferred_username` 声明。
+对于工作账户，两者的值相同。
+
+---
+
+## 注册应用
+
+AnsibleForms 需要在 Entra 管理中心的 **App registrations > New registration** 下进行应用注册：
+
+1. 为其命名，在支持的账户类型中选择 **Accounts in this organizational directory only**，并添加一个
+   类型为 **Web** 的重定向 URI：`https://af.example.com/api/v2/auth/entraid/callback`。
+2. 在 **Certificates & secrets** 下创建一个客户端密钥并复制其值；该值只显示一次。
+3. 在 **API permissions** 下添加 Microsoft Graph 的 **delegated** 权限 `User.Read` 和 `GroupMember.Read.All`，
+   并为其授予管理员同意。
+4. 在 **Overview** 页面记下 **Application (client) ID** 和 **Directory (tenant) ID**。
+
+重定向 URI 是用户访问 AnsibleForms 的地址，后接 `/api/v2/auth/entraid/callback`。
+当 [`BASE_URL`](../customization/server.html#env_BASE_URL) 为 `/forms` 时，它变为
+`https://af.example.com/forms/api/v2/auth/entraid/callback`。它必须与提供商凭据中的 **重定向 URI**
+完全一致。
+
+在 7.2.0 及更早版本中，路径为 `/api/v2/auth/azureadoauth2/callback`。从 7.3.0 起它仍然有效，因此现有的注册
+无需修改；**重定向 URI** 为空的凭据会使用新路径，此时请将新路径添加到注册中。
+
+AnsibleForms 从 Graph 读取组，不使用令牌中的 groups 声明，因此无需在注册中配置
+组声明。
+
+---
+
+## 添加提供商
+
+在 **访问 > SSO** 下添加提供商：向导分四步询问其字段，在 **类型** 一步中选择 **Microsoft Entra ID**：
+
+| 步骤 | 字段 | 含义 |
+|---|---|---|
+| 详情 | 名称、描述 | 提供商的唯一名称，以及可选的描述 |
+| 类型 | 提供商 | **Microsoft Entra ID**；创建时设定，之后不可更改 |
+| 凭据 | 凭据 | [连接 > 凭据](../credentials.html) 中的一个 **Microsoft Entra ID** 凭据，见下文 |
+| 组 | 组筛选 | 正则表达式；只保留显示名称与之匹配的组。留空则保留所有组 |
+
+凭据中保存应用注册的信息，因此只有管理员才能添加或修改它：
+
+| 字段 | 含义 |
+|---|---|
+| 租户 ID | 必填。Directory (tenant) ID（一个 GUID），或租户的某个域名。只有该租户的用户才能登录 |
+| 客户端 ID | Application (client) ID |
+| 客户端密钥 | 客户端密钥的值，加密保存或从 [密钥库](../secret-stores/) 读取 |
+| 重定向 URI | 与注册时一致，例如 `https://af.example.com/api/v2/auth/entraid/callback`。留空：使用应用的 URL 加回调路径 |
+
+租户 ID 为空的凭据在保存时会被拒绝。多租户端点 `common`、`organizations`
+和 `consumers` 会在保存引用该凭据的提供商时被拒绝，因为它们会允许任何
+Microsoft 租户的用户登录。登录时，服务器还会检查令牌是否来自配置的租户。之前保存的、没有租户 ID 的提供商
+不会让任何人登录：在填写租户 ID 之前，服务器会记录
+`Could not enable Microsoft Entra ID: set the tenant id to your tenant ('' would let any Microsoft tenant log in)`。
+
+在 7.2.0 及更早版本中，租户、客户端 ID、密钥和重定向 URL 是提供商的字段。升级到 7.3.0 时，它们会被移入一个
+名为 `<provider>-sso` 的凭据，参见 [凭据中的地址](../credentials/types.html#addresses-in-credentials)。
+请为每个新提供商选择一个凭据：服务器仍接受 7.3.0 之前自带客户端 ID 和密钥的提供商，
+在选择凭据之前，它会继续使用这些值登录。
+
+同一时间只启用一个 Entra ID 提供商，即 Entra ID 按钮登录时使用的那个。在另一个提供商的行菜单中点击 **启用**，
+或打开其 **已启用** 开关，会关闭同类型的其他提供商；列表的 **已启用** 列显示正在使用的是哪一个。提供商
+还可以跳过登录页面，参见 [切换单点登录](./#switching-single-sign-on)。保存后立即生效，无需重启。
+
+---
+
+## 映射到角色
+
+在 config.yaml 中，Entra ID 组写作 `entraid/<object id>` 或 `entraid/<display name>`，用户写作 `entraid/<upn>`。
+对象 ID 在租户中是唯一的，因此更安全；显示名称则更易读：
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - entraid/0b6c8e1a-2f4d-4c7e-9a3b-5d1e7f2a4c6b
+  - name: operator
+    groups:
+      - entraid/AF-Operators
+    users:
+      - entraid/jdoe@example.com
+```
+
+在 7.2.0 及更早版本中，前缀为 `azuread/`。从 7.3.0 起，在角色中它仍然匹配相同的成员，并将在 8.0 中移除；
+角色编辑器会写入 `entraid/`。只有角色接受 `entraid/`：用户的组以 `azuread/<object id>` 和
+`azuread/<display name>` 保存，个人资料页面和 `ansibleforms_user` extravar 也如此显示。诸如 `^AF-` 的 **组筛选** 只保留您的角色所用的组；参见 [角色](../config/roles.html)。从 7.1.0 起，
+登录令牌不再携带组，因此其大小不再随组的数量增长。对于属于很多组的用户，筛选仍然
+有意义：每次登录时与角色比对的组更少，并且用户的
+[目录记录](../users-and-groups/directory.html) 只列出起作用的组。在 7.1.0 之前，
+属于一百个或更多组的用户需要它才能看到任何表单，参见
+[单点登录后表单和作业为空](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431)。
+
+---
+
+## Microsoft Graph 端点
+
+默认情况下，服务器在 `https://login.microsoftonline.com` 让用户登录，并在 `https://graph.microsoft.com` 调用 Microsoft Graph：
+
+| 变量 | 改变的内容 |
+|---|---|
+| [`ENTRA_AUTHORITY_URI`](../customization/security.html#env_ENTRA_AUTHORITY_URI) | 登录颁发机构，用于国家云，例如 `https://login.microsoftonline.us` |
+| [`ENTRA_GRAPH_URI`](../customization/security.html#env_ENTRA_GRAPH_URI) | 读取组所用的 Graph 端点，例如 `https://graph.microsoft.us` |
+
+两者都接受不带末尾斜杠的基础 URI，均为 7.3.0 新增。未设置它们时，仍会读取 `AZURE_AUTHORITY_URI` 和 `AZURE_GRAPH_URI`，
+并在日志中记录一条警告；这两个变量将在 8.0 中移除。服务器必须能够访问 Graph：无法读取组时登录会失败。
+
+---
+
+## 限制
+
+Entra ID 用户通过 Microsoft 登录，因此有几项功能与本地账户和 LDAP 账户不同：
+
+- 他们在 AnsibleForms 中没有密码，因此无法在其中修改密码；[API 令牌](../profile/api-token.html) 由其会话生成。
+- 在 Entra ID 中显示名称不是唯一的：同名的两个组会映射到同一个角色。在角色中按对象 ID
+  指定该组，即 `entraid/<object id>`，就只会匹配这个组。
diff --git a/i18n/zh/_configure/authentication/index.md b/i18n/zh/_configure/authentication/index.md
new file mode 100644
index 0000000..f7e738f
--- /dev/null
+++ b/i18n/zh/_configure/authentication/index.md
@@ -0,0 +1,108 @@
+---
+layout: default
+title: 身份验证
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /authentication/
+translated_from: 024cff3760cf611daeacea8aea7d72b85c0a6d17
+---
+
+# 身份验证
+{: .no_toc }
+
+选择用户的登录方式，以及他们的账户和组如何映射到角色
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 登录方式
+
+AnsibleForms 支持四种登录方式，并且可以同时启用多种：
+
+| 方式 | 适用场景 | 页面 |
+|---|---|---|
+| 本地账户 | 内置管理员、服务账户、小型团队，或在目录服务不可用时作为备用。 | [本地账户](local.html) |
+| LDAP | 用户和组位于 Active Directory、OpenLDAP 或其他 LDAP 目录中。 | [LDAP](ldap.html) |
+| Entra ID | 用户使用其 Microsoft 365 / Entra ID 账户登录（单点登录）。 | [Entra ID](entra-id.html) |
+| OIDC | 通过其他 OpenID Connect 提供商（例如 Keycloak）进行单点登录。 | [OIDC](oidc.html) |
+
+本地账户和 LDAP 在 **访问 > 用户**、**组** 和 **LDAP** 下配置；Entra ID 和 OIDC 在
+**访问 > SSO** 下配置。
+
+---
+
+## 登录时如何选择方式
+
+登录页面有一个用户名和密码表单，每个已启用的单点登录提供商还各有一个按钮：
+
+- **用户名和密码** 首先与本地用户进行比对。只有当没有同名的本地用户且已启用 LDAP 时，
+  才会尝试目录服务。本地用户密码错误时会直接被拒绝，不会再询问 LDAP。
+- **Entra ID 和 OpenID 按钮** 在启用了相应提供商时显示在 **登录** 下方。它们会把浏览器跳转到
+  提供商再跳转回来；密码不会到达 AnsibleForms。
+
+同一时间只能启用一个 Entra ID 提供商和一个 OIDC 提供商：启用其中一个会关闭同类型的其他提供商。
+用户名和密码登录失败时始终显示同样的通用消息；具体原因记录在服务器日志和审计日志中。
+
+---
+
+## 切换单点登录
+
+从 7.3.0 起，**访问 > SSO** 下的每个提供商都有两个独立的开关，无需重启即可生效：
+
+| 开关 | 作用 |
+|---|---|
+| **已启用** | 在登录页面显示该提供商的按钮，并接受通过它的登录。打开它会关闭同类型的其他提供商。 |
+| **跳过登录页** | 在该提供商启用期间，用户不经过登录页面，直接跳转到该提供商。为一个提供商打开它会为其他提供商关闭它；对于已关闭的提供商，该开关显示为灰色。 |
+
+用户名和密码表单始终可以通过 `/login?local` 访问，供本地管理员使用或在提供商故障时使用；
+退出登录后，以及单点登录返回错误时，也会显示该表单。
+
+`ENABLE_SSO` 和 `SSO_AUTO_LOGIN` 变量已在 7.3.0 中移除。7.3.0 首次启动时会读取它们一次，
+只要它们仍被设置，每次启动都会记录一条警告，因此升级后请将它们从环境中删除：
+
+| 7.3.0 之前的变量 | 升级时的处理 |
+|---|---|
+| `ENABLE_SSO=0` | 关闭所有提供商：提供商的配置保留，但登录页面上不显示按钮 |
+| `SSO_AUTO_LOGIN=1` | 当恰好只启用了一个提供商且 `ENABLE_SSO` 不为 `0` 时，为该提供商打开 **跳过登录页** |
+
+---
+
+## 从用户到角色
+
+每次登录都会产生一个用户，带有一个 **类型**（`local`、`ldap`、`azuread` 或 `oidc`）、一个用户名和一个组列表。
+每个组都会加上其类型的前缀，因此 Entra ID 组会以 `azuread/...` 的形式保存和显示：
+
+| 登录方式 | 用户名 | 组 |
+|---|---|---|
+| 本地 | 本地用户名 | `local/<group>`，用户所属的每个本地组各一个 |
+| LDAP，`main` 目录 | 用户名属性的值 | `ldap/<cn>`，目录返回的每个组的 CN |
+| LDAP，其他目录 | `<directory>/<username>` | `ldap/<directory>/<cn>`，参见 [多个目录](ldap.html#several-directories) |
+| Entra ID | `upn` 声明；令牌中没有 `upn` 时使用 `preferred_username` | 每个组的 `azuread/<object id>` 和 `azuread/<display name>`，从 Microsoft Graph 读取 |
+| OIDC | `preferred_username` 声明 | `oidc/<name>`，来自 ID 令牌的 `groups` 声明 |
+
+随后，config.yaml 中的 [角色](../config/roles.html) 会匹配这些值：当角色的某个 `groups` 是用户所属的组之一，
+或者角色的 `users` 中包含 `<type>/<username>` 时，该角色即适用。每个用户还会获得 `default` 角色。从 7.3.0 起，
+角色可以用 `entraid/<group>` 或 `entraid/<upn>` 来指定 Entra ID 成员，它与保存的 `azuread/` 值匹配；在角色中使用
+`azuread/` 仍然有效，但将在 8.0 中移除。个人资料和作业的 extravars 中仍然显示 `azuread/`。
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+      - entraid/AF-Admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - ldap/jdoe
+```
+
+用户的 **个人资料** 页面列出登录类型、组和角色，这是检查映射最快的方法。
+`allowLogin` 角色选项可以拒绝未匹配任何角色的用户登录：在 `default` 上将其设为 `false`，并在允许登录的角色上设为
+`true`。
diff --git a/i18n/zh/_configure/authentication/ldap.md b/i18n/zh/_configure/authentication/ldap.md
new file mode 100644
index 0000000..7434f76
--- /dev/null
+++ b/i18n/zh/_configure/authentication/ldap.md
@@ -0,0 +1,240 @@
+---
+layout: default
+title: LDAP
+parent: 身份验证
+nav_order: 2
+translated_from: a4089d681ad976e31e7ddefb29588bd3ca334dab
+---
+
+# LDAP
+{: .no_toc }
+
+让目录用户使用自己的密码登录，并通过其目录组为他们分配角色
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作原理
+
+AnsibleForms 使用绑定账户连接到目录，搜索该用户，然后以该用户身份绑定以验证
+密码：
+
+1. 用户使用用户名和密码登录。当没有同名的 **本地** 用户时，会尝试 LDAP。
+2. AnsibleForms 使用目录凭据中的绑定账户进行绑定，并在 **搜索基准** 中搜索
+   **用户名属性** 等于该用户名的条目。
+3. 它使用输入的密码，以找到的条目身份进行绑定。
+4. 从该条目（或通过组搜索）读取组，进行筛选，并加上 `ldap/` 前缀。
+
+UPN 形式的用户名（`jdoe@example.com`）如果找不到用户，会使用 `@` 之前的部分重试一次，因此即使用户名属性
+保存的是短名称，用户也可以使用任一形式登录。密码错误时永远不会重试。
+
+同一套设置适用于 Active Directory、OpenLDAP 等目录；从 7.3.0 起可以有 [多个目录](#several-directories)。
+
+---
+
+## 设置
+
+从 7.3.0 起，设置按目录分别保存。**访问 > LDAP** 按查找不带前缀用户名时的顺序列出各个目录：
+
+![访问 > LDAP](../assets/screenshots/ldap.jpg)
+
+| 行菜单 | 作用 |
+|---|---|
+| 编辑 | 打开该目录的页面 |
+| 测试连接 | 使用测试用户名和密码尝试登录，参见 [测试连接](#testing-the-connection) |
+| 启用、禁用 | 打开或关闭该目录；`main` 只能关闭，不能删除 |
+| 上移、下移 | 更改其在查找顺序中的位置 |
+| 删除 | 删除该目录；在 `main` 上显示但不可用 |
+
+添加目录时分四步询问其字段，即其页面上的各个选项卡。**详情** 中包含 **已启用**、**名称** 和 **描述**：
+
+| 选项卡 | 设置 | 含义 |
+|---|---|---|
+| 凭据 | 凭据 | 必填。[连接 > 凭据](../credentials.html) 中的一个 `ldap` 凭据，保存连接信息，见下文 |
+| 用户 | 搜索基准 | 用户搜索开始的 DN，例如 `OU=Users,DC=example,DC=com`。也会搜索其子树 |
+| 用户 | 用户名属性 | 与登录名进行匹配的属性：AD 中为 `sAMAccountName`（默认值），OpenLDAP 中为 `uid` |
+| 用户 | 邮件属性 | 保存电子邮件地址的属性，通常为 `mail` |
+| 用户 | 登录域 | 以 `user@domain` 登录时直接使用此目录的域，参见 [多个目录](#several-directories) |
+| 组 | 组属性 | 用户条目中保存组的属性（`memberOf`，默认值），使用组搜索时为 `groups` |
+| 组 | 组搜索基准 | 组搜索开始的 DN |
+| 组 | 组类 | 组的 objectClass，例如 `group`、`groupOfNames` 或 `posixGroup` |
+| 组 | 组成员属性 | 组中列出其成员的属性，例如 `member`、`uniqueMember` 或 `memberUid`；默认为 `member` |
+| 组 | 组成员用户属性 | 这些成员值所对应的用户属性，例如 `dn` 或 `uid`；默认为 `dn` |
+| 组 | 组筛选 | 正则表达式；只保留名称与之匹配的组。留空则保留所有组 |
+
+最后三个组字段的默认值仅在使用组搜索时生效，见下一节。
+
+`ldap` 凭据保存如何访问目录以及以谁的身份进行搜索：
+
+| 字段 | 含义 |
+|---|---|
+| 服务器 | 每个字段一个，形式为 `host`、`host:port` 或 `ldaps://host:port`，按此顺序尝试：一个无法访问时，尝试下一个 |
+| 端口 | 普通 LDAP 为 `389`，LDAPS 为 `636` |
+| 启用 TLS | 使用 LDAPS（`ldaps://`）连接。不支持在 389 端口上使用 StartTLS |
+| 忽略证书 | 跳过对服务器证书的验证。仅在 **启用 TLS** 时显示 |
+| 证书 | 校验证书时，AnsibleForms 向服务器出示的客户端证书，PEM 格式 |
+| CA 证书包 | 校验证书时，签发服务器证书的 CA 证书，PEM 格式 |
+| 绑定用户 DN | 用于搜索目录的服务账户的 DN |
+| 绑定用户密码 | 其密码，加密保存或从 [密钥库](../secret-stores/) 读取 |
+
+只有管理员可以添加或修改 `ldap` 凭据，参见 [谁可以修改凭据](../credentials.html#who-may-change-a-credential)。
+在 7.2.0 及更早版本中，服务器、TLS 和绑定账户是 LDAP 设置中的字段。升级到 7.3.0 时会把它们移入凭据，
+参见 [凭据中的地址](../credentials/types.html#addresses-in-credentials)：
+
+| 升级前的目录 | 其服务器的去向 |
+|---|---|
+| 自带绑定 DN 和密码，没有凭据 | 一个名为 `<directory>-ldap` 的新 `ldap` 凭据，例如 `main-ldap` |
+| 有凭据但凭据中没有服务器 | 放入该凭据 |
+| 有凭据且凭据中已有其他服务器 | 该凭据的一个副本，名为 `<credential>-<directory>`，目录随后引用该副本 |
+
+名称已被占用时会加上 `-2`、`-3` 等后缀。来自配置种子的目录保持不变：它归种子所有。
+
+---
+
+## 组
+
+组来自以下两个位置之一，由 **组属性** 决定使用哪一个：
+
+- **用户条目的某个属性**，通常为 `memberOf`。这是 Active Directory 以及
+  启用了 `memberof` overlay 的 OpenLDAP 的常见设置。
+- **组搜索**，用于没有 `memberOf` 的目录。只有同时设置了 **组搜索基准** 和 **组类**
+  时才会执行：AnsibleForms 会搜索该类的组中 **组成员属性** 包含用户的
+  **组成员用户属性** 的组，并将结果保存在属性 `groups` 中。将 **组属性** 设为 `groups`
+  即可使用它。
+
+{: .note }
+> 当 **组属性** 为 `memberOf` 时，已配置的组搜索仍会执行，但其结果不会用于角色。
+
+每个组都是一个 DN，AnsibleForms 保留其第一个 CN：`CN=AF-Admins,OU=Groups,DC=example,DC=com` 变为 `AF-Admins`。
+然后对该名称应用 **组筛选**，剩下的组加上 `ldap/` 前缀：`ldap/AF-Admins`。
+
+在大型目录中，筛选可以让令牌和作业保持精简；无效的正则表达式会保留所有组，并记录到日志中。
+
+---
+
+## 映射到角色
+
+在 config.yaml 中，LDAP 组写作 `ldap/<group CN>`，LDAP 用户写作 `ldap/<username>`，两者都区分大小写：
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - ldap/AF-Admins
+  - name: operator
+    groups:
+      - ldap/AF-Operators
+    users:
+      - ldap/jdoe
+```
+
+用户名是目录返回的 **用户名属性** 的值，而不是用户输入的值。
+角色选项参见 [角色](../config/roles.html)。
+
+---
+
+## 多个目录
+
+从 7.3.0 起可以有多个目录，每个目录都有自己的服务器、用户和组。目录名称用于区分其成员：
+
+| 目录 | 用户名 | 组 | 在角色中 |
+|---|---|---|---|
+| `main` | `jdoe` | `ldap/AF-Admins` | `ldap/jdoe`、`ldap/AF-Admins` |
+| 其他任意目录，例如 `corp` | `corp/jdoe` | `ldap/corp/AF-Admins` | `ldap/corp/jdoe`、`ldap/corp/AF-Admins` |
+
+用户在登录时以 `corp\jdoe` 或 `corp/jdoe` 的形式指定目录，或者使用该目录所拥有域的地址登录。
+不带前缀的用户名会按顺序在每个已启用的目录中尝试；当没有名为 `other` 的目录时，像 `other\jdoe` 这样的名称也是如此：
+此时会按输入的原样查找。
+
+第一个认识该用户的目录说了算：在那里密码错误就是最终结果，不会再尝试下一个目录，
+因为下一个目录中可能有另一个同名的人。无法访问的目录会被跳过。
+
+7.2.0 及更早版本中名为 `default` 的目录从 7.3.0 起改名为 `main`：升级会将其重命名，新安装的实例一开始
+就有 `main`。其成员保留短名称，因此引用他们的角色无需修改。`main` 目录不能
+重命名，目录名称只能包含字母、数字、`-` 和 `_`。
+
+---
+
+## 测试连接
+
+**测试连接** 会要求输入测试用户名和密码，并使用屏幕上的设置（无论是否已保存）尝试登录。
+成功时会显示该用户的目录条目，从中可以看到应使用的确切属性名称和组 DN。
+
+即使测试用户不存在，也会报告成功：连接和绑定账户都正常，只是找不到该用户。
+常见错误：
+
+| 消息 | 原因 |
+|---|---|
+| `Bad server or port (connection failed)` | 主机名无法解析，或端口无法访问。 |
+| `Wrong binding credentials` | 目录凭据中的绑定 DN 或密码错误。 |
+| `Unable to verify the certificate` | 服务器证书不是由凭据的 CA 证书包签发的。 |
+| `Certificate is not valid` | 凭据的证书或 CA 证书包中没有有效的 PEM 证书。 |
+
+---
+
+## Active Directory 示例
+
+此示例通过 LDAPS 连接到两台域控制器，并只保留名称以 `AF-` 开头的组：
+
+| 设置 | 值 |
+|---|---|
+| 凭据 > 服务器 | `dc01.example.com`，然后是 `dc02.example.com` |
+| 凭据 > 端口 | `636` |
+| 凭据 > 启用 TLS | 开 |
+| 凭据 > 忽略证书 | 关，并配置客户端证书和企业 CA 的 CA 链 |
+| 凭据 > 绑定用户 DN | `CN=svc-ansibleforms,OU=Service Accounts,DC=example,DC=com` |
+| 搜索基准 | `OU=Users,DC=example,DC=com` |
+| 邮件属性 | `mail` |
+| 用户名属性 | `sAMAccountName` |
+| 组属性 | `memberOf` |
+| 组筛选 | `^AF-` |
+
+`CN=AF-Operators,…` 的成员会匹配包含 `ldap/AF-Operators` 的角色，并以 `jdoe` 或 `jdoe@example.com` 登录。
+
+---
+
+## OpenLDAP 示例
+
+此示例对 `groupOfNames` 条目使用组搜索，因此无需 `memberof` overlay 即可工作：
+
+| 设置 | 值 |
+|---|---|
+| 凭据 > 服务器 | `ldap.example.com` |
+| 凭据 > 端口 | `636` |
+| 凭据 > 启用 TLS | 开 |
+| 凭据 > 绑定用户 DN | `cn=readonly,dc=example,dc=com` |
+| 搜索基准 | `ou=people,dc=example,dc=com` |
+| 邮件属性 | `mail` |
+| 用户名属性 | `uid` |
+| 组属性 | `groups` |
+| 组搜索基准 | `ou=groups,dc=example,dc=com` |
+| 组类 | `groupOfNames` |
+| 组成员属性 | `member` |
+| 组成员用户属性 | `dn` |
+
+列在 `cn=af-admins,ou=groups,dc=example,dc=com` 中的用户会获得组 `ldap/af-admins`。对于 `posixGroup` 组，
+请使用 **组成员属性** `memberUid` 和 **组成员用户属性** `uid`。
+
+使用 `memberof` overlay 时，请将组搜索字段留空，并将 **组属性** 设为 `memberOf`。
+
+---
+
+## 常见问题
+
+大多数 LDAP 问题都可以归结为以下几种：
+
+- **存在同名的本地用户。** 本地用户会先被检查，因此对于该名称永远不会询问目录。
+- **没有组，或组不对。** 组属性必须存在（使用组搜索时为 `groups`）；`memberOf` 不处理嵌套。
+- **组名不匹配。** 请使用大小写一致的 `ldap/<CN>`，并检查组筛选是否保留了该组。
+- **组 DN 不以 CN 开头。** 只有第一个 `CN=` 值会用作组名，因此每个组 DN
+  都必须以 `CN=`（或 `cn=`）开头。
+- **证书。** TLS 需要凭据的两个证书字段都已填写，且服务器名称匹配；忽略证书仅用于测试。
+- **设置无法保存。** 当目录来自 [配置种子](../seed/managed-objects.html) 时，其页面
+  为只读：请改为修改种子文件。
+
+登录失败时显示通用消息。原因由服务器记录在日志中并保存在审计日志里；对于 Active
+Directory，原因会从目录的代码转换而来，例如 `Wrong password`、`Account locked` 或 `Password expired`。
diff --git a/i18n/zh/_configure/authentication/local.md b/i18n/zh/_configure/authentication/local.md
new file mode 100644
index 0000000..574afcb
--- /dev/null
+++ b/i18n/zh/_configure/authentication/local.md
@@ -0,0 +1,107 @@
+---
+layout: default
+title: 本地账户
+parent: 身份验证
+nav_order: 1
+translated_from: 002a371f2b4dbe5cc9c99ee569b8cf17a2a4ac88
+---
+
+# 本地账户
+{: .no_toc }
+
+内置管理员，以及保存在 AnsibleForms 数据库中的用户和组
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 内置管理员
+
+每次启动时，如果本地 `admins` 组和管理员用户不存在，就会创建它们；有三个变量控制管理员：
+
+| 变量 | 默认值 | 含义 |
+|---|---|---|
+| [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME) | `admin` | 管理员的用户名；当没有同名用户时，在 `admins` 组中创建。 |
+| [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) | `AnsibleForms!123` | 创建（或重置）管理员时为其设置的密码。 |
+| [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN) | `0` | 设为 `1` 时，将管理员密码重置为 `ADMIN_PASSWORD`，并把管理员重新加入 `admins`。 |
+
+`ADMIN_PASSWORD` 只在创建或重置用户时使用：之后单独修改它不会产生任何效果。
+
+使用公开的默认密码 `AnsibleForms!123` 登录的本地用户只能修改密码。浏览器会打开一个
+无法关闭的修改密码页面，在密码修改之前，服务器对其他所有请求都返回 `403`（代码
+`password_change_required`）。新密码必须与默认密码不同；修改之后，用户需使用新密码重新登录。
+在首次启动前将 `ADMIN_PASSWORD` 设为您自己的值，即可跳过这一步。
+
+首次启动后再修改 `ADMIN_USERNAME`，会以新名称创建第二个管理员用户；原来的用户仍会保留。
+
+{: .warning }
+> 只要设置了 `REINIT_ADMIN=1`，**每次** 启动都会重置密码。请用它来找回丢失的管理员密码，
+> 然后将其删除并重启。
+
+---
+
+## 用户和组
+
+本地用户和组在 **访问 > 用户** 和 **访问 > 组** 下管理。用户包含以下字段：
+
+| 字段 | 含义 |
+|---|---|
+| 用户名 | 登录名。必须唯一。 |
+| 描述 | 可选。 |
+| 密码 | 以哈希形式保存。之后可通过 **修改密码** 操作修改。 |
+| 电子邮件 | 可选。 |
+| 组 | 用户的第一个本地组。可在用户页面的 **组** 选项卡中添加更多组。 |
+
+本地用户在自己的个人资料中修改密码；其他用户则在其目录服务或身份提供商中修改。
+
+一个用户可以属于多个组，并获得所有这些组的角色。用户页面的 **组** 选项卡可以添加和
+移除组，组页面的 **用户** 选项卡也可以。用户至少要保留一个组：最后一个组无法
+移除。
+
+仍有用户的组无法删除：请先移除其中的用户。`admins` 组永远不能被删除或
+重命名，用户 `admin` 也永远不能被删除。
+
+---
+
+## 允许登录
+
+用户页面的 **详情** 选项卡中有一个 **允许登录** 开关，在用户列表的行菜单中也以 **阻止登录** 和 **允许
+登录** 的形式提供。本地用户以及 LDAP 和 SSO 用户都有该开关：
+
+- **开**：用户照常登录。
+- **关**：用户的会话会立即结束，所有登录都会被拒绝，直到管理员重新打开它。页面
+  会先请求确认。
+
+不能为用户 `admin`（作为恢复访问的途径）关闭该开关，管理员也不能为自己的账户关闭它。
+LDAP 或 SSO 用户的页面上还有 **结束会话**，它会让该用户在所有地方退出登录，但不会阻止其登录。
+
+---
+
+## 映射到角色
+
+角色以 `local/<group>` 指定本地组，以 `local/<user>` 指定用户；默认情况下，`admins` 获得 `admin`：
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+  - name: operator
+    groups:
+      - local/operators
+    users:
+      - local/svc-backup
+```
+
+请在 `admin` 角色中保留 `local/admins`，这样即使目录服务或身份提供商不可用，内置管理员也始终可以登录。
+当 config.yaml 完全无法加载时，`local/admins` 的成员仍会获得 `admin` 角色，以便您登录并修复它。
+角色选项参见 [角色](../config/roles.html)。
+
+---
+
+## 本地账户与 LDAP
+
+用户名和密码登录会先检查本地用户，再检查 LDAP。当本地用户与目录用户同名时，本地账户始终优先，
+该名称无法使用目录密码登录。请为本地账户取不会与目录账户冲突的名称，例如加上 `svc-` 前缀。
diff --git a/i18n/zh/_configure/authentication/oidc.md b/i18n/zh/_configure/authentication/oidc.md
new file mode 100644
index 0000000..aad5756
--- /dev/null
+++ b/i18n/zh/_configure/authentication/oidc.md
@@ -0,0 +1,133 @@
+---
+layout: default
+title: OIDC
+parent: 身份验证
+nav_order: 4
+translated_from: 5451df911884021544dea5ffbaa7228a7a4435ef
+---
+
+# OIDC
+{: .no_toc }
+
+使用 Keycloak 等 OpenID Connect 提供商进行单点登录，角色来自 groups 声明
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 工作原理
+
+启用 OIDC 提供商后，登录页面会在 **登录** 下方显示一个 OpenID 按钮。登录过程如下：
+
+1. 按钮把浏览器发送到 `/api/v2/auth/oidc`，再由它重定向到提供商（带 PKCE 的
+   授权码流程）。
+2. 用户在提供商处登录，提供商重定向回 **重定向 URL**。
+3. 服务器用授权码换取令牌，并读取 ID 令牌中的声明。
+4. 用户名是 `preferred_username` 声明；`groups` 声明中每个通过 **组筛选** 的值
+   都会成为一个组 `oidc/<value>`。
+
+AnsibleForms 请求的作用域为 `openid profile email`；作用域不可配置。从 AnsibleForms 退出登录时，
+如果提供商公布了结束会话端点，浏览器也会被发送到该端点。
+
+{: .note }
+> OIDC 已在 Keycloak 上测试过。其他提供商只要满足下面的要求即可使用。
+
+---
+
+## 提供商要求
+
+提供商必须支持 OpenID Connect 发现，并为 AnsibleForms 提供一个机密客户端：
+
+- **发现**：AnsibleForms 读取 `<issuer>/.well-known/openid-configuration`，因此 AnsibleForms 服务器
+  必须能通过 HTTPS 访问颁发者。
+- **一个机密客户端**，使用授权码流程，并有客户端 ID 和客户端密钥。
+- **重定向 URI** `https://af.example.com/api/v2/auth/oidc/callback`，即用户访问
+  AnsibleForms 的地址后接 `/api/v2/auth/oidc/callback`。当 [`BASE_URL`](../customization/server.html#env_BASE_URL)
+  为 `/forms` 时，它变为 `https://af.example.com/forms/api/v2/auth/oidc/callback`。
+- **ID 令牌中的 `groups` 声明**，包含一个组名列表。没有它，用户就不会获得任何 OIDC 组。
+- **一个 `preferred_username` 声明**，它会成为用户名。
+
+---
+
+## Keycloak 示例
+
+此示例使用 `https://keycloak.example.com` 上的 realm `example`；此时颁发者为
+`https://keycloak.example.com/realms/example`。在该 realm 中：
+
+1. 在 **Clients** 下创建一个客户端 ID 为 `ansibleforms` 的 OpenID Connect 客户端。打开 **Client authentication**，
+   保留 **Standard flow**，并将 **Valid redirect URIs** 设为 `https://af.example.com/api/v2/auth/oidc/callback`。
+2. 在客户端的 **Credentials** 选项卡中，复制 **Client secret**。
+3. 在 **Client scopes** 选项卡中，打开 `ansibleforms-dedicated`，添加一个映射器 **By configuration > Group Membership**，
+   将 **Token Claim Name** 设为 `groups`，关闭 **Full group path**，并打开 **Add to ID token**。
+
+如果打开 **Full group path**，声明中保存的是 `/af-admins` 这样的路径，此时角色必须使用 `oidc//af-admins`。
+
+---
+
+## 添加提供商
+
+在 **访问 > SSO** 下添加提供商：向导分四步询问其字段，在 **类型** 一步中选择 **Open ID**：
+
+| 步骤 | 字段 | 含义 |
+|---|---|---|
+| 详情 | 名称、描述 | 提供商的唯一名称，以及可选的描述 |
+| 类型 | 提供商 | **Open ID**；创建时设定，之后不可更改 |
+| 凭据 | 凭据 | [连接 > 凭据](../credentials.html) 中的一个 **Open ID** 凭据，见下文 |
+| 组 | 组筛选 | 正则表达式；只保留 `groups` 声明中与之匹配的值。留空则保留所有组 |
+
+凭据中保存客户端信息，因此只有管理员才能添加或修改它：
+
+| 字段 | 含义 |
+|---|---|
+| 颁发者 | 必填。颁发者 URL，例如 `https://keycloak.example.com/realms/example` |
+| 客户端 ID | 提供商处的客户端 ID，例如 `ansibleforms` |
+| 客户端密钥 | 客户端密钥，加密保存或从 [密钥库](../secret-stores/) 读取 |
+| 重定向 URI | 与注册时一致，例如 `https://af.example.com/api/v2/auth/oidc/callback`。留空：使用应用的 URL 加回调路径 |
+
+在 7.2.0 及更早版本中，颁发者、客户端 ID、密钥和重定向 URL 是提供商的字段。升级到 7.3.0 时，它们会被移入一个
+名为 `<provider>-sso` 的凭据，参见 [凭据中的地址](../credentials/types.html#addresses-in-credentials)。
+请为每个新提供商选择一个凭据：服务器仍接受 7.3.0 之前自带客户端 ID 和密钥的提供商，
+在选择凭据之前，它会继续使用这些值登录。
+
+同一时间只启用一个 OIDC 提供商，即 OpenID 按钮登录时使用的那个。在另一个提供商的行菜单中点击 **启用**，
+或打开其 **已启用** 开关，会关闭同类型的其他提供商；列表的 **已启用** 列显示正在使用的是哪一个。
+提供商还可以跳过登录页面，参见 [切换单点登录](./#switching-single-sign-on)。
+
+保存提供商后立即生效。当颁发者无法访问时，服务器会记录
+`Failed to initialize OIDC strategy`，在再次保存提供商或重启服务器之前，OIDC 登录都会失败。
+
+---
+
+## 映射到角色
+
+在 config.yaml 中，OIDC 组写作 `oidc/<group>`，用户写作 `oidc/<preferred_username>`：
+
+```yaml
+roles:
+  - name: admin
+    groups:
+      - local/admins
+      - oidc/af-admins
+  - name: operator
+    groups:
+      - oidc/af-operators
+    users:
+      - oidc/jdoe
+```
+
+这些值按精确匹配进行比较，包括大小写。角色选项参见 [角色](../config/roles.html)。
+
+---
+
+## 限制
+
+OIDC 用户在提供商处登录，因此有几项功能与本地账户和 LDAP 账户不同：
+
+- 他们在 AnsibleForms 中没有密码，因此无法在其中修改密码；从 7.2.0 起，[API 令牌](../profile/api-token.html)
+  由其会话生成。
+- 请让 `groups` 声明保持简短：只发送对 AnsibleForms 有意义的组，例如在提供商处使用专用的
+  客户端作用域或组结构，或者用 **组筛选** 对其进行筛选。从 7.1.0 起，AnsibleForms 的登录
+  令牌不再携带组；在此之前，属于一百个或更多组的用户可能看不到任何表单，参见
+  [单点登录后表单和作业为空](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431)。
diff --git a/i18n/zh/_configure/config/categories.md b/i18n/zh/_configure/config/categories.md
new file mode 100644
index 0000000..3e021f8
--- /dev/null
+++ b/i18n/zh/_configure/config/categories.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: 类别
+parent: config.yaml
+nav_order: 1
+translated_from: b85b1c12cd01bdbdaa81c2de4ea9d91dac269e2f
+---
+
+# 类别
+{: .no_toc }
+
+在仪表板上对表单进行分组。
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## categories 属性
+
+config.yaml 的顶层 `categories` 列表：
+
+{% include config_attribute.html name="categories" %}
+
+---
+
+## Category 对象
+
+`categories` 列表中的每一项：
+
+{% include config_object.html name="Category" %}
diff --git a/i18n/zh/_configure/config/constants.md b/i18n/zh/_configure/config/constants.md
new file mode 100644
index 0000000..e166849
--- /dev/null
+++ b/i18n/zh/_configure/config/constants.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: 常量
+parent: config.yaml
+nav_order: 3
+translated_from: 094e6c6c46990b88d06d0f6b1ae8e066b1912e57
+---
+
+# 常量
+{: .no_toc }
+
+所有表单都可以复用的自由对象。
+{: .fs-6 .fw-300 }
+
+---
+
+## constants 属性
+
+config.yaml 的顶层 `constants` 对象：
+
+{% include config_attribute.html name="constants" %}
diff --git a/i18n/zh/_configure/config/index.md b/i18n/zh/_configure/config/index.md
new file mode 100644
index 0000000..3969a69
--- /dev/null
+++ b/i18n/zh/_configure/config/index.md
@@ -0,0 +1,73 @@
+---
+layout: default
+title: config.yaml
+nav_order: 5
+has_children: true
+has_toc: false
+permalink: /config/
+translated_from: 6c0e2d282bc1dc386b7392e3af1f60fea593f12b
+---
+
+# config.yaml
+{: .no_toc }
+
+所有表单共用的类别、角色和常量
+{: .fs-6 .fw-300 }
+
+---
+
+面向管理员：config.yaml 文件保存所有表单共用的类别、角色和常量。
+
+AnsibleForms 使用 config.yaml 文件来配置类别、角色和常量。如果没有提供该文件，会生成一个包含最小配置的文件。也可以将配置导入数据库，这样就不再需要 config.yaml 文件。
+
+---
+
+## 概述
+
+config.yaml 文件包含 AnsibleForms 使用的类别、角色和常量的配置。
+
+**视频**：[创建您的第一个表单](https://www.youtube.com/watch?v=lIhYZ9Et5Ic)
+
+下面这个最小的 config.yaml 可以作为起点。它只包含必需的 `Default` 类别，以及必需的 `admin` 和 `default` 角色。
+
+```yaml
+categories: # a list of categories to group forms
+  - name: Default
+    icon: bars
+roles: # a list of roles
+  - name: admin
+    groups:
+      - local/admins
+  - name: default
+    groups: []
+    options:
+      allowJobRelaunch: true
+constants: {} # free objects to re-use over all forms
+```
+
+---
+
+## 配置加载优先级
+
+AnsibleForms 按以下顺序加载 config.yaml 文件（先匹配者优先）：
+
+1. **来自数据库**：导入到数据库中的配置，仅当 `ENABLE_CONFIG_IN_DATABASE=1` 时，或该
+   变量未设置且数据库中保存的配置来源为 `database` 时使用（空副本会回退到文件）
+2. **来自仓库（use_for_config）**：启用了“用于配置”开关的仓库（6.1.0 新增）
+3. **来自仓库（use_for_forms）**：启用了“用于表单”开关的仓库（为向后兼容而保留的回退）
+4. **来自本地文件**：本地 `config.yaml` 文件（CONFIG_PATH 环境变量）
+
+{: .warning }
+> **注意：** 只在一个仓库上启用“用于配置”。如果有多个仓库启用了它，会记录一条警告，并使用第一个。
+
+---
+
+## 本节内容
+
+该文件有三个顶层属性，每个属性都有自己的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [类别](categories.html) | 在仪表板上用带图标的类别树对表单进行分组 |
+| [角色](roles.html) | 将用户和组映射到角色，并设定每个角色可以做什么 |
+| [常量](constants.html) | 所有表单都可以复用的自由对象 |
diff --git a/i18n/zh/_configure/config/roles.md b/i18n/zh/_configure/config/roles.md
new file mode 100644
index 0000000..a87046d
--- /dev/null
+++ b/i18n/zh/_configure/config/roles.md
@@ -0,0 +1,125 @@
+---
+layout: default
+title: 角色
+parent: config.yaml
+nav_order: 2
+translated_from: c23a8fb9203e85e81cd128d2c129228c0a207f6c
+---
+
+# 角色
+{: .no_toc }
+
+将用户和组映射到角色，并设定每个角色可以做什么。
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## roles 属性
+
+config.yaml 的顶层 `roles` 列表：
+
+{% include config_attribute.html name="roles" %}
+
+---
+
+## default 角色
+
+每个已登录的用户都拥有 `default` 角色，因此 `roles: [default]` 的表单对所有能够登录的人开放。
+不存在匿名访问：不登录就无法获得该角色。
+
+该角色不包含任何组和用户，因为它已经适用于所有人。它的 `options` 是所有人的默认值，
+详见下文的 [角色选项](#role-options)。`config.yaml` 必须包含 `admin` 和 `default` 角色，
+角色页面会将两者都显示为 **必填**。
+
+在 7.0.0 之前，`default` 叫作 `public`，旧名称仍然有效：
+
+- **在表单中**，`roles: [public]` 仍然匹配所有用户，因此仓库中的表单无需修改。
+- **在 `config.yaml` 中**，名为 `public` 的角色会在加载配置时在文件中被重命名为 `default`。只修改名称，
+  修改前会先备份配置，保存在仓库中的配置随后会有一个待推送的更改。
+- **在 ytt 模板中**，模板不会被改写：它生成的配置会被重命名，日志中的一条警告会提示
+  您也在模板中重命名该角色。版本 8 将拒绝其中的 `public` 角色。
+
+同时包含 `default` 和 `public` 角色的配置会被拒绝，因为它们是同一个角色。
+
+---
+
+## Role 对象
+
+`roles` 列表中的每一项：
+
+{% include config_object.html name="Role" %}
+
+---
+
+## 角色选项
+
+角色的 `options` 为其成员打开或关闭各项功能。从 7.3.0 起，角色页面将它们分为四组显示，
+每个选项都有一个 (i)，说明它提供什么，其文字与个人资料的 **权限** 视图中显示的相同：
+
+| 选项 | 允许用户 | 默认值 |
+|---|---|---|
+| **设置** | | |
+| `showSettings` | 查看和修改所有设置页面；服务器日志和备份有各自的选项 | 仅管理员 |
+| `showAppearanceSettings` | 修改外观设置，但不能修改其他设置（从 7.3.0 起） | 关 |
+| `showConnectionsSettings` | 管理连接设置（凭据、运行器等），但不能修改其他设置（从 7.3.0 起） | 关 |
+| `showLogs` | 查看服务器日志 | 仅管理员 |
+| `showAuditLog` | 查看审计日志，但不能查看其他设置（从 7.3.0 起） | 仅管理员 |
+| `allowBackupOps` | 备份和恢复数据库 | 仅管理员 |
+| **设计器** | | |
+| `showDesigner` | 查看和使用设计器 | 仅管理员 |
+| `allowFormDesign` | 在设计器中编辑表单配置：类别、常量和表单。没有它则为只读（从 7.3.0 起） | 开 |
+| `allowPlaybookDesign` | 在设计器中编辑 playbook：保存、创建、删除和推送。没有它则为只读 | 开 |
+| `allowWorkflowDesign` | 在设计器中编辑工作流：保存、创建、删除和推送。没有它则为只读 | 开 |
+| `allowInventoryDesign` | 在设计器中编辑清单：保存、创建、删除和推送。没有它则为只读 | 开 |
+| `allowVarsFileDesign` | 在设计器中编辑变量文件：保存、创建、删除和推送。没有它则为只读 | 开 |
+| **作业** | | |
+| `showJobs` | 查看作业页面 | 开 |
+| `showAllJobLogs` | 查看所有用户的作业，而不仅是自己的 | 仅管理员 |
+| `manageAllJobs` | 中止、删除和重新运行所有用户的作业；删除和重新运行还需要下面的两个选项（从 7.3.0 起） | 仅管理员 |
+| `showExtravars` | 查看表单和作业的 extravars | 开 |
+| `showDebugButtons` | 查看表单上的调试按钮 | 开 |
+| `showArtifacts` | 查看作业的工件：AWX 作业返回的内容，或 playbook 用 `set_stats` 收集的内容 | 开 |
+| `allowVerboseMode` | 以详细模式运行作业 | 开 |
+| `allowJobRelaunch` | 使用之前某次运行的表单数据重新运行作业 | 仅管理员 |
+| `allowJobDeletion` | 删除作业：自己的作业，或在拥有 `manageAllJobs` 时删除所有用户的作业。没有它，作业历史将完整保留（从 7.3.0 起） | 开 |
+| `allowScheduledJobs` | 在 **调度** 页面创建和管理周期性及一次性调度（参见下方警告） | 仅管理员 |
+| `allowPlannedJobs` | 计划作业在设定的时间运行一次（**稍后运行**） | 开 |
+| `allowStoredJobs` | 保存表单的数据，之后再加载 | 开 |
+| **访问和集成** | | |
+| `allowLogin` | 登录 AnsibleForms | 开 |
+| `allowChat` | 使用 [聊天助手](../chat/)（在其启用时） | 开 |
+| `allowMcp` | 从 AI 代理使用 [MCP 服务器](../mcp/)（在其启用时） | 该角色的 `allowChat` |
+| `allowFileUploads` | 通过表单的文件字段上传文件（从 7.3.0 起） | 开 |
+| `allowApiTokens` | 为脚本创建 [API 令牌](../profile/api-token.html)，有效期最长为实例允许的上限（从 7.3.0 起） | 关 |
+| `extendedTokenExpiration` | 还可以创建永不过期的 API 令牌；需要 `allowApiTokens` | 关 |
+
+有些选项包含其他选项，角色页面会将被包含的选项显示为已打开并呈灰色：
+
+- **`showSettings`** 同时提供 `showAppearanceSettings`、`showConnectionsSettings` 和 `showAuditLog`。
+- **`manageAllJobs`** 同时提供 `showAllJobLogs`，因为要操作所有用户的作业就必须能看到它们。
+- **设计相关选项** 只有在拥有 `showDesigner` 时才有意义，`extendedTokenExpiration` 只有在拥有 `allowApiTokens` 时才有意义。
+
+在 7.2.0 及更早版本中，`showAllJobLogs` 还允许用户中止和删除其显示的作业；从 7.3.0 起，这需要 `manageAllJobs`。
+7.3.0 之前设置了 `extendedTokenExpiration` 但没有 `allowApiTokens` 的角色会获得 `allowApiTokens`，以便保留其令牌。
+
+**仅管理员** 表示对拥有 `admin` 角色的用户打开，对其他所有人关闭。当用户匹配多个角色时，
+选项按如下方式合并：
+
+- **在用户的各个角色之间**，只有当所有设置了该选项的角色意见一致时，选项才为打开：显式的 `false` 优先。
+- **`default` 角色** 补充用户其他角色都没有设置的选项，因此可以用它为所有人保存默认值。
+- **任何地方都没有设置的选项** 采用表中的默认值。
+
+`showExtraVars`（V 大写）可作为 `showExtravars` 的另一种写法；只要任一写法为 `false`，
+该选项就为关闭。
+
+{: .warning }
+> 请将 `allowScheduledJobs` 视为管理员级别的选项。调度不归创建它的用户所有：每个拥有
+> 该选项的用户都能看到并修改所有调度。调度还会以管理员权限运行任意表单，而不论创建者
+> 自身的访问权限如何。只将其授予您会像信任管理员一样信任的角色。
+
+{: .warning }
+> 在 `default` 角色上设置 `allowLogin: false`，会把其他角色没有设置 `allowLogin: true` 的所有用户都锁在外面，包括
+> 管理员。保存之前，请先在必须能够登录的角色上重新授予它。
diff --git a/i18n/zh/_configure/credentials.md b/i18n/zh/_configure/credentials.md
new file mode 100644
index 0000000..cc3e504
--- /dev/null
+++ b/i18n/zh/_configure/credentials.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: 凭据
+nav_order: 6
+has_children: true
+has_toc: false
+permalink: /credentials.html
+translated_from: 08110077a1cf59a4a52e078fc2ebc252f7cae48d
+---
+
+# 凭据
+{: .no_toc }
+
+保存表单、仓库、密钥库和通知通道用于连接的登录信息
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：添加 AnsibleForms 用于连接的用户、密码和令牌，它们以加密形式保存，或从密钥库读取。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [凭据类型](credentials/types.html) | 每种类型保存什么，以及可以在哪里选择 |
+| [凭据页面](credentials/list.html) | 凭据列表，以及添加凭据的对话框 |
+| [单个凭据的页面](credentials/credential-page.html) | 凭据的各个选项卡，以及哪些地方在使用它 |
+
+---
+
+## 工作原理
+
+**凭据** 是一个带名称的登录信息，在 **连接 > 凭据** 下添加。表单和其他管理对象按名称引用
+它，因此密码本身永远不会出现在表单中。其用户和密码要么保存在
+AnsibleForms 数据库中并用 `ENCRYPTION_SECRET` 加密，要么在每次使用凭据时从 [密钥库](secret-stores/)
+读取。
+
+---
+
+## 谁可以修改凭据
+
+从 7.3.0 起，连接或登录所依赖的凭据只能由管理员添加、修改或删除：
+
+| 凭据 | 原因 |
+|---|---|
+| 连接类型：`rte`、`awx`、`aap`、`ascender`、`semaphore`、`rundeck`、`jenkins`、`vault` 和 `cyberark` | 运行器或密钥库从中获取地址和密钥 |
+| 登录类型：`oidc`、`entraid` 和 `ldap` | SSO 提供商或 LDAP 目录用它让用户登录 |
+| 运行器引用的任何凭据 | 运行器用它登录，而修改运行器本身也需要管理员 |
+
+其他有权访问凭据的用户只能以只读方式查看这些凭据。能够把这类凭据指向另一台
+服务器的用户，将收到通过它发送的所有密钥，这就是该规则与运行器规则保持一致的原因。另有三条规则
+让这些用户无法接触到他们本来无法读取的密钥：
+
+- **引用受保护的凭据**：只有管理员才能在其他地方引用这些凭据，例如在仓库、
+  通知通道或聊天助手设置中。从密钥库读取密码的凭据也以同样方式
+  受到保护，无论其类型如何。
+- **选择密钥库**：只有管理员才能将凭据指向 [密钥库](secret-stores/)，或修改它读取的
+  密钥库或引用；其他用户仍可以将这些值原样提交，或者将它们全部清空。
+- **转移凭据**：当其他用户修改凭据的登录目标（主机、端口、颁发者、租户或
+  服务器地址）而没有重新输入密码时，保存的密码会被清除，它读取的密钥库
+  引用也会被清除，因此旧密钥永远不会发往新的目标。
+
+---
+
+## 正在使用的凭据
+
+仍被记录引用的凭据不能删除或重命名，否则这些记录将指向不存在的对象。
+拒绝消息会说明有多少条记录在使用它；[其页面](credentials/credential-page.html) 的 **使用者** 选项卡会列出这些记录。
+请先将它们指向另一个凭据，然后再删除或重命名该凭据。
diff --git a/i18n/zh/_configure/credentials/credential-page.md b/i18n/zh/_configure/credentials/credential-page.md
new file mode 100644
index 0000000..825a363
--- /dev/null
+++ b/i18n/zh/_configure/credentials/credential-page.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: 单个凭据的页面
+parent: 凭据
+nav_order: 3
+translated_from: 0269b5c0d313622bea6c910b96231f41ffd852d7
+---
+
+# 单个凭据的页面
+{: .no_toc }
+
+凭据的各个选项卡，以及哪些地方在使用它
+{: .fs-6 .fw-300 }
+
+凭据的页面将其对话框的各个步骤显示为选项卡，并额外显示哪些地方在使用它：
+
+| 选项卡 | 内容 |
+|---|---|
+| 详情 | 名称和描述。 |
+| 类型 | 凭据的用途。 |
+| 登录 | 其类型的所有字段，与对话框的 **登录** 步骤相同：用户、密码，以及登录目标（主机和端口、数据库、邮件服务器、目录的服务器、租户或颁发者、服务器地址及其 TLS）。CyberArk 凭据还包括 AppID、客户端证书和密钥。 |
+| 存储 | 数据库或密钥库，以及密钥库和引用。不适用于 CyberArk 和 HashiCorp Vault。 |
+| 使用者 | 引用此凭据的所有对象：密钥库、通知通道、仓库、LDAP 目录、SSO 提供商、运行器、聊天助手、表单以及设计器中的工作流。点击某一行即可打开它。 |
+
+密码在 **登录** 选项卡中输入，保存后永远不会再显示：留空则保留已保存的密码。对于 CyberArk
+凭据，将客户端密钥留空即可保留已保存的密钥。右上角有 **测试连接**（仅限数据库凭据）、
+**删除** 和 **保存**。
+
+从 7.3.0 起，只要 **使用者** 中列有任何内容，**删除** 和改名都会被拒绝，参见 [正在使用的凭据](../credentials.html#credentials-in-use)。
+
+在 [配置种子](../seed/) 中声明的凭据在此页面上为只读：请改为在种子文件中修改。
diff --git a/i18n/zh/_configure/credentials/list.md b/i18n/zh/_configure/credentials/list.md
new file mode 100644
index 0000000..4ebd586
--- /dev/null
+++ b/i18n/zh/_configure/credentials/list.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 凭据页面
+parent: 凭据
+nav_order: 2
+translated_from: 986d768c15d0b91bdc3760026bd904d3f89ff3e0
+---
+
+# 凭据页面
+{: .no_toc }
+
+凭据列表，以及添加凭据的对话框
+{: .fs-6 .fw-300 }
+
+**连接 > 凭据** 下的页面列出所有凭据，包括其 **名称**、**类型**、**描述** 和 **使用者**，即
+引用它的记录、表单和工作流的数量（参见 [正在使用的凭据](../credentials.html#credentials-in-use)）。
+
+**添加凭据** 会打开一个分步对话框：
+
+| 步骤 | 字段 |
+|---|---|
+| 凭据 | 名称和描述，均为必填。 |
+| 类型 | 18 种类型之一，见下文。 |
+| 登录 | 该类型用什么登录以及登录到哪里，见下文。 |
+| 存储 | 用户和密码的保存位置：**数据库**（加密保存在 AnsibleForms 数据库中）或 **密钥库**，并指定密钥库及其中的 **引用**。不适用于 CyberArk 和 HashiCorp Vault，因为密钥库本身用它们登录。 |
+
+**类型** 步骤按名称列出各种类型：AAP、API、Ascender、AWX、CyberArk、数据库、Git、HashiCorp Vault、Jenkins、LDAP、
+Microsoft Entra ID、Open ID、RTE、Rundeck、Semaphore、SMTP、SSH，以及用户名和密码（参见 [凭据类型](types.html)）。
+
+**登录** 步骤包含该类型的所有字段，包括地址；没有单独的连接步骤：
+
+| 类型 | 登录步骤的字段 |
+|---|---|
+| 除 CyberArk 外的所有类型 | 密码，或代替密码的内容：LDAP 的绑定密码、Entra ID 和 Open ID 的客户端密钥、HashiCorp Vault 的令牌、RTE 令牌、Semaphore、Rundeck 和 Jenkins 的 API 令牌，以及 AWX、AAP 和 Ascender 的令牌或密码 |
+| 除 HashiCorp Vault、RTE、Semaphore 和 Rundeck 外的所有类型 | 用户：CyberArk 的 AppID、LDAP 的绑定 DN、Entra ID 和 Open ID 的客户端 ID；对于 AWX、AAP 和 Ascender 为可选 |
+| SSH、数据库 | **主机** 和 **端口**；数据库还包括 **数据库类型** 和 **数据库** |
+| SMTP | **邮件服务器**（必填）、其 **端口** 和 **使用 TLS** |
+| LDAP | 目录的 **服务器**（必填）、其 **端口** 和 **启用 TLS**；启用 TLS 时还有 **忽略证书**、**CA 证书包** 和 **客户端证书** |
+| Microsoft Entra ID | **租户 ID**（必填）和 **重定向 URI** |
+| Open ID | **颁发者**（必填）和 **重定向 URI** |
+| HashiCorp Vault、CyberArk、RTE、AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins | **服务器**，即其登录的地址，必填，另有 **跳过证书验证** 和 **CA 证书包** |
+| CyberArk | **客户端证书** 和 **客户端密钥** |
+
+点击某一行会打开该凭据自己的页面。其菜单提供 **编辑**、**测试连接**（仅限数据库凭据）和 **删除**。
+密码在凭据页面的 **登录** 选项卡中修改。
diff --git a/i18n/zh/_configure/credentials/types.md b/i18n/zh/_configure/credentials/types.md
new file mode 100644
index 0000000..8c929df
--- /dev/null
+++ b/i18n/zh/_configure/credentials/types.md
@@ -0,0 +1,65 @@
+---
+layout: default
+title: 凭据类型
+parent: 凭据
+nav_order: 1
+translated_from: 1f21f8fc1ae73953922d8c9f21de6db05b3b1a87
+---
+
+# 凭据类型
+{: .no_toc }
+
+每种类型保存什么，以及可以在哪里选择
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 类型
+
+类型表示凭据的用途。它决定对话框要求填写哪些字段，以及可以在哪里选择该凭据：
+
+| 类型 | 保存的内容 | 使用者 |
+|---|---|---|
+| 用户名和密码 | 用于任何登录的用户和密码：使用基本认证的 REST API、某个服务等。默认类型 | Playbook，通过表单的 `credentials` 或凭据字段；[REST 表达式](../expressions/credentials.html) |
+| SSH | 用于 SSH 连接服务器的用户和密码，以及主机和端口 | Playbook，通过表单的 `credentials`、`ansibleCredentials` 或凭据字段，以及工作流节点的登录 |
+| Git | 用于 git 仓库的用户名和密码或令牌 | [仓库](../repositories/authentication.html) |
+| API | 用于 REST API 的用户名和密码或令牌 | [REST 表达式](../expressions/credentials.html)、Telegram 机器人令牌、webhook 的 bearer 令牌、聊天助手的 API 密钥 |
+| 数据库 | 数据库登录，包括其类型、主机、端口和数据库名称 | 表单查询（`dbConfig`）和 `fnCredentials`；可以测试 |
+| CyberArk | CyberArk Central Credential Provider（CCP）的地址及其 TLS，以及 CyberArk 密钥库登录所用的 AppID、客户端证书和密钥 | [CyberArk](../secret-stores/cyberark.html) 密钥库 |
+| SMTP | 邮件服务器、其端口和 TLS，以及登录信息（中继无需） | 邮件 [通知通道](../notification-channels.html) |
+| LDAP | 目录的服务器、端口、TLS 和证书，以及绑定 DN 和密码 | [LDAP 目录](../authentication/ldap.html) |
+| Microsoft Entra ID | 提供商的应用注册：租户 ID、客户端 ID、客户端密钥和重定向 URI | [Entra ID 提供商](../authentication/entra-id.html) |
+| Open ID | 提供商的客户端：颁发者、客户端 ID、客户端密钥和重定向 URI | [OIDC 提供商](../authentication/oidc.html) |
+| RTE | RTE 的令牌（`RTE_TOKEN`）和地址 | RTE [运行器](../runners.html) |
+| AWX、AAP、Ascender | 该平台的令牌或登录信息，以及地址 | 该类型的运行器 |
+| Semaphore、Rundeck | 该产品的 API 令牌和地址 | 该类型的运行器 |
+| Jenkins | Jenkins 的用户、其 API 令牌和地址 | Jenkins 运行器 |
+| HashiCorp Vault | Vault 密钥库登录所用的令牌和地址 | [HashiCorp Vault](../secret-stores/hashicorp-vault.html) 密钥库 |
+
+数据库凭据的类型可以是 MySQL、MSSQL、PostgreSQL、Oracle 或 MongoDB。
+
+在 API 和 [配置种子](../seed/) 中，类型为 `userpass`、`ssh`、`git`、`api`、`database`、`cyberark`、`smtp`、
+`ldap`、`entraid`、`oidc`、`rte`、`awx`、`aap`、`ascender`、`semaphore`、`rundeck`、`jenkins` 和 `vault`。从 6 升级时，
+每个凭据都会获得类型 `userpass`，数据库凭据则为 `database`：表单会像在 6 中一样使用它。对于工作流节点的 playbook
+用于连接的登录，请将其改为 SSH；对于 REST API，请改为 API。
+
+---
+
+## 凭据中的地址
+
+从 7.3.0 起，只在一台服务器上有效的登录会携带该服务器，因此使用它的记录只需引用凭据：
+
+| 记录 | 移入其凭据的内容 |
+|---|---|
+| LDAP 目录 | 其服务器、端口、TLS、证书和绑定账户，移入名为 `<directory>-ldap` 的 `ldap` 凭据 |
+| SSO 提供商 | 其客户端 ID 和密钥、租户或颁发者，以及重定向 URI，移入名为 `<provider>-sso` 的 `entraid` 或 `oidc` 凭据 |
+| 运行器 | 其地址和 TLS，以及令牌或登录信息，移入其类型的凭据，名为 `<runner>-token` 或 `<runner>-login` |
+| 密钥库 | 其地址和 TLS，以及令牌（`<store>-token`）或 CyberArk AppID 和证书（`<store>-appid`） |
+| 邮件通道 | 其服务器、端口和 TLS，移入其 `smtp` 凭据，或名为 `<channel>-smtp` 的新凭据 |
+
+升级到 7.3.0 时只执行一次这些迁移。已经引用凭据的记录会保留该凭据；如果另一条记录以另一台服务器
+使用了相同的登录，则会获得该凭据的一个副本。在 [配置种子](../seed/) 中声明的记录保持种子中的原样。
+连接和登录所用的凭据只能由管理员修改，参见 [谁可以修改凭据](../credentials.html#who-may-change-a-credential)。
diff --git a/i18n/zh/_configure/customization/configuration.md b/i18n/zh/_configure/customization/configuration.md
new file mode 100644
index 0000000..a213f31
--- /dev/null
+++ b/i18n/zh/_configure/customization/configuration.md
@@ -0,0 +1,62 @@
+---
+layout: default
+title: 配置
+parent: 环境变量
+nav_order: 5
+translated_from: f460336cad995f3fd6cb5a2e4667e4c1a3b67a2b
+---
+
+# 配置
+{: .no_toc }
+
+配置种子、配置的保存位置、git 和 ytt
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以决定配置的来源：配置种子、数据库、git 或 ytt 模板。
+
+---
+
+## 示例
+
+应用一个挂载的配置种子，每五分钟检查一次，并将 `config.yaml` 保存在数据库中。在 `docker-compose.yml` 中：
+
+```yaml
+    environment:
+      - CONFIG_SEED_PATH=/seed/seed.yaml
+      - CONFIG_SEED_RELOAD_SECONDS=300
+      - ENABLE_CONFIG_IN_DATABASE=1
+      - ALLOW_ENV_EDIT=0              # the environment is declared here, not on the settings pages
+    volumes:
+      - ./seed:/seed:ro
+```
+
+无效的种子会导致服务器无法启动。文件格式参见 [配置种子](../seed/)。
+
+---
+
+## config.yaml 的读取位置
+
+类别、角色和常量来自磁盘上的 `config.yaml` 或其在数据库中的副本，按以下顺序决定：
+
+1. [`ENABLE_CONFIG_IN_DATABASE`](#env_ENABLE_CONFIG_IN_DATABASE)，当它在环境中或在设置页面的
+   **配置** 选项卡中设置时：`1` 读取数据库，`0` 读取文件。
+2. 否则，使用数据库中保存的配置来源（`file` 或 `database`），即 6.3.0 之前搭建的实例
+   在设置页面上所作的选择。
+3. 否则，使用文件：启用了 **用于配置** 的仓库中的 `config.yaml`；没有时使用启用了
+   **用于表单** 的仓库中的；再没有时使用 [`CONFIG_PATH`](paths.html#env_CONFIG_PATH) 处的文件。
+
+显式设置的 `ENABLE_CONFIG_IN_DATABASE` 始终优先，即使是 `0` 也优先于保存的 `database`。每次加载
+配置时都会读取它，因此更改无需重启即可生效。**状态** 页面的 **信息** 选项卡显示正在使用的来源。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="configuration" %}
diff --git a/i18n/zh/_configure/customization/features.md b/i18n/zh/_configure/customization/features.md
new file mode 100644
index 0000000..455eac3
--- /dev/null
+++ b/i18n/zh/_configure/customization/features.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 功能
+parent: 环境变量
+nav_order: 4
+translated_from: dbd2d865ae9b177e389409777bdfffc8f199f9da
+---
+
+# 功能
+{: .no_toc }
+
+设计器、MCP、聊天、启动验证、作业列表、指标、AWX API 和查询日志
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以打开或关闭应用的可选部分。
+
+---
+
+## 示例
+
+为 AI 代理提供 MCP 服务器，并在每次启动时强制执行表单验证规则。在 compose 项目的 `.env` 中：
+
+```bash
+ENABLE_MCP=1
+LAUNCH_VALIDATION=enforce
+```
+
+`ENABLE_MCP` 和 `ENABLE_CHAT` 无需重启即可生效：每次请求时都会读取它们，因此可以在
+设置页面上打开它们。其中一个关闭时，其端点（`/api/v2/mcp` 或 `/api/v2/chat`）会返回 `404`。
+
+请先以 `LAUNCH_VALIDATION=log` 运行一段时间：它会记录 `enforce` 将会拒绝的内容，但不会真正拒绝。参见 [MCP](../mcp/)
+和 [记录与强制](../launch-validation/log-and-enforce.html)。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="features" %}
diff --git a/i18n/zh/_configure/customization/index.md b/i18n/zh/_configure/customization/index.md
new file mode 100644
index 0000000..981d122
--- /dev/null
+++ b/i18n/zh/_configure/customization/index.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: 环境变量
+nav_order: 8
+has_children: true
+has_toc: false
+permalink: /customization/
+translated_from: fd6e83f3550f59aa576c8addaf28bfa6115b96a0
+---
+
+# 环境变量
+{: .no_toc }
+
+使用环境变量配置 AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+面向部署 AnsibleForms 的管理员：服务器读取的环境变量，按主题分组。
+
+无论 AnsibleForms 是用 Docker Compose 运行、在 Kubernetes 上运行还是从源码运行，都通过环境变量进行调整。
+
+---
+
+## 值的来源
+
+服务器从以下来源中第一个设置了该变量的来源读取每个变量，因此列表中位置靠前的值始终优先：
+
+1. **进程环境**：docker-compose 中的 `environment:` 和 `env_file:`（项目的 `.env` 就是这样传入的），
+   Kubernetes 上的 `env` 和 `envFrom`，或者启动 `node` 的 shell。
+2. **`persistent/.env`**，即设置页面写入的文件（在 docker-compose 项目中为 `data/.env`，使用
+   `MANAGED_ENV_PATH` 时为其他路径）。每次启动时都会读取，生产环境中也是如此，并且它永远不会覆盖已经设置的变量。
+3. **`server/.env.<NODE_ENV>`**，例如 `.env.development`。仅当 `NODE_ENV` 不是 `production` 时（或设置了
+   `FORCE_DOTENV=1` 时）读取，实际上就是在开发模式下 [从源码](../installation/from-source.html) 运行时。
+4. **内置默认值**，显示在每组的表格中。
+
+**设置 > 常规** 下的设置页面显示当前生效的值，并将更改保存到 `persistent/.env`。许多变量
+保存后立即生效；其他变量会被保存但需要重启，页面会在保存后列出它们。在进程环境中设置的变量
+无法在那里修改：页面会将其显示为 *已在环境变量中设置，因此无法在此处更改。*
+少数变量，例如 `ENCRYPTION_SECRET` 和 `ACCESS_TOKEN_SECRET`，永远无法通过页面修改。
+
+RTE 读取的变量，例如 `AF_ROLE`、`RTE_MODE`、`APP_URL` 或 `RTE_MAX_JOBS`，根本不在设置页面上：
+应用不使用它们，因此请在 RTE 运行的环境中设置。应用本身读取的 `RTE_*` 变量，
+即 `RTE_QUEUE_MINUTES` 和 `RTE_FILES_MAX_MB`，是例外，仍保留在页面上。`RTE_MAX_JOBS`、
+`RTE_CACHE_MB`、`RTE_FILES` 和 `RTE_DRAIN_SECONDS` 这四个 RTE 变量也可以改为在每个 RTE 的运行器页面上设置，那里的值优先于
+变量（参见 [RTE 的设置](../runners/runner-page.html#an-rtes-settings)）。
+
+当 [`ALLOW_ENV_EDIT`](configuration.html#env_ALLOW_ENV_EDIT)`=0` 时，页面只显示值，保存会被拒绝。当
+环境在清单中声明时请使用它，详见 [编辑与审计](../seed/environment-and-audit.html)。
+
+[配置种子](../seed/) 不设置任何环境变量。它声明保存在数据库中的对象，其中的
+`${ENV_VAR}` 引用会从正在运行的服务器的环境中解析。
+
+有几个变量只从环境中读取，不在表格中：上文介绍的 `MANAGED_ENV_PATH` 和 `FORCE_DOTENV`，
+以及系统代理变量 `HTTPS_PROXY` 和 `NO_PROXY`（也会读取小写形式）。出站 RTE 通过
+`HTTPS_PROXY` 连接应用，入站 RTE 也通过它发送注册请求，除非应用的主机在 `NO_PROXY` 中（主机名、
+`.domain` 后缀，或表示所有主机的 `*`）。
+
+标记为 <span class="af-badge af-badge-secret">机密</span> 的变量保存密码、令牌或密钥：请不要将它们纳入版本
+控制，例如放在 Kubernetes Secret 或不提交的 `.env` 文件中。
+
+---
+
+## 本节内容
+
+这些变量按主题分组，每组一个页面：
+
+| 页面 | 内容 |
+|---|---|
+{% for g in site.data.env_groups %}| [{{ g.title }}]({{ g.slug }}.html) | {{ g.lead | slice: 0 | upcase }}{{ g.lead | slice: 1, 500 }} |
+{% endfor %}
+{% capture other %}{% include env_vars_table.html rest=true %}{% endcapture %}
+{% if other contains "<tr>" %}
+---
+
+## 其他变量
+
+以下变量尚未归入任何组：
+
+{{ other }}
+{% endif %}
diff --git a/i18n/zh/_configure/customization/logging.md b/i18n/zh/_configure/customization/logging.md
new file mode 100644
index 0000000..51b471a
--- /dev/null
+++ b/i18n/zh/_configure/customization/logging.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: 日志
+parent: 环境变量
+nav_order: 7
+translated_from: 81439c2c8adc69d31191b0a07cd9e444ff5fb2be
+---
+
+# 日志
+{: .no_toc }
+
+日志级别、文件、syslog 和控制台颜色
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以调整日志的详细程度、日志文件的位置，或以您自己的时区显示时间戳。
+
+---
+
+## 示例
+
+在文件中记录比控制台更多的日志，并以阿姆斯特丹时间显示日志和作业的时间戳。
+在 compose 项目的 `.env` 中：
+
+```bash
+LOG_LEVEL=info
+LOG_CONSOLE_LEVEL=notice
+LOG_TZ=Europe/Amsterdam
+```
+
+---
+
+## Syslog
+
+Syslog 服务器不再在这里配置：请在 **设置 > 连接 > Syslog** 下添加，参见 [日志](../production/logs.html#syslog)。
+下面的 `LOG_SYSLOG_*` 变量自 7 起已弃用。首次启动时如果发现设置了 `LOG_SYSLOG_HOST`，会将它们一次性
+导入为 syslog 服务器 `syslog`，用于接收服务器日志，此后便忽略这些变量。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="logging" %}
diff --git a/i18n/zh/_configure/customization/paths.md b/i18n/zh/_configure/customization/paths.md
new file mode 100644
index 0000000..2a14bf7
--- /dev/null
+++ b/i18n/zh/_configure/customization/paths.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 路径
+parent: 环境变量
+nav_order: 2
+translated_from: 232fd91a41c511e9f46867101d74d2313dc7ee3c
+---
+
+# 路径
+{: .no_toc }
+
+配置、表单、playbook、上传文件和备份的存放位置
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以将部分数据保存在另一个卷上，例如将备份和上传文件放在更大或更便宜的存储上。
+
+---
+
+## 示例
+
+备份和上传的文件放在单独的卷上，其余数据放在常用的持久化文件夹中。在 `docker-compose.yml` 中：
+
+```yaml
+    environment:
+      - BACKUP_PATH=/data/backups
+      - FORMS_BACKUP_PATH=/data/forms_backups
+      - UPLOAD_PATH=/data/uploads
+    volumes:
+      - /srv/ansibleforms-data:/data
+```
+
+新路径只对新文件生效：旧文件夹中已有的内容不会被移动，请自行复制过去。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="paths" %}
diff --git a/i18n/zh/_configure/customization/retention.md b/i18n/zh/_configure/customization/retention.md
new file mode 100644
index 0000000..c26072f
--- /dev/null
+++ b/i18n/zh/_configure/customization/retention.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: 备份与保留
+parent: 环境变量
+nav_order: 3
+translated_from: 76f81cfa15eaa98199a3d5963f7adc9a6f8b01dc
+---
+
+# 备份与保留
+{: .no_toc }
+
+备份命令，以及备份、作业和审计记录的保留时长
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以控制数据库保留多少历史记录，以及磁盘上保留多少个备份。
+
+---
+
+## 示例
+
+已完成的作业保留 90 天，审计记录保留两年。在 compose 项目的 `.env` 中：
+
+```bash
+JOB_RETENTION_DAYS=90
+AUDIT_RETENTION_DAYS=730
+```
+
+每日任务会在凌晨 2:30 删除早于此期限的已完成作业，在凌晨 3:30 删除审计条目。正在运行的作业或等待
+批准的作业永远不会被删除。在设置页面上修改这两个变量后，无需重启即可生效。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="retention" %}
diff --git a/i18n/zh/_configure/customization/security.md b/i18n/zh/_configure/customization/security.md
new file mode 100644
index 0000000..850d283
--- /dev/null
+++ b/i18n/zh/_configure/customization/security.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: 安全变量
+parent: 环境变量
+nav_order: 6
+translated_from: af00832e0e69ea667004fbe5ebe635dd70ff3684
+---
+
+# 安全变量
+{: .no_toc }
+
+令牌、加密、出站 REST 主机、掩码以及旧的 VAULT_* 设置
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+修改这些变量，以设置您自己的令牌和加密密钥，并限制表单可以调用和显示的内容。
+
+---
+
+## 示例
+
+使用您自己的密钥，将 REST 调用限制在一个 API 和一个内部网络，并多掩码一个键。在 compose 项目的 `.env` 中：
+
+```bash
+ACCESS_TOKEN_SECRET=change-me-to-a-long-random-string
+ENCRYPTION_SECRET=change-me-to-32-random-characters
+REST_ALLOWED_HOSTS=api.example.com,10.20.0.0/16
+MASK_EXTRAVARS_REGEX=password|secret|token|apikey
+```
+
+请在保存第一个凭据之前设置 `ENCRYPTION_SECRET`。从 7.3.0 起，设置或修改它会在下次启动时重新加密所有已保存的
+密钥；如果旧密钥是您自己设置的，则用 `ENCRYPTION_SECRET_PREVIOUS` 指定旧密钥，参见
+[更改加密密钥](../security/secrets.html#changing-the-encryption-secret)。
+
+---
+
+## REST 调用和 jq
+
+从 7.3.0 起，REST 辅助函数（`fn.fnRestBasic`、`fn.fnRestAdvanced`、`fn.fnRestJwt`、`fn.fnRestJwtSecure`）会像其他所有连接一样
+检查所调用端点的证书；在 7.2.0 及更早版本中，它们从不检查。有三项设置适用于它们：
+
+| 变量 | 默认值 | 作用 |
+|---|---|---|
+| [`REST_IGNORE_CERTS`](#env_REST_IGNORE_CERTS) | `0` | `1` 跳过证书检查：仅用于使用自签名证书的端点 |
+| [`REST_TIMEOUT_SECONDS`](#env_REST_TIMEOUT_SECONDS) | `60` | REST 调用在因超时失败之前等待应答的时长 |
+| [`JQ_TIMEOUT_SECONDS`](#env_JQ_TIMEOUT_SECONDS) | `30` | jq 过滤器在被停止之前可以运行的时长；jq 输出的上限也为 64 MB |
+
+这三项保存后即生效，无需重启。对于证书由私有 CA 签发的端点，请保持检查开启，
+改为让 Node.js 信任该 CA：在应用的环境中将 `NODE_EXTRA_CA_CERTS` 设为包含该 CA 的 PEM 文件，然后重启应用。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="security" %}
diff --git a/i18n/zh/_configure/customization/server.md b/i18n/zh/_configure/customization/server.md
new file mode 100644
index 0000000..7b8732b
--- /dev/null
+++ b/i18n/zh/_configure/customization/server.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: 服务器与数据库
+parent: 环境变量
+nav_order: 1
+translated_from: 0e4bba71dd8dd8efdf5ed7ff9c9644b1c0a89185
+---
+
+# 服务器与数据库
+{: .no_toc }
+
+Web 服务器、MySQL 连接、管理员账户，以及每个进程运行的内容（AF_ROLE 和 RTE_* 变量）
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+当应用运行在反向代理之后、使用其他端口，或连接 compose 项目之外的数据库时，修改这些变量。
+
+---
+
+## 示例
+
+位于终止 TLS 的反向代理之后，路径为 `/ansibleforms`，使用外部 MySQL。在 `docker-compose.yml` 中：
+
+```yaml
+    environment:
+      - BASE_URL=/ansibleforms        # the proxy forwards /ansibleforms/ unchanged
+      - HTTPS=0                       # the proxy terminates TLS
+      - PORT=8000
+      - DB_HOST=mysql.example.com
+      - DB_PORT=3306
+      - DB_USER=ansibleforms
+      - DB_PASSWORD=change-me
+```
+
+这些行替换 compose 文件中该处已有的 `DB_*` 和 `PORT` 行，它们优先于 `.env` 中的同名变量。请删除
+`mysqldb` 服务以及等待它的 `depends_on`，并在 `ports` 中映射 8000 端口。代理端的配置见
+[反向代理](../production/reverse-proxy.html) 页面。
+
+---
+
+## 变量
+
+本组的所有变量，包括其类型、默认值和描述：
+
+{% include env_vars_table.html group="server" %}
diff --git a/i18n/zh/_configure/disclaimer.md b/i18n/zh/_configure/disclaimer.md
new file mode 100644
index 0000000..d93e1a8
--- /dev/null
+++ b/i18n/zh/_configure/disclaimer.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: 免责声明
+nav_order: 7
+has_children: true
+has_toc: false
+permalink: /disclaimer.html
+translated_from: a22b56db001904583c51e6bd28f1281737f32a32
+---
+
+# 免责声明
+{: .no_toc }
+
+每位用户在使用应用前需接受一次的条款，并记录谁在何时接受了哪个版本
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：在 **设置 > 访问 > 免责声明** 中要求每位用户接受使用条款，需要 `showSettings` 角色选项。
+
+从 7.3.0 起，该页面列出免责声明的所有版本，每个版本都在自己的页面中打开，并附带其接受记录。
+在 7.2 及更早版本中，该页面改为三个选项卡（**常规**、**版本** 和 **接受记录**）；升级会保留所有版本。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [常规](disclaimer/general.html) | 版本列表、添加版本，以及启用用户需要接受的版本 |
+| [版本](disclaimer/versions.html) | 版本的页面，以及作为更正或要求所有人重新接受而修改其正文 |
+| [接受记录](disclaimer/acceptances.html) | 谁接受了哪个版本，以及请选定的用户再次接受 |
+
+
+---
+
+## 用户看到的内容
+
+启用某个版本后，每位登录的用户（包括管理员）都会先在一个对话框中看到它，然后才能进行其他操作：
+
+1. 他们阅读其标题和正文。
+2. 他们勾选复选框，然后点击 **接受**。红色的 **拒绝** 则会让他们退出登录。
+
+从 7.3.0 起，在用户作出回应之前，对话框后面的页面会被模糊处理。
+
+用户对每个版本只需接受一次：下次登录时不会再被询问，只有在出现新版本、
+管理员以 [再次请所有人接受](disclaimer/versions.html#changing-the-text) 保存修改后的正文，或者管理员对其接受记录使用
+[再次请求](disclaimer/acceptances.html#asking-users-again) 时，才会再次询问。
+
+在他们接受之前，API 对其会话的每个调用都返回状态 `403` 和代码 `disclaimer_required`，
+但 `/api/v2/disclaimer` 和 `/api/v2/profile` 下的调用以及浏览器订阅的实时事件除外。
+[API 令牌](profile/api-token.html) 永远不会被询问，因为脚本背后没有人可以点击。
+
diff --git a/i18n/zh/_configure/disclaimer/acceptances.md b/i18n/zh/_configure/disclaimer/acceptances.md
new file mode 100644
index 0000000..0e821ea
--- /dev/null
+++ b/i18n/zh/_configure/disclaimer/acceptances.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 接受记录
+parent: 免责声明
+nav_order: 3
+translated_from: 952000db809a111ac98ba2850a5eb8b31e7a96f5
+---
+
+# 接受记录
+{: .no_toc }
+
+谁接受了哪个版本，以及请选定的用户再次接受
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 谁接受了
+
+每次接受都会按用户和版本记录下来，版本页面的 **接受记录** 选项卡会列出它们，最新的在前：
+
+| 列 | 含义 |
+|---|---|
+| **用户** | 用户名 |
+| **登录方式** | 他们的登录方式：本地、LDAP、Microsoft Entra ID 或 OpenID Connect |
+| **接受时间** | 接受的时间 |
+| **IP 地址** | 来源地址 |
+| **浏览器** | 他们的浏览器 |
+
+---
+
+## 请用户再次接受
+
+从 7.3.0 起，可以只请选定的用户再次接受某个版本，而无需请所有人重新接受。
+
+在行菜单中，或对列表中勾选的行使用 **再次请求**，确认后会清除这些接受记录：这些用户会在下一次请求时再次看到
+免责声明，无需重新登录。与所有表格一样，该列表也可以导出。
+
+[审计日志](../production/logs.html#audit-trail) 还会记录每次接受、每次拒绝以及免责声明的每次更改。
diff --git a/i18n/zh/_configure/disclaimer/general.md b/i18n/zh/_configure/disclaimer/general.md
new file mode 100644
index 0000000..359058b
--- /dev/null
+++ b/i18n/zh/_configure/disclaimer/general.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 常规
+parent: 免责声明
+nav_order: 1
+translated_from: 5545e95acf978130082fcb459c917894e7a5286a
+---
+
+# 常规
+{: .no_toc }
+
+版本列表、添加版本，以及启用用户需要接受的版本
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 列表
+
+从 7.3.0 起，**设置 > 访问 > 免责声明** 是免责声明各个版本的列表，每个版本对应一份被接受时的正文：
+
+| 列 | 含义 |
+|---|---|
+| **已启用** | 是否为用户需要接受的版本；最多只有一个版本处于启用状态 |
+| **版本** | 版本号，从 1 开始递增 |
+| **标题** | 其对话框的标题 |
+| **发布者** | 添加它的人 |
+| **发布时间** | 添加的时间 |
+| **接受记录** | 有多少用户接受了它 |
+
+点击某一行，或行菜单中的 **编辑**，会打开 [版本的页面](versions.html)。菜单中还有 **启用** 或 **禁用**，以及 **删除**。
+
+---
+
+## 添加版本
+
+**添加免责声明** 会打开一个对话框来创建新版本，使用下一个版本号；在您启用它之前，它不会处于启用状态：
+
+| 字段 | 含义 |
+|---|---|
+| **标题** | 对话框的标题，例如使用条款 |
+| **正文** | 用户同意的内容，最多 20000 个字符。纯文本：保留换行。 |
+| **复选框** | 用户在接受前勾选的内容，初始为“我已阅读并同意这些条款。” |
+
+三者均为必填。在此之前启用的版本仍然是用户需要接受的版本，因此可以提前准备新的正文。
+
+---
+
+## 启用版本
+
+在行菜单中点击 **启用**，或打开版本页面上的 **已启用** 开关，会使该版本成为用户需要接受的版本，并关闭
+其他版本。
+
+已经接受过该版本的用户不会被再次询问，因此可以重新启用较早的版本，而无需请所有人重新接受。
+对已启用的版本点击 **禁用**，会关闭免责声明，直到再次启用某个版本；版本和接受记录都会保留。
+删除某个版本也会删除其接受记录，删除已启用的版本则会关闭免责声明。
diff --git a/i18n/zh/_configure/disclaimer/versions.md b/i18n/zh/_configure/disclaimer/versions.md
new file mode 100644
index 0000000..bfd28d8
--- /dev/null
+++ b/i18n/zh/_configure/disclaimer/versions.md
@@ -0,0 +1,43 @@
+---
+layout: default
+title: 版本
+parent: 免责声明
+nav_order: 2
+translated_from: dcab4535a8f7e4aeaff321136564ab14d61dc3fa
+---
+
+# 版本
+{: .no_toc }
+
+版本的页面，以及作为更正或要求所有人重新接受而修改其正文
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 版本的页面
+
+从 7.3.0 起，每个版本都有自己的页面 `/settings/disclaimer/<version>`，包含两个选项卡：
+
+| 选项卡 | 内容 |
+|---|---|
+| **详情** | 标题、正文和复选框文字，以及会立即保存的 **已启用** 开关 |
+| **接受记录** | 谁接受了这个版本，参见 [接受记录](acceptances.html) |
+
+**预览** 按用户将看到的样子显示对话框，**删除** 则删除该版本及其接受记录。选项卡上方的搜索框
+会同时搜索两者：**详情** 下匹配的字段和 **接受记录** 下匹配的行。
+
+---
+
+## 修改正文
+
+对用户已经接受过的标题、正文或复选框文字进行修改后点击 **保存**，会询问 **再次请所有人接受？**：
+
+| 回答 | 结果 |
+|---|---|
+| **再次请所有人接受** | 清除该版本的接受记录，每位用户在下一次请求时都需要再次接受 |
+| **保留为更正** | 改写正文（例如修正错别字），接受记录仍然有效：不会再询问任何人 |
+
+尚无人接受的版本会直接保存，不会询问。要保留已被接受的正文，请 [添加一个新版本](general.html#adding-a-version) 并启用它。
diff --git a/i18n/zh/_configure/notification-channels.md b/i18n/zh/_configure/notification-channels.md
new file mode 100644
index 0000000..df038d1
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: 通知通道
+nav_order: 9
+has_children: true
+has_toc: false
+permalink: /notification-channels.html
+translated_from: 1488a67f6f281b0236e4bad3a8b3d0c3bb32326c
+---
+
+# 通知通道
+{: .no_toc }
+
+通过邮件、Slack、Microsoft Teams、Telegram 或任意 webhook 发送审批请求和作业通知
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：添加表单用于发送通知和审批的邮件服务器和聊天通道。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [邮件](notification-channels/mail.html) | SMTP 服务器、默认服务器及其登录信息 |
+| [Slack 和 Microsoft Teams](notification-channels/slack-and-teams.html) | Slack 或 Teams 的频道 webhook |
+| [Telegram](notification-channels/telegram.html) | 在 Telegram 聊天中发言的机器人 |
+| [Webhook](notification-channels/webhook.html) | 发往任意 HTTP 端点的 JSON 请求 |
+| [在表单中使用通道](notification-channels/in-a-form.html) | 在通知和审批中引用通道 |
+| [测试通道](notification-channels/testing.html) | 发送测试，以及它能证明什么 |
+
+
+---
+
+## 工作原理
+
+**通知通道** 是通知的去处，在 **连接 > 通知** 下添加。每个通道都属于
+以下类型之一：
+
+| 类型 | 发送的内容 |
+|---|---|
+| 邮件 | 通过 SMTP 服务器发送的邮件：审批请求和作业通知。 |
+| Slack | 通过传入 webhook 发到 Slack 频道的消息，带有跳转到作业的按钮。 |
+| Microsoft Teams | 通过 Workflows webhook 发到 Teams 频道的卡片，带有跳转到作业的按钮。 |
+| Telegram | 机器人在 Telegram 聊天中发送的消息，带有作业的链接。 |
+| Webhook | 根据模板构建、发往任意 HTTP 端点的 JSON 请求。 |
+
+表单在其 [通知](forms/notifications.html) 和 [审批](forms/approval.html) 中
+用 `channels:` 引用通道。无法发送的通知会写入日志；它永远不会导致作业或审批失败。
+
+---
+
+## 通知页面
+
+**连接 > 通知** 下的页面列出所有通道，包含以下各列：
+
+| 列 | 含义 |
+|---|---|
+| 已启用 | 是否向其发送通知，参见 [在表单中使用通道](notification-channels/in-a-form.html)。 |
+| 名称 | 表单在 `channels:` 中引用它的名称。 |
+| 类型 | 邮件、Slack、Microsoft Teams、Telegram 或 Webhook。默认邮件通道会在类型后显示一个 **默认** 标记。 |
+| 描述 | 通道的用途。 |
+
+**添加通知通道** 会打开一个对话框：**通道**（名称和描述）、**类型**，然后是所选类型的
+各个步骤。类型在创建通道时设定，之后不可更改。点击某一行会打开通道自己的页面，在 **详情** 之后以选项卡形式显示相同的步骤，
+右上角有 **发送测试**、**删除** 和 **保存**。行菜单提供
+**编辑**、**启用** 或 **禁用**（视当前状态而定）、**设为默认**（邮件）、**发送测试** 和 **删除**。
+
+通道页面的 **详情** 选项卡中有会立即保存的 **已启用** 开关，邮件通道还有 **默认**
+开关，后者通过 **保存** 保存。
+
+拥有 `showConnectionsSettings` 但没有管理员角色的用户打开这些页面时，无法选择只有
+管理员才能引用的凭据，参见 [谁可以修改凭据](credentials.html#who-may-change-a-credential)。当这样的用户修改
+通道的发送目标（webhook 的 url 或其证书检查、Telegram Bot API 地址）时，通道会失去
+它所引用的凭据，除非他们在同一次修改中选择一个凭据。
+
+在 [配置种子](seed/) 中声明的通道在此页面上为只读，但仍然可以测试。
+
diff --git a/i18n/zh/_configure/notification-channels/in-a-form.md b/i18n/zh/_configure/notification-channels/in-a-form.md
new file mode 100644
index 0000000..9e2f933
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/in-a-form.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 在表单中使用通道
+parent: 通知通道
+nav_order: 5
+translated_from: ab807b79469429faf3c3838f268af1ba6c29805a
+---
+
+# 在表单中使用通道
+{: .no_toc }
+
+在通知和审批中引用通道
+{: .fs-6 .fw-300 }
+
+表单按名称引用通道：在 `notifications` 中用于作业状态和作业事件，在 `approval` 中用于审批：
+
+```yaml
+notifications:
+  recipients:
+    - ops@example.com
+  channels:
+    - ops-slack
+    - ops-teams
+  onStatus:
+    - failed
+
+approval:
+  title: Remove host $(vm.name) ?
+  roles:
+    - approvers
+  channels:
+    - approvers-teams
+```
+
+- 聊天和 webhook 通道会收到一条简短的消息（表单、作业、发生了什么），并附带作业的链接；对于
+  审批，作业的页面就是批准或拒绝它的地方。
+- 列表中的 **邮件** 通道会通过该服务器（而不是默认服务器）向 `recipients`（审批的 `notifications` 地址）
+  发送常规邮件。
+- 不存在的名称，或已关闭的聊天或 webhook 通道，会被跳过并在日志中注明。
+- 已关闭的 **邮件** 通道不会被跳过：邮件会改为通过默认邮件通道发送，日志中也会
+  注明。
diff --git a/i18n/zh/_configure/notification-channels/mail.md b/i18n/zh/_configure/notification-channels/mail.md
new file mode 100644
index 0000000..7b76c53
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/mail.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: 邮件
+parent: 通知通道
+nav_order: 1
+translated_from: 3ab21a1f2987744527863f5f25ce347dbdf2cd3d
+---
+
+# 邮件
+{: .no_toc }
+
+SMTP 服务器、默认服务器及其登录信息
+{: .fs-6 .fw-300 }
+
+邮件通道就是一台 SMTP 服务器。您可以保留多个；标记为 **默认** 的那个，是表单未引用任何邮件通道时应用发送
+邮件所用的服务器。第一个邮件通道会成为默认通道，**设为默认** 可以更改默认通道。
+
+| 步骤 | 字段 | 含义 |
+|---|---|---|
+| 凭据 | 凭据 | 必填。[连接 > 凭据](../credentials.html) 中的一个 **smtp** 凭据：邮件服务器、其端口和 TLS，以及登录信息。对于无需登录的中继，使用没有用户的 smtp 凭据。 |
+| 发件人 | 发件人 | 收件人看到的发件地址。 |
+
+邮件通道页面 **详情** 选项卡上的 **默认** 开关会将其设为默认，与 **设为默认** 的作用相同。
+当没有邮件通道作为默认通道，或默认通道已关闭时，会使用配置种子中的邮件设置。
diff --git a/i18n/zh/_configure/notification-channels/slack-and-teams.md b/i18n/zh/_configure/notification-channels/slack-and-teams.md
new file mode 100644
index 0000000..aa95c98
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/slack-and-teams.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: Slack 和 Microsoft Teams
+parent: 通知通道
+nav_order: 2
+translated_from: d0c548d54213641c8b6b142e1d7cd1764b6d02b9
+---
+
+# Slack 和 Microsoft Teams
+{: .no_toc }
+
+Slack 或 Teams 的频道 webhook
+{: .fs-6 .fw-300 }
+
+Slack 和 Teams 通道只需要频道 webhook 的地址：
+
+| 类型 | Webhook 地址 |
+|---|---|
+| Slack | 频道的传入 webhook（Slack app > Incoming Webhooks）。 |
+| Microsoft Teams | 频道的 Workflows webhook（"post to a channel when a webhook request is received"）。 |
+
+该地址就是让任何人都能向频道发帖的密钥：它以加密形式保存，保存后永远不会再显示。
diff --git a/i18n/zh/_configure/notification-channels/telegram.md b/i18n/zh/_configure/notification-channels/telegram.md
new file mode 100644
index 0000000..7c301a6
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/telegram.md
@@ -0,0 +1,21 @@
+---
+layout: default
+title: Telegram
+parent: 通知通道
+nav_order: 3
+translated_from: c268bd1ed02b399d229ecec8e49d7ba4956ee131
+---
+
+# Telegram
+{: .no_toc }
+
+在 Telegram 聊天中发言的机器人
+{: .fs-6 .fw-300 }
+
+Telegram 通道是一个在聊天中发言的机器人。其 **凭据** 步骤保存 **机器人令牌**，**机器人** 步骤保存其余内容：
+
+| 字段 | 含义 |
+|---|---|
+| 机器人令牌 | [连接 > 凭据](../credentials.html) 中的一个 **api** 凭据，其密码是从 BotFather 获得的机器人令牌。 |
+| 聊天 ID | 机器人发言的聊天、群组或频道；群组或频道为负数。 |
+| Bot API 地址 | 自建的 Bot API 服务器；留空则为 `api.telegram.org`。 |
diff --git a/i18n/zh/_configure/notification-channels/testing.md b/i18n/zh/_configure/notification-channels/testing.md
new file mode 100644
index 0000000..fc6138a
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/testing.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: 测试通道
+parent: 通知通道
+nav_order: 6
+translated_from: ae699fb758338a45780631ffec3f85ef3401280f
+---
+
+# 测试通道
+{: .no_toc }
+
+发送测试，以及它能证明什么
+{: .fs-6 .fw-300 }
+
+**发送测试** 会按已保存的状态通过该通道发送一条测试通知，因此请先保存您的更改。它对
+已关闭的通道也有效。对于邮件通道，
+对话框会询问要发送到的地址；其他通道则发到它们自己的频道。对话框会显示是否成功，
+失败时还会显示原因。
diff --git a/i18n/zh/_configure/notification-channels/webhook.md b/i18n/zh/_configure/notification-channels/webhook.md
new file mode 100644
index 0000000..1c14f1d
--- /dev/null
+++ b/i18n/zh/_configure/notification-channels/webhook.md
@@ -0,0 +1,53 @@
+---
+layout: default
+title: Webhook
+parent: 通知通道
+nav_order: 4
+translated_from: 99bafedd6f37d6afe3104cd7d8819c3891b518d0
+---
+
+# Webhook
+{: .no_toc }
+
+发往任意 HTTP 端点的 JSON 请求
+{: .fs-6 .fw-300 }
+
+Webhook 通道向任意 HTTP 端点发送 JSON 请求。其 **端点** 步骤说明发往哪里以及如何发送，其
+**凭据** 步骤保存 **Bearer 令牌**：
+
+| 字段 | 含义 |
+|---|---|
+| URL | 请求的发送地址。 |
+| 方法 | `POST`（默认）或 `PUT`。 |
+| Bearer 令牌 | [连接 > 凭据](../credentials.html) 中的一个 **api** 凭据，其密码以 `Authorization: Bearer <password>` 发送。留空：不发送令牌。 |
+| 校验 TLS 证书 | 默认开启；仅对使用自签名证书的端点关闭。 |
+
+{% raw %}
+其 **内容** 步骤保存 **请求头**（以 JSON 对象表示的额外请求头，例如 `{ "X-Source": "ansibleforms" }`）和
+**内容**（请求体的 JSON 模板）。以下占位符会被填入：
+
+| 占位符 | 值 |
+|---|---|
+| `{{title}}` | 通知的标题 |
+| `{{text}}` | 通知的正文 |
+| `{{status}}` | 作业状态 |
+| `{{event}}` | 作业事件 |
+| `{{jobId}}` | 作业 ID |
+| `{{form}}` | 表单名称 |
+| `{{user}}` | 启动作业的用户 |
+| `{{link}}` | 作业的链接 |
+
+占据整个 JSON 字符串的占位符（`"{{text}}"`）会被替换为 JSON 形式的值；位于较长字符串内部时，其
+文本会按 JSON 进行转义。未知的占位符保持原样。内容为空时发送以下模板：
+
+```json
+{
+  "title": "{{title}}",
+  "text": "{{text}}",
+  "status": "{{status}}",
+  "event": "{{event}}",
+  "job": { "id": "{{jobId}}", "form": "{{form}}", "user": "{{user}}" },
+  "link": "{{link}}"
+}
+```
+{% endraw %}
diff --git a/i18n/zh/_configure/production/backups.md b/i18n/zh/_configure/production/backups.md
new file mode 100644
index 0000000..e375c6e
--- /dev/null
+++ b/i18n/zh/_configure/production/backups.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: 备份
+parent: 生产环境运行
+nav_order: 2
+redirect_from:
+  - /production/backups-and-logs.html
+translated_from: 85cd29062adaaa52a93b688dcaddda94ef40a7bd
+---
+
+# 备份
+{: .no_toc }
+
+每晚备份、备份的内容、恢复，以及还需要保存什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 每晚备份
+
+AnsibleForms 每晚午夜自动备份，时区为 [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) 所设
+（默认为 UTC）。以下设置控制备份：
+
+| 变量 | 默认值 | 含义 |
+|----------|---------|---------|
+| [`BACKUP_PATH`](../customization/paths.html#env_BACKUP_PATH) | `%PERSISTENT_FOLDER%/backups` | 备份写入的位置，每个备份一个带时间戳的文件夹 |
+| [`NIGHTLY_BACKUP_RETENTION`](../customization/retention.html#env_NIGHTLY_BACKUP_RETENTION) | `7` | 保留多少个每晚备份，`0` 表示全部保留 |
+| [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) | `mariadb-dump --ssl-verify-server-cert=OFF` | 导出数据库的命令 |
+| [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) | `mariadb --ssl-verify-server-cert=OFF` | 恢复时重放导出文件的命令 |
+| [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS) | `3600` | 导出和恢复可以运行的时长 |
+
+拥有 `allowBackupOps` 角色选项的用户也可以随时在 **备份** 页面上创建备份。保留策略只删除
+每晚备份，并且只有包含可用导出文件的备份才计入其中，因此连续几晚失败也绝不会把最后一个正常的备份挤掉。
+
+在升级修改数据库之前，worker 会先创建一个常规备份，每个版本一次，名为 *Before the upgrade to
+&lt;version&gt;*。它会显示在 **备份** 页面上，永远不会被每晚备份的保留策略删除。如果它失败（没有导出工具、
+`BACKUP_PATH` 不可写），升级会停止并说明原因，因此应用永远不会在升级了一半的数据库上启动。
+[`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP)`=0` 表示升级时不做备份。
+
+这些命令可以是包装命令，例如 `docker exec <container> mysqldump`，只要其第一个词在本地存在。从 7.3.0 起，它们不经过
+shell 运行：引号和命令环境中的 `$NAME` 可以使用，但 `;`、`|`、`&&`、`>` 和 `<` 会被拒绝。
+
+---
+
+## 数据库权限
+
+导出以 [`DB_USER`](../customization/server.html#env_DB_USER) 身份运行，所需权限不超过应用本身所需的权限：
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+导出使用 `--no-tablespaces`，因此不需要服务器级别的 `PROCESS` 权限，并且会跳过
+描述正在运行进程的表（`nodes`、`cache_epochs`、`designer_lock`、`runner_leases`）。恢复时以同一用户身份重放。
+当该用户对所有数据库都有权限（如 `root`）时，**状态** 页面会在其 **数据库用户** 检查项上显示警告。
+
+---
+
+## 备份的内容
+
+每个备份是 `BACKUP_PATH` 下的一个文件夹，以其 UTC 时间戳（`YYYYMMDDHHmmss`）命名，包含：
+
+| 文件 | 内容 |
+|------|---------|
+| `ansibleforms.sql` | `AnsibleForms` 数据库的导出：用户、组、凭据、作业、设置、审计记录 |
+| `config.yaml` | [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) 处的文件 |
+| `forms/` | [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) 处的文件夹 |
+| `managed.env` | 设置页面写入的环境文件，不包括 `ENCRYPTION_SECRET`、`ENCRYPTION_SECRET_PREVIOUS` 和 `ACCESS_TOKEN_SECRET` |
+| `meta.yaml` | 备份的描述 |
+
+导出失败的备份会被再次删除，并记录为错误。当没有备份、最新备份已超过两天，
+或最新备份没有可用的导出文件时，**状态** 页面会发出警告，它还会检查导出工具是否存在。
+
+[`OLD_BACKUP_DAYS`](../customization/retention.html#env_OLD_BACKUP_DAYS) 则用于保留设计器的还原点（默认 60 天）。
+
+---
+
+## 恢复备份
+
+在 [**备份** 页面](../gui/administration.html#restore) 进行恢复，并勾选 **恢复前先创建新备份**。恢复会：
+
+* 重放 `ansibleforms.sql`，替换整个数据库；从 7.3.0 起，旧版本的备份随后会像新版本启动时一样
+  再次升级，失败的补丁会被报告
+* 复制回 `config.yaml`，并用备份中的 `forms/` 文件夹替换现有文件夹：从 7.3.0 起，不在备份中的表单会被
+  删除而不是保留，文件夹的链接和权限模式保持不变，复制失败时文件夹会回滚
+* **不会** 恢复 `managed.env`，因为它描述的是备份来源的主机。**恢复环境**
+  按钮可按需将其放回，并将当前文件保存为 `.env.bak`，之后需要重启。
+
+没有可用导出文件的备份会被拒绝；恢复中断后，请修复原因并重新恢复。
+
+在新主机上，请在恢复之前设置相同的 `ENCRYPTION_SECRET`，否则保存的凭据无法解密。
+
+---
+
+## 还需要备份什么
+
+每晚备份涵盖数据库、配置和表单，但不包括持久化文件夹中的其他任何内容：
+
+* **`ENCRYPTION_SECRET` 和 `ACCESS_TOKEN_SECRET`**：按设计永远不会出现在备份中。请将它们保存在您的密钥管理器中；
+  没有加密密钥，数据库导出中的凭据就毫无用处。
+* **备份本身**：它们与实例位于同一个卷上。请将 `BACKUP_PATH` 复制到另一台主机。
+* **持久化文件夹的其余部分**：playbook、上传文件、变量文件、克隆的仓库、证书和日志。
+  使用 docker-compose 项目时，请备份整个 `data/` 文件夹，其中还包含 SSH 密钥、自定义
+  函数以及 Ansible 角色和集合。
+
+来自 git 的内容（仓库、仓库中的表单）可以重新克隆，因此其备份不那么重要。
diff --git a/i18n/zh/_configure/production/index.md b/i18n/zh/_configure/production/index.md
new file mode 100644
index 0000000..38c6436
--- /dev/null
+++ b/i18n/zh/_configure/production/index.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 生产环境运行
+nav_order: 12
+has_children: true
+has_toc: false
+permalink: /production/
+translated_from: 2d7f4be84a76837fae34c1b414a229448bfae4ea
+---
+
+# 生产环境运行
+{: .no_toc }
+
+发布、备份和监控大家所依赖的实例
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 上线之前
+
+默认设置可以让实例快速运行起来，但其中有几项只适合初步试用。当未设置 `ENCRYPTION_SECRET` 或 `ACCESS_TOKEN_SECRET` 时，
+AnsibleForms 会在启动时记录一条 `[SECURITY]` 警告，**状态** 页面也会报告备份、保留设置和表达式净化器的情况。
+
+---
+
+## 生产环境检查清单
+
+在用户开始依赖该实例之前逐项检查一遍，并在每次重大升级后再检查一遍：
+
+| 项目 | 要做的事 | 详情 |
+|------|------------|---------|
+| 管理员密码 | 修改本地管理员账户的密码 | [加固](../security/hardening.html#the-admin-account) |
+| 加密密钥 | 在保存任何凭据之前设置 [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | [密钥与加密](../security/secrets.html#the-two-master-secrets) |
+| 令牌密钥 | 设置 [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)，使会话在重启后仍然有效 | [密钥与加密](../security/secrets.html#the-two-master-secrets) |
+| HTTPS | 使用您自己的证书（而非示例证书）终止 TLS | [HTTPS](../security/https.html) |
+| 反向代理 | 在代理之后发布实例，可选择放在 [`BASE_URL`](../customization/server.html#env_BASE_URL) 下 | [反向代理](reverse-proxy.html) |
+| Schema 端点 | Schema 创建后，将 [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) 设为 `0` | [加固](../security/hardening.html#the-database) |
+| 出站调用 | 用 [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS) 限制 REST 表达式 | [加固](../security/hardening.html#expressions-and-outbound-calls) |
+| 可选功能 | 除非使用，否则保持 MCP 和聊天助手关闭 | [加固](../security/hardening.html#optional-features) |
+| 备份 | 检查每晚备份是否正常，并将其复制到主机之外 | [备份](backups.html) |
+| 保留 | 决定作业和审计条目的保留时长 | [日志](logs.html#retention) |
+
+---
+
+## 本节内容
+
+每个主题都有自己的页面；实例的安全加固在 [安全](../security/) 中介绍：
+
+| 页面 | 内容 |
+|---|---|
+| [反向代理](reverse-proxy.html) | 在 Nginx、Traefik 或 Apache 之后发布 AnsibleForms，放在根路径或子路径下 |
+| [备份](backups.html) | 每晚备份、备份的内容、恢复，以及还需要保存什么 |
+| [日志](logs.html) | 日志文件、syslog、审计记录，以及作业和审计条目的保留 |
+| [扩展](scaling.html) | 多个应用节点加一个 worker；RTE 有单独的章节，见 [运行时环境](../rte/) |
+| [监控](monitoring.html) | 健康探针、Prometheus 指标和状态页面 |
diff --git a/i18n/zh/_configure/production/logs.md b/i18n/zh/_configure/production/logs.md
new file mode 100644
index 0000000..6a71332
--- /dev/null
+++ b/i18n/zh/_configure/production/logs.md
@@ -0,0 +1,126 @@
+---
+layout: default
+title: 日志
+parent: 生产环境运行
+nav_order: 3
+translated_from: 17d3894c528610d4916fbdcf4beb5bbbacd2b266
+---
+
+# 日志
+{: .no_toc }
+
+日志文件、syslog、审计记录，以及作业和审计条目的保留时长
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 日志文件
+
+AnsibleForms 向 [`LOG_PATH`](../customization/logging.html#env_LOG_PATH)
+（`%PERSISTENT_FOLDER%/logs`）写入两个按天轮转的日志，压缩较早的日志，并保留 [`LOG_RETENTION_DAYS`](../customization/logging.html#env_LOG_RETENTION_DAYS) 天
+（默认 30 天，`0` 表示保留所有文件；在设置页面上的修改会立即生效）：
+
+* `ansibleforms.<date>.log`：[`LOG_LEVEL`](../customization/logging.html#env_LOG_LEVEL) 及以上级别的所有内容
+* `ansibleforms.errors.<date>.log`：仅错误
+
+控制台（用 `docker logs` 或 `kubectl logs` 读取）有自己的级别，
+[`LOG_CONSOLE_LEVEL`](../customization/logging.html#env_LOG_CONSOLE_LEVEL)。两者默认均为 `notice`，适合
+生产环境；只在排查问题时使用 `info` 或 `debug`，并保持
+[`ENABLE_DB_QUERY_LOGGING`](../customization/features.html#env_ENABLE_DB_QUERY_LOGGING) 关闭。级别可以在
+设置页面上修改，无需重启；**服务器日志** 页面会向拥有 `showLogs` 选项的用户显示日志。
+
+---
+
+## JSON 行
+
+对于 Loki、ELK 或 Splunk 等日志收集器，请将 [`LOG_FORMAT`](../customization/logging.html#env_LOG_FORMAT) 设为 `json`。这样，
+控制台和文件中的每一行都是一个 JSON 对象，而不是 `<time> <level>: <message>`：
+
+```json
+{"time":"2026-10-12T08:15:02.113Z","level":"notice","message":"App running on port 8000!","role":"all","host":"forms01"}
+```
+
+| 字段 | 内容 |
+|-------|---------|
+| `time` | 时间，ISO 8601 UTC 格式 |
+| `level` | 日志级别 |
+| `message` | 消息 |
+| `requestId` | 该行所属的请求（在处理请求期间写入时） |
+| `role` | 进程的角色 [`AF_ROLE`](scaling.html)，未设置时为 `all` |
+| `host` | 进程所在机器或容器的主机名 |
+
+每个请求都有一个 ID：反向代理发送的 `X-Request-Id` 请求头，或者新生成的 ID。它会在响应的
+`X-Request-Id` 头中返回，并由处理该请求期间写入的每一行携带（在文本行中为 `[req <id>]`），
+因此可以在日志中跟踪一个请求，并与代理的日志对应。在设置页面上的修改会立即生效。
+
+---
+
+## Syslog
+
+Syslog 服务器在 **设置 > 连接 > Syslog** 下管理，这样 syslog 服务器或 SIEM 就能在日志写入时收到日志。
+您可以添加多台服务器，每台都有自己的设置：
+
+| 设置 | 作用 |
+|---------|--------------|
+| 已启用 | 只有已启用的服务器才会收到内容，因此可以暂停服务器而不删除它；其行菜单中的 **启用** 和 **停用** 也可以切换它 |
+| 协议 | `udp4`（默认）、`udp6`、`tcp4`、`tcp6`、`tls4`、`tls6`、`unix` 或 `unix-connect` |
+| 主机和端口 | 发送目标服务器，默认端口为 `514`；`unix` 协议则使用套接字路径 |
+| 接收内容 | 服务器日志、审计条目，或两者都接收（新服务器的默认值） |
+| 级别 | 接收的服务器日志的最低级别，默认为 `info`；审计条目总是会发送 |
+| 类型 | `BSD`（RFC 3164，默认）或 `RFC 5424` |
+
+修改无需重启即可在每个节点上生效，服务器页面上有一个按钮可以向其发送测试消息。
+无法访问的服务器永远不会导致应用停止：错误会写入控制台。
+
+从 7.3.0 起，syslog 服务器需要完整的设置权限，即 [`showSettings`](../config/roles.html#role-options) 角色选项：
+仅能访问连接设置是不够的，因为 syslog 服务器会接收服务器日志和审计条目。
+
+早期版本的 `LOG_SYSLOG_*` 变量自 7 起已弃用。首次启动时如果发现设置了
+[`LOG_SYSLOG_HOST`](../customization/logging.html#env_LOG_SYSLOG_HOST)，会将它们一次性导入为服务器 `syslog`，
+像以前一样接收服务器日志，此后便忽略这些变量。请在首次启动之后将它们从环境中删除，
+并在设置页面上管理该服务器。
+
+---
+
+## 审计记录
+
+**审计日志** 页面（在 **设置 > 日志** 下）记录谁修改了什么，这是日志文件难以回答的问题。
+它记录：
+
+* 通过 API 进行的每一次修改（`POST`、`PUT`、`PATCH`、`DELETE`），包括被 401 或 403 拒绝的尝试
+* 登录，包括尝试使用的用户名
+* 应用自身的事件，例如每晚备份、删除的备份、清理的作业以及配置种子的应用
+
+每个条目都包含时间、操作者（某个用户，或执行自身任务的应用本身）、客户端 IP 地址、
+操作、操作对象及其结果：`success`、`failure` 或 `denied`。页面可以按操作者、操作和
+结果进行筛选，拥有 `showSettings` 角色选项的用户可以打开它。
+
+IP 地址是 AnsibleForms 看到的地址，在代理之后运行时就是代理的地址。请将
+[`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) 设为代理的数量或地址，AnsibleForms
+就会改为记录代理在 `X-Forwarded-For` 中报告的客户端地址；参见 [反向代理](reverse-proxy.html)。
+
+要将审计记录保存在实例之外以供 SIEM 使用，请添加一台接收审计条目的 syslog 服务器（参见
+[Syslog](#syslog)）。每个条目在发生时即被发送，形式为一行 `audit {...}`，其中条目为 JSON，与
+服务器的级别无关。syslog 中的副本不会被下面的保留策略删除，也不会被数据库恢复所替换。
+
+---
+
+## 保留
+
+有两个带设置的每日任务，防止数据库无限增长：
+
+| 变量 | 默认值 | 运行时间 | 删除内容 |
+|----------|---------|---------|---------|
+| [`AUDIT_RETENTION_DAYS`](../customization/retention.html#env_AUDIT_RETENTION_DAYS) | `365` | 3:30 | 早于此期限的审计条目 |
+| [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) | `0`（全部保留） | 2:30 | 早于此期限的已完成作业及其输出 |
+
+对两者而言，`0` 都表示全部保留。另有两个每日任务没有设置：3:00 删除超过 30 天的已保存刷新令牌和
+已过期的令牌撤销记录，4:00 删除已过期的 [保存的作业](../jobs/stored-jobs.html)。
+时间以 [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) 的时区为准，由 worker 执行。
+
+作业输出通常是增长最快的表：**状态** 页面会报告其大小，
+并在其超过 1 GB 且未设置保留时发出警告。正在运行的作业和等待批准的作业永远不会被删除。
+请确定一个符合您审计要求的作业保留期限，并让审计记录至少保留同样长的时间。
diff --git a/i18n/zh/_configure/production/monitoring.md b/i18n/zh/_configure/production/monitoring.md
new file mode 100644
index 0000000..50db550
--- /dev/null
+++ b/i18n/zh/_configure/production/monitoring.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: 监控
+parent: 生产环境运行
+nav_order: 5
+translated_from: b2bf7ba817910d15cd4fe5c5eb5881dba1ebacd5
+---
+
+# 监控
+{: .no_toc }
+
+用于负载均衡器或 Kubernetes 的健康探针、Prometheus 指标和状态页面
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 健康探针
+
+有两个端点可以告诉负载均衡器、容器健康检查或 Kubernetes，某个进程是否可以接收流量。
+两者都不需要登录，也都不返回任何关于部署配置的信息：
+
+| 端点 | 应答 | 用途 |
+|----------|---------|------------|
+| `/api/v2/live` | 只要进程在运行，就返回 `200` 和 `{"status":"live"}` | 存活探针：进程不再应答时重启它 |
+| `/api/v2/ready` | 返回 `200` 和 `{"status":"ready"}`，或 `503` 和 `{"status":"not ready","reason":"..."}` | 就绪探针：只向就绪的进程发送流量 |
+
+当以下条件全部满足时，进程即为就绪：
+
+* 它没有在关闭（`stopping`）
+* 数据库有应答（`database unreachable`）
+* schema 存在（`schema not provisioned`）且完整，包含此版本的所有表、列和索引
+  （`schema not upgraded`）；最后这项检查会缓存 30 秒，因此每隔几秒探测一次的开销也很小
+
+在 [`BASE_URL`](../customization/server.html#env_BASE_URL) 下时，路径以它开头，例如
+`/ansibleforms/api/v2/ready`。运行时环境（RTE）在 `/live` 和 `/ready` 上应答相同的探针，但不做
+schema 完整性检查；它在关闭时排空作业期间处于未就绪状态，因此不会再有新作业发给它。出站 RTE
+在与应用的套接字建立之前也处于未就绪状态（`not connected to the app`）。
+以 `AF_ROLE=worker` 启动的进程没有 Web 界面：它只应答 `/api/v2/version` 和用于容器健康检查的 `/health`。
+各种角色参见 [扩展](scaling.html)。
+
+---
+
+## Prometheus 指标
+
+将 [`METRICS_TOKEN`](../customization/features.html#env_METRICS_TOKEN) 设为一个较长的随机字符串，即可提供 Prometheus 指标。
+提供 Web 应用的进程在 `/api/v2/metrics` 上应答，RTE 在 `/metrics` 上应答：
+
+```yaml
+scrape_configs:
+  - job_name: ansibleforms
+    metrics_path: /api/v2/metrics
+    authorization:
+      type: Bearer
+      credentials: <METRICS_TOKEN>
+    static_configs:
+      - targets: ['forms01.example.com:8000']
+```
+
+没有 `METRICS_TOKEN` 时，这些端点返回 `404`，就像它们不存在一样；没有正确的
+`Authorization: Bearer <token>` 请求头的请求会得到 `401`。每个进程都报告自己的数据，因此请分别抓取每个进程：
+
+| 指标 | 测量内容 |
+|--------|------------------|
+| `af_process_*`、`af_nodejs_*` | 进程：CPU、内存、事件循环延迟、垃圾回收 |
+| `af_http_requests_total{route,method,status}` | 已处理的请求 |
+| `af_http_request_duration_seconds{route}` | 请求耗时 |
+| `af_jobs{status}` | 当前正在运行（`running`）或等待批准（`approve`）的作业 |
+| `af_jobs_ended_24h{status}` | 过去 24 小时内结束的作业，按状态统计 |
+| `af_nodes{role,alive}` | 在数据库中注册的进程，按角色以及是否存活统计 |
+| `af_login_failures_total`、`af_login_lockouts_total` | 登录失败次数和账户锁定次数 |
+| `af_rte_running_jobs`、`af_rte_max_jobs` | 在 RTE 上：当前运行的 playbook 数量，以及最多可同时运行的数量 |
+| `af_rte_socket_connected` | 在套接字模式的 RTE 上：与应用的套接字打开时为 `1`，否则为 `0` |
+
+作业和节点的数据在每次抓取时从数据库读取。数据库没有应答时会省略这些数据，
+抓取仍会成功，并返回其他指标。
+
+---
+
+## 状态页面
+
+**设置 > 系统** 下的 **状态** 页面向拥有 `showSettings` 角色选项的用户展示实例的运行状况。
+它只读取数据，因此刷新它永远不会发送邮件或启动作业。它有两个选项卡，问题数量显示在 **检查项** 选项卡的标签上。
+
+### 检查项
+
+每个检查项为绿色（正常）、琥珀色（需要关注）或红色（有问题），展开该行即可查看详情：
+
+| 检查项 | 检查的内容 |
+|-------|------------------|
+| 数据库连接 | 数据库有应答 |
+| 数据库用户 | 当用户像 `root` 一样对所有数据库都有权限，而不是仅对 `AnsibleForms.*` 有权限时，显示琥珀色 |
+| 数据库架构 | 此版本的所有表、列和索引都存在；不存在时显示是哪个补丁失败了 |
+| 调度器 | 有一个 worker 在运行系统任务，并且没有任何任务停止调度 |
+| 节点 | 数据库中的进程，当它们运行不同版本时显示琥珀色 |
+| 作业 | 正在运行的作业和等待批准的作业，当某个作业运行超过 24 小时时显示琥珀色 |
+| 备份工具 | [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) 的导出命令存在，以及其版本 |
+| 上次备份 | 没有备份或最新备份已超过两天时显示琥珀色，没有可用导出文件时显示红色 |
+| 设计器锁 | 谁持有设计器锁，持有超过 8 小时时显示琥珀色 |
+| 仓库 | 某个仓库失败或磁盘上没有工作树时显示红色 |
+| 配置种子 | [配置种子](../seed/) 文件可读且可解析，并且上次重新加载成功 |
+| 密钥库 | 每个密钥库都有应答，HashiCorp Vault 的令牌即将过期时显示琥珀色 |
+| 运行器 | 每个运行器都有应答，没有运行器或没有默认 RTE 时显示琥珀色 |
+| 服务器表达式 | 当 [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER) 为 `legacy` 时显示琥珀色 |
+| 密钥 | 当 `ENCRYPTION_SECRET` 为公开的默认值或未设置 `ACCESS_TOKEN_SECRET` 时显示琥珀色 |
+| LDAP | LDAP 服务器可以访问且其 TLS 证书有效，不会登录到该服务器 |
+| 作业存储 | 作业表的大小，未设置作业保留且超过 1 GB 时显示琥珀色 |
+| 可写文件夹 | 每个已配置的文件夹都可以写入 |
+| 磁盘空间 | 保存备份的磁盘，使用率达到 85% 时显示琥珀色，达到 95% 时显示红色 |
+
+### 信息
+
+关于实例的、无需判定的事实，也是寻求支持时最先被问到的信息：AnsibleForms
+版本、基础 URL、数据库版本和主机、配置来源、配置种子、保留
+设置、身份验证方式、当前 [邮件通道](../notification-channels.html) 的服务器、日志
+级别和路径、运行时间、时区、Node.js 版本以及平台。
+
+该页面读取 `/api/v2/health`，需要拥有 `showSettings` 的已登录用户。对于监控系统，请改用
+上面的探针和指标。
diff --git a/i18n/zh/_configure/production/reverse-proxy.md b/i18n/zh/_configure/production/reverse-proxy.md
new file mode 100644
index 0000000..ff33722
--- /dev/null
+++ b/i18n/zh/_configure/production/reverse-proxy.md
@@ -0,0 +1,264 @@
+---
+layout: default
+title: 反向代理
+parent: 生产环境运行
+nav_order: 1
+translated_from: 13348b4571edb1aa56a0c0015a9691f81c1d412f
+---
+
+# 反向代理
+{: .no_toc }
+
+在 Nginx、Traefik 或 Apache 之后发布 AnsibleForms，放在根路径或子路径下
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 何时使用
+
+AnsibleForms 在同一个端口上提供界面、REST API 和 Swagger；在其前面放一个反向代理可以：
+
+* 在 443 端口上提供服务，并使用现有工具（ACME、企业 CA）管理的证书
+* 将 AnsibleForms 发布在子路径下，与其他应用共用一个主机名
+* 让应用端口和数据库不暴露在公共网络上
+
+代理是可选的：应用本身也可以提供 HTTPS，参见 [HTTPS](../security/https.html)。
+
+---
+
+## 关键设置
+
+只有少数几项设置会影响 AnsibleForms 在代理之后的行为：
+
+| 设置 | 在代理之后 |
+|---------|----------------|
+| [`PORT`](../customization/server.html#env_PORT) | 代理转发到的端口，默认为 `8000`。docker-compose 项目将其设为 `443`。 |
+| [`HTTPS`](../customization/server.html#env_HTTPS) | 当代理终止 TLS 并通过私有网络访问应用时设为 `0`；如果这一段也要加密，则设为 `1`。 |
+| [`BASE_URL`](../customization/server.html#env_BASE_URL) | 子路径，例如 `/ansibleforms`。当应用有自己的主机名时，保持为 `/`。 |
+| [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) | 哪些代理可以在 `X-Forwarded-For` 中报告客户端地址，通常为 `1`。参见 [客户端地址](#client-addresses)。 |
+| [`API_BODY_LIMIT_MB`](../customization/server.html#env_API_BODY_LIMIT_MB) | 应用接受的最大 JSON 请求，默认为 50 MB。代理允许的大小必须至少与此相同。 |
+| [`UPLOAD_MAX_GB`](../customization/server.html#env_UPLOAD_MAX_GB) | 表单上传字段接受的最大文件，默认为 10 GB。代理也必须允许这个大小，否则上传会在代理处失败。 |
+| [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE) | 应用接受的请求头总大小上限，默认为 16 KB，从 7.1.0 起。参见 [请求头大小](#request-header-size)。 |
+| **公共根 URL** | 在 **系统 > 常规** 的 **服务器** 选项卡中：用户访问的地址，包括子路径。它用于生成通知邮件、通道消息和审批请求中的链接。 |
+
+对于 Entra ID 或 OIDC，请将公共地址注册为重定向 URI；如果设置了 `BASE_URL`，还要包括其子路径。
+
+---
+
+## 在子路径下提供服务
+
+`BASE_URL` 把整个应用挂载在子路径下；代理必须 **原样** 转发路径。
+当 `BASE_URL=/ansibleforms` 时：
+
+* 界面、`/api/v2/...` 和 Swagger 界面都在 `/ansibleforms/` 下提供
+* 界面的 `<base href>` 会在启动时被改写，因此静态资源和 API 调用都在子路径下解析
+* 对 `/` 或 `/ansibleforms`（没有末尾斜杠）的请求会被重定向到 `/ansibleforms/`
+
+请保留前缀：Traefik 中不要使用 `StripPrefix`，Nginx 的 `proxy_pass` 中不要带 URI，因为应用需要这个前缀。
+
+**状态** 页面会显示当前生效的基础 URL。
+
+---
+
+## 超时、上传和实时输出
+
+作业页面和作业计数器通过一个长连接的服务器发送事件流
+[`/api/v2/events`](../api/events.html) 获知变化，每个浏览器保持一个连接。该事件流会发送关闭代理缓冲的请求头
+（`X-Accel-Buffering: no`），并每 15 秒发送一行保活数据，因此常见的 60 秒读取超时不会断开它；
+即使代理仍然关闭了它，浏览器也会自行重新连接。启动后紧接着显示在表单下方的输出
+则是每两秒读取一次。启动作业的请求在作业创建后立即返回，因此长时间运行的 playbook 不会一直占用
+请求。
+
+可能耗时较长的请求有：
+
+* 在 **备份** 页面进行的 **备份和恢复**，它们会等待导出或恢复命令完成，最长为
+  [`BACKUP_COMMAND_TIMEOUT_SECONDS`](../customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS)（默认 3600）
+* 通过文件字段进行的 **大文件上传**，它们在一个请求中以流的方式传输整个文件
+* 启用 [聊天助手](../chat/) 时的 **聊天消息**，它们会等待模型提供商应答
+
+代理通常在 60 秒后超时，并限制请求体大小（Nginx 默认接受 1 MB）。请为
+AnsibleForms 的路由同时提高这两项限制，如下面的示例所示。
+
+---
+
+## 运行器 WebSocket
+
+从 7.3.0 起，[出站运行器](../rte/modes.html#outbound) 会主动连接应用，并在
+`<BASE_URL>/api/v2/rte/socket` 上保持一个打开的 WebSocket。代理必须转发协议升级，否则运行器永远无法连接，会不断重试：
+
+| 代理 | WebSocket 需要的配置 |
+|-------|--------------------------|
+| Nginx | `proxy_http_version 1.1` 以及 `Upgrade` 和 `Connection` 请求头，Nginx 默认不转发它们 |
+| Traefik | 无需配置：WebSocket 会原样通过 |
+| Apache | 在 `ProxyPass` 行上使用 `upgrade=websocket`（2.4.47 及更高版本），更早的版本使用 `mod_proxy_wstunnel` |
+
+两端每 20 秒发送一次 ping，因此常见的 60 秒读取超时不会断开空闲的套接字。
+
+---
+
+## 请求头大小
+
+每个请求都在其 `Authorization` 请求头中携带登录令牌，此外还有 cookie 和代理添加的请求头。
+代理和应用都会限制请求头的大小，并在 AnsibleForms 看到请求之前拒绝超过上限的请求，
+因此服务器日志中不会有任何记录。默认值如下：
+
+| 组件 | 限制 | 默认值 | 拒绝时返回 |
+|-----------|-------|---------|--------------|
+| AnsibleForms（Node.js） | [`MAX_HTTP_HEADER_SIZE`](../customization/server.html#env_MAX_HTTP_HEADER_SIZE)，所有请求头合计 | 16384 字节 | 431 |
+| Nginx | `large_client_header_buffers`，每个请求头字段 | `4 8k`：每个字段 8 KB | 400 |
+| Traefik | 入口点的 `http.maxHeaderBytes`，所有请求头合计 | 1 MB | 431 |
+| HAProxy | `global` 部分中的 `tune.bufsize`，整个请求头块，减去 `tune.maxrewrite` 预留（1024 字节） | 16384 字节：15360 字节的请求头 | 400 |
+| Apache | `LimitRequestFieldSize`，每个请求头字段 | 8190 字节 | 400 |
+
+在 7.0.3 及更早版本中，登录令牌携带单点登录用户的所有组，可能会超出这些限制，参见
+[单点登录后表单和作业为空](../troubleshooting.html#empty-forms-and-jobs-after-a-single-sign-on-http-431)。
+从 7.1.0 起，令牌保持精简，默认值就足够了。当其他因素使请求头变大时，例如
+同一域名下其他应用的 cookie，或前面的单点登录网关，请同时提高这些限制：
+
+* AnsibleForms：`MAX_HTTP_HEADER_SIZE=65536`，7.1.0 之前为 `NODE_OPTIONS=--max-http-header-size=65536`；两者都在
+  启动时读取，因此修改后请重启应用
+* Nginx：在 `http` 或 `server` 块中设置 `large_client_header_buffers 4 32k;`
+* HAProxy：在 `global` 部分中设置 `tune.bufsize 65536`；每个流都会获得该大小的缓冲区，因此 HAProxy 建议
+  按相同倍数降低全局 `maxconn`，并且 HTTP/2 至少需要默认的 16384
+* Apache：在服务器配置或虚拟主机中设置 `LimitRequestFieldSize 32768`
+
+---
+
+## 客户端地址
+
+在代理之后，每个连接都来自代理。没有 [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY) 时，
+审计记录会为每个操作记录代理的地址，按地址计算的
+[登录限制](../security/hardening.html#sign-in-limits-and-passwords) 也会把所有客户端算作同一个地址。
+`TRUST_PROXY` 说明当代理在 `X-Forwarded-For` 中报告客户端时，应用可以相信哪些代理：
+
+| 值 | 客户端地址 |
+|-------|----------------|
+| `0`（默认） | 连接的地址。忽略 `X-Forwarded-For`；空值、`false`、`off` 和 `no` 含义相同。 |
+| 一个数字，例如 `1` | 信任应用前面这么多层代理：单个反向代理为 `1`，ingress 前面还有负载均衡器时为 `2`。 |
+| 一个列表，例如 `10.0.0.5,172.16.0.0/12` | 信任位于这些地址和 CIDR 范围内的代理。也接受预设值 `loopback`、`linklocal` 和 `uniquelocal`。 |
+| `true` | 信任每一跳：使用 `X-Forwarded-For` 最左边的地址。 |
+
+应用从右往左遍历 `X-Forwarded-For`，跳过受信任的代理，取第一个不属于它们的
+地址。请使用准确的代理数量或它们的地址：
+
+* `X-Forwarded-For` 是任何客户端都可以发送的普通请求头。数字过大或使用 `true`，会让
+  客户端自行选择审计记录中的地址。只有当应用只能通过代理访问时 `true` 才是安全的，
+  设置它时服务器会在启动时记录一条 `[SECURITY]` 警告。
+* 代理必须添加它接收连接的来源地址，如下面的示例所示
+  （Nginx 中为 `$proxy_add_x_forwarded_for`；Traefik 和 Apache `mod_proxy` 默认会添加）。
+* 无效的值在设置页面上会被拒绝；如果在环境中设置，启动时会记录一条错误，并且
+  不信任任何代理。在设置页面上保存的修改无需重启即可生效。
+
+---
+
+## 示例
+
+每个示例都将 AnsibleForms 发布在 `https://forms.example.com/ansibleforms/`，由代理终止 TLS，
+应用以 `HTTPS=0`、`PORT=8000`、`BASE_URL=/ansibleforms` 和 `TRUST_PROXY=1` 运行：
+
+<div class="af-tabs" data-tab-group="proxy">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="nginx" aria-selected="true">Nginx</button>
+<button type="button" role="tab" class="af-tab" data-tab="traefik" aria-selected="false">Traefik</button>
+<button type="button" role="tab" class="af-tab" data-tab="apache" aria-selected="false">Apache</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="nginx" markdown="1">
+
+`proxy_pass` 中没有 URI，因此 Nginx 会按原样转发路径，包括前缀。`map` 块放在
+`http` 上下文中（`conf.d/` 下的文件会被包含在那里），用于转发运行器的 WebSocket 升级：
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl;
+    server_name forms.example.com;
+
+    ssl_certificate     /etc/nginx/certs/forms.example.com.crt;
+    ssl_certificate_key /etc/nginx/certs/forms.example.com.key;
+
+    location /ansibleforms/ {
+        proxy_pass         http://10.0.0.20:8000;
+        proxy_set_header   Host $host;
+        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header   X-Forwarded-Proto $scheme;
+
+        proxy_http_version 1.1;                         # the Runners' WebSocket
+        proxy_set_header   Upgrade $http_upgrade;
+        proxy_set_header   Connection $connection_upgrade;
+
+        client_max_body_size    10g;    # UPLOAD_MAX_GB
+        proxy_request_buffering off;    # stream uploads instead of spooling them first
+        proxy_read_timeout      3600s;  # BACKUP_COMMAND_TIMEOUT_SECONDS
+        proxy_send_timeout      3600s;
+    }
+}
+```
+
+不使用子路径时，请使用 `location /`，并且不设置 `BASE_URL`。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="traefik" markdown="1" hidden>
+
+docker-compose 项目中 `app` 服务上的标签，Traefik 位于同一个 Docker 网络中。该服务
+不发布自己的端口，Traefik 通过网络访问它：
+
+```yaml
+  app:
+    image: ghcr.io/ansibleforms/ansibleforms:7
+    environment:
+      - HTTPS=0
+      - PORT=8000
+      - BASE_URL=/ansibleforms
+      - TRUST_PROXY=1                 # Traefik is the one proxy in front
+    labels:
+      - traefik.enable=true
+      - traefik.http.routers.ansibleforms.rule=Host(`forms.example.com`) && PathPrefix(`/ansibleforms`)
+      - traefik.http.routers.ansibleforms.entrypoints=websecure
+      - traefik.http.routers.ansibleforms.tls=true
+      - traefik.http.routers.ansibleforms.tls.certresolver=letsencrypt
+      - traefik.http.services.ansibleforms.loadbalancer.server.port=8000
+```
+
+这里特意没有使用 `StripPrefix` 中间件。Traefik 会自行设置 `X-Forwarded-*` 请求头，也不限制
+请求体大小，但当备份或上传耗时超过入口点的读取超时时，请检查其 `respondingTimeouts`。
+不使用子路径时，规则中只保留 `Host(...)` 部分。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="apache" markdown="1" hidden>
+
+需要 `mod_proxy`、`mod_proxy_http`、`mod_headers`、`mod_ssl`，并且运行器的 `upgrade=websocket` 需要 Apache 2.4.47 或更高版本。
+`ProxyPass` 的两侧都带有前缀：
+
+```apache
+<VirtualHost *:443>
+    ServerName forms.example.com
+
+    SSLEngine on
+    SSLCertificateFile    /etc/pki/tls/certs/forms.example.com.crt
+    SSLCertificateKeyFile /etc/pki/tls/private/forms.example.com.key
+
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    ProxyPass        /ansibleforms/ http://10.0.0.20:8000/ansibleforms/ timeout=3600 upgrade=websocket
+    ProxyPassReverse /ansibleforms/ http://10.0.0.20:8000/ansibleforms/
+
+    # no body cap here : UPLOAD_MAX_GB and API_BODY_LIMIT_MB apply in the application
+    LimitRequestBody 0
+</VirtualHost>
+```
+
+不使用子路径时，请将 `/` 代理到 `http://10.0.0.20:8000/`，并且不设置 `BASE_URL`。
+
+</div>
+</div>
+
+要让代理与应用之间的这一段也保持加密，请以 `HTTPS=1` 运行应用，将代理指向
+`https://`，并为应用配置一个代理信任的证书，参见 [HTTPS](../security/https.html)。
diff --git a/i18n/zh/_configure/production/scaling.md b/i18n/zh/_configure/production/scaling.md
new file mode 100644
index 0000000..3d2f39b
--- /dev/null
+++ b/i18n/zh/_configure/production/scaling.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: 扩展
+parent: 生产环境运行
+nav_order: 4
+translated_from: 5b76f1bfb7520ff2b072919d714d2ab72b1e5d5e
+---
+
+# 扩展
+{: .no_toc }
+
+将 AnsibleForms 拆分到多个应用节点和一个 worker 上，并搭配一个或多个 RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 角色
+
+每个 AnsibleForms 容器都运行相同的服务器代码，由 [`AF_ROLE`](../customization/server.html#env_AF_ROLE) 决定它做什么：
+
+| `AF_ROLE` | 镜像 | 运行内容 | 数量 |
+|---|---|---|---|
+| `all`（未设置） | `ansibleforms` | 在一个进程中运行 Web 应用和 worker：默认值 | 1 |
+| `app` | `ansibleforms` | Web 界面和 API | 任意多个，放在负载均衡器之后 |
+| `worker` | `ansibleforms` | 后台工作：数据库 schema 及其升级、配置种子、调度、每晚备份、仓库同步和清理 | 同一时间一个在工作；更多的则等待接管 |
+| `rte` | `ansibleforms-rte-full`（或 `-rte-core`、`-rte-base`） | playbook | 任意多个 |
+
+最小的安装是一个不设置 `AF_ROLE` 的容器加一个 RTE：这就是 [Docker Compose 项目](../installation/docker-compose.html)
+和 [Helm chart](../installation/kubernetes.html) 所运行的方式。`AF_ROLE` 的任何其他值都会使进程在启动时停止。
+
+---
+
+## RTE
+
+RTE，即运行 playbook 的运行时环境，有单独的章节：[运行时环境](../rte/)。其中介绍了 RTE
+如何运行作业、[其镜像](../rte/images.html)、[如何运行 RTE](../rte/run.html)、作为运行器或
+副本的 [多个 RTE](../rte/several.html)，以及 [位于另一个数据中心的 RTE](../rte/another-datacenter.html)。
+
+---
+
+## 多个应用节点
+
+为了服务更多用户，或在失去一个节点时继续运行，请将应用拆分为放在负载均衡器之后的 `app` 节点和一个 `worker`。
+
+### 节点共享的内容
+{: .no_toc }
+
+各节点通过数据库和一个共享卷彼此协调：
+
+* **数据库**：作业、worker 锁、设计器锁、节点列表、运行器租约（哪个应用节点持有
+  每个 RTE 的套接字），以及让每个节点的缓存保持最新的变更通知。在一个节点上编辑的凭据、运行器或调度
+  会在 5 秒内在所有节点上生效
+* **持久化卷**（`/app/dist/persistent`）：表单、配置、仓库、上传文件、备份和托管的 `.env`。
+  每个应用节点和 worker 都以读写方式挂载同一个卷
+* **ssh 文件夹**（`/home/node/.ssh`）：通过 ssh 访问 git 所用的密钥和已知主机；worker 在首次启动时创建密钥
+* **[`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET)**：在每个应用节点上都必须相同，否则由一个节点签发的
+  令牌会被下一个节点拒绝。没有它，应用节点会拒绝启动
+* **[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)**：在每个应用节点和 worker 上都必须相同，否则
+  由一个节点保存的凭据无法被另一个节点读取。套接字模式的 RTE 从不读取它；只有自行注册的、已弃用的数据库模式 RTE
+  才需要它
+
+还要让每个容器使用同一个数据库用户：只有当会话属于同一用户时，等待中的 worker 才能结束已失效 worker 的会话。
+
+### worker 锁
+{: .no_toc }
+
+同一时间只有一个 worker 在工作。它持有数据库锁 `ansibleforms_worker`；当它停止时，数据库会释放该锁，
+等待中的 worker 会在 10 秒内获取它。当 worker 的主机未经告别就宕机时，数据库可能会将该锁保持数小时，
+因此一旦两分钟内没有任何 worker 写入心跳，等待中的 worker 就会结束那个会话并接管。
+
+被另一个 worker 夺走锁的 worker 会停止，其容器会以等待者的身份重启。启动失败的 worker 也会
+停止，因此它永远不会占着锁却什么都不做。Galera 和组复制不会在数据库节点之间共享该锁：请让每个
+worker 都指向同一个数据库节点。
+
+### 作业与节点
+{: .no_toc }
+
+每个容器都以 `<role>-<hostname>-<port>` 为自己命名，无需任何设置，**状态** 页面会列出所有容器及其角色
+和版本、哪一个是 worker，并在它们运行不同版本时发出警告。
+
+在 RTE 上运行的作业属于该 RTE，即使启动它的应用节点离开也会继续运行。其他任何作业（AWX 或其他运行器上的模板作业、
+工作流作业，或已弃用的多步骤表单的各个步骤）都属于启动它的应用节点。重启的容器会结束自己未完成的作业，
+worker 则会结束已有两分钟没有应答的容器的作业，例如被替换的 pod。
+
+向任意节点发送 `SIGHUP` 都会重新应用 [配置种子](../seed/)：应用节点会请 worker 来执行。
+
+### 升级
+{: .no_toc }
+
+**先升级 worker**，然后再升级应用节点。worker 负责修补 schema，新版本的应用节点会等待
+schema 修补完成，并记录它在等待什么。先升级的应用节点在 worker 跟上之前一直处于未就绪状态，而旧节点会继续
+提供服务。RTE 可以在任何时候跟进，只要它们使用相同的协议约定。
+
+### 限制
+{: .no_toc }
+
+有几项功能只能留在一个节点上：
+
+* **聊天助手** 将其对话保存在单个应用节点的内存中：请在负载均衡器上使用会话保持（nginx
+  `ip_hash`），或只使用一个应用节点
+* **日志** 保留在每个容器中。请将 [`LOG_PATH`](../customization/logging.html#env_LOG_PATH) 设在共享卷之外，因为多个
+  进程轮转同一个文件会丢失日志行。日志查看器显示的是应答请求的那个节点的日志，因此请集中收集日志
+* **设置** 在设置页面上修改后会写入共享卷上的托管 `.env`，并在每个节点上生效；需要重启的设置
+  则需要在每个节点上重启
+
+---
+
+## 示例布局
+
+应用仓库在 [examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale) 中提供了一个完整的起点：
+
+| 服务 | 镜像 | 角色 |
+|---|---|---|
+| `db` | `mariadb:11` | 数据库，其用户只对 `AnsibleForms` schema 有权限 |
+| `app1`、`app2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=app`，位于负载均衡器之后 |
+| `worker1`、`worker2` | `ghcr.io/ansibleforms/ansibleforms:7` | `AF_ROLE=worker`：第二个等待并接管 |
+| `rte` | `ghcr.io/ansibleforms/ansibleforms-rte-full:7` | 以 `RTE_MODE=inbound` 和 `RTE_FILES=local` 运行 playbook：由应用连接它 |
+| `lb` | `nginx:stable` | 在 8443 端口上终止 HTTPS，并用 `ip_hash` 将浏览器分配到各应用节点 |
+
+RTE 的运行器 `rte` 及其登录所用的凭据（其地址 `http://rte:8000` 和 `RTE_TOKEN`）在
+[配置种子](../seed/) `seed.yaml` 中声明，worker 每次启动时都会应用它；RTE 不设置 `RTE_URL`，也不在主机上发布。
+
+应用节点和 worker 共用一个 `.env`，其中包含数据库用户、`ENCRYPTION_SECRET`、`ACCESS_TOKEN_SECRET`、`RTE_TOKEN`、
+`CONFIG_SEED_PATH`、负载均衡器之后的 `HTTPS=0`，以及设在共享卷之外的 `LOG_PATH`。RTE 没有 `env_file`：它只从
+`compose.yaml` 获得 `RTE_TOKEN`，因此不持有数据库密码。应用节点、worker 和 RTE 挂载相同的
+持久化卷和 ssh 卷：
+
+```bash
+cp .env.example .env   # and fill in the secrets
+docker compose up -d   # then https://localhost:8443
+```
diff --git a/i18n/zh/_configure/rte/another-datacenter.md b/i18n/zh/_configure/rte/another-datacenter.md
new file mode 100644
index 0000000..d9b432e
--- /dev/null
+++ b/i18n/zh/_configure/rte/another-datacenter.md
@@ -0,0 +1,488 @@
+---
+layout: default
+title: 另一个数据中心
+parent: RTE
+nav_order: 5
+translated_from: e2e67586abfd6c910942d1775e5331c1f889727e
+---
+
+# 位于另一个数据中心的 RTE
+{: .no_toc }
+
+从第二个数据中心的一台裸主机，到运行第一个 playbook 的出站 RTE
+{: .fs-6 .fw-300 }
+
+* TOC
+{:toc}
+
+---
+
+面向管理员：当第二个数据中心的受管主机应由该数据中心内的 RTE 访问，而不是由第一个数据中心访问时。
+
+{: .note }
+> **简便的方法。** [安装程序](../installation/installer.html#a-runner) 只需在 RTE 主机上运行一条命令，就能完成下面的所有步骤：
+> `curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner`，加上 `--join afj_...` 即可立即获得批准。
+> 本操作手册使用 Docker 或 Podman 手动完成同样的事情，便于您了解并调整每个部分。
+
+---
+
+## 最终结果
+
+应用、其 worker 和数据库保持原位，位于数据中心 1。数据中心 2 新增一台主机，运行一个
+出站模式的 RTE 容器（[`RTE_MODE=outbound`](../customization/server.html#env_RTE_MODE)，参见 [模式](modes.html#outbound)）：它通过
+HTTPS 连接应用并保持一个打开的 WebSocket，作为独立的运行器加入，并针对数据中心 2 的受管主机运行
+指定它的表单的 playbook。
+
+| 位置 | 在那里运行的内容 | 与谁通信 |
+|---|---|---|
+| 数据中心 1 | 应用节点、worker、数据库（与现在相同） | 没有新的通信：它在通常的 HTTPS 地址上接收 RTE 的套接字 |
+| 数据中心 2，RTE 主机 | Docker 或 Podman，以及 RTE 容器 | 通过 HTTPS 访问位于 `APP_URL` 的应用，以及数据中心 2 的受管主机 |
+
+RTE 不持有数据库凭据，也没有 `ENCRYPTION_SECRET`，只有它自己的令牌。没有任何东西连接它，因此它不需要开放
+端口、DNS 名称或证书。应用随每个作业发送 playbook 和清单（`RTE_FILES=transfer`，
+默认值），因此 RTE 不需要它们的副本，也不需要共享磁盘。
+
+除非另有说明，下面的每条命令都在 RTE 主机的终端中以具有 `sudo` 权限的用户运行。整个过程大约需要 20 分钟，
+大部分时间都在等待镜像。
+
+---
+
+## 0. 开始之前
+
+收集以下信息：
+
+| 内容 | 来源 |
+|---|---|
+| 应用的地址 | `APP_URL`：用户在浏览器中打开的地址，例如 `https://forms.example.com`，如有基础路径也要包括 |
+| 应用的证书 | 由公共 CA 签发、由私有 CA 签发（您需要其证书，见第 6 步）或自签名 |
+| 代理 | 此数据中心访问数据中心 1 所用的 `HTTPS_PROXY`（如果有） |
+| RTE 的名称 | 其运行器在 **连接 > 运行器** 下的名称，表单用 `runner:` 引用它，例如 `rte-dc2`：字母、数字和 `_ . : @ -` |
+| 加入令牌 | 可选：[加入令牌](../runners/registration.html#join-tokens)（`afj_...`）可以立即批准 RTE。没有它时，由管理员批准（第 8 步） |
+| ssh 密钥 | playbook 用于访问受管主机的私钥，或创建私钥的权限 |
+
+应用必须运行 7.3.0 或更高版本。要为这一个 RTE 生成加入令牌，管理员需调用一次 API（参见
+[加入令牌](../runners/registration.html#join-tokens)）：
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <an admin's token>" -H "Content-Type: application/json" \
+  -d '{ "name": "rte-dc2", "expiresInHours": 24, "maxUses": 1 }'
+```
+
+---
+
+## 1. 准备主机
+
+RTE 是一个容器，因此主机只需要容器引擎：Node.js、python 和 ansible 都在镜像中。
+
+| 需求 | 原因 |
+|---|---|
+| **x86_64**（amd64）上的 Linux | RTE 镜像只发布了 amd64 版本 |
+| 2 个 CPU 和 4 GB 内存，或更多 | 一个 RTE 最多同时运行 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 个 playbook（10 个），每个都有自己的分支进程：请按此确定规格 |
+| 20 GB 可用磁盘 | `-rte-full` 镜像约 3.3 GB，更新期间还要再加一个镜像，另外还有应用发来的作业文件和作业的临时文件 |
+| Docker，或 Podman 加 podman-compose | 用于拉取和运行镜像 |
+| 由 NTP 同步的时间 | 作业的时间会与应用的时间进行比较 |
+
+**Docker**，在 Ubuntu 或 Debian 上（其他发行版：[docs.docker.com/engine/install](https://docs.docker.com/engine/install/)）：
+
+```bash
+sudo apt-get update && sudo apt-get install -y ca-certificates curl chrony
+curl -fsSL https://get.docker.com | sudo sh
+sudo systemctl enable --now docker chrony
+sudo usermod -aG docker $USER          # log out and in again, so docker works without sudo
+docker run --rm hello-world
+docker compose version
+```
+
+**Podman**，在 RHEL、Rocky 或 Alma Linux 上：
+
+```bash
+sudo dnf install -y podman podman-compose chrony
+sudo systemctl enable --now chronyd
+podman run --rm quay.io/podman/hello
+```
+
+使用 Podman 时，请在下面的每条命令中将 `docker` 换成 `podman`，将 `docker compose` 换成 `podman-compose`。
+
+---
+
+## 2. 网络和防火墙
+
+RTE 自己打开每一个连接。外部没有任何东西会访问它：
+
+| 从 | 到 | 端口 | 原因 |
+|---|---|---|---|
+| RTE 主机 | 应用，位于 `APP_URL`（如设置了 `HTTPS_PROXY` 则经过它） | 应用的端口，大多数代理之后为 `443` | 作业、作业文件及其输出所经过的套接字 |
+| RTE 主机 | 数据中心 2 的受管主机 | ssh（`22`）、WinRM、它们的 API | playbook 从这里运行 |
+| RTE 主机 | `ghcr.io` | `443` | 用于拉取镜像，除非镜像来自您自己的镜像仓库或文件（第 4 步） |
+
+不要为 RTE 开放任何入站端口。其 `PORT`（`8000`）只提供 `/live`、`/ready` 和 `/metrics`，供本机上的探针使用。
+
+RTE 以 WebSocket 方式连接加上 `/api/v2/rte/socket` 的 `APP_URL`。应用前面的反向代理必须为该路径转发
+协议升级（参见 [运行器 WebSocket](../production/reverse-proxy.html#runner-websockets)）。在这里检查应用是否应答：
+
+```bash
+curl -sS https://forms.example.com/api/v2/version
+```
+
+---
+
+## 3. 文件夹
+
+所有内容都放在 `/opt/af-rte` 下。RTE 以用户 `node`（uid 1000）运行，因此其数据归该 uid 所有：
+
+```bash
+sudo mkdir -p /opt/af-rte/data/{ssh,certificates,ansible/roles,ansible/collections,git}
+sudo touch /opt/af-rte/data/ansible/ansible.cfg /opt/af-rte/data/git/.gitconfig
+```
+
+| 文件夹 | 在容器中 | 保存的内容 |
+|---|---|---|
+| `data/` | `/app/dist/persistent` | spool（`rte-spool`：每个作业的输出和结束状态，直到应用保存它们）、应用发来的作业文件（`rte-files`）、私有 CA、playbook 安装的 python 库 |
+| `data/ssh/` | `/home/node/.ssh` | playbook 的 ssh 密钥和 `known_hosts` |
+| `data/ansible/` | `/etc/ansible/...` | 您自己的 `ansible.cfg`、角色和集合，以挂载而非打包进镜像的方式提供 |
+
+请将 `data/` 保留在主机上：重启后的 RTE 仍会发送应用尚未保存的内容，并保留其作业文件缓存。
+
+**ssh 密钥。** 复制 playbook 在数据中心 1 使用的密钥，或者为此数据中心生成一个，并将其公钥部分提供给受管主机：
+
+```bash
+sudo ssh-keygen -t ed25519 -N "" -C "ansibleforms-rte-dc2" -f /opt/af-rte/data/ssh/id_ed25519
+sudo cat /opt/af-rte/data/ssh/id_ed25519.pub      # add it to ~/.ssh/authorized_keys of the managed user on each host
+sudo sh -c 'ssh-keyscan host1.dc2.example.com host2.dc2.example.com >> /opt/af-rte/data/ssh/known_hosts'
+```
+
+然后将所有内容交给 uid 1000，并使密钥只有其所有者可读：
+
+```bash
+sudo chown -R 1000:1000 /opt/af-rte/data
+sudo chmod 700 /opt/af-rte/data/ssh && sudo chmod 600 /opt/af-rte/data/ssh/id_*
+```
+
+---
+
+## 4. 镜像
+
+二选一。
+
+### 选项 A：官方镜像
+{: .no_toc }
+
+已发布的镜像位于 GitHub Container Registry 上，公开可用，无需登录（三个层级参见 [镜像](images.html)）。
+请使用与数据中心 1 相同的层级。`:7` 跟随最新的 7 版本，与应用的 `:7` 一致：
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+无法访问互联网的主机可以从能访问的主机获取镜像：
+
+```bash
+# on a host with internet
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+docker save ghcr.io/ansibleforms/ansibleforms-rte-full:7 | gzip > rte-full-7.tar.gz
+# copy the file to the RTE host, then there
+docker load < rte-full-7.tar.gz
+```
+
+或者将其推送一次到您自己的镜像仓库（`docker tag` 和 `docker push`），并在后续步骤中使用该名称。
+
+### 选项 B：您自己的镜像
+{: .no_toc }
+
+当数据中心 2 的 playbook 需要官方镜像中没有的集合或 python 库时（例如用于此数据中心
+vCenter 的 VMware 相关内容），请基于 `ansibleforms-rte-core` 构建：
+
+```bash
+sudo mkdir -p /opt/af-rte/build
+sudo tee /opt/af-rte/build/Dockerfile >/dev/null <<'EOF'
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+# the collections and python libraries these playbooks use : no root needed, both belong to node
+RUN ansible-galaxy collection install community.vmware -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir pyvmomi
+EOF
+docker build --pull -t af-rte-dc2 /opt/af-rte/build
+```
+
+应用每发布一个新版本，都要重新构建它（参见 [构建您自己的 RTE](images.html#build-your-own-rte)）。有多台 RTE 主机时，构建
+一次并推送到您自己的镜像仓库。离线时，像选项 A 一样对构建好的镜像使用 `docker save` 和 `docker load`。
+
+---
+
+## 5. 设置
+
+为它生成一个新的 [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN)，至少 16 个字符。它就是这个 RTE 的密码：应用
+将其保存在运行器的 RTE 凭据中，并用它密封每个作业的密钥。
+
+```bash
+openssl rand -base64 24
+```
+
+```bash
+sudo tee /opt/af-rte/rte.env >/dev/null <<'EOF'
+RTE_MODE=outbound
+APP_URL=https://forms.example.com
+RTE_NAME=rte-dc2
+RTE_TOKEN=<the new token>
+# optional, the first time only : approved at once instead of waiting for an admin
+RTE_JOIN_TOKEN=<afj_..., or remove this line>
+PORT=8000
+PYTHONPATH=/app/dist/persistent/python/lib
+EOF
+sudo chmod 600 /opt/af-rte/rte.env
+```
+
+| 变量 | 含义 |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | `outbound`：RTE 主动连接应用。没有它时，RTE 以已弃用的数据库模式启动 |
+| [`APP_URL`](../customization/server.html#env_APP_URL) | 应用的地址，`http://` 或 `https://`，如有基础路径也要包括 |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | 其运行器的名称。未设置时：使用其节点 ID `rte-<hostname>-<port>`，它会随容器变化 |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | 它自己的令牌，至少 16 个字符。请妥善保存：此后运行器都用它登录 |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | 可选：加入令牌，仅在其运行器尚不存在或正在等待批准时使用 |
+
+当网络需要时，添加以下变量：
+
+| 变量 | 何时需要 |
+|---|---|
+| `HTTPS_PROXY`、`NO_PROXY` | RTE 通过代理访问应用：`HTTPS_PROXY=http://proxy.dc2.example.com:3128`。列在 `NO_PROXY` 中的主机（以逗号分隔，域名写作 `.example.com`）会直接连接 |
+| `NODE_EXTRA_CA_CERTS` | 应用的证书来自私有 CA：将 CA 的证书放到 `/opt/af-rte/data/certificates/ca.pem`，并设置 `NODE_EXTRA_CA_CERTS=/app/dist/persistent/certificates/ca.pem` |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `0` 接受应用的任何证书，包括自签名证书。仅限在一个受信任的网络内部使用：优先使用 `NODE_EXTRA_CA_CERTS` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer`（默认）随每个作业获取 playbook 和清单。保持不变，除非您自己在 RTE 上挂载它们（`local`） |
+
+RTE 读取的其他设置见 [运行 RTE](run.html#settings)。`RTE_MAX_JOBS`、`RTE_CACHE_MB`、`RTE_FILES` 和
+`RTE_DRAIN_SECONDS` 也可以稍后在其运行器页面上设置，那里的值优先于变量（参见
+[RTE 的设置](../runners/runner-page.html#an-rtes-settings)）。
+
+---
+
+## 6. 启动
+
+compose 文件将整个定义与设置放在同一个地方。将第 4 步的镜像填入 `image:`：
+
+```bash
+sudo tee /opt/af-rte/compose.yml >/dev/null <<'EOF'
+services:
+  rte:
+    image: ghcr.io/ansibleforms/ansibleforms-rte-full:7   # or af-rte-dc2, the image you built
+    container_name: af_rte_dc2
+    restart: unless-stopped
+    # the running playbooks get RTE_DRAIN_SECONDS (25) to finish when the container stops
+    stop_grace_period: 40s
+    env_file: rte.env
+    # the probes, on this host only : nothing connects to an outbound RTE
+    ports:
+      - "127.0.0.1:8000:8000"
+    healthcheck:
+      test: ["CMD", "node", "./healthcheck.js"]
+      interval: 10s
+      timeout: 5s
+      retries: 30
+      start_period: 30s
+    volumes:
+      - ./data:/app/dist/persistent
+      - ./data/ssh:/home/node/.ssh
+      - ./data/git/.gitconfig:/home/node/.gitconfig
+      - ./data/ansible/ansible.cfg:/etc/ansible/ansible.cfg
+      - ./data/ansible/roles:/etc/ansible/roles
+      - ./data/ansible/collections:/etc/ansible/collections
+EOF
+cd /opt/af-rte && docker compose up -d
+```
+
+重启后 Docker 会再次启动它（`unless-stopped`）。Podman 没有守护进程来做这件事：请启用 `podman-restart.service`
+（`sudo systemctl enable --now podman-restart`），或者使用 Quadlet 文件将容器作为 systemd 服务运行。在 SELinux
+处于强制模式的主机上，请为每个卷加上 `:Z`（`./data:/app/dist/persistent:Z`）。
+
+不使用 compose 时，用一条命令运行同样的容器：
+
+```bash
+docker run -d --name af_rte_dc2 --restart unless-stopped --stop-timeout 40 \
+  --env-file /opt/af-rte/rte.env -p 127.0.0.1:8000:8000 \
+  -v /opt/af-rte/data:/app/dist/persistent \
+  -v /opt/af-rte/data/ssh:/home/node/.ssh \
+  -v /opt/af-rte/data/git/.gitconfig:/home/node/.gitconfig \
+  -v /opt/af-rte/data/ansible/ansible.cfg:/etc/ansible/ansible.cfg \
+  -v /opt/af-rte/data/ansible/roles:/etc/ansible/roles \
+  -v /opt/af-rte/data/ansible/collections:/etc/ansible/collections \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+---
+
+## 7. 在主机上检查
+
+```bash
+docker ps --filter name=af_rte_dc2        # STATUS ends in (healthy): the process listens
+docker logs -f af_rte_dc2                 # Ctrl+C to stop following
+curl -s http://127.0.0.1:8000/ready       # {"status":"ready"} once the socket to the app is open
+```
+
+日志显示 RTE 启动、连接应用并建立连接：
+
+```
+RTE 'rte-dc2' 7.3.0 (outbound, files transfer) listening on http port 8000, token fingerprint abcd-ef12
+RTE 'rte-dc2': dialing the app at wss://forms.example.com/api/v2/rte/socket
+RTE 'rte-dc2': connected to the app (node af-app1-8000)
+```
+
+没有加入令牌时，还会多一行说明它正在等待：
+`RTE 'rte-dc2': waiting for an admin to approve it under Connections > Runners (fingerprint abcd-ef12)`。请记下该指纹。
+
+在套接字打开之前，`/ready` 返回 `503` 和 `not connected to the app`。健康检查只能说明进程在监听。
+
+---
+
+## 8. 批准
+
+没有加入令牌时，RTE 会请求加入：**连接 > 运行器** 会在列表上方显示一条橙色提示，
+**1 个运行器等待批准**。打开它，核对 **指纹** 与 RTE 日志中的指纹一致，并且 **模式** 显示为
+出站，然后点击 **批准**（参见 [批准 RTE](../runners/registration.html#approving-an-rte)）。只有管理员才能批准。24 小时内
+无人处理的请求会被删除，RTE 下次连接应用时会再次请求。
+
+使用加入令牌时，运行器会立即获得批准，其描述中会注明该加入令牌。无论哪种方式，应用都会将 RTE 的令牌
+保存在一个新的 RTE 凭据 `rte-dc2-rte` 中，此后 RTE 都使用自己的 `RTE_TOKEN` 登录：`RTE_JOIN_TOKEN` 不再
+使用，您可以将其从 `rte.env` 中删除。
+
+---
+
+## 9. 在 AnsibleForms 中检查
+
+1. **连接 > 运行器** 列出运行器 `rte-dc2`，类型为 RTE。打开 **列 > 连接**，即可在列表中看到 **已连接**
+2. 打开它。其 **RTE** 选项卡显示 **模式** 为出站，**连接** 标记为 **已连接**；悬停时会显示持有该套接字的应用节点、
+   RTE 的版本以及其正在运行的作业数量
+3. 点击 **测试连接**：显示 **运行器连接正常**。它不调用任何东西：它读取哪个应用节点持有 RTE 的套接字
+   （`runner_leases`），并检查 RTE 连接时使用的协议约定
+4. 为它添加描述，例如 *Datacenter 2*
+5. 将 **默认** 保留在数据中心 1 的运行器上，除非所有没有 `runner:` 的 playbook 表单都应该在数据中心 2 运行
+
+**状态** 页面会在其他 RTE 旁边列出新的 RTE 及其版本。
+
+---
+
+## 10. 第一个作业
+
+用一个不做任何更改的 playbook 验证整个链路。在应用的 playbook 中（其 playbook 文件夹或仓库，与
+数据中心 1 相同），添加 `ping-dc2.yaml`：
+
+```yaml
+- name: Reach the hosts of datacenter 2
+  hosts: all
+  gather_facts: false
+  tasks:
+    - name: Ping
+      ansible.builtin.ping:
+```
+
+然后在设计器中添加一个指定新运行器的表单：
+
+```yaml
+name: Ping datacenter 2
+type: ansible
+playbook: ping-dc2.yaml
+runner: rte-dc2
+inventory: <an inventory with the hosts of datacenter 2>
+roles:
+  - admin
+categories:
+  - Default
+fields: []
+```
+
+启动它。应用随作业发送 playbook 文件夹和清单，RTE 按哈希保存它们，因此未改变的
+文件夹永远不会发送两次。输出以 `Running on RTE rte-dc2 (outbound)` 开头，每台主机都显示 `pong`，作业
+以成功结束。大于 [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB)（默认 512）的文件夹不会被
+发送：作业会失败并说明原因。
+
+---
+
+## 11. 将表单发给它
+
+表单在其指定的 RTE 上运行，因此请在数据中心 2 的每个表单中添加同样的一行：
+
+```yaml
+runner: rte-dc2
+```
+
+默认运行器和其他运行器类型参见 [运行器](../runners.html)。
+
+---
+
+## 出现故障时
+
+RTE 将 `notice` 及以上级别的内容写入 `docker logs`。在套接字打开之前失败的连接（DNS 名称、端口被拒绝、
+证书）只会以 `info` 级别显示为 `RTE: dialing the app again in <n> seconds`：请在 `rte.env` 中设置
+[`LOG_CONSOLE_LEVEL=debug`](../customization/logging.html#env_LOG_CONSOLE_LEVEL) 并重启它，即可看到
+`RTE: socket to wss://...: <the error>`。
+
+| 您看到的内容 | 位置 | 处理方法 |
+|---|---|---|
+| `RTE: set RTE_TOKEN (at least 16 characters) ; refusing to start` | `docker logs` | `rte.env` 中缺少 `RTE_TOKEN` 或其太短 |
+| `RTE: RTE_MODE=outbound needs APP_URL, the app's address (https://forms.example.com) ; refusing to start` | `docker logs` | 在 `rte.env` 中设置 `APP_URL` |
+| `RTE: APP_URL must be an http or https address, not ... ; refusing to start` | `docker logs` | `APP_URL` 必须以 `https://`（或 `http://`）开头 |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set)` | `docker logs` | `rte.env` 中缺少 `RTE_MODE=outbound` |
+| 没有 `connected to the app` 这一行，`/ready` 一直为 `503` | `docker logs`、`/ready` | 检查第 2 步的网络：从这台主机 `curl` 应用、代理（`HTTPS_PROXY`、`NO_PROXY`）、应用的证书（`NODE_EXTRA_CA_CERTS`，第 5 步）。设置 `LOG_CONSOLE_LEVEL=debug` 查看错误 |
+| `the app refused the socket (404)` 或 401、403 和 409 之外的其他状态 | `docker logs` | 反向代理没有转发 `/api/v2/rte/socket` 上的 WebSocket，或者 `APP_URL` 缺少应用的基础路径 |
+| `the app refused the socket (401): ... the token of RTE 'rte-dc2' is not the one stored for its runner: check its RTE_TOKEN` | `docker logs` | 已存在使用另一个令牌的运行器 `rte-dc2`。请将该令牌（运行器凭据的密码）提供给 RTE，或删除该运行器，让它请求加入 |
+| `the app refused the socket (401): ... the join token (RTE_JOIN_TOKEN) is unknown, revoked, expired or used up` | `docker logs` | 生成新的加入令牌，或删除 `RTE_JOIN_TOKEN` 并批准该 RTE（第 8 步） |
+| `the app refused the socket (409): ... runner 'rte-dc2' exists and is approved: a join token cannot give it a new token ...` | `docker logs` | RTE 使用新令牌重新安装了：请使用其运行器凭据的令牌，或请管理员修改它 |
+| `the app refused this RTE (401): dialing again in 10 minutes, or restart it once an admin acted` | `docker logs` | 出现在拒绝之后。修复原因后，执行 `docker restart af_rte_dc2`，而不必等待 |
+| `waiting for an admin to approve it under Connections > Runners` | `docker logs` | 批准它（第 8 步）。它已连接，但在此之前不接收作业 |
+| `the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds` | `docker logs` | 应用和 RTE 运行的版本使用不同的 [协议约定](images.html#the-contract)：将 RTE 更新到应用的版本（参见“更新”） |
+| **未连接**，或 **测试连接** 显示 *the RTE 'rte-dc2' (outbound) is not connected: it has not dialed the app* | 应用 | 没有任何应用节点持有其套接字：RTE 已停止，或无法访问应用。请查看其 `docker logs` |
+| 作业等待后失败，显示 *no app node holds a socket to RTE 'rte-dc2' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?* | 作业的输出 | 作业等待期间 RTE 没有连接 |
+| ssh 密钥上出现 `Permission denied` | 作业的输出 | `data/` 中的文件必须归 uid 1000 所有（第 3 步） |
+| 受管主机显示 `UNREACHABLE` | 作业的输出 | 从这台主机检查 ssh：密钥、`known_hosts`，以及通往主机的防火墙 |
+
+在应用一侧，被拒绝的 RTE 会在应用日志中显示为 `Refused an RTE socket from <address>: <why>`。
+
+---
+
+## 更新
+
+当应用升级到新版本时，也要在这台主机上跟进。在此期间，使用相同协议约定的 RTE 会继续工作；当某个版本
+修改了协议约定时，其发行说明会指出这一点（参见 [协议约定](images.html#the-contract)）。在 `compose.yml` 或
+Dockerfile 的 `FROM` 中使用 `:7` 时：
+
+```bash
+cd /opt/af-rte
+docker compose pull                 # option A; for option B: docker build --pull -t af-rte-dc2 build
+docker compose up -d
+docker image prune -f               # removes the image it no longer uses
+```
+
+请在其上没有 playbook 运行时更新：停止时会等待 `RTE_DRAIN_SECONDS`（25）让正在运行的 playbook 结束，届时仍在运行的
+会作为已放弃作业结束。它们在停止之前输出的内容会保留在 spool 中，并在 RTE 恢复后发送。离线时，在 `docker compose up -d` 之前
+先 `docker load` 新镜像（第 4 步）。
+
+---
+
+## 回退
+
+```bash
+cd /opt/af-rte && docker compose down     # or: docker rm -f af_rte_dc2
+```
+
+套接字关闭后，运行器会立即显示 **未连接**：不再有任何应用节点持有其套接字（`runner_leases`）。没有关闭套接字就消失的
+主机，会在应用节点在套接字上收不到任何消息后约一分钟内显示 **未连接**。运行器会保留：
+通过套接字加入的运行器永远不会被自动删除。请在 **连接 > 运行器** 下删除它，并在 **连接 > 凭据** 下删除其
+凭据 `rte-dc2-rte`。请先从引用它的表单中删除 `runner:` 行：在此之前，这些表单的作业会等待该 RTE，最长为
+`RTE_QUEUE_MINUTES`，然后失败。
+
+---
+
+## 扩充数据中心 2 的容量
+
+在数据中心 2 的更多主机上重复第 1 到第 9 步，每台主机都使用自己的 `RTE_NAME` 和 `RTE_TOKEN`，例如 `rte-dc2-b`：每个都作为
+独立的运行器加入，最多接收 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 个 playbook。表单用
+`runner:` 选择其中一个。两个使用相同 `RTE_NAME` 的 RTE 不会分担工作：第二个会从第一个那里接管套接字（参见
+[多个 RTE](several.html#several-rtes)）。
+
+---
+
+## 数据库模式的 RTE
+
+在 7.3.0 之前，本操作手册设置的是数据库模式的 RTE：它持有数据库凭据（`DB_*`、`ENCRYPTION_SECRET`），通过 `3306` 端口
+连接数据中心 1 的数据库，应用则通过其 `8000` 端口调用它。该模式自 7.3.0 起已弃用，并将在 8.0.0 中
+移除。要在不新建运行器的情况下将这样的 RTE 迁移到出站模式，请在其上设置 `RTE_MODE=outbound`、`APP_URL` 和 `RTE_NAME`（其
+运行器的名称），保留其 `RTE_TOKEN`，并删除 `DB_*`、`ENCRYPTION_SECRET` 和 `RTE_REGISTER`：参见
+[数据库（已弃用）](modes.html#database-deprecated)。然后关闭它不再需要的 `8000` 端口和数据库端口。
diff --git a/i18n/zh/_configure/rte/images.md b/i18n/zh/_configure/rte/images.md
new file mode 100644
index 0000000..62e12b4
--- /dev/null
+++ b/i18n/zh/_configure/rte/images.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: 镜像
+parent: RTE
+nav_order: 1
+translated_from: cb917c5cb9cbca9d530398171265e91f1ba8e94b
+---
+
+# RTE 镜像
+{: .no_toc }
+
+三种已发布的 RTE 镜像，以及包含您的 playbook 所用集合和库的自定义 RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## RTE 镜像
+
+RTE 分三层发布，每一层都基于前一层构建，标签与应用相同（参见 [镜像标签](../installation/#image-tags)）：
+
+| 镜像 | 包含的内容 | 用途 |
+|---|---|---|
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | Node.js 和 AnsibleForms 服务器、git、ssh 和 sshpass。没有 python，也没有 ansible，因此它本身无法运行 playbook | 用您自己的 python 和 ansible 版本构建 RTE |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | base 层，加上 python 3.14、ansible-core 和一些常用库（`jmespath`、`netaddr`、`requests`、`paramiko`）。没有集合 | 构建只包含您的 playbook 所用集合和库的更小的 RTE |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | core 层，加上基于同一 ansible-core 的 `ansible` 包，以及 AnsibleForms 6.5 镜像中原有的内容：NetApp、AWS 和 community 集合、`pandas`、`pyvmomi`、`boto3`、mariadb 客户端、ytt 和一些操作系统工具 | **默认镜像。** 直接运行即可：来自 6.5 的 playbook 能找到它们原来使用的内容 |
+
+与应用镜像一样，每一层都以用户 `node`（uid 1000）运行，playbook 也以该用户运行。
+
+---
+
+## 构建您自己的 RTE
+
+基于 `ansibleforms-rte-core` 构建，并添加您的 playbook 所用的集合和 python 库。这个 NetApp 示例是
+[examples/rte](https://github.com/ansibleforms/ansibleforms/tree/main/examples/rte) 中的 Dockerfile 之一：
+
+```dockerfile
+FROM ghcr.io/ansibleforms/ansibleforms-rte-core:7
+RUN ansible-galaxy collection install netapp.ontap -p /usr/share/ansible/collections \
+ && pip install --no-cache-dir netapp-lib netapp-ontap
+```
+
+python 环境和集合文件夹归 `node` 所有，因此这些安装不需要 root。安装操作系统
+软件包的层需要为此切换到 `USER root`，并在最后切换回 `USER node`。要使用您自己的 python 和 ansible，请基于
+`ansibleforms-rte-base` 构建（同一文件夹中的 `Dockerfile.own-ansible`）。
+
+请让镜像与应用的版本保持一致：`:7` 跟随应用的 `:7`。集合和角色也可以挂载而不是打包进镜像，挂载到
+`/etc/ansible/collections` 和 `/etc/ansible/roles`。这样每次修改都无需重新构建，但运行的内容取决于该卷；
+python 库则始终要放进镜像。将所有内容打包进镜像可以复现且启动快，因此是生产环境的做法。
+
+---
+
+## 协议约定
+
+应用和 RTE 必须共享的是它们的协议约定，即双方都会报告的一个编号。只要双方使用相同的协议约定，旧版本的 RTE 就能继续与较新的
+应用配合工作；当某个版本修改了它时，其发行说明会指出 RTE 必须更新。每种模式
+都有自己的协议约定：
+
+| 模式 | 协议约定 | 不匹配时 |
+|---|---|---|
+| 出站、入站 | 3，7.3.0 新增 | 应用以代码 `4409` 关闭该 RTE 的套接字，并记录 *RTE '&lt;name&gt;' speaks contract &lt;n&gt;, this app (&lt;release&gt;) contract 3: refused*。出站 RTE 会记录 *the app speaks another contract (an upgrade in progress?): dialing again in 60 seconds*。以其他协议约定发送的作业会被拒绝 |
+| 数据库（已弃用） | 2，自 7.0.0 起 | RTE 拒绝应用的作业 |
+
+运行器上的 **测试连接** 会说明 RTE 使用哪个协议约定以及应用需要哪一个（参见
+[测试连接](../runners/runner-page.html#test-connection)），**状态** 页面的 **运行器** 行也会执行相同的检查。
diff --git a/i18n/zh/_configure/rte/index.md b/i18n/zh/_configure/rte/index.md
new file mode 100644
index 0000000..7657674
--- /dev/null
+++ b/i18n/zh/_configure/rte/index.md
@@ -0,0 +1,275 @@
+---
+layout: default
+title: RTE
+nav_order: 10
+has_children: true
+has_toc: false
+permalink: /rte/
+translated_from: 2c3f3f81ad8faaf18eac56f18782ef5f78111b04
+---
+
+# 运行时环境（RTE）
+{: .no_toc }
+
+RTE 是什么、它如何运行 playbook，以及它可以接触哪些内容
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：在运行 RTE、确定其规格或将其迁移到另一个网络之前，先了解 RTE。
+
+| 页面 | 内容 |
+|---|---|
+| [镜像](images.html) | 三种 RTE 镜像，以及构建包含您的 playbook 所用集合的自定义镜像 |
+| [模式](modes.html) | 出站、入站或数据库模式：谁打开连接、spool、作业的文件 |
+| [运行 RTE](run.html) | 每种模式的设置，以及每种模式的 `docker run` 示例 |
+| [多个 RTE](several.html) | 容量、同一地址后的副本，以及 RTE 停止或宕机时会发生什么 |
+| [另一个数据中心](another-datacenter.html) | 操作手册：在第二个数据中心添加 RTE，从一台裸主机到运行第一个作业 |
+
+---
+
+## RTE 是什么
+
+AnsibleForms 7 不在应用容器中运行任何 playbook。`ansible` 表单的作业会交给类型为 `rte` 的
+[运行器](../runners.html)，即运行时环境：以 `AF_ROLE=rte` 启动的 AnsibleForms 服务器，搭配 python 和 ansible，没有 Web
+界面。它通过一个 WebSocket 与应用通信，不持有任何数据库凭据
+（[`RTE_MODE`](../customization/server.html#env_RTE_MODE) 为 `outbound` 或 `inbound`，参见 [模式](modes.html)）：应用将作业发给它，
+RTE 运行 `ansible-playbook`，应用保存它发回的输出和最终状态，浏览器再从应用读取这些内容。
+
+应用解析作业的凭据，并以仅供该 RTE 和该作业使用的密封形式交给 RTE。RTE 从不读取
+凭据表或密钥库，playbook 也不会继承 AnsibleForms 自身的环境变量
+（`ENCRYPTION_SECRET`、`DB_*`、`RTE_TOKEN` 等）：请将这类值作为 extravar 或凭据传入。7.0 到 7.2 的 RTE
+会自己读写数据库，它在 7.x 中仍以已弃用的数据库模式运行（参见 [数据库模式](#database-mode-deprecated)）。
+
+---
+
+## RTE 如何运行
+
+RTE 是您自己运行的容器，可以位于应用旁边，也可以位于另一个网络中：AnsibleForms 从不创建 RTE。下面依次介绍
+它在哪里运行、与应用共享什么，以及从表单启动到 playbook 进程结束的整个过程中，
+其内部发生了什么：
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afr-title afr-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afr-title">RTE 如何运行 playbook</title>
+<desc id="afr-desc">在由运维人员管理的容器主机或 Kubernetes 集群中，应用容器与一个或多个 RTE 容器之间各保持一个 WebSocket，由应用（入站）或由 RTE（出站）打开。只有应用与数据库通信。1：浏览器在应用上启动表单。2：应用将作业保存到数据库，选择运行器，并为其密封作业的密钥。3：应用通过套接字发送作业。4：RTE 认领作业，并从其缓存或从应用获取作业的文件。5：RTE 以子进程方式启动 ansible-playbook，每个作业一个，最多 RTE_MAX_JOBS 个。6：playbook 访问受管主机。7：RTE 将输出、事件和结束状态写入其 spool，并通过套接字发送；应用将它们保存到数据库并确认收到。8：浏览器通过应用跟踪作业。只有在 RTE_FILES=local 时，应用的卷才会挂载到 RTE 中。</desc>
+<style>
+.afr-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afr-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afr-solid{fill:var(--body-background-color)}
+.afr-back{stroke-opacity:.45}
+.afr-zone{fill:none;stroke:currentColor;stroke-opacity:.5;stroke-width:1.3;stroke-dasharray:7 5}
+.afr-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afr-proc{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-opacity:.6;stroke-width:1}
+.afr-opt{stroke-dasharray:5 4}
+.afr-t{fill:currentColor;font-size:13px;font-weight:600}
+.afr-p{fill:currentColor;font-size:12px;font-weight:600}
+.afr-s{fill:var(--af-muted);font-size:11px}
+.afr-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afr-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afr-ws{stroke:var(--link-color);stroke-width:2;fill:none}
+.afr-n{fill:var(--link-color)}
+.afr-nt{fill:var(--body-background-color);font-size:11px;font-weight:700}
+</style>
+<defs>
+<marker id="afr-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afr-zone" x="165" y="20" width="425" height="380" rx="14"/>
+<text class="afr-h" x="181" y="44">容器主机或 Kubernetes 集群</text>
+<text class="afr-s" x="181" y="61">由您运行；出站 RTE 可以位于另一个网络</text>
+<rect class="afr-box" x="12" y="106" width="118" height="64" rx="10"/>
+<text class="afr-t" x="71" y="133" text-anchor="middle">浏览器</text>
+<text class="afr-s" x="71" y="151" text-anchor="middle">表单、作业页面</text>
+<rect class="afr-main" x="190" y="90" width="140" height="262" rx="12"/>
+<text class="afr-h" x="260" y="114" text-anchor="middle">应用容器</text>
+<text class="afr-s" x="260" y="131" text-anchor="middle">Web 应用、API、worker</text>
+<rect class="afr-inner" x="202" y="142" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="161" text-anchor="middle">运行器</text>
+<text class="afr-s" x="260" y="177" text-anchor="middle">密封密钥</text>
+<rect class="afr-inner" x="202" y="296" width="116" height="44" rx="8"/>
+<text class="afr-t" x="260" y="315" text-anchor="middle">RTE 中枢</text>
+<text class="afr-s" x="260" y="331" text-anchor="middle">保存后确认</text>
+<rect class="afr-main afr-solid afr-back" x="411" y="74" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid afr-back" x="403" y="82" width="165" height="278" rx="12"/>
+<rect class="afr-main afr-solid" x="395" y="90" width="165" height="278" rx="12"/>
+<text class="afr-h" x="477" y="114" text-anchor="middle">RTE 容器</text>
+<text class="afr-s" x="477" y="131" text-anchor="middle">AF_ROLE=rte, uid 1000</text>
+<rect class="afr-inner" x="407" y="142" width="141" height="38" rx="8"/>
+<text class="afr-t" x="469" y="160" text-anchor="middle">作业文件</text>
+<text class="afr-s" x="469" y="174" text-anchor="middle">按哈希缓存</text>
+<rect class="afr-proc" x="407" y="206" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="224" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc" x="407" y="242" width="141" height="28" rx="6"/>
+<text class="afr-p" x="477" y="260" text-anchor="middle">ansible-playbook</text>
+<rect class="afr-proc afr-opt" x="407" y="278" width="141" height="28" rx="6"/>
+<text class="afr-s" x="477" y="296" text-anchor="middle">最多 RTE_MAX_JOBS 个</text>
+<rect class="afr-inner" x="407" y="318" width="141" height="40" rx="8"/>
+<text class="afr-t" x="477" y="336" text-anchor="middle">Spool</text>
+<text class="afr-s" x="477" y="351" text-anchor="middle">保留至确认</text>
+<text class="afr-p" x="362" y="245" text-anchor="middle">一个</text>
+<text class="afr-p" x="362" y="260" text-anchor="middle">Web-</text>
+<text class="afr-p" x="362" y="275" text-anchor="middle">Socket</text>
+<rect class="afr-box" x="616" y="190" width="136" height="60" rx="10"/>
+<text class="afr-t" x="684" y="215" text-anchor="middle">受管主机</text>
+<text class="afr-s" x="684" y="233" text-anchor="middle">ssh, WinRM, APIs</text>
+<rect class="afr-box afr-opt" x="616" y="276" width="136" height="74" rx="10"/>
+<text class="afr-t" x="684" y="300" text-anchor="middle">应用的卷</text>
+<text class="afr-s" x="684" y="318" text-anchor="middle">playbook、清单</text>
+<text class="afr-s" x="684" y="334" text-anchor="middle">仅 RTE_FILES=local</text>
+<rect class="afr-box" x="190" y="430" width="140" height="60" rx="10"/>
+<text class="afr-t" x="260" y="455" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afr-s" x="260" y="473" text-anchor="middle">仅供应用使用</text>
+<line class="afr-line" x1="130" y1="124" x2="188" y2="124" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="188" y1="152" x2="132" y2="152" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="330" y1="161" x2="393" y2="161" marker-end="url(#afr-arrow)"/>
+<line class="afr-ws" x1="393" y1="338" x2="332" y2="338" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="440" y1="180" x2="440" y2="204" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="576" y1="220" x2="614" y2="220" marker-end="url(#afr-arrow)"/>
+<line class="afr-line afr-opt" x1="576" y1="313" x2="614" y2="313" marker-start="url(#afr-arrow)" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="225" y1="352" x2="225" y2="428" marker-end="url(#afr-arrow)"/>
+<line class="afr-line" x1="295" y1="352" x2="295" y2="428" marker-end="url(#afr-arrow)"/>
+<circle class="afr-n" cx="148" cy="124" r="9"/><text class="afr-nt" x="148" y="128" text-anchor="middle">1</text>
+<circle class="afr-n" cx="225" cy="405" r="9"/><text class="afr-nt" x="225" y="409" text-anchor="middle">2</text>
+<circle class="afr-n" cx="361" cy="161" r="9"/><text class="afr-nt" x="361" y="165" text-anchor="middle">3</text>
+<circle class="afr-n" cx="532" cy="161" r="9"/><text class="afr-nt" x="532" y="165" text-anchor="middle">4</text>
+<circle class="afr-n" cx="461" cy="192" r="9"/><text class="afr-nt" x="461" y="196" text-anchor="middle">5</text>
+<circle class="afr-n" cx="595" cy="220" r="9"/><text class="afr-nt" x="595" y="224" text-anchor="middle">6</text>
+<circle class="afr-n" cx="361" cy="338" r="9"/><text class="afr-nt" x="361" y="342" text-anchor="middle">7</text>
+<circle class="afr-n" cx="295" cy="405" r="9"/><text class="afr-nt" x="295" y="409" text-anchor="middle">7</text>
+<circle class="afr-n" cx="148" cy="152" r="9"/><text class="afr-nt" x="148" y="156" text-anchor="middle">8</text>
+</svg>
+</div>
+
+无论哪一方打开连接，图中每个 RTE 都只有一个套接字：应用主动连接入站 RTE，出站 RTE 主动连接应用（参见
+[模式](modes.html)）。连接打开后，相同的消息在两个方向上传递，并且只有应用读写数据库。
+
+**谁来启动它。** RTE 是一个长期运行的容器，由运行您其他容器的系统启动。它等待作业，
+在作业之间保持运行：
+
+| AnsibleForms 的运行方式 | 谁启动 RTE |
+|---|---|
+| `docker run` 或 `podman run` | 您自己，使用类似 [运行 RTE](run.html) 中的命令，在任何能访问应用或应用能访问的主机上运行 |
+| [Docker Compose](../installation/docker-compose.html) | `docker-compose.yml` 中的 `rte` 服务，与 `app` 和 `mysqldb` 并列。其配置种子将它声明为默认运行器 `rte`，入站模式，地址为 `http://rte:8000` |
+| [Helm chart](../installation/kubernetes.html) | Kubernetes，作为应用 pod 中名为 `rte` 的第二个容器（`containers.rte`）。应用在 `127.0.0.1` 上以入站模式连接它，chart 的种子将它声明为默认运行器 |
+| [安装程序](../installation/installer.html) | 如上所述的 Docker Compose 或 Helm chart，或 [不使用容器](../installation/native.html) 的 systemd 服务；它自己的运行器会请求加入，并等待管理员批准 |
+
+容器引擎由您负责：主机上的 Docker 或 Podman，或 Kubernetes 集群的容器运行时，由您安装并保持
+更新。AnsibleForms 从不与它通信。应用和 RTE 都不会调用 Docker 或 Podman、挂载它们的套接字或启动
+容器：应用只通过套接字与 RTE 通信。
+
+**里面有什么。** 一个容器，只包含运行 playbook 所需的内容：
+
+* **服务器**：与应用相同的 Node.js 服务器，在 `tini` 下以 `AF_ROLE=rte`（在镜像中设置）启动
+* **省略的部分**：Web 界面、登录、调度器、worker 以及所有数据库模块，此角色不会加载它们
+* **监听的内容**：其 `PORT`（`8000`）：用于探针的 `/live` 和 `/ready`、用于 Prometheus 的 `/metrics`，入站模式下还有应用
+  连接的套接字 `/rte/v1/socket`。出站 RTE 不接受来自应用的连接
+* **Python 和 ansible**：由您选择的镜像层提供（参见 [RTE 镜像](images.html)）
+* **用户**：服务器和每个 playbook 都以 `node`（uid 1000）运行，从不以 root 运行
+
+**与应用共享什么。** 它的令牌；使用 `RTE_FILES=local` 时还有应用的文件。使用默认的 `RTE_FILES=transfer` 时，
+playbook 和清单随每个作业一起传送，RTE 不需要共享磁盘：
+
+| 与应用共享 | RTE 用它做什么 |
+|---|---|
+| `RTE_TOKEN` | 在连接应用时出示它（出站），或在应用连接它时检查它（入站）。应用在运行器的 RTE 凭据中保存相同的值，作业的密钥也用它密封 |
+| 持久化卷 `/app/dist/persistent`，仅在 `RTE_FILES=local` 时 | playbook 文件夹（[`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)），或 worker 克隆到 [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) 下的 playbook 仓库、清单（[`INVENTORY_PATH`](../customization/paths.html#env_INVENTORY_PATH) 和清单仓库）以及上传文件。RTE 会将作业的 extravars 文件写入 playbook 文件夹，因此请以读写方式挂载 |
+| ssh 文件夹 `/home/node/.ssh` | playbook 的 ssh 连接所用的私钥和 `known_hosts`：挂载应用的（在其设置页面上管理），或为 RTE 提供它自己的 |
+
+RTE 不克隆任何内容：仓库通过作业的文件到达它，或位于它与应用共享的卷上。集合、角色和
+`ansible.cfg` 来自镜像，或者来自您挂载到 `/etc/ansible/collections`、`/etc/ansible/roles` 和 `/etc/ansible/ansible.cfg`
+的文件夹（Docker Compose 项目就是这样做的），或者来自 playbook 旁边的 `ansible.cfg`。
+
+**作业的生命周期。** 下面的编号与图中的编号对应，适用于从浏览器或 API 启动的 playbook 表单：
+
+1. **启动**：应用检查表单及其值，构建 extravars，并以状态 `running` 保存作业。带有
+   [审批](../forms/approval.html) 的表单会在这里停住，直到审批人接受，在此之前不会到达任何 RTE
+2. **选择运行器**：应用使用表单以 `runner: <name>` 指定的 RTE，否则使用类型为 RTE 的默认运行器，并将其
+   名称保存在作业上。它从数据库或 [密钥库](../secret-stores/) 解析作业的凭据、ansible 登录信息和
+   vault 密码，并用 AES-256-GCM 以从该运行器令牌和作业 ID 派生的密钥将其密封
+3. **交接**：持有该 RTE 套接字的应用节点将作业发给它：extravars、表单的选项、密封的密钥以及
+   作业文件的哈希。任何应用节点都可以启动作业；持有套接字的节点会在两秒内发送。RTE 已满
+   或未连接时，作业会等待，最长为 [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)
+4. **认领**：RTE 回复 `claimed`；当它已满、正在停止、无法打开密钥，或作业带有与其自身不同的
+   [协议约定](images.html#the-contract) 时，回复 `refused`。使用 `RTE_FILES=transfer` 时，它按哈希从缓存中获取 playbook 和清单，
+   向应用请求它没有的哈希，并将它们解压到作业专属的文件夹中
+5. **开始**：在 playbook 文件夹（加上表单的 `playbookSubPath`，该路径必须存在）中写入两个文件：包含表单值和凭据的
+   `extravars_<id>.json`，以及一个包含 ansible 登录信息的隐藏文件。然后它以自己的子进程启动 `ansible-playbook`，
+   不经过 shell，位于独立的进程组中，使用 `-e @` 指向这些文件，每个清单一个 `-i`，并带上表单的 tags、limit、check、
+   diff 和详细级别。vault 密码通过 stdin 传入，从不写入文件或命令行，进程以
+   `node` 身份在经过过滤的环境中运行（见下文）
+6. **运行**：playbook 从 RTE 容器连接受管主机，通过 ssh 使用 `/home/node/.ssh` 中的密钥和 `known_hosts`，
+   密码登录时使用 `sshpass`，或者通过其模块调用的 API。需要能访问这些主机的是 RTE，而不是应用
+7. **输出与结束**：RTE 每半秒或每 64 KB 将 stdout 和 stderr 打包一次，掩码凭据，并为每批
+   编号。它在发送之前会把每一项写入其磁盘上作业的 spool：输出、事件、
+   `.joblogs/job_log_<id>.log` 中的作业日志（每 2 秒）、开始以及带有最终状态（`success`、`failed` 或 `aborted`）的结束。应用
+   每一项只保存一次并确认收到，结束状态保存后，RTE 会丢弃该 spool。某个流超过
+   [`PROCESS_MAX_BUFFER`](../customization/server.html#env_PROCESS_MAX_BUFFER) 字节（默认 50 MB）后，它不再发送更多内容，
+   playbook 继续运行。然后应用发送表单的 [通知](../forms/notifications.html)
+8. **跟踪**：浏览器从不与 RTE 通信：表单页面每 2 秒通过应用重新读取作业，作业页面
+   则在应用保存每一项时实时跟踪
+
+**套接字断开。** playbook 继续运行。RTE 重新连接（出站），或某个应用节点再次连接它（入站），并重新发送
+应用尚未确认的内容：应用会跳过已经保存的内容，因此不会丢失任何一行，也不会重复保存。前提是套接字
+在两分钟内恢复：应用只在套接字打开时写入 RTE 的心跳，一旦该心跳已过去两分钟，
+worker 就会将该 RTE 正在运行的作业作为已放弃作业结束，即使其 playbook 仍在运行。请将 spool
+（[`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)）放在卷上，这样重启后的 RTE 仍能发送它保留的内容。
+RTE 重启时正在运行的 playbook 无法继续：当 RTE 回来时没有它，应用会将其作业作为已放弃作业结束。
+
+**中止。** 中止会设置作业的中止标志，持有该 RTE 套接字的应用节点会在两秒内发送 `cancel`。RTE
+向 playbook 的进程组发送 `SIGTERM`，因此 `ansible-playbook` 及其启动的每个分支进程会一起停止，作业以
+`aborted` 结束。早于作业到达的取消请求会保留一分钟，作业随后以中止状态开始。
+
+**清理。** 进程一旦退出，无论结果如何，RTE 都会删除两个 extravars 文件（设置了 `keepExtravars` 的表单
+会保留可见的那个，但从不保留隐藏的那个）、`/tmp` 中的工件文件、作业日志文件以及作业专属的文件文件夹。
+结束状态只保存一次：第二个写入者（例如应用让 RTE 已经结束的作业失败）不会改变任何内容。
+
+**每个作业一个进程，而不是每个作业一个容器。** AWX 和 AAP 会为每个作业从执行环境镜像启动一个新的 pod 或容器。
+AnsibleForms 不启动任何东西：RTE 容器已经在运行，每个作业都是其中的一个子进程。作业启动时
+无需拉取镜像或调度 pod，AnsibleForms 也不需要您的容器引擎或集群的任何权限。相应地，
+在同一个 RTE 上运行的 playbook 共享其 CPU、内存、`/tmp`、主目录和 python：请为容器分配足够的资源，以运行
+`RTE_MAX_JOBS` 个 playbook 及其分支进程。要改变 playbook 可以使用的内容，请修改镜像，而不是作业。
+
+---
+
+## 安全边界
+
+RTE 运行的是表单作者编写的代码，因此它被设计为持有尽可能少的东西：
+
+* **只有它的令牌**：RTE 不持有数据库凭据，也没有 `ENCRYPTION_SECRET`。除了应用通过套接字使用其令牌发起的调用外，
+  它不接受任何调用，没有用户、没有登录，也没有网页。通过套接字，它只能运行应用发给它的作业、报告这些作业并
+  请求它们的文件：它不能创建作业、读取其他作业或分发凭据
+* **密封的密钥**：运行作业时，RTE 从不读取凭据表或密钥库。它获得的是自己运行的作业的密钥，
+  并且仅为其令牌和该作业 ID 密封，因此发给另一个 RTE 或另一个作业的数据包无法打开，被改动过一个字节的数据
+  也会被拒绝
+* **经过校验的连接**：出站时，RTE 校验应用的证书。通过 HTTPS 入站时，应用在 RTE 加入时固定其证书，
+  之后只有在 RTE 出示该证书时才会连接它（参见 [模式](modes.html#inbound)）。通过纯 HTTP 的入站 RTE 应位于
+  私有网络中，例如 Docker Compose 项目的网络
+* **不继承环境**：`ansible-playbook` 获得的 RTE 环境中去掉了 AnsibleForms 自己读取的所有变量
+  （`ENCRYPTION_SECRET`、`DB_PASSWORD`、`RTE_TOKEN`、`VAULT_TOKEN`、`ACCESS_TOKEN_SECRET`、`MYSQL_*` 等），因此
+  `lookup('env', ...)` 无法获取它们。您为 playbook 设置的变量（`PATH`、代理、`ANSIBLE_*`）会原样传递
+* **不使用来自用户的模板**：{% raw %}包含 `{{`、`{%` 或 `{#` 的表单值会以 unsafe 字符串的形式到达 playbook，{% endraw %}
+  ansible 从不对其进行模板渲染，除非表单设置了 `allowJinjaInExtravars`，并且命令行从不经过 shell 运行
+* **不是 root**：RTE 及其 playbook 以 `node`（uid 1000）运行，因此 playbook 能做的就是该用户在容器中能做的事，例如
+  读取其文件和 ssh 密钥，仅此而已
+
+请像对待应用一样谨慎对待它的容器、镜像和环境。
+
+---
+
+## 数据库模式（已弃用）
+
+7.0 到 7.2 的 RTE（没有 `RTE_MODE`）在整个 7.x 中都可以运行，并将在 8.0.0 中移除。它与上述步骤有四点不同：
+
+* **它持有数据库**：其 `DB_*` 设置，以及在自行注册时的 `ENCRYPTION_SECRET`
+  （[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER)）
+* **交接是一次 HTTP 调用**：应用携带令牌和密封的密钥调用 `POST <address>/rte/v1/jobs`，RTE 通过
+  在数据库中把自己的名称写到作业上来认领该作业（第 3 和第 4 步）
+* **它自己写入输出**：分批写入数据库，没有 spool（第 7 步）。中止通过作业的中止标志到达它，
+  它每 2 秒读取一次该标志，另外还有 `/cancel` 调用
+* **它从应用的卷读取文件**：它需要与应用相同的磁盘，与 `RTE_FILES=local` 相同
+
+其运行器页面上没有任何 [RTE 设置](../runners/runner-page.html#an-rtes-settings)：它读取自己的变量。要将其迁移到
+套接字模式，参见 [模式](modes.html#database-deprecated)。
diff --git a/i18n/zh/_configure/rte/modes.md b/i18n/zh/_configure/rte/modes.md
new file mode 100644
index 0000000..6f2ac51
--- /dev/null
+++ b/i18n/zh/_configure/rte/modes.md
@@ -0,0 +1,159 @@
+---
+layout: default
+title: 模式
+parent: RTE
+nav_order: 2
+translated_from: fbf98e6673b13575df08bda488a4b2881bd87ec0
+---
+
+# RTE 如何与应用通信
+{: .no_toc }
+
+出站、入站或数据库模式：谁打开连接，以及连接上传递什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：从 7.3.0 起，RTE 通过一个 WebSocket 与应用通信，不持有任何数据库凭据。请根据两者之间的网络选择
+合适的模式：谁可以向谁发起连接，以及连接经过哪些代理和防火墙。
+
+---
+
+## 三种模式
+
+RTE 上的 [`RTE_MODE`](../customization/server.html#env_RTE_MODE) 说明它如何访问应用；其运行器具有相同的 **模式**：
+
+| 模式 | 谁打开连接 | RTE 持有什么 | 适用场景 |
+|---|---|---|---|
+| `outbound` | RTE 在 [`APP_URL`](../customization/server.html#env_APP_URL) 主动连接应用，并保持一个打开的 WebSocket | 它的 `RTE_TOKEN`，没有数据库凭据 | DMZ、NAT，或不允许任何入站连接的区域：外部的任何连接都到达不了 RTE |
+| `inbound` | 应用按运行器的地址主动连接 RTE，并保持一个打开的 WebSocket | 它的 `RTE_TOKEN`，没有数据库凭据 | 由中心一侧发起所有连接的网络、compose 项目、pod |
+| `database`（已弃用） | 应用通过 HTTP 调用 RTE 的 API，RTE 自己读写应用的数据库 | 数据库凭据（`DB_*`）和 `ENCRYPTION_SECRET` | 7.0 到 7.2 的行为，将在 8.0.0 中移除 |
+
+没有 `RTE_MODE` 的 RTE 在整个 7.x 中都以数据库模式运行，并在启动时记录一条 `[DEPRECATED] This RTE runs in database mode` 警告。
+7.3.0 之前添加的运行器的模式为 **数据库（已弃用）**；迁移时，请将其设为其 RTE 实际运行的模式。
+
+---
+
+## 出站
+
+由 RTE 打开连接，因此它可以在完全不接受入站连接的网络中工作：
+
+* **套接字**：RTE 连接加上 `/api/v2/rte/socket` 的 `APP_URL`，使用 `wss://`（`http://` 地址则使用 `ws://`），并携带其
+  `RTE_TOKEN` 及其运行器名称 [`RTE_NAME`](../customization/server.html#env_RTE_NAME)。套接字断开时会重新连接
+* **第一次**：它请求加入，其运行器会在 **连接 > 运行器** 下等待管理员批准，此时已连接
+  但不接收作业（参见 [请求加入](../runners/registration.html#asking-to-join)）。加入令牌
+  [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) 可以立即批准它。此后它使用自己的令牌登录
+* **网络**：只需从 RTE 所在区域到应用的应用端口的连接，当 `HTTPS_PROXY` 指定时经过代理。应用前面的反向
+  代理必须允许该路径上的 WebSocket 通过（参见 [运行器 WebSocket](../production/reverse-proxy.html#runner-websockets)）
+* **证书**：会校验应用的证书。用 `NODE_EXTRA_CA_CERTS` 指定私有 CA，或者仅在一个受信任的网络内部，
+  用 [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY) 关闭校验
+* **运行器**：它不需要地址，因此其 RTE 凭据只保存令牌
+* **就绪**：在与应用的套接字打开之前，`/ready` 返回 `503`
+
+当负载均衡器之后有多个应用节点时，由 RTE 连接到的节点持有其套接字。任何节点都可以启动作业：持有
+套接字的节点会将作业发给 RTE；如果作业是在另一个节点上启动的，会在两秒内发送。
+
+---
+
+## 入站
+
+RTE 在其 `PORT` 上监听，应用按其运行器的地址加上 `/rte/v1/socket` 并携带 RTE 的令牌来连接它。当有
+多个应用节点时，同一时间由一个节点持有每个入站运行器的套接字；该节点停止时，另一个节点会接管并重新连接。
+
+应用在连接 RTE 之前需要有该 RTE 的运行器：类型为 RTE，模式为 **入站**，以及一个包含 RTE 地址及其
+`RTE_TOKEN` 的 RTE 凭据。有以下两种方式：
+
+| 方式 | 需要设置的内容 |
+|---|---|
+| RTE 请求加入 | `APP_URL` 和 [`RTE_URL`](../customization/server.html#env_RTE_URL)（应用连接的地址）。RTE 发起一次调用 `POST /api/v2/rte/register`，其运行器等待管理员批准：批准后应用就会连接它（参见 [请求加入](../runners/registration.html#asking-to-join)）。使用 `RTE_JOIN_TOKEN` 时会立即批准。设置了 `APP_URL` 但没有 `RTE_URL` 的入站 RTE 会拒绝启动 |
+| 您自己添加运行器 | 不设置 `APP_URL`：在 **连接 > 运行器** 下或在 [配置种子](../seed/) 中添加运行器，如 [运行 RTE](run.html#start-it) 所述 |
+
+Docker Compose 项目、Helm chart 和安装程序的控制器都以这种方式运行自己的 RTE：入站模式，由种子声明。
+
+**通过 HTTPS。** 当 [`HTTPS=1`](../customization/server.html#env_HTTPS) 时，RTE 通过 TLS 提供其套接字，使用
+[`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) 和 [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) 的密钥和证书
+（默认为其 `certificates` 文件夹中的 `key.pem` 和 `cert.pem`）。`RTE_URL` 为 `https://` 的 RTE 在请求加入时会发送该证书，
+应用会将其固定：只有当 RTE 出示同一证书时，应用才会连接它，因此自签名证书无需 CA 也能使用。
+RTE 在启动时记录证书的指纹（其 DER 字节的 SHA-256 的前 8 个十六进制数字，形如 `abcd-ef12`），
+批准对话框显示应用收到的指纹：批准之前请核对两者是否一致。
+[安装程序](../installation/installer.html#a-runner) 以这种方式设置其入站运行器，并使用其自身地址的证书。
+
+---
+
+## 数据库（已弃用）
+
+7.0 到 7.2 的 RTE：应用通过 HTTP 调用其 API，RTE 在数据库中认领作业、将输出写入数据库，并通过
+[`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) 保持自己的运行器行为最新。[数据库模式](./#database-mode-deprecated)
+说明了其步骤有何不同。它在 7.x 中仍然可用，每次启动时都会发出警告，并将在 8.0.0 中移除。
+
+要将这样的 RTE 迁移到套接字模式，请保留其运行器和令牌：
+
+1. 对于 [配置种子](../seed/) 中的运行器：先在种子中为它设置 `rte_mode: outbound` 或 `rte_mode: inbound`（入站：
+   在其凭据的 `url` 中填写应用连接的地址）。RTE 无法自行迁移由种子管理的运行器
+2. 在 RTE 上，设置 `RTE_MODE=outbound` 和 `APP_URL`，或设置 `RTE_MODE=inbound`（并设置 `APP_URL` 和 `RTE_URL` 以进行那一次
+   注册调用），并将 [`RTE_NAME`](../customization/server.html#env_RTE_NAME) 设为其运行器在
+   **连接 > 运行器** 下的名称。保留其 `RTE_TOKEN`
+3. 从其环境中删除 `DB_*` 和 `ENCRYPTION_SECRET`，以及只有数据库模式才读取的 `RTE_REGISTER`，然后重启它
+
+当升级后的 RTE 使用运行器的名称和运行器自己的令牌登录时，应用会立即将该运行器迁移到 RTE 的模式，
+无需批准，并记录 *Runner '&lt;name&gt;' moved from database mode to outbound: its RTE signed in with the runner's own
+token*。该运行器不再是其 RTE 注册的行，因此当旧容器不再应答时，worker 永远不会删除它。
+仍处于数据库模式的配置种子运行器则会被拒绝，并显示 *runner '&lt;name&gt;' is managed by the config seed in
+database mode: set rte_mode: outbound for it in the seed ..., then restart this RTE*。不要为此使用加入令牌：已经批准的运行器
+会拒绝加入令牌。没有 `APP_URL` 的入站 RTE 不会发起调用：请改为在 **连接 > 运行器** 下将其运行器的 **模式** 设为
+**入站**，应用就会连接它。[安装程序](../installation/installer.html#a-72-runner)
+以这种方式升级 7.2 的运行器。
+
+---
+
+## 套接字上传递什么
+
+在两种套接字模式下，应用都会把每个作业连同 RTE 过去从数据库中读取的所有内容发给 RTE，并将返回的内容，
+即输出、事件、作业日志和结束状态，恰好保存一次。应用还会发送结束通知。
+
+**spool。** 每一批输出、每一批事件、日志、开始和结束都会被编号，并在发送之前写入作业的 spool 文件
+（[`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH)），一直保留到应用表示已保存为止。
+重新连接（到同一个应用节点或另一个节点）后，RTE 会重新发送未被确认的内容，应用会跳过已经保存的
+内容：不会丢失任何内容，也不会重复保存。请将 spool 放在卷上，这样重启后的 RTE 仍能发送尚未
+送达的内容。RTE 重启时正在运行的 playbook 无法继续：其作业会作为已放弃作业结束。
+
+**容量。** RTE 最多同时运行 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 个 playbook，或其
+[运行器页面](../runners/runner-page.html#an-rtes-settings) 上设置的值，并每 20 秒告诉应用正在运行多少个。发给已满
+RTE 的作业会等待，详见 [多个 RTE](several.html#several-jobs-on-one-rte)。
+
+**作业的文件。** [`RTE_FILES`](../customization/server.html#env_RTE_FILES)，或其运行器页面上的 **作业文件** 设置，说明
+RTE 从哪里获取 playbook 和清单：
+
+| `RTE_FILES` | 文件的来源 |
+|---|---|
+| `transfer`（默认） | 应用随作业发送 playbook 文件夹和清单，每个都打包并以其内容的哈希命名。RTE 将它们以打包形式保存在 [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) 下，保留最近使用的，最多 [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB)（默认 1024 MB），并且只请求它没有的哈希：未改变的文件夹永远不会发送两次。RTE 不需要共享磁盘，也不需要访问仓库 |
+| `local` | RTE 从自己的文件夹运行，与数据库模式的 RTE 一样：在其上挂载 playbook（[`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)）和仓库（[`REPO_PATH`](../customization/paths.html#env_REPO_PATH)） |
+
+使用 `transfer` 时，每个作业都在自己的私有文件夹中解压文件，作业结束时删除：任何作业都看不到其他作业
+写入的内容，RTE 的磁盘上也不会留下解压后的清单或 extravars 文件。多个 RTE 可以共用一个 `RTE_CACHE_PATH`；每个 RTE 都把自己的作业放在
+自己的文件夹中，已停止的 RTE（在作业中途被杀死，或以另一个主机名重新创建）的文件夹会在 10 分钟后被其他 RTE
+删除。大于 [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB)（默认 512，由
+应用读取，无需重启即可生效）的文件夹不会被发送：作业会失败，并提示改为在 RTE 上挂载该文件夹。ssh 文件夹永远不会被发送：RTE 在
+`/home/node/.ssh` 中保存自己的私钥和 `known_hosts`。
+
+**主机和任务。** 从 7.3.0 起，任何模式的 RTE 都会在文本输出之外记录 playbook 的结构化事件：每个 play、任务和
+主机结果，以及汇总，由其 `af_events` 回调插件写入。作业页面在 **主机和任务** 下显示它们（参见
+[跟踪作业](../jobs/following.html#hosts-and-tasks)）。
+
+---
+
+## 网络
+
+按模式列出需要在应用、RTE 和受管主机之间开放的连接：
+
+| 模式 | 从 | 到 | 端口 |
+|---|---|---|---|
+| 出站 | RTE | 应用，位于 `APP_URL` | 应用的端口（大多数代理之后为 `443`） |
+| 入站 | 应用节点 | RTE，位于其运行器的地址 | RTE 的 `PORT`（`8000`） |
+| 数据库（已弃用） | RTE，以及应用节点和 worker | 数据库，以及 RTE | `3306`，以及 RTE 的 `PORT` |
+| 所有模式 | RTE | 受管主机 | ssh（`22`）、WinRM、它们的 API |
+
+在套接字模式下，RTE 从不连接数据库。其 API 只应答套接字和探针：`/live`、`/ready`、`/metrics`。
diff --git a/i18n/zh/_configure/rte/run.md b/i18n/zh/_configure/rte/run.md
new file mode 100644
index 0000000..1060208
--- /dev/null
+++ b/i18n/zh/_configure/rte/run.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: 运行 RTE
+parent: RTE
+nav_order: 3
+translated_from: 7973ec16ff9be3ec527cc8a2a652cc4b23ed5e54
+---
+
+# 运行 RTE
+{: .no_toc }
+
+每种模式的设置，以及如何启动 RTE
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 设置
+
+RTE 需要什么取决于它的模式（参见 [模式](modes.html)）。每个 RTE 都会读取以下变量：
+
+| 变量 | 含义 |
+|---|---|
+| [`RTE_MODE`](../customization/server.html#env_RTE_MODE) | 从 7.3.0 起：`outbound`（它主动连接应用）、`inbound`（应用主动连接它）或 `database`（已弃用，在整个 7.x 中为默认值） |
+| [`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN) | 应用与 RTE 之间的令牌，至少 16 个字符；没有它，RTE 会拒绝启动 |
+| [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | 它同时运行多少个 playbook，默认为 `10`（`0` 表示不限制）。发给已满 RTE 的作业会等待，直到某个 playbook 结束 |
+| [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | 停止时，它等待正在运行的 playbook 的时长，默认为 `25`；届时仍在运行的会作为已放弃作业结束 |
+| [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES) | 由应用节点和 worker 读取，而不是 RTE：作业等待已满或正在停止的 RTE 的时长，默认为 `60` |
+| [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH)、`PROCESS_MAX_BUFFER` | playbook 文件夹和输出上限：由 RTE 读取，因此请在其环境中设置 |
+| `LISTEN_HOST` | 从 7.3.0 起：其监听器绑定的地址，默认为所有接口；当外部没有任何东西连接它时（出站 RTE）设为 `127.0.0.1` |
+
+套接字模式（`outbound` 或 `inbound`）的 RTE 还会读取以下变量，并且不读取任何 `DB_*` 和 `ENCRYPTION_SECRET`：
+
+| 变量 | 含义 |
+|---|---|
+| [`APP_URL`](../customization/server.html#env_APP_URL) | 用户打开应用时使用的地址，例如 `https://forms.example.com`。出站：它连接的地址。入站：它那一次注册调用的地址 |
+| [`APP_TLS_VERIFY`](../customization/server.html#env_APP_TLS_VERIFY) | `1`（默认）：应用的证书必须有效。`0` 接受任何证书，仅限在一个受信任的网络内部使用 |
+| [`RTE_NAME`](../customization/server.html#env_RTE_NAME) | 其运行器的名称，表单用 `runner:` 引用它。未设置时：使用其节点 ID `rte-<hostname>-<port>`，它会随容器变化：在生产环境中请设置它 |
+| [`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) | 可选，仅首次使用：通过 API 生成的加入令牌，可以立即批准其运行器，而无需等待管理员（参见 [加入令牌](../runners/registration.html#join-tokens)） |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | 入站，请求加入时：应用连接的地址，例如 `http://rte-dmz.example.com:8000` |
+| [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | `transfer`（默认）：应用随作业发送 playbook 和清单。`local`：它从自己挂载的文件夹运行 |
+| [`RTE_SPOOL_PATH`](../customization/server.html#env_RTE_SPOOL_PATH) | 每个作业的输出、事件和结束状态在应用保存之前的暂存位置，默认为 `<persistent>/rte-spool`：请放在卷上 |
+| [`RTE_CACHE_PATH`](../customization/server.html#env_RTE_CACHE_PATH) | 使用 `transfer` 时：保存应用发来的文件夹的位置，默认为 `<persistent>/rte-files` |
+| [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | 使用 `transfer` 时：这些文件夹可以占用的空间，默认为 `1024`；最久未使用的先被清除，`0` 表示不保留 |
+| [`RTE_FILES_MAX_MB`](../customization/server.html#env_RTE_FILES_MAX_MB) | 由应用读取，而不是 RTE：使用 `transfer` 时它发送的最大文件夹，默认为 `512` |
+
+对于套接字模式的 RTE，`RTE_MAX_JOBS`、`RTE_DRAIN_SECONDS`、`RTE_FILES` 和 `RTE_CACHE_MB` 也可以在其运行器页面的
+RTE 选项卡下设置：那里的值优先于变量，变量只用于填充留空的字段（参见
+[RTE 的设置](../runners/runner-page.html#an-rtes-settings)）。超出范围的值会被调整到其上限或下限，RTE 会在启动时
+说明这一点。
+
+数据库模式（已弃用）的 RTE 则读取数据库设置，并自行注册：
+
+| 变量 | 含义 |
+|---|---|
+| `DB_HOST`、`DB_PORT`、`DB_USER`、`DB_PASSWORD` | 应用自己的值：RTE 从数据库读取其作业，并将输出写入数据库 |
+| [`RTE_URL`](../customization/server.html#env_RTE_URL) | 应用调用 RTE 的地址，例如 `http://rte:8000`。运行器以其主机名（`rte`）命名，因此表单可以使用 `runner: rte` |
+| [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) | 在 7.3.0 中随数据库模式一起弃用：套接字模式的 RTE 改用加入令牌加入。`1`（默认）：RTE 在启动时将自己添加到 **连接 > 运行器** 下，第一个会成为默认运行器。`0`：请自己在那里添加，或在 [配置种子](../seed/) 中添加 |
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | 应用自己的值，仅在自行注册时需要（运行器的令牌以加密形式保存）；使用 `RTE_REGISTER=0` 时不要设置 |
+
+在数据库模式下，没有 `RTE_URL` 时，RTE 会以名称 `rte-<hostname>-<port>` 注册其 IP 地址和端口，它们会在
+容器重新创建时改变：在生产环境中请设置 `RTE_URL`。对于 RTE 自行注册的运行器，worker 会在该
+RTE 最后一次心跳 10 分钟后将其删除。
+
+---
+
+## 启动
+
+RTE 运行 playbook，因此它需要 ssh 文件夹（包含 playbook 所用的私钥和 `known_hosts`），以及一个持久化
+文件夹，用于存放其 spool 和应用发来的文件。选择模式：
+
+<div class="af-tabs" data-tab-group="rtemode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="outbound" aria-selected="true">出站</button>
+<button type="button" role="tab" class="af-tab" data-tab="inbound" aria-selected="false">入站</button>
+<button type="button" role="tab" class="af-tab" data-tab="database" aria-selected="false">数据库（已弃用）</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="outbound" markdown="1">
+
+在任何能访问应用的主机上启动 RTE，使用它自己的令牌及其运行器将获得的名称：
+
+```bash
+docker run -d --name rte-dmz --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=outbound -e APP_URL=https://forms.example.com \
+  -e RTE_NAME=rte-dmz -e RTE_TOKEN=<at least 16 characters> -e HTTPS=0 \
+  -v /srv/apps/rte/persistent:/app/dist/persistent \
+  -v /srv/apps/rte/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+它会连接应用并请求加入：**连接 > 运行器** 会显示运行器 `rte-dmz` 正在等待批准，其日志会显示
+其令牌的指纹。核对审核界面中显示的是同一个指纹，然后 **批准** 它（参见
+[批准 RTE](../runners/registration.html#approving-an-rte)）：从此它开始接收作业，并使用自己的 `RTE_TOKEN` 登录。
+如需无人值守启动，请添加 `-e RTE_JOIN_TOKEN=<a join token, afj_...>`，它会立即批准该 RTE。不需要有任何东西访问这台
+主机：不要发布任何端口。其 `PORT` 上只有用于探针的 `/live`、`/ready` 和 `/metrics` 在监听。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="inbound" markdown="1" hidden>
+
+在应用能访问到的地方启动 RTE。这个 RTE 运行在应用旁边，并从其文件夹运行 playbook（`RTE_FILES=local`）：
+
+```bash
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 40 \
+  -e RTE_MODE=inbound -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_FILES=local -e PORT=8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+然后为应用提供其运行器：在 [配置种子](../seed/) 中添加一个 RTE 凭据，以及一个使用该凭据登录的入站运行器：
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      description: The RTE_TOKEN of the rte container, and its address
+      url: http://rte:8000          # where the app dials it
+      password: ${RTE_TOKEN}        # its RTE_TOKEN, from the app's environment
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true              # playbook forms that name no runner run here
+```
+
+也可以手动添加这两项：在 **连接 > 凭据** 下添加类型为 RTE 的凭据，在
+**连接 > 运行器** 下添加类型为 RTE、模式为 **入站** 并使用该凭据的运行器。如果想让 RTE 自己请求加入，请使用
+`APP_URL` 和 `RTE_URL` 启动它，并在 **连接 > 运行器** 下批准它（参见 [入站](modes.html#inbound)）。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="database" markdown="1" hidden>
+
+自 7.3.0 起已弃用，并将在 8.0.0 中移除。RTE 从自己的磁盘运行 playbook，因此还要在其上挂载应用的持久化卷
+（playbook、仓库、上传文件）和 ssh 文件夹。一个 Docker 示例，应用在同一网络中可通过
+`ansibleforms` 访问：
+
+```bash
+docker run -d --name rte --network ansibleforms \
+  -e DB_HOST=192.168.0.1 -e DB_PORT=3306 -e DB_USER=ansibleforms -e DB_PASSWORD=<password> \
+  -e ENCRYPTION_SECRET=<the app's> -e RTE_TOKEN=<at least 16 characters> \
+  -e RTE_URL=http://rte:8000 -e HTTPS=0 \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+请让入站 RTE 远离公共网络：任何持有令牌的调用方都能得到其套接字的应答。`docker stop` 在杀死容器之前只等待 10 秒，
+因此请为 RTE 设置更长的停止超时（`--stop-timeout`，或 compose 中的 `stop_grace_period`），或者降低
+`RTE_DRAIN_SECONDS`。Kubernetes 默认等待 30 秒。
+
+[安装程序](../installation/installer.html) 可以在单独的服务器上使用 Docker、Podman 或
+[不使用容器](../installation/native.html) 设置出站或入站 RTE，并打印用于批准它的指纹。要手动在另一个数据中心
+运行 RTE，请按照 [另一个数据中心](another-datacenter.html) 操作。
diff --git a/i18n/zh/_configure/rte/several.md b/i18n/zh/_configure/rte/several.md
new file mode 100644
index 0000000..170fe8b
--- /dev/null
+++ b/i18n/zh/_configure/rte/several.md
@@ -0,0 +1,71 @@
+---
+layout: default
+title: 多个 RTE
+parent: RTE
+nav_order: 4
+translated_from: 06592303233da78436fcc2765588aec6c88bc045
+---
+
+# 多个 RTE
+{: .no_toc }
+
+一个 RTE 运行多少个 playbook、作为运行器或副本的更多 RTE，以及 RTE 停止或宕机时会发生什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 一个 RTE 上的多个作业
+
+一个 RTE 最多可以并行运行 [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) 个 playbook，默认为
+10 个（`0` 表示不限制）。发给已满 RTE 的作业不会被认领。在套接字模式下，只要 RTE 最近一次
+健康报告显示没有空闲槽位，应用就不会发送作业；已满或正在停止的 RTE 会以繁忙为由回复 `refused`；在数据库模式下，RTE 回复
+`503`。无论哪种情况，应用都会在输出中写入一次 `Waiting for a free slot on RTE <name>`，并每 10 秒重新提供一次作业，
+最长持续 [`RTE_QUEUE_MINUTES`](../customization/server.html#env_RTE_QUEUE_MINUTES)（默认 60）。之后作业会失败，并显示
+*the RTE '&lt;name&gt;' stayed busy for 60 minutes (RTE_QUEUE_MINUTES)*。在等待期间被中止的作业会以 `aborted` 结束，
+永远不会到达 RTE。
+
+---
+
+## 多个 RTE
+
+应用不会自行在运行器之间分配作业：每个作业都发往一个运行器，即表单指定的运行器或
+默认运行器。更多的 RTE 容器有两种用处：
+
+* **作为独立的运行器**：每个 RTE 都有自己的 `RTE_NAME`，并作为独立的运行器加入：它请求加入并由管理员
+  批准，或者出示加入令牌（参见 [注册](../runners/registration.html)）。表单用 `runner: <name>` 选择其中一个，
+  例如带有 VMware 集合的 RTE，或位于另一个网络区域的 RTE；其他表单在默认 RTE 上运行
+* **作为同一地址后的副本**（仅限数据库模式）：多个具有相同 `RTE_URL` 和相同 `RTE_TOKEN` 的 RTE 容器，
+  例如 Kubernetes Service 后面的 pod，共用一个运行器，由该地址在它们之间分配调用。已满的副本回复
+  `503`，下一次尝试可能会落到另一个副本上。应用通过数据库跟踪作业，因此由哪个副本
+  应答其状态调用都无关紧要
+
+在套接字模式下（参见 [模式](modes.html)），一个运行器持有到一个 RTE 的一个套接字，第二个使用相同
+`RTE_NAME` 登录的 RTE 会从第一个 RTE 那里接管该套接字。请为每个 RTE 指定独立的名称和运行器，并让表单用
+`runner:` 在它们之间选择。
+
+数据库模式的每个 RTE 每 10 秒在数据库中写入一次心跳，自行注册的 RTE 每 30 秒检查一次其运行器行。
+对于套接字模式的 RTE，持有其套接字的应用节点会在套接字打开期间每 20 秒为其写入一次心跳。
+**状态** 页面列出每个 RTE 及其版本。对于数据库模式的 RTE 自行注册的运行器，一旦该 RTE 有 10 分钟没有写入心跳，
+worker 就会将其删除；当默认运行器是这样一行且其 RTE 已停止时，下一个执行检查的 RTE
+会成为默认运行器。来自配置种子的运行器、手动添加的运行器或通过套接字加入的运行器永远不会以这种方式被删除。
+
+---
+
+## RTE 停止或宕机时
+
+**RTE 停止时。** 收到 `SIGTERM`（`docker stop`、滚动更新、缩容）时，RTE 停止接收作业：`/ready` 返回 `503`，
+新作业会以繁忙为由被拒绝（数据库模式下为 `503`），因此应用会等待，或者在数据库模式下由该地址将其发往另一个
+副本。正在运行的 playbook 有 [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS)（默认 25）的时间来完成，
+然后 RTE 退出。
+
+**RTE 宕机时。** 被杀死的容器（内存不足、节点丢失、停止超时到期）会带走其 playbook：不会有任何机制
+将它们移到另一个 RTE，也不会重新运行它们。它们的作业会以 `abandoned` 结束：由 RTE 自己结束，或由应用在
+RTE 以相同 ID 回来时结束（重启后的容器会保留该 ID，即 `rte-<hostname>-<port>`），或由 worker 在 RTE 的心跳
+已过去两分钟后结束。重新启动之前，请先在受管主机上检查该 playbook 做了什么。
+
+**RTE 停机期间。** 在套接字模式下，发给它的新作业会等待其套接字，最长为 `RTE_QUEUE_MINUTES` 再加一分钟，然后
+失败并显示 *no app node holds a socket to RTE '&lt;name&gt;' and it took no job for 60 minutes (RTE_QUEUE_MINUTES): is it connected?*。
+在数据库模式下，除非另一个副本在其地址上应答，否则它会立即失败，并显示 *the RTE at ... is unreachable*。
diff --git a/i18n/zh/_configure/runners.md b/i18n/zh/_configure/runners.md
new file mode 100644
index 0000000..6f3fe6f
--- /dev/null
+++ b/i18n/zh/_configure/runners.md
@@ -0,0 +1,67 @@
+---
+layout: default
+title: 运行器
+nav_order: 11
+has_children: true
+has_toc: false
+permalink: /runners.html
+translated_from: 339eda183d7748fa923090d9f8e26e2f112b1352
+---
+
+# 运行器
+{: .no_toc }
+
+作业的运行位置：用于 playbook 的运行时环境容器，以及用于模板的 AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：添加运行作业的运行器，为每种类型选择默认运行器，批准请求加入的 RTE，并对它们进行测试。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [运行器页面](runners/list.html) | 运行器列表、添加运行器、打开或关闭运行器，以及每种类型的默认运行器 |
+| [运行器类型](runners/types.html) | 运行器可以是哪些产品，以及它们的地址和登录方式 |
+| [注册](runners/registration.html) | RTE 如何请求加入并获得批准、用于无人值守安装的加入令牌，以及数据库模式 |
+| [单个运行器的页面](runners/runner-page.html) | 运行器的各个选项卡、RTE 的模式和连接，以及测试连接 |
+| [谁管理运行器](runners/permissions.html) | 谁可以添加、修改和测试运行器 |
+
+
+---
+
+## 工作原理
+
+从版本 7 起，应用本身不运行任何东西：每个作业都在 **运行器** 上运行，运行器在 **连接 > 运行器** 下添加。
+表单的类型决定它需要哪种类型的运行器：
+
+| 表单类型 | 运行在以下类型的运行器上 | 运行的内容 |
+|---|---|---|
+| `ansible` | RTE | 在运行时环境容器中运行的 playbook |
+| `awx`、`aap`、`ascender` | AWX（包括 AWX、AAP 和 Ascender 几种产品） | 作业模板或工作流模板 |
+| `semaphore` | Semaphore | Semaphore UI 模板 |
+| `rundeck` | Rundeck | Rundeck 作业 |
+| `jenkins` | Jenkins | Jenkins 作业 |
+
+`workflow` 或 `subform` 表单没有自己的运行器：[工作流](workflows/) 的每个节点各自选择运行器。带有
+`runner:` 的节点在该运行器上运行（RTE，或 AWX、Semaphore、Rundeck 或 Jenkins 上的模板或作业），其他节点则在
+默认 RTE 上运行，因此同一个作业的各个节点可以在不同的运行器上运行。自 7 起已弃用、由工作流取代的
+`multistep` 表单也是如此：它的每个步骤都在其自身类型所需的运行器上运行。
+
+表单通过以下两种方式之一选择运行器：
+
+- **按名称**：在表单、工作流节点或已弃用的多步骤表单的某个步骤上使用 `runner: <name>`（也可以在
+  设计器的表单设置中设置）。运行器必须是表单所需的类型，否则作业会失败。旧的 `awx: <name>`
+  仍然有效，会记录一条弃用警告，并将在 8 中移除。
+- **作为默认值**：未指定运行器的表单在其类型的默认运行器上运行。没有默认运行器时，作业会失败，
+  并显示一条说明需要添加哪种类型运行器的消息。
+
+在 **连接 > 运行器** 下关闭的运行器不会接收任何作业，无论是按名称还是作为默认值：作业会失败，并提示启用它
+或指定另一个运行器（参见 [默认与已启用](runners/list.html#default-and-enabled)）。
+
diff --git a/i18n/zh/_configure/runners/list.md b/i18n/zh/_configure/runners/list.md
new file mode 100644
index 0000000..ab405f2
--- /dev/null
+++ b/i18n/zh/_configure/runners/list.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: 运行器页面
+parent: 运行器
+nav_order: 1
+translated_from: 622b7c995b553611b6b3eb2eb16d076f669f0476
+---
+
+# 运行器页面
+{: .no_toc }
+
+运行器列表、添加运行器、打开或关闭运行器，以及每种类型的默认运行器
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 列表
+
+**连接 > 运行器** 下的页面列出所有运行器，包含以下各列：
+
+| 列 | 含义 |
+|---|---|
+| 已启用 | 是否接收作业。关闭的运行器不会接收任何作业，即使它是该类型的默认运行器。 |
+| 名称 | 表单用 `runner: <name>` 引用它的名称。 |
+| 类型 | RTE、AWX、Ansible Automation Platform、Ascender、Semaphore UI、Rundeck 或 Jenkins。该类型的默认运行器会在类型后显示一个 **默认** 标记。 |
+| 描述 | 它的用途。 |
+
+**列** 可以再添加两列，默认关闭：**模式**，即 RTE 的模式（出站、入站或数据库（已弃用），参见
+[模式](../rte/modes.html)）；以及 **连接**，即是否有应用节点持有到套接字模式 RTE 的套接字：**已连接** 或
+**未连接**。
+
+从 7.3.0 起，等待批准的运行器不在列表中，而是显示在列表上方的提示中，参见 [批准 RTE](registration.html#approving-an-rte)。
+**添加运行器** 会打开一个分步对话框：**运行器**（名称和描述）、**类型** 和 **凭据**；对于 RTE，在 **类型** 之后还有一个 **模式** 步骤
+（出站，新 RTE 的默认值；入站；或数据库（已弃用））：RTE 共四步，其他类型共
+三步。在 **类型** 步骤中，每个产品都有一条提示：RTE 的提示给出了其全称 *Runtime Environment*。点击某一行会打开运行器
+自己的页面，其菜单提供：
+
+| 操作 | 作用 |
+|---|---|
+| 编辑 | 打开其页面 |
+| 测试连接 | 检查它是否应答并接受其凭据，参见 [测试连接](runner-page.html#test-connection) |
+| 启用、禁用 | 打开或关闭它，视其当前状态而定 |
+| 更改凭据 | 打开其页面的凭据选项卡 |
+| 删除 | 删除它 |
+
+---
+
+## 默认与已启用
+
+每种类型的默认运行器是该类型的表单在未指定运行器时的运行位置：
+
+| 默认用于 | 这些表单在未指定运行器时的运行位置 |
+|---|---|
+| Playbook 表单 | `ansible` 表单，在 RTE 上 |
+| AWX、AAP 和 Ascender 表单 | `awx`、`aap` 和 `ascender` 表单，在 AWX 运行器上 |
+| Semaphore 表单 | `semaphore` 表单 |
+| Rundeck 表单 | `rundeck` 表单 |
+| Jenkins 表单 | `jenkins` 表单 |
+
+某种类型的第一个运行器会成为其默认运行器，因此每种类型只有一个运行器时无需额外操作。要让另一个运行器成为默认运行器，
+请打开其页面上的 **默认** 开关（参见 [单个运行器的页面](runner-page.html)）。
+
+关闭的运行器仍会连同其设置保留在列表中，但不会有任何作业发往它，即使它是该类型的默认运行器。发给它的作业会失败，并显示
+*Runner '&lt;name&gt;' is disabled - enable it under Connections > Runners, or name another runner on the form with runner: &lt;name&gt;*。
+可以通过其行菜单中的 **启用** 或 **禁用**，或其页面上的 **已启用** 开关来打开或关闭它。新运行器默认为打开，
+7.3.0 之前已存在的运行器在升级后也为打开。[配置种子](../seed/example.html) 可以用
+`enabled: false` 关闭运行器。
diff --git a/i18n/zh/_configure/runners/permissions.md b/i18n/zh/_configure/runners/permissions.md
new file mode 100644
index 0000000..a050420
--- /dev/null
+++ b/i18n/zh/_configure/runners/permissions.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: 谁管理运行器
+parent: 运行器
+nav_order: 5
+translated_from: 9cc0a2262cdfde6142b10720e7e3d61b5be71d2b
+---
+
+# 谁管理运行器
+{: .no_toc }
+
+谁可以添加、修改和测试运行器
+{: .fs-6 .fw-300 }
+
+运行器会收到其运行的每个作业的凭据，因此只有 **admin** 角色才能添加、修改、打开或关闭以及删除运行器，
+以及批准或拒绝请求加入的 RTE。拥有设置访问权限的用户可以查看和测试它们，但不能修改。
+
+在 [配置种子](../seed/) 中声明的运行器在此页面上为只读：请改为在种子文件中修改。
diff --git a/i18n/zh/_configure/runners/registration.md b/i18n/zh/_configure/runners/registration.md
new file mode 100644
index 0000000..9bde479
--- /dev/null
+++ b/i18n/zh/_configure/runners/registration.md
@@ -0,0 +1,123 @@
+---
+layout: default
+title: 注册
+parent: 运行器
+nav_order: 3
+translated_from: 79dc369b64c0e733cc0dc8d4d863289fc64c75ab
+---
+
+# 注册
+{: .no_toc }
+
+RTE 如何请求加入并获得批准、用于无人值守安装的加入令牌，以及数据库模式
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 请求加入
+
+从 7.3.0 起，应用尚不认识的套接字模式（`outbound` 或 `inbound`）RTE 会请求加入，由管理员批准。
+它使用自己的 `RTE_TOKEN` 和 `RTE_NAME` 发起联系：出站 RTE 在首次连接应用时，入站 RTE 在它那一次
+注册调用中。没有加入令牌时，应用随后会：
+
+1. 将 RTE 的 `RTE_TOKEN` 保存到一个名为 `<name>-rte` 的新 RTE 类型凭据中（名称已被占用时会加上数字），
+   对于入站 RTE 还会保存其地址 `RTE_URL`
+2. 添加一个以 `RTE_NAME` 命名、类型为 RTE、模式与该 RTE 相同、使用该凭据登录的运行器，标记为 **等待批准**
+   并处于关闭状态。其描述中注明了它发起请求的主机
+
+出站 RTE 在等待期间保持连接，但不接收作业。在获得批准之前，应用不会连接入站 RTE。两者都会在日志中
+记录它们正在等待管理员在 **连接 > 运行器** 下批准，并附上其令牌的指纹。
+
+`RTE_URL` 为 `https://` 的入站 RTE 在请求加入时还会发送其证书，应用会将其固定：此后，
+只有当该 RTE 出示同一证书时，应用才会连接它，因此自签名证书无需 CA 也能使用（参见 [入站](../rte/modes.html#inbound)）。
+
+同一时间最多有 20 个 RTE 等待批准：超出的会被拒绝，直到有一些被批准或拒绝。24 小时内无人处理的请求
+会被 worker 连同其凭据一起删除。
+
+以应用已知的运行器名称命名、但使用另一个令牌的 RTE 会被拒绝，并且不会请求加入。请将该运行器的
+令牌提供给它，或删除该运行器，让它请求加入。只有在该运行器仍在等待批准时，[加入令牌](#join-tokens) 才有帮助。
+
+---
+
+## 批准 RTE
+
+等待批准的运行器不在 **连接 > 运行器** 的列表中，而是显示在列表上方的一条橙色提示中，例如
+**2 个运行器等待批准**，每个运行器一行：其名称、主机、IP 地址、模式、地址和指纹。
+页眉的铃铛会为能看到运行器的用户统计它们的数量（参见 [铃铛](../jobs/#the-jobs-page)）。
+
+点击该提示会依次为每个运行器打开 **审核审批** 对话框；点击某个名称则只打开该运行器。
+其页面在一个黄色框 **此 RTE 请求加入** 中显示相同的信息。批准之前，请确认它是您启动的：
+
+| 字段 | 显示的内容 |
+|---|---|
+| 指纹 | 其 `RTE_TOKEN` 的 SHA-256 的前 8 个十六进制数字，形如 `abcd-ef12`。RTE 在启动时记录它，[安装程序](../installation/installer.html#a-runner) 在结束时打印它。两者必须一致 |
+| 证书指纹 | 在对话框中，对于通过 HTTPS 的入站 RTE：应用所固定证书（其 DER 字节）的 SHA-256 的前 8 个十六进制数字，形如 `abcd-ef12`。RTE 在启动时记录它，[安装程序](../installation/installer.html#a-runner) 在结束时打印它。两者必须一致 |
+| 主机 | 它运行所在的主机 |
+| IP 地址 | 它调用应用时的来源地址 |
+| 模式 | 出站或入站 |
+| URI | 入站 RTE 的地址，即应用连接它的地址 |
+| 版本 | 它的版本 |
+| 请求时间 | 它请求加入的时间 |
+
+在对话框中或其页面的黄色框中，用 **批准** 和 **拒绝** 作出决定：
+
+| 操作 | 结果 |
+|---|---|
+| 批准 | 运行器被启用，从此开始接收作业。如果其类型还没有默认运行器，它会成为默认运行器 |
+| 拒绝 | 运行器连同其凭据被删除，其套接字被关闭。RTE 可以再次请求加入；届时它会再次等待批准 |
+
+只有管理员可以批准或拒绝 RTE。
+
+---
+
+## 加入令牌
+
+加入令牌可以立即批准 RTE，用于无人值守安装：以
+[`RTE_JOIN_TOKEN`](../customization/server.html#env_RTE_JOIN_TOKEN) 启动的 RTE，或使用安装程序的 `--join` 安装的运行器，会出示一次该令牌，
+其运行器会以启用状态添加，无需等待。加入令牌在界面中没有页面：管理员通过
+[REST API](../api/) 在 `/api/v2/runner` 下生成它们：
+
+| 调用 | 作用 |
+|---|---|
+| `POST /api/v2/runner/jointoken` | 生成加入令牌。请求体包含其 `name`，以及可选的 `expiresInHours`（不设置：永不过期）和 `maxUses`（不设置：不限 RTE 数量） |
+| `GET /api/v2/runner/jointoken` | 列出加入令牌，最新的在前，包括其使用次数以及是否仍可使用；从不列出令牌本身 |
+| `POST /api/v2/runner/jointoken/<id>/revoke` | 撤销它：它不再添加任何运行器，但仍保留在列表中 |
+| `DELETE /api/v2/runner/jointoken/<id>` | 删除它 |
+
+```bash
+curl -X POST https://forms.example.com/api/v2/runner/jointoken \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{ "name": "dmz-runners", "expiresInHours": 24, "maxUses": 5 }'
+```
+
+应答中包含以 `afj_` 开头的令牌，仅此一次：只保存其 SHA-256。出示它的 RTE 会获得与
+[请求加入](#asking-to-join) 的 RTE 相同的凭据和运行器，并处于启用状态，其描述中注明了该加入令牌。此后
+RTE 使用它自己的令牌登录，因此加入令牌过期或被撤销都不会影响它。撤销或删除加入令牌
+会保留它所添加的运行器。
+
+加入令牌永远不会为已批准的运行器提供新令牌。当已存在同名的 RTE 运行器时：
+
+| 该运行器 | 结果 |
+|---|---|
+| 正在等待批准 | 其凭据中会写入新令牌，但仍需等待管理员批准 |
+| 已批准 | 以 `409` 拒绝：*runner '&lt;name&gt;' exists and is approved: a join token cannot give it a new token. Use its current RTE_TOKEN, or have an admin change the token in its credential (or remove the runner) under Connections*。加入令牌不会被消耗 |
+| 来自 [配置种子](../seed/) | 拒绝：*runner '&lt;name&gt;' is managed by the config seed: its token is set there* |
+
+因此，使用新令牌重新安装的 RTE 应使用其运行器凭据中的令牌登录；或者由管理员在
+**连接 > 凭据** 下修改该令牌；或者删除该运行器，让 RTE 作为新的 RTE 加入。
+
+---
+
+## 数据库模式下的注册
+
+数据库模式（自 7.3.0 起已弃用）的 RTE 默认会自行注册，使用其 `RTE_URL`，否则使用其自身的地址和端口。
+一旦其 RTE 有 10 分钟没有写入心跳，worker 就会删除这样的运行器。手动添加的运行器、由配置种子添加的运行器或由
+套接字模式 RTE 添加的运行器永远不会以这种方式被删除。
+
+用于打开或关闭这种注册的 [`RTE_REGISTER`](../customization/server.html#env_RTE_REGISTER) 在 7.3.0 中随
+数据库模式一起弃用：套接字模式的 RTE 会请求加入，或使用加入令牌加入。在此期间，如果要自己管理这类运行器，请以
+`RTE_REGISTER=0` 启动 RTE，并在这里以类型 RTE、模式 **数据库（已弃用）** 添加它，同时提供一个包含其地址和
+相同令牌的 RTE 凭据。要将其迁移到套接字模式，参见 [模式](../rte/modes.html#database-deprecated)。
diff --git a/i18n/zh/_configure/runners/runner-page.md b/i18n/zh/_configure/runners/runner-page.md
new file mode 100644
index 0000000..5bb8f38
--- /dev/null
+++ b/i18n/zh/_configure/runners/runner-page.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: 单个运行器的页面
+parent: 运行器
+nav_order: 4
+translated_from: 4260f9b8ce60f26e8808cf17bf4a4c3993229c5d
+---
+
+# 单个运行器的页面
+{: .no_toc }
+
+运行器的各个选项卡、RTE 的模式、连接和设置，以及测试连接
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 选项卡
+
+运行器的页面将其对话框的各个步骤显示为选项卡，并额外显示在其上运行的内容：
+
+| 选项卡 | 内容 |
+|---|---|
+| 详情 | 名称和描述、**默认** 开关和 **已启用** 开关，每种类型的运行器都相同 |
+| 类型 | 产品，与对话框中相同。对于 RTE 还有其 **模式**：**数据库（已弃用）**、**入站** 或 **出站**，即其 RTE 运行时使用的 `RTE_MODE`（参见 [模式](../rte/modes.html)） |
+| RTE | 仅限 RTE：以文字说明的 **模式**，以及在套接字模式下的 **连接** 及其设置（参见 [RTE 的设置](#an-rtes-settings)） |
+| 凭据 | 它登录所用的 **凭据**，即连接 > 凭据 中与运行器类型相同的凭据，保存其令牌或登录信息以及其服务器的地址。RTE 的凭据保存其 `RTE_TOKEN`，以及 RTE 的地址（出站模式除外）。Semaphore、Rundeck 和 Jenkins 还有 **项目** |
+| 表单 | 在其上运行的表单及方式：**指定** 或 **作为默认运行器**。点击某一行会打开该表单 |
+| 作业 | 最近在其上运行的 100 个作业，包括其状态、开始、结束和持续时间。点击某一行会打开该作业 |
+
+每个选项卡都有自己的地址，例如 `/settings/runners/<id>/rte`，因此链接或书签可以直接打开它。没有该选项卡的运行器会打开
+详情选项卡。
+
+详情选项卡的两个开关会立即保存。**默认** 使该运行器成为其类型的默认运行器；将另一个运行器设为默认
+即可将其关闭。**已启用** 打开或关闭运行器：关闭后，不会有任何作业发往它，即使它是该类型的默认运行器（参见
+[默认与已启用](list.html#default-and-enabled)）。
+
+请求加入的 RTE 打开时会显示一个黄色框 **此 RTE 请求加入**，其中包含其指纹和它关于自身的说明，以及
+**批准** 和 **拒绝**（参见 [批准 RTE](registration.html#approving-an-rte)）。[配置种子](../seed/) 中的运行器会在其页面顶部
+注明这一点，并且为只读。
+
+---
+
+## RTE 的设置
+
+RTE 选项卡让您可以从应用中管理 RTE，而无需在其运行的机器上编辑环境。
+
+**连接。** 套接字模式的 RTE 会显示一个标记：**已连接** 或 **未连接**。悬停在 **已连接** 上时会显示持有其套接字的应用节点、
+RTE 的版本以及其正在运行的作业数量。**未连接** 表示没有任何应用节点持有到它的套接字：
+请检查 RTE 是否在运行、其地址或 `APP_URL`，以及其令牌。
+
+**设置。** 出站或入站模式的 RTE 有四项设置，默认均为空：
+
+| 设置 | 等同于 | 作用 |
+|---|---|---|
+| 最大并发作业数 | [`RTE_MAX_JOBS`](../customization/server.html#env_RTE_MAX_JOBS) | 它同时运行多少个 playbook，默认为 `10`；`0` 表示不限制 |
+| 作业文件缓存 | [`RTE_CACHE_MB`](../customization/server.html#env_RTE_CACHE_MB) | 它保留多少应用发来的作业文件，单位为 MB，默认为 `1024`；`0` 表示不保留 |
+| 停止时的等待时间 | [`RTE_DRAIN_SECONDS`](../customization/server.html#env_RTE_DRAIN_SECONDS) | 正在停止的 RTE 等待其正在运行的 playbook 的时长，默认为 `25` 秒 |
+| 作业文件 | [`RTE_FILES`](../customization/server.html#env_RTE_FILES) | **传输**：应用随作业发送作业的文件。**本地**：它从自己挂载的文件夹运行 |
+
+**哪个值优先。** 页面上的值优先于 RTE 上设置的同名变量。留空的字段使用 RTE 自身的变量，
+否则使用默认值。页面会在每个字段下方说明是哪一种：**覆盖 RTE 上设置的 RTE_MAX_JOBS（3）。**，或 **留空：RTE 使用其自身的
+RTE_MAX_JOBS，3。**；占位符显示留空字段所代表的值。
+
+**它们如何到达 RTE。** 这些设置与运行器一起保存在应用的数据库中。应用会在 RTE 连接时以及每次保存时
+通过 RTE 的套接字发送它们，RTE 会立即应用：缩小的缓存会被裁剪，新的上限从下一个
+作业开始计算。RTE 只将它们保存在内存中，不写入任何文件：重启后，它会在连接时、运行第一个作业之前再次获取它们。
+
+数据库模式（已弃用）的 RTE 没有套接字：它从自己的变量读取这些设置，选项卡中也会如此说明。
+
+---
+
+## 测试连接
+
+右上角的按钮作用于已保存的运行器。
+
+**保存** 旁边是 **测试连接** 和 **删除**，在凭据选项卡上还有 **添加凭据**，它会创建一个
+与运行器类型相同的凭据并选中它。令牌或密码保存后永远不会再显示：请在凭据上修改它。
+
+**测试连接** 检查运行器是否应答并接受其令牌或登录信息，并在一条消息中说明结果：**运行器连接
+正常**，或失败的原因。它不运行任何作业。对于 RTE，它还会检查 RTE 使用的协议约定（参见
+[协议约定](../rte/images.html#the-contract)）：
+
+| RTE | 测试读取的内容 | 失败的情况 |
+|---|---|---|
+| 出站或入站 | 每个应用节点所记录的套接字持有者，以及 RTE 连接时所报告的内容。它不调用任何东西 | 没有任何应用节点持有到它的套接字：*the RTE '&lt;name&gt;' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app*，对于入站 RTE 则为 *no app node could dial it at &lt;address&gt;: check its RTE_URL, its token and the network from the app to the RTE*。或者 RTE 使用的协议约定不是 3 |
+| 数据库（已弃用） | 使用其令牌调用 RTE 的 `/rte/v1/health` | RTE 在其地址上没有应答、拒绝令牌，或使用的协议约定不是 2 |
+
+RTE 选项卡的 **连接** 标记无需测试即可显示同样的套接字状态。
diff --git a/i18n/zh/_configure/runners/types.md b/i18n/zh/_configure/runners/types.md
new file mode 100644
index 0000000..37fba9d
--- /dev/null
+++ b/i18n/zh/_configure/runners/types.md
@@ -0,0 +1,30 @@
+---
+layout: default
+title: 运行器类型
+parent: 运行器
+nav_order: 2
+translated_from: d15bc7b93c01adc1a74f67135e114eca6b432a27
+---
+
+# 运行器类型
+{: .no_toc }
+
+运行器可以是哪些产品，以及它们的地址和登录方式
+{: .fs-6 .fw-300 }
+
+**类型** 步骤为每个产品提供一个选项，并各附一条提示；RTE 的提示写出了其全称 *Runtime Environment*。AAP 和
+Ascender 保存为类型为 `awx` 的运行器，并带有产品标识（`aap` 或 `ascender`），配置种子也使用这种方式：
+
+| 类型 | URI 示例 | 项目 | 认证方式 |
+|---|---|---|---|
+| RTE | `https://rte-vmware:8000` | | 该 RTE 的 `RTE_TOKEN` |
+| AAP | `https://aap.example.com/api/controller/v2` | | API 令牌，或用户名和密码 |
+| Ascender | `https://ascender.example.com/api/v2` | | API 令牌，或用户名和密码 |
+| AWX | `https://awx.example.com/api/v2` | | API 令牌，或用户名和密码 |
+| Jenkins | `https://jenkins.example.com` | 作业所在的文件夹（可选） | 用户及该用户的 API 令牌 |
+| Rundeck | `https://rundeck.example.com` | 项目名称 | 用户的 API 令牌 |
+| Semaphore | `https://semaphore.example.com` | 项目 ID，即 `/project/<id>` 中的数字 | 用户的 API 令牌 |
+
+AWX、AAP 或 Ascender 的地址包含其 API 路径：`/api/v2`，AAP 2.5 及更高版本为 `/api/controller/v2`。
+RTE 是以 `AF_ROLE=rte` 启动的 AnsibleForms 镜像；如何运行 RTE 参见
+[运行时环境](../rte/)。
diff --git a/i18n/zh/_configure/secret-stores/cyberark.md b/i18n/zh/_configure/secret-stores/cyberark.md
new file mode 100644
index 0000000..2f180e5
--- /dev/null
+++ b/i18n/zh/_configure/secret-stores/cyberark.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: CyberArk
+parent: 密钥库
+nav_order: 2
+translated_from: f001addbd5578169444a321ab9e668e54139842b
+---
+
+# CyberArk
+{: .no_toc }
+
+从 CyberArk Central Credential Provider（CCP）读取凭据
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+{: .warning }
+> **实验性。** 尚未在真实的 CyberArk 环境中测试过；欢迎反馈您的发现。
+
+CCP 是 CyberArk Application Access Manager 的 REST 接口。
+
+---
+
+## 密钥库字段
+
+除了 [每个密钥库都有的字段](./#adding-a-store) 之外，CyberArk 密钥库还有以下字段：
+
+| 字段 | 含义 |
+|---|---|
+| 凭据 | [连接 > 凭据](../credentials.html) 中的一个 **CyberArk** 凭据：CCP 的基础 URL，例如 `https://ccp.example.com`（会自动加上 `/AIMWebService/api/Accounts`）、其 TLS 设置、其 AppID（在 CyberArk 中为 AnsibleForms 定义的应用），以及 PEM 格式的客户端证书和密钥（仅当 AppID 要求时）。 |
+
+---
+
+## 密钥引用
+
+密钥引用以 `;` 分隔的键值对来标识账户：
+
+```
+Safe=Linux;Object=root-srv01
+Safe=DB;UserName=forms;Address=db01.example.com
+Query=Safe=Linux;Folder=Root;Object=root-srv01
+```
+
+- 允许的键：`Safe`、`Folder`、`Object`、`UserName`、`Address`、`Database`、`PolicyID`、
+  `Reason`、`Query`、`QueryFormat`、`ConnectionTimeout`、`FailRequestOnPasswordChange`。
+- `Query=` 会将引用的其余部分作为原生 CCP 查询传递，除非您另行设置，否则使用 `QueryFormat=Exact`。
+- 引用中的 `AppID` 会被忽略：始终使用密钥库的 AppID。
+- 账户的密码（`Content`）成为密码；`UserName`、`Address`、`Port` 和
+  `Database` 分别填入用户、主机、端口和数据库名称。
+
+---
+
+## 附加选项
+
+密钥库的附加选项以 JSON 对象设置：
+
+| 键 | 含义 |
+|---|---|
+| `reason` | 当引用中没有原因时，以 `Reason` 发送，用于 CyberArk 的审计。 |
+| `check_ref` | **测试连接** 实际读取的引用。没有它时，测试只验证 CCP 是否应答并接受 AppID。 |
+| `timeout_ms` | 请求超时，默认为 10000。 |
+
+例如，要发送一个原因，并让 **测试连接** 读取一个探测账户：
+
+```json
+{ "reason": "AnsibleForms", "check_ref": "Safe=Test;Object=ansibleforms-probe" }
+```
diff --git a/i18n/zh/_configure/secret-stores/hashicorp-vault.md b/i18n/zh/_configure/secret-stores/hashicorp-vault.md
new file mode 100644
index 0000000..9341618
--- /dev/null
+++ b/i18n/zh/_configure/secret-stores/hashicorp-vault.md
@@ -0,0 +1,44 @@
+---
+layout: default
+title: HashiCorp Vault
+parent: 密钥库
+nav_order: 1
+translated_from: 33cbbea1ca86bf474182d220bd6824af81aa752f
+---
+
+# HashiCorp Vault
+{: .no_toc }
+
+从 HashiCorp Vault 的 KV v1 或 v2 或动态密钥引擎读取凭据
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 密钥库字段
+
+除了 [每个密钥库都有的字段](./#adding-a-store) 之外，HashiCorp Vault 密钥库还有以下字段：
+
+| 字段 | 含义 |
+|---|---|
+| 凭据 | [连接 > 凭据](../credentials.html) 中的一个 **HashiCorp Vault** 凭据：Vault 的地址、其 TLS 设置，以及作为其密码的令牌，该令牌需要对您的凭据所用的路径有读取权限。**添加凭据** 会创建一个该类型的凭据。AnsibleForms 不会续订令牌。 |
+| 命名空间 | Vault Enterprise 命名空间，以 `X-Vault-Namespace` 发送。在 **类型** 步骤中打开 **Vault Enterprise** 后才会显示。 |
+| KV 版本 | `2`（默认）或 `1`。 |
+| 默认挂载点 | 用于不带斜杠的引用，例如 `myapp` 会变为 `secret/data/myapp`。 |
+
+密钥引用即路径，例如 `secret/myapp/prod`。对于 KV v2，如果您省略了 `/data/` 段，
+会自动插入。
+
+---
+
+## 动态数据库凭据
+
+形如 `<mount>/creds/<role>` 的引用（例如 `database/creds/readonly`）会从
+动态密钥引擎（例如 Vault 的数据库引擎）读取。Vault 随后会在每次读取时创建一个新的数据库
+账户，在租约期间内有效。
+
+- 账户会在其租约的 80% 时间内被复用，而不是缓存时间；缓存为 `0` 时，每次查询都会读取一个新账户。
+- Vault 只返回用户和密码：请将连接的其余信息放在凭据行中。
+- 租约永远不会被提前撤销；当 Vault 结束租约时，账户随之过期。
diff --git a/i18n/zh/_configure/secret-stores/index.md b/i18n/zh/_configure/secret-stores/index.md
new file mode 100644
index 0000000..b209a90
--- /dev/null
+++ b/i18n/zh/_configure/secret-stores/index.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: 密钥库
+nav_order: 13
+has_children: true
+has_toc: false
+permalink: /secret-stores/
+translated_from: 595f94a84c4e8182b1b79289eb309a814dec1287
+---
+
+# 密钥库
+{: .no_toc }
+
+从密钥管理器读取凭据，而不是将其保存在 AnsibleForms 中
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：连接密钥管理器，并让凭据从中读取其用户和密码。
+
+---
+
+## 工作原理
+
+**密钥库** 是到某个密钥管理器的连接，在
+**连接 > 密钥库** 下添加。随后，**凭据** 可以指定一个密钥库及其中的某个位置
+（即 *密钥引用*）。当表单、playbook 或表达式使用该凭据时：
+
+- **用户** 和 **密码** 每次都从密钥库读取（在密钥库的缓存时间内复用）；
+- **主机**、**端口** 和 **数据库** 仍然使用凭据行中的值。当凭据行中
+  其中某项为空而密钥中包含它时，使用密钥中的值。
+
+表单仍按名称引用凭据，因此把密码移入密钥库不会改变
+表单中的任何内容。
+
+| 密钥库类型 | 状态 |
+|---|---|
+| HashiCorp Vault（KV v1 和 v2，令牌认证） | 可用 |
+| HashiCorp Vault 动态凭据（`<mount>/creds/<role>`） | 实验性 |
+| CyberArk Central Credential Provider（CCP） | 实验性 |
+
+---
+
+## 添加密钥库
+
+从 7.3.0 起，只有管理员才能添加、修改或删除密钥库，因为其令牌或密钥会被发送到其地址。每个密钥库都有以下字段：
+
+| 字段 | 含义 |
+|---|---|
+| 名称 | 凭据引用该密钥库时使用的名称。 |
+| 类型 | 密钥管理器。 |
+| 凭据 | 密钥库如何以及在哪里登录：[连接 > 凭据](../credentials.html) 中的一个凭据，在 **凭据** 步骤中选择，类型为 **HashiCorp Vault**（其令牌和地址）或 **CyberArk**。它保存基础 URL，例如 `https://vault.example.com:8200`，以及 TLS 设置：跳过证书验证，或用于私有 CA 的 PEM 格式 CA 证书包。它本身不能从密钥库读取。 |
+| 缓存（秒） | 已读取的密钥被复用的时长。`0` 表示每次使用时都读取。默认为 60。 |
+| 附加选项（JSON） | 特定于类型的选项，以 JSON 对象形式提供。 |
+
+在 7.2.0 及更早版本中，地址、令牌和 TLS 设置是密钥库的字段。升级到 7.3.0 时会将它们移入其
+凭据，名为 `<store>-token`（CyberArk 为 `<store>-appid`），参见 [凭据中的地址](../credentials/types.html#addresses-in-credentials)。
+
+**测试连接** 在不读取密钥的情况下检查访问权限。**状态** 页面会检查每个密钥库，并在 Vault 令牌过期前 7 天
+发出警告。
+
+每种密钥管理器都有自己的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [HashiCorp Vault](hashicorp-vault.html) | 使用令牌认证的 KV v1 和 v2，以及动态数据库凭据 |
+| [CyberArk](cyberark.html) | CyberArk Application Access Manager 的 Central Credential Provider（CCP） |
+
+---
+
+## 使用密钥库
+
+### 在凭据中
+
+在 **连接 > 凭据** 下，在凭据的 **存储** 步骤中选择 **密钥库**，然后选择
+**密钥库** 并填写 **引用**。这样用户和密码就从密钥库读取，而不是手动输入。
+
+### 内联方式，无需凭据行
+
+在任何接受凭据名称的地方，都可以改为直接引用密钥库（`fnCredentials`、`fnRestBasic`、
+表单的 `credentials:`、查询的 `dbConfig`）。
+
+```javascript
+fn.fnCredentials('secret:vault:secret/myapp/prod')   // secret:<store>:<reference>
+fn.fnCredentials('vault:secret/myapp/prod')          // the store named `vault`
+```
+
+```yaml
+- name: servers
+  type: enum
+  query: SELECT name FROM servers
+  dbConfig: secret:vault:secret/cmdb/db
+```
+
+没有凭据行时，数据库密钥至少需要 `db_type` 和主机，例如：
+
+```json
+{ "username": "forms", "password": "...", "host": "cmdb.example.com", "port": 3306,
+  "db_type": "mysql", "database": "cmdb" }
+```
+
+没有 `db_type` 时，该密钥是一个普通凭据（用户、密码以及其他任何键），对其进行的查询默认为 `mysql`。
+
+### 键名
+
+密钥通过以下别名映射到凭据。其他键会原样传递。
+
+| 凭据字段 | 密钥中可接受的键 |
+|---|---|
+| `user` | `user`、`username`、`login` |
+| `password` | `password`、`token`、`api_key`、`apikey`、`secret` |
+| `host` | `host`、`address` |
+| `port` | `port` |
+| `db_name` | `db_name`、`database` |
+| `db_type`、`secure` | 同名（仅限内联密钥） |
+
+对于凭据行，只有在凭据行中留空的地方，才会使用密钥中的主机、端口和
+数据库名称。
+
+结构不同的密钥可以用 `jq` 表达式重新整理，作为 `fnCredentials` 的第三个参数
+传入：
+
+```javascript
+// secret: { "creds": { "u": "admin", "p": "Netapp12" } }
+fn.fnCredentials('vault:secret/weird', '', '.creds | { user: .u, password: .p }')
+```
+
+---
+
+## 在配置种子中
+
+与其他管理对象一样，密钥库也可以在配置种子中声明：
+
+```yaml
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login        # its address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}  # the Vault token
+    - name: production-db
+      secret_store: vault
+      secret_ref: secret/forms/production-db
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      is_database: true
+```
+
+密钥库使用其凭据登录：`vault` 凭据在 `url` 中保存 Vault 的地址，并以令牌作为其密码；`cyberark`
+凭据保存 AppID 和 CCP 地址。没有凭据时，使用密钥库自身的 `url` 和 `token`。
+详情参见 [配置种子](../seed)。
+
+---
+
+## 从 VAULT_* 变量升级
+
+在 7 之前，唯一的密钥库是用 `VAULT_*` 环境变量配置的 HashiCorp Vault，
+凭据通过 **Vault path** 指向它。
+
+- **这些变量会被导入一次**，成为名为 `vault` 的密钥库；之后请将它们删除。
+- **带有 `vault_path` 的凭据** 现在使用该密钥库；`vault_path` 将在 8 中移除。
diff --git a/i18n/zh/_configure/security/hardening.md b/i18n/zh/_configure/security/hardening.md
new file mode 100644
index 0000000..23d1e75
--- /dev/null
+++ b/i18n/zh/_configure/security/hardening.md
@@ -0,0 +1,185 @@
+---
+layout: default
+title: 加固
+parent: 安全
+nav_order: 1
+redirect_from:
+  - /production/hardening.html
+translated_from: be22a8ac091b17a67815ab392de93cd0ff519dd9
+---
+
+# 加固
+{: .no_toc }
+
+管理员账户、登录限制、数据库、表达式、作业数据、浏览器策略、可选功能和角色选项
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 管理员账户
+
+本地管理员账户在首次启动时根据 [`ADMIN_USERNAME`](../customization/server.html#env_ADMIN_USERNAME)
+和 [`ADMIN_PASSWORD`](../customization/server.html#env_ADMIN_PASSWORD) 创建，后者的默认值为 `AnsibleForms!123`。
+
+* 使用公开的默认密码 `AnsibleForms!123` 登录后必须先修改密码：在此之前，服务器对除修改密码之外的
+  所有请求都返回 `403`（代码 `password_change_required`），浏览器会显示一个
+  无法关闭的修改密码页面。新密码不能再是默认密码。
+* `ADMIN_PASSWORD` 只在首次创建账户时读取：请在首次启动前设置您自己的值。
+* [`REINIT_ADMIN`](../customization/server.html#env_REINIT_ADMIN)`=1` 会在每次启动时将密码重置为 `ADMIN_PASSWORD`。
+  只用它来找回丢失的密码，然后取消设置并重启。
+* 先设置两个主密钥：参见 [密钥与加密](secrets.html)。
+* 一旦 LDAP 或 SSO 登录可用，请只将本地管理员留作紧急情况使用，并为其设置一个保存在您的密码库中的长密码。
+
+---
+
+## 登录限制与密码
+
+有三项限制可以减缓密码猜测。失败次数记录在数据库中，因此每个应用节点看到的
+尝试次数都相同，并且每项限制都无需重启即可生效：
+
+| 变量 | 默认值 | 作用 |
+|----------|---------|--------------|
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | `5` | 登录失败达到此次数后，本地或 LDAP 账户会被锁定 `LOGIN_LOCKOUT_MINUTES`。 |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | `30` | 在 `LOGIN_LOCKOUT_MINUTES` 内登录失败达到此次数的地址会被暂停，直到该时间窗口结束：针对一个地址尝试大量账户的情况。 |
+| [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES) | `15` | 账户保持锁定的时长，也是统计失败次数的时间窗口。 |
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | `120` | 每个应用节点上，来自同一地址对登录、退出登录、令牌刷新和单点登录回调的每分钟请求数。 |
+
+被锁定的账户或被暂停的地址会在检查任何密码之前收到带有 `Retry-After` 头的 `429`，
+无论该账户是否存在；超过 `AUTH_RATE_LIMIT` 时同样返回 `429`。成功登录会清除
+该账户的计数，管理员设置该用户的密码也会清除。`0` 关闭某项限制；`LOGIN_LOCKOUT_MINUTES=0`
+会同时关闭锁定和按地址的限制。
+
+`LOGIN_MAX_FAILURES_PER_IP` 和 `AUTH_RATE_LIMIT` 按客户端地址计数：在反向代理之后，请设置 `TRUST_PROXY`，
+使地址为客户端的而不是代理的，参见 [客户端地址](../production/reverse-proxy.html#client-addresses)。
+
+通过应用设置的本地密码，无论是为新用户、由管理员设置，还是用户修改自己的密码，都必须至少有
+[`PASSWORD_MIN_LENGTH`](../customization/security.html#env_PASSWORD_MIN_LENGTH) 个字符（默认为 `8`，
+`0` 表示不检查长度）。密码不能是用户名或公开的默认密码。`ADMIN_PASSWORD` 不受检查。
+
+---
+
+## 数据库
+
+AnsibleForms 将所有凭据和作业保存在其 MySQL 数据库中，因此请让该数据库远离网络：
+
+* docker-compose 项目在主机上发布 MySQL（`MYSQLDB_LOCAL_PORT`，`3306`），并自带 root
+  密码 `AnsibleForms!123`。请删除该端口映射，或将其绑定到 `127.0.0.1`，并修改密码。
+* 使用专用账户而不是 `root` 进行连接，在 [`DB_USER`](../customization/server.html#env_DB_USER) 和
+  [`DB_PASSWORD`](../customization/server.html#env_DB_PASSWORD) 中设置。它只需要对 `AnsibleForms` schema 的权限：
+
+  ```sql
+  CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+  GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+  ```
+
+  这涵盖了创建 schema（包括 `CREATE DATABASE`）、升级时修补 schema，以及
+  以同一用户身份运行的 [备份](../production/backups.html) 和恢复：导出使用
+  `--no-tablespaces`，因此不需要 `PROCESS` 之类的服务器级权限。如果可以，请将 `%` 替换为
+  应用的地址。像 `root` 一样对所有数据库都有权限的用户，会把应用中的一个漏洞变成
+  整个数据库服务器的漏洞：**状态** 页面会在其 **数据库用户** 检查项中对此发出警告，日志也会
+  在每次启动时发出警告。
+* schema 创建后，将 [`ALLOW_SCHEMA_CREATION`](../customization/server.html#env_ALLOW_SCHEMA_CREATION) 设为 `0`。
+  创建 schema 会先删除所有表；设为 `0` 时，启动引导和 `/api/v2/schema`
+  端点都无法执行它。
+
+---
+
+## 表达式与出站调用
+
+服务器表达式会为任何已登录用户在服务器上运行，因此净化器和出站过滤器非常重要：
+
+* [`EXPRESSION_SANITIZER`](../customization/security.html#env_EXPRESSION_SANITIZER)：`strict` 或 `paranoid`，永远不要用 `legacy`，它允许用户运行服务器代码。
+* [`REST_DENIED_HOSTS`](../customization/security.html#env_REST_DENIED_HOSTS)：REST 表达式不能访问的主机，例如 `169.254.169.254,127.0.0.0/8`。
+* [`REST_ALLOWED_HOSTS`](../customization/security.html#env_REST_ALLOWED_HOSTS)：设置后，REST 表达式只能访问
+  这些主机和范围。拒绝列表优先于它。
+
+这两个列表只覆盖 AnsibleForms 自身的 REST 辅助函数；playbook 在它们之外运行，不受过滤。
+
+从 7.3.0 起，REST 辅助函数会像其他所有连接一样检查端点的证书。
+[`REST_IGNORE_CERTS`](../customization/security.html#env_REST_IGNORE_CERTS)`=1` 会关闭检查：仅用于
+使用自签名证书的端点。
+
+---
+
+## 作业数据
+
+作业的 extravars 和输出保存在数据库中，并向所有能看到该作业的人显示：
+
+* [`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX)：键匹配的 extravars
+  显示为 `********`。默认值为 `password|secret|token`；密码字段总是会被掩码。请用
+  您的表单所用的名称扩展它，例如 `password|secret|token|apikey|passphrase`。
+* [`EXTRAVARS_USER_FIELDS`](../customization/security.html#env_EXTRAVARS_USER_FIELDS)：精简随每个作业发送的
+  `ansibleforms_user` 对象，否则它会包含用户的全部组成员关系。
+* [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) 只用于隐藏冗杂的任务；隐藏密钥请使用 `no_log`。
+
+---
+
+## Content-Security-Policy
+
+界面在提供时带有 Content-Security-Policy 头，它限制页面在浏览器中可以加载和运行的内容：
+
+* 脚本只能来自应用本身，因此注入页面的脚本不会运行。
+* 其他任何网站都不能在框架中显示该界面。
+* 它允许应用所需的内容：在浏览器中计算的本地表单表达式（`'unsafe-eval'`）、内联
+  样式、来自任意 URL 的图片（表单和类别图片），以及代码编辑器的 worker。
+
+[`CONTENT_SECURITY_POLICY`](../customization/security.html#env_CONTENT_SECURITY_POLICY) 默认为 `1`，并应
+保持不变。设为 `0` 时，策略以 `Content-Security-Policy-Report-Only` 发送：浏览器控制台会列出它本会
+阻止的内容，但不会阻止任何内容。仅在暂时无法配合该策略工作的部署中使用 `0`，例如会注入自己脚本的
+反向代理。在设置页面上的修改无需重启即可生效。
+
+---
+
+## 设置页面与设计器
+
+管理员可以从浏览器修改大部分配置。当配置保存在其他地方时，请收紧这一点：
+
+* [`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)`=0`：只读设置，用于 [托管环境](../seed/environment-and-audit.html)。
+* [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER)`=0`：当表单在 git 中维护时，移除内置的
+  设计器。
+
+---
+
+## 可选功能
+
+这些功能默认关闭。只在使用时才打开它们；在设置页面上的修改无需重启即可生效：
+
+* [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP)：在 `/api/v2/mcp` 上提供 [MCP 服务器](../mcp/)，
+  使 MCP 客户端可以使用用户的令牌启动表单。
+* [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT)：[聊天助手](../chat/)。表单定义
+  以及正在填写的值会被发送到配置的模型提供商。
+
+[`LAUNCH_VALIDATION`](../customization/features.html#env_LAUNCH_VALIDATION) 的作用方向正好相反：它默认为 `enforce`，
+因此服务器会拒绝值违反表单规则的启动，包括通过 REST API 的启动。
+请保持该设置：`log` 只记录本会被拒绝的内容，`off` 什么都不检查，参见 [启动验证](../launch-validation/)。
+
+---
+
+## 角色选项
+
+[config.yaml](../config/roles.html) 中的一些角色选项所赋予的权限比其名称所暗示的更多。请谨慎授予：
+
+| 选项 | 为什么重要 |
+|--------|----------------|
+| `allowScheduledJobs` | 拥有它的用户可以看到并修改所有调度，而调度会以管理员权限运行任意表单。请将其视为管理员级别。 |
+| `allowBackupOps` | 包括 **恢复**，它会替换整个数据库。 |
+| `showSettings` | 打开管理页面。没有管理员角色时，它不能修改管理员角色所引用的账户和组，参见 [用户和组](../users-and-groups.html#accounts-that-grant-admin)。 |
+| `showLogs` | 显示服务器日志，其中可能包含主机名、用户名和错误详情。 |
+| `showConnectionsSettings` | 打开连接页面：凭据、运行器、通知通道等。添加、修改和删除运行器及密钥库仍然只有管理员可以做，连接和登录所用的凭据也是如此。对于仓库，添加或删除它以及修改其地址、分支或 `use_for_*` 标志仍然只有管理员可以做。 |
+| `showAllJobLogs` | 显示所有用户的作业，而不仅是用户自己的。 |
+| `manageAllJobs` | 中止、删除和重新运行所有用户的作业。 |
+| `allowApiTokens` | 允许用户创建有效期最长为 [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS)（默认 90）的 API 令牌。使用令牌退出登录或撤销令牌会使其失效，修改密码会使该用户的所有令牌失效，参见 [令牌](secrets.html#tokens)。 |
+| `extendedTokenExpiration` | 与 `allowApiTokens` 一起使用时，还允许用户创建永不过期的 API 令牌。 |
+| `allowFileUploads` | 允许用户通过表单的文件字段上传文件。除非某个角色将其关闭，否则对所有用户都是打开的。 |
+| `allowChat`、`allowMcp` | 在聊天助手和 MCP 服务器打开时，允许用户使用它们。除非某个角色将其关闭，否则 `allowChat` 对所有用户都是打开的；除非某个角色设置了 `allowMcp`，否则它跟随 `allowChat`。 |
+
+没有 `admin` 角色的用户不会获得上述任何管理员级别的选项，除非某个角色授予了它们。当 `admin` 角色
+没有设置任何选项时，其用户会获得 `showSettings`、`showDesigner`、`showLogs`、`showAuditLog`、`allowBackupOps`、
+`allowJobRelaunch`、`showAllJobLogs`、`manageAllJobs` 和 `allowScheduledJobs`。`allowApiTokens` 和
+`extendedTokenExpiration` 即使对 `admin` 角色也保持关闭：请在需要它们的角色上设置。
+
+当用户的多个角色设置了同一选项时，`false` 优先。`default` 角色的选项只补充用户自己的角色
+都没有设置的选项；它们永远不会推翻这些角色的设置。
diff --git a/i18n/zh/_configure/security/https.md b/i18n/zh/_configure/security/https.md
new file mode 100644
index 0000000..a1cfef1
--- /dev/null
+++ b/i18n/zh/_configure/security/https.md
@@ -0,0 +1,97 @@
+---
+layout: default
+title: HTTPS
+parent: 安全
+nav_order: 2
+redirect_from:
+  - /production/https.html
+translated_from: 2d8601a66c8f664c1cf762e7829e2c1251248a19
+---
+
+# HTTPS
+{: .no_toc }
+
+由应用本身提供 HTTPS，并替换示例证书
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## TLS 在哪里终止
+
+TLS 可以在以下三个位置之一终止，只有第一种涉及本页的设置：
+
+* **在 AnsibleForms 中**，使用 `HTTPS=1`：在 [`PORT`](../customization/server.html#env_PORT) 上使用下面的文件提供 HTTPS，docker-compose 就是这样在 443 上提供的。
+* **在反向代理中**，其后的应用使用 `HTTPS=0`：参见 [反向代理](../production/reverse-proxy.html)。
+* **在 Kubernetes ingress 中**：参见 [Kubernetes](../installation/kubernetes.html#7-open-ansibleforms) 的 Ingress 选项卡以及 chart 的 README。
+
+您可以将第一种与另外两种结合使用，让代理与应用之间的这一段也加密。
+
+---
+
+## 设置
+
+有三个变量控制应用中的 HTTPS：
+
+| 变量 | 默认值 | 含义 |
+|----------|---------|---------|
+| [`HTTPS`](../customization/server.html#env_HTTPS) | `0` | `1` 提供 HTTPS，`0` 提供普通 HTTP |
+| [`HTTPS_KEY`](../customization/server.html#env_HTTPS_KEY) | `%PERSISTENT_FOLDER%/certificates/key.pem` | 私钥，PEM 格式 |
+| [`HTTPS_CERT`](../customization/server.html#env_HTTPS_CERT) | `%PERSISTENT_FOLDER%/certificates/cert.pem` | 服务器证书，PEM 格式 |
+
+在容器镜像中，持久化文件夹为 `/app/dist/persistent`，因此默认文件为
+`/app/dist/persistent/certificates/key.pem` 和 `cert.pem`。在 docker-compose 项目中，对应主机上的
+`data/certificates/`。
+
+---
+
+## 示例证书
+
+当 `HTTPS=1` 且启动时缺少任一文件时，AnsibleForms 会记录 `httpsKey or httpsCert not found, copying from
+templates`，并从镜像中将示例密钥和证书复制到配置的路径。如果复制失败，
+应用会停止。
+
+该证书是为 `CN=ansibleforms` 签发的自签名证书，并且 **在每个安装中都相同**：其私钥
+随公开镜像一起发布。用于初步试用没有问题，但浏览器会对其发出警告，并且任何人都可以解密
+受其保护的流量。在实例保存真实凭据之前，请替换它。
+
+---
+
+## 替换证书
+
+使用由您的 CA 或 ACME 客户端为用户输入的主机名签发的 PEM 格式证书。
+证书文件可以包含完整的证书链：先是服务器证书，然后是中间证书。
+
+1. 将文件复制到持久化文件夹，或应用可以读取的任何位置：
+
+   ```bash
+   sudo cp forms.example.com.key data/certificates/key.pem
+   sudo cp forms.example.com.fullchain.crt data/certificates/cert.pem
+   sudo chmod 600 data/certificates/key.pem
+   ```
+
+2. 如果文件位于其他位置，请将 `HTTPS_KEY` 和 `HTTPS_CERT` 设为它们 **在容器内** 的路径。
+
+3. 重启应用，它会在启动时读取这两个文件。
+
+如果需要快速生成一个您自己的自签名证书（用于测试实例，或代理之后的那一段），可以用 `openssl` 创建：
+
+```bash
+openssl req -x509 -newkey rsa:4096 -nodes -days 825 \
+  -keyout data/certificates/key.pem -out data/certificates/cert.pem \
+  -subj "/CN=forms.example.com" -addext "subjectAltName=DNS:forms.example.com"
+```
+
+---
+
+## 无需重启即可续期
+
+在设置页面上修改 `HTTPS_KEY` 或 `HTTPS_CERT`，会在正在运行的服务器中重新加载密钥和证书。
+新连接会获得新证书，已打开的连接保留旧证书。如果无法读取新文件，或它们不能构成有效的
+一对，当前证书会保持不变，并记录一条警告。
+
+只有当设置页面可以写入环境（[`ALLOW_ENV_EDIT`](../customization/configuration.html#env_ALLOW_ENV_EDIT)
+为 `1`）且该变量未在真实环境中设置时，这种方式才有效。当续期在相同路径下替换文件时，
+请重启应用。
diff --git a/i18n/zh/_configure/security/index.md b/i18n/zh/_configure/security/index.md
new file mode 100644
index 0000000..2efc7fd
--- /dev/null
+++ b/i18n/zh/_configure/security/index.md
@@ -0,0 +1,34 @@
+---
+layout: default
+title: 安全
+nav_order: 14
+has_children: true
+has_toc: false
+permalink: /security/
+translated_from: f2b18fd1638cb4ccb2401652eafb82e6ce0e82eb
+---
+
+# 安全
+{: .no_toc }
+
+加固实例：管理员账户、其密钥、HTTPS，以及用户和表单可以做什么
+{: .fs-6 .fw-300 }
+
+---
+
+面向为生产环境准备实例的管理员，以及对现有实例进行安全审查的人员。
+
+---
+
+## 本节内容
+
+每个主题都有自己的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [加固](hardening.html) | 管理员账户、登录限制、数据库、表达式、作业数据、浏览器策略、可选功能和角色选项 |
+| [HTTPS](https.html) | TLS 在哪里终止、由应用提供 HTTPS，以及替换示例证书 |
+| [密钥与加密](secrets.html) | `ENCRYPTION_SECRET`、`ACCESS_TOKEN_SECRET` 以及令牌有效期 |
+
+相关页面：登录方式参见 [身份验证](../authentication/)，每次启动时的服务器端检查参见 [启动验证](../launch-validation/)，
+以及 [安全变量](../customization/security.html)。
diff --git a/i18n/zh/_configure/security/secrets.md b/i18n/zh/_configure/security/secrets.md
new file mode 100644
index 0000000..1eac36e
--- /dev/null
+++ b/i18n/zh/_configure/security/secrets.md
@@ -0,0 +1,85 @@
+---
+layout: default
+title: 密钥与加密
+parent: 安全
+nav_order: 3
+translated_from: 88f3f3eaac372a4e373c4a49f5935635da47140d
+---
+
+# 密钥与加密
+{: .no_toc }
+
+两个主密钥、它们保护什么，以及会话和令牌的有效期
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 两个主密钥
+
+两个密钥保护着其他所有内容。请在实例保存真实数据之前设置这两个密钥，将它们保存在实例之外，
+并且永远不要随意更改：
+
+| 密钥 | 保护的内容 | 未设置时 | 丢失或更改时 |
+|--------|------------------|------------------|--------------------------|
+| [`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET) | 数据库中保存的每个密码和令牌：凭据、LDAP 绑定密码、运行器令牌、SSO 客户端密钥、Slack 和 Teams 的 webhook 地址、聊天 API 密钥 | 使用一个默认密钥，该密钥在源代码中是公开的 | 丢失：所有保存的密钥都必须重新输入。更改：从 7.3.0 起，所有保存的密钥都会被重新加密，参见 [下文](#changing-the-encryption-secret) |
+| [`ACCESS_TOKEN_SECRET`](../customization/security.html#env_ACCESS_TOKEN_SECRET) | 访问令牌和刷新令牌的签名，包括长期有效的 [API 令牌](../profile/api-token.html) | 每次启动时生成一个随机密钥，因此每次重启都会让所有人退出登录 | 所有会话和所有 API 令牌都会失效 |
+
+只要它们缺失，启动时都会记录一条 `[SECURITY]` 警告。设置页面拒绝编辑它们，
+API 从不返回它们，备份也会特意将它们排除在外，因此丢失的 `ENCRYPTION_SECRET` 无法从
+任何地方恢复：请在您的密钥管理器中保存一份副本。加密密钥用作 32 个字符的密钥；较短或
+较长的值会被填充或截断。
+
+更改 `ACCESS_TOKEN_SECRET` 会立即使所有会话和所有 API 令牌失效。要使某个用户或某个
+会话的令牌失效，请使用 [令牌](#tokens) 中介绍的撤销方式。
+
+---
+
+## 更改加密密钥
+
+从 7.3.0 起，设置或更改 `ENCRYPTION_SECRET` 不再会丢失已保存的密钥。下次启动时，worker 会在任何其他操作写入密钥之前，
+在一个数据库事务中用新密钥重新加密每一个已保存的密钥：
+
+| 情况 | 需要设置的内容 |
+|---|---|
+| 实例在没有 `ENCRYPTION_SECRET` 的情况下运行，使用的是公开的默认密钥 | 只需设置 `ENCRYPTION_SECRET`：密钥会从默认密钥重新加密 |
+| 实例使用您自己的密钥运行 | 在那一次启动中，将 `ENCRYPTION_SECRET` 设为新密钥，并将 [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) 设为旧密钥 |
+
+当已保存的密钥是用这两者之外的密钥加密时，不会做任何更改，应用会拒绝启动，直到
+`ENCRYPTION_SECRET_PREVIOUS` 指定了该密钥。启动完成重新加密后，请删除 `ENCRYPTION_SECRET_PREVIOUS`，并在
+每个应用节点、worker 以及每个自行注册的数据库模式 RTE 上设置新的 `ENCRYPTION_SECRET`。这种
+自行注册（`RTE_REGISTER`）在 7.3.0 中已弃用：在套接字模式下使用加入令牌（`RTE_JOIN_TOKEN`）加入的 RTE
+不需要 `ENCRYPTION_SECRET`，参见 [RTE 模式](../rte/modes.html)。
+
+---
+
+## 令牌
+
+登录会返回一个短期有效的访问令牌和一个有效期更长的刷新令牌，浏览器用后者获取一对新令牌：
+
+* [`ACCESS_TOKEN_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_EXPIRATION)：默认为 `30m`。较短的值
+  可以限制被截获令牌的使用。
+* [`ACCESS_TOKEN_REFRESH_EXPIRATION`](../customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION)：默认为
+  `24h`。这是空闲的浏览器保持登录的时长。
+* `allowApiTokens` 角色选项允许用户申请有效期为若干天的 API 令牌，
+  `extendedTokenExpiration` 还增加一种永不过期的令牌。只将它们授予需要从脚本访问 API 的角色。
+  在 [个人资料页面](../profile/api-token.html) 上，令牌只能从最多 10 分钟前登录的浏览器会话中生成，
+  永远不能从另一个 API 令牌生成。永不过期的令牌有效期为 50 年，下面的事件仍然可以使其失效。
+* [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS)：默认为 `90`。API 令牌的
+  最长有效期：更长的申请会被截断到这个值。
+
+令牌是签名的 JWT，但服务器还会保存一个已撤销令牌的列表，由所有应用节点共享，因此令牌
+可以在过期之前失效：
+
+| 事件 | 失效的内容 |
+|-------|-----------|
+| 退出登录 | 该次登录的所有令牌：访问令牌、其刷新令牌，以及使用 API 令牌退出登录时的该 API 令牌 |
+| 用户或管理员修改密码 | 该用户在修改之前签发的所有令牌，包括 API 令牌，在所有设备上 |
+| 关闭用户的 **允许登录** 开关（本地、LDAP 或 SSO 用户），或删除本地用户 | 该用户的所有令牌 |
+| 在 LDAP 或 SSO 用户的页面上点击 **结束会话** | 该用户的所有令牌；除非被阻止，否则他们可以再次登录 |
+| 在个人资料页面或用户的 **API 令牌** 选项卡上对某个 API 令牌点击 **撤销** | 该 API 令牌，立即失效 |
+
+脚本可以使用其 API 令牌退出登录来使该令牌失效：在 `Authorization` 头中携带该令牌调用
+`POST /api/v2/auth/logout`。
diff --git a/i18n/zh/_configure/seed/environment-and-audit.md b/i18n/zh/_configure/seed/environment-and-audit.md
new file mode 100644
index 0000000..bdfa772
--- /dev/null
+++ b/i18n/zh/_configure/seed/environment-and-audit.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 编辑与审计
+parent: 配置种子
+nav_order: 5
+translated_from: 84af9202344ae1fc62b7b882fdc12f1799dd1bd3
+---
+
+# 编辑与审计
+{: .no_toc }
+
+锁定设置页面，以及审计日志记录的内容
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 关闭环境编辑
+
+`ALLOW_ENV_EDIT=0` 使设置页面变为只读。每个变量仍会显示
+当前生效的值以及无法修改的原因，保存端点则返回
+403。
+
+只要环境是在其他地方声明的，就请使用它。否则设置页面会写入
+`persistent/.env`，在临时卷上它会在下次重启时悄无声息地丢失，在
+持久卷上则会逐渐偏离本应作为权威来源的清单。
+
+{: .note }
+> 备份会将 `persistent/.env` 作为 `managed.env` 包含在内，因此重建时可以恢复数据库和
+> 路径设置。**`ENCRYPTION_SECRET` 和 `ACCESS_TOKEN_SECRET` 会被剔除**：
+> 旁边的导出文件以 AES 密文保存了每个已保存的凭据，如果把解密它的密钥
+> 写入同一个文件夹，复制一份备份就足以读取所有凭据。请改为在目标主机上设置
+> 这两个变量；文件中的一条注释说明了这一点。
+>
+> 剩下的内容仍可能包含凭据（`DB_PASSWORD`、`METRICS_TOKEN`、旧的 `VAULT_TOKEN`），因此该文件
+> 以 `0600` 写入。恢复它是一个单独的、需要主动选择的步骤，而不是常规恢复的一部分，
+> 因为其中的数据库主机和路径描述的是备份来源的机器。
+> 恢复对话框会列出该文件，并提供单独的 *恢复环境* 按钮
+> （`POST /api/v2/backup/:folder/restore-env`），它会将之前的文件保存为 `.env.bak`。
+
+---
+
+## 记录的内容
+
+每次产生更改的应用都会向审计日志写入一条 `seed.apply` 条目，列出
+创建、更新、释放和清理的对象。值永远不会被记录，因为其中大多数
+都是密钥。没有任何更改的应用不会写入任何内容，这让审计记录保持有意义。
+发现文件未改变的轮询也属于无更改的应用，因此审计记录不会每分钟都多出一行。
+
+通过端点请求的应用会被特意记录两次，这两行
+记录的内容不同：`config-seed.apply.create` 记录的是 **谁** 请求了它，`seed.apply` 记录的是
+它 **更改了什么**。
+
+状态页面会两次报告种子：一个 **检查项**，检查文件是否仍可读取和解析，
+以及上次重新加载是否成功；以及一个 **信息** 行，说明它当前拥有多少条记录。
+当磁盘上的文件与当前生效的配置出现偏差时，只有该检查项会报告，因为重新加载失败时实例仍会继续运行。
diff --git a/i18n/zh/_configure/seed/example.md b/i18n/zh/_configure/seed/example.md
new file mode 100644
index 0000000..ccfa635
--- /dev/null
+++ b/i18n/zh/_configure/seed/example.md
@@ -0,0 +1,211 @@
+---
+layout: default
+title: 示例
+parent: 配置种子
+nav_order: 1
+translated_from: f085641a12234a5485ea59e73e76c29e7452d5e9
+---
+
+# 示例
+{: .no_toc }
+
+一个完整的种子文件，逐部分说明
+{: .fs-6 .fw-300 }
+
+---
+
+下面的种子文件声明了除 `oauth2` 和已弃用的 `awx` 之外的所有部分；密钥来自 `${SEED_AWX_TOKEN}` 这样的
+环境变量：
+
+```yaml
+version: 1
+
+runners:
+  items:
+    - name: rte01
+      type: rte                  # rte, awx, semaphore, rundeck or jenkins
+      rte_mode: inbound          # an RTE's RTE_MODE: outbound, inbound or database (deprecated, the default)
+      credential: rte01          # a credential of the credentials section, of the runner's type
+      is_default: true           # playbook forms that name no runner run here
+    - name: tower
+      type: awx
+      credential: tower
+      is_default: true           # one default per type
+      enabled: true              # false: no job goes to it; left as it is when not declared
+
+secret_stores:
+  items:
+    - name: vault
+      type: vault
+      credential: vault-login    # a vault credential of the credentials section: the store's address and token
+
+credentials:
+  items:
+    - name: vault-login
+      credential_type: vault     # how the secret store vault logs in, and where
+      url: https://vault.example.com:8200
+      password: ${SEED_VAULT_TOKEN}   # the Vault token
+    - name: rte01
+      credential_type: rte       # an RTE's token, and its address unless it is outbound
+      url: http://rte01.example.com:8000
+      password: ${SEED_RTE_TOKEN}   # the RTE_TOKEN of that RTE
+    - name: tower
+      credential_type: awx       # also aap, ascender, semaphore, rundeck, jenkins
+      url: https://tower.example.com
+      password: ${SEED_AWX_TOKEN}
+    - name: production-db
+      user: svc_forms
+      password: ${SEED_DB_PW}
+      host: db.example.com
+      port: 3306
+      db_type: mysql
+      credential_type: database
+    - name: ontap-rest
+      credential_type: userpass   # a user and password for a REST API, the default
+      user: svc_forms
+      password: ${SEED_ONTAP_PW}
+    - name: smtp-login
+      credential_type: smtp      # a mail server and its login: host is required
+      host: smtp.example.com
+      port: 587
+      secure: false              # true: Use TLS to the mail server
+      user: svc_forms            # leave user and password out for a relay
+      password: ${SEED_SMTP_PW}
+
+repositories:
+  prune: true
+  items:
+    - name: forms
+      uri: https://git.example.com/forms.git
+      branch: main
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+
+syslog_servers:
+  items:
+    - name: siem
+      host: siem.example.com
+      port: 6514
+      protocol: tls4             # udp4 (default), udp6, tcp4, tcp6, tls4, tls6, unix, unix-connect
+      type: "5424"               # BSD (default) or 5424
+      receives: audit            # log, audit or both (default)
+      enabled: true
+    - name: syslog
+      host: syslog.example.com
+      level: notice              # the lowest level of the server log it gets (info by default)
+      receives: log
+
+notification_channels:
+  items:
+    - name: mail
+      type: mail                 # mail, slack, teams, telegram or webhook
+      credential: smtp-login     # an smtp credential: the server, port, TLS and login it sends with
+      from_address: ansibleforms@example.com
+      is_active: true            # the mail channel the application sends its mail with
+    - name: ops-slack
+      type: slack
+      webhook_url: ${SEED_SLACK_WEBHOOK}
+
+labels:
+  items:
+    - name: Production           # the text of a label beside the header's logo, 40 characters at most
+      color: red                 # blue, green, amber, orange, red or grey
+      enabled: true
+      position: 1                # its place among the labels, lowest first
+
+# ldap and settings are single-row sections, so EVERY field must be declared - see
+# "Single-row sections are all or nothing" below. Empty is a perfectly good value.
+ldap:
+  server: ldap.example.com
+  port: 389
+  ignore_certs: false
+  enable_tls: false
+  cert: ""
+  ca_bundle: ""
+  bind_user_dn: cn=bind,dc=example,dc=com
+  bind_user_pw: ${SEED_LDAP_PW}
+  search_base: dc=example,dc=com
+  username_attribute: uid
+  groups_attribute: memberOf
+  enable: true
+  groups_search_base: ""
+  group_class: ""
+  group_member_attribute: ""
+  group_member_user_attribute: ""
+  mail_attribute: mail
+  groupfilter: ""            # optional, see below
+
+settings:
+  mail_server: smtp.example.com
+  mail_port: 587
+  mail_secure: false
+  mail_username: ""
+  mail_password: ""
+  mail_from: ansibleforms@example.com
+  url: https://forms.example.com
+
+chat:                        # the chat assistant's model provider (6.5)
+  provider: anthropic        # see below, or "" (chat off)
+  api_key: ${SEED_CHAT_API_KEY}
+  base_url: ""               # empty for the provider default ; azure and custom need one
+  model: claude-opus-5-5
+  max_turns: 20
+  max_tool_rounds: 6
+  timeout_seconds: 60
+  allow_job_status: true
+  # optional - for a proxy or a vendor with its own ways
+  auth_type: ""              # "" (provider default) | bearer | api-key | x-api-key | none
+  api_version: ""            # e.g. 2024-10-21 for Azure OpenAI
+  request_user: ""           # sent as user, e.g. for a proxy that requires one
+  ignore_certs: false        # true skips the certificate check (a self-signed proxy) - insecure
+  extra_headers:             # a mapping of extra request headers
+    X-Org: ops
+```
+
+`provider` 为以下之一：
+
+* `anthropic`
+* `openai`
+* `azure`
+* `gemini`
+* `grok`
+* `mistral`
+* `deepseek`
+* `groq`
+* `openrouter`
+* `ollama`
+* `custom`：任何其他兼容 OpenAI 的端点
+
+与 `ldap` 一样，`chat` 部分是单行记录，因此除可选字段外，所有字段都是必填的；
+省略的可选字段保持不变。
+
+聊天助手还需要 `ENABLE_CHAT=1`；参见 [聊天助手](../chat) 页面。
+
+从 7.3.0 起，运行器使用其类型的凭据登录，该凭据在 `url` 中保存其服务器的地址。自带 `token`，
+或 `username` 和 `password` 的运行器仍然有效：种子会记录一条警告，并将它们转换为这样一个以运行器命名的凭据。
+引用 `api` 或 `userpass` 凭据的运行器也仍然有效，同样会有警告：请改为将该凭据设为运行器的类型。
+两者都自 7.3.0 起弃用，并将在 8.0.0 中移除。没有 `rte_mode` 的 RTE 运行器处于数据库模式，已弃用（参见
+[模式](../rte/modes.html)）。`enabled: false` 的运行器不会接收任何作业，即使它是该类型的默认运行器（参见
+[默认与已启用](../runners/list.html#default-and-enabled)）；没有 `enabled` 时，种子会保持其现状。
+
+除了 `name`、`type`、`description`、`credential`、`is_default` 和 `enabled` 之外，运行器项还接受以下键：
+
+| 键 | 设置的内容 |
+|---|---|
+| `rte_mode` | RTE 的模式：`outbound`、`inbound` 或 `database`（已弃用，默认值） |
+| `rte_max_jobs` | 套接字模式 RTE 的 **最大并发作业数**，`0` 到 `10000`（`0`：不限制） |
+| `rte_cache_mb` | 其 **作业文件缓存**，单位为 MB，`0` 到 `1048576`（`0` 表示不保留） |
+| `rte_files` | 其 **作业文件**：`transfer` 或 `local` |
+| `rte_drain_seconds` | 其 **停止时的等待时间**，单位为秒，`0` 到 `86400` |
+| `flavour` | 属于 AAP 或 Ascender 的 `awx` 运行器：`aap` 或 `ascender`；AWX 不设置 |
+| `project` | Semaphore 运行器的项目 ID、Rundeck 运行器的项目名称、Jenkins 运行器的文件夹 |
+| `uri`、`ignore_certs`、`ca_bundle` | 7.3.0 之前运行器自己的地址和 TLS：仅在其凭据中没有 `url` 时使用 |
+
+这四项 `rte_*` 设置就是运行器页面 RTE 选项卡上的设置（参见 [RTE 的设置](../runners/runner-page.html#an-rtes-settings)）：
+它们优先于 RTE 上设置的同名变量，数据库模式的 RTE 会忽略它们。超出范围的值会导致种子
+验证失败。
+
+数据库模式的 RTE 可能会在种子应用之前自行注册。当种子中 RTE 运行器的 `uri` 与这样一个 RTE
+注册时使用的地址相同时，它会 **接管** 那一行：它采用声明的名称和字段，RTE 不再应答时 worker 也不会再删除它，
+从而不会为同一个 RTE 出现第二个运行器。
diff --git a/i18n/zh/_configure/seed/index.md b/i18n/zh/_configure/seed/index.md
new file mode 100644
index 0000000..cf97e1d
--- /dev/null
+++ b/i18n/zh/_configure/seed/index.md
@@ -0,0 +1,68 @@
+---
+layout: default
+title: 配置种子
+nav_order: 4
+has_children: true
+has_toc: false
+permalink: /seed/
+translated_from: 030ff83b1d7c3920600b7e0668b05ab24b949b67
+---
+
+# 配置种子
+{: .no_toc }
+
+在文件中声明管理对象
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向通过 git 进行部署的管理员：在文件中声明管理对象，以便在空数据库上重建实例。
+
+---
+
+## 涵盖的内容
+
+将 `CONFIG_SEED_PATH` 设为一个 YAML 文件，AnsibleForms 会在启动时应用它。该文件
+声明以前只存在于数据库中的对象：
+
+| 部分                    | 声明的内容                                                          |
+|-------------------------|---------------------------------------------------------------------|
+| `runners`               | 作业的运行位置：RTE、AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins |
+| `secret_stores`         | 密钥库（HashiCorp Vault 等）                                        |
+| `credentials`           | 凭据                                                                |
+| `oauth2`                | SSO 提供商：Entra ID 和 OIDC                                        |
+| `repositories`          | Git 仓库                                                            |
+| `syslog_servers`        | 接收服务器日志和审计条目的 syslog 服务器                            |
+| `notification_channels` | 用于通知的邮件服务器、Slack、Teams、Telegram 和 webhook             |
+| `labels`                | 页眉徽标旁的标签，从 7.3.0 起                                       |
+| `ldap`                  | LDAP 配置                                                           |
+| `settings`              | 公共 URL，以及没有活动邮件通道时使用的邮件设置                      |
+| `chat`                  | 聊天助手的模型提供商                                                |
+| `awx`                   | 自 7 起已弃用，将在 8 中移除：请使用 `type: awx` 的 `runners`       |
+
+7 之前编写的种子仍然有效：其 `awx` 部分的每一项都会作为类型为 `awx` 的运行器应用，日志
+会在每次应用时发出警告。在升级到 8 之前，请将这些项移到 `runners` 下并设置 `type: awx`。
+
+种子与 `config.yaml` **不同**，后者保存类别、角色和常量，
+并有自己的 `CONFIG_PATH`。两者是有意分开的：
+*保存* `config.yaml` 的仓库是种子所声明的对象之一，因此种子
+不能放在该仓库中。
+
+用户和组不在其中：它们来自 LDAP 或 SSO，第一个管理员则来自 `ADMIN_USERNAME` / `ADMIN_PASSWORD`。
+
+---
+
+## 本节内容
+
+每个主题都有自己的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [示例](example.html) | 一个完整的种子文件，逐部分说明 |
+| [托管对象](managed-objects.html) | 种子如何拥有它列出的对象，以及它如何避免包含密钥 |
+| [重新加载与启动](reloading.html) | 无需重启即可修改文件，以及启动时会发生什么 |
+| [Kubernetes](kubernetes.html) | 从 ConfigMap 和 Secret 部署 AnsibleForms |
+| [编辑与审计](environment-and-audit.html) | 锁定设置页面，以及审计日志记录的内容 |
diff --git a/i18n/zh/_configure/seed/kubernetes.md b/i18n/zh/_configure/seed/kubernetes.md
new file mode 100644
index 0000000..8612459
--- /dev/null
+++ b/i18n/zh/_configure/seed/kubernetes.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: Kubernetes
+parent: 配置种子
+nav_order: 4
+translated_from: faae2b35e3b483f560c320f8999ed5b6d1029aea
+---
+
+# Kubernetes
+{: .no_toc }
+
+从 ConfigMap 和 Secret 部署 AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+从 `ConfigMap` 挂载种子，从 `Secret` 挂载其密钥：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: ansibleforms
+spec:
+  # AF_ROLE unset : the web app and the worker in one pod. See the note below.
+  replicas: 1
+  strategy:
+    type: Recreate
+  selector:
+    matchLabels: { app: ansibleforms }
+  template:
+    metadata:
+      labels: { app: ansibleforms }
+    spec:
+      terminationGracePeriodSeconds: 120
+      containers:
+        - name: ansibleforms
+          image: ghcr.io/ansibleforms/ansibleforms:7
+          env:
+            - name: CONFIG_SEED_PATH
+              value: /seed/seed.yaml
+            # a ConfigMap edited in git is remounted here within about a minute and
+            # applied from there, so changing the seed does not roll the pod
+            - name: CONFIG_SEED_RELOAD_SECONDS
+              value: "60"
+            # the environment is declared here, so the settings pages must not
+            # write persistent/.env behind this manifest's back
+            - name: ALLOW_ENV_EDIT
+              value: "0"
+          envFrom:
+            - secretRef:
+                name: ansibleforms-seed-secrets   # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
+            - secretRef:
+                name: ansibleforms-secrets        # DB_PASSWORD, ENCRYPTION_SECRET, ...
+          volumeMounts:
+            - name: seed
+              mountPath: /seed
+              readOnly: true
+            - name: persistent
+              mountPath: /app/dist/persistent
+          livenessProbe:
+            # answers as long as the process runs, without asking the database
+            httpGet: { path: /api/v2/live, port: 8000 }
+          readinessProbe:
+            # 503 until the database answers and the schema is complete, and while stopping
+            httpGet: { path: /api/v2/ready, port: 8000 }
+      volumes:
+        - name: seed
+          configMap:
+            name: ansibleforms-seed
+        - name: persistent
+          persistentVolumeClaim:
+            claimName: ansibleforms-persistent
+```
+
+{: .note }
+> **一个 pod，不设置 `AF_ROLE`。** 这个 pod 在一个进程中运行 Web 应用和 worker。调度、每晚
+> 备份和其他后台工作只在持有数据库中 worker 锁的进程里运行，设计器锁
+> 是一张数据库表，playbook 则在 RTE 上运行，而不是在这个 pod 中。尽管如此，仍请保持 `replicas: 1` 并使用 `Recreate`
+> 策略：升级时，新 pod 会等待 worker 修补 schema，而旧 pod 在停止之前一直持有
+> worker 锁。要运行多个 Web 节点，请将它们拆分为 `AF_ROLE=app` 节点和一个 worker，如
+> [扩展](../production/scaling.html) 所述。
+
+必须在输入任何凭据之前设置 `ENCRYPTION_SECRET`。一旦凭据来自
+种子，数据库实际上就成了一个缓存，因此轮换它意味着重新应用
+种子，而不是手动重新输入所有内容。
+
+这两个探针都不需要登录。在 [`BASE_URL`](../customization/server.html#env_BASE_URL) 下，它们的路径以其开头，
+[监控](../production/monitoring.html) 介绍了每个探针检查的内容。
diff --git a/i18n/zh/_configure/seed/managed-objects.md b/i18n/zh/_configure/seed/managed-objects.md
new file mode 100644
index 0000000..01c7605
--- /dev/null
+++ b/i18n/zh/_configure/seed/managed-objects.md
@@ -0,0 +1,91 @@
+---
+layout: default
+title: 托管对象
+parent: 配置种子
+nav_order: 2
+translated_from: dd0ea4d46391bf9b2e5928063cd30e33ac1285f9
+---
+
+# 托管对象
+{: .no_toc }
+
+种子如何拥有它列出的对象，以及它如何避免包含密钥
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 单行部分要么全有，要么全无
+
+`ldap`、`settings` 和 `chat` 各自都是 **单行记录**，因此种子必须声明它们的所有字段；其他部分都是列表。
+
+省略了某个字段的种子会拒绝启动，并指出该字段：
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
+```
+
+请用 `""` 或 `false` 显式声明空值。有几个字段是可选的，省略时保持不变：
+
+| 部分 | 可选字段 |
+|---|---|
+| `ldap` | `description`、`credential`（用于绑定的凭据）和 `groupfilter` |
+| `chat` | `auth_type`、`api_version`、`request_user`、`ignore_certs` 和 `extra_headers` |
+| `settings` | 无 |
+
+`settings` 只涵盖邮件字段和 URL；其他所有设置仍可编辑。
+
+---
+
+## 文件中不包含密钥
+
+每个 `${VARIABLE}` 都会被替换为对应的环境变量（在 Kubernetes 上来自 `Secret`），因此该文件可以放在 Git 中。
+
+未设置的变量会导致 **致命错误**，因此占位符永远不会被当作密码保存。
+
+凭据也可以使用 [密钥库](../secret-stores)（`secret_store`、`secret_ref`）；`vault_path` 将在 8 中移除。
+
+---
+
+## 托管对象
+
+来自种子的对象会被标记为 **托管**：
+
+- 它在 **每次** 启动时都会被强制应用，因此文件始终是权威来源。
+- 它是只读的：API 返回 **403**，界面会禁用编辑和删除，其页面会说明它来自配置
+  种子文件且为只读。
+- 只有种子可以设置或清除该标记。
+
+手动创建的对象 **永远不会被改动**，除非种子声明了同一名称。这时该记录会被 **接管**：
+声明的字段会被强制应用，它也会变为只读。接管会作为警告记录到日志和审计记录中。
+
+应用种子是幂等的：已经匹配的记录保持不变，因此重启通常会报告 `0 updated`。
+
+缺少工作树的已声明仓库会在每次启动时 **重新克隆**，因此首次克隆失败后
+会被重试。状态页面的 *仓库* 行会显示任何没有工作树的仓库。
+
+### 删除对象
+
+从文件中删除一个对象会 **释放** 它：记录会保留，并重新变为可编辑。删除整个部分
+也是如此。
+
+在列表部分中添加 `prune: true`，即可 **删除** 文件不再声明的托管记录：
+
+```yaml
+credentials:
+  prune: true
+  items:
+    - name: production-db
+      # anything else the seed used to manage is deleted
+```
+
+`prune` 永远不会删除手动创建的记录。
+
+### 关闭种子
+
+取消设置 `CONFIG_SEED_PATH` **不会** 释放任何内容：种子不再被应用，它所管理的记录仍保持托管
+和只读。要再次编辑它们，请先释放它们：将 `CONFIG_SEED_PATH` 指向一个不包含它们的文件（空文件不声明
+任何内容，会释放所有记录），让它在启动或重新加载时应用，然后再取消设置该变量。被释放的记录保持
+原样，并变为可编辑。
diff --git a/i18n/zh/_configure/seed/reloading.md b/i18n/zh/_configure/seed/reloading.md
new file mode 100644
index 0000000..821b456
--- /dev/null
+++ b/i18n/zh/_configure/seed/reloading.md
@@ -0,0 +1,81 @@
+---
+layout: default
+title: 重新加载与启动
+parent: 配置种子
+nav_order: 3
+translated_from: d6cc2dfaf45589a284b52223737ed04ac4330e67
+---
+
+# 重新加载与启动
+{: .no_toc }
+
+无需重启即可修改文件，以及启动时会发生什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 无需重启即可修改文件
+
+种子每隔 `CONFIG_SEED_RELOAD_SECONDS`（默认 60，`0` 表示关闭）重新读取一次，
+在其内容发生变化时重新应用。因此，提交到 git 的更改会自动到达
+正在运行的实例：在 Kubernetes 上，`ConfigMap` 会在大约一分钟内重新挂载到 pod 下，
+下一次检查就会读取到它。无需滚动发布，无需重启，也不需要
+任何钩子去调用什么。
+
+对于未改变的文件，轮询只计算一次哈希就会停止，因此它永远不会改写已经
+应用过的行。
+
+要立即应用文件而不是等待下一次检查，可以使用以下任一方式：
+
+```
+POST /api/v2/config-seed/apply     # settings admin ; answers with what it did
+kill -HUP 1                        # inside the container, no credentials needed
+```
+
+两者都会 **强制** 应用，即使文件没有改变。强制应用会重新确立
+直接在数据库中被编辑过的托管记录，并重新克隆缺少工作树的已声明仓库。
+
+{: .note }
+> 与启动时的应用不同，重新加载 **永远不会是致命的**。已经在
+> 提供服务的实例会保持其当前配置，原因会被记录到日志中，状态页面上的 *配置种子* 行
+> 会变红并指出原因。推送到 git 的一个拼写错误，不应该在没有任何运维操作的情况下
+> 让正在运行的实例宕机。
+>
+> 同样损坏的内容也不会在每次检查时重试；否则一次错误的编辑就会
+> 无限期地向日志写入同一条错误。请修复文件，或调用端点立即
+> 重试。
+
+---
+
+## 损坏的种子会拒绝启动
+
+无法读取的文件、无效的 YAML、未知字段、重复的名称或未解析的
+`${VARIABLE}` 会让服务器 **退出** 而不是启动。这只是 **启动** 时的
+路径：同一个文件对已经运行的实例会产生什么影响，请参见上面的说明。
+
+这是有意为之。继续使用之前的配置，会让实例的
+行为不再与本应描述它的清单相符，而且没有任何东西
+报告这种不一致。原因会同时写入标准错误和日志文件，因此
+`kubectl logs` 和 `docker logs` 都能显示它。
+
+验证是严格的：未知字段会被拒绝而不是忽略，错误会指出
+有问题的键：
+
+```
+Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
+```
+
+---
+
+## 空数据库会自行初始化
+
+在 `ALLOW_SCHEMA_CREATION` 打开时（默认），**完全没有任何 AnsibleForms
+表** 的数据库会在启动时创建其 schema。因此，全新的部署无需任何人
+手动调用 `/schema` 端点即可启动。
+
+这个前提条件是有意设得很严格的：创建 schema 会 **先删除所有表**，因此
+它只会在完全为空的数据库上运行。缺少某一列的数据库，或者有表但没有用户账户的数据库，
+都 *不算* 空，会保持不变；这些情况由 schema 补丁处理。
diff --git a/i18n/zh/_configure/users-and-groups.md b/i18n/zh/_configure/users-and-groups.md
new file mode 100644
index 0000000..9ddf998
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: 用户和组
+nav_order: 15
+has_children: true
+has_toc: false
+permalink: /users-and-groups.html
+translated_from: 8ed4dc089c64e091636c29884af1cd1002eb40aa
+---
+
+# 用户和组
+{: .no_toc }
+
+本地用户和组、与之并列的 LDAP 和单点登录用户和组，以及阻止登录
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：在 **设置 > 访问 > 用户** 和 **组** 下管理谁可以登录，需要 `showSettings` 角色选项。
+
+内置管理员、登录顺序以及本地账户的角色映射见 [本地账户](authentication/local.html)。
+
+---
+
+## 本节内容
+
+| 页面 | 内容 |
+|---|---|
+| [本地用户](users-and-groups/local-user.html) | 添加本地用户，以及其页面的各个选项卡 |
+| [多个组](users-and-groups/several-groups.html) | 属于多个组的本地用户及其角色 |
+| [本地组](users-and-groups/local-group.html) | 本地组的页面及其选项卡 |
+| [目录用户和组](users-and-groups/directory.html) | LDAP、Entra ID 和 OIDC 的用户和组，按最近一次所见记录 |
+| [阻止登录](users-and-groups/blocking-a-sign-in.html) | 允许登录：在不删除任何内容的情况下阻止用户 |
+
+
+---
+
+## 列表
+
+**用户** 和 **组** 列表显示本地用户和组，以及与之并列的 LDAP 和单点登录用户和组。
+
+LDAP、Entra ID 或 OIDC 的用户或组在登录过（或在某次登录中出现过）之后，或者被某个角色引用之后，就会出现在列表中。
+**来源** 列说明每一项来自哪里：本地、LDAP、Microsoft Entra ID 或 OIDC。从 7.3.0 起，**用户** 列表还
+有一个 **上次登录** 列，说明每个用户上次登录的时间。
+
+点击某一行会打开对应用户或组的页面。**添加用户** 和 **添加组** 创建本地用户或组。
+
+---
+
+## 授予管理员权限的账户
+
+config.yaml 中的 admin 角色引用本地组和用户，因此只有管理员才能修改它所引用的账户和组。
+
+拥有 `showSettings` 但没有 admin 角色的用户，不能修改、阻止、重新分组、设置密码或删除
+admin 角色所引用的本地账户（无论是直接引用还是通过其所属的某个组引用）。他们也不能创建、重命名或删除
+admin 角色所引用的组，或将用户加入这样的组。映射到 admin 角色的 LDAP 或 SSO 用户也是如此：阻止
+该用户、结束其会话、忘记该用户以及撤销其 API 令牌都只能由管理员进行。服务器会对这类请求返回 `403`。
+
diff --git a/i18n/zh/_configure/users-and-groups/blocking-a-sign-in.md b/i18n/zh/_configure/users-and-groups/blocking-a-sign-in.md
new file mode 100644
index 0000000..11d304f
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups/blocking-a-sign-in.md
@@ -0,0 +1,20 @@
+---
+layout: default
+title: 阻止登录
+parent: 用户和组
+nav_order: 5
+translated_from: cef313768e48582a8da62114bf837af3e5735b73
+---
+
+# 阻止登录
+{: .no_toc }
+
+允许登录：在不删除任何内容的情况下阻止用户
+{: .fs-6 .fw-300 }
+
+**允许登录** 开关可以在不删除任何内容的情况下阻止一个用户，无论是本地用户还是来自目录的用户。
+
+确认后将其关闭，该用户的会话会立即结束，所有登录都会被拒绝，直到您重新打开它。
+用户列表的每行菜单中也有 **阻止登录** 和 **允许登录**，作用相同。
+
+您不能阻止用户 `admin`，也不能阻止您自己的登录。
diff --git a/i18n/zh/_configure/users-and-groups/directory.md b/i18n/zh/_configure/users-and-groups/directory.md
new file mode 100644
index 0000000..377354d
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups/directory.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: 目录用户和组
+parent: 用户和组
+nav_order: 4
+translated_from: 4798556ab97e1c3567a81681919e13c57d7a5b4f
+---
+
+# 目录用户和组
+{: .no_toc }
+
+LDAP、Entra ID 和 OIDC 的用户和组，按最近一次所见记录
+{: .fs-6 .fw-300 }
+
+LDAP、Entra ID 或 OIDC 用户的页面位于 `/settings/users/<source>/<name>`，来源为 `ldap`、`azuread` 或 `oidc`，
+例如 `/settings/users/ldap/jdoe`。它以只读方式显示该用户上次登录时记录的内容，
+因为用户的身份及其所属的组由目录或身份提供商负责。
+
+其选项卡与本地用户相同。**详情** 中有 **允许登录** 开关、用户名、来源、名称、
+电子邮件、首次出现时间以及上次登录时间。**组** 列出上次登录时的组。
+**API 令牌** 列出该用户的 API 令牌，**撤销** 会立即使其中一个失效。
+
+右上角的 **结束会话** 会立即让该用户在所有地方退出登录。**忘记** 会删除该记录，该记录会在用户下次登录时
+重新出现；其作业、保存的作业和调度会保留。被阻止的用户不能被忘记，因为那样
+会让他们重新进入：服务器会返回 `409`，因此请先允许其登录。
+
+该记录中的组也是用户会话所使用的组，并且是实时读取的。忘记一个已登录的用户，
+会让其在重新登录之前没有任何组，也没有这些组所赋予的角色。
+
+目录组的页面位于 `/settings/groups/<source>/<name>`，为只读，包含选项卡 **详情**、
+**用户**（上次登录时出现在该组中的用户）、**角色** 和 **表单**。
diff --git a/i18n/zh/_configure/users-and-groups/local-group.md b/i18n/zh/_configure/users-and-groups/local-group.md
new file mode 100644
index 0000000..a8c21b8
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups/local-group.md
@@ -0,0 +1,24 @@
+---
+layout: default
+title: 本地组
+parent: 用户和组
+nav_order: 3
+translated_from: 21a406f84bc977e2006ab3bc6f201bf202a39330
+---
+
+# 本地组
+{: .no_toc }
+
+本地组的页面及其选项卡
+{: .fs-6 .fw-300 }
+
+组的页面 `/settings/groups/<id>` 包含以下选项卡：
+
+| 选项卡 | 显示的内容 |
+|---|---|
+| **详情** | 名称和描述 |
+| **用户** | 组中的用户；**添加用户** 添加一个用户，行菜单或复选框用于移除用户 |
+| **角色** | 引用该组的角色 |
+| **表单** | 这些角色可以打开的表单 |
+
+仍有用户的组不能删除：请先移除其中的用户。`admins` 组永远不能被删除或重命名。
diff --git a/i18n/zh/_configure/users-and-groups/local-user.md b/i18n/zh/_configure/users-and-groups/local-user.md
new file mode 100644
index 0000000..f13b4eb
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups/local-user.md
@@ -0,0 +1,35 @@
+---
+layout: default
+title: 本地用户
+parent: 用户和组
+nav_order: 1
+translated_from: 9b36582b1f0f8b333a6e9dbb4524eb10723af183
+---
+
+# 本地用户
+{: .no_toc }
+
+添加本地用户，以及其页面的各个选项卡
+{: .fs-6 .fw-300 }
+
+**添加用户** 会打开一个三步向导：**用户**（用户名、描述、电子邮件）、**密码** 和 **组**。
+
+用户的页面 `/settings/users/<id>` 包含以下选项卡：
+
+| 选项卡 | 显示的内容 |
+|---|---|
+| **详情** | **允许登录** 开关、用户名、描述、电子邮件，以及从 7.3.0 起的 **上次登录** |
+| **组** | 用户所属的组 |
+| **角色** | 用户拥有的角色，以及每个角色的来源：**直接**、**通过** 某个组，或 **所有人** |
+| **表单** | 这些角色可以打开的表单 |
+| **作业** | 用户启动的作业，最新的在前 |
+| **保存的作业** | 用户为再次运行而保存的表单值 |
+| **调度** | 用户通过稍后运行计划的作业 |
+| **活动** | 审计日志记录的该用户的操作 |
+| **API 令牌** | 用户的 API 令牌，以及每个令牌的创建时间、过期时间和上次使用时间；**撤销** 会立即使其中一个失效 |
+
+从 7.3.0 起，本地用户的登录也会被记录，就像 LDAP 或 SSO 用户原本那样：**上次登录** 显示最近一次登录，
+用户列表中对所有来源都有一个可排序的 **上次登录** 列，因此没人使用的账户会很显眼。被拒绝的登录不会被
+记录，升级后尚未登录过的本地用户显示为 `–`。
+
+**修改密码** 和 **删除** 位于右上角。用户 `admin` 永远不能被删除或重命名。
diff --git a/i18n/zh/_configure/users-and-groups/several-groups.md b/i18n/zh/_configure/users-and-groups/several-groups.md
new file mode 100644
index 0000000..24815bf
--- /dev/null
+++ b/i18n/zh/_configure/users-and-groups/several-groups.md
@@ -0,0 +1,18 @@
+---
+layout: default
+title: 多个组
+parent: 用户和组
+nav_order: 2
+translated_from: 5326b69fb4cc585072d068da8d17a0038eeab4d1
+---
+
+# 多个组
+{: .no_toc }
+
+属于多个组的本地用户及其角色
+{: .fs-6 .fw-300 }
+
+本地用户可以属于多个组，并获得每个组的角色：角色以 `local/<group>` 的形式引用组。
+
+在 **组** 选项卡上，**添加组** 会将用户加入另一个组，行菜单或复选框用于将其移出某个组。
+用户至少要保留一个组。用户列表的每行菜单中也有 **添加到组**，作用相同。
diff --git a/i18n/zh/_get_started/first-form.md b/i18n/zh/_get_started/first-form.md
new file mode 100644
index 0000000..7fef730
--- /dev/null
+++ b/i18n/zh/_get_started/first-form.md
@@ -0,0 +1,224 @@
+---
+layout: default
+title: 您的第一个表单
+nav_order: 2
+translated_from: 26f445060b68070d02251e1c756c6253e5cf85fb
+---
+
+# 您的第一个表单
+{: .no_toc }
+
+编写一个 playbook，在设计器中为它创建表单，启动它并找到对应的作业
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+本教程从一个全新的安装开始，参见 [安装](installation/)。大约需要十五分钟。
+
+---
+
+## 1. 登录
+
+在浏览器中打开 AnsibleForms，并以管理员身份登录。
+
+默认账户为 `admin` / `AnsibleForms!123`（或您设置的 [`ADMIN_*`](customization/server.html#env_ADMIN_USERNAME) 值）；随后会打开 **表单** 页面：
+
+![表单页面，带有示例表单](assets/screenshots/dashboard.jpg)
+
+---
+
+## 2. 编写 playbook
+
+`ansible` 表单会运行 playbooks 文件夹中的某个 playbook，所以先写 playbook。将下面的内容保存为 `hello.yaml`：
+
+{% raw %}
+```yaml
+- name: Hello world
+  hosts: localhost
+  gather_facts: false
+  tasks:
+    - name: Show the values from the form
+      ansible.builtin.debug:
+        msg: "Hello {{ your_name }}: a {{ vm_size }} machine in {{ target_env }} (dry run: {{ dry_run }})"
+```
+{% endraw %}
+
+这个 playbook 读取四个变量。接下来创建的表单会把它们作为 extravars 发送，每个字段一个。
+
+把文件放到持久化文件夹（[`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH)）的 `playbooks` 文件夹中；
+如果该文件夹还不存在，请先创建：
+
+<div class="af-tabs" data-tab-group="install">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="compose" aria-selected="false">Docker Compose</button>
+<button type="button" role="tab" class="af-tab" data-tab="kubernetes" aria-selected="false">Kubernetes</button>
+<button type="button" role="tab" class="af-tab" data-tab="source" aria-selected="false">从源码安装</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+即您挂载到 `/app/dist/persistent` 的文件夹，在安装示例中为 `/srv/apps/ansibleforms/persistent`：
+
+```bash
+mkdir -p /srv/apps/ansibleforms/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/persistent/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="compose" markdown="1" hidden>
+
+即 docker-compose 项目的 `data/playbooks` 文件夹：
+
+```bash
+cp hello.yaml data/playbooks/
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="kubernetes" markdown="1" hidden>
+
+即持久卷，在 AnsibleForms pod 中挂载于 `/app/dist/persistent`。先查出 pod 的名称，再把文件复制进去：
+
+```bash
+kubectl -n ansibleforms get pods
+kubectl -n ansibleforms exec <pod> -- mkdir -p /app/dist/persistent/playbooks
+kubectl -n ansibleforms cp hello.yaml <pod>:/app/dist/persistent/playbooks/hello.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="source" markdown="1" hidden>
+
+即服务器的 `persistent/playbooks` 文件夹，在安装示例中为 `/srv/apps/ansibleforms/server`：
+
+```bash
+mkdir -p /srv/apps/ansibleforms/server/persistent/playbooks
+cp hello.yaml /srv/apps/ansibleforms/server/persistent/playbooks/
+```
+
+</div>
+</div>
+
+{: .note }
+> 当某个 git 仓库开启了 **用于 playbook？** 时，playbook 会改为从该仓库运行：
+> 请把 `hello.yaml` 提交到那里。参见 [设计器和 git](gui/designer-and-git.html)。
+
+---
+
+## 3. 创建表单
+
+表单是表单文件夹中的 YAML 文件。设计器在浏览器中编辑它们，并在保存前进行检查。
+
+1. 点击顶部菜单中的 **设计器**，然后点击左侧菜单中的 **表单**。
+2. 点击右上角的开关（**启动设计器**）。它会锁定配置，以免其他人同时编辑，
+   随后开关显示 **由我锁定**。
+3. 点击工具栏的第一个按钮 **新建文件**，输入文件名 `hello-world.yaml`。设计器会在其中添加一个
+   名为 `New Form` 的表单。
+4. 用下面这个表单替换编辑器中的 YAML：
+
+```yaml
+name: Hello world
+type: ansible
+playbook: hello.yaml
+description: Greets you with the values you picked
+icon: play
+roles:
+  - default
+categories:
+  - Default
+fields:
+  - name: your_name
+    type: text
+    label: Your name
+    required: true
+  - name: target_env
+    type: enum
+    label: Environment
+    values:
+      - development
+      - test
+      - production
+    default: development
+    required: true
+  - name: vm_size
+    type: enum
+    label: Size
+    expression: "[{size:'small',cpus:1},{size:'medium',cpus:2},{size:'large',cpus:4}]"
+    runLocal: true
+    default: __auto__
+    required: true
+  - name: dry_run
+    type: checkbox
+    label: Dry run
+    default: true
+```
+
+{:start="5"}
+5. 点击 **验证**（对勾图标），然后点击 **保存**。保存会把 `hello-world.yaml` 写入表单文件夹。
+6. 再次点击开关以释放锁。
+
+![设计器，正在编辑一个表单](assets/screenshots/designer.jpg)
+
+这个表单使用了四种字段类型：
+
+| 字段 | 类型 | 作用 |
+|---|---|---|
+| `your_name` | [`text`](formfields/text.html) | 必填的文本框 |
+| `target_env` | [`enum`](formfields/enum.html) | 带有固定 `values` 列表的下拉框 |
+| `vm_size` | [`enum`](formfields/enum.html) | 由本地 [表达式](expressions/local.html) 填充的下拉框；`__auto__` 会选中第一项 |
+| `dry_run` | [`checkbox`](formfields/checkbox.html) | 复选框，以 `true` 或 `false` 发送 |
+
+`vm_size` 会显示 `size` 和 `cpus` 两列，并发送第一列 `size`；用 `valueColumn` 可以选择其他列。
+
+`roles: [default]` 让每个已登录的用户都能运行此表单，`categories: [Default]` 则把它放进默认
+`config.yaml` 所定义的类别中。
+
+{: .note }
+> 您也可以把 `hello-world.yaml` 复制到 [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH)，并 [在 VS Code 中验证它](faq.html#vs-code-validation-for-form-files)。
+
+---
+
+## 4. 启动表单
+
+从 **表单** 页面打开表单：点击顶部菜单中的 **表单**，在 **Default** 类别中选择 **Hello world**。
+
+填写您的名字，按需修改其他字段。点击 **显示 Extravars** 查看 playbook 将会
+收到的内容，然后点击 **提交**：
+
+![一个表单](assets/screenshots/form.jpg)
+
+---
+
+## 5. 查看输出
+
+作业会立即启动，运行期间其输出显示在表单下方，最后以一条 **已完成** 栏结束：
+
+![作业的输出](assets/screenshots/run.jpg)
+
+debug 任务会打印您填写的值，例如 `Hello Alice: a small machine in development (dry run: True)`。
+
+没有清单时出现隐式 localhost 警告是正常的；实际使用的表单会设置 [`inventory`](forms/ansible.html)。
+
+---
+
+## 6. 在作业历史中找到它
+
+每次启动都会保存为一个作业。点击顶部菜单中的 **作业**：新作业位于 **所有作业** 的最上方。
+
+点击该作业可再次查看其输出，点击 **显示 Extravars** 可查看发送了什么。每个作业前面的图标
+用于重新运行或删除它：
+
+![作业历史](assets/screenshots/job-output.jpg)
+
+---
+
+## 后续步骤
+
+借助参考页面继续完善这个表单：
+
+* **[表单](forms/)**：所有表单属性、运行器上的模板、工作流表单、审批点和通知
+* **[表单字段](formfields/)**：所有字段类型，包括验证、依赖和布局
+* **[表达式](expressions/)**：从 REST API、数据库和文件填充字段
+* `config.yaml` 中的 **[角色](config/roles.html)** 和 **[类别](config/categories.html)**：决定谁能看到哪个表单
+* **[工作原理](how-it-works.html)**：启动背后发生了什么，以及所有内容存储在哪里
diff --git a/i18n/zh/_get_started/installation/docker-compose.md b/i18n/zh/_get_started/installation/docker-compose.md
new file mode 100644
index 0000000..c62c7f2
--- /dev/null
+++ b/i18n/zh/_get_started/installation/docker-compose.md
@@ -0,0 +1,317 @@
+---
+layout: default
+title: Docker Compose
+parent: 安装
+nav_order: 4
+translated_from: 74a6833ea71d65db337025978672afeab0425666
+---
+
+# Docker Compose
+{: .no_toc }
+
+使用 docker-compose 或 podman-compose 一并安装 AnsibleForms、其 RTE 和 MySQL
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+[docker-compose 项目](https://github.com/ansibleforms/docker) 运行三个容器：MySQL、AnsibleForms 应用，以及运行 playbook 的 RTE
+（运行环境）。该项目包含它们的设置、示例表单和 playbook，因此唯一的其他要求就是
+Docker 或 Podman 及其 compose 工具。
+
+[安装程序](installer.html) 用一条命令下载这个项目、填好设置和密钥并启动它。本页
+介绍如何手动搭建。
+
+---
+
+## 前提条件
+
+开始之前，您需要：
+
+* **Linux 机器**：任意发行版，CPU 和内存要求不高
+* **GitHub 访问**：用于从 GitHub 下载或克隆 docker-compose 项目
+* **Docker 或 Podman**：容器引擎，安装方法见下文
+* **compose 工具**：Docker Compose 或 podman-compose，用几个配置文件启动这三个容器
+
+**视频**：[如何安装 AnsibleForms](https://www.youtube.com/watch?v=IHGIggmtTuA)
+
+---
+
+## 选择安装位置
+
+为项目创建一个文件夹；示例中使用 `/srv/apps`：
+
+```bash
+sudo mkdir /srv/apps
+cd /srv/apps
+```
+
+---
+
+## 克隆 docker-compose 项目
+
+安装 Git：
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y git
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y git
+```
+
+</div>
+</div>
+
+然后把 docker-compose 项目克隆到该文件夹中：
+
+```bash
+sudo git clone https://github.com/ansibleforms/docker.git ansibleforms-docker
+cd ansibleforms-docker
+```
+
+---
+
+## 设置正确的权限
+
+应用和 RTE 以用户 `node`（uid 1000）运行，因此请把 `data` 文件夹的所有权交给该用户：
+
+```bash
+sudo chown -R 1000:1000 ./data
+```
+
+如果您从 6 升级而来（6 的容器以 root 运行），请在启动 7 之前执行一次同样的 `chown`。MySQL 启动时会收回它自己的文件夹。
+
+---
+
+## 安装容器引擎
+
+安装 Docker 或 Podman，以及各自的 compose 工具：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+从 Docker 的软件仓库安装 Docker Engine 及 Compose 插件
+（参见 [Docker 安装手册](https://docs.docker.com/engine/install)）：
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+# Docker's own apt repository
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl
+sudo install -m 0755 -d /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
+  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+  | sudo tee /etc/apt/sources.list.d/docker.list
+
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+# Docker's own dnf repository (Rocky / Alma : use .../linux/centos/docker-ce.repo)
+sudo dnf install -y dnf-plugins-core
+sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
+sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
+```
+
+</div>
+</div>
+
+然后让容器内部能够解析名称，并将 Docker 作为服务启动：
+
+```bash
+sudo mkdir -p /etc/docker
+echo "{\"dns-opts\":[\"ndots:15\"]}" | sudo tee /etc/docker/daemon.json
+sudo systemctl enable --now docker
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman 不需要服务。将它与 podman-compose 一起安装：
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+```bash
+sudo apt-get install -y podman podman-compose
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+```bash
+sudo dnf install -y podman
+# podman-compose comes from EPEL (on RHEL, enable EPEL as Red Hat documents it)
+sudo dnf install -y epel-release
+sudo dnf install -y podman-compose
+```
+
+</div>
+</div>
+
+</div>
+</div>
+
+---
+
+## 自定义
+
+检查 `.env` 和 `docker-compose.yml` 文件中的变量，并修改每一个密码：`MYSQLDB_ROOT_PASSWORD`、
+`MYSQLDB_PASSWORD`、`ADMIN_PASSWORD` 和 `RTE_TOKEN`。[进一步了解环境变量](../customization)
+
+应用以 `ansibleforms`（`MYSQLDB_USER`）身份连接 MySQL，对 `AnsibleForms` schema 拥有全部权限，对其他内容
+没有任何权限；root 只供 MySQL 自身使用。MySQL 只在首次启动时创建该用户：此前一直以 root 连接的安装
+需要手动创建一次，方法见项目的 [README](https://github.com/ansibleforms/docker#database)。
+
+RTE 不会发布到主机上。从 7.3.0 起，应用使用 `RTE_TOKEN` 连接 `http://rte:8000`，并保持一条 WebSocket 连接
+（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)）：RTE 不获取数据库设置，也不读取 `.env`，只在
+`docker-compose.yml` 中拿到它的令牌和几个自己的设置。配置种子 `data/seed.yaml` 声明一个包含该令牌和
+地址的 RTE 凭据，以及使用该凭据登录的默认运行器 `rte`（inbound 模式）。RTE 从同一个 `data` 文件夹运行 playbook
+（`RTE_FILES=local`）。当您的 playbook 需要更多 collection 或 Python 库时，请构建您自己的 RTE，
+并让 `rte` 服务指向它（参见 [构建您自己的 RTE](../rte/images.html#build-your-own-rte)）。
+
+---
+
+## 启动 docker-compose 项目
+
+在后台启动这三个容器。应用会等待 MySQL 进入健康状态，然后连接 RTE：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+# with the older standalone tool : sudo docker-compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose up -d
+# podman is service-less : you can run it as any user, with or without sudo
+```
+
+</div>
+</div>
+
+---
+
+## 测试应用
+
+容器启动后，在浏览器中打开 AnsibleForms：
+
+* 打开 `https://your_ip`（端口 443，参见 .env 文件中的 `WEBAPP_LOCAL_PORT`）
+* 以 `admin` 和 `.env` 文件中的 `ADMIN_PASSWORD` 登录；如果它仍是默认的 `AnsibleForms!123`，请设置一个新密码
+* 在 **连接 > 运行器** 下检查 RTE 是否以默认运行器 `rte` 列出，并且其页面上的
+  **连接** 显示为 **已连接**
+* 后续步骤：
+  * 在 data/forms/ 文件夹中添加 YAML 文件，或使用内置的设计器来创建表单
+  * 把您的 playbook 添加到 data/playbooks/ 文件夹中
+  * 添加 LDAP 连接
+  * 添加用户和组
+  * 为模板表单添加运行器：AWX、AAP 或 Ascender、Semaphore、Rundeck 或 Jenkins
+  * 为外部连接（例如其他 MySQL 服务器或 REST API）添加凭据，或添加要传给 Ansible playbook 的凭据
+  * 连接 Git 仓库，并选择您的表单和/或 playbook 是否与某个仓库同步
+
+---
+
+## 文件结构
+
+docker-compose 项目的文件夹结构如下：
+
+```bash
+.
+├── docker-compose.yml # the mysqldb, app and rte containers
+├── .env # the settings, see the variables below
+└── data # everything that must survive an upgrade, mounted in the app and the rte
+    ├── ansible # mounted in the rte only
+    │   ├── ansible.cfg # ansible settings
+    │   ├── roles # roles you install
+    │   └── collections # collections you install
+    ├── forms # 1 or more yaml files with forms
+    ├── functions # custom javascript functions and jq definitions
+    ├── git # .gitconfig for repository connections
+    ├── mysql
+    │   ├── my.cnf # MySQL settings
+    │   └── db # the database files (created at first start)
+    ├── playbooks # your ansible playbooks, with sample maintenance playbooks
+    ├── repositories # local clones of your git repositories
+    ├── ssh # the client sshkey (created at first start)
+    ├── config.yaml # categories, roles and constants
+    ├── seed.yaml # the config seed: registers the rte as the default runner
+    ├── certificates # self-signed certificates (created at first start) - replace with your own
+    ├── logs # the logfiles (created at first start)
+    ├── backups # database backups (created when needed)
+    └── forms_backups # form backups (created when needed)
+```
diff --git a/i18n/zh/_get_started/installation/docker.md b/i18n/zh/_get_started/installation/docker.md
new file mode 100644
index 0000000..b1568a3
--- /dev/null
+++ b/i18n/zh/_get_started/installation/docker.md
@@ -0,0 +1,253 @@
+---
+layout: default
+title: Docker
+parent: 安装
+nav_order: 3
+translated_from: d178cc481311c66fba52c62ac7bf5841b5f83316
+---
+
+# Docker
+{: .no_toc }
+
+使用 Docker 或 Podman 运行 AnsibleForms 应用镜像和 RTE 镜像，并连接您自己的 MySQL 服务器
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+您可以用 Docker 或 Podman 以两个容器的形式运行 AnsibleForms：应用本身，以及运行 playbook 的 RTE，二者连接到一个 MySQL 数据库。
+
+---
+
+## 前提条件
+
+开始之前，您需要：
+
+* **Docker 或 Podman**：安装其中之一并保持运行
+* **MySQL**：已安装并正在运行
+
+---
+
+## 安装 MySQL
+
+在容器可以访问到的 Linux 服务器上安装 MySQL 8+ 或 MariaDB：
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Ubuntu 自带 MySQL 8：
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mysql-server
+sudo systemctl enable --now mysql
+sudo mysql_secure_installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Debian 自带的是 MariaDB 而不是 MySQL，AnsibleForms 同样支持：
+
+```bash
+sudo apt-get update
+sudo apt-get install -y mariadb-server
+sudo systemctl enable --now mariadb
+sudo mariadb-secure-installation
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+RHEL 8 及更高版本及其衍生发行版在 AppStream 中提供 MySQL 8：
+
+```bash
+sudo dnf install -y mysql-server
+sudo systemctl enable --now mysqld
+sudo mysql_secure_installation
+```
+
+</div>
+</div>
+
+AnsibleForms 通过网络连接数据库，使用 `DB_USER` 和 `DB_PASSWORD`。请为它创建一个专用用户，只授予
+`AnsibleForms` schema 的权限，不要使用 root：
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+AnsibleForms 只需要这些：有了它，就能创建和修补自己的 schema 并进行备份。如果该用户对所有数据库都有权限，**状态** 页面和日志
+会发出警告。在 Ubuntu 和 Debian 上，数据库服务器只监听 localhost：请在其配置中设置 `bind-address`，
+以便容器能够访问它。
+
+---
+
+## 准备文件夹
+
+AnsibleForms 7 运行在两个容器中：应用，以及运行 playbook 的 RTE（运行环境）。二者都挂载一个文件夹，用于存放
+您的 `config.yaml`、表单、playbook、日志和证书，以及一个存放 SSH 密钥的文件夹。镜像以用户 `node`（uid 1000）运行，
+因此请把这两个文件夹的所有权交给该用户：
+
+```bash
+sudo mkdir -p /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh
+```
+
+把应用的设置写入一个环境文件：数据库连接、在存储任何凭据之前就要设置的
+[`ENCRYPTION_SECRET`](../customization/security.html#env_ENCRYPTION_SECRET)、应用与
+RTE 共享的令牌（[`RTE_TOKEN`](../customization/server.html#env_RTE_TOKEN)，至少 16 个字符），以及声明 RTE 的配置种子：
+
+```bash
+sudo tee /srv/apps/ansibleforms/ansibleforms.env > /dev/null <<'END'
+DB_HOST=192.168.0.1
+DB_PORT=3306
+DB_USER=ansibleforms
+DB_PASSWORD=<password>
+ENCRYPTION_SECRET=<a long random string>
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml
+END
+sudo chmod 600 /srv/apps/ansibleforms/ansibleforms.env
+```
+
+RTE 有自己的文件，不含数据库设置：从 7.3.0 起由应用主动连接它，并保持一条 WebSocket 连接
+（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)），它从相同的文件夹运行 playbook（`RTE_FILES=local`）：
+
+```bash
+sudo tee /srv/apps/ansibleforms/rte.env > /dev/null <<'END'
+RTE_MODE=inbound
+RTE_TOKEN=<the same token>
+RTE_FILES=local
+PORT=8000
+HTTPS=0
+END
+sudo chmod 600 /srv/apps/ansibleforms/rte.env
+```
+
+[配置种子](../seed/) 声明一个包含 RTE 地址和令牌的 RTE 凭据，以及使用该凭据登录的
+默认运行器 `rte`：
+
+```bash
+sudo tee /srv/apps/ansibleforms/persistent/seed.yaml > /dev/null <<'END'
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+END
+sudo chown 1000:1000 /srv/apps/ansibleforms/persistent/seed.yaml
+```
+
+---
+
+## 启动容器
+
+运行 GitHub Container Registry 上发布的镜像（参见 [镜像标签](./#image-tags)）：
+应用使用 [`ghcr.io/ansibleforms/ansibleforms`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms)，
+RTE 使用 [`ghcr.io/ansibleforms/ansibleforms-rte-full`](https://github.com/ansibleforms/ansibleforms/pkgs/container/ansibleforms-rte-full)。
+
+种子会把 RTE 作为默认运行器 `rte` 添加到 **连接 > 运行器** 下，因此 playbook 表单无需进一步设置即可在其上运行。
+应用在首次启动时创建 schema，并在两个容器都运行后连接 RTE（示例 `config.yaml` 位于
+[docker-compose 项目](https://github.com/ansibleforms/docker/blob/main/data/config.yaml) 中）：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker network create ansibleforms
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+启动后会列出这两个容器：
+
+```bash
+docker ps
+CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                    PORTS                    NAMES
+5c0e2a91d7f4   ghcr.io/ansibleforms/ansibleforms-rte-full:7   "/usr/bin/tini -- no…"   10 seconds ago   Up 9 seconds (healthy)                             rte
+d91f7b05b67e   ghcr.io/ansibleforms/ansibleforms:7            "/usr/bin/tini -- no…"   2 minutes ago    Up 2 minutes (healthy)    0.0.0.0:8000->8000/tcp   ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+Podman 接受相同的选项，且不需要服务：
+
+```bash
+podman network create ansibleforms
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+启动后会列出这两个容器：
+
+```bash
+podman ps
+```
+
+</div>
+</div>
+
+应用监听端口 `8000`，除非设置 `HTTPS=1`，否则使用 HTTP。RTE 不会发布到主机上：只有应用在
+网络内部连接它。`--stop-timeout 30` 让 RTE 在停止时有时间等待正在运行的 playbook 结束（RTE 的设置以及如何构建
+您自己的 RTE，参见 [运行 RTE](../rte/run.html)）。
+
+---
+
+## 测试应用
+
+容器启动后，在浏览器中打开 AnsibleForms：
+
+* 打开 `http://your_ip:8000`（如果设置了 `HTTPS=1`，则使用 HTTPS）
+* 以 `admin` / `AnsibleForms!123`（或您通过 `ADMIN_PASSWORD` 设置的密码）登录，并设置一个新密码
+* 在 **连接 > 运行器** 下检查 RTE 是否以默认运行器 `rte` 列出，并且其页面上的
+  **连接** 显示为 **已连接**
+* 后续步骤：
+  * 在 `forms` 文件夹中添加 YAML 文件，或使用内置的设计器来创建表单
+  * 把您的 playbook 添加到所挂载持久化文件夹的 `playbooks` 文件夹中
+  * 添加 LDAP 连接
+  * 添加用户和组
+  * 为模板表单添加运行器：AWX、AAP 或 Ascender、Semaphore、Rundeck 或 Jenkins
+  * 为外部连接（例如其他 MySQL 服务器或 REST API）添加凭据，或添加要传给 Ansible playbook 的凭据
diff --git a/i18n/zh/_get_started/installation/from-source.md b/i18n/zh/_get_started/installation/from-source.md
new file mode 100644
index 0000000..4f82cfc
--- /dev/null
+++ b/i18n/zh/_get_started/installation/from-source.md
@@ -0,0 +1,268 @@
+---
+layout: default
+title: 从源码安装
+parent: 安装
+nav_order: 5
+translated_from: 5a30cd6f93473aa6d47bf91aabbe13af37d97127
+---
+
+# 从源码安装
+{: .no_toc }
+
+从源码构建 AnsibleForms，并用 Node.js 运行
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 代码的组织方式
+
+仓库包含两个 Node.js 应用，构建时会把它们合并为一个：
+
+* **client**：Web 界面，用 Vue 3 编写，并用 Vite 构建为静态文件
+* **server**：API，用 Express 编写。它把作业交给运行器、连接数据库，并提供构建好的 client。
+  以 `AF_ROLE=rte` 启动时，同一个 server 就是运行 playbook 的 RTE（运行环境）
+
+只有 client 需要构建；其输出放入 server 的 `views` 文件夹，与 [Docker 镜像](https://github.com/ansibleforms/ansibleforms/blob/main/Dockerfile) 中的做法相同。
+
+---
+
+## 前提条件
+
+从源码构建并运行需要扎实的 Linux 技能和一定的 Node.js 知识。每个组件都需要您自己安装。如果想
+不用容器、也不用自己构建就运行 AnsibleForms，安装程序的 [原生安装](native.html) 会替您完成这一切：
+
+* **Node.js 26**（`.nvmrc` 中的版本；至少 24），带 npm
+* **Git**，用于获取代码和同步仓库
+* **OpenSSH 客户端**，用于通过 SSH 使用 git；以及 **sshpass**，用于以 SSH 密码连接的 playbook
+* **MariaDB 客户端**（`mariadb`、`mariadb-dump`），用于备份和恢复，搭配 MySQL 服务器时也需要
+* **MySQL 8+ 或 MariaDB**，服务器可以访问到
+* **Ansible**，供运行 playbook 的 RTE 进程使用（`ansible-playbook` 需在其 path 中）。应用进程本身不需要
+  Ansible 和 Python；如果只使用模板表单（AWX、AAP、Ascender 和其他运行器），则完全不需要 RTE
+
+按您的发行版安装它们：
+
+<div class="af-tabs" data-tab-group="linux">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="ubuntu" aria-selected="true">Ubuntu</button>
+<button type="button" role="tab" class="af-tab" data-tab="debian" aria-selected="false">Debian</button>
+<button type="button" role="tab" class="af-tab" data-tab="rhel" aria-selected="false">RHEL / Rocky / Alma</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ubuntu" markdown="1">
+
+Node.js 26 来自 NodeSource 仓库，其他工具来自 Ubuntu 本身：
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="debian" markdown="1" hidden>
+
+Node.js 26 来自 NodeSource 仓库，其他工具来自 Debian 本身：
+
+```bash
+curl -fsSL https://deb.nodesource.com/setup_26.x | sudo -E bash -
+sudo apt-get install -y nodejs git openssh-client sshpass mariadb-client python3 python3-pip ansible
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="rhel" markdown="1" hidden>
+
+Node.js 来自 NodeSource，`sshpass` 来自 EPEL（在 RHEL 本身上，请按 Red Hat 文档的说明启用 EPEL）：
+
+```bash
+curl -fsSL https://rpm.nodesource.com/setup_26.x | sudo bash -
+sudo dnf install -y epel-release
+sudo dnf install -y nodejs git openssh-clients sshpass mariadb python3 python3-pip ansible-core
+```
+
+</div>
+</div>
+
+检查 `node --version`（26）和 `ansible-playbook --version`；数据库及其用户的设置，参见 [安装 MySQL](docker.html#install-mysql)。
+
+---
+
+## 获取代码
+
+把仓库克隆到您选择的文件夹中，该文件夹归运行应用的用户所有。示例中使用 `/srv/apps/ansibleforms`：
+
+```bash
+sudo mkdir -p /srv/apps
+sudo chown $USER /srv/apps
+cd /srv/apps
+git clone https://github.com/ansibleforms/ansibleforms.git
+cd ansibleforms
+```
+
+---
+
+## 构建
+
+在仓库文件夹中分三步构建。首先构建 client：
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+然后安装 server 的依赖：
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+最后把构建好的 client 复制到 server 的 `views` 文件夹中：
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+---
+
+## 配置
+
+server 从环境变量读取设置；在生产环境中，还会读取 `server/persistent/.env`，即
+设置页面写入的文件。
+
+从仓库根目录的示例文件开始，至少设置 MySQL 连接（`DB_HOST`、`DB_PORT`、`DB_USER`、
+`DB_PASSWORD`）：
+
+```bash
+cd /srv/apps/ansibleforms/server
+mkdir -p persistent
+cp ../.env.example persistent/.env
+```
+
+所有变量都在 [环境变量](../customization) 中说明。其余所有内容默认存储在 `server/persistent` 中：
+`config.yaml`、`forms` 文件夹和自签名证书都会在首次启动时在那里创建，日志也在那里。
+把您的 playbook 放到 `server/persistent/playbooks`，或者在 RTE 的环境中把 `ANSIBLE_PATH` 指向其他位置，因为由 RTE 读取它。
+
+---
+
+## 运行
+
+以生产模式运行 AnsibleForms，或以开发模式运行以便修改代码本身：
+
+<div class="af-tabs" data-tab-group="mode">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="production" aria-selected="true">生产</button>
+<button type="button" role="tab" class="af-tab" data-tab="development" aria-selected="false">开发</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="production" markdown="1">
+
+在 `server` 文件夹中以生产模式启动 server：
+
+```bash
+cd /srv/apps/ansibleforms/server
+npm run start
+```
+
+从命令行启动的应用会在您注销时停止。[PM2](https://pm2.keymetrics.io/) 让它在
+后台持续运行，崩溃后重启它，并在开机时再次启动它：
+
+```bash
+sudo npm install -g pm2
+
+cd /srv/apps/ansibleforms/server
+NODE_ENV=production pm2 start index.js --name ansibleforms
+pm2 save
+pm2 startup   # prints the command that starts PM2 at boot
+```
+
+playbook 在 RTE 上运行：用 `AF_ROLE=rte` 在单独的端口上再启动一次同一个 server。应用会连接它并保持
+一条 WebSocket 连接（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)），它从相同的文件夹运行 playbook
+（`RTE_FILES=local`）。它也读取 `persistent/.env`，但不使用其中的任何数据库设置。把应用与 RTE 共享的令牌
+（至少 16 个字符）以及声明 RTE 的配置种子添加到 `persistent/.env`：
+
+```bash
+RTE_TOKEN=<at least 16 characters>
+CONFIG_SEED_PATH=/srv/apps/ansibleforms/server/persistent/seed.yaml
+```
+
+[配置种子](../seed/) 声明一个包含 RTE 地址和令牌的 RTE 凭据，以及使用该凭据登录的
+默认运行器 `rte`：
+
+```yaml
+version: 1
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://127.0.0.1:8010
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+如果不使用种子，请在 **连接 > 凭据**（一个包含该地址和令牌的 RTE 凭据）和
+**连接 > 运行器**（类型 RTE，**模式** 为 **入站**）下添加它们。然后启动 RTE，只监听 `127.0.0.1`：
+
+```bash
+cd /srv/apps/ansibleforms/server
+AF_ROLE=rte RTE_MODE=inbound RTE_FILES=local PORT=8010 HTTPS=0 LISTEN_HOST=127.0.0.1 \
+  NODE_ENV=production pm2 start index.js --name ansibleforms-rte
+pm2 save
+```
+
+RTE 的设置在 [运行 RTE](../rte/run.html) 页面中说明。检查 PM2 是否列出了这两个进程：
+
+```bash
+pm2 status
+```
+
+二者都是 `online`：
+
+```text
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| id | name             | mode | version | pid  | uptime | restarts | status | cpu | mem     | user | watching |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+| 0  | ansibleforms     | fork | 7.0.0   | 3104 | 8s     | 0        | online | 0%  | 120.1mb | root | disabled |
+| 1  | ansibleforms-rte | fork | 7.0.0   | 3187 | 5s     | 0        | online | 0%  | 80.4mb  | root | disabled |
++----+------------------+------+---------+------+--------+----------+--------+-----+---------+------+----------+
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="development" markdown="1" hidden>
+
+要修改代码本身，请在仓库根目录以实时重载方式启动所有组件：server 在端口 3001，RTE 在端口 8010，
+client 在 `https://localhost:8443`。在此模式下，server 和 RTE 改为读取 `server/.env.development`：
+
+```bash
+cd /srv/apps/ansibleforms
+npm install
+(cd server && npm install && cp ../.env.example .env.development)
+(cd client && npm install)
+npm run dev
+```
+
+RTE（`npm run dev:rte`）需要 path 中有 `ansible-playbook`，它会以数据库模式把自己添加为运行器，该模式已弃用，仅用于
+开发；`npm run dev:local` 启动 client 和 server，但不启动 RTE。[贡献指南](https://github.com/ansibleforms/ansibleforms/blob/main/CONTRIBUTING.md) 说明了需要运行的测试和检查。
+
+</div>
+</div>
+
+---
+
+## 首次运行
+
+在浏览器中打开 server（使用示例 `.env` 时为 `https://your_ip:8443`）。如果数据库为空，会在
+首次启动时创建 schema。
+
+默认的管理员凭据为：
+
+* 用户名：`admin`
+* 密码：`AnsibleForms!123`
diff --git a/i18n/zh/_get_started/installation/index.md b/i18n/zh/_get_started/installation/index.md
new file mode 100644
index 0000000..9c17db4
--- /dev/null
+++ b/i18n/zh/_get_started/installation/index.md
@@ -0,0 +1,87 @@
+---
+layout: default
+title: 安装
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /installation/
+translated_from: c5efb1a569cf31ab6b1817687a024e12c26eb128
+---
+
+# 安装
+{: .no_toc }
+
+为 AnsibleForms 选择一种安装方式
+{: .fs-6 .fw-300 }
+
+---
+
+面向搭建新实例的管理员：选择一种安装方式，然后按照对应页面操作。
+
+---
+
+## 本节内容
+
+AnsibleForms 支持多种安装方式，每种方式都有单独的页面介绍：
+
+| 页面 | 内容 |
+|---|---|
+| [安装程序](installer.html) | 一条命令即可在 Docker、Podman、Kubernetes 上或以原生方式安装控制器或运行器，之后还能升级和备份 |
+| [原生安装](native.html) | 不使用容器的安装程序安装：服务器上运行 Node.js、MariaDB 和 Ansible，AnsibleForms 作为 systemd 服务运行 |
+| [Docker](docker.html) | 安装 MySQL，并使用所需的环境变量运行预构建的 Docker 镜像 |
+| [Docker Compose](docker-compose.html) | 下载 [docker-compose 项目](https://github.com/ansibleforms/docker)，用 docker-compose 同时启动 MySQL 和 AnsibleForms |
+| [从源码安装](from-source.html) | 手动安装所有依赖，然后构建并启动代码 |
+| [Kubernetes](kubernetes.html) | 安装 Helm chart，用 Kubernetes 启动 AnsibleForms 及其 MySQL 数据库 |
+
+{: .note }
+> **推荐** 从 7.3.0 起，安装程序是得到可用实例的最快方式：只需回答几个问题，它就会在
+> Docker 或 Podman 上搭建 Docker Compose 项目，或采用其他某种方式。Docker 镜像已包含所有依赖。
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+要把现有安装迁移到更新的版本，请参见 [升级](../upgrading/)。
+
+每种方式都会在应用旁运行一个 RTE，即运行 playbook 的容器（或服务）。要在另一台主机或另一个
+数据中心再添加一个，请用 [安装程序](installer.html#a-runner) 安装一个运行器：它通过一条 WebSocket 连接 AnsibleForms（出站，参见
+[模式](../rte/modes.html)），且不持有任何数据库凭据。另请参见 [运行环境](../rte/) 及其操作手册
+[另一个数据中心中的 RTE](../rte/another-datacenter.html)。
+
+---
+
+## 镜像标签
+
+镜像以 `ghcr.io/ansibleforms/ansibleforms` 发布在 GitHub Container Registry 上，该仓库归
+项目所有，且不限制匿名拉取的速率。从 7.0.0 起的每个版本都只在那里发布，6.x 版本
+也在那里。
+
+从 7 开始，playbook 在 RTE 上运行，RTE 与应用并列发布，分为三层（参见 [RTE 镜像](../rte/images.html)）：
+
+| 镜像 | 说明 |
+|---|---|
+| `ghcr.io/ansibleforms/ansibleforms` | Web 应用和 API，不含 python 和 ansible |
+| `ghcr.io/ansibleforms/ansibleforms-rte-base` | 不含 python 和 ansible 的 RTE：用于构建您自己的镜像 |
+| `ghcr.io/ansibleforms/ansibleforms-rte-core` | 在 base 的基础上加入 python、ansible-core 和少量库：用来添加您的 collection |
+| `ghcr.io/ansibleforms/ansibleforms-rte-full` | 在 core 的基础上加入 `ansible` 包及其 collection 和库：默认的 RTE |
+
+这四个镜像在同一次运行中构建，带有相同的标签，因此 RTE 的标签始终与应用的标签一致。
+
+旧的 Docker Hub 仓库 `ansibleguy/ansibleforms` 已不再更新。它保留了已有的
+版本，但两条版本线都不会再有新版本。如果您仍从那里拉取，请改用
+带相同标签的 `ghcr.io/ansibleforms/ansibleforms`，以继续获得更新。
+
+每个镜像都提供以下标签；RTE 镜像从 7.0.0 开始，因此没有 6.x 标签：
+
+| 标签 | 指向 |
+|---|---|
+| `latest` | 最新主版本的最新发布 |
+| `7`, `6` | 该主版本的最新发布 |
+| `7.0`, `6.5` | 该次版本的最新发布 |
+| `7.0.0`, `6.5.5` | 正好是该版本 |
+| `latest-rc` | 最新的候选版本，若正式版本更新则指向正式版本；每个候选版本也有自己的标签 |
+
+`latest` 只会向前移动：旧主版本的补丁（例如在 7.0.0 之后发布的 6.5.x）
+会移动 `6` 和 `6.5`，但绝不会移动 `latest`。
+
+要停留在某个主版本上，请使用其编号（`6`）而不是 `latest`。
diff --git a/i18n/zh/_get_started/installation/installer.md b/i18n/zh/_get_started/installation/installer.md
new file mode 100644
index 0000000..044c70c
--- /dev/null
+++ b/i18n/zh/_get_started/installation/installer.md
@@ -0,0 +1,409 @@
+---
+layout: default
+title: 安装程序
+parent: 安装
+nav_order: 1
+translated_from: 72dbe0a987c93d1b54d1972827c2b26e8cad5fe9
+---
+
+# 安装程序
+{: .no_toc }
+
+用一条命令在 Linux 服务器上安装、升级和维护 AnsibleForms
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员：这是得到可用实例，或为安装在别处的 AnsibleForms 部署运行器的最快方式。从 7.3.0 开始提供。
+
+---
+
+## 它安装什么
+
+安装程序在全屏向导中提出几个问题，把每个回答都列出来供您确认，然后才对服务器进行更改。
+它可以在四种引擎之一上安装两种角色之一：
+
+| 角色 | 说明 |
+|---|---|
+| 控制器 | 完整的应用：Web 界面、其数据库和它自己的运行器。首次安装请选择此项 |
+| 运行器 | 为安装在别处的 AnsibleForms 运行 playbook 的 RTE，例如位于另一个网络、DMZ 或另一个数据中心。它通过单个 WebSocket 与 AnsibleForms 通信，且不持有任何数据库凭据 |
+
+可安装到的引擎：
+
+| 引擎 | 运行方式 |
+|---|---|
+| Docker | [Docker Compose 项目](docker-compose.html)，运行在带 compose 插件的 Docker Engine 上。容器随 Docker 一起重启 |
+| Podman | 同一个项目运行在 Podman 上，可以是 rootless 或 root，使用 podman-compose。由一个 systemd 单元在开机时启动容器 |
+| Kubernetes | [Helm chart](kubernetes.html)，部署在 `kubectl` 可访问的集群上。控制器通过 ingress 对外提供服务；运行器使用 chart 的 runner 模式 |
+| 直接安装在此服务器上 | 不使用容器：服务器上运行 Node.js、MariaDB 和 Ansible，AnsibleForms 作为 systemd 服务运行。参见 [原生安装](native.html) |
+
+安装完成后，同一个程序还可以升级安装、进行备份、显示状态以及删除安装。它也能接管
+不是由它安装的 AnsibleForms，例如根据 Docker Compose 项目手动搭建的实例（参见 [已有的安装](#an-existing-installation)）。
+
+---
+
+## 运行它
+
+安装脚本会为此服务器下载安装程序并启动它：
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh
+```
+
+常见的变体：以 root 身份运行，用于安装 Docker 或 Podman、直接安装在服务器上或安装到 `/opt` 下；带上命令或
+参数（参见 [参数](#flags)）；以及使用指定版本的安装程序而不是最新版：
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh
+curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
+curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh
+```
+
+该脚本会：
+
+1. 检查服务器运行的是 amd64 或 arm64 上的 Linux，并找到 `curl` 或 `wget` 以及 `sha256sum`
+2. 从 [ansibleforms/installer](https://github.com/ansibleforms/installer/releases) 的最新版本，或 `AF_INSTALLER_VERSION` 指定的版本中
+   下载 `ansibleforms-installer_linux_<arch>`
+3. 对照该版本的 `checksums.txt` 进行校验，校验和不一致的下载一律不用
+4. 将其保存为 `ansibleforms-installer`，root 用户保存在 `/usr/local/bin`，其他用户保存在 `~/.local/bin`，供以后升级和备份使用。
+   通过 sudo 运行时，请使用完整路径：sudo 的 `secure_path`（例如在 Red Hat 系统上）经常不包含 `/usr/local/bin`
+5. 用给定的参数启动它，即使脚本是通过管道传入的，也会从终端读取键盘输入
+
+如果没有终端，例如在 CI 作业中，安装程序会以无人值守方式运行（参见 [无人值守](#unattended)）。
+
+---
+
+## 向导
+
+向导一次问一个问题，步骤列在左侧。按 **Esc** 返回上一步，已填的回答会保留：
+
+| 步骤 | 询问内容 |
+|---|---|
+| 语言 | 安装程序的语言，默认取自此服务器的 locale：加泰罗尼亚语、德语、英语、西班牙语、法语、意大利语、日语、荷兰语、波兰语、葡萄牙语或中文。最先询问，在安装程序报告它发现的任何安装之前 |
+| 发行说明 | 所安装版本的新内容，破坏性变更、移除和弃用排在最前 |
+| 角色 | 控制器或运行器 |
+| 引擎 | Docker、Podman、Kubernetes，或直接安装在此服务器上 |
+| 文件夹 | 安装文件夹和实例名称 |
+| 加入、应用、模式 | 仅限运行器：参见 [运行器](#a-runner)。在 Kubernetes 上不询问模式 |
+| 网络 | Web 界面或运行器的端口。Kubernetes 上不询问 |
+| HTTPS | 浏览器如何连接控制器 |
+| 管理员 | 第一个管理员的密码，输入两次 |
+| 集群、Ingress、存储 | 仅限 Kubernetes：namespace 和 release、ingress（控制器）、存储类 |
+| 确认 | 所有回答：**安装** 或 **修改回答** |
+
+**引擎。** 列表显示此服务器已有的引擎。缺少的引擎会显示为 *Docker（未安装：安装程序会安装它）*，
+Podman 也是如此：确认后，安装程序会用 Docker 官方脚本（`get.docker.com`，包含 compose 插件）安装 Docker，
+或从发行版的软件包安装 Podman 和 podman-compose。这需要 root 权限。当 `kubectl` 和
+`helm` 已安装并能访问集群时，会提供 Kubernetes 选项。*直接安装在此服务器上* 需要 root 权限和受支持的 Linux，选项变灰时会说明原因。
+
+**文件夹。** 默认值：
+
+| | 控制器 | 运行器 |
+|---|---|---|
+| 文件夹，以 root 身份 | `/opt/ansibleforms` | `/opt/ansibleforms-runner` |
+| 文件夹，以其他用户身份 | `~/ansibleforms` | `~/ansibleforms-runner` |
+| 实例名称，Docker 或 Podman | `af` | `runner` |
+| 实例名称，原生 | `ansibleforms` | `ansibleforms-runner` |
+
+使用 Docker 或 Podman 时，该文件夹存放 compose 文件和包含密钥的 `.env`，以及所有数据：数据库、表单、playbook
+和日志。它必须为空。实例名称由小写字母、数字和 `-` 组成，用作容器名的前缀（`af_app`、`af_db`、`af_rte`），因此多个
+实例可以共用一台服务器。运行器的实例名称也是它在 **连接 > 运行器** 下的运行器名称（`RTE_NAME`）。
+
+**网络。** 控制器的 Web 界面监听 `443`，或下一个空闲端口。随后 **HTTPS** 提供以下选项：
+
+| 选项 | 作用 |
+|---|---|
+| HTTPS，使用为此服务器创建的自签名证书 | 为此服务器的名称签发的证书，有效期十年。浏览器会要求您接受一次 |
+| HTTPS，使用我自己的证书和密钥 | 您自己的 PEM 格式证书和密钥，来自您的 CA 或 Let's Encrypt |
+| HTTP，由前端的反向代理处理 HTTPS | 在该端口上使用纯 HTTP，供处理 HTTPS 的 nginx、Traefik 或负载均衡器使用 |
+
+**管理员。** `admin` 用户的密码，输入两次，以免因输错而无法登录。留空时，安装程序会生成一个
+强密码。
+
+**结束。** 安装程序生成数据库密码和各项密钥，启动 AnsibleForms 并等待它响应。然后它会
+显示要打开的地址、用户名和密码以及文件夹。为它安装的运行器会请求加入，由管理员在
+**连接 > 运行器** 下批准（参见 [运行器](#a-runner)）。
+
+---
+
+## 运行器
+
+运行器是为运行在别处的 AnsibleForms（7.3.0 或更高版本）服务的 RTE。它不持有任何数据库凭据：它使用自己的令牌
+登录，AnsibleForms 把该令牌保存在一个 RTE 凭据中（参见 [模式](../rte/modes.html)）。在文件夹之后，向导
+还会再问三件事：
+
+| 步骤 | 询问内容 |
+|---|---|
+| 应用 | 此运行器为之工作的 AnsibleForms 的地址，即用户在浏览器中打开的地址 |
+| 模式 | **出站：运行器连接到 AnsibleForms**（默认），或 **入站：AnsibleForms 连接到运行器** |
+| 网络 | 运行器的端口，默认 `8000`。出站时，只有健康检查监听该端口，且只能从此服务器访问。入站时，还要询问 AnsibleForms 访问此服务器所用的地址 |
+
+`--role runner` 会跳过角色问题，因此在运行器的服务器上执行以下命令，会直接从运行器的问题开始：
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner
+```
+
+随后安装程序会连接 AnsibleForms。如果是自签名证书或私有 CA 签发的证书，会询问 **信任此证书？**：
+选择是会在运行器上设置 [`APP_TLS_VERIFY=0`](../customization/server.html#env_APP_TLS_VERIFY)。它会读取 AnsibleForms 运行的版本，
+拒绝低于 7.3.0 的版本，并以相同的版本安装运行器，无论安装程序本身默认会安装哪个版本。
+
+对于 DMZ、NAT 或不允许任何入站连接的区域，请选择出站：只有从此服务器到 AnsibleForms 端口的
+流量。对于由中心端发起所有连接的网络，请选择入站。
+
+确认页面会显示 **注册方式：请求批准**，如果 `--join` 提供了令牌，则显示 **自行注册，使用加入令牌**。最后安装程序会
+显示运行器的名称、模式、应用地址，入站时还有它自己的地址，然后说明它已请求加入 AnsibleForms：请在
+**连接 > 运行器** 下批准它，批准前先确认那里显示的指纹与安装程序打印的一致：
+
+```
+Fingerprint: abcd-ef12
+```
+
+指纹是运行器令牌 `RTE_TOKEN` 的 SHA-256 的前 8 个十六进制数字，该令牌保存在文件夹的
+`.env` 文件中（[原生安装](native.html) 时为 `rte.env`）。参见 [批准 RTE](../runners/registration.html#approving-an-rte)。使用 `--join` 时，运行器会立即获得批准：
+它已自行注册，并在 **连接 > 运行器** 下显示为已连接。
+
+入站运行器通过 HTTPS 提供其 socket。安装程序会为 AnsibleForms 访问它所用的地址创建一个自签名证书，
+有效期十年，存放在文件夹的 `data/certificates` 中，并把 `RTE_URL` 设为 `https://<address>:<port>`。
+运行器在请求加入时发送该证书，AnsibleForms 会固定（pin）它：只有当该运行器出示
+同一张证书时才会连接它，因此不需要 CA。安装程序会在令牌指纹下方打印证书指纹：
+
+```
+Fingerprint: abcd-ef12
+Certificate fingerprint: 3f9c-07a1
+```
+
+它是证书 DER 字节的 SHA-256 的前 8 个十六进制数字，格式为 `xxxx-xxxx`。批准运行器之前，
+请确认批准对话框显示的证书指纹与之相同。使用 `--join` 注册的运行器也会打印它。
+
+在 Kubernetes 上，运行器就是 Helm chart 的 runner 模式，并且始终是出站的：向导不询问模式和网络，因为外部无法
+连入它（参见 [Kubernetes](#kubernetes)）。
+
+---
+
+## Kubernetes
+
+对于 Kubernetes 上的控制器，安装程序会把 [Helm chart](kubernetes.html) 安装到 `kubectl` 可访问的集群上：
+
+| 问题 | 默认值 |
+|---|---|
+| Namespace | `ansibleforms` |
+| Helm release 名称 | `ansibleforms` |
+| Ingress 提供的主机名 | 无：必填，例如 `ansibleforms.example.com` |
+| Ingress 类 | 集群中的某一个，默认 `nginx` |
+| 通过 HTTPS 提供服务（使用 Ingress 证书）？ | 是 |
+| 卷的存储类 | 集群默认值 |
+
+管理员密码位于该 namespace 的 Secret `<release>-secrets` 中，键为 `ADMIN_PASSWORD`。安装程序把
+chart 的 values 保存在其状态文件旁边的 `<release>-values.yaml` 文件中，并在升级时再次应用；`--values` 可添加您自己的文件。每个版本的 chart 会在该版本发布后不久发布。
+
+对于运行器，安装程序以 [runner 模式](kubernetes.html#a-runner-on-kubernetes)（`runner.enabled`）安装同一个 chart：只有一个 RTE，
+没有应用、没有数据库、也没有 ingress，由它主动连接 AnsibleForms（出站）。在询问应用地址之后，向导还会询问：
+
+| 问题 | 默认值 |
+|---|---|
+| Namespace | `ansibleforms` |
+| Helm release 名称 | `ansibleforms-runner`，也是它在 **连接 > 运行器** 下的运行器名称 |
+| 卷的存储类 | 集群默认值 |
+
+安装程序会生成运行器的令牌，并设置应用地址、运行器名称；如果您信任应用的证书，还会设置
+`runner.appTlsVerify: false`。使用 `--join` 时，加入令牌会立即批准运行器；否则运行器会请求加入，
+安装程序会打印其指纹，供您在 **连接 > 运行器** 下批准前核对。
+
+---
+
+## 命令
+
+安装程序接受一个命令，放在参数之前或之后均可。不带命令时，它执行安装：
+
+| 命令 | 作用 |
+|---|---|
+| `install` | 安装 AnsibleForms，作为控制器或运行器（默认）。如果服务器上已有安装，无论是它自己的还是它发现的，都会提议升级 |
+| `upgrade` | 升级到更新的版本，先显示其发行说明（参见 [升级](#upgrade)） |
+| `status` | 显示安装情况（角色、引擎和版本）及其容器、pod 或服务，以及它是否响应。然后列出它在服务器上发现的其他 AnsibleForms |
+| `backup` | 立即备份数据库，保存到安装文件夹中的 `installer-backups`（在 Kubernetes 上为安装程序状态文件旁的 `backups`）。运行器没有需要备份的数据 |
+| `release-notes` | 显示某个版本（`--version` 指定的或此安装程序的版本）的发行说明，破坏性变更在前 |
+| `uninstall` | 删除安装，加上 `--purge` 时还会删除其数据 |
+| `version` | 打印安装程序的版本 |
+
+安装程序把安装信息记录在 `/etc/ansibleforms/installer.json`（root）或 `~/.config/ansibleforms/installer.json`
+（其他用户）中，因此 `install` 之后的命令无需参数即可自行找到安装。该文件夹不包含二进制文件，
+并且只有在安装程序安装或接管了一个 AnsibleForms 之后才会存在：
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer status
+sudo /usr/local/bin/ansibleforms-installer backup
+sudo /usr/local/bin/ansibleforms-installer upgrade
+```
+
+`uninstall` 会询问 **同时删除其数据（数据库、表单、playbook、日志）？**。要删除，请输入实例名称（在 Kubernetes 上为 Helm
+release）；否则它只删除容器、pod 或服务，并保留数据。
+
+---
+
+## 参数
+
+每个参数回答一个问题，向导随后会跳过该问题。`ansibleforms-installer --help` 会列出它们：
+
+| 参数 | 回答的内容 |
+|---|---|
+| `--lang <code>` | 语言：`ca`、`de`、`en`、`es`、`fr`、`it`、`ja`、`nl`、`pl`、`pt` 或 `zh` |
+| `--version <version>` | 要安装或升级到的 AnsibleForms 版本；默认为此安装程序的版本 |
+| `--role <role>` | `controller` 或 `runner` |
+| `--mode <mode>` | `compose`、`kubernetes` 或 `native` |
+| `--runtime <runtime>` | `docker` 或 `podman`（compose） |
+| `--install-runtime` | 缺少 Docker 或 Podman 时直接安装，不再询问 |
+| `--dir <folder>` | 安装文件夹（compose） |
+| `--name <name>` | 实例名称，即其容器的前缀（compose，默认 `af`） |
+| `--port <port>` | 主机上的端口：控制器为 Web 界面端口，运行器为 RTE 端口 |
+| `--tls <choice>` | `self`、`own` 或 `off`（compose 控制器） |
+| `--cert <file>`, `--key <file>` | 证书和密钥文件，配合 `--tls own` 使用 |
+| `--admin-password <password>` | 第一个管理员的密码；默认自动生成 |
+| `--join <token>` | 通过 API 生成的加入令牌（`afj_...`），可立即批准运行器（运行器，无人值守；参见 [加入令牌](../runners/registration.html#join-tokens)） |
+| `--app-url <address>` | 应用的地址，例如 `https://forms.example.com`（运行器） |
+| `--runner-mode <mode>` | `outbound`（RTE 连接应用）或 `inbound`（应用连接 RTE）（运行器） |
+| `--host <address>` | 此服务器的地址，由应用来连接（入站运行器） |
+| `--namespace <namespace>` | Kubernetes namespace，默认 `ansibleforms` |
+| `--release <release>` | Helm release，默认 `ansibleforms` |
+| `--hostname <name>` | ingress 主机名（kubernetes） |
+| `--ingress-class <class>` | ingress 类（kubernetes） |
+| `--storage-class <class>` | 存储类（kubernetes） |
+| `--values <file>` | 额外的 Helm values 文件（kubernetes） |
+| `--purge` | 配合 `uninstall`：同时删除数据 |
+| `--source <folder>` | 用于安装的 [ansibleforms/docker](https://github.com/ansibleforms/docker) 仓库本地副本（离线环境） |
+| `--bundle <file>` | 用于原生安装的发行包 `ansibleforms-<version>-linux-<arch>.tar.gz`（参见 [原生安装](native.html#air-gapped)） |
+| `--yes` | 所有问题都使用默认值回答（无人值守） |
+| `--verbose` | 显示它运行的每条命令 |
+
+---
+
+## 无人值守
+
+使用 `--yes` 或没有终端时，安装程序不会提出任何问题：参数回答各自的问题，其余问题使用默认值。它
+会跳过语言、发行说明、管理员密码（自动生成，除非 `--admin-password` 提供了一个）和确认步骤，改为打印
+发行说明的链接。只有在使用 `--install-runtime` 或 `--yes` 时，它才会安装缺少的 Docker 或 Podman；运行器
+需要 `--app-url`。不带 `--join` 时，运行器会请求加入并等待管理员批准；带上它时，运行器会立即获得批准。
+
+在 Docker 上安装控制器，缺少 Docker 时一并安装：
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'
+```
+
+在 Podman 上安装入站运行器，应用通过 `rte-dmz.example.com:8000` 连接它：
+
+```bash
+curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
+  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
+  --runner-mode inbound --host rte-dmz.example.com --port 8000
+```
+
+---
+
+## 已有的安装
+
+安装程序把它安装的内容记录在 `installer.json` 中。没有该文件时，`install`、`upgrade` 和 `status` 会先查找
+服务器上已有的 AnsibleForms，无论它是如何安装的：
+
+| 发现的类型 | 如何发现 | 何时接管 |
+|---|---|---|
+| Docker 或 Podman | 应用或 RTE 镜像的容器，按 compose 项目分组 | 文件夹中有 [ansibleforms/docker](https://github.com/ansibleforms/docker) 仓库的 compose 文件和 `.env`：服务 `mysqldb`、`app` 和 `rte`，容器为 `<name>_db`、`<name>_app` 和 `<name>_rte` |
+| 7.2 运行器 | 在自己的 compose 项目中单独运行的 RTE，带有应用的 `DB_*` 且没有 `RTE_MODE`（数据库模式） | 其 compose 文件可读。升级会把它迁移到 socket 模式（参见 [7.2 运行器](#a-72-runner)） |
+| Kubernetes | `ansibleforms` chart 的 Helm release，以及使用其镜像的 Deployment 和 StatefulSet | 它是该 chart 的一个 release：其当前 values 会成为它的 values 文件 |
+| 原生 | 用 Node.js 运行 AnsibleForms 的 systemd 服务 | 它们符合安装程序的目录布局：`releases/`、`current`、`app.env` 和 `rte.env`（参见 [原生安装](native.html#the-folder)） |
+| 无引擎 | 在常用端口上响应的应用或 RTE：443、3000、3001、8000、8001、8010 或 8443 | 从不：它是从源码或手动运行的。安装程序只会报告它 |
+
+只计算应用和 RTE 的镜像：以 AnsibleForms 命名的 MySQL 容器不算一个安装。安装程序会列出它
+发现的内容，每项一行，附上原因；对于无法接管的安装，还会说明需要手动做什么：其 compose 文件不是该仓库的、
+其数据库在 compose 项目之外、它在 Kubernetes 上运行但未使用 Helm chart、它由 Argo CD 管理（请在那里升级，
+即修改 Application 中的 chart 版本），或者无法读取其版本。
+
+对于可以接管的安装，`install` 提供三个选项：
+
+| 选项 | 作用 |
+|---|---|
+| 接管并升级 | 显示它将记录的内容，确认后写入 `installer.json`，然后继续 [升级](#upgrade) |
+| 仍然在旁边安装一个新的 AnsibleForms | 第二套安装，拥有自己的文件夹、端口和数据库，需要单独确认 |
+| 停止 | 不做任何更改 |
+
+如果某个安装运行的版本已经是安装程序要安装的版本，第一个选项会改为 **接管**：安装程序
+记录它的位置和运行方式，供今后备份、查看状态和升级使用，此时不做任何更改。
+
+`upgrade` 提供相同的选项，但没有第二个，并且在没有可接管的安装时停止。无人值守时，`install` 会显示一条消息后停止，
+而 `upgrade --yes` 只有在恰好发现一个可接管的安装时才会接管。Kubernetes release 的当前 values 会
+保存在 `installer.json` 旁边，升级时会与新版本的 chart 一起再次应用。
+
+---
+
+## 升级
+
+`ansibleforms-installer upgrade` 把安装迁移到同一主版本中更新的版本。它列出更新的版本，
+最新的在前（无人值守时选择最新版本），并显示它所跨越的每个版本的发行说明，破坏性变更
+和移除排在最前。如果其中包含破坏性变更，它会要求您确认已阅读；无人值守时，只有 `--yes` 才会继续。
+
+安装程序会在任何更改之前备份数据库。如果新版本没有响应，它会提议回滚：恢复到之前的
+版本，并从该备份恢复其数据库。它不会降级，也不会跨越主版本：跨主版本（例如从 6.x 到 7.x）
+请遵循 [升级指南](../upgrade-7.html)，其中说明了升级前要在 6.5 上做的事情。
+
+在 Docker 或 Podman 上，控制器的升级还会把它的文件更新到 docker 仓库的新版本：
+
+| 文件 | 升级时的处理 |
+|---|---|
+| `docker-compose.yml` | 先在 `installer-backups` 中保存一份副本，然后替换为新版本的文件 |
+| `.env` | 保留所有现有行，并添加新版本需要的键，其中的密钥按全新安装的方式生成。会先保存一份副本 |
+| `data/seed.yaml` | 如果它是 docker 仓库附带且未修改的种子，则替换。手动修改过的会保留，新的种子保存在它旁边 |
+| `data/` | 添加新版本带来的新文件，例如新的 playbook。已存在的文件全部保留 |
+
+对于已存在的数据库，缺失的数据库设置（`MYSQLDB_USER` 或某个密码）无法凭空补上，因此升级会在
+任何更改之前停止。回滚会把 compose 文件、`.env` 和种子恢复原样。
+
+运行器与其 AnsibleForms 运行相同的版本：请先升级 AnsibleForms，再升级它的运行器。运行器的升级会为新的 RTE 镜像
+重写其 compose 文件，并原样保留其 `.env` 和数据。
+
+---
+
+## 7.2 运行器
+
+7.2 的运行器以数据库模式运行，该模式自 7.3.0 起已弃用：其 RTE 持有 AnsibleForms 的数据库设置。安装程序会发现
+它（参见 [已有的安装](#an-existing-installation)），升级时会在同一个运行器下把它迁移到 socket 模式：
+
+1. 从旧的 RTE 容器中读取运行器的名称（`RTE_NAME`）和令牌（`RTE_TOKEN`）。如果该 RTE 没有自行注册
+   （`RTE_REGISTER=0`），则需要您输入其运行器在 **连接 > 运行器** 下的名称
+2. 询问应用地址和模式，默认为 **出站**，也可选入站；入站时还要询问端口和此服务器的地址
+3. 显示计划，然后把旧的 compose 文件和 `.env` 备份到 `installer-backups`
+4. 写入安装程序的运行器布局，不含 `DB_*` 设置。保留 `RTE_MAX_JOBS`、`RTE_DRAIN_SECONDS`、
+   `PROCESS_MAX_BUFFER` 和 `METRICS_TOKEN`，socket 模式的 RTE 仍会读取它们
+5. 在旧 RTE 旁边启动新 RTE。新 RTE 使用该运行器自己的令牌登录，AnsibleForms 会自行把运行器迁移到
+   新模式，**无需批准**：其作业以及引用它的表单都保持不变
+6. 新 RTE 连接后，旧容器会被停止并删除
+
+入站运行器与新安装的一样，通过带固定证书的 HTTPS 提供服务（参见 [运行器](#a-runner)），安装程序会打印其
+证书指纹。如果旧 RTE 占用了新 RTE 需要的端口，会先停止旧 RTE，因此在新 RTE 连接之前
+运行器处于离线状态。出站运行器的新 RTE 会使用 `127.0.0.1` 上的一个空闲端口，与旧 RTE 并行运行，不会中断。
+
+如果安装程序无法从旧 RTE 读取令牌，您需要选择新 RTE 的登录方式：
+
+| 选项 | 后续情况 |
+|---|---|
+| 输入运行器的令牌 | 即 **连接 > 凭据** 下该运行器的 RTE 凭据的密码。运行器保留其名称和作业 |
+| 使用加入令牌作为新运行器加入 | [加入令牌](../runners/registration.html#join-tokens) 会以另一个名称添加一个新运行器。请手动停用旧运行器 |
+
+如果新 RTE 没有连接上，安装程序会提议恢复旧文件并重新启动旧容器；如果 AnsibleForms
+已经迁移了该运行器，请在 **连接 > 运行器** 下把它的模式改回数据库模式。新 RTE 连接后就
+无法回退了：旧文件保留在 `installer-backups` 中。
+
+如果 AnsibleForms 不知道具有该名称的运行器，新 RTE 会改为请求加入并等待批准。请在
+**连接 > 运行器** 下拒绝该请求，然后使用运行器在那里的名称再次运行升级。
+
+---
+
+## 版本
+
+安装程序的版本跟随应用：每个 AnsibleForms 版本都附带一个相同版本的安装程序，二者一同发布，
+该安装程序默认安装该版本。`--version` 可安装其他版本。
+[安装程序的 Releases 页面](https://github.com/ansibleforms/installer/releases) 上的每个版本都提供 amd64 和 arm64 上的 Linux 二进制文件，以及它们的
+校验和。
diff --git a/i18n/zh/_get_started/installation/kubernetes.md b/i18n/zh/_get_started/installation/kubernetes.md
new file mode 100644
index 0000000..4b3f678
--- /dev/null
+++ b/i18n/zh/_get_started/installation/kubernetes.md
@@ -0,0 +1,307 @@
+---
+layout: default
+title: Kubernetes
+parent: 安装
+nav_order: 6
+translated_from: 57f229acf691cee68f7a5d61b28cc7e879b903a8
+---
+
+# Kubernetes
+{: .no_toc }
+
+使用 Helm chart 安装 AnsibleForms 及其 MySQL 数据库
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+Helm chart 会部署 AnsibleForms、MySQL 以及运行 playbook 的 RTE（参见 [values 参考](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/VALUES.md)）。
+[安装程序](installer.html) 也能根据几个问题安装该 chart，并能升级不是由它安装的 release。同一个
+chart 还可以单独安装一个运行器，供运行在别处的 AnsibleForms 使用（参见 [Kubernetes 上的运行器](#a-runner-on-kubernetes)）。
+
+---
+
+## 前提条件
+
+开始之前，您需要：
+
+* **Kubernetes 集群**：并已配置 `kubectl` 可以访问它
+* **Helm 3**：用于安装和升级 chart
+* **存储**：用于动态供给的 StorageClass，或预先创建的 PersistentVolume
+* **Ingress 控制器**：仅在您希望通过 ingress 暴露 AnsibleForms 时需要
+
+---
+
+## 1. 获取 chart 的 values
+
+从 chart 仓库或 OCI registry 把 chart 的默认 values 导出到您自己的文件中：
+
+<div class="af-tabs" data-tab-group="helmsource">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="repo" aria-selected="true">Chart 仓库</button>
+<button type="button" role="tab" class="af-tab" data-tab="oci" aria-selected="false">OCI registry</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="repo" markdown="1">
+
+```bash
+helm repo add ansibleforms https://ansibleforms.com/helm-charts/
+helm repo update
+helm show values ansibleforms/ansibleforms > my_values.yaml
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="oci" markdown="1" hidden>
+
+无需添加仓库：chart 从 GitHub Container Registry 拉取。
+
+```bash
+helm show values oci://ghcr.io/ansibleforms/charts/ansibleforms > my_values.yaml
+```
+
+</div>
+</div>
+
+---
+
+## 2. 配置存储
+
+AnsibleForms 和 MySQL 都把数据存储在持久卷上。请分别设置它们的 StorageClass 和大小：
+
+```yaml
+storages:
+  server:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+  mysql:
+    className: longhorn
+    size: 5Gi
+    accessMode: ReadWriteOnce
+```
+
+`className` 为空时使用集群的默认 StorageClass。访问模式默认为 `ReadWriteMany`，许多存储
+类并不提供该模式；单副本时使用 `ReadWriteOnce` 即可。关于预先创建的 PersistentVolume，参见 chart 的
+[README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms)。
+
+---
+
+## 3. 设置凭据
+
+AnsibleForms 需要一个管理员账户、一个数据库密码和一个 `ENCRYPTION_SECRET`，后者是加密 AnsibleForms 中所存凭据的
+密钥。以后要更换该密钥时，在一次启动中把 [`ENCRYPTION_SECRET_PREVIOUS`](../customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS)
+设为旧密钥：所有已存储的密钥随后都会用新密钥重新加密。可以通过以下三种方式之一提供它们：
+
+<div class="af-tabs" data-tab-group="helmcreds">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="values" aria-selected="true">在 values 文件中</button>
+<button type="button" role="tab" class="af-tab" data-tab="generate" aria-selected="false">由 chart 生成</button>
+<button type="button" role="tab" class="af-tab" data-tab="existing" aria-selected="false">已有的 Secret</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="values" markdown="1">
+
+在 `my_values.yaml` 中设置它们。chart 会把它们存储在名为 `<release>-secrets` 的 Secret 中：
+
+```yaml
+applications:
+  server:
+    env:
+      ADMIN_USERNAME: admin
+      ADMIN_PASSWORD: a-strong-password
+      ENCRYPTION_SECRET: a-random-string-of-32-characters
+  mysql:
+    password: a-strong-database-password
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="generate" markdown="1" hidden>
+
+让 chart 在首次安装时生成您没有提供的值。之后每次
+升级都会保留相同的值：
+
+```bash
+--set secrets.generate=true
+```
+
+这在 Argo CD 或 Flux 中不起作用，因为它们渲染 chart 时无法访问集群。生成的 Secret
+在 `helm uninstall` 后仍会保留；请备份它，因为 `ENCRYPTION_SECRET` 无法找回。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="existing" markdown="1" hidden>
+
+让 chart 指向您自己管理的 Secret，例如通过 External Secrets、Sealed Secrets 或 SOPS 管理。这样 chart
+就不会创建任何 Secret：
+
+```yaml
+secrets:
+  existingSecret: ansibleforms-credentials
+```
+
+该 Secret 必须包含 `DB_USER`、`DB_PASSWORD`、`ENCRYPTION_SECRET`、`ADMIN_USERNAME` 和 `ADMIN_PASSWORD`。
+
+</div>
+</div>
+
+---
+
+## 4. 选择 RTE 镜像
+
+AnsibleForms 7 自身不运行任何 playbook：由 RTE（运行环境）来运行。chart 把它作为 server pod 中的第二个容器运行，
+使用同一个卷，并将它注册为默认运行器 `rte`，因此 playbook 表单无需任何设置即可工作。从 7.3.0 起，
+应用通过 `127.0.0.1` 连接它并保持一条 WebSocket 连接（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)）：RTE 不获取
+数据库设置，也不获取加密密钥。chart 的配置种子声明一个包含该令牌和地址的 RTE 凭据，以及
+使用该凭据登录的运行器（inbound 模式）。
+
+默认镜像 `ghcr.io/ansibleforms/ansibleforms-rte-full` 包含 ansible 及其 collection，以及 6.5 镜像中已有的 Python 库。
+需要更多或更少的内容时，请基于三层 RTE 镜像之一（`ansibleforms-rte-base`、`-rte-core` 或 `-rte-full`，参见
+[RTE 镜像](../rte/images.html)）构建您自己的镜像，并让 chart 指向它：
+
+```yaml
+containers:
+  rte:
+    image: registry.example.com/my-rte:7.0.0
+applications:
+  rte:
+    env:
+      ANSIBLE_PATH: /app/dist/persistent/playbooks
+```
+
+应用与 RTE 之间的令牌，以及签署会话的密钥，会在首次安装时生成到
+`<release>-keys` Secret 中，并在每次升级时保留。如果使用您自己的配置种子，请把该凭据和运行器加进去：Helm 在安装后打印的说明会告诉您如何操作
+（参见 chart 的 [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms)）。
+
+---
+
+## 5. 安装 chart
+
+使用您的 values 把 chart 安装到单独的 namespace 中：
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms --create-namespace \
+  --values my_values.yaml
+```
+
+使用 OCI registry 时，chart 请写为 `oci://ghcr.io/ansibleforms/charts/ansibleforms`。在任何无人值守运行的场景中，
+请用 `--version` 固定 chart 版本，以免新版本被自动安装。
+
+---
+
+## 6. 检查安装
+
+chart 包含一个测试，会同时检查 Web 服务器和数据库连接：
+
+```bash
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+当 AnsibleForms 有响应且其数据库接受连接时，测试以 `OK` 结束。
+
+---
+
+## 7. 打开 AnsibleForms
+
+如何访问 AnsibleForms 取决于 server 的暴露方式：
+
+<div class="af-tabs" data-tab-group="helmaccess">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="portforward" aria-selected="true">端口转发</button>
+<button type="button" role="tab" class="af-tab" data-tab="loadbalancer" aria-selected="false">LoadBalancer</button>
+<button type="button" role="tab" class="af-tab" data-tab="ingress" aria-selected="false">Ingress</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="portforward" markdown="1">
+
+使用默认的 `ClusterIP` service 且没有 ingress 时，集群外部无法访问任何内容。转发一个本地端口
+来查看：
+
+```bash
+kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80
+```
+
+然后打开 `http://127.0.0.1:8080/`。
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="loadbalancer" markdown="1" hidden>
+
+设置 `services.server.type: LoadBalancer`（可选择在 `services.server.loadbalancer.ip` 中指定固定地址），
+然后等待 service 获得地址：
+
+```bash
+kubectl -n ansibleforms get svc ansibleforms-server -w
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="ingress" markdown="1" hidden>
+
+启用 ingress，并设置路由到您的 ingress 控制器的主机名：
+
+```yaml
+ingress:
+  enabled: true
+  className: nginx
+  hostname: ansibleforms.example.com
+  tls:
+    enabled: true
+```
+
+chart 的 [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) 介绍了 ingress 后面的 TLS，包括 server 上启用 HTTPS 时
+所需的后端设置。
+
+</div>
+</div>
+
+---
+
+## 8. 登录
+
+以管理员用户登录，默认为 `admin`。从 Secret 中读取密码：
+
+```bash
+kubectl -n ansibleforms get secret ansibleforms-secrets \
+  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+使用 `secrets.existingSecret` 时，请改为从您自己的 Secret 中读取。
+
+---
+
+## Kubernetes 上的运行器
+
+设置 `runner.enabled` 后，chart 只安装一个 RTE：一个为安装在别处（另一个 namespace、另一个
+集群或虚拟机上）的 AnsibleForms 服务的运行器。它主动连接应用并保持一条 WebSocket 连接（`RTE_MODE=outbound`，参见 [模式](../rte/modes.html)），因此
+不需要数据库、加密密钥或入站端口。它不渲染应用、MySQL、Service 和 Ingress：
+
+```bash
+helm install runner1 ansibleforms/ansibleforms \
+  --namespace runners --create-namespace \
+  --set runner.enabled=true \
+  --set runner.appUrl=https://forms.example.com \
+  --set runner.name=zone-a \
+  --set runner.joinToken=afj_...
+```
+
+| 值 | 作用 |
+|---|---|
+| `runner.enabled` | 只安装运行器：没有应用、MySQL、Service 和 Ingress |
+| `runner.appUrl` | 用户打开应用时的地址，如有 `BASE_URL` 也要包含。必填 |
+| `runner.name` | 它加入时使用的运行器名称（`RTE_NAME`）。为空时使用 release 名称 |
+| `runner.joinToken` | 在应用中生成的 [加入令牌](../runners/registration.html#join-tokens)，首次启动时读取，用于立即批准运行器 |
+| `runner.appTlsVerify` | `false` 表示接受应用的自签名证书（`APP_TLS_VERIFY=0`），仅限在可信网络内使用 |
+
+没有加入令牌时，运行器会请求加入，并等待管理员在 **连接 > 运行器** 下批准。获批后，它
+使用自己的 `RTE_TOKEN` 登录，该令牌保存在 `<release>-keys` Secret 中：请让该 Secret 与 release 一起保留。
+当您选择运行器角色和 Kubernetes 时，[安装程序](installer.html#kubernetes) 也会安装这种 runner 模式。
+
+---
+
+## 后续步骤
+
+chart 的 [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms) 介绍了其余的配置：
+
+* **您自己的数据库**：设置 `mysql.enabled: false`，并让 AnsibleForms 指向已有的 MySQL 服务器
+* **来自 ConfigMap 的表单**：通过 ConfigMap 提供 `config.yaml` 和表单文件
+* **ingress 后面的 HTTPS**、资源、节点调度和私有 registry
+* **RTE**：其令牌、您自己的 RTE 镜像，或完全不使用 RTE
+
+要迁移到更新的版本，请参见 [在 Kubernetes 上升级](../upgrading/kubernetes.html)。
diff --git a/i18n/zh/_get_started/installation/native.md b/i18n/zh/_get_started/installation/native.md
new file mode 100644
index 0000000..9cf9534
--- /dev/null
+++ b/i18n/zh/_get_started/installation/native.md
@@ -0,0 +1,162 @@
+---
+layout: default
+title: 原生安装
+parent: 安装
+nav_order: 2
+translated_from: eab01cbd3bc313b6a4cfd2b87dbcb2ac99408b78
+---
+
+# 原生安装
+{: .no_toc }
+
+不使用容器，直接在服务器上运行 AnsibleForms，由安装程序设置为 systemd 服务
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向不允许使用容器的服务器的管理员：[安装程序](installer.html) 会在服务器本身上安装 AnsibleForms 所需的一切，
+之后还能升级和删除它。它安装的是 AnsibleForms 7.3.0 或更高版本。
+
+---
+
+## 所需条件
+
+在安装程序的 **引擎** 步骤中选择 **直接安装在此服务器上，不使用容器**，或传入 `--mode native`。它需要：
+
+* **Root**：用 `sudo` 运行安装程序（`curl -fsSL https://ansibleforms.com/install | sudo sh`）
+* **systemd**：服务以 systemd 单元运行
+* **受支持的 Linux**：Ubuntu、Debian、RHEL 及其衍生版（如 Rocky Linux 和 AlmaLinux）、SUSE Linux Enterprise 或 openSUSE
+* **amd64 或 arm64**
+* **互联网访问**：能访问发行版的软件仓库、GitHub、nodejs.org 以及 Python 和 Ansible 的包索引（发行包可以替代哪些下载，参见
+  [离线环境](#air-gapped)）
+
+在不满足这些条件的服务器上，该引擎会显示为 *直接安装在此服务器上（需要 root：请用 sudo 运行安装程序）* 或
+*直接安装在此服务器上（此 Linux 不受支持）*。两种角色都可以这样安装：控制器和 [运行器](installer.html#a-runner)。
+
+---
+
+## 它安装什么
+
+对于两种角色，安装程序都会从发行版的软件包安装以下内容：
+
+| 软件包 | 用途 |
+|---|---|
+| `git` | 仓库 |
+| ssh 客户端 | playbook 的连接 |
+| MariaDB 客户端 | 应用的备份：`app.env` 会把 [`MYSQLDUMP_COMMAND`](../customization/retention.html#env_MYSQLDUMP_COMMAND) 和 [`MYSQL_COMMAND`](../customization/retention.html#env_MYSQL_COMMAND) 设为找到的客户端，即 `mariadb-dump` 和 `mariadb`，或较旧的 `mysqldump` 和 `mysql` |
+| `ca-certificates`、`curl`、`tar`、`gzip` | 下载 |
+| `libatomic` | Node.js 链接它，而最小化安装的服务器缺少它 |
+| `sshpass` | 使用 ssh 密码登录的 playbook。在 RHEL 及其衍生版上，它来自 EPEL，安装程序会尝试用 `epel-release` 启用 EPEL；如果无法安装，安装会继续并给出提示 |
+| MariaDB 服务器 | 仅限控制器：它的数据库 |
+
+然后安装到安装文件夹中，每个下载都会对照其公布的校验和进行检查：
+
+* **AnsibleForms**：应用 GitHub release 中的发行包 `ansibleforms-<version>-linux-<arch>.tar.gz`，即为
+  Node.js 构建的应用。没有发行包的版本会提示 *不使用容器安装需要 AnsibleForms 7.3.0 或更高版本。*
+* **Node.js**：发行包指定的主版本的最新版本，来自 nodejs.org
+* **Python 和 Ansible**：先安装 uv，再用它安装 RTE 镜像所用的 Python，以及一个包含 Ansible 和
+  full RTE 镜像所含库的虚拟环境，然后安装其 Ansible collection（参见 [RTE 镜像](../rte/images.html)）。这需要几分钟
+* **初始文件**：[docker-compose 项目](https://github.com/ansibleforms/docker) 的
+  `data` 文件夹中的表单、playbook 和设置，与全新的 Docker Compose 安装得到的相同。运行器只保留其 Ansible 配置、ssh 和 git 设置
+
+对于控制器，它随后会在 MariaDB 中创建 `AnsibleForms` schema，以及一个以实例命名的数据库用户，该用户对该
+schema 拥有全部权限，对其他内容没有任何权限，并且只能从此服务器登录。
+
+---
+
+## 文件夹
+
+所有内容都位于安装文件夹中，默认为 `/opt/ansibleforms`（运行器为 `/opt/ansibleforms-runner`）：
+
+| 路径 | 内容 |
+|---|---|
+| `releases/<version>/` | 一个版本：发行包、指向 Node.js 的链接、其 Python 虚拟环境和 collection |
+| `current` | 指向正在运行的版本的链接；升级和回滚都会移动它 |
+| `runtime/` | Node.js、uv 和 Python，各版本共用 |
+| `data/` | 容器中挂载为 `/app/dist/persistent` 的内容：表单、playbook、`config.yaml`、配置种子、证书和日志 |
+| `home/` | 系统用户的主目录：`.ssh` 和 `.gitconfig`，分别链接到 `data/ssh` 和 `data/git` |
+| `app.env`、`rte.env` | 服务的设置和密钥，只有 root 和系统用户可读。RTE 的文件不含任何数据库设置 |
+| `installer-backups/` | 安装程序在升级前或执行 `backup` 时创建的数据库备份 |
+
+各版本和运行时归 root 所有，因此服务无法修改自己的代码；`data/` 和 `home/` 归系统用户所有。
+数据库文件本身由 MariaDB 保存，位于该文件夹之外。
+
+---
+
+## 服务
+
+控制器运行两个 systemd 服务，运行器运行一个。每个服务都以一个以实例命名的系统用户（默认为 `ansibleforms`）运行，
+从 `current/server` 启动，并使用各自的设置文件：
+
+| 服务 | 运行内容 | 设置 |
+|---|---|---|
+| `<name>` | 应用：Web 界面、API 和 worker。仅限控制器 | `app.env` |
+| `<name>-rte` | 运行 playbook 的 RTE | `rte.env` |
+
+控制器的 RTE 为 `inbound`，在 `127.0.0.1` 上使用单独的端口（`8001` 或下一个空闲端口，并设置
+[`LISTEN_HOST`](../customization/server.html#env_LISTEN_HOST)`=127.0.0.1`），从应用的文件夹运行 playbook（`RTE_FILES=local`），
+并由配置种子 `data/seed.yaml` 声明为默认运行器。
+
+运行器的 RTE 会获得模式、`APP_URL`、`RTE_NAME`，使用 `--join` 时还有加入令牌，并随每个作业接收 playbook（参见
+[模式](../rte/modes.html)）。出站的 RTE 不接受来自应用的连接，因此只监听 `127.0.0.1`（`LISTEN_HOST=127.0.0.1`）。
+入站的 RTE 使用 `data/certificates` 中为其自身地址签发的自签名证书提供 HTTPS，AnsibleForms 会固定该证书。
+没有加入令牌时，它会请求加入，由管理员在 **连接 > 运行器** 下批准。
+
+服务在开机时启动，失败后会重启。用 systemd 自带的工具管理它们并查看日志：
+
+```bash
+sudo systemctl status ansibleforms ansibleforms-rte
+sudo systemctl restart ansibleforms
+sudo journalctl -u ansibleforms -f
+sudo journalctl -u ansibleforms-rte -f
+```
+
+应用无需 root 即可监听 1024 以下的端口，例如 `443`。RTE 保留使用 `sudo` 的权限，在此服务器上带
+`become` 的 playbook 需要它，因此 playbook 可以管理 RTE 所在的服务器。
+
+---
+
+## 升级和回滚
+
+`sudo /usr/local/bin/ansibleforms-installer upgrade` 升级原生安装的方式与其他安装相同（参见 [升级](installer.html#upgrade)），
+顺序如下：
+
+1. 在正在运行的版本旁边放置新版本：其发行包、Node.js、Python、Ansible 和 collection。此时尚不触碰
+   正在运行的服务
+2. 添加该版本带来的新初始文件，保留所有已存在的文件
+3. 把数据库（控制器）备份到 `installer-backups/`，并附上 `app.env` 和 `rte.env` 的副本
+4. 停止服务，把 `current` 指向新版本，然后重新启动服务
+5. 等待应用以新版本响应（运行器：等待其 RTE 重新开始监听）
+
+如果新版本没有响应，安装程序会提议回滚：`current` 重新指向之前的版本，
+数据库从备份中恢复，然后启动服务。只保留正在运行的版本及其前一个版本。
+
+如果符合安装程序布局的原生服务旁边没有 `installer.json`（例如该文件被删除了），`install`
+和 `upgrade` 会发现它们并提议接管（参见 [已有的安装](installer.html#an-existing-installation)）。
+
+---
+
+## 卸载
+
+`sudo /usr/local/bin/ansibleforms-installer uninstall` 会停止并删除服务。它会保留文件夹和数据库，除非您选择删除
+数据（或传入 `--purge`）并输入实例名称进行确认。这种情况下，它还会删除数据库及其用户（控制器）、
+删除文件夹并移除系统用户。
+
+软件包仍保持安装状态，包括 MariaDB：其他软件可能在使用它们。
+
+---
+
+## 离线环境
+
+`--bundle` 从您复制到服务器上的发行包进行安装，而不是从 GitHub 下载。请从应用的 [Releases](https://github.com/ansibleforms/ansibleforms/releases)
+中获取对应架构的文件 `ansibleforms-<version>-linux-amd64.tar.gz` 或 `-arm64`：
+
+```bash
+sudo /usr/local/bin/ansibleforms-installer install --mode native --bundle /tmp/ansibleforms-7.3.0-linux-amd64.tar.gz
+```
+
+`--source` 对初始文件起同样的作用，使用 [ansibleforms/docker](https://github.com/ansibleforms/docker)
+仓库的本地副本。Node.js、Python 及其软件包以及 Ansible collection 仍会在安装过程中下载。
diff --git a/i18n/zh/_get_started/upgrade-7.md b/i18n/zh/_get_started/upgrade-7.md
new file mode 100644
index 0000000..a97f746
--- /dev/null
+++ b/i18n/zh/_get_started/upgrade-7.md
@@ -0,0 +1,301 @@
+---
+layout: default
+title: 升级到 v7
+parent: 升级
+nav_order: 0.5
+translated_from: 8c6ca072978823febdff10a5f0a3c935f994b50b
+---
+
+# 升级到 v7
+{: .no_toc }
+
+仍在 6.5 上时需要修改什么，以及迁移到版本 7 后会有哪些变化
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+版本 7 删除了 6.x 中弃用的所有内容；请先在新旧写法都可用的 6.5 上修复它们，然后再升级。
+
+---
+
+## 升级之前（在 6.5 上）
+
+### 表单存放在各自的文件中
+
+表单只存放在表单文件夹（`FORMS_FOLDER_PATH`）或表单仓库中；`config.yaml` 保存类别、角色和常量。
+
+- **`forms.yaml` 文件：** 将其重命名为 `config.yaml`。在 6.5 上，设置页面有一个
+  **将 forms.yaml 转换为 config.yaml** 按钮可完成此操作。
+- **基础配置中的 `forms:` 部分：** 版本 7 会拒绝它。请把每个表单移到单独的文件中，例如
+  在 6.5 的设计器中把它拖到某个文件里。
+- **环境变量：**
+
+  | 已移除 | 替代方案 |
+  |---|---|
+  | `FORMS_PATH` | `CONFIG_PATH` 和 `FORMS_FOLDER_PATH` |
+  | `ENABLE_FORMS_YAML_IN_DATABASE` | `ENABLE_CONFIG_IN_DATABASE` |
+
+### `table` 字段
+
+版本 7 会拒绝 `table` 字段，其属性（`tableFields`、`insertColumns`、`readonlyColumns`、
+`tableTitleAdd`、`tableTitleEdit`）也随之移除：请使用带 `subform` 的 `list` 字段，并把每列的 `from` 改为基于
+`__parent__` 的表达式（参见 [常见问题](faq#how-do-i-migrate-from-table--tablefields-to-list--subform)）。
+
+### 重命名的属性
+
+每个已移除的属性都有直接的替代：
+
+| 已移除 | 替代方案 |
+|---|---|
+| `disableRelaunch: true`（表单） | `allowRelaunch: false` |
+| `noOutput: true`（字段） | `output: false` |
+| `enableLogin`（角色选项） | `allowLogin` |
+
+### 数据源和数据 schema
+
+数据源导入及其管理页面已被移除，
+AnsibleForms Galaxy collection 也已移除，它的模块只为数据源服务。
+
+- 计划的导入会停止，数据源表会被删除：请先记下您需要的内容。
+- 导入填充的数据 schema 是独立的数据库，会保留下来。通过凭据
+  查询它们的表单可以继续工作。
+- 要让这些数据保持更新，请用您自己的 playbook 运行导入，例如通过
+  调度来运行。
+
+### API v1
+
+`/api/v1/*` 已被移除；请使用 `/api/v2/*`（交互式文档位于 `/api/v2/docs`）。脚本
+常用的调用为：
+
+| v1 | v2 |
+|---|---|
+| `POST /api/v1/auth/login` | `POST /api/v2/auth/login` |
+| `POST /api/v1/token` | `POST /api/v2/token` |
+| `POST /api/v1/job` | `POST /api/v2/job` |
+
+v2 以 HTTP 状态码（`400`、`403`、`404`、`422`）和普通的 JSON 正文响应，而不是 v1 的
+`{ status, message, data }` 封装。
+
+**单点登录回调也是如此。** 包含 `/api/v1/` 的重定向 URL 不再响应：登录会返回
+登录页面而不会登录成功。请在两处把它改为 `/api/v2/`：AnsibleForms 中的 SSO 提供方，以及
+身份提供方（Entra ID 应用注册的重定向 URI、OIDC
+客户端的有效重定向 URI）：
+
+- Entra ID：`https://<your host>/api/v2/auth/azureadoauth2/callback`，从 7.3.0 起为 `/api/v2/auth/entraid/callback`
+- OIDC：`https://<your host>/api/v2/auth/oidc/callback`
+
+---
+
+## 7 中有哪些变化
+
+版本 7 改变了 playbook 的运行方式，并收紧了若干默认设置。从 6.5 迁移时，请逐项检查以下内容。
+
+### playbook 在 RTE 上运行
+
+版本 7 不再在 AnsibleForms 容器中运行 `ansible-playbook`。playbook 在运行环境（RTE）上运行，
+RTE 是一个独立的容器，应用镜像中不再包含 ansible 或 python。请在应用旁启动一个 RTE，使用
+`ghcr.io/ansibleforms/ansibleforms-rte-full:7` 镜像。从 7.3.0 起，应用主动连接 RTE 并保持一条 WebSocket 连接（参见
+[模式](rte/modes.html)）：RTE 不获取数据库设置，也不获取 `ENCRYPTION_SECRET`。其设置为：
+
+| 设置 | 值 |
+|---|---|
+| `AF_ROLE` | `rte`。RTE 镜像已经设置了它。 |
+| `RTE_MODE` | `inbound`：应用连接 RTE。位于另一个网络中的运行器使用 `outbound`（参见 [模式](rte/modes.html)）。 |
+| `RTE_TOKEN` | 至少 16 个字符的令牌。应用用它登录 RTE 的 socket，没有它 RTE 会拒绝启动。 |
+| `RTE_FILES` | 当 RTE 与应用挂载同一个持久化文件夹时（例如运行在应用旁边）设为 `local`。 |
+
+然后把 ansible 相关的挂载从应用容器移到 RTE：
+
+- `ansible.cfg` 位于 `/etc/ansible/ansible.cfg`，您的角色位于 `/etc/ansible/roles`，您的 collection 位于
+  `/etc/ansible/collections`。
+- 在 RTE 上也挂载与应用相同的持久化文件夹，以便它找到 playbook 和仓库。
+
+然后把 RTE 声明为运行器，可以像 Docker Compose 项目那样在 [配置种子](seed/) 中声明，也可以在 **连接 → 运行器** 下声明：
+一个包含 RTE 地址（例如 `http://rte:8000`）和同一令牌的 RTE 凭据，以及一个引用该凭据的 RTE 类型运行器（inbound 模式）：
+
+```yaml
+credentials:
+  items:
+    - name: rte
+      credential_type: rte
+      url: http://rte:8000
+      password: ${RTE_TOKEN}
+runners:
+  items:
+    - name: rte
+      type: rte
+      rte_mode: inbound
+      credential: rte
+      is_default: true
+```
+
+种子从应用的环境中读取 `RTE_TOKEN`。参见 [运行器](runners.html) 和 [运行环境](rte/)。
+
+{: .warning }
+> **应用和 RTE 使用相同的契约** 应用解析作业的凭据，并以只有该 RTE 能打开的密封形式交给它
+> （RTE 契约 2，7.0.0 新增）。契约不同的 RTE 会拒绝应用的作业：请运行与应用同一版本的
+> RTE 镜像，并同时升级二者。只要契约保持不变，后续的 7 版本仍可与较旧的 7 RTE 配合使用
+> （参见 [扩展](../rte/images.html#build-your-own-rte)）。
+
+
+### RTE 镜像包含什么
+
+RTE 分为三层，每一层都构建在前一层之上。请选择适合您 playbook 的一层：
+
+| 镜像 | 内容 |
+|---|---|
+| `ansibleforms-rte-full` | 默认镜像。Ansible 14 搭配 ansible-core 2.21，以及 6.5 镜像中已有的 collection 和 python 库。 |
+| `ansibleforms-rte-core` | Python 3.14、ansible-core 和少量常用库，不含 collection。请在基于它构建的镜像中添加您自己的 collection。 |
+| `ansibleforms-rte-base` | 只有 server，不含 python 和 ansible，用于以您自己的版本构建 RTE。 |
+
+从 6.5（ansible 12 搭配 ansible-core 2.19）迁移时，以下内容也会对您的 playbook 产生影响：
+
+- **ansible-core 2.21：** 请阅读 2.20 和 2.21 的
+  [移植指南](https://docs.ansible.com/ansible/latest/porting_guides/porting_guides.html)。
+- **Python 3.14：** 各层 RTE 都运行在 python 3.14 上。
+- **不再有 `boto`：** 旧的 `boto` 2 库已被移除。`amazon.aws` collection 使用已包含在内的 `boto3`。
+
+有两个环境变量现在属于 RTE，应用不再读取它们，因此请在 RTE 容器中设置：
+
+| 变量 | 变化 |
+|---|---|
+| `ANSIBLE_PATH` | playbook 文件夹，位于 RTE 上。 |
+| `PROCESS_MAX_BUFFER` | 现在默认为 50 MB。超过后不再存储作业输出（作业中会注明），但 playbook 会继续运行而不会被停止。 |
+
+
+### 容器以 uid 1000 运行
+
+应用和 RTE 镜像以用户 `node`（uid 1000）而不是 root 运行，其主目录为 `/home/node`：
+
+- **把卷的所有权交给 uid 1000，执行一次即可。** 对于持久化卷和 ssh 卷，运行
+  `docker run --rm -v <volume>:/v alpine chown -R 1000:1000 /v`；对于主机文件夹，运行 `sudo chown -R 1000:1000 <folder>`。
+  在 Kubernetes 上，设置 `fsGroup: 1000`。
+- **把 ssh 文件夹挂载到 `/home/node/.ssh`**，而不是 `/root/.ssh`。如果您把
+  [`HOME_PATH`](customization/paths.html#env_HOME_PATH) 设为了 `/root`，请删除它或改为 `/home/node`。
+- **基于 RTE 层构建的您自己的 RTE 镜像** 在安装时切换到 `USER root`，最后再切换回 `USER node`。
+
+
+### 运行验证默认开启
+
+[`LAUNCH_VALIDATION`](customization/features.html#env_LAUNCH_VALIDATION) 现在默认为 `enforce`（6.5：`off`）。每次
+启动，无论来自浏览器还是来自 `POST /api/v2/job`，都会按照表单的规则进行检查，作业使用服务器根据检查过的值构建的
+extravars 和凭据运行。
+
+- **REST 调用方必须发送 `rawFormData`**，即浏览器发送的原始字段值。只带
+  `extravars` 的启动会被拒绝，因为其值无法检查。
+- **要先查看哪些会被拒绝**，请设置 `LAUNCH_VALIDATION=log` 并阅读日志中的警告。`off` 会恢复
+  6.5 的行为。
+
+详情参见 [运行验证](launch-validation/)。
+
+
+### playbook 不再能看到应用的设置
+
+playbook 不再继承 AnsibleForms 自己读取的环境变量：`ENCRYPTION_SECRET`、`DB_*` 设置、
+`ACCESS_TOKEN_SECRET`、`RTE_TOKEN`、`VAULT_*` 设置、其他所有已记录的变量以及所有 `MYSQL_*` 变量。
+RTE 环境中的其余内容，例如 `PATH`、代理、`ANSIBLE_*` 设置和云凭据，仍像以前一样传递。
+
+用 `lookup('env', ...)` 读取其中某个变量的 playbook 必须改用其他方式获取该值：把它作为 extravar 或
+凭据传入，或者在 RTE 上以其他名称设置它。
+
+### 只有 admin 角色才能管理运行器和管理员
+
+拥有设置访问权限的用户不再能完全控制谁是管理员以及凭据流向何处：
+
+- **运行器：** 只有 admin 角色才能添加、修改或删除运行器，因为运行器会收到它所运行作业的
+  凭据。拥有设置访问权限的用户仍然可以查看和测试运行器。
+- **管理员账户和组：** 只有 admin 角色才能授予管理员权限。没有它的用户不能把账户放入 admin 角色
+  所指定的组中，也不能修改、重置或删除管理员账户或此类组。
+- **角色：** 没有 admin 角色的设计人员不能修改角色。角色不同的保存或恢复会被拒绝。
+
+请把 admin 角色授予负责管理运行器、管理员和角色的人。
+
+### 必须修改默认密码
+
+使用公开的默认密码 `AnsibleForms!123` 登录的用户必须先修改密码。在此之前，其他所有 API
+调用都会以代码 `password_change_required` 返回 `403`，浏览器会显示修改密码页面。
+
+请登录一次并设置新密码，或者在首次启动之前设置 [`ADMIN_PASSWORD`](customization/server.html#env_ADMIN_PASSWORD)。
+使用默认密码登录的脚本必须改用其他密码。
+
+### 令牌在注销和修改密码时失效
+
+现在注销会使该会话的令牌失效，修改密码会结束该用户的所有会话，因此修改密码后
+请重新登录。
+
+用 `?expiryDays=` 请求的 API 令牌最多有效 [`API_TOKEN_MAX_DAYS`](customization/security.html#env_API_TOKEN_MAX_DAYS) 天
+（默认 90 天）。使用长期 API 令牌的脚本必须在令牌过期前申请新令牌。
+
+### Entra ID 需要您的租户
+
+Entra ID（Azure AD）登录现在只针对您自己的租户使用 OpenID Connect，其他租户的用户无法
+登录。没有租户 ID，或租户为 `common`、`organizations` 或 `consumers` 的提供方会被拒绝。
+
+- **在 SSO 提供方上设置租户 ID**：目录（租户）ID，即一个 GUID，或者租户的域名。
+- **授予 Graph 权限：** 登录时会请求 `openid profile email User.Read GroupMember.Read.All`。请为应用
+  注册授予委托的 Microsoft Graph 权限 `User.Read` 和 `GroupMember.Read.All`，并获得管理员同意。
+- **在角色中优先使用组 ID：** 以 `azuread/<object id>`（从 7.3.0 起为 `entraid/<object id>`）指定组，而不是使用其显示名称。
+
+设置方法参见 [Entra ID](authentication/entra-id.html)。
+
+### 密码有最小长度
+
+通过应用设置的本地密码至少需要
+[`PASSWORD_MIN_LENGTH`](customization/security.html#env_PASSWORD_MIN_LENGTH) 个字符（默认 8 个），并且不能与用户名或
+默认密码相同。`PASSWORD_MIN_LENGTH=0` 会关闭长度检查。现有密码仍然有效。
+
+### 为容器设置重启策略
+
+未捕获的异常现在会结束进程，并以 `crit` 级别记录日志，而不是让进程在未知状态下继续运行。请为
+容器设置重启策略，例如 Docker 的 `--restart unless-stopped`（docker-compose 项目已设置）。
+Kubernetes 会自行重启 pod。
+
+### AWX 连接和首页链接
+
+7 中还有两项内容被移除，在 6.5 上无需做任何事：
+
+- **AWX 和 AAP 连接：** `awx` 表、`/api/v2/awx` 和 A.A.P. 页面已被移除。升级会把每个 AWX 或
+  AAP 连接迁移到 **连接 → 运行器**，作为 `awx` 类型的运行器，带有 `awx:` 的表单可以继续工作。
+- **`NAV_HOME_LABEL` 和 `NAV_HOME_ICON`：** 不再读取。页眉的第一个链接始终是表单。
+
+### 在 7 中弃用，在 8 中移除
+
+以下内容在 7 中仍然可用，但每次使用时都会记录一条警告。请在版本 8 之前改用替代方案：
+
+| 已弃用 | 替代方案 |
+|---|---|
+| `VAULT_*` 环境变量 | 名为 `vault` 的密钥库（**连接 → 密钥库**）。7 首次启动时会把这些变量导入一次作为该密钥库，之后忽略它们。 |
+| `LOG_SYSLOG_*` 环境变量 | 一个 syslog 服务器（**连接 → Syslog**）。设置了 `LOG_SYSLOG_HOST` 时，7 首次启动会把它们导入一次作为服务器 `syslog`，它像以前一样接收服务器日志，之后忽略这些变量。如果还要发送审计条目，请把它设置为同时接收两者。 |
+| 凭据上的 `vault_path`（API、配置种子） | `secret_store` 和 `secret_ref`。参见 [密钥库](secret-stores/)。 |
+| `config.yaml` 中的角色 `public` | 角色 `default`。加载配置时文件中的名称会被重命名；ytt 模板需要手动重命名。表单 `roles:` 中的 `public` 仍然匹配。 |
+| `POST /api/v2/config/vault/check`、`GET /api/v2/config/vault/mounts` | `POST /api/v2/secretstore/{id}/check`、`GET /api/v2/secretstore/{id}/mounts` |
+| 表单或步骤上的 `hasApproval` | `approval`。`hasApproval` 不再起作用。 |
+| 表单上的 `awx: <name>` | `runner: <name>`。AWX 连接是 `awx` 类型的运行器。 |
+| 表单上的 `type: multistep` 及其 `steps` | `type: workflow`，其节点指定一个 `runner`。参见 [工作流表单](forms/workflow.html)。 |
+| 配置种子中的 `awx:` 部分 | `type: awx` 的 `runners:` 项 |
+| `LOCK_PATH` | 无需替代：不再读取，设计器锁保存在数据库中。 |
+| 数据库模式的 RTE（自 7.3.0 起）：`RTE_MODE=database` 或没有 `RTE_MODE`，并在 RTE 上设置数据库的 `DB_*` 和 `ENCRYPTION_SECRET` | `RTE_MODE=outbound` 或 `RTE_MODE=inbound`，不含 `DB_*`。RTE 使用加入令牌（`RTE_JOIN_TOKEN`）加入一次，或者在 **连接 → 运行器** 下或配置种子中（`rte_mode`）把其运行器设为该模式。参见 [模式](rte/modes.html)。 |
+| `RTE_REGISTER`（自 7.3.0 起，仅限数据库模式） | 加入令牌（`RTE_JOIN_TOKEN`）：RTE 会把自己添加为使用 RTE 凭据登录的运行器。 |
+| 配置种子中运行器上的 `api` 或 `userpass` 凭据（自 7.3.0 起） | 与运行器种类相同的凭据（`credential_type: rte`、`awx`、`aap`、`ascender`、`semaphore`、`rundeck` 或 `jenkins`），其服务器写在 `url` 中。 |
+| 配置种子中带有自己的 `token`，或 `username` 和 `password` 的运行器（自 7.3.0 起） | `credentials` 部分中与运行器种类相同的凭据，其服务器写在 `url` 中，由运行器用 `credential:` 引用。在此期间，种子会创建一个以该运行器命名的凭据。 |
+
+自 7.3.0 起不再读取 `ENABLE_SSO` 和 `SSO_AUTO_LOGIN`。7.3 首次启动时会把它们迁移一次：`ENABLE_SSO=0` 会禁用
+所有 SSO 提供方，`SSO_AUTO_LOGIN=1` 会在唯一启用的提供方上勾选 **跳过登录页**。之后它们会被忽略：只要它们仍被设置，每次启动
+都会记录一条警告，每个提供方在 **访问 → SSO** 下都有 **已启用** 和 **跳过登录页**。
+
+---
+
+## 镜像标签
+
+`latest` 在 7.0.0 时移到 7。要停留在 6，请使用标签 `6`（或 `6.5`）而不是 `latest`。
+所有标签都列在 [镜像标签](installation/#image-tags) 中。
+
+---
+
+## 回滚
+
+升级前请先进行备份（**设置 → 备份**）。6.5 可以在已升级到 7 的数据库上运行，但只有
+备份才能恢复已删除的数据源定义。
diff --git a/i18n/zh/_get_started/upgrading/docker-compose.md b/i18n/zh/_get_started/upgrading/docker-compose.md
new file mode 100644
index 0000000..fb36be2
--- /dev/null
+++ b/i18n/zh/_get_started/upgrading/docker-compose.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: Docker Compose
+parent: 升级
+nav_order: 2
+translated_from: e0588e18950ebc7164327833bdc85871783048ba
+---
+
+# Docker Compose
+{: .no_toc }
+
+升级使用 docker-compose 项目完成的安装
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+docker-compose 项目运行三个容器：MySQL（`mysqldb`）、AnsibleForms（`app`）以及运行
+playbook 的 RTE（`rte`）。AnsibleForms 和 RTE 使用镜像标签 `7`，它始终指向最新的 7.x 版本。
+升级会重新拉取镜像，并重新创建镜像发生变化的容器。所有需要持久保存的内容都存储在
+`data` 文件夹中，并会被保留。
+
+---
+
+## 升级之前
+
+做好升级准备，以便出现问题时可以回退：
+
+* 在 **设置 → 备份** 下 **进行备份**。新版本会在首次启动时升级数据库 schema。
+* **阅读 [更新日志](../changelog)** 中从您的版本到新版本之间的各个版本。
+* **要迁移到新的主版本？** 请先遵循 [升级到 v7](../upgrade-7.html)。
+* **从 6.5 升级？** 6.x 项目（位于其 `v6` 分支）没有 `rte` 容器。请把您的项目副本更新到
+  其 `main` 分支，保留您的 `.env` 设置和 `data` 文件夹，使 `docker-compose.yml` 包含 `rte`
+  服务。该 compose 文件设置了 `CONFIG_SEED_PATH`，而 6.x 的 `data` 文件夹中没有 `seed.yaml`：请从
+  仓库复制 `data/seed.yaml`，并像仓库的 `.env` 那样在您的 `.env` 中添加 `RTE_TOKEN`（至少 16 个字符）。缺少它们时，
+  应用会拒绝启动。7 的镜像以 uid 1000 而不是 root 运行：请执行一次
+  `sudo find data -path data/mysql -prune -o -exec chown 1000:1000 {} +`，把 `data` 文件夹交给该用户，MySQL 的文件则留给 MySQL。
+  `data/ssh` 文件夹现在挂载到 `/home/node/.ssh`，而不是 `/root/.ssh`。
+* **从 7.2 升级？** 请同时更新 `docker-compose.yml` 和 `data/seed.yaml`：先参见 [从 7.2 到 7.3](#from-72-to-73)。
+
+---
+
+## 从 7.2 到 7.3
+
+在 7.2.0 及之前，`rte` 服务会获得数据库的设置，而它在 `data/seed.yaml` 中声明的运行器以数据库模式运行，
+该模式在 7.3.0 中弃用，并在 8.0.0 中移除。从 7.3.0 起，应用通过 `http://rte:8000` 连接 RTE 并保持一条 WebSocket 连接
+（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)），RTE 不再持有任何数据库设置。请从仓库的
+`main` 分支获取这两个文件，并保留您的 `.env`：
+
+| 文件 | 变化 |
+|---|---|
+| `docker-compose.yml` | `rte` 服务不再读取 `.env`：它获得 `RTE_MODE=inbound`、`RTE_TOKEN` 和 `RTE_FILES=local`，不再有 `DB_*` |
+| `data/seed.yaml` | 一个 RTE 凭据 `rte`，带有 `url: http://rte:8000` 和 `password: ${RTE_TOKEN}`，以及带有 `rte_mode: inbound` 和 `credential: rte` 的运行器 `rte` |
+
+两个文件都要修改。如果只换了新的 compose 文件，种子会让运行器 `rte` 保持数据库模式：应用会把 RTE 当作 7.2 的 RTE 来调用，
+而新的 RTE 不会响应，于是没有任何 playbook 能运行。您自己修改过的种子也需要加上同样的凭据和 `rte_mode`。
+
+由种子创建的运行器始终处于受管理状态，在 **连接 → 运行器** 下为只读，即使您删除了 `CONFIG_SEED_PATH` 也是如此：只有
+被应用的种子才会释放它不再声明的运行器。因此请保留种子并在其中设置 `rte_mode`，而不是删除
+`CONFIG_SEED_PATH` 后再手动修改运行器。
+
+[安装程序](../installation/installer.html#upgrade) 会自行完成这些：它的升级会替换 `docker-compose.yml`；如果 `data/seed.yaml`
+是仓库附带且未修改的种子，也会替换它。手动修改过的会保留，新的种子保存在它旁边。
+
+---
+
+## 1. 拉取新镜像
+
+下载 `docker-compose.yml` 中各标签对应的最新镜像：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo docker compose pull
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+cd /srv/apps/ansibleforms-docker
+sudo podman-compose pull
+```
+
+</div>
+</div>
+
+---
+
+## 2. 重新创建容器
+
+再次启动项目；镜像发生变化的容器会被重新创建：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose up -d
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose down
+sudo podman-compose up -d
+```
+
+</div>
+</div>
+
+---
+
+## 3. 检查升级
+
+在 AnsibleForms 启动时跟踪其日志。新版本首次启动时会升级数据库 schema，RTE
+会在 AnsibleForms 进入健康状态后启动：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+sudo docker compose logs -f app
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+sudo podman-compose logs -f app
+```
+
+</div>
+</div>
+
+在 AnsibleForms 中，**帮助 → 关于** 显示正在运行的版本，**设置 → 状态** 显示
+数据库、schema 以及 AnsibleForms 所依赖的其他系统的健康状况。
+
+---
+
+## 回滚
+
+要回到之前运行的版本，即升级前 **帮助 → 关于** 显示的版本，请在
+`docker-compose.yml` 中把 AnsibleForms 和 RTE 镜像的标签都从 `7` 改为该版本的确切标签，然后再次执行步骤 2。如果该版本
+无法在升级后的数据库上启动，请恢复您在 **设置 → 备份** 下创建的备份。把标签改回
+`7` 即可再次获得更新。
+
+**视频**：[如何升级 AnsibleForms](https://www.youtube.com/watch?v=5ZDJ8CcUx5c)
diff --git a/i18n/zh/_get_started/upgrading/docker.md b/i18n/zh/_get_started/upgrading/docker.md
new file mode 100644
index 0000000..06e919f
--- /dev/null
+++ b/i18n/zh/_get_started/upgrading/docker.md
@@ -0,0 +1,182 @@
+---
+layout: default
+title: Docker
+parent: 升级
+nav_order: 1
+translated_from: 4b3babaa4c1dd9c7848cf92c8bd75af68e6fac97
+---
+
+# Docker
+{: .no_toc }
+
+升级不使用 docker-compose 的独立容器
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+独立安装通过替换其容器来升级：拉取新镜像，删除旧容器，并用相同的 `run` 命令
+启动新容器。从版本 7 起有两个容器：AnsibleForms 和运行 playbook 的 RTE，二者始终使用同一个版本。
+您的文件存储在所挂载的 `/app/dist/persistent` 文件夹中，数据存储在
+MySQL 中，因此两者都会被保留。
+
+---
+
+## 升级之前
+
+做好升级准备，以便出现问题时可以回退：
+
+* 在 **设置 → 备份** 下 **进行备份**。新版本会在首次启动时升级数据库 schema。
+* **阅读 [更新日志](../changelog)** 中从您的版本到新版本之间的各个版本。
+* **要迁移到新的主版本？** 请先遵循 [升级到 v7](../upgrade-7.html)。
+* **从 6.5 升级？** 7 的镜像以 uid 1000 而不是 root 运行：请把您挂载的文件夹交给该用户，执行一次即可，
+  例如 `sudo chown -R 1000:1000 /srv/apps/ansibleforms/persistent /srv/apps/ansibleforms/ssh`。
+* **从 7.2 升级？** RTE 有了自己的文件，并由应用主动连接它：先参见 [从 7.2 到 7.3](#from-72-to-73)。
+
+---
+
+## 从 7.2 到 7.3
+
+在 7.2.0 及之前，RTE 读取应用的环境文件（包含数据库设置），并根据 `RTE_URL` 把自己添加为运行器。这
+就是数据库模式，在 7.3.0 中弃用，并在 8.0.0 中移除。从 7.3.0 起，应用主动连接 RTE 并保持一条 WebSocket 连接
+（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)），RTE 不再持有任何数据库设置。在执行步骤 2 之前，做一次以下操作：
+
+1. 像 [安装](../installation/docker.html#prepare-the-folders) 时那样创建 `/srv/apps/ansibleforms/rte.env`，内容为
+   `RTE_MODE=inbound`、相同的 `RTE_TOKEN`、`RTE_FILES=local`、`PORT=8000` 和 `HTTPS=0`。不要 `DB_*`、`ENCRYPTION_SECRET` 和 `RTE_URL`
+2. 以该模式声明运行器。可以添加安装时的 [配置种子](../seed/)，即包含 RTE 凭据
+   （`url: http://rte:8000`、`password: ${RTE_TOKEN}`）和运行器 `rte`（`rte_mode: inbound`）的 `persistent/seed.yaml`，并在
+   应用的环境文件中添加 `CONFIG_SEED_PATH=/app/dist/persistent/seed.yaml`。或者不使用种子，在
+   **连接 → 运行器** 下打开该运行器，把其 **模式** 设为 **入站**，并选择一个包含 `http://rte:8000` 和该令牌的 RTE 凭据
+
+使用种子时，应用的环境文件中也要有 `RTE_TOKEN`，即同一个令牌，因为种子从那里读取它。
+
+---
+
+## 1. 拉取新镜像
+
+下载您所运行标签的最新 AnsibleForms 和 RTE 镜像：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker pull ghcr.io/ansibleforms/ansibleforms:7
+docker pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman pull ghcr.io/ansibleforms/ansibleforms:7
+podman pull ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+---
+
+## 2. 替换容器
+
+删除旧容器，并用 [安装](../installation/docker.html) 时的 `run` 命令启动新容器。应用
+从其环境文件中读取数据库连接，使用 AnsibleForms 的数据库用户（而不是 root）。RTE 读取自己的
+`rte.env`，其中不含数据库设置，应用通过两个容器共享的网络连接它：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker stop ansibleforms rte
+docker rm ansibleforms rte
+
+docker run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+docker run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman stop ansibleforms rte
+podman rm ansibleforms rte
+
+podman run -d --name ansibleforms --network ansibleforms -p 8000:8000 --restart unless-stopped \
+  --env-file /srv/apps/ansibleforms/ansibleforms.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms:7
+
+podman run -d --name rte --network ansibleforms --restart unless-stopped --stop-timeout 30 \
+  --env-file /srv/apps/ansibleforms/rte.env \
+  -v /srv/apps/ansibleforms/persistent:/app/dist/persistent \
+  -v /srv/apps/ansibleforms/ssh:/home/node/.ssh \
+  ghcr.io/ansibleforms/ansibleforms-rte-full:7
+```
+
+</div>
+</div>
+
+如果从 6.5 升级，此时还没有 RTE 容器：`stop` 和 `rm` 命令只会找到应用。请用
+`docker network create ansibleforms`（或 `podman network create ansibleforms`）创建一次共享网络。像
+[安装](../installation/docker.html#prepare-the-folders) 时那样，把数据库连接、`ENCRYPTION_SECRET`、至少 16 个字符的 `RTE_TOKEN`
+和 `CONFIG_SEED_PATH` 写入应用的环境文件，并创建 `rte.env` 和配置种子。如果您的 6.5 安装挂载的是其他文件夹，
+请使用您自己的文件夹。种子会把 RTE 作为默认运行器 `rte` 添加到 **连接 → 运行器** 下；
+参见 [升级到 v7](../upgrade-7.html#playbooks-run-on-an-rte)。
+
+---
+
+## 3. 检查升级
+
+在 AnsibleForms 启动时跟踪其日志。新版本首次启动时会升级数据库 schema：
+
+<div class="af-tabs" data-tab-group="engine">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="docker" aria-selected="true">Docker</button>
+<button type="button" role="tab" class="af-tab" data-tab="podman" aria-selected="false">Podman</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="docker" markdown="1">
+
+```bash
+docker logs -f ansibleforms
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="podman" markdown="1" hidden>
+
+```bash
+podman logs -f ansibleforms
+```
+
+</div>
+</div>
+
+RTE 会写自己的日志，可用 `docker logs rte` 查看。在 AnsibleForms 中，**帮助 → 关于** 显示正在运行的版本，**设置 → 状态** 显示
+数据库、schema 以及 AnsibleForms 所依赖的其他系统的健康状况。
+
+---
+
+## 回滚
+
+要回到之前运行的版本，即升级前 **帮助 → 关于** 显示的版本，请再次执行步骤 2，并把
+AnsibleForms 和 RTE 镜像的 `7` 都换成该版本的确切标签。如果该版本无法在升级后的
+数据库上启动，请恢复您在 **设置 → 备份** 下创建的备份。
diff --git a/i18n/zh/_get_started/upgrading/from-source.md b/i18n/zh/_get_started/upgrading/from-source.md
new file mode 100644
index 0000000..e4783da
--- /dev/null
+++ b/i18n/zh/_get_started/upgrading/from-source.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: 从源码安装
+parent: 升级
+nav_order: 3
+translated_from: f01384ded41bf8e1913196bb78e7ea1a6532989c
+---
+
+# 从源码安装
+{: .no_toc }
+
+升级从源码构建的安装
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+从源码构建的安装通过检出新版本、重新构建并重启
+应用来升级。您的设置、表单、playbook、证书和日志存储在 `server/persistent` 中，Git 和
+构建都不会修改它。
+
+---
+
+## 升级之前
+
+做好升级准备，以便出现问题时可以回退：
+
+* 在 **设置 → 备份** 下 **进行备份**。新版本会在首次启动时升级数据库 schema。
+* **阅读 [更新日志](../changelog)** 中从您的版本到新版本之间的各个版本。
+* **要迁移到新的主版本？** 请先遵循 [升级到 v7](../upgrade-7.html)。
+* 在更新日志中 **检查新版本所需的 Node.js 版本**。
+
+---
+
+## 1. 获取新版本
+
+获取版本标签并检出您想要的版本。版本标签带有版本号，`git tag` 会列出
+它们；`main` 分支可能包含尚未发布的更改：
+
+```bash
+cd /srv/apps/ansibleforms
+git fetch --tags
+git checkout <version>
+```
+
+---
+
+## 2. 重新构建
+
+按照与安装时相同的三个步骤重新构建。首先重新构建 client：
+
+```bash
+cd client
+npm ci
+npm run build
+```
+
+然后更新 server 的依赖：
+
+```bash
+cd ../server
+npm ci --omit=dev
+```
+
+最后再次把重新构建的 client 复制到 server 的 `views` 文件夹中：
+
+```bash
+rm -rf views
+mkdir views
+cp -r ../client/dist/. views/
+```
+
+把仓库根目录的 `.env.example` 与您的 `persistent/.env` 进行比较，以加入该版本新增的设置。
+
+---
+
+## 3. 重启
+
+重启应用及其 RTE 以加载新代码。数据库 schema 会在首次启动时升级：
+
+```bash
+pm2 restart ansibleforms ansibleforms-rte
+```
+
+如果从 7.2 升级，RTE 原先以数据库模式运行，带有数据库设置和 `RTE_URL`，该模式在 7.3.0 中弃用，并在 8.0.0 中移除。
+请以入站模式重新启动它，并在种子中或 **连接 → 运行器** 下用一个 RTE 凭据声明其运行器，具体参见
+[安装](../installation/from-source.html#run)：先执行 `pm2 delete ansibleforms-rte`，再执行其 `pm2 start` 命令。
+
+如果您不使用 PM2 运行应用，请停止 `npm run start` 并再次启动它。
+
+---
+
+## 4. 检查升级
+
+在应用启动时跟踪其日志：
+
+```bash
+pm2 logs ansibleforms
+```
+
+在 AnsibleForms 中，**帮助 → 关于** 显示正在运行的版本，**设置 → 状态** 显示
+数据库、schema 以及 AnsibleForms 所依赖的其他系统的健康状况。
+
+---
+
+## 回滚
+
+要回到之前运行的版本，即升级前 **帮助 → 关于** 显示的版本，请用
+`git checkout <version>` 检出其标签，然后按步骤 2 和 3 重新构建并重启。如果该版本无法在升级后的数据库上启动，请恢复您在
+**设置 → 备份** 下创建的备份。
diff --git a/i18n/zh/_get_started/upgrading/index.md b/i18n/zh/_get_started/upgrading/index.md
new file mode 100644
index 0000000..ba6c12c
--- /dev/null
+++ b/i18n/zh/_get_started/upgrading/index.md
@@ -0,0 +1,42 @@
+---
+layout: default
+title: 升级
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /upgrading/
+translated_from: 0312d064ef52498600338c2db720a4c928aed953
+---
+
+# 升级
+{: .no_toc }
+
+把 AnsibleForms 迁移到更新的版本
+{: .fs-6 .fw-300 }
+
+---
+
+面向正在运行实例的管理员：使用您安装时所用的方式，迁移到更新的版本。
+
+---
+
+## 本节内容
+
+升级步骤取决于您安装 AnsibleForms 的方式。每种方式都有单独的页面介绍：
+
+| 页面 | 内容 |
+|---|---|
+| [升级到 v7](../upgrade-7.html) | 迁移到 7 之前，仍在 6.5 上时需要修改的内容 |
+| [使用安装程序](../installation/installer.html#upgrade) | `ansibleforms-installer upgrade`，适用于由安装程序完成的安装：备份、发行说明和回滚 |
+| [Docker](docker.html) | 拉取新镜像，并用相同的设置重新创建容器 |
+| [Docker Compose](docker-compose.html) | 拉取新镜像，并重启 docker-compose 项目 |
+| [从源码安装](from-source.html) | 拉取新代码，重新构建并重启应用 |
+| [Kubernetes](kubernetes.html) | 刷新 chart 仓库，并使用您的 values 运行 `helm upgrade` |
+
+{: .note }
+> **先备份** 升级前请先进行备份（**设置 → 备份**）。数据库 schema 会在新版本首次启动时升级，
+> 因此一旦出现问题，备份就是您的回滚点。从 7.3.0 起，worker 在从旧版本升级之前也会自行创建一个
+> 以版本命名的备份，除非 [`UPGRADE_BACKUP`](../customization/retention.html#env_UPGRADE_BACKUP) 为 `0`。
+
+您获得的版本取决于所运行的镜像标签：`latest` 跟随最新的主版本，而 `7` 之类的标签
+则停留在该主版本上。所有标签都列在 [镜像标签](../installation/#image-tags) 中。
diff --git a/i18n/zh/_get_started/upgrading/kubernetes.md b/i18n/zh/_get_started/upgrading/kubernetes.md
new file mode 100644
index 0000000..aa92116
--- /dev/null
+++ b/i18n/zh/_get_started/upgrading/kubernetes.md
@@ -0,0 +1,105 @@
+---
+layout: default
+title: Kubernetes
+parent: 升级
+nav_order: 4
+translated_from: 656ff7668e57ae8b6183a2654c4943f046caba6a
+---
+
+# Kubernetes
+{: .no_toc }
+
+升级使用 Helm chart 完成的安装
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+每个 chart 版本部署一个 AnsibleForms 版本。升级会用您现有的 values 安装更新的 chart 版本；
+持久卷上的数据会被保留。没有任何变化的升级不会触碰 pod。
+
+---
+
+## 升级之前
+
+做好升级准备，以便出现问题时可以回退：
+
+* 在 **设置 → 备份** 下 **进行备份**。新版本会在首次启动时升级数据库 schema。
+* **阅读 [更新日志](../changelog)** 中从您的版本到新版本之间的各个版本。
+* **要迁移到新的主版本？** 请先遵循 [升级到 v7](../upgrade-7.html)。
+* **阅读 chart 的 [更新日志](https://github.com/ansibleforms/helm-charts/blob/main/charts/ansibleforms/CHANGELOG.md)**，了解 values 的变化。
+* **使用生成的凭据时**（`secrets.generate`），请备份 `<release>-secrets` Secret：`ENCRYPTION_SECRET` 无法找回。
+* **从 7.2 升级？** server pod 中的 RTE 会改变模式：参见 [从 7.2 到 7.3](#from-72-to-73)。
+
+---
+
+## 从 7.2 到 7.3
+
+chart 7.3.0 让应用旁边的 RTE 脱离数据库模式，该模式在 7.3.0 中弃用，并在 8.0.0 中移除。应用通过
+`127.0.0.1` 连接它并保持一条 WebSocket 连接（`RTE_MODE=inbound`，参见 [模式](../rte/modes.html)）：
+
+* RTE 容器不再获得 `DB_HOST`、`DB_USER`、`DB_PASSWORD`、`ENCRYPTION_SECRET` 或 `RTE_URL`，并从
+  共享卷获取作业的文件（`RTE_FILES=local`）
+* chart 的配置种子声明一个包含令牌和地址的 RTE 凭据，以及使用该凭据登录的运行器（`rte_mode: inbound`）。
+  使用 chart 的种子时，无需做任何事
+* 设置了 `containers.rte.seedRunner: false`，或使用您自己的配置种子（`CONFIG_SEED_PATH`）时，RTE 不再把自己添加为运行器。
+  请自行声明它，在您的种子中或在 **连接 → 运行器** 下：一个包含 `http://127.0.0.1:<port>` 和令牌的 RTE 凭据，
+  以及一个引用它、带有 `rte_mode: inbound` 的 RTE 类型运行器。Helm 在升级后打印的说明会告诉您如何操作
+
+从 7.3.0 起，chart 还可以通过 `runner.enabled` 单独安装一个运行器（参见
+[Kubernetes 上的运行器](../installation/kubernetes.html#a-runner-on-kubernetes)）。
+
+---
+
+## 1. 查找新的 chart 版本
+
+刷新 chart 仓库并列出可用的 chart 版本：
+
+```bash
+helm repo update
+helm search repo ansibleforms/ansibleforms --versions
+```
+
+---
+
+## 2. 升级 release
+
+使用您的 values 文件和新的 chart 版本，运行与安装时相同的 `helm upgrade` 命令：
+
+```bash
+helm upgrade --install ansibleforms ansibleforms/ansibleforms \
+  --namespace ansibleforms \
+  --values my_values.yaml \
+  --version 7.0.0
+```
+
+使用 OCI registry 时，chart 请写为 `oci://ghcr.io/ansibleforms/charts/ansibleforms`。
+
+---
+
+## 3. 检查升级
+
+等待新的 pod 启动，然后运行 chart 的测试，它会同时检查 Web 服务器和数据库连接：
+
+```bash
+kubectl -n ansibleforms get pods -w
+helm test ansibleforms --namespace ansibleforms --logs
+```
+
+在 AnsibleForms 中，**帮助 → 关于** 显示正在运行的版本，**设置 → 状态** 显示
+数据库、schema 以及 AnsibleForms 所依赖的其他系统的健康状况。
+
+---
+
+## 回滚
+
+Helm 会保留 release 的历史记录。要回到上一个修订版本：
+
+```bash
+helm history ansibleforms --namespace ansibleforms
+helm rollback ansibleforms --namespace ansibleforms
+```
+
+如果它无法在升级后的数据库上启动，请恢复您的备份（参见 chart 的 [README](https://github.com/ansibleforms/helm-charts/tree/main/charts/ansibleforms)）。
diff --git a/i18n/zh/_integrate/api/authentication.md b/i18n/zh/_integrate/api/authentication.md
new file mode 100644
index 0000000..f9c6966
--- /dev/null
+++ b/i18n/zh/_integrate/api/authentication.md
@@ -0,0 +1,134 @@
+---
+layout: default
+title: 身份验证
+parent: REST API
+nav_order: 1
+translated_from: 58596f571c415f814cc79306f4f882b3078e962e
+---
+
+# 身份验证
+{: .no_toc }
+
+登录、刷新令牌或使用长期令牌
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+每次调用都需要在 `Authorization` 头中携带访问令牌。令牌通过登录获得，并通过
+刷新令牌保持有效。
+
+---
+
+## 登录
+
+使用基本认证，以用户名和密码登录：
+
+```bash
+curl -X POST https://af.example.com/api/v2/auth/login -u admin:<password>
+```
+
+响应包含两个令牌，即访问令牌和刷新令牌：
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## 调用 API
+
+每次调用时都把访问令牌作为 bearer 令牌发送：
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+---
+
+## 刷新令牌
+
+访问令牌会过期（`ACCESS_TOKEN_EXPIRATION`，默认 30 分钟）。使用刷新令牌获取新的访问令牌，
+无需密码：
+
+```bash
+curl -X POST https://af.example.com/api/v2/token \
+  -H "Content-Type: application/json" -d '{ "refreshtoken": "<refreshtoken>" }'
+```
+
+响应包含一对新的令牌，结构与登录时相同。刷新令牌只能使用一次：请保留新的刷新令牌以备下次刷新。
+
+```json
+{ "token": "eyJ...", "refreshtoken": "eyJ..." }
+```
+
+---
+
+## 长期令牌
+
+无人值守运行的脚本可以使用有效期更长的令牌。从 7.3.0 起，这需要 `allowApiTokens` 角色选项：
+
+* 在 [个人资料 > API 令牌](../profile/api-token.html) 下创建一个。
+* 或者在登录时带上 `expiryDays` 查询参数，获得有效期为指定天数的令牌：
+
+```bash
+curl -X POST "https://af.example.com/api/v2/auth/login?expiryDays=90" -u automation:<password>
+```
+
+`expiryDays` 只从 URL 中读取，从不从请求体中读取。对于角色中没有 `allowApiTokens` 的用户，它会被忽略，
+登录返回的令牌使用通常的有效期。`expiryDays=never` 还需要 `extendedTokenExpiration`。添加 `name`
+查询参数（`?expiryDays=90&name=nightly-backup`）可以为令牌命名，该名称会显示在用户的令牌列表中。
+
+长期令牌最多有效 [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) 天，默认
+90 天：更长的 `expiryDays` 会被截断为该值，除非它是 `never`。刷新长期令牌会返回普通令牌，因此在其过期后请重新登录。
+
+### 已登录用户的令牌
+
+个人资料中的 **API 令牌** 视图使用以下端点，它们不需要密码，因此适用于任何账户，包括 SSO 账户：
+
+| 调用 | 作用 |
+|---|---|
+| `GET /api/v2/profile/tokens` | 列出您的 API 令牌，包括其 `sid`、`name`、创建时间、过期时间和最后使用时间 |
+| `POST /api/v2/profile/tokens` | 从您的会话生成一个令牌；请求体包含 `expiryDays`（数字或 `never`）以及可选的 `name` |
+| `DELETE /api/v2/profile/tokens/{sid}` | 撤销您的某个令牌 |
+
+当使用 API 令牌调用时（令牌不能生成另一个令牌）、没有 `allowApiTokens` 时，或者会话登录已超过 10 分钟时
+（代码 `sign_in_again`），`POST` 会返回 `403`：请先重新登录。有效期超过最大值时返回 `400`。
+
+---
+
+## 令牌提前失效的情况
+
+无论是否为长期令牌，发生以下情况之一时，令牌都会在过期前停止工作：
+
+* **其会话注销**：使用该令牌调用 `POST /api/v2/auth/logout` 会使该次登录的令牌失效，且只影响这些令牌。
+  在浏览器中注销不会使脚本的令牌失效。
+* **修改密码**：用户修改了自己的密码，或管理员为其设置了密码。此前签发的所有令牌都会被拒绝。
+* **用户被删除或被封锁**：删除本地用户或封锁用户会使其所有令牌失效。管理员也可以
+  结束 LDAP 或 SSO 用户的会话。
+
+被拒绝的令牌返回 `401`。请重新登录，如果密码已修改，请使用新密码。
+
+---
+
+## 每次运行都登录的脚本
+
+登录和令牌端点受到防洪泛和防密码猜测的保护，因此每次运行都登录的脚本
+应了解以下限制：
+
+| 限制 | 默认值 | 后果 |
+|---|---|---|
+| [`AUTH_RATE_LIMIT`](../customization/security.html#env_AUTH_RATE_LIMIT) | 每个地址每分钟 120 次请求 | 登录、注销、刷新、SSO 端点、`PUT /api/v2/profile`（修改密码）以及 `POST` 或 `DELETE /api/v2/profile/tokens` 返回 `429` |
+| [`LOGIN_MAX_FAILURES`](../customization/security.html#env_LOGIN_MAX_FAILURES) | 连续 5 次登录失败 | 账户被锁定 [`LOGIN_LOCKOUT_MINUTES`](../customization/security.html#env_LOGIN_LOCKOUT_MINUTES)（15）分钟，所有登录都返回 `429` |
+| [`LOGIN_MAX_FAILURES_PER_IP`](../customization/security.html#env_LOGIN_MAX_FAILURES_PER_IP) | 来自同一地址的 30 次登录失败 | 在时间窗口结束前，来自该地址的所有登录都返回 `429` |
+
+`429` 带有 `Retry-After` 头，其中是需要等待的秒数：请停下来等待，不要立即重试。被锁定的账户
+在锁定结束前连正确的密码也会拒绝，因此一个使用错误密码的脚本会让该用户对所有人都处于锁定状态。
+修改密码（`PUT /api/v2/profile`）时输错当前密码也算一次登录失败，被锁定的账户
+无法修改密码。成功登录会清除该账户的计数，管理员设置密码也会清除。
+
+为避开这些限制，请登录一次并重复使用令牌，或使用长期令牌，而不要每次调用都
+登录。在反向代理后面时，请设置 [`TRUST_PROXY`](../customization/server.html#env_TRUST_PROXY)，以便服务器看到
+客户端的地址，否则所有客户端都会被算作同一个。
diff --git a/i18n/zh/_integrate/api/events.md b/i18n/zh/_integrate/api/events.md
new file mode 100644
index 0000000..ce9efeb
--- /dev/null
+++ b/i18n/zh/_integrate/api/events.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: 实时事件
+parent: REST API
+nav_order: 4
+translated_from: 2dcfc48df93271c0e13e05c67682a3b02e6e7e97
+---
+
+# 实时事件
+{: .no_toc }
+
+在作业和设置发生变化时收到通知，而不必轮询
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+服务器会在变化发生时告诉其客户端发生了什么变化。脚本也可以监听，而不必每隔几秒读取一次作业。
+
+---
+
+## 事件流
+
+`GET /api/v2/events` 是一个保持打开的 [服务器发送事件](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)
+流。任何已登录的用户都可以用通常的 bearer 令牌打开它：
+
+```bash
+curl -N https://af.example.com/api/v2/events -H "Authorization: Bearer <token>"
+```
+
+当有内容发生变化时，它会发送一个 `changed` 事件，其中包含变化内容的名称：
+
+```text
+event: changed
+data: {"name":"jobs"}
+```
+
+---
+
+## 事件名称
+
+事件只携带名称，从不携带数据，因此不会泄露用户无权查看的任何内容。会发送以下名称：
+
+| 名称 | 变化内容 |
+|---|---|
+| `jobs` | 作业：被启动、其状态或输出变化、被删除 |
+| `appearance` | 页眉显示的设置：主题、名称、公告、环境变量 |
+| `designer` | 设计器的锁被获取或释放 |
+| `runners` | 运行器（从 7.3.0 起）：RTE 连接或断开、请求加入、被批准或拒绝，或者改变了其模式或设置 |
+
+收到某个名称后，请通过常规 API 以您自己的权限重新读取您显示的内容（例如 `GET /api/v2/job/42`）。
+频繁变化的名称每秒最多发送一次。
+
+---
+
+## 保持连接
+
+该事件流设计为能穿过代理和负载均衡器，客户端会自行重新连接：
+
+* 连接时，服务器会发送一个 `hello` 事件，并要求客户端在重新连接前等待 3 秒。
+* 每 15 秒它会发送一行注释（`: ping`），以免空闲连接被关闭。请忽略以 `:` 开头的行。
+* 来自每个应用节点的事件都会到达每个事件流，无论客户端连接的是哪个节点。
+* 重新连接后，请重新读取您显示的内容：事件流中断期间发送的事件不会重发。
+
+---
+
+## 健康检查和指标
+
+存活和就绪探针（`/api/v2/live`、`/api/v2/ready`）以及 Prometheus 指标（`/api/v2/metrics`）
+面向监控工具，而不是以用户身份执行操作的脚本。参见 [监控](../production/monitoring.html)。
diff --git a/i18n/zh/_integrate/api/index.md b/i18n/zh/_integrate/api/index.md
new file mode 100644
index 0000000..ef01dbc
--- /dev/null
+++ b/i18n/zh/_integrate/api/index.md
@@ -0,0 +1,50 @@
+---
+layout: default
+title: REST API
+nav_order: 3
+has_children: true
+has_toc: false
+permalink: /api/
+translated_from: e14092fbd301073c7ed9be6839530efae43d4c6b
+---
+
+# REST API
+{: .no_toc }
+
+通过脚本启动表单和管理 AnsibleForms
+{: .fs-6 .fw-300 }
+
+---
+
+面向开发人员和自动化工程师：通过脚本启动表单和管理 AnsibleForms。
+
+Web 界面所做的一切都经过 REST API，因此脚本和其他工具也可以做同样的事。
+
+---
+
+## 概述
+
+API 由 AnsibleForms 服务器在 `/api/v2` 下提供：
+
+* **完整参考**：这些页面介绍脚本最常用的内容。所有端点都在服务器内置的
+  Swagger 页面 `https://<your server>/api/v2/docs` 上有说明，并可直接试用。
+* **权限**：调用以其令牌所属用户的身份运行，使用该用户的角色，与浏览器中相同。
+* **运行验证**：通过 API 启动的作业可以像浏览器中的启动一样接受检查
+  （参见 [运行验证](../launch-validation/)）。
+* **速率限制**：只有登录、注销、令牌刷新和单点登录端点、修改密码
+  （`PUT /api/v2/profile`）以及 API 令牌端点（`POST` 和 `DELETE /api/v2/profile/tokens`）受到限制（参见
+  [身份验证](authentication.html)）。其他调用没有速率限制（[聊天助手](../chat/) 有其自身的
+  限制），因此脚本应自行控制节奏，例如在跟踪作业时。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [身份验证](authentication.html) | 登录、刷新令牌或使用长期令牌 |
+| [作业](jobs.html) | 启动表单、跟踪作业、中止、重新运行或批准作业 |
+| [响应和错误](responses.html) | 响应的结构以及状态码 |
+| [实时事件](events.html) | 在作业和设置发生变化时收到通知，而不必轮询 |
diff --git a/i18n/zh/_integrate/api/jobs.md b/i18n/zh/_integrate/api/jobs.md
new file mode 100644
index 0000000..db9bb1f
--- /dev/null
+++ b/i18n/zh/_integrate/api/jobs.md
@@ -0,0 +1,165 @@
+---
+layout: default
+title: 作业
+parent: REST API
+nav_order: 2
+translated_from: ceba9eb4f9c2acb23646bd60c48cc579fe8ce202
+---
+
+# 作业
+{: .no_toc }
+
+启动表单、跟踪作业、中止、重新运行或批准作业
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+作业是表单的一次运行。用表单的名称和值启动它，然后通过其 ID 跟踪它。
+
+---
+
+## 启动表单
+
+把表单名称及其值发送到 `POST /api/v2/job`：
+
+```bash
+curl -X POST https://af.example.com/api/v2/job \
+  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
+  -d '{
+        "formName": "Create Virtual Machine",
+        "extravars": { "vm_name": "test-vm", "datacenter": "dc1" },
+        "rawFormData": { "vm_name": "test-vm", "datacenter": "dc1" }
+      }'
+```
+
+请求接受以下属性：
+
+| 属性 | 含义 |
+|---|---|
+| `formName` | 要启动的表单名称。必填。 |
+| `extravars` | 作业的额外变量。也接受 `payload` 作为它的别名。 |
+| `rawFormData` | 表单字段的值，与浏览器中保存的一致。[运行验证](../launch-validation/) 会检查这些值，并据此构建 extravars。 |
+| `credentials` | 按名称传给作业的凭据。 |
+| `files` | 表单文件字段的上传内容（参见 [文件上传](../launch-validation/file-uploads.html)）。 |
+
+响应包含新作业的 ID：
+
+```json
+{ "id": 42 }
+```
+
+要以详细模式运行作业，请在 extravars 中添加 `"__verbose__": true`。这需要 `allowVerboseMode` 角色选项，
+否则启动会返回 `403`。
+
+---
+
+## 上传文件
+
+带有文件字段的表单需要先上传文件。将文件作为 multipart 部分 `file` 发送到 `POST /api/v2/job/upload`：
+
+```bash
+curl -X POST https://af.example.com/api/v2/job/upload \
+  -H "Authorization: Bearer <token>" -F "file=@firmware.bin"
+```
+
+响应描述了已存储的上传内容：
+
+```json
+{ "fieldname": "file", "originalname": "firmware.bin", "encoding": "7bit", "mimetype": "application/octet-stream",
+  "destination": "<UPLOAD_PATH>", "filename": "3f9c...", "path": "<UPLOAD_PATH>/3f9c...", "size": 1048576 }
+```
+
+在启动的 `files` 中，以文件字段的名称原样传入它：`"files": { "firmware": { ... } }`。服务器
+会对照自己磁盘上的文件进行检查（参见 [文件上传](../launch-validation/file-uploads.html)）。
+
+---
+
+## 跟踪作业
+
+通过 ID 读取作业：
+
+```bash
+curl https://af.example.com/api/v2/job/42 -H "Authorization: Bearer <token>"
+```
+
+作业包含其 `status`、`extravars`（也以 `payload` 提供，是同一个对象）、`subjobs` 和 `output`。
+输出是带有作业页面颜色的 HTML；添加 `?text=true` 可获得纯文本，适合脚本或日志：
+
+```bash
+curl "https://af.example.com/api/v2/job/42?text=true" -H "Authorization: Bearer <token>"
+```
+
+作业运行时其 `status` 为 `running`，等待批准时为 `approve`。作业以下列状态之一结束：
+
+| 状态 | 含义 |
+|---|---|
+| `success` | 作业已完成，没有错误 |
+| `failed` | 作业失败 |
+| `warning` | 多步骤作业已完成，但途中某个设置了 `continue` 的步骤失败 |
+| `aborted` | 作业已被中止 |
+| `rejected` | 批准被拒绝，因此等待批准的内容没有运行 |
+| `abandoned` | 跟踪该作业的进程停止了（重启、容器被替换），作业被放弃 |
+
+被放弃时正在运行器上运行的作业，如果该运行器最终完成了它，仍可能以其实际结果结束。
+
+---
+
+## 查找作业
+
+`GET /api/v2/job` 列出作业，最新的在前，格式为 `{ "count": ..., "records": [ ... ] }`。以下查询参数可以缩小范围：
+
+| 参数 | 含义 |
+|---|---|
+| `records` | 最多返回多少个作业。默认为 [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE)（1000），最多为 5000，除非 `JOBS_LIST_SIZE` 更高。 |
+| `user`, `user_type` | 只返回该用户的作业。省略 `user_type` 时为 `local`（其他类型为 `ldap`、`azuread`、`oidc`）。 |
+| `runner` | 只返回在该运行器上运行的作业 |
+
+```bash
+curl "https://af.example.com/api/v2/job?records=20&user=automation" -H "Authorization: Bearer <token>"
+```
+
+用户可以看到自己的作业，以及等待其某个角色可给予的批准的作业。管理员，或带有
+`showAllJobLogs` 或 `manageAllJobs` 选项的角色，可以看到所有作业。每条记录包含作业的摘要（`id`、`form`、`status`、`start`、`end`、`user`、`runner` 等）；
+要获取 extravars 和输出，请读取作业本身。
+
+`GET /api/v2/job/approvals` 返回一个数字：有多少个作业在等待该用户可给予的批准。
+
+---
+
+## 关于作业的更多信息
+
+以下端点读取某个作业的更多内容：
+
+| 调用 | 返回内容 |
+|---|---|
+| `GET /api/v2/job/{id}/rawformdata` | 启动作业时的字段值，与表单中保存的一致。适用与重新运行相同的权限：您自己的作业（管理员或带有 `manageAllJobs` 的角色则为所有作业）、允许重新运行的表单，以及 `allowJobRelaunch` 角色选项。 |
+| `GET /api/v2/job/{id}/events` | playbook 作业的结构化事件（从 7.3.0 起，适用于在 7.3.0 或更高版本 RTE 上运行的 playbook）：每个 play、任务、主机结果和汇总，带有其 `order`、`type`、`play`、`task`、`host`、`duration` 和 `time` |
+| `GET /api/v2/job/{id}/events/{order}` | 其中一个事件及其完整的 `result`，与 **任务结果** 对话框中显示的一致；`order` 不是整数时返回 `400`，作业没有该事件时返回 `404` |
+| `GET /api/v2/job/{id}/node/{nodeId}` | 工作流作业的一个节点：`{ "node", "job", "extravars", "artifacts" }`，其中 `job` 是该节点自身作业的 ID，节点未运行时为 `null`。 |
+
+---
+
+## 其他操作
+
+以下端点对已有的作业执行操作：
+
+| 调用 | 操作 |
+|---|---|
+| `POST /api/v2/job/{id}/abort` | 中止正在运行的作业 |
+| `POST /api/v2/job/{id}/relaunch` | 重新运行作业，按原样或带修改（参见 [重新运行](../launch-validation/relaunching.html)） |
+| `POST /api/v2/job/{id}/approve` | 批准等待批准的作业；您自己的作业会返回 `403`，除非其批准设置了 `allowSelf: true` 或您是管理员 |
+| `POST /api/v2/job/{id}/reject` | 拒绝等待批准的作业 |
+| `GET /api/v2/job/{id}/download` | 下载作业的输出 |
+| `DELETE /api/v2/job/{id}` | 删除作业 |
+
+中止、批准、拒绝和删除会返回一条消息，重新运行还会返回新作业的 ID：
+
+```json
+{ "message": "Job has been relaunched with job id 43", "id": 43 }
+```
+
+在重新运行时添加 `?verbose=true` 可让新作业以详细模式运行，这需要 `allowVerboseMode` 角色选项。如果作业
+处于不适合该操作的状态，例如中止一个已经结束的作业，会返回 `409`。
diff --git a/i18n/zh/_integrate/api/responses.md b/i18n/zh/_integrate/api/responses.md
new file mode 100644
index 0000000..ad63998
--- /dev/null
+++ b/i18n/zh/_integrate/api/responses.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: 响应和错误
+parent: REST API
+nav_order: 3
+translated_from: 2687f844abe74f8c0e76c8685a1bd57151edc933
+---
+
+# 响应和错误
+{: .no_toc }
+
+响应的结构以及状态码
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+响应是普通的 JSON，HTTP 状态码表明调用是否成功。
+
+---
+
+## 响应
+
+成功的调用返回对象本身，或者一个带有其大小的列表：
+
+```json
+{ "count": 2, "records": [ { "id": 41 }, { "id": 42 } ] }
+```
+
+错误会返回一条消息，如有详细信息也会一并返回：
+
+```json
+{ "error": "The form data is not valid", "details": [ ... ] }
+```
+
+---
+
+## 状态码
+
+状态码说明出了什么问题：
+
+| 代码 | 含义 |
+|---|---|
+| `200` | 调用成功 |
+| `400` | 请求格式错误，例如刷新令牌时没有刷新令牌，或上传时没有文件 |
+| `401` | 令牌缺失、错误或已过期：请登录或刷新令牌 |
+| `403` | 用户的角色不允许该调用（包括批准您自己的作业，除非其批准设置了 `allowSelf: true` 或您是管理员），或者该账户必须先做某件事（见下文） |
+| `404` | 对象不存在 |
+| `409` | 请求不完整（没有数据的启动），或者对象所处的状态不允许该操作 |
+| `422` | [运行验证](../launch-validation/) 拒绝了表单的值；`details` 列出了原因 |
+| `429` | 对登录和令牌端点的请求过多，或登录失败次数过多（参见 [身份验证](authentication.html)） |
+| `500` | 服务器出错；服务器日志中有原因 |
+
+对于作业，`409` 表示它处于不适合该操作的状态：中止一个没有在运行的作业（或已请求过中止的作业）、
+重新运行一个仍在运行的作业，或者批准或拒绝一个已不再等待批准的作业。
+
+---
+
+## 带代码的 403
+
+有些 `403` 响应带有 `code`，表示用户必须先在浏览器中完成某件事，其他调用才能正常工作：
+
+```json
+{ "error": "...", "code": "password_change_required" }
+```
+
+| 代码 | 怎么做 |
+|---|---|
+| `password_change_required` | 用户使用公开的默认密码登录：请先在个人资料中修改密码 |
+| `disclaimer_required` | 免责声明已开启，而用户尚未接受其当前版本：请在浏览器中接受它 |
+
+长期 API 令牌（参见 [身份验证](authentication.html#long-lived-tokens)）从不会被免责声明拦住。
diff --git a/i18n/zh/_integrate/chat/index.md b/i18n/zh/_integrate/chat/index.md
new file mode 100644
index 0000000..82d585b
--- /dev/null
+++ b/i18n/zh/_integrate/chat/index.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: 聊天助手
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /chat/
+translated_from: 7c15de43a5f69fd80751b38b0fd379f282ffd84c
+---
+
+# 聊天助手
+{: .no_toc }
+
+通过对话填写和启动表单
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向开启它的管理员以及与它对话的用户：通过对话填写和启动表单。
+
+每个页面上都有一个聊天按钮，点击后会打开一个
+助手，它会找到合适的表单、询问缺少的信息、把表单本身的
+选项以按钮形式提供，并显示一份带有 **运行** 按钮的摘要。只有用户点击该按钮时，作业才会启动。
+
+---
+
+## 工作原理
+
+助手通过服务器与 AI 模型通信，服务器使用与浏览器相同的表单引擎来响应模型的请求：
+
+```text
+the user types           -> AnsibleForms server -> the AI model (Anthropic, OpenAI, ...)
+                                   |                  asks for a tool
+                                   v
+                         catalog | resolve | relaunch preview | job status
+                                   |   the same form engine as the browser and the MCP server,
+                                   |   as the logged-in user, with their roles
+                                   v
+the page shows the reply, the choices, and a summary card with a Launch button
+the user clicks Launch   -> AnsibleForms resolves the form again and launches exactly that payload, once
+```
+
+- **模型调用来自服务器**，从不来自浏览器，因此 API 密钥始终留在服务器上
+  （参见 [提供方](providers.html)）。
+- **模型无法启动任何东西。** 它准备一份一次性摘要；点击运行时会在执行前重新检查它。
+- **目标由用户选择。** 选项和必填的名称都来自用户，从不来自模型。
+- **输入“是”或“运行”不会有任何作用。** 只有按钮才能启动作业。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [开启助手](switching-it-on.html) | 启用助手，并在其中提供表单 |
+| [提供方](providers.html) | 助手背后的语言模型，以及代理 |
+| [隐私和限制](privacy-and-limits.html) | 哪些内容会离开网络，以及每个用户的限制 |
+| [重新运行和审计](relaunching-and-audit.html) | 从聊天中重新运行、审计记录以及局限 |
diff --git a/i18n/zh/_integrate/chat/privacy-and-limits.md b/i18n/zh/_integrate/chat/privacy-and-limits.md
new file mode 100644
index 0000000..37808ff
--- /dev/null
+++ b/i18n/zh/_integrate/chat/privacy-and-limits.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: 隐私和限制
+parent: 聊天助手
+nav_order: 3
+translated_from: d29279a71f7aaa5553602f5a463132c842600690
+---
+
+# 隐私和限制
+{: .no_toc }
+
+哪些内容会离开网络，以及每个用户的限制
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 哪些内容会离开网络
+
+对于参与的表单，以下内容会发送给提供方：
+
+- 表单名称和描述、字段标签、帮助文本、选项以及正在填写的
+  值；
+- 对话内容。
+
+以下内容从不会发送给提供方、页面或日志：
+
+- 密码（由用户在浏览器中输入）、已存储的凭据和 API 密钥；
+- 作业的输出及其存储的 extravars（助手只读取作业的状态，而且只有
+  在设置中开启了 **让助手跟踪它的作业** 时才会读取）。
+
+任何位于看起来像密钥的键（`password`、`secret`、`token`、`api_key` 等）下的内容，
+都会在模型或页面看到之前被遮盖。
+
+要让表单数据留在内部，请使用您自己的租户（Azure OpenAI）或本地模型（Ollama），而不是公共 API。
+
+---
+
+## 限制
+
+以下限制在设置页面上设置：
+
+- **每次对话的消息数**（20）：达到后用户必须开始新的对话。
+- **每条消息的工具轮次**（6）：模型在回答之前最多可以调用工具的次数。
+- **超时**（60 秒）：每次调用提供方的超时时间。
+
+以下限制是固定的：每个对话同一时间只处理一条消息，每条消息最多 4000 个字符，每个用户每小时
+60 条消息，每个用户 5 个对话。对话在 2 小时内没有消息后会被丢弃。
+
+带有 **运行** 按钮的摘要卡片只能使用一次，并在 15 分钟后过期：之后点击运行会提示
+摘要已过期，用户需要让助手重新生成一份。对话和摘要保存在内存中，因此
+重启后用户必须开始新的对话。
diff --git a/i18n/zh/_integrate/chat/providers.md b/i18n/zh/_integrate/chat/providers.md
new file mode 100644
index 0000000..2ea0200
--- /dev/null
+++ b/i18n/zh/_integrate/chat/providers.md
@@ -0,0 +1,83 @@
+---
+layout: default
+title: 提供方
+parent: 聊天助手
+nav_order: 2
+translated_from: 234d1d2e9b7ceec20856b33357e93df7c0777c52
+---
+
+# 提供方
+{: .no_toc }
+
+助手背后的语言模型，以及代理
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+在设置页面上选择提供方。这会填入基础 URL、身份验证方式和
+API 版本，它们都可以继续编辑。留空的字段使用提供方的默认值。
+
+| 提供方 | 协议 | 基础 URL（默认） | 密钥发送方式 |
+|---|---|---|---|
+| **Anthropic** | Anthropic | `https://api.anthropic.com` | `x-api-key` |
+| **OpenAI** | OpenAI | `https://api.openai.com/v1` | `Authorization: Bearer` |
+| **Azure OpenAI** | OpenAI | 必填：`https://<resource>.openai.azure.com/openai/deployments/<deployment>` | `api-key`，API 版本 `2024-10-21` |
+| **Google Gemini** | OpenAI | `https://generativelanguage.googleapis.com/v1beta/openai` | Bearer |
+| **xAI Grok** | OpenAI | `https://api.x.ai/v1` | Bearer |
+| **Mistral** | OpenAI | `https://api.mistral.ai/v1` | Bearer |
+| **DeepSeek** | OpenAI | `https://api.deepseek.com/v1` | Bearer |
+| **Groq** | OpenAI | `https://api.groq.com/openai/v1` | Bearer |
+| **OpenRouter** | OpenAI | `https://openrouter.ai/api/v1` | Bearer |
+| **Ollama** | OpenAI | `http://localhost:11434/v1` | 无 |
+| **其他兼容 OpenAI 的服务**（LiteLLM、网关、vLLM、LM Studio 等） | OpenAI | 必填，通常以 `/v1` 结尾 | Bearer |
+
+模型 ID 即提供方或代理所使用的 ID（`claude-opus-5-5`、`gpt-5`、`llama3.3`
+等）。助手需要支持 **工具调用** 的模型；小型本地模型对此的支持
+程度不一。
+
+对于不需要密钥的本地服务器和代理，只填基础 URL 即可；不会发送任何授权头。
+
+---
+
+## API 密钥
+
+密钥来自一个凭据，因此它像其他所有密钥一样存储和轮换：
+
+* 在 **设置 > 连接 > 凭据** 下创建一个 **api** 类型的凭据（参见 [凭据](../credentials.html)），
+  以密钥作为其密码。它也可以从 [密钥库](../secret-stores/) 读取密钥。
+* 在聊天设置的 **凭据** 字段中选择它。每条消息都会重新读取密钥，因此
+  修改后的密码会在下一条消息时生效。
+
+在凭据功能出现之前保存在设置页面上的密钥，在未选择凭据时仍然有效。
+[配置种子](../seed/) 直接以 `api_key` 设置密钥本身。
+
+---
+
+## 用于代理
+
+模型前面的代理或网关可能需要以下设置：
+
+- **身份验证**：密钥的发送方式：`Authorization: Bearer`、`api-key`、`x-api-key`，
+  或者不发送。留空则使用提供方的默认值。
+- **API 版本**：`anthropic-version` 头，对于兼容 OpenAI 的服务（Azure）则是 URL 中的 `?api-version=`。
+- **用户**：每次调用时作为 `user`（兼容 OpenAI）或 `metadata.user_id`
+  （Anthropic）发送。有些代理需要它。留空则不发送。
+- **忽略证书错误**：不安全；请改用 `NODE_EXTRA_CA_CERTS` 信任代理的 CA。
+- **附加请求头**：一个 JSON 对象，例如 `{"X-Org": "ops"}`。值为单行文本，最多 20 个；
+  密钥头和内容头不能被替换。
+
+---
+
+## 在容器中、位于代理之后
+
+聊天功能从 AnsibleForms 服务器容器发起普通的出站 HTTPS 连接。如果位于
+企业出口代理之后，请设置 `HTTPS_PROXY` **以及** `NODE_USE_ENV_PROXY=1`；缺少后者时，
+Node 内置的 HTTP 客户端会忽略 `HTTPS_PROXY`。如果提供方使用由
+内部 CA 签发的证书，则需要让 Node 信任该 CA（`NODE_EXTRA_CA_CERTS=/path/to/ca.pem`）。
+设置 `NODE_USE_ENV_PROXY=1` 后，位于网络内部的模型或代理必须列在
+`NO_PROXY` 中，否则调用会发往出口代理，而出口代理无法访问它。
+
+连接测试失败时会给出主机名和原因（DNS、连接被拒绝或证书不受信任）。
diff --git a/i18n/zh/_integrate/chat/relaunching-and-audit.md b/i18n/zh/_integrate/chat/relaunching-and-audit.md
new file mode 100644
index 0000000..386e4e4
--- /dev/null
+++ b/i18n/zh/_integrate/chat/relaunching-and-audit.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 重新运行和审计
+parent: 聊天助手
+nav_order: 4
+translated_from: b7d416fbf35e98de81e41ee53ba0d2ff9040fea0
+---
+
+# 重新运行和审计
+{: .no_toc }
+
+从聊天中重新运行、审计记录以及局限
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 重新运行
+
+像“再次运行作业 1234”这样的请求（用户必须输入作业 ID）会预览一次重新运行，
+其规则与 MCP 服务器的 `relaunch_job` 相同，包括
+[运行验证](../launch-validation) 的密码规则，并显示一份 **重新运行** 摘要；该按钮
+会启动它一次。“用服务器 web02 再次运行作业 1234”只会修改该字段。
+
+---
+
+## 审计
+
+每次从聊天中启动都会记录为 **chat.launch**，包括用户、作业、表单、
+提供方以及所批准摘要的 payload 哈希。对聊天设置的修改
+与其他任何设置修改一样被记录。
+
+---
+
+## 局限
+
+聊天助手目前还不能完成浏览器所做的所有事情：
+
+- **向导表单** 不能参与（对其设置 `enableForChat` 会被拒绝），
+  助手不填写的字段也不能参与：密码和文件上传。
+- 回复一次性完整到达；尚不支持流式输出。
+- 模型可能会误解请求。摘要卡片准确显示将要发送的内容；
+  请在点击 **运行** 之前检查它。
diff --git a/i18n/zh/_integrate/chat/switching-it-on.md b/i18n/zh/_integrate/chat/switching-it-on.md
new file mode 100644
index 0000000..1030ae7
--- /dev/null
+++ b/i18n/zh/_integrate/chat/switching-it-on.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: 开启助手
+parent: 聊天助手
+nav_order: 1
+translated_from: 9277301a5a83fdc57c5acd1ba4687f8b16497081
+---
+
+# 开启助手
+{: .no_toc }
+
+启用助手，并在其中提供表单
+{: .fs-6 .fw-300 }
+
+---
+
+助手需要同时满足以下四个条件：
+
+1. **`ENABLE_CHAT=1`**：环境变量。在设置页面上修改后立即生效，无需重启；
+   关闭时，聊天端点返回 `404`。参见 [`ENABLE_CHAT`](../customization/features.html#env_ENABLE_CHAT)。
+2. **模型提供方**：设置 -> 连接 -> **聊天助手**（在 Kubernetes 上也可使用 [配置种子](../seed)）。
+3. **参与的表单**：在每个表单上设置 `enableForChat: true`；助手会忽略其他所有表单。
+4. **可以使用它的用户**：角色选项 `allowChat`（默认：true）。在角色上设置
+   `allowChat: false` 可排除其成员。
+
+四个条件都满足后，用户就会看到聊天按钮。
diff --git a/i18n/zh/_integrate/mcp/index.md b/i18n/zh/_integrate/mcp/index.md
new file mode 100644
index 0000000..ec5962b
--- /dev/null
+++ b/i18n/zh/_integrate/mcp/index.md
@@ -0,0 +1,52 @@
+---
+layout: default
+title: MCP 服务器
+nav_order: 2
+has_children: true
+has_toc: false
+permalink: /mcp/
+translated_from: a5acf44b528914d81ce5c387c685d4fd41a0fdd6
+---
+
+# MCP 服务器
+{: .no_toc }
+
+让 AI 代理通过 Model Context Protocol 使用您的表单
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向管理员和集成人员：让 MCP 客户端以其所持令牌对应的用户身份列出、填写和启动表单。
+
+AnsibleForms 可以提供一个
+[Model Context Protocol](https://modelcontextprotocol.io) 服务器，使 MCP 客户端（例如
+聊天后端或 IDE 助手）能够列出用户可以使用的表单、确定其字段、
+启动作业并跟踪其进度。
+
+---
+
+## 它是什么，不是什么
+
+MCP 服务器是一个技术接口，通向浏览器所用的同一套表单流程。它
+**以所收到令牌对应的用户身份** 运行：与浏览器提交相同的表单角色、相同的作业可见性、
+相同的保留 extravars 检查。
+
+它没有添加任何自己的 AI 策略。代理在启动前是否必须请求确认、
+可以使用哪些表单、可以发出多少请求，都由 MCP 客户端决定。
+启动工具被标记为破坏性操作，因此行为规范的客户端会先请求确认，
+但服务器并不强制这一点。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 内容 |
+|---|---|
+| [设置](setup.html) | 开启服务器并对客户端进行身份验证 |
+| [工具](tools.html) | 代理用来填写、批准和重新运行表单的工具 |
+| [局限](limitations.html) | 在服务器上运行的表达式，以及 MCP 服务器不做的事情 |
diff --git a/i18n/zh/_integrate/mcp/limitations.md b/i18n/zh/_integrate/mcp/limitations.md
new file mode 100644
index 0000000..5dd8564
--- /dev/null
+++ b/i18n/zh/_integrate/mcp/limitations.md
@@ -0,0 +1,54 @@
+---
+layout: default
+title: 局限
+parent: MCP 服务器
+nav_order: 3
+translated_from: 619aa0f8cd31ac0038d76dd8e6f75a0a9dffe089
+---
+
+# 局限
+{: .no_toc }
+
+在服务器上运行的表达式，以及 MCP 服务器不做的事情
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## runLocal 表达式
+
+`runLocal` 表达式、`local` / `credential` / `html` 字段以及 `evalDefault` 默认值
+都在服务器上一个独立的 V8 上下文中求值：没有 `process`、`require`、网络和
+定时器，不能把字符串编译为代码，有 2 秒的时间限制，并且只有浏览器提供的那些辅助
+函数（`fnArray`、`fnGetNumberedName`、`fnToTable` 等）。
+
+这可以防范有缺陷或失控的表达式。它不是针对恶意代码的沙箱，
+也不需要是：代码来自表单定义，从不来自 MCP
+调用方，调用方发送的每个值都会作为 JavaScript 字面量代入。
+
+使用浏览器 API（`window`、`document`、`fetch`）的表达式无法在这里运行，
+会返回 `status: error`。
+
+服务器端表达式（不带 `runLocal`）与浏览器中一样，遵循相同的
+[`EXPRESSION_SANITIZER`](../customization) 规则。
+
+---
+
+## 局限
+
+有些表单和字段目前还不能通过 MCP 服务器使用：
+
+- **向导表单** 目前还不能启动。它们的步骤可以用 `subform` 解析。
+- **文件字段** 不能填写；文件字段有值的表单会被拒绝。
+- **列表行**（以及带有子表单的 `yaml` 字段，它就是这样的一行）：您发送的每一行，
+  除了带有列表 `deleteMarker` 的行，都会通过其子表单解析，以表单的值作为 `__parent__`，
+  然后进行验证。这也包括嵌套列表，其中
+  `__parent__.__parent__` 指向表单。请发送普通的行，即原始的子表单字段
+  值。验证失败的行按列表字段列在 `rowErrors` 中
+  （消息中为 `vms[1].disks[0].size (missing)`）。每次调用在所有层级中
+  最多接受 500 行。
+- 保留为 `__auto__` 的 enum 不会自动填入其第一个选项；调用方必须自行选择。
+- 每个 MCP 请求都会在审计日志中创建一条记录（操作“MCP 请求（AI 代理）”）；
+  作业本身与其他任何启动一样，记录在该用户名下。
diff --git a/i18n/zh/_integrate/mcp/setup.md b/i18n/zh/_integrate/mcp/setup.md
new file mode 100644
index 0000000..50658c1
--- /dev/null
+++ b/i18n/zh/_integrate/mcp/setup.md
@@ -0,0 +1,119 @@
+---
+layout: default
+title: 设置
+parent: MCP 服务器
+nav_order: 1
+translated_from: 700a4267f3326788b8c7e4dcd9ce0b2544b0b17f
+---
+
+# 设置
+{: .no_toc }
+
+开启服务器并对客户端进行身份验证
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 启用
+
+把 [`ENABLE_MCP`](../customization/features.html#env_ENABLE_MCP) 设为 `1`，或在 **设置 > 连接 > MCP** 下开启它
+（参见 [MCP 页面](#the-mcp-page)）。在设置页面上修改后，开关立即生效，无需重启。关闭时，
+该端点返回 `404`。端点为：
+
+```
+POST <your url>/api/v2/mcp
+```
+
+它使用无状态的 Streamable HTTP，响应为普通 JSON，因此 `GET` 和 `DELETE` 返回 405。
+
+---
+
+## 限制代理能做的事
+
+另外两个开关可以为所有客户端收窄 MCP 服务器的能力。与 `ENABLE_MCP` 一样，它们无需重启即可生效：
+
+| 变量 | 设为 `1` 时 |
+|---|---|
+| [`MCP_READ_ONLY`](../customization/features.html#env_MCP_READ_ONLY) | 服务器不提供任何启动、计划或修改类的工具（`launch_job`、`relaunch_job`、`plan_job`、`create_schedule`、`delete_schedule`、`store_job`、`delete_stored_job`），并拒绝它们。代理可以列出、读取和填写表单，读取调度和保存的作业，并跟踪作业，但不能启动或修改任何东西：这是试用代理的一种安全方式。 |
+| [`MCP_CHAT_FORMS_ONLY`](../customization/features.html#env_MCP_CHAT_FORMS_ONLY) | 代理只能看到设置了 `enableForChat: true` 的表单，与 [聊天助手](../chat/) 的列表相同。其他任何表单及其作业都会返回未找到。 |
+
+两者默认都是关闭的：代理可以看到用户角色允许的所有表单，并可以启动它们。
+
+---
+
+## MCP 页面
+
+**设置 > 连接 > MCP** 在两个选项卡中保存 MCP 服务器的设置。
+
+- **常规** 包含三个开关 `ENABLE_MCP`、`MCP_READ_ONLY` 和 `MCP_CHAT_FORMS_ONLY`，用 **保存** 保存。后两个
+  只能在 MCP 服务器开启时修改。
+- **客户端配置** 显示 **端点** 及一个复制按钮，并为 **Claude Code**
+  （`.mcp.json`，或 `claude mcp add` 命令）、**Cursor**（`~/.cursor/mcp.json`）、**VS Code**（`.vscode/mcp.json`，在服务器首次启动时
+  询问令牌）和 **Codex**（`~/.codex/config.toml`，令牌放在
+  `ANSIBLEFORMS_TOKEN` 环境变量中）提供现成的配置。每个配置都有复制按钮；请把 `<your-token>` 替换为您自己的令牌，
+  可通过 **创建令牌** 链接生成。
+
+如果设置了应用的 URL（**设置 > URL**），端点就根据它构建，否则根据浏览器的地址构建。
+
+---
+
+## 身份验证
+
+每个请求都需要一个 AnsibleForms 访问令牌：
+
+```
+Authorization: Bearer <token>
+```
+
+按通常的方式获取令牌（`POST /api/v2/auth/login`，或 OIDC / Entra ID 流程），并
+用 `POST /api/v2/token` 刷新它。这里特意 **没有登录工具**：作为工具参数传入的密码
+会进入语言模型的上下文及其聊天记录中。
+
+用户的角色还必须通过 `allowMcp` [角色选项](../config/roles.html) 允许使用 MCP 服务器。当用户的任何角色
+都没有设置它时，它跟随 `allowChat`，后者默认开启。被拒绝的用户在每个请求上都会收到 `403`。
+
+- **聊天后端** 自行为用户登录，保存刷新令牌，并在每次 MCP 调用时传递访问
+  令牌。
+- **IDE 客户端** 需要一个有效期足够长的令牌，以便只配置一次。如果角色
+  带有 `allowApiTokens` 选项，可在
+  [个人资料 > API 令牌](../profile/api-token.html) 下创建一个，或在登录 URL 上加上 `?expiryDays=<n>` 登录，
+  获得有效期为指定天数的令牌。
+
+用这样的令牌连接编码代理：
+
+<div class="af-tabs" data-tab-group="mcpclient">
+<div class="af-tab-list" role="tablist">
+<button type="button" role="tab" class="af-tab" data-tab="claude" aria-selected="true">Claude Code</button>
+<button type="button" role="tab" class="af-tab" data-tab="codex" aria-selected="false">Codex</button>
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="claude" markdown="1">
+
+添加服务器，并把令牌作为请求头：
+
+```bash
+claude mcp add --transport http ansibleforms https://af.example.com/api/v2/mcp \
+  --header "Authorization: Bearer <token>"
+```
+
+</div>
+<div class="af-tab-panel" role="tabpanel" data-tab="codex" markdown="1" hidden>
+
+把服务器添加到 `~/.codex/config.toml`，令牌从环境变量中读取：
+
+```toml
+[mcp_servers.ansibleforms]
+url = "https://af.example.com/api/v2/mcp"
+bearer_token_env_var = "ANSIBLEFORMS_TOKEN"
+```
+
+然后在启动 Codex 之前设置该变量：
+
+```bash
+export ANSIBLEFORMS_TOKEN=<token>
+```
+
+</div>
+</div>
diff --git a/i18n/zh/_integrate/mcp/tools.md b/i18n/zh/_integrate/mcp/tools.md
new file mode 100644
index 0000000..89fe9df
--- /dev/null
+++ b/i18n/zh/_integrate/mcp/tools.md
@@ -0,0 +1,171 @@
+---
+layout: default
+title: 工具
+parent: MCP 服务器
+nav_order: 2
+translated_from: a8c4d7ff425720a098c720cc1ade3629094bdb40
+---
+
+# 工具
+{: .no_toc }
+
+代理用来填写、批准和重新运行表单的工具
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+MCP 服务器最多提供 15 个工具。其中 6 个提供给每个用户；其余的取决于用户的角色选项，因此没有某个选项的用户
+根本不会看到对应的工具：
+
+| 工具 | 作用 | 提供条件 |
+|---|---|---|
+| `list_forms` | 用户可以使用的表单：名称、描述、类别，以及 `enableForChat`（聊天助手是否提供该表单）。 | 始终 |
+| `get_form` | 一个表单的完整定义。每个字段还带有 `dynamic`（由表达式或查询求值）和 `dependsOn`（它读取的字段）。 | 始终 |
+| `resolve_field` | 根据目前已填写的值对表单求值。见下文。 | 始终 |
+| `launch_job` | 用给定的值启动表单，与浏览器提交完全相同。返回作业 ID。 | 始终 |
+| `relaunch_job` | 修改部分字段后再次启动作业。见下文。 | 始终 |
+| `get_job` | 作业的状态和输出（`tail` 把输出限制为最后几行）。 | 始终 |
+| `plan_job` | 以该用户身份在稍后运行一次表单：即表单上 **稍后运行（一次性）** 所做的事。 | `allowPlannedJobs` |
+| `create_schedule` | 创建一个调度，周期性的（`cron`）或一次性的（`run_at`），与 **调度** 页面上相同。 | `allowScheduledJobs` |
+| `list_schedules` | 用户可以看到的调度：有 `allowScheduledJobs` 时为全部调度，否则为其计划的运行。 | `allowPlannedJobs` 或 `allowScheduledJobs` |
+| `get_schedule` | 一个调度，带有其额外变量（看起来像密钥的会被遮盖）以及其上次运行的输出。 | `allowPlannedJobs` 或 `allowScheduledJobs` |
+| `delete_schedule` | 取消一次计划的运行，或删除用户可以看到的调度。 | `allowPlannedJobs` 或 `allowScheduledJobs` |
+| `list_stored_jobs` | 用户可以看到的 [保存的作业](../jobs/stored-jobs.html)，不含其值。 | `allowStoredJobs` |
+| `get_stored_job` | 一个保存的作业及其值，按 `id` 查找，或在用户自己的作业中按 `form` 和 `name` 查找。 | `allowStoredJobs` |
+| `store_job` | 以某个名称保存表单的值，与表单上的 **保存** 相同。 | `allowStoredJobs` |
+| `delete_stored_job` | 删除用户可以看到的保存的作业。 | `allowStoredJobs` |
+
+`launch_job`、`relaunch_job` 和 `plan_job` 接受 `verbose: true` 以详细模式运行作业，这需要
+`allowVerboseMode` 角色选项。设置 [`MCP_READ_ONLY`](setup.html#limiting-what-agents-can-do) 后，启动、计划或
+修改类的工具（`launch_job`、`relaunch_job`、`plan_job`、`create_schedule`、`delete_schedule`、`store_job` 和 `delete_stored_job`）
+不会提供。
+
+没有用于运行任意表达式、查询、playbook 或 extravars 的工具。表达式
+和查询只会按表单定义的方式运行。
+
+[聊天助手](../chat) 也使用这些工具，只是用 **运行** 按钮代替了 `launch_job`。
+
+---
+
+## 填写表单
+
+用表单名称和目前已有的值调用 `resolve_field`，每得到一个回答后再调用一次。它按
+依赖顺序处理各字段，并为每个字段报告：
+
+- `status`：`resolved`、`waiting`（带有 `waitingFor`）、`hidden` 或 `error`（字段回退到其默认值）；
+- `value`、`default`，对于选择类字段还有 `options`（最多 `maxOptions` 个，默认 200）；
+- `needsInput`：没有值的必填字段，或仍为 `__auto__` 的选择；
+- `validationErrors`：该值违反的规则，格式为 `[{type, description}]`，带有浏览器的提示消息。
+
+对于整个表单，`missing` 和 `invalid` 列出仍需修正的内容；在 `complete` 为 true 之前，`launch_job` 会拒绝它。
+
+验证使用的是浏览器自己的代码，与 [运行验证](../launch-validation) 共享。隐藏字段不会
+被验证，空的可选字段是有效的。
+
+---
+
+## 调度和计划的运行
+
+`plan_job` 接受与 `launch_job` 相同的 `form`、`values` 和 `expectedPayloadHash`，以及运行的 `name` 和 `run_at`，后者是
+带有时区偏移或 `Z` 的 ISO 8601 时间（`2026-10-15T22:00:00+02:00`）；不带时区的时间会被拒绝。值会立即解析
+并验证，并在运行触发时再次检查，与浏览器中的 [计划的运行](../jobs/schedules.html#planned-runs) 相同。
+响应会给出 UTC 时间和应用时钟下的运行时间。
+
+`create_schedule` 接受 `form`、`name`、`cron`（五个字段，例如 `0 22 * * 1-5`）或 `run_at` 二者之一，以及作业获得的
+`extraVars`。这样的调度以 `Schedule Service` 身份运行，不经过表单的验证；要以该用户身份运行一次表单，
+请使用 `plan_job`。调度名称是唯一的。
+
+---
+
+## 保存的作业
+
+保存的作业是以某个名称保存的表单值；这些工具操作的是与浏览器中相同的保存的作业。
+
+`list_stored_jobs` 列出用户自己的保存的作业，对于拥有 `showSettings` 的用户则列出所有人的，包括其名称、描述、
+表单、创建时间和过期时间。标记为 `usable` 的作业（用户自己的、属于其可启动表单的）可以作为 `storedJob`
+（`{ "id": 7 }`，或在该表单中用户自己的作业里用 `{ "name": "..." }`）传给 `resolve_field`、`launch_job` 或 `plan_job`：其
+值作为起点，`values` 覆盖在其上。密码字段不会被保存，因此请在 `values` 中提供它们。
+从保存的作业执行 `launch_job` 和 `plan_job` 时，需要 `resolve_field` 为其返回的 `expectedPayloadHash`，并且
+`resolve_field` 会拒绝同时带有 `storedJob` 和 `subform` 的请求。
+
+`store_job` 接受 `form`、在该表单的用户保存的作业中唯一的 `name`、`values`，以及可选的
+`description` 和 `expires_at`（带有时区偏移或 `Z` 的 ISO 8601）。其响应会说明哪些密码字段被略去了。
+
+---
+
+## 传递值
+
+传入 `field` 可以只解析该字段及其依赖的内容。对于列表行或向导步骤，传入 `subform`（以及
+可选的 `parent`，即父表单的值）。
+
+按浏览器中保存的形式发送值。选择类字段也接受部分记录或其 `valueColumn` 值
+（`"vol1"`），为 `multiple` 时接受数组。计算字段会忽略发送的值，除非它们是 `editable`。
+
+---
+
+## 批准确切的 payload
+
+表单完整后，`resolve_field` 还会返回 `launch_job` 将要提交的内容：
+
+- `modeledExtravars`：应用 `model`、`valueColumn` 和 `output` 之后的 extravars，
+  密码字段已遮盖；
+- `credentials`：作业将使用的 AnsibleForms 凭据（名称，而不是密钥）；
+- `payloadHash`：表单名称、真实 extravars 和凭据的 SHA-256 哈希。
+
+把 `modeledExtravars` 展示给操作人员，并把他们批准的 `payloadHash` 作为
+`expectedPayloadHash` 传给 `launch_job`。启动时会再次解析表单，如果 payload 不同就会
+拒绝，例如因为某个查询现在的结果不同了。
+`ansibleforms_user`、`__jobid__` 和 `__verbose__` 在启动时添加，不计入哈希。
+
+`launch_job` 只检查 payload。对表单的修改如果没有改变 payload，就不会导致启动被拒绝。
+`resolve_field` 的每个响应还带有 `formFingerprint`，即表单定义的 SHA-256 哈希：如果要在
+表单有任何修改后拒绝启动，请在调用 `launch_job` 之前自行比较它，聊天助手的
+**运行** 按钮就是这样做的。
+
+---
+
+## 带修改的重新运行
+
+`relaunch_job` 接受作业 `id` 和 `values`：只包含要修改的字段，为原始值。
+`values` 覆盖在作业最初启动时的值之上，结果的解析和验证
+与 `launch_job` 完全相同，包括列表行，然后由您作为一个
+新作业启动（`ansibleforms_user` 是您，而不是原提交者）。原作业的
+文件上传会被复用。
+
+不带 `values` 时，它是一次 **按原样** 的重新运行：其存储的 extravars 在
+服务器上重放，包括密码（预览中会遮盖它们）。但如果表单的
+运行验证为 `enforce`，重新运行会经过与带修改的重新运行相同的检查。
+
+**密码从不与字段值一起存储**，因此当表单显示密码字段时（无论在顶层还是在列表行中），
+经过检查的重新运行会被拒绝（`unsupported`，带有 `passwordFields`）。被其依赖关系隐藏的密码字段
+不会阻止重新运行。参见 [运行验证](../launch-validation)。
+
+请先带 `preview: true` 调用它：它返回 `modeledExtravars`（密码已遮盖）、
+`credentials` 和 `payloadHash`，但不启动。与用户确认后，再带
+`expectedPayloadHash` 调用一次。适用与浏览器中重新运行相同的权限：
+表单必须允许重新运行，并且您的角色需要 `allowJobRelaunch` 选项。没有
+存储表单数据的作业（在重新运行功能出现之前启动的）和向导表单不能
+带修改重新运行。
+
+REST API 通过 `POST /api/v2/job/{id}/relaunch` 提供同样的功能，请求体为
+`{ "values": { ... } }`；不带请求体时，它按原样重放作业。
+
+---
+
+## 错误
+
+被拒绝的调用是一个工具错误，其结构化内容带有 `code` 和详细信息：
+
+| 代码 | 何时出现 |
+|---|---|
+| `form_incomplete` | 对不完整的表单执行 `launch_job` 或 `relaunch_job`，带有 `missing`、`invalid`、`waiting`、`validationErrors` 和 `rowErrors` |
+| `payload_mismatch` | payload 与 `expectedPayloadHash` 不同，带有两个哈希 |
+| `access_denied` | 用户的角色不授予该表单、作业、调度或保存的作业，或不授予详细模式，或服务器为只读 |
+| `not_found` | 没有这样的表单、子表单或作业 |
+| `unsupported` | 向导表单、单独的子表单、文件字段，或者需要显示的密码字段的 `relaunch_job` |
+| `no_form_data` | 对没有存储表单值的作业（例如由调度启动的作业）执行带修改的 `relaunch_job`；请改为不带修改地重新运行它 |
+| `invalid_request` | 服务器认为格式错误而拒绝的请求 |
+| `internal_error` | 其他任何情况 |
diff --git a/i18n/zh/_introduction/concepts.md b/i18n/zh/_introduction/concepts.md
new file mode 100644
index 0000000..b3926f5
--- /dev/null
+++ b/i18n/zh/_introduction/concepts.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: 概念
+nav_order: 4
+translated_from: d62ee1e491a725a384186e3909ae1f9cee654bde
+---
+
+# 概念
+{: .no_toc }
+
+本文档中使用的术语，每个都链接到其页面
+{: .fs-6 .fw-300 }
+
+---
+
+## 术语表
+
+本文档中使用的术语：
+
+| 术语 | 含义 |
+|---|---|
+| **[表单](forms/)** | 一个 YAML 定义，用于收集输入并运行 playbook、模板或工作流 |
+| **[表单字段](formfields/)** | 表单的一个输入项，例如 `text`、`enum` 或 `checkbox`；其值会成为一个 extravar |
+| **[类别](config/categories.html)** | 表单页面上表单树中的一个分组，在 `config.yaml` 中定义 |
+| **[角色](config/roles.html)** | 一组用户和组；表单列出可以查看和运行它的角色，`default` 表示所有人 |
+| **[表达式](expressions/)** | 计算字段值的 JavaScript，在浏览器中（`runLocal: true`）或在服务器上运行 |
+| **[Extravars](formfields/)** | 发送给 playbook 或模板的变量，由字段值构建 |
+| **[凭据](expressions/credentials.html)** | 一份已存储的登录信息，用 `ENCRYPTION_SECRET` 加密：用户名和密码（以及主机、端口、数据库），或者从 7.3.0 起，LDAP 目录、SSO 提供方、运行器或 HashiCorp Vault 的地址和密钥 |
+| **[密钥库](secret-stores/)** | 与 HashiCorp Vault 或 CyberArk 的连接，为凭据提供用户名和密码 |
+| **[作业](gui/forms-and-jobs.html)** | 表单的一次运行，带有其状态、extravars 和输出，保存在作业历史中 |
+| **[运行器](runners.html)** | 作业运行的地方，在 **连接 > 运行器** 下添加：`rte` 用于 playbook，`awx`（AWX，或其变体 `aap` 或 `ascender`）、`semaphore`、`rundeck` 或 `jenkins` 用于模板和作业。表单用 `runner:` 选择一个运行器，否则在默认的 `rte`（playbook）或 `awx`（模板）运行器上运行 |
+| **[RTE](rte/)** | 运行环境：以 `AF_ROLE=rte` 在自己的容器中启动的 AnsibleForms 服务器，与 python 和 ansible 一起，运行 `rte` 类型运行器的 playbook |
+| **[审批点](forms/approval.html)** | 作业中的一次暂停，直到拥有审批角色的用户批准或拒绝它 |
+| **[工作流](workflows/)** | 由 playbook、审批和其他工作流组成的图，按成功、失败或始终相连，采用 AWX 的语法 |
+| **[多步骤表单](forms/multistep.html)** | 自 7 起已弃用：按顺序运行多个 playbook 或模板的表单；由工作流取代 |
+| **[通知通道](notification-channels.html)** | 通知和审批请求的发送目标：邮件服务器、Slack 或 Teams webhook、Telegram 聊天或 webhook |
+| **[设计器](designer/)** | 用于编辑表单、playbook、清单和工作流的浏览器编辑器，同一时间只能一人使用 |
+| **[子表单](forms/subform.html)** | 一组可复用的字段，描述 `list` 字段的行或 `yaml` 字段的对象 |
+| **[config.yaml](config/)** | 包含类别、角色和常量的文件；表单存放在各自的文件中 |
+| **[配置种子](seed/)** | 一个 YAML 文件（`CONFIG_SEED_PATH`），用于声明运行器和凭据等管理对象 |
+| **[持久化文件夹](customization/paths.html)** | 存放 AnsibleForms 在重启和升级后必须保留的文件的文件夹 |
diff --git a/i18n/zh/_introduction/gui/administration.md b/i18n/zh/_introduction/gui/administration.md
new file mode 100644
index 0000000..0c9ab40
--- /dev/null
+++ b/i18n/zh/_introduction/gui/administration.md
@@ -0,0 +1,164 @@
+---
+layout: default
+title: 管理
+parent: 界面导览
+nav_order: 3
+redirect_from:
+  - /gui/settings.html
+  - /gui/ldap-configuration.html
+  - /gui/credential-manager.html
+  - /gui/backups.html
+  - /gui/restore.html
+  - /gui/server-log.html
+  - /gui/swagger-interface.html
+translated_from: 65b6b65919b22de7d7973732ebd29647e20f3184
+---
+
+# 管理
+{: .no_toc }
+
+设置菜单：系统、外观、访问、连接和日志
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 设置菜单
+
+页眉中的 **设置** 会打开管理页面，这些页面在左侧菜单中分组为 **系统**、**外观**、
+**访问**、**连接** 和 **日志**。每个条目只对拥有其页面所需角色选项的用户显示：
+**备份** 需要 `allowBackupOps`，**服务器日志** 需要 `showLogs`，其他所有页面需要 `showSettings`。
+从 7.3.0 起，有三个选项可以只打开其中一部分页面：
+
+| 角色选项 | 打开的页面 |
+|---|---|
+| `showAppearanceSettings` | **外观** 页面 |
+| `showConnectionsSettings` | **连接** 页面，**Syslog** 除外；仓库、密钥库和受保护的凭据仍只能由管理员修改 |
+| `showAuditLog` | **审计日志** |
+
+关于角色选项，参见 [角色](../config/roles.html#role-options)。
+
+---
+
+## 列表和记录页面
+
+从 7.3.0 起，设置中的列表和记录页面采用统一的布局，其控件位于标题下方单独的一行中：
+
+| 部分 | 工作方式 |
+|---|---|
+| 搜索框 | 在每个设置页面和记录页面上，它都位于该行的最前面。输入一个词会同时筛选所有选项卡：匹配的字段、行或行内容显示在各自选项卡的名称下 |
+| 每页条数 | 在选择每页条数之前，表格显示屏幕能容纳的行数：可选 10、20、50 或 100 |
+| 列 | 每个有名称的列都可以排序，空单元格显示 `–` |
+| 复选框 | 只有在勾选行后可以执行某些操作时，行才带有复选框，行菜单（⋮）也提供相同的操作 |
+| 行菜单 | 简短的标签，例如 **编辑** 和 **删除**。带有 **已启用** 列的列表会把它放在第一列，并在每个行菜单中根据情况提供 **启用** 或 **禁用** |
+
+带有 **已启用** 列的列表包括 SSO 提供方、LDAP 目录、运行器、调度、通知
+通道、syslog 服务器、公告、标签以及免责声明的版本。
+
+---
+
+## 系统
+
+实例本身：其设置、健康状况和备份。
+
+| 页面 | 用途 |
+|---|---|
+| **常规** | 环境变量，分布在从配置到日志的各个选项卡中。参见 [环境变量](../customization/)。 |
+| **状态** | 实例及其所依赖系统的健康状况，分为检查项和信息两个选项卡。参见 [监控](../production/monitoring.html)。 |
+| **备份** | 创建、还原和删除数据库、config.yaml 和表单的备份。参见 [备份](../production/backups.html)。 |
+
+![设置 > 常规，配置选项卡](../assets/screenshots/settings.jpg)
+
+### 备份
+
+备份列表，包括每晚备份和手动备份：**添加备份** 立即创建一个备份，行菜单中有 **查看备份**、**还原** 和 **删除**。
+
+![设置 > 备份](../assets/screenshots/backups.jpg)
+
+### 还原
+
+**还原** 会显示备份包含的内容，然后进行还原；**恢复前先创建新备份（推荐）** 默认处于勾选状态。
+
+![还原备份](../assets/screenshots/restore.jpg)
+
+---
+
+## 外观
+
+实例对所有人呈现的样子，以及它显示的消息。
+
+| 页面 | 用途 |
+|---|---|
+| **默认值** | 未自行选择的用户所使用的主题、语言、表单视图、时区和日期格式。参见 [默认值](../appearance/defaults.html)。 |
+| **名称** | 浏览器选项卡和登录页面上显示的名称。参见 [名称](../appearance/name.html)。 |
+| **徽标** | 页眉中您自己的徽标。参见 [徽标](../appearance/logo.html)。 |
+| **图标** | 浏览器选项卡中您自己的图标。参见 [图标](../appearance/icon.html)。 |
+| **链接** | 设计器链接，以及页眉中您自己的链接和菜单。参见 [链接](../appearance/links.html)。 |
+| **标签** | 徽标旁边的标签，例如 PRODUCTION 和 EU。参见 [标签](../appearance/labels.html)。 |
+| **公告** | 页眉下方的消息，每条从其开始时间显示到结束时间。参见 [公告](../announcements.html)。 |
+
+---
+
+## 访问
+
+谁可以登录，以及登录后可以做什么。
+
+| 页面 | 用途 |
+|---|---|
+| **免责声明** | 每个用户需接受一次的条款，以及谁接受了哪个版本。参见 [免责声明](../disclaimer.html)。 |
+| **用户** | 本地用户，以及 LDAP 和单点登录用户。参见 [用户和组](../users-and-groups.html)。 |
+| **组** | 本地组，以及 LDAP 和单点登录组。参见 [用户和组](../users-and-groups/local-group.html)。 |
+| **角色** | config.yaml 中的角色：谁拥有它们以及它们允许做什么。参见 [角色](../config/roles.html)。 |
+| **LDAP** | 使用 LDAP 目录或 Active Directory 登录。参见 [LDAP](../authentication/ldap.html)。 |
+| **SSO** | 使用 Entra ID 或 OpenID Connect 提供方进行单点登录。参见 [身份验证](../authentication/)。 |
+
+![访问 > LDAP，主目录](../assets/screenshots/ldap.jpg)
+
+---
+
+## 连接
+
+AnsibleForms 访问的系统，以及登录这些系统所用的凭据。
+
+| 页面 | 用途 |
+|---|---|
+| **仓库** | 表单和 playbook 所来自的 git 仓库。参见 [Git 仓库](../repositories/)。 |
+| **凭据** | 表单、playbook 和连接所使用的账户和密钥。参见 [凭据](../credentials.html)。 |
+| **密钥库** | 可以从中读取凭据的 HashiCorp Vault 和 CyberArk。参见 [密钥库](../secret-stores/)。 |
+| **运行器** | 作业运行的地方：用于 playbook 的 RTE 容器，以及用于模板的 AWX 等。参见 [运行器](../runners.html)。 |
+| **SSH** | 应用连接 git 时所用的密钥对，以及已知主机。参见 [SSH](../repositories/authentication.html#ssh-with-the-generated-key)。 |
+| **通知** | SMTP 服务器、Slack、Microsoft Teams、Telegram 和 webhook。参见 [通知通道](../notification-channels.html)。 |
+| **聊天助手** | 聊天助手的 AI 提供方。参见 [聊天助手](../chat/)。 |
+| **MCP** | 供 AI 代理使用的 MCP 服务器。参见 [MCP](../mcp/)。 |
+| **Syslog** | 接收服务器日志、审计日志或两者的 syslog 服务器。参见 [Syslog](../production/logs.html#syslog)。 |
+
+![连接 > 凭据，凭据的连接选项卡](../assets/screenshots/credentials.jpg)
+
+---
+
+## 日志
+
+实例上发生了什么。
+
+| 页面 | 用途 |
+|---|---|
+| **审计日志** | 谁修改了什么，以及是否被允许，可按用户、操作和结果筛选。参见 [审计记录](../production/logs.html#audit-trail)。 |
+| **服务器日志** | 服务器自身的日志，用于故障排查。参见 [日志](../production/logs.html)。 |
+
+### 服务器日志
+
+日志的最后几行，最新的在底部，并随写入实时跟踪。搜索框可以筛选它们（正则
+表达式），**清空** 清空的是视图而不是日志，**下载** 保存完整的日志。
+
+![日志 > 服务器日志](../assets/screenshots/logs.jpg)
+
+---
+
+## API 文档
+
+帮助菜单（页眉中的问号）中的 **API 文档** 链接到 REST API 的 Swagger UI，地址为 `/api/v2/docs`。
+参见 [API](../api/)。
+
+![Swagger 界面](../assets/screenshots/swagger.jpg)
diff --git a/i18n/zh/_introduction/gui/designer-and-git.md b/i18n/zh/_introduction/gui/designer-and-git.md
new file mode 100644
index 0000000..de5436a
--- /dev/null
+++ b/i18n/zh/_introduction/gui/designer-and-git.md
@@ -0,0 +1,45 @@
+---
+layout: default
+title: 设计器和 git
+parent: 界面导览
+nav_order: 2
+redirect_from:
+  - /gui/builtin-designer.html
+  - /gui/git-repositories.html
+  - /gui/git-repository-editor.html
+translated_from: cac87e4a1cca1fbbaa06fb153104a3964d578f25
+---
+
+# 设计器和 git
+{: .no_toc }
+
+编辑表单并将其保存在 git 中
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 内置设计器
+
+编辑表单、类别、常量、变量文件、playbook、清单和工作流，每种都可以用 YAML、字段（可视化）
+和预览方式编辑。[设计器](../designer/) 各页面介绍了每个部分。
+
+![内置设计器](../assets/screenshots/designer.jpg)
+
+---
+
+## Git 仓库
+
+与 Git 仓库集成，对您的表单和 playbook 进行版本控制。
+
+![Git 仓库](../assets/screenshots/git.jpg)
+
+---
+
+## Git 仓库编辑器
+
+编辑和配置 Git 仓库集成设置。
+
+![Git 仓库编辑器](../assets/screenshots/git-edit.jpg)
diff --git a/i18n/zh/_introduction/gui/forms-and-jobs.md b/i18n/zh/_introduction/gui/forms-and-jobs.md
new file mode 100644
index 0000000..af58c46
--- /dev/null
+++ b/i18n/zh/_introduction/gui/forms-and-jobs.md
@@ -0,0 +1,100 @@
+---
+layout: default
+title: 表单和作业
+parent: 界面导览
+nav_order: 1
+redirect_from:
+  - /gui/login.html
+  - /gui/the-dashboard.html
+  - /gui/a-form.html
+  - /gui/form-json-preview.html
+  - /gui/running-job.html
+  - /gui/job-output.html
+  - /gui/job-logs.html
+  - /gui/multi-step.html
+  - /gui/schedules.html
+translated_from: 951f0d014ee94f1c1c52883277a003d7eb67a6ec
+---
+
+# 表单和作业
+{: .no_toc }
+
+登录、仪表板、填写表单以及跟踪其作业
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 登录
+
+用户身份验证页面，支持本地、LDAP、Entra ID 和 OIDC 身份验证。
+
+![登录](../assets/screenshots/login.jpg)
+
+---
+
+## 仪表板
+
+主仪表板按类别显示所有可用的表单。
+
+![仪表板](../assets/screenshots/dashboard.jpg)
+
+---
+
+## 一个表单
+
+一个带有外部数据源和动态字段的表单示例。
+
+![表单示例](../assets/screenshots/form.jpg)
+
+---
+
+## 表单 JSON 预览
+
+在运行作业之前，预览传给 Ansible 的 JSON payload 和额外变量。
+
+![表单 JSON 预览](../assets/screenshots/form-json.jpg)
+
+---
+
+## 运行中的作业
+
+实时执行 Ansible playbook，并显示实时输出。
+
+![运行中的作业](../assets/screenshots/run.jpg)
+
+---
+
+## 作业输出
+
+已执行的 Ansible playbook 的完整输出。
+
+![作业输出](../assets/screenshots/job-output.jpg)
+
+---
+
+## 作业日志
+
+所有作业及其状态和时间，可从左侧菜单按状态筛选。
+
+![作业日志](../assets/screenshots/job-log.jpg)
+
+---
+
+## 多步骤
+
+一个多步骤作业，每个步骤的输出都位于主作业之下。多步骤表单自 7 起已弃用：
+改由 [工作流](../workflows/) 来串联 playbook、模板和审批。
+
+![多步骤表单](../assets/screenshots/multistep.jpg)
+
+---
+
+## 调度
+
+安排表单在特定时间或按特定间隔运行。[cron 示例](../faq.html#which-cron-expressions-can-i-use) 列出了常用的
+表达式，并说明了调度在哪个时区运行。
+
+![调度](../assets/screenshots/schedules.jpg)
diff --git a/i18n/zh/_introduction/gui/index.md b/i18n/zh/_introduction/gui/index.md
new file mode 100644
index 0000000..b758c70
--- /dev/null
+++ b/i18n/zh/_introduction/gui/index.md
@@ -0,0 +1,33 @@
+---
+layout: default
+title: 界面导览
+nav_order: 3
+has_children: true
+has_toc: false
+description: 图形用户界面的截图和导览
+permalink: /gui/
+translated_from: 6eb61d9a8319466a99b234e942d1ec6d005c4f7d
+---
+
+# 界面导览
+{: .no_toc }
+
+AnsibleForms Web 界面的图解导览，从仪表板到高级管理功能。
+{: .fs-6 .fw-300 }
+
+---
+
+面向所有用户和管理员：Web 界面的各个页面，按用途分组。
+
+---
+
+## 本节内容
+
+每组页面都有单独的页面介绍：
+
+| 页面 | 内容 |
+|---|---|
+| [表单和作业](forms-and-jobs.html) | 登录、仪表板、填写表单以及跟踪其作业 |
+| [设计器和 git](designer-and-git.html) | 编辑表单并将其保存在 git 中 |
+| [管理](administration.html) | 设置菜单：系统、外观、访问、连接和日志 |
+| [个人设置](personal-settings.html) | 您的个人资料和深色主题 |
diff --git a/i18n/zh/_introduction/gui/personal-settings.md b/i18n/zh/_introduction/gui/personal-settings.md
new file mode 100644
index 0000000..15f0b7d
--- /dev/null
+++ b/i18n/zh/_introduction/gui/personal-settings.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: 个人设置
+parent: 界面导览
+nav_order: 4
+redirect_from:
+  - /gui/user-profile.html
+  - /gui/dark-mode.html
+translated_from: 9a803556b1f36b043f5f8c45aeebdfabd7e0e68b
+---
+
+# 个人设置
+{: .no_toc }
+
+您的个人资料和深色主题
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 用户个人资料
+
+您的账户、偏好、密码、权限和 API 令牌。
+
+参见 [您的个人资料](../profile)。
+
+![用户个人资料](../assets/screenshots/profile.jpg)
+
+---
+
+## 深色模式
+
+AnsibleForms 支持深色模式，以减轻眼睛疲劳。
+
+![深色模式](../assets/screenshots/darkmode.jpg)
diff --git a/i18n/zh/_introduction/how-it-works.md b/i18n/zh/_introduction/how-it-works.md
new file mode 100644
index 0000000..dcbf0d8
--- /dev/null
+++ b/i18n/zh/_introduction/how-it-works.md
@@ -0,0 +1,209 @@
+---
+layout: default
+title: 工作原理
+nav_order: 2
+translated_from: e802a9168b87771c9d1a2d2d9af9368646b4f39f
+---
+
+# 工作原理
+{: .no_toc }
+
+安装由哪些部分组成、启动时发生了什么，以及数据保存在哪里
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 架构
+
+AnsibleForms 是一个 Node.js 服务器，提供 Web 应用和 REST API，后端为 MySQL 数据库。它从
+YAML 文件读取表单，自身不运行任何东西：它把每个作业交给一个 [运行器](runners.html)。playbook 会交给您的某个 RTE
+（运行环境）容器，由它运行 `ansible-playbook`；模板或作业则交给 AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins：
+
+<div class="af-diagram" markdown="0">
+<svg viewBox="0 0 760 500" role="img" aria-labelledby="afd-title afd-desc" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:100%;height:auto;color:var(--body-text-color);font-family:inherit">
+<title id="afd-title">AnsibleForms 架构</title>
+<desc id="afd-desc">浏览器和可选的 MCP 客户端与 AnsibleForms 服务器通信。服务器把数据存储在 MySQL 和持久化文件夹中，并连接数据源、密钥库、git 仓库、登录提供方、通知通道、syslog 服务器以及可选的模型提供方。它的运行器把每个 playbook 交给一个或多个 RTE 容器之一，每个容器各通过一条 WebSocket 连接，RTE 运行 ansible-playbook 并把输出发回服务器；每个模板或作业则交给 AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins。</desc>
+<style>
+.afd-box{fill:var(--af-accent-soft);stroke:currentColor;stroke-opacity:.45;stroke-width:1.2}
+.afd-main{fill:none;stroke:var(--link-color);stroke-width:1.8}
+.afd-solid{fill:var(--body-background-color)}
+.afd-back{stroke-opacity:.45}
+.afd-inner{fill:var(--body-background-color);stroke:currentColor;stroke-opacity:.35;stroke-width:1}
+.afd-run{fill:var(--af-accent-soft);stroke:var(--link-color);stroke-width:1.4}
+.afd-opt{stroke-dasharray:5 4}
+.afd-t{fill:currentColor;font-size:13px;font-weight:600}
+.afd-s{fill:var(--af-muted);font-size:11px}
+.afd-h{fill:var(--link-color);font-size:14px;font-weight:700}
+.afd-line{stroke:currentColor;stroke-opacity:.6;stroke-width:1.3;fill:none}
+.afd-go{stroke:var(--link-color);stroke-opacity:.85;stroke-width:1.5;fill:none}
+</style>
+<defs>
+<marker id="afd-arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="currentColor" fill-opacity=".7"/></marker>
+</defs>
+<rect class="afd-box" x="20" y="70" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="99" text-anchor="middle">浏览器</text>
+<text class="afd-s" x="105" y="118" text-anchor="middle">表单、设计器、作业、聊天</text>
+<rect class="afd-box afd-opt" x="20" y="200" width="170" height="70" rx="10"/>
+<text class="afd-t" x="105" y="229" text-anchor="middle">MCP 客户端</text>
+<text class="afd-s" x="105" y="248" text-anchor="middle">可选</text>
+<line class="afd-line" x1="190" y1="105" x2="258" y2="105" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="190" y1="235" x2="258" y2="235" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main" x="260" y="30" width="240" height="345" rx="12"/>
+<text class="afd-h" x="380" y="56" text-anchor="middle">AnsibleForms 服务器</text>
+<text class="afd-s" x="380" y="74" text-anchor="middle">Node.js / Express</text>
+<rect class="afd-inner" x="280" y="88" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="114" text-anchor="middle">Web 应用和 REST API</text>
+<rect class="afd-inner" x="280" y="142" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="168" text-anchor="middle">表单引擎、表达式</text>
+<rect class="afd-inner" x="280" y="196" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="222" text-anchor="middle">工作流、调度</text>
+<rect class="afd-inner afd-opt" x="280" y="250" width="200" height="42" rx="8"/>
+<text class="afd-t" x="380" y="276" text-anchor="middle">MCP 服务器（可选）</text>
+<rect class="afd-run" x="280" y="304" width="200" height="50" rx="8"/>
+<text class="afd-t" x="380" y="325" text-anchor="middle">运行器</text>
+<text class="afd-s" x="380" y="342" text-anchor="middle">把每个作业交给其运行器</text>
+<rect class="afd-box" x="570" y="30" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="47" text-anchor="middle">数据源</text>
+<text class="afd-s" x="655" y="63" text-anchor="middle">数据库、REST API、文件</text>
+<rect class="afd-box" x="570" y="80" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="97" text-anchor="middle">密钥库</text>
+<text class="afd-s" x="655" y="113" text-anchor="middle">HashiCorp Vault, CyberArk</text>
+<rect class="afd-box" x="570" y="130" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="147" text-anchor="middle">Git 仓库</text>
+<text class="afd-s" x="655" y="163" text-anchor="middle">表单、playbook、配置</text>
+<rect class="afd-box" x="570" y="180" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="197" text-anchor="middle">登录提供方</text>
+<text class="afd-s" x="655" y="213" text-anchor="middle">LDAP, Entra ID, OIDC</text>
+<rect class="afd-box" x="570" y="230" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="247" text-anchor="middle">通知通道</text>
+<text class="afd-s" x="655" y="263" text-anchor="middle">邮件、Slack、Teams、webhook</text>
+<rect class="afd-box" x="570" y="280" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="297" text-anchor="middle">Syslog 服务器</text>
+<text class="afd-s" x="655" y="313" text-anchor="middle">日志、审计记录</text>
+<rect class="afd-box afd-opt" x="570" y="330" width="170" height="42" rx="10"/>
+<text class="afd-t" x="655" y="347" text-anchor="middle">模型提供方</text>
+<text class="afd-s" x="655" y="363" text-anchor="middle">可选，聊天助手</text>
+<line class="afd-line" x1="500" y1="51" x2="568" y2="51" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="101" x2="568" y2="101" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="151" x2="568" y2="151" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="201" x2="568" y2="201" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="251" x2="568" y2="251" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="500" y1="301" x2="568" y2="301" marker-end="url(#afd-arrow)"/>
+<line class="afd-line afd-opt" x1="500" y1="351" x2="568" y2="351" marker-end="url(#afd-arrow)"/>
+<rect class="afd-box" x="20" y="420" width="170" height="60" rx="10"/>
+<text class="afd-t" x="105" y="445" text-anchor="middle">持久化文件夹</text>
+<text class="afd-s" x="105" y="463" text-anchor="middle">配置、表单、playbook</text>
+<rect class="afd-box" x="210" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="285" y="445" text-anchor="middle">MySQL / MariaDB</text>
+<text class="afd-s" x="285" y="463" text-anchor="middle">作业、用户、凭据</text>
+<polyline class="afd-line" points="260,355 105,355 105,418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<line class="afd-line" x1="285" y1="377" x2="285" y2="418" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<rect class="afd-main afd-solid afd-back" x="412" y="408" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid afd-back" x="406" y="414" width="150" height="60" rx="10"/>
+<rect class="afd-main afd-solid" x="400" y="420" width="150" height="60" rx="10"/>
+<text class="afd-t" x="475" y="445" text-anchor="middle">RTE 容器</text>
+<text class="afd-s" x="475" y="463" text-anchor="middle">运行 ansible-playbook</text>
+<rect class="afd-box" x="570" y="420" width="182" height="60" rx="10"/>
+<text class="afd-t" x="661" y="445" text-anchor="middle">AWX / AAP / Ascender</text>
+<text class="afd-s" x="661" y="463" text-anchor="middle">Semaphore, Rundeck, Jenkins</text>
+<line class="afd-go" x1="420" y1="354" x2="420" y2="405" marker-start="url(#afd-arrow)" marker-end="url(#afd-arrow)"/>
+<polyline class="afd-go" points="470,354 470,394 661,394 661,418" marker-end="url(#afd-arrow)"/>
+<text class="afd-s" x="413" y="387" text-anchor="end">playbook，</text>
+<text class="afd-s" x="413" y="400" text-anchor="end">WebSocket</text>
+<text class="afd-s" x="566" y="388" text-anchor="middle">模板、作业</text>
+</svg>
+</div>
+
+图中的每个组件都有各自的作用：
+
+| 组件 | 作用 |
+|---|---|
+| **浏览器** | Vue Web 应用：表单、[设计器](gui/designer-and-git.html)、作业历史和设置 |
+| **AnsibleForms 服务器** | 对表单求值、记录作业、运行工作流和调度、把每个作业交给其运行器并跟踪它，并提供 [REST API](api/) |
+| **运行器** | 作业运行的地方，在 **连接 > 运行器** 下添加：表单用 `runner: <name>` 指定一个，或使用其类型的默认运行器（参见 [运行器](runners.html)） |
+| **RTE 容器** | 一个或多个运行环境容器，即以 `AF_ROLE=rte` 启动的同一个服务器：每个容器为 [ansible 表单](forms/ansible.html) 运行 `ansible-playbook`，使用其镜像中的 python 库和 collection，并通过一条 WebSocket 把输出和最终状态发回服务器，不持有数据库凭据（参见 [RTE 如何运行](rte/#how-the-rte-runs)） |
+| **AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins** | 用于模板和作业的运行器：[AWX 表单](forms/awx.html) 启动作业模板或工作流模板，[Semaphore](forms/semaphore.html)、[Rundeck](forms/rundeck.html) 和 [Jenkins](forms/jenkins.html) 表单启动它们的某个作业，服务器跟踪其输出 |
+| **MySQL / MariaDB** | 保存作业及其输出、用户、凭据和连接；只有服务器读写它 |
+| **持久化文件夹** | 保存 `config.yaml`、表单文件、playbook、日志和备份 |
+| **数据源** | 填充字段：[数据库查询](formfields/enum.html)、[REST API](expressions/rest-apis.html)、文件和 [其他函数](expressions/remote.html) |
+| **密钥库** | 在使用时提供凭据的用户名和密码，参见 [密钥库](secret-stores/) |
+| **Git 仓库** | 对表单、playbook 和 `config.yaml` 进行版本控制 |
+| **登录提供方** | 让用户登录：[LDAP、Entra ID 和 OIDC](authentication/)，以及本地用户 |
+| **通知通道** | 传递 [通知](forms/notifications.html) 和审批请求：[邮件、Slack、Microsoft Teams、Telegram 或 webhook](notification-channels.html) |
+| **Syslog 服务器** | 在日志和审计记录写入时接收它们，参见 [Syslog](production/logs.html#syslog) |
+| **MCP 客户端、聊天** | 可选，默认都关闭：[MCP 服务器](mcp/) 和 [聊天助手](chat/)，后者需要模型提供方 |
+
+默认情况下，一个容器同时运行服务器、Web 应用和后台任务，旁边是一个 RTE。如需在
+负载均衡器后面运行多个应用节点、由一个 worker 运行后台任务，以及运行更多 RTE，请参见 [扩展](production/scaling.html)。
+
+### 构建技术
+
+服务器和 Web 界面基于以下组件构建：
+
+| 部分 | 技术 |
+|---|---|
+| **服务器** | Node.js 和 Express |
+| **数据库** | MySQL 或 MariaDB |
+| **Web 界面** | Vue 3，搭配 Bootstrap 5 和 Font Awesome |
+
+---
+
+## 启动表单时发生了什么
+
+无论来自浏览器还是来自 [REST API](api/jobs.html)，一次启动都会经过相同的步骤：
+
+1. **加载**：服务器只发送用户的 [角色](config/roles.html) 所允许的表单，并对服务器端表达式求值
+2. **提交**：浏览器把字段值转换为 extravars，并发送到 `POST /api/v2/job`
+3. **检查**：服务器按用户的角色重新加载表单，在开启 [运行验证](launch-validation/) 时检查这些值
+4. **记录**：作业以 `running` 状态存储，其 ID 以 `__jobid__` 添加到 extravars 中
+5. **审批**：带有 [`approval`](forms/approval.html) 点的表单会等待审批人接受该作业
+6. **凭据**：对于 playbook，由应用（而不是 RTE）从数据库或 [密钥库](secret-stores/) 读取表单的凭据
+7. **运行**：作业交给其运行器，即表单用 `runner:` 指定的运行器或其类型的默认运行器。对于 playbook，应用通过 RTE 的 WebSocket
+   把作业发送给其 RTE，凭据以只有该 RTE 能打开的方式密封，由 RTE 运行 `ansible-playbook`（参见 [RTE 如何运行](rte/#how-the-rte-runs)）；
+   模板或作业则由 AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins 运行。[工作流](workflows/) 会运行其节点，每个节点都作为
+   一个独立的作业在其自己的运行器上运行
+8. **跟踪**：服务器在输出到达时把它保存到数据库中，对于 playbook 由 RTE 通过其 socket 发送，对于
+   其他运行器则从它们那里读取。表单页面每两秒重新读取一次作业，作业页面则在服务器
+   通知每次变化时实时跟踪
+9. **结束**：作业获得最终状态，如果表单有要求，其 [`notifications`](forms/notifications.html) 会通过邮件以及
+   [通知通道](notification-channels.html) 发出
+
+---
+
+## 数据存储在哪里
+
+AnsibleForms 把其状态保存在两个地方：MySQL 数据库和持久化文件夹。请同时备份两者。
+
+### 在数据库中
+{: .no_toc }
+
+数据库 `AnsibleForms` 在首次启动时创建（除非 `ALLOW_SCHEMA_CREATION` 为 `0`），其中保存：
+
+* 作业、其 extravars 和输出、调度以及保存的作业
+* 本地用户、组和 API 令牌
+* 用 `ENCRYPTION_SECRET` 加密的凭据，以及密钥库连接
+* 运行器、通知通道（包括邮件）、syslog 服务器，以及 LDAP、SSO、仓库和聊天助手的设置
+* 审计日志
+
+### 在持久化文件夹中
+{: .no_toc }
+
+它在镜像中为 `/app/dist/persistent`，从源码运行时为 `server/persistent`；每个路径都有自己的 [变量](customization/paths.html)：
+
+| 默认路径 | 变量 | 内容 |
+|---|---|---|
+| `config.yaml` | [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) | 类别、角色和常量 |
+| `forms/` | [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) | 表单文件，`.yaml` 或 `.yml`，可以放在子文件夹中 |
+| `playbooks/` | [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) | `ansible` 表单的 playbook 及其工作目录 |
+| `repositories/` | [`REPO_PATH`](customization/paths.html#env_REPO_PATH) | git 仓库的克隆 |
+| `forms_backups/` | [`FORMS_BACKUP_PATH`](customization/paths.html#env_FORMS_BACKUP_PATH) | 设计器在保存前创建的副本 |
+| `backups/` | [`BACKUP_PATH`](customization/paths.html#env_BACKUP_PATH) | 数据库备份 |
+| `uploads/` | [`UPLOAD_PATH`](customization/paths.html#env_UPLOAD_PATH) | 通过 `file` 字段上传的文件 |
+| `logs/` | [`LOG_PATH`](customization/logging.html#env_LOG_PATH) | `ansibleforms.log` 和 `ansibleforms.errors.log` |
+| `certificates/` | [`HTTPS_CERT`](customization/server.html#env_HTTPS_CERT), [`HTTPS_KEY`](customization/server.html#env_HTTPS_KEY) | `HTTPS` 为 `1` 时使用的证书和密钥 |
+| `.env` | | 从设置页面保存的环境变量（除非 `ALLOW_ENV_EDIT` 为 `0`） |
+
+生成的 SSH 密钥位于 [`HOME_PATH`](customization/paths.html#env_HOME_PATH) 中，默认在持久化文件夹之外。
diff --git a/i18n/zh/_introduction/prerequisites.md b/i18n/zh/_introduction/prerequisites.md
new file mode 100644
index 0000000..e369644
--- /dev/null
+++ b/i18n/zh/_introduction/prerequisites.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: 前提条件
+nav_order: 5
+translated_from: 730eff82a2f1ae75eaf5d1cb57f10f6e1019d14b
+---
+
+# 前提条件
+{: .no_toc }
+
+安装 AnsibleForms 之前您需要准备什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 运行环境
+
+AnsibleForms 以容器形式运行，或作为服务器本身上的 systemd 服务运行，对于自行构建的用户，也可以作为 Node.js 应用运行：
+
+| 安装方式 | 您需要 |
+|---|---|
+| [安装程序](installation/installer.html) | amd64 或 arm64 上的 Linux、`curl` 或 `wget` 以及 `sha256sum`，以及它所安装到的引擎的要求（见下文） |
+| [原生安装](installation/native.html) | Root、systemd 和受支持的 Linux（Ubuntu、Debian、RHEL 及其衍生版、SUSE）；其余由安装程序安装 |
+| [Docker](installation/docker.html) | Docker 或 Podman，以及您自己的 MySQL 服务器 |
+| [Docker Compose](installation/docker-compose.html) | Docker Compose 或 podman-compose；该项目也会启动 MySQL |
+| [Kubernetes](installation/kubernetes.html) | 一个集群、Helm 3 和一个 StorageClass（或预先创建的 PersistentVolume） |
+| [从源码安装](installation/from-source.html) | Node.js 26（至少 24）及 npm、Git，以及供运行 playbook 的 RTE 进程使用的 Ansible |
+
+应用镜像 `ghcr.io/ansibleforms/ansibleforms` 包含 Node.js 以及服务器调用的工具（git、ssh、mariadb 客户端和
+ytt），但不包含 Python 和 Ansible。playbook 在 RTE（运行环境）上运行，RTE 是第二个容器，使用
+`ghcr.io/ansibleforms/ansibleforms-rte-full`，或使用您基于 `ansibleforms-rte-core` 构建的镜像（参见 [扩展](rte/)）。
+只在 AWX、AAP、Ascender、Semaphore、Rundeck 或 Jenkins 上启动模板的表单不需要 RTE。
+
+---
+
+## 数据库
+
+AnsibleForms 把作业、用户、凭据和连接存储在 MySQL 8 或更高版本，或 MariaDB 中。
+
+首次启动时，它会自行创建 `AnsibleForms` schema。请为它创建一个专用的数据库用户，只授予该 schema 的权限，
+不要使用 root：
+
+```sql
+CREATE USER 'ansibleforms'@'%' IDENTIFIED BY '<password>';
+GRANT ALL PRIVILEGES ON `AnsibleForms`.* TO 'ansibleforms'@'%';
+```
+
+它只需要这些：它会创建和修补 schema、进行备份，在有多个 worker 时还会结束已失效 worker 的会话。
+如果该用户对所有数据库都有权限，**状态** 页面和日志会发出警告。应用节点和 worker 都使用这个
+用户连接。socket 模式（出站或入站，参见 [模式](rte/modes.html)）的 RTE 不持有任何数据库凭据：只有
+数据库模式（自 7.3.0 起已弃用）的 RTE 也会连接数据库。要自行创建 schema，请把 [`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) 设为 `0`。
+Docker Compose 项目和 Helm chart（使用 `mysql:8.4`）会为您启动一个数据库。
+
+---
+
+## 容量规划
+
+没有经过测量的硬性要求：负载主要取决于同时运行的作业数量以及它们写入的输出量。
+Helm chart 的默认资源设置是小团队的一个合理起点：
+
+| 组件 | Requests | Limits | 卷 |
+|---|---|---|---|
+| AnsibleForms | 1 CPU，1 GiB 内存 | 4 CPU，4 GiB 内存 | 10 GiB |
+| MySQL | 0.5 CPU，512 MiB 内存 | 2 CPU，2 GiB 内存 | 10 GiB |
+
+应用容器不运行任何 playbook。每个 playbook 都是 RTE 上的一个 `ansible-playbook` 进程，带有其 forks：请根据每个 RTE 同时运行的 playbook
+来规划其 CPU 和内存，最多 [`RTE_MAX_JOBS`](customization/server.html#env_RTE_MAX_JOBS) 个（默认 `10`），要运行更多就运行更多
+RTE。在 AWX、AAP、Ascender 或其他模板运行器上运行的作业对 AnsibleForms 的开销很小。
+
+作业输出默认永久保存在数据库中。在繁忙的实例上请设置 [`JOB_RETENTION_DAYS`](customization/retention.html#env_JOB_RETENTION_DAYS)，
+以免数据库无限增长。
+
+---
+
+## 网络
+
+应用和每个 RTE 都监听各自的端口，并向您的表单和设置所使用的系统发起出站连接。
+
+### 入站
+{: .no_toc }
+
+服务器监听端口 `8000`（[`PORT`](customization/server.html#env_PORT)），使用 HTTP；如果把
+[`HTTPS`](customization/server.html#env_HTTPS) 设为 `1`，则使用 HTTPS。Docker Compose 项目把它发布在端口 443 上，
+Helm chart 则通过 service 或 ingress 暴露它。RTE 也监听自己的 `PORT`，但只有应用会调用它：
+请不要把它暴露在公共网络上。出站 RTE 完全不需要入站端口：它通过应用的端口主动连接应用。
+
+### 出站
+{: .no_toc }
+
+开放从 AnsibleForms 到您所使用系统的连接：
+
+| 目标 | 用途 |
+|---|---|
+| MySQL / MariaDB | AnsibleForms 数据库（`DB_HOST`、`DB_PORT`，默认 `3306`） |
+| RTE | 通过一条 WebSocket 连接位于其运行器地址的入站 RTE，或者调用位于其 [`RTE_URL`](customization/server.html#env_RTE_URL) 的数据库模式 RTE，后者随后自行连接 MySQL；出站 RTE 则由它主动连接应用（参见 [模式](rte/modes.html)） |
+| AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins | 通过它们的 HTTP(S) API 在 [运行器](runners.html) 上启动并跟踪模板和作业 |
+| 受管主机 | playbook 从 RTE 连接它们，例如通过 SSH 或 WinRM |
+| LDAP、Entra ID、OIDC | 使用目录账户或单点登录账户登录 |
+| Git 服务器 | 通过 HTTPS 或 SSH 克隆和拉取仓库 |
+| REST API 和数据库 | 表单中表达式和查询的数据源 |
+| HashiCorp Vault、CyberArk | 从 [密钥库](secret-stores/) 读取凭据 |
+| 邮件服务器、Slack、Teams、Telegram、webhook | 通过 [通知通道](notification-channels.html) 发送作业通知和审批请求 |
+| 模型提供方 | [聊天助手](chat/)，仅在开启时使用 |
+
+要限制表达式的 REST 函数可以调用哪些主机，请参见
+[`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS) 和
+[`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS)。
+
+---
+
+## 浏览器
+
+Web 应用面向当前的浏览器构建：Chrome 或 Edge 111、Firefox 114、Safari 16.4 或更新版本。
+不支持更旧的浏览器。
+
+---
+
+## 扩展
+
+默认情况下，一个 AnsibleForms 容器同时运行 Web 应用和后台任务，旁边是一个 RTE。
+
+要服务更多用户，请在负载均衡器后面运行多个应用节点（`AF_ROLE=app`），并配一个 worker（`AF_ROLE=worker`），由它运行
+调度、备份和其他后台任务；同一时间只有一个 worker 在工作，第二个 worker 会等待接管。它们共享
+数据库、持久化文件夹、`ACCESS_TOKEN_SECRET` 和 `ENCRYPTION_SECRET`。参见 [扩展](production/scaling.html)。要同时运行更多 playbook，
+请运行更多 RTE：参见 [多个 RTE](rte/several.html)。
diff --git a/i18n/zh/_introduction/what-is-ansibleforms.md b/i18n/zh/_introduction/what-is-ansibleforms.md
new file mode 100644
index 0000000..a063e02
--- /dev/null
+++ b/i18n/zh/_introduction/what-is-ansibleforms.md
@@ -0,0 +1,72 @@
+---
+layout: default
+title: 什么是 AnsibleForms
+nav_order: 1
+translated_from: a331f74d2fa27a41cd4321b636ac9640550cac26
+---
+
+# 什么是 AnsibleForms
+{: .no_toc }
+
+位于 Ansible 和 AWX 之前的自助服务表单，以及何时需要它们
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 它做什么
+
+AnsibleForms 在 playbook、工作流，或 AWX、AAP、Ascender、Semaphore、Rundeck
+或 Jenkins 上的模板或作业之前放置一个 Web 表单，让人们无需命令行即可运行自动化。
+
+表单收集输入、检查输入、将其整理为 extravars 并启动作业。表单中的数据可以来自数据库、
+REST API、文件和其他字段，每次启动及其输出都会记录在作业历史中。
+
+---
+
+## 典型用途
+
+团队使用 AnsibleForms 把日常自动化交给提出请求的人：
+
+* **自助服务请求**：虚拟机、存储卷、共享或用户账户，由请求者自行填写
+* **受保护的操作**：带有审批点的操作，作业运行前需要第二个人签字确认
+* **数据驱动的选择**：从 CMDB、数据库或 REST API 填充的下拉框，并从一个字段级联到下一个字段
+* **周期性作业**：稍后运行或按 cron 调度运行的表单，每次都使用同样经过验证的输入
+* **面向工具和代理的自动化**：REST API、MCP 服务器和聊天助手启动的都是同样的表单
+
+---
+
+## AnsibleForms 还是 AWX survey？
+
+AWX、AAP 和 Ascender 有它们自己的 survey。选择哪一个，取决于启动作业的人需要什么。
+
+在以下情况下，**survey** 就足够了：
+
+* 问题是固定的：文本、数字、密码以及来自静态列表的选项
+* 用户已经在使用 AWX、AAP 或 Ascender，其权限模型适合他们
+* 您不想再运行和维护另一个应用和数据库
+
+在以下情况下，**AnsibleForms** 会有所帮助：
+
+* 选项来自其他地方：数据库、REST API、文件或另一个字段（级联下拉框）
+* 输入在到达 playbook 之前需要验证、结构化（列表、嵌套对象）或计算值
+* 作业需要审批点、调度，或者需要从一个表单串联 playbook、模板和审批的工作流
+* 用户完全不应该看到 AWX，或者您还要在没有 AWX 的情况下运行 playbook
+
+AnsibleForms 可以启动 AWX、AAP 和 Ascender 模板，因此二者可以协同工作：表单收集并整理输入，
+AWX 继续负责运行作业。
+
+---
+
+## 下一步去哪里
+
+本节其余部分会在您安装之前解释各个组成部分：
+
+| 页面 | 内容 |
+|---|---|
+| [工作原理](how-it-works.html) | 架构、一次启动的各个步骤，以及数据保存在哪里 |
+| [界面导览](gui/) | 每个页面的截图，从登录到管理页面 |
+| [概念](concepts.html) | 本文档中使用的术语 |
+| [前提条件](prerequisites.html) | 安装之前您需要准备什么 |
diff --git a/i18n/zh/_reference/faq.md b/i18n/zh/_reference/faq.md
new file mode 100644
index 0000000..c0b0f67
--- /dev/null
+++ b/i18n/zh/_reference/faq.md
@@ -0,0 +1,1277 @@
+---
+layout: default
+title: 常见问题
+nav_order: 2
+translated_from: 6616eaf626411a615cb68d8cc4f2a43401fe21d9
+---
+
+# 常见问题
+{: .no_toc }
+
+关于 AnsibleForms 的常见问题和解答
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 入门
+
+### 部署拓扑：一个容器还是多个节点
+
+默认情况下，一个 AnsibleForms 容器在一个进程中运行 Web 应用和后台任务，旁边是一个运行 playbook 的
+RTE 容器。请为它设置重启策略（例如 Docker 中的 `restart: unless-stopped`），并同时备份数据库和
+持久卷。
+
+要在负载均衡器后面运行多个副本，请用 `AF_ROLE` 拆分进程：
+
+- `app` 节点提供 Web 界面和 API：可以运行任意多个，每个都使用相同的 `ACCESS_TOKEN_SECRET`
+- 一个 `worker` 运行后台任务：schema 及其升级、配置种子、调度、每晚备份、仓库
+  同步和清理。同一时间只有一个 worker 在工作，它持有一个数据库锁；第二个 worker 会等待，并在第一个停止时接管
+- `rte` 容器运行 playbook：运行更多 RTE 容器就能同时运行更多 playbook
+
+应用节点和 worker 共享数据库、持久卷和 `ENCRYPTION_SECRET`。socket 模式（出站或
+入站，参见 [模式](rte/modes.html)）的 RTE 既不需要数据库也不需要 `ENCRYPTION_SECRET`。聊天助手需要会话保持，
+每个节点各自保存日志。参见 [扩展](production/scaling.html) 和
+[examples/scale](https://github.com/ansibleforms/ansibleforms/tree/main/examples/scale) 示例配置。
+
+### 多仓库表单管理
+
+所有启用了 **用于表单** 的 Git 仓库中的表单会自动合并；表单名称重复时，第一个
+生效并记录一条警告。请只在一个仓库中保留 `config.yaml`。参见 [Git 仓库](repositories/)。
+
+### 关于仓库
+
+AnsibleForms 在仓库路径（`REPO_PATH`）下克隆和拉取 Git 仓库，在 **设置 > 仓库** 下管理。
+每个仓库上的开关决定它包含什么：配置、表单、playbook 或变量文件。参见 [Git 仓库](repositories/)。
+
+### VS Code 中表单文件的验证
+
+在表单 YAML 文件中添加 schema 头，即可在 VS Code 中获得实时验证和自动补全。
+
+安装 [YAML 扩展](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml)，并把以下注释作为任意表单文件的 **第一行**：
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+```
+
+这既适用于单表单文件（一个 YAML 字典），也适用于多表单文件（一个 YAML 列表）：
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/ansibleforms/ansibleforms/main/server/schema/public/form_schema.json
+- name: My Form
+  type: ansible
+  playbook: site.yml
+  roles: [default]
+  fields:
+    - name: env
+      type: enum
+      values: [dev, staging, prod]
+```
+
+VS Code 会在您输入时高亮显示未知属性、缺少的必填字段和错误的类型。
+
+---
+
+## 作业管理
+
+### 用预填数据重新运行作业
+
+重新运行按钮会打开预先填入先前作业值的表单；密码字段从不存储。
+它需要角色选项 `allowJobRelaunch`，表单可以用 `allowRelaunch: false` 关闭它。参见 [重新运行作业](jobs/actions.html#relaunch-a-job)。
+
+### 作业日志文件
+
+通过作业专属的日志文件跟踪进度（v6.1.2）。
+
+AnsibleForms 可以在 Ansible 输出旁边显示一个 **作业专属的日志文件**。这样您就可以跟踪长时间运行的自定义模块的进度，否则这些模块在执行期间不会产生任何可见的反馈。
+
+{: .note }
+> 此功能只适用于在 RTE 上运行的 playbook。AWX、AAP、Ascender、Semaphore、Rundeck 或
+> Jenkins 上的模板和作业没有日志文件。
+
+**工作原理：**
+- 作业运行期间，RTE 会监视 playbook 文件夹内一个约定路径上的日志文件
+- 每隔两秒，如果文件发生了变化，RTE 就把其内容复制到作业中，playbook 结束时再复制一次
+- 日志文件显示在作业输出的 **日志文件** 部分，行号与输出的行号相同：日志行的时间戳和级别（ERROR、WARNING、INFO、DEBUG）会像输出一样被读取并着色，并支持 ANSI 颜色
+
+**日志文件路径约定：**
+
+日志文件必须写入以下路径：
+
+```
+<playbook_dir>/.joblogs/job_log_<jobid>.log
+```
+
+**AnsibleForms 会自动传入 `__jobid__`**，因此您无需任何额外配置即可在 playbook 中拼出该路径：
+
+{% raw %}
+```yaml
+job_log_path: "{{ vars['playbook_dir'] }}/.joblogs/job_log_{{ __jobid__ }}.log"
+```
+{% endraw %}
+
+把这个变量传给任何需要把进度写入该文件的角色或自定义模块。
+
+**playbook / 模块开发人员的职责：**
+- 在操作开始时 **创建** 日志文件（及其 `.joblogs/` 目录）
+- 随着操作的进行 **写入** 有意义的进度消息
+
+playbook 结束、最后的内容保存到作业后，RTE 会删除该文件。
+
+**支持 ANSI 颜色编码。**  
+日志消息中的标准 ANSI 转义码（例如绿色为 `\033[92m`，红色为 `\033[91m`）会在界面中渲染为颜色，因此成功、警告和错误状态一目了然。
+
+**典型用例：**  
+一个执行一长串 API 调用或数据操作的自定义 Python Ansible 模块（例如 SnapMirror DR 工作流）可以每一步向日志文件追加一行。在 AnsibleForms 中查看该作业的操作人员会在作业页面跟踪作业时，于日志文件部分看到实时进度。
+
+### Jobid
+
+传入当前作业 ID。
+
+AnsibleForms 会自动在 extravars 中以 `__jobid__` 发送当前作业 ID；无需任何配置。
+
+### Userinfo
+
+传入当前用户。
+
+AnsibleForms 会自动在 extravars 中以 `ansibleforms_user` 发送用户信息；无需任何配置。
+
+您可以选择发送其中多少内容。`EXTRAVARS_USER_FIELDS` 接受以逗号分隔的顶层键列表
+（`username,email,type`），或 `none` 表示什么都不发送；表单可以用自己的 `userExtravars` 属性覆盖它。
+默认与以前一样发送整个对象。下面介绍的表单端 `__user__` 来自登录令牌，从不受影响。
+
+### 表单中的 Userinfo
+
+在表单中访问当前用户信息（v4.0.2）。
+
+字段 `__user__` 会自动添加到表单中，并可在表达式中引用：
+
+```yaml
+expression: $(__user__)
+expression: "'$(__user__.username)'"
+expression: $(__user__.groups)
+expression: $(__user__.roles)
+```
+
+---
+
+## 表单字段
+
+### 级联下拉框
+
+制作级联下拉框。
+
+`enum` 字段（下拉框）的 `query` 或 `expression` 属性中可以包含占位符，格式为 `$(another_field)` 或 `$(another_field[0].name)`。  
+一旦被引用的字段发生变化，引用它的字段就会重新求值，从而形成动态的级联下拉框。  
+客户端 Web 应用每 100 毫秒重新对字段求值一次；在当前的处理器和 Chromium 引擎上，体验非常流畅。
+
+{: .note }
+> 对另一个 enum 字段的引用返回的是所选的值，**而不是** 完整的下拉列表。请使用 `placeholderColumn` 属性或 `$(city.name)` 这样的点号写法。  
+> **v4.0.20 新增**：把 placeholderColumn 设为 "*" 会输出整条记录，而不是单独一列。
+
+```yaml
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name from cmdb.city
+  name: city_name
+  label: Select a city
+  default: Amsterdam
+  required: true
+  model: cmdb.city
+  group: CMDB
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select datacenter.name from cmdb.datacenter,cmdb.city where datacenter.city_id=city.id
+    and city.name='$(city_name)'
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__    # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB      
+
+# or use the placeholderColumn property
+
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select id,name,description from cmdb.city
+  name: city
+  label: Select a city
+  default: Amsterdam         # evaluated against valueColumn
+  required: true
+  model: cmdb.city
+  group: CMDB
+  valueColumn: name          # we choose the name column as value for placeholders
+  placeholderColumn: id      # we can reference the id by using $(city)
+  previewColumn: description # when you select a value, the dropdown will show description
+  columns:                   # we hide id
+  - name
+  - description
+- type: enum
+  dbConfig: 
+    name: CONN1
+    type: mysql
+  query: select name, capacity_pct from cmdb.datacenter where datacenter.city_id=$(city)
+# this cascaded dropdown will react using "id" as placeholder
+# or "query":"select name from cmdb.datacenter where datacenter.city_id=$(city.id)",  
+# or reference the column in the placeholder                            
+  name: datacenter_name
+  label: Select a datacenter
+  default: __auto__         # default can be "__auto__" (first item) or "__all__" (all items) or "__none__" (no default)
+  multiple: true
+  pctColumns:
+  - capacity_pct
+  outputObject: true
+  required: true
+  model: cmdb.datacenter
+  group: CMDB
+```
+
+### 字段占位符
+
+引用另一个字段的值。
+
+占位符是对表单中其他字段的引用。  
+占位符的格式始终为 `$(reference)`，表达式和查询中都可以包含占位符。  
+指向简单字段（text、number、password）的占位符保存的是该字段的值。  
+指向基于对象的 enum 字段的占位符，必须使用 `placeholderColumn` 属性或 `$(city.name)` 这样的点号写法。  
+指向 expression 字段的占位符会返回完整的对象，您也可以使用类似 JavaScript 的高级引用，例如 `$(myarray[0].name)`。
+
+{: .important }
+> 占位符在表达式求值 **之前** 被替换。如果您期望结果是字符串，必须用引号把它括起来。  
+> **v4.0.20 新增**：把 placeholderColumn 设为 "*" 会输出整条记录，而不是单独一列。
+
+```yaml
+- name: field1
+  type: expression
+  expression: "[{name: 'foo'},{name: 'bar'},{name: 'ansible'}]"
+  runLocal: true
+- name: field2
+  type: expression
+  expression: "'$(field1[0].name)'"  # result : 'foo' (note the wrapping quotes)
+  runLocal: true
+- name: field3
+  type: expression
+  expression: "$(field1)[0].name"  # result : {name: 'foo'}.name => 'foo'  
+  runLocal: true    
+- name: field4
+  type: expression
+  expression: "$(field1).slice(-1)[0].name"  # result : {name: 'ansible'}.name => 'ansible' 
+  runLocal: true
+- name: field5
+  type: enum
+  expression: $(field1).filter(x => x.name.includes('a'))   # result : [{name: 'bar'},{name: 'ansible'}]
+  runLocal: true
+  default: __auto__                                         # result: bar
+- name: field6
+  type: expression
+  expression: "'$(field5)'"   # result : the selected item from field5 (default=bar)
+  runLocal: true        
+```
+
+### 隐藏字段
+
+隐藏一个字段。
+
+用字段属性 `hide` 隐藏字段，或者用字段属性 `dependencies` 和 `dependencyFn` 动态地显示和隐藏它。
+
+### 字段分组
+
+把字段归入一个块中。
+
+使用字段属性 `group`。组名相同的字段会被归入同一个块。
+
+### 字段验证
+
+验证一个字段。
+
+使用验证类的字段属性，例如 `regex`、`minValue` 和 `notIn`。
+
+### Enum 的默认值
+
+Enum 默认值。
+
+字段属性 `default` 设置默认值，在 `enum` 字段上可以使用 `__auto__` 等值来自动选中第一项。
+
+要根据表达式设置动态默认值，请把默认项移到列表的最前面，如下例所示。
+
+```yaml
+# using client javascript manipulation
+
+- type: expression
+  expression: "[{name:'bert'},{name:'ernie'},{name:'pino'}]"
+  name: dropdownsource
+  label: Dropdown source
+  runLocal: true
+- type: expression
+  expression: "'pino'"
+  name: dropdownsourceDefault
+  label: Default source
+  runLocal: true
+- type: enum
+  expression: "[...[{name:'$(dropdownsourceDefault)'}],...$(dropdownsource).filter(x => x.name!=='$(dropdownsourceDefault)')]"
+  name: dropdownwithdefault
+  label: Example with expression default by moving it to top
+  runLocal: true
+  default: __auto__     
+
+# explained : 
+# we take our default and merge it with the source where we filter out the default (to avoid doubles)    
+# the default is thus shifted to the first element, which we can now select with the default `__auto__`
+```
+
+### 表达式默认值
+
+表达式默认值。
+
+对于 text、number 或 date 字段，`default` 属性设置静态默认值。
+
+要让默认值基于表达式动态变化，请使用以下两个属性之一：
+* `editable`：使用 editable 属性让 expression 字段可编辑
+* `evalDefault`：使用 evalDefault 属性把默认值作为表达式求值
+
+```yaml
+# using editable
+- type: expression
+  expression: "'$(some_other_field)'.toLowerCase()"
+  name: field1
+  runLocal: true
+  editable: true # this will add an edit-button so you manually overwrite the expression value
+
+# using evalDefault
+- type: text
+  name: field1
+  default: "'$(some_other_field)'.toLowerCase()"
+  evalDefault: true # it will treat the default as if it was an expression.
+  # note : when `some_other_field` changes, the default will be re-evaluated
+  # note2 : works for other fields too.
+
+# more complex evalDefault example
+- name: checkbox
+  type: checkbox
+- name: textfield1
+  type: text
+  line: line2
+  default: ping
+- name: textfield2
+  type: text
+  line: line2
+  default: pong
+- name: checkbox3
+  type: checkbox
+  line: line3
+  label: This checkbox will default check if checkbox or textfield1==textfield2
+  default: |
+    (
+      (c=false,t1="",t2="") => { return c || (t1==t2) }
+    )( $(checkbox) , "$(textfield1)" , "$(textfield2)" )
+    
+  evalDefault: true
+```
+
+---
+
+## 向导和工作流
+
+### 向导和工作流有什么区别？
+
+**向导** 和 **工作流** 都是分步骤的，但它们作用于不同的层面，并且可以组合使用。
+
+| | [`workflow`](forms/workflow.html)（工作流） | [`wizard`](forms/wizard.html) |
+|---|---|---|
+| **层面** | 执行 | 表单 / 界面 |
+| **拆分的对象** | 把作业拆分为依次或并行运行的节点 | 把一个表单的输入拆分为多个页面 |
+| **结果** | 1 个工作流作业，每个节点一个作业（各自有自己的 playbook 或模板） | 最后运行 1 个作业 |
+| **表单 `type`** | 必须是 `workflow` | 适用于除 `subform` 之外的所有表单类型 |
+| **定义方式** | 设计器中的 [工作流文件](workflows/file.html)（`workflow:`） | [子表单](forms/subform.html) 引用的列表（`wizard:`） |
+| **适用场景** | “先做 A，再做 B，然后做 C，作为单独的作业” | “我的表单字段太多，一页放不下” |
+
+**要点：** 工作流关注的是 *运行什么以及按什么顺序运行*；`wizard` 关注的是 *用户如何填写表单*。
+
+{: .note }
+> 7 之前，执行部分由 `multistep` 表单类型及其 `steps` 完成。它自 7 起已弃用，并将在
+> 8 中移除：工作流可以做多步骤表单所做的一切，参见 [多步骤表单](forms/multistep.html)。
+
+#### 仅工作流
+{: .no_toc }
+
+`type: workflow` 表单运行设计器中的某个工作流。用户填写单个页面的字段并点击提交，
+工作流随后运行其节点，每个节点都以表单的值作为额外变量：
+
+```yaml
+- name: Provision host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  fields:
+    - name: hostname
+      type: text
+```
+
+#### 仅向导
+{: .no_toc }
+
+表单上的 `wizard:` 块把输入收集分散到多个页面上。最后只运行 **一个** 作业：所有页面合并后的 extravars 会发送给单个 playbook、模板或工作流。
+
+```yaml
+- name: Provision host
+  type: ansible
+  roles:
+    - default
+  playbook: provision.yml
+  wizard:
+    - subform: basics
+      title: Basics
+    - subform: network
+      title: Network
+      defaultModel: net
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: ipv4
+      type: text
+```
+
+最后会自动追加一个只读的确认页面作为向导的最后一页；您无需在 YAML 中声明它。
+
+#### 组合使用（在工作流之上叠加向导）
+{: .no_toc }
+
+向导可以叠加在工作流表单之上。用户填写向导页面并点击提交，**然后** 工作流才开始运行。
+通过让向导步骤的 `defaultModel` 与节点的
+[`extra_vars_key`](workflows/file.html#ansibleforms-own-keys) 相匹配，您可以把 **一个向导页面路由到一个节点**：
+
+```yaml
+- name: Provision and verify host
+  type: workflow
+  workflow: provision-host
+  roles:
+    - default
+  wizard:
+    - subform: basics
+      title: Basics
+      defaultModel: basics            # wraps basics fields under `basics`
+    - subform: network
+      title: Network
+      defaultModel: network           # wraps network fields under `network`
+```
+
+以及设计器中某个工作流文件里的工作流 `provision-host`：
+
+```yaml
+workflow_job_templates:
+  - name: provision-host
+    related:
+      workflow_nodes:
+        - identifier: create
+          unified_job_template:
+            name: create_host.yml
+            type: job_template
+          extra_vars_key: basics      # only sees the basics page payload
+          related:
+            success_nodes:
+              - identifier: network
+        - identifier: network
+          unified_job_template:
+            name: configure_network.yml
+            type: job_template
+          extra_vars_key: network     # only sees the network page payload
+```
+
+`extra_vars_key` 只做单层查找，因此如果希望二者匹配，请在 `defaultModel` 中使用扁平的名称（例如 `defaultModel: basics`，而不是 `defaultModel: input.basics`）。
+
+完整的属性参考请参见 [向导页面](forms/wizard.html)。
+
+### 如何有条件地显示或跳过向导步骤？
+
+使用 `when:` 完全 **隐藏** 某个步骤，或使用 `optional: true` 让用户 **跳过** 某个可见的步骤。二者相互独立，一般不应组合使用。
+
+#### `when:`：有条件的可见性
+{: .no_toc }
+
+当表达式求值为假值时，该步骤会被隐藏。用户永远看不到它，其值也不会被收集。表达式可以通过 `__parent__.<stepname>.<field>` 读取前面的步骤：
+
+```yaml
+wizard:
+  - subform: basics             # has a `kind` enum field with values vm/bare-metal/container
+    title: Basics
+  - subform: virtualization
+    title: Virtualization
+    when: $(__parent__.basics.kind) === 'vm'
+  - subform: hardware
+    title: Hardware
+    when: $(__parent__.basics.kind) === 'bare-metal'
+```
+
+只显示与所选 `kind` 匹配的页面。隐藏步骤之后的步骤会自动重新编号。
+
+#### `optional: true`：允许跳过可见的步骤
+{: .no_toc }
+
+该步骤在步骤条中 **始终显示**，但用户可以不填写就点击 **下一步**，即使从未访问或完成该页面，也允许 **提交**：
+
+```yaml
+wizard:
+  - subform: basics
+    title: Basics
+  - subform: advanced
+    title: Advanced (optional)
+    optional: true
+```
+
+用户可以打开 Advanced 页面，保持为空，点击下一步，直接进入确认页面。
+
+{: .note }
+> `when:` 控制 *可见性*；`optional:` 控制 *该页面是否必须完成*。不要组合使用它们：要让页面消失，请使用 `when:`；要让它保持可见但可以跳过，请使用 `optional:`。
+
+### 如何引用前面向导步骤中的值？
+
+在后面步骤的任意字段中使用 `$(__parent__.<stepname>.<field>)`。
+
+向导步骤的 `name`（默认为其 `subform` 名称）就是其值暴露给后续步骤时所用的命名空间：
+
+```yaml
+- name: Provision host
+  type: ansible
+  playbook: provision.yml
+  roles:
+    - default
+  wizard:
+    - subform: basics          # step name defaults to "basics"
+      title: Basics
+    - subform: network
+      title: Network
+
+- name: basics
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+
+- name: network
+  type: subform
+  fields:
+    - name: fqdn
+      type: text
+      # Re-evaluated when basics.hostname changes
+      default: $(__parent__.basics.hostname).local
+```
+
+这与 `list` 和 `yaml` 子表单使用的 `__parent__` 机制相同；参见 [如何在子表单中访问父表单的数据？](#how-do-i-access-parent-form-data-inside-a-subform)。
+
+---
+
+## 安全和凭据
+
+### 凭据
+
+传递凭据。
+
+凭据可以通过以下几种方式传递：
+* 使用字段属性 `asCredential`  
+* 使用 `credentials` 表单属性（键值对）
+* 使用名为 `__credentials__` 的 extravar
+
+```yaml
+# assume you have 2 credentials created in Ansible Forms
+# 1: vcenter
+# 2: ad
+
+# you want them exposed to the playbook as
+# 1: vc_cred
+# 2: ad_cred
+
+# Method 1 : using asCredential field-property
+fields:
+- name: vc_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'vcenter'"
+- name: ad_cred
+  type: expression
+  runLocal: true
+  asCredential: true
+  expression: "'ad'"
+
+# Method 2 : using credentials form-property   
+name: myplaybook
+type: ansible
+playbook: myplaybook.yaml
+roles:
+  - default
+credentials:
+  vc_cred: vcenter
+  ad_cred: ad
+  veeam_cred : veeam_prod,veeam_dev # will first try veeam_prod, then as fallback veeam_dev
+
+# Method 3 : using __credentials__ extravar
+fields:
+- name: __credentials__
+  type: expression
+  runLocal: true
+  expression: "{vc_cred: 'vcenter',ad_cred: 'ad',veeam_cred:'$(veeam_server)'}"
+  # note : in the expression you can use placeholders to make them dynamic
+```
+
+### 找回丢失的管理员密码
+
+如果您丢失了本地 `admin` 账户的密码，并且没有其他管理员用户可用，请使用 `REINIT_ADMIN` 恢复选项。**这不是运行时的身份验证绕过**：它只会在启动时对本地管理员账户强制执行一次重置，之后照常进行身份验证。
+
+**工作原理**
+
+启动时设置了 `REINIT_ADMIN=1` 时，AnsibleForms 会：
+
+1. 确保 `admins` 组存在（缺失时创建它）。
+2. 查找本地管理员用户（默认用户名为 `admin`，可用 `ADMIN_USERNAME` 覆盖）。
+3. 如果该用户存在，把其密码重置为 `ADMIN_PASSWORD` 的值，并把它重新加入 `admins` 组。
+4. 如果不存在，则创建它（与全新安装时相同）。
+5. 醒目地记录该操作，使其在日志中清晰可见。
+
+**步骤**
+
+1. 停止 AnsibleForms。
+2. 设置环境变量（请使用强密码）：
+   ```bash
+   ADMIN_USERNAME=admin
+   ADMIN_PASSWORD=YourNewStrongPasswordHere
+   REINIT_ADMIN=1
+   ```
+   在 Docker Compose 中，把它们添加到 AnsibleForms 服务的 `environment:` 块中。
+3. 启动 AnsibleForms，并留意日志中类似下面的一行：
+   ```
+   REINIT_ADMIN: admin user 'admin' has been recreated. UNSET REINIT_ADMIN now.
+   ```
+4. 用 `admin` / `YourNewStrongPasswordHere` 登录。
+5. **取消设置 `REINIT_ADMIN`（或把它改回 `0`）** 并重启，以免以后的重启再次重置管理员密码。
+
+**注意事项**
+
+- 如果您被锁在外面是因为 LDAP 是唯一配置的登录方式而它失败了，恢复后的本地 `admin` 账户始终会回退到本地数据库身份验证，这足以登录并修复 LDAP。
+- 以前的 `ENABLE_BYPASS` 环境变量已被移除。它允许用任意密码以 admin 身份登录，保持启用是不安全的。`REINIT_ADMIN` 只重置密码；之后照常进行身份验证。
+- `REINIT_ADMIN` 不会使现有的会话和令牌失效；只有密码哈希和组成员关系会改变。
+
+### 限制 REST 辅助函数的目标（允许/拒绝列表）
+
+`fn.fnRestBasic`、`fn.fnRestAdvanced`、`fn.fnRestJwt` 和 `fn.fnRestJwtSecure` 辅助函数可以在表单的 `expression` 属性中调用，以通过 HTTP 获取数据。默认情况下，表达式的作者可以访问 AnsibleForms 主机能够到达的 **任何** URL，在敏感网络中您可能需要加以限制。
+
+两个环境变量分别提供允许列表和拒绝列表：
+
+| 变量 | 行为 |
+|---|---|
+| `REST_ALLOWED_HOSTS` | 以逗号分隔的主机名或 CIDR。设置后，**只** 允许这些目标。 |
+| `REST_DENIED_HOSTS` | 以逗号分隔的主机名或 CIDR。始终阻止。优先于允许列表。 |
+
+主机名与 URL 的主机进行不区分大小写的匹配。CIDR 与该主机解析出的每个 IP 进行匹配，因此 `10.0.0.0/8` 会阻止任何解析到该私有地址段的 DNS 名称。
+
+**示例：**
+
+第一行只允许两个主机；第二行阻止特定的目标：
+
+```bash
+# Whitelist: only your two API partners are reachable
+REST_ALLOWED_HOSTS=api.example.com,partner.api.com
+
+# Blacklist: block cloud metadata + internal admin UIs
+REST_DENIED_HOSTS=169.254.169.254,127.0.0.0/8,internal-admin.example
+```
+
+{: .warning }
+> **此防护只保护 AnsibleForms 的 Node.js 进程。** playbook 一旦运行，Ansible 本身就可以从主机访问任何地方，不受 AnsibleForms 控制。请用这些列表防止表单作者把表达式变成访问元数据服务或内部界面的代理；不要把它们当作网络防火墙来依赖。
+
+从 7.3.0 起，REST 辅助函数会像其他所有连接一样检查端点的 TLS 证书，并在
+[`REST_TIMEOUT_SECONDS`](customization/security.html#env_REST_TIMEOUT_SECONDS)（默认 `60`）后放弃。请用
+`NODE_EXTRA_CA_CERTS` 信任私有 CA，或者只为使用自签名证书的端点把 [`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) 设为 `1`。
+
+### HashiCorp Vault 集成
+
+凭据可以从配置为 **密钥库** 的 HashiCorp Vault 读取其用户名和密码。
+参见 [密钥库](secret-stores)。早期版本的 `VAULT_*` 环境变量
+会在 7.x 首次启动时导入一次，作为密钥库 `vault`。
+
+对于只在某个 playbook 内部使用的密钥，您也可以使用 `community.hashi_vault`
+lookup 插件，它直接从 Vault 读取，绕过 AnsibleForms。
+
+---
+
+## 集成
+
+### 查询 AWX/Tower/AAP
+
+从 AWX 或 Ansible Automation Platform 查询信息。
+
+要用来自 AWX 或 Tower 的数据填充下拉框，请使用 `fn.fnRestBasic` 或 `fn.fnRestJwtSecure`。从 7.3.0 起，这些辅助函数会检查
+AWX 地址的证书：如果是自签名证书，请用 `NODE_EXTRA_CA_CERTS` 信任其 CA，或者把
+[`REST_IGNORE_CERTS`](customization/security.html#env_REST_IGNORE_CERTS) 设为 `1`。
+
+```yaml
+name: Query awx
+type: awx
+runner: myAwxConfigName # a runner of type awx
+template: my_template # will be overwritten by the field __template__
+description: ""
+awxCredentials:
+  - vmware
+executionEnvironment: my_execution_environment
+roles:
+  - default
+categories: []
+inventory: my_inventory # will be overwritten by the field __inventory__
+tileClass: bg-info-subtle
+icon: bullseye
+fields:
+  # make sure you add credentials called "awx_rest" where the password holds the token
+  # if you like basic authentication, switch the expressions below to fn.fnRestBasic instead
+
+  - name: organization
+    label: Organization
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/organizations','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: id # => we want the organisation field to hold the id !!
+  - name: __template__  # use this special name to override the template from the form
+    label: Template
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/job_templates?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name
+  - name: __inventory__  # use this special name to override the inventory from the form
+    label: Inventory
+    type: enum
+    default: __auto__
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/inventories?organization=$(organization)','','awx_rest','[.results[]]')"
+    columns:
+      - name
+    valueColumn: name    
+  - name: __awxCredentials__  # use this special name to override the credentials from the form
+    label: Credentials
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/credentials?organization=$(organization)','','awx_rest','[.results[]]')"
+    multiple: true
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name     
+  - name: __executionEnvironment__  # use this special name to override the executionEnvironment from the form
+    label: Execution environment
+    type: enum
+    expression: "fn.fnRestJwtSecure('get','https://172.16.50.1/api/v2/execution_environments?organization=$(organization)','','awx_rest','[.results[]]')"
+    default: __auto__
+    columns:
+      - name
+    valueColumn: name           
+```
+
+---
+
+## 自定义
+
+### 自定义
+
+自定义 AnsibleForms。
+
+AnsibleForms 是一个 Web 应用。在 Node.js 中原生运行时，您可以替换或修改它的文件。  
+不过，推荐的做法是以 Docker 镜像运行它，并添加卷或文件映射。Docker Compose 项目已经映射了一些目录，用于持久保存数据库、playbook、日志、证书和 SSH 密钥，您还可以添加更多映射。自定义徽标在 **徽标** 设置页面上传。  
+`custom.js` 文件存放您自己的 JavaScript 函数，供表达式使用。内置函数使用前缀 `fn.`（例如 fn.fnRestBasic）；自定义函数使用前缀 `fnc.`。  
+同样，您可以在 `jq.custom.definitions` 文件中添加您自己的 jq 定义。
+
+```yaml
+volumes:
+  # Mount application folder to host folder (to maintain persistency)
+  - ./data:/app/dist/persistent
+  # Map custom functions for js expressions and jq
+  - ./data/functions/custom.js:/app/dist/src/functions/custom.js
+  - ./data/functions/jq.custom.definitions:/app/dist/src/functions/jq.custom.definitions
+  # Map custom sshkey to local node .ssh location
+  - ./data/ssh:$HOME_DIR/.ssh
+  - ./data/git/.gitconfig:$HOME_DIR/.gitconfig
+```
+
+### 启用 YTT
+
+启用 ytt。
+
+要使用 ytt，请设置 `USE_YTT=1`。  
+关于 ytt 的更多信息，请参见 https://carvel.dev/ytt/。
+
+{: .important }  
+> 此功能尚未经过广泛测试，自作为增强功能加入以来也没有收到任何反馈。  
+> 使用 ytt 时，必须禁用设计器：设计器会把 YAML 文件转换为中间 JSON，从而丢掉 ytt 语法（它由 YAML 注释构成）。
+
+根目录中必须存在一个 `lib` 目录；它会自动包含在 ytt 调用中。
+可以通过设置带前缀的环境变量来全局提供数据：  
+
+```bash
+YTT_VARS_PREFIX=YTT_VAR
+YTT_VAR_INVENTORY_PATH=/tmp/inventory.yml
+YTT_VAR_default_host=localhost
+```  
+
+或者提供库数据文件：
+
+```bash
+YTT_LIB_DATA_DEMO=/tmp/demo_data.yml
+```  
+
+```yaml
+# /tmp/demo_data.yml
+message: 'hello demo'
+```
+
+**库 `demo` 必须存在于 ytt 上下文中（lib/_ytt_lib/demo/values.yml）**
+
+```yaml
+# lib/_ytt_lib/demo/values.yml
+#@ data/values
+---
+demo: {}
+```  
+
+然后就可以使用加载的数据：
+
+```yaml
+# config.yaml
+#@ load("@ytt:data", "data")
+#@ load("@ytt:library", "library")
+#@ demo = library.get("demo")
+---
+categories:
+  - name: Default
+    icon: bars
+roles:
+  - name: admin
+    groups:
+      - local/admins
+constants:
+  data_values: #@ data.values
+  demo: #@ demo.data_values()
+```
+
+---
+
+## 访问控制
+
+### 如何限制用户能做的事（角色选项）？
+
+除了限制角色可以看到哪些表单之外，角色的 `options` 还可以为其成员开启或关闭界面功能。
+所有选项、其默认值以及选项在多个角色之间如何组合，请参见 [角色选项](config/roles.html#role-options)。
+
+### 如何在 playbook 或表单中实现自定义 RBAC 逻辑？
+
+每次执行时，前端和后端都可以获得用户身份。
+
+每次提交表单时，AnsibleForms 都会自动把当前用户的完整身份注入发送给 Ansible 的 extravars 中：
+
+```yaml
+ansibleforms_user:
+  username: jane.doe
+  groups:
+    - local/admins
+    - ldap/network-team
+  roles:
+    - admin
+    - operators
+  options:
+    showLogs: true
+    allowJobRelaunch: true
+    # ...all resolved role options
+```
+
+因此，您的 playbook 或任何自定义 Ansible 模块都可以直接使用 `ansibleforms_user` 做细粒度的决策，例如只允许某些组修改生产清单，或者用提交者的用户名写入审计记录。
+
+在 **前端**，同一个对象可以通过特殊字段 `__user__` 获得：
+
+```yaml
+fields:
+  - name: is_admin
+    type: expression
+    runLocal: true
+    hide: true
+    expression: "$(__user__.roles).includes('admin')"
+
+  - name: target_env
+    type: enum
+    # hide the production option for non-admins by cross-referencing __user__
+    expression: |
+      $(__user__.roles).includes('admin')
+        ? ['dev','staging','production']
+        : ['dev','staging']
+    runLocal: true
+    default: __auto__
+```
+
+**典型模式：**
+
+用户身份支持以下这些模式：
+
+- **对照 RBAC 配置文件或数据库**：加载一个把组映射到允许资源的 YAML 或 JSON 文件（用 `fn.fnReadYamlFile` 或表达式），然后按 `$(__user__.groups)` 进行筛选
+- **审计记录**：把 `ansibleforms_user.username` 作为额外变量传入，记录是谁触发了作业
+- **动态字段值**：根据用户的组或角色，显示不同的 enum 选项、预填字段或隐藏某些部分
+- **playbook 端授权**：在 playbook 继续执行之前，断言 `ansibleforms_user.groups` 包含所需的组，作为独立于表单 `roles` 列表的纵深防御检查
+
+{: .note }
+> 上面的对象是默认发送的内容。如果实例设置了 `EXTRAVARS_USER_FIELDS`，
+> 或者表单设置了 `userExtravars`，则只发送其中指定的键，因此对
+> `ansibleforms_user.groups` 进行断言的 playbook 要求 `groups` 在其中。前端的
+> `__user__` 字段来自登录令牌，从不会被这两个设置裁剪。
+
+---
+
+## 作业调度
+
+### 如何让表单自动按计划运行？
+
+打开 **提交** 旁边的下拉菜单，选择 **调度（周期性）** 或 **稍后运行（一次性）**；它们分别需要角色
+选项 `allowScheduledJobs`（管理员级别）和 `allowPlannedJobs`。参见 [调度](jobs/schedules.html)。
+
+### 可以使用哪些 cron 表达式？
+
+周期性调度接受标准的 5 字段 cron 表达式（分、时、日、月、星期）。
+
+| 表达式 | 运行时间 |
+|---|---|
+| `*/15 * * * *` | 每 15 分钟 |
+| `0 * * * *` | 每小时整点 |
+| `0 */6 * * *` | 每 6 小时，在 00:00、06:00、12:00 和 18:00 |
+| `0 2 * * *` | 每天 02:00 |
+| `30 7 * * 1-5` | 周一至周五 07:30 |
+| `0 8 * * MON` | 每周一 08:00（接受星期和月份的英文名称） |
+| `0 0 1 * *` | 每月第一天的午夜 |
+| `0 22 L * *` | 每月最后一天的 22:00 |
+| `0 6 * * 1#1` | 每月第一个周一的 06:00 |
+| `*/30 * * * * *` | 每 30 秒（前面可选的第六个字段是秒） |
+
+当同时设置了日和星期时，只要其中任一匹配，调度就会运行：`0 0 13 * 5` 会在
+每月 13 日以及每个周五运行。服务器会拒绝它无法运行的表达式，或者永远不会出现的表达式（`0 0 30 2 *`）。
+
+在 **调度** 页面上，cron 编辑器会描述表达式并预览接下来的运行时间。它不接受 `@daily` 这样的
+别名、`?` 通配符或 `W`（最近工作日）修饰符，因此请使用表中的这些写法。
+
+{: .note }
+> **时区** cron 调度按服务器的时区运行，该时区用 [`LOG_TZ`](customization/logging.html#env_LOG_TZ) 设置
+> （默认 `UTC`），而不是您的个人资料或浏览器的时区。在 `LOG_TZ=Europe/Madrid` 时，`0 2 * * *` 全年都在马德里时间
+> 02:00 运行，并跟随夏令时变化。cron 编辑器在同一时区中预览接下来的运行。仓库的
+> 拉取调度也使用同一时区。
+
+---
+
+## 保存和加载表单数据
+
+### 如何在不运行作业的情况下保存并重新加载表单数据？
+
+在 **提交** 旁边的下拉菜单中选择 **保存** 来保存字段值，以后再用 **从已保存项加载** 恢复它们。
+密码字段从不存储。这需要角色选项 `allowStoredJobs`。参见 [保存的作业](jobs/stored-jobs.html)。
+
+---
+
+## 嵌套表单和结构化字段
+
+### 如何在表单中收集结构化或重复的数据？
+
+使用带子表单的 `list` 和 `yaml` 字段（6.2.0+）。
+
+要收集复杂的结构化数据，例如服务器列表、一组网络接口或单个嵌套对象，请把 `list` 或 `yaml` 字段类型与 `subform` 一起使用。
+
+**子表单** 是一个可复用的表单片段（用 `type: subform` 定义），从不作为独立的磁贴显示。它只为了被其他表单中的字段引用而存在。完整参考请参见 [子表单文档](forms/subform.html)。
+
+**收集结构化行的列表：`list` 字段：**
+
+`list` 字段为每一行打开一次所引用的子表单：
+
+```yaml
+- name: Server
+  type: subform
+  fields:
+    - name: hostname
+      type: text
+      required: true
+    - name: ip
+      type: text
+      regex:
+        expression: ^\d+\.\d+\.\d+\.\d+$
+        description: Must be an IPv4 address
+
+- name: Deploy to servers
+  type: ansible
+  roles:
+    - default
+  playbook: deploy.yml
+  fields:
+    - name: servers
+      type: list
+      subform: Server   # opens Server subform in a drilldown editor per row
+```
+
+发送给 Ansible 的 `servers` extravar 是一个对象数组：`[{hostname: "web1", ip: "10.0.0.1"}, ...]`
+
+**编辑单个结构化对象：`yaml` 字段：**
+
+`yaml` 字段有三种模式：
+
+| 模式 | 方式 | 行为 |
+|---|---|---|
+| **编辑器** | 默认 | 显示完整的带 YAML 语法高亮的编辑器，用户可以直接输入 |
+| **只读** | `readonly: true` | 把 YAML 值渲染为格式化的只读文本，不能编辑 |
+| **子表单** | `subform: MySubform` | 隐藏原始编辑器；点击时以下钻编辑器的形式打开子表单 |
+
+```yaml
+fields:
+  # editor mode (default)
+  - name: raw_config
+    type: yaml
+
+  # readonly mode
+  - name: generated_config
+    type: yaml
+    readonly: true
+
+  # subform mode
+  - name: network_config
+    type: yaml
+    subform: NetworkConfig   # opens NetworkConfig subform as a drilldown editor
+```
+
+**上传和下载：`list` 和 `yaml` 字段：**
+
+两种字段类型都通过两个可选属性支持客户端的文件传输：
+
+```yaml
+fields:
+  - name: servers
+    type: list
+    subform: Server
+    showLoadButton: true      # shows an Upload button: imports content from a local file
+    showDownloadButton: true  # shows a Download button: exports current content to a file
+
+  - name: config
+    type: yaml
+    showLoadButton: true
+    showDownloadButton: true
+```
+
+{: .note }
+> `list` 字段和 `subform` 表单类型取代了 `table` 字段和 `tableFields`，后两者已在 7.0.0 中移除。
+
+### 如何在子表单中访问父表单的数据？
+
+在子表单中通过 `__parent__` 引用父表单字段的值（v6.3.0+）。
+
+子表单打开时，无论是从 **`list`** 字段（每个行编辑器）还是从子表单模式的 **`yaml`** 字段打开，AnsibleForms 都会自动向子表单注入一个名为 `__parent__` 的特殊只读字段。它包含 **子表单打开时父表单中所有字段值** 的快照，包括常量和变量。
+
+这样，子表单字段无需任何额外配置，就能使用引用父表单数据的表达式。
+
+#### `__parent__` 中有什么？
+{: .no_toc }
+
+`__parent__` 是一个普通对象，其键为父表单的字段名：
+
+```yaml
+__parent__:
+  environment: production          # a regular field
+  region: eu-west-1
+  max_nodes: 10
+  owner: jane.doe                  # a constant
+  default_image: ubuntu-22.04      # from varsFiles
+  __user__:                        # system fields are also included
+    username: jane.doe
+    roles: [admin]
+```
+
+{: .note }
+> `__parent__` **不会发送给 Ansible**；与 `__user__` 一样，它会从 extravars 中剔除。它纯粹是供子表单内部表达式使用的前端辅助字段。
+
+#### 在子表单表达式中访问父表单的值
+{: .no_toc }
+
+用标准的 `$(...)` 表达式语法引用父表单的值：
+
+```yaml
+- name: NodeConfig
+  type: subform
+  fields:
+    - name: node_name
+      type: text
+      label: Node name
+      required: true
+
+    - name: image
+      type: enum
+      label: Image
+      # default to the parent form's chosen image
+      expression: "'$(__parent__.default_image)'"
+      runLocal: true
+
+    - name: is_production
+      type: expression
+      hide: true
+      runLocal: true
+      expression: "'$(__parent__.environment)' === 'production'"
+
+    - name: node_type
+      type: enum
+      # only offer gpu nodes in production
+      expression: |
+        '$(__parent__.environment)' === 'production'
+          ? ['standard', 'high-memory', 'gpu']
+          : ['standard', 'high-memory']
+      runLocal: true
+      default: __auto__
+
+- name: Deploy cluster
+  type: ansible
+  roles:
+    - default
+  playbook: deploy_cluster.yml
+  fields:
+    - name: environment
+      type: enum
+      values: [dev, staging, production]
+
+    - name: default_image
+      type: text
+      default: ubuntu-22.04
+
+    - name: nodes
+      type: list
+      subform: NodeConfig
+      columns: [node_name, node_type]
+```
+
+#### 嵌套子表单
+{: .no_toc }
+
+`__parent__` 始终指向 **直接父级** 表单。如果您在一个本身从父表单打开的子表单中嵌套了一个 `list`，内层子表单的 `__parent__` 保存的是中间那个子表单的数据。要访问更上层，如果中间的子表单也传递了它自己的 `__parent__`，可以链式引用，例如 `$(__parent__.__parent__.someField)`。
+
+### 如何从 `table` / `tableFields` 迁移到 `list` / `subform`？
+
+`table` 字段和 `tableFields` 属性在 6.2.0 中弃用，并在 7.0.0 中移除，仍在使用它们的表单会验证失败。迁移方法：
+
+1. 把 `tableFields` 中的列提取到一个新的 `type: subform` 表单中，使用常规的 `formfields`
+2. 把 `table` 字段替换为一个通过 `subform: MySubformName` 引用该子表单的 `list` 字段
+
+**之前：**
+```yaml
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: table
+      tableFields:
+        - name: username
+          type: text
+        - name: email
+          type: text
+```
+
+**之后：**
+```yaml
+- name: User
+  type: subform
+  fields:
+    - name: username
+      type: text
+    - name: email
+      type: text
+
+- name: Manage users
+  type: ansible
+  roles:
+    - default
+  playbook: users.yml
+  fields:
+    - name: users
+      type: list
+      subform: User
+```
+
+#### 把 `tableFields` 中的 `from` 迁移为 `__parent__` 表达式
+{: .no_toc }
+
+`tableFields` 中 enum 列的 `from` 属性会从父表单的另一个字段填充下拉选项。在 `subform` 中，它被一个通过 `__parent__` 读取同一个值的 `expression` 所取代。
+
+**之前：带 `from` 的 `tableFields`：**
+
+```yaml
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: table
+      tableFields:
+        - name: department
+          type: enum
+          from: available_departments   # pulls choices from the parent field above
+        - name: firstname
+          type: text
+```
+
+**之后：带 `__parent__` 表达式的子表单：**
+
+```yaml
+- name: Member
+  type: subform
+  fields:
+    - name: department
+      type: enum
+      # replaces "from: available_departments"
+      expression: "$(__parent__.available_departments)"
+      runLocal: true
+
+    - name: firstname
+      type: text
+
+- name: Manage members
+  type: ansible
+  roles:
+    - default
+  playbook: members.yml
+  fields:
+    - name: available_departments
+      type: expression
+      expression: "['HR','Engineering','Finance']"
+      runLocal: true
+      hide: true
+
+    - name: members
+      type: list
+      subform: Member
+```
+
+{: .note }
+> `$(__parent__.available_departments)` 返回该字段的 **当前值**，因此如果该字段本身是一个动态的 expression 字段，子表单看到的始终是父表单中最新的求值结果。
diff --git a/i18n/zh/_reference/getting-help.md b/i18n/zh/_reference/getting-help.md
new file mode 100644
index 0000000..b4e2841
--- /dev/null
+++ b/i18n/zh/_reference/getting-help.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: 获取帮助
+nav_order: 3
+translated_from: dfdabe97bba34b6e588429ab17c3c458a136c81c
+---
+
+# 获取帮助
+{: .no_toc }
+
+在哪里提问、报告 bug 或安全问题，以及提出改进建议
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 提问之前
+
+大多数答案都已经写在文档里了；快速查一下往往能省去一来一回：
+
+1. 使用每个页面顶部的搜索框搜索本站。
+2. 在 [故障排查](troubleshooting.html) 中查找确切的错误消息，并浏览一下 [常见问题](faq.html)。
+3. 查看服务器日志（**设置**，然后 **服务器日志**）和 **状态** 页面，它们会报告大多数配置问题。
+4. 查看 [更新日志](changelog.html)：问题可能已在更新的版本中修复。
+
+---
+
+## 去哪里
+
+每类请求都有各自的去处，全部在 GitHub 上：
+
+| 您想要 | 前往 |
+|---|---|
+| 提问或分享想法 | [Discussions](https://github.com/ansibleforms/ansibleforms/discussions) |
+| 报告 bug | [New issue → Bug report](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| 建议新功能 | [New issue → Feature request](https://github.com/ansibleforms/ansibleforms/issues/new/choose) |
+| 报告安全问题 | [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)，私下报告 |
+| 修正或改进本文档 | 任意页面底部的 **Edit this page on GitHub**，或 [网站的 issue](https://github.com/ansibleforms/website/issues) |
+
+---
+
+## 报告 bug
+
+可以复现的报告修复得最快。bug 报告模板会要求提供以下内容：
+
+* **版本**：显示在顶栏帮助（**?**）菜单的 **关于** 下
+* **部署方式**：Docker、Docker Compose、Kubernetes、安装程序（及其引擎）、原生安装或从源码安装
+* **复现步骤**：您做了什么、期望发生什么，以及实际发生了什么
+* **证据**：服务器日志中的相关行，问题可见时附上截图
+
+如果是表单的问题，请附上一个能体现问题的最小表单定义。发布之前，请从日志和表单中删除密码、令牌、主机名和其他
+任何隐私数据：issue 和讨论都是公开的。
+
+---
+
+## 报告安全问题
+
+**切勿为此开公开 issue：** 请使用 [Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)，只有维护者能看到。
+
+[安全策略](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) 列出了受支持的版本，以及
+报告之后会发生什么。
diff --git a/i18n/zh/_reference/troubleshooting.md b/i18n/zh/_reference/troubleshooting.md
new file mode 100644
index 0000000..609da19
--- /dev/null
+++ b/i18n/zh/_reference/troubleshooting.md
@@ -0,0 +1,759 @@
+---
+layout: default
+title: 故障排查
+nav_order: 4
+translated_from: b7b3f3dfe9b603afe24b167dcc2fc117601638d5
+---
+
+# 故障排查
+{: .no_toc }
+
+错误消息和症状、其原因以及解决方法
+{: .fs-6 .fw-300 }
+
+---
+
+下面每个问题都以您看到的消息或症状作为标题，随后是原因和解决方法。消息完全按照
+AnsibleForms 写出的原文引用；`<name>` 表示因情况而异的值。其中大多数会出现在服务器
+日志中，您可以在 [服务器日志](gui/administration.html#server-log) 下或通过 `docker logs` 查看。
+
+**数据库和启动**
+
+* [Mysql not ready yet](#mysql-not-ready-yet)
+* [Schema is not ready, skipping group and user initialization](#schema-is-not-ready-skipping-group-and-user-initialization)
+* [Schema creation is disabled](#schema-creation-is-disabled)
+* [Config seed failed, refusing to start](#config-seed-failed-refusing-to-start)
+* [ENCRYPTION_SECRET is not set](#encryption_secret-is-not-set)
+
+**配置和表单**
+
+* [Could not load the forms](#could-not-load-the-forms)
+* [基础配置中有 forms 部分](#the-base-config-has-a-forms-section)
+* [仪表板上缺少某个表单](#a-form-is-missing-from-the-dashboard)
+* [Could not save the forms](#could-not-save-the-forms)
+* [The editor is read-only](#the-editor-is-read-only)
+* [Abuse attempt of eval function](#abuse-attempt-of-eval-function)
+* [Destination is not in REST_ALLOWED_HOSTS](#destination-is-not-in-rest_allowed_hosts)
+
+**登录**
+
+* [Authentication failed: Invalid credentials](#authentication-failed-invalid-credentials)
+* [LDAP check failed](#ldap-check-failed)
+* [Azure AD 或 OIDC 身份验证失败](#azure-ad-or-oidc-authentication-failed)
+* [Not authenticated, login is not enabled for this user](#not-authenticated-login-is-not-enabled-for-this-user)
+* [重启后或一天后被注销](#logged-out-after-a-restart-or-after-a-day)
+* [单点登录后表单和作业为空（HTTP 431）](#empty-forms-and-jobs-after-a-single-sign-on-http-431)
+
+**作业**
+
+* [Playbook failed with status](#playbook-failed-with-status)
+* [Playbook was aborted by the main process](#playbook-was-aborted-by-the-main-process)
+* [Failed to launch awx template](#failed-to-launch-awx-template)
+* [作业显示状态 abandoned](#a-job-shows-the-status-abandoned)
+* [RTE 无法连接](#an-rte-does-not-connect)
+* [The form data is not valid](#the-form-data-is-not-valid)
+
+**Git 仓库和备份**
+
+* [仓库克隆或拉取失败](#a-repository-clone-or-pull-failed)
+* [表单仓库尚未克隆](#the-forms-repository-is-not-cloned-yet)
+* [备份失败](#a-backup-failed)
+
+[常见问题](faq.html) 深入介绍了两个相关的问题：
+[丢失管理员密码](faq.html#recovering-a-lost-admin-password) 和
+[限制 REST 辅助函数的目标](faq.html#restricting-rest-helper-destinations-allowdeny-lists)。
+
+---
+
+## Mysql not ready yet
+
+AnsibleForms 无法启动，日志每 5 秒重复以下几行：
+
+```
+Waiting for mysql to start
+[ansibleforms] Query error : Error: <reason>
+Mysql not ready yet
+```
+
+**原因**
+
+启动时，AnsibleForms 会等待数据库响应查询，只要数据库不响应，它就一直等待。
+`<reason>` 是数据库驱动自身的消息：连接被拒绝或超时说明主机或端口有问题，
+拒绝访问的消息则说明用户名或密码有问题。
+
+**解决方法**
+
+检查 [`DB_HOST`](customization/server.html#env_DB_HOST)、[`DB_PORT`](customization/server.html#env_DB_PORT)、
+[`DB_USER`](customization/server.html#env_DB_USER) 和 [`DB_PASSWORD`](customization/server.html#env_DB_PASSWORD)。
+在容器内部，`localhost` 指的是容器本身，而不是运行 MySQL 的主机。请确保 MySQL 监听
+某个网络地址，并且该用户可以从 AnsibleForms 主机连接。数据库一旦响应，AnsibleForms 就会自行
+继续；无需重启。
+
+---
+
+## Schema is not ready, skipping group and user initialization
+
+浏览器打开的是数据库页面而不是登录页面，日志显示：
+
+```
+Schema is not ready, skipping group and user initialization
+Please create the schema via the /schema endpoint
+```
+
+**原因**
+
+`AnsibleForms` schema 缺失或不完整。*空* 数据库会在启动时自动初始化，除非
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) 为 `0`。如果初始化失败，例如因为
+数据库用户无权创建 schema，日志会显示 `Failed to create the schema automatically : <reason>`。已存在但
+缺少表的 schema（`Table '<name>' is not present`）永远不会被自动重建，因为创建
+schema 会先删除所有表。此时数据库页面会显示 *It appears that you have an unuseable schema*。
+
+**解决方法**
+
+在全新安装上，授予数据库用户创建 `AnsibleForms` schema 的权限并重启，或在数据库页面上点击
+**新建**。对于部分存在的 schema，请恢复备份，或删除不完整的 `AnsibleForms`
+schema，以便 AnsibleForms 重新创建它。日志会列出哪些表和补丁失败了。
+
+---
+
+## Schema creation is disabled
+
+从数据库页面或通过 `POST /api/v2/schema` 创建 schema 时失败，显示：
+
+```
+Schema creation is disabled
+```
+
+**原因**
+
+[`ALLOW_SCHEMA_CREATION`](customization/server.html#env_ALLOW_SCHEMA_CREATION) 为 `0`，这会同时关闭启动时的自动
+创建和该端点。在已有用户的数据库上，该端点还会拒绝未以管理员身份登录的调用方，
+显示 `Schema creation requires an authenticated administrator`。
+
+**解决方法**
+
+用 `ALLOW_SCHEMA_CREATION=1`（这是默认值）创建一次 schema，或从备份中恢复它，然后把该
+变量改回 `0`。在已初始化的数据库上，重建 schema 之前请以管理员身份登录，并记住
+重建会删除并重新创建所有表。
+
+---
+
+## Config seed failed, refusing to start
+
+容器启动后立即退出，其输出以下面这行结束：
+
+```
+Config seed failed, refusing to start : <reason>
+```
+
+**原因**
+
+[`CONFIG_SEED_PATH`](customization/configuration.html#env_CONFIG_SEED_PATH) 中的文件无法应用：例如它不是有效的
+YAML，或违反了种子的 schema；`<reason>` 说明了问题所在。AnsibleForms 宁可拒绝启动，也不会
+在只有一半声明对象的情况下运行。原因也会写入标准错误，因此 `docker logs` 和 `kubectl logs` 会显示它。
+
+**解决方法**
+
+修正 `<reason>` 指出的问题后重新启动。种子如何应用，参见 [重新加载和启动](seed/reloading.html)；
+有效的文件，参见 [示例](seed/example.html)。
+
+---
+
+## ENCRYPTION_SECRET is not set
+
+每次启动都会记录以下警告：
+
+```
+[SECURITY] ENCRYPTION_SECRET is not set. Stored passwords are encrypted with the default key, which is public in the source code. Set ENCRYPTION_SECRET: the stored ones are re-encrypted with it on the next start.
+```
+
+或者 worker 拒绝启动，显示：
+
+```
+[SECURITY] The stored secrets were encrypted with a key that is not ENCRYPTION_SECRET: set ENCRYPTION_SECRET_PREVIOUS to the key they were encrypted with, and they are re-encrypted with ENCRYPTION_SECRET on the next start. Nothing was changed.
+```
+
+**原因**
+
+存储的密钥用 [`ENCRYPTION_SECRET`](customization/security.html#env_ENCRYPTION_SECRET) 加密：从 7.3.0 起，它们保存在
+凭据中（包括 LDAP 目录、SSO 提供方、运行器和密钥库等的密码和令牌），与 Slack
+和 Teams webhook 地址放在一起。没有它时，会使用一个在源代码中公开的密钥。从 7.3.0 起，使用新的
+`ENCRYPTION_SECRET` 启动时，会在一个事务中用它重新加密所有存储的密钥：首次设置时从默认密钥重新加密，
+修改时从 [`ENCRYPTION_SECRET_PREVIOUS`](customization/security.html#env_ENCRYPTION_SECRET_PREVIOUS) 重新加密。如果
+存储的密钥既不是用前者也不是用后者加密的，则不做任何更改，AnsibleForms 也不会启动。
+
+**解决方法**
+
+设置 `ENCRYPTION_SECRET`，并把它与您的其他密钥放在一起保管：备份中从不包含它。下次启动时会记录
+`[SECURITY] Re-encrypted <n> stored secrets from the default key with ENCRYPTION_SECRET`。以后要更换它时，在一次启动中把新值设在
+`ENCRYPTION_SECRET`，把旧值设在 `ENCRYPTION_SECRET_PREVIOUS`，然后删除 `ENCRYPTION_SECRET_PREVIOUS`。如果
+worker 拒绝启动，请把 `ENCRYPTION_SECRET_PREVIOUS` 设为加密这些密钥时所用的密钥，或者把旧值改回来。
+
+---
+
+## Could not load the forms
+
+仪表板不显示任何表单，并报告：
+
+```
+Could not load the forms.
+
+Failed to get forms list
+
+<reason>
+```
+
+**原因**
+
+基础配置（`config.yaml`）无法读取或无效。`<reason>` 说明了是哪种情况：
+
+| 原因 | 起因 |
+|--------|-------|
+| `Error parsing the base config, it's not valid yaml. : <error>` | YAML 语法错误 |
+| `The base config has no content. It must be a yaml mapping holding at least 'categories' and 'roles'.` | 文件为空，或只有注释 |
+| `Duplicate role name(s) : <names>. Each role must appear once.` | 同一个角色定义了两次 |
+| `There is no config.yaml nor could one be created from template.` | `config.yaml` 缺失，且其文件夹不可写 |
+| `There is no forms directory nor could there be one created from template.` | 表单文件夹缺失且无法创建 |
+| 其他任何内容 | 配置违反了 schema，例如角色没有 `groups` |
+
+**解决方法**
+
+修正 [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) 所指的文件，或用于配置的仓库中的
+`config.yaml`。如果缺少文件，请让 [`CONFIG_PATH`](customization/paths.html#env_CONFIG_PATH) 和
+[`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) 指向一个可写的持久化位置。结构
+参见 [config.yaml](config/)。
+
+---
+
+## 基础配置中有 forms 部分
+
+从 6.x 升级后仪表板为空，警告面板显示：
+
+```
+The base config has a 'forms' section. Since 7.0.0 forms are no longer read from the base config - move each form to its own file in the forms folder (FORMS_FOLDER_PATH).
+```
+
+**原因**
+
+从 7.0.0 起，每个表单都存放在表单文件夹中自己的文件里。仍列在 `config.yaml` 中的表单会被
+忽略。
+
+**解决方法**
+
+把每个表单移到 [`FORMS_FOLDER_PATH`](customization/paths.html#env_FORMS_FOLDER_PATH) 中自己的文件里。参见
+[升级到 7.x](upgrade-7.html)。
+
+---
+
+## 仪表板上缺少某个表单
+
+表单文件存在，但某个用户在仪表板上看不到该表单。
+
+**原因**
+
+只有当表单的某个 `roles` 是用户的角色之一时，用户才能看到该表单；管理员可以看到所有表单。每个用户都有
+`default` 角色，因此 `roles: [default]` 的表单对所有人可见。用户的角色来自 `config.yaml` 中
+`roles` 下列出的组和用户。没有 `categories` 的表单显示在 **Default** 下，因此在
+其他类别中看不到它，但它仍列在 **所有表单** 下。最后，验证失败的表单会被跳过。此时
+仪表板会显示一个 **此配置有警告或错误** 按钮，点击后会显示如下消息：
+
+```
+Failed to validate form '<name>'.
+skipping duplicate form <name>
+Form found with no name.
+```
+
+**解决方法**
+
+打开警告面板，修正其中列出的问题。在个人资料的 [权限](profile/permissions.html) 下检查用户的角色，
+并检查表单的 `roles` 和 `categories`。参见 [角色](config/roles.html) 和 [类别](config/categories.html)。如果两个文件定义了同一个表单名称，
+先加载的那个生效。
+
+---
+
+## Could not save the forms
+
+在设计器中保存时失败，显示：
+
+```
+Could not save the forms.
+
+Failed to save forms
+
+<messages>
+```
+
+**原因**
+
+设计器在写入任何内容之前，会按照 schema 验证每个表单。`<messages>` 的每一行都指出了
+违反规则的表单和字段。7.0.0 中移除的选项会有专门的消息，例如
+`Field '<name>' : the table field was removed in 7.0.0, see https://ansibleforms.com/upgrade-7 - use a list field with a subform`。
+
+**解决方法**
+
+修正消息中指出的字段。对于 7.0.0 移除的选项，请遵循 [升级到 7.x](upgrade-7.html)。
+要在表单文件进入 AnsibleForms 之前验证它们，请参见常见问题中的
+[VS Code 中表单文件的验证](faq.html#vs-code-validation-for-form-files)。
+
+---
+
+## The editor is read-only
+
+设计器显示 **已被锁定** 及另一个用户的名称，保存时失败，显示：
+
+```
+The editor is read-only
+```
+
+**原因**
+
+同一时间只能有一个人编辑表单。有人启动设计器时会获取锁，并一直保持到
+他们停止设计器为止，即使他们没有停止设计器就关闭了浏览器也是如此。API 会拒绝其他任何人的保存，显示
+`Designer is locked by <username>`。
+
+**解决方法**
+
+请 `<username>` 停止设计器。如果无法做到，请在设计器中使用 **强制解锁**。持有锁的人
+会丢失尚未保存的更改。
+
+---
+
+## Abuse attempt of eval function
+
+表达式字段显示错误，日志中有如下一行：
+
+```
+Error in expression : Error: Abuse attempt of eval function, using custom functions, try runLocal
+```
+
+**原因**
+
+服务器端表达式在运行前会被检查。它们只能调用 `fn.` 和 `fnc.` 函数；多条语句、
+多行、模板字面量、`process.env` 以及 `require` 或 `constructor` 等词都会被拒绝。消息
+会说明违反了哪条规则。如果 [`EXPRESSION_SANITIZER`](customization/security.html#env_EXPRESSION_SANITIZER) 设为
+`off`，所有服务器表达式都会失败，显示
+`Server expressions are disabled (EXPRESSION_SANITIZER=off), use runLocal`。
+
+**解决方法**
+
+把表达式改写为单个 `fn.` 调用或简单的运算，或者用 `runLocal: true` 在浏览器中运行它。参见
+[表达式](expressions/) 和 [本地表达式](expressions/local.html)。
+
+---
+
+## Destination is not in REST_ALLOWED_HOSTS
+
+调用 REST API 的字段保持为空，日志显示：
+
+```
+Error in expression : Error: [hostfilter] destination <host> (<addresses>) is not in REST_ALLOWED_HOSTS
+```
+
+**原因**
+
+设置了 [`REST_ALLOWED_HOSTS`](customization/security.html#env_REST_ALLOWED_HOSTS)，而 URL 的主机不在其中。
+匹配 [`REST_DENIED_HOSTS`](customization/security.html#env_REST_DENIED_HOSTS) 的主机会被拒绝，显示
+`blocked by REST_DENIED_HOSTS entry "<entry>"`；无法解析的主机则显示 `cannot resolve <host>`。
+
+**解决方法**
+
+把该主机名或覆盖其地址的 CIDR 添加到 `REST_ALLOWED_HOSTS`，或者从
+`REST_DENIED_HOSTS` 中删除阻止它的条目。参见 [限制 REST 辅助函数的目标](faq.html#restricting-rest-helper-destinations-allowdeny-lists)。
+
+---
+
+## Authentication failed: Invalid credentials
+
+登录页面拒绝用户名和密码，显示：
+
+```
+Authentication failed: Invalid credentials
+```
+
+**原因**
+
+登录页面对所有失败都给出相同的回答，以免泄露某个用户是否存在。AnsibleForms
+先尝试本地用户，然后尝试 LDAP：有多个目录时，会按照 **访问 > LDAP** 下的顺序查找用户名，
+除非用户名指定了某个目录（`corp\jane`）或其某个登录域（`jane@corp.example`）。真正的原因会写入日志。LDAP
+失败记录为 `Error connecting to ldap: <reason>`，原因例如 `Wrong binding credentials` 或
+`Unable to verify the certificate`；Active Directory 的代码会被转换为 `Wrong password`、`User not found`、
+`Account disabled`、`Account locked` 或 `Password expired`。
+
+**解决方法**
+
+阅读日志中的原因。要查看每次登录失败的完整原因，请把
+[`LOG_LEVEL`](customization/logging.html#env_LOG_LEVEL) 设为 `debug`，这会记录 `Ldap authentication failed: <reason>`。
+如果丢失了本地管理员密码，请参见 [找回丢失的管理员密码](faq.html#recovering-a-lost-admin-password)。
+
+---
+
+## LDAP check failed
+
+在 **访问 > LDAP** 下测试 LDAP 目录时失败，显示以下之一：
+
+```
+LDAP check failed: Error: Wrong binding credentials
+LDAP check failed: Error: Bad server or port (connection failed)
+LDAP check failed: Error: Unable to verify the certificate
+LDAP check failed: Error: Certificate is not valid
+```
+
+**原因**
+
+绑定用户或其密码错误、服务器或端口无法访问，或者在使用 TLS 时无法根据 CA 证书包验证服务器的证书。
+从 7.3.0 起，这些设置位于目录的 ldap 凭据中，在 **连接 > 凭据** 下。不存在的测试用户
+仍算作测试成功，因为连接和绑定都成功了。
+
+**解决方法**
+
+在 **连接 > 凭据** 下打开目录所引用的凭据（默认目录为 `main`），修正绑定
+DN 及其密码、服务器和端口（通常为 389，LDAPS 为 636）。对于 TLS 问题，请粘贴签发
+LDAP 服务器证书的 CA 证书包；跳过证书检查不适用于生产环境。参见 [LDAP](authentication/ldap.html)。
+
+---
+
+## Azure AD 或 OIDC 身份验证失败
+
+单点登录后返回登录页面，显示：
+
+```
+Azure AD authentication failed: <reason>
+OIDC authentication failed: <reason>
+```
+
+**原因**
+
+身份提供方已把用户送回，但 AnsibleForms 无法完成登录。常见原因有
+`azuread login is not enabled` 或 `oidc login is not enabled`（提供方已关闭），以及 `jwt expired`，因为
+来自提供方的交接只在 5 分钟内有效。来自提供方的回调期间发生的错误也会显示
+在登录页面上，并写入日志。
+
+**解决方法**
+
+在 **访问 > SSO** 下启用提供方，并在身份提供方中注册与
+AnsibleForms 所用完全一致的回调 URL：Entra ID 为 `https://<your host>/api/v2/auth/entraid/callback`（从 7.3.0 起；`azureadoauth2` 仍然可用），
+OIDC 为 `https://<your host>/api/v2/auth/oidc/callback`。来自 7 之前或
+6.1.5 之前、包含 `/api/v1/` 的回调 URL 必须更新：否则登录页面会重新加载，既不登录也不报错。交接过期后
+请重试登录。
+
+---
+
+## Not authenticated, login is not enabled for this user
+
+拥有有效密码的用户无法登录，显示：
+
+```
+Not authenticated, login is not enabled for this user.
+```
+
+**原因**
+
+用户的某个角色把角色选项 `allowLogin` 设为了 `false`。日志显示
+`Login is disabled for user '<username>' in the configuration (allowLogin option is set to false), please check your settings`。
+
+**解决方法**
+
+从该角色中删除 `allowLogin: false`，或者把该用户移出该角色。参见 [角色](config/roles.html)。
+
+---
+
+## 重启后或一天后被注销
+
+AnsibleForms 重启后，或使用一天后，所有用户都会被送回登录页面。
+
+**原因**
+
+未设置 [`ACCESS_TOKEN_SECRET`](customization/security.html#env_ACCESS_TOKEN_SECRET) 时，每次启动都会生成一个
+新的签名密钥，并记录
+`[SECURITY] JWT signing secret was auto-generated. All tokens will be invalidated on restart. Set the ACCESS_TOKEN_SECRET environment variable for persistent token signing.`
+此后，重启之前的令牌
+不再被接受。另外，会话在其刷新令牌过期时结束
+（`Refresh token is expired`），即在
+[`ACCESS_TOKEN_REFRESH_EXPIRATION`](customization/security.html#env_ACCESS_TOKEN_REFRESH_EXPIRATION) 之后，默认 24 小时。
+
+**解决方法**
+
+把 `ACCESS_TOKEN_SECRET` 设为一个固定的保密值。如果一天太短，请调高 `ACCESS_TOKEN_REFRESH_EXPIRATION`。对于
+长期的 API 访问，请使用 [API 令牌](profile/api-token.html)。
+
+---
+
+## 单点登录后表单和作业为空（HTTP 431）
+
+用户用 Entra ID 或 OIDC 登录时没有报错，但表单和作业页面一直为空。浏览器的网络
+选项卡显示 API 调用的响应为：
+
+```
+431 Request Header Fields Too Large
+```
+
+服务器日志中没有这些调用的记录，而同一个用户使用 LDAP 或本地账户时可能一切正常。
+
+**原因**
+
+在 7.1.0 之前，登录令牌携带用户的所有组，而 Entra ID 组在其中出现两次，分别按对象 ID
+和名称。浏览器在每个请求的 `Authorization` 头中发送该令牌，因此属于大约一百个
+或更多组的用户，其请求头会远超 16 KB。Node.js 会以 431 拒绝大于 16 KB 的请求头，
+请求根本到不了 AnsibleForms，这就是没有任何日志的原因。前面的反向代理可能更早就拒绝
+请求：Nginx 默认每个头字段允许 8 KB
+（`large_client_header_buffers 4 8k`），并改为返回 400。
+
+**解决方法**
+
+升级到 7.1.0 或更高版本：登录令牌不再携带组，因此其大小不再取决于用户所属组的数量，
+并且当请求以 431 被拒绝时，界面会给出提示而不是显示空页面。
+在能够升级之前，可以：
+
+* 在 **访问 > SSO** 下为提供方设置 **组筛选**，即一个只保留您的
+  角色所用组的正则表达式，参见 [Entra ID](authentication/entra-id.html) 或 [OIDC](authentication/oidc.html)；用户重新登录后
+  即可获得更小的令牌
+* 或者用环境变量 `NODE_OPTIONS=--max-http-header-size=65536` 提高 Node.js 的限制，然后
+  重启 AnsibleForms
+
+从 7.1.0 起，[`MAX_HTTP_HEADER_SIZE`](customization/server.html#env_MAX_HTTP_HEADER_SIZE) 设置同样的限制，默认 16384
+字节，在启动时读取，用于其他较大的请求头，例如前面的单点登录网关设置的大型 cookie。
+同时也要提高代理的请求头限制，参见 [请求头大小](production/reverse-proxy.html#request-header-size)。
+
+---
+
+## Playbook failed with status
+
+Ansible 作业以失败结束，其输出的最后一行为：
+
+```
+[ERROR]: Playbook failed with status (<code>)
+```
+
+**原因**
+
+`ansible-playbook` 以非零代码退出。上面几行是 Ansible 自身的错误：找不到 playbook、
+主机不可达、某个任务失败，或者清单有误。playbook 会在启用了
+**用于 playbook** 的仓库中查找，或在 [`ANSIBLE_PATH`](customization/paths.html#env_ANSIBLE_PATH) 中查找；日志行
+`Running from directory : <path>` 显示了所用的文件夹。
+
+**解决方法**
+
+阅读最后一行上方的作业输出。如果找不到 playbook，请对照
+`Running from directory` 中的文件夹检查表单的 `playbook`。参见 [Ansible 表单](forms/ansible.html)。
+
+---
+
+## Playbook was aborted by the main process
+
+Ansible 作业以失败结束，显示：
+
+```
+Playbook was aborted by the main process.  Likely some buffer or memory error occured.  Also check the maxBuffer option.
+```
+
+**原因**
+
+RTE 上的 `ansible-playbook` 进程被信号终止，而且没有人中止该作业。从 7.0.0 起，
+输出的大小不再导致这种情况：超过 [`PROCESS_MAX_BUFFER`](customization/server.html#env_PROCESS_MAX_BUFFER)（默认每个流 50 MB）
+后，其余输出不再存储，作业显示
+`[WARNING]: the stdout of this job passed PROCESS_MAX_BUFFER (<bytes> bytes) : the rest is not stored, the playbook goes on`，
+playbook 会一直运行到结束。现在通常的原因是内存：RTE 容器达到了其内存限制，
+内核终止了 playbook，例如因为 forks 很多或 facts 很大。
+
+**解决方法**
+
+在 playbook 运行时检查 RTE 容器的内存（`docker stats`、`kubectl top pod`）并提高其限制，或者降低
+playbook 的内存使用（更少的 `forks`，不收集不必要的 facts）。如果您只看到 `PROCESS_MAX_BUFFER` 警告并且
+需要完整的输出，请在 RTE 容器的环境中调高 `PROCESS_MAX_BUFFER`；它由 RTE 读取，而不是由应用读取。
+---
+
+## Failed to launch awx template
+
+AWX 作业以失败结束，其输出以下面这行开头：
+
+```
+failed to launch awx template <name>
+```
+
+**原因**
+
+下一行给出了原因。`Request failed with status code 401` 表示
+AWX 运行器凭据上的令牌或用户名和密码被拒绝。`could not find job template <name>` 表示没有作业模板或工作流作业模板
+正好叫这个名称，或者连接所用的用户看不到它。证书错误，例如
+`unable to verify the first certificate`，表示 AWX 证书不受信任。
+
+**解决方法**
+
+在运行器上（**连接 > 运行器**）使用 **测试连接**，成功时会返回 `Runner connection is OK`。从
+7.3.0 起，令牌或用户名和密码、地址以及 **CA 证书包** 都位于运行器的凭据中，在
+**连接 > 凭据** 下：请在那里更新令牌或密码；对于证书错误，请把 CA 粘贴到其 **CA 证书包** 中。
+检查模板的名称和权限。输入地址时不要带 `/api/v2`：AnsibleForms 会自行添加
+[`AWX_API_PREFIX`](customization/features.html#env_AWX_API_PREFIX)。
+参见 [AWX 表单](forms/awx.html)。
+
+---
+
+## 作业显示状态 abandoned
+
+一个原本在运行的作业现在被标记为 `abandoned`，某个节点或 RTE 的日志显示以下之一：
+
+```
+Abandoned <n> jobs this node followed before it restarted
+Abandoned <n> jobs this worker followed before it restarted
+Abandoned <n> jobs followed by a node that stopped answering
+Job <id>: RTE '<name>' came back without it: abandoned
+Abandoned <n> jobs
+```
+
+已弃用的数据库模式 RTE 会记录它自己的消息：
+
+```
+RTE: abandoned <n> job(s) left running by a previous start
+RTE: stopping with <n> job(s) still running: they end as abandoned
+```
+
+**原因**
+
+作业属于运行或跟踪它的容器：playbook 属于其 RTE，其他任何作业（AWX 作业、多步骤
+表单的步骤）属于启动它的应用节点。当该容器重启时，它会结束自己未完成的作业。当它消失时，例如 pod
+被替换，worker 会在它两分钟没有响应后结束其作业。socket 模式的 RTE 回来时如果没有
+它原先运行的某个作业，例如新容器没有其 spool，该作业会以 abandoned 结束。正在停止的 RTE 会先等待
+[`RTE_DRAIN_SECONDS`](customization/server.html#env_RTE_DRAIN_SECONDS) 让其 playbook 结束。每小时，运行超过
+一天的作业也会被标记为 abandoned。
+
+从 7.3.0 起，AWX、AAP 或 Ascender 上的作业会在其运行器上继续运行：重启使其被放弃之后，节点会立即再次跟踪它
+（如果它是在过去 24 小时内启动的），并以它在那里的实际结果结束。日志随后会显示 `Following <n> abandoned job(s) again on their runner`。
+
+**解决方法**
+
+重新运行 playbook 作业。请在没有作业运行时重启或升级 RTE 和应用节点，并给正在停止的 RTE 留出足够时间
+（参见 [扩展](rte/run.html)）。重新运行之前，请检查 playbook 是否真的在受管主机上完成了，
+因为它可能只运行了一部分。
+
+---
+
+## RTE 无法连接
+
+RTE 运行器上（**连接 > 运行器**）的 **测试连接** 失败，显示：
+
+```
+the RTE '<name>' (outbound) is not connected: it has not dialed the app: check its APP_URL, its token and the network from the RTE to the app
+the RTE '<name>' (inbound) is not connected: no app node could dial it at <address>: check its RTE_URL, its token and the network from the app to the RTE
+```
+
+**原因**
+
+socket 模式的 RTE 通过一条 WebSocket 与应用通信：出站时由它连接应用，入站时由应用连接它（参见
+[模式](rte/modes.html)）。应用和 RTE 的日志会说明 socket 为什么没有打开：
+
+| 消息 | 位置 | 含义 |
+|---|---|---|
+| `RTE: refused a socket without the right token from <address>` | RTE（入站） | 运行器 RTE 凭据中的令牌与 RTE 的 `RTE_TOKEN` 不一致 |
+| `Runner '<name>': the RTE at <address> refused the socket (401): check its RTE_TOKEN` | 应用（入站） | 同上，从应用一侧看到 |
+| `the token of RTE '<name>' is not the one stored for its runner: check its RTE_TOKEN` | 应用，以及被拒绝的 RTE（`401`） | RTE 登录所用的令牌与应用为其运行器保存的令牌不同 |
+| `RTE '<name>': waiting for an admin to approve it under Connections > Runners (fingerprint <fingerprint>)` | RTE（出站） | 它已请求加入，正在等待批准 |
+| `RTE '<name>': asked to join as inbound runner '<name>': the app dials it once an admin approves it under Connections > Runners (fingerprint <fingerprint>)` | RTE（入站，带 `APP_URL`） | 同上，针对入站 RTE |
+| `runner '<name>' is managed by the config seed in database mode: set rte_mode: outbound for it in the seed (and its credential), then restart this RTE` | 应用，以及被拒绝的 RTE（`409`） | 配置种子声明该运行器时没有 `rte_mode`，因此处于数据库模式，而它的模式由种子决定。入站 RTE 会看到 `rte_mode: inbound` 和 `(and its credential with the address the app dials, RTE_URL)` |
+| `RTE: RTE_MODE=inbound with APP_URL registers with the app, which then dials RTE_URL : set RTE_URL (http://this-host:8000) ; refusing to start` | RTE | 自行注册的入站 RTE 需要应用连接它所用的地址 |
+| `Runner '<name>': dialing <address>: <reason>` | 应用，`debug` 级别 | 应用无法打开 socket，例如因为 RTE 的证书不是为其运行器固定的那张 |
+| `[DEPRECATED] This RTE runs in database mode (RTE_MODE is not set): it holds the database's credentials and reads and writes it itself. Set RTE_MODE=outbound (it dials the app, APP_URL) or RTE_MODE=inbound (the app dials it, RTE_URL), and drop DB_* from its environment. Database mode is removed in 8.0.0.` | RTE | 它以数据库模式运行，根本不打开 socket |
+
+**解决方法**
+
+* **令牌被拒绝**：把运行器 RTE 凭据（**连接 > 凭据**）中的令牌交给 RTE，或者反过来
+* **等待批准**：在 **连接 > 运行器** 下批准它，批准前先确认那里显示的指纹与其日志中的一致
+  （参见 [批准 RTE](runners/registration.html#approving-an-rte)）
+* **由数据库模式的配置种子管理**：在种子中为该运行器设置 `rte_mode`，并配上一个 RTE 凭据（入站时还要有其
+  地址），然后重启 RTE
+* **入站但没有 `RTE_URL`**：把 `RTE_URL` 设为应用访问 RTE 所用的地址，或者去掉 `APP_URL`，在
+  种子中或在 **连接 > 运行器** 下声明该运行器
+* **证书不是固定的那张**：通过 HTTPS 的入站 RTE 在注册时发送其证书，应用只用那张证书
+  连接它。换了新证书后，RTE 会在注册时再次发送；如果凭据的 CA 证书包是
+  手动设置的，应用会保留它并记录
+  `Runner '<name>': its ca_bundle was set by hand: the certificate its RTE sent (fingerprint <fingerprint>) is not stored. Empty the ca_bundle to have the RTE's certificate pinned again`
+* **[DEPRECATED] 警告**：在 RTE 上设置 `RTE_MODE`，从其环境中删除 `DB_*`，并把其运行器设为该模式（参见
+  [模式](rte/modes.html)）
+
+---
+
+## The form data is not valid
+
+运行验证为 `enforce` 时，启动被拒绝，返回 `422` 和：
+
+```
+The form data is not valid
+```
+
+**原因**
+
+服务器按照表单的规则检查了字段值，发现有缺失或无效的字段；响应在 `details` 下列出了
+它们。没有 `rawFormData` 的启动也会被拒绝。尚无法检查的表单，例如向导，
+会被拒绝并显示 `Form '<name>' cannot be launched with launch validation 'enforce' yet : <reason>`。
+
+**解决方法**
+
+修正 details 中指出的字段，如果表单的规则过于严格则修改规则。请先以 `log` 运行：它会记录
+`Launch validation would refuse form '<name>' ...`，但不拒绝任何东西。参见
+[enforce 做什么](launch-validation/log-and-enforce.html#what-enforce-does) 和
+[推广上线](launch-validation/rolling-it-out.html)。
+
+---
+
+## 仓库克隆或拉取失败
+
+仓库显示失败状态，其输出中包含 git 的错误，或者日志显示
+`Background clone of '<name>' failed : <reason>`。
+
+**原因**
+
+Git 无法访问远程仓库或无法通过身份验证。对于 SSH URL（`git@host:path`），远程仓库必须接受
+AnsibleForms 的公钥；对于 HTTPS，用户名和令牌必须有效。如果工作树有
+更改，拉取也会被拒绝，显示
+`Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.`
+
+**解决方法**
+
+对于 SSH，从 **连接 > SSH** 的 **密钥** 选项卡复制公钥，并将其添加为部署密钥，或添加到
+有权访问该仓库的用户上。AnsibleForms 在克隆时会把远程主机添加到已知主机中；对于其他主机，请使用
+同一页面的 **已知主机** 选项卡。对于
+HTTPS，请更新令牌。参见 [Git 仓库](gui/designer-and-git.html#git-repositories) 和
+[关于仓库](faq.html#about-repositories)。
+
+---
+
+## 表单仓库尚未克隆
+
+在设计器中保存表单时失败，显示：
+
+```
+The forms repository '<name>' is not cloned yet ; clone it from the repositories settings first
+```
+
+**原因**
+
+启用了 **用于表单** 的仓库还没有工作树，因为克隆尚未运行或已失败。
+
+**解决方法**
+
+在仓库设置中克隆该仓库。如果克隆失败，请参见
+[仓库克隆或拉取失败](#a-repository-clone-or-pull-failed)。
+
+---
+
+## 备份失败
+
+备份失败，备份列表中没有新增任何内容。原因为以下之一：
+
+```
+'mariadb-dump' was not found on this system. Install the mysql/mariadb client tools, or set MYSQLDUMP_COMMAND to a command that works here.
+The database dump is empty, '<file>' was not written
+The command timed out
+```
+
+**原因**
+
+转储命令 [`MYSQLDUMP_COMMAND`](customization/retention.html#env_MYSQLDUMP_COMMAND) 没有安装、无法
+连接，或生成了空文件。大型数据库也可能耗时超过
+[`BACKUP_COMMAND_TIMEOUT_SECONDS`](customization/retention.html#env_BACKUP_COMMAND_TIMEOUT_SECONDS)，默认一小时。
+失败的备份不会留下文件夹；日志会显示 `Backup failed, removing the incomplete folder '<folder>' : <reason>`。
+
+**解决方法**
+
+安装 MySQL 或 MariaDB 客户端工具，或者把 `MYSQLDUMP_COMMAND`（以及用于恢复的 `MYSQL_COMMAND`）设为
+在此主机上可用、并与您的服务器版本兼容的命令。对于大型数据库，请调高 `BACKUP_COMMAND_TIMEOUT_SECONDS`。
+参见 [备份](gui/administration.html#backups)。
diff --git a/i18n/zh/_security_assessment/security-assessment/advisories.md b/i18n/zh/_security_assessment/security-assessment/advisories.md
new file mode 100644
index 0000000..1c401d1
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/advisories.md
@@ -0,0 +1,80 @@
+---
+layout: default
+title: 安全公告
+nav_order: 5
+translated_from: 6c1cec5253792365347a7303bf545cdb375681fb
+---
+
+# 安全公告
+{: .no_toc }
+
+每个已公布的漏洞、其严重程度及修复
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 已公布的公告
+
+每次构建本站时从[仓库的 Security 选项卡](https://github.com/ansibleforms/ansibleforms/security/advisories)读取：
+
+{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %}
+{% if af_advisories.size > 0 %}
+<table>
+  <thead>
+    <tr>
+      <th>公告</th>
+      <th>严重程度</th>
+      <th>弱点</th>
+      <th>受影响版本</th>
+      <th>修复版本</th>
+      <th>公布日期</th>
+    </tr>
+  </thead>
+  <tbody>
+    {% for a in af_advisories %}
+    <tr>
+      <td>
+        <strong>{{ a.summary | escape }}</strong><br>
+        <a href="{{ a.html_url }}">{{ a.ghsa_id }}</a>{% if a.cve_id %}<br>{{ a.cve_id }}{% endif %}
+      </td>
+      <td>
+        {{ a.severity | capitalize }}
+        {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%}
+        {%- if af_cvss.score %}<br>CVSS {{ af_cvss.score }}{% endif %}
+      </td>
+      <td>
+        {%- for w in a.cwes %}<span title="{{ w.name | escape }}">{{ w.cwe_id }}</span>{% unless forloop.last %}<br>{% endunless %}{% endfor -%}
+      </td>
+      <td>{% for v in a.vulnerabilities %}<code>{{ v.vulnerable_version_range }}</code>{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}<br>{% endunless %}{% endfor %}</td>
+      <td>{{ a.published_at | date: "%Y-%m-%d" }}</td>
+    </tr>
+    {% endfor %}
+  </tbody>
+</table>
+{% else %}
+尚未公布任何公告。
+{% endif %}
+
+GitHub 上的每条公告都给出了详细信息：影响、条件、CVSS 向量以及修复。
+
+---
+
+## 这对您的版本意味着什么
+
+公告会列出受影响的版本以及第一个已修复的版本。修复随受支持的版本发布，
+即 [7.x 和 6.5.x](development.html#supported-versions)，更早的版本不会打补丁：升级就是修复办法。
+
+将实例的版本（帮助菜单中的**关于**，或 `GET /api/v2/version` ）与**受影响版本**进行比较。
+
+---
+
+## 获取新公告的通知
+
+公告发布时，GitHub 会通知该仓库的关注者：
+
+* 在 [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) 上，选择 **Watch > Custom > Security alerts**。
+* [更新日志](../changelog.html)会在包含修复的版本下列出每个安全修复。
diff --git a/i18n/zh/_security_assessment/security-assessment/development.md b/i18n/zh/_security_assessment/security-assessment/development.md
new file mode 100644
index 0000000..e6f8a66
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/development.md
@@ -0,0 +1,92 @@
+---
+layout: default
+title: 安全开发
+nav_order: 3
+translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f
+---
+
+# 安全开发
+{: .no_toc }
+
+变更如何检查和发布，以及哪些版本受支持
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 源代码
+
+AnsibleForms 是开源软件，因此本页的所有内容都可以在仓库中自行核实：
+
+* 代码、其历史和构建流水线都公开在 [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms) 上。
+* [许可证](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE)为 GPL-3.0。
+* [更新日志](../changelog.html)列出了每个版本的每项变更，包括安全修复。
+
+---
+
+## 变更如何合并
+
+每项变更都通过拉取请求进入 `main` ，并受一套任何人都无法绕过的规则集约束：
+
+| 规则 | 含义 |
+|---|---|
+| 必须使用拉取请求 | 任何内容都不会直接推送到 `main` |
+| 必需的检查 | 只有下面的每项检查都通过，拉取请求才会合并 |
+| 禁止强制推送，禁止删除 | `main` 的历史不能被改写或删除 |
+| 线性历史 | 每个拉取请求都会变成一个提交，因此每项变更都可以单独追溯和回退 |
+
+拉取请求必须通过的检查：
+
+| 检查 | 作用 |
+|---|---|
+| Client、Server | 网页界面和服务器的单元测试 |
+| CodeQL | GitHub 对 JavaScript 和 TypeScript 代码的静态分析，用于发现注入、跨站脚本和其他弱点 |
+| Public schema is up to date | 代码所期望的数据库架构与其附带的架构一致 |
+| Title、Branch | 拉取请求遵循命名规则，以保证更新日志准确 |
+
+另外还有两项会在每个拉取请求上运行并报告结果：
+
+* **Database** 在 MySQL 和 MariaDB 上测试服务器， **Browser** 在浏览器中操作界面。
+* **Dependency review** 会阻止引入存在已知高危或严重漏洞的新依赖。
+
+---
+
+## 代码分析和依赖
+
+代码及其依赖在合并之后还会再次检查：
+
+* **CodeQL** 还会分析每次推送到 `main` 和发布分支的内容，并每周分析整个代码库：
+  这样新的 CodeQL 规则也会检查在它之前合并的代码。
+* **Dependabot** 会为依赖的每个新版本打开一个拉取请求：服务器和
+  界面的 npm 包、运行时环境的 Python 包以及流水线的 GitHub Actions 每周一次，
+  容器的基础镜像每天一次。
+* 基础镜像通过摘要固定（ `node:26-trixie-slim@sha256:...` ），因此构建使用的正是经过审查的镜像。
+  当上游重新构建镜像时，Dependabot 会更新摘要。
+
+---
+
+## 版本发布和镜像
+
+版本只由 GitHub Actions 构建和发布，从不在开发者的机器上进行：
+
+* 版本从 `main` （或 `release/6.x` ）切出，附带根据其拉取请求生成的更新日志。
+* 镜像由 [Publish 工作流](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml)构建，
+  并推送到 GitHub Container Registry `ghcr.io/ansibleforms/ansibleforms` ，运行时环境镜像
+  也在旁边。该工作流及其日志都是公开的，因此任何人都可以看到镜像中包含了什么。
+* 应用程序和运行时环境镜像以非特权用户 `node` （uid 1000）运行，从不以 root 运行。
+
+---
+
+## 受支持的版本
+
+安全修复会进入每条受支持版本线的最新版本：
+
+| 版本 | 是否接收安全修复 |
+|---|---|
+| 7.x | 是 |
+| 6.5.x | 是 |
+| 早于 6.5 | 否：升级就是修复办法 |
+
+[升级指南](../upgrading/)介绍如何迁移到更新的版本，[升级到 v7](../upgrade-7.html) 介绍如何从 6.5 迁移。
diff --git a/i18n/zh/_security_assessment/security-assessment/faq.md b/i18n/zh/_security_assessment/security-assessment/faq.md
new file mode 100644
index 0000000..3da9b11
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/faq.md
@@ -0,0 +1,86 @@
+---
+layout: default
+title: 评估常见问题
+nav_order: 6
+translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2
+---
+
+# 评估常见问题
+{: .no_toc }
+
+对安全问卷中最常见问题的简短回答
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 数据和托管
+
+数据存放在哪里，以及谁能访问它：
+
+| 问题 | 回答 |
+|---|---|
+| 我们的数据存储在哪里？ | 存储在您运行的 MySQL 或 MariaDB 数据库中，以及您实例的持久化文件夹中。AnsibleForms 是自托管的，背后没有任何云服务。 |
+| 它会把数据发送给开发者吗？ | 不会。没有遥测，没有使用情况上报，也没有更新检查。 |
+| 它会连接到哪里？ | 只连接管理员配置的系统：参见[出站连接](measures.html#outbound-connections)。 |
+| 它是否使用 AI，或者把数据发送给模型提供商？ | 只有在开启[聊天助手](../chat/)时才会，该功能默认关闭。开启后，它会把表单定义和正在填写的值发送给您配置的提供商。 |
+| 它能在没有互联网连接的情况下运行吗？ | 能。应用程序不需要互联网连接；playbook 需要的是其任务所访问的资源。 |
+
+---
+
+## 加密
+
+哪些内容会加密，以及使用哪些密钥：
+
+| 问题 | 回答 |
+|---|---|
+| 数据在传输中是否加密？ | 通过 [HTTPS](../security/https.html) 加密，由应用程序或您的反向代理提供，应用程序与其运行时环境之间使用 `wss://` 。 |
+| 数据在静态存储时是否加密？ | 应用程序用 AES-256 加密每一个存储的机密。作业及其输出按原样存储：请使用数据库自身的静态加密。参见[存储的机密](measures.html#stored-secrets)。 |
+| 密钥由谁持有？ | 由您持有： [`ENCRYPTION_SECRET`](../security/secrets.html) 由您设置，不包含在备份中，并且可以轮换。 |
+| 机密可以留在我们自己的 vault 中吗？ | 可以：作业需要时会读取 [HashiCorp Vault 和 CyberArk](../secret-stores/)。 |
+
+---
+
+## 访问和问责
+
+谁可以登录、他们能做什么，以及记录了什么：
+
+| 问题 | 回答 |
+|---|---|
+| 是否支持单点登录？ | 支持：LDAP / Active Directory、OpenID Connect 和 Entra ID。参见[认证](../authentication/)。 |
+| 是否支持多因素认证？ | 通过单点登录支持：适用您的身份提供商的 MFA。本地账户本身没有 MFA。 |
+| 权限如何管理？ | 通过映射到组的角色管理，服务器会在每个请求上检查。参见[权限](measures.html#permissions)。 |
+| 是否有审计日志？ | 有：记录每项变更和每次被拒绝的尝试，默认保留 365 天，并可转发到 syslog。参见[审计跟踪](measures.html#audit-trail)。 |
+| 是否有默认密码？ | 第一个管理员账户有一个公开的默认密码，必须在首次登录时修改。参见[管理员账户](../security/hardening.html#the-admin-account)。 |
+
+---
+
+## 漏洞和更新
+
+问题如何发现、修复和公布：
+
+| 问题 | 回答 |
+|---|---|
+| 是否发现过漏洞？ | 是的。每个已公布的漏洞都列在[安全公告](advisories.html)中，并附有修复它的版本。 |
+| 我们如何报告漏洞？ | 通过 GitHub 私下报告：参见[报告漏洞](reporting.html)。 |
+| 代码如何检查？ | 每个拉取请求都会经过 CodeQL 静态分析和依赖审查，此外还有自动化测试和 Dependabot 更新。参见[安全开发](development.html)。 |
+| 哪些版本会获得安全修复？ | 7.x 和 6.5.x。参见[受支持的版本](development.html#supported-versions)。 |
+| 我们如何得知新公告？ | 在 GitHub 上关注该仓库的安全警报。参见[获取新公告的通知](advisories.html#being-told-of-new-advisories)。 |
+| 是否做过渗透测试？ | 没有公布第三方渗透测试报告。代码是公开的，因此您自己的团队或测试人员可以对其进行评估，发现的问题按上述方式报告。 |
+
+---
+
+## 镜像和供应链
+
+镜像来自哪里，以及如何检查它们：
+
+| 问题 | 回答 |
+|---|---|
+| 镜像发布在哪里？ | 发布在 GitHub Container Registry `ghcr.io/ansibleforms/ansibleforms` 上，由公开的 GitHub Actions 工作流构建。参见[版本发布和镜像](development.html#releases-and-images)。 |
+| 容器是否以 root 运行？ | 不是：以非特权用户 `node` 运行。 |
+| 镜像是否签名？ | 尚未签名。请按摘要（ `@sha256:...` ）拉取镜像，以确保运行的是您审查过的镜像。 |
+| 是否有 SBOM？ | 目前尚未随镜像发布 SBOM。Trivy 或 Syft 之类的扫描工具可以根据镜像生成一份。 |
+| 镜像是否经过漏洞扫描？ | 发布流水线中没有扫描。其基础镜像通过摘要固定，并由 Dependabot 保持更新；请在您自己的镜像仓库中扫描镜像，以执行您自己的策略。 |
+| 它采用什么许可证？ | GPL-3.0，开源，不提供任何担保。 |
diff --git a/i18n/zh/_security_assessment/security-assessment/index.md b/i18n/zh/_security_assessment/security-assessment/index.md
new file mode 100644
index 0000000..efcbe5d
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/index.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: 概述
+nav_order: 1
+permalink: /security-assessment/
+translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd
+---
+
+# 安全评估
+{: .no_toc }
+
+面向安全审查：安全措施、开发流程和安全公告
+{: .fs-6 .fw-300 }
+
+---
+
+## 简而言之
+
+AnsibleForms 运行 playbook 并保管其凭据，因此它是您信任链的一部分：
+
+* 它是**自托管**的：运行在您的基础设施上，数据保存在您的数据库中，不向开发者发送任何内容。
+* 它是**开源**的（GPL-3.0）：代码、其流水线以及每条公告都是公开的。
+* 每个存储的机密都经过**加密**，每项变更都经过**审计**，每个请求都会检查**角色**。
+* 漏洞**私下报告**，在每个受支持的版本中修复，并**公开发布**。
+
+---
+
+## 本节内容
+
+这些页面回答安全审查中的问题，从设计到 CVE 列表：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [安全措施](measures.html) | 登录、权限、存储的机密、审计跟踪、浏览器、服务器、连接和容器 |
+| [安全开发](development.html) | 变更如何审查和测试、代码和依赖分析、镜像如何构建、受支持的版本 |
+| [报告漏洞](reporting.html) | 如何私下报告问题，以及之后会发生什么 |
+| [安全公告](advisories.html) | 每个已公布的漏洞，及其 CVE、严重程度和修复版本 |
+| [评估常见问题](faq.html) | 对安全问卷中最常见问题的简短回答 |
+
+如果要保护实例而不是评估它，请参阅管理员指南中的[安全](../security/)。
diff --git a/i18n/zh/_security_assessment/security-assessment/measures.md b/i18n/zh/_security_assessment/security-assessment/measures.md
new file mode 100644
index 0000000..61eb8ec
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/measures.md
@@ -0,0 +1,157 @@
+---
+layout: default
+title: 安全措施
+nav_order: 2
+translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a
+---
+
+# 安全措施
+{: .no_toc }
+
+登录、权限、机密和连接如何受到保护
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 在哪里运行
+
+AnsibleForms 是自托管的，运行在您的基础设施上，数据保存在您运行的数据库中。
+
+* 没有 AnsibleForms 云服务或许可证服务器，也没有遥测或更新检查。
+* 界面由应用程序自身提供，不从其他站点加载任何内容。
+* 应用程序只连接管理员配置的系统，这些系统列在[出站连接](#outbound-connections)中。
+
+各个组成部分及其保存的内容：
+
+| 组成部分 | 作用 | 保存的内容 |
+|---|---|---|
+| 应用程序 | 网页界面、REST API、调度器 | 本身不保存数据：一切都在数据库中 |
+| MySQL 或 MariaDB | 应用程序的数据库 | 用户、组、凭据（已加密）、作业及其 extravars 和输出、审计日志 |
+| 运行时环境（RTE） | 在其自己的容器中运行 playbook | 它运行的作业的文件，以及仅在作业运行期间存在的该作业的机密 |
+| 持久化文件夹 | 配置、表单、playbook 和上传的文件 | 表单和 playbook 使用的文件 |
+
+完整的介绍请参阅[工作原理](../how-it-works.html)，运行时环境请参阅 [RTE](../rte/)。
+
+---
+
+## 登录
+
+每个读取或修改数据的页面和 API 调用都需要已登录的用户。少数无需登录即可访问的端点用于
+登录本身、版本、实例的名称和徽标、API 文档以及首次启动时的数据库设置，
+最后一项可以用 [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` 关闭：
+
+| 方式 | 工作原理 |
+|---|---|
+| 本地账户 | 密码用 bcrypt 哈希，有[最小长度](../security/hardening.html#sign-in-limits-and-passwords)要求，公开的默认管理员密码必须在首次登录时修改 |
+| LDAP / Active Directory | 由目录检查密码，其组映射到角色。参见 [LDAP](../authentication/ldap.html) |
+| OpenID Connect、Entra ID | 通过您的身份提供商单点登录，同时也带来其自身的多因素认证。参见[认证](../authentication/) |
+
+* 登录失败会[锁定账户](../security/hardening.html#sign-in-limits-and-passwords)，并且登录受速率限制。
+* 登录会返回一个有效期 30 分钟的签名访问令牌，以及一个有效期 24 小时的刷新令牌。
+* 令牌可以在过期前终止：退出登录、修改密码、用户被封禁以及 API 令牌被撤销，都会在
+  所有节点上同时终止令牌，参见[令牌](../security/secrets.html#tokens)。
+* AnsibleForms 本身没有多因素认证：在需要的场合请使用单点登录。
+
+---
+
+## 权限
+
+用户能做什么取决于其所在组的角色，服务器会在每个请求上检查：
+
+* 角色在 [config.yaml](../config/roles.html) 中定义：用户能看到哪些表单，以及拥有哪些选项，
+  例如设计器、设置页面或其他用户的作业。
+* 服务器会根据表单的规则（其字段、字段的值以及用户的访问权限）检查每次运行，包括
+  通过 REST API 的运行，参见[运行验证](../launch-validation/)。
+* 按照设计，管理员角色可以运行任何 playbook。其他角色只获得被授予的权限：拥有多个角色的用户，只有在
+  这些角色都不拒绝某个选项时才能获得该选项，因此只要有一个限制性角色就足以收回它。
+
+---
+
+## 存储的机密
+
+密码、令牌和密钥在写入数据库之前都会加密：
+
+* 每个存储的机密，包括凭据、LDAP 绑定密码、运行器令牌、单点登录客户端密钥、webhook
+  地址和 API 密钥，都用 AES-256 加密，每个值使用随机的初始化向量，并基于
+  您设置的 [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) 。
+* 任何 API 调用或设置页面都不会显示存储的机密，备份也不包含主密钥。
+* 机密可以留在您的 vault 中：作业需要时会读取 [HashiCorp Vault 和 CyberArk](../secret-stores/)。
+* 作业的机密以 AES-256-GCM 加密封装后传给运行时环境，密钥由其令牌派生。
+* 名称看起来像机密的 extravars 会在作业视图中被掩码，密码字段则始终被掩码，参见[作业数据](../security/hardening.html#job-data)。
+
+数据库的其余部分，即作业、其 extravars 和输出，按原样存储：请用数据库自身的
+静态加密和访问控制来保护它，参见[数据库](../security/hardening.html#the-database)。
+
+---
+
+## 审计跟踪
+
+每项变更以及每次被拒绝的尝试都会被记录：
+
+* 每次通过界面或 API 进行的创建、修改和删除，都会写入审计日志，包括用户、其
+  地址、操作、对象和结果。拒绝和登录也会被记录，包括失败的登录。
+* 看起来像机密的值在写入之前会被隐去。
+* 日志默认保留 365 天，并可通过 UDP、TCP 或 TLS 复制到 syslog。
+
+---
+
+## 在浏览器中
+
+界面受到保护，可防止向页面注入代码：
+
+* [Content-Security-Policy](../security/hardening.html#the-content-security-policy) 只允许应用程序自己的脚本和框架。
+* 每个响应都带有防护性的响应头：nosniff、框架保护，以及通过 HTTPS 时的 HSTS。
+* 表单、帮助文本和聊天回答中的 HTML 会经过清理，作业输出会被转义。
+
+---
+
+## 在服务器上
+
+处理用户输入的代码避免了经典的注入问题：
+
+* 数据库查询以参数形式传递值，从不把值作为文本拼接到查询中。
+* 命令（包括 git）通过参数列表运行，从不经过 shell，因此 shell 字符不起任何作用。
+* 服务器表达式要经过[表达式清理器](../security/hardening.html#expressions-and-outbound-calls)，其 REST 调用要经过主机过滤器。
+* [MCP 服务器](../mcp/)、[聊天助手](../chat/)和指标端点在您开启之前都处于关闭状态。
+
+---
+
+## 连接
+
+进出 AnsibleForms 的流量可以端到端加密：
+
+* 应用程序可以自己提供 [HTTPS](../security/https.html)，也可以位于您的反向代理之后。
+* 运行时环境通过 WebSocket 与应用程序通信，使用 HTTPS 地址时为 `wss://` ，应用程序
+  还会固定入站运行时环境的证书，参见 [RTE 模式](../rte/modes.html)。
+* LDAP、单点登录、运行器、git、密钥库以及表达式的 REST 调用都会检查其所连接
+  服务器的证书，除非管理员为使用自签名证书的服务器关闭了该检查。
+
+### 出站连接
+
+AnsibleForms 只连接管理员配置的对象：
+
+| 连接 | 时机 |
+|---|---|
+| LDAP、OpenID Connect、Entra ID（Microsoft 登录和 Graph） | 设置了该登录方式时 |
+| AWX / AAP / Ascender、Semaphore、Rundeck、Jenkins | 表单在该运行器上运行时 |
+| Git 服务器 | 设置了仓库时 |
+| 邮件服务器、Slack、Teams、Telegram、webhook | 设置了通知通道时 |
+| HashiCorp Vault、CyberArk | 设置了密钥库时 |
+| 模型提供商（Anthropic、OpenAI 等） | 仅在开启[聊天助手](../chat/)时，该功能默认关闭 |
+| 表单中指定的主机和 API | 表单的表达式或 playbook 调用它们时 |
+| Syslog 服务器 | 设置了审计或日志转发时 |
+
+---
+
+## 容器
+
+镜像在构建时尽可能以最少的权限运行：
+
+* 应用程序和运行时环境以非特权用户 `node` 运行，而不是 root。
+* 它们基于通过摘要固定的精简 Debian 镜像构建，参见[安全开发](development.html#code-analysis-and-dependencies)。
+* 应用程序只监听一个端口：8000。
+
+关于保护新实例的步骤，请按照[加固](../security/hardening.html)操作。
diff --git a/i18n/zh/_security_assessment/security-assessment/reporting.md b/i18n/zh/_security_assessment/security-assessment/reporting.md
new file mode 100644
index 0000000..a014824
--- /dev/null
+++ b/i18n/zh/_security_assessment/security-assessment/reporting.md
@@ -0,0 +1,66 @@
+---
+layout: default
+title: 报告漏洞
+nav_order: 4
+translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69
+---
+
+# 报告漏洞
+{: .no_toc }
+
+如何私下报告安全问题，以及之后会发生什么
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 私下报告
+
+AnsibleForms 保管着凭据和 vault 令牌，因此切勿在公开 issue 中报告安全问题：
+
+1. 打开 **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**：这是只有维护者能看到的私密公告。
+2. 如果您无法使用该页面，请打开一个普通 issue，只说明您有一份安全报告，并请求
+   一个私密渠道：不要写细节、复现步骤或版本号。维护者会打开一个私密公告并
+   邀请您加入。
+
+完整的政策见仓库的 [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md)。
+
+---
+
+## 应包含哪些内容
+
+报告提供的以下信息越多，修复就越快：
+
+* 攻击者能获得什么：其他用户的数据、本无权运行的 playbook、主机，或管理员权限。
+* 版本，以及部署方式：Docker、Kubernetes 或原生安装。
+* 复现步骤，或者触发问题的请求。
+* 是否需要已登录的用户，以及需要哪些[角色选项](../config/roles.html)。
+
+---
+
+## 之后会发生什么
+
+从第一条消息到公开发布，报告都在同一个私密公告中处理：
+
+| 步骤 | 您会得到什么 |
+|---|---|
+| 确认收到 | 确认报告已收到，以及问题能否复现 |
+| 接受 | 在每个[受支持版本](development.html#supported-versions)的下一个版本中修复，并发布一条署名致谢您的公告，除非您不希望被署名 |
+| 拒绝 | 说明理由，通常是该行为需要报告者本来就拥有的权限 |
+
+修复发布后，公告也会公开，并出现在[安全公告](advisories.html)中。
+
+---
+
+## 范围
+
+该政策的界线与角色模型的界线一致：
+
+| 范围内 | 范围外 |
+|---|---|
+| 已登录用户能访问到超出其角色授权范围的任何内容 | 需要管理员账户已经被攻破的发现：管理员能运行任意 playbook 正是产品本身的功能 |
+| 无需登录即可访问的任何内容 | 没有证明实际影响的扫描器报告 |
+| 存储的凭据变得可读，或被写入日志 | |
+| 对 shell、数据库或浏览器的注入 | |
diff --git a/i18n/zh/_use/designer/index.md b/i18n/zh/_use/designer/index.md
new file mode 100644
index 0000000..2d4ddd8
--- /dev/null
+++ b/i18n/zh/_use/designer/index.md
@@ -0,0 +1,77 @@
+---
+layout: default
+title: 设计器
+nav_order: 1
+has_children: true
+has_toc: false
+permalink: /designer/
+translated_from: 77ea52f327e41f36adaf3be7d2b50c1d1716bcb6
+---
+
+# 设计器
+{: .no_toc }
+
+在浏览器中编辑表单、playbook、清单和工作流
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向表单作者：设计器的各个部分，以及每个部分的选项卡显示什么。
+
+设计器需要 `showDesigner` [角色选项](../config/roles.html#role-options)。它一次编辑一项内容，即一个
+表单、一个 playbook 或一个工作流文件，各个部分位于左侧菜单中。每种文件还需要各自的选项，这些选项
+默认都是开启的： **Playbook** 需要 `allowPlaybookDesign` ， **工作流**需要 `allowWorkflowDesign` ，
+**清单**需要 `allowInventoryDesign` ， **变量文件**需要 `allowVarsFileDesign` 。缺少某个选项时，对应部分
+是只读的，服务器会拒绝保存、创建、移除或推送其文件；表单和工作流仍然可以选择这些文件。
+**表单**、**类别**和**常量**同样需要 `allowFormDesign` ：没有它时它们是只读的，服务器
+会拒绝保存、拉取或推送它们。同一时间只能有一个人编辑：参见[设计器锁](lock.html)。
+
+---
+
+## 各个部分
+
+每个部分编辑一种文件，这些文件保存在本地或[仓库](../repositories/)中：
+
+| 部分 | 编辑的内容 |
+|---|---|
+| **表单** | 表单文件 |
+| **类别** | `config.yaml` 中的类别 |
+| **常量** | `config.yaml` 中的常量 |
+| **变量文件** | 表单加载的变量文件 |
+| **Playbook** | 表单和工作流运行的 playbook |
+| **清单** | 清单： `inventory.yaml` 、 `group_vars` 和 `host_vars` |
+| **工作流** | [工作流](../workflows/)文件 |
+
+包含文件的部分会在文件浏览器中列出它们，并打开第一个文件；还没有文件的部分会给出提示。
+**表单**部分和每个文件部分的工具栏中，第一个按钮都是**新建文件**：在清单中它新建一个
+清单，在工作流中则新建一个空工作流。文件浏览器的放大镜会打开一个输入框，按名称筛选其中的文件。
+
+标题行上的搜索框会在当前打开的 YAML 中查找文本：标记出它出现的每个位置。它在
+**YAML** 选项卡上可用，前提是您持有设计器锁。
+
+---
+
+## 各个选项卡
+
+每个部分都有同样的三个选项卡，它们都基于同一份 YAML：在其中一个选项卡中的编辑会显示在其他选项卡中，**保存**会将其保存。
+
+- **YAML** 是文件的原始内容。
+- **可视化**通过字段编辑它。只有编辑涉及的键会改变，因此注释和其余内容都保持原样。
+- **预览**显示它的效果，不编辑任何内容。
+
+各部分的可视化和预览选项卡显示的内容：
+
+| 部分 | 可视化 | 预览 |
+|---|---|---|
+| **表单** | 表单的设置及其字段，带有设计器中 playbook、清单和工作流的列表 | 表单的当前样子，包括未保存的编辑；提交时不运行任何内容 |
+| **类别** | 以表格形式编辑类别 | 由类别生成的表单页面菜单 |
+| **常量** | 以大纲形式编辑常量（用方向键移动键） | 每个常量及其可复制的引用 `$(NAME)` ，以及使用它的表单 |
+| **变量文件** | 编辑变量 | 每个变量及其在 playbook 中可复制的引用 {% raw %}`{{ name }}`{% endraw %} ，以及加载该文件的表单 |
+| **Playbook** | 各个 play：每个 play 的名称、主机、**Become**、**收集 facts** 和角色，以及其任务，每个任务带有模块和参数 | playbook 的大纲：其 play 及其主机、角色和任务，以及它导入的 playbook |
+| **清单** | 组、其子组、其主机，以及各自设置的变量 | 以树形显示的清单，以及其 `group_vars` 和 `host_vars` |
+| **工作流** | 工作流的图，用于[编辑它](../workflows/designer.html) | [试运行](../workflows/designer.html#trying-it-out)：点击节点让它失败 |
+
+当 YAML 无法读取时，可视化和预览选项卡会说明原因，并提供**在 YAML 中显示**，在 YAML 中打开对应的行。
diff --git a/i18n/zh/_use/designer/lock.md b/i18n/zh/_use/designer/lock.md
new file mode 100644
index 0000000..df66f4a
--- /dev/null
+++ b/i18n/zh/_use/designer/lock.md
@@ -0,0 +1,63 @@
+---
+layout: default
+title: 设计器锁
+parent: 设计器
+nav_order: 1
+translated_from: f23a01e973e287a772930e69ca9ccaa7cb463c65
+---
+
+# 设计器锁
+{: .no_toc }
+
+同一时间只能有一个人编辑
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 获取锁
+
+在您用设计器右上角的开关将其打开之前，设计器处于关闭状态。打开它即获取
+锁：从此刻起只有您能保存，直到您再次将其关闭。
+
+没有锁时，设计器显示**设计器未激活**，任何内容都无法编辑。
+
+保存永远不会重叠：从 7.3.0 起，在保存、推送或加载进行期间，第二次**保存**（双击，或按住 Ctrl+S）会被
+忽略，因此不会与第一次竞争而写入第二个备份或第二个提交。
+
+---
+
+## 锁被别人持有时
+
+当其他用户持有锁时，设计器只显示**设计器正由**该用户**使用**，别的什么都不显示：没有各个部分，
+也没有文件。
+
+开关显示为开启但呈灰色，旁边显示**已被**该用户**锁定**。等对方关闭设计器后，您就可以获取锁。
+锁被获取或释放时，所有打开的设计器都会立即看到，无需重新加载。
+
+当两个用户在同一时刻打开设计器时，其中一人会得到锁。从 7.3.0 起，另一人会看到谁持有锁，
+并且每个编辑器都保持只读，因此不会输入任何无法保存的内容。
+
+---
+
+## 释放别人的锁
+
+管理员可以释放别人持有的锁，例如对方下班回家时仍开着设计器。
+
+**释放**位于**已被……锁定**旁边，只对管理员显示。它会先询问确认：该用户未保存的更改将会丢失。
+
+从 7.3.0 起，锁被释放的用户会收到通知，并得知是谁释放的：**您的设计器锁已被**管理员的名字**释放**，
+以及**未保存的更改无法再保存。** 他们的设计器不会自行重新获取锁；想继续时，他们需要再次打开它。
+
+---
+
+## 被遗忘的锁
+
+没有人使用的锁会自行释放，因此没有人需要等待一个根本没人打开的设计器。
+
+持有者打开的设计器会不断告诉服务器它仍然在线。当服务器
+5 分钟没有收到它的消息时（因为浏览器被关闭、电脑关机或网络断开），锁就会再次变为可用。当
+持有者回到设计器时，如果没有其他人获取锁，它会再次获取锁。管理员的释放是例外：
+释放之后不会再自动取回锁。
diff --git a/i18n/zh/_use/jobs/actions.md b/i18n/zh/_use/jobs/actions.md
new file mode 100644
index 0000000..9466118
--- /dev/null
+++ b/i18n/zh/_use/jobs/actions.md
@@ -0,0 +1,198 @@
+---
+layout: default
+title: 作业操作
+parent: 作业
+nav_order: 3
+translated_from: 6014f8e14db84fca0d144f1d64232e50aa6cbec9
+---
+
+# 作业操作
+{: .no_toc }
+
+运行、中止、重新运行、批准或拒绝以及删除作业
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 运行作业
+
+每个作业都从表单开始。在**表单**页面打开表单，填写字段，然后按**提交**：
+
+1. 表单在浏览器中验证，字段值被提交到服务器。
+2. 服务器创建作业并返回其编号；表单的 [`onSubmit`](../forms/job-status-action.html) 动作随即运行。
+3. 作业的输出显示在表单下方，每两秒刷新一次，直到作业结束。
+
+作业也会出现在**作业**页面上，您可以稍后在那里跟踪它。
+
+### 谁可以运行表单
+
+如果用户拥有表单 `roles` 列表中的某个[角色](../config/roles.html)，就能看到并运行该表单。
+每个用户都拥有 `default` 角色，因此带有该角色的表单对所有能登录的人都可用。
+
+### 提交之前
+
+字段上方的工具栏提供了一些工具，每个工具只在您的角色允许时才显示：
+
+| 按钮 | 作用 | 角色选项 |
+|---|---|---|
+| **显示 Extravars** | 在您填写字段时预览作业将收到的 extravars | `showExtraVars` |
+| **verbose** | 以详细模式运行作业 | `allowVerboseMode` |
+| **从已保存项加载** | 用[保存的作业](stored-jobs.html)填充字段 | `allowStoredJobs` |
+| **重新加载此表单** | 重新加载表单，恢复其默认值 | 无 |
+
+### 运行时的选择
+
+表单可以通过声明一个使用保留名称的字段，让用户在运行时选择某些 Ansible 选项。
+这时该字段的值会覆盖表单自身的设置：
+
+| 字段名 | 覆盖的内容 | 常用字段类型 |
+|---|---|---|
+| `__check__` | 检查模式，即不做任何更改的试运行 | `checkbox` |
+| `__diff__` | 差异模式，显示将会更改的内容 | `checkbox` |
+| `__limit__` | playbook 运行所针对的主机 | `text` 或 `enum` |
+| `__tags__` | 要运行的标签 | `text` 或 `enum` |
+| `__inventory__` | 清单 | `enum` |
+| `__playbook__` 、 `__template__` | playbook，或 AWX / AAP 模板 | `enum` |
+
+例如，一个提供试运行和主机限制的表单：
+
+```yaml
+fields:
+  - name: __check__
+    type: checkbox
+    label: Dry run (check mode)
+  - name: __limit__
+    type: text
+    label: Limit to these hosts
+```
+
+服务器只接受把这些名称声明为字段的表单所提供的值，因此来自 API 的运行无法自行添加它们。
+它们所覆盖的属性在 [Ansible 表单](../forms/ansible.html)和 [AWX 表单](../forms/awx.html)中介绍。
+
+### 什么会阻止运行
+
+运行并不总是会立即变成一个正在运行的作业：
+
+* **无效字段**：表单不会提交，每个未通过验证的字段都会显示原因。
+* **运行验证**：当[运行验证](../launch-validation/)设置为 `enforce` 时，服务器会再次检查这些值，
+  并拒绝违反表单规则的运行。
+* **审批**：带有[审批点](../forms/approval.html)的表单会创建作业，作业随后以
+  `approve` 状态等待；参见[批准或拒绝作业](#approve-or-reject-a-job)。
+
+作业结束时，表单的[通知](../forms/notifications.html)会发送邮件和通道消息，其作业
+状态动作也会运行。
+
+### 启动作业的其他方式
+
+表单也可以在没有人按**提交**的情况下启动作业：
+
+| 启动方 | 方式 | 页面 |
+|---|---|---|
+| 稍后运行或 cron 调度 | **提交**旁边的**稍后运行（一次性）** 或**调度（周期性）** | [调度](schedules.html) |
+| 脚本或流水线 | 使用 API 令牌调用 `POST /api/v2/job` | [REST API 作业](../api/jobs.html) |
+| AI 代理 | MCP 服务器的 `launch_job` 工具 | [MCP 工具](../mcp/tools.html) |
+| 对话 | 聊天助手填写表单并运行它 | [聊天助手](../chat/) |
+| 之前的作业 | 下文介绍的**重新运行** | [重新运行作业](#relaunch-a-job) |
+
+---
+
+## 中止作业
+
+在列表的行菜单（⋮）中点击**中止**，或在作业页面上点击**中止作业**，可以停止状态为 `running` 的作业。确认后，
+AnsibleForms 会把该作业标记为中止：
+
+* **`ansible`**：RTE 会停止 playbook 进程（连同其所有 worker），作业以 `aborted` 结束，并显示
+  `... was aborted by the operator` 。仍在等待空闲 RTE 的作业会在开始前被中止。
+* **模板作业**（AWX、AAP、Ascender、Semaphore、Rundeck、Jenkins）：AnsibleForms 请求运行器取消或停止
+  该作业，作业以 `aborted` 结束。当运行器拒绝时，输出会显示 `Abort request denied` ，随后是
+  `reverting abort request` ，作业继续运行。仍在队列中的 Jenkins 构建会被移出队列。
+* **`workflow`**：正在运行的节点作业会被中止，不再启动任何内容（参见
+  [运行工作流](../workflows/running.html#abort)）。
+* **`multistep`**：尚未开始的步骤会被跳过（ `skipping: [Abort is requested]` ），主作业
+  以 `aborted` 结束。已经在运行的步骤是一个独立的作业：打开它并将其中止，才能同样停止它。
+
+您可以中止自己的作业；管理员，或者从 7.3.0 起角色设置了 `manageAllJobs` 的用户，可以中止任何作业。 `showAllJobLogs` 只让
+用户能看到其他用户的作业，而不能中止它们。
+
+---
+
+## 重新运行作业
+
+在列表的行菜单（⋮）中点击**重新运行**，或在作业页面上点击**重新运行作业**，可以从已结束的作业启动一个新作业。对于任何
+既不是 `running` 也不在等待审批的作业，只要用户的角色设置了 `allowJobRelaunch` 角色选项，就会提供此操作。
+
+对话框提供：
+
+* **重新运行**：用作业运行时的值再次运行，以您的名义作为一个新作业。
+* **详细模式**：以详细模式重新运行；拥有 `allowVerboseMode` 角色选项时显示。
+* **重新运行前编辑值**，然后点击**编辑并重新运行**：打开预填了作业值的表单，这样您
+  可以在提交前修改它们。
+
+重新运行还要求表单允许重新运行（ `allowRelaunch` ，默认为 true），并且作业是**您自己的**，除非
+您是管理员，或者从 7.3.0 起拥有 `manageAllJobs` ；在 7.2 及之前可以重新运行任何作业的 `showAllJobLogs` ，现在已不再可以。重新运行如何根据表单规则进行检查，以及为什么带有
+密码字段的表单可能会拒绝重新运行，请参阅[重新运行](../launch-validation/relaunching.html)。
+
+### 使用预填数据重新运行
+
+**编辑并重新运行**会用 `prefillJobId` URL 参数打开表单，您也可以在自己的链接中使用该参数：
+
+```text
+https://af.example.com/form?form=New%20Virtual%20Machine&prefillJobId=61
+```
+
+表单会加载作业 `61` 保存的字段值，并显示 `Form pre-filled with data from previous job #61` 。
+提交后会启动一个新作业，和其他运行一样经过检查。预填遵循与重新运行相同的规则：
+
+* **密码字段从不保存**，因此从不会被预填：请重新输入。常量也不会保存。
+* 需要 `allowJobRelaunch` 角色选项，并且作业必须是您自己的（或者您是管理员，或拥有 `manageAllJobs` ）。
+* 设置了 `allowRelaunch: false` 的表单不能重新运行，也不能预填：
+
+```yaml
+- name: New Virtual Machine
+  type: ansible
+  playbook: create-vm.yaml
+  allowRelaunch: false
+```
+
+在开始保存字段值之前的作业无法预填，表单会改为显示错误：
+
+```text
+No saved form data found for job <id>. This job may have been created before the relaunch feature was enabled.
+```
+
+---
+
+## 批准或拒绝作业
+
+带有[审批点](../forms/approval.html)的作业会停在 `approve` 状态并等待。它会列在其
+审批人（拥有该审批某个角色的用户）的作业页面上，以便他们找到它；从 7.3.0 起，其他用户不再能看到它。
+
+**审核审批**会提供给管理员以及拥有该审批某个角色的用户：点击作业所在的行、
+行菜单中的**审核审批**，或作业页面上的**审核审批**按钮。对话框会显示审批的
+消息，并填入作业的值（没有消息时显示一行通用文字），以及表单、作业 ID、运行者和
+运行时间，并附带指向该作业的链接；用**拒绝**和**批准**作出回应：
+
+* **批准**：作业继续执行，其状态恢复为 `running` 。
+* **拒绝**：作业以 `rejected` 结束，其输出记录 `rejected by <username>` 。
+
+等待审批的作业不能在作业页面上重新运行或删除；请先批准或拒绝它。
+
+从 7.3.0 起，运行作业的用户不能批准该作业，因此总会有第二个人来审查，不过运行者仍然可以拒绝它以
+撤回作业。管理员始终可以批准，包括自己的作业。如果表单的审批点设置了
+[`allowSelf: true`](../forms/approval.html#approving-your-own-job) ，其运行者也可以批准自己的作业。
+
+---
+
+## 删除作业
+
+在列表的行菜单（⋮）中点击**删除**，或在作业页面上点击**删除作业**，确认后会删除作业及其输出。
+删除多步骤作业时也会删除其各个步骤。要一次删除多个作业，请在列表第一列勾选它们，然后
+点击上方的**删除 (n)**。
+
+您可以删除自己的作业。管理员以及从 7.3.0 起拥有 `manageAllJobs` 角色选项的用户可以删除任何作业； `showAllJobLogs`
+不再可以。设置了 `allowJobDeletion: false` 的角色不能删除任何作业，连自己的也不行，这样作业历史就能保持完整。在作业
+页面上，作业正在运行或正在中止时（管理员和 `manageAllJobs` 除外）以及等待审批时，该按钮会被隐藏；在列表中，对于您不能删除的作业，
+菜单项和复选框会显示为灰色。
diff --git a/i18n/zh/_use/jobs/cleanup.md b/i18n/zh/_use/jobs/cleanup.md
new file mode 100644
index 0000000..84e89f2
--- /dev/null
+++ b/i18n/zh/_use/jobs/cleanup.md
@@ -0,0 +1,49 @@
+---
+layout: default
+title: 清理
+parent: 作业
+nav_order: 6
+translated_from: 48c1ec6d3d2ac80c86dd71d6799fbb1b59c5cb2f
+---
+
+# 清理
+{: .no_toc }
+
+因重启而中断的作业，以及已结束作业的保留时长
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 已放弃的作业
+
+正在运行的作业由启动它的 AnsibleForms 进程跟踪。当这种跟踪停止时，作业会被标记为
+`abandoned` ：
+
+* **启动时**，该进程在重启前跟踪的作业，以及 7 之前没有任何进程
+  跟踪的作业，如果仍处于 `running` 或正在中止，就会被标记为已放弃；日志会显示 `Abandoned <n> jobs` 。在 RTE 上
+  运行的作业不受影响：即使没有启动它的进程，它也会继续运行。
+* **每分钟**，由另一个已停止响应 2 分钟的 AnsibleForms 进程（或 RTE）跟踪的作业会被
+  标记为已放弃；日志会显示 `Abandoned <n> jobs followed by a node that stopped answering` 。
+* **每小时**，开始于一天多以前、仍处于 `running` 且一天内没有写入任何输出的作业会被标记为已放弃。
+  在 RTE 上运行的作业在这里同样不受影响：RTE 重启时会自行清理其作业。
+
+从 7.3.0 起，因重启或节点停止而被放弃的 AWX、AAP 或 Ascender 模板作业，如果是在过去 24 小时内
+开始的，会被重新接管：由一个 AnsibleForms 进程接手，再次在运行器上跟踪它，作业最终以
+运行器上实际发生的结果结束。其他运行器上的作业、playbook、工作流和多步骤作业仍保持已放弃状态。
+
+已放弃的 playbook 可能已部分运行。在重新运行之前，请检查受管主机；参见
+[作业显示状态 abandoned](../troubleshooting.html#a-job-shows-the-status-abandoned)。
+
+---
+
+## 作业保留
+
+作业会一直保留，直到被删除，除非管理员设置了保留期限。
+
+设置了 [`JOB_RETENTION_DAYS`](../customization/retention.html#env_JOB_RETENTION_DAYS) 后，每晚的一个任务（在 2:30）会删除
+结束时间早于该天数的已结束作业，连同其输出和步骤一起删除。它只删除状态为
+`success` 、 `failed` 、 `warning` 、 `aborted` 、 `rejected` 或 `abandoned` 的作业，因此正在运行的作业和等待
+审批的作业无论多旧都会保留。默认值 `0` 会保留所有作业。
diff --git a/i18n/zh/_use/jobs/following.md b/i18n/zh/_use/jobs/following.md
new file mode 100644
index 0000000..f98770e
--- /dev/null
+++ b/i18n/zh/_use/jobs/following.md
@@ -0,0 +1,148 @@
+---
+layout: default
+title: 跟踪作业
+parent: 作业
+nav_order: 2
+translated_from: 3beb53d60eeac0e108e31a8dabf2877ab15d2126
+---
+
+# 跟踪作业
+{: .no_toc }
+
+实时输出、extravars、筛选和下载
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 跟踪作业
+
+点击某个作业会打开其页面：以作业的表单为标题，标题栏中是其操作，下方是其输出。
+
+![作业的输出](../assets/screenshots/job-output.jpg)
+
+从 7.3.0 起，该页面由卡片组成，每张卡片都可以在其标题下折叠：
+
+| 卡片 | 显示内容 |
+|---|---|
+| **摘要** | 以作业的名称、状态和类型作为标题，下方以三列网格（页面较窄时为两列，再窄则为一列）显示其信息 |
+| **工作流** | 对于工作流作业（包括 AWX 或 AAP 工作流作业），显示其图和节点数（参见[工作流图](#the-workflow-graph)） |
+| **输出** | 作业的输出及其工具栏 |
+
+在 AWX、AAP、Ascender、Jenkins、Semaphore 或 Rundeck 上运行的作业会在那里显示其编号，作为指向该工具中对应页面的链接，在
+新标签页中打开。该链接保存在作业上，因此即使运行器后来被重命名或移除，链接仍然有效。
+
+页面会实时更新：每当作业被运行、状态改变、写入输出或被删除时，服务器都会发送一个事件，
+页面随即重新读取作业，因此输出会随着作业写入而增长。作业列表也以同样的方式更新。
+**刷新**可手动重新加载作业。
+
+当您位于输出末尾时，页面会随着新行的到来向下跟随。向上滚动阅读之前的行时，
+页面会停留在您所在的位置：这时输出底部会显示**跳到最新**，如果又有新行到来，
+它会变为**新行**。点击它，或者滚动回末尾，即可再次跟随新行。表单页面上**提交**之后的输出，
+以及[服务器日志](../production/logs.html)，也以同样的方式跟随新行。
+
+输出工具栏包含：
+
+| 按钮 | 作用 |
+|---|---|
+| **显示 Extravars** | 在输出上方的面板中显示作业运行时使用的 extravars，带有 **JSON** / **YAML** 切换和**复制** |
+| **显示工件** | 在同一面板中显示作业的工件（见下文） |
+| **显示参数** | 对于 Jenkins 作业，替代**显示 Extravars**：显示其运行时的值，即其构建参数 |
+| **显示 payload** | 对于 Rundeck 作业，替代**显示 Extravars**：显示发送给它的 payload |
+| **主机和任务** | 在输出上方显示 playbook 的主机和任务（参见[主机和任务](#hosts-and-tasks)） |
+| **刷新** | 重新加载输出 |
+| **应用筛选** | 隐藏名称与输出筛选条件匹配的任务；**移除筛选**会重新显示它们 |
+| **复制输出** | 以纯文本复制输出，可以应用筛选，也可以不应用 |
+| **下载输出** | 以 `ansibleforms-job-<id>.txt` 下载输出 |
+
+除模板作业之外的每个作业（例如 RTE 上的 playbook 或工作流）都提供**显示工件**（如果其 playbook 没有用
+`set_stats` 收集工件，则为空），在 AWX、AAP 或 Ascender 上运行的模板作业也提供。Semaphore、Rundeck
+和 Jenkins 作业没有工件，因此从不为它们提供。
+
+在工具栏左侧，**全部折叠**按钮会折叠输出的每个部分（每个 play 和任务），并变为
+**全部展开**，点击后会重新展开它们。
+
+**显示 Extravars** 需要 `showExtravars` 角色选项，**显示工件**需要 `showArtifacts` 角色选项（参见
+[角色选项](../config/roles.html#role-options)）。密码字段的值以及与
+[`MASK_EXTRAVARS_REGEX`](../customization/security.html#env_MASK_EXTRAVARS_REGEX) 匹配的键的值都会被掩码。
+
+筛选条件由 [`REGEX_FILTER_JOB_OUTPUT`](../customization/security.html#env_REGEX_FILTER_JOB_OUTPUT) 设置，默认为 `\[low\]` 。
+在输出很多的任务名称中加上 `[low]` ，**应用筛选**就会隐藏该任务及其输出行。
+
+多步骤作业的页面会在主作业下方逐个显示每个步骤，每个步骤位于一个标题栏下，例如
+**步骤 1 · Prepare the server (作业 ID 98)**，并显示其状态。点击标题（或在标题上按 Enter 或空格键）可折叠该输出，
+再次点击则展开。AWX/AAP 工作流还会显示其节点的状态。
+
+[工作流](../workflows/running.html#the-job)作业会把每个节点的输出保存在自己的输出中，每个节点位于一个 `WORKFLOW NODE` 横幅之下；
+它们会实时绘制其图，点击节点即可打开其输出。
+
+---
+
+## 在输出中查找文本
+
+从 7.3.0 起，作业页面的标题行上、作业操作的左侧有一个搜索框：**在输出中查找**。
+
+文本在输出中出现的每个位置都会被高亮，不区分大小写，页面会跳转到第一个位置。按 **Enter** 会跳到
+下一个，并以更醒目的方式显示，工具栏会显示当前是第几个、共几个（ **第 2 个，共 4 个** ），或者显示**未找到**。搜索会先展开输出及其
+各个部分，作业运行期间新的行也会被搜索，但页面不会移动。
+
+---
+
+## 浏览很长的输出
+
+从 7.3.0 起，很长的输出（在作业页面上，以及表单**提交**之后的下方）提供以下浏览方式：
+
+| 控件 | 作用 |
+|---|---|
+| 固定标题 | 某个部分（工作流节点、作业的 playbook、多步骤作业的步骤）的标题会固定在顶部，其行在下方滚动 |
+| **2 个失败** | 统计失败的任务，不包括 Ansible 被告知要忽略的失败；每次点击都会跳到下一个，并将其展开和高亮。没有失败任务时，**1 个错误**会改为统计错误行 |
+| 行号 | 每个行号都链接到对应的行，例如地址中的 `#L45` ：打开该地址会滚动到该行并将其高亮 |
+| 向上和向下按钮 | 页面滚动后显示在右下角，用于回到顶部或跳到末尾 |
+| **运行中**和**中止** | 作业运行期间，表单页面的状态栏会固定在窗口底部，点击其中的**中止**会立即停止作业 |
+
+---
+
+## 任务结果
+
+从 7.3.0 起，点击 playbook 输出中某台主机的结果行，会像 AWX 一样在**任务结果**对话框中打开该结果。
+
+结果行、其后的结果正文（ `=> { ... }` ）以及失败结果之前打印的错误，在鼠标悬停时会作为一个整体高亮，
+点击即可打开对话框。它适用于作业页面以及表单**提交**之后的下方，前提是 playbook 在 7.3.0 或
+更高版本的 RTE 上运行，因为结果与[主机和任务](#hosts-and-tasks)来自相同的事件。对话框包含以下选项卡：
+
+| 选项卡 | 显示内容 |
+|---|---|
+| **详情** | 状态、主机、play、任务、模块、循环项、开始时间、持续时间、返回码和消息 |
+| **JSON** 和 **YAML** | 模块的完整结果，带语法着色和行号 |
+| **标准输出**和**标准错误** | 结果的 `stdout` 和 `stderr` （如果有） |
+
+只有当作业以详细模式运行时，才会保存完整结果，以及相应的 **JSON**、**YAML** 和输出选项卡，因为这时输出
+本身也会显示它；否则对话框只显示详情。即使在详细模式下，模块的参数（ `invocation` ）也会被
+排除，看起来像机密的键的值会被掩码，并且结果一旦超过 64 KB 的 JSON 就会被截断。
+
+---
+
+## 工作流图
+
+从 7.3.0 起，正在运行的工作流的图会自动滑动，让正在运行的节点始终可见。
+
+如果您把图滚动开，它会停留在您放置的位置，并显示**跟随正在运行的节点**按钮，以便再次跟随。鼠标悬停在节点上
+会显示其卡片和完整名称，并突出显示该节点及其连接，图的其余部分则变淡。图带有**适应
+屏幕**和**全屏**按钮，在表单**提交**之后的下方，点击节点会像在作业页面上一样打开其输出。
+
+---
+
+## 主机和任务
+
+自 7.3.0 起，在 7.3.0 或更高版本的 RTE 上运行的 playbook 作业，会在其文本输出之外记录结构化事件：每个 play、任务
+和主机结果，以及汇总。输出工具栏中的**主机和任务**会在输出上方的面板中显示它们，适用于作业页面以及
+表单**提交**之后的下方。作业有了事件之后就会提供此按钮，作业运行期间面板每隔几秒重新读取一次：
+
+| 视图 | 显示内容 |
+|---|---|
+| **网格** | 每台主机的汇总（ok、changed、failed、unreachable、skipped、rescued、ignored），然后是主机与任务的网格：每个单元格按该主机在该任务上的结果着色，悬停时显示其消息和时间，或者显示*未运行* |
+| **时间线** | 每个任务显示为一个条形，其长度为最慢主机所用的时间，并显示以秒为单位的时间和总计 |
+
+文本输出保持原样。事件由 RTE 自带的 `af_events` 回调插件写入，因此 playbook 无需任何修改。
diff --git a/i18n/zh/_use/jobs/index.md b/i18n/zh/_use/jobs/index.md
new file mode 100644
index 0000000..0570c64
--- /dev/null
+++ b/i18n/zh/_use/jobs/index.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: 作业
+nav_order: 3
+has_children: true
+has_toc: false
+redirect_from:
+  - /jobs.html
+permalink: /jobs/
+translated_from: 5ebe08c87f55b79169432884bb849e27dde03cb2
+---
+
+# 作业
+{: .no_toc }
+
+跟踪、中止、重新运行、批准和删除由表单启动的作业
+{: .fs-6 .fw-300 }
+
+---
+
+面向所有运行表单的用户：什么是作业、在哪里找到它，以及谁能看到它。
+
+---
+
+## 什么是作业
+
+作业是表单的一次运行：表单一经提交，AnsibleForms 就会记录它及其状态、extravars 和输出。
+
+每个作业保存：
+
+* 它运行的**表单**以及运行它的**用户**（包括用户类型，例如 `local` 或 `ldap` ）；
+* 它的**作业类型**和**状态**，以及**开始时间**和**结束时间**；
+* 它的**输出**、运行时使用的 extravars 和凭据，以及在表单中输入的字段值。
+
+多步骤表单会为表单创建一个作业，并为每个步骤各创建一个作业。各步骤关联到主作业，并列在其下方。
+
+同样的作业也可以通过 [REST API](../api/jobs.html) 运行、跟踪和管理。
+
+---
+
+## 作业页面
+
+标题栏中的**作业**链接会打开所有作业的列表，最新的排在最前（ `/jobs/all` ）。只有角色设置了 `showJobs` [角色选项](../config/roles.html#role-options)的用户
+才能看到该页面及其链接。
+
+![作业列表](../assets/screenshots/job-log.jpg)
+
+左侧菜单按时间对作业进行分类，每个条目都显示作业数量；状态条目会按该状态筛选列表：
+
+| 部分 | 菜单条目 | 显示内容 |
+|---|---|---|
+| **过去** | **成功** | 状态为 `success` 的作业 |
+| | **失败** | 状态为 `failed` 的作业 |
+| | **已中止** | 状态为 `aborted` 的作业 |
+| | **已拒绝** | 状态为 `rejected` 的作业 |
+| | **已放弃** | 状态为 `abandoned` 的作业 |
+| **现在** | **运行中** | 状态为 `running` 的作业 |
+| | **等待审批** | 状态为 `approve` 的作业；有作业等待时计数变为橙色 |
+| **未来** | **已计划** | [调度](schedules.html)页面（角色选项 `allowScheduledJobs` ） |
+| | **已保存** | [保存的作业](stored-jobs.html)页面（角色选项 `allowStoredJobs` ） |
+
+菜单中没有显示所有作业的条目：标题栏中的**作业**链接会显示所有作业，包括 `warning` 作业。
+
+在表格上方的标题行上：
+
+* **搜索框**保留那些显示的列中包含该文本（不区分大小写）的作业，或者其某个步骤的 ID
+  或目标包含该文本的作业；
+* **删除**（带有已勾选作业的数量）会一起删除第一列中勾选的作业；
+* **列**用于显示或隐藏 `id` 、 `form` 、 `job type` 、 `status` 、 `start time` 、 `end time` 、 `duration` 和 `user` 列；
+  正在运行的作业的持续时间会不断增加；
+* **刷新**会重新加载列表。
+
+列表加载最新的作业，数量由 [`JOBS_LIST_SIZE`](../customization/features.html#env_JOBS_LIST_SIZE) 设置决定
+（**设置 > 系统 > 常规**，**作业**选项卡，默认 `1000` ）；其分页、搜索和筛选都只覆盖这些作业。
+
+每一列都可以排序，并有自己的筛选字段。多步骤作业在其 `form` 前面有一个箭头，可展开
+其各个步骤；点击行的其余部分会打开该作业。
+
+标题栏中的铃铛统计等待您审批的作业数量，并打开**等待审批**列表。对于能看到
+运行器的用户，它还会统计[等待批准的运行器](../runners/registration.html#approving-an-rte)，即请求加入的 RTE，
+当只有运行器在等待时，会打开**连接 > 运行器**。两者都在等待时，它会打开一个菜单，包含**等待批准的作业**和
+**等待批准的运行器**，每项都带有其数量。
+
+---
+
+## 谁能看到哪些作业
+
+用户能看到的作业取决于其角色：
+
+| 用户 | 能看到 |
+|---|---|
+| 管理员（ `admin` 角色） | 所有作业 |
+| 角色选项 `showAllJobLogs` | 所有作业 |
+| 角色选项 `manageAllJobs` （从 7.3.0 起） | 所有作业，并且可以中止、删除和重新运行它们 |
+| 其他任何用户 | 自己的作业，以及等待审批且审批指定了其某个角色的作业 |
+
+在 7.2 及之前，每个用户都可以打开任何等待审批的作业，包括其 extravars 和输出；从 7.3.0 起，只有其所有者和
+审批人才能打开。能看到作业并不意味着可以对它执行所有操作：中止、删除和重新运行其他用户的作业需要管理员或
+`manageAllJobs` ，而 `showAllJobLogs` 只用于显示作业。删除还需要 `allowJobDeletion` ，重新运行还需要 `allowJobRelaunch` 。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [状态和类型](statuses.html) | 作业可能具有的每种状态，以及作业的种类 |
+| [跟踪作业](following.html) | 实时输出、extravars、筛选和下载 |
+| [作业操作](actions.html) | 运行、中止、重新运行、批准或拒绝以及删除作业 |
+| [调度](schedules.html) | 稍后运行表单或按 cron 调度运行，以及管理所有调度 |
+| [保存的作业](stored-jobs.html) | 保存表单的数据，以便以后再次加载 |
+| [清理](cleanup.html) | 因重启而中断的作业，以及已结束作业的保留时长 |
diff --git a/i18n/zh/_use/jobs/schedules.md b/i18n/zh/_use/jobs/schedules.md
new file mode 100644
index 0000000..867a829
--- /dev/null
+++ b/i18n/zh/_use/jobs/schedules.md
@@ -0,0 +1,170 @@
+---
+layout: default
+title: 调度
+parent: 作业
+nav_order: 4
+redirect_from:
+  - /schedules.html
+  - /schedules/
+  - /schedules/scheduling.html
+  - /schedules/schedules-page.html
+translated_from: 7ffab643975d7705375fbd02588c9db76e27f74f
+---
+
+# 调度
+{: .no_toc }
+
+稍后运行表单或按 cron 调度运行，以及管理所有调度
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 表单操作
+
+表单不只能立即运行：其**提交**按钮旁边的下拉菜单中还有另外三个操作。
+
+| 操作 | 作用 | 角色选项 |
+|---|---|---|
+| **调度（周期性）** | 创建一个按 cron 表达式运行表单的调度 | `allowScheduledJobs` |
+| **稍后运行（一次性）** | 创建一个在您选定的日期和时间运行一次表单的调度 | `allowPlannedJobs` |
+| **保存** | 保存字段值，以便以后再次加载到表单中 | `allowStoredJobs` |
+
+角色选项关闭的操作不会显示。执行任何这些操作之前，表单都会像**提交**时一样进行验证。两种
+调度操作都会在**调度**页面上创建一个条目；**保存**会在**保存的作业**页面上创建一个条目。
+[作业](./)页面的侧栏在**未来**下以**已计划**和**已保存**打开它们。这些角色选项的说明
+见[角色选项](../config/roles.html#role-options)。
+
+{: .warning }
+> 请把 `allowScheduledJobs` 视为管理员级别的选项。其调度不归创建它们的用户所有：每个拥有
+> 该选项的用户都能看到并修改所有调度。这样的调度还会以管理员权限运行任何表单，无论
+> 创建者自己的访问权限如何。只把它授予您会像信任管理员一样信任的角色。
+
+{: .note }
+> **稍后运行（一次性）** 只需要 `allowPlannedJobs` 。对于没有 `allowScheduledJobs` 的用户，它会**以该
+> 用户身份**计划一次运行：服务器检查该用户是否可以运行该表单，到时间时作业以该用户身份运行，并归其所有
+> （参见[计划的运行](#planned-runs)）。
+
+---
+
+## 调度表单
+
+填写表单，然后打开**提交**旁边的下拉菜单，选择其中一个调度操作。
+
+- **调度（周期性）** 会打开**创建调度**：输入**名称**和 **Cron 表达式**（默认值 `0 0 * * *`
+  表示每天午夜运行），然后选择**创建调度**。
+- **稍后运行（一次性）** 会打开**稍后运行**：输入**名称**并选择**运行时间**的日期和时间，然后选择
+  **调度作业**。
+
+名称在所有调度中必须唯一。调度会保存表单的名称，以及表单在那一刻生成的 extravars 的副本，
+以 YAML 格式写入；每次运行都使用该副本，因此要更改作业收到的内容，请在**调度**页面上编辑它。
+
+![调度](../assets/screenshots/schedules.jpg)
+
+---
+
+## 调度页面
+
+**调度**页面列出所有调度，从 7.3.0 起带有**已启用**列，需要 `allowScheduledJobs` 。每一行的菜单提供：
+
+| 操作 | 作用 |
+|---|---|
+| **编辑** | 修改名称、类型、cron 表达式或运行时间、表单以及 extra vars |
+| **立即运行** | 立即运行该调度，不等待其 cron 表达式或运行时间 |
+| **启用**或**禁用** | 根据**已启用**列的状态，打开或关闭该调度（从 7.3.0 起） |
+| **删除** | 移除该调度；它会立即停止运行 |
+| **最近输出** | 在调度页面上显示最近一次运行报告的内容，例如它启动的作业编号 |
+
+也可以在这里从头创建调度。选择**表单**，然后勾选**一次性运行**并设置
+**运行时间**，或者不勾选并设置 **Cron 调度**。**Extra vars** 是 YAML，没有表单来填写它，因此请自行添加
+playbook 需要的值，以字典（键: 值对）的形式。
+
+**Cron 调度**字段是一个 cron 编辑器：它会用文字描述表达式，提供预设，并预览接下来的
+几次运行。服务器会拒绝它无法运行的表达式，或者永远不会发生的表达式。
+
+从 7.3.0 起，每个调度都有一个**已启用**开关，可以暂停调度而无需删除它。关闭的调度仍保留在页面上，
+其设置不变，但不会自行运行：周期性调度会跳过其 cron 触发点，一次性调度则会越过其
+**运行时间**一直等待，直到再次打开。**立即运行**仍然可以按需运行它。新的调度默认开启，7.3.0 之前
+已存在的调度在升级后也处于开启状态。
+
+---
+
+## Cron 表达式和时区
+
+周期性调度使用标准的 5 字段 cron 表达式：分钟、小时、月中的日、月份和星期。
+
+| 表达式 | 运行时间 |
+|---|---|
+| `*/15 * * * *` | 每 15 分钟 |
+| `0 2 * * *` | 每天 02:00 |
+| `30 7 * * 1-5` | 周一至周五 07:30 |
+| `0 0 1 * *` | 每月第一天的午夜 |
+
+更多示例，以及编辑器不接受的 cron 功能，请参阅常见问题中的
+[我可以使用哪些 cron 表达式？](../faq.html#which-cron-expressions-can-i-use)。
+
+{: .note }
+> Cron 调度按服务器的时区运行，该时区由 [`LOG_TZ`](../customization/logging.html#env_LOG_TZ) 设置（默认 `UTC` ），
+> 而不是您的个人资料或浏览器的时区。cron 编辑器也按同一时区预览接下来的运行。
+
+---
+
+## 调度如何运行
+
+调度到期时会进入队列，服务器每 10 秒检查一次队列，并逐个启动排队的调度。
+
+- **周期性**调度在上一次运行仍在排队或运行时会跳过当次触发，因此各次运行永远不会重叠。
+- **一次性**调度在**运行时间**之后一分钟内运行，然后被删除，通过**立即运行**启动时也是如此。
+- **状态**在作业已启动时为 `success` ，无法启动时为 `failed` 。 `success` 只表示作业已
+  运行：请打开作业查看其最终结果。
+
+用 `allowScheduledJobs` 创建的调度以内置用户 `Schedule Service` （类型 `schedule` ）运行，拥有
+`admin` 角色。它可以运行任何表单，无论创建调度的人有何访问权限，其 extravars 中的 `ansibleforms_user`
+描述的就是该用户。而[计划的运行](#planned-runs)则以计划它的用户身份运行。
+
+作业还会得到一个 `schedule` 对象（包含其 `id` 、 `name` 和 `form` ），这样 playbook 就知道是调度启动了它：
+
+```yaml
+schedule:
+  id: 3
+  name: Nightly cleanup
+  form: Cleanup servers
+```
+
+---
+
+## 计划的运行
+
+没有 `allowScheduledJobs` 的用户使用**稍后运行（一次性）** 时，会创建一个计划的运行：一个与该用户绑定的一次性调度。
+
+- **计划时**，服务器会检查该用户是否可以运行该表单（其 `roles` ），详细模式需要
+  `allowVerboseMode` 。计划的运行始终是一次性的；cron 表达式会被拒绝。
+- **在运行验证为 `enforce` 时**，字段值会在计划时检查，因此本会被拒绝的运行会在
+  用户还在查看时就被拒绝。
+- **运行时**，作业以该用户身份运行并归其所有，经过与从浏览器运行相同的检查：
+  当时的表单角色、去除保留的 extravars，以及运行验证。 `ansibleforms_user` 描述的就是该用户。
+
+计划者看不到**调度**页面，因为它需要 `allowScheduledJobs` ；作业会出现在他们自己的作业历史中。
+
+---
+
+## 表单发生变化时
+
+调度按名称引用其表单，并在每次运行时按表单当时的定义运行。
+
+- **表单被编辑**：下一次运行使用新的定义（playbook、模板、清单）以及调度中保存的
+  extravars。表单不会被渲染，因此不会重新计算任何字段；请编辑调度的 extra vars 使其匹配。
+- **表单被重命名或移除**：运行失败，**状态**变为 `failed` ，**最近输出**显示
+  `Failed to launch : No such form '<name>'` 。请编辑调度并选择正确的表单，或者删除它。
+
+---
+
+## 作业历史中的调度作业
+
+调度的每次运行都会创建一个普通作业，列在[作业](./)页面上，其用户为 `Schedule Service` ；
+如果是计划的运行，则为计划它的用户。
+
+`Schedule Service` 作业不属于创建调度的人，因此只有管理员和
+拥有 `showAllJobLogs` 的用户才能看到；计划的运行所产生的作业，其用户也能看到。调度的**最近输出**会指出它启动的作业，方便您在列表中找到它。
diff --git a/i18n/zh/_use/jobs/statuses.md b/i18n/zh/_use/jobs/statuses.md
new file mode 100644
index 0000000..5834491
--- /dev/null
+++ b/i18n/zh/_use/jobs/statuses.md
@@ -0,0 +1,58 @@
+---
+layout: default
+title: 状态和类型
+parent: 作业
+nav_order: 1
+translated_from: 5974310f0d30079e77ad45698ed2afb70e68ce1e
+---
+
+# 状态和类型
+{: .no_toc }
+
+作业可能具有的每种状态，以及作业的种类
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 作业状态
+
+AnsibleForms 会为作业设置以下状态。列表中每种状态都显示为一个彩色标签：
+
+| 状态 | 含义 | 您可以做什么 |
+|---|---|---|
+| `running` | 作业正在运行，或者已批准的作业已恢复执行 | 跟踪其输出，中止它 |
+| `approve` | 作业在运行之前（或多步骤作业的某个步骤运行之前）停在[审批点](../forms/approval.html)等待 | 如果您的某个角色是审批人，可以批准或拒绝它 |
+| `success` | playbook、模板或每个步骤都已无错误地完成 | 查看输出、重新运行、删除 |
+| `failed` | 作业以错误结束，或者运行本身失败 | 查看输出了解原因、重新运行、删除 |
+| `warning` | 多步骤作业已完成，但某个设置了 `continue` 的步骤失败了 | 查看输出、重新运行、删除 |
+| `aborted` | 作业在 AnsibleForms 中被中止，或者 AWX / AAP 作业被取消 | 查看输出、重新运行、删除 |
+| `rejected` | 审批人拒绝了该作业；它从未运行 | 查看输出、重新运行、删除 |
+| `abandoned` | AnsibleForms 停止跟踪该作业（参见[已放弃的作业](cleanup.html#abandoned-jobs)） | 检查受管主机、重新运行、删除 |
+
+`running` 为蓝色， `success` 为绿色并显示为**成功**， `failed` 为红色。 `approve` 为橙色并显示为**等待审批**，
+这样等待人工处理的作业就与已停止的作业区分开来； `warning` 、 `aborted` 和 `rejected` 为琥珀色。 `abandoned` 为
+灰色：没有人停止它，只是运行它的东西已经不在了。
+
+---
+
+## 作业类型
+
+作业类型取决于启动该作业的表单的 `type` ，与列表和作业页面上显示的一致：
+
+| 显示的类型 | 运行的内容 |
+|---|---|
+| `ansible` | 在 RTE 上运行的 Ansible playbook |
+| `awx` 、 `aap` 、 `ascender` | AWX、AAP 或 Ascender 上的作业模板或工作流模板 |
+| `semaphore` | Semaphore UI 上的模板 |
+| `rundeck` 、 `jenkins` | Rundeck 或 Jenkins 上的作业 |
+| `workflow` | 一个[工作流](../workflows/)，其 playbook 节点作为其下的独立作业运行 |
+| `multistep` | 已弃用，请使用 `workflow` ：一系列步骤，每个步骤都作为主作业下的独立作业记录 |
+
+模板作业以 `awx` 作业的形式保存（在 REST API 中也是如此），并显示其所运行的运行器类型，无论
+表单如何称呼它：在 AAP 运行器上运行的 `awx` 类型表单会显示 `aap` 。
+
+表单方面的内容请参阅 [Ansible 表单](../forms/ansible.html)、[AWX 表单](../forms/awx.html)、[工作流表单](../forms/workflow.html)和
+[多步骤表单](../forms/multistep.html)。
diff --git a/i18n/zh/_use/jobs/stored-jobs.md b/i18n/zh/_use/jobs/stored-jobs.md
new file mode 100644
index 0000000..2ce0971
--- /dev/null
+++ b/i18n/zh/_use/jobs/stored-jobs.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: 保存的作业
+parent: 作业
+nav_order: 5
+redirect_from:
+  - /schedules/stored-jobs.html
+translated_from: c4e55de429d31936d8735965a2f487c070b9140d
+---
+
+# 保存的作业
+{: .no_toc }
+
+保存表单的数据，以便以后再次加载
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 保存的作业
+
+保存的作业会保留表单的值，以便您再次加载它们，而不必每次都填写相同的字段。
+
+要保存，请填写表单，打开**提交**旁边的下拉菜单并选择**保存**。在**保存表单数据**中，输入
+**名称**、可选的**描述**以及**过期时间（可选）** 日期，然后保存。密码字段和常量字段
+从不保存。子表单的**保存**按钮旁边也有同样的**保存**操作，可以保留尚未完成的值而不
+对其进行验证。
+
+要加载，请在表单顶部选择**从已保存项加载**。**加载已保存的表单**会列出您为该表单保存的作业，以及
+其创建日期和过期日期；选择其中一个即可用其值填充表单。在您提交之前不会运行任何内容。
+
+保存的作业保存在 AnsibleForms 数据库中（表 `stored_jobs` ），包含表单名称、以
+`<type>/<username>` 表示的您的用户（例如 `local/admin` ），以及 JSON 格式的值。名称在每个用户和表单中必须唯一；
+用相同的名称再保存一个会失败，并提示 "A saved form with this name already exists"。
+
+---
+
+## 管理保存的作业
+
+**保存的作业**页面列出保存的作业，以及其表单、用户、创建日期和过期日期，需要 `allowStoredJobs` 。
+
+- **编辑**会打开该保存作业自己的页面：其**详细信息**（名称、表单、过期时间）以及其**值**，即以 YAML 表示的已保存
+  字段值，可以在那里修改并保存。
+- **在表单中打开**会打开其表单并填入保存的值；在您提交之前不会运行任何内容。
+- **删除**会将其移除。您可以删除自己保存的作业；拥有 `showSettings` 的用户可以删除任何保存的作业。
+- **过期时间**已过的保存作业每天 04:00（按 `LOG_TZ` ）自动删除。
diff --git a/i18n/zh/_use/profile/account.md b/i18n/zh/_use/profile/account.md
new file mode 100644
index 0000000..3ef329e
--- /dev/null
+++ b/i18n/zh/_use/profile/account.md
@@ -0,0 +1,22 @@
+---
+layout: default
+title: 账户
+parent: 个人资料
+nav_order: 1
+translated_from: 35964a289ed9b27e456ace0ed3fb2f930c55f533
+---
+
+# 账户
+{: .no_toc }
+
+您当前以谁的身份登录
+{: .fs-6 .fw-300 }
+
+---
+
+账户视图显示您当前以谁的身份登录，以及决定您访问权限的因素：
+
+- **用户名**和**登录类型**：本地账户、LDAP、Microsoft Entra ID 或 OpenID Connect。
+- **组**：随您的登录而来的组，例如 `local/admins` 或 `ldap/Domain Admins` 。
+- **角色**： `config.yaml` 中与这些组和您的用户匹配的角色。它们决定了
+  您能看到哪些表单以及拥有哪些选项。
diff --git a/i18n/zh/_use/profile/api-token.md b/i18n/zh/_use/profile/api-token.md
new file mode 100644
index 0000000..3dbc8d9
--- /dev/null
+++ b/i18n/zh/_use/profile/api-token.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: API 令牌
+parent: 个人资料
+nav_order: 5
+translated_from: d3889d55e63b57c6b78525515638d33617daa750
+---
+
+# API 令牌
+{: .no_toc }
+
+为脚本和 AI 代理创建令牌
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 谁可以创建
+
+长期有效的令牌让脚本无需您的密码即可调用 API。从 7.3.0 起，它需要 `allowApiTokens` 角色选项：
+
+```yaml
+roles:
+  - name: automation
+    groups:
+      - local/automation
+    options:
+      allowApiTokens: true
+      extendedTokenExpiration: true   # also tokens that never expire
+```
+
+在 7.2.0 及之前，只需要 `extendedTokenExpiration` 选项。7.3.0 之前只设置了该选项的角色会被赋予
+`allowApiTokens` ，因此能保留其令牌；两者都设置时，还可以创建永不过期的令牌。参见[角色选项](../config/roles.html#role-options)。
+
+---
+
+## 创建令牌
+
+**个人资料 > API 令牌**标题行上的**新令牌**会打开一个分三步的向导：
+
+1. **详细信息**：一个名称，便于您在列表中认出该令牌，以及它的有效期。可选 30、90、180
+   或 365 天，最多不超过 [`API_TOKEN_MAX_DAYS`](../customization/security.html#env_API_TOKEN_MAX_DAYS) （默认 90），也可以选择该
+   最大值本身，拥有 `extendedTokenExpiration` 时还可以选择**永不过期**。请选择您的脚本所需的最短期限。
+2. **确认**：本地账户或 LDAP 账户需要输入密码，该密码不会保存在令牌中。Microsoft Entra ID 或
+   OIDC 账户在这里没有密码：其令牌由其会话生成，该会话必须是在最多 10 分钟之前
+   登录的，因此提供商可能会先要求您重新登录。
+3. **复制**：显示令牌，**仅显示一次**。用**复制**复制它，并像保管密码一样妥善保管。
+
+在每次 API 调用的 `Authorization` 请求头中发送该令牌：
+
+```bash
+curl -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/job
+```
+
+API 令牌不能用来创建另一个令牌。SSO 账户的令牌带有其最近一次登录时的角色：身份提供商中的
+组变更，只有在您重新登录并创建新令牌后才会生效。
+
+---
+
+## 您的令牌
+
+您创建的令牌会列出其名称，以及各自的创建时间、过期时间和最后使用时间；行菜单中的**撤销**可以终止某个令牌。
+管理员也可以在**设置 > 用户**下您的页面中看到并撤销它们。令牌在过期时终止，或者更早终止：
+
+- **撤销**，在列表中操作；
+- **使用该令牌退出登录**（ `POST /api/v2/auth/logout` ，在 `Authorization` 请求头中带上该令牌），这会将其连同
+  创建它的会话一起终止；
+- **修改密码**，这会终止您账户在此之前创建的所有令牌和会话；封禁您的账户也是如此。
+
+永不过期的令牌在这些情况下同样会终止。脚本也可以通过登录 API 及其
+`expiryDays` 参数自行请求令牌（ `POST /api/v2/auth/login?expiryDays=90` ，或 `expiryDays=never` ）；更长的 `expiryDays` 会被截断
+为 `API_TOKEN_MAX_DAYS` 。
diff --git a/i18n/zh/_use/profile/index.md b/i18n/zh/_use/profile/index.md
new file mode 100644
index 0000000..892fdf9
--- /dev/null
+++ b/i18n/zh/_use/profile/index.md
@@ -0,0 +1,57 @@
+---
+layout: default
+title: 个人资料
+nav_order: 4
+description: 您的账户、偏好设置、密码、权限和 API 令牌
+has_children: true
+has_toc: false
+permalink: /profile/
+translated_from: f2ec61e6df09174e802478963ba70ff7dee51098
+---
+
+# 个人资料
+{: .no_toc }
+
+您的账户、偏好设置、密码、权限和 API 令牌
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+面向所有用户：您自己的账户、偏好设置、密码、权限和 API 令牌。
+
+从右上角的头像打开您的个人资料：**个人资料**。
+
+---
+
+## 打开视图
+
+左侧菜单按字母顺序列出个人资料的各个视图。每个视图都有自己的地址，
+因此您可以直接链接到它：
+
+| 视图 | 地址 |
+|---|---|
+| 账户 | `/profile/account` |
+| API 令牌 | `/profile/token` |
+| 密码 | `/profile/password` |
+| 权限 | `/profile/permissions` |
+| 偏好设置 | `/profile/preferences` |
+
+只写 `/profile` 会打开菜单中的第一个视图。您的角色不允许的视图会被隐藏；其地址会改为打开第一个
+视图。只有当您的某个角色拥有 `allowApiTokens` 角色选项时，才会显示 **API 令牌**。
+
+---
+
+## 本节内容
+
+每个主题都在单独的页面中介绍：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [账户](account.html) | 您当前以谁的身份登录 |
+| [偏好设置](preferences.html) | 语言、主题、时区、日期格式和桌面通知 |
+| [密码](password.html) | 修改本地账户的密码 |
+| [权限](permissions.html) | 您的角色允许您做什么 |
+| [API 令牌](api-token.html) | 为脚本和 AI 代理创建令牌 |
diff --git a/i18n/zh/_use/profile/password.md b/i18n/zh/_use/profile/password.md
new file mode 100644
index 0000000..3ae33c1
--- /dev/null
+++ b/i18n/zh/_use/profile/password.md
@@ -0,0 +1,19 @@
+---
+layout: default
+title: 密码
+parent: 个人资料
+nav_order: 3
+translated_from: 68ef2ad67e934aa9b72e2b71895e30f7de352659
+---
+
+# 密码
+{: .no_toc }
+
+修改本地账户的密码
+{: .fs-6 .fw-300 }
+
+---
+
+输入您的当前密码，再输入两次新密码，然后点击**修改密码**。
+
+LDAP、Entra ID 和 OpenID Connect 账户则需要在相应的提供商处修改密码。
diff --git a/i18n/zh/_use/profile/permissions.md b/i18n/zh/_use/profile/permissions.md
new file mode 100644
index 0000000..415270a
--- /dev/null
+++ b/i18n/zh/_use/profile/permissions.md
@@ -0,0 +1,32 @@
+---
+layout: default
+title: 权限
+parent: 个人资料
+nav_order: 4
+translated_from: 08770187a1159539d1d450cf7dddf80c6943cfed
+---
+
+# 权限
+{: .no_toc }
+
+您的角色允许您做什么
+{: .fs-6 .fw-300 }
+
+---
+
+角色选项按选项卡分组，每个选项卡都会显示您拥有其中多少个选项，例如 `5/8` ：
+
+| 选项卡 | 相关选项 |
+|---|---|
+| **访问和集成** | 登录、聊天助手、MCP 服务器、文件上传和 API 令牌 |
+| **设计器** | 打开设计器，以及编辑表单、playbook、工作流、清单和变量文件 |
+| **作业** | 查看作业及其 extravars 或工件，重新运行、删除、调度和保存作业 |
+| **设置** | 设置页面、日志、审计日志和备份 |
+| **其他** | 手动在角色中设置、不属于其他任何选项卡的选项；始终是最后一个选项卡 |
+
+其他选项卡按字母顺序排列。每个选项卡都是一个表格，包含**设置**（选项）、**描述**
+（作用）和**您的权限**三列：**允许**或**不允许**。因另一个选项而生效的选项会在
+其描述下方注明：**已包含在**您拥有的某个选项**中**会开启它，**需要**您缺少的某个选项则会让它保持关闭。
+
+选项来自您在 `config.yaml` 中各个角色的 `options` ；[角色](../config/roles.html)页面介绍了它们
+如何组合。
diff --git a/i18n/zh/_use/profile/preferences.md b/i18n/zh/_use/profile/preferences.md
new file mode 100644
index 0000000..7cb4adb
--- /dev/null
+++ b/i18n/zh/_use/profile/preferences.md
@@ -0,0 +1,89 @@
+---
+layout: default
+title: 偏好设置
+parent: 个人资料
+nav_order: 2
+translated_from: d67f4050fea45cbd0cccd16c37cdc03838042925
+---
+
+# 偏好设置
+{: .no_toc }
+
+语言、主题、时区、日期格式和桌面通知
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 偏好设置项
+
+偏好设置视图可以改变 AnsibleForms 在您面前的外观。每个选择都保存在您做出选择的
+浏览器中，因此换一个浏览器或电脑时会从默认值开始。
+
+| 设置 | 可选项 | 也可以在这里设置 |
+|---|---|---|
+| 语言 | Català、Deutsch、English、Español、Français、Italiano、Nederlands、Polski、Português、日本語（日语）、简体中文 | 标题栏中的旗帜 |
+| 主题 | 跟随浏览器、浅色、深色，或颜色（标题栏使用您选择的颜色） | 标题栏中的太阳图标 |
+| 表单视图 | 磁贴或列表 | 表单页面上的按钮 |
+| 时区 | UTC、此浏览器的时区，或按名称选择的任意时区 | 仅限此处 |
+| 日期格式 | `YYYY-MM-DD` 、 `DD/MM/YYYY` 、 `MM/DD/YYYY` 或 `DD.MM.YYYY` | 仅限此处 |
+| 桌面通知 | 开或关 | 仅限此处 |
+
+从 7.3.0 起，该视图分为多个选项卡，每个选项卡都有自己的地址（ `/profile/preferences/<tab>` ）：**外观**（语言、主题和表单
+视图）、**日期和时间**（时区和日期格式）以及**通知**。它们上方的搜索框会在所属选项卡的名称下列出匹配的
+设置。选择在点击**保存**之前只是草稿，带着未保存的修改离开该视图时会先询问确认。
+
+**跟随浏览器**会随浏览器切换浅色或深色，并跟着浏览器一起变化。从 7.3.0 起它是默认主题，除非您的
+管理员选择了其他主题。在此处或标题栏的主题菜单中，将鼠标悬停在**颜色**主题的某个颜色上，会以该颜色预览应用，
+指针离开调色板时会恢复之前的主题；只有点击之后才会真正改变。
+
+---
+
+## 桌面通知
+
+从 7.3.0 起，对于角色设置了 `showJobs` 的用户，**通知**选项卡可以在此浏览器中开启桌面通知。
+
+浏览器会在第一次时请求权限。当浏览器阻止该站点的通知时，开关保持关闭，并说明如何
+允许通知；使用普通 `http` 的站点则完全无法显示通知。开启后，会在以下情况发出通知：
+
+| 时机 | 通知内容 | 点击后 |
+|---|---|---|
+| 您运行的作业结束时 | 表单及其结果，例如 *Patch Linux servers: 成功*，以及作业编号和持续时间 | 将该标签页切换到前台并显示该作业 |
+| 有作业等待您审批时 | 表单、作业编号以及运行者，并带有**批准**和**拒绝**按钮 | 打开等待审批的作业列表 |
+
+**批准**和**拒绝**按钮在 Chrome 和 Edge 中显示；Firefox 和 Safari 显示的通知不带这些按钮，使用
+自签名证书的站点也是如此，因为这些按钮需要 service worker。只有在 AnsibleForms 标签页打开时才会收到通知，
+即使在后台也可以：所有标签页都关闭后就不会再发送任何通知。无论打开了多少个标签页，每条通知只显示一次，并且
+多步骤作业的各个步骤以及您正在查看的作业不会发出通知。
+
+---
+
+## 时区
+
+AnsibleForms 中的日期和时间都按您选择的时区显示。这包括作业的开始
+和结束时间、审计日志、状态页面、备份、保存的作业，以及 API
+令牌的过期时间。修改时区会立即更新每个页面，无需重新加载。
+
+在您选择之前，适用管理员为所有人设置的时区（**设置 > 外观 > 默认值**，参见
+[外观](../appearance.html)），未修改时为 **UTC**。**此浏览器**跟随您电脑的时区，
+列表中包含所有按名称列出的时区，例如 `Europe/Madrid` 。卡片会以所选的时区和格式显示当前时间。
+
+---
+
+## 日期格式
+
+日期格式决定每个日期中日期部分的显示方式，每个选项都以今天的日期作为示例： `YYYY-MM-DD`
+（2026-10-12）、 `DD/MM/YYYY` 、 `MM/DD/YYYY` 或 `DD.MM.YYYY` 。在您选择之前，适用管理员设置的默认日期格式，
+未修改时为 `YYYY-MM-DD` 。与其他选项一样，它保存在此浏览器中。
+
+---
+
+## 哪些内容保留服务器时间
+
+有两个例外会保留服务器自己的时间：
+
+- **服务器日志和作业输出**是文本，其中包含服务器写入的时间。
+- **您输入的时间**，例如计划作业的运行时间，以及 cron 调度，都与
+  以前一样。
diff --git a/i18n/zh/_use/repositories/adding.md b/i18n/zh/_use/repositories/adding.md
new file mode 100644
index 0000000..7116d00
--- /dev/null
+++ b/i18n/zh/_use/repositories/adding.md
@@ -0,0 +1,114 @@
+---
+layout: default
+title: 添加仓库
+parent: Git 仓库
+nav_order: 1
+translated_from: 910365ea3ea4dec644e621ff8570917205671a76
+---
+
+# 添加仓库
+{: .no_toc }
+
+仓库页面、仓库的每个字段，以及在配置种子中声明仓库
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 仓库页面
+
+仓库在**设置 > 连接 > 仓库**下管理，需要 `showSettings` ，或者从 7.3.0 起需要
+`showConnectionsSettings` [角色选项](../config/roles.html#role-options)。有些修改只有管理员才能进行，参见[下文](#who-may-change-a-repository)。
+
+![仓库](../assets/screenshots/git.jpg)
+
+列表显示**名称**、**描述**、**分支**、**Head**（检出的提交的短哈希）、**拉取**和
+**推送**。仓库的**详情**选项卡在其 head 上方显示同样的拉取和推送标记：
+
+| 列 | 含义 |
+|---|---|
+| **拉取** | 最近一次克隆、拉取或重置：git 工作期间显示**运行中**，然后显示**成功**或**失败**；第一次之前显示短横线 |
+| **推送** | 最近一次推送失败时显示**失败**；在这里（由设计器）保存的更改尚未推送到远程仓库时显示**待推送的更改**；没有待推送内容时显示**成功**；第一次推送之前显示短横线 |
+
+推送列中的**成功**只表示没有等待推送的内容：远程仓库中可能仍有更新的提交，
+需要通过拉取获取。每一行的菜单包含以下操作：
+
+| 操作 | 作用 |
+|---|---|
+| **编辑** | 修改下面的字段 |
+| **拉取** | 克隆仓库；如果工作树已经存在，则拉取它 |
+| **推送** | 提交并推送工作树；仅适用于用于表单、配置、playbook、工作流或清单的仓库，并且只在有尚未推送的更改时才可用 |
+| **重置** | 删除工作树并重新克隆，这会丢弃本地更改 |
+| **更改凭据** | 打开仓库的**凭据**选项卡，以选择 git 使用的凭据 |
+| **显示上次拉取的输出** | 显示最近一次克隆、拉取或重置的 git 输出，密码会被掩码 |
+| **显示上次推送的输出** | 显示最近一次推送的 git 输出，密码会被掩码 |
+| **删除** | 移除该记录及其在 `REPO_PATH` 下的工作树；仅限管理员 |
+
+列表上方的**全部拉取**会一次拉取所有仓库。
+
+同一时间，一个仓库上只能运行一个 git 操作。第二个操作会被拒绝，并提示
+`Repository '<name>' not found or already running, try again later` 。
+
+---
+
+## 添加仓库
+
+点击**添加仓库**：向导会分四步询问各个字段（**仓库**、**凭据**、**用途**、**拉取
+计划**），保存后 AnsibleForms 会立即在后台开始克隆。
+
+![编辑仓库](../assets/screenshots/git-edit.jpg)
+
+| 字段 | 必填 | 含义 |
+|---|---|---|
+| **名称** | 是 | `REPO_PATH` 下的文件夹名称；字母、数字、短横线、下划线和点 |
+| **分支** | 是 | 要克隆、拉取和推送的分支，例如 `main` ；从 7.3.0 起为必填。只有配置种子中的仓库可以省略它，以克隆远程仓库的默认分支 |
+| **凭据** | 否 | [连接 > 凭据](../credentials.html)中的某个凭据，包含 git 使用的用户名以及密码或令牌；**添加凭据**可创建一个 |
+| **URI** | 是 | 远程仓库， `https://...` 或 SSH（ `git@git.example.com:team/forms.git` 、 `ssh://...` ） |
+| **启用定时拉取** | 否 | 按计划拉取仓库 |
+| **拉取计划** | 否 | 何时拉取，以 cron 表达式表示；启用定时拉取后才会显示 |
+| **描述** | 是 | 自由文本描述 |
+| **用于配置？** …… **用于清单?** | 否 | 仓库包含的内容，参见[上文](./#what-a-repository-is-for) |
+| **应用启动时拉取** | 否 | 每次 AnsibleForms 启动时克隆或拉取该仓库 |
+
+重命名仓库会把其工作树移动到新的文件夹，并把其拉取计划一并移过去。7 之前的仓库如果仍然
+有自己的用户，会在其**凭据**选项卡上注明：请选择一个凭据来替换它。
+
+---
+
+## 谁可以修改仓库
+
+仓库的内容会成为 AnsibleForms 加载和运行的内容，因此从 7.3.0 起，没有 `admin` 角色的用户不再能够：
+
+- 添加或删除仓库；
+- 修改其 **URI** 或**分支**；
+- 打开或关闭其任何**用于**标志。
+
+他们仍然可以修改其描述、拉取计划和凭据，并对其进行拉取、推送或重置。被运行器、
+连接或登录方式使用的凭据，他们无法选择；拒绝信息会指出该凭据，但不会透露其中的内容。
+
+---
+
+## 在配置种子中声明仓库
+
+仓库也可以在[配置种子](../seed/)中声明，这样新实例会在首次启动时克隆它们。
+
+```yaml
+repositories:
+  items:
+    - name: forms
+      description: Forms and configuration
+      uri: https://git.example.com/team/forms.git
+      branch: main
+      credential: git-bot
+      use_for_forms: true
+      use_for_config: true
+      rebase_on_start: true
+      cron: "*/15 * * * *"
+```
+
+字段与页面上的相同，包括 `credential` （种子或应用中的凭据）、 `rebase_on_start` （**应用启动时
+拉取**）和 `cron` （拉取计划）；仍然可以用 `user` 和 `password` 代替凭据。
+通过种子创建的仓库在界面中是只读的，如果启动时其工作树缺失，会被重新克隆；参见
+[托管对象](../seed/managed-objects.html)。
diff --git a/i18n/zh/_use/repositories/authentication.md b/i18n/zh/_use/repositories/authentication.md
new file mode 100644
index 0000000..77c2ebb
--- /dev/null
+++ b/i18n/zh/_use/repositories/authentication.md
@@ -0,0 +1,61 @@
+---
+layout: default
+title: 认证
+parent: Git 仓库
+nav_order: 2
+translated_from: 9e2bb180b35951e97851c21f388db0d7d54d4c73
+---
+
+# 认证
+{: .no_toc }
+
+使用令牌的 HTTPS、使用生成密钥的 SSH，以及自定义 git 命令
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 认证
+
+AnsibleForms 的认证方式取决于 **URI** 的形式。
+
+### 使用令牌的 HTTPS
+
+对于私有的 HTTPS 远程仓库，请选择一个**凭据**，其用户为 git 用户，其密码为个人访问令牌
+（或密码）。
+
+从 7.3.0 起，git 通过 `GIT_ASKPASS` 登录：用户名和令牌会传给每个与服务器通信的 git 命令，从不写入
+URL，因此不会保存在克隆的 `.git/config` 中，修改后的令牌会在下一次拉取或推送时生效。令牌需要
+读权限才能拉取，需要写权限才能推送。公开的远程仓库不需要凭据。
+
+在 7.2.0 及之前，两者都会插入到 URL 中，形如 `https://<user>:<token>@git.example.com/team/forms.git` 。当时创建的克隆会保留
+该 URL，直到下一次拉取或推送，届时其远程地址会被设回仓库自己的 **URI**。
+
+### 使用生成密钥的 SSH
+
+对于 SSH 远程仓库，AnsibleForms 使用自己的密钥对进行认证，该密钥对在首次启动时生成。
+
+1. 打开**设置 > 连接 > SSH**，在其**密钥**选项卡上复制**公钥**。
+2. 在 git 服务器上添加它，作为该仓库的部署密钥（如果需要推送，请赋予写权限），或者添加给一个有访问权限的用户。
+3. 用 SSH **URI** 添加仓库，例如 `git@git.example.com:team/forms.git` ，并且不选择凭据。
+
+密钥对位于 [`HOME_PATH`](../customization/paths.html#env_HOME_PATH) 下的 `.ssh/id_rsa` 中，因此请把该文件夹放在
+持久化存储上，否则重新创建容器时密钥会改变。
+
+对于使用 `user@host:path` 形式 URI 的克隆，AnsibleForms 会先对该主机运行 `ssh-keyscan` ，并把其密钥添加到
+已知主机中。对于其他远程仓库，请在首次克隆之前，在**设置 > 连接 > SSH** 的**已知主机**选项卡上
+添加该主机。
+
+### 自定义 git 命令
+
+克隆、拉取和推送命令可以通过三个设置替换，例如用于添加 git 选项。
+
+| 设置 | 默认值 | AnsibleForms 追加的内容 |
+|---|---|---|
+| [`GIT_CLONE_COMMAND`](../customization/configuration.html#env_GIT_CLONE_COMMAND) | `git clone` | `-b <branch>` 、 `--verbose` 、URI 和名称 |
+| [`GIT_PULL_COMMAND`](../customization/configuration.html#env_GIT_PULL_COMMAND) | `git pull` | `--verbose` |
+| [`GIT_PUSH_COMMAND`](../customization/configuration.html#env_GIT_PUSH_COMMAND) | `git push` | `-u origin HEAD` |
+
+从 7.3.0 起，这些命令不经过 shell 运行：引号可以正常使用，但 `;` 、 `|` 、 `&&` 或 `>` 之类的 shell 运算符会被拒绝。
diff --git a/i18n/zh/_use/repositories/designer.md b/i18n/zh/_use/repositories/designer.md
new file mode 100644
index 0000000..cdcf824
--- /dev/null
+++ b/i18n/zh/_use/repositories/designer.md
@@ -0,0 +1,40 @@
+---
+layout: default
+title: 设计器与推送
+parent: Git 仓库
+nav_order: 4
+translated_from: 9f1f2463b8bc0fb3c8b5b934435c305fef1f7f20
+---
+
+# 设计器与推送
+{: .no_toc }
+
+在设计器中编辑表单，并将其推送到仓库
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 在设计器中编辑和推送
+
+有用于表单的仓库时，设计器会编辑其工作树中的文件，并将它们推送回远程仓库。
+
+| 按钮 | 作用 |
+|---|---|
+| **保存（本地）** | 把表单和 `config.yaml` 写入工作树，但不提交 |
+| **保存（仓库）** | 提交并推送已保存的更改；有未推送的更改时才可用 |
+| **加载（仓库）** | 拉取表单仓库并重新加载设计器，如果有未保存的编辑会先请求确认 |
+
+表单保留在其仓库中；新的表单在您推送之前存放在 [`FORMS_STAGING_PATH`](../customization/paths.html#env_FORMS_STAGING_PATH) 中，但已经可以使用。
+保存在子文件夹中的表单会保留其相对路径： `team/deploy.yaml` 会被推送到仓库 forms 文件夹下的
+`team/deploy.yaml` 。如果新表单的路径在那里已经存在，则不会覆盖；它会留在暂存区中，因此请重命名它。
+有多个表单仓库时，**保存（仓库）** 和**加载（仓库）** 会询问使用哪一个，默认为包含 `config.yaml` 的那个。
+
+推送会暂存所有更改，以 `AnsibleForms` 的身份提交，提交信息为 `Forms sync by <user>` ，然后获取远程内容、在
+远程分支上变基并推送，最多重试五次。如果变基出现冲突，会中止变基并列出冲突的文件；
+请在远程仓库中修复它们，或者在仓库页面上使用**重置**。仓库页面上的**推送**也执行同样的操作。
+
+当单个表单仓库被克隆时是空的，AnsibleForms 会把本地的 `config.yaml` 和表单复制到其工作
+树中，这样推送（**保存（仓库）**，或仓库页面上的**推送**）就会发布它们。关于设计器的更多内容，请参阅[设计器与 git](../gui/designer-and-git.html)。
diff --git a/i18n/zh/_use/repositories/index.md b/i18n/zh/_use/repositories/index.md
new file mode 100644
index 0000000..e876bbb
--- /dev/null
+++ b/i18n/zh/_use/repositories/index.md
@@ -0,0 +1,110 @@
+---
+layout: default
+title: Git 仓库
+nav_order: 2
+has_children: true
+has_toc: false
+redirect_from:
+  - /repositories.html
+permalink: /repositories/
+translated_from: 8eb2dfed1f173597f36522be4b3bb4cb606557d6
+---
+
+# Git 仓库
+{: .no_toc }
+
+把表单、变量文件、配置和 playbook 保存在 git 中
+{: .fs-6 .fw-300 }
+
+---
+
+面向把表单、配置和 playbook 保存在 git 中的管理员：仓库可以包含什么，以及哪个来源优先。
+
+---
+
+## 仓库的用途
+
+仓库是 AnsibleForms 克隆并保持更新的 git 远程仓库，每个仓库都有一些开关，用于说明它包含什么：
+
+| 开关 | AnsibleForms 从中读取的内容 | 仓库中的文件夹 |
+|---|---|---|
+| **用于配置？** | 包含类别、角色和常量的 `config.yaml` | 根目录 |
+| **用于表单？** | 表单文件（设计器也会把它们保存回该仓库）及其变量文件 | `forms` 或根目录；变量文件在 `vars` 中 |
+| **用于 playbook？** | 作业运行的 Ansible playbook | `playbooks` 或根目录 |
+| **用于工作流?** | [工作流](../workflows/)文件，设计器也会把它们保存回该仓库 | 任意文件夹 |
+| **用于清单?** | 一个以仓库命名的清单，表单通过 `inventory:` 引用它 | 根目录： `inventory.yaml` 、 `group_vars` 、 `host_vars` |
+
+没有子文件夹时，使用仓库根目录。一个仓库可以包含所有内容；如果拆分成多个仓库，只有**用于
+表单**、**用于工作流**和**用于清单**可以在多个仓库上开启：其他开关只取第一个仓库，
+并记录一条警告。
+
+每个仓库都会被克隆到 [`REPO_PATH`](../customization/paths.html#env_REPO_PATH) 下以其名称命名的子文件夹中。
+
+### 一个仓库包含所有内容
+
+单个仓库可以包含表单、变量文件、配置和 playbook，只需开启相应的开关，每类内容使用一个子文件夹。
+
+```
+forms-repo/
+├── config.yaml        # categories, roles and constants
+├── forms/             # form files (*.yaml)
+├── playbooks/         # Ansible playbooks and roles
+└── vars/              # vars files used by forms
+```
+
+### 每种用途一个仓库
+
+使用独立的仓库可以让各个团队负责自己的部分，每个仓库开启一个开关，文件直接放在根目录中。
+
+| 仓库 | 开关 | 根目录中的内容 |
+|---|---|---|
+| `af-config` | **用于配置？** | `config.yaml` |
+| `af-forms-network` 、 `af-forms-storage` | **用于表单？** | 各团队的表单文件，合并到一个列表中 |
+| `af-playbooks` | **用于 playbook？** | playbook 和角色 |
+
+只有表单可以来自多个仓库；配置和 playbook 各自只能来自一个仓库。变量文件来自第一个包含 `vars`
+文件夹的表单仓库中的该文件夹。
+
+---
+
+## 仓库如何与本地文件夹结合
+
+仓库内容会替代对应的本地文件夹；下表总结了每类文件从哪里读取。
+
+| 内容 | 读取来源，以第一个匹配的为准 |
+|---|---|
+| 配置 | 1. 数据库，当配置保存在数据库中时（ [`ENABLE_CONFIG_IN_DATABASE`](../customization/configuration.html#env_ENABLE_CONFIG_IN_DATABASE) ） <br> 2. **用于配置**仓库中的 `config.yaml` <br> 3. 没有仓库用于配置时，**用于表单**仓库中的 `config.yaml` <br> 4. [`CONFIG_PATH`](../customization/paths.html#env_CONFIG_PATH) |
+| 表单 | 所有**用于表单**的仓库加上 `FORMS_STAGING_PATH` ；只有在没有这类仓库时才使用 [`FORMS_FOLDER_PATH`](../customization/paths.html#env_FORMS_FOLDER_PATH) |
+| Playbook | **用于 playbook** 的仓库，否则为 [`ANSIBLE_PATH`](../customization/paths.html#env_ANSIBLE_PATH) |
+| 变量文件 | 第一个包含 `vars` 文件夹的**用于表单**仓库中的该文件夹，否则为 [`VARS_FILES_PATH`](../customization/paths.html#env_VARS_FILES_PATH) |
+| 工作流 | 所有**用于工作流**的仓库加上 [`WORKFLOWS_PATH`](../customization/paths.html#env_WORKFLOWS_PATH) ，一起使用 |
+
+来自多个仓库的表单会合并到一个列表中。当其中两个仓库包含同名表单时，保留先加载的那个，
+并记录警告 `skipping duplicate form <name>` ，因此请保持表单名称在各仓库之间唯一。
+
+---
+
+## 故障排除
+
+大多数问题会显示在**拉取**列以及**显示上次拉取的输出**（或**显示上次推送的输出**）中，其中包含 git 自己的
+错误消息。
+
+- [仓库克隆或拉取失败](../troubleshooting.html#a-repository-clone-or-pull-failed)：认证、已知
+  主机和本地更改。
+- [表单仓库尚未克隆](../troubleshooting.html#the-forms-repository-is-not-cloned-yet)：在首次克隆之前，设计器
+  无法保存。
+- 卡在 `running` 的仓库会被重置为 `failed` ：重启后，在下一次启动时；运行其 git 操作的节点
+  停止响应 2 分钟后，一分钟内；以及无论如何在 2 小时后。请再次运行**拉取**。
+
+---
+
+## 本节内容
+
+每个主题都有单独的页面：
+
+| 页面 | 涵盖内容 |
+|---|---|
+| [添加仓库](adding.html) | 仓库页面、仓库的每个字段，以及在配置种子中声明仓库 |
+| [认证](authentication.html) | 使用令牌的 HTTPS、使用生成密钥的 SSH，以及自定义 git 命令 |
+| [拉取更改](pulling.html) | 定时、手动和 API 拉取，以及本地更改 |
+| [设计器与推送](designer.html) | 在设计器中编辑表单，并将其推送到仓库 |
diff --git a/i18n/zh/_use/repositories/pulling.md b/i18n/zh/_use/repositories/pulling.md
new file mode 100644
index 0000000..90b7d59
--- /dev/null
+++ b/i18n/zh/_use/repositories/pulling.md
@@ -0,0 +1,56 @@
+---
+layout: default
+title: 拉取更改
+parent: Git 仓库
+nav_order: 3
+translated_from: 1246850e9b868af155c96ce8f3f5d55f0464fb6e
+---
+
+# 拉取更改
+{: .no_toc }
+
+定时、手动和 API 拉取，以及本地更改
+{: .fs-6 .fw-300 }
+
+1. TOC
+{:toc}
+
+---
+
+## 拉取更改
+
+仓库可以按计划拉取、在启动时拉取、从页面拉取，或者通过 API 拉取；没有 webhook 端点。
+
+| 触发方式 | 方法 |
+|---|---|
+| 计划 | **启用定时拉取**并设置**拉取计划**，例如 `0 * * * *` 表示每小时一次 |
+| 启动 | **应用启动时拉取**会克隆仓库，如果已经克隆则拉取它 |
+| 设置页面 | 行菜单中的**拉取**，或列表上方的**全部拉取** |
+| 设计器 | **加载（仓库）**，它会拉取表单仓库并重新加载设计器；获取设计器锁时也会先拉取所有表单仓库 |
+| API | `POST /api/v2/repository/<name>/pull` （ `showSettings` 或 `showConnectionsSettings` ）或 `POST /api/v2/forms-repos/pull/<name>` （见下文） |
+
+### 从流水线或 webhook 拉取
+
+AnsibleForms 没有专门的 webhook 接收端，但 CI 作业或 git 服务器的 webhook 可以调用拉取端点。
+
+```bash
+curl -X POST -H "Authorization: Bearer $TOKEN" https://af.example.com/api/v2/repository/forms/pull
+```
+
+按照 [API 令牌](../profile/api-token.html)中的说明创建令牌，用户的角色需要拥有 `showSettings` 或
+`showConnectionsSettings` 。 `/api/v2/forms-repos/pull/<name>` 则需要 `showDesigner` 和 `allowFormDesign` ，并且设计器
+已开启（ [`SHOW_DESIGNER`](../customization/features.html#env_SHOW_DESIGNER) ）。 `GET /api/v2/repository/<name>` 会返回
+`head` 、 `status` 和 `output` ，因此流水线可以在拉取后检查实例运行的是哪个提交。
+
+### 本地更改
+
+拉取从不会覆盖尚未推送的工作，因此定时拉取会在运行前检查工作树。
+
+当工作树中有未提交的更改或未推送的提交时，以及当有设计器持有设计器锁时，定时拉取会被跳过。
+对含有冲突更改的工作树进行手动拉取会失败，并提示：
+
+```
+Repository '<name>' has local changes that block the pull. Use 'Save (repository)' to push them first, or discard them.
+```
+
+请推送这些更改，或者用行菜单中的**重置**丢弃它们，这会删除工作树并重新克隆。
diff --git a/i18n/zh/index.md b/i18n/zh/index.md
new file mode 100644
index 0000000..333b56a
--- /dev/null
+++ b/i18n/zh/index.md
@@ -0,0 +1,139 @@
+---
+layout: default
+title: 首页
+nav_order: 1
+description: "AnsibleForms：为 Ansible 自动化构建动态的、数据驱动的表单"
+permalink: /
+translated_from: 99aee5157823eac7674a411d032a7a133bb0ba5e
+---
+
+<div class="af-hero">
+  <div>
+    <h1 class="no_toc">面向 <span>Ansible</span> 的自助服务表单</h1>
+    <p class="af-hero-lead">
+      Ansible 是一款强大的自动化工具，但它终究是一个命令行应用程序，而 AWX/AAP/Ascender 缺少
+      能从多个来源收集数据的表单。AnsibleForms 让您可以构建动态的、数据驱动的表单，生成 extravars，
+      并将其发送到 Ansible、AWX/AAP/Ascender、Semaphore、Rundeck 或 Jenkins，在那里执行模板。
+    </p>
+    <div class="af-hero-actions">
+      <a href="installation/" class="btn btn-primary">安装 AnsibleForms</a>
+      <a href="first-form.html" class="btn btn-outline">构建您的第一个表单</a>
+    </div>
+  </div>
+  <div class="af-hero-shot">
+    <img src="assets/screenshots/dashboard.jpg" alt="AnsibleForms 仪表板">
+  </div>
+</div>
+
+## 功能
+
+AnsibleForms 能为您的 Ansible 环境带来什么，以及单个表单能做什么：
+
+<div class="af-features">
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-server" aria-hidden="true"></i>应用程序</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-play" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>自动化平台</strong><span>在 RTE 上运行 playbook，在 Ascender、Semaphore 等平台上运行模板</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-user-shield" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>访问控制</strong><span>角色和角色选项，支持本地、LDAP、Entra ID 和 OIDC 登录</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-calendar-days" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>调度</strong><span>稍后运行表单，或按 cron 调度运行</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-clock-rotate-left" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>作业历史</strong><span>跟踪、中止和重新运行作业</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-vault" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>凭据和机密</strong><span>保存凭据，或从 Vault 或 CyberArk 读取</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-code-branch" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>Git 仓库</strong><span>把表单、playbook 和配置保存在 Git 中</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-pen-ruler" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>设计器</strong><span>以 YAML 编辑表单，并进行校验</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-plug" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>API、MCP 和聊天</strong><span>从脚本、AI 代理或聊天中运行表单</span></span>
+      </li>
+    </ul>
+  </div>
+  <div class="af-feature-panel">
+    <div class="af-feature-title"><i class="fa-solid fa-rectangle-list" aria-hidden="true"></i>表单</div>
+    <ul class="af-feature-list">
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-sitemap" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>级联下拉框</strong><span>随其他字段变化的下拉框</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-database" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>表达式和数据源</strong><span>从数据库、REST API、文件和 JavaScript 填充字段</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-eye" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>字段依赖</strong><span>根据其他字段显示或隐藏字段</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-check-double" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>校验</strong><span>最小值、最大值、正则表达式等，可选择在服务器上检查</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-diagram-project" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>工作流和向导表单</strong><span>串联 playbook 和审批，或把输入拆分到多个页面</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-cubes" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>结构化字段</strong><span>基于可复用子表单的列表和对象</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-stamp" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>审批点</strong><span>暂停作业，直到有人批准</span></span>
+      </li>
+      <li>
+        <span class="af-feature-icon"><i class="fa-solid fa-bell" aria-hidden="true"></i></span>
+        <span class="af-feature-text"><strong>通知</strong><span>在作业事件发生时通过邮件、Slack、Teams、Telegram 或 webhook 通知</span></span>
+      </li>
+    </ul>
+  </div>
+</div>
+
+## 需要帮助？
+
+问题、缺陷和安全报告各有各的去处：
+
+<div class="af-cards af-quick">
+  <a class="af-card" href="troubleshooting.html">
+    <span class="af-card-icon"><i class="fa-solid fa-stethoscope"></i></span>
+    <strong>故障排除</strong>
+    <span>查找错误消息及其解决方法</span>
+    <span class="af-card-more">故障排除 &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/discussions" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-comments"></i></span>
+    <strong>提问</strong>
+    <span>向社区和维护者提问</span>
+    <span class="af-card-more">讨论区 &rarr;</span>
+  </a>
+  <a class="af-card" href="https://github.com/ansibleforms/ansibleforms/issues/new/choose" target="_blank" rel="noopener">
+    <span class="af-card-icon"><i class="fa-solid fa-bug"></i></span>
+    <strong>报告缺陷</strong>
+    <span>提交 issue，并附上复现步骤</span>
+    <span class="af-card-more">新建 issue &rarr;</span>
+  </a>
+  <a class="af-card" href="getting-help.html">
+    <span class="af-card-icon"><i class="fa-solid fa-life-ring"></i></span>
+    <strong>获取帮助</strong>
+    <span>应提供哪些信息，以及如何报告安全问题</span>
+    <span class="af-card-more">获取帮助 &rarr;</span>
+  </a>
+</div>
+
diff --git a/source/_config.yml b/source/_config.yml
index 9c2ee20..eea811b 100644
--- a/source/_config.yml
+++ b/source/_config.yml
@@ -50,16 +50,35 @@ docs_versions:
     title: "6.x"
     url: "/v6/"
 
-# Docs languages : the selector at the right of the header (_includes/language_select.html).
+# Docs languages : the selector at the right of the header (_includes/language_select.html),
+# in the app's order (client/src/config/languages.js), alphabetical by label.
 # Each language is its own build under /<code>/ ; docs_language marks the one this site is
 # written in. A language is listed here once its pages exist : its pages live in i18n/<code>/,
 # its settings in i18n/<code>.yml, and scripts/build-language.sh builds it.
 docs_language: "en"
 docs_languages:
+  - code: "ca"
+    label: "Català"
+  - code: "de"
+    label: "Deutsch"
   - code: "en"
     label: "English"
   - code: "es"
     label: "Español"
+  - code: "fr"
+    label: "Français"
+  - code: "it"
+    label: "Italiano"
+  - code: "nl"
+    label: "Nederlands"
+  - code: "pl"
+    label: "Polski"
+  - code: "pt"
+    label: "Português"
+  - code: "ja"
+    label: "日本語"
+  - code: "zh"
+    label: "简体中文"
 
 # Aux links (top right)
 aux_links:
diff --git a/source/_data/ui.yml b/source/_data/ui.yml
index 987a67d..61bfca9 100644
--- a/source/_data/ui.yml
+++ b/source/_data/ui.yml
@@ -53,3 +53,238 @@ es:
   aux:
     Images: Imágenes
   theme_credit: 'Este sitio usa <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, un tema de documentación para Jekyll.'
+ca:
+  language: Idioma
+  version: Versió
+  previous: "&larr; Anterior"
+  next: "Següent &rarr;"
+  prev_next_label: Pàgina anterior i següent
+  attribute: Atribut
+  comments: Comentaris
+  variable: Variable
+  choices_defaults: Opcions/Valors per defecte
+  choices: "Opcions:"
+  default: "Valor per defecte:"
+  default_choice: (per defecte)
+  examples: "Exemples:"
+  added: Afegit
+  secret: Secret
+  secret_title: "Conté un secret: mantén-lo fora del control de versions"
+  with_types: "Només disponible amb els tipus:"
+  search: Cerca
+  toc: Índex
+  on_this_page: En aquesta pàgina
+  no_results: No s'ha trobat cap resultat
+  theme: Tema
+  aux:
+    Images: Imatges
+  theme_credit: 'Aquest lloc fa servir <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, un tema de documentació per a Jekyll.'
+de:
+  language: Sprache
+  version: Version
+  previous: "&larr; Zurück"
+  next: "Weiter &rarr;"
+  prev_next_label: Vorherige und nächste Seite
+  attribute: Attribut
+  comments: Kommentare
+  variable: Variable
+  choices_defaults: Auswahl/Standardwerte
+  choices: "Auswahl:"
+  default: "Standard:"
+  default_choice: (Standard)
+  examples: "Beispiele:"
+  added: Hinzugefügt
+  secret: Geheim
+  secret_title: "Enthält ein Geheimnis: nicht in die Versionskontrolle aufnehmen"
+  with_types: "Nur verfügbar mit den Typen:"
+  search: Suchen
+  toc: Inhaltsverzeichnis
+  on_this_page: Auf dieser Seite
+  no_results: Keine Ergebnisse gefunden
+  theme: Design
+  aux:
+    Images: Images
+  theme_credit: 'Diese Website verwendet <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, ein Dokumentations-Theme für Jekyll.'
+fr:
+  language: Langue
+  version: Version
+  previous: "&larr; Précédent"
+  next: "Suivant &rarr;"
+  prev_next_label: Page précédente et suivante
+  attribute: Attribut
+  comments: Commentaires
+  variable: Variable
+  choices_defaults: Choix/Valeurs par défaut
+  choices: "Choix :"
+  default: "Par défaut :"
+  default_choice: (par défaut)
+  examples: "Exemples :"
+  added: Ajouté
+  secret: Secret
+  secret_title: "Contient un secret : à garder hors du contrôle de version"
+  with_types: "Disponible uniquement avec les types :"
+  search: Rechercher
+  toc: Table des matières
+  on_this_page: Sur cette page
+  no_results: Aucun résultat
+  theme: Thème
+  aux:
+    Images: Images
+  theme_credit: 'Ce site utilise <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, un thème de documentation pour Jekyll.'
+it:
+  language: Lingua
+  version: Versione
+  previous: "&larr; Precedente"
+  next: "Successiva &rarr;"
+  prev_next_label: Pagina precedente e successiva
+  attribute: Attributo
+  comments: Commenti
+  variable: Variabile
+  choices_defaults: Scelte/Valori predefiniti
+  choices: "Scelte:"
+  default: "Predefinito:"
+  default_choice: (predefinito)
+  examples: "Esempi:"
+  added: Aggiunto
+  secret: Segreto
+  secret_title: "Contiene un segreto: tienilo fuori dal controllo di versione"
+  with_types: "Disponibile solo con i tipi:"
+  search: Cerca
+  toc: Indice
+  on_this_page: In questa pagina
+  no_results: Nessun risultato trovato
+  theme: Tema
+  aux:
+    Images: Immagini
+  theme_credit: 'Questo sito usa <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, un tema di documentazione per Jekyll.'
+nl:
+  language: Taal
+  version: Versie
+  previous: "&larr; Vorige"
+  next: "Volgende &rarr;"
+  prev_next_label: Vorige en volgende pagina
+  attribute: Attribuut
+  comments: Opmerkingen
+  variable: Variabele
+  choices_defaults: Keuzes/Standaardwaarden
+  choices: "Keuzes:"
+  default: "Standaard:"
+  default_choice: (standaard)
+  examples: "Voorbeelden:"
+  added: Toegevoegd
+  secret: Geheim
+  secret_title: "Bevat een geheim: houd het buiten versiebeheer"
+  with_types: "Alleen beschikbaar bij de types:"
+  search: Zoeken
+  toc: Inhoudsopgave
+  on_this_page: Op deze pagina
+  no_results: Geen resultaten gevonden
+  theme: Thema
+  aux:
+    Images: Images
+  theme_credit: 'Deze site gebruikt <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, een documentatiethema voor Jekyll.'
+pl:
+  language: Język
+  version: Wersja
+  previous: "&larr; Poprzednia"
+  next: "Następna &rarr;"
+  prev_next_label: Poprzednia i następna strona
+  attribute: Atrybut
+  comments: Komentarze
+  variable: Zmienna
+  choices_defaults: Opcje/Wartości domyślne
+  choices: "Opcje:"
+  default: "Domyślnie:"
+  default_choice: (domyślnie)
+  examples: "Przykłady:"
+  added: Dodano
+  secret: Sekret
+  secret_title: "Zawiera sekret: trzymaj go poza systemem kontroli wersji"
+  with_types: "Dostępne tylko dla typów:"
+  search: Szukaj
+  toc: Spis treści
+  on_this_page: Na tej stronie
+  no_results: Brak wyników
+  theme: Motyw
+  aux:
+    Images: Obrazy
+  theme_credit: 'Ta strona korzysta z <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, motywu dokumentacji dla Jekylla.'
+pt:
+  language: Idioma
+  version: Versão
+  previous: "&larr; Anterior"
+  next: "Seguinte &rarr;"
+  prev_next_label: Página anterior e seguinte
+  attribute: Atributo
+  comments: Comentários
+  variable: Variável
+  choices_defaults: Opções/Valores predefinidos
+  choices: "Opções:"
+  default: "Predefinição:"
+  default_choice: (predefinição)
+  examples: "Exemplos:"
+  added: Adicionado
+  secret: Segredo
+  secret_title: "Contém um segredo: mantém-no fora do controlo de versões"
+  with_types: "Disponível apenas com os tipos:"
+  search: Pesquisar
+  toc: Índice
+  on_this_page: Nesta página
+  no_results: Nenhum resultado encontrado
+  theme: Tema
+  aux:
+    Images: Imagens
+  theme_credit: 'Este site usa o <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>, um tema de documentação para Jekyll.'
+ja:
+  language: 言語
+  version: バージョン
+  previous: "&larr; 前へ"
+  next: "次へ &rarr;"
+  prev_next_label: 前のページと次のページ
+  attribute: 属性
+  comments: 説明
+  variable: 変数
+  choices_defaults: 選択肢/既定値
+  choices: "選択肢:"
+  default: "既定値:"
+  default_choice: (既定)
+  examples: "例:"
+  added: 追加
+  secret: シークレット
+  secret_title: "シークレットを含みます。バージョン管理に含めないでください"
+  with_types: "次のタイプでのみ使用可能:"
+  search: 検索
+  toc: 目次
+  on_this_page: このページの内容
+  no_results: 該当する結果はありません
+  theme: テーマ
+  aux:
+    Images: イメージ
+    Charts: チャート
+  theme_credit: 'このサイトは Jekyll 用のドキュメントテーマ <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a> を使用しています。'
+zh:
+  language: 语言
+  version: 版本
+  previous: "&larr; 上一页"
+  next: "下一页 &rarr;"
+  prev_next_label: 上一页和下一页
+  attribute: 属性
+  comments: 说明
+  variable: 变量
+  choices_defaults: 可选值/默认值
+  choices: "可选值："
+  default: "默认值："
+  default_choice: （默认）
+  examples: "示例："
+  added: 新增于
+  secret: 机密
+  secret_title: "包含机密信息：请勿纳入版本控制"
+  with_types: "仅适用于以下类型："
+  search: 搜索
+  toc: 目录
+  on_this_page: 本页内容
+  no_results: 未找到结果
+  theme: 主题
+  aux:
+    Images: 镜像
+  theme_credit: '本站使用 Jekyll 文档主题 <a href="https://github.com/just-the-docs/just-the-docs">Just the Docs</a>。'
diff --git a/source/_includes/lunr/custom-index.js b/source/_includes/lunr/custom-index.js
new file mode 100644
index 0000000..73ecfa4
--- /dev/null
+++ b/source/_includes/lunr/custom-index.js
@@ -0,0 +1,63 @@
+{%- comment -%}
+  Runs inside the theme's search index builder (just-the-docs.js), once per page indexed.
+
+  Japanese and Chinese are written without spaces, and lunr splits words on spaces : a
+  whole sentence became one token, and its trimmer then removed every character that is
+  not a latin letter, so a search in those languages found nothing. In those two builds
+  the tokenizer splits every run of Japanese or Chinese characters into overlapping pairs
+  (設定画面 : 設定 定画 画面), on the pages and in what the reader types alike, and trims
+  the tokens by Unicode letters instead. The other languages keep the theme's search.
+{%- endcomment -%}
+{%- if site.docs_language == "ja" or site.docs_language == "zh" %}
+if (!lunr.afCjk) {
+  var afTokenizer = lunr.tokenizer;
+  var afCjkRun = /[぀-ヿ㐀-䶿一-鿿豈-﫿ｦ-ﾟ]+/g;
+  var afEdges = /^[^\p{L}\p{N}]+|[^\p{L}\p{N}]+$/gu;
+  lunr.tokenizer = function(input, metadata) {
+    var out = [];
+    afTokenizer(input, metadata).forEach(function(token) {
+      var str = token.toString().replace(afEdges, '');
+      var start = token.metadata.position ? token.metadata.position[0] : 0;
+      var offset = token.toString().indexOf(str);
+      var pieces = [];
+      var last = 0;
+      var match;
+      // Step 1 : the latin parts stay whole, every CJK run becomes pairs of characters
+      afCjkRun.lastIndex = 0;
+      while ((match = afCjkRun.exec(str)) !== null) {
+        if (match.index > last) {
+          pieces.push([str.slice(last, match.index), last]);
+        }
+        var run = match[0];
+        if (run.length === 1) {
+          pieces.push([run, match.index]);
+        }
+        for (var i = 0; i + 1 < run.length; i++) {
+          pieces.push([run.slice(i, i + 2), match.index + i]);
+        }
+        last = match.index + run.length;
+      }
+      if (last < str.length) {
+        pieces.push([str.slice(last), last]);
+      }
+      // Step 2 : each piece keeps its position in the page, for the search previews
+      pieces.forEach(function(piece) {
+        var text = piece[0].replace(afEdges, '');
+        if (text === '') {
+          return;
+        }
+        var meta = lunr.utils.clone(token.metadata) || {};
+        meta.position = [start + offset + piece[1], piece[0].length];
+        meta.index = out.length;
+        out.push(new lunr.Token(text, meta));
+      });
+    });
+    return out;
+  };
+  lunr.tokenizer.separator = afTokenizer.separator;
+  lunr.afCjk = true;
+}
+this.tokenizer = lunr.tokenizer;
+this.pipeline.remove(lunr.trimmer);
+this.pipeline.remove(lunr.stopWordFilter);
+{%- endif %}